Example - Phase 4 An Alternative Implementation
The preceding example showed how the separate ClaimsOrg and FinanceOrg organization models could be merged into a single runtime model, by using the same major version number.
However, the Finance division could equally have kept their organization model completely separate by using a different major version number.
Design Time
The solution designer:
(1) Creates a FinanceOrg organization model with a version number of V3.0.0.qual.
(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 (3) is recorded (internally) in the FinanceProc1 process definition as part of the participant definitions.
Deployment
The solution designer:
(1) Deploys the FinanceOrg organization model as the easyAsOrg2 application, version 3.0.0.ts.
(2) Deploys the FinanceOrg project as the FinanceProc1 application, version 1.0.0.ts.
Runtime
TIBCO ActiveMatrix BPM creates the deployed FinanceOrg organization model as a new V3 runtime organization model.
(1) Directory Services uses the deployment artifact from the 3.0.0.ts version of the easyAsOrg2 application to create a new V3 organization model.
(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) Both the V2 and V3 organization models are available.
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 3.0.0.ts (inclusive) to version 4.0.0.ts (exclusive).
(2) FinanceProc1 executes against the V3 runtime organization model.
(3) ClaimProc1 and ClaimProc2 have a dependency on the easyAsOrg1 application, version 2.0.0.ts (inclusive) to version 3.0.0.ts (exclusive).
(4) ClaimProc1 and ClaimProc2 continue to execute against V2 of the runtime organization model (which includes departments a and c).
Alternative Scenario
If the FinanceOrg project was instead deployed as a new major version of the easyAsOrg1 application - version 3.0.0.ts - the resulting scenario would be as shown below.
In this case:
(1) FinanceProc1 has a dependency on the easyAsOrg1 application, version 3.0.0.ts (inclusive) to version 4.0.0.ts (exclusive).
(2) FinanceProc1 executes against V3 of the runtime organization model (which now includes only departments d, e and f).
(3) ClaimProc1 and ClaimProc2 have a dependency on the easyAsOrg1 application, version 2.0.0.ts (inclusive) to version 3.0.0.ts (exclusive).
(4) ClaimProc1 and ClaimProc2 still reference V2 of the runtime organization model, which has been deleted.