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.
Comments
0 comments
Please sign in to leave a comment.