Stardust/Knowledge Base/Modeling/Process Interfaces and Dynamic Process Selection

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 interfaces that can have multiple implementations. The implementation chosen at runtime can be 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 structured data type (“CustData”). The Product Purchase process imports this data and binds it to the formal process interface parameter to exchange data with 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 provides his own implementations that meet the actual business need. In our example we provide two implementations (Figure 3) for the follow-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 structured data of type Customer_Data. As discussed earlier these are 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” structured data type 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 sub process activity that dynamically invokes the process implementation determined earlier (Figure 7). We declare that the sub process 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