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.
Figure: Product Purchase Process
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).
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.
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).
Figure: Definition of the Data FollowUp
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.
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.
Figure: Runtime binding of Process Implementation