Life Cycle Overview
Below is a high level overview of the request that Enterprise makes to the end node service execution, and the response that is returned:
1) JEF ‘clients’ such as Enterprise use a message queue to send job execution requests. These requests reference the existing action configuration / resource configuration that has been previously saved in JEF. This includes every CRUD (create, read, update, delete) action configuration and resource configuration from the Enterprise UI or REST API.
2) JEF’s internal service consumes the job execution request and resolves the action and resource configuration that is referenced by the UUID and revision number. It then dispatches to the relevant job synchronous, asynchronous executors, or resource services.
1) The job sync executors process the jobs through the REST API. JEF’s internal service retrieves the result and publishes it back to the Enterprise message queue in the form of a message.
2) The job async executor and resource service processes the jobs from the message queue. These are long running tasks. The type, plugin, and version are used to define the RabbitMQ topics. This allows messages to be dispatched to a queue, which can be consumed by different types of job execution services that are either internal or external to JEF. For example: 3rd party integrations.
3) The job async executor sends a message back to Enterprise. It will either send:
- A Progress Update: this can have one of the following statuses: RUNNING, TIMED_OUT, FAILED.
- A Final Response: a final response will either be in a CANCELLED or COMPLETED state.
This diagram provides you with a visual representation of the JEF lifecycle: