Example - Phase 4 Extending the Organization Model
Finally, the project is rolled out to include other parts of the company.
The initial Finance division implementation defines a single application, FinanceProc1, which involve departments d, e and f.
Design Time
The solution designer:
(1) Creates a FinanceOrg organization model with a version number of V2.1.0.ts.
(2) Adds participants from departments d, e and f to FinanceProc1. Each participant is defined as an external reference to the FinanceOrg organization model.
FinanceOrg’s major version number (2) is recorded (internally) in the FinanceProc1 process definition as part of the participant definitions.
Because this will be an extension to the existing runtime organization model (which does not impact departments a and c) the same major version number can be used with an update to the minor version number.
Deployment
The solution designer:
(1) Deploys the FinanceOrg organization model as the easyAsOrg2 application, version 2.1.0.ts.
(2) Deploys the FinanceOrg project as the FinanceProc1 application, version 1.0.0.ts.
Runtime
TIBCO ActiveMatrix BPM merges the changes from the deployed FinanceOrg organization model - the addition of departments d, e and f - into the existing V2 runtime organization model.
(1) Directory Services adds the deployment artifact from the 2.1.0.ts version of the easyAsOrg2 application to the V2 organization model.
This establishes a dependency on the deployment artifact from the 2.0.0.ts version of the easyAsOrg1 application.
(2) The platform does not delete the 2.0.0.ts version of the easyAsOrg1 application (because it has a different name from the deployed application).
(3) The V2 organization model is the combination of both deployment artifacts.
User Application Dependencies
- 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) FinanceProc1 has a dependency on the easyAsOrg2 application, version 2.1.0.ts (inclusive) to version 3.0.0.ts (exclusive).
(2) ClaimProc1 and ClaimProc2 have a dependency on the easyAsOrg1 application, version 2.0.0.ts (inclusive) to version 3.0.0.ts (exclusive).
(3) ClaimProc1, ClaimProc2 and FinanceProc1 all execute against V2 of the runtime organization model (which includes departments a, c, d, e and f).
Alternative Scenario
Instead of using a new application name, the FinanceOrg project could have been deployed as version 2.1.0.ts of the easyAsOrg1 application. This would have resulted in the scenario shown below.
In this case:
(1) FinanceProc1 has a dependency on the easyAsOrg1 application, version 2.1.0.ts (inclusive) to version 3.0.0.ts (exclusive).
(2) ClaimProc1 and ClaimProc2 have a dependency on the easyAsOrg1 application, version 2.0.0.ts (inclusive) to version 3.0.0.ts (exclusive).
(3) ClaimProc1, ClaimProc2 and FinanceProc1 execute against V2 of the runtime organization model (which now includes only departments a, c, d, e and f).