Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
Showing results for 
Search instead for 
Did you mean: 

Hello SAP Community,

I am Dhinesh Kumar, working as Integration consultant with SAI Digital (
In this blog series, I shall be sharing my interesting experience of building consolidated error email notifications – Integration Package wise using the SAP Cloud Integration APIs.

SAP Integration suite already offers a great feature for monitoring the messages processed in the tenant.
It offers various filtering options to ensure easy monitoring.

But to ensure a smooth project support, it’s always recommended to trigger email alerts in case of any errors occurs during message processing.

There are numerous blogs available in “ “on how we can implement email alert notification with details of that particular failed message.

The above mentioned alerting mechanism would trigger an alert for every instance of failed message processing.

In this blog , I would explain how to build an Iflow that produces an error notification consolidated respective integration package wise with an URL included to list all the failures occurred in a specific time interval.

Below is the sample Alert notification produced using our Iflow

Clicking on the “CLICK_FOR_MONITORING_UI_ERROR_RECORDS” and “CLICK_FOR_MONITORING_UI_ABANDONED_RECORDS” will navigate to your respective SAP CPI monitoring view displaying the list of failures for the respective Iflows


The below are list of pre-requisites to be done before we start building the Iflow.

1) If your Cloud Integration instance is on Cloud Foundry environment, follow below documentation for generating a service key to be used for consuming SAP Cloud integration APIs


2) If your Cloud Integration instance is on NEO environment, follow below documentation for registering an OAUTH Client

3)Create an OAuth2 Client Credentials artifact in “Manage Security Material” view in your SAP Cloud Integration tenant.



SAP Cloud Integration APIs :

Design Requirement:

Our Customer team requested consolidated error alerts for specific set of integration Packages.
Emails should be triggered only if there are failures for Iflows in the specific set of integration Packages.


Solution Overview:

I have implemented the solution in NEO environment. The design has 2 Iflows.

#1) The Iflow 1 runs on a specific time and has list of respective package Id details listed in an XML.
Uses splitter and sends each Package Id to Iflow 2.

#2) The Iflow 2 uses the respective Integration Package ID and executes the below operations, retrieves message processing details for a specific interval.

1) Retrieves list of Iflows in the package.

2)Iterates each Iflow entry.

3) Uses Iflow Id fetches the count of total executions.

4) Uses Iflow Id, fetches the count of successful executions.

5) Uses Iflow Id, fetches the count of failed executions.

6)Executes mapping.

7) Checks if the failure count for at least one entry (Iflow) is more than 0.

8)If ‘7’ is Yes, sends an email else stop iFlow execution.


In this Iflow, I have used the below steps

STEP 1) Timer: To execute every 1 hour. <configure it as per your requirement>

STEP 2) SET PARAM: A Content Modifier with an exchange property ‘CPI_ALERT_CONSOLIDATE_LSR’ to store the current date time in the format ‘yyyy-MM-dd'T'HH:mm:ss.SSS’ . Expression used: ${date:now:yyyy-MM-dd'T'HH:mm:ss.SSS}

STEP 3) Package IDs: A Content modifier with the list of Package Ids in the below xml format for which we need the consolidated report to be triggered via email.









STEP 4) SPLIT PACKAGE WISE: A general splitter used to iterate each “SET” node in the above xml and send as an individual message to IFLOW 2

Step 4) Process Direct adapter to call the IFLOW 2.

Step 5) Write Variable step to store the last successful run date time as a global variable. <This value will be used by Iflow 2 in the API GET calls >


STEP 1: “Process Direct” sender adapter to receive the Package ID details as XML from IFLOW 1







STEP 2:  “ContentModifier to retain certain parameters in the exchange property

Parameter table :

Parameter name value to be used
INT_PACKAGE Package ID as received from IFLOW 1
SCPI_URL https://<TENANT_tmn>/itspaces/shell/monitoring/Messages/
INT_TO Current date Time: ${date-with-timezone:now:Etc/GMT:yyyy-MM-dd'T'HH:mm:ss'Z'}
FROM Last Successful,value retained from Global Variable: " CPI_ALERT_CONSOLIDATE_LSR " ,created/updated by IFLOW 1


STEP 3: “Local Process call”-Used to call a local process “GET IFLOW ARTIFACT LIST” to get the list of Iflows in the respective package (Package-id retained in property ‘INT_PACKAGE’).

The http request makes a GET call to the below URL to get the list of “IFLOW Id” and “IFLOW Name” of Iflows in the Integration Package

https://<TMN_URL>/api/v1/IntegrationPackages('<Integration_Package_ID>’)/ IntegrationDesigntimeArtifacts? $select=Id,Name

STEP 4: “SPLIT IFLOWS” – A General Splitter to split the xml entries to have each IFLOW details.

STEP 5 : “Retrieve IFLOW ID” – A Content Modifier to retrieve the IFLOW_ID and IFLOW_NAME in the exchange parameter.

STEP 6 :  A local Process call to retrieve Total, Successful, Failed and Abandoned message count of each Iflow.

http request for each case :


Total: https://<Tenant_Management_URL>/api/v1/MessageProcessingLogs/$count?$filter=IntegrationFlowName eq '${property.IFLOW_ID}' and LogEnd ge datetime'${property.FROM}'

Failed: https://<Tenant_Management_URL>/api/v1/MessageProcessingLogs/$count?$filter=IntegrationFlowName eq '${property.IFLOW_ID}' and Status eq 'FAILED' and LogEnd ge datetime'${property.FROM}'

Success: https://<Tenant_Management_URL>/api/v1/MessageProcessingLogs/$count?$filter=IntegrationFlowName eq '${property.IFLOW_ID}' and Status eq ' COMPLETED ' and LogEnd ge datetime'${property.FROM}'

Abandoned: https://<Tenant_Management_URL>/api/v1/MessageProcessingLogs/$count?$filter=IntegrationFlowName eq '${property.IFLOW_ID}' and Status eq ' ABANDONED ' and LogEnd ge datetime'${property.FROM}'


STEP 7: A Gather step to combine the results for all the Iflows .

STEP 8 and STEP 9 :
Filter and Content Modifier steps to format the combined xml data.

STEP 10 :
Message Mapping step to format the XML data as a HTML table.

STEP 11:
Groovy Script to inspect the MessageMapping output , identifies if the count for Failed or Abandoned entries are higher than ‘0’ for any of the IFLOWS in the package .
If Yes, Sets Property “Failure_Found” as “true”.


STEP 12:
Conditional Router step to check if the property “Failure_Found” is “true” .
If true, proceeds to Sends Email else ends message processing.

STEP 13 AND 14 :
Content Filter and Content Modifier steps to format ,produce final email content with details.

STEP 15,16 :
“Send ” Configured with Receiver Email Adapter.

Email Adapter configs for reference :

You can download the Integration Package from the below git repo

To configure click on “Configure” in the respective iflows and fill in the Parameters.



In summary, these IFlows can be used to generate consolidated email notifications for specific integration package errors.

If you need this to be implemented for all the integration packages in your tenant, you can explore the option of using the API-
"" in iFlow-1, as mentioned in this blog, instead of hard-coding the integration package IDs.

Please feel free to download and experiment with the iFlow uploaded in the Git repository and provide your valuable suggestions for any design improvements.

Thanks ,

Dhinesh Kumar R.
Labels in this area