Hi,
In Production context, a process raised an error on a Write To Multiple DS Entity node because of a mandatory field is set to null.
When editing the process, I can see that some process variables are editable ("Modify" button is visible) but the PV for my concern is not editable (type CDT).
From the link below, I've read that 2 solutions are possible to fix and resume the instance :
1/ Creating a new PV, then assigning the latter to the Write To Multiple DS Entity node...
(but I don't see any way to add a new PV, as the "variables" tab from process properties is not visible from the monitor process instance view)
2/ Using the IFM Manager plugin.
What would be the best way (more simple) to correct the process and then resume it please ?
https://community.appian.com/discussions/f/process/13373/how-to-add-a-process-variable-in-already-initiated-process-instance-and-map-this-new-process-variable-to-a-form-input
Discussion posts and replies are publicly visible
Harshit's answer is correct - if you end up doing this often like me, here's one revision of the technique that I prefer:
instead of placing the script task right before the "write..." node, instead just add a script task and follow it with a non-terminating end node. Run the script task to push a new value into whatever CDT field(s) you need to update. Then you can check current variable values in the monitor and ensure they're correct. *Then* just right-click on the WTDS node that originally failed and click "start". The main point here is that it allows you to be sure of your fix before trying the WTDS node again and potentially having another failure and/or writing something you didn't really mean to write, if your script task didn't do what you expected it to on the first try.
Thank you Mike, that is a very good idea to have a way to control the data, before to resume the process.
- However, I'm not sure to understand where you would place your new Script Task. You mean adding it "anywhere", but not connected to the others existing nodes ?- what do you mean by "non-terminating end node" ? you mean an "End event" node with no trigger ?
I use the same theory as Mike. I run my data-fixing script tasks off of the Start Event most often, you can have the incoming flow from any node that will never be started automatically again (to prevent it from overwriting data later).
cedric01 said:You mean adding it "anywhere", but not connected to the others existing nodes ?
Correct. When adding it to an already-running instance, it doesn't need to follow anything. This is a handy feature.
cedric01 said:what do you mean by "non-terminating end node" ? you mean an "End event"
Yes, a regular end event. When there are active (or failed) nodes in a running instance, a regular (non-terminating) end event won't cause the instance to "complete" in the sense that a parent flow would continue - so non-terminating ends can be used safely when trying to fix instances.
I'm emphasizing "non-terminating" here because lots of people (me included) use Terminate nodes in most situations, until a non-terminating one is needed specifically (like in a process flow where some parallel flows might need to end early while the main flow continues).
Chris said: I run my data-fixing script tasks off of the Start Event
...but since we don't need to connect them to an incoming flow, why even do that? Just add it and provide an end event, then start it manually? Or are you handling some other special use case in this way?
Mike Schmitt said:...but since we don't need to connect them to an incoming flow, why even do that? Just add it and provide an end event, then start it manually? Or are you handling some other special use case in this way?
I do this purely because I did not know that in an already-running instance, nodes do not need an incoming flow...... No other use case, news to me!
I feel like that has not always been allowed, but cannot confirm..
Interestingly enough, I was just able to publish a model in this fashion - then when started for debugging, all nodes fire..
Chris said:then when started for debugging, all nodes fire..
I feel like this might be the only reason that all nodes need an incoming flow in the model itself (i.e. to provide actually predictable starting conditions. i'm not sure what the behavior is, for instance, if such a process is started as a subprocess - do they all still fire, or does something else happen? i'd test and find out, but there are only so many hours in a day lol)
Mike Schmitt said:I feel like this might be the only reason that all nodes need an incoming flow in the model itself (i.e. to provide actually predictable starting conditions. i'm not sure what the behavior is, for instance, if such a process is started as a subprocess - do they all still fire, or does something else happen? i'd test and find out, but there are only so many hours in a day lol)
Just ran a quick test, same behavior as a sub - all nodes fire..
I'm sure in the past I've seen an error when publishing related to some nodes not having an incoming path, but apparently that's old news..
Chris said:I'm sure in the past I've seen an error when publishing related to some nodes not having an incoming path
AFAIK it does do this for nodes without outgoing flows. But I agree, I feel like it used to be different - but alas, no really feasible way to check.
Thank you Mike for these precisions.
Mike Schmitt said:Yes, a regular end event. When there are active (or failed) nodes in a running instance, a regular (non-terminating) end event won't cause the instance to "complete" in the sense that a parent flow would continue - so non-terminating ends can be used safely when trying to fix instances.
When you say a "Non terminated" end node is a regular one, what would be a "Terminated" end node ?
An end event configured with Result tab set with "Terminate process" ? (just to be sure ;-) )
cedric01 said:what would be a "Terminated" end node ?
That's what it would be. We can usually just say a "terminate node", but some users might hear "end node" and not realize they should *specifically not* use a "terminate" node (which is just an end node with a different configuration), hence my choosing the explicit language in use above.
cedric01 said:An end event configured with Result tab set with "Terminate process" ?
oh - yes; though i'd think most designers would be very used to using terminate nodes (at least, i hope?!?) - but yes, to be clear, i mean an end node with the "terminate" setting enabled. Hence the way I worded it repeatedly above.
Thanks a lot Mike for these further informations.