SAP Community - Cloud Integration

Architecting Electronic Bill of Lading on SAP BTP - Blueprint (Part 2 of 3)

2026-04-02T00:23:19.930000+02:00

Introduction

In Part 1 , we explored the transformative potential of the Electronic Bill of Lading in international trade, highlighting its impact on sustainability, enhanced supply chain transparency, and accelerated business processes.

Part 2 presents the building blocks used to implement the solution and includes an architecture diagram illustrating how the SAP BTP services and components are integrated.

1. System Context

The ocean carrier already operates an established core system that manages transactional data such as bookings, shipping instructions, and transport events on SAP Cloud ERP( S/4HANA Transportation Management).

SAP Cloud ERP

2. SAP Business Technology Platform

The foundation of this solution is SAP BTP, a cloud platform that brings together application development, data management, integration, and AI capabilities. It provides the core infrastructure and services needed to build enterprise applications.

To support the transition to digital trade, the Electronic Bill of Lading capability is implemented on SAP BTP as a side-by-side extension.

3. Electronic Bill of Lading: TradeTrust Framework

The open-source TradeTrust Framework serve as the foundation for implementing a fully digital and verifiable Electronic Bill of Lading solution. It can be deployed as a Node.js application on Cloud Foundry, which provides the runtime for developing and running cloud-native applications on SAP BTP.

On this PoC, the TradeTrust framework uses the Ethereum blockchain whereby the ERC-721 provides a widely-used smart contract API used on non-fungible tokens (NFTs) to allow transfer of ownership whilst providing assurance of integrity, singularity, and control.

Blockchain technology is a decentralized digital ledger system that records and verifies transactions across a network of computers in a secure and transparent manner. It consists of a chain of blocks, each containing a list of transactions thatare linked and secured using cryptographic techniques. Once a block is added to the chain, its data become immutable through a distributed ledger system, ensuring the integrity and permanence of the transaction records. This immutability and transparency enable blockchain to facilitate the exchange of anything of value, whether tangible assets including physical goods or intangible items such as digital assets.[11]

4. Terminal Operating System

Terminal Operating System (TOS) is the port terminal’s operational platform that manage and monitor container and vessel activities. Leveraging IoT-enabled equipment and sensors, the TOS generates real-time operational events such as container loading, vessel arrival, and departure. These events are distributed through a publish–subscribe model, pushing notifications to a configured endpoint. To ensure authenticity and integrity, the messages are encrypted and digitally signed.

5. Event-Driven Architecture

SAP Integration Suite running on SAP BTP provides the capabilities that enable Event-Driven Architecture within the solution. The Cloud Integration is the middleware layer responsible for routing, transforming, and exchanging messages between external systems and SAP services. Under the hood, it uses the open-source Apache Camel Framework, enabling integration flows based on enterprise integration patterns.

For event orchestration SAP Event Mesh is the message broker, it facilitates asynchronous communication by receiving events from the terminal/port and routing them to the subscribed consumer Events-To-Business Actions Framework, that leverages the decisions capability of SAP Build Process Automation to initiate business actions.

6. Automation

For the process automation, a workflow is managed on SAP Build Process Automation

7. UI

Stakeholders access the application through SAP Build Work Zone, where authentication is handled by SAP Cloud Identity Services integrated with a custom Identity Provider (IdP) that validates blockchain wallet signatures. Authorization is then enforced via role collections, ensuring access only to permitted functionalities.

8. Diagram

The Terminal Operating System generates an operational event(Load, Departure, Arrival). The event is published to the event broker SAP Event Mesh.
Event-to-Business-Actions framework is subscribed to SAP Event Mesh topics to receive the events.
Based on the rule outcome, the processor triggers a workflow on SAP Build Process Automation to orchestrate the business process.
The workflow calls SAP Integration Suite to start the process.
An Integration Flow retrieves the required Ocean Freight Booking from SAP S/4HANA and builds the payload to issue the eBL.
The Integration Flow invokes the TradeTrust Framework.
The Electronic Bill of Lading is issued on Ethereum Network.

9. Data Context

Conclusion:

Part 2 outlined the essential building blocks and architectural components for implementing the eBL solution on SAP Business Technology Platform.

In Part 3, I’ll walk through a complete end-to-end global trade scenario, illustrating how the architecture operates in practice, from container loading event to eBL issuance, ownership transfer, and final surrender.

Architecting Electronic Bill of Lading on SAP BTP - End-to-End Scenario(Part 3 of 3)

2026-04-02T19:09:58.380000+02:00

Introduction

In Part 1 – Case Study and Part 2 – Blueprint, we introduced the concept of the Electronic Bill of Lading and walked through the key steps required for its implementation.

The Part 3 presents a complete end-to-end global trade scenario, beginning with a container loading event emitted by the Terminal Operating System, continuing through the issuance of the electronic Bill of Lading, and ending with the surrender of the eBL when the importer claims the goods.

Teaser

The recently announced trade agreement between the European Union and Mercosur (January 2026) opens new opportunities for smaller producers to gain greater market access and visibility in cross-border commerce. Additionally, the European Union will contribute with €1.8 billion through the Global Gateway initiative to support Mercosur’s green and digital transition. As trade volumes grow, Electronic Bills of Lading help by enabling faster, more secure, and fully digital handling of one of the most important documents in international trade.

Scenario

A Brazilian Coffee Exporter contracts an Ocean Carrier to ship a container of coffee beans to an European Coffee Importer:

Stakeholders: Buyer, Seller and Carrier
Origen: Port of Santos, Brazil
Destination: Port of Antwerp, Belgium
Goods: Arabica Coffee Beans
Amount: 18 tons
Container: 1 TEU

Booking Request

The exporter requests transportation from the ocean carrier by submitting a booking request.

The booking page of the app call the FREIGHTBOOKING API to create the Ocean Booking on SAP Cloud ERP

Stakeholder Onboarding

Before the shipment process begins, key participants such as the exporter, importer, and carrier are onboarded to the platform. During this step, each party registers its digital identity and public key, enabling secure signing, verification, and ownership transfer of the Electronic Bill of Lading.

Electronic Bill of Lading Lifecycle

The eBL lifecycle is based on the events generated by the Terminal Operating System:

1. Event: Load

Port/Terminal Operating System: confirms the container has been loaded on a vessel

Event Payload:

{
  "event_id": "evt-load-0001",
  "event_created_date_time": "2026-03-16T10:15:30Z",

  "event": {
    "journey_type": "EQUIPMENT",
    "event_classifier": "ACT",
    "event_type": "LOAD",
    "transport_mode": "VESSEL",
    "empty_indicator": "FULL"
  },

  "facility": {
    "facility_type": "POTE",
    "location": {
      "location_code": "BRSSZ",
      "location_name": "Port of Santos"
    }
  },

  "transport": {
    "vessel_name": "Atlantic Pearl",
    "voyage_number": "VY-2024-095"
  },

  "equipment": {
    "container_number": "MSKU1234567",
    "iso_equipment_code": "22G1"
  },

  "shipment": {
    "commodity": "Green Coffee Beans",
    "gross_weight_kg": 18000
  },

  "destination": {
    "location_code": "BEANR",
    "location_name": "Port of Antwerp"
  }
}

On step 1, the event is published on a topic of SAP Event Mesh

On the step 2, the event is consumed by the Event-to-Business Actions framework that triggers the workflow on SAP Build Process Automation.

On the step 3, an integration flow is triggered on Integration Suite:

Integration Suite

On step 4, Integration flow fetches the Ocean Freight Booking on SAP Cloud ERP(Step 5) according to the 'Container ID' and 'Voyage ID' and then proceed with the creation of the Electronic Bill of Lading via TradeTrust Framework.

Business Partners:

Container:

Shipping Instructions

After SAP Integration Suite fetch the data from the backend, it generate a payload.

Electronic Bill of Lading Payload:

{
  "$schema": "https://schema.tradetrust.io/ebl/1.0/schema.json",
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://schema.trustvc.io/credentials/v1"
  ],
  "id": "urn:uuid:sap-ebl-trustvc-001",
  "type": [
    "VerifiableCredential",
    "ElectronicBillOfLading",
    "TradeTrustDocument"
  ],
  "issuers": [
    {
      "name": "Carrier",
      "documentStore": "0x0908aD5481673E19c3D03f1379E0032458118881",
      "identityProof": {
        "type": "DNS-TXT",
        "location": "carrier.example.com"
      }
    }
  ],
  "issuanceDate": "2026-03-16T11:00:00Z",
  "credentialSubject": {
    "id": "did:ethr:0x562eeBbaBB405db740f2e607F87f152989a10b7E",
    "origin": "Port of Santos, Brazil",
    "destination": "Port of Antwerp, Belgium",
    "goods": "Green Coffee Beans",
    "amount": "18 tons",
    "container": "1 TEU",
    "holder": "0x562eeBbaBB405db740f2e607F87f152989a10b7E",
    "consignee": "0x5C1d8d47784d8302B3839436e0e82E094D8e234f"
  }
}

On step 6, Integration Suite sends the payload to the TradeTrust framework to issue the eBL(step 7) :

Tradetrust framework Node.js deployed on Cloud Foundry.

const fs = require("fs");
const path = require("path");
const { Wallet, ethers } = require("ethers");
const { signDocument, SUPPORTED_SIGNING_ALGORITHM } = require("@tradetrust-tt/tradetrust");
require("dotenv").config();

const RPC_URL = "https://rpc.sepolia.linea.build"; // Linea Sepolia RPC
const PRIVATE_KEY = process.env.PRIVATE_KEY; // Carrier wallet 
const NFT_CONTRACT_ADDRESS = "0x6fD6DB343c5d84Baa7fDaeD5CedDA15652451a8f";

// Stakeholders
const EXPORTER = "0x562eeBbaBB405db740f2e607F87f152989a10b7E";
const IMPORTER = "0x5C1d8d47784d8302B3839436e0e82E094D8e234f";

The payload is wrapped with OpenAttestation metadata and cryptographically signed using the carrier’s key pair (public and private keys).

let rawWrapped = fs.readFileSync(WRAPPED_JSON, "utf-8");
    const wrappedDocument = JSON.parse(rawWrapped);
    console.log("✅ Wrapped document loaded");

    // Sign document with carrier key
    const keyPair = {
      public: "did:ethr:0x9843Cd2834010A4dca776d3035117750d20b3C01#controller",
      private: PRIVATE_KEY
    };

    const signedDocument = await signDocument(
      wrappedDocument,
      SUPPORTED_SIGNING_ALGORITHM.Secp256k1VerificationKey2018,
      keyPair
    );

    fs.writeFileSync(SIGNED_JSON, JSON.stringify(signedDocument, null, 2));
    console.log("Document signed successfully");

Prepare parameters

// Connect wallet & contract
    const provider = new ethers.JsonRpcProvider(RPC_URL);
    const wallet = new Wallet(PRIVATE_KEY, provider);

    console.log("🧾 Wallet (carrier):", wallet.address);
    const balance = await provider.getBalance(wallet.address);
    console.log(" ETH balance:", ethers.formatEther(balance));
    if (balance === 0n) throw new Error("Wallet has ZERO ETH — fund it for gas");

    const contract = new ethers.Contract(NFT_CONTRACT_ADDRESS, EBL_ABI, wallet);

    // Check wallet is carrier
    const carrierAddress = await contract.carrier();
    if (wallet.address.toLowerCase() !== carrierAddress.toLowerCase()) {
      throw new Error(`Wallet is not the carrier. Contract carrier is ${carrierAddress}`);
    }

    //Prepare issueEBL parameters
    const tokenId = BigInt(Date.now()); // PoC uniqueness
    const merkleRoot = signedDocument?.signature?.merkleRoot;
    const documentHash = toBytes32(merkleRoot);

    // Estimate gas + send
    const gasEstimate = await contract.issueEBL.estimateGas(
      tokenId,
      EXPORTER,
      IMPORTER,
      documentHash,
      tokenURI
    );

    const gasLimit = percentBuffer(gasEstimate, 25);

    const maxPriorityFeePerGas = ethers.parseUnits("1", "gwei"); // tip
    const maxFeePerGas = ethers.parseUnits("5", "gwei");         // must be >= priority
    
    const tx = await contract.issueEBL(
      tokenId,
      EXPORTER,
      IMPORTER,
      documentHash,
      tokenURI,
      {
        gasLimit,
        maxFeePerGas,
        maxPriorityFeePerGas
      }
    );
    

    console.log("📤 Transaction sent:", tx.hash);
    const receipt = await tx.wait();
    console.log("✅ Mint/Issue confirmed in block:", receipt.blockNumber);

NFT Minted on Blockchain

From this point onward, all TradeTrust-related steps will be demonstrated using the TradeTrust viewer. However, these operations can also be implemented programmatically using the TradeTrust Node.js library.

Electronic Bill of Lading created:

2. Event: Departure

Once the vessel leaves the port and start the journey, the Terminal Operating System emits the event Departure:

{
  "event_id": "evt-depa-0001",
  "event_created_date_time": "2026-03-16T18:40:00Z",
  "journey_event": {
    "journey_type": "TRANSPORT",
    "event_classifier": "ACT",
    "event_type": "DEPA",
    "transport_mode": "VESSEL",
    "facility_type": "POTE"
  },
  "shipment_location": {
    "type_code": "POL",
    "location_code": "BRSSZ"
  },
  "transport": {
    "vessel_name": "Atlantic Pearl",
    "voyage_number": "VY-2024-095"
  },
  "shipment": {
    "transport_document_reference": "BL-SANTOS-ANT-0001"
  }
}

The vessel starts to transmit telemetry(stored on a Hana DB) which is used for tracking and trace:

Once the goods are in transit, the buyer is notified via SAP BPA to provide the payment:

Once the payment is verified, the ownership of the Electronic Bill of Lading can be transferred to the Importer:

3. Event: Arrival

This event notifies the consignee via SAP Process Automation that the goods have arrived at the destination port and it is ready for pick up

Payload:

{
  "event_id": "evt-arri-0001",
  "event_created_date_time": "2026-03-26T07:20:00Z",
  "journey_event": {
    "journey_type": "TRANSPORT",
    "event_classifier": "ACT",
    "event_type": "ARRI",
    "transport_mode": "VESSEL",
    "facility_type": "POTE"
  },
  "shipment_location": {
    "type_code": "POD",
    "location_code": "BEANR"
  },
  "transport": {
    "vessel_name": "Atlantic Pearl",
    "voyage_number": "VY-2024-095"
  },
  "shipment": {
    "transport_document_reference": "BL-SANTOS-ANT-0001"
  }
}

Journey completed:

The Importer surrenders the electronic Bill of Lading to the carrier for cargo release at the destination port.

The surrender step marks the end of the workflow and completes the trade process.

Endorsement Chain completed:

Conclusion:

This Proof of Concept demonstrates how an electronic Bill of Lading can be issued, verified, and transferred using a blockchain technology integrated with SAP Business Technology Platform.

Given that modern container vessels can carry thousands of containers, the proposed architecture is designed to scale and process a high volume of operational events efficiently.

Looking ahead, AI agents could be integrated to further enhance the solution. These agents could monitor events, detect potential issues, automate operational tasks, and trigger workflows when required.

Combined with digital payment mechanisms such as on-chain settlement, this approach has the potential to significantly transform how international trade processes are executed.

Sources: SAP BTP Guidance Framework, SAP Application Extension Methodology , SAP Integration Solution Advisory Methodology , Integration Architecture Guide.

References:

[1] ICC Academy: Break the eBL silos: Why interoperability is the missing link in digital trade

[2] CargoX: Environmental impact of digitalisation in shipping documentation: Carbon footprint comparison of paper and electronic bills of lading

[3] Weareprocarrier

[4] Intracen: International Trade Centre

[5] IMDA: TradeTrust Legal Analysis Article

[6] Smart Ports Bynder

[7] GitHub - Event to Business Action

[8] Irishweekly: Europe Greenlights Massive Mercosur Trade Deal, Ending Long Stalemate

[9] 93degreescoffeeroasters

[10] ICC Academy: Ebl digital trade

[11] Intracen: Expediting Trade Through Electronic Bills of Lading

Message Mapping in SAP Integration Suite - Custom Scripts and Conditional Mapping

2026-04-03T18:10:00.019000+02:00

I find it useful to look at two capabilities of message mapping, which may seem confusing and may be overlooked for the first-sight complexity - custom functions and graphical conditional mapping - both being configured in the bottom half of the message mapping screen.

Custom Groovy Functions

The standard function library in the Mapping Expression editor already covers a lot of use-cases. Under Standard you get arithmetic, boolean logic, date functions, string operations, conversions, and node functions. For many projects, this is sufficient.

Where the standard library starts to show its limits is when your logic involves multiple conditions chained together, or when you need to validate and reformat values in a way the graphical nodes simply cannot express cleanly.

Writing a Custom Script Function

You can extend the mapping with your own Groovy functions. The function is added directly in the Mapping Expression editor under Scripts.

I chose a simple example of a custom function - the script will transform a date from YYYY-MM-DD format into SAP-native date format YYYYMMDD. This is a trivial functionality and is actually coved by the standard functions (section 'Date'), but the point here is just to show the syntax.
Click 'Create', give the script a name and you will be taken to a Groovy editor.

Delete the placeholder code and the script will then look like this:

import com.sap.it.api.mapping.*
def String date_to_YYYYMMDD(String date) {
    if (date == null || date.trim().isEmpty()) {
        return ""
    }
    // Expected input format: YYYY-MM-DD
    if (!date.matches("\\d{4}-\\d{2}-\\d{2}")) {
        return ""
    }
    // Remove hyphens
    return date.replaceAll("-", "")
}

Import com.sap.it.api.mapping.* is the API package you need for mapping scripts.
Null and empty guard - the very first thing the function does is handle null and blank input.
Input validation before processing - the regex check ensures the function only processes values that actually look like a date. If the source field contains garbage, the function returns empty rather than silently producing a malformed output.
The transform itself - once the value passes validation, removing the hyphens is a one-liner.

You can even have multiple input parameters or work with nodes, but we keep it simple in this article. You will get the code from any AI tool anyway, so no reason to get too technical. The important thing here to know what is the place for custom logic.

Note: Keep your script functions focused — one function, one responsibility. It makes testing much easier and keeps the mapping readable for the next person who opens it.

Graphical Conditional Mapping

Custom scripts are powerful, but for conditional logic that depends on comparing a source field against a known value, the graphical approach is often cleaner and more transparent.
We look at a dummy scenario, where the business rule is simple: if PO_NUMBER equals 100500, the recipient should be 100500; for anything else, the default recipient is 100000.

Building the Condition

In the Mapping Expression canvas this is what the setup looks like:

Those blue boxes are standard functions from the left menu, the yellow boxes are fields from mapping - PO_NUMBER is a source field, RECIPNT_NO is a target field, values '100500' and '100000' are constants, which we have to summon from the left-hand-side function menu as well.

The first function is 'equals(string)', which compares two inputs. If the two input values are equal, the result is a boolean 'true'.

The second function is 'if', which receives a boolean condition - if true, returns the 'true value', if false, returns the 'false value'.

Reading the canvas left to right: a constant node with value 100500 and the source field PO_NUMBER both feed into an equals(string1, string2) comparison node. The result of that comparison, together with the constant 100000, feed into an if node — where the comparison result is wired to condition, 100500 goes to true value, and 100000 goes to false value. The output of the if node maps directly to RECIPNT_NO.

No code required. The logic is immediately readable to anyone who opens the mapping editor.

Testing with the Simulate Tool

Once the mapping is defined you want to verify it before deploying. This is where the Simulate feature saves a lot of time. Instead of deploying the iFlow and sending a real message through it, you can test right inside the Mapping editor.

Generating a Test Payload

Click the Generate button to automatically create a dummy input payload based on your source structure.

Every field gets a _sample suffix value so you can immediately identify which source field produced which output. The PO_NUMBER field has been manually changed to 100111 — a value that does not match the constant 100500. The Test Output on the right shows RECIPNT_NO resolved to 100000, confirming the false branch of the condition fired correctly (highlighted by the blue arrow).

The generated payload is fully editable. This is the key point: Generate gives you the structure, and then you adjust individual field values to test specific scenarios without having to author an entire XML document by hand.

Testing the True Branch

Now change PO_NUMBER to 100500 and run the simulation again:

With PO_NUMBER set to 100500, the Test Output immediately shows RECIPNT_NO as 100500. The blue arrow highlights exactly where to confirm the result in the output tree. The condition evaluated true, and the mapping used the matching constant value.

Tips for Using the Simulate Tool Effectively

Always test both branches of every condition. It is easy to only verify the happy path — set up values that exercise the false branch too.
Test null and empty inputs. Leave a field blank in the test payload and check that your mapping handles it gracefully, especially for fields that feed into script functions.

Summary

Message Mapping in SAP Integration Suite is more capable than it might appear at first glance. The graphical function library handles conditional logic elegantly without a single line of code. Custom Groovy scripts let you express validation, reformatting and derivation logic that the standard nodes cannot cover. And the Simulate tool with its Generate feature gives you a tight test cycle right inside the editor.

To sum up the best-practice: start graphically, reach for a script only when the graphical approach becomes unreadable, and always validate with Simulate before you deploy.

Currency Conversion Made Easy with SAP Integration Suite

2026-04-03T19:58:00.295000+02:00

📝Introduction

Hello All,

As we all know that business environment means working with different countries and their currencies but the thing is we need accurate exchange amounts every day. For this I have prepared an Iflow which will convert the Source Currency into Target Currency most accurately calling an external API. I also used HTML to beautify the output.

The below figure shows the Iflow that I have created for the Currency Conversion in SAP Integration Suite:

Here we are sending JSON as input from Postman through HTTPS adapter.
Using a GroovyScript to validate the input JSON, if JSON is in correct format the Json will go through the main flow otherwise it will trigger the EXception Subprocess.

Valid JSON Input:

When JSON is in correct format the JSON will be converted into XML using JSON2XML_In
CM_Extract_Params(content modifier) is used to extract the parameters like source currency, target currency and the amount from the XML into the exchange properties.
Request Reply(RR_Call_API) is used for synchronous communication which will call the exchange rate API which is an external API service through the HTTP adapter connection.
Will receive JSON as output from external API as response which will be converted into XML payload using JSON2XML_API.
This converted XML is used for XSLT mapping(XSLT_HTML) also HTML is used to beautify the output in a tabular format which the target recipient will receive as a mail through mail adapter.

2. Invalid JSON input:

If the input JSON format is failed then the GS_ValidateInput will trigger the Exception Subprocess which will start with Error Start Event.
Content modifier with the name CM_Error is used to format the body of the error mail using runtime variables including the Error Category, Flow Name, MPL ID and Error timestamp.
Mail adapter in the Exception subprocess will sends the ErrorMail to the support or monitoring team

Working Demo – Input and Output

✔️Successful Case

A valid JSON triggers the flow and returns an email with HTML content showing:

Source Currency
Target Currency
Source Amount
Converted Amount

Input from postman for successful Case:

Output/successful currency conversion mail:

❌Error Case

Invalid inputs trigger the Exception Subprocess, such as:

Missing fields
Incorrect JSON structure
External API failure

In such cases, an email is sent containing a clear explanation of the error.

The below image shows the input from postman for the error case where I just removed a comma in the line 3 at target currency which means an invalid JSON input:

Output/Error mail for Invalid Input:

Exception Subprocess Explained:

This part of the flow ensures the system remains stable by handling:

Bad input format
Missing mandatory fields
External API issues

It prevents the main flow from failing silently and provides meaningful alerting via email.

Business Value:

This solution delivers business value by delivering business value by automating currency conversion with real time exchange rates.
Reduces manual efforts and errors, improves accuracy.
Improves supportability by sending proactive error mails with message details like the MPL ID, Iflow name and error details.

🙏Conclusion:

In conclusion this scenario demonstrates how SAP IS can be used for a practical use case involving real time currency conversion.
It’s an excellent example of modernizing business processes using API-driven automation.

@jareenabee_dudekula

Secure APIs: External OIDC-Based Authentication for API Artifacts in SAP Integration Suite

2026-04-05T02:59:56.314000+02:00

Introduction

Security is the cornerstone of any API strategy. In SAP Integration Suite's Edge Integration Cell (EIC), the Authentication Policy is the first line of defence for every API artifact — and it is non-deletable by design. This is intentional: no API should ever be reachable without an authentication gate.

Until recently, this policy supported only SAP tenant specific XSUAA-based authentication — a robust mechanism tightly coupled to the SAP Business Technology Platform (BTP) identity ecosystem. While this works perfectly for SAP-native landscapes, modern enterprises increasingly rely on external Identity Providers (IDPs) — whether it's SAP Identity Authentication Service (SAP IAS, Entra, or any OIDC-compliant provider — to manage identities across their application portfolio.

That's where the new External Auth (OIDC) authentication capability comes in.

In this blog, I'll walk you through:

What the Authentication Policy is and why it is fundamental to EIC
The difference between SAP Tenant specific XSUAA and External (OIDC) authentication — when to use which
A real-world walkthrough using a SuccessFactors (SFSF) API secured with SAP IAS and JWT Bearer grant type

Whether you are an integration consultant, an API developer, or a decision-maker evaluating EIC's security posture, this blog is for you.

Background: The Authentication Policy in EIC API Artifacts

When you create an API artifact in SAP Integration Suite and target it to an Edge Integration Cell runtime, an Authentication Policy is automatically attached to the API. This policy sits at the ingress — meaning it validates every inbound request before any other policy, mediation or routing logic executes.

Key characteristics of this policy:

It is default and non-deletable — enforcing the principle that no API artifact can run unauthenticated
It governs who is allowed to call your API

Prior to the External Auth feature, the only supported mode was Tenant specific Authentication using SAP XSUAA tokens issued from BTP. Now, with the introduction of External Authentication, you can configure the policy to validate tokens issued by any OIDC-compliant external IDP.

Tenant specific XSUAA vs. External Authentication: What's the Difference?

SAP Tenant specific XSUAA Authentication

The calling application obtains an OAuth 2.0 access token from SAP XSUAA — the authorization server embedded in SAP BTP. This token is then passed in the Authorization header when invoking the API artifact URL on EIC. EIC runtime validates the token against the BTP subaccount's XSUAA instance. The token's audience, client credentials, and scopes are checked internally within the SAP trust chain.

When to use it:

The calling application is built on SAP BTP (e.g., a BTP-hosted app, a CAP service, or another Integration Suite artifact)
Your identity landscape is fully SAP-native
You want zero configuration overhead — XSUAA trust is pre-established within the SAP ecosystem
Internal system-to-system calls where all principals live in BTP

Minimal configuration, since EIC and BTP share the same trust domain, you primarily use either type (“oAuth”, “Basic”, “Client Certificate” ) and token is generated/validated with XSUAA

External Authentication (OIDC-based External IDP)

The calling application obtains a JWT token from an external OIDC-compliant Identity Provider (e.g., SAP IAS, Entra, Okta etc.). This JWT is passed to runtime, which validates it against the external IDP's OIDC configuration. EIC runtime uses the IDP's Well-Known URL (the OIDC discovery endpoint) to fetch the public keys and token metadata, then validates:

Token signature — verified against the IDP's JWKS (JSON Web Key Set)
Audience (aud claim) — must match what is configured in the policy
Client ID — validated against the registered application
Expiry and standard JWT claims

If all validations pass, the token is considered authentic and the request proceeds. The validated token can then be propagated downstream to the backend API (e.g., SuccessFactors) — enabling end-to-end token chaining.

When to use it:

Your calling application uses a non-SAP IDP or SAP IAS as its identity authority
You are integrating with third-party ecosystems (partner apps, customer portals, mobile apps) that are not BTP-resident
You need to support federated identity scenarios — e.g., corporate Azure AD federated into SAP IAS
Your organization's identity strategy mandates a centralized external IDP beyond BTP's XSUAA
You are calling APIs on behalf of a human user whose identity lives in IAS (not in XSUAA)

Aspect	Internal (XSUAA)	External (OIDC)
Token Issuer	SAP BTP XSUAA	Any OIDC-compliant IDP (IAS, Entra, Okta…)
Trust Setup	Pre-established within BTP	Configured via Well-Known URL in policy
Primary Use Case	BTP-native app-to-API calls	Cross-ecosystem, federated, or IAS-managed identities
Token Type	XSUAA OAuth 2.0 Access Token	Standard OIDC JWT
Policy Config Effort	Minimal	Explicit (Well-Known URL, Audience, Client ID)
Token Propagation	Supported	Supported
User Info Key (Audit)	Not applicable	Optional — JWT claim for audit identity; falls back to Client ID

Create an API in SAP Integration Suite with External Auth

Now let's bring this to life with a concrete scenario.

Scenario Overview

I have a Application Status API of SuccessFactors(SFSF) managed via an API artifact on EIC runtime. The API is consumed by an application developer (or an application they have built) whose identity is managed by SAP Identity Authentication Service (IAS). The SFSF API itself is configured to accept OAuth 2.0 JWT Bearer tokens issued by IAS.

The flow looks like this:

Application Developer

│ 1. Obtains JWT from SAP IAS token endpoint

▼

SAP IAS (External IDP)

│ 2. JWT passed in Authorization header

▼

API Artifact URL on EIC

│ 3. Authentication Policy validates JWT

│ - Well-Known URL → fetch JWKS from IAS

│ - Validate: signature, audience, client ID

│ - Resolve caller identity

▼

Validation Passed

│ 4. Token propagated to SFSF API

▼

Backend API

│ 5. Backend validates JWT Bearer, returns response

▼

Response returned to caller

Prerequisites

Before we start the let’s ensure the following are in place:

SAP Integration Suite is activated with both API Management and Cloud Integration capabilities enabled in your BTP subaccount
Edge Integration Cell is provisioned.
An API artifact has been created in your Integration Suite tenant targeting the EIC runtime, with the SFSF API as the backend target URL
In SAP IAS, an application is registered representing your API client. Note down:

The IAS tenant's Well-Known URL: https://<your-ias-tenant>.accounts.ondemand.com/.well-known/openid-configuration
The Client ID of the registered IAS application
The Audience configured for token issuance (often the client ID itself, or a dedicated resource URI)

The SFSF OAuth configuration is set up to trust IAS-issued JWT Bearer tokens

Model the Authentication Policy in the API Artifact

Navigate to Design → Integrations and APIs in your SAP Integration Suite tenant
Open the Content Package containing your SFSF API artifact
Click on the API artifact to open it in the editor
Switch to the Policies tab
You will see the Authentication Policy already present — this is the default, non-deletable policy attached to every API artifact on EIC
Click on the Authentication Policy to open its configuration panel

Configure External Authentication

In the Authentication Policy configuration panel: Under Authentication Policy, check External OAuth (OIDC).

In the Well-Known URL field, enter your SAP IAS discovery endpoint:

https://<your-ias-tenant>.accounts.ondemand.com/.well-known/openid-configuration

This URL tells runtime where to fetch the IDP's public signing keys and token metadata. EIC calls this endpoint at runtime to validate incoming JWTs. In the Audience field, enter the audience value that IAS is configured to embed in the JWT's aud claim. This is typically the Client ID of the target application or a resource URI defined in IAS.

In the Client ID field, enter a dynamic expression which maps to the claim in your JWT token representing the Client ID of the IAS application that the calling application uses to obtain its JWT. For e.g. ${authn.oidc.jwt.azp}

In the User Info Key field (optional), enter a dynamic expression which maps JWT claim you want EIC to use for identifying the caller in audit logs — for example, email, sub, or user_name. For e.g. ${authn.oidc.jwt.email}.

There is a preference for UserInfo Key:

If you provide a value (e.g., email), the runtime will look for that claim in the inbound JWT or in the IDP's UserInfo endpoint response, and use it as the caller identity in audit log entries.
If you leave it empty, the runtime falls back to the Client ID as the audit identity.
If you provide a value but the claim is not found in the JWT or UserInfo at runtime, the EIC again falls back to the Client ID — the policy does not fail. At most, audit log entries will reflect the fallback identifier rather than the preferred one.

If your organisation's audit and compliance requirements demand that API access logs reflect human-readable identifiers (like an email address or user principal name) rather than technical Client IDs, this is the field to configure. It gives you meaningful, traceable audit trails without any impact on the authentication flow itself.

Save and Deploy the API Artifact to EIC Runtime Profile

In the artifact editor, click Deploy
Select your Edge Integration Cell runtime as the deployment target
Confirm the deployment

Navigate to Monitor → Integrations and APIs and switch the runtime filter to your EIC instance to verify the artifact status shows "Started"

Invoke the API — End-to-End Flow in Action

Now let's test the flow from the application developer's perspective.

Obtain a JWT from SAP IAS:

The application developer (or application) calls the IAS token endpoint using the JWT Bearer grant type. In this grant type, the application presents a signed JWT assertion to IAS, which in turn issues a new JWT scoped for the target audience (SFSF). IAS validates the assertion and returns an access token (JWT).

Call the API artifact URL on EIC:

What happens inside EIC runtime profile:

The request hits the EIC ingress
The Authentication Policy intercepts it
EIC fetches the JWKS from the IAS Well-Known URL (cached after first call for performance)
The JWT signature is verified using IAS's public key
The aud claim is matched against the configured Audience
The client_id (or azp claim) is matched against the configured Client ID
The EIC runtime resolves the caller identity— using the configured User Info Key claim (e.g., email) from the JWT or IAS UserInfo endpoint; falls back to Client ID if the claim is absent
Validation passes ✓
The JWT is propagated as-is in the Authorization header to the SFSF API backend
SFSF validates the JWT Bearer token against its own IAS trust configuration and returns the employee data

Response flows back through EIC to the original caller.

Step 6: What Happens on Validation Failure?

If the JWT is invalid — expired, wrong audience, or tampered signature — EIC returns:

HTTP 401 Unauthorized

{

"error": {

"code": "invalidToken",

"message": "Unable to authenticate user, invalid token"

}

The request never reaches the backend. This is the security guarantee of the non-deletable Authentication Policy — the backend is always protected.

Key Takeaways

The Authentication Policy is the immovable security anchor of every EIC API artifact — and that is a feature, not a limitation.
Tenant specific (XSUAA) authentication is your go-to for BTP-native, SAP-ecosystem calls. Zero configuration friction, pre-established trust.
External (OIDC) authentication unlocks enterprise-wide API security — enabling any OIDC-compliant IDP to serve as the trust authority, with EIC validating tokens using standard OIDC discovery.
Configuration is declarative and straightforward — four fields (Well-Known URL, Audience, Client ID, and the optional User Info Key) are all you need to onboard an external IDP into your API security model. The User Info Key is a lightweight but powerful addition — it shapes how callers appear in your audit logs without touching the authentication flow.
Token propagation works seamlessly — validated external JWT tokens are forwarded to backend systems like SuccessFactors, enabling clean end-to-end identity chaining without re-authentication.
The SFSF + SAP IAS scenario demonstrates a production-grade pattern: IAS as the central identity broker, JWT Bearer as the grant type, and EIC as the secure, policy-governed API gateway — all within your private, on-premise or hybrid landscape.

What's Next?

The introduction of External IDP authentication in EIC is a significant step toward making EIC a truly enterprise-grade, identity-agnostic API gateway — one that can sit in your private landscape while speaking the universal language of OIDC.

In upcoming post, I'll explore:

Configuration and Authentication via Microsoft Entra ID → Integration Cell (New generation cloud based runtime for API Management) for enterprise SSO-driven API access

Stay tuned, and feel free to drop your questions and experiences in the comments below!

For official documentation, refer to the SAP Help Portal – Authentication Policy for API Artifacts

Step-by-Step Guide: Real Time Currency Conversion using SAP Integration Suite (CPI)

2026-04-06T09:44:32.392000+02:00

Introduction

In real-world integration scenarios, integrations are never limited to just data movement. Very often, they also involve business logic that needs to be accurate, reliable, and understandable for non‑technical users. One such recurring requirement encounters is currency conversion.

Whether it’s for reporting, billing, or analytics, converting currency values accurately and in real time is an important requirement.

In this blog, I will be sharing a real‑time currency conversion iFlow that I designed and implemented using SAP Integration Suite (CPI). This solution uses an external currency exchange‑rate API (RapidAPI) and delivers the result in a clean, email‑friendly output, along with robust exception handling.

Business Scenario

The scenario is straightforward but very realistic:

A source system sends an amount in one currency
A target system expects the amount in another currency
The exchange rate must be live and reliable
The final output should be human‑readable and user friendly, not just raw JSON

At the same time, the integration should not break silently when:

Mandatory fields are missing
The input payload is malformed
The external API is down
Any runtime exception occurs

This Integration scenario strictly follows all the mentioned points and ensures that it give accurate results and handle errors efficiently.

Input Payload (Source System to CPI)

The source system (ie, Postman) sends a simple JSON payload:

Mandatory Fields

sourceCurrency – currency to convert From
targetCurrency – currency to convert To
sourceAmount – amount to be converted

NOTE:

I have made a conscious decision to treat all three as mandatory.
If even one is missing, the message is rejected immediately and routed to the Exception Subprocess.

High‑Level Architecture

The integration flow consists of:

HTTPS Sender – receives the request
Content Modifier – stores RapidAPI host and key securely
Groovy Script – validates input and extracts fields
Request Reply – calls external exchange‑rate API
JSON to XML Converter – prepares response for XSLT
XSLT Mapping – beautifies output into HTML
Mail Adapter – sends result to user
Exception Subprocess – handles all runtime failures

STEP 1: HTTPS Sender – Entry Point of the Integration Flow

The integration flow begins with an HTTPS Sender Adapter, which acts as the entry point for the entire currency conversion process.

Purpose of HTTPS Sender

Exposes the iFlow as a secure REST endpoint
Receives the input JSON payload from the source system (Postman)
Secure by default and commonly used in real projects for inbound APIs

STEP 2: Content Modifier – Managing API Credentials

Instead of hard‑coding the RapidAPI host and key inside a Groovy script, I stored them as headers in a Content Modifier. It makes the integration much more maintainable.

Credentials are easy to change
Scripts remain clean
No risk of accidentally logging secrets

STEP 3: Groovy Script – Input Extraction & Validation

The Groovy script performs hard validation for the incoming payload.

Here is the Groovy Script:

So in this Groovy script, I have :

Parsed the JSON explicitly
Checked each mandatory field
Stored valid values as Exchange Properties
Throws a meaningful exception if any field is missing

This hard validation is crucial because CPI does not throw errors for missing JSON fields by default.

Because of this, invalid messages are stopped immediately and routed to the Exception Subprocess

STEP 4: Request Reply – Calling the Exchange Rate API

The Request Reply step dynamically calls the external RapidAPI Currency Exchange endpoint using:

Source currency
Target currency
Secure headers from the Content Modifier

And If the API:

Times out
Returns an error
Is unreachable

Exception Subprocess handles the failure gracefully.

STEP 5: JSON to XML Converter

Since XSLT only works with XML, so i converted the API’s JSON response into XML.

This made:

Mapping easier
Formatting predictable
Transformation logic much cleaner

STEP 6: XSLT Mapping – Beautified HTML Output

Here is the XSLT Script:

Instead of returning raw API data in JSON, I used XSLT to generate a beautiful modern HTML card, optimized for email clients.

Features that i have focused for beautification includes:

A green glowing success card
Currency symbols
Proper decimal formatting
Email‑safe inline CSS
Readable and user friendly

STEP 7: Mail Adapter – Delivering the Result

The Mail Adapter sends:

The formatted HTML
Clean layout
No broken styling
Compatible with Outlook, Gmail, mobile clients

STEP 8: Exception Subprocess – For Error Handling

The Exception Subprocess ensures there are no silent failures and handles errors effectively.

Here's what the Groovy script does:

Captures runtime errors
Identifies what actually went wrong
Categorizes the error:
- Missing mandatory fields
- Malformed JSON
- External API failure
- Script execution error
Generates modern card formation using HTML for Beautification

Here what the Error Mail Adapter does:

Send a structured and well formatted HTML error email, just like as for success mail

Success Email Output:

Gives successful currency conversion information dynamically

Error Email Output:

Gives Error message and its possible causes in case of any error

Key benefits of this approach

Robust mandatory field validation
Secure credential handling
Professional, email‑ready output
User‑friendly error messages
Reusable iFlow pattern for other APIs
Fully Externalized Parameters

Conclusion

This currency conversion iFlow shows how SAP Integration Suite can be used for much more than just routing messages.

I was able to build an integration that is stable, readable, and production‑ready.

This implementation helped me better understand how to design flexible and maintainable integration flows, especially when dealing with real-world requirements.

I hope this experience helps others who are working on similar scenarios in SAP Cloud Integration.

If you found this blog helpful:

Like the blog
Share it
Feel free to comment or ask questions

Happy Integrating !

Automating SAP CPI Deployment Validation : IntegrationRuntimeArtifacts API in Real-Time Monitoring

2026-04-06T13:09:45.902000+02:00

Background & Problem Statement

As an integration developer we know that our SAP Integration Suite landscape handles hundreds of integration flows across multiple environments — Dev, QA, Pre-Prod/Production.

In many release cycles, our team faces a few pain points like:

Deployed iFlow → Assumed it started → Found error hours later
Wrong version deployed → No one noticed until message failures
Manual checks → Time-consuming → Human error prone
No centralized visibility → Each team checking independently

We can have an automated, programmatic way to:

Verify deployment success immediately after release
Check runtime status in real-time
Integrate this check into our CI/CD pipeline

Discovering the API

SAP Integration Suite exposes a rich set of OData APIs for managing and monitoring integration artifacts.

The key API I used:

GET /api/v1/IntegrationRuntimeArtifacts('{iflowID}')

what this API returns:

<Id>jmsChecksdummy2</Id>
        <Version>1.0.0</Version>
        <Name>jmsChecksdummy2</Name>
        <Type>INTEGRATION_FLOW</Type>
        <DeployedBy>Rohit.Parihar@syngenta.com</DeployedBy>
        <DeployedOn>2026-02-25T09:46:43.180</DeployedOn>
        <Status>STARTED</Status>

</properties>

Design: I understand that the CPI developer does not need steps on how to create the flow and utilize the objects however, I am pasting the flow skeleton here for reference.

I've used two integration processes, both of which can run independently. One runs on a timer-based schedule and the other through an external system using a REST endpoint.
The body remains the same but can be dynamically modified to fetch information for multiple artifacts at once. Since it is externalized, it can be configured without editing the flow.
The payload can also be logged in the message processing logs. This is condition-based, meaning if the Log Payload flag as header is set to true, the payload will be logged otherwise, it will not.

One of the example of the input I'm passing and the response is pasted below.

<root>
<iflowID>jmsChecksDummy</iflowID>
<iflowID>jmsChecks</iflowID>
</root>

Conclusion

The information is helpful for identifying versions mismatch, changes and stage of runtime artifacts in real time.

Note: designtime artifacts information will not include status information.

Hope this helps someone someday, happy learning!

How I Connected Claude AI to My SAP ABAP System Using MCP — A Complete Windows Guide

2026-04-07T12:35:07.976000+02:00

Introduction

The SAP developer community has been buzzing about connecting Claude AI directly to live SAP ABAP systems using MCP (Model Context Protocol) — reading code, modifying objects, creating transports, and activating changes, all from a natural language chat interface.

I tried it myself on Windows, and it works. This blog walks you through exactly how to set it up.

What is MCP?

MCP (Model Context Protocol) is an open standard that lets AI models like Claude connect to external tools and data sources. Think of it as a plugin system for AI — instead of just answering questions from training data, Claude can actually call tools that interact with real systems.

For SAP developers, this means Claude can:

Read your actual ABAP code directly from your system
Write and modify objects
Run syntax checks
Create transport requests
Activate objects

All without you copy-pasting anything.

The Architecture

Claude Desktop / Claude Code CLI         ↕ MCP Protocol  ┌──────────────────────────┐  │   mcp-abap-adt           │  ← Read-only (13 tools)  │   mcp-abap-abap-adt-api  │  ← Full CRUD (30 tools)  └──────────────────────────┘         ↕ ADT REST API    Your SAP ABAP System

Both MCP servers were built by Mario Andreschak and communicate with SAP via the same ADT (ABAP Development Tools) API that Eclipse uses under the hood.

Prerequisites

Before starting, you need:

Windows 10 or 11 (64-bit)
An SAP ABAP system with /sap/bc/adt active in SICF
A user with SAP_ADT_DEVELOPER role (or equivalent)
A Claude Pro/Max/Team subscription at claude.ai
Internet connection

Step 1 — Install Node.js

Node.js is the runtime required by Claude Code CLI and the MCP servers.

Go to https://nodejs.org and download the LTS version
Install with all defaults
Verify in Command Prompt:

node -v    → v24.x.xnpm -v     → 11.x.x

Step 2 — Install Git for Windows

Git provides the bash shell Claude Code requires on Windows.

Go to https://git-scm.com/downloads/win and download the installer
During setup, on the PATH screen select: "Git from the command line and also from 3rd-party software"
Complete with all other defaults

Step 3 — Install Claude Code CLI

cmd

npm install -g @anthropic-ai/claude-codeclaude --version

Then log in:

cmd

claude

Select option 1 (Claude subscription), log in via browser, return to terminal.

Step 4 — Install mcp-abap-adt (Read-Only MCP Server)

This server gives Claude read access to your SAP system with 13 tools including GetProgram, GetClass, GetFunction, GetTable, SearchObject, and more.

cmd

mkdir C:\Toolscd C:\Toolsgit clone https://github.com/mario-andreschak/mcp-abap-adtcd mcp-abap-adtnpm installnpm run build

Create a .env file in the folder:

SAP_URL=https://your-sap-system.com:44300SAP_USERNAME=YOUR_USERNAMESAP_PASSWORD=YOUR_PASSWORDSAP_CLIENT=300TLS_REJECT_UNAUTHORIZED=0

cmd

claude mcp add mcp-abap-adt node C:/Tools/mcp-abap-adt/dist/index.jsclaude mcp list

You should see: mcp-abap-adt: ✓ Connected

Step 5 — Install mcp-abap-abap-adt-api (Full CRUD Server)

This is the powerful one — 30 tools including read, write, syntax check, activate, lock/unlock, and transport management.

cmd

cd C:\Toolsgit clone https://github.com/mario-andreschak/mcp-abap-abap-adt-api.gitcd mcp-abap-abap-adt-apinpm installnpm run build

Create .env (note: slightly different variable names):

SAP_URL=https://your-sap-system.com:44300SAP_USER=YOUR_USERNAMESAP_PASSWORD=YOUR_PASSWORDSAP_CLIENT=300SAP_LANGUAGE=ENNODE_TLS_REJECT_UNAUTHORIZED=0

cmd

claude mcp add mcp-abap-adt-api node C:/Tools/mcp-abap-abap-adt-api/dist/index.js

Step 6 — Setup Claude Desktop (GUI Interface)

Claude Desktop is where it really comes alive — a beautiful chat UI like the LinkedIn video.

Download from https://claude.ai/download
Install and log in
Go to ☰ → Settings → Developer → Edit Config
Replace the content with:

json

{
  "mcpServers": {
    "mcp-abap-adt": {
      "command": "C:\\Program Files\\nodejs\\node.exe",
      "args": ["C:\\Tools\\mcp-abap-adt\\dist\\index.js"],
      "env": {
        "SAP_URL": "https://your-sap-system.com:44300",
        "SAP_USERNAME": "YOUR_USERNAME",
        "SAP_PASSWORD": "YOUR_PASSWORD",
        "SAP_CLIENT": "300",
        "TLS_REJECT_UNAUTHORIZED": "0"
      }
    },
    "mcp-abap-adt-api": {
      "command": "C:\\Program Files\\nodejs\\node.exe",
      "args": ["C:\\Tools\\mcp-abap-abap-adt-api\\dist\\index.js"],
      "env": {
        "SAP_URL": "https://your-sap-system.com:44300",
        "SAP_USER": "YOUR_USERNAME",
        "SAP_PASSWORD": "YOUR_PASSWORD",
        "SAP_CLIENT": "300",
        "SAP_LANGUAGE": "EN",
        "NODE_TLS_REJECT_UNAUTHORIZED": "0"
      }
    }
  }
}

⚠️ Windows-specific tip: You MUST use the full path C:\\Program Files\\nodejs\\node.exe — using just "node" does not work in Claude Desktop on Windows. Also note double backslashes \\ in all paths.

Kill Claude in Task Manager and reopen
Go back to Settings → Developer — you should see both servers listed as running ✅

Step 7 — Add Free Official SAP MCP Servers

Bonus: Claude Desktop has a built-in directory of official SAP MCP servers. Click "Connect your tools to Claude" at the bottom of the chat, search for "SAP", and add:

SAPUI5 MCP Server — for UI5 development
SAP CAP MCP Server — for CAP projects
SAP Fiori MCP Server — for Fiori Elements apps

Also add these free hosted servers to Claude Code CLI (no installation needed):

cmd

claude mcp add --transport http abap-docs https://mcp-abap.marianzeis.de/mcpclaude mcp add --transport http sap-docs https://mcp-sap-docs.marianzeis.de/mcp

These give Claude access to the full ABAP keyword documentation across 8 SAP releases, ABAP cheat sheets, CAP docs, UI5 docs, and SAP Community posts.

Testing It

Open Claude Desktop, create a New Chat, and type:

Get the source code of program SAPMV45A

Watch Claude automatically call your SAP system, retrieve the source code, and explain it — all in seconds.

For write operations (test on $TMP objects only!):

Find a simple Z program in $TMP, add a comment at the top saying "Modified by Claude", save and activate it

For complex workflows like the LinkedIn video:

Connect to my SAP system. Copy class ZCL_SOURCE from package ZPKG_A into ZPKG_B, rename it to ZCL_TARGET, change the carrier_id in the SELECT for /DMO/CONNECTION, create a transport and activate.

Security Notes

Never commit .env files to Git
Change your SAP password if shared in screenshots
Use dedicated service accounts with minimum required authorizations
Only test write operations in $TMP before moving to real packages
The TLS_REJECT_UNAUTHORIZED=0 flag disables SSL validation — use only in dev environments
Check your company's AI policy before sending code to external APIs

My Experience

What surprised me most is how Claude handles the entire workflow autonomously. It doesn't just write code — it searches for the object, reads the source, understands the structure, reads class includes, creates the transport, locks the object, writes the code, runs a syntax check, activates, and unlocks. All from one natural language request.

Important Hint

It can make ABAP-specific mistakes (like forgetting RAP locking fields, or using reserved DDIC words). Always review AI-generated code before activating in production. But as a development accelerator and code reviewer, it's genuinely powerful.

References

GitHub: mcp-abap-adt — Mario Andreschak
GitHub: mcp-abap-abap-adt-api — Mario Andreschak
GitHub: sap-skills — 35 Claude Code plugins for SAP
Blog: SAP Docs MCP Server — Marian Zeis
Blog: Claude Code via MCP — SAP Community
Blog: Installing and Extending an ABAP MCP Server — SAP Community

I hope this helps other ABAP developers get started. If you run into issues or have questions, feel free to comment below. Happy coding!

Designing File Processing in BTP Integration Suite with Amazon S3 and Apache POI

2026-04-07T15:48:35.411000+02:00

Introduction

Even in the world of AI and LLMs, file-based interfaces are still very common in enterprise landscape. Legacy systems and external applications often exchange operational data in spreadsheet form, even when the downstream integration landscape is API-driven. This creates an interesting architectural challenge for the middleware layer to perform controlled document-level transformations along with integration.

Recently, I came across a use case where an Excel file placed in an Object Store had to be picked up by SAP Cloud Integration, enriched with additional data and written back. At first glance, this looked like a straightforward file transfer requirement. However, the real question was not about moving the file from one folder to another, but about deciding how the data-level processing should be performed and how much should responsibly sit within the integration layer.

I thought this would be a good opportunity to document my learning through a practical end-to-end scenario. In this blog, I will focus on five key aspects:

Provisioning and using Amazon S3 as the object store through SAP BTP.
Configuring and performing S3 operations through AWS CLI.
Connecting SAP Cloud Integration to the S3 bucket using the AmazonWebServices adapter.
Integrating external open-source libraries (example: Apache POI) into Cloud Integration.
Finally, Groovy script to perform document-level processing and writing the file back to S3.

I have tried to keep it simple and the motive behind this blog is to showcase the possibilities and give a starting point for developers and consultants.

1. Provisioning and using Amazon S3 as the object store through SAP BTP:

I chose to explore SAP BTP Object store as a part of this journey. You can very well substitute it with SFTP server for file based integration as well. You can very well search for Object Store from the Service Marketplace of your BTP subaccount. Refer below diagram:

Figure 1: Object Store Service

Create a service instance.This service is specific to the infrastructure layer such as Azure Blob Storage, Amazon Web Services, and Google Cloud Platform. In my case as my BTP subaccount is provisioned on AWS, S3 instance will be created.

Once the instance is successfully created, create a service key with preferred name, for example: sandbox-object-store-service-key. This service key will provide all the metadata for the provisioned S3 bucket.

2. Configuring and performing S3 operations through AWS CLI:

I wanted a simple way to validate the S3 bucket outside SAP Cloud Integration before using it into the iFlow. AWS CLI was the choice because it allowed me to upload, download, list, and delete files directly from the terminal. That made it useful not only for initial setup, but also for end-to-end validation of the overall integration flow.

Installing AWS CLI

brew install awscli

aws --version

If AWS CLI is installed correctly, you should see the version details.

Configuring AWS CLI

aws configure

The above command will ask you to enter below details

Access Key ID
Secret Access Key
Region
Output format (default it to: json)

All the above details can be obtained from the service key which you have created in the above section.

You can check of the attributes are added to the configuration using the below command

aws configure list

Connecting to the S3 Bucket

aws s3 ls "s3://<bucket-name-from-service-key>/inbound/"

This is an important validation step. If the command succeeds, it confirms that:

The CLI is installed correctly
Credentials are valid
Configured endpoint is correct
Access policy allows listing the bucket

Uploading a File to S3

I created a excel file which contains some predefined data as shown below

Col1	Col2	Col3
1	2	3
4	5	6
7	8	9

Using the following command, you can upload the file from your local machine to S3 bucket.

aws s3 cp "/Users/<Directory>/Desktop/Book1.xlsx" "s3://<bucket-name>/inbound/Book1.xlsx"

Once done you can check by listing the files in the inbound directory

aws s3 ls "s3://<bucket-name-from-service-key>/inbound/"

With this, you have successfully configured S3 bucket and uploaded files.

3. Connecting SAP Cloud Integration to the S3 with AmazonWebServices adapter:

To connect Cloud Integration with Amazon S3, SAP provides the AmazonWebServices adapter. As per the Cloud Integration adapter documentation, this adapter supports S3 for both sender and receiver scenarios. For more details you can check the Business Accelerator Hub

To start with I created an integration flow as shown in the below image

Figure 2: Integration Flow

The above integration flow performs below tasks:

Leverages "AmazonWebServices" receiver adapter to read file from S3 bucket.
Logs the file metadata
Reads the excel workbook and adds data to the existing row (You can enrich data from external API as well and extend this use case).
Uploads the updated file to the S3 bucket using "AmazonWebServices" receiver adapter for write operation.

For reference, I provided the screenshot of the adapter configuration

Figure 3: AWS Adapter Config

4. Integrating external open-source libraries (example: Apache POI) into Cloud Integration:

Standard Groovy scripting alone was not sufficient because the requirement was to read and update Excel workbook content directly. That introduced the need for an external library capable of working with spreadsheet structures such as workbooks, sheets, rows, and cells. After further exploring, I used Apache POI, which is a widely used open-source Java library for Microsoft Office document processing.

You can add external archives to be referenced in the groovy script. This makes it possible to bring in third-party libraries when the use case goes beyond what the standard runtime APIs provide. You can do it from the References section as shown below

Figure 4: Archives

Following JARs are imported in the integration flow:

commons-collections4-4.1.jar
poi-3.17.jar
poi-ooxml-3.17.jar
poi-ooxml-schemas-3.17.jar
xmlbeans-2.6.0.jar

Important Note: A practical example of this pattern is Apache POI, but the same concept can also be applied to other well-scoped open-source libraries when there is a clear functional reason to do so and the additional dependency remains manageable, secured and as per licensing agreements.

5. Groovy script to perform document-level processing and writing the file back to S3.

Once the connectivity to S3 was established and the Apache POI libraries were imported in the integration flow, the data processing logic is implemented in a Groovy script.
The Groovy script shown below is a good starting point to demonstrate data handling and enrichment in SAP Cloud Integration using Apache POI. In this example, I update the excel worksheet by adding a new column (SUM) and populating it with the summation of the first three columns for each data row. Eventually the data is saved in a new file named : Book2.xlsx

import com.sap.it.script.v2.api.Message
import org.apache.poi.ss.usermodel.Cell
import org.apache.poi.ss.usermodel.DataFormatter
import org.apache.poi.ss.usermodel.Row
import org.apache.poi.ss.usermodel.Sheet
import org.apache.poi.ss.usermodel.Workbook
import org.apache.poi.xssf.usermodel.XSSFWorkbook
import java.io.ByteArrayInputStream
import java.io.ByteArrayOutputStream

def Message processData(Message message) {

    byte[] body = message.getBody(byte[].class)
    if (!body) {
        throw new IllegalStateException('Payload is empty')
    }

    Workbook workbook
    try {
        workbook = new XSSFWorkbook(new ByteArrayInputStream(body))
        Sheet sheet = workbook.getSheetAt(0)

        DataFormatter formatter = new DataFormatter()

        int headerRowIndex = sheet.getFirstRowNum()
        Row headerRow = sheet.getRow(headerRowIndex)
        if (headerRow == null) {
            throw new IllegalStateException('Sheet has no header row')
        }

        Map<String, Integer> headerToIndex = buildHeaderIndex(headerRow, formatter)
        Integer col1Idx = headerToIndex.get('col1')
        Integer col2Idx = headerToIndex.get('col2')
        Integer col3Idx = headerToIndex.get('col3')

        if (col1Idx == null || col2Idx == null || col3Idx == null) {
            throw new IllegalStateException("Expected header columns: Col1, Col2, Col3")
        }

        int sumColIdx = col3Idx + 1;
        setCellString(headerRow, sumColIdx, 'SUM')

        int lastRow = sheet.getLastRowNum()
        for (int r = headerRowIndex + 1; r <= lastRow; r++) {
            Row row = sheet.getRow(r)
            if (row == null) continue

            double v1 = readNumeric(row.getCell(col1Idx, Row.MissingCellPolicy.RETURN_BLANK_AS_NULL))
            double v2 = readNumeric(row.getCell(col2Idx, Row.MissingCellPolicy.RETURN_BLANK_AS_NULL))
            double v3 = readNumeric(row.getCell(col3Idx, Row.MissingCellPolicy.RETURN_BLANK_AS_NULL))
            double sum = v1 + v2 + v3

            Cell sumCell = row.getCell(sumColIdx, Row.MissingCellPolicy.CREATE_NULL_AS_BLANK)
            sumCell.setCellValue(sum)
        }

        ByteArrayOutputStream out = new ByteArrayOutputStream(Math.max(body.length, 1024))
        workbook.write(out)
        message.setBody(out.toByteArray())
        message.setHeader("CamelFileName", "Book2.xlsx")
        message.setHeader('Content-Type', 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet')
        return message
    } finally {
        if (workbook != null) {
            workbook.close();
        }
    }
}

def Map<String, Integer> buildHeaderIndex(Row headerRow, DataFormatter formatter) {
    Map<String, Integer> result = new HashMap<>()
    short last = headerRow.getLastCellNum()
    if (last < 0) return result

    for (int c = 0; c < last; c++) {
        Cell cell = headerRow.getCell(c, Row.MissingCellPolicy.RETURN_BLANK_AS_NULL)
        if (cell == null) continue
        String name = formatter.formatCellValue(cell)
        if (name == null) continue
        name = name.trim().toLowerCase()
        if (!name) continue
        result.put(name, c)
    }
    return result
}

def void setCellString(Row row, int colIdx, String value) {
    Cell cell = row.getCell(colIdx, Row.MissingCellPolicy.CREATE_NULL_AS_BLANK)
    cell.setCellValue(value)
}

def double readNumeric(Cell cell) {
    if (cell == null) return 0d
    return cell.getNumericCellValue()
}

Once the additional data is added to the worksheet, last step is to write back the file in the S3 bucket using AWS receiver adapter with write operations. The connection properties remain same as before. The processing properties are updated as shown in the below image

Figure 5: AWS S3 Write File

Once you deploy the integration flow and completes successfully, you should see a new file in your S3 bucket.

Download the file from S3 on your local using below command

aws s3 cp "s3://<S3-bucket-name>/inbound/Book2.xlsx" "/Users/<Directory>/Desktop/Book2.xlsx"

You should see a fourth column "SUM" as shown below

Col1	Col2	Col3	SUM
1	2	3	6
4	5	6	15
7	8	9	24

Important Considerations

This approach works well in a controlled environment with smaller dataset, there are few important points worth keeping in mind

Use compatible JAR versions: Open source libraries should be compatible with the JAVA runtime.
Keep an eye on security vulnerabilities: Open source libraries might come with some security vulnerabilities.
Plan for upgrades carefully: Test your integrations thoroughly if you upgrade the JAR files or if there is platform upgrades.
Be cautious with large files: Since the workbook is processed in memory, there is a possibility of higher memory consumption and potential out-of-memory situations for large datasets. In such cases, it is better to split the file in smaller sizes and then process it.
Exception Handling: Ensure robust exception handling and alerting during development.

Wrap-Up

At this point, we have looked at:

Provisioning and using Amazon S3 for the integration scenario
Performing basic S3 operations through AWS CLI
Connecting SAP Cloud Integration to Amazon S3 using the AmazonWebServices adapter
Integrating external open-source libraries such as Apache POI into Cloud Integration
Using Groovy and Apache POI to enrich an Excel workbook and write the updated file back to S3

This exercise was a practical way to explore how SAP Cloud Integration can handle document-level processing in addition to file movement. While the example itself was intentionally simple, the pattern opens up interesting possibilities for data enrichment scenarios within the integration layer.

Disclaimer: This is not an official reference application or documentation. The thoughts outlined in this blog are based on my real world experience and learnings.

Feel free to “like“, “Share“, “Add a Comment” and to get more updates about my next blogs follow me!

References

Building a CAP App with Fiori Integration – Part 1: Environment & HANA Cloud Setup

2026-04-08T08:32:43.137000+02:00

In this blog series we are going to see how to create a Basic CAPM Application from scratch through BTP Trial Account and Integrate it with Fiori.

--> The First Part of this series will explain all the Pre-Requisites to be done before creating CAP Application.

--> Second Part of this series will explain how to create CAP Application and Integrate it with Fiori.

Cloud Based Applications may look complex from outside but when blocks are perfectly aligned even a beginner can build a powerful CAP application using BAS. Let’s dive in and start arranging those blocks from the ground up.

Tools Required: BAS, HANA Cloud Central

At end of this series we can able to successfully run a CAP Application in Fiori Generated App and able to create entries in HANA Cloud Central based DB from the Fiori App.

1. Create a BTP Trial Account/Use existing Global Account for the Development Process. Access to your SubAccount as below from Account Explorer -> SubAccounts.

2. Now get into Sub Account and Navigate to Instances and Subscriptions as below and then click Create Button.

3. Under Services tab -> Select SAP HANA Cloud & in Plan select Tools/hana-cloud which makes service compatible for shareable instance.

Note: If SAP HANA Cloud is not showing under services tab then add it from Entitlements->Add service Plans.

4. After Creation, the SAP HANA Cloud Central tool will be added to subscription as below along with Business Application Studio. Note: Incase if BAS is not added then add that as well from Create Button.

5. Once the HANA Cloud and BAS set up is done, then navigate to Security->Users and assign these Roles.

Roles Required :

Note: These roles should be assigned to the user and with that HANA Cloud can be accessed.

Before moving into next point lets have a quick overview on what is SAP HANA Cloud Central and BAS.

SAP HANA Cloud Central - It manages SAP HANA Cloud instances within the SAP Business Technology Platform (BTP). It acts as a centralized dashboard to create, monitor, and maintain both SAP HANA database instances and Data Lake instances.

SAP BAS - SAP Business Application Studio is a cloud-based Integrated Development Environment (IDE) designed specifically to build and extend SAP applications.

Basically SAP HANA Cloud Central helps to manage data through cloud instances and BAS helps in building data. We can decide how the data should look/maintained from BAS.

Now let's continue with the Pre-Requisites;

6. As a next step, navigate to Cloud Foundry->Spaces and ensure if space dev is available. If that is not there then create dev space using Create space Button. This Space is really important as it acts as a deployment target from CAP where code is deployed and executed.

7. Navigate to HANA Cloud and click on Create Instance. Again, Creation of HANA Cloud Instance is as important as creation of dev space in cloud foundruy. It acts as the database-as-a-service (DBaaS) where application’s data is permanently stored. HANA Cloud instance also contains HDI Containers which act as a bridge between design-time code from BAS into run-time database objects like tables and views.

8. On Type section select Instance configuration as Configure Manually ( Select other options if you want to configure instance in different way ) and Instance type as SAP HANA Database as we are creating Instance for HANA DB. If Data Lake is expected then select Data lake instead of HANA DB.

9. In section SAP HANA Database General, Cloud foundry tab to be navigated for filling instance related details as the deployment happens for Cloud Foundry. But it is disabled by default. Henceforth user should select Sign in to cloud Foundry Environment and after sign in the Cloud Foundry tab will be enabled. In that tab fill the details as below.

10. Post filling the important section as above, navigate to other sections where Connection Details and Advanced settings needs to be mentioned. For a Minimalistic App execution these tabs are not required and henceforth I've skipped it. It needs to be filled based on Business expectations.

11. Enable Data lake if required and click on create instance as below.

12. Once above process is done, Test Instance will be created for SAP HANA Cloud central as below and it acts as DB for the Developments made from CAP Project.

13. Now SAP HANA Cloud is all set, Let's Navigate to BAS and create Dev Space. Get back to your subaccount. Navigate Instances and Subscriptions -> Business Application Studio. Click on create Dev space.

14. Define Dev space name and select Full Stack cloud Application option as below.

15. With that Dev space will be created in BAS.

From here, let's continue on Part - 2 where full stack CAP Application will be built and Deployed/Integrated with SAP HANA Cloud.

What we did till now.

-> Created Trial Account

-> Enabled necessary subscriptions and Roles

-> Set up SAP HANA Cloud Central

-> Created Instance and ensured Dev space is available

-> Set up BAS Dev space.

PART: 2 Link - Build BTP CAP App with Fiori Integration – Part 2: Implementing End to End App

SAP Cloud Integration (CI/CPI) - Identify & Manage Unused iFlows (integration flows)

2026-04-10T17:24:28.745000+02:00

Over time, SAP Cloud Integration (CI/CPI) tenants, especially larger ones tend to accumulate integration flows that are no longer needed. These may include old test flows, integration scenarios tied to decommissioned systems, or temporary interfaces created during projects and never removed.

Manually identifying such unused integration flows is difficult and time‑consuming. SAP Cloud Integration provides standard APIs that expose deployment status and recent execution history. By combining these APIs, we can build a simple, transparent, and repeatable solution to highlight unused integration flows and optionally clean them up.

Problem Statement

Integration teams often face questions such as:

Which integration flows are still being used?
Which flows have silently stopped executing?
Which deployed flows can safely be reviewed or removed?

Solution Overview

The solution described in this blog is implemented as a controller integration flow. It uses only standard SAP Cloud Integration APIs and consists of the following steps:

Retrieve all currently deployed integration flows
Retrieve message processing logs from the monitoring API
Correlate deployment status with execution evidence
Identify unused integration flows
Generate easy‑readable reports (JSON and CSV)
Optionally undeploy unused integration flows (explicitly controlled)

What Do We Mean by Unused Integration Flows?

Due to SAP CI monitoring retention limits, this solution intentionally uses a clear and conservative definition:

An unused integration flow is a deployed integration flow that has not shown any execution activity within the available monitoring window and is older than a configurable grace period.

Rather than making assumptions about long‑term execution history, the solution classifies unused flows based on what the platform can reliably confirm.

Distinction Between Inactive and No Message Processing Logs

When the inactivity threshold is configured to a value lower than the monitoring retention window (for example, 14 days), the solution can provide additional insight:

Inactive Integration Flows:

Execution logs exist
The flow executed previously but not within the last N days (eg: 14 days)

No Message Processing Logs:

No execution records exist within the monitoring window
This may indicate that the flow never executed recently or that any execution happened outside the retention period (30 days)

When the inactivity threshold is equal to or greater than the monitoring retention period, both cases are safely grouped under a single concept: unused integration flows.

High-Level Architecture

The controller integration flow is structured into modular steps:

Retrieve deployed integration flows
Retrieve message processing logs
Build an execution map
Detect unused integration flows
Generate reports
Optional undeploy branch

Update: Flow is updated in order to account pagination while extracting messages from Message processing logs API due to default 1000 messages/ extraction by the API

This modular design keeps the logic easy to understand, test, and extend.

Scripts Used in the Integration Flow

extractDeployedIflows

import com.sap.gateway.ip.core.customdev.util.Message
import groovy.json.JsonSlurper

def Message processData(Message message) {

    def body = message.getBody(String)
    def json = new JsonSlurper().parseText(body)

    if (!json?.d?.results) {
        throw new RuntimeException("Invalid response from IntegrationRuntimeArtifacts API")
    }

    def deployedIflows = []

    json.d.results.each { r ->

        // Only Integration Flows
        if (r.Type == "INTEGRATION_FLOW") {

            // Consider active runtime states only
            if (r.Status in ["STARTED", "STARTING"]) {

                deployedIflows << [
                    id         : r.Id,
                    name       : r.Name,
                    version    : r.Version,
                    status     : r.Status,
                    deployedOn : r.DeployedOn,
                    deployedBy : r.DeployedBy
                ]
            }
        }
    }

    message.setProperty("DEPLOYED_IFLOWS", deployedIflows)
    message.setProperty("DEPLOYED_COUNT", deployedIflows.size())

    return message
}

This script parses the Integration Runtime Artifacts API response and collects all deployed integration flows along with metadata such as deployment timestamp.

Update:

Instead of the below script "buildExecutionMapFromLogs", please use "buildExecutionMapFromLogsPaged"

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

def Message processData(Message message) {

    def xmlText = message.getBody(String)
    def xml = new XmlSlurper(false, false).parseText(xmlText)

    // Get or initialize execution map safely
    def executionMap = message.getProperty("EXECUTION_MAP")
    if (!(executionMap instanceof Map)) {
        executionMap = [:]
    }

    int entryCount = 0   

    xml.entry.each { entry ->
        entryCount++    

        def props = entry.content."m:properties"
        if (!props) {
            return
        }

        def iflowName = props."d:IntegrationFlowName"?.text()
        def logStart  = props."d:LogStart"?.text()

        if (iflowName && logStart) {
            def existing = executionMap[iflowName]
            if (!existing || logStart > existing) {
                executionMap[iflowName] = logStart
            }
        }
    }

    // Save merged execution map
    message.setProperty("EXECUTION_MAP", executionMap)

    // Pagination control
   
    def pageSize = (message.getProperty("LOG_PAGE_SIZE") ?: "1000") as Integer
    def skip     = (message.getProperty("LOG_SKIP") ?: "0") as Integer

    if (entryCount < pageSize) {
    // Last page reached
        message.setProperty("HAS_MORE_LOGS", false)
    } else {
    // More pages available
    message.setProperty("LOG_SKIP", skip + pageSize)
    message.setProperty("HAS_MORE_LOGS", true)
}


    return message
}

~~buildExecutionMapFromLogs~~

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

def Message processData(Message message) {

    def xmlText = message.getBody(String)
    def xml = new XmlSlurper(false, false).parseText(xmlText)

    /*
      Map:
        IntegrationFlowName -> Latest LogStart
    */
    def executionMap = [:]

    xml.entry.each { entry ->

        // CPI-safe namespace access
        def props = entry.content."m:properties"

        if (!props) {
            return
        }

        def iflowName = props."d:IntegrationFlowName"?.text()
        def logStart  = props."d:LogStart"?.text()

        if (iflowName && logStart) {

            def existing = executionMap[iflowName]

            // Keep only the latest timestamp
            if (!existing || logStart > existing) {
                executionMap[iflowName] = logStart
            }
        }
    }

    message.setProperty("EXECUTION_MAP", executionMap)
    message.setProperty("EXECUTION_COUNT", executionMap.size())

    return message
}

~~This script parses the Message Processing Logs response and builds a map that links each integration flow ID to its most recent execution timestamp found in monitoring.~~

detectUnusedIflows

import com.sap.gateway.ip.core.customdev.util.Message
import java.time.LocalDateTime
import java.time.temporal.ChronoUnit

def Message processData(Message message) {

    def deployed = message.getProperty("DEPLOYED_IFLOWS")
    def execMap  = message.getProperty("EXECUTION_MAP")
    def days     = message.getProperty("INACTIVITY_DAYS") as Integer

    if (!deployed || execMap == null || days == null) {
        throw new RuntimeException(
            "Missing required properties: " +
            "DEPLOYED_IFLOWS=${deployed != null}, " +
            "EXECUTION_MAP=${execMap != null}, " +
            "INACTIVITY_DAYS=${days != null}"
        )
    }

    def now = LocalDateTime.now()
    def inactiveIflows = []

    deployed.each { i ->

        def deployedOn = LocalDateTime.parse(i.deployedOn)

        // Grace period: skip newly deployed flows
        def deployedDaysAgo = ChronoUnit.DAYS.between(deployedOn, now)
        if (deployedDaysAgo < days) {
            return
        }

        def lastRun = execMap[i.id]

        if (lastRun) {
            // Execution exists in monitoring
            def last = LocalDateTime.parse(lastRun)
            def inactiveDays = ChronoUnit.DAYS.between(last, now)

            if (inactiveDays >= days) {
                inactiveIflows << [
                    id            : i.id,
                    name          : i.name,
                    deployedOn    : i.deployedOn,
                    lastExecution : lastRun,
                    inactiveDays  : inactiveDays,
                    reason        : "INACTIVE"
                ]
            }
        } 
        
        
        else {
            // No execution detected in monitoring
            inactiveIflows << [
                id            : i.id,
                name          : i.name,
                deployedOn    : i.deployedOn,
                lastExecution : null,
                inactiveDays  : deployedDaysAgo,
                reason        : "NO_MONITORING_LOGS"
            ]
        }
        
    }

    message.setProperty("UNUSED_IFLOWS", inactiveIflows)
    message.setProperty("UNUSED_COUNT", inactiveIflows.size())

    return message
}

This script compares deployed integration flows with available execution data. It applies a grace period and identifies which flows can be considered unused.

generateJsonAndCsvReport

import com.sap.gateway.ip.core.customdev.util.Message
import groovy.json.JsonOutput
import java.time.LocalDateTime

def Message processData(Message message) {

    def unused = message.getProperty("UNUSED_IFLOWS") ?: []
    def days   = message.getProperty("INACTIVITY_DAYS")

    // -------- JSON Report --------
    def report = [
        scanTimestamp   : LocalDateTime.now().toString(),
        inactivityDays  : days,
        unusedCount     : unused.size(),
        unusedIflows    : unused
    ]

    def reportJson = JsonOutput.prettyPrint(JsonOutput.toJson(report))

    // Set JSON as response body
    message.setBody(reportJson)
    message.setHeader("Content-Type", "application/json")

    // -------- CSV Report --------
    def csvLines = []
    csvLines << "Id,Name,DeployedOn,LastExecution,InactiveDays,Reason"

    unused.each { u ->
        csvLines << [
            u.id,
            u.name ?: "",
            u.deployedOn ?: "",
            u.lastExecution ?: "",
            u.inactiveDays != null ? u.inactiveDays.toString() : "",
            u.reason ?: ""
        ].join(",")
    }

    def reportCsv = csvLines.join("\n")

    // -------- MPL Attachments --------
    def messageLog = messageLogFactory.getMessageLog(message)
    if (messageLog != null) {

        // JSON attachment
        messageLog.addAttachmentAsString(
            "Unused_Integration_Flow_Report.json",
            reportJson,
            "application/json"
        )

        // CSV attachment
        messageLog.addAttachmentAsString(
            "Unused_Integration_Flow_Report.csv",
            reportCsv,
            "text/csv"
        )
    }

    return message
}

This script produces a JSON and a CSV report containing all unused integration flows. Both reports are attached to the Message Processing Log for auditing and review.

Update:

buildPagingQuery - This script is used to build CamelHTTPQueryHeader which is used to inject for Pagination

import com.sap.gateway.ip.core.customdev.util.Message

def Message processData(Message message) {

    def top  = message.getProperty("LOG_PAGE_SIZE") ?: 1000
    def skip = message.getProperty("LOG_SKIP") ?: 0

    // Build OData pagination query
    message.setHeader(
        "CamelHttpQuery",
        "\$top=${top}&\$skip=${skip}"
    )

    return message
}

countExecutionMap - This script is used to get the get the count in EXECUTION_MAP

import com.sap.gateway.ip.core.customdev.util.Message

def Message processData(Message message) {

    def execMap = message.getProperty("EXECUTION_MAP")
    int count = (execMap instanceof Map) ? execMap.size() : 0

    message.setProperty("EXECUTION_MAP_COUNT", count)

    // Optional: log for visibility
    def log = messageLogFactory.getMessageLog(message)
    if (log != null) {
        log.addCustomHeaderProperty(
            "ExecutionMapCount",
            count.toString()
        )
    }

    return message
}

Integration Flow Steps:

For Integration Content API Reference, please refer this link

1. Setting the inactivity days property to explicity specify if you want to add a grace period Eg: 10 days or 14 days apart from the standard 30 days retention. Setting a property to automatically undeploy the unused flows

2. Call the API /api/v1/IntegrationRuntimeArtifacts to get all the deployed integration flows in the tenant

3. Use the script extractDeployedIflows

Update:

4. Use content modifer "Set - Properties for Pagination" to set the properties needed for pagination

5. Add a Looping process Call "Get - Message Processing Logs"

6. Use the script buildPagingQuery

7. Call the API /api/v1/MessageProcessingLogs to get all the message logs in the tenant

8. Use the script buildExecutionMapFromLogsPaged

9. Use the scriptcountExecutionMap

5. Use the script buildExecutionMapFromLogs

10. Use the script detectUnusedIflows

11. Use the script generateJson&CsvReport

12. If the undeploy unused iflows needs to be automated then use a router as below

13. Since we need to provide iflow ids one by one to API, we need to use a General Splitter. General Splitter works well if the format is in xml. Hence, I have used a standard JSON to XML converter

14. In the General Splitter, I have set the XPATH expression as below

15. Set iflow id property as below

16. Call /api/v1/IntegrationRuntimeArtifacts('${property.id}') with DELETE operation

JSON Report:

CSV Report:

How to Use the Results

In Non‑Production Systems:

Clean up abandoned test integration flows
Reduce tenant clutter
Improve troubleshooting efficiency

In Production Systems:

Identify candidates for review
Support governance and lifecycle discussions
Optionally undeploy flows with explicit control

Limitations and Transparency

This solution respects SAP Cloud Integration monitoring retention limits. It does not attempt to infer execution history beyond what the platform provides. For long‑term historical analysis, execution timestamps would need to be stored externally.

Conclusion

By combining deployment information with recent execution evidence, this solution provides a practical and transparent way to manage unused integration flows in SAP Cloud Integration.

It delivers immediate value in non‑production systems and meaningful governance insights in production, all while relying solely on standard CPI capabilities.

I invite you to share your thoughts in the comments below. It helps others who are navigating similar journeys and contributes to a community of shared knowledge. I look forward to hearing from you!

Event-Driven Integration Simplified: Why Salesforce Pub/Sub Adapter Is the Right Choice in SAP CI

2026-04-13T12:55:27.854000+02:00

Introduction

If you are building integrations between Salesforce and SAP using SAP Cloud Integration (SAP CI), the Salesforce Adapter has likely been your trusted workhorse, and it should remain so. It handles CRUD operations beautifully: querying records with SOQL, creating leads, updating opportunities, upserting accounts with External IDs.

But here is the question this blog is really asking: when your integration need is event-driven, are you using the right tool?

Many customers today subscribe to Salesforce Platform Events or Change Data Capture (CDC) events through the Salesforce Adapter's Streaming API capability. It works, but it relies on the CometD protocol, a technology that was designed for a different era of web communication. SAP CI now offers a dedicated Salesforce Pub/Sub Adapter, built on the modern gRPC protocol, that is a significantly better fit for event-based integration.

This blog is not about replacing the Salesforce Adapter. It is about using the right adapter for the right job. For CRUD operations, keep using the Salesforce Adapter. For events, it is time to move to the Pub/Sub Adapter.

The Salesforce Adapter:

The Salesforce Adapter in SAP CI is a full-featured integration adapter that supports:

REST API : Standard CRUD operations on Salesforce objects

REST API Composite : Batch multiple operations in a single call

Bulk API : High-volume data loads

APEX REST : Invoke custom server-side Salesforce logic

Streaming API : Subscribe to real-time event channels

That last capability “Streaming API” is where things get interesting. The Salesforce Adapter does support event-based communication, and many customers are using it today for Platform Events and PushTopics. This is not a broken integration. It works.

However, underneath the Streaming API is the CometD protocol, CometD is an open-source messaging bus that implements the Bayeux protocol (a specification for server-push communication over HTTP). Salesforce's Streaming API is built on top of CometD.

The Pub/Sub Adapter: Built for Events from the Ground Up

SAP CI's Salesforce Pub/Sub Sender Adapter takes a fundamentally different approach. Instead of the Streaming API's CometD layer, it uses Salesforce's Pub/Sub API, which is built on gRPC over HTTP/2.

This is not just a protocol swap, it is a rethinking of how event subscriptions should work in an enterprise integration context.

The difference gRPC protocol brings:

gRPC is a modern, high-performance Remote Procedure Call framework developed by Google. It operates over HTTP/2, which enables:

Persistent bidirectional streams : a single connection stays open and allows messages to flow in both directions simultaneously, without the need for repeated handshakes

Binary serialisation with Protocol Buffers (protobuf) : event payloads are compact and efficient, making gRPC approximately 7–10x faster than REST in payload processing

Multiplexing and Low Latency : multiple streams over a single connection, with no head-of-line blocking and binary message serialization through Protocol Buffers, resulting in lower latency and faster data delivery.

Native flow control : built into the HTTP/2 layer, giving both sides control over how much data is in flight

In practical terms: where CometD is a series of HTTP/1.1 conversations imitating a stream, gRPC is a genuine, persistent, bidirectional channel.

A Side-by-Side Comparison: Streaming API (CometD) vs Pub/Sub API (gRPC)

Capability	Streaming API via Salesforce Adapter	Pub/Sub API via Pub/Sub Adapter
Underlying Protocol	CometD / Bayeux over HTTP/1.1	gRPC over HTTP/2
Connection Type	Long-polling (simulated stream)	Genuine persistent bidirectional stream
Flow Control	None : server pushes at its own pace	Pull-based : client controls event intake
Payload Format	JSON or XML	Binary (Apache Avro / Protobuf)
Performance	Moderate	High ~7–10x faster payload processing
Invalid ReplayID Support	Not available	Available , Latest and Earliest events
Duplicate Handling	Manual implementation needed	Built into the SAP CI adapter
Authentication	OAuth 2.0 and OAuth 2.0 JWT	OAuth 2.0 and OAuth 2.0 JWT
Event Types Supported	Platform Events, PushTopics, CDC	Platform Events, CDC, Event Monitoring

The Right Adapter for the Right Job

Here is how to think about it:

Integration Need	Recommended Adapter
Query Salesforce records (SOQL)	Salesforce Adapter
Create or update Salesforce records	Salesforce Adapter
Upsert with External ID	Salesforce Adapter
Bulk data load	Salesforce Adapter (Bulk API)
Subscribe to Platform Events in real time	Salesforce Pub/Sub Adapter
Subscribe to Change Data Capture events	Salesforce Pub/Sub Adapter
Subscribe to Event Monitoring events	Salesforce Pub/Sub Adapter
Publish events	Salesforce Pub/Sub Adapter

Think of them as complementary adapters operating in different lanes. In a sophisticated Salesforce–SAP integration landscape, you will likely use both the Salesforce Adapter handling your data operations, and the Pub/Sub Adapter handling your event subscriptions.

Migration Considerations

The perception vs. The reality

One of the most common reactions when consultants first propose this migration is concern about scope. The assumption is that moving to a new event protocol means coordinating with the Salesforce team, changing Platform Event definitions and managing a coordinated cutover. It feels like a project that needs multiple teams and a change freeze window.

That concern is understandable, but it is not accurate.

There are zero changes required on the Salesforce side. Your Platform Event definitions stay exactly as they are. The CDC configuration stays exactly as it is. The Pub/Sub Adapter is just a new subscriber, using a different transport underneath.

The Salesforce team does not need to be involved at all. The configuration experience in SAP CI also remains largely familiar. The Salesforce Pub/Sub Adapter shares most of its configuration fields with the standard Salesforce Adapter, with only a few additional parameters introduced specifically for event-driven communication.

In the section below, we will focus only on these new fields, their configuration, and their significance.

Step 1 : Adapter Configuration:

In SAP CI, create a new Integration Flow in your package. Add a Sender participant, connect it to the Start Message event, and select Salesforce Pub/Sub from the adapter dropdown.

Connection Tab:

Parameter Description:

Host

(New field)

Specify the host to which the proxy requests are sent for the gRPC API (towards the gRPC host). The proxy requests to the gRPC host will go through the proxy.

Example: api.pubsub.salesforce.com

Port

(New field)

Specify the port to which the proxy requests are sent for the gRPC API (towards the gRPC port). The proxy requests to the gRPC port will go through the proxy.

Example: 7443

Tenant ID

(New field)

Specify the Salesforce Organization ID, this can be found in Company Information within the "Setup" page on Salesforce

Authentication

Select the authentication type to be used for the connection to Salesforce:

OAuth 2.0 Username-Password

OAuth 2.0 JWT Bearer

Connection Check Interval (in ms)

(New field)

Specify the interval in milliseconds to verify the connection validity of the gRPC.

Processing Tab:

Channel Name :	Enter the channel name
Replay ID Approach :	Replay ID is the unique ID that is generate for every event, The adapter offers 3 approaches here. Events from a Specific Position (Custom): Use this option to listen to events starting from a specific Replay ID. Ideal when you want to resume from a known checkpoint. Once selected, a parameter called Replay ID is enabled where ID can be specified. Events from the Earliest Position (Earliest): This option starts listening from the oldest available event in the event bus at the time of adapter deployment. It captures all events retained in the event bus Events from the Latest Position (Latest): This option starts listening from the latest event at the moment the adapter is deployed. It ignores older events and captures only new incoming ones from that point onward.
Request Batch Size (New field)	Specify the number of events to be requested in the Salesforce fetchRequest. The Maximum events that Salesforce can return in a single call is 100
Replay Preset for Invalid Replay ID (New field)	Select the replay option in case sfdc.platform.eventbus.grpc.subscription.fetch.replayid.corrupted error occurs: Events from latest position (Latest) Events from earliest position (Earliest)
Duplicate Check Expiration (in ms) (New field):	SAP CI operates with two active worker nodes that can simultaneously consume events from Salesforce, which introduces a possibility of duplicate processing. The adapter handles this internally by performing a duplicate check. This parameter defines the expiration time (in milliseconds) for which an event is considered during the duplicate check, helping to prevent redundant processing.
Process Errors as an Event (New field) :	This option is useful for debugging errors occurring on the Salesforce backend. When enabled, errors are streamed as events and can be received in SAP CI, allowing you to monitor and track issues directly within your integration flow. If disabled, connection or processing errors related to event streams will be logged only in Salesforce, without being sent to SAP CI.

Step 2 : Handle the payload format

While both adapters ultimately deliver the same business information (for example, Platform Events or Change Data Capture events), the way this data is structured and delivered differs slightly.

Key Differences

Payload Format:
- Salesforce Adapter delivers payloads directly in XML format
- Pub/Sub Adapter delivers payloads in Avro (binary), which SAP CI internally deserializes into a JSON-like structure
- This requires an additional JSON-to-XML conversion step in the iFlow

Structure & Envelope:
- Salesforce Adapter wraps the payload inside a structured envelope like:
  - <subscribeTopic> → <data> → <payload> → <event>
- Pub/Sub Adapter provides a flatter and cleaner structure, with:
  - <payload> containing all fields
  - Metadata fields like schemaId and id at root level

Field Representation:
- In Pub/Sub payloads, all fields of the entity are typically present, even if empty
- In Streaming API, the payload is often more compact and selective

ChangeEventHeader Node:
- Present in both formats and largely consistent
- Pub/Sub provides additional elements like:
  - nulledFields
  - diffFields
- This gives more flexibility for advanced event processing

Salesforce Adapter (Streaming API) Response:

Salesforce Pub Sub Adapter Response:

Only the following adjustments are needed in SAP CI:

Add a JSON-to-XML Converter
1. Immediately after the Pub/Sub Sender adapter
2. This aligns the payload with your existing XML-based mappings
Minor Mapping Adjustments (if required)
1. Update XPath references if your existing mapping depends on:
  - Envelope structure (/subscribeTopic/data/...)
2. With Pub/Sub, mapping typically starts directly from /root/payload/...
Leverage Additional Metadata (Optional)
1. Fields like nulledFields and diffFields can enhance logic
2. Not mandatory for migration, but useful for optimization

In most cases, existing mappings can be reused with only minor adjustments if required, as the core business data and ChangeEventHeader structure remain consistent across both adapters.

Step 3 : Test in parallel, then switch

This is where the migration story becomes genuinely low-risk. Because the Pub/Sub Adapter is simply an additional subscriber on the same event channel, you can run both your existing Salesforce Adapter iFlow and your new Pub/Sub Adapter iFlow at the same time. Salesforce will deliver the event to both consumers independently.

This means the migration path looks like this:

Deploy the new Pub/Sub iFlow alongside the existing Salesforce Adapter iFlow, both consume the same Platform Event or CDC channel
Test in parallel, validate payload processing, replay behaviour, error handling, and downstream integration in the new iFlow while the old one continues running in production
Switch over when you are confident, decommission the old Streaming API iFlow on your own timeline

There is no big-bang cutover. There is no risk window where your production integration is down. The old iFlow keeps running until you decide to retire it. This is as safe a migration as it gets.

What stays the same, what changes

	Stays the same	Changes
Salesforce side	Platform Events, Apex triggers, CDC config, channel names	Nothing
SAP CI Auth	Same Connected App, same credential alias	Nothing
SAP CI iFlow	Downstream calls, error handling	New sender adapter, Avro → XML conversion step, Mapping (Minor changes)

The Salesforce team does not need a ticket. The project does not need a steering committee. It needs a developer, a new iFlow, and a test run.

Conclusion

The Salesforce Adapter’s Streaming API capability has served its purpose well. But at its core, CometD remains a long-polling workaround from a pre-HTTP/2 era.

The Salesforce Pub/Sub Adapter is the modern foundation for event-driven integration in SAP CI, offering better performance, reliability, and control through persistent connections, flow control, and built-in deduplication.

Use each tool for what it does best:

Salesforce Adapter for CRUD, bulk operations, and queries

Pub/Sub Adapter for real-time, event-driven integration

The tools are already in your hands. Now it’s about using them the right way.

References

SAP Help: Configure Salesforce Pub/Sub Sender Adapter

Real-Time Salesforce Integration with SAP CI: Introducing Salesforce Pub/Sub Adapter

SAP API Business Hub: Salesforce Pub/Sub Adapter Package

Hope this helps!

Cheers,

Punith

End-to-End B2B Integration in SAP CPI: EDIFACT ORDERS (D96B) to IDoc using TPM

2026-04-13T13:33:55.732000+02:00

In modern B2B integrations, handling EDI messages without hardcoding partner-specific logic is key to building scalable solutions. In this blog, I walk through a real-world scenario where an external trading partner sends a purchase order in EDIFACT ORDERS (D96B) format, which I process in SAP Integration Suite using Trading Partner Management (TPM) and transform into an SAP IDoc (ORDERS05) for backend processing.

I cover how I define Message Implementation Guidelines (MIGs), configure trading partners, set up agreements, and use the standard TPM runtime to dynamically identify partners, validate messages, and route them correctly. The focus is on building a robust and reusable integration that ensures traceability and aligns with SAP’s recommended B2B architecture

Scenario:

B2B Integration: EDIFACT ORDERS (D96B) → SAP IDoc using TPM

Direction: External Partner → Internal SAP System
Message Type: EDIFACT ORDERS D96B
Target Format: SAP IDoc (e.g., ORDERS05)

Business Context

An external trading partner sends a purchase order in EDIFACT ORDERS (D96B) format.

Our responsibility:

Identify the correct partner agreement
Validate the message
Transform EDI → IDoc
Route to internal SAP system
Ensure monitoring and traceability

Create a MIG (Message Implementation Guide) for EDIFACT Message

The EDIFACT message in scope in our implementation is ORDERS D96 B. We will create a MIG for this EDIFACT Message.

Go to Integration Suite –> Design –> MIGs. Click on ADD

Select UN/EDIFACT

Search for ORDERS and Select ORDERS

Select D.96B.S3 (Corresponding to our EDIFACT Incoming EDI)

If we do not have the EDI XML, you can skip this step.

Provide the below details

Name: MIG_UN_EDIFACT_ORDERS_D96B
Direction: BOTH
Own Business Context: Select Required Business Process Context
Click on Create
1. If we have your EDI File example, you can also Simulate this and make sure it works.
2. Activate your MIG

Create a MIG for IDoc

As per our requirement, the IDoc in scope is an ORDERS.ORDERS05 IDoc. You can use the Message Implementation Guidelines section to create a MIG for ORDERS.ORDERS05 IDoc

Select SAP S/4Hana on premise IDOC

Skip sample payload (we are not using xml payload in our case)

Create And Activate MIG

TPM CONFUGURATION

Creating Company profile

Create > Company name > Company short name

Create contact details

Create Identifiers for the company

Two Identifiers required

One for ERP – ERPCLNT200

Identification: ERPCLNT200
Alias: ERPCLNT200
Type System: SAP S/4HANA On Premise IDoc
Scheme: N/A

One for EDI Identifier – SELF_1234

Identification: SELF_1234
Alias: SELF_1234
Type System: UN/EDIFACT
Scheme: N/A

Create Systems for Company

These are just display values that you will then see the B2B Monitoring

Name: ERP_ECC
Alias: ERP_ECC
Type: Create New in this case

Name: ECC
Description: ECC
Deployment Type: OnPremise
Application: SAP ERP

Purpose: Dev

Create Type Systems for Company

Create Communication details

Navigate to Systems -> Communications and Click on Create

Name: ERP_ECC_IDOC_RECEIVER
Alias: ERP_ECC_IDOC_RECEIVER
Direction: Receiver
Adapter: IDOC
Address: http://<<erphostname>>/sap/bc/srt/idoc?sap-client=<<clientnumber>>

Ex: http://erpclnt200:80/sap/bc/srt/idoc?sap-client=200

Proxy Type: OnPremise
Authentication: None

Creating Partner Profile Details

Navigate to partner profile> Create > Trading partner

Give the contact details

Create Identifiers (for Trading Partner)

One for ERP – CUSTOMER1

Identification: CUSTOMER1
Alias: CUSTOMER1
Type System: SAP S/4HANA On Premise IDoc
Scheme: N/A

One for EDI Identifier – CUST_1234

Identification: CUST_1234
Alias: CUST_1234
Type System: UN/EDIFACT
Scheme: N/A

Create System (for Trading Partner)

Create Type System (for Trading Partner)

Create a Type System for the Trading Partner with the Below details

Name: UN/EDIFACT
Type: D.96A.S3, D.96B.S3

Create Communication (for Trading partner)

Name: CUST1_COMM_SFTP_PROCESSDIRECT_SENDER
Alias: CUST1_COMM_SFTP_PROCESSDIRECT_SENDER
Direction: Sender
Adapter: Process_Direct

Define Agreement Template

The Agreement Template here is where CUSTOMER1 is the Initiator and ERPCLNT200 is the Reactor

Go to Integration Suite -> Design -> B2B Scenarios -> Agreement Templates

Name: Customer1 Initiates EDIFACT ORDERS D96B
System –> ERP_ECC
Type System –> S/4 HANA On Premise IDoc
Type System Version –> 701
Identifier –> ERPCLNT200

Create a B2B Scenario / Transaction

Name: EDIFACT ORDERS D96B To IDoc ORDERS.ORDERS05
Business Transaction Pattern: One Way Notification

My Company Role: Reactor

When you try to select the Message Implementation Guideline MIG; you will not be able to see your MIG. That is because your MIG was defined for S/4Hana 1709 but our ECC version is 701. Reset the filters and then the search will work.

Define the Communication channel (IDoc) in your Template.

Define Agreement

Create Agreement in your Trading Partner Management as per below details.

Provide all the Information as shown below

In the b2b Scenario

Provide Sender Communication Details in Trading Partner Agreement

Provide Sender Interchange Details in Trading Partner Agreement

Provide Mapping Details in Trading Partner Agreement

As per our scope, we will not use MAG and use a Message Mapping in Cloud Integration. Select option “Customized Mapping Processing” and provide your Process Direct endpoint of your Iflow (/tpm/Customer1/EDIFACT_ORDERSD86B/IDOC_ORDERS_ORDERS05). Note this endpoint as you will use it in the next step.

Provide Receiver Interchange Details in Trading Partner Agreement

Provide Receiver Communication Details in Trading Partner

Save the Configurations

Activate your Trading Partner Agreement (It should be up to date)

Create your Custom Mapping IFlow

we need to have a custom mapping flow running on the Process Direct Endpoint: /tpm/Customer1/EDIFACT_ORDERSD86B/IDOC_ORDERS_ORDERS05

Create an IFlow as below

If we have any mapping logic we can add here in this iflow (for now I’m not adding any mapping)

Create other Iflow as below (used to trigger the whole process)

I’m using Standard Trading Partner Management v2 package so according to that I added headers and address details (end of document you can find more information and how it works)

In this Iflow we will do these configurations

Adding headers According to the groovy script From TPMv2 package

SAP_EDI_Receiver_ID_Qualifier

SAP_EDI_Sender_ID_Qualifier

SAP_EDI_Message_Release

SAP_EDI_Sender_ID

SAP_COM_SND_Adapter_Type

SAP_EDI_Receiver_ID

SAP_EDI_Message_Type

SAP_EDI_Message_Version

SAP_EDI_Document_Standard

EDI Custom Headers

SAP_EDI_Document_Standard

Process Direct Address

From the Standard package (Sender Process Direct Communication Flow V2)

EDI PAYLOAD

UNA:+.? '

UNB+UNOA:1+CUST_1234+SELF_1234+240204:1000+1'

UNH+1+ORDERS:D:96B:UN:S3'

BGM+220+PO-123456+9'

DTM+137:20240204:102'

NAD+BY+CUST_1234::9'

NAD+SU+SELF_1234::9'

UNS+S'

UNT+8+1'

UNZ+1+1'

Configure / Customize Standard IFlows

Navigate to Discover -> Integrations and Copy the Standard Package
Cloud Integration – Trading Partner Management V2 to your tenant

Deploy all the 11 Artifacts

Deploy custom flows along with standard package flows

To check TPM activity, navigate to Monitor > B2B Scenario > Interchange tab. There, you can view all the details, including which agreement was triggered, where the payload originated, where it was sent, and other related information.

From this Package we will use these artifacts

Reusable Groovy Scripts V2
Step 1 – Sender Process Direct Communication Flow V2
Step 1b - Write Message to Message Queue
Step 2 – Interchange Processing Flow V2
Step 3 – Receiver Communication Flow V2

Reusable Groovy Scripts V2 – Modified Headers in custom iflow according to this script

Step 1 – Sender Process Direct Communication Flow V2 à Connecting our custom iflow to this artifact using Process direct Address

Step 1b - Write Message to Message Queue àStoring the payload with the headers from content modifier in JMS

Step 2 – Interchange Processing Flow V2 àMain logic of v2 package(vadidates headers payload with agreement à groovy runsà validates pd lookup runs the logic of v2 standard package)

Step 3 – Receiver Communication Flow V2 à Receives the payload with all the modification like mappings/transformation etc and enters s/4 hana through idoc

Let me explain what happens from the moment the EDI file arrives.

External Partner sends EDIFACT message

The external trading partner Customer1 sends an EDIFACT ORDERS D96B message.

In our test case, the payload looks like this :

UNB Sender → CUST_1234 (Customer)
UNB Receiver → SELF_1234 (Our company)

This direction is very important.

This means:

Customer → Our Company

TPM does not blindly trust custom headers.

Instead, the standard CPI B2B runtime:

Reads the EDI envelope (UNB, UNH)
Determines:

Who is the sender
Who is the receiver
Message type (ORDERS)
Version (D96B)

So, if the UNB sender/receiver is wrong, TPM will:

Override headers
Build the wrong Partner ID
Fail Partner Directory lookup

That’s exactly what happened during debugging.

TPM AGREEMENT

What this agreement means:

Initiator (Sender) → Customer (CUST_1234)
Responder (Receiver) → Our Company (SELF_1234)
Document:

Standard: UN-EDIFACT
Message Type: ORDERS
Version: D
Release: 96B

When this agreement is activated, TPM automatically creates a Partner ID (PID) internally, something like:

SAP_TPM_xxxxxxxxxxxxxxxxxxxxxxxx

This PID is stored in the Partner Directory.

When the message comes in, a standard TPM Groovy script runs (the one that failed at line 585).

This script:

Reads sender/receiver info
Builds a PID lookup string, for example:
Process_Direct-UN-EDIFACT--D.96B-CUST_1234-----SELF_1234-----ORDERS
Hashes this string
Looks it up in Partner Directory

If the string exactly matches what was created during agreement activation → success
If even one value is wrong → lookup fails

PGP Encryption and Decryption in SAP Cloud Integration – A Step-by-Step Guide

2026-04-13T13:37:57.349000+02:00

Introduction

What is PGP?

PGP (Pretty Good Privacy) is an encryption standard used to protect data through a combination of symmetric and asymmetric cryptography. In the context of SAP Cloud Integration (CPI), PGP is used to encrypt and decrypt message payloads to ensure that sensitive data remains secure during transmission between systems.

PGP encryption is a common requirement in enterprise integrations, particularly when exchanging sensitive information such as bank account numbers, salary data, or personal records with external partners.

Why Use PGP in SAP Cloud Integration?

In many integration scenarios, the data exchanged between systems contains sensitive information that must be protected. For example, when integrating SAP SuccessFactors with a banking system to share employee bank account numbers for salary payments, the payload must be encrypted before being sent to the external partner.

PGP encryption ensures that even if the message is intercepted during transit, its content cannot be read without the corresponding decryption key. This makes PGP one of the most widely used encryption methods in SAP Cloud Integration and a best practice for securing message payloads.

How PGP Works: Public and Private Keys

PGP operates on the principle of asymmetric encryption, which involves a pair of cryptographic keys:

Public Key: used to encrypt the message. This key can be shared openly with communication partners.
Private Key: used to decrypt the message. This key must be kept secure and never shared.

These two keys are mathematically linked. A message encrypted with a public key can only be decrypted with the corresponding private key, and vice versa. This is often referred to as a key pair.

Note: Some fields in the screenshots throughout this document have been intentionally hidden using white masking boxes to protect sensitive information.

Key Exchange Principles

Understanding how keys are exchanged between parties is essential for implementing PGP encryption correctly.

Encrypting a Message for a Partner

When we need to send an encrypted message to a partner, the following applies:

We use our public key to encrypt the outgoing message.
We share our private key with the partner so they can decrypt the message.

In this scenario, the private key acts as the decryption credential for the receiving party.

Decrypting a Message from a Partner

When a partner sends us an encrypted message, the following applies:

The partner uses their public key to encrypt the message before sending it.
We need the corresponding private key (provided by the partner) to decrypt the message.

In both cases, the public key encrypts the data, and the private key decrypts it. The key pair must always match.

Generating a PGP Key Pair

Before configuring PGP in SAP Cloud Integration, a key pair (public and private) must be generated. Several tools are available for this purpose.

Using Kleopatra (Desktop Application)

Kleopatra is a widely used open-source certificate manager and GUI for GnuPG. It provides a user-friendly interface for generating, managing, and exporting PGP key pairs.

Using an Online Key Generator

For educational and testing purposes, online tools such as pgpkeygen.com can be used to generate a PGP key pair quickly. The tool generates both a public key file and a secret (private) key file that can be downloaded directly.

Understanding the Generated Files

After generating the key pair, the following files are typically produced:

Public key file (.pub or .asc): used for encryption.
Secret key file (.sec or .asc): used for decryption.

Additionally, a passphrase is defined during the key generation process. This passphrase is required whenever the private key is used for decryption and serves as an additional layer of security.

Note: The passphrase must be saved securely. Without it, the private key cannot be used for decryption.

Uploading PGP Keys to SAP BTP

Once the key pair has been generated, the keys must be uploaded to the SAP BTP Integration Suite so that SAP Cloud Integration can use them for encryption and decryption operations.

Uploading the Public Key

The public key file (.pub) is uploaded to the PGP Keys section in the SAP Integration Suite Monitor. This key will be referenced by the PGP Encryptor step in the integration flow.

Uploading the Private Key

The private (secret) key file is also uploaded to the PGP Keys section. When uploading a secret key, the system prompts for the passphrase that was defined during key generation.

Verifying the Uploaded Keys

After uploading, both keys appear in the PGP Keys list in the Integration Suite Monitor. The public key is identified by its Key User ID, which will be referenced later in the integration flow configuration.

Configuring PGP in SAP Cloud Integration

PGP Encryptor Configuration

The PGP Encryptor is a processing step in the SAP Cloud Integration flow that encrypts the message payload using PGP before it is sent to the receiver.

To configure the PGP Encryptor, the Encryption Key User ID must be specified. This value corresponds to the public key identifier that was uploaded in the PGP Keys section of the Integration Suite Monitor.

The Encryption Key User ID tells the PGP Encryptor which public key to use for encrypting the payload.

PGP Decryptor Configuration

The PGP Decryptor is used to decrypt incoming messages that have been encrypted with PGP. Unlike the PGP Encryptor, the Decryptor does not require a specific key reference in its configuration. It automatically retrieves the appropriate private key from the PGP Keys stored in SAP BTP.

The decryption process uses the passphrase-protected private key that was uploaded earlier. SAP Cloud Integration handles the key retrieval and decryption automatically.

Testing the PGP Encryption and Decryption Flow

To validate the PGP configuration, a test can be performed using a simple text payload in the integration flow.

Before Encryption

The original message payload is a plain text value that is visible and readable.

After Encryption

After the PGP Encryptor step processes the message, the payload is transformed into an encrypted PGP block. The content is no longer readable and can only be decrypted using the corresponding private key.

After Decryption

After the PGP Decryptor step processes the encrypted message, the original plain text payload is restored. This confirms that both the encryption and decryption steps are configured correctly and that the key pair is valid.

Best Practices and Security Considerations

When implementing PGP encryption in SAP Cloud Integration, the following best practices should be observed:

Private keys and passphrases should never be shared in emails, documents, or screenshots. They must be transmitted through secure channels.
Passphrases should be stored securely and never hardcoded in integration flow configurations.
Key pairs should be rotated periodically to maintain a strong security posture.
When exchanging keys with external partners, always verify the key fingerprint to ensure authenticity.
Use the SAP Integration Suite Monitor to manage and audit PGP keys centrally.
For production environments, prefer desktop tools such as Kleopatra over online generators for key pair creation.

Following these practices ensures that PGP encryption is implemented securely, professionally, and in alignment with enterprise integration standards.

Conclusion

PGP encryption provides a robust and widely adopted mechanism for securing message payloads in SAP Cloud Integration. By leveraging asymmetric encryption with public and private key pairs, sensitive data can be transmitted securely between integration partners.

This document covered the complete PGP workflow in SAP Cloud Integration: from understanding the encryption principles and generating a key pair, to uploading keys to SAP BTP, configuring the PGP Encryptor and Decryptor steps, and testing the end-to-end flow.

By adopting PGP encryption and following the recommended security practices, integrations can be implemented in a way that is secure, maintainable, and aligned with enterprise standards.

how to develop an API Provider, API Proxy, Product, and Application in SAP API Management

2026-04-14T12:44:01.945000+02:00

This content is a stepwise instruction on how to develop an API Provider, API Proxy, Product, and Application in SAP API Management. It will provide users with insights on how to safely expose and operate APIs with OAuth and basic authentication schemes. You will get to know how to set up connections, create proxies and make APIs available as products. Also, the blog discusses how to build and maintain apps in the Developer Hub. The guide is aimed at SAP consultants and developers as well as beginners who deal with API Management.

Create API Provider ,API Proxy,Product & Application

Creation of API Provider-:

1. Under Config Section In API’s Navigate to API Provider Sub-Section and Click on Create

2. In Overview tab enter the description

3. In the Connection tab Enter the host details,Port Number & Check on Use SSL

4. In Catalog tab keep the default setting and click onSave.

5. Click on Test Connection IT should ping 200 status code now you have setup your API Provider.

Creation of API Proxy-: 1. Main Proxy (token verification & basic auth)
2. OAuth Proxy (token generation proxy)

We will proceed with OAuth proxy first to create the Bearer token.

1. Navigate to API Proxy sub-tab and click on create as shown below.

2. Select URL fill the details as shown below & click on create to generate the api proxy.

3. After Clicking on Create an api proxy dialog box will open navigate to proxy end points and fill the details as shown & click on save.

4. Click on Policies and navigate to the Policy Editor.

5. You will see two main sections
Proxy Endpoint: Handles client-side logic (e.g., OAuth, API key validation)
Target Endpoint: Handles backend-side logic (e.g., Basic Auth)
We will create policies on proxy end point.

6. Click on PreFlow under ProxyEndpoint, then add the following policies in order in request and response pipeline :

Request-pipeline policies

JS-Policy

1. On the right pane of the window click on edit and under extension policies group click on javascript policies as shown & click on add.

Now Click on the policy and paste the below xml code.

<ResourceURL>jsc://ExtractParam.js</ResourceURL>

</Javascript>

Now we have to create the script for this JS policy
On the left pane of the window in scripts section click on + Icon fill the details as shown.

After Clicking on Add Button Paste this Script.

var gr_type_header = context.getVariable("request.header.grant_type");

var gr_type_queryParam = context.getVariable("request.queryparam.grant_type");

var gr_type;

if(gr_type_queryParam)

{

gr_type = gr_type_queryParam;

}

else if (gr_type_header)

{

gr_type = gr_type_header;

}

else

{

gr_type = "";

}

context.setVariable("request.queryparam.grant_type", gr_type);

TargetEndpoint pre-flow policies

Request-pipeline policies

1. KVM Operations -:follow similar steps to add the policy.

Name -: KVM-GetParams

XML Code -:
<KeyValueMapOperations mapIdentifier="TestBasicAuthCreds" async="true" continueOnError="true" enabled="true" xmlns="http://www.sap.com/apimgmt">

<Key>

<Parameter>clientid</Parameter>

</Key>

</Get>

<Key>

<Parameter>clientsecret</Parameter>

</Key>

</Get>

<Scope>environment</Scope>

</KeyValueMapOperations>

KVM

a.Duplicate the tab & navigate to config section under Apis click on Key Value Maps and hit the create button.

b. Fill the details as shown add the respective key’s encrypt the kvm and save it.

On the right pane of window click on update and navigate to proxy main window and click on save & deploy the proxy as shown.

Product & Application Creation

Publishing the product

1. On left pane of window navigate to engage section in product hit the create icon.

2. In create product dialogue box fill the section as shown and add the respective proxies

Fill the mandatory fields in overview section as shown

b. Navigate to api’s section and add the proxies and hit the publish button.
Now the product is published and proxies are bundled together next we will create application in developer hub.

Developer Hub

Creating application

Prerequisites-: AuthGroup.API.ApplicationDeveloper
role must be assign to user sub-account if not assign it in sub-account under security section.

1. On the top right pane of window click on Explore Our Ecosystem dots and navigate to developer hub as shown.

2. In developer hub click on register button as shown.

3. Fill the details select select country/region as India.

4. Click on admin center navigate to users.

5. Move to Registered user section and assign developer role to your self by clicking on action.

6. Check box the developer and save it.

7. In Developer Hub Navigate to my workspace tab and hit the create button.

3. Follow the steps as shown.

4. After clicking on save button an application window will open which have client credentials copies

the key and secret

The end result of this process is operational API set-up within the SAP API Management with an API Provider set to connect to the backend system.The API is packaged and released as a Product, and thus can be consumed.

SAP Integration Suite Licensing: A Practical Guide for Businesses and Architects

2026-04-16T11:16:02.182000+02:00

Introduction

Within the SAP ecosystem, developers benefit from extensive documentation and technical tutorials. However, business leaders, enterprise architects, procurement teams, and startups often struggle to find clear guidance on licensing, pricing, and commercial models—particularly for SAP Integration Suite.

This blog bridges that gap by offering a practical, business-focused overview of SAP Integration Suite licensing, along with real-world case studies that illustrate how organizations can select the most suitable commercial model.

Why Licensing Information Is Hard to Find

Unlike technical documentation, commercial details are not widely publicized. Key reasons include:

1. Tailored Pricing Models

SAP solutions are customised based on:

Organization size and industry
Integration volumes and complexity
Geographic presence
Compliance requirements
Existing SAP investments

2. Sales-Led Engagement Model

Licensing information is typically provided through:

SAP account executives
Authorized SAP partners
Commercial proposals and Statements of Work

3. Consumption-Based Cloud Economics

SAP Business Technology Platform (BTP) follows a consumption-based model where costs depend on usage metrics such as:

Integration runtime capacity
Messages processed
API calls and events
Compute and memory utilization
Additional capabilities like B2B Integration and API Management

4. Rapid Evolution of SAP Offerings

SAP frequently enhances its cloud offerings, making static pricing references less reliable over time.

Overview of SAP Integration Suite Commercial Models

1. Free Tier

Best For: Developers, students, and innovation teams

Purpose: Learning, experimentation, and prototyping

Benefits:

No cost
Ideal for proofs of concept
Hands-on experience

Limitations:

Restricted resources
Not intended for production use

2. Pay-As-You-Go (PAYG)

Best For: Startups, SMEs, and organizations with unpredictable workloads

Benefits:

No upfront commitment
Pay only for what you consume
Rapid scalability and flexibility

Considerations:

Requires cost governance
Expenses increase with scale

3. Cloud Platform Enterprise Agreement (CPEA)

Best For: Large enterprises adopting multiple SAP BTP services

Benefits:

Prepaid cloud credits
Flexibility across SAP BTP services
Volume-based discounts
Centralized governance

Considerations:

Requires upfront financial commitment
Needs consumption planning

4. Subscription-Based Licensing

Best For: Organizations with stable and predictable workloads

Benefits:

Predictable costs
Simplified budgeting
Guaranteed capacity

Considerations:

Less flexibility compared to consumption models
Potential risk of underutilization

5. RISE with SAP

Best For: Organizations adopting SAP S/4HANA Cloud as part of digital transformation

Benefits:

Bundled services under a single contract
Simplified vendor management
Accelerated cloud adoption

Considerations:

Less granular pricing visibility
Best suited for SAP-centric landscapes

Decision Matrix: Choosing the Right Model

*Business Scenario*	*Recommended Model*
Learning and experimentation	Free Tier
Startups building their first integrations	Pay-As-You-Go
SMEs with growing integration needs	PAYG transitioning to CPEA
Enterprises adopting multiple BTP services	CPEA
Predictable, high-volume workloads	Subscription-Based Licensing
S/4HANA Cloud transformation initiatives	RISE with SAP
System integrators and consulting firms	PAYG for projects; CPEA for internal use

Key Cost Drivers for SAP Integration Suite

Cost Driver	*Business Impact*
Number of integrations	Influences runtime capacity
Message volume	Major contributor to consumption costs
API calls	Impacts API Management usage
B2B/EDI capabilities	Adds specialized costs
Number of environments (Dev, QA, Prod)	Increases consumption
Data transformation complexity	Affects processing requirements
High availability and scalability	Raises infrastructure costs
Security and compliance requirements	May increase operational overhead

Real-World Case Studies

Case Study 1: Startup Integrating SaaS Applications

Industry: HR Technology Startup

Challenge: Integrate a cloud-based HR platform with SAP S/4HANA for clients.

Solution: Pay-As-You-Go model.

Implementation:

Connected Salesforce, SAP S/4HANA, and SuccessFactors.
Leveraged API Management and Cloud Integration.
Scaled gradually based on customer demand.

Outcome:

Zero upfront investment.
Faster time-to-market.
Controlled operational expenses.

Why PAYG Was Ideal:

Unpredictable workloads.
Need for agility and cost efficiency.

Case Study 2: Manufacturing Enterprise Modernizing Legacy Systems

Industry: Global Manufacturing

Challenge: Replace point-to-point integrations across SAP ECC, Ariba, and third-party logistics providers.

Solution: Cloud Platform Enterprise Agreement (CPEA).

Implementation:

Standardized enterprise integrations using SAP Integration Suite.
Enabled EDI and API-based partner connectivity.
Utilized BTP credits across multiple services.

Outcome:

Reduced integration complexity.
Improved supply chain visibility.
Optimized costs through prepaid credits.

Why CPEA Was Ideal:

Large-scale, enterprise-wide adoption.
Need for flexibility across multiple BTP services.

Case Study 3: Retail Chain Managing Seasonal Demand

Industry: Retail and E-Commerce

Challenge: Handle fluctuating integration volumes during festive and seasonal peaks.

Solution: Pay-As-You-Go model.

Implementation:

Integrated SAP Commerce Cloud with logistics and payment gateways.
Scaled integrations during peak sales periods.

Outcome:

Cost optimization during off-peak seasons.
Elastic scalability during high demand.

Why PAYG Was Ideal:

Variable workloads and seasonal spikes.

Case Study 4: Banking Institution Requiring Predictable Costs

Industry: Banking and Financial Services

Challenge: Ensure secure, compliant, and stable integrations across core banking systems.

Solution: Subscription-Based Licensing.

Implementation:

Integrated SAP and non-SAP systems with strict governance.
Ensured regulatory compliance and high availability.

Outcome:

Predictable budgeting and financial planning.
Stable, mission-critical operations.

Why Subscription Was Ideal:

Consistent transaction volumes.
Strong compliance requirements.

Case Study 5: Enterprise Migrating to SAP S/4HANA Cloud

Industry: Professional Services

Challenge: Transform legacy systems while migrating to SAP S/4HANA Cloud.

Solution: RISE with SAP.

Implementation:

Leveraged pre-packaged integrations and clean-core principles.
Enabled seamless connectivity across cloud applications.

Outcome:

Simplified vendor and contract management.
Accelerated digital transformation.

Why RISE with SAP Was Ideal:

Unified approach to ERP modernization and integration.

A Typical Adoption Journey

Most organizations follow this path:

Free Tier → Pay-As-You-Go → CPEA or Subscription → RISE with SAP

This approach enables businesses to:

Validate use cases
Optimize investments
Scale efficiently
Reduce financial risks

Essential Questions to Ask SAP or Partners

Before selecting a commercial model, consider asking:

What metrics determine Integration Suite costs?
Which capabilities are included in the license?
How are non-production environments billed?
Are there volume discounts available?
What governance tools exist for cost monitoring?
Can the commercial model be converted later?
What is the estimated total cost of ownership over three years?
How does pricing scale as the organization grows?

Recommended Resources

Key Takeaways

Pay-As-You-Go is a licensing model—not a license-free option.
CPEA provides flexibility and cost optimization for enterprises.
Subscription models offer predictable costs for stable workloads.
RISE with SAP simplifies ERP-led transformations.
Architects must align technical architecture with commercial strategy.
Understanding licensing early prevents costly redesigns later.

Conclusion

While developers benefit from extensive technical guidance, businesses and architects often lack clarity around licensing and pricing. By understanding SAP Integration Suite’s commercial models, organizations can make informed decisions that align technology investments with business goals.

Selecting the right licensing model ensures scalability, cost efficiency, and long-term success in the cloud integration journey.

Call to Action

Have you implemented SAP Integration Suite using PAYG, CPEA, Subscription, or RISE with SAP? Share your experiences and insights in the comments to help the SAP Community learn and grow together.

Thank you for reading!

Connect in LinkedIn : Naveen Kumar

Disclaimer:
This article reflects personal insights and is intended for educational and informational purposes only. It does not represent the official position of SAP. Pricing, licensing, and commercial models are subject to change and may vary by region and customer agreement. For the most accurate and up-to-date information, please consult SAP directly or an authorized SAP partner. SAP and other SAP products mentioned herein are trademarks or registered trademarks of SAP SE in Germany and other countries.

SAP Developer News for April 16th, 2026

2026-04-16T21:00:00.018000+02:00

ITEMS

UX Innovation Day in Silicon Valley on 11 June

Event page https://events.sap.com/us-ux-innovation-day-siliconvalley-2026/en_us/home.html

SAP BTP ABAP Environment – Pre-Upgrade Option for Release 2605

Blog post https://community.sap.com/t5/technology-blog-posts-by-sap/sap-btp-abap-environment-pre-upgrade-option-for-release-2605/ba-p/14347147

XML Annotations: The Essentials Before Adapting Documentation Samples to Your Project

Mio’s blog post https://community.sap.com/t5/technology-blog-posts-by-members/xml-annotations-the-essentials-before-adapting-documentation-samples-to/ba-p/14369241

OData Deep Dive mission https://developers.sap.com/mission.odata-deep-dive.html

OData Deep Dive rewrite blog post https://qmacro.org/blog/posts/2026/02/02/odata-deep-dive-rewrite-in-the-open/

Edge Integration Cell APIs and Cloud Integration AI-assisted error resolution

Edge Integration Cell APIs: https://help.sap.com/docs/cloud-integration/sap-cloud-integration/local-odata-api-access-for-edge-integration-cell?locale=en-US

AI-assisted error resolution: https://help.sap.com/docs/integration-suite/sap-integration-suite/analyze-message-processing-errors-with-ai-f27f95d7b90b4f13aea22b399418b702?locale=en-US

DYK #12 AI Launchpad Leaderboard

The Model Library topic in the SAP Help Portal https://help.sap.com/docs/ai-launchpad/sap-ai-launchpad/model-library

CHAPTER TITLES

00:00 Intro

00:07 UX Innovation Day in Silicon Valley on 11 June

01:00 SAP BTP ABAP Environment – Pre-Upgrade Option for Release 2605

02:00 XML Annotations: The Essentials Before Adapting Documentation Samples to Your Project

03:16 Edge Integration Cell APIs and Cloud Integration AI-assisted error resolution

04:25 DYK #12 AI Launchpad Leaderboard

TRANSCRIPT

[INTRO]
This is the SAP Developer News for April the 16th, 2026.

[DJ]
If you're in the Silicon Valley area in June and are interested in the intersection between AI and UX, then there's an event just for you. It's on the 11th of June at the SAP AppHaus in Palo Alto, and it's an in-person event only. It's for developers, architects, and technical consultants, and it's all about the AI functionality being built into the SAP Fiori elements framework. There's AI for business users and AI for application developers. The event page has an agenda for the day, which is currently tentative, but it gives us a good idea of the format and content. There's also a link on there for registration. Anyway, check it out. Link in the description.

[Mamikee]
We have an important update for SAP BTP ABAP environment users. We're offering a free pre-upgrade option for release 2605, giving customers and partners the chance to test their existing applications ahead of the standard upgrade, which is planned for May 16th and 17th. Now some of the key milestones have already passed. Planned new features were announced on April April 13th, and pre-upgraded systems are scheduled for upgrade on April 17th, which means teams already participating should now be focused on regression testing and validating their custom-built apps. Now, looking ahead, Hot Fix Collection 2 is planned for April 30th, and any issues found during testing should be reported by May 1st using component BC-CP-ABA. Now, the goal is simple. help make the upgrade a no-event and avoid day one surprises. You can read more in the link below.

[DJ]
Fiori elements based UIs are great, but sometimes it's hard for us to grok how they can be controlled and configured, which is mostly through annotations, which are organized in vocabularies, expressed in metadata, which is usually in the form of XML. So any help is welcome. And in that context, we wanted to point you to a great blog post by SAP community member Mio Yasutake, who takes time to explain these topics in great detail, how things fit together based upon samples and documentation for UI5 and in the context of CAP and RAP-based services. There's lots of detail and it's well worth a read. Thanks Mio! Also if you want more detail to complement this then we have the OData deep dive mission over on the tutorial navigator and in there there are specific tutorials on metadata vocabularies and annotations ready to go as well. Happy learning!

[Antonio]
Hola, SAP Developers! Two quick updates for Edge Integration Cell and Cloud Integration users. First, the local OData APIs for Edge Integration Cell just got better. You can now authenticate using Client ID and Client Secret. More secure, easy to automate. Now, a quick reminder that there are many APIs in Edge Integration Cell that you can use. Monitoring APIs, for example, to track message processing. and management APIs for message stores, data stores, JMS brokers, and variables. These are perfect for building custom dashboards or for automating operations or integrating with your existing monitoring tools. Now, in Cloud Integration, we have AI-assisted error resolution. When your integration flow fails, you can now use AI to analyze the error, get root cause suggestions, and even get remediation steps. So it's like having an integration buddy next to you. which can save time debugging and gets you back on track faster. So check the links in the description for full documentation on both features. ¡Hasta luego!

[Nora]
Did you know that you can compare foundation models right in AI Launchpad? So just jump over to Generative AI Hub in your AI Launchpad and open the model library. And then here you can click on Leaderboard. And now you see all the models that we have available here. and over here you can see the different scores so the HELM score for example tells you how well the model performed in a multiple choice exam across a variety of topics the chatbot arena score tells you how well the model performed in a head-to -head against different AI models and then the AIRBench refusal rate and the AIRBench discrimination bias refusal rate tells you how well the model is handling harmful or biased requests and then all the way over here you have the output and input token cost and the context window size. Now this really helped me to find the right model for my use case depending on cost and context window size and performance overall. I honestly usually don't go to the leaderboard, I head directly to the chart because here you can very easily compare the models.

Q1/2026 Product Highlights - SAP Integration Suite

2026-04-17T10:42:48.013000+02:00

Welcome to another quarterly recap of the latest released features in SAP Integration Suite! The new capabilities in Q1/2026 focus on better operations and smoother eventing for integration practitioners who build, run, and troubleshoot integrations every day. Enjoy the highlights and check the linked docs and demos for how-to details and the road map for the full list.

Enhanced Edition is here

SAP Integration Suite, enhanced edition helps move AI and agentic AI from pilots to production by providing governed, real-time connectivity, low-code developer tools, and AI-driven operations (Text-to-Flow, Script Optimization, API Anomaly Detection, API Traffic Prediction, plus connectors, event mesh, Document AI, alerting, and transport management). It reduces integration debt, enables secure agent actions across cloud and on-prem systems, and creates reusable building blocks for faster, repeatable AI value.

Accelerate your AI initiatives and make them enterprise-ready, get more details in the SAP Discovery Center.

Event-driven Integration

Discovery and publication of advanced event mesh events in the Developer Hub

Content administrators can discover and publish Advanced Event Mesh events directly in the Developer Hub, enabling events to be exposed as event products and making it easier for application developers to search and find relevant events. To use it, you create a destination to connect SAP Integration Suite, advanced event mesh to the Developer Hub; once connected, the business system appears in the Developer Hub for discovery and publication.

For more detailed instructions, check the documentation: Discover and Publish Events from Advanced Event Mesh in Developer Hub.

Migration support from SAP Event Mesh to SAP Integration Suite, advanced event mesh

This update provides technical and process-oriented support to help customers migrate from SAP Event Mesh (default plan) to SAP Integration Suite, advanced event mesh, enabling organizations to move their event-driven architectures to a more powerful, feature-rich platform. The guide targets customers already using the SAP Event Mesh default plan and outlines steps to expand their event-based architecture. Read the guide: Migration From SAP Event Mesh to SAP Integration Suite, Advanced Event Mesh.

Process Integration

Valkey support for Edge Integration Cell

The Edge Integration Cell capability in SAP Integration Suite now supports Valkey as an alternative datastore option alongside Redis and HANA DB. This option is available as selectable installation supporting versions 8.0-8.2 and allows administrators to choose Valkey for deployments helping reduce total cost of ownership.

For the steps and prerequesites, see: Deploy the Edge Integration Cell Solution

Monitor Message Processing on SAP Focused Run and SAP Cloud ALM

Users can monitor message processing from Edge Integration Cell using a push-based approach to send logs to SAP Focused Run (FRUN) and SAP Cloud ALM (CALM). This enables centralized monitoring of multiple Edge Integration Cell runtimes within a single application, lets you configure alerts based on message processing log status, and supports monitoring of Edge Integration Cell message processing logs in SAP Focused Run even during offline scenarios.

See Monitor Message Processing on SAP Focused Run and SAP Cloud ALM for more information.

Message queue management: extension and filtering of scenario details in the message queue monitor

The message queue monitor now displays scenario-specific attributes, such as Sender, Receiver, Application Message Type, Application Message ID, and Correlation ID, which can be enabled in the Messages table settings and used as filter criteria.

This feature lets you narrow messages more efficiently and quickly identify problematic entries with immediate context, reducing mean time to resolution by allowing direct filtering to relevant messages, enabling more precise troubleshooting and root-cause analysis, cutting operational noise by surfacing only the messages that matter, improving auditing and compliance with visible searchable metadata, and simplifying collaboration and handover between operations, support, and development teams. Get started: Managing Messages Stored in Queues

Support for parameterized mappings for the adapter type

The import options from SAP Process Orchestration into SAP Integration Suite - Cloud Integration have been extended to support parameters in message mappings for the adapter category, enabling you to import PI/PO message mappings that include adapter-type parameters; migration tooling and standalone message mapping import now accept mapping objects with the Adapter Type parameter category of type Import, which preserves adapter-specific parameterization, reduces manual adjustments and rework during migration, improves fidelity of migrated mappings, and accelerates onboarding and troubleshooting by maintaining runtime behavior tied to adapter parameters. See documentation: Import a Message Mapping from Enterprise Services Repository (ESR)

Connectivity Updates

Customer-managed cloud connectors

The Edge Integration Cell runtime now supports using a customer-managed external SAP Cloud Connector instead of the built-in, SAP-managed connector, allowing organizations to deploy the connector in a network zone that best fits their infrastructure and security requirements. This feature adds deployment flexibility, improves security controls, enables additional traffic inspection capabilities, and helps meet infrastructure and compliance needs. See configuration steps: Configure an External Cloud Connector for Edge Integration Cell

Additionally, users can now add and initialize an Edge Node with an external Cloud Connector through Edge Lifecycle Management. See how: Initializing an Edge Node with External Cloud Connector

Latest adapters

The list of released adapter in Q1/2026 includes:

BambooHR adapter: Connect to BambooHR to access APIs related to employee, organizational, time off data etc.
Zendesk adapter: Offers a comprehensive set of Ticketing CRUD operations for various entities such as Tickets, Attachments, Requests, Tags, etc. The adapter is designed to receive and process data from an integration flow in SAP Integration Suite and facilitate communication with Zendesk application (external) using REST-based APIs.
Microsoft 365 Outlook adapter: Enables seamless integration between Microsoft Outlook and SAP Integration Suite by improving communication and automating workflows between the two platforms. Available as a Sender and Receiver adapter. 🎥 Watch the demo.
OFTP2 adapter: Use the Odette File Transfer Protocol (OFTP) adapter to exchange EDI and business files with partners on your Edge Integration Cell.
NFS File adapter: Enables connectivity to NFS server facilitating read and write operations for files on your Edge Integration Cell. 🎥 Watch the demo.

Updated data center availability

The new data center availability options for SAP Integration Suite include: Australia (Sydney) on SAP infrastructure, Japan (Tokyo) and USA on an SAP-hosted infrastructure, and the United Kingdom through Microsoft Azure.

---

Learn more

Want a sneak peek into what else is in store for SAP Integration Suite in 2026? Watch this walkthrough:

What are the key innovation you're looking forward to in 2026? Let me know in the comments!

SAP Cloud Integration (CI) for SAP IBP HPA integration: A real-world implementation case study

2026-04-17T20:37:37.846000+02:00

In one of the previous blog post, SAP Cloud Integration was introduced as new integration option for SAP IBP. Subsequent blog posts covered technical topics for creating integration flows based on SAP delivered packages and flows for different integration scenarios. These blog posts in addition to highlighting why organizations should consider SAP CI as part of their IBP integration strategy, covered fundamental set-up and configuration steps for using it for integrating SAP IBP with S/4 Hana Cloud.

In this blog, we explore a real-world example of an organization using Cloud Integration to overcome complex integration challenges for their IBP HPA implementation. We share details of challenges, key architectural decisions, and lessons learned from this complex supply chain planning implementation. This blog highlights a proven integration approach that offers valuable learnings for organizations navigating similar challenges.

Integration challenges: Distributed landscape

The organization in focus like other large manufacturing organizations operates an extensive global supply chain. Their landscape includes:

Multiple ERP system distributed globally
Large product portfolio with complex supply chain spread across locations using different systems

The key challenge was to integrate data from multiple SAP and Non-SAP systems. The integration approach needs to be flexible enough to support multiple source system integration with SAP IBP.

Key decision: Cloud Integration or Real Time Integration

One of the most critical decisions in any IBP implementation is to choose the right integration tool for IBP. From release 2508 onwards, RTI and SAP CI are the two integration tools available to integrate SAP IBP HPA with SAP S4 Hana private cloud.

The sample customer’s implementation team made an early decision to go with a standalone CI integration approach for IBP. Some of the drivers for this decision were:

Cloud Integration works well with all SAP and non-SAP ERP systems, compared to RTI which is restricted only to S/4HANA Private edition
Readily available Cloud Integration expertise within the organization
Operational planning is carried out in ERP system, ruling out need for Order based planning in IBP
Business followed monthly planning cycle, with delta data load planned daily

Additionally, the availability of prepackaged reusable assets for SAP Cloud Integration supports accelerated implementation and reduces time to value significantly. It provides comprehensive connectivity options for diverse landscape, and it being under active development from SAP keeps your integration architecture future ready. Its web-based centralized monitoring and error handling capabilities help in reducing the overall maintenance cost. Because of these inherent advantages of SAP CI, the implementation team decided to go with standalone SAP CI integration architecture.

As real-time data sync capability was not needed, RTI didn’t offer any additional business value in comparison to CI in this scenario. However, depending on your business needs, Operational planning (OBP) in IBP and real time sync capabilities could be essential, in that case CI can be used in conjunction with RTI. As per SAP guidelines, integration architecture can utilize both the integration technologies following way:

RTI used for integrating master data and order data from S/4 Hana Private edition
SAP Cloud Integration (CI) used for all other integration scenarios such as Key Figures or other non-standard objects.

Following SAP help portal page helps you find right integration tool for your business needs: Finding the Right Integration Tool | SAP Help Portal

Integration design philosophy: keep interfaces “Lean” and “Scalable”

An important contributing factor to the successful implementation of CI for SAP IBP was to keep interfaces simple. The customer's implementation team followed a clear guiding principle that Cloud Integration (CI) should be used only for transporting data from one system to another. It should not be used for deriving any business logic. Cloud Integration (CI) is best used for:

Data transportation
Data format transformation and technical validation
Security handling

Business rules, process logic, and calculations were handled in the source or target system. This approach of preprocessing data in source or target system, made sure CI flows are simple, maintainable and reusable.

Preprocessing of data in source system:

To keep the core and IBP Add-on clean on the S/4 Hana, the implementation team decided to use extended CDS views for data preprocessing in S/4 Hana. Cloud integration flows read data directly from CDS views, avoiding modification of extractors and therefore sticking to clean core best practices.

How it works: Multi layered CDS views were created for preprocessing data in S/4 Hana:

Reuse layer CDS views: Built on IBP add-on staging tables and raw tables (for additional data), this layer provided filtered data. As these CDS view also included data from raw tables, any custom data fields not available in IBP add-on staging tables were captured in these CDS views
Consumption layer CDS views: This is primarily used for renaming S/4 fields to IBP fields. Reuse layer CDS views served as input for these CDS views. CI flows read data directly from these CDS views.

Above approach along with Change Data Capture (CDC) capability for CDS extraction allows delta loads for master data and S/4 Hana execution transaction data.

Reusable integration flows in CI:

SAP CI provides prepackaged reusable integration flows, that can be used to integrate all master data and transaction data types with minimal configuration changes. For the sample customer, data integration is executed by running a single prepackaged reusable CI iflow. One reusable integration flow handles all integration scenarios – all master data and key figures, with the help of flexible parameters. These parameters define:

Source CDS view to read in S/4 Hana
Target Master data and Key figures in IBP
Transfer mode: delta or full load

By sticking to preprocessing within the source system using CDS views and integrating using reusable flow, solution is flexible to accommodate future requirements. Any future business requirements can be handled by extending CDS views in the source system, avoiding any changes in the integration layer.

Integration with non-SAP system:

To integrate non-SAP ERP systems, data from multiple ERP systems is first integrated into a Data warehousing system. In Data warehousing system similar CDS view dependent process is used to preprocess data and then a reusable CI flow is used to pull data into IBP. This unified approach means consistent data structure regardless of the source system type.

Back integration to S4 Hana system:

IBP add-on staging tables enable a fire and forget approach for integrating planning output data from IBP to S/4 Hana. CI delivers data to S/4 IBP add-on tables and S/4 process them independently.

With this lean integration approach, figure below shows high level data flow between different systems:

Key takeaways: Some of the key learnings from this successful implementation of CI integration are:

Evaluating business requirements to select the right integration tool for your implementation. Depending on specific scenarios, CI only integration strategy can be effective.
Keep integration lean and focus on data transport only. Push transformation and business logic in source and target systems
Availability of prepackaged integration flow helps in accelerated implementation, and results in scalable and low maintenance integration solution

Cloud Integration with Translation Hub

2026-04-19T12:53:57.332000+02:00

Introduction:

In this blog post, I will demonstrate how to connect Cloud Integration with Translation Hub. As a use case, consider a scenario where a sender system submits an order request. If the order creation fails, the system expects the error message to be returned in both English and Japanese.

Translation Hub:

For an overview of the SAP Translation Hub service and its features, refer to discovery center.

Step 1:

Create an instance for a service named SAP Translation Hub (technical name: document-translation) and generate its corresponding service key.

From the service key, retrieve ‘documenttranslation.url’, ‘uaa.clientid’, ‘uaa.clientsecret’ and ‘uaa.url’, which will be later used in integration scenario.

Step 2:

Explore document translation api at Business Accelerator Hub.

For the model parameter, two values are supported: default and llm. The default model uses SAP-trained Neural Machine Translation (NMT). For a list of supported languages, refer to the SAP Translation Hub documentation: Supported Languages

The llm falls under the generative AI category and can be used when a target language is not supported by the SAP-trained NMT model. For example, to translate text into Bengali.

Cloud Integration:

Step 1:

Create a security material of type ‘OAuth2 Client Credentials’.

Step 2:

Design the iFlow as illustrated below.

The Content Modifier is used to set the message header and body. As only the translated text is required, the ‘Accept’ header is set to ‘application/octet-stream’.

The request body is configured as shown below:

Configure the HTTP receiver adapter to connect with document translation api as shown below.

Step 3:

Test the iFlow endpoint using an API testing tool. In the request payload, ‘orderId’ is a mandatory field as defined in the XML Validator step; therefore, any payload that does not include ‘orderId’ is routed to an exception subprocess.

Please note that all the data are fictitious.

Conclusion:

This blog post demonstrates a prototype for integrating Translation Hub with Cloud Integration.