SAP Community - Cloud Integration

New Integration Content for Coupa to SAP Signavio Process Intelligence Now Available

2025-05-28T14:19:56.416000+02:00

We’re excited to announce that new integration content for Coupa to SAP Signavio Process Intelligence is now available, offering organizations an enhanced capability to analyze their end-to-end procurement processes. This valuable integration is accessible free of charge on the SAP Business Accelerator Hub, empowering businesses to make data-driven decisions with greater precision and efficiency.

Streamline Your Procurement Analysis

Procurement processes are complex, involving numerous stakeholders and steps that can create inefficiencies and gaps if not closely monitored. By leveraging the new integration content for Coupa and SAP Signavio Process Intelligence, you can gain comprehensive insights into your procurement workflows. This integration helps you visualize, analyze, and optimize the entire procurement process from purchase requisition to payment, ensuring greater transparency and continuous improvement.

How to Access the Integration Content

Accessing this powerful integration is straightforward. To get started:

Navigate to the “Explore” tab and search for “SAP Signavio”.

Locate the new integration content for Coupa.

View the integration package and dedicated integration flows.

The integration package includes dedicated integration flows that outline the relevant business objects and events extracted by default. This setup enables a quick start with the flexibility to adjust and extend the content to meet your specific business needs.

Key Benefits of the Integration

End-to-End Visibility: Gain a holistic view of your procurement operations, identifying bottlenecks and opportunities for optimization.
Customizable Data Extraction: The predefined business objects and events can be tailored to your organization’s unique requirements, offering adaptability for varied use cases.
Enhanced Decision-Making: With seamless data extraction from Coupa and integration into SAP Signavio Process Intelligence, organizations can make informed decisions based on accurate process execution data.

Share Your Feedback

We value your input and look forward to hearing your thoughts on this new integration package. Share your experiences and suggestions in the comments section below.

Start analyzing and optimizing your procurement processes today with the new Coupa to SAP Signavio Process Intelligence integration. Discover how this solution can transform your operations and drive better outcomes.

In case you have not seen it yet, also check out the integration content we have recently released for Salesforce (Blog post / Integration content) and Microsoft Dynamics CRM (Blog post / Integration content)

Cloud to Cloud的数据直连集成：业务伙伴Business Partner主数据

2025-05-29T10:31:27.171000+02:00

这篇文章是作为Cloud to Cloud的数据直连集成：产品主数据的后续，介绍第二个集成场景：业务伙伴Business Partner主数据。

1. 业务伙伴Business Partner的集成：

BP主数据的集成，我们参考的是同一个scope item 1RO（Master Data Integration）。

1.1 发送系统的设置

1.1.1 创建通信系统

与前一个场景一样，我们同样需要首先设置通信系统。该通信系统是需要集成的目标系统。

输入自定义的System ID、System Name，Host Name为接收系统（receiver system）的地址，维护字段Logical System和Business System。

另外，需要在通信系统中维护通信的inbound user和outbound user。

这里需要特别注意的是，发送系统的outbound user与之后维护的接收系统的inbound user需要一致。

1.1.2 创建通信安排

BP主数据的集成借助了通信场景SAP_COM_0008，创建基于该通信场景的通信安排，选中之前创建的通信系统：

具体使用到的接口信息如下，选择激活该SOAP接口，并且维护Replication Model， Replication Mode， Output Mode。

1.2 接收系统的设置

1.2.1 通信系统的设置

不同于发送系统中创建的通信系统需要选择接收系统，在接收系统中创建的通信系统是选择其本身，因为在这个通信场景里，它是一个被动接收的角色。

同样，在该通信系统中，需要维护inbound user和outbound user。 inbound user需要特别注意，与之前发送系统的outbound user维护成一致。

1.2.2 创建通信安排

接收端的通信安排不需要激活outbound services，使用的是下面的这个inbound service。因此，不需要特别的设置。

1.3 设置消息的监控

为了测试中能够看到SOAP接口的消息，打开应用Assign Recipients to Users，给测试的用户分配以下条目：

1.4 测试

与前一篇分享的类似，BP主数据的集成可以单个集成同步（Replicate by Object Selection）或者批量同步完成（Replicate by Replication Model）。具体可参考 Cloud to Cloud的数据直连集成：产品主数据

1.5 查看消息日志

消息的查看同样是在Message Dashboard里可以看到。

2. 参考文档

如文章开头所说，实现Cloud to cloud的业务伙伴Business Partner主数据的集成，参考的是标准scope item 1RO，如想了解详细内容，可参考以下链接：

1RO（Master Data Integration）的set-up Guide

通过该标准流程，亦可实现BP主数据在cloud系统之间通过后台作业的方式实现数据的同步。

感谢阅读！

SAP Developer News May 29th, 2025

2025-05-29T21:10:00.041000+02:00

DESCRIPTION

PODCAST: https://podcast.opensap.info/sap-developers/2025/05/29/sap-developer-news-may-29th-2025/

SAP BTP ABAP Environment – Release 2505

Blog post: https://community.sap.com/t5/technology-blog-posts-by-sap/sap-btp-abap-environment-release-2505/ba-p/14102638
What's New in ABAP Generative AI in ABAP Cloud: https://help.sap.com/whats-new/4d359a7f8e8248e18f98e85ea0b9d83e?locale=en-US

Studio Home in SAP Build

Introducing Studio Home, new decision management application for business users

https://community.sap.com/t5/application-development-and-automation-blog-posts/empowering-business-to-manage-decisions-in-sap-build-process-automation/ba-p/14092130

Configure Studio Home application in Work zone – SAP Help Portal

https://help.sap.com/docs/build-process-automation/sap-build-process-automation/configure-studio-home-application

SAP CAP Developer Challenge June

Blog post: https://community.sap.com/t5/application-development-and-automation-blog-posts/sap-community-escape-house-for-june-sap-cap-%EF%B8%8F-%EF%B8%8F/ba-p/14110094
SAP Community Escape House: https://sap-community-escape-house.cfapps.us10.hana.ondemand.com/

SAPUI5 WCAG 2.2 Update

WCAG Homepage: https://www.w3.org/WAI/
WCAG 2.2 Changes: https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/
SAPUI5 is Leading the Way in Accessibility with WCAG 2.2 Blog Post: https://community.sap.com/t5/technology-blog-posts-by-sap/sapui5-is-leading-the-way-in-accessibility-with-wcag-2-2/ba-p/14101596

New learning content for SAP Integration Suite

SAP Integration Suite Basic Trial: https://community.sap.com/t5/integration-blog-posts/sap-integration-suite-basic-trial/ba-p/14112484
Start your free trial for SAP Integration Suite: https://www.sap.com/products/technology-platform/integration-suite/trial.html
Get Started with SAP Integration Suite, advanced event mesh: https://developers.sap.com/mission.advanced-event-mesh-get-started.html

CHAPTER TITLES

0:00 Intro

0:10 SAP BTP ABAP Environment – Release 2505

1:29 Studio Home in SAP Build

3:38 SAP CAP Developer Challenge June

4:37 SAPUI5 WCAG 2.2 Update

5:18 New learning content for SAP Integration Suite

TRANSCRIPTION

[Intro] This is the SAP Developer News for May the 29th, 2025.

[Shilpa] Hello, ABAP Developers. The ABAP release of 2505 happened last week, and I'm here to highlight some of the key features. Firstly, reduction in the technical downtime during the release upgrade, which is great to keep your business process running. Secondly, in ADT, there is a new wizard called Quick Fiori Application Generator, which will help you to generate a Fiori project within ADT itself. You need not have to log into Business Application Studio or Visual Studio Code to create a Fiori project, but it is integrated with ADT. A video about this feature will be available coming Monday in our SAP Developers YouTube channel. And thirdly and most important one, AI in ABAP. In the AI space, I want to highlight three things. First, Joule Chat is now integrated in ABAP repository object generator wizard, which will help you to generate OData UI service from the scratch just by using natural language prompts. Second, Unit test is quite important, and you can now use the prompt to generate ABAP Unit test methods. Third, the prediction of the code completion has been enhanced. There are other features related to ADT, OData, CDS, which is described in the blog post by Nora Klemp, which is in the description. Do check it out.

[Shrinivasan] Decisions in SAP Build allows business users to create business rules for approval policies, pricing logic, visibility check, etc. within a process automation project. Until now, even the simplest rule modifications required developer intervention, leading to delayed updates and a slow change management cycle due to their dependency. That's where Studio Home, SAP Build's latest decision management application comes in. With the new Studio Home, business users can now view, edit and maintain decisions from a dedicated user interface that only shows the decision artifacts within a project. Options such as inputs, outputs, reorder, create new rule are not present in this user interface, showing only the options that are relevant to the business users With a one-click button, they can release a patch version of the project and deploy it after making the rule updates This application comes with a design console that shows any error or warning message during the release and deployment of a project and a version history option to navigate and view the previous versions of the decision artifacts in the project. The Studio Home application can be configured to be accessed from a work zone tile. The instructions to configure the application in the work zone site is provided in the help portal. On top of Studio Home's release, there are enhancements to the expression editor in decision tables, making quick edits faster and more intuitive than ever before. With a new Studio Home, business users can now take the ownership of maintaining and owning the decision artifacts independently. By simplifying the process, reducing dependencies, and accelerating change management, decision management is more accessible and efficient than ever. Check out this blog post from Sesh Sreenivas to find out all the details about Studio Home and the enhancements to the expression editor for decisions.

[Ajay] Hello everyone. We have almost come to the end of this month and we thank all the participants who have already completed the ABAP Developer Challenge. We still have a couple of days to finish the ABAP Developer Challenge and earn a badge of completion. In June, we get to escape a brand new room for SAP Cloud Application Programming Model in SAP Community Escape House. This room will be unlocked next week for the participants to attempt the SAP Developer Challenge. In order to escape the CAP room, you would have to create a CAP project, create some custom code, and perform some testing. On your way out, you will also learn about remote debugging. In order to participate, you just need to use your user ideas and input and start the challenge and explore the story that unfolds. Links to the SAP Community's Cave House are included in the description. Wishing you all the best for your challenge and happy learning!

[Michelle] SAP has announced that its SAPUI5 Web Development Framework now complies with the latest Web Content Accessibility Guidelines, WCAG 2.2 and SAPUI5 version 1.136 and UI5 Web Components version 2.9.0. These updates enhance features like focus visibility and assistive technology, ensuring better usability for people with disabilities and improve the user experience overall. If you're interested to learn more of what kind of changes have been made to the SAP UI5 and UI5 Web Components frameworks, be sure to check out the link in the description below. Happy coding!

[Antonio] Hola, SAP developers. I'm always amazed by how accessible SAP learning content is nowadays. Long gone are the days that the only way you could learn about an SAP technology was by attending a course at a training center. I just want to highlight two new learning offerings that are available to all of you developers out there who are interested in learning about integration. There is the new SAP Integration Suite basic trial, which provides you a ready-made environment where you can get familiar with a few capabilities, like for example, cloud integration, API management, and integration assessment. It should take you around an hour 30 minutes to complete it, so go ahead and check it out. Also, there's a new mission in the tutorial system, which helps you get started with SAP Integration Suite Advanced Event Mesh. It covers everything, from creating an instance to connecting to an S4HANA cloud system, getting familiar with the main components of the service, and how you can integrate with other products, like cloud integration and SAP Build Process Automation. All the content is freely available. It is just a matter of dedicating time to learn. So, go ahead and enjoy the learning. Happy learning!

A look into the Migration Assessment Modernization Recommendation - Clean Core

2025-05-30T09:23:11.898000+02:00

Moving from SAP Process Orchestration to SAP Integration Suite shouldn’t be just about migrating.

In order to unlock full potential, increase agility and flexibility and reduce technical debts we have to think about modernization.

The modernization recommendations are used in the Migration Assessment capability of Cloud Integration. Once you´ve extracted your integration scenarios and executed the Scenario Evaluation, you can find the modernization recommendations in the Dashboard and in the downloadable Evaluation Run Results reports - under the Modernization Recommendations section of the pdf and in the Recommendations and API Recommendations tabs of the excel, as shown below:

So, you have done your data extraction and opened the respective Scenario Evaluation Dashboard. There you can see the Modernization Recommendations under the Overview tab, and you have the option to export the results to a spreadsheet or to generate a report.

When you open the pdf report there is a section dedicated to modernization recommendations, where you can have an idea of the integration scenarios that could be improved.

In a similar way, when you open the excel results you can check the recommendations for the possible modernization item of the integration scenario and the category it falls into.

On a different tab, you can also analyze the API recommendations presented based on the extracted Object ID, its type, and the proposed solution.

And on the next tab, you can see the recommendations for the existing Business Event scenarios.

Those recommendations point out where your existing integration scenarios show potential to be updated for optimal usage in Cloud Integration and can be divided in the following categories:

Clean Core: Recommendations on replacing outdated or custom interfaces with standard content or standard APIs to be up to date and in line with SAP product strategy

Integration Style: Recommendations on integration patterns

Mapping: Recommendations on using different mapping approaches

Monitoring & Operation: Recommendations on enhancing monitoring and operations

Protocol: Recommendations on using state-of-the-art communication protocols

Security: Recommendations on using state-of-the-art security options in integration scenarios

Today we will focus on the category Clean Core Modernization Recommendations.

As SAP landscapes evolve to meet the demands of agility, scalability, and innovation, the concept of Clean Core has become a key priority. It refers to maintaining a stable, upgrade-friendly SAP system by minimizing customizations and relying on standardized, modern integration practices.

Guiding Principles

Having that in mind the guiding principles for the clean core modernization rely on four pillars:

Avoid extensions where not necessary and stay as close as possible to SAP standards.

Be Aware of your technical debts, evaluate them on a regular basis and establish a binding governance framework.

Be Cloud Ready by extending and integrating in a stable and transparent manner.

Decouple by leveraging BTP as a platform to innovate for additional differentiation and automate with standard APIs and Events.

Integration Dimension

There are some main aspects regarding the integration implementation that you can follow to keep your landscape reliable:

Integrations shall be based on standard APIs (OData and SOAP).

Aim for side-by-side extensibility with API integration or even SAP Build, by utilizing the tight coupling with the SAP Cloud Integration.

Loosely coupled integrations could be realized in an event-driven design based on standard events.

Avoid traditional APIs (RFC and IDoc) and their related classical extension options.

Ensure proper monitoring and error resolution capabilities by utilizing SAP Application Interface Framework.

Three of the most impactful modernization moves include:

1. Replacing RFCs (BAPIs) with SOAP/OData APIs

Modern APIs are better suited for integration with both SAP and non-SAP systems, offering:

Greater flexibility for future changes

Public documentation and support via SAP Business Accelerator Hub
Cleaner, standardized interfaces

2. Replacing custom interfaces with Pre-Delivered Packages

Pre-delivered content accelerates implementation and ensures consistency:

Saves development time with ready-to-use mappings and flows

Built on best practices and regularly updated by SAP
Scalable and adaptable for enterprise growth

3. Replace IDOCs with SOAP/OData APIS or Business Events

Using open and standardized protocols like SOAP or OData for event communication provides benefits like:

Interoperability

Wider adoption

Easier integration with non-SAP systems

The central access point to discover integration artifacts like standard APIs, events and integration flows is SAP Business Accelerator Hub.

Below you have a step by step of how to find the recommended API and business event highlighted in the API Recommendation and Business Event Recommendation tabs of the Evaluation Run Results excel.

So, you opt to move forward with the API and the Business Event recommendations and choose the object you want to replace. Let’s take the second line as an example, the Object ID is ORDERS05, and you will be replacing an IDOC for an SAP S/4HANA or SAP S/4HANA Cloud Public Edition SOAP API, depending on your context.

As for the business event, you will be replacing the IDOC for a Purchase Order Event, available either on SAP S/4HANA Business Events or SAP S/4HANA Cloud Public Edition for Business Events, according to your context.

Note that in these cases we can see that there is a solution available for both S/4HANA versions, but sometimes the suggestion might be only available for one of the versions (public or private edition).

To find the recommended object you must open the Business Accelerator Hub and look for it. There are multiple ways to do it.

You can go to the general categories of APIs/Events, where both SAP S/4HANA and SAP S/4HANA Cloud Public Edition will show up.

There, you can search by the name and protocol provided in the Evaluation Run Results excel or by the event name, respectively.

As an alternative you can go directly to SAP S/4HANA Cloud Public Edition and search there for the Public Edition solution.

In a similar way, you can go directly to SAP S/4HANA Cloud Private Edition and search there for the S/4HANA solution either for the API or for the business event.

For an even more refined result you can search by the API or the event technical name and get a 1:1 match.

Once you find it, you can access the specification and use it on Cloud Integration.

Note that after the replacement, either by S/4HANA or S/4HANA Cloud Public Edition API/Event, further changes in the iFlow may be required. At the moment that additional effort is not being considered on the effort estimation results, so it is important not only to have that in mind but also to verify if that given recommendation fulfills all the necessary functional requirements currently in place for the given business scenario.

Final Thoughts

Modernizing your integration landscape isn’t just about following trends—it’s about future-proofing your SAP environment. By replacing outdated technologies with standardized APIs and leveraging prebuilt content, you move closer to a Clean Core that’s easier to maintain, more responsive to business needs, and ready for the future.

Think strategically, start simple, and scale confidently by adopting SAP’s recommendations and incrementally build a cleaner and smarter core.

SAP Help Pages

To explore in more detail the Migration Assessment, refer to Migration Assessment or Automatically assess your migration
To get information on Modernization Recommendations, refer to Modernization Recommendations

ARIBA API data extraction & reporting with SAP BTP

2025-06-03T09:31:27.716000+02:00

Introduction

In this blog post I'm sharing some highlights from a recent project work involving data extraction from ARIBA API into SAP Datasphere OpenSQL schema using Integration suite with a basic dashboard in Analytics cloud.

✅ Use Integration Suite iflow to extract data from ARIBA API.

✅ Persisting records in Datasphere OpenSQL schema

✅ Data modelling in Datasphere

✅ Reporting in Analytics Cloud

Upcoming Functionality with SAP BDC 🚀

With the annoucement of SAP Business Data cloud (BDC), a fully managed SaaS solution that unifies and governs all SAP data and seamlessly connects with third-party data, we will soon have standard Data Products & Insight Applications across SAP LoB solutions, and with that we will have direct access to such data assets without the need for data integration as in this blog post. SAP has already started publishing these data products and these can be looked up here : SAP Data Products.

In this post you get to see some highlights with screenshots on how SAP Integration suite can work with ARIBA APIs, with end to end data modelling and visualization. Its quite relevant for customers with exisitng subscription of Integration Suite.

SAP Discovery Mission 🔍

For detailed implemenation of ARIBA API spend data extraction please refer this SAP Discovery mission which comes with Integration Suite iflows, sample SQL scripts to execute on Datasphere etc.

While the discovery mission is very detailed , we will observe in the blog post the overall flow with sample implementation steps using a single iflow and I hope it will help understand the overall flow when modelling ARIBA apis for extraction.

ARIBA API ⛓

I have used the Purchase orders buyer API which can tested using the free sandbox at api.sap.com

ARIBA Network Purchase Orders buyer API

Prepackaged Integration Content 🎁

With Integration Suites prepackaged content you get well designed iflows which you can configure for your specific systems & apis.

Explore Prepakaged Content on Business Accelerator Hub .

For the integration in discussion as well we have the standard iflows listed as below:

ARIBA connection iflows on Business Accelerator Hub

On your integration suite tenant you can access this prepackaged content under Discover --> integrations

Published ARIBA connection package in Integration suite :

As part of this packages you get 2 iflows as described below :

MODIFIED INTEGRATION FLOW (iflow): ↖️

I did some modifications on this prepackaged iflow so that I can connect to ARIBA and then process data using below addtional operators :

General Splitter
Content modifier
JDBC receiver (OpenSQL schema of SAP Datasphere)

If needed you can download this from my Github page : Download modified iflow

Here is a screenshot of the modified iflow :

So the second iflow "output_from_ARIBA" is simply calling the first iflow using ProcessDirect and it gets deployed with an HTTP end point, which when queried triggers the first iflow "Connect SAP ARIBA to the SAP ARIBA APIs". The iflows are used to just show the mechanism of fast and direct communication between iflows using Process Direct, you can read more it here : ProcessDirect

In the screenshot you see that "output_from_ARIBA" iflow gets deployed with an address of /vinay/Ariba, this will reflect in the eventual endpoint when the iflow is deployed.

Below we see the processDirect Adapter making an internal call to the first iflow, which gets deployed with an address : /Ariba/OpenAPI.

Extract data from ARIBA API ▶️

Lets now look at the first iflow "connect SAP Ariba to the SAP Ariba APIs" in detail. We will go through each important section of the iflow and understand the processing with screen shots.

GET ACCESS TOKEN

The first step in the iflow execution is to get an Access token from ARIBA's Oauth URL with encoded client id/secret, an auth token is returned which is then saved in the header.

GET DOCUMENT

Now when then access token is retrieved we can further add additional headers for our subsequent call to ARIBA's Purchase order buyer API, e.g in this case the ARIBA networkx- ID along with the API key.

Now we make the final HTTP request to ARIBA API, in the query ARIBA Realm and filters can also be specified.

JSON TO XML Converter

The JSON structure of the API was intitially tested at the api.sap.com, and now we have used JSON to XML converter, so the message can be parsed using the XPATH - which is a query language to navigate through elements and attributes in an XML document.

GENERAL SPLITTER

Splitter will simply split the XML message based on the number of records as in this example there will be multiple purchase orders returned from the ARIBA API.

CONTENT MODIFIER

In the message body of the Content Modifier, we now use Type Expression, to build a SQL query using the exchange properties we desgined above.

Finally, we reach the point of the database call which is configured as the OpenSQL schema of the Datasphere.

The JDBC connection is maintained in the integration suite tenant as below :

Runnning the Integration Flow

We deploy both iflows and we can see the Endpoint against the iflow below :

Call the endpoint either using Postman or visual Studio code and you will see the message processed as below :

We now verify the OpenSQL table to see the persisted records : ( Please note we only had a few records from the sabdbox API used in this case and the iflow was run mutiple times so you see some duplicate records below)

Data modelling in Datasphere 📈 📊

With the data moved to Datasphere OpenSQL schema we can access the table in Datasphere Data Builder, Open a new Graphical view and from the left navigation under sources you would see the linked openSQL Schema. Drag & drop the table on the canvas. I have added a calculated column here to convert the POAMOUNT to a decimal value ( it was nvarchar after the initial data import). Save and deploy the view.

Create an Analytical model using the Graphical view created above, use the POAMOUNT field as a Measure :

Reporting in SAP Analytics Cloud 📊

I'm using a linked SAP analytics cloud tenant, you can learn how to connect Datasphere & Analytics cloud tenants here.

Once linked, open a black story and proceed to add new data --> Existing Data model --> select Datasphere system from the left navgation as below.

Select your deployed model under the datasphere space name and build a story with data that you processed using the iflow :

CONCLUSION 🔚

Hope this helps the community members to get an overall idea of the integration discussed in this blog post and sparks ideas for your exisitng or future projects.

Thank you for your time & attention!

APPENDIX

Monitoring the iflow and the message flow using trace

As some of you must already know Integration suite provides several advanced capabilities to monitor the iflow. In the below steps we will enable the trace on the main iFlow and see how different components are workign together :

Enabling the Trace :

Navigate to Monitor --> Integrations and APIs --> Manage Integration Content and look for the "Started" iflows for ARIBA.

Here we enable the Trace by changing the "Log Level" to trace. The trace only gets enabled for 10 mins (default setting) as Integration suite startes storing on the messages.

Trigger the iFlow again to fetch the records and so that we can now see the tracing results :

Goto : Monitor --> Integrations and APIs --> Monitor Message Processing

you can now see the trace as below, click on the "Trace" :

Now, we can easily check various parameters, headers, exchange properties & payloads across various the iflow:

You can see the JSON payload coming through below :

Splitting & XML conversion happens in the iflow and here we see the splitted payload:

Extracted Exchange properties can be seen here (e.g documentNumber) :

Finally, we see the prepared SQL statement.

Tracing is a very powerful tool to debug the various phases of the iflow and at the same time allowing us to format the data passing through to make required corrections.

Currency Conversion using Integration Suite

2025-06-03T17:48:23.494000+02:00

Hi all. Today I will explain the use case of currency conversion that I have made using Integration Suite. Below I have attached the image of the Integration Flow that I have created:

In the Currency Parameter setting, we have set the 3 parameters : one for storing the currency in which we will insert our amount (say USD), second one for storing the target currency (INR), and the third one is for storing the amount which we want to convert to the target currency. Also, we set our APIKey here to acces the external api using Request Reply. Next we Request Reply to an external api, say fastFOREX, for fetching the base currency and the target currency/currencies rate(s). Then we use the script Amount conversion to convert the given amount to target currency amount. Then we formulate our final message in Payload Creation that we want to be sent to the target mail ids using mail adapter.

Here's a sample mail that one will get after deploying it:

If you want to change the currencies you can do the same by changing the toCurrency and fromCurrency properties in the 'Currency Parameter setting' Content Modifier.

Hope you like it.

#btp cpi @Mukulvarshney8 @Bibekananda123

Integrating GMAIL using SAP CPI Mail Adapter in iFlow

2025-06-03T17:48:40.060000+02:00

Hi All,

📌 Introduction

In SAP CPI (Cloud Integration), the Mail Adapter for Gmail plays a crucial role in automating email notifications and integrating email functionality into business processes. It allows seamless communication via SMTP, ensuring secure transmission of emails within integration flows.

Below is the image of the Integration Flow I created:

📌 Step 1: Content Modifier for Email Body

I have used a Content Modifier named Mail_body to define the email content dynamically using HTML code for styling. This ensures structured email formatting and supports customization.

📌 Step 2: Configuring the Mail Adapter

The Mail Adapter is configured using an SMTP connection to communicate with the Gmail server.
An Authentication Credential is created under Security Material with the help of GCP (Google Cloud Platform) credentials to ensure secure email transmission and prevent unauthorized access.
Under the Processing tab, I have defined the mail attributes, including:
- Recipient details (To, CC, BCC)
- Subject line
- Body Mime-Type set as "Text/HTML" for styling the email body using HTML.

📌 Step 3: Sample Email Output

Once deployed, here’s a sample email that users will receive: (Attach an example email screenshot here.)

📌 Step 4: Using Exchange Properties for Dynamic Content

To store dynamic email content (mail attributes), we use exchange properties in the Content Modifier. This allows dynamic values like recipient email, transaction details, and timestamps to be populated during runtime.

Conclusion

In this blog, we explored how to: ✅ Set up the Mail Adapter in an iFlow. ✅ Configure SMTP authentication for secure email transmission. ✅ Format HTML-based email bodies for structured messages. ✅ Optimize integration with exchange properties for dynamic content.

By applying these best practices, enterprises can enhance email reliability, security, and customization in their CPI workflows. With continuous enhancements in SAP Integration Suite, email-based automation will remain a powerful tool for business process efficiency.

If you have any questions or insights, feel free to share your thoughts in the comments!

@Souravraj_Maitra @Bibekananda123

Sending a processed payload to receivers

2025-06-03T17:49:04.188000+02:00

Hi all,
today I will be explaining the use case of payload processing using Integration Flow. Below I have attached screenshots and their corresponding explanations:

1. Sample Payload

Here's the sample payload that we will be providing to the Integration Flow using Postman thats the sender here. This payload, as you can see in the JSON Format.

2. Sample Payload:

This is the response we are supposed to get after final processing of the payload using iFlow. Seeing the response, we can understand that we need the following for this message to be formulated:
a. firstName

b. mailID

c. totalProductPrice

3. Integration Flow:

As mentioned in the previous point, Postman is the sender here. As for thew remaining components, we will be explaining it stepwise:
i. Payload Append: We are using this script to accept the payload from the Postman ,calculate the total productPrice and append it to the JSON Payload.

ii. JSON to XML Converter: It converts the modified payload to an XML file.

iii. Content Modifier: It's used to pull the data we mentioned in the previous point from the XML file i.e. firstName and mailId that was there initially, and totalProductPrice that we appended to the payload in Payload Script, into the properties section using XPath. After this we formulate the message, we mentioned in Sample Payload to be sent to the receivers.

iv. Parallel Multicast: It's used to send copies of the same message to multiple targets parallelly. In our case its just 2 targets - one to the mail adapter, another to the target system using SFTP. For this adapter to work, we need required certifications in Monitor --> Integrations and APIs --> Manage Security --> Security Materials.

v. Receivers: Here we have 2 receivers - one is gmail recipient using Mail adapters and other is SFTP. Mail adapters are used to to connect iFlow with mails and SFTP is used to connect iFlow with Client system for secured file transfer. A point to note: the file you want to transfer must have a copy in the target system, it can be empty. If not, it will throw an error.

===================================================================================

Hope my explanation is up to the mark. Please feel free to ask any questions you may have.

#btp cpi

@Mukulvarshney8 @Bibekananda123

Understanding incorrect Message Mapping and why Context matters

2025-06-03T17:50:15.893000+02:00

What are Contexts in Message Mapping?

Contexts allow for a logical grouping of data elements, influencing how data is processed during mapping. Each context can hold specific information that helps in deciding how data should be transformed.

Why Contexts are Important

Data Organization: Contexts help organize data, making it easier to see relationships and hierarchies.
Flexibility: They allow different data sets to be handled differently based on situations.
Performance: Using contexts can make data processing more efficient by simplifying the transformation steps.

Understanding Queues in Message Mapping

Queues temporarily hold messages as they move between processing stages, ensuring orderly data handling. They help manage messages between systems, especially when different systems process data at different speeds.

Purpose of Queues: Queues help buffer messages and synchronize data processing.
Integration with Contexts: Contexts help organize how messages are processed once in a queue and may trigger specific processing rules based on the data.

Managing Contexts

Defining Contexts: Clearly define contexts to represent different data areas when creating message mappings.

Using Context Functions: SAP offers tools to help change data within contexts, such as 'Context Switch' functions.
Context Variables: Use temporary context variables to retain values during processing, avoiding repeated calculations.
Conditional Logic: Use if-else statements to adjust the context based on incoming data from queues.
Nesting Contexts: Nest contexts for complex data structures, allowing better data management.

Hands-on example

With the basics out of the way, lets look at the information in a real world example, a problem that i had to resolve a while back. In one flow an issue arises, somehow data gets mixed up after message mapping. Users (Employees) have mostly correct information, but at some point Users have a correct ID, correct job description, etc. However, their first and last names are incorrect. How can this happen? But not only that, looking at the bottom of our Employees, the last few entries of our mapping results are basically empty.

Identifying an issue with source data

After a lot of searching, debugging, checking we find out that our mapping tries to look up some nodes that do not exist:

In our case, the "empInfo" tag is empty, this holds information about our employees, like the aforementioned firstName and lastName.

Debugging

So this mapping here is being ignored, as the nodes leading up to it do not exist and the whole mapping is skipped.This is where the queue comes in, but in a way that messes up our data. Let's have a look at what i am talking about:

To check out what exactly is happening with our data, it is necessary to provide a test input file. This can be done in a few different ways, like when trying to simulate mapping some examples which requires data given with a test file. Once we provide a file, we can check out what the input queue looks like and what it would look like after mapping:

The input node can display the input queue, which in our test case right now would look something like this:

Well that's fine but what are we looking at here? First entry, the <null> can simply be ignored, this is the start of the queue. Every white background entry means a value that will end up in our mapping result, which we can check here:

Every grey entry means a context change. Basically a new entry, in our case a new Employee. But right there, we can see two grey rows with "Brandon" in them. A white row is missing. That is the reason why our resulting mapped list of Employees firstName is messed up. Say we have 10 employee's first names and we want the result to also show these 10 names, with our given example we would end up with only 9 names. Because the context changed and no value was given.

Why fix the message mapping?

Why would an employee have no first name? Simple actually. Admin users, service users. If we were to exclude them from the mapping, filter them out before mapping, we would be done and could continue without a problem. Yes, that is a possibility. But then again, what other issues might arise with our given data? How much more would we have to filter out, would we even be aware of incorrect data? In our case alone, we found two more instances of the source data not being what we expected it to be. No, filtering is not the solution here.

Tools

What we need to correctly map everything thrown at us is to handle the context and handle the queue. Message mapping gives us a few tools that we can use.

This method allows us to handle every context change by ourselves. In the Advanced section there are several options, so we can change the context only when the value in the queue changes, only on empty values, etc.

This method can give us a default value if the input is empty.
With these two we changed the mapping on all of our input fields, so they all look like this now:

So we force our given queue to always give us something into our output and the context is forced to always change.
But still, we have issues. Because even if we make sure to always handle the context correctly, this does not matter if we can't even reach the input node during mapping. As we've seen earlier, the whole chain of nodes leading down to the firstName doesn't exist. So we created a perfectly fine mapping which is simply ignored by our message mapping.

The solution

The solution is simple but very easy to miss. When we select the input property and click the three-dots-menu, we are given a few selections.One of these options is the Context entry:

Here we can see our chain of nodes. In this case PerPersonal cannot be reached as many of its parent nodes are missing. So all need to do is select the lowest node that always exists, the node that we are sure is always present. In our case this was empInfo:

The result

With this new start of the context selected, and all of our additional methods for context manipulation, our output queue now looks like this:

The queue changed, so even if we have some missing nodes, our output would still have at least something, in this case an empty String (as provided in the default value mapping).
After we changed the context and added the node methods on all of our input fields, it was done. We mapped all of our data correctly, nothing was missing.

Success.

Cloud to Cloud的数据直连集成：PO/SO转换

2025-06-04T08:27:13.971000+02:00

这篇文章是作为Cloud to Cloud直接集成的第三篇介绍，前面两篇关于产品主数据和BP主数据的集成可参考以下链接：

Cloud to Cloud的数据直连集成：产品主数据

Cloud to Cloud的数据直连集成：业务伙伴Business Partner主数据

1. 背景介绍

除了之前介绍的主数据集成，另外一个常见的场景是关于贸易公司和生产公司之间采购订单（PO）与销售订单（SO）的集成：当贸易公司生成采购订单，立刻集成到生产公司生成一张销售订单（SO）。两个系统间PO/SO的集成，可以实现Cloud到Cloud直连的方式，不需要借助中间平台即可实现。

2. 发送系统的设置

在这个集成场景中，我们借助了两个标准scope item来实现PO到SO的转换。

在发送系统中，需要往外发送采购订单（PO），参考的scope item是2EJ（Integration of Procurement with External Suppliers）。

2.1 创建通信系统

如果有实现之前主数据集成的场景，那么可以复用之前的通信系统。该通信系统是需要集成的目标系统。

输入自定义的System ID、System Name，Host Name为接收系统（receiver system）的地址，维护字段Logical System和Business System。

另外，需要在通信系统中维护通信的inbound user和outbound user。

这里需要特别注意的是，发送系统的outbound user与之后维护的接收系统的inbound user需要一致。

2.2 创建通信安排

参考scope item 2EJ，创建基于通信场景SAP_COM_0224的通信安排。在该通信安排中，使用到的是下面这个outbound service：

2.3 输出参数定义（Output Parameter Determination）

进入Fiori应用“输出参数定义Output Parameter Determination”，配置采购订单EDI相关的内容。具体可参考scope item 2EJ配置文档的2.2.16章节：

2.4 给用户分配收件人（Assign Recipients）

为了后续能够看到SOAP接口的消息，打开应用Assign Recipients to Users，给测试的用户分配以下条目：

3. 接收系统的设置

在接收系统中，我们将会接收从发送系统发出的采购订单，在接收系统内创建销售订单。参考的scope item是2EL（Integration of Sales with External Buyers）。

3.1 创建通信系统

在接收系统中，我们首先也是创建通信系统。同样，在该通信系统中，需要维护inbound user和outbound user。 inbound user需要特别注意，与之前发送系统的outbound user维护成一致。

3.2 创建通信安排

参考scope item 2EL，创建基于通信场景SAP_COM_0223的通信安排。在该通信安排中，使用到的是下面这个inbound service：

3.3 给用户分配收件人（Assign Recipients）

为了后续能够看到SOAP接口的消息，打开应用Assign Recipients to Users，给测试的用户分配以下条目：

在完成了上述的配置之后，发送系统创建采购订单，在采购订单审批完成之后，会自动触发该接口，在接收系统创建销售订单。

4. 参考文档

如文章开头所说，实现Cloud to cloud的PO转SO的集成，参考的是标准scope item 2EJ和2EL，如想了解详细内容，可参考以下链接：

2EJ_Set-Up_EN_XX.pdf

2EL_Set-Up_EN_XX.pdf

感谢阅读！

Add SAP PI/PO Communication Channel Start/Stop Functionality to Your iFlows

2025-06-04T09:14:40.214000+02:00

Greetings SAP Integration Community. My name is Craig Stasila, and I have been in the SAP integration ecosystem for many, many years. It has been a long time since I’ve written a technical blog post, but while I was at SAP Sapphire Orlando recently, a customer that had migrated from SAP PI/PO to SAP Integration Suite posed a question for which I did not have an immediate answer. I promised this person that I would author a blog post with all the details to answer her question, and this is that blog post.

Her question was simple--the answer was not exactly straightforward:

When will SAP Integration Suite have a feature like the SAP PI/PO Communication Channel start/stop control?

On its face, this request sounds like a regular feature request. But the power and flexibility of the Cloud Integration capability of SAP Integration Suite means that you do not have to wait for an official implementation of this feature, and this blog post will tell you how.

Quick sidebar: To create and vote on future feature requests, visit SAP Integration Suite Customer Influence campaign.

The following artifacts have been created to demonstrate the channel start/stop prototype. Each artifact will be explained below:

Figure 1: Package Channel Start/Stop Prototype Artifacts

Mass Controlling Communication Channels and Adapters

The adapter engine component of SAP PI/PO had a feature that allowed for communication channels to be started and stopped through an administration user interface. And, while SAP Integration Suite does not have this exact feature, we can implement a close analog.

We can accomplish this by having our iFlows check the status of a global variable, GlobalChannelStatus for example, and stopping the processing of the iFlow if it has a value of 'STOPPED'.

When to check and what to do if the variable is 'STOPPED' depends on whether the integration is synchronous or asynchronous.

Stopping Channel in Synchronous Integrations

Stopping processing for synchronous interfaces is relatively straightforward. The best practice to stop integration execution for synchronous interfaces is to stop processing and return the call to the sender as soon as possible--before any transformation of the message occurs.

Figure 2: Best-practice to stop synchronous interface processing

When implementing this pattern, handling and reprocessing the messages must be handled by the sender. The logic is implemented in the iFlow _1 Synchronous Check Channel Status.

Figure 3: iFlow _1 Synchronous Check Channel Status

As soon as the synchronous message arrives from the sender, the global variable GlobalChannelStatus is retrieved. A router checks the variable and if the value is 'RUNNING', the message can be transformed as normal and the message can be sent to the receiver system. If, however, the channel status is 'STOPPED', the message is stopped via an exception. I suggest referencing this blog post to create a custom error message so that the sending system receives the correct context that processing has been halted by the administrator.

Stopping Channel in Asynchronous Integrations

Stopping processing for asynchronous interfaces is a bit more involved. In addition to checking the global variable GlobalChannelStatus, we will also be implementing the Retry Pattern with a JMS queue. Unlike the best-practice for synchronous interface processing, for asynchronous processing it is the best practice to hold the message after the message has been transformed--immediately before the message is to be sent to the receiver.

Figure 4: Best-practice to stop asynchronous interface processing

Processing for the asynchronous scenario starts like any other interface. I created iFlow A - Build Message Payload to simulate the creation of a message payload whenever the package is deployed. In practice, this will be whatever the standard interface message processing will be. The sender system, channel, and message processing will be unchanged. The only feature that is specific to the channel start/stop processing is the usage of a JMS receiver at the conclusion of the iFlow processing instead of directly calling the receiver system.

Figure 5: iFlow A - Build Message Payload

The iFlow B - Check Channel Status and Send to Adapter is where we will check the status of the global channel variable and implement all of the JMS retry logic. This iFlow will be invoked immediately after A - Build Message Payload publishes the message to the shared message queue. The iFlow simply retrieves the global variable GlobalChannelStatus. If the value of this variable is 'RUNNING', the message is sent to the receiver system--in this case a iFlow called via the ProcessDirect adapter that simply logs the message payload. If the value of the global variable is 'STOPPED', the processing of the message is stopped and the message will stay in the JMS queue in a Failed status.

Figure 6: iFlow B - Check Channel Status and Send to Adapter

Finally, I created a small iFlow to mock a receiver system. The simple iFlow C - Process Direct Call Adapter logs the message header and body to the message processing log so that it can be viewed in the message monitor.

Figure 7: iFlow C - Process Direct Call Adapter

For this prototype, the global variable GlobalChannelStatus can be set to 'RUNNING' through iFlow D - Start Channels and can be set to 'STOPPED' by deploying iFlow E - Stop Channels. In practice, these iFlows could be triggered externally from an API or through a custom application.

Figure 8: iFlows D - Start Channels & E - Stop Channels

Conclusion

SAP Integration Suite is not a one-for-one reimplementation of SAP PI/PO in the cloud—in many ways it is way more powerful. This blog post is an example of how using SAP Integration Suite as a true platform solution unlocks a whole host of advanced functionality.

Have any of you tried the JMS retry functionality? Can you think of any improvements to what I’ve shown here? I can think of a couple things I could improve but want to hear from you! What would you do to improve this channel start/stop concept?

Integration of SAP Digital Currency Hub into your S/4 payments infrastructure

2025-06-10T19:47:36.646000+02:00

Recently we had an opportunity to build a prototype for digital payments solution and successfully integrated Digital Currency Hub service platform. Here we would like to share some practical aspects ouf our work.

Configuration steps in the S/4 system

Our S/4 systems are designed to work with traditional currencies(fiat) in treasury and payment operations. To be able to operate with digital currencies via DCH, you will need a new payment method and new house bank account.

Define a new payment method in your country and company code
Use a custom payment medium format, where you’ll be able to call custom function modules. This is where you’ll integrate API-Calls offered by DCH to transfer payment instructions. Disable DME Mapping Engine in format settings
Define an internal bank master data record of type "payment system". Then use this record to set up a house bank account, account determination rules and GL account for payment clearing

Having completed this step, you should be able to use your new payment method while booking an invoice and assign it to business partners.

Configuration steps in the DCH payment platform

In general DCH is a cloud plattform and uses the Fiori Launchpad user interface design, that we know. It is easy to navigate and find an appropriate tile for a specific task

Define cryptocurrencies: We used stablecoins in our case. DCH offers an option to map traditional (fiat) currencies to cryptos. So using this setup we were able to initiate payments in fiat currencies in S/4 and transfer the funds in stablecoins. Another benefit of this aproach is no need to maintain a new crypto-currency and exchange rates in S/4.
There are also some related tasks to be done: networks, custodians etc.
Set up integration. Write down client ID and client secret somewhere safe, as you will need this data for authentification later
Finally set up your master data in DCH:
- Create a company as payment initiator as a conterpart for your company code
- Replicate business partners records, which you choose for test. Tipp: use business partner ID in S/4 as external ID in DCH. This will make your integration a lot more transparent

General overview

This is how it all fits together in our test environment.

Technical implementation

Certain configuration steps must be performed by your system engineers. Just like other solutions by SAP, S/4 Systems connect to DCH via cloud connector. Hence somebody needs to take care of cloud connector add-on installation, setting up a logon procedure and network security.

The API integration takes place via REST calls in ABAP. Use function modules of your custom payment medium format as wrappers. All necessary information such as business partner, amount, currency, will be delivered automatically by the interface of the function modules.

Now, lets face the most technical part of our prototype. ABAP Coding would generally consist of handling two tasks:

1) Authentication call and retrieving the access token

The purpose here is to retrieve the access token by an authification call using previuosly retrieved client ID and client secret. We used generic HTTP-Client Class for our purpose.

cl_http_client=>create_by_url(
   exporting
      url = auth_url,
      ssl_id = 'ANONYM'
   importing
      client = data(mo_token_client)
).
mo_token_client->request->set_method( 'POST' ).
mo_token_client->authenticate(
   exporting
      username = client_id,
      password = client_secret
).

Submit the call and check the http-code by mo_token_client->response->get_status( ) method. If “200” value is returned, read response object and retrieve access token from the JSON Body by mo_token_client->response->get_cdata( ) method.

2) API Call

Create another instance of http-client for api calls and set your access token as a header parameter:

cl_http_client=>create_by_url(
   exporting
      url = api_url,
      ssl_id = 'ANONYM'
   importing
      client = data(mo_http_client)
).
mo_rest_client->if_rest_client~set_request_header(
   iv_name = 'Authorization',
   iv_value = |Bearer { lv_access_token }|
).

Prepare payment payload from deep structure in ABAP to a JSON string by calling /ui2/cl_json=>serialize( ).

Finally submit your payments to payment platform

lo_request->set_content_type( iv_media_type = if_rest_media_type=>gc_appl_json ).
lo_request->set_string_data( io_payments ).
mo_rest_client->if_rest_resource~post( lo_request ).

Check the result of API call. This is indicated by the response object. If all went well, you should see a new transaction in DCH. Initially its status would be "In process" and then changed to "Completed".

Conclusion and outlook

This case covers a very basic scenario of payment processing with digital currencies. Its puspose is to trigger a fund transfer from one party to another and ensure correct booking in S/4 . At the end your booked invoice is automatically cleared by F110-payment run and payments are processed in usual manner.

More advanced options are upcoming, when the ongoing DCH-release with Multi Banking Connectivity becomes available.

But no matter, if you run your payments on larger scale using MBC or use simple integration as described here, adding the option of digital payments may turn out highly beneficial. Treasurers might be attracted by optimization af cross-border payments costs, processing speed and becoming independent from banking holidays and working hours

Automating Customer Communication and Data Delivery Using SAP Integration Suite

2025-06-10T20:03:27.325000+02:00

Part 1: Customer Notification iFlow

Below is a JSON payload received via HTTP, we have to extract customer details, calculate the total purchase amount, and send a personalized email using gcp and smtp to the customer.
This is the sample payload which is sent using postman. Postman will be the sender here for testing purposes.

1. HTTP Sender Adapter:

Here we are sending the payload using http sender adapter via postman.
Configuration:
- Method: We are using a POST method.
- Address: /CalculateTotalProductPrice02

2. Content Modifier

The HTTP adapter is connected to start message event which is in turn connected to content modifier which stores the incoming payload in the message body for further usage.

3. Parallel Multicast

After the processing of the message in the content modifier we send the payload to two different routes at the same time using a parallel multicast.
- Branch 1 is connected to Groovy Script which extracts the required data, and it is further connected to end event which is connected to receiver1 via Mail Adapter.
- Branch 2 is connected to end event which is connected to receiver2 via Process Direct which triggers a second iFlow.

4. Groovy Script

Using the groovy script we are parsing the JSON payload, calculating the total amount of all the products, and extracting the name and email of the customer from the payload for dynamic mail sending.

Copy the code below and paste in GroovyScript.

import com.sap.gateway.ip.core.customdev.util.Message;
import groovy.json.JsonSlurper;
Message processData(Message message) {
    def body = message.getBody(String);
    def json = new JsonSlurper().parseText(body);
    def firstName = json.customerFirstName;
    def customerEmail = json.customerEmail;
    def total = 0;
    json.purchases.each { purchase ->
        total += purchase.productPrice;
    }
    message.setProperty("customerEmail", customerEmail);
    message.setProperty("customerFirstName", firstName);
def response = "Hi ${firstName}. Your transaction of ${total} is successfully placed. Regards, My Website Sales Team ";
    message.setBody(response);
    return message;
}

5. Mail Adapter
- To: ${property.customerEmail} refer to Camel property of accessing properties.
- Subject: Order Confirmation for ${property.customerFirstName}
- Body: Uses the message body set by the Groovy script.
6. Process Direct Adapter:
The process direct adapter is used to forward the processed payload to the second iFlow for transformation and delivery.

Part 2: JSON to CSV Transformation and SFTP Delivery iFlow

Convert the JSON payload into CSV format and send it to an SFTP server. Since SAP Integration Suite doesn’t support direct JSON-to-CSV conversion, we use a multi-step approach.

Integration Flow Components

1. Process Direct Sender Adapter

We are using a process direct from the sender here to receive the processed payload from the first iFlow.
Configuration: <package_name> /<iFlow_name>

2. JSON to XML Converter

We are using a JSON to XML converter that converts the JSON payload into XML format.

3. Parallel Multicast

We are again making use of parallel multicast to split the XML into two branches:
- Branch 1 named products extract's and converts product data.
- Branch 2 named customer extract's and converts customer data.

4. XML to CSV Converters

Here we are using two XML to CSV Converters.
Converter 1 (Products) is used to convert product XML to CSV and Converter 2 (Customers) is used to convert customer XML to CSV.

5. Join Component

The join component is used to join the two parallel branches after conversion.

6. Gather Component

The gather component is used to aggregate the joined data into a single message.

7. SFTP Receiver Adapter

The end message event is connected to receiver via SFTP adapter that sends the final CSV file to an SFTP server.
Configuration: Includes server address, port, authentication, and target directory.

Key Takeaways

Content Modifier is essential for storing and forwarding payloads.
Parallel Multicast enables concurrent processing paths.
Groovy Script provides flexibility for custom logic.
Mail Adapter supports dynamic personalization.
Process Direct promotes modular iFlow design.
JSON to XML → XML to CSV is a practical workaround for JSON-to-CSV transformation.
SFTP Adapter enables secure file delivery to external systems.

Set up the SAP Cloud Connector: Integrating On‑Premise Systems with Cloud Services

2025-06-12T08:24:48.267000+02:00

Set up the SAP Cloud Connector: Integrating On‑Premise SAP Systems with Cloud Services Using the Cloud Connector

In today’s hybrid IT landscape, connecting on‑premise SAP systems with cloud services is a strategic necessity and a best practice ecomended by SAP. This blog explains how to establish secure connections between your internal SAP environment and cloud platform, such as the Business Technology Platform, Integration Suite, or SAP Build Apps, using the Cloud Connector. We cover the key connection protocols, compare three OData service deployment strategies, and outline the service creation process with relevant SAP transaction codes. Finally, we detail the steps to set up the Cloud Connector with proper certificate management and configuration paths, ensuring a secure and efficient integration.

Connection Protocols and Their Roles

Before configuring your integration, it is essential to understand the protocols that underpin communication between systems:

HTTP/HTTPS:
These protocols form the basis for web-based communication. HTTPS, in particular, ensures that data transferred between cloud services and on‑premise systems is encrypted and secure—critical for protecting sensitive business information.
RFC (Remote Function Call):
RFC enables communication between different SAP components. When integrated with the Cloud Connector, RFC calls are securely transmitted from cloud applications to your on‑premise SAP system, ensuring consistency and reliability in data and process exchanges.
OData (Open Data Protocol):
OData is the standard protocol for exposing SAP Business Suite data as RESTful services. It supports CRUD operations (Create, Read, Update, Delete), making it ideal for modern applications that require flexible and real‑time data interaction across multiple devices.

Interface Connections and Deployment Strategies

Interface connections are the channels through which data flows between your on‑premise SAP systems and cloud platforms. When exposing SAP Business Suite data via OData services, you can choose among three primary deployment strategies:

Embedded Deployment:
With Embedded Deployment, available from SAP NetWeaver 7.4 onward, the SAP Gateway Foundation is integrated within each SAP Business Suite system. Each system runs its own SAP Gateway instance, meaning that you must configure the gateway individually for each backend system. This approach is ideal when data needs to be exposed independently for each system, although it does require managing multiple configurations.
Central HUB Deployment:
In this model, the SAP Gateway is installed on a dedicated front‑end server (the hub system) rather than being embedded in every backend system. A single SAP Gateway instance serves all SAP Business Suite systems, centralizing connectivity and enhancing security.
OData Provisioning via Cloud-Based Deployment:
This strategy moves the SAP Gateway frontend to the cloud. Here, the SAP Cloud Platform manages the gateway while OData services connect to on‑premise systems (typically SAP HANA) via the Cloud Connector. The Cloud Connector, acting as an on‑premise agent, initiates outbound connections, thereby eliminating the need to open inbound firewall ports. This not only enhances security but also leverages modern, centrally managed, browser-based development environments like the cloud version of SAP Web IDE.

Why Use the SAP Cloud Connector?

Even if your OData services appear to be accessible directly, employing the SAP Cloud Connector provides substantial benefits beyond basic connectivity:

Enhanced Security via Reverse Invoke
SAP Cloud Connector uses a secure, outbound "reverse invoke" approach. Instead of opening risky inbound firewall ports that could expose your internal network to threats, the connector initiates secure connections outward from your protected on-premise environment to the SAP Cloud. This significantly reduces vulnerabilities by preventing unauthorized external access.

Centralized Connection Management
By providing a centralized point of control, SAP Cloud Connector simplifies managing your cloud-to-on-premise connections. It allows administrators to handle access controls, authentication, and certificate management in one place. Consequently, you ensure that only authorized SAP cloud services can connect to your internal systems, maintaining consistency and simplifying governance.

Granular and Precise Access Control
Even if OData links seem publicly reachable, the Cloud Connector gives you detailed control over exactly which services, APIs, or datasets external applications can access. This granular management greatly reduces the risk of unauthorized data exposure, ensuring compliance and protecting sensitive information. Facilitating SAP BTP Services (SAP Build Apps, Integration Suite, and More)

Beyond security, the Cloud Connector is vital for enabling seamless and effective integration of SAP Business Technology Platform (BTP) services, such as SAP Build Apps, SAP Integration Suite, and SAP Analytics Cloud. It ensures these cloud-based applications can reliably and securely interact with your on-premise SAP backend systems, enhancing their functionality and simplifying integration tasks.

In summary, SAP Cloud Connector doesn't just enhance security—it simplifies integration, provides centralized control, and significantly enhances the effectiveness and security of your SAP cloud integrations

Service Creation and Interface Configuration

This blog primarily covers setting up the Cloud Connector. If you're new to SAP, additional background information about available data and deployment strategies is available.

SAP recommends using predefined CDS views to securely expose data via OData services. CDS views offer control over selecting relevant fields, enable data transformations, and help enforce security and business rules through built-in annotations and validations.

You can create OData services rapidly through automatic service generation or develop more complex services manually using the SAP Gateway Service Builder (SEGW). Once created, services must be activated using transaction /IWFND/MAINT_SERVICE and can be tested with /IWFND/GW_CLIENT. This link provides more information: https://community.sap.com/t5/application-development-and-automation-blog-posts/a-step-by-step-proces...

Setting Up the Cloud Connector

Establishing a secure interface using the Cloud Connector involves several key steps:

1. Installation:

Download: Begin by downloading the latest version of the Cloud Connector: https://tools.hana.ondemand.com/#cloud
Install: Before you install the Cloud Connector make sure that the newest Java 8 version is installed: https://www.oracle.com/nl/java/technologies/javase/javase8-archive-downloads.html.To install the cloud connector it is possible to click true all the steps in the setup
Open: To open the Cloud Connector run the program “Start Cloud Connector” as administrator and enter this link in your web browser: https://localhost:8443 and click on proceed to local host.

To login use the Username: Administrator and the Password: manage. In the next page you can set your new password and proceed with the initial setup. for the Initial setup choose Master (primary installation) and press save.

2. Configuring Subaccount:

To connect to the SAP Subaccount, press the button + Add Sub Account. The following pop up will be displayed:

Connecting to the internet through an HTTPS proxy, as prompted here in SAP Cloud Connector Administration, may be necessary in the following scenarios:

When to Use an HTTPS Proxy

Cloud Integration Needs: If your SAP environment connects to external cloud services like SAP BTP Integration Suite, an HTTPS proxy ensures secure, reliable data tunnels between on-premises systems and the cloud. Even if the Cloud Connector is hosted locally, connecting to SAP BTP (a cloud service) typically requires a proxy unless your network allows direct, secure internet access.
Enhanced Security & Compliance: Proxies add a layer of protection by monitoring traffic, helping meet regulatory standards and internal security policies.
Restricted Corporate Networks: If your network blocks direct internet access, a proxy is mandatory to enable external communication while adhering to company policies.
Simplified Maintenance: Proxies streamline software updates and patches, keeping your Cloud Connector secure and up-to-date.

When to Skip the Proxy

Secure Direct Internet Access: If your network already allows secure direct connections to SAP BTP endpoints (e.g., *.hana.ondemand.com), a proxy may add unnecessary complexity.
Internal Use Only: If the Cloud Connector doesn’t interact with external services, a proxy offers no benefit and can be omitted.
Prioritizing Simplicity: Proxies introduce configuration overhead. If your setup values minimalism, bypassing the proxy reduces management effort.

If you need to configure an HTTPS proxy for SAP Cloud Connector, here's what you typically fill in: But for this example we leave the proxy empty.

Host: Enter the proxy server’s hostname or IP address provided by your organization's network team (Example: proxy.mycompany.com or 192.168.1.1)

Port: The proxy server's port number, often 8080, 443, or another port specified by your IT department.

User: Proxy username, if authentication is required.

(Leave empty if no authentication is necessary.)

Password: Corresponding password for the proxy user.

(Leave empty if no authentication is necessary.)

After this step, open your BTP environment, here you can find the relevant data you need to connect SAP BTW with your cloud connector. You can choose to add all the data manually, or go to Cloud Connectors and download Authentication data.

After downloading this data go back to your cloud connector and select configure using authentication data and choose, add sub account authentication data from file and select the file that you just downloaded.

You can now Check if there is a secure connection in the BTP platform and in your cloud connector. This should look somewhat like this:

!If the Cloud Connector cannot establish a connection to your BTP account, first verify that your Windows network profile is set to “Private.” At home the Connector often works on “Public” because your router allows port 8443 and outbound HTTPS by default, but in a corporate setting a firewall or proxy will block these connections. Switching to “Private,” configuring the Connector with your company’s proxy, or asking IT to open ports 8443 and 443 to *.hana.ondemand.com will restore connectivity.

3. Configuring Certifications:

When setting up HTTPS communication between the SAP Cloud Connector and your SAP backend system, properly managing certificates in the SAP Trust Manager (transaction STRUST) is essential. Certificates act like digital passports—they verify identities, establish trust between systems, and ensure that data is encrypted during transmission. But how does this actually work in SAP? And where exactly do these certificates go? Let’s break it down.

Identity Certificates vs. Trust Anchors in STRUST

In each Personal Security Environment in STRUST, there are two types of certificates to be aware of:

1. Identity Certificate ("Own Certificate")

This is your SAP system’s own server certificate—it contains a private key and is used when SAP needs to prove its identity (e.g., during TLS handshakes). Only one identity certificate can be active per PSE at any given time.

!If you replace this certificate, you must update all other devices to trust the new one; otherwise, connections may fail!

2. Trusted Certificates ("Certificate List")

These are public certificates your SAP system uses to trust other systems—such as the Cloud Connector or its CA. These are also called trust anchors. You can store multiple trusted certificates here without issue.

Regularly reviewing this list helps avoid trust errors or certificate expiration surprises.

Where to Place Certificates in STRUST

When your SAP backend receives inbound HTTPS connections (such as requests from the SAP Cloud Connector), it uses a specific trust store in STRUST called the SSL System-wide Standard PSE.

To establish trust, you typically need to upload the Cloud Connector’s certificate or the CA certificate that signed it into this PSE. This tells your SAP system: “This incoming connection is safe and trusted.”

Important: You do not need to upload this certificate if it's already signed by a widely trusted root CA that your SAP system recognizes by default. In many cases, SAP already includes a list of common root CAs—so the Cloud Connector will be trusted automatically.

Configuring Certificates

When setting up HTTPS communication between the SAP Cloud Connector and your SAP backend system, properly managing certificates in the SAP Trust Manager (transaction STRUST) is essential. The goal is to ensure that your SAP system both presents a valid identity certificate when required and trusts the relevant external certificates to establish a secure SSL/TLS handshake.

Identity Certificates vs. Trust Anchors in STRUST

In each Personal Security Environment (PSE) in STRUST, there are two types of certificates to be aware of:

When dealing with certificates in STRUST, it’s important to understand the distinction between identity certificates (also called “Own Certificates”) and trust anchors (trusted certificates in the Certificate List). These serve different purposes:

An identity certificate is the certificate that identifies your SAP system. It usually includes a private key and is used by SAP when acting as a server or client to present its identity to others. For example, if your SAP system is serving HTTPS requests, it will present its identity certificate to the client (browser or Cloud Connector) during the SSL handshake. In STRUST, the identity certificate is shown in the “Own Certificate” section of a PSE.
Trust anchors are the certificates of external authorities or systems that your SAP system trusts. In other words, these are usually root CA certificates or intermediate certificates that form the chain of trust for the certificates presented by others. They do not contain a private key in your system; they are public certificates that you add to SAP so that it recognizes and trusts the identities of external parties. In STRUST, trusted certificates are listed in the “Certificate List” section of a PSE (the lower pane). For example, if you need to call an external web service over HTTPS, you must import the web service’s root CA certificate as a trust anchor. This way, when SAP (as a client) connects, it can verify the server’s certificate against these trusted CAs.

Understanding the Difference Between PSE Types

Finally, it’s important to clearly understand the two primary Personal Security Environment Types we’ve discussed and when each is used:

SSL System-wide Standard PSE (SSL Server PSE): This PSE is used when the SAP system acts as a server in an SSL/TLS communication. In other words, for inbound connections to SAP. The System-wide SSL Server PSE provides the server’s identity certificate and uses its trust list to verify clients if needed. “System-wide” means one certificate can be used across all application servers in the system (as opposed to having a separate certificate per instance).
SSL Client (Standard) PSE: This PSE is used when the SAP system acts as a client making outbound HTTPS requests. For any outbound connection that SAP initiates (calling a REST API, connecting to an external cloud service, etc.), the SSL Client (Standard) PSE is consulted. It contains the list of trusted CA certificates that SAP will accept for server certificates on the other side.
Be careful where you import certificates: Always choose the correct PSE based on the direction of the connection. Importing a certificate into the wrong PSE, like putting a client certificate into the system-wide PSE, can disrupt communication with other systems and cause unexpected connection failures.

Creating Certificates:

If your SAP system doesn’t already have a background trust certificate (X.509), you can generate one using one of the methods outlined below. However, it's rare for this certificate to be missing, so if you're unsure, it's best to consult your network specialist.

Using XCA (recommended due to its user-friendly GUI): https://community.sap.com/t5/technology-blogs-by-sap/how-to-guide-xca-quick-start-guide/ba-p/133254...
Using OpenSSL: https://www.youtube.com/watch?v=Z2l-5utm3WY

Exporting Existing Certificates:

To export an existing certificate from SAP, go to transaction STRUST in the PSE SSL Server Standard system wide and double click on one of the issuer certificates:

Now the certificate is opened on the bottom of the page. Press the button export certificate.

A new tab is opened where you can select the location, name of the certificate and the file format. After downloading your certificate go to the cloud connector site and select configuration. On the configuration screen select on premise.

Go to the tab Backend Trust Store allowlist and press the button add x509 certificate.

Upload your certificate here. It is not necessary to upload a CA Certificate because the system already trusts publicly signed certificates from standard Certificate Authorities (CAs).

4. Configuring Connection Paths:

After making sure the right certificates are in place we can continue with connecting the system. Open the sap cloud connector site and select Cloud to On premise in the left menu. and press the button “add system mapping”. For the back end type are several options available. For this case we choose SAP HANA, but it is also possible to select other back end systems.

Field	Entry
Back-end Type	SAP HANA: Select this option to specify that the backend system is an SAP HANA database.
Protocol	HTTPS: Choose HTTPS to ensure that communication with the backend system is encrypted and secure.
Internal Host	Enter the Fully Qualified Domain Name (FQDN) or hostname of the machine where the Production Connector is installed. A mismatch between the entered hostname and the certificate will result in SSL errors and block the connection. I used the command /IWFND/GW_CLIENT or /IWFND/MAINT_SERVICE to inspect the request url. For example https://prod-connector.company.com:44321/sap/opu/odata/sap/ZC_142JJ_MATERIALSPERUSER_CDS/?$format=xm.... Use the red text as the internal host.
Internal Port	Enter the port number used by the Production Connector for cloud communication (e.g., 443 or a custom HTTPS port). For example https://prod-connector.company.com:44321/sap/opu/odata/sap/ZC_142JJ_MATERIALSPERUSER_CDS/?$format=xm.... Use the red text as the internal host.
Virtual Host	Enter a unique virtual host name, such as prodconccms, to identify this Production Connector instance. Only use letters (A–Z, a–z), numbers (0–9), and periods (.). Special characters are not allowed.
Virtual Port	Enter a virtual port number, for example: 50066.This will be used together with the virtual host to form the URL, e.g., https://prodconccms:50066. The virtual port can be the same as the internal port if desired.
Principal Propagation	Deselect this option.Certificate-based OAuth is now used for authentication instead of principal propagation.
System Certificate for Logon	Select this checkbox to enable certificate-based authentication for logging into the system.
Host In Request Header	Use the default setting: Use Virtual HostThis ensures the virtual host name is sent in the request headers.
Description	No input required.This field can be left empty unless a description is specifically needed.
Check Internal Host	Select this checkbox to verify that the internal host name is reachable and correctly configured.

The result should look like this and the status should be reachable:

Define “Cloud to On‑Premise” Paths: Configuring resource path mappings is what actually grants your cloud applications access to specific services in your internal network. Without this step, even though the Cloud Connector is installed and connected to your subaccount, no data can flow. These mappings define exactly which internal systems and paths the Cloud Connector is allowed to expose to the cloud, acting as a secure filter to prevent unauthorized access.

When a request comes from SAP BTP, such as a call to an OData service, it passes through the Cloud Connector. Here’s where resource path mappings come in: they translate the virtual host and path requested by the cloud app into the actual internal system address and path, ensuring that the request reaches the right backend component (e.g., SAP Gateway, ABAP system, or ERP backend).

I used the command /IWFND/GW_CLIENT or/IWFND/MAINT_SERVICE to inspect the request url. For example https://prod-connector.company.com:44321/sap/opu/odata/sap/ZC_142JJ_MATERIALSPERUSER_CDS/?$format=xm.... Use the red text as the path. Additionally, set the Access Policy to “Path and all Sub-Paths” to ensure the system allows access to the specified path as well as any nested resources and query options beneath it.

5. Create Destination:

Go to the connectivity tab in SAP BTP and check if your cloud connector has an exposed back end system. And that the resources are available.

The next step is to create a new Destination. For this go to SAP BTP Connectivity and then Destinations. And then press the button to create a new Destination. Use your virtual host as url like this example below. Set proxy type to OnPremise and use basic authentication and use your own SAP username and password. Also don't forget to use the Additional Properties mentioned in the example below and set your SAP-Client to your own client.

6. Test your Connection

When you go to the SAP application studio select the Data source Connect to a System. You can select your own system (Destination that we just created). Here are all services that are opened with the URL resource path in the SAP CLOUD connector.

Final Thoughts

Installing the Cloud Connector is a straightforward process, but the many available options can make it challenging for beginners to set up a connection. I wrote this blog during my SAP traineeship, so I'm not an expert in certificates or network configurations. If you spot any mistakes or have suggestions for improvement, I'd really appreciate your feedback!

Employee Central: Reporting of Pending workflow data

2025-06-13T10:26:42.662000+02:00

Introduction:

Few of our customers have a requirement to report on Employee Central - pending workflow data. That is, the workflow is in pending approval status and report needs to generate data changes (current and previous values) which are in the workflow. This information is crucial for decision makers like Managers, HR business partners and Compliance teams. The users need to know the information in the pending workflows to make better business decisions.

The HR department and compliance teams have several use-cases for pending data. Few examples are:

Use-Case 1: The HR compliance teams require a report on all pending location change requests (Current location and new location)

Use-Case 2: The HR mobility teams require a report on list of all Global Assignment transfers pending approval (short-term assignment and long-term)

Use-Case 3: The HR compensation teams require a report to track all employees changing their payment cycle (hourly and monthly)

When high volume of workflow changes are pending in the system for approval, a report would be easier to read than opening each workflow request in the UI and viewing the data changes. A report would also help workflow approvers to make better decisions on the pending workflow itself, either to edit the workflow with or without route change, Approve or Decline or initiate follow on processes in the 3rd party system.

Challenge:

The KBA 2274688 lists all the currently available standard reports for workflow. However, reporting on pending workflow data of HRIS Entities (like Job Info, Comp info. etc...) is still a limitation (KBA 2682975)

Solution Approach:

The solution is to use API getWorkflowPendingData. This API can be used to query the changed data in a workflow that is not yet approved or rejected, as well as fully completed. This API supports entities that are in the label: value pair format (oldValue vs newValue). The following list of entities are supported:

EmpCompensation
EmpEmployment
EmpGlobalAssignment
EmpJob
EmpPensionPayout
FOPayComponentGroup
PerAddress
PerGlobalInfo
PerPerson
PerPersonal
PerPersonRelationship

The getWorkflowPendingData can be used in combination with other workflow related API's/function imports to extract all the required data and build a custom solution. For more detailed information on all the available workflow API's, kindly refer to Successfactors API help documentation.

Using workflow API's customers can build innovative solutions to meet their business needs.

Example: Managers raise location change requests in Successfactors which are getting routed to the compliance team for action. The team reviews these requests and takes the necessary actions as per the regulatory guidelines/company policies. Based on the report, the approver will either approve/decline the workflow, forward the workflow to onboarding partner in the new location or initiate follow-on processes in the 3rd party system. Let's say there are 300 location change requests pending for approval. In the absence of a report, all the compliance team members have to open individual works and gather the data. This will slow down the process and impact employee experience.

Step 1. Get all Pending workflow request ID's(wfRequestId) of users on jobinfo. Use ToDo api to query all the pending workflows. Also, use WfRequest API, EmpWfRequest navigation properties to get all the relevant records. You can limit the selection by identifying specific event reasons and field changes that contribute to a location change. Sample query:

https://<api-server>/odata/v2/TodoEntryV2?$format=json&$filter=categoryIdeq'14'&statuseq'2'

https://<api-server>/odata/v2/WfRequest?$format=JSON&$filter=statuseq'PENDING'

Step 2: For each wfRequestId, call the getWorkflowPendingData API and it will capture both oldValue (current) and newValue (proposed).
https://<api-server>/odata/v2/getWorkflowPendingData?wfRequestId=1115152L

Step 3: Retrieve all the records and deliver the output to a SFTP folder or SAP Datasphere to enable creation of reports.

I hope you will find this blog useful. In case of feedback or question, please feel free to use comment section.

Special character in XML processed by CPI

2025-06-13T16:08:38.734000+02:00

In most of the CPI steps, it will convert escaped form into original form automatically. Let's analyse them one by one.

This is the source message used. There is an escaped & in the xml making it a valid xml to be processed.

<Message>
    <content>Test special character: &amp;</content>
</Message>

These below methods will be used to check how the escaped character will be processed by them.

1. Xpath in Content Modifier

This is the value of the property after the step.

conclusion: value has been changed.

2. setProperty in Graphic Mapping

This is the UDF

import com.sap.it.api.mapping.*;
def String customFunc1(String P1,MappingContext context) {
         String value1 = context.setHeader("Myheader",P1);
         return P1;
}

This is the value of head after process

conclusion: value has been changed.

3. setProperty in XSLT Mapping

This is the xsl used for test

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="3.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                              xmlns:cpi="http://sap.com/it/">
    <xsl:output method="xml" omit-xml-declaration="yes" />
    <xsl:param name="exchange"/>
	<xsl:template match="/">
		<xsl:apply-templates select='Message'/>
	</xsl:template>
	
	<xsl:template match="Message">
	   <xsl:value-of select="./text()"/>
	   <xsl:value-of select="cpi:setProperty($exchange, 'context', content/text())"/>
	</xsl:template>
</xsl:stylesheet>

This is the result after the step

the value has been changed.

4. setProperty in Groovy Script

This is the groovy script used.

import com.sap.gateway.ip.core.customdev.util.Message;
import groovy.xml.MarkupBuilder
def Message processData(Message message) {
    //Body
    def input = message.getBody(Reader).getText();
    def source = new XmlSlurper(false,false).parseText(input);
    message.setProperty("TestProperty", source.content.text());

    //def target = Mapping(source);
    //message.setBody(target);
    return message;
}

This is the result

The value has been changed.

Unchanged Situation

The only way i found that doesn't not change the escape value back to its orginal form is message body level mapping into another XML.

Since the only outcome of graphic mapping is XML, the graphic mapping can always keep the escaped value without being changed back.

For XSLT mapping, if the outcome is not XML, say text, the escaped value shall be changed back to its original form automatically. However the only way to retrieve the escaped value from an element and set it as a message body without any tags is via XSLT mapping. here is an example code:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="3.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                              xmlns:cpi="http://sap.com/it/">
    <xsl:output method="xml" omit-xml-declaration="yes" />
    <xsl:param name="exchange"/>
	<xsl:template match="/">
		<xsl:apply-templates select='Message'/>
	</xsl:template>
	
	<xsl:template match="Message">
	   <xsl:value-of select="content/text()"/>
	</xsl:template>
</xsl:stylesheet>

This is the value in the message body:

For groovy script, if the message bod is a xml, the escaped character will be remained. if it is a text , json or some format else, the escaped character will be changed into it original format.

conclusion

Most of value retrieving methods in CPI changes the escaped characters from xml automatically. This mechanism should be awared by the developer. Otherwise, if the value has been populated back to form a new XML, you might generate an invalid XML message to the target system. two cents.

Transforming XML in SAP CPI Using Groovy: A Real-World Example

2025-06-13T16:09:13.106000+02:00

The Scenario

The input XML was structured like this:

<Demo>
  <columns>
    <string>idOnController</string>
    <string>name</string>
    <string>id</string>
    <string>MacAddress</string>
    <string>lat</string>
    <string>lng</string>
    <string>address</string>
    <string>location.streetdescription</string>
    <string>location.city</string>
    <string>location.zipcode</string>
    <string>GroupName</string>
  </columns>
  <values>
    <object-array>
      <string>178531359</string>
      <string>178531359</string>
      <int>25342</int>
      <string>43434343432ff</string>
      <double>35.431632</double>
      <double>-97.494129</double>
      <string>TEST Line 21</string>
      <string>OKLAHOMA CITY</string>
      <string>OKLAHOMA CITY</string>
      <string>73129-5130</string>
      <string>Sunrise</string>
    </object-array>
  </values>
</Demo>

The Goal

Transform this into a simplified XML structure like:

<Attributes>
  <componentId>178531359</componentId>
  <deviceName>178531359</deviceName>
  <SerialNumber>25342</SerialNumber>
  <macAddress>345435435435ff</macAddress>
  <latitude>35.431632</latitude>
  <longitude>-97.494129</longitude>
  <address1>Test Line 21</address1>
  <address2>OKLAHOMA CITY</address2>
  <city>OKLAHOMA CITY</city>
  <zipcode>73129-5130</zipcode>
  <GroupName>Sunrise</GroupName>
</Attributes>

The Groovy Script

Here’s the Groovy script that made it happen in CPI:

import com.sap.gateway.ip.core.customdev.util.Message
import groovy.util.XmlSlurper
import groovy.xml.MarkupBuilder

def Message processData(Message message) {
    def body = message.getBody(String) as String
    def inputXml = new XmlSlurper().parseText(body)

    def values = inputXml.values.'object-array'.children().collect { it.text() }

    def writer = new StringWriter()
    def xml = new MarkupBuilder(writer)

    xml.Attributes {
        componentId(values[0])
        deviceName(values[1])
        SerialNumber(values[2])
        macAddress(values[3])
        latitude(values[4])
        longitude(values[5])
        address1(values[6])
        address2(values[7])
        city(values[8])
        zipcode(values[9])
        GroupName(values[10])
    }

    message.setBody(writer.toString())
    return message
}

Lessons Learned

Indexing matters: Initially, I mistakenly passed the entire list to each tag, resulting in repeated values. Correcting the index for each field fixed the issue.
Use groovy.util.XmlSlurper in CPI: Unlike standard Groovy environments, CPI requires groovy.util.XmlSlurper instead of groovy.xml.XmlSlurper.
Test incrementally: Always test your script with sample payloads in the CPI runtime to catch formatting or parsing issues early.

If you're working with XML transformations in CPI and need to extract structured data from nested arrays, this approach might save you hours of debugging.

Have you faced similar challenges in CPI? Share your tips or questions in the comments!

Would you like me to format this into a downloadable .md or .txt file for easy posting?

"PD Where Used" Button – A Chrome Extension for SAP Integration Suite

2025-06-13T16:15:45.230000+02:00

For consultants managing integrations on SAP Integration Suite, small yet effective tools can greatly simplify daily tasks. Based on this need, I developed a Chrome extension called: "PD Where Used" Button.

What does "PD Where Used" button do?

While working on a complex iFlow that contained many ProcessDirect calls, I found myself constantly switching tabs, manually searching for where each target address was used. The lack of a quick overview made this process annoying and time-consuming, especially in projects with dozens (or hundreds) of iFlows.

The "PD Where Used" button analyzes all ProcessDirect addresses used in the currently open iFlow and lists which other iFlows are referencing them. The results are displayed in a new popup window.

This extension has been developed and tested on the SAP Integration Suite running in a Cloud Foundry environment.

Installation

Install directly from Chrome Web Store. After installation, button must appear in your flows.

Acknowledgement

I want to sincerely thank Dominic Beckbauer, the creator of the CPI Helper extension, for his support and guidance throughout the development of this tool. His feedback was incredibly valuable.

Emre Anil Kucuk

SAP BTP API Proxy to Work with Basic Authentication or OAuth 2.0

2025-06-13T16:16:55.746000+02:00

Introduction

In modern SAP integration landscapes, organizations often face diverse authentication requirements. Some external consumers may depend on Basic Authentication due to legacy system constraints or simplicity, while others are required to use OAuth 2.0 to comply with enterprise security policies.
In this blog post, we’ll explore how to configure a single SAP BTP API Management proxy that supports both Basic Authentication and OAuth 2.0, ensuring flexibility for a range of API consumers without compromising on security standards

Business Scenario

In complex enterprise environments, particularly federated organizations:

Legacy systems or subsidiaries may still utilize Basic Authentication.
Corporate IT may mandate OAuth 2.0 for cloud and mobile integrations.
Maintaining separate API proxies for each authentication method is undesirable due to increased complexity and maintenance.

Objective: Implement a unified API proxy in SAP BTP that dynamically supports both authentication methods based on the incoming request.

Solution Architecture

Here's how the solution works:

API Consumer --> SAP BTP API Proxy (auth policy check) --> SAP Backend (e.g., S/4HANA)

Various consumers, such as Legacy, Cloud, or Mobile applications, may utilize the same proxy endpoint with either Basic or OAuth2.0 authentication. The proxy inspects the request for:

Authorization: If "Basic", it validates via Basic Authentication.
Authorization: If "Bearer", it validates via the OAuth 2.0 token.
Upon successful authentication, the request is routed to the backend.
If authentication fails, a response is sent back.

Implementation Steps

Develop an API Proxy in SAP BTP API Management, ensuring to establish the backend SAP connection for oData services.

Required Parameters will be entered.

API Basepath:
Target Endpoint:
- API Provider: SAP (or any provider)
- URL: Odata path (or any URL)

Add Pre-Flow Policies with condition routing.

Please refer to the following for more detailed information on each step.

RaiseFault: This step checks if authentication is used and raises a fault if neither Basic nor OAuth is applied.
- Condtion String request.header.authorization = null
- Policy String:

oAuthVerify: This function verifies oAuth credentials when a bearer token is provided.
- Condition String request.header.Authorization ~ "Bearer*"
- Policy String:

decodebasicAuth: Decodes Basic Authentication.
- Condition String : request.header.Authorization ~ "Basic*".
- Policy String :

verifyKey: This will check if the key is associated with this API Product APP key.
- Consdition String : request.header.Authorization !~ "Bearer*"
- Policy String :

invalidCredentials: This fault exception occurs when credential validation fails.
- Condition String : (verifyapikey.Verify-API-Key.failed = true) or (varanganti.clientSecret != verifyapikey.verifyKey.client_secret)
- Policy String:

RemoveHeader (Optional): This function removes the API headers post-authorization, as they are no longer necessary for targeting the application once authorization is successful. The necessity of this step depends on subsequent procedures.
Readkey (Optional): Since I am accessing an OData service on the backend, credentials for Key Vault Manager (KVM) are being read.
Basic (Optional): Include a Basic Header for the target application if necessary. This depends on how the target key is being accepted.
scCSRF (Optional): This parameter is used to set the CSRF token, as is required by my target application.
setSCParsms (Optional) : Follow-up step for SCRF to call backend application.

Configure Credential Aliases

In the API Developer Hub, create an application to obtain credentials. These will be utilized for basic authentication or OAuth Authentication.

Testing the Proxy
- Cas1: No Authentication
  - Do Not pass any credentials

Cas2: Basic Authentication
- The call will succeed and receive a response.

Case 3: Utilizing OAuth Authentication
- Pre-Requisite: Set up a proxy with a placeholder target for obtaining the OAuth authentication token.
- Select OAuth2.0 as the authentication method and execute accordingly.

Conclusion

Configuring a single SAP BTP API proxy to support both Basic Authentication and OAuth 2.0 provides a scalable and secure solution for diverse integration requirements. This approach minimizes redundancy, simplifies management, and supports both modern and legacy applications accessing the same backend services.

By leveraging policy-based routing and dynamic authentication handling, enterprises can ensure compliance, enhance flexibility, and optimize their API architecture.

Blog series on my CPI + Camel learning journey - Interlude2 APIM debugging

2025-06-15T22:59:37.197000+02:00

Motivation

Well, as with MPL you have to start doing some real life debugging to figure out the tools you are provided with "have some space for improvement", to put it mildly.

And this is what happened to me when I had a weird case for one of my api proxies.

A little bit about Apigee and debug session structure

Not a secret that under the hood APIM has apigee platform (that google bought)

So, it turns out it was not SAP to blame for this "debug session" logic, but still the app they made is something special I have to say..

What bothers us is this stuff https://cloud.google.com/apigee/docs/api-platform/debug/trace

And particularly the structure of session/transactions https://cloud.google.com/apigee/docs/api-platform/debug/trace#download-structure

Without going into details (after all this blog does not aim to provide the full schema details) let's see what could be of our most interest here.

First, the whole session is an array of entries (we will call it transactions which are api calls)

Below we would see "point" array - kinda Steps of flow execution each having an array of "results" in turn.

[
    {
        "completed": true,
        "point": [
            {
                "id": "Paused|Resumed|StateChange|FlowInfo|Condition|Execution|Error",
                "results": [
                    {
                        "ActionResult": "DebugInfo|RequestMessage|ResponseMessage|ErrorMessage|VariableAccess"
                    }
                ]
            }
        ]
    }
]

These results contain some more details (which we see in the standard app as lists/forms) of key-value pairs

What is different is just name of "aggregation" - path in json to those arrays (eg "properties/property" or "headers" or "accessList")

{
    "ActionResult": "DebugInfo",
    "properties": {
        "property": [ { "name": "<PROP_NAME>", "value": "<PROP_VALUE>" } ]
    },
    "timestamp": "04-06-25 13:28:52:904" // yes, not a proper iso8601 timestamp ;(
}

{
    "ActionResult": "RequestMessage",
    "content": "<REQUEST_BODY_IF_PRESENT>",
    "headers": [ { "name": "<HEADER_NAME>", "value": "<HEADER_VALUE>" } ],
    "uRI": "<URI>",
    "verb": "<VERB>"
}

{
    "ActionResult": "ResponseMessage",
    "content": "<RESPONSE_BODY_TRIMMED>.....",
    "headers": [ { "name": "<HEADER_NAME>", "value": "<HEADER_VALUE>" } ],
    "reasonPhrase": "<STATUS_PHRASE>",
    "statusCode": "<STATUS_CODE>"
}

{
    "ActionResult": "ErrorMessage",
    "content": "<APIM_ERR_BODY>",
    "headers": [ { "name": "<HEADER_NAME>", "value": "<HEADER_VALUE>" } ],
    "reasonPhrase": "<STATUS_PHRASE>",
    "statusCode": "<STATUS_CODE>"
}

{
    "ActionResult": "VariableAccess",
    "accessList": [
        {
            "Get": { "name": "<VAR>", "value": "<VALUE_IF_GOT>" }
        },
        {
            "Set": { "name": "<VAR>", "success": true, "value": "<VALUE>" }
        }
    ]
}

Api Proxy debug viewer app

But most important thing is that we DO HAVE Request and Response (and Error) Method, Url, Content and Status!!

And so I decided to make a really simple frontend-only ui5 app based on Flexible Column Layout (which is hidden behind the intent #apim-dbg in capic launchpad)

For this I just had to figure out the structure of the session and then apply some transformations to display it nicely.

And while the original app tries to follow "visual approach" apigee had in their app (you could see it following the link above) - using lots of pictograms/icons while doing its best to hide essential information from us like target endpoint http code/status or request/response body - I decided to display our stuff via lists and forms, cuz as a developer I LOVE TEXT (which can even be searchable).

This image from apigee documentation illustrates it well https://docs.apigee.com/api-platform/fundamentals/what-are-flows (not 100% percent sure I am right regarding mapping of stages, but it somewhat makes sense to me)

Basically, the app displays our debugging session in the following way (kinda 5 levels):

Master - 1 Transactions (api calls) as Items // with objectstatus stuff
Detail - 2 Stages (list grouping) + 3 points (steps) as Items // also with some color coding
Detail-Detail - 4 ActionResults (form container) + 5 results params as form elements

Some other things to point out here (at Detail screen):

StateChange typically has RequestMessage|ResponseMessage|ErrorMessage ActionResult object appearing

It comes first in group and it is marked with blue highlight (also from this guy I calculated groups for detail list)

Error has some error information that doesn't help much but is a place in flow where error occured - marked red
Execution - is an interesting step, basically, this is where our policies run - it is marked amber

Properties of DebugInfo action here contain "type" or "stepDefinition-type" which is policy type (not 100% sure) and "

stepDefinition-name" or "stepDefinition-displayName" which is actual policy name as we created it.

I use it as a name for step instead of just "Execution" (this is why you don't see it in UI)

Here are the screenshots of a simple debugging session that hopefully will immediately make sense to you

Some JS magic

Ok, this might even look good (or at least better than the original), but how to get the data?

Well, it turns out, SAP did a great job exposing some global methods (and even oapiproxyData object ) in their app (yes it seems to be a really, really old one), so we can just programmatically create us a session and then fetch data into clipboard.

And for that I used super old trick: javascript favourites snippets (even had to google they were called "bookmarklets")

So, to start session you might want to use something like this:

sap.apimgmt.commons.ajaxHandler({
  data: JSON.stringify({"name": oapiproxyData.name, "version": oapiproxyData.version, "session_id":"pwn3d"}),
  headers: {"Content-Type": "application/json", "Accept": 'application/json', "operation": "start"},
  url: APIMGMT.TRACE_WORKSPACE_ROOT,
  type: APIMGMT.HTTP_METHODS.POST,
  success: console.log, error: console.log
})

And to fetch data into your browser clipboard (and I was surprised I did not need a focusable element when using the bookmarkelt to write to it) you would do this:

sap.apimgmt.commons.ajaxHandler({
  data: JSON.stringify({"name": oapiproxyData.name, "version": oapiproxyData.version, "session_id":"pwn3d"}),
  headers: {"Content-Type": "application/json", "Accept": 'application/json', "operation": "get"},
  url: APIMGMT.TRACE_WORKSPACE_ROOT,
  type: APIMGMT.HTTP_METHODS.POST,
  success: function(data){ navigator.clipboard.writeText(JSON.stringify(data))}, error: console.log
})

And I am not going to teach you how to add that stuff into bookmarks but wiki probably could.

Demo

In this demo we are going to reproduce the session from screenshots above.

For this purpose we use simplest api proxy possible - to anonymous Northwind service https://services.odata.org/V2/Northwind/Northwind.svc/ and protect it with apikey, so you can easily try it yourself in like 10 mins.

00:00 Intro and motivation

01:39 Northwind api proxy and debug with standard app (2 positive and 2 negative responses)

03:45 Try interpreting the results

04:58 But actual session data json contains more data and that is what we cover in blog (kind of)

06:06 A little bit about apigee stuff and json structure and corresponding app screens

08:34 How to obtain session data json (other than by copying from network requests)

10:08 Repeat same api test/debug routine with bookmarklets magic

11:36 Fetch session json data to finally see the new app in action (and try to interpret data there)

15:15 Confirm that AnalyticsPublisher policy/step indeed contains response message.status.code, request.path and request.verb as vars (but not body though)

16:10 "And we do see that we do have body which is very nice" (in proper place)

17:07 Final words about app screens and features and outro

P.S Disclaimer and feature requests/fixes

This is the simplest and mot naive implementation of this app made out offrustration, so if for some reason you might want to test it there can (or must) be scenarios it does not support (haven't tried using scripts, conditional flows etc).

Please feel free to comment here regarding errors/features you might need, but DON'T paste session info here as it contains sensitive information about your apim instance.

SAP Community - Cloud Integration

New Integration Content for Coupa to SAP Signavio Process Intelligence Now Available

Streamline Your Procurement Analysis

How to Access the Integration Content

Key Benefits of the Integration

Share Your Feedback

Cloud to Cloud的数据直连集成：业务伙伴Business Partner主数据

1. 业务伙伴Business Partner的集成：

1.1 发送系统的设置

1.1.1 创建通信系统

1.1.2 创建通信安排

1.2 接收系统的设置

1.2.1 通信系统的设置

1.2.2 创建通信安排

1.3 设置消息的监控

1.4 测试

1.5 查看消息日志

2. 参考文档

SAP Developer News May 29th, 2025

DESCRIPTION

CHAPTER TITLES

TRANSCRIPTION

A look into the Migration Assessment Modernization Recommendation - Clean Core

ARIBA API data extraction & reporting with SAP BTP

Currency Conversion using Integration Suite

Integrating GMAIL using SAP CPI Mail Adapter in iFlow

📌 Introduction

📌 Step 1: Content Modifier for Email Body

📌 Step 2: Configuring the Mail Adapter

📌 Step 3: Sample Email Output

📌 Step 4: Using Exchange Properties for Dynamic Content

Conclusion

Sending a processed payload to receivers

Understanding incorrect Message Mapping and why Context matters

What are Contexts in Message Mapping?

Why Contexts are Important

Understanding Queues in Message Mapping

Managing Contexts

Hands-on example

Identifying an issue with source data

Debugging

Why fix the message mapping?

Tools

The solution

The result

Cloud to Cloud的数据直连集成：PO/SO转换

1. 背景介绍

2. 发送系统的设置

2.1 创建通信系统

2.2 创建通信安排

2.3 输出参数定义（Output Parameter Determination）

2.4 给用户分配收件人（Assign Recipients）

3. 接收系统的设置

3.1 创建通信系统

3.2 创建通信安排

3.3 给用户分配收件人（Assign Recipients）

4. 参考文档

Add SAP PI/PO Communication Channel Start/Stop Functionality to Your iFlows

Mass Controlling Communication Channels and Adapters

Stopping Channel in Synchronous Integrations

Stopping Channel in Asynchronous Integrations

Conclusion

Integration of SAP Digital Currency Hub into your S/4 payments infrastructure

Automating Customer Communication and Data Delivery Using SAP Integration Suite

Part 1: Customer Notification iFlow

1. HTTP Sender Adapter:

2. Content Modifier

3. Parallel Multicast

4. Groovy Script

5. Mail Adapter

6. Process Direct Adapter:

Part 2: JSON to CSV Transformation and SFTP Delivery iFlow

Integration Flow Components

1. Process Direct Sender Adapter

2. JSON to XML Converter

3. Parallel Multicast

4. XML to CSV Converters

5. Join Component

6. Gather Component

7. SFTP Receiver Adapter