Is there any OOTB feature available in appian to programmatically update the pv variables of the inflight instances like any smart service, apart from IFM (In-flight Modification) plugin? please suggest.
Discussion posts and replies are publicly visible
That is the only way. What are you looking for?
I basically want to update a pv variable for a list of inflight instances.
Did you check this?
It's possible to change the value of process variables in a process instance. The approach differs based on the type of the variable.
To change process variables of system data types:
text string 1, text string 2
To change process variables of custom data types, you need to add a script task to your process model that stores the new value into the variable:
To change an encrypted text value, you can use a technique similar to modifying values of custom data types:
docs.appian.com/.../Monitoring_and_Editing_Processes.html
Hi David,
Thanks for your suggestion, but this is not what iam looking for. My requirement is not to update the pv for just 1 instance, it is for multiple instances programatically. I tried using IFM smart service and it is working. I want to check if there is any other better option than IFM.
Is that for a rare support case or do you plan to make this part of the overall solution design?
No not for support case, it is for part of the solution.
That is not something I recommend. What problem do you want to solve?
There are a few ways you can achieve this type of design, if needed. I've used similar setups in situations such as, process data can be updated outside of the regular flow / Related Action while the process is active, and the main process CDTs need to obtain the updates as well.
To note, I have used the IFM Manager in a single one-off support situation, it worked but I would not recommend building this into your design, reserving it for unforeseen support situations only.
Typically I will have the Related Action / outside flow update the database for the main process instance (query data, update, persist back to DB), then make a call to the process instance(s) with one of a few methods to update it's own CDTs, such as with process messaging. This works if your variables are always persisted to the DB. The model is setup something like below:
When the process starts, the Main Flow moves on while the Update flow waits at a Receive Message node. Once the outside process is complete it will message the main process, which starts the Reset node that queries data back from the DB via a!queryEntity(), updates it's own CDTs, and returns to the Receive Message node to wait for further updates. This is my preferred method since it is all OOTB, but you should review the Process Messaging Best Practices to determine if it is acceptable for your case.
There are race conditions to be aware of as well, depending on your process you may consider pessimistic locking. E.g. if an outside update is occurring at the same time your main process is being updated.
Alternatively I'll note some related plugins:
- Process Management Services is one I've used in a similar setup as above, where instead of messaging we use the Start All Nodes service to call the main process to update it's own data from the DB.
- Get and Set External Process Variables is an older plugin that can Set External PVs, you can send the data directly to the process variables without needing them persisted to the DB.
Always with plugins, you run some risk of issues after upgrades, etc. My preferred method is always whatever is OOTB.
DO yu want to do this only once? or is something that you will have to to do periodically?
If it's the second case, I would suggest to change the way your process are implemented..... in order to support this behavior...
I've started using a similar approach recently.Though instead of resetting the PVs from the DB, I simply pass in a map of PVs that can be updated on the fly.