JEF: ExecutionStep walkthrough

Preparing for ExecutionStep execution

The ActionExecutor class enables you to register the ExecutionStep plugin function with the specific logic.

Example:

  @Componentf

  @Scope("prototype")

  @Slf4j

  @PluginScope(value = PluginScopeType.DEVELOPMENT)

  @ActionPlugin(uuid = "3ab237d4-0b19-4f01-8ded-396ee5444284", type = "smoke",
  plugin = "async-smoke-action",

  version = "1.2", actionConfiguration = AsyncSmokeActionConfiguration.class,

  executionStep = AsyncSmokeExecutionStep.class, executionStepData = AsyncSmokeExecutionStepData.class)

  public class AsyncSmokeActionExecutor extends ActionExecutor <AsyncSmokeActionConfiguration>
  {

  …

ActionExecutor.execute(...) is called for the first time using the following method to execute a job request:

  @Override

  @SneakyThrows

  public ActionExecutorResponse execute(ExecutionStepData executionStepData) {

  // logic to run the plugin for the first time

  …

The plugin developer is responsible for:

• Preparing task execution (see executionStepData below for further information).
• Preparing any other logic required for plugin behaviour.

ExecutionStep implementation responsibilities

Once the first call to ActionExecutor.execute has been made, ExecutionStep.execute(ExecutionStepData) is subsequently called until the job completes, fails, or is cancelled using the following method:

  @Override

  public ActionExecutorMessage execute(Job job, AsyncSmokeExecutionStepData executionStepData)
  {

Plugin developer is responsible now for the following:

• Taking the executionStepData from the latest iteration.
• Implementing any other logic required as part of the plugin behaviour.
• Returning an ActionExecutorMessage for every call to the ExecutionStep.execute(...) plugin if job is RUNNING, along with a message. This will be propagated in Dalet Flex Enterprise and will show up in the job history.
• Returning an ActionExecutorResponse with a COMPLETED state when the job has completed successfully.

If ExecutionStep.execute(...) doesn't return in a deadline, the JEF watcher running periodically will mark this job as TIMED_OUT after two deadlines (see JEF Feature Guide for more information).

Further configuration options

requiresExecutionStepContext, default to false, the developer can control if the ExecutionStep has the ExecutionStepContext available. ExecutionStepContext hosts properties such as:

  private final String executionId;

  private final String workflowId;

  private ActionConfiguration actionConfiguration;

  private ResourceConfiguration resourceConfiguration;

  private final JsonNode actionConfigJson;

  private final JsonNode resourceConfigJson;

  private final List<FlexObjectReference> flexObjectReferences;

  private final String assetContext;

  private Map<String, Object> jobContextVariables;

  private Map<String, Object> workflowContextVariables;

  ..

  private final Class<? extends ActionConfiguration> actionConfigurationClass;

  private String userId;

This could be useful in case that the plugin need to access several of these properties during the life of the job.
Its inclusion has a slight performance impact, so enable this only when you actually need it.

deleteExecutionStepDataWhenTerminated, default to true, the developer can control if ExecutionStepData is deleted from JEF repository after the job is CANCELLED or COMPLETED.

Post-execution step options

The methods onCompleted(), onCancel(), or onFailed() will be called after the ExecutionStep.execute(...) changes the job state to the respective terminal state.

Developers should not change the job status at this point, as the job has been terminated and propagated to the original Enterprise client. This method gives the developer the option to add any required logic before the ActionExecutor is finally discarded.