Table of Contents

Search

  1. Preface
  2. Welcome to Informatica Process Developer
  3. Using Guide Developer for the First Time
  4. Getting Started with Informatica Process Developer
  5. About Interfaces Service References and Local WSDL
  6. Planning Your BPEL Process
  7. Participants
  8. Implementing a BPMN Task or Event in BPEL
  9. Implementing a BPMN Gateway or Control Flow
  10. Using Variables
  11. Attachments
  12. Using Links
  13. Data Manipulation
  14. Compensation
  15. Correlation
  16. What is Correlation
  17. What is a Correlation Set
  18. Creating Message Properties and Property Aliases
  19. Adding a Correlation Set
  20. Deleting a Correlation Set
  21. Adding Correlations to an Activity
  22. Rules for Declaring and Using Correlation Sets
  23. Correlation Sets and Engine-Managed Correlation
  24. Event Handling
  25. Fault Handling
  26. Simulating and Debugging
  27. Deploying Your Processes
  28. BPEL Unit Testing
  29. Creating POJO and XQuery Custom Functions
  30. Custom Service Interactions
  31. Process Exception Management
  32. Creating Reports for Process Server and Central
  33. Business Event Processing
  34. Process Central Forms and Configuration
  35. Building a Process with a System Service
  36. Human Tasks
  37. BPEL Faults and Reports

2. Designer

2. Designer

What is Process Versioning

What is Process Versioning

Process Server manages process versioning. 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 online (effective) and for how long. You can also control what happens to processes created by older versions when a new version comes online. While multiple versions of a process can exist concurrently, only the latest online version is capable of creating new process instances.
The latest version is in an
online
state. Other states include
online pending
, to describe versions that have an effective date in the future,
offline pending
to describe versions whose expiration date has arrived or has been set, and
offline
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="maintain"/>
where:
  • online date
    is the effective 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 can continue to run until complete using the older version. The online 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 online date, it defaults to the date and time the process is deployed to the server.
  • offline date
    is the date, beyond the online date, the current version expires. An offline version is not capable of creating new process instances. Once all of the running processes tied to an offline pending version complete then the version becomes offline. All process instances for the online version run to completion. The offline date is an XML schema datetime value. If you do not provide an offline date, the version does not go offline until you manually set it in the Process Console or until a newer version is deployed.
  • id
    is the process version number in major.minor format. You do not need to provide a version number. The Process 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.
  • runningProcessDisposition
    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.
    If you specify
    Migrate
    , be sure to view the Server Log in the Process Console for possible warning messages describing incompatibilities between running processes and the new version they are running against. Refer to the Process Console Help for details.
Valid dispositions are:
  • Maintain
    . Indicates that all process instances for the previous versions should run to completion. This is the default value.
  • Terminate
    . Indicates that all process instances running under previous versions should terminate on the online date of the new version, regardless of whether or not the process instances are complete.
  • Migrate
    . All running process instances created by previous versions will have their state information migrated to use the newly deployed process definition once its online date arrives. If there are incompatible changes between the versions, descriptive warning messages are generated in the Process Console Server Log. Refer to the Process Console Help for details.


Updated March 30, 2020