Is there any OOTB feature available in appian to update the pv variables of the inflight instances apart from IFM (In-flight Modification) plugin? please suggest.

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.

Hi Chris,

Thanks for your suggestions, i will try these options to see if it works for my design. 

Be aware that a larger number of active process instances, waiting for incoming messages, can have a severe impact on system performance and stability. I suggest to discuss your design with Appian before going on.

Totally agree with Stephan,, take into consideration the fact that having a lot of process instances waiting for messages can lead to performance issues....

I may be wrong but I think that mostly applies if you send a msg without a destination process id and it has to scan all the listeners. I would obviously strongly advise to always provide a destination process id when sending a msg event but I agree that its not fool proof and could be dangerous in some environments.

Agree, un-targeted messaging should be completely avoided in my opinion. 

With targeting by process ID, we'll have around 500 Receive Message events active at one time - that small range has not given us any concerns.  Based on what I've seen, I would feel comfortable scaling that up some if needed.

Agree, un-targeted messaging should be completely avoided in my opinion. 

With targeting by process ID, we'll have around 500 Receive Message events active at one time - that small range has not given us any concerns.  Based on what I've seen, I would feel comfortable scaling that up some if needed.