Each event carries properties of the event source job.
If there is an event listener specified, a task may use these properties.
For example, the next job in the chain may use "EVENT_FILE_NAME" placeholder which activated the first job in the chain.
Job properties, which are set specifically for each run (e.g.
RUN_ID), are overridden by the last job.
Types of jobflow events
A Jobflow started event is created, when a jobflow starts its execution (i.e. it gets to the RUNNING status). If the jobflow was enqueued, then this event is triggered when the jobflow is pulled from the queue and started.
Jobflow phase finished
The Jobflow phase finished event is created every time a jobflow phase is finished and all its nodes are finished with the
The Jobflow finished event is created, when all phases and nodes of a jobflow are finished with the
The Jobflow error event is created, when a jobflow cannot be executed for some reason, or when any node of the jobflow fails.
The Jobflow aborted event is created, when a jobflow is explicitly aborted.
The Jobflow timeout event is created, when a jobflow runs longer than a specified interval. If the jobflow was enqueued, then the time it spent waiting in the queue is not taken into its run time - only the time it actually spent running is used (i.e. when it’s in RUNNING state).
You have to specify the Job timeout interval for each listener of the jobflow timeout event. You can specify this interval in seconds, minutes or hours.
Jobflow unknown status
The Jobflow unknown status event is created, when the Server, during the startup, detects run records with undefined status in the Execution History. Undefined status means, that the Server has been killed during the jobflow run. The server automatically changes the state of the jobflow to Not Available and sends the jobflow status unknown event.
Please note, that this works just for executions which have a persistent record in the Execution History. It is possible to execute a transformation without a persistent record in the Execution History, typically for better performance of fast running transformations (e.g. using Data Services).