
I) Introduction:
While there are already many blogs online about message monitoring reports in the SAP Integration Suite, I want to add my own perspective and share some useful files for developers. In today's world, Artificial Intelligence models (such as Gemini and ChatGPT) and automation are becoming important everywhere, even in SAP.
Have you ever found yourself in need of checking a daily transactional report at your enterprise business? With the SAP Integration Suite, there's a handy tool called message monitoring for just that. However, here's the snag: after a while, the transaction seems to disappear. Many companies desire these reports emailed (for logs) and seek suggestions for failed messages, especially in cases of failed transactions.
Picture this: you rely on these reports, but they mysteriously vanish. Frustrating, isn't it? Well, fear not! Artificial Intelligence (AI) and Integration Suite (IS)-API have the solution. They detect transaction issues and offer solutions, alleviating your time and stress burdens.
In this blog, we'll explore how we can revolutionize SAP Integration Suite reports, making your job simpler and more efficient. Let's dive in!
II) Agenda:
III) Cost Background: Explaining the Financial Aspect
While SAP offers a multitude of features including HANADB with Fiori screen report, ALM, SAC, and analytic tools, it's important to note that the solution discussed here is a zero-cost option for accessing reports via email. The only scenario where additional expenses may arise is if AI suggestions are required for productive use. Apart from that, the daily report functionality is completely free of charge when utilizing the solution outlined below.
IV) Overview: Exploring the Background Story
Imagine Tamil Selvan, a newly hired SAP Analyst at XYZ organization. One of Tamil's primary responsibilities is to compile and send a daily report of failed transactions to the relevant teams. Each morning at 8 AM, Tamil diligently logs into the SAP Integration Suite to review the list of failed and escalated messages. He then meticulously copies these details into Excel tables, which he shares with the technical team for investigation. Concurrently, the Application Management Services (AMS) team logs a ticket for further action.
This daily routine consumes a significant amount of Tamil's time, typically ranging from 1 to 1.5 hours. Extrapolating this across a week, Tamil spends approximately 7 to 10.5 hours dedicated solely to this task. Over the course of a year, this translates to a staggering 336 to 504 hours invested in creating these reports.
TimeFrame | TimeSpentPerDay | TimeSpentPerWeek | TimeSpentPerYear |
Daily | 1 - 1.5 hours |
|
|
Weekly |
| 7 - 10.5 hours |
|
Yearly |
|
| 336 - 504 hours |
Considering the broader perspective, Tamil's annual commitment to generating these reports amounts to nearly two months of full-time work for individual client. Additionally, this is merely the initial step in addressing the identified issues. Following the report creation, the support team invests another 30+ days in diagnosing the problems and implementing solutions, often requiring additional iterations.
This inefficiency is striking; Tamil alone dedicates nearly 48 days per year solely to report creation, not including the subsequent resolution efforts by the support team. It's evident that the current process is time-consuming and resource-intensive, highlighting the urgent need for optimization.
The forthcoming blog aims to revolutionize these workflows, promising to enhance efficiency by over 98%. By implementing the proposed improvements for automation iFlow, the number of days spent on these tasks will be drastically reduced to Zero days, providing much-needed support to consultants, and expediting issue resolution processes.
V) Technical Architecture Diagram: Visualizing the System Design
VI) Technical Implementation: Step-by-Step Integration Details
Before proceeding, please ensure the following prerequisites are met:
Step 1: Establishing an Integration Package with Proper Naming Conventions, Followed by iFlow Creation within the Artifacts.
Step 2:
Step two has been divided into three sections, each detailed below:
Section-A: Setting the Parameters, Creating the Queries, and Calling the APIs
Configure the parameters mentioned above in the content modifier. These parameters serve as the initial declarations for the iFlow properties, which will be utilized in later stages within the Groovy scripts.
The Groovy script above enhances the query to filter statuses such as failed or escalated. Additionally, it incorporates a manual flag check. For instance, if the manual flag is set to true, the configured value in the iFlow will be used. Conversely, if the manual load flag is set to false, the script will utilize the last successful runtime to retrieve results from the Integration Suite API.
Utilize the message processing log API to retrieve the pertinent response from the Integration Suite for escalated and failed messages. Refer this link: https://api.sap.com/api/MessageProcessingLogs/resource/Logs
Section-B: Establishing Conditions to Determine the Response Route
Verify whether the inbound response contains valid records. If the record count is valid, proceed with further actions. Otherwise, transition it to a completed state with a marker indicating zero records.
Section-C: Iterating Through the Responses
One of the notable features in the SAP Integration Suite is the Iteration Splitter (IS), which allows us to iterate through messages and obtain their respective IDs. These IDs can then be used to query additional APIs within the Integration Suite using exchange parameters and the XPATH mechanism. Below is an example where we capture the messageGuid to fetch more details from subsequent APIs within the Integration Suite.
Step-3:
Step three is divided into three sections, outlined as follows:
Section-D: Utilizing the messageGUID to retrieve the relevant message details.
Utilizing the OData protocol to retrieve pertinent details from the Integration Suite server involves accessing artifact information and transaction status. This includes identifying the iFlow name and message GUID, aiding developers in locating transactions within the message monitoring dashboard.
Section-E: Employing the messageGUID to retrieve the relevant error message from another API.
Ensure to utilize the HTTP protocol when accessing error message details through the SAP API, as it currently supports the HTTP protocol for this purpose. While it's possible that this method may transition to being embedded within OData entities in the future, for now, HTTP remains the preferred protocol.
Store the returned message in the "error" property, as indicated above. The subsequent step involves utilizing this property value in the AI models to generate the response.
Section-F: Leveraging Artificial Intelligence (AI) to receive suggestions for errors.
In this section, we leverage the openAI models to provide suggestions for the errors encountered in the systems.
Utilize the provided script to capture the AI-suggested response and store it in a property named "openAIResponse."
Store the AI response in the “AISuggessionForError” property in the content modifier. And set the below XML format in the Content modified body
The XML payload resulting from message processing will be merged with the original payload, facilitating the creation of a consolidated report. This report, presented in a table format, enhances the readability and presentation of the details for email recipients.
Step-4:
Step four is subdivided into two sections, each outlined as follows:
Section G: Gather the response, and execute message mapping.
In this section, we are gathering the responses from the respective sources. Since we are utilizing iteration splitter and multicasting, we have collected and halted the loop by employing a gather functionality.
During this gathering process, additional components may be added, which may not be suitable for message mapping. Therefore, we are using a Groovy Script to remove the unwanted headers using Groovy to remove multi tag script.
With the message mapping described above, the consolidated report has been formatted in a manner suitable for HTML. This formatted report includes tables, headers, and relevant information, providing a detailed and beautified result set.
Section H: Generate HTML content for report creation and initiate email dispatch.
Creating an HTML table response with Groovy to include transaction errors, iFlow names, AI suggestions, and job details.
The HTML content is delivered via the mail adapter from the Integration Suite, providing automated daily reports for failed and escalated transactions, along with Artificial Intelligence (AI) suggestions.
Step-5:
The program automatically generates an email containing details of the report, including failed and escalated transactions. Additionally, it provides solutions for the failed transactions within the report, facilitated by AI.
If you find this information helpful, please consider clicking the "Like" button on this blog and sharing your thoughts in the comments section below. You can also connect with the author on their LinkedIn profile: [Author's LinkedIn Profile]
VII) Conclusion: Reflecting on the Key Takeaways and Future Directions
VIII) Additional Resources: Providing Research Material Links for Further Exploration
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
11 | |
10 | |
9 | |
7 | |
5 | |
4 | |
4 | |
4 | |
3 | |
3 |