How do I force an active Workflow to use a new definition?

I 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.

By continuing to use the site, you agree to the use of cookies. more information

In common with almost all professionally run websites, this website logs the IP address of each visitor in order to keep it running reliably. This is also essential for protecting the website and its visitors from malicious attacks, including infection with malware.

This website provides information as a service to visitors such as yourself, and to do this reliably and efficiently, it sometimes places small amounts of information on your computer or device (e.g. mobile phone). This includes small files known as cookies. The cookies stored by this website cannot be used to identify you personally.

We use cookies to understand what pages and information visitors find useful, and to detect problems such as broken links, or pages which are taking a long time to load.

We sometimes use cookies to remember a choice you make on one page, when you have moved to another page if that information can be used to make the website work better. For example:
- avoiding the need to ask for the same information several times during a session (e.g. when filling in forms), or
- remembering that you have logged in, so that you don’t have to re-enter your username and password on every page.

You can prevent the setting of cookies by adjusting the settings on your browser (see your browser Help for how to do this). Be aware that disabling cookies will affect the functionality of this and many other websites that you visit.