Previous Topic: Integration with Third-Party ApplicationsNext Topic: Participant Resolver API


Saving Job Objects

To prevent the possibility of a workflow job being saved to cache in a corrupt state when more than one operation occurs on the job simultaneously, the job object is cloned after being read from the cache so that each individual thread has its own copy of the job it is modifying.

This requires custom scripts to use the following workflow API objects:

Synchronous scripts

All synchronous scripts must use the This<object>Data when fetching userdata from an activity. The This<object>Data objects that are passed in have access to the live job, and any updates to the job made in the script are persisted after the transaction completes.

Synchronous scripts include resource scripts, synchronous agent scripts, and state rules.

Asynchronous scripts

For all asynchronous scripts executed by the general monitor, read-only versions of This<object>Data objects are passed in. Asynchronous scripts do not have access to the live job.

Asynchronous scripts include asynchronous agent scripts, mail scripts, and alert scripts.

Asynchronous agent scripts can use the This<object>Data to retrieve the real job object, make changes, and save the job in the script itself.

The following code example illustrates the required code changes for an asynchronous script.

Current code:

ThisJobData.setUserData("Test","Pass");

Revised code:

var jobTableId = ThisJobData.getJobID();
var job = Job.queryByID(ClientContext,jobTableId,true);
job.setUserData("Test","Pass");
job.save();