IBM BPM 7.5 All Platforms-Versioning

The life cycle of a process application begins with the creation of the process application and continues through a cycle of updating, deploying, co-deploying, undeploying, and archiving the process application. Versioning is a mechanism used to manage the life cycle of the process application by uniquely identifying the individual versions of the process application.

The way that versioning works in IBM® Business Process Manager depends on what you are deploying–a process application, deployed from the repository in IBM Process Center, or an enterprise application deployed directly from IBM Integration Designer.

The process applications and toolkits that you deploy to a runtime environment from the Process Center are, by default, versioned. For enterprise applications, you can choose to version modules and libraries in IBM Integration Designer.

In addition, you can create versions of a human task or state machine, so that multiple versions of the task or state machine can coexist in the runtime environment.

• Versioning process applications
  Versioning provides the ability for the runtime environment to identify snapshots in the lifecycle of a process application and to be able to concurrently run multiple snapshots at the same time.
• Versioning modules and libraries
  If a module or library is in a process application or toolkit, it takes on the life cycle of the process application or toolkit (versions, snapshots, tracks, and so on). Module and library names must be unique within the scope of a process application or toolkit.
• Naming conventions
  A naming convention is used to differentiate the various versions of a process application as it moves through the life cycle of updating, deploying, co-deploying, undeploying, and archiving.
• Version-aware bindings
  Process applications can contain SCA modules that include import and export bindings. When you co-deploy applications, the binding for each version of the application must be unique. Some bindings are automatically updated during deployment to ensure the uniqueness between versions. In other cases, you have to update the binding after deployment to ensure its uniqueness.
• Version-aware dynamic invocation
  You can configure mediation flow components to route messages to endpoints that are determined dynamically at run time. When you create the mediation module, you configure the endpoint lookup to use version-aware routing.
• Versioning of BPEL processes
  Business processes evolve over time. They need to reflect changing environments and business needs. These changes might be business-driven changes, such as changes in regulations, or optimizations of processes. Business-process applications can include long-running BPEL instances. These instances can run for weeks, months, or even years. This characteristic imposes specific requirements on the introduction of new versions of BPEL processes.
• Deploying process applications with Java modules and projects
  Process applications can contain custom Java EE modules and Java projects. When you co-deploy applications, the custom Java EE module for each version of the application must be unique.
• Deploying process applications with business rules and selectors
  If you are deploying multiple versions of a process application that includes a business rule or selector component, be aware of the way that the associated metadata is used by the versions.

For training on IBM Lombardi mail us at [email protected]