Engine Processor Registry
Zeebe registra ~80 processors contra ~25 ValueTypes en
EngineProcessors.createEngineProcessors(). Este método factory es el punto de entrada que define TODO el comportamiento del engine, mapeando cada combinación (ValueType, Intent) a su processor correspondiente.
EngineProcessors — el factory method¶
EngineProcessors.createEngineProcessors() es un método estático que:
- Crea todas las dependencias compartidas (behaviors, metrics, schedulers)
- Registra cada processor contra su
(ValueType, Intent)enTypedRecordProcessors - Registra listeners que reaccionan a eventos del stream
- Retorna el registro completo listo para el StreamProcessor
Orden de registro¶
El orden de registro es significativo para la inicialización pero no para el procesamiento (el dispatch es por key en un map):
- Deployment (3 processors)
- Messages (~8 processors via
MessageEventProcessors) - BPMN Process (~12 processors via
BpmnProcessors) - Decisions (1 processor)
- Jobs (~8 processors via
JobEventProcessors) - User Tasks (1 processor, múltiples intents)
- Incidents (3 processors)
- Resources (3 processors)
- Signals (1 processor)
- Conditionals (2 processors)
- Command Distribution (3 processors)
- Identity (~18 processors: Users, Roles, Groups, Tenants, Mappings, Auth)
- Clock, Scaling, Batch Ops, Cluster Variables, Metrics, History, Listeners, Expressions
Conteo total¶
| Categoría | Processors | ValueTypes |
|---|---|---|
| BPMN execution | 1 (BpmnStreamProcessor) | PROCESS_INSTANCE (~15 intents) |
| Process lifecycle | 7 | PROCESS_INSTANCE_CREATION, MODIFICATION, MIGRATION, BATCH |
| Deployment | 3 | DEPLOYMENT, DEPLOYMENT_DISTRIBUTION |
| Jobs | ~8 | JOB, JOB_BATCH |
| Messages | ~8 | MESSAGE, MESSAGE_SUBSCRIPTION, PROCESS_MESSAGE_SUBSCRIPTION |
| Timers | 2 | TIMER |
| User Tasks | 1 | USER_TASK (~10 intents) |
| Incidents | 3 | INCIDENT |
| Identity | ~18 | USER, ROLE, GROUP, TENANT, MAPPING_RULE, AUTHORIZATION |
| Otros | ~29 | SIGNAL, CONDITIONAL, COMMAND_DISTRIBUTION, etc. |
| Total | ~80 | ~25 ValueTypes |
BpmnProcessors — el sub-registry BPMN¶
BpmnProcessors.addBpmnStreamProcessor() registra los processors específicos de ejecución BPMN:
-
BpmnStreamProcessor: registrado para TODOS los
ProcessInstanceIntent.isBpmnElementCommand()intents (ACTIVATE_ELEMENT, COMPLETE_ELEMENT, TERMINATE_ELEMENT, etc.). Es el dispatcher central que delega a los 24 element processors (ver concepts/bpmn-element-processors). -
ProcessInstanceCancelProcessor: maneja CANCEL — termina una instancia completa.
-
ProcessInstanceCreation: CREATE y CREATE_WITH_AWAITING_RESULT (ver concepts/process-instance-creation).
-
ProcessInstanceModification: MODIFY — permite activar/terminar elementos en runtime.
-
ProcessInstanceMigration: MIGRATE — migra instancias entre versiones de un proceso.
-
ProcessInstanceBatch: TERMINATE y ACTIVATE en batch.
-
Ad-Hoc Sub-Process: ACTIVATE y COMPLETE para instrucciones ad-hoc.
-
Timers: TRIGGER y CANCEL (ver concepts/timer-system).
-
Messages: CREATE, CORRELATE, DELETE para process message subscriptions.
-
Variables: UPDATE para VariableDocument.
-
Conditionals: TRIGGER para conditional subscriptions.
Listeners registrados¶
Además de processors, el engine registra listeners que se ejecutan periódicamente o reactivamente:
| Listener | Función | Scheduling |
|---|---|---|
DueDateTimerCheckScheduler |
Dispara timers cuyo due date ha pasado | Demand-driven, 100ms |
PendingProcessMessageSubscriptionCheckScheduler |
Reintenta correlación pendiente | Periódico |
DeploymentRedistributionScheduler |
Reintenta distribución de deployments | Periódico |
CommandRedistributionScheduler |
Reintenta distribución de commands | Periódico |
IncidentBehavior |
Auto-crea incidents en failures | Reactivo |
CommandDistributionBehavior |
Maneja acknowledgments de distribución | Reactivo |
Shared dependencies¶
BpmnBehaviorsImpl se crea una sola vez y se inyecta en múltiples processors. Contiene:
- processingState: acceso al estado mutable (RocksDB)
- writers: para escribir commands, events, rejections, responses
- subscriptionCommandSender: para enviar commands cross-partition
- routingInfo: información de routing dinámico
- timerChecker: scheduler de timers
- jobStreamer: streaming de jobs a workers
- clock: fuente de tiempo (inyectable para testing)
- authCheckBehavior: verificación de autorización
- decisionBehavior: evaluación de DMN
- expressionLanguageMetrics: métricas de FEEL
Implicaciones para simplificación¶
Para un MVP, los ~80 processors se pueden reducir a ~15-20:
| Mantener | Simplificar | Eliminar |
|---|---|---|
| BpmnStreamProcessor | Identity (de ~18 a 3) | Scaling |
| ProcessInstanceCreation | Command Distribution (no multi-partition) | Batch Operations |
| DeploymentCreate | Jobs (merge activate + stream) | Cluster Variables |
| Job processors | Messages (single-partition) | History Deletion |
| Timer processors | Ad-Hoc Sub-Process | |
| Incident processors | Global Listeners | |
| User Task processor | Expressions API | |
| Variable update | Job/Usage Metrics processors | |
| Signal broadcast | Resource Reexport |