Workflow Upgrades and Versioning

Modified on 2010/01/20 13:43 by John — Categorized as: Versioning


Workflow Versions

Jetfire code, when parsed, added to the client nexus Code Collection and persistent storage in the server nexus. Jetfire code can be added to a running system.

When Jetfire code parses correctly, the code is added to the Jetfire Code Collection as a 'parse unit'. Otherwise, the errors are identified.

When code is updated, the Parse Unit of the previous version must be referenced so that the running system is aware of changes being made.

Versioning example

Figure 1 is a simple workflow class. 
namespace MyNamespace
{
   public workflow MyWorkflow
   {
      public MyWorkflow() { }
   }
}

Workflows instantiated based on this code have the base members of the workflow object.

Figure 2 is the same workflow class with an additional property. 
namespace MyNamespace
{
   public workflow MyWorkflow
   {
      public MyWorkflow() { }
   }
   public string MyFavoriteProperty
   {
      get;
      set;
   }
}

When the second code snippet is added to the Code Collection, it becomes the active workflow class. When 'MyWorkflow' class instantiated the code in Figure 2 will be used.

Note: The code class of Figure 1 is now called 'MyWorkflow.0'. This class may still be instantiated by using the 'MyWorkflow.0' class.

See a complete versioning example using C#.

Versioning Application

The following illustrates a typical case where a design team wants to use multiple versions of a business process at the same time.

Code versions are used in continuous improvement to improve business processes. For example, Jetfire can be used to define business processes. Let's say that a business process is used to track software development. Design teams decide that Software Tracker 1.0 captures the following properties:
After a couple of releases, the design team decides at a post mortem that there are some additional properties to track and the addition of states is useful. Further, this new process takes effect for any software features being developed starting one month from today by a sub-set of the team. The team calls this version: Software Tracker 2.0.

The changes are instrumented in the code, uploaded and ready to use. Software Tracker 1.0 continues to be used by the majority of the team. Software Tracker 2.0 is used by a sub-set of the team. Both processes continue until the design team is ready to migrate to Software Tracker 2.0 or make a couple of adjustments to create Software Tracker 2.1.

Workflow Upgrades

Multiple operating versions of a business process is one example where versioning is used. The other example of versioning is where all existing workflows are upgraded to the new class definition.

For example, a customer has an Event Tracking system. There are a number of properties that are included in Events 1.0. The customer has a great idea that they would like to track three additional properties and make them available to existing events. Hence the creation of Events 2.0, which is uploaded to the running system.

At this point, the existing workflows still use the definition of Events 1.0. The next step is for the Web Master to upgrade the events by using the Upgrade Workflows Web Part. With a single click, upgrade migrates identified workflows from Events 1.0 to Events 2.0. The existing workflows now have the three new properties included in their data.

Rules for Workflow Objects Upgrades

When upgrading workflow objects, here are a few rules to follow.
  1. Workflows can only be upgraded to the current workflow class.
  2. Workflows must be upgraded from the same workflow class.

Workflows can only be upgraded to the current workflow class

The system has a workflow class with various versions: 'MyWorkflow.0', 'MyWorkflow.1', 'MyWorkflow'. Workflows may only be upgraded to the 'MyWorkflow' class.

Workflows can only be upgraded from the same workflow class

The system has a workflow class with various versions: 'MyWorkflow.0', 'MyWorkflow.1', 'MyWorkflow'. Workflows are upgraded as follows: