A shared business object (question 2536) is used in a client-side human service exactly like a normal business object: bind coach controls to its fields, read and write it in client-side scripts. The differences are when the server copy is refreshed:
- When the CSHS starts (the task is opened) the current version of the shared object is loaded into tw.local in the browser.
- Changes made in coaches stay in the browser until a server round trip: a service flow call from the CSHS, or the end of the task. At that moment the changes are saved to the shared object storage and visible to everyone else who loads it afterwards.
- Another task working on the same shared object in parallel sees your changes only after it reloads (a service flow call or reopening the task); last writer wins per save - design the fields so that different tasks edit different parts, or add a version check.
// CSHS with tw.local.order (Shared BO "Order") - a "Save draft" button: service flow "Touch" with order in/out forces the save
// client-side script before showing the coach again after the save: nothing needed, tw.local.order is the saved version
// optimistic check in the saving service flow (server side):
var fresh = tw.local.order; // the shared object as loaded by this service call (latest server state)
if (fresh.version != tw.local.expectedVersion) { throw new Error("The order was changed by someone else - reload"); }
fresh.version = fresh.version + 1;Tips: expose the shared object's fields as business data only where searches need them; keep large blobs (documents) out of the shared object (references only); if two parallel tasks must edit the same object, split it into two shared objects or serialise the tasks. Everything else - validation, visibility rules, tables bound to lists inside the object - works as with any business object.
References