Expand my Community achievements bar.

Don’t miss the AEM Skill Exchange in SF on Nov 14—hear from industry leaders, learn best practices, and enhance your AEM strategy with practical tips.
SOLVED

How to get Workflow event type/ Launcher details in workflow process step AEM?

Avatar

Level 3

Hi, Is there a way to access workflow event type or workflow launcher details in backend java workflow process step?

 

Usecase: We have multiple workflow launchers (created, modified, deleted) using the same workflow model. Based on type of event, we need to take different action within the workflow process step.

 

We could not find a way to get the event type in the backend java class. Just wondering if anyone has done this before.

 

 

Thanks

1 Accepted Solution

Avatar

Correct answer by
Employee Advisor

In that case I would not use the workflow launcher, but rather work either with a JCR Observation Listener or a Sling ResourceChangeEvent handler. They give you much more details about the type of action which happened, and then you can invoke the workflow and provide the details in the invocation.

 

WorkflowSession wfSession = ...
WorkflowModel model = wfSession.getModel("/path/to/wf/model");
WorkflowData data = wfSession.newWorkflowData("JCR_PATH","/path/to/the/payload");
Map<String,Object> metadata = new HashMap<>();
metadata.put("reason","changed");
wfSession.startWorkflow(model, data, metadata);

With this approach you make the "reason" available in the workflow, and of course it should be related to the actual reason (this information is available from both types of event handling).

 

And then you can access this information like this in a workflow step:

[...]
public class MyProcess implements WorkflowProcess {
[...]
execute(WorkItem item, WorkflowSession session, MetaDataMap args) {
  String reason = args.get("reason",String.class);
}
[...]
}

 

 

View solution in original post

7 Replies

Avatar

Community Advisor

Hi @beast42 

Hope below code will be helpfull

 

List<HistoryItem> historyItems = workflowSession.getHistory(workitem.getWorkflow());

for (HistoryItem historyItem : historyItems) {
String itemType = historyItem.getWorkItem().getNode().getType();
String itemTitle = historyItem.getWorkItem().getNode().getTitle();

if ((null != itemType && itemType.equals(WorkflowNode.TYPE_PARTICIPANT))
&& (null != itemTitle && itemTitle.equalsIgnoreCase(McDConstants.STEP_NOTIFY_REVIEWER))) {
rejectionComment = historyItem.getComment();
break;
}
}

Avatar

Level 3

Thanks for your response.

 

Looks like the code snippet shared by you is for dynamic participant step. My use-case is different.

Avatar

Community Advisor

@beast42 Oh In that case i am not sure we have any option for that. 

Avatar

Employee Advisor

Hi,

 

no, this is not possible. The workflow does not know about the circumstances it was launched. What's the exact usecase you are working on?

Avatar

Level 3

Hi, Thanks for the response. 

 

Exact use-case: We are syncing assets created under specific folder in DAM with a third party systems. We need to capture asset creation, modification and deletion events and call 3rd party REST API with required details. 

 

We have multiple workflow launchers (created, modified, deleted) using the same workflow model. Based on type of event, we need to take different action within the workflow process step.

Avatar

Correct answer by
Employee Advisor

In that case I would not use the workflow launcher, but rather work either with a JCR Observation Listener or a Sling ResourceChangeEvent handler. They give you much more details about the type of action which happened, and then you can invoke the workflow and provide the details in the invocation.

 

WorkflowSession wfSession = ...
WorkflowModel model = wfSession.getModel("/path/to/wf/model");
WorkflowData data = wfSession.newWorkflowData("JCR_PATH","/path/to/the/payload");
Map<String,Object> metadata = new HashMap<>();
metadata.put("reason","changed");
wfSession.startWorkflow(model, data, metadata);

With this approach you make the "reason" available in the workflow, and of course it should be related to the actual reason (this information is available from both types of event handling).

 

And then you can access this information like this in a workflow step:

[...]
public class MyProcess implements WorkflowProcess {
[...]
execute(WorkItem item, WorkflowSession session, MetaDataMap args) {
  String reason = args.get("reason",String.class);
}
[...]
}