Skip to Content
Technical Articles
Author's profile photo Madhubala Chandran

SAP Cloud Platform Integration- How to capture interface run count in header using Message Monitoring Using oAuth authentication.

Introduction:

This blog post explains, how to capture successful/error run count of the interface in header of the file.

In some scenarios, we need to capture the successful or failed status of an interface and send it to any downstream applications. So this blog post will explain the simplest way to implement it.

Below is the simple iflow shown in this blog and this may varies based on the requirement:

Iflow

This is the overall iflow looks like and this could be called as sub flow in any of the interface to capture the status.

Use OData adapter which support the “MessageProcessingLog” resource path.

Connection

Under connection tab use Oauth credentials or client certificate. Basic authentication will also work however the user and password will be changing based on the environment so recommended option is to use a common user and password like (Oauth credentials or client certificate)

In Address use your tenant url followed by /api/v1 like below

https://tenant. …….com/api/v1

 

Deploy the oauth token url , client Id and secret id from the cockpit in Manage Security Material

Processing:

Under processing tab follow the below steps

  • Operation Details: Get
  • Resource path: MessageProcessingLogs – Which will fetch all the status from the Monitor
  • Query Option: In query option Select the required field (OriginComponentName, LocalComponentName ,CustomStatus, ,Status,IntegrationFlowName,LogEnd, LogStart , &$filter=(Status eq ‘COMPLETED’ or ‘Failed’) and (IntegrationFlowName eq ‘Your iflow name- Here’)
  • And any logstart and logend date and time could also be used in the filter criteria to capture the status depends on any particular time period

Use content modifier to capture the count by using simple expression “Count” and the xpath of the status as shown below

“count(/MessageProcessingLogs/MessageProcessingLog/Status)”

And call this property in the end of the iflow

Output

Conclusion:

This is one of the simplest ways of capturing run count of an iflow and this could be used or customized based on your requirements. And this blog post helps ,who are not, much familiar with scripts.

Assigned Tags

      5 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Gautham Ulaganathan
      Gautham Ulaganathan

      Keep going Madhu !!

      Informative one

      Author's profile photo Mounika Ravilla
      Mounika Ravilla

      Nice Blog Madhu
      Very detailed and simple.

      Hoping for more blogs

      Good Job!!

      Author's profile photo Saurabh Kabra
      Saurabh Kabra

      Very nice blog Madhu.

      BTW...You can avoid the last "Content Modifier" step to calculate the "Count" of the records. Instead, CPI OData already exposes $count as well as $inlinecount(see Documentation) which can give you the number of record count as part of OData resposne.

      For e.g. in you case when you want to retrieve the MessageProcessingLogs count then you can simply call:

      https://<HostName>/api/v1/MessageProcessingLogs?$inlinecount=allpages&$select=MessageGuid,IntegrationFlowName&$top=1

      Author's profile photo Madhubala Chandran
      Madhubala Chandran
      Blog Post Author

      Hi Saurabh ,

      Thanks for sharing this , but my requirement was just to calculate the deployed count of the interface not the total count .

      But what you shared was useful 🙂

      Author's profile photo Saurabh Kabra
      Saurabh Kabra

      Hello Madhu,

      But even then you can still use "$filter". Basically using $inlinecount gives you the count of records _after applying the filter_. Let say an odata entity without filter returns 10 records but with a certain filter only 5 then $inlinecoun will return 10 and 5 in the respective use case. Hence it is very effective and reduces the complexity. Further, you need to keep in mind such operations on Content Modifier could be quite a performance intensive so use it wisely.

      e.g. https://<host>/api/v1/MessageProcessingLogs?$filter=LogStart%20gt%20datetime%272021-11-02T13:33:24%27&$inlinecount=allpages&$select=MessageGuid,IntegrationFlowName,Status

       

      But, of course, it also depends sometimes on the business case to the business case.