In the diagram containing the activity and the data element you can map the data as the activity's input and output. There is at least one data flow connection between an activity and a data. The data flow connection is indicated by arrows:
This chapter covers:
For details on data flow in general, refer to chapter Workflow Data Workflow Data of the Concepts handbook. Concepts Handbook in the Infinity Process Platform Documentation.
You can create data flow connections using two different ways:
Figure: Create Connector Icon
Figure: Create Connector - Data Flyout Menu
Hover the mouse in proximity of the data flow connector and click the Delete icon.
Figure: Delete Data Flow
To view and edit properties of data flow, perform the following steps:
Figure: Data Flow - Properties
The UUID and ID options are displayed only when you switch to Integrator profile.
Access points are named parameters to set or get values associated with a model element at runtime. Refer to section Access Points of chapter Workflow Data of the Infinity Concepts handbook Access Points of chapter Workflow Data of the Concepts Handbook in the Infinity Process Platform Documentation for details on the concept of using access points in IPP.
You can select the context from the drop-down list in the Input Access Point and Output Access Point fields. Per default, the Default input and output access points are selected. For application activities, application context access points are provided according to the type of implementation. Refer to the Specifying Applications overview and select the chapter applying to your application for details on setting implementation specific access points.
Figure: Input Access Point - Application Context
In an engine context, you can also select Activity Instance.
Figure: Output Access Point - Application Context
Depending on the type of the access point an input or output access point path can be applied to it.
For example, an output access point path could be a String method to convert a primitive output from a message transformation application to upper case letters:
Figure: Example Output Access Point Path
You can provide multiple data mapping to an application from the same structured object or you can apply the same simple data to more than one data path.
For example, email application provides multiple access points like "To", "From", "CC", "Subject" etc. You can provide data mapping to more than one of these from the same structured data object.
For example, from the structured data named Customer, you want to see only ID and Zip fields from it. The Customer data has Address as the nested structured data which contains Zip and CIty. In this case, following would be the model and data mapping:
Figure: Data Mapping
In the above example, the access points are filled by using the same data object multiple times and selecting different data paths for ID and Zip.
Note that deleting the data flow from the modeling canvas removes all data mappings.
The Delete icon is enabled only when there are two or more data mappings. Deleting the last or only data mapping is supported from the drawing canvas only. Also, reordering of data mappings is not supported.
In case you import an Eclipse-based model which contains Java classes and methods associated with Java-type application (Spring Bean, Session Bean etc.), its access points are available for selection in the Modeling perspective. Data paths are not editable for data mapping between Java, Spring Bean and Session Bean applications and data.
Figure: Input Access Point - Java-type Application
Input and Output Access Points for multiple instance tasks have (List) appended to indicate that the list data iterates for each data element from the list as access point.
Figure: Access Point Selection for Multiple Instance Activity
For details on the concept of using multi instances activities refer to chapter Using Multiple Instance Activities of the Concepts handbook. Using Multiple Instance Activities of the Concepts handbook.
Data Access Points for Rule Tasks are computed from the Rule Set that is selected for the Rule Task. All data parameters created for the Rule Set are exposed in the Data Flow. For details on Rule Tasks refer to section Rule task implementation of chapter Working with Activities.
For example, a Rule Set IN data parameter CustomerName is provided for a Rule Set that is selected as implementation for the Rule Task.
Figure: In Data Parameter for selected Rule Set
This data parameters is provided as In access point for the Rule Task data flow.
Figure: Input Access Point for Rule Task
The same happens for the OUT data parameters specified in the same Rule Set.
Figure: Out Data Parameter for selected Rule Set
They are provided as Out Access Points for the Rule Task data flow.
Figure: Output Access Point for Rule Task
Similarly, all In/Out data parameters created in the Rule Set are provided for both, In Access Points and Out Access Points for the Rule Task.
The Process Interface Context is needed when one model is referring to another model through exposed process interface. Suppose the referred subprocess has IN parameters defined and it returns the result. Then, in this case. the called process should know the IN and OUT parameters. So if the referred process has exposed the parameters then you need to provide the data mappings in the process interface context.
Note that the data type specified in the formal parameters should match with the data type specified in the consumer model. For example, you have defined structure data type in the provider model. To access the same structured data in the consumer model, you need to drag and drop the structured data and reference through the data mappings.
To specify the process interface context, perform the following steps:
Figure: Data Flow - Referred Elements
Figure: Input Access Point - Process Interface Context