Versioning Solutions


A snapshot is a "copy" of the state of all the artifacts in a Process Application or Toolkit at the point in time when the snapshot was made. The purpose of taking a snapshot is to allow you to revert back in time to the state of the snapshot if that is desired.

A snapshot can be captured by clicking on the Snapshot icon in IBPM PD.

When selected, a dialog appears prompting for the name of the new Snapshot. This must be unique from other snapshots.

The revision section of IBPM PD will show the list of current and past snapshots:

A snapshot is required in some circumstances such as:

Clicking a Snapshot in the Revision History area gives that Snapshot focus allowing you to see the state of the solution at that point in time.

The fact that it is a historic snapshot we are viewing is shown in the top of the IBPM PD:

Clicking the close button on this marker will return us to the current environment.

While viewing a snapshot, you can select an older version of an asset and copy it into the latest version. Alternatively, you can revert back to an earlier snapshot, effectively taking you back in time to a previous version.

Managing Snapshots

There are a number of relatively low-level commands available that will allow you to manage snapshots. These are:


This command can be used to delete a named snapshot from a Process Server. This will not work against a Process Center.


This command can be used to delete snapshots from a Process Center.

The command has a number of options:

First we must connect to the Process Center server using wsadmin. Ensure that you do NOT connect to the Deployment Manager. For example:

C:\IBM\WebSphere\AppServer\profiles\Node1Profile\bin>wsadmin -conntype SOAP -port 8881 -lang jython -user cadmin -password password

One particular useful application of this command is to reload a Toolkit that has become "out of sync" with the rest of the world.

Imagine we have a SN1 and then SN2 … and now we wish to reload SN1 so that it becomes the tip. We can't do that because Process Center will tell us that SN1 still exists. To achieve our goal, we first have to tell Process Center to forget SN1. The recipe for this is as follows:

print AdminTask.BPMShowProcessApplication('[-containerAcronym XYZ]')

Name: SN1 Acronym: **XXXX **Created On: 2013-12-19 12:31:29.041 Created By: User.1002 Is Default: false State: State[Archived] Capability: Capability[Standard] No of running instances: 0

print AdminTask.BPMSnapshotCleanup ('[-containerAcronym XYZ -containerSnapshotAcronyms XXXX -ignoreDependency true]')

The results of the command's operation will be seen in the Console Log for Process Center:

PALAdminComma I PALAdminCommands snapshotCleanup Entering SnapshotDelet I [BPMSnapshotCleanup] -- There is/are 1 snapshot(s) in total that has/have been deleted within this transaction. [BPMSnapshotCleanup] -- The following snapshot(s) for the process application KolbanTK was/were deleted: [ID: Snapshot.bd2d9b64-e081-4b80-a6a6-1e9eca361379 | Name: 2013-12-19-1 | Created on: 2013-12-19 12:31:29.041] PALAdminComma I PALAdminCommands snapshotCleanup Total amount of snapshot to be deleted: 1 PALAdminComma I Total amount of snapshot to be deleted: 1 PALAdminComma I PALAdminCommands snapshotCleanup Exiting Restore the Toolkit from its archived state

Note that you can NOT delete a snapshot that is flagged as the 'tip'.


This command lists the status of a Process Application. It has one mandatory parameter.

Here is an example of usage:

wsadmin>print AdminTask.BPMShowProcessApplication('[-containerAcronym XYZ]') Name: XYZ Acronym: XYZ Description: Toolkit: false Tracks: Track Name: Main Track Acronym: Main Default: true Tip: Created On: 2013-11-19 10:00:23.123 Created By: User.1002 State: State[Inactive] Capability: Capability[Standard] No of running instances: 0 List of Snapshots: Name: backup Acronym: B Created On: 2013-11-19 09:56:44.363 Created By: User.1002 Is Default: false State: State[Inactive] Capability: Capability[Standard] No of running instances: 0 Name: 2013-11-19-1 Acronym: 2013111 Created On: 2013-11-19 10:00:23.123 Created By: User.1002 Is Default: false State: State[Inactive] Capability: Capability[Standard] No of running instances: 0

Migration of in-flight BPMN process instances

Consider the notion of versioning a process where we already have instances of that process running. What should happen to any instances that are already running? We term these as "in-flight" instances. I believe this name comes from the notion of an airline flight from one city to another. We can do maintenance on the plane at the "from" city or the "to" city but not while the plane is "in-flight".

First let us consider the base of the problem.

Imagine we have a process that looks as follows:

Now imagine we have a new version that now looks like:

As we can see the step that was known as "Step B" is simply no longer part of the process model. If we have instances of this process in-flight then instances which are at "Step A" will be migrated to "Step A" in the new version. The same will be true for instances at "Step C". But what about instances currently at "Step B"? What should happen to them in the new story?

It feels like we have a number of possibilities:

Let us back up a little and think about when migration of in-flight instances may be required. When a process instance is live, it is based upon a snapshot definition of a process application. If we deploy a new snapshot definition of the same process, this is where migration can take effect.

When we deploy a new snapshot version we are presented with a dialog that contains the following options.

Let us now look at the migration option. If we had selected "Leave" then the process instances in the old snapshot will still run against the old snapshot. If we now wish to migrate, we can select that option. Here we see a page from the Process Admin Console where we have two snapshots of the same application. SN2 has an instance of the process called BPD1 still running.

If we click on SN3, we are presented with an option to migrate inflight data:

Upon selecting that option, we are now asked which snapshot instances we wish to migrate the data from:

We also see that we are prompted to choose a "policy file". A policy file can be generated using the wsadmin command:

print AdminTask.BPMCheckOrphanTokens

|| |Name|Description| |-processAppAcronym|| |-sourceSnapshotName|| |-targetSnapshotName|| |-outputFile|| |-overwrite||

AdminTask.BPMCheckOrphanTokens('-processAppAcronym MIG1 -sourceSnapshotName SN2 -targetSnapshotName SN3 -outputFile c:/temp/dat.xml -overwrite')

The format of the policy file is:

<orphanTokenPolicy> <processApplication acronym="..." id="..." name="..."> <sourceSnapshot acronym="..." id="..." name="..." /> <targetSnapshot acronym="..." id="..." name="..." /> <process bpdId="..." name="..."> <step id="..." name="..."> Command </step> </process> </processApplication </orphanTokenPolicy>

The commands can be one of "move" or "delete".

If "delete", then the token is deleted.

If "move", then the token is moved. If moved, we need to specify the id of the new target with a "targetStepId" option.

For both the "delete" and the "move" commands, an attribute called "suspendProcess" can be supplied with a value of true or false.

In addition to the recipe described above, the REST API provides API for both moving and deleting tokens. The Methods are:

See also:

Notes on testing

We need a real Process Server …. Process Center will not do. In my tests, the name of the Process Server was PS1:

Page 5

No Comments
Back to top