SAP Community - Cloud Integration

Updated LJ - Discover the foundations of SAP Commerce Cloud and SAP S/4HANA Cloud Integrations

2024-11-28T08:25:41.256000+01:00

Hola SAP Community! Fernando at the wheel!

In Abril 2022 we created from scratch a new learning journey: Discover the foundations of SAP Commerce Cloud and SAP S/4HANA Cloud integration, read about the original announcement here.

In April 2023 we updated with major improvements to enhance the learners experience, read about the original announcement here.

This summer, after more than 20,000 learners going over it and have issued almost 700 record of achievement to the learners who have completed the whole course, we've analyzed the feedback given to us by them, and started a another update of the whole course content in order to be always improving our content.

Learning Journey Screenshot
This full course update comes with a long number of changes:

Replacing all graphics interactions with explanation videos.
Optimized the content order for the units and lessons to be more easily understandable.
Providing more fluent text descriptions and narrations for the topics.
Updated all resource links, version information and features to the latest SAP Commerce Cloud, S/4HANA Cloud and SAP Cloud Integration sources.
Updated the branding for all the content.

So, what are you waiting for? go to SAP Learning site, and enroll for the new updated version of Discovering the Foundations of SAP Commerce Cloud and SAP S/4HANA Cloud Integrations, after completing it... Don't forget to claim your digital badge to show it in your professional social network profile!

I’ll be back very soon to present you new content and updates for SAP Customer Experience Integration and Extensibility learning area: courses, live sessions, micro learnings and any other educational asset which can be interesting for you!

In the mean time, I’ll be looking forward to your feedback and questions via comments here in this post.

Please share your experience - new API Management survey

2024-11-28T12:08:40.807000+01:00

Dear @SAP Integration Customers,

We are always eager to learn more about how our customers interact with SAP Integration Suite.

In particular, we are interested in hearing how you use the API Management capability of SAP Integration Suite —or why you might not use it yet. Whether you’re an experienced API administrator, an integration specialist, or have never used API Management, we’d love to hear from you!

Your feedback helps shape the future of SAP Integration Suite and meet your needs better.

Who Should Participate?

✓ Current API Management users: Share how you're implementing and benefiting from the capability
✓ Customers not currently using API Management: Help us understand your reasons and challenges

Survey: Usage of API Management

Hugely appreciated! 🙂

--
Chaim Bendelac
Product Manager - SAP Integration Suite

SAP Trading Partner Management - Part III: Partner configuration

2024-12-02T12:05:51.028000+01:00

Now let's focus on the PARTNER part of the EDI message exchange.

At first we need to configure our Parent Company, which is the business entity we are going to integrate with external Trading Partners. We can have only one Parent Company, which means we cannot create a dummy one for testing.

We configure Parent Company the same way we configure external Trading Partners. I will describe the configuration of a Trading Partner, but the same applies to Parent Company. Trading Partners are those companies we will be communicating with. Before configuring our Partner, we should be clear about 3 levels of communication which we need to establish:

System — Type of our Partner’s back-end system (SAP, Microsoft etc.). This is not mandatory and we can name it as we want in case we don’t know
Type System — this is the message format we use in our mutual communication (X12, IDoc, Edifact)
Communication — the transmission technology or protocol of the exchange, which will define the integration adapter in SAP Cloud Integration (HTTP, IDoc, AS2)

Let’s say our Partner ACME Corp uses SAP S/4HANA as their ERP system, IDoc format as the exchange message type and AS2 protocol as the technical communication channel.

With this in mind, we can configure our Trading Partner.

Clicking on the Trading Partner, we enter the Trading Partner Profile. We fill purely descriptive sections Overview and Contacts and let’s jump to Identifiers.

Identifiers

These are codes, identifying our Parent Company and Trading Partners in the communication.

SAP recognizes two sets of Identifiers:

codes identifying the Partners (including Parent Company) in the Parent Company’s own back-end system
codes identifying the Partners (including Parent Company) in the EDI message exchange, ie. these IDs will be used in the message itself and will be validated against TPM configuration. Often these Identifiers are assigned by Dun & Bradstreet or other recognized institution.

We can as well use only one Identifier and if needed, we can map it to whatever value we want in our back-end system. This is the case of our scenario. Let’s say that in our EDI communication with ACME Corp the Identifier 10001_ACME_IDOC will be used in the message exchange.

For our ACME Corp, let’s now create two Identifiers. Identifiers are system-specific, so if our Trading Partner operates IDoc message format, as well as X12 message format, we need to create at least two Identifiers. You can see that for IDoc there is no Scheme available, whereas for X12 EDI format we can choose from various institutions. When using IDs which are not officially assigned by any institution, we can select Mutually Defined, which is also a common choice in the real world.

For simplification, from now on we will consider ACME Corp running only IDoc communication.

Systems.
We skip Business Context section, which is descriptive and helps with the business classification, and have a look at Systems tab. Each System represents a technological platform, which the partner operates — SAP S/4HANA, Microsoft, Amazon, Adobe etc. This is not related to a communication protocol, rather to an ERP or EDI system.

Type System

Clicking on the ACME SAP system, another screen opens. These Type Systems are the communication types. If we exchange IDocs with our Partner, the message format will be XML, even though the Communication type can be HTTP or AS2. This can be confusing. Here you specify solely the message format, not the communication protocol.

Creating a new Type System, we have to select from a dropdown list. Apart of ASC X12 and on-prem SAP S/4HANA we have the following choice:

Communications

Now we get to Communication channel, which represents the technical integration adapter in SAP Cloud Integration.

In our scenario, we communicate over AS2 protocol, so we establish 3 channels — Sender, Receiver and one more Receiver for MDN acknowledgement.

If our preferred communication channel is not listed (for example SFTP at this moment), we select Process_Direct and we have to create a custom separate iflow with SFTP adapter.

Now we have to configure the individual channels. This is the same activity as configuring them in the SAP Cloud Integration iflow. For its complexity I will describe the AS2 settings, but in a separate blog.

Now we have configured our Trading Partner. Nevertheless, we are still not able to exchange a message with this Partner. We need to set Agreement to be able to do so. This we will see in the next chapter.

SAP PI Migration to BTP Integration Suite Patterns and learning experiences

2024-12-04T11:45:02.414000+01:00

In this blog, we share integration patterns used in SAP PI Migration to BTP Integration Suite as well as shared our learning experiences during migration.

Here is high level diagram of integration patterns used:

Here are descriptions of each pattern:

SAP business systems consuming SAP BTP iflow’s using XI/SOAP adapters
- XI is mainly used for async or sync without business faults
- SOAP is mainly used for sync with business fault messages
- SAP BTP Integration suite has been accessed via SAP webdispatcher and blog explains on how to use the same.
APIs exposed follows below patterns:
- Pattern 1:
  - SAP BTP API management proxy -> SAP BTP Cloud integration iFlow -> SAP business systems (via cloud connector using XI/SOAP adapters)
  - API management proxy is used for JWT validation (non SAP identity provider)/ip filtering and exposing API using specific url naming conventions
  - SAP CI iflow for request and response transformations
- Pattern 2:
  - SAP BTP API management proxy -> SAP Gateway ODATA API (via cloud connector)
  - API management proxy is used for JWT validation/ip filtering and exposing API using specific url naming conventions/converting between odata api format and open API specification.
  - Pattern 3:
    - SAP Cloud integration iflow -> SAP business systems (via cloud connector using XI/SOAP adapters)
    - We are using SAP identify provider for oauth 2.0 and iflow used for request, response transformations
APIs or SOAP services consumption:
- Cloud integration iflow to Internal on premise/privately managed cloud APIs via cloud connector and Oauth 2.0
- Cloud integration iflow to external using https with oauth 2.0 from external providers
SFTP communication
- SFTP adapter using SSH for internal SFTP communication via cloud connector
- SFTP adapter using SSH for external SFTP communication
Eventing solution:
- Async outbound and inbound integration with Advanced Event Mesh and Event Mesh (AMQP)
- Async outbound and inbound integration with Confluent Cloud KAFKA using Advantco kafka adapter
  - KAFKA adapter in Cloud integration has limited functionalities and Advantco kafka adapter has advanced configurations for Confluent cloud
Datasphere communication:
- Not part of PI migration but used https and JDBC communication
  - Activity logs using https adapter
  - Audit log or any data related interfaces using JDBC
- Splunk
  - Splunk monitoring integration using MPL – using https or splunk adapter
Mail adapter via cloud connector to send emails securely

Here are key learnings we had during PI migration:

Pattern by pattern migration
Redesign interfaces when needed (like BPM, adapter modules, authentication)
Migration tool is evolving but few changes in PI can be done to migration ICOs when migration tool is not working (like removing of external libraries, removing complex routing)
Identify workarounds if possible- as an example until IBM MQ adapter gets delivered, we could use AMQP
Sizing with SAP
Perform performance test to avoid memory exhaustion, IO exceptions, datastore connection issues, reaching limits of monitoring storage
Request SAP/ Open SAP ticket to increase resources based on your usage/sizing
Reduce usage of datastore (instead use internal JMS queues)
If needed increase JMS internal queues up to 100 (increase further with SAP ticket)
Try not to enable transaction handling (JDBC/JMS)
XI receiver adapter- try to use QoS Exactly once JMS queue instead of Data store
XI sender adapter- try to use QoS At least once JMS instead of Exactly once Datastore
Try to not log payloads or header for high volume interfaces
SOAP vs XI adapter – fault handling vs sxmb_moni logs
Organizing Cloud integration packages and naming conventions/development standards
Implement generic groovy scripts:
Log multiple customer headers
Update json datatypes in json payload
Implement reusable fault message types:
Create generic fault message types mapping
Update message type names using groovy scripts
Develop generic iflow to migrate value maps
Deploy Undeploy Config tool documented in blog

To conclude, we have shared integration patterns and learning experiences which can used by other SAP customers.

New Pipeline Concept features: more bypass options and custom extensions

2024-12-04T12:41:15.645000+01:00

We have recently shipped a new version 1.0.8 of the Pipeline Concept were we introduced the following new features:

Option to combine receiver and interface determination in one single XSLT mapping for an improved runtime behavior
Option to bypass interface determination pipeline step in case of Recipient List pattern without interface split
Option to bypass receiver determination pipeline step in case of interface split scenarios with one single receiver only
Supporting header-based XSLT routing conditions if message body is non-XML
Extension for custom receiver determination instead of XSLT from Partner Directory
Extension for custom interface determination instead of XSLT from Partner Directory
New pipeline processing log providing more details if message is stored to the dead letter queue
Fixed standard retry handling for generic integration flows with splitter to avoid message duplicates

The package can be accessed from the SAP Business Accelerator Hub. If you have already copied the package to your workspace in your SAP Integration Suite tenant, you can simply run the update of the package to be able to use the latest features.

Let me briefly describe some of the new features.

Further bypass options

With version 1.0.6, we have already shipped a bypass option for pure Point-to-Point scenarios, see New Pipeline Concept features: new partner id definition, alternative partner, bypass option. With the latest version, you now have the option to either bypass the receiver determination or the interface determination depending on your integration scenario. For an interface split scenario with one single receiver only, you can bypass the receiver determination. For a Recipient List pattern with one interface per receiver, you can bypass the interface determination. In any cases, by applying the different bypass options you can save at least one JMS queue and one pipeline step which leads to an improved runtime behavior.

Further runtime improvements can be achieved by combining the receiver determination xpaths and the interface determination xpaths in one single XSLT. This use case is actually a special case of the interface determination bypass option. Here, the receiver determination pipeline step has been enhanced supporting a receiver determination XSLT that contains xpaths conditions for both the receiver and the interface determination. The receiver determination pipeline step then splits both the number of receivers and the number of interfaces. This way, you only need to read, decode, and run one single XSLT instead of multiple interface determination XSLTs for each receiver.

Here's an example of such a combined XSLT:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="3.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:param name="dc_country"/>
  <xsl:template match="/">
    <ns0:Receivers xmlns:ns0="http://sap.com/xi/XI/System">
      <ReceiverNotDetermined>
        <Type>Error</Type>
        <DefaultReceiver/>
      </ReceiverNotDetermined>
      <xsl:if test="/*:Item/Category = 'Keyboards'">
        <Receiver>
          <Service>Receiver_11</Service>
          <Interfaces>
            <xsl:if test="/*:Item/Quantity = '10'">
              <Interface>
                <Index>1</Index>                       
                <Service>/PIP/Step07/Samples/Scenario_1/Receiver_11/IfIdx1</Service>
              </Interface>
            </xsl:if>
            <xsl:if test="/*:Item/CurrencyCode = 'EUR'">
              <Interface>
                <Index>2</Index>
                <Service>/PIP/Step07/Samples/Scenario_1/Receiver_11/IfIdx2</Service>
              </Interface>
            </xsl:if>
            <xsl:if test="/*:Item/Quantity != '10'">
              <Interface>
                <Index>3</Index>
                <Service>/PIP/Step07/Samples/Scenario_1/Receiver_11/IfIdx3</Service>
              </Interface>
            </xsl:if>
          </Interfaces>
        </Receiver>
      </xsl:if>
      <xsl:if test="(/*:Item/Category = 'Keyboards') or (/*:Item/Category = 'Software')">
        <Receiver>
          <Service>Receiver_12</Service>
          <Interfaces>
            <xsl:if test="$dc_country = 'DE'">
              <Interface>
                <Index>1</Index>
                <Service>/PIP/Step07/Samples/Scenario_1/Receiver_12/IfIdx1</Service>
              </Interface>
            </xsl:if>
            <xsl:if test="$dc_country != 'DE'">
              <Interface>
                <Index>2</Index>
                <Service>/PIP/Step07/Samples/Scenario_1/Receiver_12/IfIdx2</Service>
              </Interface>
            </xsl:if>
          </Interfaces>
        </Receiver>
      </xsl:if>
    </ns0:Receivers>
  </xsl:template>
</xsl:stylesheet>

As you can see, the XSLT contains the receiver components as well as the receiver interface index and the end points of the scenario-specific outbound processing flows where the mappings and the delivery to the receivers are done. By providing the end point information here, the interface determination pipeline step is bypassed.

For more details, see Pipeline Bypass Options.

Custom extensions

As an alternative to the standard receiver or interface determination based on an XSLT from the Partner Directory, you can implement your own custom receiver or interface determination. The generic integration flows support a kind of custom exit that you can use to run your own custom logic without changing the delivered generic integration flows. To do so, you must implement a separate scenario-specific integration flow that's called instead of the standard XSLT mappings.

You do not need to create the scenario-specific integration flows from scratch, the updated Pipeline package contains templates that you can copy and adapt to your needs. The templates have the target XSDs as references which eases the implementation effort. So, you can create a message mapping that maps to the target structure or alternatively you can create your own groovy scripts or use any other logic which you prefer. The target XSD for the receiver determination by the way supports the combined receiver and interface determination as described above. So, when using the custom extensions, you can also leverage the bypass options.

For more details, see Customizing the Pipeline Concept.

Non-XML payloads

When running an XSLT mapping to determine the list of receivers or interfaces for non-XML messages, you usually run into an error even if the conditions are based on headers only because the XSLT expects an XML. To overcome this error, a dummy XML is created right before running the XSLT. With this, you are able to process non-XML messages within the pipeline without the need to convert into XML before.

Processing log

At various places during message processing, information is stored in a new header which we pass across the pipeline steps. We decided to add the log information whenever we call groovy scripts to avoid to make too many changes to the integration flow model. Whenever a message is stored in the dead letter queue because the maximum of retries has been exceeded, the log information is attached to the message processing log.

Retry handling

For the generic receiver and interface determination integration flows where the message is split, transaction handling ensures that split messages are rolled back in case of an error. However, if the message is forwarded to the dead letter queue, the message processing ends with either a message end event or an escalation end event so that in rare cases already split messages might be committed. This may lead to duplicates if the message is moved from the dead letter queue to the actual queue for reprocessing. To avoid duplicates, we had to change the standard retry handling within the receiver and the interface determination flows. When the actual maximum number of retries have been exceeded, we need to do an additional retry and then check right at the beginning of the integration flows before splitting the message. For the other generic flows that do not carry out a split, the retry handling kept unchanged.

If you like to try out the pipeline concept in general and the new features in particular, check out this github repository where I describe how to setup sample scenarios using the pipeline concept. Here, we have added the following new scenarios and scenario variants leveraging the new features:

Scenario 1A, scenario 2A and scenario 2B cover the bypass options including the combined receiver and interface determination.
Scenario 2C and scenario 4A cover the custom extensions samples.
Scenario 7 covers the non-XML payload use case.

As usually, in case of feedback, feel free to reach out to me.

How to Provide Read-only Access to Integration Advisor

2024-12-09T09:00:00.044000+01:00

Introduction

Recently, we delivered a new role in Integration Advisor, which allows read-only access to the application in addition to the existing content developer and content admin roles. In this blog post, I will show how you can assign this role to a user in Neo as well as in CF.

How to?

First you must assign yourself to the role of a "Subaccount Administrator" in the subaccount which is subscribed to Integration Suite (in CF) or you must be a member with at least "Application User Admin" role in the subaccount which is subscribed to Cloud Integration (in Neo).

Role assignment (CF)

Now, you can assign the new role to your users. Open your subaccount in the BTP cokcpit and navigate to Security->Users:

Open user maintenance

Then click on the user, that you want to assign a role to (if the user doesn't yet exist you can create it via the "Create" button), and navigate to "Role Collections" on the right hand side:

Role Assignment

There click on the button "Assign Role Collection", select the role collection "iadv-content-read" and press "Assign Role Collection". Check if there are no other "iadv-*" role collections assigned to the user. If there are some, remove the assignment, otherwise the user can still create and modify content in Integration Advisor.

For more details you can also read Configuring User Access to SAP Integration Suite and Security Administration: Managing Authentication and Authorization.

Role assignment (Neo)

Open your subaccount in the BTP cockpit and navigate to Security->Authorizations:

Maintain Authorizations

There enter the user ID and press the "Show Assignments" button (alternatively, you can also navigate to "Groups" and select a user group from the list of available groups, if you want to assign a whole group to the new role):

Display of Role Assignments

If the role "Guidelines.ReadWrite" is shown, remove it, because otherwise this will take precedence over the read-only role. Then press the "Assign" button of the "Roles" table and select your Integration Advisor subscription in the popup:

Assignment of Roles

Select the role "Guidelines.Read" and press "Assign", then repeat the same for the role TypeSystem.Read, which is needed additionally for all Integration Advisor users. For more details you can also read Assigning Users for SAP Integration Advisor and Managing Roles.

Usage of new role

Logout from the cockpit and open the Integration Suite (or Integration Advisor for Neo) URL in your browser. If asked for a user, use the user, that you assigned the new role to. Then Integration Advisor will open in read-only mode, where all modifying activities are not possible:

More specifically, the new role enables you to:

View the following artefacts in read mode: Type system library, MIGs, MAGs, Custom Type Systems
Simulate MIGs and MAGs
Export Runtime Artefacts for MIGs and MAGs
Export Documentation (PDF, XLS) for MIGs and MAGs

The new role does not allow any modifying actions like

Create, Edit, Activate, Copy
Import

(see also SAP Online Help)

Summary

You know now how you can assign the new read-only role of Integration Advisor to your users, so that they can only view content but not modify it, which is helpful for productive systems and for support users who shall not change anything in the system, but only check the content.

Please, share your ideas and feedback in a comment. Furthermore, you can follow the SAP Integration Suite topic page to get to know more about Integration Suite in general, or read other posts about Integration Advisor. You can also follow my profile if you want to read similar content in the future.

Which S/4HANA extensibility option is the best for thriving as an SAP partner in the cloud space?

2024-12-09T14:18:38.623000+01:00

Get more value from S/4HANA with SAP Extensibility options, part 3

In my first article of this series, I explained why extensibility options are crucial for S/4HANA customers. In the second article , I explained which option I should choose for the different use cases from a customer's point of view. In this last article, I want to focus on existing and new SAP partners who wish to connect their cloud offerings to S/4HANA customers or migrate their existing SAP ECC add-on to ABAP Cloud.

I have worked for almost 30 years in the SAP ERP space and have seen many innovations in SAP software. I started in 1996 when SAP introduced the client-server ERP and RFC libraries. During the turn of the century, SAP adopted the Internet and launched its new dimension portfolio, and third-party integration products were introduced into the market. SAP has stepped into the cloud in the last decade and fully adopted artificial intelligence.

There are a lot of changes at the core of ERP, but the challenges in my job are almost the same. As a developer, enterprise architect, SAP mentor, speaker, teacher, and advisor, I ask myself, ‘How can I add additional value for my customers out of an ERP system?’ And the answer is always the same. Focus on the missing functionality. SAP always delivers best-practice solutions that never fulfill all customers' requirements. This is still an ample opportunity for me, consultancy companies, SAP add-on solution providers, and all other software vendors.

For the last eight years, I have mostly worked for big cloud companies like Blackline, Booking, and Zuora to advise them to connect their cloud portfolio and systems to SAP S/4HANA. The cloud companies' customers are also big SAP customers. In this article, I will share my experience and tell you which S/4HANA extensibility options fit the best cloud vendors that want to thrive as SAP partners.

Challenges for SAP Solution Partners

The question is easy, but the answer is more complex. As I wrote in my previous article, SAP supports several S/4HANA extensibility options, which depend on the S/4HANA releases and versions. So you need to answer the question: Do you want to support the S/4HANA Cloud private version, the S/4HANA Cloud public version, or even support ‘classic’ SAP ECC? But also, do you want to build a standalone add-on that runs on Business Technology Platform Software as a Service (BTP SAAS) or is embedded on S/4HANA? Or do you want to connect your partner cloud solution to S/4HANA?

But there are more answers needed. The data and events must be publicly available in the S/4HANA system. How will we handle the data exchange's latency, performance, size, and security? Who will be responsible when something goes wrong, technical, infra, and business-wise? Will the current SAP license be enough, or will there be additional operational and license costs for my customers? How will user management, authentication, authorization, and security be handled? How will the execution be monitored, and how will alerting and mapping be arranged? How should sensitive data be managed, and what audit trails and data should be archived? How will networking, security, risk, and complaint departments react to the solution? Will the used platform and tooling be future-proof? And so we can ask a lot more questions.

Ultimately, all these questions should be answered to develop the best solution. However, in my experience, not all SAP partners consider these questions.

SAP positions the S/4HANA Cloud public edition as the preferred version to GROW with SAP in the long term. However, SAP also provides the S/4HANA Cloud private edition for existing customers to RISE, with SAP as the golden path to move to the S/4HANA Cloud public edition in the future.

We will first focus on the S/4HANA Cloud public edition because this release is SAP’s long-term solution. Next, we can consider other SAP ERP systems, such as the S/4HANA Cloud private edition, S/4HANA on-premise, and SAP ECC.

S/4HANA extensibility options

In my second article, I described the eight extensibility options for S/4HANA. However, if we look at partner solutions, we can skip the classic extensibilities because they are not supported in the public edition and are obsolete from a certification point of view. Also, the low-code extensibilities options S/4HANA Key User Extensibility, SAP Analytics Cloud, and SAP Build Apps could be more suitable because they mainly focus on custom developments for the citizen developer.

Figure 1 – Possible Partner Integration Options

This limited the possible extensibility options, and because we can also access the S/4HANA APIs and events directly, we will have five possibilities (See Figure 1) to deliver a partner solution:

An add-on application on the S/4HANA embedded ABAP environment
A partner application as a SAAS application running on SAP BTP ABAP environment
A partner application as a SAAS application developed with SAP Build Code on SAP BTP
An integration package on SAP Cloud Integration
Running your application on a non-SAP solution and directly accessing S/4HANA events and APIs.

Using APIs and events

Software vendors that run their solutions on their cloud will primarily consider the last option and try to connect their cloud solution directly to S/4HANA events and APIs. But from my experience, this isn’t the right approach. The S/4HANA Cloud public edition strongly depends on business events, and most cloud vendor solutions aren’t prepared for this. Due to the configuration possibilities in the S/4HANA Cloud and the use of APIs, the responsibility for root cause analysis shifts from the customer to the cloud vendor, which needs to build a big SAP knowledge support center. Also, the cloud vendor should handle all security, risk, and compliance issues, which are initially the customer's responsibility.

Another issue with this approach is that you, as a partner, cannot certify the solution with SAP. SAP is not responsible for the solution's availability and performance, code changes, or deprecation of APIs and events. This approach carries a high risk for customers and the cloud vendor.

SAP Cloud Integration

A better approach is an integration package that can be installed on the customer's SAP Cloud Integration system. In this case, SAP will ensure smooth integration between S/4HANA and SAP Cloud Integration. The solution can be certified, and as a cloud vendor, you can mainly focus on integrating your cloud partner solution and SAP Cloud integration. The downside of this approach is that SAP Cloud Integration is separate from any S/4HANA Cloud edition license and should be brought by the customer separately. Only some customers are willing to do so. Most customers already have an existing integration product for more than just their SAP landscape. The need for separate SAP Cloud Integration licenses and setting up a support and knowledge center to maintain SAP Cloud Integration will be a blocker. Providing an integration package as a partner solution will limit the number of SAP customers you can connect to your cloud solution in the market.

ABAP Cloud environments

The best approach for cloud vendors is to build the connectivity as an add-on product on S/4HANA, a SAAS solution on BTP, or a combination of these options. Building your partner integration solution on an ABAP Cloud environment is the best extensibility option for applications strongly dependent on S/4HANA. Based on my investigation, cloud vendors will profit the most from this option. They can shift the responsibility of the availability and maintenance of the landscape to SAP; they are highly flexible in a robust and stable environment following SAP’s future path and can directly profit from the innovations SAP is launching. The barriers to developing these extensions are higher, but the barriers for customers will be lower. There will be no additional costs for running the developer extensions on the embedded ABAP cloud environment in S/4HANA Cloud. When cloud vendors run their solution as a SAAS solution on BTP, they can share the costs with multiple customers. The advantage of the SAAS solution above the Addon is that the cloud vendor fully controls the code line, and the customer is still responsible for accessing and connecting to their S/4HANA tenant.

Another significant advantage of building connectivity from S/4HANA to your cloud solution on ABAP Cloud for BTP as a SAAS solution is that you can connect to the S/4HANA cloud public edition, make your future-proof solution with one code line, and downport the connection to other ERP versions, such as the S/4HANA cloud private edition, S/4HANA on-premise, or even SAP ECC.

Figure 2 – Codeline options of ABAP Cloud

Because the ABAP Cloud on the BTP code line follows SAP’s Clean core strategy, it should also run as an add-on on the S/4HANA Cloud editions when these editions support the same underlying ABAP Cloud version.

As mentioned before, in SAP ECC, many SAP solution partners have already provided an add-on to solve the missing functionality of standard SAP. However, this add-on should be rewritten to be S/4HANA Cloud compliant because SAP only accepts code that follows SAP’s Clean core strategy. The SAP solution partner can rewrite the code as S/4HANA Cloud Developer Extensibility, but in this case, the partner always depends on the customers' upgrade strategy. Suppose he wants to control the versioning of his code line and innovations. In that case, the partner can rewrite the addon as a side-by-side extensibility with SAP Build Code in SAP CAP or ABAP, which connects to S/4HANA. Or he can even run the applications in a non-SAP cloud environment of his choice and follow the extensibility options described above. From my experience, all these options are valid, future-proof, and in line with the solution for cloud vendors.

Cloud and SAP Add-on vendors who want to build their solutions with ABAP Cloud can even speed up their development, shorten the time to market, and shift responsibilities back to their customers using an OEM solution like the FEXS API Connect from fexs.com. These OEM solutions already take care of the most common tasks, resulting in less development needed, smaller SAP support departments, and higher customer satisfaction.

Conclusion

Because SAP and its customers are still on the move with S/4HANA to its future Cloud ERP landscape, it isn’t easy for SAP Solution partners to make the right decision for their future-proof solution. The move of SAP to the cloud and the openness and flexibility of its portfolio will give SAP Addon partners and existing cloud solution providers an excellent opportunity to bring added value to the existing SAP community. Suppose your solution strongly depends on S/4HANA processes. In that case, I believe a partner application running as S/4HANA Cloud Developer Extensibility or on a SAP BTP ABAP Environment following SAP Clean Core strategy is the best and most future-proof solution. An article is always too short to explain all the details, but I hope this article triggers your mind. And in my job as a strategic architect and advisor, I’m open to any discussion and available to help push you in the right direction.

This article was initially posted on the linked-in profile of Robert Eijpe

SAP Trading Partner Management - Part IV: Agreement

2024-12-11T12:29:54.341000+01:00

Agreement

Agreement is the heart of Trading Partner Management - it is here where all configuration components meet.

When creating Agreement, we have to create Agreement Template first. This is a generic Agreement, which can be reused and modified for as many Agreements as needed.

As we have many trading partners, we can create Agreement Template with My Company only and individual Agreements will be partner-specific. As we specify Type System here, we create one Template for IDoc communication and one for X12 communication, depending on what message method we are using.

Now we create the Agreement based on our Agreement Template. We usually select Copy from Template to have Agreements independent, even though binding the template may be useful in case our trading partners share similar configuration.

This is an example of an Agreement between My Company and our ACME trading partner. Don't worry too much about the Type System Version, as it can be always edited later, based on real message content.

B2B Scenarios

The detailed message exchange configuration is specified in B2B Scenarios, where we define inbound / outbound flows. Let's demonstrate it on inbound (partner is sending an IDoc to us).

We populate individual boxes in alignment with our TPM configuration. It is here, where all the components meet! Here we connect SCI Sender / Receiver adapters with TPM message configuration and apply Mapping, which we built in Integration Advisor. In the inbound scenario we have to read the above diagram from right to left.

Once we save it and activate, the configuration is moved to TPM Partner Directory, which we can imagine as a database with all the data necessary for successful message exchange.

Sending a test AS2 message

Only now, we can try to send a message, as we have the whole chain configured. Let's do it.

Just one thing before that - in order for this to work, we have to have this SAP-built package installed and configured. You can get it on SAP Business Accelerator Hub. This is more of a SAP Cloud Integration topic, so I will skip it here. If there is a demand, I can write another article about it.

I will simulate a partner's call by Mendelson AS2 client with a sample IDoc message. The IDoc header is what matters to TPM, so let's just focus on that.

Now we run the transfer and the message was sent to TPM.

We can see the message in TPM proprietary B2B Monitor.

The result is an error, which is nothing unusual in the beginning and its resolution will help us further understand the TPM logic.

Let's click it and see the Details of the error.

The 'Partner Directory lookup failed' error can be really frustrating, if we don't know what to look for.

What the error is saying is that the IDoc message doesn't correspond to the configuration, which we saved into Partner Directory.

TPM takes several so called Lookup Keys and if they don't match, it throws this error. Now we have to compare the above Lookup Keys from the message with Lookup Keys from Partner Directory.

In TPM B2B Scenarios menu, we go on Partner Directory Data tab and look for the record, which represents our Agreement. Here we can see the Lookup Keys combination, which we need to match.

Now we have Lookup Keys string from the message exchange and Lookup Keys string from Partner Directory. Now we have to compare them. Doing so, be careful even about the dashes, upper case, numbers, everything. Those strings need to match 100%.

We see 5 Keys:

'AS2-SAP_IDoc' is derived from out partner Type System
'1809_FPS02' is the version of the Type System we selected. We could change it in the Trading Partner profile, if this was causing a mismatch
'10001_ACME_IDOC' is our partner Identifier (configured in Trading Partner profile) and it needs to be specified in the IDoc as SNDPRN (Sender Partner)
'QS4CLNT300' vs 'DS4CLNT100' - we have mismatch in the SAP client identification. In our TPM Agreement we declared DS4CLNT100, but our partner is sending different value in RCVPRN (Receiver Partner) value. Let's fix it in our IDoc and set value DS4CLNT100
'ORDRSP.ORDERS05' - In Partner Directory this is derived from the MIG in the TPM configuration, whereas in the IDoc it is a combination of <MESTYP>.<IDOCTYP>
Mismatch in this is usually the hardest to fix, as we may need to redefine the MIG. I take a shortcut here and rename it in the IDoc

This is our new IDoc header

The IDoc now passes TPM, as the Lookup Keys match and TPM was able to identify the Sender, Receiver, the exchange type, message format and the mapping.

As we can see, we can resolve the mismatch either by changing the message content, or the configuration. Changing the configuration is usually a better option, as we may not be able to control what the partner is sending.

SAP Cloud Integration : B2B - Restart/Retry Messages - B2B Monitor

2024-12-21T01:00:55.740000+01:00

Hello SAPiens,

With new Cloud Integration - Trading Partner Management V2 version 2.3.7 SAP has released a new B2B monitor feature of Restart/Retry Interchanges

Understanding a feature:-

The B2B Monitor has a manual restart/retry function exclusively designed for failed interchanges, allowing you to re-process failed messages. The Actions button is enabled when you select the interchanges and it consists of two options: Restart and Retry. These options appear only for interchanges with the status Failed.

Restart: This option resets the sender payload to integration flow Step 1b - Write Message to Message queue, thereby re-initiating the messaging process from the beginning. As a result, the message mapping is re-executed, making room for corrections or adjustments to be made. Restart is ideal for addressing errors related to message transformation or formatting.

Retry: Retry resets the receiver payload to Step 3 - Receiver Communication Flow V2, bypassing the message mapping step. This option is suited for resolving errors related to receiver-side processing or temporary connectivity issues, where the original message mapping remains valid.

Prerequisites

1. Deploy Iflow - Step 1 - Sender Communication Flow V2 - Internal

2. Copy deployed endpoint URL from Integrations Content

3. Create BTP - Destination

Name - B2BTPM_Reprocess_Endpoint

URL - <host:port>/http/tpm/internal/repost_endpoint

Ignore HTTP 500 error of test connection check.

Procedure

#HappyLearning

Regards,

How to configure PollEnrich in Cloud Integration

2024-12-30T22:20:06.846000+01:00

Introduction:

What is Poll Enrich: It is used to read the messages from external system and add the content to the original message in the middle of message processing sequence. Currently, we can use Poll Enrich step only to read the data from SFTP server.

There are the following options in Poll Enrich:

Combine XML: Combines the message polled from the external component with the original message without any conditions. The messages are combined in multimapping format.

Concatenate: The message polled from the external component is added to the existing message.
Replace: The existing message is replaced with the message polled from the external component.

Step-1: Add i-Flow and name it as PollEnrich and add an artifact take sender as HTTPs and receiver as SFTP

Step-2: Open the i-Flow and Change the Sender Participant to “HTTP” and Target Participant to “SFTP”

Step-3: Connect the Sender Participant “HTTP” to Start and use the HTTPs adapter. Configure the Connection Tab as per below.

Note: Address can be anything, but for practice purpose here I am using POllEnrich as naming convention. This will be the end point URL for the Interface to trigger.

Step-4:From the pallet functions, choose Call ---> External call--->Poll Enrich and drop it in-between Start and End Message.

Double click on Poll Enrich function and select Combine XML from the Processing tab

Step-5: Connect the End message and Target Participant “SFTP” and use SFTP adapter. In SFTP adapter, enter the following details

Make sure that the SFTP credentials are deployed in the below path

Monitoring–>Integrations And APIs–>Overview –> Manage Security –> Security Material –> Create/Upload Credentials

Check the connectivity test of SFTP adapter in Test Connectivity in the below path

Overview –> Manage Security –> Connectivity Tests –> SSH

Copy the Host Key and paste it in notepad & deploy it in Known Hosts(SSH) file in the below path

Overview –> Manage Security –> Security Material –> Upload Known Hosts(SSH)

Step-6: Now take one more sender from the Participant pallet and Connect the Sender Participant “SFTP1” to Poll Enrich.

In SFTP adapter, enter the following details

Step-7: Save the Integration Flow & deploy it. Once Deployed, Go to Monitor. The status of the Integration Flow should be started

Step-9:Now we are good to test the Integration flow. The next step is configuring the end point in Postman Copy the end point from Monitor tab.

Inputdata:

<Order>

<OrderStatus>Shipped</OrderStatus>

<CustomerEmail>customer@example.com</CustomerEmail>

<Order>

</OrderDetails>

Data from external system:

<OrderDetails>
<Order>
<OrderNumber>12345</OrderNumber>
<OrderStatus>delivered</OrderStatus>
<CustomerEmail>customer@example.com</CustomerEmail>
<CustomerName>John Doe</CustomerName>
<EmailNotificationFlag>true</EmailNotificationFlag>
<OrderTrackingNumber>TN12345678900</OrderTrackingNumber>
</Order>
</OrderDetails>

Step-8:

Open Postman paste the endpoint that you have copied from the monitor select basic authentication and provide the credentials the you have created.

Inputdata:

Output:

You can also try the other two functions in the same flow by changing the aggregation algorithm to

Concatenate
Replace

Thank you & Happy
Integrating

SAP Cloud Identity Services for Beginners

2025-01-04T18:57:21.208000+01:00

Introduction:

SAP Cloud Identity services consist of 3 key components.

Identity Authentication (IAS): Manages user login and provides single sign-on.

Identity Provisioning (IPS): Syncs user data between systems. It does the transformation/filtering from source to target system.

Identity Directory: Centralizes user information, acting as a single source of truth for identity management.

In this blog post, I will showcase the following:

Use IAS as a custom IDP for Integration Suite
Provision users from FSM to IAS using IPS

Configure IAS as custom IDP for BTP Subaccount using

OIDC

In this scenario, we have two subaccounts, say trial and cis. Subaccount named - trial has Integration Suite subscribed and Subaccount named - cis has Cloud Identity Services subscribed.

Step 1:

Go to the Sub Account of Integration Suite for trust configuration.

Click on ‘Establish Trust’ Button.

The login page of Integration Suite looks like below:

Step 2:

Go to Cloud Identity Services -> Users & Authorizations -> User Management -> Add New User

After account activation, the user (in our case Mr. John Doe) still cannot access the Integration Suite. See the screenshot below. This brings to the next step.

Step 3:

Go to Subaccount for Integration Suite.

Create a custom role collection containing all the required roles of SAP CPI Consultant.

Step 4:

Go to Cloud Identity Services.

Create a group for CPI consultants and assign the user to that group.

Step 5:

After establishing trust (referring to step 1), an application is auto-generated, as shown below.

Now there is an attribute related to ‘group’.

Go to subaccount for Integration Suite -> Trust Configuration -> Click on Custom IDP link

Step 6:

When a user logins, we can see the logs from Troubleshooting log of Cloud Identity Service.

Monitoring & Reporting -> Troubleshooting Logs -> search for keyword ‘jwt’.

Action type is ‘issueJwtToken’.

Click on ‘Log Details’.

Step 7:

Enable 'Risk-based Authentication' for email domain.

Now if the user's email domain is gmail, it will ask for two-factor authentication.

Go to Profile Management UI.

Provision users from FSM to IAS using IPS

Step 1:

Create source system for FSM (Field Service Management)

For this case, I will replicate only one dummy user from FSM to IAS. The filter criteria (fsm.user.filter) is used.

Please note the data used in executing these scenarios throughout this blog post is test data/ fake data only.

Ignore 'Group' entity (to avoid group sync).

Step 2:

Create target system for IAS (Identity Authentication)

Create a system admin for IAS and use the generated client id as user and secret as password.

Step 3:

Run 'Read Job'. It is also possible to subscribe for job failure notifications by clicking on 'Subscribe'.

Step 4:

Go to Provisioning log to check the job execution status and details.

Reference Links:

Regards,

Priyanka Chakraborti

Step into the Future of Integration: Using Azure CosmosDB Receiver Adapter in SAP Integration Suite

2025-01-05T22:14:08.054000+01:00

Background

With its December 27, 2024 release, SAP introduced the Azure CosmosDB receiver adapter, enhancing the SAP Integration Suite's capabilities. Azure CosmosDB, a cloud-native NoSQL and vector database from Microsoft, supports globally distributed applications with high availability and low latency. In this blog, we will explore the features of Azure CosmosDB and the new receiver adapter, walk through the setup process, and demonstrate a sample integration scenario to help you get started.

The new Azure CosmosDB receiver adapter is generally available, subject to your subscription plan. For more details, refer to SAP Notes 2903776 and 3188446. You can find it in SAP Business Accelerator Hub or directly on Discovery page of you Cloud Integration tenant.

Below I gather few links that can help you with starting up:

Azure CosmosDB documentation: Azure Cosmos DB | Microsoft Learn

AzureCosmosDB Adapter for SAP Integration Suite: https://api.sap.com/package/AzureCosmosDBAdapterforSAPIntegrationSuite/overview

SAP Help Page: https://help.sap.com/docs/integration-suite/sap-integration-suite/azure-cosmosdb-receiver-adapter

What is Azure CosmosDB?

Azure Cosmos DB, a cloud-native database service from Microsoft, is designed to support globally distributed, modern applications. It offers high availability, exceptional scalability, and low-latency access to data. Unlike traditional relational databases, Cosmos DB is a NoSQL and vector database, making it versatile enough to handle unstructured, semi-structured, structured, and vector data.

Azure CosmosDB organizes data into 'items,' which are stored in 'containers.' The terminology and structure may vary based on the API used. For example, with the MongoDB-compatible API, data is referred to as 'documents' within 'collections'. These containers are grouped into "databases," functioning as namespaces. One standout feature of Cosmos DB is its schema-agnostic design, allowing the addition of items without requiring a predefined schema.

Features of Azure CosmosDB Receiver Adapter on SAP Cloud Integration

At first glance, the Azure CosmosDB adapter functions similarly to the Azure Storage adapter in SAP Integration Suite. This is because CosmosDB, on the surface, got similar integration capability as Blobs that are kept in containers. This helps a lot in understanding how potential integration scenarios and patterns can be designed. Therefore, if you are familiar with Azure Storage adapter on Integration Suite you will quickly catch how to use also this new adapter.

What is nice about Azure CosmosDB is that you don’t need to really define the data model before you start playing with DB itself or integrating with it. You just need few steps of preparation and you are ready. Just create new CosmosDB in your workspace, then create the Container in it and assign Partition Key in case it's required (in some specific scenarios it will be needed).

Azure CosmosDB adapter allows for all CRUD operations with option to List, Query and Replace records on objects in scope that are Database, Containers and Documents of CosmosDB account configured on the adapter. Documents are simply records specified by id and optionally by Partition Keys.

Partition Keys are groupings for Documents in Container, in case of Products it might be CategoryID. Partition Keys do not need to be unique across containers and documents but serve to logically group documents for improved data organization and retrieval. Apart from Single Document processing adapter provides also an option to use Bulk processing option.

With an understanding of the adapter's capabilities, let's move to the setup process required for this integration. Below show few steps needed on Azure side to start with.

Prerequisites and Initial Setup

1. First create an account on https://portal.azure.com/

2. Once you are done with it, request creation of CosmosDB resource in your Azure account

3. Creation and deployment of your first CosmosDB should go fast and result with resource available as below

4. Now you are ready to create your first Data Base and Container, in my case I have designed it to keep Products. For now the Items are empty but soon it will be fulfilled with data coming from SAP Cloud Integration.

I didn't specified additional Partition Key, its important aspect on Azure CosmosDB, for more information about it you can refer to following documentation. https://learn.microsoft.com/en-us/azure/cosmos-db/partitioning-overview

In general for small databases int is not required to introduce the additional partition key and you can set it to "/id" of your Document. For big data collections in CosmosDB Partition Key is required. For container with products apart of Product ID key you can introduce Partition Key as Product Category ID that will group Products logically.

5. The final critical step is to obtain the API Key for integration and configure it in SAP Cloud Integration as a Secure Parameter under Security Materials. You have an option to use Master Key Token or Resource Token (Isolated to specific resource on Azure). In this scenario I used Master Key.

Here you go you can now start using your CosmosDB and Container in your integration scenario!

In the next section, we will demonstrate a simple integration scenario where data from an external API is transformed and loaded into Azure CosmosDB using the SAP Integration Suite - Cloud Integration.

Demo Scenario

The demo scenario is straightforward yet sufficient to illustrate the basic steps and principles for setting up a connection and integrating with Azure CosmosDB using SAP Cloud Integration. The following section provides an overview of the iFlow built to implement this scenario.

Data of Products will be pulled from REST API of Northwind JSON Server, that is free of charge demo API with sample data for test scenarios.

Products will be pulled from Northwind API using SAP Cloud Integration iFlow started with timer (run once). Products pulled from Demo API will be transformed slightly to meet expectations of CosmosDB and processed in Bulk mode to my Azure CosmosDB. Below snippet shows part of Northwind Products payload that will be processed by the iFlow.

Data Source: northwind.vercel.app/api/products

Although it's important to mention that apart from requirement of having unique UUID "id" or additional PartitionKey, if expected by CosmosDB, there is no restriction and no special requirement on JSON structure pushed to CosmosDB as no data model creation and modeling is expected upfront. Below is overview of an iFlow build for this scenario.

Main iFlow steps:

1. Data of Products is pulled from Northwind API

2. Transformation of Product payload to fit into CosmosDB container. The Groovy script is used to transform the Product payload to align with CosmosDB's requirements. Here's how the script works::

a. Introduce ProductID field and copy "id" of Product into ProductID

b. Replace id with unique UUID accepted by CosmosDB as a key for Document

Content before groovy script processing:

Snippet of groovy code:

import com.sap.gateway.ip.core.customdev.util.Message;
import groovy.json.JsonSlurper;
import groovy.json.JsonOutput;
import java.util.UUID;

def Message processData(Message message) {
    def body = message.getBody(String);
    
    def jsonSlurper = new JsonSlurper();
    def productsList = jsonSlurper.parseText(body);

    if (productsList instanceof List) {
        productsList.each { product ->
            if (product != null) {
                if (product.id != null) {
                    product.ProductID = product.id;
                }
                product.id = UUID.randomUUID().toString();
            }
        }
    } else {
        throw new IllegalArgumentException("Invalid JSON structure: Expected a list of products.");
    }

    def updatedJson = JsonOutput.toJson(productsList);

    updatedJson = JsonOutput.prettyPrint(updatedJson);

    message.setBody(updatedJson);

    return message;
}

The output of this Groovy script ensures that each Product has a unique UUID as the 'id' field and an additional 'ProductID' field. Result of groovy script processing:

Main principle for Products transformation is that CosmosDB expect id of Document in a form of unique UUID and Northwind Product ID cannot be used. This code is just for a purpose of this demo, real life solution will look slightly different but requirement on CosmosDB side need to be addressed in overall design.

3. Data of Products is pushed to Azure CosmosDB

Configuration of Azure CosmosDB adapter is setup with Azure CosmosDB account details and Master Key Alias.

The Processing Tab is configured to use Bulk mode, enabling us to process all products from the Northwind API at once. The Upsert mode is selected to create or update records seamlessly, ensuring that any document with the same UUID already existing in the container is updated instead of duplicated. This helps to do creation and update in one request.

Database and Container is specified. As we dont have additional PartitionKey we are using our main table key /id as PartitionKey.

Demo execution

Next, we will execute the iFlow and observe the results. Our Container in CosmosDB named "Products2" is still empty but we will fulfil it with data using our Demo iFlow.

Our iFlow runs fine and without errors but you need be careful here as in case of Bulk processing Cloud Integration will not raise exceptions during runtime in case problems with Documents Upsert on CosmosDB side. Exception will be only raise in case of connectivity or adapter configuration issues or in case of processing Single mode set on adapter. As mentioned, I’m using Bulk operation on Documents to Upsert new records into my CosmosDB.

Proper error handling is crucial. Note that errors on the CosmosDB side are not flagged as failures by the Azure CosmosDB adapter in Bulk mode. The processing status is marked as 'Completed' in SAP Cloud Integration unless there are connectivity or configuration issues. CamelHttpResponseCode is also sent back as 200 with ResponseCode “OK” . Failures are only visible in the response payload if the connection is fine to Azure CosmosDB.

So you need to check and verify payload after response is received in Bulk scenario.

How to troubleshoot such errors? It's another big topic and there is not place in this blog to discuss it this time but definitely you need to learn little bit on error handling on Azure side. Logs are available on AzureCosmosDB side but you need few steps and some configuration to pull out from Logs what you need.

In our happy scenario and in any case of successful processing the response payload will give you clear information on the results for each Document processed in Bulk mode. It might be needed to analyze the response and handling problems with each Document separately, depending on scenario.

Result

Let's check what is the result of our Demo iFlow on Azure CosmosDB side. We can see data injected to our container with id's set using our groovy script. The structure of JSON was accepted and CosmosDB added additional technical attributes during runtime needed to keep data in container properly. All the JSON fields that starts with "_" are CosmosDB technical attributes added during Upsert operation. They are not part of initial payload from Northing API. JSON if field from the payload is used as id key of the record/Document in Container. Using UUID "id" you can perform all CRUD operations on this Document.

Each Document created in Container can have different JSON structures, there is no data model definition that needs to be followed. That's one of the principles of CosmosDB that is so powerful and flexible to work with.

This demonstrates the successful replication of product data from the Northwind API to Azure CosmosDB, with the JSON structure adapted dynamically during the integration process.

Our goal is achieved, data from demo Northwind API of Products is replicated to CosmosDB using new adapter. Setup is fairly simple and testing is easy. Lets see on another options and operations available with this adapter.

Other operations

You can perform CRUD (Create, Read, Update and Delete) operation on Databases, Containers and Documents in both Single and Bulk processing mode. There are also other features that you can learn about from very good adapter documentation for example it supports operations among other as List, Query, Update, Patch Delete and Replace on various entities in Azure CosmosDB.

List operation: gives you easy way to get the content of each object and list databases, container and documents in containers.
Query operation: is quite interesting as you can inject SQL statements in your JSON request to CosmosDB and perform more advanced queries on your Documents.
Update operation can be used to modify the contents of an existing Document within a
Container in Azure CosmosDB.
Delete operation: can be used to delete a Database, Container, or Document in Azure
CosmosDB.
Replace operation: in Azure CosmosDB involves replacing/updating multiple documents
in a single batch operation. This is useful when you need to modify existing documents in bulk
rather than inserting new ones.
Patch operation: involves path-level updates to specific files/properties to multiple
documents in a single batch. These operations include modifications such as add, increment,
move, remove, replace, and set.
Upsert operation: is used to insert or update multiple documents in a single operation. It
updates any existing documents in CosmoDB and insert it if they are not already present.
Delete operation: refers to the process of deleting multiple documents in a single operation.

Below are samples configurations of adapter showing how you can List databases, Containers or Documents in Container and sample response payload.

Sample operation 1: Get List of Databases

For this REST No-SQL query adapter provides all Databases for the given CosmosDB account.

{"_rid":"","Databases":[{"id":"SampleDB","_rid":"5tgUAA==","_self":"dbs/5tgUAA==/","_etag":"\"0000c505-0000-0d00-0000-677997ed0000\"","_colls":"colls/","_users":"users/","_ts":1736021997},{"id":"ToDoList","_rid":"YCE6AA==","_self":"dbs/YCE6AA==/","_etag":"\"0000bf05-0000-0d00-0000-677997930000\"","_colls":"colls/","_users":"users/","_ts":1736021907}],"_count":2}\

Sample operation 2: Get List of Containers for specific Database

For this REST No-SQL query adapter provides all Containers for the give CosmosDB (below snippet is reduced for the purpose of the blog).

{
	"_rid": "5tgUAA==",
	"DocumentCollections": [
		{
			"id": "Products2",
			"indexingPolicy": {
				"indexingMode": "consistent",
				"automatic": true,
				"includedPaths": [
					{
						"path": "/*"
					}
				],
				"excludedPaths": [
					{
						"path": "/\"_etag\"/?"
					}
				]
			},
			"partitionKey": {
				"paths": [
					"/id"
				],
				"kind": "Hash",
				"version": 2
			},
			"uniqueKeyPolicy": {
				"uniqueKeys": []
			},
			"conflictResolutionPolicy": {
				"mode": "LastWriterWins",
				"conflictResolutionPath": "/_ts",
				"conflictResolutionProcedure": ""
			},
			"geospatialConfig": {
				"type": "Geography"
			},
			"fullTextPolicy": {
				"defaultLanguage": "en-US",
				"fullTextPaths": []
			},
			"_rid": "5tgUAL2JYlI=",
			"_ts": 1736025012,
			"_self": "dbs/5tgUAA==/colls/5tgUAL2JYlI=/",
			"_etag": "\"0000d305-0000-0d00-0000-6779a3b40000\"",
			"_docs": "docs/",
			"_sprocs": "sprocs/",
			"_triggers": "triggers/",
			"_udfs": "udfs/",
			"_conflicts": "conflicts/",
			"computedProperties": []
		}
	],
	"_count": 2
}

Sample operation 3: Get List of Documents from specific Container

For this REST No-SQL query adapter provides all Documents for the given Container and Database (the snippet is reduced for the blog).

{
	"_rid": "5tgUAPPYRnQ=",
	"Documents": [
		{
			"unitPrice": 13,
			"unitsInStock": 32,
			"reorderLevel": 15,
			"supplierId": 12,
			"name": "Original Frankfurter grüne Soße",
			"ProductID": 77,
			"id": "985cfdf8-43f7-4fe9-a10a-34adbab8b50a",
			"quantityPerUnit": "12 boxes",
			"discontinued": false,
			"categoryId": 2,
			"unitsOnOrder": 0,
			"_rid": "5tgUAPPYRnTnAAAAAAAAAA==",
			"_self": "dbs/5tgUAA==/colls/5tgUAPPYRnQ=/docs/5tgUAPPYRnTnAAAAAAAAAA==/",
			"_etag": "\"9a01b953-0000-0d00-0000-677ae3130000\"",
			"_attachments": "attachments/",
			"_ts": 1736106771
		}
	],
	"_count": 1
}

One limitation I noticed is the inability to externalize certain configuration options in the adapter. These fields must be configured directly in the iFlow, requiring a redeployment whenever changes are made. It would be beneficial to allow these options to be modified through externalized parameters in future releases.

Summary

This blog showcases the integration of SAP Integration Suite's Azure CosmosDB receiver adapter with a practical demo scenario. It demonstrates how to pull product data from the Northwind API, transform it using Groovy scripting, and store it in Azure CosmosDB with Bulk processing. Key features of the adapter, such as CRUD operations and schema-agnostic capabilities, were explored alongside important considerations like error handling and Partition Key usage. Readers will gain insights into setting up seamless integrations for modern, hybrid-cloud applications.

Thanks for attention! Hope you enjoyed and will have fun with new Azure CosmosDB receiver adapter.

Piotr

Migration Checklist: SAP PO to SAP Integration Suite, Cloud Integration

2025-01-06T11:16:26.891000+01:00

Dear SAP community,

There is a lot of information available already regarding the move from SAP PO to CPI, please find a collection of links in our blog Integration Excellence: https://www.integration-excellence.com/migration-checklist-sap-po-to-sap-integration-suite/

The following areas are covered:

Preparing Questions
SAP Backend (ABAP) Integration
Interface Design
Security
Operations

Please leave a comment if I might have missed major aspects!

Accrual Posting Made Simple with SAP Enterprise Service Management (ESM)

2025-01-06T16:49:02.772000+01:00

Efficient employee case management is a cornerstone of modern HR and service operations. By integrating SAP Enterprise Service Management (ESM) with SAP WorkZone, organizations can offer employees a seamless self-service experience, empowering them to address their needs while improving operational efficiency.

This blog outlines the process flow for managing employee cases within the ESM-WorkZone integration, detailing each step from case creation to resolution and closure.

Scenario Overview

In today's dynamic business environment, services often span multiple accounting periods, requiring precise accrual postings to maintain financial accuracy. Consider a scenario where:

Service cases are created in SAP Service Cloud (V2).
Financial transactions, like accrual postings, are automated and processed in SAP S/4HANA.

SAP ESM facilitates this seamless flow, automating calculations, postings, and reconciliations to save time and reduce errors.

Technical Architecture

The integration involves:

SAP Service Cloud (V2): Manages service cases and initiates accrual requests.
SAP Integration Suite: Facilitates real-time data transfer between systems.
SAP S/4HANA: Processes accrual postings and reconciliations.

Below is a high-level architecture diagram:

Service Cloud V2 → Integration Suite → S/4HANA

Key Features of the ESM-WorkZone Integration

Centralized Access:
- The ESM Self-Service Portal is embedded within SAP WorkZone under the Employee Self-Service (ESS) page.
Knowledge Base Access:
- Employees can optionally search Knowledge Base (KB) articles for relevant information before creating a case.
Structured Attachments:
- The system enforces consistent structure for attachments and forms, ensuring all required information is included with the case.
Streamlined Case Creation:
- Employees can create cases using a pre-configured JE form, making the process intuitive and efficient.

Employee Case Management Process

Case Creation: Once employees log into the WorkZone ESS page.The company accountant seamlessly initiates an accrual posting request through the Employee Self-Service widget on the SAP Build Work Zone portal, ensuring all essential details are accurately captured and submitted with ease.

Once an Accountant submits an accrual posting request, the Finance Support Agent receives an instant real-time alert about the new case assignment. This streamlined notification system ensures quick access to the case and enables efficient management, allowing finance teams to respond promptly and maintain smooth operational workflows.

The Finance Support Agent carefully examines the details of each newly created case, reviewing key aspects such as case type, employee information, and categorization. This thorough assessment ensures accurate classification, enabling swift and efficient resolution.

Leveraging advanced AI capabilities, Finance Support Agents can now access dynamically generated summaries that consolidate essential case details. These intelligent summaries provide a clear, concise overview of critical information, empowering agents to make faster, more informed decisions and deliver efficient resolutions.

The Finance Support Agent meticulously reviews the Case Form to ensure all details are accurate and complete. Once verified, they seamlessly process and post the data as a journal entry in SAP S/4HANA, maintaining precise and efficient financial records. This streamlined workflow not only upholds data integrity but also enhances overall operational efficiency in financial management.

Once the journal entry is posted, the Finance Support Agent accesses the SAP S/4HANA Journal Entry interface to review and validate the recorded details. This crucial step ensures the accuracy of the data and allows for the swift identification and resolution of any discrepancies.

When a Journal Entry is posted, the system seamlessly updates the case status to "Completed." This automation streamlines case management, ensuring efficient workflows and accurate case closures.

Benefits of ESM-WorkZone Integration

Enhanced Employee Experience:
- By centralizing access and enabling self-service capabilities, employees can address their concerns without unnecessary delays.
Operational Efficiency:
- Automation of accrual postings and structured case management reduces manual errors and administrative overhead.
Knowledge Empowerment:
- Access to the Knowledge Base empowers employees to find answers independently, reducing case volume.
Comprehensive Case Visibility:
- Integration with SAP WorkZone ensures that employees and agents can track case status in real time.
Compliance and Accuracy:
- Seamless posting to SAP S/4HANA ensures financial accuracy and compliance with organizational policies.

Real-World Application

Consider an employee needing reimbursement for an approved expense:

The employee logs into WorkZone ESS, searches for relevant KB articles, and submits the JE form with supporting documents.
The case is created in ESM, capturing all necessary details.
HR agents review the case, validate the attachments, and post the accrual to SAP S/4HANA.
The case status is updated in WorkZone, and the employee is notified of the resolution.

This streamlined process ensures transparency, efficiency, and employee satisfaction.

Conclusion

Integrating SAP ESM with WorkZone simplifies employee case management by providing a unified platform for case creation, tracking, and resolution. Whether it’s troubleshooting common issues, posting accruals, or closing cases, this integration ensures that both employees and HR teams have the tools they need for efficient service delivery.

Ready to transform your employee service operations? Start leveraging the power of SAP ESM and WorkZone today!

How to send Email Notifications only on the Last Retry Attempt in SAP CI/IS when using AEM

2025-01-07T20:29:44.570000+01:00

Introduction:

In SAP Cloud Platform Integration (CPI) or Integration Suite, handling retries effectively is crucial for ensuring smooth and reliable message processing. One common requirement in integration scenarios is sending email notifications only when a certain condition is met- such as after the last retry attempt. This helps in reducing notification overload while ensuring that stakeholders are only alerted when necessary.

When using the Advanced Event Mesh (AEM) Sender, you can leverage event driven communication to handle retries in a more controlled manner. In this blog, we will explore how to configure SAP CPI to send email notifications only after the final retry attempt, using the AEM Sender adapter. This solution not only streamlines the notification process but also ensures that notifications are sent only when the retry attempts have been exhausted, making the system more efficient and less intrusive.

Use Case Overview:

In this use case, we will demonstrate how to configure an integration flow using the Advanced Event Mesh (AEM) Sender to consume messages from a queue. The primary goal is to handle retry logic in such a way that an email alert is sent only after the final retry attempt is reached, ensuring notifications are triggered only when necessary.

Integration Flow:

Below is a sample Integration Flow created to route email alert only on the last retry attempt.

Important note: Make sure to use * in the Allowed headers as shown, to ensure that the full set of headers is received from the AEM sender.

Now, let's discuss the basic configuration.

For guidance on configuring the AEM sender channel, refer to SAP help or other relevant blogs. In this example, we have set the Maximum Message Processing Attempts to 3, and our goal is to send an alert only on the third (final) retry attempt.

This is achieved by using the "LocalProcessingAttempt" header, which is dynamically set during runtime based on the number of attempts. Initially, the AEM sender sets this header to 1 as shown below, and it increments with each subsequent retry.

In the local sub-process, we use a router to define the routing condition as ${header.LocalProcessingAttempt} > '2'. This means that once the attempt exceeds 2, the flow will follow the path where the email receiver is configured.

Note: To make the retry attempt dynamic, you can substitute the value 2 with a property that we can set in a content modifier before router.

Conclusion:

With the use of the "LocalProcessingAttempt" header and routing conditions, you can tailor the retry logic to suit specific business needs and enhance the overall efficiency of your integration processes.By configuring the integration flow to send email alerts only on the final retry attempt, you can significantly reduce unnecessary notifications and focus attention on the most critical events. This method provides better control over communication in your SAP CPI environment, ensuring that stakeholders are only alerted when all retry options have been exhausted.

XML to CSV conversion in integration

2025-01-08T05:46:53.985000+01:00

In SAP Process Orchestration, 'content conversion' processes XML level 3 elements into CSV format. Note, the fieldNames do not influence the output CSV.

Conversely, in SAP Cloud Integration, the 'CSV to XML converter' generates CSV using the element names from the first record of the input XML. If a new element appears in subsequent records, it will be appended at the end of the line.

This difference in behavior can create challenges in migration projects. For PO interfaces with optional elements, fewer CSV columns are produced, whereas CPI interfaces will append optional fields at the end of the line. To manage these issues, you can use additional message mapping with a one-to-one mapWithDefault, although this will create columns even for optional elements. Another option is to use a Groovy script to create consistent elements (e.g., field1, field2, field3, and so on). Below is an example Groovy script:

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

def Message processData(Message message) {
    def stringWriter = new StringWriter()
    def xmlBuilder = new MarkupBuilder(stringWriter)
    def inputXml = new XmlSlurper().parseText(message.getBody(String))

    xmlBuilder.Root {
        inputXml.Record.each { record ->
            Record {
                record.children().eachWithIndex { element, index ->
                    "field${index + 1}"(element.text())
                }
            }
        }
    }

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

You can use a Content Modifier after the 'XML to CSV Converter' if you want to prefix the header with actual field names instead of generic names like field1, field2, field3.

SAP Help Links:-

SAP PO - Converting File Content in a Sender Adapter

SAP Cloud Integration - Configure XML to CSV Converter - "When optional fields exists in the XML, the ordering is maintained in the order when a tag is encountered."

How to Convert from HTML to PDF in SAP CPI - Part I

2025-01-08T10:07:23.211000+01:00

Overview

In this guide, I will detail the process of generating a PDF document by converting HTML content on SAP Cloud Platform Integration (CPI). The use case involves the following steps:

Fetch Terminated Employee Data: Retrieve data for terminated employees from SAP SuccessFactors.
Use a Document Template: Leverage an HTML document template built in SuccessFactors.
Replace Placeholders: Populate the template with dynamic data specific to each employee.
Generate a PDF File: Convert the populated HTML to a PDF document.
Send PDF via Email: Attach the generated PDF to an email and send it to the terminated employee.

Considerations for PDF Generation

After researching available libraries, two primary solutions were identified:

iText's Html2Pdf:

Some licensing limitations.
Preferred for cases requiring advanced formatting and multilingual text (e.g., English and Arabic).
Reference: SpringHow - iText PDF.

OpenHtml2Pdf:

Complex implementation.
No apparent licensing limitations.
Reference: OpenHtml2Pdf Integration Guide.

Given the need to support bilingual text (English and Arabic) with specific fonts, iText's Html2Pdf was selected for this implementation. I will present an implementation with OpenHtml2Pdf on a second article.

Data Requirements

The HTML template is populated using the following dynamic fields:

Employee Name (English and Arabic)
Nationality (English and Arabic)
Employee ID
Job Title (English and Arabic)
Job Start and End Dates
Company Name (English and Arabic)
Company Logo, Footer, and Stamp
Employee’s Personal Email Address

Fetching Employee Data

Data is retrieved from the EmpEmploymentTermination entity in SuccessFactors using a GET request. Key paths include:

Field	Path
Full Name (English)	/EmpEmploymentTermination/personNav/PerPerson/personalInfoNav/PerPersonal/firstName
Full Name (Arabic)	/EmpEmploymentTermination/personNav/PerPerson/personalInfoNav/PerPersonal/firstNameAlt1
Nationality	has a custom path
Nationality Arabic	has a custom path
Employee ID	/EmpEmploymentTermination/userId
Job Title (English)	/EmpEmploymentTermination/jobInfoNav/EmpJob/positionNav/Position/externalName_en_GB
Job Title (Arabic)	/EmpEmploymentTermination/jobInfoNav/EmpJob/positionNav/Position/externalName_ar_SA
Personal Email	/EmpEmploymentTermination/EmpEmploymentTermination/personNav/PerPerson/emailNav/PerEmail - emailAddress and filter by emailType (check the corresponding optionId to the Personal type on object definition)
Job Start Date	/EmpEmploymentTermination/EmpEmploymentTermination/jobInfoNav/EmpJob/hireDate
Job End Date	/EmpEmploymentTermination/EmpEmploymentTermination/endDate
Company Name (English)	/EmpEmploymentTermination/EmpEmploymentTermination/jobInfoNav/EmpJob/companyNav/FOCompany/name_en_GB
Company Name (Arabic)	/EmpEmploymentTermination/EmpEmploymentTermination/jobInfoNav/EmpJob/companyNav/FOCompany/name_ar_SA
Company Code	/EmpEmploymentTermination/EmpEmploymentTermination/jobInfoNav/EmpJob/companyNav/FOCompany/externalCode

Note: Ensure that filters for termination codes and dates are properly defined to fetch relevant records. The query should include parameters such as TerminationCode, CurrentRunDate, and PreviousRunDate.

Implementation in SAP CPI

The process is divided into three main components:

1. Main Process

Main Process

Timer Configuration:

Scheduled based on client preferences. For manual runs, use the "Run Once" option.

Define Parameters:

Define Initial Parameters

Set external parameters such as personIdExternal, TerminationCode, and PreviousRunDate_Ext for filtering and query building.

Query Builder:

Using script to determine the “PreviousRunDate” value, used for a delta logic.
personIdExternal externalized parameter used for extra optional personIdExternal filter, built in the script.

import com.sap.gateway.ip.core.customdev.util.Message
import java.util.HashMap;
import java.text.DateFormat;
import java.text.SimpleDateFormat;
import java.util.Date;

def Message buildQuery(Message message) {
    
    prop = message.getProperties();
    head = message.getHeaders();
    StringBuffer debugLog = new StringBuffer();
    String modDate="";
    Date today = new Date();
    DateFormat dateFormat= new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssZ");
    String todayInString = dateFormat.format(today);
    String personIdExternal = prop.get('personIdExternal');
    
    // use fixed RunDate as the initial delta timestamp
    if(!(prop.get("PreviousRunDate_Ext").trim().isEmpty()))
    {
        modDate = prop.get("PreviousRunDate_Ext");
        message.setProperty("PreviousRunDatePersisted_Value",modDate);
    }
    
    // use previously persisted RunDate as the initial delta timestamp
    else if(!(prop.get("PreviousRunDate").trim().isEmpty()))
    {
        modDate = prop.get("PreviousRunDate");
        message.setProperty("PreviousRunDatePersisted_Value",modDate);
    }

    // use the CurrentDate as the initial delta timestamp
    else
    {
        modDate=todayInString;
        message.setProperty("PreviousRunDatePersisted_Value",modDate);
    }
        
    message.setProperty("PreviousRunDate", modDate);
    
    // create extra query parameter for a fixed employee id
    if(!(personIdExternal.trim().isEmpty())){
        message.setProperty("personIdExternalQuery", " and personIdExternal eq '"+personIdExternal + "'");
    }else{
        message.setProperty("personIdExternalQuery", "");
    }
    return message;}

Get Terminated Employees
Splitter

Split by XPath expression “/EmpEmploymentTermination/ EmpEmploymentTermination/”

Process each employee record individually

2. Get Terminated Employees

Get Terminated Employees

Use query builder to choose the needed fields (mentioned previously)

Use "Custom Query Options" to define filters such as:

$filter=jobInfoNav/eventNav/externalCode eq '${property.TerminationCode}' and lastModifiedOn le datetime'${property.CurrentRunDate}' and lastModifiedOn ge datetime'${property.PreviousRunDate}' ${property.personIdExternalQuery}

Ensure proper handling of delta requests to fetch updated records.

3. Handle Each Employee

Handle Each Employee

Message Mapping:

Transform data into a simple XML structure for debugging and processing.

Message Mapping to Simple Structure

Assign specific logos, footers, and stamps to each company code using a Value Mapping.

Value Mapping operation in Message Mapping

Value Mapping from Company Code

Build PDF Text:

Populate the HTML template with employee-specific details.
Ensure correct URL paths for logos and stamps.
See the cpi_anonymized.txt attachment for an example of HTML content being used in SAP CPI.

PDF Generation

import com.sap.gateway.ip.core.customdev.util.Message
import org.apache.camel.impl.DefaultAttachment
import javax.mail.util.ByteArrayDataSource
import javax.activation.DataHandler
import javax.activation.DataSource
import javax.activation.FileDataSource
import javax.mail.util.ByteArrayDataSource
import java.io.ByteArrayOutputStream
import com.itextpdf.html2pdf.HtmlConverter
import com.itextpdf.html2pdf.ConverterProperties
import com.itextpdf.layout.font.FontProvider
import com.itextpdf.html2pdf.resolver.font.DefaultFontProvider

def Message convertHtmlToPdf(Message message) {
    // Get HTML Body
    String htmlContent = message.getBody(String.class);
    OutputStream pdfOutput = new ByteArrayOutputStream();

    FontProvider fontProvider = new DefaultFontProvider(true, true, true);
    ConverterProperties properties = new ConverterProperties();
    properties.setCharset("UTF-8");
    properties.setFontProvider(fontProvider);
    
    // Convert from HTML to pdf (in byte array format)
    HtmlConverter.convertToPdf(htmlContent, pdfOutput, properties);
    
    // Close the OutputStream if it's no longer needed
    pdfOutput.close()
    
    // Convert OutputStream to byte array
    byte[] pdfBytes = pdfOutput.toByteArray()
    
    // Create a DataSource from the byte array
    DataSource dataSource = new ByteArrayDataSource(pdfBytes, "application/pdf")
    
    // Create a DataHandler from the DataSource
    DataHandler dataHandler = new DataHandler(dataSource)
    
    // Construct a DefaultAttachment object
    def attachment = new DefaultAttachment(dataHandler);

    // Attach the document
    message.addAttachmentObject("Attachment.pdf", attachment);
    
    return message;
}

HTML to PDF Conversion:

Use OutputStream to write data to a destination.
Use HTML Converter to convert our HTML content to pdf.
Specify properties such as FontProvider to keep the correct format of the document.
Construct a DefaultAttachment object using the ByteArrayDataSource fed with the pdfOutput’s byte array. This object encapsulates the attachment data and is ready to be added to the email with addAttachmentObject();

Adding External Libraries

Before executing the iFlow, it is essential to include the required external libraries in the project references. The primary library for HTML-to-PDF conversion, such as html2pdf, has several dependencies that must also be included.

Needed iText Libraries

These libraries can be downloaded from Maven repositories, such as:

Maven Repository for iText PDF.

Important Considerations:

While the html2pdf library is available for free, its usage is subject to specific licensing conditions. Ensure that you review and comply with these terms before implementation.
OpenHtml2Pdf requires a more complex implementation, but it may be a good choice due to no apparent licensing limitations.

Final Notes

While this implementation meets the requirements, it is not an ideal architectural solution. A more robust approach would involve:

Using SAP CPI for data retrieval and HTML preparation.
Delegating PDF generation and email dispatch to an API, such as SAP Forms Service by Adobe:
- SAP Forms Service by Adobe REST API | SAP Help Portal

We did not go with this approach due to restraints that were placed by the customer itself and some lack of experience with SAP Forms API.

This approach reduces dependency on external libraries and aligns with best practices in enterprise architecture.

Ensure compliance with licensing terms for any third-party libraries used.

Leveraging SAP Integration Suite for Salesforce extraction into SAP BW/4HANA

2025-01-10T12:34:21.027000+01:00

*This article has been collaboratively created with Frank Riesner .

Dear BW enthusiasts!
There have been several contributions covering the ADSO write-interface already, like
Data Integration with SAP BW/4HANA
SAP Cloud Integration into SAP BW/4HANA
SAP BW/4HANA write interface-enabled ADSO connected to a 3rd Party Tool
SAP Cloud Platform Integration (CPI) to push data into SAP BW/4HANA

There are various approaches to connect Salesfore as a source with the aforementioned write-interface of SAP BW/4HANA:

Via SAP HANA Smart Data Integration and its OData Adapter.
(SAP Note: 2776343 describes the approach and same Interface for SAP SuccessFactors. However is is a useful source to understand the general approach for 3rd Party Products like Salesforce as well regarding the interface towards BW)
Via SAP Data Services and its Salesforce Adapter or the generic OData Adapter.
Via SAP BTP Integration Suite and the Salesforce Adapter
(SAP Help, SAP Note: 3001980 and this Blog provide a more general overview under the aspect of "Non-SAP Integration - New Version of Adapters and Integration Packs)

In this Blog, we dive deep into approach (3) based on the SAP BTP Integration Suite. The intention is to give you a detailed approach for the specific use case to load data from Salesforce to SAP BW/4HANA.

Prerequisites:

In SAP BW/4HANA system there is an DataStore object (ADSO) available with the special property “Write Interface enabled". After activation of this new ADSO, template URIs (Uniform Resource Identifiers) are generated in the Properties window by default. These provide the target interface for our scenario. For more details refer to the SAP Help ADSO modeling properties (note: This feature is not available in BW 7.5).
In SAP Integration Suite the Salesforce Adapter has been activated and is available.
Credentials and Access Tokens for Salesforce and BW has been generated.

The target interface in SAP BW/4HANA is represented by following URIs:
In this table below, the ADSO technical name is represented by term "ZADSO". In the illustrations our template ADSO is called "zc8sfop01".

Description	HTTP Method	URL	Illustration
Get all ADSOs and Request XCSRF-Token	GET	https://server:8443/sap/bw4/v1/push/dataStores/
Get structure and meta data of specific ADSO (here called "ZADSO")	GET	https://server:8443/sap/bw4/v1/push/dataStores/zadso
Get sample Data e.g. 10 examples	GET	https://server:8443/sap/bw4/v1/push/dataStores/zadso/sampleData?records=10&seed=0
Send Data without TSN	POST	https://server:8443/sap/bw4/v1/push/dataStores/zadso/dataSend
Create New TSN request (Transaction Sequence Number)	POST	https://server:8443/sap/bw4/v1/push/dataStores/zadso/requests
Send Data with TSN	POST	https://server:8443/sap/bw4/v1/push/dataStores/zadso/dataSend?request=[tsn]&datapid=[dynamic starting at 1 + n]
Close Request for specific TSN	POST	https://server:8443/sap/bw4/v1/push/dataStores/zc8sfop01/requests/[tsn]/close

High level solution approach in BTP Integration Suite:

Recover the timestamp of the last run (in our case the data load runs once a day).
Perform a SOQL (Salesforce Object query language) query to Salesforce, including the timestamp of the last run, to collect all new entries.
Check for the new entries; otherwise cancel further processing.
Perform a GET to fetch the X-CSRF-Token. Then save the token and cookies.
Perform a POST to request a new TSN for data transfer. Save this TSN.
Perform message mapping with Groovy script from Salesforce result to SAP BW/4HANA target structure.
Perform a POST with SAP BW/4HANA payload (i.e. the data you sent via BTP), including TSN in the URL.
Perform a POST to close the related TSN request.
If successful, save the new timestamp of the last run.
The remaining processing is all controlled by SAP BW/4HANA standard means.

Design Time details in BTP Integration Suite

Step	Illustration
Main Flow Remember last execution of data load and last TSN ID Get Content from Salesforce Get X-CSRF-Token Send data to SAP BW/4HANA
Get source data from Salesforce Data Load from Salesforce with SOQL Query
Get Token Request X-CSRF-Token with Fetch Call: ADSO URL with header details containing X-CSRF-TOKEN Get/set cookies from: ${header.set-cookie}
Send Data to BW Request TSN (see first table) Prepare data load with Groovy-Script and set content type to JSON Send data including TSN (see first table) Close TSN request (see first table)
Define Groovy Script Hint: Due to the example payload which contains all content – it was easy to generate the Groovy script and field mapping with support of SAP Joule.

Runtime details in BTP Integration Suite

Step	Illustration
Get Request TSN
Send Request including TSN
Close Request
Result in SAP BW/4HANA	to be updated later...

Conclusion:

When data is posted into SAP BW/4HANA, it can be processed by Streaming Process chains automatically. See details in this blog post , and there part D.
For integration approaches of other cloud sources (mainly SAP) please refer to this blog post .
Use of AI to generate the mapping makes development easier and much faster - not only for this use case but in general!
A good documentation of API’s allows an improved speed of development. This blog post should provide exactly this.
This blog post will be updated when we learn more about delta-capability and performance in our dedicated scenario. We are just working on it, and we will keep you updated.
An Event-driven approach could be an option, if the business requires data in real time.

*Many thanks to Alexandros, Jingjiee and Christopher for their contribution.

Optimizing SuccessFactors OData Calls Using Looping Process Call

2025-01-12T12:30:23.271000+01:00

Imagine you need to retrieve details for 1600 users from SuccessFactors. If we were to retrieve each user's information one at a time, we will hit SuccessFactors with 1600 requests.
/odata/v2/User?$filter=userId eq '1234'

This approach is inefficient, puts a strain on the SuccessFactors server, and risks exceeding the daily request limit.

We can make this process more efficient by retrieving multiple users in a single call:
/odata/v2/User?$filter=userId in '1234','1235'

However, the maximum number of expressions in the "in" clause of the $filter query option is 1000. In my testing, I found that it allows only 500 values. SAP Help Link. By retrieving 500 users at a time, we can significantly reduce the number of calls to SuccessFactors.

Here's a sample interface:

Content Modifier: This step contains the list of Employee IDs. In your case, it can be any step from which you get the filter list.

Looping Process Call: This process continues until the condition ${property.p_StopLoop} != 'Stop' is met.

Call SuccessFactors: This local integration process includes a 'Build Filter Query' Groovy script that generates the filter query. Using CamelLoopIndex and filterSize, it builds queries to fetch details in groups of 500 users. For instance, the first loop retrieves the first 500 users, the second loop fetches the next 500, and so on. You can externalize the filterSize to configure the number of records retrieved in each call.

import com.sap.gateway.ip.core.customdev.util.Message
// Build query $filter=userId in '1234','1235' and so on.
def Message processData(Message message) {
    int camelLoopIndex = message.getProperty('CamelLoopIndex')
    String empIds = message.getProperty('p_EmpIds')

    def filterSize = 500
    def idsArray = empIds.split(',')
    int start = Math.min(camelLoopIndex * filterSize, idsArray.length)
    int end = Math.min(start + filterSize, idsArray.length)
    
    def partOfEmpIds = idsArray[start..<end].collect { "'${it}'" }.join(',')
    String filter = new StringBuilder("\$filter=userId in ${partOfEmpIds}")
    message.setProperty('p_FilterQuery', filter)
    
    if(partOfEmpIds.isEmpty()){
        message.setProperty('p_StopLoop', 'Stop')
    }

    return message
}

SuccessFactors Adapter:
Operation Detials: Query (GET)
Resource Path: User
Query Options: ${property.p_FilterQuery}

Router: This component avoids calling SuccessFactors when the end of the list is reached (since 'Looping Process Call' is a do-while loop, it runs until the condition is true).

Remove XML Declaration: This step removes the <?xml version="1.0" encoding="UTF-8"?> declaration from each SuccessFactors response.

Set Lookup Result Property: This step appends the SuccessFactors response to the previous response using ${property.p_LookupResult} ${in.body}.

Get LookupResult Property: In the main integration process, this step builds the combined SuccessFactors response:
<ROOT>
${property.p_LookupResult}
</ROOT>

Move Records to Root: Using XSLT, we can move all records to single level in XML.

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="3.0">
	<xsl:output method="xml" indent="yes"/>
	<xsl:template match="/">
		<ROOT>
			<xsl:for-each select="/ROOT/User/User">
				<xsl:copy-of select="."/>
			</xsl:for-each>
		</ROOT>
	</xsl:template>
</xsl:stylesheet>

Please note, while this approach will reduce the number of calls to SuccessFactors, it may introduce complexity in downstream transformations if further work on the XML response is needed.

Creating Customer in SAP S/4 HANA Public Cloud via OData

2025-01-17T09:08:38.073000+01:00

Let's see how to create Business Partner as Customer in SAP S/4 HANA Public Cloud via HTTP adapter in SAP Cloud Integration.

SAP provides RESTful API (A2X), which is available at the Business Accelerator Hub.

From the environment of SAP Cloud Integration, we have actually two options - we can use OData adapter or HTTP adapter. When in decision about which one to choose, this blog can help you. I wanted to have more flexibility over the entire process and hence I will be describing the use of HTTP adapter. It requires more work, but provides you with higher level of control.

The structure of SAP S/4 APIs can be sometimes confusing, as it doesn't always follow a consistent logic. Sometimes you are referring to Business partner in the query, sometimes in the payload. Sometimes an object has its own API, sometimes you use an extension of another object's API. No worry, we will clarify this.

X-CSRF-TOKEN

The first obstacle you face using HTTP adapter is the handling of authentication against the SAP S/4. As creating a Business Partner is a POST operation, you need higher privileges then when using GET query. And that is why we need to get x-csrf-token first.

To achieve this, we need to set a request to this service:
/sap/opu/odata/sap/API_BUSINESS_PARTNER/A_BusinessPartner
We run this request in Request-Reply component with HTTP adapter:

HTTP method I select HEAD, as we are not sending any content, neither we are asking for data. So to minimize the exchange overhead, I think HEAD is the most economic method for this kind of call.

The asterisks in Request Headers and Response Headers ensure that the headers will be exchanged and that we will receive all the headers we need.

You may be wondering why we are calling the /A_BusinessPartner service, when we want to get the token. The reason is that we should be calling the same service which we will call to actually create the Customer later.

Right before the Request-Reply component we need to place a Content Modifier with this header: x-csrf-token = Fetch

And one more thing - click anywhere in the canvas to enter the Integration Flow config, go to Runtime Configuration and set HTTP Session Reuse. This will assure that token is reused for any other subsequent call.

The iflow section which handles the token can look like this
After we run the iflow, the service will be called and we will receive the token and cookie in the response header. We don't need to extract them or handle them before calling the service to create Business Partner.

What we can do is to handle the http response. I chose a router, which routes the '200' response to positive scenario and any other response code to error handling subprocess.

CREATE BUSINESS PARTNER

Now let's go to create the Business Partner entity, which we will extend later to Customer.

We will be again calling the service:
/sap/opu/odata/sap/API_BUSINESS_PARTNER/A_BusinessPartner
Now we use the POST method, as we are sending data to SAP S/4.
Place a Content Modifier before the Request-Reply with content-type = application/json, as seen at the screenshot above. Like this we are telling the server what format we are sending.
The body has to be in json and have following format and syntax. We can set up a Business Partner with such as simple payload as this:

{
"BusinessPartnerCategory": "1",
"FirstName": "John",
"LastName": "Smith"
}

BusinessPartnerCategory decides whether the Business Partner will be Person (1), Organization (2) or Group (3).
More sophisticated payload to create an Organization can look like this:

{
  "BusinessPartnerCategory": "2",
  "OrganizationBPName1": "ACME CORP",
  "CorrespondenceLanguage": "EN",
  "SearchTerm1": "ACME",
  "to_BusinessPartnerAddress": [
    {
      "to_MobilePhoneNumber": [
        {
          "PhoneNumber": "111222111"
        }
      ],
      "to_EmailAddress": [
        {
          "EmailAddress": "acme@email.com"
        }
      ],
      "StreetName": "Long Street",
      "HouseNumber": "25",
      "Country": "GB",
      "PostalCode": "11111",
      "CityName": "London",
      "Language": "EN"
    }
  ]
}

Notice that we are using 'to_' prefixes for object extensions to be able to create Business Partner with address, email and telephone number. When we run the POST query, SAP will provide us with an XML response, which carries information about the newly created Business Partner.
As we will need the Business Partner number further in our iflow, we can extract the number via this XPath statement in Content Modifier:
//*[local-name()='properties']/*[local-name()='BusinessPartner']

We extracted the Business Partner number into a Property.

ASSIGN CUSTOMER ROLES

To extend our Business Partner to Customer, we need to assign it customer roles. We do this via another API.

URL: /sap/opu/odata/SAP/API_BUSINESS_PARTNER/A_BusinessPartnerRole
Method: POST
Headers: Content-type = application/json
Sample body:

{
      "BusinessPartner": "BP number of newly created Business partner",
      "BusinessPartnerRole": "FLCU00"
}

The same call we use to assign any other role (like FLCU01), just modify the value in body.

CREATE CUSTOMER IN SALES AREA

Now we need to set Sales area data for our Customer.

URL: /sap/opu/odata/SAP/API_BUSINESS_PARTNER/A_Customer('BP number of newly created Business partner')/to_CustomerSalesArea
Method: POST
Headers: Content-type = application/json
Sample body (we are also setting a fixed Payer for demonstration):

{
  "SalesOrganization": "1000",
  "DistributionChannel": "01",
  "Division": "01",
  "CustomerPaymentTerms": "0001",
  "Currency": "USD",
  "to_PartnerFunction": {
    "results": [
      {
        "PartnerFunction": "PY",
        "BPCustomerNumber": "1000001"
      }
    ]
  }
}

CREATE CUSTOMER IN COMPANY CODE

And similarily for Company code data.

URL: /sap/opu/odata/SAP/API_BUSINESS_PARTNER/A_Customer('BP number of newly created Business partner')/to_CustomerCompany
Method: POST
Headers: Content-type = application/json
Sample body:

{
  "CompanyCode": "1000",
  "ReconciliationAccount": "10000000",
  "PaymentTerms": "0001"
}

Our Customer should now be all set for basic business operations.

Notice that SAP responds to our calls in XML format. If for some reason you need to convert it to JSON, use an XML to JSON converter component, or use header Accept = application/json in your query. By that you are telling SAP to provide response in JSON.

SAP Community - Cloud Integration

Updated LJ - Discover the foundations of SAP Commerce Cloud and SAP S/4HANA Cloud Integrations

Please share your experience - new API Management survey

SAP Trading Partner Management - Part III: Partner configuration

Identifiers

Type System

Communications

SAP PI Migration to BTP Integration Suite Patterns and learning experiences

New Pipeline Concept features: more bypass options and custom extensions

Further bypass options

Custom extensions

Non-XML payloads

Processing log

Retry handling

How to Provide Read-only Access to Integration Advisor

Introduction

How to?

Role assignment (CF)

Role assignment (Neo)

Usage of new role

Summary

Which S/4HANA extensibility option is the best for thriving as an SAP partner in the cloud space?

Get more value from S/4HANA with SAP Extensibility options, part 3

SAP Trading Partner Management - Part IV: Agreement

Agreement

B2B Scenarios

Sending a test AS2 message

SAP Cloud Integration : B2B - Restart/Retry Messages - B2B Monitor

How to configure PollEnrich in Cloud Integration

SAP Cloud Identity Services for Beginners

Introduction:

Configure IAS as custom IDP for BTP Subaccount using

OIDC

Step 1:

Step 2:

Step 3:

Step 4:

Step 5:

Step 6:

Step 7:

Provision users from FSM to IAS using IPS

Step 1:

Step 2:

Step 3:

Step 4:

Reference Links:

Step into the Future of Integration: Using Azure CosmosDB Receiver Adapter in SAP Integration Suite

Background

What is Azure CosmosDB?

Features of Azure CosmosDB Receiver Adapter on SAP Cloud Integration

Prerequisites and Initial Setup

Demo Scenario

Main iFlow steps:

Demo execution

Result

Other operations

Summary

Migration Checklist: SAP PO to SAP Integration Suite, Cloud Integration

Accrual Posting Made Simple with SAP Enterprise Service Management (ESM)

Scenario Overview

Technical Architecture

Key Features of the ESM-WorkZone Integration

Employee Case Management Process

Benefits of ESM-WorkZone Integration

Real-World Application

Conclusion

How to send Email Notifications only on the Last Retry Attempt in SAP CI/IS when using AEM

Introduction:

Use Case Overview:

Integration Flow:

Conclusion:

XML to CSV conversion in integration

How to Convert from HTML to PDF in SAP CPI - Part I

Implementation in SAP CPI

1. Main Process

2. Get Terminated Employees

3. Handle Each Employee

Leveraging SAP Integration Suite for Salesforce extraction into SAP BW/4HANA

Prerequisites:

The target interface in SAP BW/4HANA is represented by following URIs:In this table below, the ADSO technical name is represented by term "ZADSO". In the illustrations our template ADSO is called "zc8sfop01".

The target interface in SAP BW/4HANA is represented by following URIs:
In this table below, the ADSO technical name is represented by term "ZADSO". In the illustrations our template ADSO is called "zc8sfop01".