How do I force an active Workflow to use a new definition?
August 30th, 2011 MattI was asked a few days back about whether there is any way for an existing Workflow process to be forced to use a new definition when the new version is saved to the database:
There is some transaction already in ACTIVE status ( i.e. ACTIVE workflows ) in database. I need to run this transaction according to new wft file what I have putted in database recently. Is is possible ?
The simple answer is: “it depends”! Workflow allows multiple versions of the same process to exist in the database at the same time, so in this post, I’ll be looking at what you can do to use the new definition.
Workflow Automatic Versioning
When a new definition of an Item Type is deployed to the database, the Workflow Engine will automatically create a new version of some objects if they have been changed. The objects which are versioned by the Workflow system are:
- Notifications
- Functions
- Events
- Processes and Sub-Processes
- Process Activities (anything on the Node, Node Attributes or Event Details tabs for an activity)
- Activity Attributes
- Activity Attribute Values
- Transitions
So, if you have made any changes to any of these things, when you save the definition to the database, a new version of the object will be created – any existing processes will continue to use the old definition rather than the new one.
If you have made any changes to Item Attributes, Lookup Types, Lookup Codes, Messages or the underlying PL/SQL code then those changes will immediately be picked up by processes which are already running and any new processes which are launched. So, here’s a warning – if you are making changes to messages or lookups within a process, any changes you make will take immediate effect when the definition is deployed to the database.
Changing your PL/SQL will also impact the processes which are already running – particularly if the code references any new attributes which do not exist in the processes which are already running. There are some things that can be done within the code to catch and handle any errors which may be thrown by attributes not existing – for example, you can include an exception handler which calls WF_ENGINE.AddItemAttr to add a new attribute if one does not exist in the definition.
Forcing Existing Processes to Use a New Definition
So, if you have made changes to the process which means that a new version has been deployed, what do you do with the existing processes?
The simple approach would be to abort the existing process and then re-run them from the beginning. Some processes may include a mechanism for doing this, for example in an approval process, if a user rejects the request then the process may send it back to the requestor to resubmit. However, if the process has been running for a long time, then it may not be practical to restart it. Some years back, I worked with a business where their processes could run for years before completion, where aborting the process just wouldn’t be practical.
When an activity is started by the Workflow Engine, the engine determines which version of the definition to use by checking the begin date of the record within WF_ITEMS. The date that the process started is then checked against the effective dates for the activities and the version which was current when the Workflow process started will be used to determine which activity to run and what the transitions are from the activity.
So, if you really, really need to force the running processes to use the latest definition, then you can update the BEGIN_DATE field for the record in WF_ITEMS to a later date. When the next activity is executed, the engine will check the date and will use the latest version of the process.
There are two main drawbacks of having to adopt this approach. Firstly, any reporting / auditing / metrics that you have for determining process execution time will no longer be accurate because the start date of the process has now been manipulated. Secondly, if there are any problems further down the line with the process, then Oracle won’t support you – that said, if this is a custom process, then you won’t be getting much support from Oracle anyway…
As ever, make your changes in a test environment before making changes to your production system to ensure that everything still works, though.
