Page History: Workflow Upgrades and Versioning

Compare Page Revisions

21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Current 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

« Older Revision - Back to Page History - Newer Revision »

Page Revision: 2009/10/10 02:59

Table of Contents [Hide/Show]    Workflow Versions       Versioning example       Versioning Application    Workflow Upgrades       Rules for Workflow Objects Upgrades          Workflows can only be upgraded to the current workflow class          Workflows must be upgraded from the same workflow class          Base workflow classes are not upgraded

Workflow Versions¶

Jetfire code is added to the Code Collection dynamically and automatically. This means that Jetfire code can be added to a running system. If the code parses correctly, then the code is added to the Jetfire Code Collection as a 'parse unit'. Otherwise, the errors are identified.

The vesion of Jetfire code is simply added to the Code Collection by parsing it. The code can be further modified and then uploaded to the be added to the Code Collection.

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. This means that any 'MyWorkflow' class instantiated uses the code in Figure 2.

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

Versioning Application¶

Let's look at an example where the 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: - Title of the software being developed - Short Description for the software being developed - Target Release - Start Date for the developement - End Date for the development

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. This is 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 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, the 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.
3. Inherited workflows are not upgraded.
   

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 must 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:

• Upgrade workflows with class 'MyWorkflow.0' to 'MyWorkflow'.
• Upgrade workflows with class 'MyWorkflow.1' to 'MyWorkflow'.
  

Base workflow classes are not upgraded¶

A workflow class is defined as follows:

namespace MyNamespace
{
   public workflow BaseWorkflow
   {
      public BaseWorkflow()
   }

   public workflow MyWorkflow : BaseClass
   {
      public MyWorkflow()
   }
}

The BaseClass workflow can be instantiated separately. These workflows can be upgraded. MyWorkflow workflows when upgraded upgrade the inheritance chain.