Graph Events
Each event carries properties of a graph, which is the source of the event.
If there is an event listener specified, the task may use these properties.
For example the next graphs in a chain may use "EVENT_FILE_NAME" placeholder which was activated by the first graph in the chain.
Graph properties, which are set specifically for each graph run (e.g. RUN_ID), are overridden by the last graph.
Types of graph events
Graph started
The Graph started event is created, when a graph starts its execution (i.e. it gets to the RUNNING status). If the graph was enqueued, then this event is triggered when the graph is pulled from the queue and started.
Graph phase finished
The Graph phase finished event is created, every time a graph phase is finished and all its nodes are finished with status FINISHED_OK.
Graph finished
The Graph finished event is created, when all phases and nodes of a graph are finished with FINISHED_OK status.
Graph error
The Graph error event is created, when a graph cannot be executed for some reason, or when any node of graph fails.
Graph aborted
The Graph aborted event is created, when a graph is explicitly aborted.
Graph timeout
The Graph timeout event is created, when a graph runs longer than a specified interval. If the graph 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 a graph timeout event. You can specify the interval in seconds, minutes or hours.
Graph unknown status
The Graph 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 graph run. The Server automatically changes the state of the graph to Not Available and sends a graph unknown status 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).