Configuring the Process Interface in the Eclipse Modeler

The example explained here is a fictional Product Purchase Process. Extract the Customer_Data.xsd file from the all-tutorials.zip file and add it to the classpath of your Web project. It provides the structured type Customer_Data used in the example models. Import the following example models used in the Eclipse modeler:

Please see the example process from model ProductPurchaseModel.xpdl in the screenshot below. 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 (see screenshot below). 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 (Call Followup Process activity) at runtime.


Product Purchase Process
Figure: Product Purchase Process


CustData_Interface_Process Interface and Formal Parameter definition
Figure: CustData_Interface_Process Interface and Formal Parameter definition

While the process interface defines 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 for the follow-up process (CustDataImplementationModel.xpdl).

3: Two Implementations of CustData_Interface_Process
Figure: Two Implementations of CustData_Interface_Process

The two implementations (CustData_Escalation_Process and CustData_Shipping_Process) are both defined to implement CustData_Interface_Process.

Implementation Process Properties
Figure: 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 the Product Purchase Process above, the set of possible actions that can be selected by the user is picked from the data Followup. As shown in the screenshot 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).

Definition of the Data FollowUp
Figure: Definition of the Data FollowUp

Converting Follow-up Actions

Now the options Ship or Escalate are presented as follow-up actions. The subsequent activity Determine Followup Process is responsible for converting these values into appropriate process implementation names. Note that the Stardust convention {ModelId}{ProcessId} is used to uniquely identify the process.

ConvertingFollow-up action into Process Implementation name
Figure: Converting Follow-up action into Process Implementation name

Finally, we define a sub process activity that dynamically invokes the process implementation determined earlier. 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.

Runtime binding of Process Implementation
Figure: Runtime binding of Process Implementation