Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
Paul_todd
Product and Topic Expert
Product and Topic Expert
2,655

In the previous installment Building your first iFlow - Part 6: Identifying issues tracing was used to see how the HCI engine processed data at each step of the integation process. This yielded very good insights as to what data was being received by the process step and what data was being sent to the next step.


If you followed the previous tutorial steps the call to get the weather would sometimes fail. The trace log would not show anything but by looking at the message monitoring log the failure can be seen. This is something that needs to be fixed, both in the scenario and in other real world integrations.

As above the error code is 401. If the same request is run through a REST client then a little bit more information is revealed. This will say that the application id key is missing. Whilst it is trivial to fix this by applying for a free key at http://openweathermap.org/appid#get a much better solution is to handle the error in the integration. This is what the topic of this post is about.

Our existing integration looks like the following:

At a specified time the service calls the open weather API and then extracts properties from the XML using XPath to send and email to a specified email address via GMail.

For the remainder of this post the Exception subprocess will need to be added. The sub process will handle any exceptions generated by this iFlow. This is useful since it will be invoked when the RequestReply task fails. Click on the command palette on the right and choose the “Exception SubProcess” element under the “Others” section.

This sub process may only be added to an integration so now go ahead and add the exception sub process to the integration process as below.

You will probably need to adjust the layouts as I have done to make the flow look decent.

It is important to note that the exception sub process actually ends with a message end event. This is the event that will be extended to send an email to the same message service that the weather report is being sent to. However before the exception can be handled there is some additional processing that needs to be done. To accomplish this a process call needs to be added to the exception subprocess. This will take the message in the sub process and do further processing on it. In this case the exception will be extracted together with the HTTP status and error message.

Next create a new local integration. This integration’s role will be to extract the HTTP status and error from the exception and put them in a header that can be used by the caller.

The new local integration process is also renamed to “Extract_Error_Process” to descriptively name the function of this local integration process.

In this process a new script step will be added to process the exception and extract the fields needed from the exception.

Firstly a folder called "script" needs to be created under the WeatherReport.src.main.resources folder. Using the File|New..|Other… command, expand the “General” node and choose “Folder"

Click the “next” button and choose the folder

Expand the nodes under weather report by selecting “src” then “main” then “resources” and then entering the name “script” for the folder name in the edit control

Click “finish” and the folder will be created

Without the script folder a new script will not be able to be added using the script element.

Going back the integration select the “Script” element from the “Message Transformers” panel and add it to the "Extract_Error_Process" integration.

Right click over the “Script” element and choose “New Script"

If you did not create the folder in the previous step you will be unable to create the script file and an error will be displayed at the top of the dialog.

However we did create the folder so a script can be now created. The script will be named “parseerror.gsh”.

Click “Finish” and the “parsererror.gsh" file will be added to the scripts folder and also opened.

Delete the contents of “parserror.gsh” and replace it with the script below. This default script had a single method “processData” which takes a message. This message object can be altered according to the comments at the top of the script file.

import com.sap.gateway.ip.core.customdev.util.Message;
import java.util.HashMap;

def Message processData(Message message) {
 
   def map = message.getProperties();
   def ex = map.get("CamelExceptionCaught");
  
  
    if (ex!=null) {
def body = message.getBody();
message.setBody(ex.getResponseBody());

//Headers
message.setHeader("STATUS_CODE", ex.getStatusCode());
message.setHeader("STATUS_TEXT", ex.getStatusText());

    }

      
return message;

}

This script extracts the “CamelExceptionCaught” element from the message and then extracts the status code and status text from the exception message.

To the message the following headers are added, STATUS_CODE and STATUS_TEXT, both of which are useful when creating our error message email when an error is thrown.

A useful tip is that if the groovy plugins are installed in your eclipse environment, then right clicking over the file in the Project Explorer and selecting “Other…” from the “Open With” command will display a list of editors of which one will be the groovy editor.

Click “OK” and the “parseerror.gsh" file will be opened with the groovy editor rather than the default text editor. The groovy editor will give syntax hilighting amongst other features.

Save the file and close the editor window.

Select the “Script” node in the “Extract_Error_Process” and verify that indeed the script associated with this step is the “parseerror.gsh” file.

This completes the setup for parsing the status code and the error message from the exception. The message will now contain two new header fields for the HTTP Status Code and the HTTP Status message. Finally we are going to send these to the email channel in the subprocess exception handler.

Goto the Exception subprocess created earlier and add a new sender component and a channel from the “End Event” of the exception Sub-process to the sender end point.

Right click over the Channel and choose “Configure Channel"

Select the email adapter and optionally add a name and a description for the general channel settings.

Click on the “Adapter Specific” tab and fill in the values identically to the step previously where the channel was configured to deliver the report.

Address: smtp.gmail.com:587

Authentication: Plain Username/Password

Credential Name: HCI WeatherReport Credentials

From: <your gmail address>

To: <your gmail address>

Subject: Weather Error: ${header.STATUS_CODE} ${header.STATUS_TEXT}

Body: $(in.text}

Change back to the “Model Configuration” and rename the sender component to “sendError” so the name does not clash with the existing sender.

Also the "Process Call" needs to be linked to the local integration. Click on the “Process Call” node in the “Exception Subprocess” block and in the properties click the “Browse…” button and choose an integration, in this case it is “Extract_Error_Process"

Click “OK” and save the changes for the integration

Click on the lined drawing board, right click and select “Execute Checks” to ensure the integration flow is correctly.

Again right clicking on the drawing board and selecting  “Deploy Integration Content” will deploy and execute the integration flow. If you have built the package correctly then a message will be delivered to your inbox showing the error code and the error message in the subject as was configured in the email channel. The body will display the text of the error received from the openweathermap web site.

This concludes how to enable error handling in an integration so errors can be dealt with appropriately and integrated into the flow of the message processing.