Example - Phase 2 Making an Additive Update to the Model

Following some user testing, EasyAs decide that they need to change one of the processes to involve an additional department, c.

Design Time

The solution designer:

(1) Adds department c to the ClaimsOrg organization model.

(2) Changes the ClaimsOrg project’s version number to 1.1.0.ts. (As this is an extension to the existing organization model, the version number can be changed on the minor or micro level.)

(3) Modifies ClaimProc2 to use participants from departments b and c.

(4) Leaves ClaimProc1 unchanged, as it still just uses participants from department a.

Deployment

The solution designer:

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

(2) Upgrades the ClaimProc2 application to version 1.1.0.ts.

Runtime

TIBCO ActiveMatrix BPM merges the changes from the deployed ClaimsOrg organization model - the addition of department c - into the existing V1 runtime organization model.

(1) Directory Services adds the deployment artifact from the 1.1.0.ts version of the easyAsOrg1 application to the V1 organization model.

(2) The platform deletes the 1.0.0.ts version of the easyAsOrg1 application.

Note: This is because the deployed application has the same name as an existing application. The version number is irrelevant.

(3) Directory Services deletes the deployment artifact from the 1.0.0.ts version of the easyAsOrg1 application.

(4) Directory Services uses the deployment artifact from the 1.1.0.ts version of the easyAsOrg1 application as the V1 organization model.

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.)

(1) ClaimProc1 has not been upgraded, so still has a dependency on the easyAsOrg1 application, version 1.0.0.ts (inclusive) to version 2.0.0.ts (exclusive).

(2) ClaimProc2 has a dependency on the easyAsOrg1 application, version 1.1.0.ts (inclusive) to version 2.0.0.ts (exclusive).

(3) ClaimProc1 and ClaimProc2 both execute against V1 of the runtime organization model (which now includes departments a, b and c.)

Note: If the organization model 1.0.0.ts had more entities that the one deployed in 1.1.0.ts, the un-deployment of 1.1.0.ts removes those additional entities.

So, if 1.0.0.ts contained a, b and d, and 1.1.0.ts contained a, b and c, entity d would be removed after 1.1.0.ts is deployed (causing 1.0.0.ts to be un-deployed).

To avoid this, change the name of the application when deploying the updated model (and deploy as a new application and not as an upgrade).