|Oracle Workflow Developer's Guide|
Part Number B10284-02
Before you modify the definitions of any Workflow objects, you should ensure that your changes will not adversely affect any active work items that are based on those definitions. Changes to Oracle Workflow objects have different effects on active work items depending on whether or not the objects support versioning.
For a Workflow object, versioning means that either the object itself or the object that owns it supports multiple occurrences of the same object in the database, distinguished only by a version number, begin date, and end date. For example, the following table shows two versions of a VOTE activity that could exist simultaneously in the WF_ACTIVITIES table.
|Name||Version||Begin Date||End Date||Message||Lookup Type|
|Vote||2||01-JAN-1999||<blank>||New Vote Message||Approval|
When you modify a Workflow object that supports versioning, both the original version and the new version exist in the database. Any active work items that reference that object will continue to completion still using the same version that was in effect when the work items were initiated. Only new work items initiated after the change will use the new version.
In the above example, work items that are initiated between January 1, 1998 and December 31, 1998 will send the message Vote Message with result options of Yes or No, whether the work items are completed before January 1, 1999 or not. Only work items that are initiated on or after January 1, 1999 will send the message New Vote Message with result options of Approve or Reject.
Note: All process definition information is versioned.
When you modify a Workflow object that does not support versioning, however, the previous definition of the object is updated and only the modified definition exists in the database. Any active work items that reference that object will use the modified object after the change.
If the modified object is no longer compatible with the rest of the workflow definition used by the work item, errors may arise. To avoid such errors, you must take all references to the object into consideration when planning your changes to ensure that the changes do not cause any incompatibility.
Note: If your situation allows, you can avoid the risk of backward incompatibility by aborting and restarting all active work items after you make your changes. This method forces the restarted work items to use the modified definitions of all Workflow objects, including those that support versioning as well as those that do not.
Workflow Objects That Do Not Support Versioning