Expand my Community achievements bar.

SOLVED

What is the proper way to save a workflow dialog step's widget values?

Avatar

Level 4

For example, I have a dialog step that has two textarea widgets.

The first, used in most default steps, is named "comment". When a user enters text into this field during the workflow it is saved to the workitem history metadata as a property called "comment" (/etc/workflow/instances/<date>/<model>/history/<###>/workItem/metaData).

The second widget could be any text that i want to get from the user for use in the next step. Is it possible to set this widget's name so that it is stored similarly to "comment" in the workitem's metadata? I've tried a few different names - "randomText", "./metaData/randomText" - but it seems to want to store these values on the payload's node. For now, i've been naming it "./jcr:content/randomText" and grabbing it off of the payload's node but this isn't ideal.

Is there a better way to get this text from the user for use in the next step (a service that implements ParticipantStepChooser) without having to store and lookup the value on the payload's content node? (Using CQ5.6)

Thanks

1 Accepted Solution

Avatar

Correct answer by
Level 10

I recommend reading this AEM doc topic:  http://dev.day.com/docs/en/cq/current/workflows/wf-ref.html#Dialog Participant Step:
 

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 cq: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.

********************************************************************************************

You are on the correct path. 

View solution in original post

4 Replies

Avatar

Correct answer by
Level 10

I recommend reading this AEM doc topic:  http://dev.day.com/docs/en/cq/current/workflows/wf-ref.html#Dialog Participant Step:
 

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 cq: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.

********************************************************************************************

You are on the correct path. 

Avatar

Level 4

Thanks for taking a look, sorry if i wasn't clear enough. I'm currently storing the data with the payload as you suggested. What i am wondering is if there is a way to store it with the WorkItem metaData.

Storing the data on the payload doesn't seem to be reliable, as often i've found that the next workflow step runs before the JCR Session has been able to save/update the value from the previous step's dialog. Also, storing it in the workItem metaData will allow me to keep those values in the workflow history instead of over-writing them the next time a workflow runs on the same payload.

Edit: To expand, i see that your link says to just name the widget "nodename" and it will be saved in the workitem metadata. This doesn't seem to work for me however, as it will throw an error along the lines of ConstraintViolationException  {} nodename not a valid property name. I will keep exploring this route though because it seems to be what i'm looking for.

Avatar

Level 10

Another option you have (always another option with AEM is to develop your service, custom workflow step, or front end component) is you can develop a custom workflow step and use the JAVA JCR API to store data where you want. To learn how to create a custom workflow step using Java and Maven -- see http://scottsdigitalcommunity.blogspot.ca/2012/09/developing-cq-custom-workflow-steps.html