Currently it is only possible to set the output and/or analytics collections of a transaction item while changing its status to success.
I would like to see the following options:
- also enable this for the status failed. Especially for business exceptions this infomration can still be relevant output data if parts of the process are executed.
- add a new activity that can set or update these collections without changing the status. A similair activity already exists with the ‘Set Transaction Progress’ activity. This would enable runtime updates of output data, so that it does not need to be collected through the entire process and process endings. It would further empower the REF framework that we currently use.
Currently using Studio 2020.10.2 and Orchestrator 2020.10.1
Would you mind sharing some details about the types of data that you want to store?
One way to achieve this type of tracking could be the Data Service with its entities. One of its intended uses is to be complementary to the queues.
The data types are pretty straightforward string values (as in key-value pairs), similair to what is available as the queueitem.specificcontent dictionary values.
Updating the latter runtime obviously only updates the localized instance of this dictionary.
A use case from the default REF framework:
I have a process containing three main steps:
- Read some order information from a system.
- Create a ticket in the ticketing system containing the order information.
- Inform some key-user of the ticket created.
Lets assume this does not go well, an application error occurs, and the REF allows an automated retry of the queueitem.
If the error occurs before finishing step 2, the queueitem can safely be retried.
If the error occurs after finishing step 2, it cannot be retried, because it would result in duplicate tickets being created, which is not a desired outcome.
So, the retried queueitem needs to determine what steps were completed, and what not, so logic can be built to skip steps 1 and 2, and proceed directly to step 3.
Step 3 however requires multiple values created in step 2, such as a ticket number, and maybe some order information too.
Having the ability to store those values on the transaction item would simplify this task.
‘Set Transaction Progress’ can achieve this, but only holds one string.
Using Set transaction Status immediately completes (and fails) the entire queue item, which is also not a desired effect in this case.
My current ‘workaround’ is indeed using the ‘Set Transaction Progress’ activity, using a pipe separated string from several key value pairs which is decoded on a retry for reprocessing, but from a maintenance point of view this is not really legible.