A shared business object (BAW 8.6+) keeps one current state; the engine does not store a version history you can load. What you can do:
- Snapshot copies on change: whenever a step changes the shared object, copy it into a history list (non-shared BO with a timestamp and user) stored on the instance or in your own table; loading "previous version 3" is then a lookup in that list.
- Database audit: the shared business object tables of the BPMDB hold the current serialised state only; a database trigger or CDC on those tables can keep versions outside BPM, but IBM does not document their layout - treat it as a last resort.
- Version field + optimistic locking: a version number in the object lets you detect concurrent changes (question 390) and correlate with your history copies.
- Documents instead of objects for things that need real versioning: the BPM document store and ECM keep document versions natively (check-in / check-out, versionSeriesId) - store the "form as of approval" as a document (JSON or PDF) at each milestone.
// service flow "Record version" called after each significant change of tw.local.order (shared)
var h = new tw.object.OrderVersion(); // non-shared BO: version, changedBy, changedOn, data (String JSON)
h.version = tw.local.order.version; h.changedBy = tw.system.user.name; h.changedOn = new Date();
h.data = JSON.stringify(tw.local.order); // BAW 20+: business objects serialise; 8.6: use toXMLString()
tw.local.history.insertIntoList(tw.local.history.listLength, h); // tw.local.history: list of OrderVersion on the instance
// "load previous": var prev = JSON.parse(tw.local.history[n].data);
Rule of thumb: shared objects are for collaboration on the current state; anything auditable belongs in explicit history records or documents.
References