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:

The Request:

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.

The Response

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.

Note: The job result will be in a COMPLETED, FAILED, or CANCELLED state.

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.

Note: At this stage the type, plugin, and version are strings, which do not have any conventional schema defined. It is the developer’s responsibility to define the structure for the action / resource.

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: