SAP Community - SAP Integration Strategy

SAP Business AI Testing = SAP API Testing

2024-10-01T11:56:36.576000+02:00

Introduction - why testing APIs is important for SAP Business AI

When we talk about SAP Business AI in business we need to remember one thing: AI cannot work without APIs. In fact, testing SAP Business AI is all about testing how well APIs work. Let’s break down why this is so important.

Figure 1 - generative AI cannot do any business activity without SAP APIs

Only AI powered Chatbots in SAP Business AI?

SAP Business AI has a potential to eliminate all frontend applications (SAP GUI, Fiori and all other front end applications) and leave only chatbots (Joule, Copilot, etc.) to work with all SAP business functions of SAP S/4HANA. This might mean that all business functions will be exposed via APIs.

Figure 2 - SAP Gui - sailing away into the past

Why APIs Are Important for SAP Business AI

APIs (Application Programming Interfaces) are like bridges that let different programs talk to each other. AI, especially advanced AI like generative AI, needs APIs to get information and connect with other systems. Without these connections, AI can't do much.

Integration is the backbone of digital transformations, and APIs are the building blocks for every SAP customer who sells, buys, or transports their products. This means APIs are the key to making all of a company’s systems work together. For AI, APIs are what allow it to be part of that big picture.

How APIs Help SAP Business AI Work

Think of AI like a chef who needs ingredients to make a meal. The API is the helper that brings those ingredients to the kitchen. Without it, the chef (AI) can’t do their job. Here’s how APIs help AI:

Getting Data: AI needs a lot of information to make smart decisions. APIs bring that data from different places to the AI.
Executing Business Activities: To do any business task—like creating an order, delivering goods, or managing inventory—AI needs to use APIs to make things happen. For example, if AI is asked to create a new sales order, it has to send a request through an API to the system that manages orders. Without APIs, AI wouldn’t be able to carry out any business activities.
Building New Solutions: APIs allow businesses to create new smart tools by connecting AI with existing software, kind of like mixing different ingredients to create a new recipe.

Figure 3 - SAP API Testing with Int4 Suite = SAP Business AI testing

How does SAP Business AI execute business activities on SAP S/4HANA

SAP has many ways to expose it’s SAP S/4HANA and their use depends on the context:

SAP APIs (Webservices, ODATA, etc.) can be exposed directly from SAP S/4HANA. Some typical ways include generating web services or ODATA interfaces.
In order to manage APIs exposed by SAP S/4HANA some other components might be used like SAP BTP API Management (part of SAP Integration Suite) and those APIs can also be exposed by SAP Business Accelerator Hub – https://api.sap.com
In most cases however SAP APIs are build and designed using SAP Integration Suite. SAP Integration Suite is the go to solution for building the SAP S/4HANA Clean Core side by side extensions which include building and orchestrating complex integration scenarios and exposing them to the outside world (to SAP Business AI, Joule, Copilots, etc.)

Why Testing SAP Business AI = Testing SAP APIs

Since APIs are so important to AI, testing SAP Business AI is really about testing how well the APIs work. If the APIs don’t work right, the AI won’t either. Here are some key things to check when testing APIs:

Getting and Posting the Right Data: Making sure the API sends the right information to the AI, so it can make the best decisions and making sure that APIs exposed to AI are working as they we designed
Working Together: Testing if AI and other SAP systems can communicate smoothly through APIs.
Speed and Performance: Ensuring the APIs work quickly and don’t slow down the AI’s responses.

In short, AI can’t exist without APIs. And in SAP systems, this connection is even more important because everything is linked together through APIs. So, if you're testing SAP Business AI, you're really testing the APIs that make it all possible.

Further Reference

Learn how to test SAP APIs with Int4 Suite - Avoid SAP S/4HANA Project Delays with Third-Party Systems Service Virtualization

What is Composable Architecture?

2024-10-06T14:20:39.714000+02:00

So, what is Composable Business Architecture? Is this yet another "buzzword", or this is genuine approach to the Enterprise Architecture, Gartner is talking about[1]?

How is this related with Decoupled Integration (Architecture)?

And how is all this related with Event-Driven Architecture?

My 2 cents…

It’s a kind of buzzword, yes, not necessarily Gartner invented it – but it is meaningful one, to be honest….

Gartner talks about Composable Business (Architecture) in fact[1] – listing 4 main principles:

More speed through discovery
Greater agility through modularity
Better leadership through orchestration
Resilience through autonomy

If we go deeper – in the essence, it’s about (Architecture) building blocks supporting different business operations – which are connected seamlessly with each other. Of course, blocks are replaceable by other blocks (i.e. other products) supporting the same business operations or extending it. Actually, one may say nothing new that TOGAF is already not teaching us to do, as part of ADM[2]…

Sounds good? Well, maybe I am over-simplifying – but this is basically it...

We are talking about (Architecture) building blocks, which are not just built in any "best fit" style, but built in such a way to support agility, flexibility and resilience… And this is the main differentiator (and the main benefit, as well) of the modern Compossible Business (Architecture).

Clearly, Decoupled Integration (Architecture) is an enabling layer for the Composable Architecture. To put this in a very simple words (again), integrating via middleware and using API/Event Portal(s) is just must. What kind of "flexibility" would it be, if we would design P2P integrations between 2 building blocks? Probably none...

So, is Event-Driven Architecture answer to all?

Well, not really.

Event-Driven Architecture (EDA) is indeed one of the key Integration Styles providing Decoupled Integration. EDA, in its core, is built to be “decoupled”, but it is primarily executed asynchronously – although we are more and more talking about (near) real time integration as well[3] (I do strongly recommend this article in Solace from Bruno Baloi - pls note, when we talk about Solace PubSub+, we are also talking about SAP Integration Suite, advanced event mesh)

Fully synchronous integration, like REST or OData APIs can also be built through integration middleware (i.e. SAP Integration Suite incl. API Management) – let’s use Omni-channel integration as an example – where multiple commerce channels through the integration middleware are taking (in both synchronous and asynchronous fashion) orders on the same backend[4][5].

EDA is a key substance of the modern Decoupled Integration (Architecture) and thus of the Compossible Business (Architecture) – but we are not limited to EDA only… We should not abandon other good patterns[6] – as not one size fits all...

Final…

Those are my 2 cents…

Of course, would be glad to hear other thoughts as well…

In my next article(s) I will try to talk more about some practical examples (Events, APIs) and how those are addressing 4 principles of the modern Compossible Business.

Acknowledgment

*) Intro photo by Ryan Quintal on Unsplash

References

[1] The Future of Business Is Composable - Gartner Keynote

[2] Introduction to the ADM (opengroup.org)

[3] Why it's Time to Event Enable your Integration | Solace

[4] Building Integration Architecture for the Omni-cha... - SAP Community

[5] Part 3: Next steps in building the Integration Arc... - SAP Community

[6] Agile EA - from SOA to Interoperability - SAP Community

Comparison of Users from SuccessFactors(odata) and Custom MDF using SAP CPI/CI

2024-10-29T12:28:08.968000+01:00

Introduction:

This article is a deep dive into a detailed comparison of payloads from SAP SuccessFactors OData and Custom MDF in this insightful article. We’ll break down the structure, key attributes, and data elements of both payloads, highlighting their unique strengths and how they can be effectively utilized. Join us as we explore practical examples and outputs that demonstrate the integration capabilities and optimize your HR processes!

Overview:

Scenerio/Requirement:

We need to retrieve user IDs based on country groups from SAP SuccessFactors (SF) and cross-reference these with data in Custom MDF. The objective is to query the specified country groups in SF to obtain the relevant user IDs and then identify any users who have been removed from these country groups in SF as compared to the entries in MDF. This process is crucial for maintaining accurate and up-to-date user records, ensuring data integrity, and to find exact which user ids are removed from that group.

What we do in this blog/article:

In SAP CPI implementation scenarios, the comparative analysis of input payloads is essential for optimizing data and message flows. This blog explores a detailed examination of two XML payloads. Regardless of whether these payloads exhibit distinct structures or align closely, our primary objective is to identify and highlight data changes between the payloads and find removed users from the groups.

Solution:

This below solution is just an example and please change the solutioning accordingly to your requirement.

Lets initially query data for users from SF Odata where you filter the data based on group country = 'India'

For example when you query:

SF_Payload:

<?xml version="1.0" encoding="UTF-8"?>
<JobRequisition>
	<JobRequisitionOperator>
		<jobReqId/>
		<usersSysId>User1</usersSysId>
		<operatorRole>T</operatorRole>
	</JobRequisitionOperator>
	<JobRequisitionOperator>
		<jobReqId/>
		<usersSysId>User2</usersSysId>
		<operatorRole>T</operatorRole>
	</JobRequisitionOperator>
	<JobRequisitionOperator>
		<jobReqId/>
		<usersSysId>User3</usersSysId>
		<operatorRole>T</operatorRole>
	</JobRequisitionOperator>
	<JobRequisitionOperator>
		<jobReqId/>
		<usersSysId>User4</usersSysId>
		<operatorRole>T</operatorRole>
	</JobRequisitionOperator>
	<JobRequisitionOperator>
		<jobReqId/>
		<usersSysId>User5</usersSysId>
		<operatorRole>T</operatorRole>
	</JobRequisitionOperator>
	<JobRequisitionOperator>
		<jobReqId/>
		<usersSysId>User6</usersSysId>
		<operatorRole>T</operatorRole>
	</JobRequisitionOperator>
</JobRequisition>

Store the incoming payload from SF using property with "SF_payload" for future use.

In the next step, you are querying custom MDF object with the country = 'India' and you may have some sets of data.

Lets consider MDF Payload:

<?xml version="1.0" encoding="UTF-8"?>
<JobRequisition>
	<JobRequisitionOperator>
		<jobReqId/>
		<usersSysId>User8</usersSysId>
		<operatorRole>T</operatorRole>
	</JobRequisitionOperator>
	<JobRequisitionOperator>
		<jobReqId/>
		<usersSysId>User2</usersSysId>
		<operatorRole>T</operatorRole>
	</JobRequisitionOperator>
	<JobRequisitionOperator>
		<jobReqId/>
		<usersSysId>User3</usersSysId>
		<operatorRole>T</operatorRole>
	</JobRequisitionOperator>
	<JobRequisitionOperator>
		<jobReqId/>
		<usersSysId>User4</usersSysId>
		<operatorRole>T</operatorRole>
	</JobRequisitionOperator>
	<JobRequisitionOperator>
		<jobReqId/>
		<usersSysId>User7</usersSysId>
		<operatorRole>T</operatorRole>
	</JobRequisitionOperator>
	<JobRequisitionOperator>
		<jobReqId/>
		<usersSysId>User9</usersSysId>
		<operatorRole>T</operatorRole>
	</JobRequisitionOperator>
</JobRequisition>

And, store the incoming payload from SF using property with "MDF_payload" for future use.

Now we want to find the users that has been removed from SF_Payload where this data can be sent to functional team for their business purposes.

Groovy:

import com.sap.gateway.ip.core.customdev.util.Message;
import java.util.HashSet;
import java.io.ByteArrayInputStream;
import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.parsers.DocumentBuilder;
import org.w3c.dom.Document;
import org.w3c.dom.NodeList;
import org.w3c.dom.Node;
import org.w3c.dom.Element;
import javax.xml.transform.Transformer;
import javax.xml.transform.TransformerFactory;
import javax.xml.transform.dom.DOMSource;
import javax.xml.transform.stream.StreamResult;
import java.io.StringWriter;

def Message processData(Message message) {
    // Retrieve payloads from properties
    def wfPayload = message.getProperty('SF_payload') ?: ''
    def mdfPayload = message.getProperty('MDF_payload') ?: ''

    // Check if payloads are present
    if (!wfPayload || !mdfPayload) {
        throw new IllegalArgumentException("One or both payloads are missing")
    }

    // Initialize DocumentBuilderFactory and DocumentBuilder
    DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance()
    DocumentBuilder builder = factory.newDocumentBuilder()

    // Parse the XML payloads
    Document wfDoc = builder.parse(new ByteArrayInputStream(wfPayload.bytes))
    Document mdfDoc = builder.parse(new ByteArrayInputStream(mdfPayload.bytes))

    // Extract user IDs from WF payload
    def wfUserIds = new HashSet<String>()
    NodeList wfOperators = wfDoc.getElementsByTagName("JobRequisitionOperator")
    for (int i = 0; i < wfOperators.getLength(); i++) {
        Element operator = (Element) wfOperators.item(i)
        NodeList userIdNodes = operator.getElementsByTagName("usersSysId")
        if (userIdNodes.getLength() > 0) {
            wfUserIds.add(userIdNodes.item(0).getTextContent())
        }
    }

    // Extract user IDs from MDF payload and find those not in WF payload
    def removedUsers = []
    NodeList mdfOperators = mdfDoc.getElementsByTagName("JobRequisitionOperator")
    for (int i = 0; i < mdfOperators.getLength(); i++) {
        Element operator = (Element) mdfOperators.item(i)
        NodeList userIdNodes = operator.getElementsByTagName("usersSysId")
        if (userIdNodes.getLength() > 0) {
            String userId = userIdNodes.item(0).getTextContent()
            if (!wfUserIds.contains(userId)) {
                removedUsers.add(userId)
            }
        }
    }

    // Create the result XML
    Document resultDoc = builder.newDocument()
    Element rootElement = resultDoc.createElement("RemovedUsers")
    resultDoc.appendChild(rootElement)
    for (String userId : removedUsers) {
        Element userElement = resultDoc.createElement("RemovedUser")
        userElement.appendChild(resultDoc.createTextNode(userId))
        rootElement.appendChild(userElement)
    }

    // Convert result document to string
    TransformerFactory transformerFactory = TransformerFactory.newInstance()
    Transformer transformer = transformerFactory.newTransformer()
    DOMSource source = new DOMSource(resultDoc)
    StringWriter writer = new StringWriter()
    StreamResult result = new StreamResult(writer)
    transformer.transform(source, result)

    // Set the result XML as the body
    message.setBody(writer.toString())

    // Optionally set additional headers or properties if needed
    message.setHeader("ProcessingStatus", "Completed")
    message.setProperty("RemovedUsersCount", removedUsers.size())

    return message
}

For the above scenario, SF_payload and MDF_payload is compared and removed users from SF_payload has been identified.

For example the output for the above would be:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<RemovedUsers>
	<RemovedUser>User1</RemovedUser>
	<RemovedUser>User5</RemovedUser>
	<RemovedUser>User6</RemovedUser>
</RemovedUsers>

And also the RemovedUsersCount property would have the value '3'. This output payload can be saved in a property for any uses such as sending it to the Admin via mail etc.

Applications:

This is used to compare for any valid xmls where you can find the removed data or fields.
Also, whenever if the users are manually removed from any groups/countries we can find out removed users with the custom MDF objects if created.

Hope this blog gives some insights above the XML payloads comparison and figuring out the removed data.

Thanks,

Yogesh Kumar S

SAP Integration Suite SAP SuccessFactors Platform #sapcpi

Extract MS Dynamics CRM data into SAP Signavio Process Intelligence with SAP Integration Suite

2024-10-30T14:09:01.655000+01:00

Now available on Business Accelerator Hub

To expand our offering to analyze processes that touch non-SAP system, we are happy to announce the release of our new integration content that allows you to extract data from Microsoft Dynamics CRM into SAP Signavio Process Intelligence.

This speeds up the connectivity to Microsoft Dynamics CRM so you can immediately start analyzing your CRM processes.

Let's have a look where you can find this content.

Logon to SAP Business Accelerator Hub and under "explore" search for "SAP Signavio":

Navigate to "Integrations" and there you can find the Microsoft Dynamics CRM integration content for SAP Signavio Process Intelligence.

Click on the content package.

You see a list of integration flows highlighting which business objects and events are being extracted.

This includes the business objects "Opportunity", "Lead", "Quote", and many more.

If you are interested in understanding the underlying logic of how the data is getting extracted from Microsoft Dynamics CRM, transformed and pushed into SAP Signavio Process Intelligence, you can open up these respective integration flows.

Also check out the configuration guide attached to the integration package.

I will help you to setup these integration flow with ease.

Try out this integration package and let me know what you think in the comments below 😊

Below some useful resources:

SAP Signavio integration content on SAP Business Accelerator Hub

Microsoft Dynamics CRM integration content for SAP Signavio Process Intelligence

Blog: Extract Salesforce data into SAP Signavio Process Intelligence

SAP UI Test Automation is Dead as it’s Too Slow - Part Two

2024-11-04T12:50:35.690000+01:00

In the first part of my article series Was SAP UI Test Automation just killed by SAP API Hub and Solace?, we explored the key factors making SAP UI Test Automation increasingly obsolete. The combination of SAP Business Accelerator Hub and Solace’s event-driven architecture (EDA) introduced powerful alternatives to UI testing by leveraging APIs and real-time event messages. The benefits were clear:

Stability Over Changing Interfaces: Unlike SAP UI testing, API interfaces remain consistent and unaffected by frequent UI updates, making them a more reliable choice.
Broad Participation: API testing enables functional teams, developers, and business users to participate in testing, breaking the dependency on specialized test automation teams.
Simplified Setup: API testing eliminates the need for complex, screen-based test setups.
Cost-Effectiveness: Resource demands for API testing are far lower, leading to significant savings.

However, one major factor we didn’t delve into before was speed. While SAP UI test automation is resource-intensive and complex to set up, it’s also extremely slow in execution, especially when dealing with end-to-end processes across platforms connected to SAP S/4HANA. Let’s explore why SAP UI testing lags so far behind and how API testing has revolutionized speed and efficiency in SAP testing that allows testing a complex SAP Business Processes one hundred times in a matter of 129 seconds only as shown in the Figure 1.

Figure 1 - testing a complete E2E SAP S/4HANA process 100 times in 129 seconds

The Drawbacks of SAP UI Test Automation: Setup and Execution Speed

Beyond the challenges we’ve already discussed, SAP UI testing is inefficient by design. Here’s why it slows down both testing and deployment cycles:

Complex Setup: SAP UI test automation requires recording screens across various UI technologies, whether SAP GUI, SAP Fiori, or Web Dynpro. This is labor-intensive and needs to be redone with every update to the UI or business process, making setup slow and costly.
Resource-Heavy Execution: Running a full suite of SAP UI tests demands significant computational resources, often requiring multiple virtual servers to simulate user interactions across different screens. This complexity makes it nearly impossible to run large-scale tests efficiently, limiting how often organizations can execute these tests in agile deployment cycles.
Slow Processing Time: UI-based testing involves replicating user actions, which must wait for each screen to load, process inputs, and complete transitions. This means that even basic tests take longer to execute compared to API-based processes, which bypass the UI entirely.

Speed Advantage of SAP API Testing

In contrast, API testing introduces an entirely different experience when it comes to speed. With API and event-driven architecture, testing bypasses the SAP UI and interacts directly with the business logic and data processing. This shift eliminates many of the inefficiencies inherent in UI testing. Here’s how:

Rapid Execution Without Extra Hardware: Unlike UI testing, which often requires virtual servers and other costly infrastructure, API testing runs smoothly on standard hardware, removing a significant financial and logistical burden.
Blazing-Fast Test Cycles: For example, running an end-to-end SAP Ariba and SAP S/4HANA process 100 times with API testing can take just 129 seconds—an astonishingly short time that UI test automation cannot compete with. This speed enables organizations to test thoroughly and frequently, supporting agile development and faster deployment cycles.
Efficient Resource Utilization: Since API tests only communicate with the business logic layer, they can execute in parallel with minimal resource strain. This allows organizations to maximize testing without overloading their infrastructure, unlike SAP UI tests, which are confined by server availability and loading times.

The End of SAP UI Test Automation?

The clear advantage in setup, resource efficiency, and speed makes SAP API testing the superior approach for SAP S/4HANA and SAP Ariba transformations. The continued reliance on UI testing is becoming increasingly difficult to justify when API testing offers:

Incredible Speed: API testing can handle processes in seconds, allowing full-scale testing to occur in the time it would take a single UI test to load.
Reliability: API testing bypasses the inconsistencies of changing UI interfaces, enabling a stable and consistent testing environment.
Lower Costs: By reducing the need for virtual servers and specialized hardware, API testing frees up valuable resources for other business initiatives.
Greater Scalability: With no need for multiple servers or specialized hardware, API tests scale easily across large data sets and complex business processes.

The move towards API and event-driven testing isn’t just an upgrade; it’s a paradigm shift that addresses the limitations of UI-based testing and aligns testing capabilities with modern, agile business needs. By embracing API and EDA-driven testing, organizations can look forward to faster, more efficient, and more cost-effective SAP testing, ensuring their systems meet high standards without sacrificing speed.

Conclusion

As SAP landscapes become more composable and connected, the need for efficient testing methodologies becomes paramount. SAP UI test automation, once a necessary part of testing, now stands in the way of speed and agility. SAP API testing, with its remarkable execution time, efficient resource usage, and low-cost infrastructure, has emerged as the clear replacement.

The time has come for organizations to transition fully from SAP UI to SAP API testing to keep pace with the demands of the modern ERP landscape. The shift not only streamlines testing but ensures that testing supports rather than hinders business agility and innovation.

Further Reference:

Avoid SAP S/4HANA Project Delays with Third-Party Systems Service Virtualization

SAP CI: To Configure, Export/Import, Execute and Skip the Design Guidelines and Download the Report.

2024-11-05T13:11:13.703000+01:00

Introduction To Design Guidelines:

As the name specifies this feature provides the certain guidelines/rules to be followed while designing the SAP integration flow and also helps integration developers to validate their Integration flow against the guidelines provided by SAP. So that they can design and deliver a flawless Integration flow. To explore more about the feature, you can check Design Guidelines|SAP Help Portal and Design Guidelines View|SAP Help Portal

This feature that was introduced in SAP Cloud Integration version 5.59.x/6.51.x, which had 5 guidelines under 4 different categories.

The latest version has 33 design guidelines under 9 different categories. To explore about the guidelines check Integration Flow Design Guidelines|SAP Help Portal

Each guidelines have its own level of severity, there are three levels of severity which indicates the importance and criticality of each guideline.

High: These are critical for the stability and performance of your Integration Flow. Violating these may lead to some serious issues.
Medium: These are important for the maintainability and scalability of your integration flows.
Low: These are optional, but following these may improve the quality and understandability of your integration flows.

To configure the Design Guidelines:

Pre-requisite: To configure/enable the design guidelines you must have tenant administrator role or ‘WorkspaceDesignGuidelinesConfigure’ role.

In the SAP Integration Suite, Go to Settings --> Integrations.
Switch to Design Guidelines tab and Click on Edit.

By default, all the guidelines will be enabled, you can disable the guidelines which ever is not required and Click on Save.

The Design guidelines is configured now.

To Export/Import the Design Guidelines:

If you want to replicate the design guidelines in another tenant, you can simply export the design guidelines and import it to the tenant in which you want to replicate.

You can export by simply clicking the Export option next to the search bar.

A .zip file gets downloaded into your local machine.

To import the design guidelines, Click on the Import option next to the Export option. A dialog box appears, select the file you want to import.

Note: The Guidelines will be enabled/disabled as per the imported file. There is no need to edit/save the guidelines after importing the file.

To Execute the Design Guidelines:

Pre-requisites: To execute the design guidelines, the user must have assigned the Integration developer role.

Navigate to your Integration flow --> Integration Flow Editor --> Design Guidelines --> Execute Guidelines.

Note:

Here you will see only the count of guidelines that are enabled while configuring.
You can execute the Design Guidelines for an Integration flow even when it is in locked/deployed/undeployed status.

Once executed, you will get the compliance status message along with the last execution time, version of the Integration flow for which execution happened.

You can click on the Analysis button to view the violated component and what is the expected action to be performed.

You have to make the required changes to the Integration flow and re-execute the guidelines until all the applicable guidelines are compliant to deliver a quality and flawless Integration flow.

To Skip the Design Guidelines:

There are situations where a developer may require to skip one of the guidelines due to the specific requirement of the respective interface or may need to restrict the false positive guidelines failure. In such cases, the skip option helps the developers to skip the guidelines with his/her consent.

Enable the NO option on the skip guidelines column.
Provide the appropriate reason and consent in the pop up that appears.
Then select skip. Once skipped the NO button turns to YES.

Click on the Information symbol near to the YES button to see the who skipped the guidelines and why.

You can also revert the skip anytime by turning the YES button to NO. Provide your consent over the pop up that appears and click on revert.

To download the Guidelines Report:

Simply click on the Download Report option next to the Execute Guidelines option and select .XLS.

The report gets downloaded into your local machine. You can share it to your peer for reviews.

The below screenshot represents how the report looks like.

Hope you find this blog useful. Thank you!😊

Integration patterns for the Composable Business Architecture

2024-11-08T21:19:33.576000+01:00

Linking Composable Business (Architecture) with Decoupled Integration (Architecture), and Event-Driven Architecture… And beyond…

How does this look like?

Continuing the story I’ve started in my previous article[1].

About Composable Business (Architecture) – again…

Gartner again?

Yes… And they do say (validly), “Composable means modularity”[2]. When we look the four main principles, what is attracting me the most?

More speed through discovery
Greater agility through modularity
Better leadership through orchestration
Resilience through autonomy

All is important, but I will emphasize on resilience – and not by coincidence… Why? Because all of it is leading toward – building the Enterprise Architecture with “modularity” and this is why we need resilience… Resilience in the volatile market conditions, global trends, emerging technology – you name it… This is why the emphasis is on “Composable technologies[2][3].

An enabling layer, or a foundation, of this “modularity” providing the resilience, is Decoupled Integration Architecture (please take a look on my previous article)[1]… And then, EDA is the main approach[4] we need to use – logical?

Figure 1. Capability matrix of the Composable Business (Architecture)

Decoupled Integration Architecture must support scalability and flexibility; it must have integration resilience to changes, and all this must be done by ensuring data quality. To achieve all this, we can list some critical requirements when designing integrations for the Decoupled Integration Architecture:

Retry pattern – when Recipient system is temporarily unavailable – providing data quality and integration resilience;
Idempotent – prevent message duplicates – directly supporting cross-system data quality;
Serialization – enable FIFO when needed – may be required to ensure data quality;
Guaranteed delivery – by using all available mechanic (like Retry logic) deliver message and provide acknowledgement of the success or failure – again, important from the perspective of the overall data quality;
Publish-Subscribe pattern – sending to N unknown Recipients – fostering integration flexibility;
Async Request-Reply pattern – not being blocked by processing on the Recipient end – i.e. do not “await” until other system finishes processing and then provide Response (like in sync processing) – this is very important for the overall scalability (like, not keeping connection “alive” for extended period of time etc.);
Queue messages – handling “burst” traffic – extremely important for scalability and integration resilience;
Distribution pattern – adding additional Subscriber(s) to distribute the “load” – i.e. by flexible “routing” using dynamic Topic taxonomy - again very important for the scalability;

In the respect to Guaranteed delivery, it’s not “really” guaranteed… Yes, through QoS (Quality of Service) and Retry logic we can insure it is guaranteed as-“much-as-possible”, but in case of longer unavailability of the Recipient, message will end in Death Message Queue (or Death Letter Queue) as non-delivered.

Of course, message could end up as non-delivered in case of some wrong business logic, or wrong implementation of the integration logic – i.e. one system is sending new Sales Oder to the Recipient system, where referencing new Customer (or Account) record does not exist.

If we do not send new Customer record prior or when we create Sales Order on that new Customer – this is most likely faulty implementation of the business logic…
If new Customer record message has been sent, but it is delayed – we can always set reasonable number of Sales Order messages Retry so it is “recorded” after Customer record has been successfully replicated.
… Or alternately, Recipient could simply create Sales Order with “temporary” Customer record until it is successfully updated with “full” Customer details – although in some use-cases we would have to keep this Sales Order blocked and have some trigger to unblock it after Customer record is properly created.

Explaining Composable Business Architecture

To make it simple…

It should be like building a house with LEGO© bricks (I guess, I am not the only one who likes LEGO©[5]). We may at some point decide to replace or rebuild part of the house with other LEGO© bricks, or maybe other bricks, from other manufacturers (meeting the “golden” bricks standard), produced from different type of plastic, or different material in general.

Here bricks are Architecture Building Blocks (ABB), and “golden” brick standard would be various “standard” integration protocols (i.e. openAPI, AsyncAPI etc.) of connecting those ABBs.

Ideally it should work – while in practice things are not always so easy… And I am not talking of the “quality” of the bricks itself…

There are many integration approaches, styles, patterns, standard, methodologies, etc. Different manufacturers may push for different standards, of have their own interpretations of the specific standards (which is, in fact, often worse than completely “new” standards).

Challenges

Putting all ABBs into one large enterprise and making it work is still a challenge.

In the world of todays’ Digital Agenda, business stakeholders would very often choose “best of breed” for their own Line of Business (LOB).

Choosing “best of breed” product (or ABB in border term) is not necessarily “best fit” in the overall Enterprise Architecture.

Where there are challenges – there are always some solutions…

Obviously, we cannot expect all “bricks” -will really follow the same integration standards – we have to rely on the power of middleware – to connect all loosely coupled “bricks” or ABBs.

… And still, I am still not talking about async or sync – I will come to this…

Let’s go with few examples… I will use an example of Omni-channel Commerce, and some key integrations services around Order Management – primarily around various Sales Order actions like taking an order, tracking status of an order etc.

Figure 2. Omni-channel Commerce

EDA (Event-Driven Architecture) approach

Order Management is not only about “taking an order”. An integral part of the overall Order Fulfilment, is providing “ordered status” to various connected systems – those could trigger some specific action in the connected system or can serve e.g. as an information to the Customer.

Let’s take a look on async EDA PubSub (Publisher-Subscriber)[6] approach…

In this example I will go through the simplest approach when our Backend S/4HANA system is publishing information about Sales Order(s) to the subscribed systems.

Figure 3. Publishing Sales Order Events to the multiple subscribed systems

This example is showing a simple 1:N “broadcasting” pattern (pattern described more in my article)[7]. But even if we would introduce multiple Backend systems (e.g. covering different regions etc.) things would not be much different for N:N pattern.

Figure 4. Multiple systems publishing Sales Order to the multiple subscribed systems

When building integrations with EDA approach, natively by design, it’s decoupled integration

All those Sales Order “statuses” are Events – either new order created, or order has been changed (i.e. quantities, replacing articles, delivery address etc.), or some status of an order has been changed etc.… Using EDA approach to “manage” Events through the ecosystem, either inside the Enterprise, or outside – it’s somehow natural choice.

Target systems or Recipient systems are generally referred as Subscribers – and they are “subscribed” to specific Topic(s).

In the case Event Broker is supporting dynamic Topics, situation may even be more flexible – smart choice of dynamic Topic taxonomy (hierarchical structure, variables etc.) can enable Subscriber to subscribe to only specific subset of Events within one Topic i.e. one Subscriber is interested only for Events when new Sales Order is been created in the specific Sales Organization etc.

Example of the dynamic Topic taxonomy, we can build in SAP AEM (#Advanced Event Mesh), for the Sales Order Events:

/eda/s4/salesorder/v1/{SalesOrganization}/{SalesOrder}/{OrderHeader|OrderItem}/{Create|Change|Delete |…}

In this hierarchy we are defining multiple “levels” within the Topic:

Level_1/Level_2/Level_3/Level_4/Level_5/Level_6/Level_7/Level_8

where:

Level 1 and Level 2 describe the domain – in this case our domain is “eda” and source system is “s4”
Level 3 is object-type – in this example this is “salesorder”
Level 4 is version – in this example this is “v1”
Levels 5 and Level 6 are additional dynamic object-types – in this example those are “{SalesOrganization}” are “{SalesOrder}” variables enabling dynamic filtering for Subscriber systems or Subscriber Queues
Levels 7 is another dynamic object-type – in the example “{OrderHeader|OrderItem}” is predefined list of values describing type of Event
Level 8 is a verb defining the actual action – here those action can be “{Create|Change|Delete |…}”

Beside using variables with dynamic Topics, Subscriber can utilize additional flexibility using “wildcards”, In SAP AEM we have these options:

We can subscribe to only Sales Organization starting with “11” using in “11*” in Level 5.
Or we can assign for all actions on Order Header using “/>” after Level 7.

The above is only an example – and other rules for building dynamic Topic taxonomy may apply in the different Enterprises.

In general, EDA is more about choreography than orchestration[8][9][10].

Obviously, dynamic Topic taxonomy is a very powerful tool allowing a lot of flexibility for “routing” the traffic from the Publisher(s) to the Subscriber(s)[11]. With smart design of the Topic taxonomy, many things can be done without any further “development” or coding outside of the Event Broker. More info is available in the official SAP AEM page: Get Started with SAP Integration Suite, Advanced Event Mesh[11].

In addition, Recipient systems can choose if they subscribe to the Topic or Queue. My preferred pattern is to use Queue. In this scenario, we will have one or more Queues as actual “Subscribers”, where each Queue will subscribe to one or more Topics (in the case of dynamic Topics, it be also be subsets of the various Topics). Finaly, each Queue is “connected” with the Recipient or Target system.

Various Event Brokers (i.e. SAP Event Mesh, SAP AEM, or non-SAP products as well) may support various ways to communication with Subscribers – it could be AMQP, MQTT, HTTP REST webhook - or even HTTP REST PULL where Target system has to periodically PULL messages form the Queue (this one, I generally do not prefer).

When build smartly, being async with EDA approach (with various SAP or non-SAP products), we can address all Decoupled Integration Architecture requirements:

Retry pattern –usually by design;
Idempotent –by design;
Serialization – depending on partitioning/session configuration, but generally option is available;
Guaranteed delivery – depending of the configuration, based on Retry logic and Queue messages, but generally supported;
Publish-Subscribe pattern – by design;
Async Request-Reply pattern – by design;
Queue messages – by design;
Distribution pattern – by design;

What does this say to us? EDA approach, by design, brings us scalability and flexibility.

RESTful API?

But can we follow best practices of decoupling with RESTful APIs?

Let’s take a look on this Synch Request-Response pattern. Can we use it in Decoupled Integration Architecture? Shell we immediately dismiss it as it is sync?

Wait…

Let’s say, multiple Client systems are invoking sync Sales Order creation in the Backend S/4HANA system …

Figure 5: Multiple Client systems invoking order creation

But we can also have scenarios where middleware is actually routing requests to the different Backend system – e.g. serving different regions or so.

Figure 6: Multiple Client systems invoking order creation, in the multiple Backend systems

In these scenarios, we actually talk about Client system(s) invoking some operation (or command) in the Backend system(s). So, it’s obviously not fully Decoupled, but it does use middleware and can be considered as Loosely-coupled Client-server approach.

We can integrate via API Management Gateway (APIM) and even use façade endpoint – making Client system completely “unaware” of the of the underlaying Backend system serving RESTful service Request (and providing the Response).

Furthermore, using APIM Policies we can route traffic to multiple Backend system i.e. serving different regions (or Sales Organization). If needed, we can in between use SAP CPI to adjust payloads etc.

When we talk about Sync Request-Response pattern, where we are with Decoupled Integration Architecture requirements:

Retry pattern – no, not by the integration layer – as this is RESTful API, HTTP(S) Request is invoking sync processing in the Backend system, which is send its HTTP(S) Response. If response is different from http200, sender system can have specific logic for retry mechanism.
Idempotent –by design, controlled by the sender;
Serialization – by design, controlled by the sender;
Guaranteed delivery – no, not by the integration layer – however, sender system will be aware of the failed message based on HTTP(S) Response, and can act on it;
Publish-Subscribe pattern – no, as it follows Sync Request-Response pattern;
Async Request-Reply pattern – no, as it follows Sync Request-Response pattern;
Queue messages – no;
Distribution pattern – yes, i.e. beneath API Management Gateway it can route traffic;

Obviously, we can ensure most of the requirements… but not all. No surprise, as we are here talking more about Loosely-coupled Integration Architecture, which is not fully decoupled.

So, is it loosely-coupled or decupled “enough”? I would see “it can be” – but it all depends on the specific use-case… And how we implement it...

The main limitation – no Queue messages capability.

Sync Request-Response pattern is simply not good in handling “burst” traffic scenario (when we have periodically very high increase in integration message volumes). If we have burst of requests/messages coming to the Backend system, we would have to:

Either design overall Backend solution to be able to sustain maximum peak traffic – could be very expensive, as most of the time Backed resources would work with low utilization;
Or dynamical scaling of the Backed system(s) to handle peaks – possible with cloud solutions, but also comes with the price;
Or Client system(s) will have to accept longer waiting time during the peaks – however, this is not user friendly, and may lead to other technical issues (i.e. sync connection may timeout);

When does Sync Request-Response pattern make sense?

If we run banking transactions – we should normally want to ensure ACID (and keep several operations encapsulated with “one” transaction). Here using Sync Request-Replay pattern is an obvious choice.

But in our examples of the Order Management, some operations may or may not make sense to be run with sync approach.

If we have fairly small Sales Order(s), with 10-20 Products, with no “burst” pattern – submitting it to the Backed system which can perform ATP checks, credit checks and pricing calculation in ”lighting” speed (let’s say S/4HANA) – why not using sync approach?

But what if we have Sales Order(s) with 100, 200 or more Products, with complex Backend pricing and promo calculations? What if we have huge volumes with “burst” pattern? Using async approach for sure looks better option…

It all depends on the specific use-case…

Do we “go” sync or async?

When we talk about Sales Order, as an example, we could have various integration patterns. I am showing few simple examples with some standard APIs and IDOCs – representing both sync and async approach.

Let’s take a look at the “classical” approach…

Figure 7: Splitting Sales Order Taking process for “large” orders

What do we see here:

Fully Sync Request-Response pattern using OData API_SALES_ORDER_SRV Sales Order (A2X) for inbound Order Taking requests[11];
For “large” orders, async creation of the Sales Order using SALESORDER_CREATEFROMDAT204 IDOC (previously has been part of the reference integration architecture of SAP Commerce Cloud), without any confirmation weather Backend S/4HANA system has successfully processed the IDOC – this approach can be supplemented with standardSales Order Replication or Standard/custom Sales Order Create Event Notification, allowing Client system to get formal confirmation as well – still, strictly speaking, this is not Async Request-Response pattern, as published Replication or Event Notification is not intended only for the Client system originally creating Sales Order, but to all “interested” Subscribers;

But can we do better with EDA?

Figure 8: Fully (near) real time async approach of Sales Order Taking

Now we have fully Async Request-Response pattern with EDA middleware and few transformations and Value Mappings, of course.

Still for smaller message sizes, it will switch to Sync Request-Response pattern toward to Backend S/4HANA system, using OData API_SALES_ORDER_SRV Sales Order (A2X) for inbound Order Taking requests[12] – where Response with Order ID confirmation (or error) is published and respective Subscriber(s) can take it;
For “large” orders, fully Async Request-Response pattern using B2B ORDERS and ORDRSP IDOCs – where ORDRSP IDOC with Order ID confirmation is published and respective Subscriber(s) can take it;

What do we achieve with this approach?

First of all, no matter if order is “large” or not, from the perspective of the overall integration process it is always Async Request-Response pattern. We can always set QoS so message is remove from the Topic/Queue only if Sales Order API has been successfully called, or in case of “large” orders IDOC has been successfully created and sent.

In most of the cases, speed would be matching Sync Request-Response pattern, but in all cases Client is not “blocked” until Response has been received.

Event when calling sync Sales Order API, in case of some technical failure, we still have possibility within our EDA middleware to run Retry. This also addresses “burst” pattern.

Now, this is only high-level Solution Concept, not a details design – we may go for other options, and not use B2B IDOCs – but the idea stays the same…

And conclusion is…

Conclusion is straight-forward:

We cannot build modern Composable Business (Architecture) without EDA approach, as this is core of the Decoupled Integration Architecture – simple as that!
But we should not dismiss RESTful approach for some use-cases – we just have to make sure we design it in the Loosely-coupled Integration Architecture style.

This article is not evaluating EDA vs. RESTful – actually it’s about both EDA and RESTful working together. And they can work together…

Still, I would give an “upper edge” to EDA approach because it provides natural way of building scalable and flexible integrations – and this is the “modularity” we must enable (as much as possible) for the Composable Business (Architecture)

Figure 9: Composable Business with “all” enablers

I would not try to put any “golden” rules when to “go” sync and when to go “async” – but I will share few thoughts…

When we need to ensure encapsulation of the transactions – go for sync RESTful API
When we have large messages with potentially complex processing in the Recipient system – go for EDA (or async API in general)
When we have high volumes and/or “burst” pattern – go for EDA (or async API in general)
When we explicitly do not have real time requirements – go for EDA (or async API in general) – even though EDA is quite capably of (near) real time integrations
When we are publishing Notification Events, or Data Events, or Decision Events – go for EDA

In all other cases, both RESTful API and EDA (or async API in general) could do just fine – although we should still evaluate (having the big integration picture in mind) if one or the other approach would fit better on each specific use-case. If we aim for long term scalability and flexibility (and we should) – let’s choose EDA approach.

NOTE: In this article I did not cover streaming and ETL integration styles (i.e. for Big Data). But we will see in the forthcoming articles, that streaming and ETL integration style can be very much supported by EDA tools and approach, in general.

Acknowledgment

*) Intro photo Joshua Sortino on Unsplash

**) This article uses SAP Business Technology Platform Solution Diagrams & Icons as per SAP Terms of Use governing the use of these SAP Materials (please note, newer version of the Solution Diagrams & Icons, as well as Terms of Use, might be in place after the publication of this article).

More guidelines on Solution Diagrams & Icons can be found in this article by Bertram Ganz.

References

[1] SAP Blog: What is Composable Architecture? - SAP Community

[2] Gartner: The Future of Business Is Composable - Gartner Keynote

[3] SAP Blog from @mariafay: What is a composable enterprise? And who is the co... - SAP Community

[4] Solace: Why it's Time to Event Enable your Integration | Solace

[5] SAP Blog from @fjaviergar07: Composable Architecture: A Practical Example - SAP Community

[6] Wikipedia: Publish–subscribe pattern

[7] SAP Blog: How to build an Integration Architecture for the I... - SAP Community

[8] Solace: Microservices Choreography vs Orchestration Overview

[9] IBM: Event-driven architectures with Kafka and Kafka Streams - IBM Developer

[10] Choreography and orchestration | Serverless Land

[11] SAP AEM: Understanding Topics

[12] SAP Blog on Omni-channel: Building Integration Architecture for the Omni-cha... - SAP Community

Integration architecture guide: Updated version available now

2024-11-25T09:06:55.361000+01:00

I am happy to share the news that an updated version of the integration architecture guide has been released! Based on SAP Business Technology Platform offerings available today, this document provides you with detailed guidance on how to evolve your existing integration architecture. As before the integration guide is structured along the concepts of the SAP Integration Solution Advisory Methodology, such as integration styles and integration use case patterns.

This blog post gives you an overview about the most important news delivered with this version of the guide.

Process Integration

This chapter has been updated to include recommendations regarding the latest capabilities of SAP Integration Suite such as the new Edge Integration Cell option, Data Space Integration and Advanced Event Mesh.

You can also find consolidated information about how to elevate toward SAP Integration Suite – be it from SAP Process Integration/Orchestration or from SAP API Management and/or SAP Cloud Integration on SAP BTP Neo cloud platform. In the first case, Edge Integration Cell plays an important role: Deployed in customer-controlled environments, it allows you to run your integration scenarios locally within your own environments, without going through the public internet. Migrated existing integrations flows can be redeployed to and run by the Edge Integration Cell.

Scenarios using Edge Integration Cell

Event-Driven Integration

Event-driven architecture (EDA) is a well-known approach for designing and building decoupled, hyper-connected software systems and it’s rapidly gaining popularity in the world of enterprise integration due to its reliability, scalability, and cost-effectiveness. This chapter describes the role and interplay of SAP EDA solutions such as SAP Integration Suite, advanced event mesh, SAP Cloud Application Event Hub, further capabilities of SAP Integration Suite and technologies for event-enabling SAP applications.

Event-Driven Architecture in the Enterprise

Data Integration

The guide also describes the role of SAP Datasphere with regards to data integration options. SAP Datasphere enables a business data fabric architecture and supports integration use case pattern like data ingestion, virtual data access, and data transformation and orchestration.

Overview of SAP Datasphere

User Integration

There is also a major overhaul of this chapter to provide recommendations regarding the latest SAP solutions which enable a central entry point for users to business solutions. These are SAP Start, SAP Mobile Start, SAP Build Work Zone (standard and advanced edition) and SAP Task Center.

Cross-solutions entry point on SAP Business Technology Platform

Furthermore, the technology recommendation for the chatbot integration use case pattern of the SAP Integration Solution Advisory Methodology reflects now the latest innovations by introducing Joule: Joule is a generative AI-based assistant embedded in SAP’s cloud enterprise portfolio that provides proactive, contextualized insights from various data sources.

New Content Format and Access Point

In addition to updating the content of the integration architecture guide we also changed its format: The guide is now available as documentation at SAP Help Portal and comes with benefits such as easier navigation and search, option to bookmark, subscribe and to provide feedback to the content.

The integration architecture guide is an integral part of SAP BTP Guidance Framework which is the central access point for architects, developers and administrators to build and run enterprise-grade solutions on SAP BTP.

Integration architecture guide at SAP BTP Guidance Framework

The integration guide belongs to the decision guides of the framework and is interconnected with other assets of SAP BTP Guidance Framework such as the documentation of the SAP Integration Solution Advisory Methodology and SAP BTP reference architectures (for integration).

Enjoy reading the new guide! It would also be great to get your feedback, for instance which integration topics should be addressed with the next update. If you have any suggestions feel free to leave them as comments to this blog post. Happy integrating 😊

SAP Integration Architecture Guide

2024-12-11T14:41:17.513000+01:00

SAP Integration Architecture Guide
The SAP Integration Architecture Guide is based on the recent update from SAP for Integration Architecture explained in a summarized way, emphasizes how organizations can utilize SAP Integration Suite to create a scalable, efficient, and potentially productive integration landscape. This blog will thoroughly explore the essential principles, methods, tools, and practices outlined in the guide, providing a concise insight into SAP’s strategy regarding integration.
________________________________

1. Introduction to Integration Architecture
The Integration Architecture Guide emphasizes the increasing significance of integration as a strategic business driver. SAP emphasizes:
• The necessity for smooth connectivity throughout various IT environments, such as hybrid, multi-cloud, and on-premises environments.
• Leveraging SAP Integration Suite as an enterprise-grade iPaaS (Integration Platform as a Service) to connect applications, data, and users effectively.
• Assisting complete processes such as Lead-to-Cash, Hire-to-Retire, and Procure-to-Pay across SAP and non-SAP systems.
________________________________

2. Core Integration Principles
The guide defines four foundational principles of SAP’s integration strategy:

Predefined Integration/ Out-Of-The-Box Integration
• Prepackaged APIs, integration flows, and domain models facilitate implementation and curtail costs.
• Instances comprise preconfigured connectors for processes such as Invoice Management or else Employee Onboarding.

Open Integration
• Out of the box third-party integration via more than 170 Open Connectors.
• Public APIs for customization and extensibility, establishing compatibility with non-SAP systems.

Holistic Integration
• Process Integration: Automating workflows between SAP and non-SAP applications.
• Data Integration: Providing synchronized and uniform master data through systems.
• User Integration: Delivering flawless user experiences through SAP Build Work Zone.
• Analytics Integration: Utilizing SAP Analytics Cloud for practical understanding AI-Driven Integration.

AI-Driven Integration
• Integration Advisor: A machine learning-powered tool to automate complex mapping tasks and provide integration templates.
• Better efficiency in B2B and API-based integrations.

________________________________

3. SAP Integration Solution Advisory Methodology (ISA-M)
SAP’s ISA-M is a framework for building a robust enterprise integration strategy. It includes:

Phase 1: Assess Your Integration Strategy

• High level assessment of your integration architecture through integration domains, current scope of integration domains are Cloud2Cloud, Cloud2OnPremise, OnPremise2OnPremise, User2Cloud, User2OnPremise, Thing2Cloud, Thing2OnPremise.

• Examine existing systems, pinpoint deficiencies, and outline integration areas.
• Categorize integration patterns (A2A, B2B, B2G, etc.) and styles (process, data, user). Typically an integration architect who has a solid understanding of integration requirements across business applications performs the scoping of integration styles.

Phase 2: Design Hybrid Integration Platform

• Create architectural designs customized for business requirements.
• Establish frameworks and tools for smooth integration through the tools and technology mapping, utilizing SAP Integration Suite

Phase 3: Define Integration Best Practices

• Make templates and architecture reusable blueprints as a reference for all Integration developments.
• Align with SAP governance frameworks to ensure compliance and uniformity.

Phase 4: Enable a Practice of Empowerment

• Establish Centers of Excellence (CoE) to promote innovation and facilitate knowledge sharing through the right organizational structure.

• A set of templates with a governance structure for all the enterprise integration developments, below is an example for reference.

________________________________

4. Big Picture - SAP Integration Suite
SAP Integration Suite serves as a unified integration platform with the following components:

Cloud Integration

• Core middleware component simplifies the communication through a integrated flow design and used for diverse scenarios (A2A, B2B, B2G).
• Used for both Synchronous and Asynchronous communication minimal latency.
• Prepackaged Content with end-to-end process blueprints are available.
• Integration Advisor and Trading Partner Management through AI/ML learning used to generate mappings and interfaces templates.

API Management

• Serves as the baseline for API lifecycle management along with the industry best practices for security.
• Integrates with Graph to enable seamless access to interconnected data.
Advanced Event Mesh

• Works as the core for event driven architecture enabling asynchronous communication across systems with scalability and system availability options.
• Handles high-volume, low-latency event streams.

Dataspace Integration

• Offers secure and collaborative data exchange across systems.
• Supports compliance with data governance standards within industry partnerships like Catena-X.
________________________________

5. Integration Patterns and Use Cases
The guide categorizes integration use cases into distinct patterns:
Application-to-Application (A2A)
• Example: SAP S/4HANA and SAP SuccessFactors real time synchronization for employee and organizational data.
Business-to-Business (B2B)
• Example: EDI-based order processing and invoicing with trading partners.
Business-to-Government (B2G)
• Example: SAP Document and Reporting Compliance for Automated tax filing as the e-invoicing solution.
Master Data Integration
• Synchronization of master data, such as employees, customers or products, across all connected systems.

________________________________

6. API Life Cycle
The API lifecycle starts from API planning, creation and implementation by company developers and other API creators and composers, to the consumption of these APIs by other employees, partners or users of the company’s products and services. The figure below illustrates the API lifecycle,

________________________________

7. SAP Business Accelerator Hub
SAP Business Accelerator Hub works with BTP, it’s a platform that allows users to discover APIs, integration content, business events, and process blueprints to build and extend applications. It enables API-based business functionality (organized into packages) and provides process insights using SAP Enterprise Architecture Methodology. APIs available on Business Accelerator Hub enable developers to build custom integrations, create new applications, and extend the functionality of SAP solutions.
It gives diverse sandbox APIs for several SAP products like SAP S/4HANA, SAP BTP, SAP SuccessFactors, SAP Concur, and more. It can be used to make extensions, applications, or integrations and test them with testing data provided, via these sandbox API.

SAP drives API adoption by:
1. Positioning APIs as digital building blocks.
2. Enhancing API maturity.
3. Providing a lifecycle API platform.
4. Engaging developers via API discovery and consumption.

________________________________

8. SAP Integration Suite – Hybrid Strategy
The Edge Integration Cell is a hybrid approach that enables the processing of data within a private landscape having Kubernetes container, runtime environment facilitating secure, internal data exchange. Existing integrations can be migrated and run on the Edge Integration Cell with provided tooling.

________________________________

9. SAP Integration Suite, managed gateway for spend management and SAP Business Network
The SAP Integration Suite, managed gateway for spend management and SAP Business Network, makes integration through its Integration-as-a-Service (IaaS) model. This solution utilizes the Cloud Integration capability, connects buyers' and suppliers' systems with systems like SAP S/4HANA, SAP ECC, Taulia, and SAP Ariba at no extra cost. It offers A2A, B2B, and B2G scenarios, emphasizing processes such as supply chain management, procure-to-pay, and order-to-cash.

Key features include:
• Predefined Scenarios: Pre-Packaged mappings and message types.
• Self-Service Tools: Integration project wizards, document validation, mapping tools, and monitoring frameworks.
• Reusable Content: Prebuilt integration flows via SAP Ariba Transformation Service.
The suite enables seamless integration across heterogeneous IT landscapes, supporting event-driven and API-managed models. It provides secure connectivity, robust monitoring, and ensures compliance with regulatory standards. Integration tools like the Edge Integration Cell and SAP Application Interface Framework further enhance flexibility and governance. This hybrid, scalable approach addresses diverse business needs while future-proofing integration strategies.

________________________________

10. Migration Strategy
The guide emphasizes a structured migration approach to SAP Integration Suite:
• Migration Assessment Tool: Evaluate readiness for transition and identify gaps.
• Prebuilt Migration Packs: Automate repetitive tasks to reduce complexity.
• Hybrid Strategy Support: Ensure continuity by enabling hybrid operations during migration.

SAP is transitioning to a flexible BTP multi-cloud foundation, with BTP Neo set to retire by 2028 and SAP NetWeaver/Process Orchestration by 2027. The focus is on SAP Integration Suite as the primary integration solution.
SAP provides migration support through:
• Neo to Integration Suite:
o Migration packs for smaller projects and tools for complex scenarios (e.g., tenant cloning and API migration).
o Best practices, documentation, and cost-lowering guidance.
• Process Orchestration to Integration Suite:
o Step-wise migration guidance, including free assessments, migration services, and premium offerings.
o Edge Integration Cell for secure on-premise integration, supporting migrated flows.
SAP’s tools and services ensure a smooth transition with minimized commercial and operational impact.

________________________________

11. SAP Application Interface Framework (AIF)
SAP Application Interface Framework, embedded in SAP S/4HANA, enhances interface management by enabling efficient implementation, monitoring, and analysis of application interfaces. It integrates deeply with SAP applications, supporting features like data validation, value mappings, and business logic-based checks.
Key benefits include:
• Business user-friendly monitoring, error management, and alerting without IT support.
• GDPR-compliant error handling with in-app corrections, avoiding message resends.
• Role-based governance to secure interface data and hide sensitive fields.
AIF complements SAP Integration Suite by providing robust application-level integration and management capabilities.

________________________________

12. Technology Guidance for Specialized Integrations
SAP offers specific guidance for various integration scenarios:
• Event-Driven Architecture: Real-time responses to critical system events.
• API-Managed Integration: Comprehensive API lifecycle management to connect internal and external applications.
• B2B Integration: Secure data exchange with partners using protocols like EDI.
• Master Data Integration: Centralized data governance for consistency across platforms.
• Dataspace Integration: Facilitates secure and sovereign data sharing between organizations using SAP's implementation of the Eclipse Dataspace Connector, particularly in consortium-driven contexts like Catena-X Automotive Network.
________________________________

13. AI-Assisted Tools and Enhancements
Integration Advisor
• Automates mappings for complex integration scenarios through specific templates.
• Leverages machine learning to recommend best practices and streamline B2B integrations.
Business Accelerator Hub
• Repository of prebuilt APIs, integration templates, and business events for rapid deployment.
________________________________

14. Data Integration Patterns
1. Data Replication:

Migration of data from one system to another keeping the synchronization intact across the landscapes, in such cases usually requires high data availability, backups, or reporting, SAP supports this through tools like SAP HANA Smart Data Integration(SDI) and SLT Replication Server.

2. Data Virtualization:

Provides a unified view of data without replication. It facilitates on-demand access to data from diverse sources using tools like SAP Data Warehouse Cloud and SAP Datasphere.

3. Data Quality Management:

Maintaining a reliable and accurate data set through data cleansing and various validations. SAP's solutions include SAP Data Intelligence and SAP Information Steward to monitor and improve data quality.

4. Data Orchestration:

Coordinates data flow across systems for streamlined processes. It uses SAP Integration Suite for tasks like data transformation, error handling, and real-time processing.

5. Overview of Products and Services for Data Integration:

The SAP Datasphere, SAP Integration Suite, and SAP Data Intelligence are key solutions to handle diverse integration needs, including replication, orchestration, and quality management, for hybrid and multi-cloud environments.

6. Data Integration vs. Process Integration:

Process Integration addresses business process automation and data flow management from one system to another, while Data Integration focuses on data synchronization, governance, and virtualization. SAP offers complementary tools for both styles under its Integration Suite.
________________________________

15. Analytics Integration in SAP

SAP Analytics integration involves data from various sources towards one combined data set through which insights and decision making is made easier by making one source of truth in order to calculate the key performance indicators. This includes embedded analytics such as reports
and dashboards into a business application and cross-application analytics by combining data of one or more source systems using an analytics or data warehouse solution. On top of the combined data an analytic consumption model can be built to enable (cross app) reporting. For example Order to Cash Dashboard which is embedded in S/4 Hana Cloud, using predefined charts it allows the sales managers to analyze the key figures, whereas, Financial Analytics Dashboard enables a workforce performance analysis, combining the HR data from Success Factors and Finance data from S/4 Hana making cross application data model and bringing the Cross Application Analytics.

Key Components:
1. Use Case Patterns:
o Embedded Analytics: Embeds reports and dashboards directly into business applications (e.g., an Order-to-Cash dashboard in SAP S/4HANA Cloud).
o Cross-Application Analytics: Combines data from multiple sources, such as financial data from SAP S/4HANA and HR data from SAP SuccessFactors, into unified dashboards.

2. SAP Analytics Cloud (SAC):
o Capabilities: Combines business intelligence (BI), planning, and augmented analytics, enhanced with AI and ML.
o Features:
- Data exploration, dashboards, enterprise reporting.
- Predictive analytics and automated insights.
- Planning tools for budgeting and forecasting.
- Integration with Microsoft Excel for enhanced usability.
3. SAP Datasphere:
o Role in Analytics: Provides a data foundation for cross-application analytics, ensuring seamless access to business-critical data with preserved semantics.
o Key Features:
- Unified data management through cataloging, semantic modeling, federation, and virtualization.
- Accelerates time-to-value by leveraging prebuilt semantic definitions.
- Supports hybrid and cloud environments, enabling complex analytics scenarios.

4. Business Data Fabric:
o Offers a semantically rich layer across data landscapes, ensuring integrated, consistent, and context-aware data without duplication.
5. Partner Integrations:
o Collaboration with vendors like Collibra (data cataloging), Confluent (real-time streaming), DataRobot (ML models), and Google Cloud (AI/ML integration).
________________________________

16. User Integration in SAP
User integration focuses on creating a seamless, unified user experience across systems and applications. Key aspects include:

1. Centralized Access:
o Provides a single entry point to access multiple business applications and processes.
o Achieved through tools like SAP Build Work Zone, SAP Start, and SAP Mobile Start.
2. Enhanced User Experience (UX):
o Enables consistent cross-system experiences.
o Incorporates UX integration qualities, ensuring usability across platforms.
3. Technology Support:
o Leverages SAP tools for integration to facilitate user-centric designs.
o Ensures intuitive interfaces, supporting both desktop and mobile users.

Data Provisioning Options
When integrating systems for SAP Front End applications, several data provisioning options are available depending on the deployment scenario:
1. SAP Gateway (On-Premise):
• Embedded Deployment:
o Suitable for fully on-premise setups.
o Simplifies configuration but limits content scope and scalability.
o Directly integrates UI and backend, offering improved performance.
• Hub Deployment:
o Preferred when provisioning data from multiple back-end systems or when using Fiori apps in the cloud.
o Centralizes configuration, supports global environments, and decouples UI from back-end systems for enhanced scalability and security.
2. SAP OData Provisioning Service (SAP BTP):
• Neo Environment:
o Ideal for cloud-based Fiori/ Frontend apps to reduce TCO.
o Eliminates the need for on-premises hub systems.
o Suitable for connecting single or multiple back-end systems.
• Cloud Foundry Environment:
o Designed for hybrid setups requiring data provisioning from multiple back-end systems.
o Reduces TCO while supporting SAP Business Suite or SAP S/4HANA systems with OData v2 services.
3. SAP Integration Suite (Cloud Integration Capability):
• Recommended when data sources are mixed (some OData and others non-OData).
• Connects on-premises or cloud systems, both SAP and third-party.
4. Deployment Considerations:
• Hub Deployment:
o Provides centralized functionality (e.g., in-box, search).
o Requires synchronization with back-end systems but ensures decoupling for scalability and security.
• Embedded Deployment:
o Limits scope and central functionality but simplifies ownership and configuration.

Use Case Patterns for User Integration

1. UI Integration:
o Description: Combines multiple application UIs into a centralized entry point. Supports backend service consumption through a unified web user interface.
o Example: Federates content from SAP business applications like SAP S/4HANA Cloud, SAP Integrated Business Planning, and integrates custom or third-party applications.
2. Mobile Integration:
o Description: Provides access to backend application services via mobile apps, leveraging native or hybrid device capabilities.
o Example: Mobile entry points for accessing SAP solutions like SAP S/4HANA and SAP SuccessFactors using native applications optimized for mobile platforms.
3. Chatbot Integration:
o Description: Integrates chatbots into communication channels to interact with backend applications, enabling transactions or information retrieval.
o Example: SAP Joule integrated with SAP SuccessFactors to facilitate natural language interactions with business users.
These patterns address diverse user needs by enabling seamless access across devices and interfaces, improving efficiency and the user experience.
________________________________

17. Identity Integration
Identity integration ensures seamless user authentication, role management, and lifecycle management across SAP and third-party applications in both cloud and on-premise landscapes. Key components include:

1. Authentication and Single Sign-On (SSO):
• Purpose: Simplifies user access with unified login credentials, enhancing security and user convenience.
• Solutions:
o SAP Cloud Identity Services - Identity Authentication (IAS):
- Supports SSO for SAP applications.
- Integrates multi-factor authentication for enhanced security.
o SAP Secure Login Service (SLS):
- Generates short-term user certificates (X.509) for SSO in ABAP systems.
- Facilitates secure access through corporate Identity Providers (IdPs).
• Heterogeneous Scenarios:
o Combines cloud and on-premise systems, ensuring smooth authentication with tools like SAP GUI.

2. Identity Lifecycle Management/ Identity Provisioning:

• Challenges: Managing identities across applications and landscapes while reducing complexity and ensuring automation.
• Solutions:
o SAP Cloud Identity Services:
- Centralizes identity storage, lifecycle management, and replication.
- Provides lightweight tokens for app access, minimizing user replication efforts.
o SCIM API (Identity Directory Service - IdDS):
- Automate integration with applications.
o Global User ID:
- Acts as a unique identifier for users across applications, ensuring consistent correlation of tasks and permissions.
3. Roles and Authorization:
• Purpose: Defines and manages user access levels across applications.
• Solution:
o Authorization Management Service:
- Centralizes policy definitions for new applications.
- Ensures consistent role and permission management across integrated systems.
- Facilitates compliance and streamlined governance.

Benefits of Reference Architecture:
• Centralized Authentication and Identity Flow:
o Single endpoint for authentication and identity assignment.
• Simplified Integration:
o Facilitates onboarding of additional SAP applications.
• Compliance and Security:
o Enforces consistent authorization policies across hybrid landscapes.

SAP’s identity integration framework leverages central services like SAP Cloud Identity Services and global identifiers to streamline authentication, lifecycle management, and role assignments, ensuring a cohesive, secure, and scalable identity management strategy.
________________________________

18. Integration Configuration with the Cloud Integration Automation Service (CIAS)
CIAS provides a centralized framework for defining and automating the configuration of integration scenarios, offering:
1. Standardization: Consistent user experience and standardized configurations for integration scenarios delivered by SAP.
2. Automation: Parts of the integration setup are automated, reducing effort and errors.
3. Customization: Configuration steps are tailored to the customer’s specific cloud and on-premise landscape, with dynamically derived hyperlinks and configuration values.

Integration Scenarios Supported:
• CIAS supports scenarios for end-to-end processes like:
o Lead to Cash
o Recruit to Retire
o Source to Pay
• Integration with tools such as:
o SAP Integration Suite
o SAP Cloud Connector
o SAP Launchpad Service

Two Phases of Configuration:

1. Planning Phase:
o Select a scenario.
o Gather the specific config content at one place along with the specific system and tenant data.
o Prepare a tailored customer specific workflow based on the customer’s landscape.
2. Execution Phase:
o Specifies the steps for the required scenario for the generation of the workflow
o Users are guided step-by-step, and tasks are grouped by roles (e.g., "Configuring the BTP ABAP Environment to use the Custom Code Migration App").
o The guided automation is triggered when required, but the manual interventions is retained for complex and security critical tasks.

The Cloud Integration Automation Service transforms setup into a more guided, and standardized process. For example, For the custom code migration app setup, the CIAS service is used where required in a more effective way which decreases the complexity and enhances the overall process in a more simplified way across hybrid landscapes.

________________________________
19. End-to-End Monitoring
Scope:
• Tracks integration issues, system health, and message flows.
• Monitors exceptions, performance, response times, and throughput.

Capabilities:
• Manages real time integration artifacts monitoring through end-to-end message flows.
• Provides alert notifications and analytics for issue resolution.
• Supports in various automations for operational tasks.

Monitoring Tools:
• SAP Cloud ALM: Tailored for cloud-based applications.
• SAP Solution Manager: Monitors on-premise systems.
• SAP Focused Run: High-performance monitoring for large-scale landscapes.

________________________________

SAP Integration Architecture Guide, provides a design framework for building a scalable and future-proof integration landscape. Using SAP's tools, templates, methodologies, and best practices, organizations can unlock new opportunities for innovation, operational efficiency, and business growth.

References:

https://help.sap.com/docs/sap-btp-guidance-framework/guidance-framework/what-is-sap-btp-guidance-framework?q=SAP+BTP+Guidance+Framework

https://help.sap.com/docs/sap-btp-guidance-framework/integration-architecture-guide/summary

https://community.sap.com/t5/technology-blogs-by-sap/integration-architecture-guide-updated-version-available-now/ba-p/13930016

Join us at the Integration Modernization Summit for SAP Partners

2024-12-17T17:33:30.406000+01:00

In today's fast-paced business environment, the need for organizations to have an agile and scalable integration architecture has become more critical than ever before. As technology continues to evolve, modernizing integration architecture becomes crucial for organizations to stay competitive. In the SAP ecosystem partners play an important role helping organizations to unlock the full potential of modern integration technologies SAP Business Technology Platform (BTP) provides.

Hence, we would like to call all SAP partners to join us for the Integration Modernization Summit for SAP Partners to get valuable insights and updates about SAP's integration strategy, SAP’s integration portfolio, SAP’s best practices for integration and SAP’s offerings for partners. This event is scheduled for January 27th and 28th 2025 at SAP in St. Leon-Rot (Germany). The agenda of this event is designed to meet the needs of different SAP partner types such as sell, build and service partners.

Let’s take a look at the preliminary agenda of this summit:

Explore integration modernization and business opportunities with SAP Integration Suite

We plan to kick-off the first day in the early afternoon with lectures to set the stage for the entire event:

Integrate to innovate - SAP’s integration strategy
Bridging the gap - Exploring the untapped potential for integration
Uplevel your integration along your ERP transformation

In the afternoon we plan to offer further sessions allowing you to learn from SAP experts about how sell, service and implement SAP Integration Suite for modernizing integration. We plan to close the day with an evening event which will offer a lot of networking opportunities in a relaxed atmosphere.

Enjoy deep dive into sessions on integration modernization

Let’s start the second day of the event with lectures about SAP partner program offerings, integration best practices and product innovations, such as:

Empowering Partner Success - programs & resources for SAP Partners
Defining and executing an integration strategy based on ISA-M using SAP Integration Suite together with SAP LeanIX enterprise architecture management solutions
Future innovations planned for SAP Integration Suite and SAP Datasphere

In the afternoon you will have the opportunity to join various breakout sessions to learn more about how to sell, transform and innovate with SAP Integration Suite. Before closing the event take the chance to meet the experts and to engage with your peers.

Check out the event page for further details and updates or simply register here (for SAP partners only).

Looking forward to seeing you all hopefully soon 😊

Test-Driven Development for SAP Integration Suite Migrations: A Game-Changer for Mapping Scenarios

2024-12-30T10:59:39.962000+01:00

Migration to SAP Integration Suite represents a significant step forward for many organizations looking to modernize their integration landscapes. However, for scenarios where existing mappings cannot be automatically migrated, Test-Driven Development (TDD) becomes a vital strategy to ensure a smooth, reliable, and cost-effective transition.

The Why: Why Use TDD for Integration Migrations?

When migrating to SAP Integration Suite, a key challenge arises: certain integration platforms use mapping mechanisms that cannot be directly moved or reused in the new environment. TDD provides a systematic approach to mitigate this issue by ensuring mapping integrity and reducing risks through robust automated testing.

Specific Scenarios Requiring TDD

SAP Process Orchestration (SAP PO):

SAP PO often utilizes ABAP or Java-based mappings that are tightly coupled with the platform.
These mappings need to be re-implemented manually in the SAP Integration Suite, making them prone to human error.

Third-Party iPaaS Solutions (Boomi, Mulesoft, WebMethods, Tibco, etc.):

Proprietary mapping formats and logic in these platforms cannot be transferred directly to SAP Integration Suite.
Recreating these mappings from scratch demands rigorous validation to avoid errors.

Custom or Homegrown Solutions:

Custom applications often feature highly bespoke mappings that lack standardization, further complicating migration.
TDD ensures these mappings align with new platform requirements while maintaining original functionality.

The Importance of TDD in These Scenarios

Risk Mitigation: Recreating mappings introduces a high likelihood of defects, data loss, or process disruptions. TDD minimizes these risks through iterative validation.
Efficiency: Automated testing accelerates the process of verifying new mappings, saving time compared to manual testing.
Accuracy: By basing tests on historical data, TDD ensures new mappings perform consistently with the legacy environment.

The How: Implementing TDD in Migration Projects

Understanding Test-Driven Development (TDD)

TDD involves writing automated tests before implementing mappings or other migration tasks. These tests validate the behavior of the new mappings against historical data from the legacy system, ensuring alignment with business requirements.

Steps to Apply TDD in SAP Integration Suite Migrations
Leverage Historical Data:

Extract real-world input and output messages from the legacy platform (e.g., SAP PO, Boomi, Tibco).
Use these messages to define expected outcomes in the SAP Integration Suite environment.

Automate Test Case Creation:

Tools like Int4 Shield can convert historical messages into automated test cases. Using Int4 Robotic Crawler 1000s of test cases can be create for all interfaces in no time as shown in the video below.

Organize test cases by interface for easier management and traceability by using Test Case Analysis functionality

Recreate Mappings:

Develop new mappings in SAP Integration Suite based on business requirements.
Execute automated tests for each mapping to validate correctness against historical outputs.

Iterative Validation:

Identify discrepancies, correct mapping errors, and re-run tests to ensure compliance.
Automate regression testing to verify that changes in one wave of the migration do not impact previously validated interfaces.

Simulate EDI Partners:

Simulate partner systems and external applications to reduce dependency on third-party availability.
Virtualize message exchanges to enable controlled testing without disrupting production environments.

Regression Testing

One of TDD’s greatest advantages is its support for continuous and regression testing:

Validate migrated interfaces across multiple waves of migration.
Ensure changes in later phases do not negatively affect previously completed mappings.

You can check out more on how in this video:

Video showing Test Driven Development for SAP Integration Suite migration programs

Benefits of Using TDD for Mapping-Heavy Migrations

Consistency and Accuracy:

Ensures that newly created mappings replicate the behavior of legacy mappings without introducing errors.

Reduced Risk:

Identifies and addresses issues early, preventing disruptions in critical business processes.

Efficiency Gains:

Automates the validation process, reducing the time and effort required for testing.

Seamless Migration:

Guarantees business continuity by thoroughly validating all mappings before go-live.

Scalability:

Enables organizations to manage and validate complex mapping scenarios across multiple interfaces and migration waves.

Conclusion

Migrating to SAP Integration Suite is an opportunity to modernize and future-proof your integration landscape. However, when legacy mappings cannot be directly transferred, the risk of errors and disruptions increases. Adopting Test-Driven Development (TDD) ensures these challenges are met with confidence. By automating the creation and execution of test cases and iteratively validating mappings, TDD transforms a daunting migration project into a seamless and controlled process.

For organizations moving from platforms like SAP PO, Boomi, or Mulesoft, TDD is not just a best practice—it’s a necessity to safeguard data integrity, maintain business continuity, and achieve a successful migration.

SAP Integration Suite: Education on How to Deploy it for HR (January 22nd Webinar)

2025-01-07T18:07:12.944000+01:00

To help with understanding how SAP Integration Suite can improve the efficiency and effectiveness of integrations between HR systems (such as with SAP SuccessFactors Employee Central core HR application), one of our partners (Comentec) is hosting an executive briefing specifically designed for HR and HR IT leaders.

Topic: "Maximizing Your HR Cloud Journey: Strategic Integration for Employee Central"
Date: January 22, 2025
Time: 12:00 PM EST / 18:00 CET

This session is particularly valuable for customers who:

Are maintaining legacy integrations alongside Employee Central (on-premise, third-party, and/or using bespoke integration tools)
Want to improve their integration operational excellence and/or modernization timeline

Topics to be covered include:

HR customer success stories of using SAP Integration Suite with Employee Central
Frameworks for assessing your current needs and facilitating discussions about integration
Integration ROI examples
Debunking common misconceptions about SAP Integration Suite

Registration Link: https://us06web.zoom.us/webinar/register/WN_-zjq5jhRSwmRvKkDN68SjA

SAP Enterprise Integration Strategy - Integration Solution Advisory Methodology (ISA-M)

2025-01-14T16:25:13.280000+01:00

The Phases of the SAP Integration Solution Advisory Methodology

Below are the phases of SAP Integration solution advisory methodology,

Assess your integration Strategy
Design your hybrid integration platform
Define Integration Best Practices
Enable a Practice of Empowerment

Let's discuss them below,

1. Assess Your Integration Strategy

In order to initiate the process, the integration architects needs to analyze the to-be integration architecture landscape, in order to do that, there are three key parameters,

Integration Domains
Integration Styles
Integration Use Case Patterns

Integration Domains:

The integration domains refers different integration touch points in todays cloud and hybrid solution landscapes, for instance in today's hybrid landscapes, cloud system is communicating with either cloud applications or on-premise applications and vise versa, are example integration domains. Below are the currents scope of integration domains,

Integration Domain Description

Cloud2Cloud	Integration of cloud-based business applications with other cloud-based business applications
Cloud2OnPremise	Integration of cloud-based business applications with business applications that are deployed on premises
OnPremise2OnPremise	Integration of business applications that are deployed on premises
User2Cloud	Integration of cloud-based business applications with user-centric applications
User2OnPremise	Integration of business applications that are deployed on premises with user-centric applications
Thing2Cloud	Integration of cloud-based business applications with real world objects (Internet of Things)
Thing2OnPremise	Integration of business applications that are deployed on premises with real world objects (Internet of Things)

Download the Integration Domain Scoping Template

Integration Styles:

Integration styles represents the key integration architecture types, which explains how the integration scenario should look like between the business application and the target.

Currently the ISAM includes the below 5 styles,

Process integration: Connects business processes across business applications and further entities.
Data integration: Synchronizes or accesses data across business applications and data sources.
Analytics integration: Exposes data from data sources to support business intelligence.
User integration: Integrates user-centric applications with business applications.
Thing integration: Integrates real-world things with business applications.

Integration Styles Decision Criteria Process integration Data integration Analytics integration User integration Thing integration

Objective	Chaining of business processes	Synchronization of data	Deriving business insights from business applications and data sources	Omni-channel access to back-end applications	Capturing and processing of real-world data
Interaction type	System-2-system	System-2-system	System-2-user	User-2-system	Thing-2-system
Coupling to application	Process-level	Data-level	Data-level / business-level	User interface level	Thing event
Primary trigger	Application event	Schedule or application event	User event	User event	Thing event
Urgency of completion	(Near) real time	Batch or near real time	(Near) real time or batch	(Near) real time	(Near) real time or batch
Unit of data exchange	Single objects	Bulk-data or single objects	From aggregated to line-item data	Single objects or bulk-data	Single objects or bulk-data
Specific requirements	Transactional integrity Reliable messaging Message orchestration B2B protocol support	Data orchestration Complex transformations Data quality management Big Data processing	Local and remote data sources Data & predictive modeling, planning Data privacy & authentication Data volume	Online / offline support Device management End-user management Application management	Thing management Edge intelligence IoT protocol support Event stream processing

Typically an integration architect who has a solid understanding of integration requirements across business applications performs the scoping of integration style

Download the Integration Style Scoping Template

Integration Use Case Patterns:

Process Integration Style:
A2A Integration: Application to Application integration implement a message based exchange of transactional data.
Master Data Integration: Synchronizes the master data objects across multiple applications.
B2B Integration: Business to Business Integration exchanges electronically generated document across applications.
B2G Integration: Country specific organizations reporting and compliance with local requirements mandating the submission of electronic documents to authorities or business partners.

Data Integration Style:
Data Replication (ETL): Extract the data set and transforms under a specific schema and loads on the front end.

Data Virtualization: Creates a virtual abstraction layer as view which holds the data as a container.
Data Quality Management: Data from multiple sources consolidated at a single point through data cleansing and standardization.
Data Orchestration: A pipeline driven data integration approach for distributed processing for data across multiple and complex landscapes.

Analytics Integration Style:
Embedded Analytics: Charts and KPIs reports are embedded in a business application for both user interfaces and data.
Cross Application Analytics: Combines data from multiple data sources through a data warehouse or business intelligence solution.

User Integration Style:
UI Integration: Incorporates the user interfaces of different business applications in a single point of entry front end.
Mobile Integration: Incorporates the backend application services in a mobile application.
Chatbot Integration: Integrates the chatbots based communication through API consumption from business applications.

Thing Integration Style:
Thing to Analytics: Integrates the data from IOT devices and machines with analytical solutions.
Thing to Process: Exchanges data through triggering a physical object event(e.g. like robotic gears) within a business application.
Thing to Data Lake: Enables the collection of thing or machine data such as time series data into a data lake for predictive analysis.
Thing to Thing: Enables machine to machine communication like devices and robots transmits messages to each other via sensors.

Cross Use-Case Patterns:
API-Managed Integration: Two way secure access to business applications through usage policies and controlled access.
Event-Driven Integration: Business events based loosely coupled asynchronous communication where an event represents a state of change in the business object.
Stream Analytics: Process streams of incoming event data in real time, collecting feedback on incoming information.
Process Automation: Automates business processes and workflows tasks across business applications.
Digital Integration Hub: Enables APIs in business applications in large scale by inserting a high performance data store layer in between through a decoupled style.

2. Design Your Hybrid Integration Platform

Below are the steps in order to design the hybrid integration platform,

Technology Mapping
Integration Policies
Interface Assessment

1. Technology Mapping:

Technology Mapping are supposed to describe the high level building block in order to to design a Hybrid Integration Platform. For instance a integration technology requiring more than one integration technology, like a Unified Approval Application, consuming data from various sources and different middleware technologies coming in the picture.

Use case :

For a B2B integration, companies may use a combination of B2B gateways and Enterprise Service Buses (ESBs) for exchanging documents with trading partners while also integrating with internal systems using APIs.

2. Define Your Integration Policies:

Once you have specified the scope of your hybrid integration platform through technology mapping, you can specify one or more for each technology as well, this will work as a guideline for the integration developers and help them to identify required technology for a new requirement.

- Develop a guideline of Integration policies for integration domains and styles, in order to select the right technology for various Integration scenarios, this can be general recommendations, reasonable alternatives, possible exceptions, and techniques for an organized landscape.

Use Case:

Set a policy for all new cloud native applications to use cloud based Integration tools but allow the legacy systems for on-premise solutions till there is an other alternative for them.

Download the Integration Policy Template

3. Assess Your Interfaces:
- For each new requirement, the most suitable integration technology or the combination of technologies should be assessed as part of Interface Assessment Policy. For e.g. The integration between the SAP Success Factors with S/4 HANA, When integrating SAP SuccessFactors with SAP S/4HANA, the interface assessment would help determine whether a data replication solution or an API-based integration is more appropriate.

Use Case:

For large scale organizations transitioning towards a hybrid IT landscape, the technology mapping may align for using the SAP Analytics Cloud for business intelligence, SAP Data Intelligence for data processing, and SAP Integration Suite for API management. So these technologies would work together to facilitate integration scenarios from master data synchronization (Data Integration) to real-time transactional process integration (Process Integration), In this manner, interface assessments guides towards the integration development process while policies ensure that the best technology is used for each case.

Create a Business Solution Request and Interface Request

3. Define Integration Best Practices

Below are the steps in order to define the Integration best practices,

Specify Your Integration Dos and Don’ts
Create Your Architecture Blueprints
Create Tailored Development Guidelines

Integration architects can derive integration standards for their organizations. This makes it possible to channel the integration demand through well-defined processes and to implement integration solutions based on company best practices. For this purpose, the SAP Integration Solution Advisory Methodology foresees best practices such as integration dos and don'ts, architecture blueprints, and integration development guidelines.

1. Specify Your Integration Dos and Don’ts
- Dos: Use integration packages to reduce development effort, prefer asynchronous messaging for better scalability, and avoid tight coupling between applications.
- Don’ts: Avoid synchronous calls unless necessary and steer clear of complex integration chains that are difficult to monitor.

Download the Integration Dos and Don’ts Template

2. Create Your Architecture Blueprints
Develop visual blueprints to map integration technologies and their interactions with business applications, such as Cloud2OnPremise or API-managed integration. These blueprints help define the integration scope.
For example:
- A Cloud2OnPremise blueprint might detail how cloud-based applications are integrated with on-premise systems.
- An API-managed integration blueprint could show how APIs are used to facilitate communication between different systems.

The below is the architecture blueprint sample of the cross-use case pattern “digital integration
hub” for the integration domain Cloud2OnPremise.

Download the Integration Development Guideline Template

3. Create Tailored Development Guidelines
Prepare specific development guidelines, such as naming conventions and best practices for error handling, that align with your organization's technology and business needs.
For example, in a project where SAP S/4HANA needs to be integrated with SAP SuccessFactors, the development guidelines could define:
- How to handle data synchronization between both systems.
- The specific integration tools and technologies to be used, such as SAP Cloud Platform Integration (CPI).
- The best approach for ensuring data consistency and system reliability during integration.

Use Case:
Case: Hybrid Integration Platform with SAP Integration Suite
Consider an organization implementing a hybrid integration platform using SAP Integration Suite to connect cloud-based applications like SAP SuccessFactors (for HR management) and on-premise solutions like SAP S/4HANA (for ERP). The integration scenarios involve transferring employee master data between SAP SuccessFactors and SAP S/4HANA.

- Dos:
- Use SAP Integration Suite's prebuilt connectors to simplify the integration process.
- Prefer near real-time data transfer for employee data to ensure that business processes in SAP S/4HANA are always up-to-date.
- Apply asynchronous messaging patterns for HR data synchronization to handle high volume without impacting performance.

- Don’ts:
- Avoid relying on batch processing for employee master data updates, as this can lead to delays in critical business processes.
- Do not couple the SAP SuccessFactors HR module tightly with SAP S/4HANA without clearly defined integration points, as this can complicate the maintenance of the system.

4. Enable a Practice of Empowerment

Below are the steps in order to Enable a Practice of Empowerment,

Establish the Right Organizational Structure
Introduce Integration Governance
Ensure Integration Quality Assurance

Key Tasks:
1. Establish the Right Organizational Structure: Create clear roles and responsibilities to empower decentralized teams, like an Integration Center of Excellence (CoE).
- Example: A CoE provides guidance and support for integration projects, ensuring consistency with the strategy.

2. Introduce Integration Governance: Set up frameworks to manage integration projects, ensuring compliance and consistency.
- Example: Regular audits and policies for data handling, API security, and error management.

3. Ensure Integration Quality Assurance: Implement practices like testing and performance monitoring to ensure reliable and scalable integrations.
- Example: Automated testing tools to validate data flows between SAP S/4HANA and SAP SuccessFactors.

Use Case:
In an integration scenario involving SAP S/4HANA and SAP SuccessFactors, an empowered integration team could be organized within an Integration Center of Excellence (CoE). The team would follow well-defined governance rules, including compliance with data security policies and the use of standardized APIs for communication between systems. The team would also perform regular integration testing to ensure data consistency across the systems and use tools like SAP Integration Suite for effective management of the integration lifecycle.

Download the Integration Development Guideline Template

By using the SAP Integration Solution Advisory Methodology you can raise the maturity level of your Enterprise Integration Strategy from an ad hoc integration towards a systematic modular approach based on your organization standards by establishing integration as a recognized discipline that empowers the digital transformation journey.

References:

SAP Integration Solution Advisory Methodology | SAP Help Portal

Checklist for Service Procurement Integration SAP Fieldglass, Ariba and S/4HANA Solutions

2025-01-20T22:25:31.222000+01:00

Welcome to the Checklist for Service Procurement Integration SAP Fieldglass, Ariba and S/4HANA Solutions

Target Audience

This blog is for implementors and administrators from customer and partner organizations. It’s a living document that will be updated regularly, so bookmark this page and revisit for the latest insights. Got a question? Drop it in the Q&A section at the bottom of the page!

Why Service Procurement Integration Matters

Did you know that employees now make up only 58% of workforce spend? The other 42% goes to external resources. This data, from Services Procurement Insights: The Big Reveal, underscores the rising importance of managing external services efficiently.

In today’s business landscape, organizations come from diverse backgrounds and unique journeys. This heterogeneity can make service procurement integration challenging. But here’s the good news: streamlining your Purchase Requisition (PR), Purchase Order (PO), Service Entry Sheets (SES), and Invoice processes can give you tighter control over your procurement lifecycle.

Why is this critical? For one, you don’t want to fall victim to scams where fraudulent invoices got paid. Tight integration can help you avoid paying for services without authorized POs and verified proof of delivery. (funny but real story)

The Benefits of Integration

Integrating PR/PO, SES, and Invoice processes isn’t just about compliance; it’s about transformation. Here’s what you stand to gain:

Fraud Prevention: Never pay invoices without an authorized PO and proof of service delivery.
Enhanced Visibility: Get a complete picture of your service procurement spend.
Improved Compliance: Stay audit-ready and meet regulatory standards.
Streamlined Performance: Reduce inefficiencies and manual interventions.

Your Options for Integration

Here are three solid solutions for integrating end-to-end service procurement applications:

ERP Add-on by ASAPIO

For customers on SAP ECC or S/HANA MM-SRV

22K Solution

For Customers who prefers direct integration between SAP Fieldglass and SAP S/4HANA (lean services)

4R2 Solution

For Customers who like to integrate SAP Fieldgalss and SAP S/4HANA(lean services) via SAP Ariba

Questions to Answer Before You Start

Before diving into implementation, take a moment to reflect on these key questions:

What cost objects will your services spend be allocated to?

Think cost centers, internal orders, maintenance orders or projects. Clarifying this early will guide your financial postings.

What version of SAP S/4HANA are you using?

Features and compatibility often hinge on your specific SAP S/4HANA version (MM-SRV vs lean services a key decision criteria). For customers who are adopting SAP S/4HANA Cloud, they will automatically start only on lean services however many customers on-prem or private cloud may need to take care of this migration. MM-SRV to lean services migration can be found here: Link: https://me.sap.com/notes/2906140

Why can integration be complicated?

Integration complexity grows exponentially due to:

Types of cost objects
Business documents (PR, PO, SES, Invoice)
Actions like create, revise, or close

What about performance considerations?

A major bottleneck can be the number of SES entries per single PO line item. Plan your system design to avoid performance issues.

Let’s Hear From You!

Have questions, thoughts, or tips to share? Drop them in the comments below, and let’s start a conversation!

Content Enricher & Request Reply in sap cpi

2025-01-21T19:44:04.703000+01:00

SAP CPI Request Reply & Content Enricher:

Request-Reply :
Description: Calls an external receiver system synchronously and retrieves a response.
Use Cases: Certain integration scenarios require the Cloud Integration tenant to communicate with an external service, retrieve data, and further process it. In such cases, you can use the request-reply step as an exit point to connect to the external service.
Content Enricher:
Function: The content enricher adds the content of a payload with the original message during an integration process. This process combines the two separate messages into a single enhanced payload.
Purpose: This feature enables you to make external calls during an integration process to obtain additional data.
Here two tabs are there
1.General: we give meaningful name.
2.Processing: here we can perform the operations.
Aggregation Algorithm: Here two options presents.
You can choose between two strategies to enrich these two payloads into a single message:
Combine: Combines the original and lookup messages. You cannot define any rules for combining messages with this strategy.
Enrich: Enables you to define paths to specific nodes and key elements within the original and lookup messages. The original message is enriched with data from the lookup message based on these paths.
Original Message: The first message in the integration flow.
Path to Node: Path to the reference node within the original message.
Key Element: Key element within the original message.
Lookup Message: The message obtained by making an external call during the integration process.
Path to Node: Path to the reference node within the lookup message.
Key Element: Key element within the lookup message.
Example: Using OData Adapters
OData Adapter: This adapter exchanges data with a remote component that might be outside the scope of SAP.
https://services.odata.org/V2/OData/OData.svc/
Scenario: We will use a product catalog as the resource for the original message (obtained using a request-reply step with an OData adapter) and add to incoming payload place a supplier list as the resource for the lookup message (also obtained using a Content enricher step with an OData adapter).
Enrichment Strategy:
First Scenario: Combine
This option simply combines the two payloads without any modification.
Second Scenario: Enrich
This option merges the two payloads into a single payload based on specified conditions.
Outputs:1. Combine

2.ENRICH:

Service procurement end to end Integration with SAP Fieldglass and SAP S/4HANA(22K)

2025-01-22T21:28:02.899000+01:00

SAP’s S/4HANA and Fieldglass solutions offer a comprehensive approach to streamline the end-to-end process(via scope item 22K)—from job postings to payments for contingent, SOW and SOW workers. Let’s dive into the key process flow, business benefits, and standout features that make this integration a game-changer.

Key Process Flow

Create Purchase Requisitions: Generate purchase requisitions in SAP S/4HANA for each job posting and statement of work after creating a work order.
Approve Purchase Requisitions: (Optional) Approve requisitions directly in SAP S/4HANA.
Create Purchase Orders: Convert approved requisitions into purchase orders in SAP S/4HANA Cloud Public Edition.
Approve Purchase Orders: (Optional) Approve purchase orders within SAP S/4HANA.
Submit Time for Approval: External workers log their time in SAP Fieldglass, which is then submitted for managerial approval.
Create Service Entry Sheets: Generate service entry sheets in SAP S/4HANA. Approval is optional but can be enabled with minor configuration tweaks.
Propose Invoices: Suppliers receive invoice proposals based on submitted time data in SAP Fieldglass.
Post Invoices: After supplier approval, invoices are posted in SAP S/4HANA.

Business Benefits

Integrating SAP S/4HANA and SAP Fieldglass delivers numerous advantages, including:

Timely and Automated Payments: Reduce the cost and risk of outstanding payments with automated processes.
Accurate and Compliant Booking: Ensure precise recording of time and expenses for the external workforce.
Enhanced Productivity: Streamline workflows with integrated purchase requisitions, purchase orders, service entry sheets, and supplier invoices.
Improved Data Consistency: Achieve seamless data replication from SAP S/4HANA to SAP Fieldglass for reliable system-wide consistency.

Key Features of the End-to-End Process

1. Faster and Accurate Close with Self-Billing

Self-billing, also known as Evaluated Receipt Settlement (ERS), automates the settlement of goods and service receipts. With ERS, suppliers agree not to submit invoices for purchase order transactions. Instead, the system automatically posts invoice documents based on purchase order and goods receipt data, eliminating invoice variances.

Benefits of Self-Billing:

Automatic settlement of service entry sheets
Prevention of invoice variances
Faster transaction closure
Elimination of non-value-added work
Centralized tax management

SAP S/4HANA’s scope item 22K supports this feature, allowing selective activation via supplier master data (look for ERS checkbox on supplier master data in SAP S/4HANA which will be replicated to SAP Fieldglass automatically via MDI).

2. Automatic Accruals Management

SAP S/4HANA integrates accruals management for unapproved time and expenses recorded in SAP Fieldglass. This feature ensures compliance with generally accepted accounting principles (GAAP) and enables timely cost and revenue recognition.

Value Proposition:

Recognize costs and revenue without delays
Ensure compliance with accounting standards

By leveraging SAP’s integrated solutions, organizations can streamline workforce procurement, improve accuracy, and drive operational excellence. Whether it’s automating self-billing or managing accruals, the possibilities are transformative. Ready to explore these capabilities?

Optimizing Production Order Process: Leveraging SAP BTP Event Mesh for Decoupling Inbound Scenario

2025-01-23T16:59:29.683000+01:00

We were working on a scenario for a greenfield implementation project, with the initial phase focused on a newly built plant. The technologies used included SAP S/4HANA Private Cloud, Integration Suite on Cloud Foundry, and a third-party Manufacturing Execution System (MES). The scenario revolved around the production order process, encompassing activities like backflush and confirmations.

For confirmations, we employed the Auto GR (Goods Receipt) process. From a technical standpoint, we planned to implement API-based development and integrations, adhering to SAP best practices. Before diving into the technical solution, let me first provide the context of the problem and the reason for the change.

In the initial phase, the design dictated that SAP S/4HANA would expose only the OData APIs required for the production order process, while the MES team would handle the remaining responsibilities. You may already be questioning this approach, and rightfully so—I completely agree. There was indeed a flaw in the design process, but by the time it was identified, it was too late to implement major changes. We had no choice but to proceed with the existing design, while remaining open to revisiting it in the future.

Problem Statement: We implemented the design as planned, where the MES system utilized Azure technologies to make calls and process confirmations and backflushes. Initially, everything functioned well due to the low volume of data. However, as the shop floor operations scaled and multiple systems began simultaneously triggering GR (Goods Receipt) and backflush requests, the system started throwing errors.

The issue stemmed from API-level locking inherent in SAP’s design, where only one request could process a production order at a time. If a request was already being processed, subsequent ones failed due to the lock. Additionally, the second flaw was that the MES team could only see the default error response code provided by the OData API. This lack of visibility left the S/4HANA team unable to provide effective support or handle exceptions.

The SAP S/4HANA team could not provide support or implement exception handling due to the absence of an application layer or any development and integration mechanisms to monitor errors effectively. After analyzing the issue, we requested the MES team to implement a 5-second delay for processing confirmations and backflushes. While this solution initially worked for a few orders (around 10), it quickly failed under higher data volumes, as the same error reoccurred.

To address this recurring issue, we brainstormed alternative approaches and proposed introducing Event-Driven Architecture (EDA) into EDA into the landscape. This approach involved leveraging SAP Event Mesh on SAP BTP and building an integration layer using SAP Integration Suite to process the data efficiently. The resulting high-level architecture offered a scalable and resilient solution to overcome these challenges.

Let me explain the steps we followed to implement the solution.

Prerequisites

Before proceeding, ensure that SAP Event Mesh (EM) is activated in the SAP Business Technology Platform (BTP) with the necessary roles and authorizations. Once the prerequisites were met, we completed the following configurations.

It is important to note that when activating EM, you must create a service key specific to the Event Mesh. To receive data, you need to share the service key credentials for EM. A common mistake I have observed is sharing the Cloud Integration service keys instead of the Event Mesh service key. These two are not the same, and the service key in SAP BTP serves a specific purpose.

Steps to Configure Event Mesh

Create a Queue in Event Mesh:

The queue serves as a receiver for the data to be processed by the system.

Bind the CPI Endpoint to the Queue:

Configure the integration flow endpoint in the SAP Cloud Integration Suite as a webhook to the queue. This ensures that incoming messages from the queue are routed to the integration flow for processing into SAP S/4HANA.

Create a Dead Queue:

Typically, dead queues are used to handle exception messages. However, in this scenario, we repurposed the dead queue to log and reprocess lock errors. I’ll explain this usage further.

Configure the Integration Flow:

Initially, we considered creating a custom integration flow to handle this, but we found pre-packaged integration content that streamlined the implementation. The package is available in the SAP Integration Suite Discover section under the name “Replay Messages from Queues via SAP Event Mesh”.

Using the Pre-Packaged Integration Content

The package contains four artifacts, each with a specific purpose. However, we utilized only three artifacts as there was no need to leverage value mapping which was the fourth artifact.

Retrieving Messages from SAP Event Mesh to JMS:

This integration flow retrieves messages from SAP Event Mesh and sends them to the JMS queue.

JMS Router for SAP Event Mesh Messages:

The core integration flow routes messages from the JMS queue based on their type or purpose.

Processing Messages:

This flow processes the JMS messages retrieved from SAP Event Mesh and sends them to SAP S/4HANA.

By utilizing this pre-packaged content, we eliminated the need to develop a custom solution from scratch, saving significant time and effort. The setup allowed us to handle and process messages efficiently while addressing exceptions such as lock errors through the configured dead queue.

Exposing an Event Mesh (EM) Endpoint to Receive Data

Once a queue is created in SAP Event Mesh, you need to use a prefix to publish or consume the data. Instead of duplicating existing content, I recommend referring to this Exposing EM Endpoint that provides detailed steps for exposing an Event Mesh endpoint.

What We Achieved Compared to the Initial Problem

After implementing the Event-Driven Architecture (EDA) and exposing the Event Mesh endpoint, we addressed several challenges outlined in the initial problem statement. Here’s what we achieved:

Added a Technology Layer to Monitor the Process:

By introducing SAP Integration Suite and Event Mesh, we gained better visibility and control over the transaction flow.

Decoupled the Process Using EDA:

The MES system was no longer directly coupled to SAP S/4HANA, reducing dependencies and bottlenecks.

Streamlined Transactions from MES to S/4HANA:

Transactions flowed seamlessly from the MES system into SAP S/4HANA, thanks to the event-driven approach.

Eliminated MES Exception Handling for Lock Issues:

The MES system no longer handled API lock issues, as the Event Mesh took over and returned 204 responses (success status).

Enhanced Monitoring in SAP Integration Suite:

All S/4HANA transactions received from the MES system could now be monitored and managed effectively in the SAP Integration Suite.

Automatic Processing of Lock Issues with Dead Queue:

Using the Dead Queue concept, API lock issues were processed automatically until successful, ensuring consistency.

Integrated Exception Handling for Data Issues:

Alerts for data-related issues were integrated, allowing the data team to address problems promptly.

How We Used the Dead Queue to Process Messages

The Dead Queue concept was applied with a unique approach. Here’s how it worked:

Handling API Lock Issues:

When multiple transactions were processed simultaneously, any transaction encountering an API lock was written to the Dead Queue.

Custom Integration Flow:

A copy of the standard integration artifact was created, designed to read messages directly from the Dead Queue.
The custom flow repeatedly processed the messages until they were successfully posted.

Outcome:

This approach allowed us to monitor and handle transactions with lock issues effectively.
We could tally the total number of messages processed from the MES system to SAP S/4HANA, ensuring all transactions were accounted for.

Solution to COGI Errors and Decoupling GR and Backflush

After rigorous testing, we concluded that the EDA architecture effectively resolved the primary problem. However, we encountered COGI errors due to standard BAPI locks during the final posting to S/4HANA. To address this, we implemented the following solution:

Decoupling GR and Backflush Processes We introduced changes to separate the Goods Receipt (GR) and Backflush processes, reducing contention at the BAPI level.
1. - Decouple GR and Backflush Process for a detailed explanation of how we decoupled the processes.

Final Results

With these enhancements, we successfully processed hundreds of orders simultaneously. By leveraging Event-Driven Architecture and decoupling critical processes, we significantly reduced system dependencies and resource contention.

For high-volume, scalable implementations, I strongly recommend using EDA and decoupling processes wherever possible. This approach not only reduces system dependencies but also enhances performance, monitoring, and resilience.

Note: I have not purposefully included the technical details are there are many blogs from our experts detailing how to use the EM. Incase if you have specific questions please reach out to me.

Regards

Welcome to the Integration Group in SAP Community!

2025-01-24T17:57:50.069000+01:00

We’re thrilled to announce the launch of the Integration Group, a dedicated space within SAP Community where integration developers can connect, collaborate, and innovate. Whether you’re a seasoned professional or just starting your integration journey, this group is designed to support your efforts in accelerating innovation through integration.

What’s in it for you?

This group serves as your hub for:

Asking questions and staying updated with latest feature releases for SAP Integration Suite and SAP Integration Suite, advanced event mesh.

Exploring and discussing topics like application integration, API lifecycle management, and event streaming.

Sharing your expertise and learning from fellow community members.

Collaborating on ideas and projects that push the boundaries of integration innovation.

Getting Started

Here’s how to make the most of this group:

Join the Group: While anyone can browse the content, you need to join the group to contribute and participate actively. By joining, you’ll also receive notifications for updates on subscribed content.

Need help? Check out the Getting Started content in the Help section.

Follow the Rules: We’re committed to maintaining a respectful and productive environment. Make sure to follow the SAP Community Rules of Engagement.

Our moderators will ensure that discussions remain relevant and valuable to all members.

Label Your Content: When creating discussion posts or blogs, create labels for your content using Message User Tags to label your content. This helps improve organization and makes it easier for others to find and engage with your contributions.

Shape the Group’s Future

This group will evolve based on your input. We’re eager to hear your ideas for topics, content formats, or features that you’d like to see here. Share your suggestions freely - this is your community, and your voice matters!

Let’s Innovate Together

The Integration Group is built to bring people together, engage in meaningful conversations, and drive innovation in integration. We encourage you to participate actively, share your knowledge, and collaborate with peers.

With that, welcome to your new integration hub. Let’s build, share, and grow together. Join the group now and start your journey with us!

We can’t wait to see how this group grows and evolves into a collaborative space for integration enthusiasts through your contributions. Let’s innovate together!

Feel free to join the new Integration group in our community

2025-01-30T12:37:08.682000+01:00

You may have seen the announcement from SAP's Chief Product Officer for SAP Integration Suite about the launch of a new Integration group, a dedicated space within our SAP Community meant to collaborate across different integration topics.

Feel free to join this Integration group to exchange information, ask questions, post blogs posts etc. across different integration topics all under one hood, such as SAP Integration Suite and its capabilities like Cloud Integration, API Management, (Advanced) Event Mesh, Graph, etc., interface development as well as monitoring and error handling with SAP Application Interface Framework, integration strategy, etc.

What does this now mean for the topic pages such as the one for SAP Integration Suite?

Well, the topic pages remain, here you find all relevant information about the respective products like product documentation, roadmap information, new features, learning information, best practices, etc.

However, when accessing community content and creating new content, we have changed the navigation to ease the collaboration within the new Integration group. Let's check how this looks like for the SAP Integration Suite topic page.

The Community content menu now points to the new group. So, from here you can directly navigate to the Integration group.

The Create content has three entries:

You can Create a Question: this will create a new question below Technology Q&A which is automatically tagged with SAP Integration Suite. Note, this question won't show up in the group.
You can Start a Discussion: this is similar to asking a question but this time you navigate to the Discussion board of the Integration group.
You can Create a Blog Post: here you navigate to the Blog posts board of the Integration group where you are able to create a blog post which will then show up in the group.

By intention, we do not directly enter the discussion editor or the blog posts editor of the group but rather open the boards so that you are aware that you have navigated to the group. When you create a discussion or a blog post, don't forget to tag your post. Your content will show up in the group and depending on the tag also in the respective Community pages.

If you still like to access the Community pages, we have now added all links into the navigation pane of the topic page. Within the Community pages, you can also post content, but unfortunately this won't be shown in the group.

Enjoy collaboration! See you in the group then.

SAP’s Shift to Open Standards – A Strategic Move or Happy Accident?

2025-02-04T18:08:09.112000+01:00

Introduction

11 years ago, when I began my career as an SAP Integration consultant, often times when I google for work related research, I’d see results from SAP SCN and SAP help pages only. Today, what has changed is that, I see results on the same question/theme, being addressed by blogs/sites that have nothing to do with the SAP tool/platform on which, I am working currently. But the answer/content that I read there somehow turns out to be highly relevant to the issue/topic I am researching currently, on the SAP tool/platform that I am working with.

Upon reflection, as a broader trend across various SAP products and platforms, there seem to be a strong adoption of industry standard technologies, protocols & frameworks, which in many cases are open-source as well. While SAP’s proprietary standards have influenced others in the ERP industry for a long time, this remarkable departure and SAP gravitating towards standards in many aspects, is something that prompted me to connect the dots and to share with the community. In this post, I’d like to list a few of the areas, where I have noticed this trend:

1) Integrations:

REST, ODATA APIs encouraged instead of bapi/rfc, proxy, Idoc
Edge Integration Cell is based on Kubernetes containers, which is industry standard to package & distribute workloads, a necessary evolution from the SOA style platform that SAP PI/PO used to be.
Well documented APIs in Business Accelerator Hub than in PI/PO days
SAP Cloud Integration being based on Apache camel open-source framework. By extension, this facilitates direct support for camel expression language as well as various enterprise integration patterns – like splitter, router, gather, join in the Iflow design.
Integration advisor’s crowdsourced ML based mapping recommendation, supports conversion of canonical data model to standard EDI formats like ANSI X12, EDIFACT and vice-versa.

2) Platform choices:

Choice of hyperscaler platforms – Azure, AWS, etc. allowed to be exercised by the customer. This makes SAP an ERP Software selling company.
Runtime environments such as Cloud Foundry & Kyma are open-source. (Further reading)

3) Application Development:

Support for Java, JavaScript (node js), in addition to ABAP as tech stacks. This is a big step in utilizing coding skills available in the market.
BAS and Build Code being Git friendly.

4) Broader BTP services:

Application logging service in BTP uses Kibana (an open-source project)
KServe, an open-source Model Inference Platform on Kubernetes, being used behind the scenes by AI Core.
Redis & Postgres hyperscaler offering in addition to the proprietary HANA DB.
Evolution of UX/UI from proprietary SAP GUI to Fiori / UI5 based front-end. OpenUI5 is a JavaScript UI Framework released by SAP under the Apache 2.0 license.

Conclusion

SAP’s growing adoption of open-source technologies and industry standards doesn’t just seem to be accidental, but based on a conscious vision, as reflected in the SAP Open-source Manifesto. This shift benefits both customers and developers by fostering interoperability, flexibility, and innovation in the SAP ecosystem.

Disclaimer: My observations are based on my exposure to SAP BTP & ERP only and this trend might not apply or apply differently across SAP’s other product lines.