1.5 KiB
Runtime tachograph Esper scope processing
This document is kept for compatibility. The preferred architecture is now the common Runtime Processing execution model.
Preferred endpoint:
POST /api/eventhub/runtime-processing/executions
Use:
{
"processingPlanKey": "driver-working-time-v1"
}
Legacy compatibility endpoint:
POST /api/eventhub/runtime-processing/tachograph/esper-processing
still exists and delegates through the common runtime processing infrastructure.
Legacy profile endpoint:
POST /api/eventhub/runtime-processing/event-processing
with:
{
"profileKey": "tachograph-driver-esper-v1"
}
also remains available, but new clients should use processingPlanKey and /executions.
When the runtime scope must mix file sessions, direct source databases, and EventHub-backed canonical events in one request, use /executions with per-source sourceInputs. The tachograph compatibility endpoints remain useful for file-session-centric scopes, but they are no longer the best shape for mixed-source runtime execution.
The current driver-working-time-v1 plan uses these modules:
event-to-activity-intervals
event-to-vehicle-usage-intervals
vehicle-evidence-attachment
support-evidence-normalization
driving-derived-projections
It can load runtime events from multiple sources and sessions, partition them by driver, attach vehicle-only evidence by vehicle/time overlap, normalize support evidence, and run the existing tachograph Esper/Java processing chain per driver partition.