I have edit’ed your post, to make the code more readable.
I really like this question and your solution to it, but I don’t think that will work ( or I’m not completely understanding what you are trying to do )
The “workflow in” node will get activated every time the user press a button or a field is auto submitting, there for adding pop/push in there is generally not a good idea unless it’s right after completing the form instance.
Normally you return a form with no data on first activation, this add an instance id to the database, and every activation after this, will keep form state in the database, and ensure we have access to all of that in nodered. Then when the user submit/completes the form, you complete the workflow instance, and do something with the result.
So please correct me if this is not what you intended. I suggest something like this.
This will ensure we only create the workitem once the workflow is complete, and if you need additional logic, for looking up data from external resources or do more complex form validation, you can do that, and ensure only one workitem gets added. How ever this will not allow the user to see the result of processing, since we are completing the form, once we have the data.
There are two solutions to this, a bad one ( that could break ) and a more solid one, that will require a little more work.
- We could change the “form completed” to go into “processing” instead of completing, and then add logic that checks once the work item has completed and then add the result payload and set the state to completed.
This can/will break if the user closed the webpage or navigates away, And if the user tries to come back AFTER the result has been set, the workflow will be hard to find, since it will be completed.
And depending on the implementation it will also break/stop if nodered is restarted doing the flow.
- So we normally notify the user in other ways ( send email, text message, slack message etc. ) or we create a new form instance, with the result and some kind of confirmation ( you use the “Assign” node for this ) We can use queue “on success” for that.
For running the work item on the robot. There are diffidently cases where using the RPA node would make sense, mostly when you need a reply right away, but with workitems we try to keep it transactionaly safe, so here we should let openflow take of that. We do that by updating the workitem queue to allow openflow to send notification to the robot(s) when there is workitems to be processed.
Then in a workflow on the robot you add the exception catching logic, so openflow can retry when needed, and you don’t get workitems stuck in pending state.
That is what you need a workflow like this for
One thing i often see, is people “chain” the queues, for each part of the process.
So once the robot is done processing the workitem, you set a “success” queue on the workitem queue. This new queue is then responsible for notifying the user about a new workflow has been assigned to them.
This way it becomes very easy to report on workflows that is waiting on the user to acknowledge they have seen the result from the robot. Or what is more likely, you would push the failed items to this queue, to notify people about failed workitems, that they can then re-submit after updating the payload.