SAP Community - SAP Integration Strategy

Certification for Partner AI Apps on SAP BTP – Ensuring Reliability, Responsibility, and Relevance

2024-07-04T10:06:55.781000+02:00

UPDATE - Exclusive Offer: Certification for Partner AI Applications on SAP BTP available for FREE

Overview:

As technology continues to advance at a rapid pace, businesses are seeking innovative solutions to maintain their competitive edge. Development of AI applications has the potential to transform the way companies operate and serve their customers.

Organizations are leveraging the robust capabilities of SAP Business Technology Platform (SAP BTP) to build, integrate, and extend applications in the cloud. The platform's extensive suite of tools and services allows for the creation of secure, scalable, and intelligent applications with significant business impact. With the addition of the generative AI hub in SAP AI Core, businesses have access to a wealth of AI development resources, including pre-trained models, data annotation tools, and custom AI model training. By utilizing these tools, companies can harness the power of AI to build predictive, personalized applications that drive value for their customers.

SAP BTP: Empowering Applications with Generative AI

SAP BTP empowers our application portfolio by enabling the integration of generative AI. This platform facilitates the seamless embedding of AI features and process innovations across SAP and partner applications, offering the following impactful advantages:

Comprehensive AI Services: SAP BTP provides a wide range of generative AI services that can be incorporated into applications, including code generation, automation, and extensibility.
Enterprise-grade Integration: Our platform ensures that all AI integrations are trusted, compliant, and enterprise-ready, utilizing SAP’s business data to deliver robust AI capabilities.
Driving Innovation: Partners can harness the generative AI capabilities to develop cutting-edge AI applications, whether they are creating new apps or transforming existing ones.

Launching certification program for partner AI applications:

Are you a partner looking to certify your AI application for use on SAP BTP? Look no further! SAP Integration and Certification Center (SAP ICC), as part of SAP Partner Innovation Lifecycle Services (PILS) offers a certification program specifically designed to ensure that partner AI apps running on SAP BTP meet the highest standards of reliability, responsibility, and relevance.

The certification program covers technical integration and responsible AI criteria, offering a comprehensive scope to ensure that your app meets the necessary requirements.

Certification requirements for Reliable AI include:
- Development and implementation following the respective SAP development and best practice guidelines, such as the BTP AI Dev Guide
- Utilization of generative AI hub capabilities in SAP AI Core
- Use of other relevant BTP services (reference: SAP Discovery Center - Services)
- Deployment of the Partner app on the SAP BTP runtime environment

Certification requirements for Responsible AI include:
- Must adhere to guiding principles and ethics as outlined in SAP Global AI Ethics policy leveraging the SAP AI Ethics Handbook during all stages of the development lifecycle
- To ensure compliance, business scenario and AI ethics policy for the AI application will be carefully reviewed using a structured assessment process.

Certification requirements for Relevant AI include:
- Integration with SAP solutions as applicable for your business need, utilizing released APIs as documented in SAP Business Accelerator Hub, where applicable.
- Execute representative functional end-to-end test cases of the application.

Upon completion of certification, it ensures that your app is not only technically sound, but also ethically responsible.

You will be awarded with ‘SAP Certified – built with SAP Business AI’ logo and your certified solution details will be listed in SAP Certified Solutions Directory

Benefits of certification for Partners:

By having the AI application tested by SAP, our partners can unlock numerous benefits, including:

Trust & Credibility: Achieving Certification is a powerful testament to a partner's commitment to quality and technical excellence. It instils trust in customers and prospects, assuring them that the certified solution run on SAP BTP and technically integrated with SAP solution.
Innovation: Embrace cutting-edge AI technologies to drive innovation and stay ahead of the competition.
Growth: Showcase advanced AI capabilities to enhance service offerings and attract new clients, driving business growth.
Competitiveness: Deliver more intelligent, responsive, and personalized solutions to gain a competitive edge in the market.

What Next:

By obtaining certification for your AI app on SAP BTP, you can demonstrate to your customers that your app meets the highest standards of reliability, responsibility, and relevance, giving them the confidence to use it in their business processes. Don't miss out on this opportunity to showcase your app's capabilities and join the ranks of certified AI apps on SAP BTP!

Apply today for the AI application certification directly at the SAP Partner Benefits Catalog (PBC).

This blog post is brought to you by the SAP Integration and Certification Center. For more information on our services and certifications, visit our website.

Create DataType and Message Type artifact in Cloud Integration capability of SAP Integration Suite

2024-07-10T10:43:24.414000+02:00

Introduction

SAP Cloud Integration version 6.54.xx comes with new feature, where in one can create Datatype and Messagetype as reusable design time artifacts in Cloud Integration capability of SAP Integration Suite

This feature is available only in SAP Integration Suite standard and above service plans.

SAP Cloud Integration version 6.54.xx software update is planned on mid of July 2024 (date and time subjected to change).

Create DataType :

1. Open the Integration Suite Tenant and navigate to Design -->Integrations and API's

2. Create an Integration Package or open an existing one.

3. Navigate to the Artifacts tab and click on Edit in the top right corner

4. Click on Add drop down and select Data Type from the list

5. Add Data Type dialog is displayed with Create (radio button) selected by default.

6. Enter the values for the fields Name, ID,Target Namespace, Description ,select the category - Simple Type(selected by default) or Complex Type for the Datatype you want to create and click on Add or Add and Open in Editor

7. On Click of Add, the Data Type artifact with the provided name gets created and is listed in the Artifacts list page

8. On Click of Add and Open in Editor, the Data Type artifact gets created with the provided name and the artifact gets opened in the Editor in display mode.

9. The Editor contains three tabs : Overview,Structure and XSD.The Structure is shown by default when the artifact is opened. It displays the structure of the datatype in a tree table with the following columns :

Name : Contains the Name of the node(element or attribute).For Root node the name is same as the name of the Datatype and it cannot be edited.
Category : This column shows whether the root element has subnodes or not . For root node it is either Simple type or Complex Type and for submodes it can be either Element or Attribute. You cannot change values in this column.
Type: This column displays the type with which the node is defined.Here you select a built-in data type or reference to an existing data type for an element or attribute. You must specify a type for attributes.
Occurrence: Determines how often elements occur.For attributes, you can determine whether the attribute is optional or required.
Restrictions : This column displays the facets (if any) defined incase the node is defined by a built-in primitive type or a user defined Simple type Datatype

9. Switch to edit mode and to define/build the Structure of the Datatype. On selecting the first row(rootnode),the Add drop down in the table header gets enabled (for category complex type) and also the details of the row are displayed in the right side section of the editor.

10. Simple Type Data Type :

No child nodes can be added
Root node is defined by string built-in primitive datatype.
Click on the root node and the Properties sheet which contains the details of the node selected is displayed on the right side of the editor. In Edit mode ,user can edit the Type ,define the restrictions applicable for the Type selected.

11.Complex Type Data Type :

To add child nodes:

Click on the root node and the Add drop down in the table header gets enabled.

Add -->Element to add child element node

Add -->Attribute to add attribute node

Add -->Rows to add multiple Elements/Attributes

Click on the newly added node and define the details in the Properties sheet

12. Once the Structure is defined,Click on Save to save the artifact as Draft, Save as Version to save the artifact as versioned artifact.

13. XSD tab displays the read only view of the xsd schema of the Datatype artifact

Create MessageType:

1. Open the Integration Suite Tenant and navigate to Design -->Integrations and API's

2. Create an Integration Package or open an existing one.

3. Navigate to the Artifacts tab and click on Edit in the top right corner

4. Click on Add drop down and select Message Type from the list

5. Add Message Type dialog is opened

6.Enter the values for the fields Name, ID, XMLNamespace, Datatype to be Used, Description, and click on Add or Add and Open in Editor

7. On Click of Add, Message Type artifact gets created and is listed in the Artifacts list page

8.On Click of Add and Open in Editor, MessageType artifact gets created and the artifact gets opened in the DataType Editor with Structure tab loaded by default in non-edit mode . The rootnode Name would be same as the Message Type name ,Category as Element and Type as Data Type Used (if selected in the Add Message Type dialog)

9. Overview tab in Edit mode is as shown below :

10 XSD tab :

11. Datatype Used to create a Message type can be changed in Overview tab or in Structure tab. Switch to edit mode and select the root node in the Structure tab.The properties sheet gets displayed on the right side of the page with Datatype Used field as editable.

12. No other nodes(child nodes) are editable in the Message Type artifact.

Next Steps: Deletion of element/Attribute nodes, Cut,Copy and Paste, Move up and Move Down,Drag and Drop actions to edit the structure of the Datatype

Simplifying SAP Implementations with Generative AI Innovations

2024-07-13T12:58:30.685000+02:00

The latest advancements in Generative AI have opened up new possibilities for simplifying SAP implementations, making it easier than ever to achieve seamless integration across various SAP environments.

The Role of Generative AI in SAP Integration
Generative AI, a subset of artificial intelligence focused on creating content and solutions based on given parameters, has found a significant role in SAP integration. These innovations help automate complex tasks, generate code snippets, and provide intelligent recommendations, reducing the time and effort required for SAP implementations.

Key Innovations in Generative AI for SAP

Automated Code Generation: One of the most important applications of Generative AI in SAP is the automated generation of integration scripts. Whether it's Groovy scripts for SAP Cloud Platform Integration (CPI) or ABAP code for SAP ECC, Generative AI can create code and adapt it based on specific business requirements. This drastically reduces development time and ensures consistency in coding standards.

Intelligent Mapping Recommendations: Data mapping is a critical aspect of any integration project. Generative AI can analyze existing data structures and suggest optimal mappings, taking into account data types, business logic, and transformation rules. This not only speeds up the mapping process but also enhances accuracy.

Natural Language Processing (NLP) for Error Resolution: Troubleshooting integration issues often involves through extensive logs and error messages. NLP-driven tools can interpret these messages and provide actionable insights or even resolve certain errors autonomously. This capability empowers integration specialists to focus on more strategic tasks.

Enhanced Testing and Validation: Generative AI can simulate various test scenarios and generate test data, ensuring thorough validation of integration workflows. Automated testing not only accelerates the implementation process but also improves the reliability of the integration solutions.

Proactive Monitoring and Optimization: AI-driven monitoring tools can predict potential integration issues based on historical data and current performance metrics. These tools can suggest optimizations to improve the efficiency and reliability of integration processes, ensuring smoother operations.

The Future of SAP Implementations

As Generative AI continues to evolve, its integration with SAP will become even more seamless and sophisticated. We can expect further advancements in automated documentation, dynamic integration scenario generation, and making SAP implementations faster, more efficient, and more accessible.

Embracing these AI-driven innovations is not just about staying ahead of the curve; it's about transforming the way businesses operate, enabling them to respond faster to market changes and achieve their strategic objectives with greater agility.

Conclusion
Generative AI is revolutionizing the landscape of SAP integration by simplifying complex tasks, enhancing accuracy, and accelerating implementation timelines. As these technologies continue to mature, they will unlock new possibilities for businesses to optimize their SAP environments and drive innovation.

SAP Integration Suite – Generative AI based Integration Flow Generation

2024-07-19T13:53:54.018000+02:00

Introduction

SAP Cloud Integration version 6.54.**, one of the capabilities of SAP Integration Suite, comes with an enhancement on Generative AI (GenAI) feature - GenAI based Integration Flow Generation. This feature will be available only in SAP Integration Suite Cloud Integration Premium Editions, on specific regions/data centres JP10, EU10, AP10, US10, EU10-003, EU10-002, and US10-002. This feature is forecasted to rollout during calendar week 29/30/31 2024 (tentative timelines, subjected to change as per phased rollout plan).

Update as of September 2024: This feature is now available on above mentioned regions.

Enabling GenAI Based Integration Flow Generation feature

As tenant administrator of your premium edition tenant, you need to enable this feature in Settings page of SAP Integration Suite. By enabling this feature, you need to agree to the relevant terms and conditions.

Below are the sample screenshots of the same

Settings Tab for Generative AI

Click on Edit

Switch ON the flag

Terms and Conditions

Clicking on Save button will display the user who has accepted the terms and condition. Click on Save and then click on Cancel button to come out of edit mode.

Generating Integration Flows

Once this feature is switched ON by the tenant administrator, you - as integration flow developer persona - can use this feature to generate integration flows.

The GenAI based integration flow generation makes use of the Unified Cloud Landscape (UCL) concept. For that, you need to configure your account’s System Landscape configuration with SAP Integration Suite formation and add the required systems in that formation.

If you have a successful SAP Integration Suite formation created with some systems (e.g. S4), the GenAI based Integration flow generation feature will browse the systems and APIs and lists them in the Sender and Receiver sections in GenAI based integration flow creation UI dialog, as shown in the screenshot below. For more information on how to achieve this, see Enabling System Landscape in SAP BTP Cockpit for SAP Integration Suite.

Below are the sample screenshots of System Landscape configuration with Systems with system type SAP Integration Suite (the sub-account where Integration Suite is subscribed to) and Formations of type of Integration with SAP Integration Suite formation type along with other systems participating in the integration.

Some sample systems added

SAP Integration Suite sample formation

In case if you have not enabled System Landscape configuration as above, the systems and API listings will not happen for Sender and Receiver systems, and these fields will be empty in the selection of GenAI based integration flow UI dialog.

Now, you click on Add -> Integration flow menu in your package view, you will be given option of generating the integration flow with assistance from AI or create integration flow manually. Below are the screenshots of generating integration flows using generative AI.

Click on Package Edit

Edit the package

Click on Add -> Integration Flow menu

Select Integration Flow

Choose GenAI based Integration flow generation option

Provide your scenario description and click on Send button

Observe the AI response and correct the description in case of suggestions

After correcting the description, click on send button again. If scenario description is correct, AI will list the sender and receiver systems from configured System Landscape infromation

Clicking on Select button will list other systems from System Landscape configuration

AI will suggest integration scenario name, you can change it

Click on Generate button to generate integration flow

Upon click on Generate button, an integration flow will be generated as shown in

Generated Integration Flow template

Observe the Timer flow step generated as per the schedule in scenario description in GenAI dialog

Sender system address configuration has been pre-filled as per the system discovery from System Landscape (UCL) information along with Receiver system

The generated integration flow will act as a template, you need to further configure the integration flow and/or update the integration with some more integration steps to match your end to end integration scenario requirement.

Note: As mentioned above, in case of issues in UCL, the systems and API listings will not happen for Sender and Receiver systems, and these fields will be empty in the selection of GenAI based integration flow UI dialog as shown in sample screenshot below. You can still continue the integration flow generation.

GenAI Integration Flow generation dialog when UCL systems & API discovery fails, sender and receiver fields will be empty.

This feature is currently provided on the basis of free and fair usage option. Due to this, you will be allowed to generate limited number of integration flows per tenant per calendar month for next 6 months. The exact number of integration flows generated with GenAI will be difficult to provide, because it depends on the scenario description you provided and the responses from GenAI backend, and back-and-forth communication, which ends up in consumption of GenAI transactions. If you exhaust these transactions, you will observe below information message.

GenAI Transaction limits exceeded

Summary

SAP Integration Suite – Cloud Integration GenAI based integration flow generation feature will help you bootstrap and accelerate the integration development activity.

As a first step towards the generative AI in integration, we have introduced this feature which currently able to interpret the scenario description and generate an integration flow with sender and receiver systems only. Going forward, we will be enhancing this offering to include mediation steps (e.g. converters, mappings etc.) based on the description on the integration scenario to generate more enriched integration flow.

Digital Transformation. View of an Enterprise Architect - Steps and Tips

2024-07-19T16:25:04.444000+02:00

#GenerativeArt

In 2021, I had already written a blog on the subject of architecture development, in which I wrote down my customer experiences during these days (Blog). As this approach is still valid today, I have integrated an updated version of this blog into the series. It is based on TOGAF and the SAP EAF.

Note: No licenses are required for the following procedure! If you already have licenses for SAP Signavio or LeanIX, for example, this makes the architecture work much easier

The following methodology is intended to serve as a lean, evolutionary option for architecture development, which primarily includes the active participation and cooperation of several parties, instead of relying exclusively on existing experts and wisdom. Because of this, a corresponding project should be viewed and accompanied from the perspective of the following business units:

Specialist Department

“Applications are computer programs that perform useful functions for the user” (Wikipedia).
The user must define in which business processes, sub-processes of his activity the software should support him (which capabilities must the application include?).

Project Sponsor (Board of Directors, Management)

The development of a target architecture must be based on the support of senior management:

Guiding Principles
Reliable fundamental decisions must be made (e.g., what is the company’s cloud strategy?) .

Personnel expenditure
In total, a large number of employees are usually tied up in the project (even if not always full-time). This personnel expenditure must be known and approved.

Innovation pressure
Some customers take the target architecture as an opportunity to align their IT with it. For this, decisions must be made about the future direction of the company (e.g., from product to service provider).

IT-Department

Introduction/Operation

Which applications (modules) are necessary?

How/where should they be operated?

Migration (not part of the consideration of this blog)

Which transactions still exist, are no longer necessary or have been simplified?

What needs to be considered for the respective modules, functions and transactions?

Examination of effects of the “custom code“? Changes in operation?

Which functionalities can be found in which applications?

This list is not intended to be complete, but it illustrates the importance of each role/viewpoint for the success of the project.

The following steps show an example of a methodical procedure for developing a high-level target architecture based on the business processes used. A step-by-step approach, from the process to the correct technology (top-down). If all parties agree on the high-level architecture that has been developed, the next phase is to start refining/strengthening this architecture.

Procedure

Setting the Stage

What are we actually working on here?
All parties involved must be clear in every meeting about the expected goal before the target architecture can be worked out. For example, if one party in the room thinks we are working out the target architecture for the “SAP S/4HANA PoC” and the other assumes an “SAP S/4HANA Enterprise Architecture 2025” (which is exactly what happened to me, by the way), this can lead to very entertaining discussions.

NOTE:
1. The Goal: Define the goal concisely. Repeat the goal definition before each meeting to ensure clarity.

2. The Focus: We want to identify the correct technology via the process and the associated requirements. The currently used software or even the technical migration path must not play a role in this process

Guiding/Architecture Principles

Guiding/Architecture Principles are guidelines or fundamental decisions for the project. These are decisions that everyone thinks are clear anyway. On closer questioning, however, everyone has a different view of these “clear” rules.

Rule examples: Cloud first, data is an asset, data protection and privacy are key, one central ERP system, etc.

NOTE:
Write down these rules. Designate a responsible person for every single rule (preferably a sponsor) who will take responsibility for them. Make these rules known to all participants and avoid that these rules are discussed anew in every meeting. Otherwise they will (you guessed it)….never get done.

Step 1 – Identification of the End-2-End business process

The identification of the business process(es) for which a target architecture is to be developed is elementary. Without this step, you will not be able to appoint the necessary experts in the company for the subsequent steps.

The “SAP Business Accelerator Hub”, with its SAP reference processes, supports the identification of the correct End-2-End business process: SAP Business Accelerator Hub:

The outcome of this step should be to narrow down the End-2-End business processes to be considered.

Step 2 – From End-2-End process to business activity

Often, an entire End-2-End process with all its activities is not to be included in the consideration. The reference processes of the SAP Business Accelerator Hub and their associated documentation also serve to delimit the process.

The next levels of the End-2-End process (see the following Value-Flow-Diagram) help to identify the correct sub-process (modular), the business process segment, and the associated business activity (example of the End-2-End process “Plan to Fulfill”)

NOTE:
Identification down to activity level is usually very difficult to implement on the sole basis of a Value-Flow-Diagram. Ask your sales representative for support and organize a workshop between SAP and the process owners in which the overall or partial process is represented in the system.

Step 3 – Identification of the relevant applications and their relationship

Up to this point, the focus has been on identifying the business process, sub-process and activity, and thus on the perspective of the business department. The next step is to transfer this result to the IT perspective and thus to the selection of the correct applications based on the result of the previous steps.

The “Scenario Implementation” point leads to a Solution-Architecture-Diagram (End-2-End business process), which shows the necessary components and their relationship to each other:

If a business process is not to be used in its entirety, the application belonging to the sup-process down to the activity-level can be identified starting from the Value-Flow-Diagram via the Software-Collaboration-Diagram.

Step 4 – The Platform

The previous steps represent a simple way of identifying the required applications based on the business processes used. Furthermore, it must be remembered that there are also key issues that may not be considered through this route but have a potential impact on the overall architecture.

Integration: An end-to-end process normally involves several applications that have to interact with each other. Even if the interaction between standard components is usually predefined, there are always individual integrations. Consider, for example, the connection of non-SAP systems. To identify the right integration software, I recommend using the SAP Integration Solution Advisory Methodology (ISAM).

Development: If a standard process cannot reflect reality, there are two possibilities. Adaptation of reality to the standard process or adaptation of the standard process to reality. A common guiding principle is “back to standard”, which means adapting reality to the standard process. However, there are always exceptions in which this is not possible for good reason. In order to have the right tool at hand for these exceptions, it is advisable to use the SAP Application Extension Methodology (AEM).

Data&Analytics: The potential to gain value from data remains largely untapped as companies struggle to keep pace with simply accessing, storing and harmonizing the data in complex and unintegrated data landscapes. To provide guidance in the design and validation of solution architectures for data-driven business innovations I recommend to use the SAP Data & Analytics Advisory Methodology (DAAM).

Further potential questions to think about:

What is my master data strategy?
How does my master data organisation look like?
What are my financial consolidation and planning requirements?
Do I need a solution for government communication?
Does the architecture meet the requirements of the DSGVO (GDPR)?
Have I thought about the Corporate Sustainability Reporting?

Again, this list is not intended to be complete, but rather thought provoking. Further ideas, including solution diagrams, can be found via SAP Missions:

Step 5 – The Unification

Different applications as well as their relation have now been identified via one or mostly several processes/subprocesses and platform requirements. In order to create and display a customer-specific architecture diagram from this, I recommend using the SAP Cloud Platform Solution Diagrams&Icons: Be Visual!

Conclusion

This is a very practical solution for identifying the correct application starting from a business process and creating a high-level target architecture. Involve SAP early on to implement this methodology. Joint planning with experts from the customer and SAP right from the start facilitates the development of an architecture and identifies any stumbling blocks early on.

Common thread of this blog series:

Maximize Customer Retention with Customer Service Tools in SAP Commerce Cloud

2024-07-21T22:49:11.277000+02:00

Introduction

Customer service is a key differentiator in today's competitive business world; therefore, this blog aims to assist you in understanding the dynamic features of this module, how it can be transformative for your business, and its real-world applications. Additionally, further modules such as Order Management Services Module and Assistance Service module will be referred here, to complement the usual business process and better illustrate the use cases. The Use Cases and Demo Flow section will focus on the real cases scenarios for improved linkage and understanding.

Business benefits

The SAP Commerce Cloud Customer Service module elevates customer experiences to new levels. Notably, it simplifies interactions through self-service options and reduces the cost of customer support by enabling service reps to focus on complex issues. Also, it boosts customer satisfaction rates through efficient problem resolution.

Below are some of the key business benefits while relying on the activation of the Customer Service Module from SAP Commerce Cloud:

Increases customer satisfaction through highly personalized customer service and support.
Increases performance of both response time and time-to-resolution.
Improves usability, speed, and efficiency through use of a single, highly responsive interface for handling all sales and customer interactions.
Supports full website integration enabling CSAs to access the same data and content your customers do.
Drives sales and revenue by enabling CSAs to run advanced catalog search and access cross- and up-sell promotions.
Provides a unified view of customers to give your CSAs access to customer information and their preferences.
Configures your own cross-channel strategy through a modular, highly configurable, widget-based approach.
Supports multi-tenancy for streamlining personalized service to customers of multiple brands
Saves time on both development and training costs.

Features and Capabilities

The module is equipped with numerous features that optimize customer service.

Some of these include:

Designed for the call center environment.
Ready-to-use integration with the Order Management Services and the Assisted Service Module.
Maximum performance of your customer service agents.
Higher usability, speed, and efficiency.
Single, highly responsive interface.
Keystroke access for quick access to the relevant information.
Highly personalized customer service and sales support.
The customer service agent sees the same information as the customer.
An agent can alert customers about promotions, offers, and cross-/up-sells.
Personalized content is visible to the agent as well.
The agent sees the same information as the customer does.
Support for chat integration.

Real use case scenarios

The Customer Service Module can be used for various scenarios, such as handling customer inquiries, resolving product or service complaints, handling order cancellation, returns, and managing customer profiles. Therefore, to better describe how it works, let focus on two possible real word scenarios where the customer might need support from the customer service team.

*For the phone call interaction, the demos assume the Powertool company has set a contact number for the customers. Also, the customer service team department, integration with an ERP or S/4HANA as well as telephony technology required are considered.

Although before we start, let’s get to know the Personas/roles involved in these use cases and demo flow as well as the industry and business considered:

Personas / Roles

Customer Support Agent – Rachel Gloves
Customer / B2B Buyer – Mike Rivers

Use cases and Demo Flow

CASE 1 - The customer calls CSR asking for support on partial order cancellation.

CASE 2 - The customer raises a ticket request to complain about an invalid coupon.

Industry and Type of Business

Powertool Manufacturing and Business-to-Business

Use Cases and Demo Flow

Therefore, let's now jump to each of the use cases and demo flow.

CASE 1 - The customer Mike Rivers calls the Customer service team asking for support on partial order cancellation.

Mike River just bought some products from the Powertool Manufacturing storefront and after rechecking the internal stock, he did realize the quantities requested are not correct, hence he needs to cancel some items from the past order partially. As the below image shows, the initial request considered 5 Standard and other 5 Professional screwdrivers:

As Mike Rivers is new in the Powertool Manufacturing site, he decided to call the service team, seeking support to guide him on the process to partially cancel items from the last order. After checking the Powertool Manufacturing contact, he then called towards the customer service team. Therefore, Rachel Gloves from Customer Service team picks up the call and start interacting with the Mike Rivers.

So here, Rachel Gloves from Customer Service team has some options to support the Mike Rivers while relying on the standard capabilities of the SAP Commerce Cloud – Customer Service module.

1) Rachel Gloves may explain how the customers may process with the partial order cancellation on their end, launching the ASM tool from the Backoffice:

And check the order history with the customers. In the order summary, the customer could then initial the cancel order easily. So here, imagining that Mark Rivers needs to reduce the professional screwdriver to 3, he could manage that from the cancel order option:

And submit this request:

However, another option could be 2) as Mark River - says he is not able to manage it on his end, then Rachel Gloves can perform this request on the customer's behalf.

To accomplish this, Rachel Gloves would go towards the Customer Support module via SAP Commerce Cloud Backoffice and look for the Mike River order placed:

After that, start the partial order cancelation as instructed by Mark Rivers:

Proceeding to the reduction of quantity and confirm the selection:

After performing this action, the order history will be tracked both in the customer service module backoffice:

And the Mike River will also see the updated action on the Powertool Manufacturing site:

*Also emails to inform the customers about the order status changes are considered. For more, please check here: E-mails in Backoffice Customer Support Cockpit and Configuring Emails.

CASE 2 - The customer raises a ticket request to complain about an invalid coupon.

Now, picturing Mike Rivers is more mature in the Powertool Manufacturing, and instead of calling the Customer Service team, he basically decided to raise a ticket request in the Powertool Manufacturing. The request is about an invalid coupon code that he has tried tout o use while placing an order.

Hence, to raise such a request, Mark River goes to the customer service option:

And create the request, explaining the situation:

After submitting the request, Mark River can see the status and review any relevant information:

Given that, in the Backoffice – Customer Support, Rachel Gloves will be able to see the request and act upon the subject:

After picking up the correct request, all the necessary information will be available for the customer service team support the customer:

Hence from here, Rachel Gloves may start interacting with Mark Rivers and message the customer to resolve the request:

After sending the message, Mark River can be informed via email and the message will also be available in the Powertools site under the customer service option:

With that, Mark River is now informed and can then proceed with the new order and close the request, as a new promo code has been provided.

Likewise, these updates from Mark Rivers will be reflected in the customer service module accordingly:

Important Considerations / Notes to be taken in attention.

For successful implementation and adoption, businesses must thoroughly define their service team's hours and commitment to responding to customer queries. The size of the service team also plays a critical role, as it must be in accordance with the business's demand and customer interaction frequency. In the case of multi-site or regional operations, specific strategies must be designed to offer seamless support. Robust organization and attention to infrastructure are essential prerequisites as well. With that said, we recommend a proper business process definition in place to manage the impact and efficiency to better assess the whole purpose of having customer service using the Customer Service Module from SAP Commerce Cloud rather than relying on the CRM system to manage it. Hence, for complex use cases or high-demand support, we recommend an appropriate assessment to review the best option for your use cases. Please also take a look at this blog for further reference: The seamless ticketing support journey between SAP Commerce Cloud and SAP Service Cloud

Useful Links

To dive deeper into the world of SAP Commerce Cloud's Customer Service Module, Order and Returns and Assisted Service Module, please follow these links:

Conclusion

SAP Commerce Cloud’s Customer Service along with both Order Management Services and Assisted Service module may transform your customer service game, armed with its extensive capabilities and benefits. It attentively caters to the needs of the new-age customer while ensuring your business operations become more streamlined and efficient. Whether your organization is small, medium, or even large-scale, adopting SAP Commerce Cloud’s Customer Service Module is a worthwhile advantage in enhancing customer satisfaction.

We hope you have enjoyed the reading,
Thank you,

Luciano Monteiro,

CX Solution Value Advisory team.

Integrating SAP Systems with Non-SAP Cloud Data Warehouses Using OData

2024-08-05T19:59:24.446000+02:00

Introduction

In today's data-driven landscape, integrating SAP systems with cloud-based data warehouses (DWH) like Azure Synapse or Databricks is crucial for enabling real-time analytics and decision-making. One effective approach for this integration is leveraging the OData protocol, a RESTful API architecture that ensures seamless data transfer and interoperability. This blog delves into the benefits, challenges, and practical steps for integrating SAP systems with non-SAP cloud DWHs using OData.

Background

SAP's decision to update SAP Note 3255746, which prohibits the use of the RFC Module of Operational Data Provisioning (ODP) API for third-party applications, necessitates alternative data extraction methods. One such recommended approach is using the ODP OData API or existing OData connectors. This change significantly impacts the ability to ingest data from SAP to non-SAP cloud and non-cloud applications that rely on the ODP framework.

Why OData?

OData, an open standard protocol, offers several advantages for integrating SAP with cloud DWHs:

Standardization and Interoperability: OData's adherence to open standards facilitates smooth integration with various Azure services and Databricks.
Real-Time Data Access: OData supports real-time data updates, which are essential for up-to-date analytics and decision-making.
Simplified Data Modelling: OData abstracts the complexities of data modeling, making it easier to manipulate and query data without requiring deep SAP system knowledge.
Scalability: Both Azure and Databricks provide scalable storage and compute capabilities, while OData ensures efficient data transfer even as data volumes grow.

Implementing OData Integration

Prerequisites

To implement OData services, ensure the following:

SAP Gateway Foundation: Required either locally in the SAP NetWeaver system of the provider or in a separate SAP NetWeaver instance.
Software Component IWBEP: Necessary for generating the OData service.

Steps to Generate and Consume OData Services

Expose Data Models: Expose the extractor, data model, or table as an OData service using SAP Gateway Builder.
Generate and Register the Service: Once the service is created, register it in the SAP Gateway system.
Configure External Applications: External applications can now consume the service via URL calls, initiating data extraction.

Azure Databricks Configuration

Adapt Ingestion Pipeline: Replace the existing connector with the OData connector.
Service Configuration: Configure the service details using the generated SAP OData Service and create a new linked service in Azure Databricks.

Solution Approach: Pros and Cons

Pros

Standardization and Interoperability: Facilitates integration with Azure services and Databricks.
Real-Time Data Access: Supports real-time updates, essential for analytics and decision-making.
Simplified Data Modelling: Reduces complexities in data manipulation and querying.
Scalability: Ensures efficient data transfer even with growing data volumes.

Cons

Performance Concerns: OData's RESTful nature may lead to performance bottlenecks with large data volumes or complex queries.
Security and Governance: Requires robust access controls and monitoring mechanisms to prevent unauthorized access or data breaches.
Latency: Network latency and response times can be a concern, especially in high-throughput scenarios or with geographically dispersed systems.
Maintenance Overhead: Ongoing effort may be required for developing and maintaining OData services, particularly with frequent changes in data structure or SAP updates.

Conclusion

Leveraging OData for integrating SAP systems with non-SAP cloud data warehouses offers a streamlined, standardized approach for data extraction and real-time analytics. While there are challenges related to performance, security, and maintenance, the benefits of real-time data access, simplified data modeling, and scalability make OData a viable solution for modern data integration needs.

Implementing this integration requires careful planning and execution, ensuring all prerequisites are met and potential drawbacks are addressed. By doing so, organizations can unlock the full potential of their SAP data in cloud-based analytics platforms.

What’s New for SAP Integration Suite – June & July 2024

2024-08-09T08:54:52.588000+02:00

This is a continuation of the blogpost series you may find at #WhatsNewInSAPIntegrationSuite. Today you oversee all our impressive updates released within the June and July timeframe. As we have already August, the next update will come very soon. Stay tuned and enjoy the lovely summertime.

Our highlights were:

Accelerate development of integration flows with Generative AI assistance
New adapters available
Creation of new data type and message types
New design guidelines added for the validation of integration flows
Additional adapters for Edge Integration Cell
Simulation support for Edge Integration Cell
API validation policy for API artifacts
Edge Integration Cell on Red Hat OpenShift
Offline availability during periods of temporary connectivity loss
Sizing recommendations for asynchronous messaging
Support for outgoing connections through a HTTP proxy
API anomaly detection reduces security and performance risks
Maintenance of multiple target endpoints through UI
Changes in user interface
Make use of your own global custom codelists in Trading Partner Management
Integrations with trading partners through value-added networks
Support partners with subsidiaries
Improved situational awareness with Event Mesh
Additional data centers for advanced event mesh
Modernization recommendations for on-premise integration scenarios
Updates to the pipeline concept
New rules added to Migration Assessment
Migration tooling is now pattern based
Support for message type objects in migration tooling
New partner content on SAP Business Accelerator Hub
Search and discovery of validated partner use cases on SAP Business Accelerator Hub

Cloud Integration

Accelerate development of integration flows with generative AI assistance

As a first step towards generative AI in our integration area we have extended the design-time tooling in that way that you can create integration flows with the help of generative AI and the unified customer landscape (UCL). Based on your description of a desired integration scenario and existing system instances from UCL, the generative AI tool creates an integration flow with sender and receiver systems. This improves your developer productivity and saves cost. Going forward, we will enhance this offering to include also mediation steps. This feature is only available for tenants with premium edition and as of today in some regions on AWS landscapes. Read the blogpost, watch the demo, and check out the documentation for more information.

New adapters available

We are happy to announce four new adapters in addition to our already rich set of built-in connectivity options. Make use of the new Coupa, NetSuite ERP, Snowflake, and Amazon DynamoDB receiver adapters. All these adapters are available on SAP Business Accelerator Hub and run within the cloud or on the optional Edge Integration Cell runtime.

Creation of new data type and message types

This feature is important for all customers in their journey moving from SAP Process Orchestration to the SAP Integration Suite. You can now import data and message types from the ES Repository along with dependent data types, or create new ones from scratch, or edit existing ones in Cloud Integration by e.g., adding new attributes. These new design time artifacts are stored as XSDs and can be reused in message mapping or in the XML validator flow step. For more information, see the documentation and read the blogpost.

New design guidelines added for the validation of integration flows

Additional design guidelines are added to help you further in designing integration flows in a robust fashion. The new design guidelines include checks to efficiently use scripts, handle security, optimize memory usage, and a few more.

Another new feature is that integration developers may skip a non-compliant design guidelines with consent by providing a reason. This action can also be reverted. See the documentation.

Edge Integration Cell

For running your integration scenarios in your private landscape using the optional hybrid integration runtime Edge Integration Cell runtime we are heavily working on offering you new features and adapters.

Additional adapters

We have increased the set of connectivity options. The following adapters now support also the Edge Integration Cell runtime profile: Amazon Web Services, Microsoft Dynamics 365 CRM, Salesforce, SugarCRM, ServiceNow, Workday, Slack, MS SharePoint, MS Azure Storage, RabbitMQ, and Splunk.

Simulation support

Simulation was a limitation that we had for Edge Integration Cell. Now you may select also the Edge Integration Cell runtime in your designer and run simulations for your integration flows. See the details in our documentation.

API validation policy for API artifacts

We have extended the set of policies. You can now validate incoming messages against an OpenAPI 3.0 Specification using the API validation policy. In the OpenAPI Specification, you can define the expected message headers and query parameters for each API endpoint. See further details in the documentation.

Kubernetes cluster deployment on Red Hat OpenShift

We have extended the set of Kubernetes container application platforms of your choice and you are able now to deploy your Kubernetes cluster on Red Hat OpenShift. Next to the both hyperscaler-based Kubernetes offerings Microsoft AKS and Amazon EKS, you can use SUSE Rancher and Red Hat OpenShift. Alibaba Cloud and Google Kubernetes Engine are on our roadmap. Read the documentation and see note #3247839.

Offline availability during periods of temporary connectivity loss

You can now perform client certificate authentication and authorization for integration flow processing and API proxies in the Edge Integration Cell instance within the customer network. This Edge Local Authentication and Authorization is a fallback to the default cloud-based authentication and authorization in SAP BTP and synchronizes XSUAA security data. Initially, only certificate authentication is supported, further expansion for other OAuth flows and external IDPs are planned. Check out the documentation and note #3472645.

Sizing recommendations for asynchronous messaging

We have updated our sizing guide. Now you get also sizing recommendation for hardware resources in asynchronous messaging scenarios. It calculates CPU and memory requirements depending on number of messages per second and payload sizes. Check out the sizing guide for Edge Integration Cell for further details.

Support for outgoing connections through a HTTP proxy

The Edge Integration Cell runtime now supports you with routing of outgoing connections through a proxy. This is useful if your Edge Integration Cell is part of a network that is using an HTTP proxy to communicate with Edge Lifecycle Management Cloud. Read the documentation.

API-led Integration

API anomaly detection reduces security and performance risks

Since June already you are able to monitor actively an exceptional behavior with the help of the anomaly detection feature of API Management. This AI-based feature helps you to optimize your system performance by identifying irregularities as a sudden spike or drop in API calls, as well as an increase in latency or an increase in the number of detected errors. Patterns that deviate from the normal behavior are visualized and in addition subscribers can be promptly notified through emails to minimize the potential impact of an anomaly and to make sure the issues are addressed in a timely manner. This feature is available with SAP Integration Suite, premium edition and in some data centers. Check out the blogpost and read the documentation.

Maintenance of multiple target endpoints through UI

Previously, the only way to add multiple target endpoints was through API proxy zip update, and policies could only be added to the target endpoint that appeared first in the target endpoints dropdown menu. Now, multiple target endpoints can be added and maintained through the UI, and policies can be added to any target endpoint of your choice using the UI. See the documentation create an API proxy and edit an API proxy.

Changes in user interface

Find the previously named APIs that were located under Monitor in the navigation bar, now renamed to Analyze and located under Monitor and. The functionality remains unchanged.

The classic design of the API business hub enterprise has been removed and is no longer accessible.

B2B Integration

Make use of your own global custom codelists

Important for us to improve your developer efficiency wherever possible. Under Custom Type Systems, you can now create global custom codelists centrally and use them across all artifacts such as MIGs and MAGs. The codelists can be created manually or by uploading a csv file that is based on a standard code list. Refer to the documentation.

Integrations with trading partners through value-added networks

In the B2B Integration area we are happy to tell that we support communications with trading partners through value-added networks (VAN). You can create a new profile type communication partner, which holds the configuration of a VAN provider offering the communication service to trading partners. This profile holds centrally the AS2 partner ID and connection properties which can be used by different templates and agreements. Check out the documentation.

Support partners with subsidiaries

We have introduced Identifier Groups in company and trading partner profiles to enable the assignment of several individual identifiers to a group. This supports scenarios where the agreement are the same across multiple suborganizations of a company and want to use centralized processing with identical mappings. This innovation reduces the need for configuring multiple redundant agreements. The idea is to configure agreements using these identifiers groups, then, at runtime, the associated identifiers will be utilized. Refer to the documentation.

Event-driven Integration

Improved situational awareness with Event Mesh

Since early June already Event Mesh is part of the family. It is targeted for customers with SAP Integration Suite, standard or premium edition, reducing the time to get started with end-to-end event-driven architectures in or beyond the SAP event-driven ecosystem. And it provides the option to combine the event-driven integration with the classic process integration approach. Check out the blogpost and use the access to the Event Mesh documentation.

Additional data centers for advanced event mesh

SAP Integration Suite, advanced event mesh is now available in additional landscapes: on Google Cloud Platform in Europe (Frankfurt) and in US Central and on Amazon Web Service in Brazil (Sao Paulo). See the full list at the SAP Discovery Center.

Migration Assessment and migration tool

Supporting our SAP Process Orchestration customers in their journey to SAP Integration Suite is one of our key investment areas. During last development takts we have released the following innovations:

Modernization recommendations for on-premise integration scenarios

You can now receive modernization recommendations for integration scenarios you are evaluating for a migration from SAP Process Orchestration to SAP Integration Suite. The aim of these recommendations is to improve your integration practice and make use of standardized protocols like SOAP, REST, and OData, modern integration styles such as API-led integrations or event-driven integrations and leverage pre-built integration content from the SAP Business Accelerator Hub. You find the recommendations in a report and in a dashboard after the scenario evaluation. For detailed descriptions, see the modernization recommendations in the migration guide for SAP Process Orchestration and the documentation.

Updates to the pipeline concept

To run integration scenarios on cloud in an asynchronous manner, we had published a documentation how to set up the pipeline concept and offered also a Process Integration Pipeline package on SAP Business Accelerator Hub. The latest version of this package covers custom error handling and improvements of the IDoc inbound processing flow. Furthermore, we have introduced a testMode header to implement your own logic how to deal with messages in test mode.

New rules added to Migration Assessment

We have extended the list of rules applied during evaluation. Now there are rules available that count the number of inbound interfaces, receivers of an integration scenario, determine the number of fields in which file content conversion is used, etc.

A set of characteristics according to which the application evaluates whether an integration scenario can be migrated and what effort you can expect.

Migration tooling is now pattern-based

To cover the migration of much more Integrated Configuration Objects (ICO) and be more generic, our migration tooling has switched from a template-based towards a pattern-based migration approach. Your ICOs need not necessarily match a specific template anymore to be ready for a migration. It is sufficient that the ICO is similar to one of the supported patterns to achieve migration. The migration tooling analyses the ICO that are evaluated as migratable via the Migration Assessment capability and maps it with the patterns. Based on the pattern, it creates an equivalent integration flow in Cloud Integration.

Support for message type objects in migration tooling

As message type and data type objects are available in SAP Integration Suite that you may import or create from scratch, you can now also generate integration flows that contain references to message type and data type objects using the migration tooling. Refer the documentation.

Business Accelerator Hub

Search and discovery of validated partner use cases

We are very excited to announce a new type of accelerator, the content category VPUC on the SAP Business Accelerator Hub. SAP-validated partner use cases are solution packages helping you maximize the return on investment on your SAP BTP venture. Checkout the blogpost read the documentation.

New partner content

Lots of new partner content has been published on SAP Business Accelerator Hub by Kaar Technologies, PiLog, Coveo, Qintesi, Crave InfoTech, Tarento, Wipro, KPMG, Twenty5, and RealCore. Check out the blogpost explaining all the details.

How to stay tuned to recent and upcoming innovations?

The SAP Road Map Explorer is your one-stop shop for all SAP Integration Suite innovations. You can easily check out the latest innovations and follow what is planned for the following quarters. All recent innovations also cover under the tab Features further links to blogposts or documentation.

We also refer to the complete list of new releases in our documentation: What’s New in SAP Integration Suite.

And if you have not heard of our monthly webinars, I suggest you sign up to get an invitation to the upcoming ones. Our team of Product Management experts host these webinars and showcase the latest and greatest updates regarding all SAP Integration Suite capabilities. The webinars take place on the last Tuesday of every month and the next one is already scheduled for August 27th.

In case you have missed our last monthly webinar, don’t worry. Visit 2024 Learning Sessions for SAP User Groups on SAP Integration Suite for all recordings, presentations, and Q&As.

Are you aware of the Release Navigator for SAP BTP? It consolidates release information across SAP BTP products and services easing you the way to find product release related notes, blogposts, and webpages. For your convenience use the direct link to the SAP Integration Suite section of the Release Navigator.

SAP Integration Strategy - End-to-end business processes deep dives - NEW eBook available

2024-08-11T23:05:07.722000+02:00

Dear community members,
Dear colleagues,

I'm happy to announce our 2nd edition of our SAP Integration Strategy eBook, this time more focusing on how our customers benefit from an integrated SAP software portfolio by enabling them to design, model, implement, and ultimately run their business processes end-to-end.

You may remember our first Youtube calls and presentations – that we also already put together with this first eBook – and in which we informed you about our overall integration strategy at SAP, where we walked you through our so-called suite qualities, to address the various aspects of integration requirements as such.

Simply take these 2 examples – e.g. the need to unify and harmonize our user interfaces of the various software solutions that SAP offers, and the other is about requirements such as consistent security and identity management, that functions across all applications, just think of Single Sign-On.

Our suite qualities are now implemented in our SAP software solutions, and SAP is therefore proven to be able to support our customers’ end-to-end business processes.

Thus it was just obvious for us to share these achievements with you, as we ran the so called E2E business process deep dives series to provide a detailed picture what customers and partners can expect from SAP to drive their digital transformation and establish business processes, at the same time fitting to their particular needs:

Lead to Cash
Hire to Retire
Source to Pay
Design to Operate

With the new eBook you now have an excellent collection of all of our SAP Community calls and the related presentations that show you how SAP can now support your business requirements with a holistically integrated software portfolio.

For upcoming events, webinars and any kind of new information you may bookmark this SAP Community Topic Page called “SAP Integration Strategy” to remain up-to-date with regards to our upcoming sessions and webinars that we area about to setup for you.

Happy reading and enjoy watching the recordings as well as studying the presentations!

What’s New for SAP Integration Suite – August 2024

2024-09-03T15:40:02.610000+02:00

Fall is coming and the next TechEd Virtual is already in preparation. Take the chance and flip through the session catalog for all the interesting sessions of our integration track. Register now and join us online October 8-9, 2024.

As usual find with this blogpost the highlights of our SAP Integration Suite increments that have been released in August:

Get ready with custom and purchased adapters for the Apache Camel 3.14 upgrade
Edit namespace for message types
Persistence in MariaDB databases
Principal propagation as authentication method to connect with on-premise systems
New parameters in SFTP and AMQP sender adapters
Inspection of content size
Diagnostic tasks in operation cockpit of Edge Integration Cell
Community integration package for extension points
Appropriate time zone in B2B monitor
Suborganizations in company profiles
Support of EDI flat-file payloads
Integration Advisor migration guide
Envelope templates for EDI messages
New version of the Process Integration pipeline concept
Adapter modules
Manage content from API business hub enterprise
Default credential type for service key

A2A integration

Get ready with custom and purchased adapters for the Apache Camel 3.14 upgrade

As the Apache Camel upgrade is happening soon, do some prerequisites to run your integration scenarios before your productive tenants are updated to the new runtime. Please upload a Camel 3.x compatible version of your custom adapters and of adapters you have purchased from other vendors to your productive tenant. A special area is available for upload. By uploading your adapters, we ensure that they will get ported automatically during the update.

With regards to OEM adapters by partners, please run the latest Camel 2.x compatible versions. An upload isn’t necessary.

To avoid any business disruption with unexpected integration flow behaviour, we recommend an upfront validation of your custom adapters. For this purpose you may leverage the free 90 days valid test tenant that already offer for quite some time. It runs on Apache Camel 3.14 where you can test your adapters and integration flows.

Ensure that also your design time has the latest version of the adapters and upload the .esa files to the appropriate integration packages. For more details, see SAP Note #3326553.

Edit namespace for message types

The recently introduced message types have been extended in the way that you can now view the namespace to which a message type belongs to and edit and create a new one. Refer the documentation.

Persistence in MariaDB databases

To support our SAP Process Orchestration customers, we have extended the Java database connectivity (JDBC) receiver adapter by supporting now also MariaDB. The adapter is available in multi-cloud environments and in Edge Integration Cell runtime for ground-to-ground integration scenarios. See the documentation.

Principal propagation as authentication method to connect with on-premise systems

You can now propagate the principal of the inbound technical user with the principal propagation authentication method in the HTTP receiver adapter. The tenant authenticates itself against the receiver by forwarding the principal of the inbound user to the Cloud Connector, and from there to the back end of the relevant on-premise system. Check out the documentation.

New parameters in SFTP and AMQP sender adapters

We have introduced new parameters in the SFTP and AMQP adapters. The SFTP sender adapter is extended by Poll on one worker only used to specify that the polling process is performed on a single worker node only. The AMQP sender adapter that is consuming messages from queues in an external message broker offers now the parameter Disable Reply-To allowing you to disable the reply back for a message.

Inspection of content size

The powerful inspect feature to analyze your resource consumption has been extended. You can now inspect the file size of all the integration artifacts (such as integration flows, value mappings, adapters) they allocate on the tenant they are deployed on. You may detect the top consumers and in case of integration flow artifacts switch also between the various inspect categories to detect the consumption of other relevant database and system resources. Refer the Inspect Content Size.

Integration in private landscapes

Diagnostic tasks in operation cockpit of Edge Integration Cell

Integration administrators can run diagnostic tasks in the operation cockpit of Edge Integration Cell. You may increase the log level configuration temporary with only few clicks, and with the Takt 2408 in September you may either trigger and view thread and heap dump on Java components. The diagnostic data can be collected on a file system and shared with SAP Support for troubleshooting. Check out the documentation.

B2B integration

Community integration package for extension points

The B2B Integration Factory integration packages are available for customers that require additional extension points and custom features that are not yet provided by the standard TPM solution. If the standard TPM solution does not cover your integration requirements, use the community packages instead.

The following packages are available:

Appropriate time zone in B2B monitor

To enhance efficiency in B2B monitoring, dates and times are now displayed according to your browser's time zone, rather than UTC. Additionally, you can easily rearrange field positions using drag and drop, and sort the columns in the interchange list. For more information, see monitor interchanges and monitor unassigned interchanges.

Suborganizations in company profiles

Within the Trading Partner Management subsidiaries are supported. You can now create and maintain suborganization profiles as children of the main company profile. They may have their own configuration requirements, such as certificates, systems, and communication channels. Check out the documentation for more details.

Support of EDI flat-file payloads

For payload XML was the only supported format by the Integration Advisor capability so far. To increase your efficiency, you can now use the text-based flat-file EDI format (used for X12, UN/EDIFACT, and Tradacoms) as well. EDI payloads can be uploaded as MIGs, and you can also use the payload during the MIG and MAG simulation. The conversion of the EDI payload into its XML representation is implicitly done by Integration Advisor. Check out all the details in the blogpost.

Integration Advisor migration guide

We have now published a migration guide for the Integration Advisor capability that details the steps needed for customer planning to migrate their design time artifacts from the Neo environment to SAP Integration Suite.

Envelope templates for EDI messages

The EDI standards X12 and UN/EDIFACT have so called envelopes that are wrapped around the actual messages. You can now define Message Implementation Guidelines (MIGs) that combine envelope and message structure and share this documentation with business partners. For the definition you can leverage envelope templates as defined by the standards. The envelope template content will be released gradually over the next few weeks, starting with UN/EDIFACT and ASC X12, followed by EDIFACT subsets and Odette. See the details in the documentation.

Migration from SAP Process Orchestration

New version of the Process Integration pipeline concept

To run your asynchronous message processing in Cloud Integration in a similar way as you do it in SAP Process Orchestration, we have introduced the pipeline concept. Now we have released a version 1.0.6 of the package with some enhancements. To offer a way to define sender wildcard scenarios we have revised the partner ID definition and support also alternative partners to overcome partner id restrictions. Another enhancement is that the receiver and interface determination can now be bypassed in pure point-to-point scenarios to improve the runtime performance. Read the very detailed blog post and see the pipeline package published at the SAP Business Accelerator Hub. And if you like to make yourself familiar check out the Process Integration pipeline sample scenarios in the GitHub repository including also a guideline how to the pipeline concept

Adapter modules

The message transformation utilities community package contains artifacts that help transforming message payloads to various formats, such as XML, plain text, CSV, and JSON. The package delivers various functionalities that once existed in SAP Process Orchestration as adapter modules. The utilities covered so far are MessageTransformBean and XMLAnonymizer.

API-managed integration

Manage content from API business hub enterprise

You can now publish selected SAP system APIs directly into the API business hub enterprise catalog, without first defining API proxies for these APIs. To accomplish this, your global account administrator first needs to register these systems in your tenant. The registered systems then appear in the manage content page of API business hub enterprise, from which you can then publish the APIs directly. See the documentation.

Default credential type for service key

In the API business hub enterprise, we've updated the default credential type for the service key. It's now binding-secret instead of instance-secret. We made this change because xsuaa has deprecated the credential type instance-secret. See more details in our documentation.

How to stay tuned to recent and upcoming innovations?

We also refer to the complete list of new releases in our documentation: What’s New in SAP Integration Suite.

And if you have not heard of our monthly webinars, I suggest you sign up to get an invitation to the upcoming ones. Our team of Product Management experts host these webinars to showcase the latest and greatest updates regarding all SAP Integration Suite capabilities. The webinars are hosted on the last Tuesday of every month and the next one is already scheduled for September 24th.

In case you have missed our last monthly webinar, don’t worry. Visit 2024 Learning Sessions for SAP User Groups on SAP Integration Suite for all recordings, PDFs, and Q&As.

‌‌ Transforming Supply Chain in Transportation with Generative AI on SAP BTP

2024-09-12T09:04:29.592000+02:00

Transforming Supply Chain in Transportation with Generative AI on SAP BTP

🚃🚞🚢🚅🚆🚄

In an era where efficiency and agility are paramount, the transportation sector faces increasing pressure to innovate and streamline supply chain operations. Leveraging Generative AI (Gen AI) on the SAP Business Technology Platform (BTP) can catalyze a transformative approach to managing logistics, routing, maintenance, and demand forecasting. This article delves into a detailed use case i have been ideating for implementing Gen AI in supply chain transformation, utilizing advanced SAP technologies like SAP HANA Cloud Vector Engine, Business Application Studio (BAS), UI5/Fiori, OData V4, Work Zone, Build, S/4HANA APIs, SAP DataSphere, Integration Suite, SAP AI Core, and Generative AI Hub.

Use Case: Generative AI for Supply Chain Transformation and Efficient Transportation operations

Business Challenge

A large logistics company faces challenges in maintaining efficient transportation operations. Key issues include:

- Inefficient Routing: Existing routing methods do not account for real-time traffic data, leading to delays and increased fuel costs.
- Predictive Maintenance: The fleet suffers from unexpected breakdowns, resulting in costly repairs and unplanned downtime.
- Demand Forecasting: Inaccurate predictions lead to overstocking or stockouts, affecting service levels.

Solution Architecture

The proposed solution integrates multiple SAP technologies, leveraging their capabilities for a comprehensive Generative AI solution.

Using Retrieval Augmented Generation and Generative AI on SAP BTP

RAG and Gen AI Reference Architecture

Understanding the Generative AI Landscape

To effectively utilize Generative AI in supply chain transformation, it is essential to understand the different model types and their applications in this context.

Transformer-based Models
- Definition: Transformer models use self-attention mechanisms to weigh the relevance of different input data points, making them suitable for sequence-to-sequence tasks such as language translation and time-series prediction.
- Application: In the transportation supply chain, Transformer models can analyze historical delivery routes and predict optimal paths based on real-time traffic data. For instance, a model can assess patterns in delivery times, identifying peak traffic hours, and suggest alternative routes that minimize delays.
Generative Adversarial Networks (GANs)
- Definition: GANs consist of two neural networks—a generator and a discriminator—that create realistic data by competing against each other.
- Application: In transportation, GANs can generate synthetic data to simulate various traffic conditions and assess how these conditions might affect delivery times. This data can help in training predictive models without the need for extensive historical data, which may not be available for rare events (e.g., natural disasters).
Variational Autoencoders (VAEs)
- Definition: VAEs are generative models that learn to encode data into a latent space and can reconstruct data from this representation.
- Application: VAEs can be used to analyze customer demand patterns by reconstructing data on past orders. This analysis can provide insights into seasonal variations in demand, enabling better inventory management and resource allocation.

SAP AI Core and Generative AI Hub: These platforms provide the necessary tools and frameworks to develop, deploy, and manage AI models. They support various model types, enabling the selection of the best-suited architecture for specific tasks.

SAP HANA Cloud Vector Engine: This engine provides advanced analytics and supports complex queries against large datasets. It is essential for generating embeddings that represent various data points (e.g., routes, delivery times, traffic conditions).

SAP DataSphere: DataSphere serves as the central data management solution, integrating data from various sources like GPS systems, traffic reports, and historical delivery records. It ensures data quality and accessibility for AI models.

SAP S/4HANA APIs: By utilizing these APIs, the AI models can interact with the company's existing ERP systems, fetching real-time data for analysis and decision-making.

SAP Integration Suite: This suite facilitates seamless integration between different systems and applications, allowing for the smooth flow of data across platforms.

SAP UI5/Fiori: The user interface can be developed using UI5/Fiori, providing intuitive dashboards that visualize insights from the AI models and allowing users to interact with the system easily.

Establish a central entry point with SAP Build Work Zone

Implementation Steps

1. Data Collection and Integration:

1.1 Use SAP DataSphere to consolidate data from various sources, including:

GPS Tracking: Real-time location data from vehicles.
Maintenance Records: Historical data on vehicle servicing and repairs.
Traffic Reports: Data from third-party APIs that provide real-time traffic conditions.

1.2. Clean and preprocess the data to ensure it is suitable for model training.

2. Model Development:

Choose appropriate models based on the specific tasks:

Routing Optimization: Use Transformer-based models to analyze historical delivery routes and predict optimal paths based on real-time traffic data.
Predictive Maintenance: Implement VAEs to analyze patterns in maintenance records, predicting when a vehicle is likely to require servicing.
Demand Forecasting: Utilize GANs to create synthetic datasets that simulate various demand scenarios, training models that can better forecast future orders.

Generating Embeddings:

Use the HANA Cloud Vector Engine to generate embeddings from the cleaned data. These embeddings represent complex relationships in the data, allowing for more sophisticated analytics and querying capabilities.
This step enables Retrieval-Augmented Generation (RAG), where generated insights are combined with retrieved data to improve accuracy.

3. API Integration:

Utilize SAP S/4HANA APIs to fetch real-time data from the ERP system and return predictions from the AI models. For example, when a delivery is scheduled, the system can query the API to fetch current traffic conditions and suggest an optimal route.

4. User Interface Development:

Create a user-friendly dashboard using SAP UI5/Fiori displaying:

Real-time insights into fleet performance.
Predictive maintenance alerts.
Demand forecasts.

Users can interact with the system to adjust parameters and view the impact on predictions.

5. Feedback Loop:

Implement a feedback mechanism to continuously improve the AI models including:

Collecting data on the accuracy of predictions.
Adjusting model parameters based on real-world outcomes.
Regularly retraining models with new data to enhance their performance.

Merits and Limitations of Generative AI in SAP

Benefits

1. Enhanced Decision-Making: By providing insights derived from predictive analytics, businesses can make informed decisions that lead to reduced costs and improved operational efficiency. For instance, real-time routing suggestions can cut delivery times and fuel expenses.

2. Scalability: The architecture built on SAP BTP allows for easy scaling to accommodate growing data volumes and user demands, ensuring that the system can adapt to future needs.

3. Integration: SAP's robust integration capabilities ensure that generative AI models can seamlessly interact with existing systems, enhancing the overall efficiency of supply chain operations.

4. Real-Time Insights: By leveraging real-time data, the solution enables immediate adjustments to operations, optimizing performance continuously and improving customer satisfaction.

Limitations

1. Data Quality: The effectiveness of generative AI models relies heavily on the quality of the data used. Poor data can lead to inaccurate predictions and insights, ultimately affecting decision-making.

2. Complexity: Developing and maintaining generative AI models can be complex, requiring skilled resources and ongoing management to ensure optimal performance.

3. Cost: The initial investment in technology and resources may be significant, though it is often offset by the long-term benefits of improved efficiency and decision-making.

4. Ethical Considerations: As with any AI application, ethical considerations surrounding data privacy and bias must be addressed. Organizations must ensure compliance with data regulations and ethical standards.

Conclusion

Integrating generative AI into the supply chain transformation process in transportation presents a significant opportunity for organizations to enhance their efficiency and decision-making capabilities. By leveraging SAP BTP technologies, including the HANA Cloud Vector Engine, DataSphere, AI Core, and S/4HANA APIs, businesses can develop sophisticated models that provide real-time insights and predictive analytics.

As organizations embrace this innovative approach, they must remain mindful of the challenges and limitations while continuously seeking to improve their models and practices. The future of supply chain management in transportation lies in the hands of those willing to harness the power of generative AI to drive transformative change. By embracing these technologies and methodologies, companies can not only stay competitive in an evolving landscape but also set new standards for efficiency and customer satisfaction.

Inspiration for my current article: SAP Generative AI and Joule was introduced around SAP TechEd 2023, and the buzz around its application in BTP and SAP began to grow. I had an incredible opportunity to be the first developer in my previous company to work on a Gen AI use case even before SAP started offering various Gen AI offerings across its portfolio in 2024. I co-developed a customer service assistant utilizing SAP Gen AI and BTP with Ethan Jewett(SAP Alumni Mentor and my manager I was fortunate to work with during and after my Graduate school where I focused on AI and Data Mining) and Abesh Bhattacharjee(SAP Author, Mentor, and an awesome teammate I learned a lot from on and off work in a short time I interacted with him). After reading Ethan's blog on 'Leveraging the richness of SAP data and processes in GenAI systems' and Abesh's blog on 'Dr RAG and Mr HyDE' i was inspired to think and ideate how Generative AI can be applied to enhance supply chain transportation industry/customers. I'm excited to share my insights and ideas in the above article. cc: @esjewett @abesh

Digital Technologies SAP BTP Security SAP S/4HANA SAP HANA Cloud, SAP HANA database SAP Analytics Cloud SAP Fiori Elements SAP Integration Suite SAP Build Process Automation ,SAP Innovation Management Sustainability SAP Supply Chain Management Travel and Transportation Machine Learning Artificial Intelligence SAP Agile Data Preparation SAP Enterprise Architecture Designer SAP BTP, Cloud Foundry runtime and environment SAP Data Intelligence SAP Datasphere SAP Alert Notification service for SAP BTP

How to setup SAP CDC Solution in Azure Data Factory

2024-09-20T22:06:52.277000+02:00

Introduction

Azure Data Factory (ADF) is a data integration (ETL/ELT) Platform as a Service (PaaS) and for SAP data integration, ADF currently offers six connectors:

These connectors can only extract data in batches, where each batch treats old and new data equally w/o identifying data changes (“batch mode”). This extraction mode isn’t optimal when dealing w/ large data sets, such as tables w/ millions/billions of records, that change often

Consequently, customers have been asking for a new connector that can extract only data changes (inserts/updates/deletes = “deltas”), leveraging Change Data Capture (CDC) feature that exists in most SAP systems (“CDC mode”). After gathering their requirements, New SAP CDC connector leveraging SAP Operational Data Provisioning (ODP) framework. This new connector can connect to all SAP systems that support ODP, such as R/3, ECC, S/4HANA, BW, and BW/4HANA, directly at the application layer or indirectly via SAP Landscape Transformation (SLT) replication server as a proxy. It can fully/incrementally extract SAP data that includes not only physical tables, but also logical objects created on top of those tables, such as ABAP) Core Data Services (CDS) views,

Architecture

The high-level architecture of our SAP CDC solution in ADF is divided into two sides, left-hand-side (LHS) and right-hand-side (RHS). LHS includes SAP CDC connector that invokes ODP API over standard Remote Function Call (RFC) modules to extract raw SAP data (full + deltas). RHS includes ADF copy activity that loads the raw SAP data into any destination, such as Azure Blob Storage/Azure Data Lake Store (ADLS) Gen2, in CSV/Parquet format, essentially archiving/preserving all historical changes. RHS can also include ADF data flow activity that transforms the raw SAP data, merges all changes, and loads the result into any destination, such as Azure SQL Database/Azure Synapse Analytics, essentially replicating SAP data. ADF data flow activity can also load the result into ADLS Gen2 in Delta format, enabling time-travel to produce snapshots of SAP data at any given periods in the past. LHS and RHS can be combined as SAP CDC/replication template to auto-generate ADF pipeline that can be frequently run using ADF tumbling window trigger to replicate SAP data into Azure w/ low latency and w/o watermarking.

ADF copy activity w/ SAP CDC connector runs on a self-hosted integration runtime (SHIR) that you install on your on-premises/virtual machine, so it has a line of sight to your SAP source systems/SLT replication server, while ADF data flow activity runs on a serverless Databricks/Spark cluster, Azure IR. SAP CDC connector via ODP can extract various data source (“provider”) types, such as:

SAP extractors, originally built to extract data from SAP ECC and load it into SAP BW
ABAP CDS views, the new data extraction standard for SAP S/4HANA
Info Providers and Info Objects in SAP BW and BW/4HANA
SAP application tables, when using SLT replication server as a proxy

These providers run on SAP systems to produce full/incremental data in Operational Delta Queue (ODQ) that is consumed by ADF copy activity w/ SAP CDC connector in ADF pipeline (“subscriber”).

INITIAL SLT CONFIGURATION

SLT is a database trigger-enabled CDC solution that can replicate SAP application tables and simple views in near real time. SLT replicates from SAP source systems to various targets, including the operational delta queue (ODQ). In S/4HANA 2020 and higher, the addon is already built into the S4CORE component.

During the replication process, database triggers track all changes to the data stored in the source tables. Every operation is registered in the logging table, and the function module transfers data to a specified target. SLT automatically creates all required objects when you initiate the data extraction. Keeping changes in the logging tables provides a level of fault tolerance that prevents data loss when the system that manages the replication is temporarily unavailable. In such a case, once the replication process is re-established, the SLT can easily identify all not-replicated changes and continue operation.

To start the replication process you need to set-up SAP SLT. You do it by creating configurations that controls the replication process. You manage the configuration in the SLT Cockpit (t-code: LTRC). In the Standalone deployment you should start the cockpit on the Replication Server, and not on the source.

The initial screen of the SLT Cockpit lists all previously created configurations. Each configuration has a unique identifier called Mass Transfer ID (MTID). Click the Create Configuration button to define a new one. It opens a wizard that guides you through basic settings.

The SAP SLT framework is part of the DMIS (Data Migration Server) component. In standalone deployment, you must install it on both systems: the source (transactional) system, as well as the one

The number of Data Transfer / Initial Load / Calculation Jobs should come from the sizing you perform. For small configuration, with limited number of tables in scope SAP recommends using not less than two data load jobs. There is 1-to-1 correlation between specified data transfer jobs and the dialog work processes in the source system.

The number of Initial Load Jobs should be lower than total number of data transfer jobs, otherwise after the initial load the system won’t replicate changes. Calculation Jobs run the initial assessment of the data stored in the source table and chunk data into smaller pieces.

Validation

To validate your SAP system configurations for ODP, you can run RODPS_REPL_TEST program to test the extraction of your SAPI extractors, CDS views, BW objects, etc.

Prepare SHIR (self-hosted integration runtime) w/ SAP CDC connector

To prepare SHIR w/ SAP CDC connector, complete the following steps: \

On ADF Studio, create and configure SHIR, We can download our latest private SHIR version w/ improved performance and detailed error messages from https://adfsapfileshare.blob.core.windows.net/shir/IntegrationRuntime_5.18.8172.1.msi and install it on your on-premises/virtual machine.
The more CPU cores you have on your SHIR machine, the higher your data extraction throughput.
To avoid being replaced by later versions, on ADF Studio, go to the Integration runtimes section of Manage hub, select your SHIR to edit, and select the Auto update tab to disable this feature.

Download the latest 64-bit SAP .NET Connector (SAP NCo 3.0) from https://support.sap.com/en/product/connectors/msnet.html and install it on your SHIR machine. During installation, select the Install Assemblies to GAC option in the Optional setup steps window.

Add a network security rule on your SAP systems, so SHIR machine can connect to them. If your SAP system is on Azure virtual machine (VM), add the rule by setting the Source IP addresses/CIDR ranges property to your SHIR machine IP address and the Destination port ranges property to 3200,3300. For example:

On SHIR machine, run the following PowerShell cmdlet to ensure that it can connect to your SAP systems: Test-NetConnection <SAP system IP address> -port 3300

Prepare SAP CDC linked service

To prepare SAP CDC linked service, complete the following steps:

On ADF Studio, go to the Linked services section of Manage hub and select the New button to create a new linked service.

Search for SAP and select SAP CDC (Preview).

Set SAP CDC linked service properties, many of them are similar to SAP Table linked service properties
1. For the Connect via integration runtime property, select your SHIR.
2. For the Server name property, enter the mapped server name for your SAP system.
3. For the Subscriber name property, enter a unique name to register and identify this ADF connection as a subscriber that consumes data packages produced in ODQ by your SAP system.

Test the connection and create your new SAP CDC linked service.

Monitor data extractions on SAP systems

To monitor data extractions on SAP systems, complete the following steps:

Using SAP Logon Tool on your SAP source system, run ODQMON transaction code.

Enter the value for Subcriber name property of your SAP CDC linked service in the Subscriber input field and select All in the Request Selection dropdown menu to show all data extractions using that linked service.

You can now see all registered subscriber processes in ODQ representing data extractions from ADF copy activities that use your SAP CDC linked service. On each ODQ subscription, you can drill down to see individual full/delta extractions. On each extraction, you can drill down to see individual data packages that were consumed.
When ADF copy activities that extract SAP data are no longer needed, their ODQ subscriptions should be deleted, so SAP systems can stop tracking their subscription states and remove the unconsumed data packages from ODQ. To do so, select the unneeded ODQ subscriptions and delete them.

Conclusion:

The SAP CDC connector in Data Factory reads delta changes from the SAP ODP framework. The deltas are recorded in ODQ tables.

Reference:

Overview and architecture of the SAP CDC capabilities - Azure Data Factory | Microsoft Learn

Integrate SAP LeanIX with Integration Assessment in SAP Integration Suite

2024-09-30T08:39:17.453000+02:00

Integration Assessment

In the mission, you will start using Integration Assessment for defining, documenting, and executing an integration technology strategy for your organization. After you will have configured Integration Assessment you will process a sample business solution request to specify your integration requirements and an interface request to determine the most suitable integration technology with the help of the intelligent proposal service.

SAP LeanIX

Key features of LeanIX are:

Application Portfolio Management: Helps assess and manage the applications in use, facilitating retirement or replacement decisions.
Integration with SAP: Provides tailored functionalities for SAP users, allowing them to leverage existing SAP data and processes.
Collaboration Tools: Supports teamwork and communication among stakeholders involved in enterprise architecture initiatives.
Reporting and Dashboards: Offers visualizations and analytics to track progress and performance metrics.

SAP system integration is a key process for enterprise architects embarking on application modernization. Yet, it isn’t always straightforward.

SAP is the world’s largest provider of enterprise application software, used by 87% of all global commerce and 99 of the world’s 100 largest companies. At the core of SAP’s impressive market share is their ability to deliver value through seamless integration. Yet, to benefit from this, SAP must be connected to other key business systems, which may be in need of re-organization.

The technical and strategic change management considerations related to SAP system integration require thorough preparation. Many companies fail to meet the full potential of integration because of these challenges.

In this guide, we’ll break down seven steps you can take to meet integration challenges head-on and execute the process with confidence.

SAP Standard Integration Package by NTT DATA Business Solutions

This integration package is designed to synchronize data between SAP LeanIX and Integration Assessment, focusing primarily on the synchronization of Applications, Vendors and Interface Requests. Utilizing the SAP Integration Suite, this synchronization process ensures a seamless, secure, and up-to-date data flow. This enhances the accuracy and efficiency of IT integration strategies, providing comprehensive insights for integration assessments

Note: Due to the equivalence of 'Vendors' in Integration Assessment to 'Providers' in SAP LeanIX for simplicity and clarity, 'vendor' is used as the uniform term throughout the package.

The package comprises four distinct integrations, each serving unique functions and designed to operate independently. Users can select and deploy any iFlow according to their specific requirements and needs:

Fullsync Integration Assessment Vendors: Synchronizes all vendors (providers) from SAP LeanIX to Integration Assessment. This interface is triggered manually and operates once per trigger.
Fullsync Integration Assessment Applications: Synchronizes all applications from SAP LeanIX to Integration Assessment. This includes optional synchronization of application instances (on-premise/public-cloud/private-cloud). This interface is also manually triggered and operates once per trigger.
Create Integration Assessment Vendor: Activated whenever a factsheet of type 'provider' is created in SAP LeanIX. This event triggers the creation of a new vendor in Integration Assessment, ensuring real-time data updates.
Create Integration Assessment Application: Similar to the vendor creation interface, this is activated when a factsheet of type 'application' is created in SAP LeanIX. It triggers the creation of a new application in Integration Assessment, including the synchronization of application instances (on-premise/public-cloud/private-cloud) if applicable. This interface also requires manual triggering and operates once per trigger.
Create SAP LeanIX Interface Factsheet: Synchroniz a SAP LeanIX Interface Fact Sheet from Integration Assessment Interface Requests at a configurable interval. Applications selected in the Interface Request will also be referenced in the Fact Sheet, provided they have been synced by this package.

https://api.sap.com/package/SAPLeanIXIntegrationwithSAPIntegrationSuite/overview

User Journey

New created applications in SAP LeanIX

Automated Sync to Integration Assessment

New Business Solution Request in Integration Assessment

New Interface Fact Sheet in SAP LeanIX

Outlook

Does that Integration help you?
Would you like to integrate with other tools?
What are you use cases?

Please use the comment or send me a message 🙂
I'll be happy to discuss your scenario and requirements around SAP Integration Suite and SAP LeanIX!

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

SAP Community - SAP Integration Strategy

Certification for Partner AI Apps on SAP BTP – Ensuring Reliability, Responsibility, and Relevance

UPDATE - *Exclusive Offer: Certification for Partner AI Applications on SAP BTP available for FREE*

Overview:

SAP BTP: Empowering Applications with Generative AI

Launching certification program for partner AI applications:

Benefits of certification for Partners:

What Next:

Create DataType and Message Type artifact in Cloud Integration capability of SAP Integration Suite

Simplifying SAP Implementations with Generative AI Innovations

SAP Integration Suite – Generative AI based Integration Flow Generation

Introduction

Enabling GenAI Based Integration Flow Generation feature

Generating Integration Flows

Summary

Digital Transformation. View of an Enterprise Architect - Steps and Tips

Specialist Department

Project Sponsor (Board of Directors, Management)

IT-Department

Setting the Stage

Maximize Customer Retention with Customer Service Tools in SAP Commerce Cloud

Integrating SAP Systems with Non-SAP Cloud Data Warehouses Using OData

Introduction

Background

Why OData?

Implementing OData Integration

Prerequisites

Steps to Generate and Consume OData Services

Azure Databricks Configuration

Solution Approach: Pros and Cons

Pros

Cons

Conclusion

What’s New for SAP Integration Suite – June & July 2024

Cloud Integration

Accelerate development of integration flows with generative AI assistance

New adapters available

Creation of new data type and message types

New design guidelines added for the validation of integration flows

Edge Integration Cell

Additional adapters

Simulation support

API validation policy for API artifacts

Kubernetes cluster deployment on Red Hat OpenShift

Offline availability during periods of temporary connectivity loss

Sizing recommendations for asynchronous messaging

Support for outgoing connections through a HTTP proxy

API-led Integration

API anomaly detection reduces security and performance risks

Maintenance of multiple target endpoints through UI

Changes in user interface

B2B Integration

Make use of your own global custom codelists

Integrations with trading partners through value-added networks

Support partners with subsidiaries

Event-driven Integration

Improved situational awareness with Event Mesh

Additional data centers for advanced event mesh

Migration Assessment and migration tool

Modernization recommendations for on-premise integration scenarios

Updates to the pipeline concept

New rules added to Migration Assessment

Migration tooling is now pattern-based

Support for message type objects in migration tooling

Business Accelerator Hub

Search and discovery of validated partner use cases

New partner content

How to stay tuned to recent and upcoming innovations?

SAP Integration Strategy - End-to-end business processes deep dives - NEW eBook available

What’s New for SAP Integration Suite – August 2024

A2A integration

Get ready with custom and purchased adapters for the Apache Camel 3.14 upgrade

Edit namespace for message types

Persistence in MariaDB databases

Principal propagation as authentication method to connect with on-premise systems

New parameters in SFTP and AMQP sender adapters

Inspection of content size

Integration in private landscapes

Diagnostic tasks in operation cockpit of Edge Integration Cell

B2B integration

UPDATE - Exclusive Offer: Certification for Partner AI Applications on SAP BTP available for FREE