You don't so much need to "trick" the engine as leverage one of the functionalities available in the tool. I can think of a few ways to do this -
Shared Business Objects
I've not used these in the real world, but the purpose behind shared business objects was to keep multiple threads (tasks) working on the same data when they were doing parallel updates. You would need to test that these changes also update the Process Context even if tokens aren't moving. I'll note that when they first came out there were lots of difficulties with SBOs, which I think has wound up creating a bias against them.
If this provides the functionality you want it is likely the easiest approach with the least work. Note however there were reports of performance impact in those early days, so be judicious with your use, or do the work to make sure the performance is adequate to your need.
Message Events
You could have an event listener in parallel to the task whose entire purpose is to update the process variable values as the user executes the task. You would then have the task invoke the message to provide the update. This has the advantage of more fine grained control of when the update happens, but the down side of having to create an explicit set of code that a developer might miss in one or more cases, causing the values to not get updated.
Independent Sync
If you don't mind a bit of a delay in the values updating, I think you could leverage the ReST API or JS-API to periodically poll the instances and update the value using them. This feels like a very ham-handed way to get what you need, and certainly would increase server load, but if this is for a minor set of the overall functionality, the approach might be worth it.
Custom DB Approaches
There are 2 of these, one with Sync, one with custom search. Both of them would be based on realizing there is data here you may want to reference outside of the process execution context and saving that data to a custom DB instead of relying on Execution Context values. Once you have that established you have 2 choices to keep tasks up to date.
Sync -
Like the ReST API above, when the DB gets a save you could also update the Process Context using an API call.
Custom Search -
Replace the default portal with one that uses the custom DB as part of its search rather than relying on Process Variable values.
I'm sure there are other ways to do this, but those are the first that occur to me.
------------------------------
Andrew Paier
------------------------------
Original Message:
Sent: Fri August 07, 2020 02:47 PM
From: Laszlo Kertesz
Subject: How to refresh process-level variables from a human task?
Hi guys,
In a process there are long-running human tasks - from several days to several weeks. During this time the task is assigned to the starter user. After a while there are many tasks assigned to the user who don't know which task is which, I mean he/she can't identify the tasks using data entered on one of the coaches (say a customer name or customer ID) because the displayed process level variables are refreshed when the task is executed and closed.
I know, that we can modify the narrative string of a taks, but we need to modify process-level variables displayed on the Portal.
Is there any built-in function or finally a trick to refresh the process level variables from a task, without closing that task?
Thx,
------------------------------
____________________
Laszlo
------------------------------