Building your first iFlow – Part 5: Completing the iFlow

In the previous instalment Building your first iFlow – Part 4: Configuring your credentials we built an integration process and configured receiving the data and forwarding the response. The actual step for performing the processing of the data now needs to be built.

The first thing that needs to be done is getting rid of the error on the content modifier since this is preventing deployment and testing of the iFlow. To do this the content modifier needs to be configured to extract the relevant fields from the XML and then pass them onwards. To decide what data needs to be extracted, it is best to connect to the service and examine the resulting XML in an application that will easily allow REST services to be accessed.

In this case I used the Postman REST client in Chrome, though there are many other options that could have been equally as well suited.

For this the “weather” element in the “current” root element needs to be extract and the “value” field will be used. This is formed by the XPath string “/current/weather/@value” The last update field will also need to be passed onto the next process in the integration and can be extracted in the same way.

We create two header properties that are strings called “currentConditions” and “currentReport” and these point to the XPath attributes “/current/weather/@value” and “/current/lastupdate/@value”. In XPath the “@” refers to an attribute and not an element. Also remember to make these header values so they can be passed to the external service calls. If they are properties they will not be sent to the external processes.

It is now possible to complete configuration of the email channel by setting the subject, body and attachments.

Open the email channel and configure the subject to use the “currentConditions” value and the body to use the “currentReport” and “currentConditions” values. HCI uses the ${property/header/body} format to allow header, body and property values from content modifier steps to be inserted into succeeding operation steps in the iFlow.

For extra credit, the message body from the content modifier step (that is the response from the weather service as XML) can be used  as an attachment to the email.

Update: The last step is to configure the sender to use Basic, rather than Certificate authentication. Select the “Sender” element in the iFlow. Then in the properties at the bottom, set the “Authentication Mode” to “Basic Authentication”

Save the iFlow and first use the Execute Checks command to check the “Process Integration” component is consistent.

Use the Deploy Integration Content command to deploy the iFlow to your HCI Tenant.

Because iFlow is marked as run once, on deployment the iFlow will execute. It should now run successfully and a message should be received in your Gmail account.

Note the header text, the body text and of course as expected there is also an attachment in the message.

The final configuration step in the iFlow is to have this iFlow integration process execute every day. To do this the start timer needs to be reconfigured to run daily at 08:00. Of course other execution options could be chosen to run the integration process at different times depending on the processing required.

Select the “Start Event 2” component and then from the properties tab, uncheck the “run once” checkbox and select the “daily” radio button and then select the “time” radio button, setting the time to “08:00” as below:

Save the iFlow, execute the Checks command to ensure that the iFlow is consistent and then deploy the iFlow to your HCI tenant. Pat yourself on the back for designing, creating and deploying your first iFlow, have a sleep and wake up with the weather being delivered to your gmail inbox everyday.

In the final installment the tracing options will be discussed.