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

  • JEF ‘clients’, such as Flex Enterprise, use a message queue to send job execution requests. These requests reference the existing Action Configuration / Resource Configuration that Enterprise previously saved in JEF.
  • 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

  • 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.
  • The job async executor and resource service processes the jobs from the message queue. Job Async are usually long running tasks. The type, plugin, and version are used to define the RabbitMQ topics.

    Note: At this stage the type, plugin, and version are free strings, and JEF does not impose any specific format. However, Ooyala Flex plugins follow a <major>.<medium>.<minor> number schema for our plugins. Medium is only changed when it is not compatible with the plugin configuration/logic.

3) The job async executor sends messages 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:

https://help.ooyala.com/sites/all/libraries/dita/en/media-logistics/flex/dev/70/jef_programming_guide_lifecycle_overview.html