AEM Workflow - Unable to Save an Array to WorkItem me...

[pankaj49319]

Hi,

I am writing a custom workflow process step where I need to save an array of values into workitem metadata map, that will be used later by subsequent steps by reading through history.

Interestingly when I add an array or List object to WorkItem Metadata map, it is not persisted in workitem/metadata node whereas normal string/boolean variables are persisted in WorkItem metadata node.

I am able to save array or list object as property to Workflow and WorkflowData MetadataMap but it's just not working with workItem metadata map

workItem.getMetaDataMap().put("key", Value);

where Value is an array of String

I will appreciate any help on this.

Thanks,

Pankaj

[hamidk92094312]

Check this doc .. it possibly can help you:

https://helpx.adobe.com/ca/experience-manager/6-3/sites/developing/using/workflows-customizing-exten...

[pankaj49319]

Thanks Hamid,

We are following most of things outlined in this article, My situation is a specific case where we have simulate user inputs to dialog step that are generally stored with workitem metadata map.
Please see my response to other post for implementation.

This scenario in not covered in documentation

[Vijayalakshmi_S · Accepted solution]

Hi @pankaj49319,

As mentioned in MetaDataMaps section in the link shared by @hamidk92094312, using WorkflowData's MetaDataMap is recommended to share data across steps. 

WorkItem's MetaDataMap is specific to that step (while it is running).

Is there any particular reason/need that you are looking to read it from history for access in subsequent steps (as you have mentioned in your original post)

[pankaj49319]

Hi,

We have a custom workflow for content activation governance where we are already following the best practices.

This workflow has a dialog step where user provides certain information that decides how course of approval and activation flow will take place. So the data user provides in dialog is stored in dialog step workitem's metadata map and once the step completes it is archived and becomes part of history items. this is standard workflow process, we can only store dialog inputs either with payload or work item.

In subsequent steps where we want to read the values user provided, history items are iterated for specific properties of workitem metadata map.

Everything was working fine and then we got an enhancement where we had to mimic user input pro-grammatically as if user has provided it and all the subsequent steps would read it in same way as user data is consumed, as I explained earlier.

I added a process step that fetches data to be written and adds it to workitem metadata map and when workitem is archived upon completion metadata is persisted under history and history can be iterated by subsequent steps for value of specific properties. I was able to save String and Boolean values in this manner but when I added array or list of String to metadata map of workitem. It is not persisted to metadata map in history, String & boolean values are still written back.

Hope the explanation helps, 

[Vijayalakshmi_S]

Hi @pankaj49319,

Thanks for the detailed inputs.

I tried reproducing this in my local and could see that it is not letting to persist array values to WorkItem's MetaDataMap.

Tried few other alternatives as the MetaDataMap value is of type "Object", no clue still.

Will respond to this thread once I have an update.

[pankaj49319]

Thanks,
This post is showing as solved, I don't remember marking the question as solved.
Did it happen because I replied to your post?

I think we should keep status as unresolved so that people know correct status and respond.

[Vijayalakshmi_S]

Hi @pankaj49319,

In the process of debugging, apart from the concern on saving array values, could notice that WorkItem's MetaDataMap set in the custom workflow process accepts only String and Boolean when set using 

• workItem.getMetaDataMap().put(key, value);

This conclusion is when I tried to save data types like "Date" and "Double", it gets saved as String in the history. While the same in WorkflowData's MetaDataMap and Workflow's MetaDataMap, it is saved in its respective data type. (You can give it a try in your local)

Note: This is tried with both com.day.cq.workflow.* and com.adobe.granite.workflow.* APIs

Given this, as an alternative (considering the existing implementation that you already have in place), 

• Try to persist the values as String with values separated using a delimiter (say "|") and retrieve accordingly as you iterate the history items.

I request Adobe folks to let know if this is the expected behavior/ it is so for a specific reason.

Thanks in advance.

[pankaj49319]

Hi @Vijayalakshmi_S,

Thank you for investigating further and I concur with your findings, but workflow, WorkflowData and WorkItem all use same MetaDataMap class instance and while for Workflow and WorkflowData MateDataMap adding array value to map is persisted correctly, it doesn't work same way for workitem.

However if you create a dialog step and add a mutlifield then values of multifield are saved as String[] in WorkItem metadata in history.

And because of this all subsequent wokflow steps are programmed to read a String[] from workItem history and If I save array as delimited String I will have to update all the steps to read in this way as well that I want to avoid.

I have used another workaround to address this as I am adding String array values to workItem history using JCR API to identify node and save array as node property which allows subsequent steps to read String[] in same way as done earlier.

Thanks for your time,

[Vijayalakshmi_S]

Hi @pankaj49319,

No problem. Thanks for the confirmation. 

Yes all three MetadataMap is the same interface and it is not that WorkItem MetaData can't accept String[] values (I also happen to try saving dialog values to WorkItem - select dialog with multiple option).

Just that setting it via process step is not happening. (Should be behind the scene logic of the way history is getting created and hence the WorkItem/metadata under that)

Given the already existing implementation/concern on retrieval, your workaround seems to be fine.