HCI First Steps Part 6 – Identifying issues

In the previous installment HCI First Steps Part 5 – Completing the iFlow the integration flow was built, deployed and set to run daily. In the final installment of the series we will be looking at what happens when things go wrong; how to find and resolve errors with your iFlow.

We have now completed the iFlow and deployed it. Each time the iFlow is run, providing tracing is enabled, there will be a log of each step of the process. This trace data can then be integrated into the iFlow so that each step can be examined to verify the input data and the output data to make sure the data is as expected.

To enable tracing the first step is to request tracing be enabled on your tenant. By default this is disabled. Goto the SAP Incident Report portal (https://support.sap.com/kb-incidents/incident.html) and create a new request using the component “LOD-HCI”. Making sure to have your tenant id to hand and the S-User as well. Once the ticket has been actioned, tracing will now be enabled for your tenant. Typically tracing is disabled as it has an overhead that could impact the data to day performance in high volume situations.

The first step is to enable the tracing and logging messages in the iFlow. Click outside the iFlow, on the checkerboard pattern and the properties tab will now show the configuration settings for the iFlow

Click on the Runtime Configuration tab since we want to enable debugging and in the “Message Processing Log” option, select “All Events”. Also check the “Enable Debug Trace” checkbox.

Next choose the “Trace Configurations” tab and change the trace level to “Header and Body”

This is all that is needed to enable the iFlow to generate trace and debug information. Redeploy the iFlow and switch to the “Message Monitoring” tab in the “Integration Operations “ perspective.  This view will help assist in seeing how your integration process executed and also where to find the logging and trace messages of the integration flow that was just deployed.

This highlighted areas show the most important features on this view. The “Refresh” button on the top right is used to refresh the list of messages from integration flow executions. In this case there is only one row and that row shows the “WeatherReport” iFlow version 1.0.0 execution was completed successfully. The result of the execution is shown in the Properties tab on the bottom. This shows a textual representation of the execution of the iFlow, which though concise and comprehensive is also not very user friendly. The “View Trace” button on the right of the messages will take the message trace and apply it to each step of the integration flow so that the inputs and outputs can be linked to the graphical iFlow.

Click on the “View Trace” button now. If the button is not enabled then click on the message in the list and then the button will enable.

Note how now each sequence flow is annotated with a yellow envelope. This is the output of the previous step so that makes it possible to view each step of the process and the outputs of the process. Click on the envelope and the properties tab will show the message headers and also the message payload. In the example above the payload will be the XML body that was retrieved by the Request-Reply external service call to obtain the weather.

Remember that in the “Content Modifier” step additional header values were added to the message by extracting the values from the iFlow. These values can now be examined by clicking on the final envelope.

Of course this shows a deployment that was successful, unfortunately despite our best intentions, sometimes something goes wrong. To illustrate this, lets create a new step in our integration flow that will translate JSON to XML. Whilst the output of the request reply is an XML string, the intention is to generate an exception to illustrate in the graphical iFlow what an exception trace looks like.

Right click over the sequence between the Request-Reply and the Content Modifier and from the “Add Message Transformers” menu, select the “Convertor” transformer.

This will insert the default converter which converts from CSV to XML. Right click over the element and change the type to JSON to XML.

The integration flow will now have a new element to transform the response from JSON to XML

Deploy the integration flow as normal and the execution will fail

Click on the Failed line and the “View Trace” button will enable as before. Click this button and the integration flow will now show an error where an exception was generated in the sequence processing.

Click on the error envelope and the properties will now show the exception as well as the body (payload) and header of the message.

However in a number of cases a exception is not raised, it is up to you to handle situations such as where the server is unavailable or the wrong URL is supplied. These are error conditions the iFlow should handle.

Last but not least, sometimes for one reason or another the iFlow will deploy but no run. To simulate this scenario, deploy the iFlow but choose to deploy it to an IFL node rather than an IFLMAP node. Ignore the warning message and continue.

Since IFL nodes are not supported on trial tenants this will deploy but will not run. Unfortunalty no messages will be displayed in the Message Monitoring either.  To find out what happened between Deployment and Execution, open the “Tasks View” view and scroll through the tasks list until the task in red is shown.

The big red X stands out and this is the deployment that failed.

In the task trace window scroll under the task list, through the task deployment trace text to see the error. In this case I have hilighted the error: There is no node of type IFL to deploy the integration flow to.

Change the type back to IFLMAP and deploy the integration flow.

This concludes the final instalment of the HCI First Steps series.