There are resources out there that explain what AIF is and what it can do, but when you actually start implementing AIF in a project, we noticed that resources on SAP AIF are scarce.

And perhaps one of the biggest challenges we faced during our projects was how do you explain to IT manager, SAP implmentation teams why AIF should be used and how it should fit into the overall integration architecture?

“We faced many of these challenges ourselves while working on different SAP implementation projects.”

So we decided to put what we have learned along the way into one place.

Introducing the SAP AIF Configuration Guide for SAP Consultants

This is a complete guide for SAP consultants who are already working with AIF, want to learn AIF, or are looking to newly implement AIF in their organizations.

We didn’t want to create another guide that only explains the theory.

Our goal was to create something practical that you can actually use when working on an SAP project.

There are currently more than 75 lessons covering different parts of SAP AIF.

And this is not the final version.

This Is a Living Guide

We will be regularly adding new AIF lessons and new topics to the guide.

So if there are areas of AIF that are not covered yet, there is more content coming.

And the important part is that all future lessons will be included for you when you get access now.

Our intention is to keep improving this guide and make it a most useful resource for SAP consultants working with AIF.

Get the eBook!

Who Is This For?

If you are an SAP technical and functional consultant who:

• Is currently working with SAP AIF

• Wants to learn SAP AIF

• Is involved in SAP S/4HANA implementation projects

• Needs to understand how AIF is configured and implemented

• Wants to implment SAP AIF for the first time

• Or is trying to understand where AIF fits into your overall integration architecture

Then this guide is for you.

We have tried to bring together the theory, configuration, implementation steps, practical examples, and lessons we have learned from working with AIF in real projects.

Get life time access!

The SAP AIF Configuration Guide is now available.

If you want to start learning SAP AIF or improve your understanding of how to implement it, you can get access using the link below.

And remember, as we add new lessons to the guide, you will get access to those future lessons as well.

👉 Get access to the SAP AIF Configuration Guide here.

Get the eBook!

What Is an API Proxy?

Let’s start with the concept, because it’s worth slowing down on this before touching the API Portal.

Say your backend is a service sitting at a real, callable address.

For this article, we’ll use a free exchange-rate API at https://open.er-api.com/v6/latest. If you called that URL right now, it would hand you back the latest currency exchange rates.

If we let every client app call that address directly, we have a problem: once a client knows your backend’s real address, you’ve lost control over who can call it, how often they can call it, and what they can do once they’re in.

So instead of exposing the backend itself, we put something in front of it.

That something is called an API proxy.

An API proxy is a facade for your APIs that you build and deploy in SAP API Management. The client app never talks to your actual API backend. It talks to the proxy, and the proxy forwards that call to the real backend on the client’s behalf.

Here’s an analogy for an API Proxy: think of a hotel front desk.

If you want to contact someone staying at the hotel, you never call a guest’s room directly, and you don’t even know the room’s extension number. Instead, every call goes through one number - the hotel’s front desk. You dial the front desk, the person at the desk figures out who you’re trying to reach, and connects you through internally. The guest never has to publish their extension to the outside world, and the hotel can move that guest to a different room tomorrow without anyone outside ever noticing, because the number you dial never changes.

The API proxy is that front desk. The backend system is the guest’s room. The client app is you, calling in from outside.

API Proxy URL vs. Target API URL

This is the part that trips up most people new to SAP APIM, so it’s worth being explicit about it.

🛑 Key distinction

The Target API URL is your backend’s real address - the room extension. The API Proxy URL is a brand new, published address that SAP API Management generates once you deploy the proxy - the front-desk number. Clients only ever call the API Proxy URL.

The Target API URL, in our case, is https://open.er-api.com/v6/latest. This address lives inside the proxy’s target configuration and is never given out to client apps.

The API Proxy URL is generated by SAP API Management once you deploy, something like:

https://3ed7f623trial-trial.integrationsuitetrial-apim.us10.hana.ondemand.com/3ed7f623trial/v1/exchangerates

This is the only address you ever hand to a client. Nobody outside needs to know, or should know, that open.er-api.com exists at all and know that is where the actual exchange rates are extracted.

Why Use the APIM (Proxy) Layer?

Three reasons, each mapping back to the hotel front desk:

• Decoupling. The hotel can move a guest to a different room, or even a different floor, and the number you dial never changes. If you later move your backend, or swap the exchange-rate provider entirely, the client’s API Proxy URL doesn’t change - you just update where the proxy points internally.

• Control. Every call is forced through the front desk - there’s no side door. This is the checkpoint where you attach policies like Verify API Key, Spike Arrest (protection againist bots), and Quota. None of that logic sits on the backend; it all sits at the proxy.

• Transformation. A front desk doesn’t just connect a call - it can take a message and pass it along in a cleaner form. A proxy can reshape the request before it reaches the backend, or reshape the response before it goes back to the client, without the backend ever needing to change.

Every API proxy has two sides: the ProxyEndpoint, which faces the client (the published front-desk number), and the TargetEndpoint, which faces your backend (the real room extension). We’ll go deeper on both of these in a later article - for now, just remember which side does what.

Demo Scenario Overview

For this walkthrough, we’ll wrap the same exchange-rate backend we just discussed:

• Target API URL: https://open.er-api.com/v6/latest

It’s a free, no-auth API, which makes it a good first target. There’s no credential handling to worry about yet, so we can focus entirely on the proxy mechanics.

Step 1: Create the API Proxy

Log in to the SAP API Portal and go to the Configure area. This is where all your API proxies live.

Click Create under the API Proxy tab. A wizard opens asking for some basic details.

Give it a name. Since this proxy wraps the exchange-rate backend, let’s name it exchangerates.

Below the name, set the base path. This is the part of the URL clients will use to reach the proxy once it’s deployed, effectively the front-desk number.

Set the API base path to /exchangerates.

Subscribe now

It is recommended to structure your API resources with a version ID. Therefore, let’s add the version as v1. If the version is configured, the base path of the API proxy will be automatically changed to reflect the version: /v1/exchangerates.

Step 2: Configure the Target Endpoint

Move to the next step, where you configure where the proxy should actually forward requests. Paste in the target URL: https://open.er-api.com/v6/latest.

This is the private room extension, or the backend service URL - the client will never see this address directly

We will select the target type as “URL” since the target API we configure is a pure URL.

Click Create, and you’ll see a summary of everything configured: the name exchangerates, the base path /v1/exchangerates, and the target URL https://open.er-api.com/v6/latest.

Click Save.

At this point, the API proxy has been created but it isn’t live yet. It will be in “Un Deployed” status. Creating the proxy only saves its configuration and proxy URL.

Step 3: Deploy the API Proxy

To make the proxy callable, you need to deploy it.

Click Deploy.

Wait for the deployment to finish. Once the status changes to Deployed, the proxy is live and reachable at its own published URL.

The API Proxy URL for trial accounts will be in this format:

https://<subaccount-id>–trial.integrationsuitetrial-apim.<region>.hana.ondemand.com/<subaccount-id>/<your-API-proxy-base-path>

That’s your front-desk number now. Nobody calling this URL needs to know that open.er-api.com exists behind it.

Testing the API Proxy

Grab the deployed proxy URL and open it in a new browser tab, or trigger it via Postman.

The response comes back with the latest exchange rates, exactly what the backend would have returned if called directly.

Nothing has been added or removed, because no policies have been attached yet. Right now, the proxy is doing exactly one thing: receiving the client’s request and passing it straight through to the backend, then passing the response from the backend straight back to the caller.

Notice the response from the backend you saw before - it should be identical to the proxy response. The same data, same structure, nothing lost in between.

That’s exactly what you want to confirm at this stage, before adding any logic on top.

Now you can add your policies on top of it. We will look at how to add policies in another article.

Tips and Tricks

• Keep the very first version of any proxy a bare pass-through, like we did here, before attaching any policies. It gives you a baseline to compare against once you start adding Verify API Key, Spike Arrest, or transformation policies. If something breaks later, you’ll know it’s the policy, not the underlying proxy configuration.

• Double-check the base path doesn’t collide with an existing proxy on the same environment. Since the base path is what routes incoming calls to the correct proxy, an overlapping path will cause deployment or routing issues.

This bare pass-through proxy is your starting point. In upcoming lessons, we’ll start attaching policies to it, and this is exactly where the ProxyEndpoint and TargetEndpoint structure we introduced above comes into play.

If you have any questions about creating or deploying your first API proxy in SAP API Management, leave a comment on the original post. I’ll be happy to help.

Full online course

Rather watch the lesson in video format?

Cloud Integration with SAP Integration Suite for Beginners — 200+ video lessons, direct support from me if you get stuck, no prior SAP experience needed.

See the full curriculum →

📚 SAP AIF Configuration Series - Guide #3

We are configuring value mappings on top of the iDoc interface we developed in our previous guides.

If you are new here and would like to see the previous articles, check out the following guides.

1. How to configure your first IDoc monitoring interface in AIF.

2. How to Configure Fixed Values in SAP AIF

Value mapping in SAP Application Interface Framework (AIF) is a mechanism used to translate incoming external values into internal SAP-compliant values during message processing.

It’s needed because different source systems often use different coding or naming conventions than SAP. Value mapping ensures that these external representations are converted into the correct internal values, so the data can be processed without errors and remains standardized across interfaces.

Scenario

In this example, let’s assume the external system sends us the passenger (customer) master information with the title as MISTER or MISTRESS.

However, when we create the customer master data, we don’t want to use these external values in the title; instead, we want to save them as Mr. and Mrs.

We’ll create a value mapping for the FORM field in the iDoc.

The external values are converted into standard internal SAP values as follows:

• MISTER → Mr.

• MISTRESS → Mrs.

This ensures that incoming data is normalized during processing, regardless of how the external system represents the salutation.

Step 1 - Define Value Mapping

Transaction: /AIF/CUST -> SAP Application Interface Framework -> Error Handling -> Define Namespace-Specific Features -> Define Structure Mappings -> Define Field Mappings

In Define Structure Mappings -> Define Field Mappings, create a new entry.

Make sure the destination structure is mapped correctly. We created this mapping in the previous example for Fixed Values.

⚠️ Warning

Make sure the interface II_FL_CUST in namespace ZDEMO is already working before you start this step.

The value mapping you’re about to create sits on top of the structure mapping from the Fixed Values chapter, so that needs to be in place first.

Maintain the following values under Define Field Mapping:

• Field in Destination Structure: E1SCU_CRE-E1BPSCUNEW-FORM — the field you’d like to transform

• Field Name 1: E1SCU_CRE-E1BPSCUNEW-FORM — the field you’d like to transform

• Namespace: ZDEMO Value Mapping: VM_FORM — the name of the new value mapping table

💡 Tip

You can select the field from the drop-down.

Since the value mapping doesn’t yet exist, you’ll be prompted to create it.

Confirm the dialog.

Then define the value mapping with the following settings:

• Value Mapping Description: Map customer form (salutation)

• Data Element for INT: S_FORM

• Number of External Values: 1

• Single or Multiple Value Mapping: Single

• Customizing or Master Data: Master Data

💡 Customizing or Master Data?

This controls how and where the mapping values are maintained.

• Master Data - values are maintained at runtime directly in transaction /AIF/VMAP. They’re client-dependent, meaning each client manages its own set of mapping values. Use this when the mapping is likely to change over time or differs between clients (e.g. sandbox vs production).

• Customizing - values are maintained in the IMG and transported like any other Customizing entry. Use this when the mapping is stable and needs to be consistent across all clients through the transport landscape.

For most real-world interfaces, Master Data is the more practical choice because business users or support teams can update the values directly in /AIF/VMAP without needing a transport.

Our AIF eBook with a full collection of these guides is coming soon!

Read more

📚 SAP AIF Configuration Series - Guide #2

We are configuring the fixed values on top of the iDoc interface we developed in AIF previously. If you are new here and like to learn how to configure the namespaces and the iDoc Monitoring basic steps in AIF, check out the linked article first.

Introduction to Fixed Values in SAP AIF

Fixed values in SAP Application Interface Framework (AIF) allow you to assign predefined values to interface fields during message processing. This is particularly useful when a field must always contain a specific value, or when the incoming message doesn’t provide all the mandatory information required by the target application.

Scenario

In this example, we’ll use a fixed value mapping to populate the CUSTTYPE field during inbound IDoc processing. The CUSTTYPE field is mandatory and cannot be left empty. It also only accepts two valid values:

• P - Passenger

• B - Business

In our requirement, all customers created through this interface should initially be classified as passengers. We’ll configure a fixed value in SAP AIF that automatically assigns the value P to the CUSTTYPE field. This ensures that every IDoc processed through the interface contains a valid customer type and can be processed successfully, without requiring the sender system to provide this information. The sender system may send a blank value.

Sample IDoc segment showing the CUSTTYPE field left blank by the sender

In the following steps, you’ll learn how to configure a fixed value mapping in SAP AIF so that all customer master records created through the II_FL_CUST interface automatically receive the customer type P (Passenger) during preprocessing.

Step 1 - Configure the Interface for Preprocessing

Transaction: /AIF/CUST -> SAP Application Interface Framework -> Interface Development -> Define Interfaces

Go to Customizing for SAP Application Interface Framework (transaction code /AIF/CUST) and navigate to Interface Development -> Define Interfaces.

💡 Tip Pre-Processing must be enabled on the interface before AIF can apply any field mappings - including fixed values and value mappings at runtime. Without this flag set, the structure mapping configuration in the following steps will have no effect.

/AIF/CUST - Define Interfaces menu path

In the selection screen, enter your namespace (for example, ZDEMO) and choose Continue.

/AIF/CUST - namespace selection screen

Switch to Change Mode and open the existing interface II_FL_CUST.

/AIF/CUST - opening interface II_FL_CUST in change mode

Configure the following settings:

• Deselect Move Corresponding Structures

• Select Pre-Processing

• Maintain the source and destination structures

/AIF/CUST - interface settings with Pre-Processing enabled

Save your changes.

Step 2 - Define Structure Mappings

Transaction: /AIF/CUST -> SAP Application Interface Framework -> Interface Development -> Define Structure Mappings

While still in Customizing, navigate to Interface Development -> Define Structure Mappings.

/AIF/CUST - Define Structure Mappings menu path

Enter the following values:

• Namespace: ZDEMO

• Interface Name: II_FL_CUST

• Interface Version: 1

/AIF/CUST - structure mapping selection screen with namespace/interface/version fields

Choose Continue.

💡 Tip

Notice that in this example, the fixed value is created under the combination Namespace / Interface / Version (ZDEMO / II_FL_CUST / 1). As a result, this fixed value is specific to this interface version and cannot be reused by other interfaces within the same namespace. This approach is useful when the fixed value is only relevant to a particular interface and should not be available elsewhere. SAP AIF also allows you to create fixed values at the namespace level. Namespace-level fixed values aren’t tied to a specific interface and can therefore be reused across multiple interfaces within the same namespace. For example, if several interfaces in namespace ZDEMO require the same customer type, status code, company code, or any other constant value, it’s more efficient to create the fixed value directly under the namespace.

Select New Entries and create a mapping for the root node of your interface structure.

/AIF/CUST - New Entries for structure mapping

Select the root structure that was generated for your interface.

Save the entry.

💡 Tip

The source structure you select here should be the root-level DDIC structure that was generated for your IDoc basic type in the DDIC generation step. If you’re unsure of the name, you can look it up in SE11 or check the objects created during the /AIF/IDOC_GEN run.

Step 2.1 - Assign Destination Structure

Select the newly created source structure and double-click Assign Destination Structure.

/AIF/CUST - Assign Destination Structure option

⚠️ Warning

Make sure to first select the source structure and then the destination structure; otherwise, the configuration cannot be created properly.

Create a new entry with the following values:

• Number of Structure Mapping: 10 Destination Structure: Root structure of the interface

• Move Corresponding Fields: Selected

Save your changes.

Step 3 - Create a Fixed Value for Customer Type

Read more

Scenario Detail

In this scenario, we will set up an SAP AIF interface to process customer data received through an IDoc. The interface will be capable of creating and updating customer (passenger) master records.

We will use the following IDoc:

Message Type: FLCUSTOMER_CREATEFROMDATA

Basic Type: FLCUSTOMER_CREATEFROMDATA01

Step 1 - Define the Namespace

Transaction: /n/AIF/CUST -> SAP Application Interface Framework -> Define Namespaces

Navigate to transaction /n/AIF/CUST and create a new namespace. Alternatively, you can use an existing namespace. In this example, we will use the existing namespace ZDEMO.

💡 Tip

The namespace is the top-level container for all your AIF objects - interfaces, recipients, and value mappings all sit inside it. Using a consistent naming convention (e.g. Z + project abbreviation) makes it much easier to manage objects across a large system.

Step 2 - Generate DDIC Structure

Transaction: /n/AIF/IDOC_GEN

SAP AIF works with SAP Data Dictionary (DDIC) structures. However, IDoc basic types, which define the structure of an IDoc, do not have corresponding DDIC structures delivered by default. Therefore, before an IDoc can be monitored and processed through SAP AIF, a DDIC structure must be generated for the IDoc basic type.

Open the IDoc Structure Generator using transaction /n/AIF/IDOC_GEN and enter the details of the IDoc you want to monitor.

💡 Tip

This step only needs to be done once per IDoc basic type. If a DDIC structure has already been generated for your basic type by a previous project, you can skip to Step 2.1 and create the interface directly in /n/AIF/CUST without re-running the generator.

Step 2.1 - Create the Interface

You can create the interface directly during this step. Alternatively, you can create the interface later using transaction /n/AIF/CUST.

To create the interface as part of the IDoc Structure Generator process, select the Create Interface option and maintain the interface details as shown below.

💡 Tip

The IDoc Processing Scenario field controls how AIF hooks into the IDoc processing. The option “ALE runtime; AIF enabler writing application log” is the most common choice for inbound IDocs - it means AIF runs as part of the standard ALE inbound processing and writes errors to the application log so they appear in the AIF monitor.

Namespace: ZDEMO or the namespace created in Step 1

Interface Name: II_FL_CUSTOMER

Interface Version: 1

Interface Description: Customer Master IDoc Interface

IDoc Processing Scenario: ALE runtime; AIF enabler writing application log

Customizing Request: Your customizing request

After maintaining the required information, execute the generation process.

If the generation is successful, SAP AIF creates all required objects, including the DDIC structures and interface definitions. A confirmation popup is displayed showing the details of the generated objects.

If the objects are created successfully, you will have a log with all the objects like this.

Step 3 - Create Interface-Specific Single Index Table

Transaction: SE11

Go to transaction SE11 to create the index table. SAP provides a standard index table template that can be used as a reference. Copy the template table and create a new custom index table based on it. Make sure the new table follows the required naming conventions for your namespace and interface.

💡 Tip

To leverage the full capabilities of SAP AIF and to customize interface error handling and monitoring as required, an index table is typically needed. Therefore, it is recommended to always create an index table for your interfaces.

This index table is used by SAP AIF to enable message indexing and monitoring for the interface.

⚠️ Warning

You can switch the single index table later; however, messages stored in the old index table will no longer be visible in the Interface Monitor. Only new messages will be written to the newly assigned table.

You can use the AIF index template table /AIF/STD_IDX_TBL and select Copy. Then, enter the name ZIDX_IXIFL_CUSTO for the new table and select Continue. When prompted, enter the package name you created earlier.

🛑 Required

Make sure to activate the table in SE11 before moving on. Without activation the index table does not exist in the database and AIF will not be able to write messages to it. You will get a runtime error the first time an IDoc is processed.

Step 4 - Define Namespace-Specific Features

Transaction: /n/AIF/CUST -> SAP Application Interface Framework -> Error Handling -> Define Namespace-Specific Features -> Define Interface-Specific Features

Next, assign the index table to the interface. Go to transaction /n/AIF/CUST and navigate to SAP Application Interface Framework -> Error Handling -> Define Namespace-Specific Features.

Enter namespace ZDEMO and continue.

In Define Interface-Specific Features, choose New Entries and maintain the interface II_FL_CUST with version 1. In the Message Index Table field, enter the newly created index table ZAIF_IDOC_CUST and save your changes.

Step 5 - Create Recipient for Alerts

One of the main purposes of SAP AIF is to enable users to monitor interfaces through AIF monitoring tools. However, not all users should have access to all interfaces in the system. Therefore, users must be grouped into different categories so that access can be controlled based on business requirements.

In SAP AIF, these user groups are defined as Recipient for Alerts. Based on your organization’s requirements, you should create appropriate recipient groups.

For example, you can create one recipient group for users who should monitor all IDoc-related interfaces, and another group for users responsible for OData services.

💡 Tip

In a real-world scenario, access is typically restricted by functional areas. For instance, the Material Master team (PLM) may be given access to material-related interfaces, while the OTC team may be granted access to all sales-related interfaces.

Go to Customizing (transaction /AIF/CUST) and navigate to SAP Application Interface Framework > Error Handling > Define Namespace-Specific Features.

Enter or select your namespace ZDEMO and select Continue.

Navigate to Define Recipients by double-clicking it.

Select New Entries, enter a meaningful name for your new recipient.

Step 6 - Assign the Recipient to the Interface

Transaction: /AIF/CUST -> SAP Application Interface Framework -> Error Handling -> Define Namespace-Specific Features -> Define Interface-Specific Features -> Assign Recipients Without Key Fields

Now assign the recipient to the interface. Go to transaction /AIF/CUST and navigate to SAP Application Interface Framework -> Error Handling -> Define Interface-Specific Features.

💡 Tip

Use Assign Recipients Without Key Fields when all messages for this interface should be visible to the recipient group, regardless of any business key values (e.g. customer number or company code). If you want to restrict visibility to only certain key values, use Assign Recipients with Key Fields instead.

Enter namespace DEMO_1, interface FCUSTOMER, and version 1, then choose Continue.

Read more

Message Validation in System Integration, Why It Matters

When it comes to system integration, one of the most important steps before message processing begins is ensuring that the incoming message is valid.

This means checking:

• Is the message format correct?

• Does it match the defined schema?

• Are all mandatory elements required for processing available?

• Do fields contain data with correct length and data type?

• Are there invalid characters?

• Do field values fall within an acceptable or expected range?

These are critical checks to perform before continuing with the pipeline. Without proper validation, you may encounter unexpected behavior during later stages of message processing.

Where Should Message Validation Take Place?

In an enterprise integration landscape, there is typically a middleware layer—such as SAP Integration Suite—between the sender and the receiver. If the receiver system is an ERP system like SAP S/4HANA, you could technically perform validation there using tools such as SAP AIF (Application Integration Framework).

However, it is important to assign responsibilities to the right components in your architecture. The receiver system should not be burdened with all validations, especially structural validations like checking XML format against schema. Doing such validations at the receiver means writing unnecessary and often complex backend logic.

Structural validation is best handled in the middleware, as it is the first line of defense.

On the other hand, business validations—such as checking whether an order type, warehouse code, or material exists—should ideally be performed in the receiver system, since that system owns the business data.

A balanced approach is recommended:

• Structural validations (XSD compliance, format, mandatory fields, data type, etc.)

  • Where to Validate: Middleware

  • Reason: Prevent processing of invalid payload early.

• Business validations (order type exists, material code valid etc.)

  • Where to Validate: Receiver system (e.g. S/4HANA)

  • Reason: Requires master data available only in backend.

Message Validation in SAP Integration Suite

SAP Integration Suite provides multiple ways to perform payload validation. You may use:

• XML Validator palette option

• EDI Validator

• Groovy scripts

• XPath expressions

• Filter step logic

• Other validation options depending on the scenario

The recommended first approach is to use standard palette steps. For structural validations, SAP Integration Suite provides XML Validator and EDI Validator out-of-the-box.

In this article, we will focus on the XML Validator, how to configure it, how it behaves, and how to handle payload validation results in your iFlow.

Prerequisites for Implementing XML Validator in SAP Integration Suite

It goes without saying that you need to have the incoming XML message format as well as the corresponding XSD schema for the XML.

For this example, I have created an XML format that sends order information, and based on that, I have created the corresponding XSD schema. The XSD defines all validation rules, and every incoming XML will be validated against it. We want to stop processing any XML that is invalid or does not comply with the XSD.

Incoming XML Format

<?xml version="1.0" encoding="UTF-8"?>
<SalesOrder>
    <!-- ===== Order Header ===== -->
    <Header>
        <CustomerID>VINET</CustomerID>
        <OrderDate>1996-07-04T00:00:00Z</OrderDate>
        <ShippedDate>1996-07-16T00:00:00Z</ShippedDate>
        <DocumentCurrency>EUR</DocumentCurrency>
        <PurchaseOrderNumber>PO-458922</PurchaseOrderNumber>
        <OrderStatus>Confirmed</OrderStatus>
    </Header>
    <!-- ===== Customer Information ===== -->
    <CustomerDetails>
        <CustomerName>Vins et alcools Chevalier</CustomerName>
        <ContactPerson>Jean Dupont</ContactPerson>
        <Email>contact@vins-chevalier.fr</Email>
        <Phone>+33-320-556-789</Phone>
        <BillingAddress>
            <AddressLine1>59 rue de l'Abbaye</AddressLine1>
            <City>Reims</City>
            <PostalCode>51100</PostalCode>
            <Country>France</Country>
        </BillingAddress>
    </CustomerDetails>

    <!-- ===== Shipping Information ===== -->
    <ShippingDetails>
        <ShipMethod>Express</ShipMethod>
        <ShipVia>3</ShipVia>
        <Freight>32.38</Freight>
        <ShipTo>
            <ShipName>Vins et alcools Chevalier</ShipName>
            <ShipAddress>59 rue de l'Abbaye</ShipAddress>
            <ShipCity>Reims</ShipCity>
            <ShipRegion></ShipRegion>
            <ShipPostalCode>51100</ShipPostalCode>
            <ShipCountry>France</ShipCountry>
        </ShipTo>
    </ShippingDetails>

    <!-- ===== Item/Order Lines ===== -->
    <Items>
        <Item>
            <LineNumber>1</LineNumber>
            <MaterialID>SKU-1001</MaterialID>
            <Description>Red Wine Premium</Description>
            <Quantity>50</Quantity>
            <Unit>EA</Unit>
            <UnitPrice>15.00</UnitPrice>
            <Discount>0.10</Discount>
            <NetAmount>675.00</NetAmount>
        </Item>

        <Item>
            <LineNumber>2</LineNumber>
            <MaterialID>SKU-2450</MaterialID>
            <Description>Champagne Brut</Description>
            <Quantity>20</Quantity>
            <Unit>EA</Unit>
            <UnitPrice>35.00</UnitPrice>
            <Discount>0.00</Discount>
            <NetAmount>700.00</NetAmount>
        </Item>
    </Items>

    <!-- ===== Order Summary ===== -->
    <Totals>
        <SubTotal>1375.00</SubTotal>
        <Tax>206.25</Tax>
        <ShippingCharges>32.38</ShippingCharges>
        <GrandTotal>1613.63</GrandTotal>
    </Totals>
</SalesOrder>

XSD Schama of the XML

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           elementFormDefault="qualified">

    <!-- ========= Root Element ========= -->
    <xs:element name="SalesOrder">
        <xs:complexType>
            <xs:sequence>
                <xs:element name="Header" type="HeaderType"/>
                <xs:element name="CustomerDetails" type="CustomerDetailsType"/>
                <xs:element name="ShippingDetails" type="ShippingDetailsType"/>
                <xs:element name="Items" type="ItemsType"/>
                <xs:element name="Totals" type="TotalsType"/>
            </xs:sequence>
        </xs:complexType>
    </xs:element>

    <!-- ========= Header Segment ========= -->
    <xs:complexType name="HeaderType">
        <xs:sequence>
            <xs:element name="OrderID" type="xs:string"/>
            <xs:element name="CustomerID" type="xs:string"/>
            <xs:element name="OrderDate" type="xs:dateTime"/>
            <xs:element name="RequiredDate" type="xs:dateTime" minOccurs="0"/>
            <xs:element name="ShippedDate" type="xs:dateTime" minOccurs="0"/>
            <xs:element name="DocumentCurrency" type="xs:string"/>
            <xs:element name="PurchaseOrderNumber" type="xs:string" minOccurs="0"/>
            <xs:element name="OrderStatus" type="xs:string" minOccurs="0"/>
        </xs:sequence>
    </xs:complexType>

    <!-- ========= Customer Info ========= -->
    <xs:complexType name="CustomerDetailsType">
        <xs:sequence>
            <xs:element name="CustomerName" type="xs:string"/>
            <xs:element name="ContactPerson" type="xs:string" minOccurs="0"/>
            <xs:element name="Email" type="xs:string" minOccurs="0"/>
            <xs:element name="Phone" type="xs:string" minOccurs="0"/>
            <xs:element name="BillingAddress" type="BillingAddressType"/>
        </xs:sequence>
    </xs:complexType>

    <xs:complexType name="BillingAddressType">
        <xs:sequence>
            <xs:element name="AddressLine1" type="xs:string"/>
            <xs:element name="City" type="xs:string"/>
            <xs:element name="PostalCode" type="xs:string"/>
            <xs:element name="Country" type="xs:string"/>
        </xs:sequence>
    </xs:complexType>

    <!-- ========= Shipping Details ========= -->
    <xs:complexType name="ShippingDetailsType">
        <xs:sequence>
            <xs:element name="ShipMethod" type="xs:string" minOccurs="0"/>
            <xs:element name="ShipVia" type="xs:int"/>
            <xs:element name="Freight" type="xs:decimal" minOccurs="0"/>
            <xs:element name="ShipTo" type="ShipToType"/>
        </xs:sequence>
    </xs:complexType>

    <xs:complexType name="ShipToType">
        <xs:sequence>
            <xs:element name="ShipName" type="xs:string"/>
            <xs:element name="ShipAddress" type="xs:string"/>
            <xs:element name="ShipCity" type="xs:string"/>
            <xs:element name="ShipRegion" type="xs:string" minOccurs="0"/>
            <xs:element name="ShipPostalCode" type="xs:string"/>
            <xs:element name="ShipCountry" type="xs:string"/>
        </xs:sequence>
    </xs:complexType>

    <!-- ========= Line Items ========= -->
    <xs:complexType name="ItemsType">
        <xs:sequence>
            <xs:element name="Item" type="ItemType" minOccurs="1" maxOccurs="unbounded"/>
        </xs:sequence>
    </xs:complexType>

    <xs:complexType name="ItemType">
        <xs:sequence>
            <xs:element name="LineNumber" type="xs:int"/>
            <xs:element name="MaterialID" type="xs:string"/>
            <xs:element name="Description" type="xs:string"/>
            <xs:element name="Quantity" type="xs:decimal"/>
            <xs:element name="Unit" type="xs:string"/>
            <xs:element name="UnitPrice" type="xs:decimal"/>
            <xs:element name="Discount" type="xs:decimal" minOccurs="0"/>
            <xs:element name="NetAmount" type="xs:decimal"/>
        </xs:sequence>
    </xs:complexType>

    <!-- ========= Totals ========= -->
    <xs:complexType name="TotalsType">
        <xs:sequence>
            <xs:element name="SubTotal" type="xs:decimal"/>
            <xs:element name="Tax" type="xs:decimal"/>
            <xs:element name="ShippingCharges" type="xs:decimal" minOccurs="0"/>
            <xs:element name="GrandTotal" type="xs:decimal"/>
        </xs:sequence>
    </xs:complexType>

</xs:schema>

Basic Configuration of XML Validator

Let’s create an iFlow and validate the incoming XML against an XSD using the default configuration of the XML Validator. We will leave Prevent Exception on Failure unchecked.

Upload the XSD file to the configuration option XML Schema option of the XML validator.

Test Scenario 1: Valid XML

When a valid XML is sent, the validator passes successfully and the message continues. Since we are not performing additional operations here, the same payload is returned as the response.

Test Scenario 2: Invalid XML

Now let’s remove a mandatory field (e.g., OrderID) and send the XML again.

This time the iFlow throws an exception, and the sender receives an HTTP 500 error with a generic MPL error response. It does not clearly indicate what went wrong.

However, the message monitor shows detailed information stating exactly which field failed and why the validation did not pass.

To improve the experience, we should send a meaningful validation response back to the sender indicating:

• Whether validation succeeded or failed

• If failed, the exact reason

This helps the sender correct the payload and resend it. We will look at two variations of iFlows to do the same.

iFlow Variation 1 – XML Validation without Raising an Exception for Invalid XML Messages

Now, let’s enable Prevent Exception on Failure. With this option active, even if the XML is invalid, it will not throw an exception, allowing the message to continue through the iFlow.

Integration Suite will store the Validation results in the header parameter: SAP_XmlValidationResult

• If the XML is valid → SAP_XmlValidationResult = null that means XML is valid.

• if validation fails → this header contains the failure reason. Hence, the parameter SAP_XmlValidationResult will not be null.

Using a Router with an expression such as: ${header.SAP_XmlValidationResult} != null we will create two routes to process valid XMLs and invalid XMLs.

Now let’s configure the response back to the message sender. We will use content modifiers to set the response payload and return the status of the message validation.

In case of failure, it is recommended to return an appropriate HTTP status code to the message sender, preferably one from the 4xx series. For this example, if the message validation fails, we will return HTTP status code 400 (Bad Request) to clearly indicate that the incoming request was invalid.

We can use the CamelHttpResponseCode header parameter to set the HTTP status code in the response message.

Now, let’s test the iFlow with both a valid and an invalid XML message.

Test Scenario 1 – Valid XML

Test Scenario 2 – Invalid XML

Learn how to implement payload validation in SAP Integration Suite iFlows using the XML Validator. This guide covers setup, configuration options, best practices for handling invalid XML messages, returning validation responses to senders, and even a workaround for validating JSON payloads. Perfect for integration developers looking to improve data quality and message reliability.

Notice that the message status in the message monitor will still appear as Successful or Completed even if the XML is invalid. This is because we prevented an exception from being raised for invalid XML messages and explicitly ended the processing using the End Message event.

If you’d like to learn SAP integration step by step, join my SAP Integration Suite course for Beginners, and start building real-world integration skills today.

Learn SAP Integration with me!

This behavior is acceptable since, in end-to-end synchronous scenarios, it is the responsibility of the message-sending system to correct the payload and resend the request. We have already returned the error details to the sender, enabling them to take corrective action.

iFlow Variation 2 – Raise an Exception for Invalid Message and Handle them in the Exception Sub Process

Now let’s uncheck the Prevent Exception on Failure option. This will allow the XML Validator to throw an exception if the incoming message does not comply with the XSD. Once an exception is raised, no further processing of the message will take place, and the exception must be handled in the Exception Subprocess.

We will now handle invalid XML messages in the Exception Subprocess. Therefore, we need to set the response body and the appropriate HTTP status code for the error response within the exception subprocess.

Notice that we will now use the header parameter CamelExceptionCaught instead of SAP_XmlValidationResult. When the exception originates from the XML Validator, CamelExceptionCaught will contain the validation error details, similar to the information previously available in SAP_XmlValidationResult in iFlow Variation 1.

In the main flow, you can continue processing the message for valid XML payloads.

If you test the flow, you will notice that the response sent back to the message sender is the same as in Variation 1. The response body and the HTTP status code are returned to the sender as expected.

If you’d like to learn SAP integration step by step, join my SAP Integration Suite course for Beginners, and start building real-world integration skills today.

Learn SAP Integration with me!

How to Easily Identify Messages Where XML Validation Failed?

As you may have noticed, even when XML validation fails, the message status in the Message Monitor still appears as Successful or Completed.

This is unavoidable if you want to send a custom rbody of the message in the response back, such as a meaningful HTTP status code. To achieve this, you must end the message processing with an End Message event, which in turn sets the message status in the monitor to Completed.

This means you cannot rely on the standard status field to differentiate between valid and invalid messages.

So, how can users easily filter messages that failed XML validation?

In such cases, you can make use of the Custom Status feature in SAP Integration Suite. By setting a meaningful value to the parameter SAP_MessageProcessingLogCustomStatus, you can mark messages where validation failed and later filter them in the Message Monitor.

In this example, we will set the value of SAP_MessageProcessingLogCustomStatus to: XMLValidationFailed

Once configured, you can simply use the Custom Status filter in the Message Monitor to quickly identify messages where XML validation did not pass.

What Kind of Payload Validations Can be Done?

You can validate incoming XML files against the XSD, as all the validation rules are defined within the schema. An XML Validator checks the incoming message against the XSD to determine whether it is valid and suitable for processing.

Below are some examples of the types of validations that can be performed using a properly defined XSD:

Optional / Required Elements

Here the order ID element is mandatory, you know that because minOccurs attribute is not set as zero on this field. While elements such as RequiredDate and ShippedDate are optional as both elements have minOccurs=”0″.

So if any of the madatory fields are not avilable validation fails.

    <!-- ========= Header Segment ========= -->
    <xs:complexType name="HeaderType">
        <xs:sequence>
            <xs:element name="OrderID" type="xs:string"/>
            <xs:element name="CustomerID" type="xs:string"/>
            <xs:element name="OrderDate" type="xs:dateTime"/>
            <xs:element name="RequiredDate" type="xs:dateTime" minOccurs="0"/>
            <xs:element name="ShippedDate" type="xs:dateTime" minOccurs="0"/>
            <xs:element name="DocumentCurrency" type="xs:string"/>
            <xs:element name="PurchaseOrderNumber" type="xs:string" minOccurs="0"/>
            <xs:element name="OrderStatus" type="xs:string" minOccurs="0"/>
        </xs:sequence>
    </xs:complexType>

    <!-- ===== Order Header ===== -->
    <Header>
        <OrderID>0001</OrderID>
        <CustomerID>VINET</CustomerID>
        <OrderDate>1996-07-04T00:00:00Z</OrderDate>
        <DocumentCurrency>EUR</DocumentCurrency>
        <PurchaseOrderNumber>PO-458922</PurchaseOrderNumber>
        <OrderStatus>Confirmed</OrderStatus>
    </Header>

This is valid although ShippedDate and RequiredDate are not available.

    <!-- ===== Order Header ===== -->
    <Header>
       <CustomerID>VINET</CustomerID>
        <OrderDate>1996-07-04T00:00:00Z</OrderDate>
        <DocumentCurrency>EUR</DocumentCurrency>
        <PurchaseOrderNumber>PO-458922</PurchaseOrderNumber>
        <OrderStatus>Confirmed</OrderStatus>
    </Header>

This is inavlid because the mandatory element OrderID is missing

Data Type Validation

You can check values in each element is in the correct type. For example, OrderDate should be of type dateTime. Order data like this <OrderDate>2025-07-04</OrderDate> would fail because it should a timestamp format with data and time like <OrderDate>2025-07-04T00:00:00Z</OrderDate>.

Here is the exact error raised from XML validator, <OrderDate> does not match the required simple type. Invalid dateTime value “2025-07-04” (Too short).

Here are some of the other Built-in types: xs:string, xs:int, xs:decimal, xs:date, xs:dateTime, xs:boolean, etc.

Message Structure

Notice that each segment under the SalesOrder element must appear in the defined sequence.
If any segment is placed in the wrong order, an error will be raised.

<xs:element name=”SalesOrder”>
<xs:complexType>
<xs:sequence>
<xs:element name=”Header” type=”HeaderType”/>
<xs:element name=”CustomerDetails” type=”CustomerDetailsType”/>
<xs:element name=”ShippingDetails” type=”ShippingDetailsType”/>
<xs:element name=”Items” type=”ItemsType”/>
<xs:element name=”Totals” type=”TotalsType”/>
</xs:sequence>
</xs:complexType>
</xs:element>

For example, if I move the Totals segment to an incorrect position, you will see this validation error.

In content of element 
 <SalesOrder>: The content model does not allow element 
 <Q{}Totals> to appear immediately after element 
 <ShippingDetails>. It must be preceded by 
 <Q{}Items>. 

Following are other types of structure rules you can apply in the XSD.

• <xs:all> → all elements present in any order

• <xs:sequence> → elements must appear in order

• <xs:choice> → only one element out of many

Pattern Validation

Lets say you want to make sure the email is a valid email. You can make assign a pattern in the XSD.

<xs:element name=”Email” minOccurs=”0″>
<xs:simpleType>
<xs:restriction base=”xs:string”>
<xs:pattern value=”[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}”/>
</xs:restriction>
</xs:simpleType>
</xs:element>

Then if the email is not in the expacted pattern with @ sign, it will though an error. Such kind of data that should adhere to a defined pattern like a address, email, phone number, etc can be defined in the XSD.

Enumeration

Using Enumeration rules, you can check if the data is valid againist a list of values allowed for that element.

Now lets check if the OrderStatus value comply with the list of allowed statuses.

<xs:simpleType name="OrderStatusEnum">
    <xs:restriction base="xs:string">
        <xs:enumeration value="New"/>
        <xs:enumeration value="Pending"/>
        <xs:enumeration value="Processing"/>
        <xs:enumeration value="Shipped"/>
        <xs:enumeration value="Delivered"/>
        <xs:enumeration value="Cancelled"/>
        <xs:enumeration value="Returned"/>
        <xs:enumeration value="On Hold"/>
    </xs:restriction>
</xs:simpleType>

<!-- ========= Header Segment ========= -->
<xs:complexType name="HeaderType">
    <xs:sequence>
        <xs:element name="OrderID" type="xs:string"/>
        <xs:element name="CustomerID" type="xs:string"/>
        <xs:element name="OrderDate" type="xs:dateTime"/>
        <xs:element name="RequiredDate" type="xs:dateTime" minOccurs="0"/>
        <xs:element name="ShippedDate" type="xs:dateTime" minOccurs="0"/>
        <xs:element name="DocumentCurrency" type="xs:string"/>
        <xs:element name="PurchaseOrderNumber" type="xs:string" minOccurs="0"/>
        <xs:element name="OrderStatus" type="OrderStatusEnum" minOccurs="0"/>
    </xs:sequence>
</xs:complexType>

If you send a value that is not the list it will error out. Allowing you to check for valid values

<OrderStatus>Confirmed</OrderStatus>

The content "Confirmed" of element <OrderStatus> does not match the required simple type. Value "Confirmed" contravenes the enumeration facet "Returned, New, Delivered, On H..." of the type Q{}OrderStatusEnum

Min/Max Values (Numeric or Length)

The following rules allow you to check whether numeric values fall within an allowed range, such as a minimum or maximum value. You can also validate the length of a string value in a similar way.

• Numeric:

  • xs:minInclusive, xs:maxInclusive

  • xs:minExclusive, xs:maxExclusive

• String length:

  • xs:minLength, xs:maxLength

<xs:element name="Quantity">
    <xs:simpleType>
        <xs:restriction base="xs:decimal">
            <xs:minInclusive value="1"/>
            <xs:maxInclusive value="1000"/>
        </xs:restriction>
    </xs:simpleType>
</xs:element>

Workaround to Validate JSON and Other Message Formats

The XML Validator works only for XML. So what is the incoming message is a JSON payload?

Although there is no native palette step for JSON structure validation, as a workaround you can:

1. Convert the JSON to XML using the JSON → XML Converter

2. Create an XSD that represents the structure of the message

3. Validate the converted XML using the XML Validator

This approach allows you to validate JSON messages using the same mechanism as XML.

Now let’s send an JSON message to the iFlow.

You can also write a Groovy script for JSON validation but custom logic should be implemented. Advantage of using the XML validator for JSON messages is that you can use standard features witout creating complex Groovy Scripts.

The downside of this workaround is that the error details will be displayed as XML elements.

Summary

Message validation is a crucial part of any integration flow. Implementing it correctly ensures quality, prevents runtime issues, and helps sender systems quickly correct and resend bad messages.

• Use middleware for structural validation

• Use the receiver for business validation

• SAP Integration Suite provides XML and EDI validators out of the box

We explored the configuration options in the XML Validator and different variations for using the XML Validator palette options. You can handle invalid XML messages either in the Exception Subprocess or by using an appropriate Router Exception. We also looked at some of the rules you can define in the XSD to validate the incoming XML.

In addition, we also looked at how to use a Custom Status to indicate which messages have failed, as well as a workaround for validating incoming JSON messages.

Hope you enjoyed the article! If you’d like to learn SAP Integration with me, check out my Online Course on SAP Integration Suite.

Learn SAP Integration with me!

The post How to Validate Incoming Messages with XML Validator in SAP IS appeared first on SAP Integration Hub.

What Is Idempotency? Definition and Explanation

In computing and system integration, an operation is called idempotent if performing it multiple times produces the same result as performing it once.

In other words, even if the operation is repeated, intentionally or due to retries, network issues, or user error, the final state of the system remains unchanged beyond the effect of the first execution.

To make this concept clearer, let’s look at a simple real-world scenario.

Imagine an e-commerce application that sends sales orders to a backend database or ERP system.
In the ideal or “happy” flow, the e-commerce portal sends the order, the receiver successfully creates the order in the backend system, and then sends an acknowledgment back to the e-commerce application.

In this perfect situation, everything works exactly as expected.

But what happens if the acknowledgment is not received by the sender, even though the backend system actually received and created the order?

In this situation, the sender has no way of knowing whether the order was created successfully or not.
As a result, the sender will naturally try to send the message again.

Now imagine a frustrated user repeatedly clicking the Submit button because they think the order didn’t go through, simply because they never received a confirmation. If each of those clicks creates a new sales order in the backend system, the outcome would be a complete disaster.

And this issue isn’t limited to user actions; many systems have automatic retry mechanisms.
When they fail to receive the expected response, they will resend the message, often multiple times.

This is why it is essential to detect and handle duplicate messages.
This is exactly what we mean when we talk about making a process idempotent: the Backend system should not create new sales orders after the first operation. The interface should identify duplicate messages and prevent them from being processed again.

Only the first valid message should be processed. Any subsequent duplicates should be safely ignored.

Which HTTP Methods Are Idempotent?

When working with HTTP calls, it’s important to understand which methods are idempotent, meaning which methods do not change the result even if they are executed multiple times.

GET Method

Take the GET method, for example. If you send a request to retrieve sales order information from a database, the sender provides the order ID and receives the corresponding order details. Even if the same GET request is sent repeatedly, nothing in the database changes; you are just reading the data, not altering the data. The data in the backend system remains exactly the same. That’s why the GET method is considered idempotent; multiple identical requests do not alter the result of the system.

POST Method

Now, let’s look at POST. A POST request is typically used to create a new resource, in our scenario, a new sales order in the backend system or database. If the same POST request is sent multiple times, it creates multiple orders, changing the system each time. Therefore, POST is not idempotent.

DELETE Method

On the other hand, DELETE is idempotent. You can only delete a resource once. The first DELETE request removes the order; any subsequent DELETE requests for the same order do not make further changes to the database. The system state remains the same after the first deletion.

The same principle applies to other HTTP methods that do not alter the system after their initial execution; they are considered idempotent, because repeated calls do not lead to additional changes.

What Is an Idempotent Receiver?

So, what if the message receiver system itself can identify duplicate messages?

For this to work, each message must include a unique identifier. In our example, this could be the Sales Order ID, which is unique for every order.

The Sales Order ID is assigned by the sender system. When the message reaches the receiver, the receiver can check this ID for uniqueness. If the ID has never been processed before, the receiver processes the order and saves it to the database. It should also store that ID in memory or in a table, so that it can compare future incoming messages against it.

If a message arrives with an ID that has already been processed, the receiver simply ignores it. In this way, the receiver behaves as an idempotent receiver, capable of safely handling duplicate messages.

However, not all receivers are built this way. Some systems cannot handle duplicates and are considered non-idempotent. In such cases, the middleware must take responsibility for ensuring idempotency.

This is where the Idempotent Process Call feature in SAP Integration Suite comes into play. It allows the middleware to detect and handle duplicates before they even reach the backend system, ensuring reliable and consistent processing.

When to Use the Idempotent Process Call in SAP Integration Suite

In cases where the backend system is non-idempotent, it cannot detect or manage duplicate messages on its own. Or if the HTTP method used is non-idempotent. That’s where the middleware must take responsibility.

As discussed earlier, a unique ID is required to identify duplicates. In our scenario, the unique reference is the Sales Order ID included in the order XML.

This ID serves as the key for the middleware to check whether a message has already been processed. If the middleware encounters this Sales Order ID for the first time, it allows the message to pass through to the backend system.

If the same ID appears again, whether due to network retries, system errors, or users clicking “Submit” multiple times, the middleware can safely ignore the duplicate message.

By implementing this check, the middleware ensures that the backend system receives each order only once, even if the message has been sent multiple times.

Prerequisites for Using the Idempotent Process Call in SAP Integration Suite

One of the prerequisites for using the Idempotent Process Call in SAP Integration Suite is that we must have a unique ID to identify each message (or iteration). This ID is then used to detect duplicates and ignore any subsequent duplicate messages associated with that same ID.

This unique ID can be taken from the payload, or it can be a technical ID generated by the sender adapter — such as a UUID, GUID, Transaction ID, etc.

In simple terms, it just needs to be unique for every incoming request.

Example: Idempotent Process Call Flow in SAP Integration Suite

Now let’s look at a real-life example with the sales order scenario we looked at earlier.

Here is the incoming message format.

<?xml version="1.0" encoding="UTF-8" ?>
 <Order>
     <OrderID>10250</OrderID>
     <CustomerID>VINET</CustomerID>
     <EmployeeID>5</EmployeeID>
     <OrderDate>1996-07-04T00:00:00Z</OrderDate>
     <RequiredDate>1996-08-01T00:00:00Z</RequiredDate>
     <ShippedDate>1996-07-16T00:00:00Z</ShippedDate>
     <ShipVia>3</ShipVia>
     <Freight>32.38</Freight>
     <ShipName>Vins et alcools Chevalier</ShipName>
     <ShipAddress>59 rue de l'Abbaye</ShipAddress>
     <ShipCity>Reims</ShipCity>
     <ShipRegion></ShipRegion>
     <ShipPostalCode>51100</ShipPostalCode>
     <ShipCountry>France</ShipCountry>
 </Order>

Our unique ID is the Sales Order ID. We should process each sales order only once, meaning it should be sent to the backend system only a single time. Any subsequent messages with the same Sales Order ID should be ignored.

For the receiver system, I created a webhook on Beeceptor, which sends back an acknowledgment whenever it receives an order. It works as a ready-to-use mock server that requires no setup or signup. You can use Beeceptor to tailor response payloads, adjust status codes, reuse request parameters, and shape mocks from your OpenAPI specifications. This is the fastest way I have found to validate message flows before connecting to real downstream systems.

As you can see, the webhook does not check for duplicate orders; it simply accepts every message that arrives. We can imagine that it would create a new order each time a message is received.

Therefore, the middleware must handle duplicates and safely ignore them, ensuring that no duplicate messages are sent to the webhook receiver.

Develop an iFlow with an Idempotent Process Call in SAP Integration Suite

Create a Local Integration Process that sends the message to the receiver. In this case, the sales order message is sent to the webhook. This Local Integration Process will be called by the Idempotent Process Call.

Extract the unique ID, which is the sales order ID, using an XPath expression from the payload.

Configure the Idempotent Process Call using the Local Integration Process and Unique Message ID options.
For this scenario, let’s keep Skip Process Call for Duplicates enabled. This means that when the message reaches the Idempotent Process Call, if it is identified as a duplicate based on the Message ID, the local integration process will not be triggered.

Now, let’s test the interface.

Send a unique message, for example, a new sales order.

Lets send a duplicate message, the same order.

Notice that the Idempotent Process Call skips the local Process Call being executed.

Use of CamelDuplicateMessage and Customize Duplicate Handling

In the previous flow, we explored the Idempotent Process Call with the option “Skip Process Call for Duplicates” enabled. Notice that when this option is selected, the local process call is not executed for duplicate entries.

If you’d like to learn SAP integration step by step, join my SAP Integration Suite course for Beginners, and start building real-world integration skills today.

Learn SAP Integration with me!

However, you can also deselect the “Skip Process Call for Duplicates” option and handle duplicates manually by using the exchange header property CamelDuplicateMessage. When this option is deselected, the local integration process will be executed even for duplicate messages, which means you must implement your own duplicate-handling logic.

If the Idempotent Process Call detects that a message is a duplicate based on the unique Sales Order ID, the CamelDuplicateMessage header will be set to true. If it is not a duplicate, the value will be false.

In this example, I will use a Router to check whether the message is a duplicate. If it is, I will return a message to the sender stating: “Order ID XXX was already processed and will be ignored.”

Additionally, we will send a meaningful HTTP 4XX response back to the sender to indicate that the message is a duplicate using the header parameter CamelHttpResponseCode. For this scenario, I will use the HTTP response code 409 (Conflict) to clearly signal that the request conflicts with an already processed order.

Now let’s test the interface with the customized behavior.

First, we send a new sales order.

Then, let’s try sending the same sales order again.

Notice that the response body is meaningful, and the 4xx HTTP status code clearly indicates a bad request due to a conflict. Of course, you can use other 4xx HTTP response codes based on your design preference.

If you’d like to learn SAP integration step by step, join my SAP Integration Suite course for Beginners, and start building real-world integration skills today.

Learn SAP Integration with me!

Idempotent Repository and Validity Period

The Idempotent Process Step identifies whether a message is a duplicate by storing the unique Message ID (configured under the Message ID option) in the tenant’s Idempotent Repository, in our example, this is the Sales Order ID.

When a new request arrives, SAP Integration Suite checks whether this ID already exists in the repository. If it does, the message is considered a duplicate, and the Local Integration Process is skipped.

Keep in mind the 90 days rule!

However, note that the idempotent repository data is retained for 90 days only. After 90 days, the stored Message IDs are removed, meaning duplicate checks can only be performed within a 90-day window from the first message execution. In most real-world scenarios, this time frame is more than sufficient — just keep this in mind when designing your interfaces.

I hope you learned something new from this article. We explored the concept of Idempotency in system integration, compared idempotent vs non-idempotent HTTP calls, and discussed when it’s necessary to handle duplicate requests in the middleware. Especially when the receiver system is not idempotent.

Additionally, we walked through an end-to-end iFlow example, covering how to build an iFlow using the Idempotent Process Call, along with its configuration steps. We also looked at how to send a meaningful response back to the sender when a duplicate or invalid request occurs, using appropriate 4xx HTTP response codes.

If you would like to learn SAP Integration Suite with me, I’ve created an online course with 200+ video lessons. Check out the syllabus and sign up to become a confident SAP Integration Consultant.

Learn SAP Integration with me!

The post How to Implement Idempotent Process Call in SAP Integration Suite appeared first on SAP Integration Hub.

Of course, SAP provides some standard search parameters such as Message ID, Correlation ID, and even the option to filter messages by a specific time period. However, these parameters are mostly technical and not directly connected to the business context.

For example, how can you search for all Sales Order messages, all Delivery Documents, or even find messages based on a specific Sales Order Number or Delivery Number? What if you need to filter by sender or target system names? These kinds of business-friendly searches are not possible without customization in SAP Integration Suite.

This is where standard and custom header parameters come into play. By leveraging them, you can enrich your monitoring capabilities with business-relevant information, making message tracking and troubleshooting much more efficient.

Standard Header Parameters Available to Filter Messages

SAP provides a standard set of header parameters in the exchange envelope. Some of these standard parameters can be leveraged to add custom filter options in the Message Monitor.

Here are the standard parameters you can use:

• Message ID – The unique identifier that is associated with the message processing log (MPL).

• Correlation ID – The identifier used to correlate different messages with each other that are processed jointly in the context of an integration scenario.

• Application Message ID – Identifier set by a dedicated header (SAP_ApplicationID).

• Sender – Identifier set by a dedicated header (SAP_Sender).

• Receiver – Identifier set by a dedicated header (SAP_Receiver).

• Custom Status – Identifier set by a dedicated exchange property (SAP_MessageProcessingLogCustomStatus).

• Application Message Type – Identifier set by a dedicated header (SAP_MessageType).

Message ID and Correlation ID are quite technical and form the basis of the message processing log, so we will leave them as they are. Of course, you can still use these two values to filter messages.

You can assign values to any of these header parameters during integration processing at runtime, and later use those values to filter messages in the Integration Monitor.

Sample Integration Scenario to Demonstrate Message Monitoring Customization

To demonstrate this, let’s imagine we have an interface that processes product master data from your PLM system to SAP S/4HANA. For example, you may want to filter messages based on the Product ID, Catagory ID, Supplier ID or other business-related data. That is the information that is part of the actual message payload.

For demonstration purposes, we will simply save the product information in a data store, using the data store entry ID as the Product ID.

{
    "value": [
        {
            "ProductID": 51,
            "ProductName": "Gravad lax",
            "SupplierID": 20,
            "CategoryID": 9,
            "QuantityPerUnit": "12 - 500 g pkgs.",
            "UnitPrice": 26.0000,
            "UnitsInStock": 11,
            "UnitsOnOrder": 50,
            "ReorderLevel": 25,
            "Discontinued": false
        }
    ]
}

Here is the incoming JSON message from the PLM system.

In the integration flow, we will first convert the JSON message to XML, and then extract the Product ID from the payload to use as the entry ID in the data store.

Now let’s process some messages through the interface. If you go to the Message Monitor, you will notice that in the Properties section you only see the Message ID and Correlation ID, and nothing else.

But what if you need to search for messages based on the Product ID? In this case, we want to filter messages using the Product ID that comes in the incoming payload.

Using Standard Header Parameter to Filter Messages

To filter messages based on the business object ID, we need to set its value in the standard header parameter SAP_ApplicationID. We can achieve this by extracting the Product ID from the payload and assigning it to this parameter.

Use a Content Modifier step to set the value of the header parameter SAP_ApplicationID.

Now, let’s process another product and see the message monitor.

Now you can not only view the business document number processed by the message without digging into the payload, but also use this value to filter messages. In the standard filter “ID”, you can now enter this value to quickly find the relevant messages.

Not just SAP_ApplicationID, let’s set all the other standard parameters as well, such as;

• SAP_Sender

• SAP_Receiver

• SAP_MessageType

We will set the sender system as PLM, the receiver system as S/4HANA, and the application type as “Product Master”.

Now process a message and notice that all the values we set using the Content Modifier in the iFlow are visible in the Properties section of the Message Monitor.

Now you can use any of these filter criteria to filter messages.

For example, let’s filter the messages for Product ID, 40. You can use the ID field in the Message Monitor to do this. In the same way, you can use all other standard parameters.

Now, imagine having many interfaces and needing to filter messages based on sender system, target system, document type, etc. All of this is possible if you set the values correctly for these standard parameters during runtime.

Using Additional Filter Criteria with Custom Header Properties

⚠️ Warning

Now we have used all the standard parameters available for additional filtering.

Let’s imagine we have another key data field we want to use to filter messages in SAP Integration Suite.

For example, suppose we want to filter messages by the incoming payload’s data field “CategoryID”.

We will add a new custom header parameter with the value of CategoryID extracted from the payload.

To set a custom header parameter, we need to create a Groovy script.

First, we will extract the required information from the payload, in this example, the CategoryID.

We will use an XPath expression with a Content Modifier to achieve this.

Then we have to set a new custom header property with the value of the category ID.

Now, from this Groovy script, we will set a custom header property named “productCategory” with the value of the exchange property “productCategory” that we set earlier using the Content Modifier.

Let’s process another product and see how the custom header property appears in the Message Monitor.

How do we now filter messages in the Integration Suite based on a custom header property?

In this example, let’s filter messages with Category ID 9.

To do this, add the Custom Header filter criteria by specifying the header property name and the corresponding value.

To summarise, filtering and monitoring messages in SAP Integration Suite can be challenging when dealing with multiple interfaces and large volumes of data. While standard search parameters like Message ID and Correlation ID provide basic filtering, they are often too technical for business-oriented monitoring. By leveraging standard header parameters such as SAP_ApplicationID, sender system, receiver system, and application type, you can add meaningful business context to your messages and enable more effective filtering in the Message Monitor.

💡 Tip

For scenarios requiring additional business-specific criteria, custom header parameters offer a great solution. By extracting values from the message payload and setting them as custom headers using Groovy scripts, you can filter messages based on business attributes, such as Order Number, Invoice Number, Article ID, etc.

This approach transforms the Integration Suite’s Message Monitor into a more intuitive and business-focused tool, allowing for faster filtering of messages, improved monitoring, and more efficient message tracking across your interfaces.

The post Message Filtering with Standard & Custom Headers in SAP Integration Suite appeared first on SAP Integration Hub.

In greenfield SAP S/4HANA implementations, it’s common to see the backend SAP system using either SOAP or OData APIs for integrations instead of iDocs. However, there is a significant difference in how messages are monitored and reprocessed in iDoc-based interfaces compared to those using SOAP and OData APIs.

The key differences between iDocs and SOAP/OData APIs in SAP S/4HANA lie in their communication patterns and technical behavior.

Key Differences Between iDocs and OData/SOAP APIs in SAP S4 HANA

Asynchronous iDocs vs Synchronous API

iDocs are asynchronous in nature, while OData APIs are synchronous. SOAP services can operate in either asynchronous or synchronous mode, depending on how they are configured.

Another important distinction is that iDocs are stateful, whereas web APIs like OData and SOAP are stateless. In simpler terms, OData APIs require an external request to be triggered, and there is always a request-response interaction. On the other hand, iDocs do not require an external trigger, SAP can push data out asynchronously without waiting for a request.

Interface Message Persistence in SAP S4 HANA

A major difference is in message persistence. iDoc messages are stored in the SAP system in database tables such as EDIDC, EDID4 and other EDIC tables, regardless of whether they result in success or failure. This means both successful and failed iDocs are persisted and can be monitored and analyzed at any time, as long as they are not archived. SAP customers can configure how long iDocs remain in the system, providing flexibility in message retention.

In contrast, for OData calls, only error messages are logged. Successful API calls are not persisted in the standard SAP system. For example, if a sales order is created in SAP S/4HANA using an OData API, only failed calls will appear in the error logs; successful messages are not visible in standard monitoring tools. To the best of my knowledge, there is no standard option to enable monitoring of successful OData calls in SAP S/4HANA.

However, for SOAP API calls, both successful and error messages are available in SAP S4 HANA, and you can monitor the messages using the transaction SRT_MONI.

Monitoring of OData/SOAP APIs vs iDocs in SAP S4 HANA

Due to the way messages are persisted, monitoring iDocs is straightforward. You can use transactions such as WE02 and WE05 to monitor iDocs easily. In many organizations, iDoc messages are retained for several months before older records are archived and removed from the system. As a result, monitoring iDoc-based interfaces in SAP is generally not a concern.

However, when it comes to OData APIs, the situation is different. Unfortunately, you can only see messages that end in error. If an OData call fails, it is logged and can be viewed in standard transactions /IWFND/ERROR_LOG, /IWFND/TRACES.

OData Message Selection Screen – Transaction IWFND/ERROR_LOG

But what if you want to check successful OData API calls? At the moment, this is not supported by standard SAP S4 HANA tools. There is no built-in way to trace successful OData API calls using standard monitoring transactions.

Only the erroneous OData calls are logged in SAP S4 HANA. You can see the error code, HTTP response code, time stamp, error description and other details related to the message in this transaction.

Select an OData message to drill down to further detail.

If you need to monitor successful API calls, one option is to leverage the Application Interface Framework (AIF). By building an AIF interface on top of the OData service, you can add logging and monitoring capabilities for both successful and failed calls but this requires custom development.

SOAP APIs you have the option of monitoring message directly in SAP S4 HANA using transaction SRT_MONI.

Here you can find the information such as processing statuses, interface or the SOAP API name, messages ID, and the timestamp of the SOAP messages processed. Notice, unlike the OData messages, both successful and error messages are available in SRT_MONI.

Automatic Message Reprocessing Limitations for OData API Based Interfaces

There are scenarios where an interface message fails due to an issue within the SAP S/4HANA system. For example, missing master data, incomplete configuration, document locked by another user at the time of message processing (locking issue), or other application-level errors relevant to SAP. In such cases, we are accustomed to fixing the root cause in SAP and then reprocessing the message directly within the SAP S4 HANA system.

However, due to the stateless and synchronous nature of OData services, it is not possible to simply reprocess failed OData messages automatically within SAP itself.

In iDoc-based scenarios, it is common to have scheduled background jobs that regularly scan for failed iDocs and automatically reprocess them. This kind of built-in, automated recovery mechanism is a standard feature of iDoc handling.

Unfortunately, this option does not exist for OData services. There is no native way to automatically reprocess failed OData messages via a background job in SAP periodically. Instead, you have to rely on other methods, which we will discuss later in the article.

However, for SOAP API based messages, you can reprocess messages using a batch job directly in SAP S4 HANA.

Workarounds for Monitoring Limitations in SAP S/4HANA

There are a few ways to overcome the message monitoring limitations in SAP S/4HANA, especially when it comes to tracing successful messages for OData and SOAP APIs.

Leverage SAP Application Interface Framework (AIF)

The first option is to leverage SAP Application Interface Framework (AIF) in S/4HANA. You can build an AIF interface for each API-based integration to log and monitor both successful and failed messages. However, this approach requires custom development. That said, it’s a good option when business users need visibility into interface processing from within SAP.

Monitoring capabilities of SAP Integration Suite

Another approach is to use the monitoring capabilities of SAP Integration Suite. In most SAP S/4HANA landscapes, a middleware is involved for managing integrations, and SAP Integration Suite (SAP IS) is often the preferred platform. You can use the message monitoring features of SAP Integration Suite (or any other middleware in use) to trace and log both successful and failed messages. You can also choose to store message payloads for high-priority interfaces.

If you’d like to learn SAP integration step by step, join my SAP Integration Suite course for Beginners, and start building real-world integration skills today.

Learn SAP Integration with me!

Access the SAP Integration Suite message monitor and you can find an overview of all the interfaces.

From there, you can drill down to each interface for further analysis.

Here you can find the request and reply payloads of the OData call.

Leverage SAP Cloud ALM (CALM)

Additionally, you can also leverage SAP Cloud ALM (CALM) for end-to-end interface monitoring, regardless of the technology used. CALM provides centralized monitoring and traceability across different systems. However, it’s important to note that message payloads are not logged in CALM. Only certain metadata and trace parameters are available for analysis.

How to Handle Message Reprocessing Requirements for OData and SOAP

When it comes to overcoming message reprocessing challenges in SAP S/4HANA, let’s look at the available options.

SOAP API Message Reprocessing

The easiest scenario to handle is with SOAP APIs. For both inbound and outbound interfaces; that is, messages coming into SAP as well as those going out, and for both asynchronous and synchronous SOAP APIs, you can reprocess messages directly in SAP using a standard program.

Even if the error originates in SAP Integration Suite, the SOAP error log still captures the message details in SAP S/4HANA. These logs are accessible via transaction SRT_MONI, which allows you to view and reprocess failed messages.

How to automate SOAP message reprocessing?

Because of this logging, it is also possible to automate the reprocessing of failed SOAP messages periodically within SAP via a batch job. You should be able to use the program “SRT_UTIL_RESTART” to set up a batch job to reprocess errornous messages automatically.

How to Reproceses OData APIs for Inbound Interfaces?

Let’s consider a scenario where the interface is inbound, and we are using an OData API to post data into SAP S/4HANA. In this case, messages are sent from an externally connected system, which acts as the message sender.

Since OData follows a request-reply pattern, the sender system must use the appropriate method, such as POST or PATCH to call the OData service and send the request along with the payload. SAP processes the request and returns a response, which includes the status of the message (success or failure), error codes in case of failure, and, if successful, the business document number (e.g., sales order number).

However, if there is an error on the SAP side, for example, due to missing configuration or master data, the failure is still communicated in the response. Because OData is stateless and synchronous, SAP S4 HANA independently reprocessing the erroneous message does not make sense, and reprocessing must be triggered from the sender system.

Alternatively, you can also implement a queue-based approach in SAP Integration Suite using JMS queues, allowing you to reprocess failed messages directly from the Integration Suite once the issue in SAP has been resolved.

Even though the root cause of the failure lies in SAP, there is no standard way to reprocess the message within SAP once the issue is resolved. The only option is to resend the request from the sender system or SAP Integration Suite.

Manually Reprocess Erronous OData Messages in SAP S4 HANA

However, there is an option to manually reprocess OData calls on the SAP S/4HANA side. You can use the “Replay” option in transaction IWFND/ERROR_LOG.

Note: The payload of the request can be edited, meaning the user can modify the data without any restrictions. This approach is not suitable for a production landscape, as users would be able to post data without proper control mechanisms.

Additionally, the response from the OData call will not reach SAP Integration Suite or the connected system, which can disrupt end-to-end integration scenarios.

Moreover, the view itself is quite technical, and you need to manually define the JSON message structure. This option may be appropriate for support users, system administrators, or specially authorized users for exceptional cases.

I hope this gave you a clear overview of how monitoring and automatic error reprocessing for SAP OData and SOAP APIs differ from iDoc-based interfaces. Due to the nature of API-based integrations, it’s important to design your interfaces thoughtfully, keeping these limitations and capabilities in mind.

If you’d like to learn SAP integration step by step, join my SAP Integration Suite course for Beginners, and start building real-world integration skills today.

Learn SAP Integration with me!

The post OData/SOAP API Message Monitoring and Reprocessing in SAP S4 HANA appeared first on SAP Integration Hub.

For example, imagine a scenario where you are connected to a database system and need to insert or update data records, where the order of SQL statements is important. This could be for order processing, delivery tracking, or financial document posting. In such cases, it is critical to maintain the correct sequence of message processing.

Messages should be processed in the order they are received. If a particular message fails, any subsequent messages should not be processed until the failed message is successfully retried and completed.

In this article, we will explore:

1. How Exclusive JMS queues in SAP Integration Suite enable EOIO processing

2. A step-by-step implementation and configuration guide using the JMS Exclusive queue option

Understanding EOIO and Other Message Processing Methods

Let’s understand the difference between EOIO and other message-processing techniques when it comes to SAP or system integration.

Best Effort (BE) – Messages are processed as they arrive, with no guarantee of order.

Exactly Once (EO) – Ensures a message is processed only once, avoiding duplication but without enforcing order.

Exactly Once In Order (EOIO) – Ensures that messages are processed in the exact sequence they were received and that no subsequent message is processed until the previous one is completed.

Can an Exclusive JMS Queue in SAP Integration Suite Achieve EOIO?

As of now, SAP Integration Suite provides two types of JMS queue options: Exclusive and Non-Exclusive.

JMS queues of type Exclusive cannot be processed by multiple worker nodes or multiple consumers. Messages in an Exclusive JMS queue can only be processed by a single node, ensuring in-order processing. The JMS sender adapter picks up and processes messages sequentially, from the oldest to the newest, in the exact order they were received.

If a message in the JMS queue fails to process, the messages that come after it will not be processed until the failed message is successfully retried and completed. This makes the Exclusive JMS queue a viable option for scenarios where message order is crucial or where EOIO (Exactly Once In Order) processing is required.

While Non-Exclusive JMS queues allow messages to be processed by multiple nodes or consumers, they do not guarantee the order of processing.

Sample iFlow with Exclusive and Non-Exclusive Queues

To demonstrate the difference in behavior between Non-Exclusive and Exclusive queues, I created the following integration flows:

Message Producer iFlow

• Flow 1 produces messages and places them in two queues: one in an Exclusive Queue (ProductQueueExclusive) and the other in a Non-Exclusive Queue (ProductQueue_NonExclusive).

Message Consumer iFlow(s)

• There are two JMS listeners (consumer iFlows): one retrieves messages from the Exclusive Queue, and the other retrieves messages from the Non-Exclusive Queue.

iFlow that Consumes Messages from JMS Exclusive Queue

iFlow that Consumes Messages from JMS Non-Exclusive Queue

Testing the Behavior of Exclusive vs Non-Exclusive JMS Queue Consumption

I have pushed the same 3 messages to both JMS queues. They are now waiting to be picked up and processed by the respective iFlows.

JMS Non-Exclusive Queue Consumer

In the Non-Exclusive queue, you will notice that the consumer picks up all the messages from the queue. In this example, all three messages are picked up and attempt to process them.

Hence, you see all messages in failed status as they cannot be moved to the target Cloud HANA DB, as the receiver system is offline.

JMS Exclusive Queue Consumer

However, in the Exclusive queue, only the first message that entered the queue is picked up for processing.

Other Considerations when Working with JMS Exclusive Queues

Header Parameter SAPJMSRetries is Not Available for Exclusive Queues

💡 Tip

We usually use the JMS header parameter SAPJMSRetries to determine how many times a message has been attempted for processing by the JMS sender adapter. Based on this, we can build logic to set a maximum number of retries and send the message to a Dead Letter Queue (DLQ) if SAPJMSRetries exceeds the defined limit. This is typically done to prevent endless message processing.

⚠️ Warning

However, the SAPJMSRetries header parameter is only available for Non-Exclusive queue consumers. If you are using an Exclusive queue, you cannot use the SAPJMSRetries header parameter.

What If the Adapter and Message Producer Do Not Support EOIO?

In my view, even if you use JMS Exclusive queues, EOIO in SAP Integration Suite cannot be guaranteed if the message producer does not ensure EOIO processing.

For example, if messages are produced by SAP S4 HANA and are being sent by the SOAP adapter, XI adapter, or HTTP adapter, and the sender-side adapter or SAP system does not guarantee that messages are received in the correct order to SAP Integration Suite, then we cannot ensure EOIO behavior for the end-to-end (E2E) scenario just by using a JMS queue.

Do Not Use Exclusive Queue for Everything.

⚠️ Warning

Notice that in exclusive JMS queues, if a message fails, all other messages that come afterward in the queue are not picked up for processing. One failure in a message can disable the processing of all subsequent messages.

That means a total failure of the entire message pipeline. Imagine you use an exclusive queue for delivery processing. Would you want to hold the processing of all deliveries just because one delivery fails to process?

Summary of EOIO Processing with JMS Queues in SAP Integration Suite

Unlike in SAP PI/PO, SAP Integration Suite did not initially have a standard mechanism for processing messages in EOIO (Exactly Once In Order) mode.

However, with the introduction of the “Access Type” feature in the JMS adapter, we now have the option to process messages in a FIFO sequence. By using an “Exclusive” JMS queue, messages can be picked and processed sequentially, from the first arrived to the last.

However, ensure that the message producer can guarantee EOIO; otherwise, maintaining the correct sequence may not be possible when you take the E2E integration.

The post EOIO Processing with JMS Exclusive Queues appeared first on SAP Integration Hub.

However, in the past, when consuming an API via the HTTP adapter, if the call failed, there were no built-in options to automatically retry the request. Instead, you had to rely on other techniques like asynchronous decoupling with JMS queues to retry failed messages in the HTTP receiver adapter.

That said, there are certain cases where an automatic retry from the adapter itself would be beneficial. For example, in a high-available system (HA), message failures can sometimes be temporary. In such cases, it would be advantageous for the adapter to automatically retry the request, improving reliability without additional manual intervention or overcomplicating the integration scenario. Additionally, you might be able to save some JMS resources in your tenant.

How the Retry Mechanism Works in HTTP Receiver Adapter

If an HTTP request fails with an unsuccessful status, such as 500, 404, or 420, and the retry option is not enabled, the message enters a failed status in SAP Integration Suite, and message processing ends there.

However, with the retry option enabled, if an HTTP request through the HTTP adapter fails, iFlow can automatically retrigger the message a certain number of times. When configuring the adapter, you can specify for which status codes you want the retry mechanism to activate.

The advantage is that for scenarios such as the receiver is temporarily unavailable, the business process will not be affected. The message can be automatically delivered with the next retry.

For example, HTTP status codes between 300 to 599 are considered error statuses. However, in the adapter settings, you can filter specific status codes for which the retry mechanism should be triggered.

The retry mechanism works as follows: If the initial message delivery fails, the message enters a “Processing” status, which you can see in the Message Monitor.

Then, based on the “Retry Interval (in seconds)” configured in the HTTP Receiver Adapter, the first retry attempt will be triggered after the specified interval. If that retry also fails, the mechanism will continue attempting to resend the message if you have configured “Retry Iterations” as more than 1.

The maximum number of retries can also be configured in the adapter. Currently, the maximum number of automatic retries is 3.

For example, if you set the “Retry Interval (in seconds)” to 10 seconds and “Retry Iterations” to 2, the message will be automatically retried every 10 seconds, for up to 2 times, after the initial failure.

Configuring the Retry Option in HTTP Receiver Adapter

One of the prerequisites for the Retry option is that you must have “Throw Exception On Failure” enabled in the adapter. This setting ensures that the message status in SAP Integration Suite goes into a failure state when the remote receiver (server) returns a failed response. Generally, this option allows you to receive all HTTP response codes from the remote server, regardless of their status.

Retry Failed Requests

This option enables automatic retries for failed messages in the HTTP adapter. By default, this option is disabled. When you enable it, the corresponding adapter configuration options, such as “HTTP Error Response Codes,” “Retry Interval (in seconds),” and “Retry Iterations” are also enabled.

In this example, I want the messages to be automatically reprocessed only if the response contains HTTP status codes 500, 404, or 420.

HTTP Error Response Codes

Here, you can provide a comma-separated list of HTTP error codes that should trigger the retry mechanism in the integration flow. The retry will not start for any other error statuses not specified in the configuration.

Retry Interval (in seconds)

This setting defines how long the integration flow must wait after each failed message delivery before retrying. The maximum retry interval is 60 seconds.

Retry Iterations

This option allows you to set the maximum number of retries for message delivery. The highest number of retries you can configure is 3.

Testing HTTP Automatic Retry Mecanisum in Action

When the interface is start processing for the first time, If an error status is received from the receiver, the message processing status changes to ‘Processing’.

Then, based on the configuration of the HTTP adapter, automatic retry starts. The first retry occurs after 60 seconds. Thereafter, the processing will restart every 60 seconds.

Once the interface processing reaches the maximum number of retries, in this example, 3, the message goes into error if the error still persists in the last retry.

Other Considerations When Implementing the HTTP Retry Mechanism

What if you have an exception subprocess in your iFlow?

If you use an exception subprocess, it is invoked only after all retry iterations configured in “Retry Iterations” are exhausted and the error continues to persist.

What if the retry instruction comes from the response of the target system?

If the target system provides reprocessing instructions in the “Retry-After” header parameter, the retry configuration set in the HTTP adapter is overwritten with the values received from the target system.

Keep these factors in mind when designing your iFlow with HTTP automatic retry enabled.

I hope you learned something new. To become confident in all the features of SAP Cloud Integration feature of SAP Integration Suite, join my online course.

The post Retry Failed Requests in HTTP Receiver Adapter – BTP IS appeared first on SAP Integration Hub.

The Persist step allows you to retain messages during processing, enabling access for later analysis. This feature proves essential when businesses need to prove which messages were received or sent at a specific time. While the Persist step doesn’t affect message processing, it plays a critical role in building reliable, traceable, and auditable integration solutions.

In this article, we’ll explore how the Persist step works, its use cases, data storage mechanics, and how to access stored messages in SAP CI (CPI).

What is the Use of Persist Step?

Auditing and Compliance

The Persist step in SAP Integration Suite CI (CPI) ensures message traceability by storing messages at key points within an integration flow. This creates an audit trail, making it easier to prove which data was sent or received at a specific time. Businesses can meet legal and regulatory compliance requirements by retaining messages for auditing purposes. Additionally, having a record of historical messages helps organizations demonstrate transparency during compliance checks and security assessments. This makes the Persist step essential for industries with strict regulatory frameworks such as finance, healthcare, and logistics.

Monitoring and Analysis

The Persist step in SAP CI (CPI) plays a crucial role in troubleshooting and error analysis by providing a way to track messages for root cause investigation when flows fail to function as expected. Persisted messages offer a snapshot of the exact payloads and metadata, allowing teams to conduct detailed debugging and pinpoint issues. Additionally, the ability to store messages provides operational transparency and improves monitoring of integration flows. By retaining these messages, teams can gain valuable insights into message processing, ensuring smoother operations and quicker resolutions for issues that arise. Persisted messages also enable teams to reprocess or simulate message flows, further supporting error resolution and operational continuity.

Unlike other data storage options in SAP Integration Suite like Data Stores, Variables, Queues, etc, persist messages are NOT meant to access during runtime. They are meant to access post-processing!

How the Persist Step Works

Typically, we place a Persist step after the Message Start Event to store the message when first received from the sender. They log the message again before or after the Send, Message End Event, or Request-Reply step to capture the message being sent to the receiver. This approach ensures that both incoming and outgoing messages are recorded, meeting auditing and compliance requirements.

However, you can use persist steps before or after any step in your integration flow as per your requirement.

Once the Persist step is executed, the stored message remains in the Message Store until it is accessed through the Cloud Integration OData API. Note that the message store has a disk space limit of 32 GB per tenant, so it’s important to manage storage effectively to avoid exceeding this limit.

How Data Is Stored

When the Persist step is used in SAP CI, the data (messages) is stored in the Message Store, which is a logical storage location within the SAP Cloud Platform Integration environment.

1. Logical Storage Location:

   • The Message Store acts as the storage container for persisted messages. This store is specifically designed to hold the messages that are captured by the Persist step at designated points within an integration flow.

2. Physical Storage Location:

   • The data is physically stored in the tenant database, which is shared with the Data Store in the SAP CI environment. This means that the data for messages is stored securely within the infrastructure of your SAP tenant.

However, there is a storage limit of 32 GB per tenant for all data in the Message Store, which includes persisted messages. It’s important to monitor storage usage to avoid hitting this limit, as exceeding it could impact the performance or availability of message storage.

How to Access Data Stored from a Persisit Step

Accessing persisted data in SAP CI requires the use of the Cloud Integration OData APIs, as there is no direct user interface option for retrieving messages from the Message Store. Here’s how you can access the stored messages:

Read Message Processing Log (MPL)

You can access Message Store Entries under Message Processing Log instance using the following URL endpoint.

https://<Cloud Integration host>/api/v1/MessageProcessingLogs('<Message ID>')/MessageStoreEntries

Example: https://mytenant.tmn.hci.eu1.hana.ondemand.com/api/v1/MessageProcessingLogs('ABCD-1234-EFG')/MessageStoreEntries

You can find the API documentation of MessageProcessingLogs here.

Read Message Store Entries

You can read individual persist messages (Message Store Entry) of a certain message ID as follows;

Each Persisited Message or Message Store Entry has a unique GUID (MessageStoreEntryId). Using this GUID, you can access the properties and messages stored as follows.

https://<Cloud Integration host>/api/v1/MessageStoreEntries('{MessageStoreEntryId}')

To access the message content of the persist message use the following URL;

https://<Cloud Integration host>/api/v1/MessageStoreEntries('{MessageStoreEntryId}')$value

You can find the MessageStore API documentation here.

Example Integration Flow with Two Persist Steps

I will create an integration flow that consumes invoice data from an API and enriches the data with product information.

Let’s imagine that ultimately, the invoices received are processed, and there is an IT auditing requirement to log the inbound message before data enrichment and the outbound message after data enrichment for future auditing purposes.

Here is the message before enrichment, we get the invoices from the Northwind OData service. At this point, we only have the Product ID.

Then we have the message enriched with Product information such as ProductName, CatafgoryID, UnitProice, etc. The respective product data is fetched from the Northwind OData API linking the <ProductID> element from entity Invoices and Products.

Sample iFlow with Two Persist Steps

Here first step is to get Invoices from OData API, then we persist the invoices XML. That is the first message milestone we want to persist or save to the tenant database.

Then we enrich the invoice information with respective product information by calling the Northwind OData API. After the invoice XML message has been enriched with product information, we persist the message again. This time the persisited message should have invoice information with additional product information.

Configuring Options of Persist Steps

Each persist step can be given a name so you can identify the message you are saving.

Persist Step 1 – Invoice List Before Data Enrichment

Since the first Persist Step saves the message before the data enrichment, I will call it “PersisitPreEnrich.” This will help me identify the stage of the message processing and at what point of the integration flow the message persisted—kind of like a milestone.

Persist Step 2 – Message After Data Enrichment

Similarly, the next persistence is after data is enriched. Therefore, I will name the Step ID as “PersisitPostEnrich”. These names will come in handy when you want to read the stored messages from Persist step.

If you have sensitive data, you can also enable the option “Encrypt Stored Message” to save the message encrypted. When you are reading the data, you will have to decrypt the message.

Test the iFlow and Persist the Messages

Here is the Message ID of the instance. We will need the Message ID to filter the messages persisted for this instance of the interface run.

How to Access the Peristed Messages

As we talked about, there is no graphical option provided by SAP Integration Suite to view or access saved messages. You have to make use of the standard OData APIs provided by SAP Cloud Integration (CI) to access the messages.

To read the messages stored, we have to read the “MessageStore” entries. Since we already have the MessageID of the instance, we can find what are all the MessageStore entries under the Message Processing Log (MPL) using the following OData endpoint.

https://<Cloud Integration Host>/api/v1/MessageProcessingLogs('<Message ID>')/MessageStoreEntries

Here you will notice that we have two messages persisted. One with step ID “PersisitPreEnrich” and the other one with “PersisitPostEnrich”, the same names we defined as the StepID of persisting steps in the iFlow.

Also, notice there is a unique ID for each MessageStore entry a Message GUID. Using this Message GUID, you can read individual Message Store entries in the following URL endpoint.

https://<Cloud Integration host>/api/v1/MessageStoreEntries('{MessageStoreEntryId}')

View the Message Content

Now to check the actual message content of each MessageStore entry or in other words the payload that was saved by each Persisit step ad “$value” to the end of the URL.

/MessageStoreEntries('{MessageStoreEntryId}')/$value

Message of Persisit Step ID – PersisitPreEnrich

Message of Persisit Step ID – PersisitPostEnrich

Limitations and Workarounds when Using Persist Step

Persist Step in SAP Cloud Integration only writes successfully processed messages to the Message Store. If a message processing fails, it is not stored by default.

The workaround is to catch exceptions in an exception subprocess and end the message processing in an Escalating End Event instead of an Error End Event.

Summary of Persisit Step in SAP Integration Suite CI (CPI)

The Persist step in SAP Cloud Integration (CI) enhances message traceability, auditing, and troubleshooting in integration scenarios. It stores messages at key points within an integration flow, enabling businesses to meet compliance requirements, conduct root cause analysis, and improve operational monitoring.

SAP CI securely stores persisted messages in the tenant’s Message Store, allowing access through OData APIs since no graphical interface exists. By strategically placing Persist steps in an integration flow, businesses create detailed audit trails, ensure data transparency, and support error resolution through stored message snapshots.

However, the Persist step stores messages only when processing succeeds.

This capability helps industries with strict regulatory demands build traceable and compliant integration solutions, making SAP CI a reliable platform for enterprise integration needs.

I hope you learned something new. To become confident in all the features of SAP Cloud Integration feature of SAP Integration Suite, join my online course.

The post Persist Step in SAP Integration Suite CI appeared first on SAP Integration Hub.

Over the years, SAP has continuously adapted its integration offerings to meet system integration needs, starting with on-premises solutions like SAP Process Integration (PI) and SAP Process Orchestration (PO). These middleware platforms were designed to connect SAP and non-SAP systems, enabling seamless business processes in traditional enterprise environments.

However, the rise of cloud computing, Software-as-a-Service (SaaS) applications, and the demand for agile, scalable, and real-time integrations brought about a significant paradigm shift. This led SAP to evolve its integration technology from the infrastructure-heavy on-premise PI/PO solutions to cloud-based Integration Platform-as-a-Service (iPaaS) models, starting with SAP HANA Cloud Integration (HCI) to SAP Cloud Platform Integration (CPI) and culminating in the SAP Integration Suite on BTP (Business Technology Platform)

This transition marks a fundamental shift in how businesses approach integration, emphasizing flexibility, scalability, and lower total cost of ownership (TCO), all while supporting hybrid and cloud-native architectures. This article explores the historical development of SAP’s middleware solutions, the key differences between on-premises PI/PO and modern cloud-based iPaaS tools, and the benefits of embracing this next generation of integration technologies.

Moreover, we will discuss the features of the SAP Integration Suite and SAP Cloud Platform Integration.

For us to understand the differences between XI, PI, PO, CPI and Integration Suite on BTP (Business Technology Platform) first, we need to look at the main functionaries of middleware and the difference between a traditional On-Premise Middleware and iPaaS Solution.

Key aspects of On-Premise Middleware (e.g., SAP PI/PO) versus iPaaS Solutions (e.g., SAP Integration Suite):

The evolution of integration technology within SAP has witnessed a significant shift over the last decade, as enterprises grapple with rapidly changing IT landscapes. Traditionally, SAP Process Integration (SAP PI) and SAP Process Orchestration (SAP PO) were the go-to middleware solutions for on-premises, application-to-application (A2A) and business-to-business (B2B) integration. These platforms, built on SAP’s NetWeaver architecture, served businesses well for years by enabling the seamless flow of data across SAP and non-SAP systems.

What is a Traditional Middleware:

A traditional middleware tries to cover system integration from requirements in the following key aspects,

• Connectivity: Which protocol to use – SOAP, FTP?

• Routing: Who are the receivers of the message – Multiple receivers? Condition-based routing?

• Transformation: What kind of conversion or mapping is required? XML to text?

• Runtime:  messages monitoring and security

• Workflow (BPM): How to execute a series of steps? Integration scenario with a Purchase Order approval process?

SAP has been able to cover all these areas successfully with SAP PI/PO middleware solution.

However, with the advent of cloud computing, the proliferation of SaaS applications, and the need for agile, scalable, and cost-effective integration, a paradigm shift occurred. Businesses now require faster, more flexible, and hybrid integration approaches that support modern cloud-native applications while still maintaining connections to legacy systems. This shift led to the rise of cloud-based Integration Platform-as-a-Service (iPaaS) solutions like SAP Cloud Platform Integration (CPI) and SAP Integration Suite.

These cloud-based middleware solutions represent a fundamental change in how organizations approach integration. Rather than the rigid, infrastructure-heavy setups of SAP PI/PO, iPaaS offers:

• Scalability: Elastic cloud infrastructure that grows with business needs.

• Agility: Rapid deployment of integration flows and easy adaptation to new business demands.

• Flexibility: Support for hybrid landscapes, including multi-cloud and on-premises systems.

• Cost Efficiency: Reduced capital expenditure (CapEx) and infrastructure management costs.

This transition reflects a broader trend towards cloud-first architectures, enabling businesses to embrace digital transformation, streamline operations, and enhance their competitive edge. In this new era of cloud-based integration, SAP’s iPaaS solutions are designed to meet the complex, dynamic integration needs of enterprises, paving the way for the future of digital connectivity.

SAP Integration Product History Overview and Key Milestones:

1. 2002: SAP XI – SAP’s first middleware solution focused on message-based integration.

2. 2007: SAP PI – Rebranded from XI, expanding integration capabilities within SAP and non-SAP environments.

3. 2011: SAP PO – Merging PI with BPM and BRM for full process orchestration and business rules management.

4. 2013: SAP HCI – SAP’s first cloud integration platform, focused on integrating cloud applications with on-premises systems.

5. 2017: SAP CPI – Rebranded HCI, expanding integration beyond SAP’s cloud products to include third-party applications.

6. 2020: SAP Integration Suite – A comprehensive iPaaS solution offering hybrid, multi-cloud, API-driven, and event-driven integration capabilities.

The Key Paradigm Shift from On-Premise to Cloud Integration

When SAP introduced SAP HCI and CPI, it marked a key paradigm shift in moving from traditional on-premise middleware solutions, like SAP PI/PO, to modern cloud-based iPaaS platforms.

This shift reflects the changing demands of businesses as they transition to hybrid and multi-cloud environments. On-premise solutions were infrastructure-heavy, rigid, and often required extensive manual management, while cloud-based integration platforms offer flexibility, scalability, and agility.

With features like API management, event-driven architectures, and pre-built connectors, cloud iPaaS solutions enable faster, more seamless integrations across diverse landscapes, aligning with the growing need for real-time data exchange and digital transformation.

Overview of SAP On-Premise Middleware Versions:

The first SAP eXchange Infrastructure (XI) was introduced in 2002 with version XI 2.0. This was a dual-stack option with ABAP and Java stacks. After a few versions of XI, SAP introduced SAP Process Integration (PI) 7.0. PI single stack only installation option was introduced with PI 7.3 in 2010. Finally, in 2011 SAP introduced PO (Process Orchestration) with version 7.31.

To understand the differences between these versions, let’s look at the major architectural changes of each.

SAP eXchange Infrastructure (XI) Architecture Overview:

• Launch: SAP introduces SAP XI as part of the SAP NetWeaver stack.

• Purpose: SAP’s first centralized integration platform for on-premise systems, designed to enable communication between SAP and non-SAP systems using a message-basedarchitecture.

• Key Features:• Message transformation and routing using adapters.
  • Integration of applications through a common integration engine.

SAP eXchange Infrastructure (XI) contains Adapter Engine (AE), Integration Engine (IE), and Business Process Engine (BPE). It was installed on a dual stack Netweaver installation with ABAP and Java stacks.

• AE – Adapter Engine

As the name suggests, the main purpose of this component was to provide connectivity functionality. Adapter engine provided capabilities of talking to different communication protocols using different adapters.

• IE – Integration Engine

SAP XI component which was responsible for transformation and routing of the messages. Integration Engine also provided a runtime to the message communication. In XI heavy message processing was done through IE as each message was routed, transformed and executed by this component.

• BPE – Business Process Engine

The engine which executess ccBPM (Cross Component Business Process Management) workflows. ccBPM is based on Business Process Execution Language (BPEL) and required a dual-stack installation as its runtime environment was on Web AS ABAP.

Drawbacks and Challenges with eXchange Infrastructure (XI):

One major drawback of XI is inefficient performance due to back and forth communication between components. Also due to the dual-stack architecture and multipole components, message persistence impacted the performance.

SAP Process Integration (PI) Architecture Overview:

• Launched: Early 2000s.

• Primary Use Case: Facilitates the exchange of information between SAP and non-SAP systems, typically in on-premises environments.

• Architecture: A middleware solution built on SAP NetWeaver, using an integration server and adapters to connect applications.

• Key Features:

  • Focuses on application-to-application (A2A) and business-to-business (B2B) communication.

  • Supports synchronous and asynchronous messaging.

  • Provides adapters for various protocols (e.g., HTTP, FTP, SOAP, and IDoc).

With SAP introducing Advanced Adapter Engine (AAE), PI was able to process messages end to end without Integration Engine (IE) runtime. This reduced the cross-communication between components and improved performance massively.

• AAE – Advanced Adapter Engine

AAE has capabilities to handle routing, transformation, and connectivity which were segregated into different components in SAP XI. Integration Configuration Object (ICO) was introduced for design time instead of traditional XI objects such as sender agreement, receiver determination, and receiver agreement. ICO made it possible to connect, transform and route messages in AAE without Integration Engine (IE) runtime. Also, dual-stack message persistence was eliminated since ICO scenarios were executed independently by AS Java.

Drawbacks and Challenges of PI with AAE

Although PI installation with AAE  enhanced performance in comparison with XI, still improvements were needed to extend connectivity and performance. AAE could only handle a limited set of connections and still required IE runtime for development and administrative purposes. Plus, the RNIF adapter and the CIDX were not available in AAE. Also, earlier versions of AAE did not include iDoc and HTTP adapters since they belonged to the ABAP stack. Moreover, BPE still required ABAP stack for runtime as it was ccBPM. As you notice, although performance was improved compared to XI, SAP couldn’t completely decouple the need for Integration Engine (IE).

• B2B Add-on

B2B add-on was also introduced to PI with versions PI 7.1. B2B comes with a set of B2B protocol adapters, converter modules, and B2B infrastructure services for serving the EDI integration needs of most industries.

• AEX -Advanced Adapter Engine Extended

Finally, with SAP PI 7.30 version SAP eliminated the need for Integration Engine (IE) and introduced the Advanced Adapter Extended (AEX). AEX is a single-engine which includes Enterprise Service Bus (ESB), Integration Directory (ID), and AAE capabilities. With AEX, PI became a Java AS-only installation and SAP completely decoupled the ABAP stack. Also with PI 7.3 SAP introduced the iDoc_AAE adapter and http_AAE which run on Java. The complete removal of the ABAP stack is a major change in the SAP PI architecture.

Drawbacks and Challenges of PI with AEX

Although PI with AEX improved performances by completely decoupling the ABAP stack and the need for Integration Engine (IE), it did not include Business Process Management (BPM) capabilities.

SAP Process Orchestration (PO) Overview:

• Launched: Around 2011, evolving from SAP PI.

• Primary Use Case: Enhances SAP PI with additional process orchestration capabilities, combining SAP PI with Business Process Management (BPM) and Business Rules Management (BRM).

• Architecture:

  • SAP PO is a bundled solution that includes SAP PI for integration, BPM for process automation, and BRM for managing business rules.

  • This enhances the ability to design, execute, and monitor processes across the enterprise.

• Key Features:

  • Complete end-to-end integration and orchestration platform.

  • Enables greater process automation and complex workflows.

  • Advanced monitoring capabilities and error handling.

  • Still primarily used for on-premises scenarios but supports hybrid approaches.

To overcome all these challenges with PI, SAP released Process Orchestration which was a Java-only installation. Yes! No ABAP stack installation was available from PO 7.31. Plus, with the new PO version SAP has added fully functional Netweaver Business Process Management (NW BPM) and Business Rule Management (BRM) which were fully executable on Java. Therefore, Process Orchestration (PO) is a combination of Process Integration (PI) with AEX, Business Process Management (BPM), and Business Rule Management (BRM) which only runs on Java.

• NW BPM – Netweaver Business Process Management

Unlike ccPBM, NW BPM runs on a Java-based environment called CE (Composite Environment). Also, NW BPM uses Business Process Model Notation (BPMN) language while ccBPM uses Business Process Execution Language (BPEL). Although ccBPM design time was on ABAP stack, you require Eclipse-based tool NWDS (Netweaver Development Studio) for NW BPM. Even if you have extensive experience in ccBPM, you need to start learning NW BPM from scratch.

• BRM – Business Rule Management

Business Rule Management (BRM) contains modeling capabilities targeting business analysts. Rules are owned by LoB, not by IT.

SAP HANA Cloud Integration (HCI)

• Introduction: Launched in 2013, SAP’s first cloud-based integration platform.

• Purpose: Designed to integrate SAP’s cloud applications (like SuccessFactors and Ariba) with on-premise SAP systems.

• Key Features:

  • Lightweight, cloud-native integration.

  • Pre-built integration content for SAP SaaS solutions.

  • Faster deployment for cloud-to-cloud and cloud-to-on-premise scenarios.

What is SAP Integration Suite and Cloud Platform Integration (CPI) Overview:

• Introduction: Rebranded from HCI in 2017 as part of SAP Cloud Platform (now SAP Business Technology Platform).

• Purpose: A cloud-based iPaaS solution offering expanded integration capabilities beyond SAP’s ecosystem, supporting third-party applications and hybrid landscapes.

• Key Features:

  • Pre-built integration flows (iFlows) for various use cases.

  • Integration of SAP cloud and non-SAP cloud applications.

  • Support for hybrid integration, connecting cloud and on-premise systems

SAP Integration Suite on BTP

• Introduction: Launched in 2020 as the evolution of CPI, part of SAP Business Technology Platform.

• Purpose: A comprehensive Integration Platform-as-a-Service (iPaaS) offering a full range of tools for hybrid, multi-cloud, and API-based integrations.

• Key Features:

  • API Management: Full lifecycle management of APIs.

  • Event Mesh: Support for event-driven architectures.

  • Open Connectors: Pre-built connectors for integrating third-party applications like Salesforce, ServiceNow, and more.

  • Low-code/No-code tools: Simplified integration for business users.

  • Hybrid Integration: Integration across on-premise, cloud, and multi-cloud environments.

SAP Integration Suite was formally known as SAP Cloud Platform Integration Suite (CPI). SAP Integration Suite is the Integration-Platform-as-a-Service offering from SAP. Organizations can acquire SAP Integration Suite features on a subscription basis. Since the integration platform services can be accessed via the internet, it greatly reduces the initial implementation costs for hardware and IT resources.

The following are the main features of the SAP Integration Suite;

• Cloud Integration

• Open Connectors

• API Management

• Event Mesh

• Integration Advisor

SAP Integration suite (CPI) is not a newer version of SAP PO. It is a new integration platform provided by SAP to address cloud-based integration requirements.

Cloud Integration

Cloud Integration feature provides a platform to build, deploy, and manage end-to-end integration scenarios in cloud-to-cloud, cloud-to-on-premise, and on-premise-to-on-premise domains.

Additionally, SAP has provided more than 2000+ prebuilt integration flows on A2A, B2B, and B2G processors that can be deployed with the minimum development effort.

Open Connectors

The open connector capability of the SAP Integration Suite standardizes the connectivity to third-party cloud applications. SAP has provided more than 160+ pre-built connectors to none-SAP cloud applications such as Shopify, ADP, SalesCloud, Workday, etc. Developers can easily reuse these prebuilt connectors to establish connections to third-party cloud applications. You can find a full list of open connectors here.

API Management

API Management is the feature that provides a platform to build, analyze, publish and monetize APIs.

Event Mesh

The event mesh makes use of event-driven architecture for integration. This greatly reduces having to have peer-to-peer connections. Organizations have the option to publish their business events in a data lake or data queue for multiple data receivers to consume.

You can read more details of SAP Integration Suite in the linked article. Moreover, we are written an article that discusses what to consider when migrating from SAP PI/PO to CPI.

Summary of the Evolution of SAP Integration Offering:

The transition from SAP XI to SAP Integration Suite reflects a major evolution in SAP’s middleware strategy, driven by changing business needs and the shift toward cloud-first architectures. SAP’s traditional on-premises solutions (PI/PO) have given way to flexible, scalable, and comprehensive iPaaS offerings like SAP Integration Suite, which cater to modern enterprises dealing with hybrid landscapes, API management, and event-driven architectures. This shift not only supports digital transformation but also positions SAP as a leader in integrating complex, multi-cloud, and dynamic business environments.

I hope you were able to visualize the evolution of SAP middleware. By looking at the history of changes to SAP middleware architecture from XI to PI to PO, you can see the reasoning behind these changes.

Additionally, we discussed the features of SAP Integration Suite and CPI.

If you have any more questions comment below!

The post What is the Difference Between SAP PI, PO, CPI and Integration Suite? appeared first on SAP Integration Hub.

For example, EDI segments ISA.13 (Interchange Control Number), ST.02 (Transaction Set Control Number) or IEA.02 (Interchange Control Number) are a few segments where unique sequence numbers are required. Not only these Control Numbers, but you can assign a unique number to any element of the message using Number Ranges. Another use case is setting a unique number to part of the generated file name.

In SAP Integration Suite (BTP-IS/CI/CPI) and SAP PI/PO, managing these interchange control numbers efficiently is essential for ensuring seamless EDI communication. This is where Number Range Objects come in. By using number range objects, BTP-IS-CI can generate and assign unique ICNs for every interchange, ensuring that each transmission is properly tracked and handled.

In this blog post, we’ll discuss how to use Number Range Objects in SAP CPI and SAP PI/PO, and explore different methods to retrieve or generate these numbers. The unique number allows us to avoid common issues like duplicates and facilitates traceability of EDI messages.

Steps to Configure a Number Range in SAP Integration Suite (BTP-IS/CI/CPI)

Practical EDI Integration Usecase Scenario

In this scenario, you receive a bulk EDI message containing multiple individual transactions (e.g., multiple purchase orders or invoices bundled together) to SAP Integration Suite. To process these efficiently, you first need to split the bulk message into individual transactions using an EDI splitter in SAP Integration Suite. Once the transactions are split, each one must be acknowledged with a Functional Acknowledgement (FA), such as a 997 in ANSI X12 or CONTRL in EDIFACT, which confirms receipt and validates the syntactical correctness of each transaction. To ensure each FA is unique and traceable, a unique control number must be assigned to each generated FA.

You can copy over the Control Number of the incoming EDI message and assign it to the FA generated. Or you can define a Unique Number Range and assign the Control Number from that. In this example, we will use the latter.

Understand the Pattern of the Number Range

• The ISA13 element holds the Interchange Control Number, which is a 9-digit numeric value.

• It is padded with leading zeros if necessary to ensure it is always 9 digits long.

ISA*00* *00* *ZZ*SENDERID *ZZ*RECEIVERID *211013*1200*U*00401*000012345*0*P*>~

In this sample ISA segment, 000012345 is the ICN. If you assign the value as 12345, it becomes an invalid EDI message.

Create a Number Range in the Integration Suite

Go to SAP Integration Suite and select the Option Number Range.

Create a new Number Range by using the option “Add“.

Assign a meaningful name and define the Minumum Value and Maximum Value of the Number Range. Also, configure the Field Length, in this scenario 9 digits.

I will also activate the option “Rotate” so when the number range reaches the maximum value of 999999999, it starts back up from the minimum value, zero.

Configure the EDI Splitter and Configure the Interchange Number Option

Now I have activated the option to “Create Acknowledgment” to Required so EDI splitter generates FAs after splitting the bulk EDI file.

I have set the “Interchange Number” option to “Number Range” and provided the name of the number range object I generated in the above step.

Test the EDI Interface

Let’s trigger the interface with multiple transactions in the incoming EDI message body.

Notice the ISA Control Number of the FA 997 assigned from the Number Range.

The number Range Status will be changed and it will show the next number inline.

Steps to Configure Number Range Objects in SAP PI/PO

• Create the Number Range Object in B2B home.

• Call the number range in message mapping and map the value to the target field.

• Configure the receiver adapter modules to call the number range.

Let us look at these three steps in detail.

Step 1: Create the Number Range Object (NRO) in B2B Home

You should be able to access Netweaver B2B Integration Cockpit home using URL http://<host>:<port>/b2bic

Go to Number Range Object (NRO) Maintenance under B2B Home

Provide the essential parameters such as NRO name, minimum value, maximum value, and number range length.

Step 2: Call the Number Range Object in Message Mapping and Map the Values to Target Field.

The number range should be mapped to the target field as below. Use a Constant to assign with the value in the format ‘$B2B_UEBNR<Number Range Name>$B2B_END_UEBNR’.

Assume our number Range Object (NRO) name is OTC377_BSN02.

Constant value should be configured as “$B2B_UEBNROTC377_BSN02$B2B_END_UEBNR”.

Step 3: Configure the Receiver Adapter Modules to Execute the Number Range Object.

In the receiver communication channel include the module “TransmissionNumberModule” with module key “NRO”.

If you have any question about Number Range Objects, please leave a comment below.

The post Number Range Objects for EDI in SAP Integration Suite (BTP-IS, CPI, PI/PO) appeared first on SAP Integration Hub.

Additionally, SFTP adapter configuration to connect with an On-Premise SFTP Server in SAP Integration Suite .

Part 1 - SAP Integration Suite

In this article, We will look at the following steps to establish a connection to an SFTP in SAP Integration Suite (BTP-IS/CI/CPI)

1. Prerequisites to Setting Up the SFTP Connection

2. Register the On-Premise SFTP Server on Cloud Connector

3. Ping and Test the Connection to the SFTP Server

4. Append the Known Host File with the Server Key

5. Maintain Security Material

6. Configure the SFTP Adapter

Part 2 - SAP PI/PO

Moreover, We will look at these settings in SFTP Adapter of PI/PO,

1. SFTP Adapter Transport Protocol, Message Protocol, and Adapter Engine Configuration.

2. SFTP Receiver Server Destination Configuration.

3. Authentication Methods of SFTP Channel.

4. SFTP File Name and Directory Configuration.

5. SFTP Processing Parameters, Timestamp to File Name, Message-ID to File Name, Write Mode, etc.

6. Run Operating System (OS) Command in Receiver SFTP Adapter.

7. Advance Variable Substitution for SFTP File Path and File Name.

8. Adapter Specific Message Attributes (ASMA) of SFTP Receiver Communication Channel.

9. Communication Channel Adapter Status.

10. File Archiving technique.

You can also connect SAP directly with FTP file server and create files.

Part 1 - SFTP Adapter Configuration in SAP Integration Suite

Let’s understand what kind of SFTP Servers SAP Integration Suite can connect to and different authentication methods. Then we will look at how to establish connectivity to an On-Premise SFTP server from SAP Integration Suite CI.

Understand the Type of SFTP Server

SAP CPI supports connecting to various types of SFTP servers, as long as they comply with standard SFTP protocols and are configured appropriately.

Here are the key types of SFTP servers that can be connected via SAP CPI:

1. On-Premise SFTP Servers

These are SFTP servers hosted within an organization’s internal data centers or IT infrastructure or in a private cloud environment.

• Connectivity: To connect CPI to an on-premise SFTP server, CPI needs to access it via a cloud connector or reverse proxy to establish the connection between the cloud (SAP CPI) and the on-premise network.

💡 Tip

On-premise systems are not limited to systems hosted within your organization's private IT infrastructure. They also include systems hosted in private cloud environments that are not exposed to the public internet.

2. Cloud-based SFTP Servers

These are SFTP servers hosted by cloud providers, offering secure file transfer services over the internet.

• Popular Cloud SFTP Providers:

  • AWS Transfer for SFTP (Amazon S3): AWS provides an SFTP service for transferring files into S3 storage.

  • Azure SFTP (Azure Blob Storage): Azure offers secure file transfer capabilities for storage solutions like Blob.

  • Google Cloud SFTP: Google Cloud Platform (GCP) provides a secure way to manage file transfers into their cloud storage.

  • Other Managed Services: Providers like ExaVault, Files.com, etc., provide fully managed SFTP services.

• Connectivity: CPI can connect directly to these servers over the internet.

SFTP Authentication Options in SAP Integration Suite CI

Authentication can be done using Username/password or public key authentication. Also, you can use a combination of both.

Steps to Connect an On-Premise SFTP Server on SAP Integration Suite

Prerequisites to Setting Up the Connection

1. SAP Cloud Connector is installed and configured to connect your on-premise network with the SAP Cloud Platform.

1. SFTP Server Credentials: Obtain the necessary credentials to connect to the SFTP server (username/password or public/private key pair).

2. Public Key: If using public key authentication, generate the key pair and upload the public key to the SFTP server.

Step 1- Register the On-Premise SFTP Server on Cloud Connector

Log in to the Cloud Connector. Go to “Cloud to On-Premise” in the left-hand menu. Click “Add” and choose “Non-SAP System”.

• Back-End Type: Select “SFTP”.

• Protocol: Choose “TCP”.

• Internal Host: Set the internal hostname or IP address of your on-premise SFTP server.

• Virtual Host: Define a preferred virtual hostname.

• Internal/Virtual Port: Typically, SFTP uses port 22.

Click “Check Connection” to ensure the Cloud Connector can reach the on-premise SFTP server.

Step 2 – Ping and Test the Connection to the SFTP Server

Open Connectivity Tests:

This tool allows you to test connections to various protocols, including SFTP.

In the Monitor section, go to Manage Security → Connectivity Tests.

Enter the SFTP Connection Details:

• Host: Enter the hostname or IP address of the SFTP server.

• Port: Typically, the default port for SFTP is 22, but you may need to change this if your server uses a different port.

• Authentication: Choose the appropriate authentication method:

  • User Credentials: If using username/password authentication, enter the username and password.

  • Private Key: If using key-based authentication, upload the private key or reference it if it’s already stored in the Security Material.

Copy the Host Key:

I will keep the authentication as “None” to just ping the server and get the Host Key. Hit “Send” and check the response. If there are no issues, you will be able to copy the Host Key of the server using “Copy Host Key” option.

You can save the Host Key copied from the above step for later use.

Step 3 – Append the Known Host File with the Server Key

Usually, a running system should have a Known Host file already. Download the Known Host file and append the Host Key of the SFTP server copied from above step to the bottom of the file. Then upload the file again to the Security Material using the “Upload” option.

If you do not have a Known Host file, you can directly upload the file with the Host Key entry.

⚠️ Important

Always download the existing Known Hosts file first, then apend the new host entry to the end of the file before uploading it again. Do not upload a file containing only the new host entry. Uploading a Known Hosts file replaces the entire list, so any existing entries that are not included in the uploaded file will be deleted.

Be especially careful when performing this task in the Production environment.

Maintain Security Material

Here I am using username/password for authentication. The security details should be maintained as Security Material.

Go to “Manage Security” and “Security Material”

Maintain the username and password and give it a meaningful name (identifier).

Configure the SFTP Adapter

Now configure the SFTP receiver adapter.

• Address: The SFTP server’s hostname or IP address. Provide the virtual host name we configured before

• Port: The port used by the SFTP server (default is 22).

• Location ID: Location ID configured in Cloud Connector. We defined it as “LOC2” in Cloud Connector, which is one of the prerequisites.

• Credential Name: Refers to the credentials deployed in the Security Material section of the tenant in the above step. In this example, my-sftp-user.

• Directory: The directory path on the SFTP server where files will be uploaded (e.g., /Processed Orders).

• Filename: The name of the file that will be written to the SFTP server. You can use expressions like ${propertyName} or ${headerName} to dynamically generate the filename.

Write Mode

• Overwrite: If the file already exists, it will be overwritten.

• Append: Data will be appended to the file if it exists.

• Create New: A new file will be created with a unique name (e.g., by appending a timestamp).

Processing Mode

• Binary/Text Mode: Specifies whether the file is transferred as binary or text.

• File Type:

  • Binary for binary files.

  • Text for plain text files.

Timeout

• Connection Timeout: Specifies how long (in milliseconds) to wait for the SFTP server to respond before timing out (e.g., 60000 ms = 60 seconds).

Part 2 - SFTP Adapter Transport Protocol, Message Protocol and Adapter Engine Configuration in SAP PI/PO

Adapter type ‘SFTP’ has only one Transport Protocol which is ‘SFTP’ itself. Depending on your PI/PO version you can configure the Adapter Engine. Usually, the default Adapter Engine is ‘Central Adapter Engine’ and it will be populated automatically.

Message Protocol – File Content Conversion.

If the target message (file) created by Message Mapping needs to be converted by the Receiver Adapter Communication Channel select the option ‘File Content Conversion‘. Usually, if the receiver file format is anything other than XML, you can use this feature to convert the file to an appropriate format such as CSV, Text, etc.

SFTP Receiver Server Destination Configuration.

Server

Defines the TCP/IP of the SFTP server. It can be configured as a hostname or IP address.

Port

The default SFTP port is ’22’. This Parameter defines the Port of the SFTP server.

Timeout (ms)

The timeout parameter defines how long the transmitted file remains unacknowledged by the receiver SFTP server. After the defined time (ms), when the receiver Communication Channel terminates the connection, set the message to error status and log the error in Message Log.

Server Fingerprint

When you connect to the SFTP server for the first time using any SFTP/FTP clients such as FileZilla, WinSCP, etc., Server Fingerprint will be promoted.

Authentication Methods of SFTP Channel.

There are three Authentication Methods in the sFTP adapter:

• Password

• Private Key

• Duel Authentication

SFTP Authentication Method ‘Password’.

The password method authenticates the connection with the sFTP server using the Username Password combination.

SFTP Authentication Method ‘Private Key’.

Authentication using ‘Private Key‘ method allows us to connect to sFTP server more securely. During design time, system administrators of PI/PO system and sFTP server owners should exchange respective ‘Public Keys’ and install them. Public Key of sFTP host should be installed in PI/PO server and vice versa.

System Administrators (BASIS) maintain the SSH keys in Key Store under ‘Certificates and Keys‘ section of ‘Netweaver Administrator‘

SAP Netweaver Administrator > Configuration > Security > Certificates and Keys.

In older versions of SAP PI or XI key store can be accessed under,

NWA > Configuration Management > Security > Certificates and Keys > Key Storage > Content > Keystore Views.

What we configure with Private Key View and Private Key Entry parameters is the SAP PI/PO’s Private Key information. During the system setup (configuration) only Public Keys of the servers are exchanged and installed. At the time of actual connection or handshake with SFTP, Private Key configured in the Communication Channel and Public Key installed in SFTP combination decrypt the data and allow the connection.

Username is the SFTP username.

SFTP Authentication Method ‘Duel Authentication’.

This is simply a combination of ‘Password‘-based authentication and ‘Private Key‘-based authentication.

SFTP File Name and Directory Configuration.

There are several ways to configure the File Name and Directory of receiver files. You can do it by using parameters in the receiver Communication Channel or set the file names dynamically at run-time.

The configuration above defines the receiver file name as ‘test.xml‘, and files will be generated in the directory ‘/home/username/in/test/’. Prefix ‘~’ defines the home directory of the user configured in ‘Authentication Method’.

You can also define a directory without the prefix ‘~’.

You can set the filename and directory dynamically using any of the methods below. Check my previous posts on in-detail examples of each method.

• Set the filename and directory using a User Defined Function (UDF)

• Using Adapter Specific Message Attributes (ASMA)

• Variable Substitution

SFTP Processing Parameters, Timestamp to File Name, Message-ID to File Name, Write Mode, etc.

Add Timestamp to filename.

Add the timestamp in format YYYYMMDD_HHMMSS-xxx before the extension of the filename. If the configuration is activated and File Name parameter is set as ‘Test_.XML’, the name of the receiver files will be set as Test_YYYYMMDD_HHMMSS-xxx.XML. ‘xxx’ is a random sequence number generated by Adapter Engine.

Add Message-ID to file name.

Add the PI Message ID to the file name. This is a great way to avoid overwriting files at the receiver by keeping the file name unique.

Write Mode — Direct.

Files are written directly to the specified folder in File Parameter’s Directory.

Write Mode — Temporary Mode.

Files are written at the receiver under temporary names before being converted to the specified format in the Communication Channel. Even with a timestamp in the filename, there is a possibility of overwriting files when large number of files are generated at the same time (same second). This is the best method to use if there is a chance of receiver picking up the files and processing them while they are being generated by PI/PO. Temporary mode creates each file with a unique name and changes the filename to specified format after file generation is completed.

In Temporary File mode, file names are first set as <timestamp><file name>.tmp. The time stamp here is up to a millisecond.

Empty File Handling.

Setting this parameter as ‘Write Empty File‘ will allow you to create empty file in the target directory. Otherwise set it as ‘Ignore‘ so empty files are not created at the receiver directory.

Store Attachments.

Allow the adapter to save attachments in the PI message and in the target directory.

Run Operating System (OS) Command in Receiver sFTP Adapter.

These two parameters allow us to run OS commands before and after message processing. OS scripts should be defined in Command Line parameter.

Advance Variable Substitution for SFTP File Path and File Name.

Parameters defined in ‘Filename’ or ‘Directory’ can be replaced by message payload attributes using this option. For example, replace the file name with a field value from a target message (after Message Mapping). Check out my previous post on how to set the Purchase Order number in the target message to file name using the Variable Substitution method.

Enable Security Check if you want to validate the Directory path for characters such as ‘.’, ‘\’, ‘/‘. If these characters are found after the variable substitution, message is set to error.

Adapter Specific Message Attributes (ASMA) of SFTP Receiver Communication Channel.

Filename and Directory can be copied from the incoming message using ASMA. SFTP Adaper Specific Message Attributes are included under namespace ‘http://sap.com/xi/XI/System’.

In order to use these attributes, you also need to set ASMA in the sender adapter Communication Channel.

Go to message content’s Dynamic Configuration to view these attributes.

Notice the FileName and Directory attributes under “http://sap.com/xi/XI/System/File” namespace. These are automatically set from Sender sFTP Adapter Communication Channel when ASMA is activated. Use them in the Receiver Adapter using Dynamic File Name generation methods.

<?xml version="1.0" encoding="utf-8" ?>
<sap:DynamicConfiguration xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" xmlns:sap="http://sap.com/xi/XI/Message/30">
<sap:Record namespace="http://sap.com/xi/XI/Message/30/routing" name="SourceMessageType"/>
<sap:Record namespace="http://sap.com/xi/XI/System/File" name="Directory">/out/test/</sap:Record>
<sap:Record namespace="http://sap.com/xi/XI/Message/30/routing" name="InterfaceDeterminationHash">60fde8e2912f3f0ae7109f852b1f7f08</sap:Record>
<sap:Record namespace="http://sap.com/xi/XI/Message/30/routing" name="SourceMessageTypeNS"/>
<sap:Record namespace="http://sap.com/xi/XI/Message/30/routing" name="InterfaceFromOperation"/>
<sap:Record namespace="http://sap.com/xi/XI/Message/30/general" name="senderAgreementGUID">11ce9cb7133b3e50a27ac679e2e0772b</sap:Record>
<sap:Record namespace="http://sap.com/xi/XI/System/File" name="FileName">test_20190223-133040-125.xml</sap:Record>
</sap:DynamicConfiguration>

Communication Channel Adapter Status.

If adapter status is ‘Active“, adapter is allowed to exchange messages. If the status is ‘Inactive‘, Communication Channel is blocked from exchanging messages.

Archiving of Files.

Archiving configuration allows you to save the files in your PI/PO server. Archive Name parameter defines the location (Directory) of the archive files saved.

Use these substitution parameters to define the Archive location of the PI/PO server.

• %SEQNUM: A sequence number, starting with 1

• %RTSEQNUM: A server wide sequence number, starting with 1

• %START: The start time of the adapter

• %TIME: The archiving period in milliseconds

• %MSGID: The XI message ID

if you have any questions on SFTP receiver Adapter configuration or any of the parameters of the Communication Channel, please leave a comment below.

The post Receiver SFTP Adapter Configuration – SAP Integration Suite CPI and PI/PO appeared first on SAP Integration Hub.

SAP Versions used in the illustration:

• SAP S4 HANA

Introduction to Base64 Algorithm.

Base64 schema is a text representation of Binary data. It is mainly used to transmit large files or data over the web or between applications without data being corrupted.

For example, Base64 representation of a sentence,

‘Welcome to SAP Integration Hub.‘ is

‘V2VsY29tZSB0byBTQVAgSW50ZWdyYXRpb24gSHViLg==‘.

Base64 Encoding Algorithm Flow Overview.

ASCII code represents data in 8 Bits. Base64 algorithm first groups Bits array of ASCII code into 4 groups of 6 bits each. Then each group of 6 bits is again mapped to Base64 code. The name “Base64” comes from the groups of 6 bits each. 2 to the power 6 is 64, hence the name Base64.

Illustration of the Base64 Encoding Algorithm

Text ‘SAP’ in Base64 is represented as ‘U0FQ’. Let’s look at how algorithm converts the text into the Base64 format.

Input text is,

‘SAP‘.

Text ‘SAP‘ in ASCII code is represented by,

‘83 65 80‘.

Binary representation of the ASCII code above is,

‘01010011 01000001 01010000‘.

Now group the complete bit array to groups of 6 bits.

010100|110100|000101|010000

Now convert each group of 6 bits to numeric.

20 | 52 |5 |16

Map each numeric value to Base64 character using the Encoding table below. 20 is ‘U’, 52 is ‘0’, etc. Full representation of 20 | 52 |5 |16 is,

U|0|F|Q

While Encoding happens from the top down as shown in the example above, Decoding happens from the bottom up. You can use this tool to Encode and this one to decode online.

Use Cases of Base64 in SAP Integration Scenarios.

Base64 is a great way to transfer XML, PDF, Text, and Image files among SAP applications, web services, and SAP APIs. When APIs don’t have the capabilities to transfer large files as attachments, use Base64 Encoded string to transfer data between systems.

In outbound scenarios, use this method to transfer Files generated in the SAP application server (AL11) between AIF (Application Integration Framework) and SAP Process Orchestration (PI/PO) using ABAP Proxies. You can find more information about AIF custom functions in this article. Convert the Files generated by SAP to Base64 and assign the Base64 value to the ABAP Proxy message. Implement a Java Mapping in PI/PO to decode the Base64 string back to text format. For example, Payment Data XMLs generated by SAP standard Payment Run (F110) can be transferred to PI/PO using an ABAP proxy in Base64 format.

For inbound scenarios, use the Base64 decoding method to process files imported to SAP via web services or PI/PO. You can directly process this data in SAP ABAP programs without saving them in AL11. Or, if the Files should be processed by SAP standard programs, save the file in AL11 and call the SAP standard program using ABAP keyword SUBMIT. For example, Electronic Bank Statements that are transferred from Banks through PI/PO can then be sent to SAP through ABAP proxy.

ABAP Function Modules to Encode Text to Base64.

Let’s encode String to Base64 format using ABAP Function Modules ‘SCMS_STRING_TO_XSTRING’ and ‘ SCMS_BASE64_ENCODE_STR’.

The first step is to convert the string (text) to XString. XSTRING is a predefined byte-like ABAP type with variable length which holds the value in Hexdecimal format. Usually Xstring type is used when we need to transfer heavy files such as XMLs, PDFs, etc. between SAP ABAP and Java applications.

Step 1: Use Functional Module SCMS_STRING_TO_XSTRING to Convert String to Xstring.

*Convert string to xstring

     CALL FUNCTION 'SCMS_STRING_TO_XSTRING'
      EXPORTING
        text   = p_input
      IMPORTING
        buffer = lv_xstring
      EXCEPTIONS
        failed = 1
        OTHERS = 2.

Step 2: Use FM ‘SCMS_BASE64_ENCODE_STR’ to Convert the Xstring to Base64.

*Convert XString to Base64

CALL FUNCTION 'SCMS_BASE64_ENCODE_STR'
        EXPORTING
          input  = lv_xstring
        IMPORTING
          output = lv_base64.

ABAP Function Modules to Decode Base64 to String.

Decoding of the Base64 format to String is done in three steps. First, we will convert the Base64 format to XString using ‘SCMS_BASE64_DECODE_STR’. Then, XString is converted to Binary using Function Module ‘SCMS_XSTRING_TO_BINARY’. Finally, Binary value is decoded to actual Text or String value using Function Module ‘SCMS_BINARY_TO_STRING’.

Step 1: Convert Base64 String XString Using Function Module ‘SCMS_BASE64_DECODE_STR’.

*Convert Base64 string to XString.

    CALL FUNCTION 'SCMS_BASE64_DECODE_STR'
      EXPORTING
        INPUT          = p_input
     IMPORTING
       OUTPUT         = lv_xstring
     EXCEPTIONS
       FAILED         = 1
       OTHERS         = 2.

Step 2: Convert Xstring to Binary ‘SCMS_XSTRING_TO_BINARY’.

Table’s parameter ‘binary_tab’ outputs the Xstring in Binary format.

*Convert Text to Binary

    CALL FUNCTION 'SCMS_XSTRING_TO_BINARY'
      EXPORTING
        buffer        = lv_xstring
      IMPORTING
        output_length = lv_len
      TABLES
        binary_tab    = lt_content[].

Step 3: Decode the Binary to Text (String) Format Using FM ‘SCMS_BINARY_TO_STRING’.

Exporting parameter ‘text_buffer’ of the Functional Module ‘SCMS_BINARY_TO_STRING’ outputs the decoded text value.

*Convert Binary to String

    CALL FUNCTION 'SCMS_BINARY_TO_STRING'
      EXPORTING
        input_length = lv_len
      IMPORTING
        text_buffer  = lv_string
      TABLES
        binary_tab   = lt_content[]
      EXCEPTIONS
        failed       = 1
        OTHERS       = 2.

ABAP Program Encode and Decode Base64 format.

The program has three selection screen parameters, one input parameter to enter either the Text that should be Encoded or the Base64 string which should be decoded with options to select either Encode or Decode.

Select either Decode or Encode functions, depending on your input string.

Encoded or Decoded output is written into output screen.

ABAP Program Code for Base64 Conversion using FMs.

*&---------------------------------------------------------------------*
*& Report ZBASE64_ENCODE_DECODE
*&---------------------------------------------------------------------*
*&
*&---------------------------------------------------------------------*
REPORT ZBASE64_ENCODE_DECODE.

Data: lv_xstring  TYPE xstring,       "Xstring
      lv_len TYPE i,                  "Length
      lt_content  TYPE soli_tab,      "Content
      lv_string   TYPE string,        "Text
      lv_base64   TYPE string.        "Base64

SELECTION-SCREEN BEGIN OF BLOCK IN1 WITH FRAME TITLE TEXT-t01.
PARAMETERS: p_input type string OBLIGATORY LOWER CASE.
SELECTION-SCREEN END OF BLOCK IN1.

SELECTION-SCREEN BEGIN OF BLOCK IN2 WITH FRAME TITLE TEXT-t02.
PARAMETERS: p_encode RADIOBUTTON GROUP rb1 USER-COMMAND grb1 DEFAULT 'X',
            p_decode RADIOBUTTON GROUP rb1.
SELECTION-SCREEN END OF BLOCK IN2.

CASE 'X'.
  WHEN p_encode.

*Convert string to xstring

     CALL FUNCTION 'SCMS_STRING_TO_XSTRING'
      EXPORTING
        text   = p_input
      IMPORTING
        buffer = lv_xstring
      EXCEPTIONS
        failed = 1
        OTHERS = 2.

*Find the number of bites of xstring

      lv_len  = xstrlen( lv_xstring ).

      CALL FUNCTION 'SCMS_BASE64_ENCODE_STR'
        EXPORTING
          input  = lv_xstring
        IMPORTING
          output = lv_base64.

  WHEN p_decode.

*Convert Base64 string to XString.

    CALL FUNCTION 'SCMS_BASE64_DECODE_STR'
      EXPORTING
        INPUT          = p_input
     IMPORTING
       OUTPUT         = lv_xstring
     EXCEPTIONS
       FAILED         = 1
       OTHERS         = 2.

*Convert Text to Binary
    CALL FUNCTION 'SCMS_XSTRING_TO_BINARY'
      EXPORTING
        buffer        = lv_xstring
      IMPORTING
        output_length = lv_len
      TABLES
        binary_tab    = lt_content[].

*Convert Binary to String
    CALL FUNCTION 'SCMS_BINARY_TO_STRING'
      EXPORTING
        input_length = lv_len
      IMPORTING
        text_buffer  = lv_string
      TABLES
        binary_tab   = lt_content[]
      EXCEPTIONS
        failed       = 1
        OTHERS       = 2.
ENDCASE.

*Write the converted string to Screen.
CASE 'X'.
  WHEN p_decode.
    write lv_string.
  WHEN p_encode.
    write lv_base64.
  WHEN OTHERS.
ENDCASE.

Encode and Decode Base64 using ABAP Class CL_HTTP_UTILITY.

We can also use the HTTP utility class CL_HTTP_UTILITY. This utility class contains methods to directly encode or decode Base64 string.

Decode Base64 using method DECODE_BASE64.

Using static method DECODE_BASE64 decode Base64 string directly to string.

*Decode Base64 String to String
    CALL METHOD cl_http_utility=>if_http_utility~decode_base64
      EXPORTING
        encoded = p_input
      RECEIVING
        decoded = lv_string.

Encode Base64 using method ENCODE_BASE64.

Static method ENCODE_BASE64 allow us to encode string to Base64.

*Encode String to Base64
    CALL METHOD cl_http_utility=>if_http_utility~encode_base64
      EXPORTING
        unencoded = p_input
      RECEIVING
        encoded   = lv_base64.

ABAP Program to Encode and Decode Base64 using CL_HTTP_UTILITY Class.

I have re-designed the ABAP program to convert Base64 using CL_HTTP_UTILITY class methods ENCODE_BASE64 and DECODE_BASE64 .

*&---------------------------------------------------------------------*
*& Report ZBASE64_ENCODE_DECODE
*&---------------------------------------------------------------------*
*&
*&---------------------------------------------------------------------*
REPORT zbase64_encode_decode_v1.
DATA: lv_string  TYPE string,        "Text
      lv_base64  TYPE string.        "Base64
SELECTION-SCREEN BEGIN OF BLOCK in1 WITH FRAME TITLE TEXT-t01.
PARAMETERS: p_input TYPE string OBLIGATORY LOWER CASE.
SELECTION-SCREEN END OF BLOCK in1.
SELECTION-SCREEN BEGIN OF BLOCK in2 WITH FRAME TITLE TEXT-t02.
PARAMETERS: p_encode RADIOBUTTON GROUP rb1 USER-COMMAND grb1 DEFAULT 'X',
            p_decode RADIOBUTTON GROUP rb1.
SELECTION-SCREEN END OF BLOCK in2.
CASE 'X'.
  WHEN p_encode.
*Encode String to Base64
    CALL METHOD cl_http_utility=>if_http_utility~encode_base64
      EXPORTING
        unencoded = p_input
      RECEIVING
        encoded   = lv_base64.
  WHEN p_decode.
*Decode Base64 String to String
    CALL METHOD cl_http_utility=>if_http_utility~decode_base64
      EXPORTING
        encoded = p_input
      RECEIVING
        decoded = lv_string.
ENDCASE.
*Write the converted string to Screen.
CASE 'X'.
  WHEN p_decode.
    WRITE lv_string.
  WHEN p_encode.
    WRITE lv_base64.
  WHEN OTHERS.
ENDCASE.

Other Related ABAP Functions to Use with Base64 Function Modules.

In order to convert the File to Base64 format, first, you need to read the files from the application server (AL11). Read data from AL11 using OPEN DATASET,
READ DATASET, and CLOSE DATASET key words.

How to Encode Message to Base64 in SAP Integration Suite (CPI)

If you are interested in learning how to work with Base64 format using UDFs in SAP Integration Suite, you can go to the linked article.

I hope you learned how Base64 representation works, and the use cases of Base64. Encoding and Decoding of Base64 in SAP can be done using Function Modules or utility class CL_HTTP_UTILITY. If you have any questions on Base64 topics covered by the article, please leave a comment below.

The post Base64 Encoding and Decoding in SAP ABAP appeared first on SAP Integration Hub.

If you are interested in learning how to assign the parameters during runtime dynamically in SAP Integration Suite, go the linked article.

In this example (iDoc to File scenario) I am setting the iDoc Message type and Material number to the file name in the below format.

File name format: <Message Type>_<Material Number>_TimeStamp.XML

Let’s look at how to create a file name in the above format at the receiver communication channel using a UDF.

Step 1: Create File Name User Defined Function (UDF).

UDF name: Set_FileName

Configure the parameters of the UDF. Since we require the file name to have ‘Message Type’ and the ‘Material Number’ from the input, we need to create two import parameters in the UDF. One for ‘Message Type’ and another one for ‘Material Number’.

Step 2: Code UDF Logic to Set the File Name.

Here we need to set the file name to the dynamic configuration key ‘FileName’. You can change the UDF code here as per your file format requirement.

try {

String filename = new String("");

DynamicConfiguration conf1 = (DynamicConfiguration) container.getTransformationParameters().get(StreamTransformationConstants.DYNAMIC_CONFIGURATION);

DynamicConfigurationKey key1 = DynamicConfigurationKey.create("http:/"+"/sap.com/xi/XI/System/File","FileName");

filename = MessageType+"_"+MaterialNumber+"_.xml";

conf1.put(key1,filename);

return "";
}

catch(Exception e)

{
String exception = e.toString();
return exception;

}

File name generation UDF comes in handy when your file name logic is complex and it cannot be handled by other dynamic file name generation methods such as variable substitution.

Step 3: Configure the Message Mapping program.

Map the created file name generation UDF as above. In the example we import two values from the input structure to the UDF, they are Message type (MESTYP) and Material Number (MATNR).

Step 4: Configure the receiver file communication channel .

You can set any text as the ‘File Name Schema’ as it would be replaced by the ASMA.

Configure ASMA by checking ‘Use Adapter Specific Message Attributes’ (ASMA) and also ‘File Name’. These two settings should be activated in the receiver communication channel to runtime to override the hardcoded file name in ‘File Name Schema’ with the file name set from the UDF.

Set the time stamp since we need the timestamp at the end of the file name.

Test Case for Dynamic File Generation using UDF.

If you would like to learn configuration steps for dynamic file name generation using the variable substitution method, check out the linked article. Additionally, I have written another post to illustrate how to encode and decode Base64 using UDFs. You can follow all posts related to UDFs here.

Please leave a comment if you have any questions about the dynamic file generation steps discussed here.

The post Dynamic File Name UDF Example – SAP PI/PO appeared first on SAP Integration Hub.