Page History: Workflow Upgrades and Versioning
Compare Page Revisions
Page Revision: 2009/10/08 21:01
Workflow Versions
Workflow Classes are added to the Jetfire Code Collection dynamically. 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. Otherwise, the errors are identified.
The first time that Jetfire code is added to the Code Collection, this is referred to as the baseline for the code class. 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 baseline code 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.
Using Versioning
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.