ActiveVOS Designer User’s Guide
Previous | Next
What is Process Versioning?
ActiveVOS server manages process versioning.
Process versioning allows different versions for a given process
to exist. Two deployments are considered to be different versions
of the same process if they have the same target namespace and name
in the BPEL file, but one deployment differs from the other in some
way.
Process versioning allows you to control when processes become
effective and for how long. You can also control what happens to
processes created by older versions when a new version becomes effective.
While multiple versions of a process can exist concurrently, only
the latest effective version is capable of creating new process
instances.
The latest effective version is in a current state.
Other states include future, to describe versions
that have an effective date in the future, expired to
describe versions whose expiration date has arrived or has been
set, and inactive to describe expired versions
that no longer have running process instances.
The process deployment descriptor provides selections for
describing how a deployment is to be versioned. These selections
are all optional and have default values as described below.
If desired, you can provide version information as described
in Creating a Process Deployment Descriptor File.
The following example shows the syntax for version information
in the .pdd file.
<version effectiveDate="2005-12-12T00:00:00-05:00"
expirationDate="2007-12-12T00:00:00-05:00" id="1.5"
runningProcessDisposition="migrate"/>
where:
- is the date
the new version becomes the current version and all new process
instances run against it. Depending on the disposition selected
for running processes, some may continue to run until complete using
the older version. The effective date is an XML schema datetime
value. Time is indicated as the midnight hour plus or minus the
number of hours ahead of or behind Coordinated Universal Time (UTC)
for the computer’s time zone. In the example above, the computer
time zone is eastern standard time, which is five hours behind UTC.
For date/time details, refer to Deadline and Duration Expressions. If you do not provide an effective
date, it defaults to the date and time the process is deployed to
the server.
- is the date, beyond
the effective date, the current version expires. An expired version
is not capable of creating new process instances. Once all of the
running processes tied to an expired version complete then the version
becomes inactive. All process instances for the current version
run to completion. The expiration date is an XML schema datetime
value. (Same as effective date). If you do not provide an expiration
date, the version does not expire until you manually expire it in
the Server Administration Console or until a newer version is deployed.
- is the process version number
in major.minor format. You do not need to provide a version number.
The ActiveVOS server auto-increments new versions. The server increments
a version number by dropping the minor value and adding 1 to the
max number. For example, version 1.5 increments to version 2.0.
- is the
action the server takes on any other versions of the same process
that currently have processes executing once this version’s effective
date arrives.
Valid dispositions are:
- . Indicates that all
process instances for the previous versions should run to completion.
This is the default value.
- . Indicates that all process
instances running under previous versions should terminate on the
effective date of the new version, regardless of whether or not
the process instances are complete.
- . All running process instances
created by previous versions will have their state information migrated
to use the newly deployed process definition once its effective
date arrives. If there are incompatible changes between the versions
that would not permit them to be migrated, you receive an error
message during deployment of the new process, and its deployment
fails. Changes should be limited to XPath (or other language) expression
changes in the BPEL XML file.
Criteria for a New Version
A new version of a deployed process must meet the following
criteria:
- The fully qualified process name must not change
- A new version can include a change to either the BPEL
XML or the process deployment descriptor file
- A version is not new if the autoincrement feature determines
that the BPEL XML and the deployment descriptor are the same as
the deployed version having the highest version number. If the BPEL
XML and the descriptor file do not contain any differences, then
the version on the server is up-to-date and no deployment occurs.
- If you need to modify WSDL-related properties, such as
partner links or correlation properties, then you should create
a new process, not a new version
Copyright (c) 2004-2009 Active Endpoints, Inc.