Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Stardust/Knowledge Base/Modeling/Deploying multiple Models"
m (→Bulk Deployment) |
|||
| (16 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | == | + | == Purpose and Benefits == |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | Stardust supports deployment of multiple models to the Audit trail. This facility can be used to: | |
| − | + | *Separate model elements into libraries of data/message structures, applications, basic process definitions and participants (Use A) | |
| − | + | *Design process skeletons, where parts (sub-process definitions, applications) might be overwritten in a concrete deployment scenario (Use B) | |
| − | + | *Design implementations for subprocesses and applications used in Type B scenarios (Use C) | |
| + | *Process models or sets of these which have no reference to other deployed models (Use D) | ||
| − | + | The mechanism is also useful for exposing processes with service interfaces, as described in article Process as Service. Use cases for multiple models include: | |
| − | + | *Projects separate and distribute work to multiple teams (A) | |
| + | *An operational template provides process model elements for re-use across an organization (A) | ||
| + | *An organization deploys core processes with regional/departmental variations (A,B,C) | ||
| + | *Environments that serve multiple customers/tenants with different levels of service/process(A,B,C) | ||
| + | *Departments deploy models in isolation to a shared audience (D) | ||
| − | <div><br></div><div>Linking happens during model deployment to resolve this issue:</div> | + | == Terminology == |
| − | #Start with a given model deployment. | + | |
| − | #Add all other deployments linked as Producer. | + | In multiple model environments, a process definition can have type 'Producer, 'Consumer', and 'Implementer'. A Producer provides an 'Process Interface' through which Consumers can re-use elements specified in that interface. An Implementer is a processes that replaces a specific process (usually sub-process) within a target model. Any combination of model type can be packaged together as a 'Process Model Set', and deployed to the Audit trail as part of a 'Bulk Deployment' |
| − | #Add all other deployments linked as Consumers. | + | |
| + | {| | ||
| + | |- | ||
| + | | [[Image:MultipleModelReuse.png]] | ||
| + | | [[Image:MultipleModelDeploy.png]] | ||
| + | |- | ||
| + | | Figure 1. Model element re-use | ||
| + | | Figure 2. Model Sets and references | ||
| + | |} | ||
| + | |||
| + | <br> | ||
| + | |||
| + | In Figure 1, consumer model M2 is reusing the public elements A1 & D1, and process P1 of producer M1. In Figure 2, M1 and M2 form a model set S1, and are deployed together. M3 consumes or provides implementation for M1 & M2 elements, therefore must be deployed within S1 or after S1. More information on deployment follows. | ||
| + | |||
| + | For now, refer to the process models in [[Media:MultipleModel.zip]] that follow these examples. | ||
| + | |||
| + | == Defining Interfaces == | ||
| + | |||
| + | In the Eclipse IDE, the Process properties dialog includes a 'Process Interfaces' section. Here the default (no interface, for normal processes) can be changed to Provides Process Interface or Implements Process Interface.<br> When providing an interface, data in/out can be selected (Parameters) from those used by that process definition. Additional options (Invocation) allow this interface to be specified by a REST or SOAP service. These services can then be located through the IPP Process Interface Endpoint URL i.e. <server>/services/soap/InfinityBpmService.wsdl? | ||
| + | |||
| + | For a Consumer or Implementor Process to access elements in another model, a reference must exist to that model. External Model information is a top level element for IPP process models. Connections can be either to files on the local file system, or a network repository, with the latter usually used with distributed development. At deployment these models will be linked and local/remote connections are overridden by process engine linking (see bulk deployment). | ||
| + | |||
| + | == Modeling == | ||
| + | |||
| + | Once a connection exists the model elements will be available to drag and drop onto the canvas from the outline. | ||
| + | |||
| + | <br> | ||
| + | |||
| + | {| | ||
| + | |- | ||
| + | | [[Image:MultipleModelReferences.png]] | ||
| + | |- | ||
| + | | Figure 5. External model references in Eclipse IDE | ||
| + | |} | ||
| + | |||
| + | Drag & dropping a data type will be displayed in a diagram as you might normally expect, with a local data element (e.g. D1) added to the consumer model. A process will be added as a sub-process (refer to P1 within P3 in the example zip). Re-using an application, however is not as intuitive, with an activity created that contains an internal link to the referenced application type, e.g. Application Activity 1. View activity properties and you will notice the 'Application' section references M1 (select 'display imported model elements as groups' checkbox). | ||
| + | |||
| + | == Bulk Deployment == | ||
| + | |||
| + | <font face="Arial">Since references exist between models, deployment order is important to manage correct linking between </font><font face="Arial">multiple parallel deployments of a models or their versions. Multiple deployments at runtime mean that design time associations are no longer unique. C</font>ircular ‘uses‘ associations are prohibited and must rejected<span style="font-family: Arial;">.</span> | ||
| + | <div><br></div><div>Linking happens during model deployment to resolve this issue:</div> | ||
| + | #Start with a given model deployment. | ||
| + | #Add all other deployments linked as Producer. | ||
| + | #Add all other deployments linked as Consumers. | ||
#Recurse for any deployment added during 2. or 3.<br> | #Recurse for any deployment added during 2. or 3.<br> | ||
| − | |||
| − | + | <br> | |
| − | + | <div>The result is a ‘Process Model Set‘ which is stored in the Audit Trail as a discrete unit. Each new process instances contain a snapshot of the Process Model Set valid at the time of process instantiation.</div><div></div> | |
| − | In Figure 3, the three deployed models are shown. Consumer models icons (blue arrow facing left) are disabled so that only Producer model references are shown. Here is is clear that M3 references M1, M2, and M2 references M1, as in Figure 2. If multiple versions of a model have been deployed that is also indicated | + | A deployment unit can consist of multiple models, will linkages resolved within this unit before checking models/units already deployed on a target server.<br> The console command is: <code>console -deploy -filename<code>, with options <code>-overwrite -predecessor</code> Note that deployed models are still restricted by audit partitions. |
| − | + | ||
| − | + | == Runtime Configuration == | |
| − | + | ||
| − | + | In Figure 3, the three deployed models are shown. Consumer models icons (blue arrow facing left) are disabled so that only Producer model references are shown. Here is is clear that M3 references M1, M2, and M2 references M1, as in Figure 2. If multiple versions of a model have been deployed that is also indicated | |
| + | |||
| + | Note M1 has runtime configuration available as a gear icon. This dialog (Figure 4) allows P1 or P1' to be set as the active model. This choice will be actioned for each ''new'' P1 instance once selected. | ||
| + | |||
| + | {| | ||
| + | |- | ||
| + | | [[Image:MultipleModelMgmt.png]] | ||
| + | | [[Image:MultipleModelImpl.png]] | ||
| + | |- | ||
| + | | Figure 3. Portal (Administration) Model Management | ||
| + | | Figure 4. Process Implementation selection | ||
| + | |} | ||
| + | |||
| + | == Resources == | ||
| + | |||
| + | [[Media:MultipleModel.zip]] | ||
Latest revision as of 23:34, 30 May 2012
Contents
Purpose and Benefits
Stardust supports deployment of multiple models to the Audit trail. This facility can be used to:
- Separate model elements into libraries of data/message structures, applications, basic process definitions and participants (Use A)
- Design process skeletons, where parts (sub-process definitions, applications) might be overwritten in a concrete deployment scenario (Use B)
- Design implementations for subprocesses and applications used in Type B scenarios (Use C)
- Process models or sets of these which have no reference to other deployed models (Use D)
The mechanism is also useful for exposing processes with service interfaces, as described in article Process as Service. Use cases for multiple models include:
- Projects separate and distribute work to multiple teams (A)
- An operational template provides process model elements for re-use across an organization (A)
- An organization deploys core processes with regional/departmental variations (A,B,C)
- Environments that serve multiple customers/tenants with different levels of service/process(A,B,C)
- Departments deploy models in isolation to a shared audience (D)
Terminology
In multiple model environments, a process definition can have type 'Producer, 'Consumer', and 'Implementer'. A Producer provides an 'Process Interface' through which Consumers can re-use elements specified in that interface. An Implementer is a processes that replaces a specific process (usually sub-process) within a target model. Any combination of model type can be packaged together as a 'Process Model Set', and deployed to the Audit trail as part of a 'Bulk Deployment'
|
|
| Figure 1. Model element re-use | Figure 2. Model Sets and references |
In Figure 1, consumer model M2 is reusing the public elements A1 & D1, and process P1 of producer M1. In Figure 2, M1 and M2 form a model set S1, and are deployed together. M3 consumes or provides implementation for M1 & M2 elements, therefore must be deployed within S1 or after S1. More information on deployment follows.
For now, refer to the process models in Media:MultipleModel.zip that follow these examples.
Defining Interfaces
In the Eclipse IDE, the Process properties dialog includes a 'Process Interfaces' section. Here the default (no interface, for normal processes) can be changed to Provides Process Interface or Implements Process Interface.
When providing an interface, data in/out can be selected (Parameters) from those used by that process definition. Additional options (Invocation) allow this interface to be specified by a REST or SOAP service. These services can then be located through the IPP Process Interface Endpoint URL i.e. <server>/services/soap/InfinityBpmService.wsdl?
For a Consumer or Implementor Process to access elements in another model, a reference must exist to that model. External Model information is a top level element for IPP process models. Connections can be either to files on the local file system, or a network repository, with the latter usually used with distributed development. At deployment these models will be linked and local/remote connections are overridden by process engine linking (see bulk deployment).
Modeling
Once a connection exists the model elements will be available to drag and drop onto the canvas from the outline.
|
| Figure 5. External model references in Eclipse IDE |
Drag & dropping a data type will be displayed in a diagram as you might normally expect, with a local data element (e.g. D1) added to the consumer model. A process will be added as a sub-process (refer to P1 within P3 in the example zip). Re-using an application, however is not as intuitive, with an activity created that contains an internal link to the referenced application type, e.g. Application Activity 1. View activity properties and you will notice the 'Application' section references M1 (select 'display imported model elements as groups' checkbox).
Bulk Deployment
Since references exist between models, deployment order is important to manage correct linking between multiple parallel deployments of a models or their versions. Multiple deployments at runtime mean that design time associations are no longer unique. Circular ‘uses‘ associations are prohibited and must rejected.
- Start with a given model deployment.
- Add all other deployments linked as Producer.
- Add all other deployments linked as Consumers.
- Recurse for any deployment added during 2. or 3.
A deployment unit can consist of multiple models, will linkages resolved within this unit before checking models/units already deployed on a target server.
The console command is: console -deploy -filename<code>, with options <code>-overwrite -predecessor Note that deployed models are still restricted by audit partitions.
Runtime Configuration
In Figure 3, the three deployed models are shown. Consumer models icons (blue arrow facing left) are disabled so that only Producer model references are shown. Here is is clear that M3 references M1, M2, and M2 references M1, as in Figure 2. If multiple versions of a model have been deployed that is also indicated
Note M1 has runtime configuration available as a gear icon. This dialog (Figure 4) allows P1 or P1' to be set as the active model. This choice will be actioned for each new P1 instance once selected.
|
|
| Figure 3. Portal (Administration) Model Management | Figure 4. Process Implementation selection |