Request/Reply Flow Example
For this example of using a Request/Reply flow, assume you are writing a custom application and you want to display Contact data with any associated Address data for each Contact. Some Contacts have multiple Address records. Use a Request/Reply flow in your CRM system to provide that data through a REST service.
For this example, you have a ContactId and you want to display the Contact’s name, the last modified date of the Contact entry in your CRM system, and any Addresses for that Contact. Create the following On event Request/Reply flow in TIBCO Cloud™ Integration - Connect to retrieve the data needed in one call as a JSON object:
Building The Flow
- Select Apps from the menu to open the Apps list.
- Select an existing On event app to edit it or select the Create/Import button and choose On event to add a new app.
- At the top of the App Details page enter a name for the app.
- Select an agent from the agent drop-down.
- On the flows tab, select New Flow.
- Select Request/Reply Flow from the list of options.The flow dialog the workspace displays.
- Add Connections to the Connections panel. The blocks you need to build your flow display beneath each Connection name.
- Move a Wait For Request block into the workspace.
- Select the Wait For Request block.
- From the Gear menu select Edit to open the General tab of the Block Properties dialog.
- Change the label to Wait For Request (ContactId).
- Select OK to close the Properties page.
- Select OK to save and close the flow. After saving the flow the first time, TIBCO Cloud™ Integration - Connect generates a unique Endpoint URL which displays on the Wait for Request Block Properties General tab. This may take a few minutes.
Note: Once you have saved the flow, you can copy and paste the Endpoint URL from the Wait For Request block's General tab into a location in the source application. This URL allows your application to communicate directly with this specific flow in TIBCO Cloud™ Integration - Connect.
- Open the flow again and open the Wait for Request block.
- Select the Request tab on the Properties dialog. Specify the request, which in this case is ContactId, and the data type is Guid. The Debug value is used only for Debug, but the format should match the data type you selected.
Later, when you call the Endpoint URL specified in the Wait For Request block, you can pass in these inputs as a JSON object in the POST body of the REST API call, as follows:
{
ContactId="ac35fda0-1092-404a-9257-ae14862faf03"
} - After the Wait For Request block, the next Block is a Fetch Block that filters Contact data by ID on the Filter tab. Fetch also leverages the Include tab to use the Contact to CustomerAddress relationship in your CRM system to look up all related Addresses for that Contact entry.
Fetch Block — Filter
Fetch Block — Include
- Inside the Fetch Contact block, use a Build Reply Block to create the top level of the data hierarchy. In the Entity field, type Contacts. Since Contacts, note the plural name, is at the top level, it does not have a Parent Entity and the Parent Entity field cannot be configured:
- In the Fields Tab for this Build Reply block, specify that ContactID, ContactName, and LastModifiedDate are in the reply. Use the New link to add a row to the Target Connection for each field, ContactID, ContactName, and LastModifiedDate. Map the corresponding source fields on the left to the target fields on the right. This mapping is what builds the reply.
Note: TIBCO Cloud™ Integration - Connect uses the lower camel case naming convention for field names sent in the Reply. Field names that do not follow that convention are changed in the response payload. Best practice is to use lower or lower camel casing, such as lastName instead of LastName. A warning symbol () is displayed when this naming convention is not followed.
At this point, if you ran the flow with just the Build Contact Reply block, the Reply would be similar to the following:
- However, you want the Reply to include both Contact names and addresses. A Contact may have more than one address, so use a second Build Reply block inside a For Each Child Block to build up the addresses. For the For Each Child block, configure the General tab to retrieve data from the related Contact_CustomerAddress entity configured in the Fetch block.
- For the second Build Reply block inside the For Each Child block, in the Entity field type Addresses. Use the Parent Entity field to specify the Build Contact Reply block, which displays only as BuildReply. This causes the Addresses to appear as children of the Contact.
- And then, map only the Address fields required by the target CRM datastore:
Which, when you call the Endpoint URL from your external application, returns the hierarchical reply expected. For example: