Running Multiple Versions of a Plugin

You can run multiple versions of the same plugin concurrently in JEF as shown below:

The following scenarios are possible:

Scenario 1: Deploying a Brand New Plugin

The first version of the ActionConfiguration (type+plugin+version1) definition is deployed in the job executor.

  • The Registry Service obtains the type+plugin+version1 definition.
  • Enterprise deploys type+plugin+version1 of the new definition. Enterprise creates a new ActionConfig using the type+plugin+version1 definition and generates the ActionConfig (UUID1+revision1). The Execution Configuration Service (ECS) stores UUID1+revision1.
  • Enterprise executes UUID1+revision1.
  • The job executor receives type+plugin JobRequest for the UUID1+revision1 and type+plugin+version1 definition is used.

Scenario 2: Updating the Version of a Previously Deployed Plugin

The next version of the ActionConfiguration (type+plugin+version2) is deployed. This replaces the previous version (version1) in the job executor.

  • The Registry Service overwrites the previous version, with the latest version (type+plugin+version2). Only the latest is stored in the Registry Service.
  • Enterprise deploys type+plugin+version2. Enterprise creates a new ActionConfig using the type+plugin+version2 definition and generates the ActionConfig (UUID2+revision2). The Execution Configuration Service (ECS) stores UUID2+revision2.
  • Enterprise executes UUID2+revision2.
  • The job executor receives a type+plugin JobRequest for UUID2+revision2 and type+plugin+version2 definition is used.

Scenario 3: Running Either the Latest or Previous Version

Enterprise can run previous or new ActionConfig versions. This can be done in the following ways:

  • Using the Enterprise UI: You can run the latest ActionConfig version of a plugin using the Enterprise UI. In keeping with scenario 2, the flow is as follows: UUID2+revision2 (from type+plugin+version2).
  • Using a Workflow: A workflow always uses the ActionConfig version that has been created. For example: UUID1+revision1 is used if you created/updated the Workflow when UUD1+revision1 was the latest version.
  • Using a REST Endpoint: You can select the ActionConfig to use for the execution using a REST endpoint. For example: POST: .api/jobs

Based on the scenarios mentioned above, you (as the plugin developer) have two options:

1) You can deploy the latest version the plugin and process a different JSON with the action configuration (ActionConfig) from the previous version.

2) You can deploy the latest version of the plugin with a different Java class name and a new version in the annotation.

For example:

@ActionPlugin(uuid = "16bd9321-19bd-48b3-a3b0-f20d689660d0", type = "smoke", plugin = "async-smoke-version-action",version = "1.0.2", actionConfiguration = AsyncSmokeActionConfiguration.class)
public class AsyncSmokeActionV2Executor extends ActionExecutor<AsyncSmokeActionConfiguration> {
….
@ActionPlugin(uuid = "16bd9321-19bd-48b3-a3b0-f20d689660d0", type = "smoke", plugin = "async-smoke-version-action", version = "1.0.3", actionConfiguration = AsyncSmokeActionConfiguration.class)
public class AsyncSmokeActionV3Executor extends ActionExecutor<AsyncSmokeActionConfiguration> {		
https://help.ooyala.com/sites/all/libraries/dita/en/media-logistics/flex/dev/70/jef_programming_guide_running_multiple_versions.html

Was this article helpful?