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

Persisting and Accessing Data via dialog participant step

Avatar

Level 2

Hello All,

 

As part of dialog participant step - We have designed custom touch ui dialog which gets triggered when participant tries to complete the step. In the custom dialog - we are capturing inputs from the workflow participant. We need this input data in later steps of the workflow so we are trying to save property like ./metaData/jcr:title and ./metaData/jcr:description by following the below link:

 

https://docs.adobe.com/content/help/en/experience-manager-64/developing/extending-aem/extending-work...

 

However, values are neither getting stored under /var/workflow/instances/server0/2020-11-02/new-wf_30/metaData nor under /var/workflow/instances/server0/2020-11-02/new-wf_30/data/metaData

If we save the property like jcr:title and jcr:description - values are getting stored but under particular workitem(/var/workflow/instances/server0/2020-11-02/new-wf_30/history/1604331030298/workItem/metaData). This won't solve the purpose as we will not be able to leverage Workflow metadata stored in a MetaDataMap object.

 

Let us know if we are missing something.

 

Below is the content.xml of the custom dialog:

 

<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0" xmlns:cq="http://www.day.com/jcr/cq/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0" xmlns:nt="http://www.jcp.org/jcr/nt/1.0"
jcr:primaryType="nt:unstructured"
jcr:title="Custom step"
sling:resourceType="cq/gui/components/authoring/dialog">
<content
jcr:primaryType="nt:unstructured"
sling:resourceType="granite/ui/components/coral/foundation/tabs">
<items jcr:primaryType="nt:unstructured">
<common
jcr:primaryType="nt:unstructured"
jcr:title="Common"
sling:resourceType="granite/ui/components/coral/foundation/fixedcolumns">
<items jcr:primaryType="nt:unstructured">
<columns
jcr:primaryType="nt:unstructured"
sling:resourceType="granite/ui/components/coral/foundation/container">
<items jcr:primaryType="nt:unstructured">
<basic
jcr:primaryType="nt:unstructured"
sling:resourceType="granite/ui/components/coral/foundation/form/fieldset">
<items jcr:primaryType="nt:unstructured">
<title
jcr:primaryType="nt:unstructured"
sling:resourceType="granite/ui/components/coral/foundation/form/textfield"
fieldLabel="Title"
name="./metaData/jcr:title"/>
<description
jcr:primaryType="nt:unstructured"
sling:resourceType="granite/ui/components/coral/foundation/form/textarea"
fieldLabel="Description"
name="./metaData/jcr:description"/>
</items>
</basic>
</items>
</columns>
</items>
</common>
</items>
</content>
</jcr:root>

 

1 Accepted Solution

Avatar

Correct answer by
Level 3

Hi Prathik,

 

This is as per adobe document and verified in one of the usecase created by me.

Dialog Participant Step - Storing Data in the Payload

You can store widget data in the workflow payload or in the work item metadata. The format of the name property of the widget node determines where the data is stored.
  • Store Data with the Payload
    • To store widget data as a property of the workflow payload, use the following format for the value of the name property of the widget node:
      ./jcr:content/nodename
    • The data is stored in the nodename property of the payload node. If the node does not contain that property, the property is created.
    • When stored with the payload, subsequent uses of the dialog with the same payload overwrites the value of the property.
  • Store Data with the Work Item
    • To store widget data as a property of the work item metadata, use the following format for the value of the name property:
      nodename
    • The data is stored in the nodename property of the work item metadata . The data is preserved if the dialog subsequently used with the same payload.

You can find a similar discussion in the below thread.

 

https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager/dialog-participant-step-no...

 

Let me know if you need more help.

 

Thanks,

Debasis

View solution in original post

4 Replies

Avatar

Correct answer by
Level 3

Hi Prathik,

 

This is as per adobe document and verified in one of the usecase created by me.

Dialog Participant Step - Storing Data in the Payload

You can store widget data in the workflow payload or in the work item metadata. The format of the name property of the widget node determines where the data is stored.
  • Store Data with the Payload
    • To store widget data as a property of the workflow payload, use the following format for the value of the name property of the widget node:
      ./jcr:content/nodename
    • The data is stored in the nodename property of the payload node. If the node does not contain that property, the property is created.
    • When stored with the payload, subsequent uses of the dialog with the same payload overwrites the value of the property.
  • Store Data with the Work Item
    • To store widget data as a property of the work item metadata, use the following format for the value of the name property:
      nodename
    • The data is stored in the nodename property of the work item metadata . The data is preserved if the dialog subsequently used with the same payload.

You can find a similar discussion in the below thread.

 

https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager/dialog-participant-step-no...

 

Let me know if you need more help.

 

Thanks,

Debasis

Avatar

Level 2
Our query is different - we are trying to store data as part of metadata neither under workitem nor under payload. The reason being this data we want to retrieve and use it in later steps of the workflow. So if it is part of Workflow metadata is stored in a MetaDataMap object. The Java API provides the Workflow.getWorkflowData method to return a WorkflowData object that provides the appropriate MetaDataMap object. This WorkflowData MetaDataMap object is available to the OSGi service or ECMA script of a step component.