Cloud Integration has to be hands down one of the favorite offerings in the Integration Suite. Just the other day I was trying to perform a POC for a particular scenario and the way it fast forwards to the end product is simply fascinating. To top it up, I’d say the Product Team has put some real good thought behind how they want this product to be utilized and at the same time positioned a mechanism to extend the capabilities of Cloud Integration. How? You may ask… It’s via the Cloud Integration’s OData API. In this blog post I’ll take you through this less talked about feature (which we usually get to hear about during the Integration Suite Certification) while focusing majorly on Message Processing Logs and share a scenario where I leveraged it to automate a mundane process.

The Boring stuff

Just like any other API, the Cloud Integration OData API helps you perform some CRUD operations without having to make use of the Cloud Integration UI. Like any other API, of-course the leeway to perform these operations is tight, nonetheless there are still pretty powerful capabilities that can be leveraged such as Message monitoring, updating Integration Flow configurations, and lot many other things which I haven’t yet explored much on. You can get a glimpse of these capabilities in the official documentation.

Message Monitoring

I don’t know how many times I have used the Message Monitoring tool in Cloud Integration in order to debug what stupid mistake I made while building a new Integration Flow. Further it has helped in getting some insights about how many times during a span of timestamps a specific integration flow has been triggered by the integrated applications. In all, the Message Monitoring provided by Cloud Integration is itself a useful reporting tool if we use it the right way without having to build custom usage analytics in the integrated applications.

Message Monitoring UI

A Big Picture (The Picture itself is small but… 😁)

Last year my team and I had built a Fiori Application on BTP and integrated it with an Integration Flow developed on Cloud Integration. As the main functionality the Fiori Application used to take some inputs and in turn trigger an Integration Flow on a button press. The integration worked perfectly (and still does 😉).

Integration Context

After any successful go live, we do get some requirements. We too got some requirements and then stumbled upon a requirement to share Usage metrics of our Fiori Application. Like a noob that I am, I forgot to incorporate any kind of Usage metric keeping in the Fiori Application. In my defense I had not built a application from scratch for a long time. Of course there are ways to incorporate this kind of monitoring or logging with Firoi Apps but that requires additional development effort. And that’s when we improvised. We knew that the Cloud Integration’s Message Monitoring that can provide us good view about the usage metrics because what’s a better indicator of App usage than the triggering of the Integration Flow. EASY!!! We adjusted the timestamps, got the count of requests the IFlow received and viola. Task achieved ✅, right? Had it been so simple I wouldn’t have written this blog post.

The Struggle is Real

Now the expectation was that these Usage metrics need to be shared with a bigger group of people, on monthly basis, at start of each month (which included weekends – I am not complaining 👀) and this to be done by a person (me) who doesn’t remember what movie he watched just the other day, well you are set to fail.

Call for Help!

Automate, maybe?

This scenario cried for automation. This was one place where the theory I studied for my Integration Suite certification came in handy and I was able to apply it in a real life use case. I was (lowkey) really excited to come up with this solution.

One of the Cloud Integration OData APIs provide a resource to retrieve the Message Processing Logs data as well. These are the same Message monitoring logs that you see on the Cloud Integration UI.

How to: Enable OData API

Cloud Integration should be up and running on your tenant. Next, since the API access is under Access Control you need to do either of two things:

1. Assign the ‘MonitoringDataRead‘ to a User – Authentication type to be leveraged: Basic Authentication (UserID/Password)
2. Create a Service Key for Process Integration Runtime – Authentication type to be leveraged: OAuth 2.0 (Bearer Token)
   Oh btw, you can create the Service Key directly via Cloud Foundry CLI as well. You can follow this quick tutorial by Antonio Maradiaga

Based on what kind of a Auth mechanism you went ahead with, you’ll either need to use the User ID/User Password combo, or Client ID/Client Secret combo in conjunction with TokenURL which you got as part of the Service Key.

With either of these mechanisms you should be able to Invoke these APIs from any 3rd Party Tool such as Postman, Insomnia etc.

API Response Screenshot

API Endpoints for Message Processing Logs

• Get Message Processing Logs –
  • This provides the same data that you see in the Monitor Message Processing Tile in Cloud Integration
  • It provides the Message Processing Logs data in SOAP or JSON format
  • The format is decided based on the ‘Accept’ header sent as part of request
  • Given this is an OData API you can make use of already familiar query attributes including:
    • $filter
    • $count
    • $select
  • The API Response additionally provides location/URLs for other data linked with the Message processing Logs like Message Store, Custom Header Properties etc
  • Sample URL: https://<you-subtenant-base-path>/api/v1//MessageProcessingLogs/$count?$filter=IntegrationFlowName eq ‘EDI_Converter’ and LogStart gt datetime’2022-07-01T00:00:00′ and LogEnd lt datetime’2022-07-30T00:00:00′
    • <your-subtenant-base-path> would look something like: iambatman.cfapps.sap.hana.ondemand.com

• Get Custom Header Properties Endpoint – I found this particularly interesting
  • If your iFlow is using Message logging in script in order to log any incoming Custom Headers, you can get those details via this endpoint
  • Refer to Use Custom Header Properties to Search for Message Processing Logs for more details
  • It provides the Message Processing Logs data in SOAP or JSON format
  • The format is decided based on the ‘Accept’ header sent as part of request

That Inception moment

I had the API to retrieve the counts of number of times a Message was processed by the given IFlow. However there was still some more automation required, such as calling this API at a scheduled interval (start of each month) and send automated mails to the recipient list. But all that was fairly simple because I had Cloud Integration to take care of it which inherently called Cloud Integration OData API to get the usage counts. I did not have to put a lot of brain on how I needed to develop an integration flow. Almost all the components were provided OOTB by Cloud Integration. I just needed to plug these components together, provide configurations like security materials and my IFlow was up an running in no time.

The same Scenario – but Automated

Winding Up!

Extending the use case for Cloud Integration OData APIs can vary. The scenario that I showcased was something that made my life easier 😁. There can be other scenarios where in we:

• Can create Unified Dashboards for monitoring the different integrations scattered across different solutions (SAP CIG, On Prem Applications, 3rd Party integrations) – These solutions can prevent a lot f hassle of navigating through multiple applications, while at the same get the reporting needs fulfilled
• Can Automate mundane tasks
• Need proactive reporting

It’s the small things like this that truly makes a case for using offerings provided by BTP. From building an App to accommodating custom requirements and automating certain use cases, there are possibilities to do all that without writing custom logic from scratch and all that with a low-code/no-code approach. So that’s just the cherry on top.

Have you used the Cloud Integration OData APIs? Tell me about it by dropping a comment down below and share the use cases what and how these APIs helped you achieve. You can ask your questions in the comments section or reach out to the amazing SAP Community.