Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Stardust/Knowledge Base/Modeling/Process Interfaces and Dynamic Process Selection"
(→Output) |
(→Example) |
||
Line 20: | Line 20: | ||
<br /> | <br /> | ||
The two implementations (“CustData_Escalation_Process” and “CustData_Shipping_Process”) are both defined to implement “CustData_Interface_Process” (Figure 4). | The two implementations (“CustData_Escalation_Process” and “CustData_Shipping_Process”) are both defined to implement “CustData_Interface_Process” (Figure 4). | ||
− | |||
[[File:Stardust_Modeling_Process_Interfaces_and_Dynamic_Process_Selection4.png|Figure 4: Implementation Process Properties]] | [[File:Stardust_Modeling_Process_Interfaces_and_Dynamic_Process_Selection4.png|Figure 4: Implementation Process Properties]] | ||
:::::::Figure 4: Implementation Process Properties | :::::::Figure 4: Implementation Process Properties | ||
− | |||
<br /> | <br /> | ||
− | Thus, it is expected that both these implementations will consume and return a Customer_Data SDT. As discussed earlier this is precisely the values that are passed to these processes from the Product Purchase process. We now return to the Product Purchase process to discuss the process of runtime binding to a process interface implementation. As shown in Figure 1 above, the set | + | Thus, it is expected that both these implementations will consume and return a Customer_Data SDT. As discussed earlier this is precisely the values that are passed to these processes from the Product Purchase process. We now return to the Product Purchase process to discuss the process of runtime binding to a process interface implementation. As shown in Figure 1 above, the set of possible actions that can be selected by the user is picked from the data “Followup”. As shown in Figure 5 below, this data is a reference to the “Followup” SDT which consist of two parts – “ActionSelected” (an enumeration of type “Followup_Actions”) and “FollowupProcess” (a string). |
− | + | ||
− | + | ||
[[File:Stardust_Modeling_Process_Interfaces_and_Dynamic_Process_Selection5.png|Figure 5: Definition of the Data FollowUp]] | [[File:Stardust_Modeling_Process_Interfaces_and_Dynamic_Process_Selection5.png|Figure 5: Definition of the Data FollowUp]] | ||
:::::::Figure 5: Definition of the Data FollowUp | :::::::Figure 5: Definition of the Data FollowUp | ||
− | |||
The user is thus presented the options “Ship” or “Escalate” as follow-up actions. The subsequent activity “Determine Followup Process” is responsible for converting these values into appropriate Process Implementation names (Figure 6). Note that the Stardust convention {ModelId}{ProcessId} is used to uniquely identify the process. | The user is thus presented the options “Ship” or “Escalate” as follow-up actions. The subsequent activity “Determine Followup Process” is responsible for converting these values into appropriate Process Implementation names (Figure 6). Note that the Stardust convention {ModelId}{ProcessId} is used to uniquely identify the process. | ||
− | |||
[[File:Stardust_Modeling_Process_Interfaces_and_Dynamic_Process_Selection6.png|Figure 6: ConvertingFollow-up action into Process Implementation name]] | [[File:Stardust_Modeling_Process_Interfaces_and_Dynamic_Process_Selection6.png|Figure 6: ConvertingFollow-up action into Process Implementation name]] | ||
:::::::Figure 6: Converting Follow-up action into Process Implementation name | :::::::Figure 6: Converting Follow-up action into Process Implementation name | ||
− | |||
Finally, we define a Subprocess activity that dynamically invokes the process implementation determined earlier (Figure 7). We declare that the Subprocess is resolved at runtime and pass in the process data (“Followup/FollowupProcess”) that identifies the Process Id of the desired implementation. | Finally, we define a Subprocess activity that dynamically invokes the process implementation determined earlier (Figure 7). We declare that the Subprocess is resolved at runtime and pass in the process data (“Followup/FollowupProcess”) that identifies the Process Id of the desired implementation. | ||
− | |||
[[File:Stardust_Modeling_Process_Interfaces_and_Dynamic_Process_Selection7.png|Figure 7: Runtime binding of Process Implementation]] | [[File:Stardust_Modeling_Process_Interfaces_and_Dynamic_Process_Selection7.png|Figure 7: Runtime binding of Process Implementation]] | ||
:::::::Figure 7: Runtime binding of Process Implementation | :::::::Figure 7: Runtime binding of Process Implementation | ||
− | |||
− | |||
− | |||
== Output == | == Output == |
Revision as of 01:29, 28 November 2013
Introduction
Sometimes a need arises where a certain process needs to be implemented differently depending on certain process data. For example, a regulatory process for a company based in the US might require certain Sarbanes-Oxley (“SOX”) compliance activities while a company listed elsewhere might have to comply with other local laws. Stardust provides the ability to support such scenarios by defining process interfacesthat can have multiple implementations. The implementation chosen at runtime is bound to certain process data and can thus be dynamically selected. All artifacts referred to in the following discussion can be downloaded from here.
Example
The example explained here is a fictional product purchase process (Figure 1) (“ProductPurchaseModel.xpdl”). The process begins by accepting certain customer information. The user is then prompted to select the follow-up process. The follow-up process is an example of a Process Interface. This interface is defined in its own model (“CustDataInterfaceModel.xpdl”) which also provides a default implementation (Figure 2). A reference to this interface is made in the “Product Purchase Process”. This interface defines a single INOUT parameter of type “Customer_Data” and an instance of this SDT (“CustData”). The Product Purchase process imports this data and binds it to the formal process interface parameter to pass data to/from the Process Interface implementation (“CallFollowup Process” activity) at runtime.
- Figure 1: Product Purchase Process
- Figure 2: CustData_Interface_Process Interface and Formal Parameter definition
While the process interface does define a default implementation it is intended that the process designer extend the interface by providing his own implementations that meet the actual
business need. In our example we provide two implementations (Figure 3) for thefollow-up process (“CustDataImplementationModel.xpdl”).
- Figure 3: Two Implementations of CustData_Interface_Process
The two implementations (“CustData_Escalation_Process” and “CustData_Shipping_Process”) are both defined to implement “CustData_Interface_Process” (Figure 4).
- Figure 4: Implementation Process Properties
Thus, it is expected that both these implementations will consume and return a Customer_Data SDT. As discussed earlier this is precisely the values that are passed to these processes from the Product Purchase process. We now return to the Product Purchase process to discuss the process of runtime binding to a process interface implementation. As shown in Figure 1 above, the set of possible actions that can be selected by the user is picked from the data “Followup”. As shown in Figure 5 below, this data is a reference to the “Followup” SDT which consist of two parts – “ActionSelected” (an enumeration of type “Followup_Actions”) and “FollowupProcess” (a string).
- Figure 5: Definition of the Data FollowUp
The user is thus presented the options “Ship” or “Escalate” as follow-up actions. The subsequent activity “Determine Followup Process” is responsible for converting these values into appropriate Process Implementation names (Figure 6). Note that the Stardust convention {ModelId}{ProcessId} is used to uniquely identify the process.
- Figure 6: Converting Follow-up action into Process Implementation name
Finally, we define a Subprocess activity that dynamically invokes the process implementation determined earlier (Figure 7). We declare that the Subprocess is resolved at runtime and pass in the process data (“Followup/FollowupProcess”) that identifies the Process Id of the desired implementation.
- Figure 7: Runtime binding of Process Implementation
Output
We first deploy the interface, implementation and consumer models. The Model Management view appears as shown below (Figure 8).
- Figure 8: Deploying the interface, implementation and consumer models
Next, we kick off the Product Purchase process and enter some customer data (Figure 9). We do no enter any value for the “Final Outcome” field since it is populated by the runtime process implementation selected and displayed as the modified customer data in the final step of the Product Purchase process.
- Figure 9: Enter Customer Details activity
In the next step (Figure 10), we select the follow-up action (in this case “Escalate”). The “Followup Process” field is left blank since it is populated in the subsequent MTA (see Figure 6 above).
- Figure 10: Select Followup Action activity
In the final step, the “Display Final CustData” activity (Figure 11), displays the modified customer data. The “Final Outcome” field is populated with a value that depends on the Process Implementation selected at runtime. In this particular case the value “Escalated” is displayed since we chose the “Escalate” action in an earlier step (see Figure 10 above).
- Figure 11: Display Final CustData
The Process History view (Figure 12) displays the sequence of activities executed during the process run. It also indicates that the “CustData_Escalation_Process” was selected at runtime. This agrees with the input provided earlier and validates that our processes have been designed correctly. We can run the process once more and choose the other follow-up action this time “Ship” totest that the “CustData_Shipping_Process” is executed for this value (not discussed here).
- Figure 12: Process History and display of runtime Process Implementation information