This blog describes how to configure a scenario where an generic Iflow can be used to handle exceptions sent from all the Iflows in the tenant. And this is mainly applicable if you have lot of Iflows running in the tenant as defining exception in each iflow will be take more time.

Please note standard package from SAP is available to get an alert email. But this blog will help you develop a exception handling strategy which can be used in each Release phase.

Designing the Generic Exception Handling Iflow.

So, what functionalities would be like from an exception sub process ?

Get a email notification and get the incoming payload as attachment (only where monitoring team can have access to payload) ?

Store the payload ?

Let’s start with these basic requirements. The below is the design.

This gives us granular control over handling strategy. As we can have two sender adapter HTTP and process direct.

As any message processed in a Iflow will have new messageID generated, the generic iflow will new messageID. So, the original iflow where the error occurred will have to be propagated to this iflow via message headed as shown below.

These headers will be used to reset the message body with error details. And the flags are used to route the message in the generic exception handling iflow.

If storemsg is set to True, store the message in datastore or persistent store.

If sendEmail is set to True, then the email notification is send with the details. This should be used when the iflow is in hyper-care phase as CPI standard alert iflow will send overall report of the tenant.

If sendBody is set to True ,send the original payload as the attachment of email.

Note: sendBody shall be used only where the payload dose not contain sensitive data.

Email adapter configuration can be as below.

This iflow can not be used even in the hyper-care phase if the frequency of the iflow messages are more. So for this use case build a iflow which runs on schedule and reads the data from data store which has error details.

Here, The IflowList is name of the iflow’s data stores more the one should be added using a separator. This should be looped and sent via email. Again this iflow should be used for only high frequency message flows.

However, The main iflow where the exception is stored in Data store can be orchestrated as shown below.

If data started is has data that should be edited, if the data store has no data then it should be added and written to data store.

Note: The content modifier can be replaced with script step to handle complex data.

This is an iflow which is built based on the standard iflow of SAP CPI. The only chnage is last step where one cloud add a script to get an HTML encoded Email. This can be used in case when SAP Cloud Platform Alert Notification is not activated.

The script creates a HTML page which is then encoded to email. Sample output would be something like below.

Conclusion

There is no one way to handle the exceptions it will always dependent on the business flow. But the above two ifows in combination of alerts CPI standard iflow suffice for most situations. The above is just an idea which can be improved or changed according to needs. But , this is very important when iflow development for large implementation.