Technical Articles
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.
Keep going Madhu !!
Informative one
Nice Blog Madhu
Very detailed and simple.
Hoping for more blogs
Good Job!!
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
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 🙂
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.