Example - Phase 3 Making a Destructive Update to the Model

A company reorganization now occurs which results in department b being broken up.

Design Time

The solution designer:

(1) Removes department b from the ClaimsOrg organization model.

(2) Changes the ClaimsOrg project’s version number to 2.0.0.qual. (As this is a destructive change to the existing organization model, the major part of the version number must be changed.)

(3) Modifies ClaimProc2 to remove participant references to department b.

(4) Updates ClaimProc1 so that ClaimsOrg’s updated major version number (2) is reflected (internally in the process definition) in its participant references to department a.

Note: If ClaimProc1 is not updated, at runtime it will continue to try and use participants defined in V1 of the organization model.

Deployment

The solution designer:

(1) Deploys the ClaimsOrg organization model as an upgrade to the easyAsOrg1 application, as version 2.0.0.ts.

Note: Using the same application name (that is, upgrading) undeploys the V1 runtime organization model. (This is why ClaimProc1 must also be updated as described above - see User Application Dependencies .)

(2) Upgrades the ClaimProc1 and ClaimProc2 applications to, respectively, version 1.1.0.ts and version 2.0.0.ts.

Runtime

TIBCO ActiveMatrix BPM:

(1) creates a V2 runtime organization model.

(2) deletes the V1 runtime organization model.

(1) Directory Services uses the deployment artifact from the 2.0.0.ts version of the easyAsOrg1 application to create a new V2 organization model.

(2) The platform deletes the 1.1.0.ts version of the easyAsOrg1 application (because it has the same name as the deployed application).

(3) Directory Services deletes the deployment artifact from the 1.1.0.ts version of the easyAsOrg1 application. As there are no longer any deployment artifacts contributing to the V1 organization model, it is deleted.

User Application Dependencies

Note: In the following diagram, application dependencies are shown using the convention [Min,Max):
  • Min is the version referenced when the process application is initially deployed. The square bracket denotes that the value is inclusive.
  • Max is the next major version. The round bracket denotes that the value is exclusive.

For example, [1.0.0.ts,2.0.0.ts) denotes any version from 1.0.0.ts (inclusive) to 2.0.0.ts (exclusive). (The ts is not used in the comparison.)

ClaimProc1 and ClaimProc2 both:

(1) have a dependency on the easyAsOrg1 application, version 2.0.0.ts (inclusive) to version 3.0.0.ts (exclusive).

Note: Although ClaimProc1 does not reference department b, its participant references (to department a) must be updated to use the new version. If this is not done, ClaimProc1 would still have a dependency on the easyAsOrg1 application, version 1.0.0.ts (or later 1.x.x.ts).

As the 1.1.0.ts application has now been deleted, this dependency cannot be resolved and the ClaimProc1 application would enter a "Waiting for dependencies" state.

(2) execute against V2 of the runtime organization model (which now includes only departments a and c.)