This document outlines the steps required to add a new task to the EPM Component Workflow Orchestrator. Follow the instructions carefully to ensure successful integration.
Before proceeding to add a task to workflow, it is recommended to watch this demo for a quick example of creating a workflow and invoking it end to end.
This guide assumes that the functionality you want to invoke as part of your task are identified and agreed upon with the team.
Go to the class CriticalWorkflowName
and create an ENUM representing your task. For the sake of this guide, we will name our task DEMO_TASK
.
Under the package src/main/kotlin/io/atlassian/micros/responsibility/model/workflow/scheduler/v1/runner/concrete
, create a class that while be responsible for invoking the service layer that has your functionality in it.
DemoWorkflowRunner
class. It needs to override and implement the runWorkflow
function.runWorkflow
function, you can define your business logic of the task.Identify which order you want to task to execute in. Once identified, create an instance of your runner class you created in Step 2 above.
Example:
1 2runner = DemoWorkflowRunner( // Define your Constructor fields to inject epmWorkflowTrackingHistoryRepository, meterRegistry // Etc. )
This step will show how to run the workflow orchestrator and validate functionalities of your new task provided by the workflow orchestrator.
/api/asyncJobs/componentWorkflows
.async_job_tracking_history
table. You should see a row with job_type=COMPONENT_WORKFLOW_SCHEDULER
showing status IN-PROGRESS
.epm_workflow_status_tracking_history
table. Depending on the order in which your task is defined, you will not see a row for your task until the previous tasks are completed. In our case, we should see a row where workflow_name=DEMO_WORKFLOW
with the appropriate status.SUCCESS
./api/asyncJobs/componentWorkflows
. The response object will return an id
/api/asyncJobs/{asyncJobId}
where the asyncJobId
is the id
from step 1."workflowName":"DEMO_WORKFLOW"
with a "status":"SUCCESS"
.Once tested in Staging, it is recommended to create a chart for your task on the WorkflowOrchestrator SignalFX Dashboard. Default metrics provided in the orchestrator should have a chart for your task. These would include job Success/Failure and duration. Reference existing charts on the dashboard for a blueprint on how to create one for your workflow.
One of the enhancements introduced via the workflow orchestrator is to enable debugging in Splunk with easy lookup. If at any point during your implementation of a new task/workflow you find that an error has occurred, a task status FAILURE
is returned or an unknown exception has occurred, you can leverage Splunk to debug and pinpoint the cause.
The way this is achieved is by having EPM backend code use one traceId
for the duration of a Workflow.
traceId
pertaining to the workflow or task you executed and want to root cause on.BaseComponentWorkflowOrchestrator
class where we log Creating Workflow Orchestrator Job.
1 2`micros_responsibility-model` env="prod-east" "Creating Workflow Orchestrator Job."
traceId
as in the example below.1 2{ [-] ec2: { [+] } env: prod-east level: INFO logger_name: io.atlassian.micros.responsibility.model.service.workflow.scheduler.v1.orchestrator.BaseComponentWorkflowOrchestrator m: { [+] } message: Creating Workflow Orchestrator Job. micros_container: responsibility-model spanId: 1edce45e4364d14d thread_name: boundedElastic-170 time: 2025-03-18T15:51:57.548643498Z traceId: 7cc02e860238ab5dff4543783114fb6b traceSampled: false }
descending
order, you will likely see what caused your workflow to fail within the first page of results. This is by design as the orchestrator is written to catch and log any exceptions and stop the workflow when discovered. Meaning, very few logs should show up after the exception.1 2`micros_responsibility-model` env="prod-east" "7cc02e860238ab5dff4543783114fb6b"
Rate this page: