Introduction

This blog presents a complete walkthrough for migrating both outbound and inbound ABAP proxy configurations from SAP PO to SAP Integration Suite (Cloud Integration – CI). It is based on real project experience and focuses on the most direct and efficient path, leveraging SAP’s latest enhancements in ABAP proxy support within Integration Suite.

If you have explored other approaches involving MDR (Metadata Repository), SPXNMIG, or full redesign strategies, this method offers a clear alternative. When the objective is to transition existing proxy scenarios from PO to Integration Suite with minimal disruption, the approach outlined here is both streamlined and practical.

Why this approach — and how it differs from other approaches

There is already substantial guidance available on ABAP proxies, covering areas such as greenfield implementations, MDR-based migrations, OAuth configurations, and pipeline-based architectures in CI. Each of these serves specific use cases effectively.

This blog takes a focused, migration-centric perspective. It outlines a straightforward, end-to-end approach to moving existing proxy scenarios from SAP PO to Integration Suite using SAP’s current ABAP proxy generation capabilities. Both outbound and inbound configurations are addressed together, without introducing MDR or requiring a full pipeline setup. The emphasis is on simplicity, clarity, and direct applicability in migration projects.

Quick Comparison: What Changes, What Stays the Same

 This table shows exactly what changes and what the equivalent looks like after migration:

Before You Begin — Prerequisites

Ensure the following are in place before starting:

• Service Interface(s) already imported inside a Cloud Integration Design package (this is what SAP_PROXY_ESR will read from)
• SAP Cloud Connector (SCC) configured and connected to your BTP subaccount
• The user for the RFC destination must have the PI_Integration_Developer role collection assigned. For OAuth setup, a Process Integration Runtime service instance (plan: API) with AuthGroup_IntegrationDeveloper role is needed in BTP Cockpit.
• S/4HANA or ECC system with sufficient basis access to configure SM59, SXMB_ADM, SMICM, SICF, and SPROXY

Part 1: Outbound Proxy Migration

Recalling how Outbound Proxy Worked in SAP PO

In SAP PO, outbound proxy communication is handled through two RFC destinations. Understanding both is important, as they map directly to their CI equivalents—only the targets change.

The first RFC destination, typically named SAP_PROXY_ESR, pointed to SAP PO’s Enterprise Repository (ESR). Transaction SPROXY used this to browse available Service Interfaces and generate Proxy classes in the ABAP system.

Figure 1: SAP_PROXY_ESR RFC destination pointing to SAP PO’s Enterprise Repository (SM59)

The second RFC destination will be configured in SXMB_ADM and handled the actual runtime message routing – every outbound proxy call from ECC/S4 was sent to SAP PO through this destination.

Figure 2: Mapping RFC destination for outbound message routing to SAP PO (SXMB_ADM – Config)

Figure 3: HTTP_PO1 RFC destination — routing messages from S4 to SAP PO (SM59)

Setting Up Outbound Proxy in SAP Integration Suite

What the new setup looks like

The concept is identical in CI — same two RFC destinations, same SXMB_ADM configuration. What changes is only where they point. Let’s go through each one.

Figure 4: The outbound Service Interface in SAP PO ESR — this is what we are migrating to CI

Use SAP’s migration tooling (or a third-party alternative) to migrate the Integration Configuration Object (ICO) from PO to CI. After migration, configure the XI Sender adapter address in the iFlow—this becomes the target endpoint for the RFC destination in S/4.

Step 1 – RFC Destination for Runtime Message Routing

Create an RFC destination of type G (HTTP connection) in SM59. This destination routes outbound proxy messages from S/4 to the XI Sender endpoint in CI. The path prefix must exactly match the address configured in the XI Sender adapter of the iFlow.

Figure 5: RFC destination for routing outbound messages from S4 to CI (SM59)

Figure 6: The iFlow in CI showing the XI Sender adapter address — this must match the RFC path prefix

Step 2 – RFC Destination for Proxy Generation (SAP_PROXY_ESR) — The Key Change

With recent SAP updates, ABAP proxy generation can now be performed directly by connecting the backend system (ECC or S/4) to the SAP Integration Suite tenant.

Once configured, SPROXY reads Service Interfaces directly from CI design packages, enabled via the SAP_PROXY_ESR connection—eliminating the need for MDR or redesign.

Configure the RFC destination in SM59 with:

• Connection Type: G (HTTP connection)
• Target Host: Host from the Process Integration Runtime service key (plan type: API) — not the CI tenant host directly
• Path Prefix: /rest/api/v1/workspace/sproxy
• SSL: Active (Port 443)

Figure 7: SAP_PROXY_ESR RFC destination now pointing to SAP Integration Suite (SM59)

Step 3 – Authentication for SAP_PROXY_ESR

Before setting up the RFC destination, make sure your user has the PI_Integration_Developer role collection assigned in BTP>users. we have two ways to authenticate and for this blog we’re using Basic Auth to keep it simple.

Basic Auth — straightforward, just put the S-User credentials in the Logon & Security tab in SM59. This is what we used in our project.

OAuth — you’ll need to first go into BTP Cockpit, create a Process Integration Runtime service instance with plan API, and pick AuthGroup_IntegrationDeveloper during setup. That generates a service key which has everything you need — clientid, clientsecret and token URL. Detailed steps are covered in blog (referred at the end of this blog) on this topic, so I won’t repeat it here.

Figure 8: Logon & Security tab — Basic Auth configured with PI_Integration_Developer role (SM59)

Figure 9: RFC destination connection settings — SSL active, port 443 (SM59)

Run the connection test. A response of HTTP 200 confirms the RFC destination is working correctly. Once this is in place, SPROXY will reflect the Service Interfaces available in CI packages.

Figure 10: Service Interface from CI is now visible and ready for proxy generation (SPROXY)

Step 4 – Configuring Sender/Receiver IDs and IS_URL in SXMB_ADM

In SXMB_ADM, create the Sender and Receiver IDs that identify the participating systems. These IDs are then referenced in the IS_URL entry, which maps each outbound proxy to its target RFC destination.

Figure 11: SXMB_ADM — Creating Sender/Receiver IDs for the outbound proxy

Configure the IS_URL entry pointing to the RFC destination that routes to CI (e.g., XIMessage_toCI). The Sender/Receiver ID created above is entered as the sub-parameter.

Figure 12: Configure Destination (SXMB_ADM)

Figure 13: IS_URL entry pointing to the CI RFC destination

Once this is configured, trigger a test message from your ABAP program or test tool and confirm it flows correctly through to CI.

Part 2: Inbound Proxy Migration

Inbound proxy scenarios operate in reverse—CI sends messages to the ABAP system, where the inbound proxy processes them. Since the ABAP system is on-premise, secure exposure is handled via SAP Cloud Connector.

Step 1 — Retrieve the ABAP System Hostname (SMICM)

In SMICM → Goto → Services, note the HTTPS hostname and port. This internal host will be mapped in Cloud Connector.

Figure 14: SMICM — Collecting the ABAP system hostname and port for Cloud Connector mapping

Step 2 — Configure Virtual Host Mapping in SAP Cloud Connector

In the Cloud Connector administration portal:

• Define a Virtual Host (e.g., s4host.internal)
• Map it to the internal host from SMICM
• Use HTTPS protocol
• Set system type as ABAP System

Add resource access:

• / (full access), or
• /sap/xi/engine (restricted access)

Then add the resource. For this blog’s scenario, access to all paths is granted (resource: /), but for tighter security you can restrict it to /sap/xi/engine specifically.

Figure 15: SAP Cloud Connector — virtual host mapped to the ABAP system

Step 3 — Activate /sap/xi/engine in SICF

In transaction SICF, navigate to the path /sap/xi/engine and check whether the service is active. If it shows as inactive, right-click and activate it.

Figure 16: SICF — /sap/xi/engine confirmed active

Step 4 — Construct the Receiver XI Adapter URL in CI

The endpoint URL to be used in the CI Receiver XI Adapter should follows this pattern:

https://<VirtualHost>:<Port>/sap/xi/engine?type=receiver&sap-client=<CLIENT>

Use the virtual host name defined in Cloud Connector (not the internal hostname). This is the URL CI will call to deliver the message to the ABAP system.

Step 5 — Migrate the ICO and Update the Inbound iFlow

Figure 17: The inbound Service Interface in SAP PO ESR — this is what we are migrating to CI

Migrate the ICO from PO to CI using your preferred approach. After migration, open the iFlow and update the Receiver XI Adapter with the URL constructed above. The On-Premise connectivity should be set with the Cloud Connector Location ID.

Figure 18: Migrated iFlow — Receiver XI Adapter updated with the ABAP system URL via Cloud Connector

The Inbound Service Interface also needs to be added to the iFlow separately. It is not pulled in automatically as part of ICO migration.

Figure 19: Inbound Service Interface added separately to the iFlow after migration

Configure the delivery assurance and Quality of Service in the XI adapter based on your scenario requirements.

Step 6 — Activate the Service Interface in SPROXY

Open SPROXY in S/4HANA. The inbound Service Interface will now be visible via SAP_PROXY_ESR. Activate it to generate the corresponding ABAP proxy class.

Figure 20: SPROXY — Inbound Service Interface visible from CI, activated for proxy generation

Once activated, test the end-to-end flow: send a test message from CI and verify it is received and processed by the ABAP inbound proxy. Check SXMB_MONI in the ABAP system for message status.

Troubleshooting Guide

Below are the most common issues encountered during proxy migration, along with their root causes and fixes. This is based on real project experience and commonly reported issues in the community

Summary

Migrating ABAP proxy scenarios from SAP PO to SAP Integration Suite does not have to be complicated. Here is the core of what this blog covers:

• The SAP_PROXY_ESR RFC destination is the linchpin of this approach. By pointing it to Integration Suite instead of the ESR, SPROXY automatically reads Service Interfaces from CI packages — no MDR, no SPXNMIG, no inline type conversion needed.
• For Outbound Proxy: update two RFC destinations (SAP_PROXY_ESR and the message routing destination in SXMB_ADM) to point to CI instead of PO. The rest of the SXMB_ADM Sender/Receiver ID and IS_URL config works the same way.
• For Inbound Proxy: expose the ABAP system’s /sap/xi/engine endpoint via Cloud Connector, configure the Receiver XI Adapter in your CI iFlow, and activate the Service Interface in SPROXY.
• Watch out for: wrong client in SICF (multi-client systems), the target host for RFC: SAP_PROXY_ESR is from the Process Integration Runtime service key and not the CI tenant URL directly, and Service Interface not appearing in SPROXY (package not imported into CI).

Thanks for reading. Questions or corrections — drop them in the comments, I’ll do my best to help.

  Read More Technology Blog Posts by Members articles 

#abap