The example explained here is a fictional Product Purchase Process. For viewing the example in the Portal Modeling Perspective, we use the following example files from the all-tutorials.zip file:
CustDataInterfaceModelWeb.xpdlCustDataImplementationModelWeb.xpdlPurchasingWeb.xpdlCustomer_Data.xsdThe Customer_Data.xsd file provides the structured type Customer_Data used in the
example models. Add it to the classpath of your Web project. Import the example models in the Portal Modeling
perspective. Start with the import of the CustDataInterfaceModelWeb.xpdl model as this is the provider
model providing the process interface.
Please see the example process from model PurchasingWeb.xpdl in the
screenshot below.

Figure: Product Purchase Process
The process begins by accepting certain customer information. The user is then prompted to select the follow-up
process Call Followup Process. The follow-up process is an example of a process interface. This
interface is defined in its own model CustDataInterfaceModelWeb.xpdl, which also provides a default
implementation as displayed in the screenshot below.

Figure: CustData_Interface_Process Interface and Formal Parameter definition
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.
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 in model
CustDataImplementationModelWeb.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