Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
Showing results for 
Search instead for 
Did you mean: 
I am Jithin Mohan, Consultant - SAP Technology at Applexus Technologies, and this blog is co-authored by Lekshmi Nirmala, Principal Consultant - SAP Technology at Applexus Technologies.

SAP Process Orchestration (PO) is a widely used middleware that integrates SAP with various SAP and non-SAP applications. However, SAP has announced its plan to phase out PO by 2027, with extended maintenance until 2030. As a result, many customers have already migrated or are planning to migrate to SAP's Integration Suite, an iPaaS (Platform as a Service) solution. Other than the 2027 deadline, there are several compelling reasons for customers to prioritize migrating to the Integration Suite.

Firstly, this cloud-based integration platform provides a broader range of features compared to the on-premise middleware SAP PO. These features include out-of-the-box integration packages, APIs, events, and third-party connectors, significantly simplifying and expediting the integration process. Additionally, the Integration Suite allows customers to reuse their existing objects from SAP PO, safeguarding their prior investments. By leveraging these existing integrations, organizations can save time and effort during the migration process by avoiding the need to start from scratch. To facilitate a seamless transition, SAP introduced a Migration tool in January 2023. This tool offers customers an easy migration path, with future tool releases expected to address specific exceptions.

Proxy Communication and Migration Challenges

Proxy communication remains the preferred option among various SAP connectivity options in SAP PO. Proxies offer superior performance under high loads, support synchronous and asynchronous communication, and handle attachments, among other benefits. Proxies play a significant role in facilitating the integration of SAP systems with SAP PO. They offer a convenient approach by defining them in the Enterprise Services Repository (ESR) within PO and generating them as ABAP proxies in the SAP backend system. However, during migration projects from PO to Integration Suite, one critical decision involves determining the approach for migrating ABAP proxy interfaces. It is important to note that the Integration Suite does not support proxy generation on the SAP backend system, necessitating a new approach when migrating from SAP PO to SAP Integration Suite.

Migrating SAP PO interfaces using ABAP proxies to Integration Suite presents a straightforward approach with the availability of the XI adapter in Integration Suite. SAP's migration tool greatly simplifies the migration process, reducing efforts significantly. After successful migration, the proxy interfaces will continue to function as they did in SAP PO. However, please note that you will not be able to make any further changes to these objects because the underlying ESR or SAP PO will no longer be available. While the migration of proxy interfaces from SAP PO to Integration Suite has its limitations, it is essential to consider the dynamic nature of IT environments and the need for flexibility. Relying on the assumption that nothing will change in the future may not be the correct approach for proxy interface migration. It is recommended to transition away from ABAP proxies and convert existing ABAP proxies to SOAP web services while ensuring reusability. This approach allows for the decoupling of dependencies on the on-premise integration platform, SAP PO, and leverages the cloud capabilities of SAP Integration Suite.

To address these challenges, SAP provides a feature that facilitates the migration of ABAP proxy objects from the Enterprise Service Repository (ESR) to the metadata repository (MDR) in the SAP backend system. This enables customers to maintain message types and data types on the backend without relying on the ESR. As a result, organizations can reuse existing ESR objects and make local changes in the backend even when the ESR is unavailable.

Migrating ESR Proxy Objects to MDR in Integration Suite

During the migration of ESR proxy objects to MDR, it is crucial to address several challenges to ensure a successful migration and seamless integration with Integration Suite.

Let us explore some common questions and their corresponding solutions:

Here are the steps involved in migrating proxies from SAP PO to Integration Suite:

  1. Namespace Selection: Decide on the namespaces in SAP PO that require migration. You have the flexibility to migrate all namespaces together or select specific ones. Use the transaction code SPXNGENAPPL to add the migration namespace, specifying the Backend Metadata Repository as the source to maintain the objects in the SAP backend system.

  2. Proxy Interface Migration: Open the transaction SPXNMIG, enter the namespace containing the proxy objects, and execute the transaction. This generates a list of objects under the namespace that need migration and highlights any issues requiring attention before migration.

  3. Migrate Objects to MDR: Select the objects to migrate to the Metadata Repository (MDR) and click on the "Migrate" option for the objects highlighted in green. For the remaining objects, address the underlying issues before migrating them to MDR.

  4. Handling Inline Types: One common issue that may arise is with inline types of proxy objects, which cannot be migrated to MDR. To resolve this, change all underlying data types to global types in the Enterprise Services Repository (ESR). This issue occurs when certain fields in data types don't have associated types, as shown below:

To resolve this issue, you can convert the inline data type to a global data type in the Enterprise Service Repository (ESR). Simply create a data type that captures all the fields under the "RecordReceive" category, allowing you to have a centralized and reusable representation of the "RecordReceive" field.

Assign the data type "DT_RecordReceive" as the associated data type for the "RecordReceive" field.

After converting inline types to global types in ESR, regenerate the proxy at the SAP end using the transaction code SPROXY. Save and activate the changes, making the proxy objects ready for migration under the transaction code SPXNMIG. Select all the objects and click on "Migrate" to complete the migration process.

After completing the migration steps, the objects reside in the repository of the SAP backend system instead of the ESR. Once the objects have been migrated to the Master Data Repository (MDR), it is not possible to make any further modifications or changes to these objects through the ESR.

Now, let us explore how to configure the endpoint for the SOAP web service through SOAMANAGER, covering both inbound and outbound scenarios.

Provider (inbound) Proxy:

In the SOAMANAGER transaction, create a web service endpoint by defining the web service binding and authentication methods.

Obtain the service WSDL file from SOAMANAGER, which provides the SOAP endpoint for the corresponding web service. This service endpoint sends data from the Integration Suite to the backend, similar to the proxy call from SAP PO. Open the WSDL document for the selected binding to find the SOAP web service endpoint.

As per SAP recommendations, it is not advisable to expose any service from an on-premise system to the external network. To expose the SAP SOAP web service to Integration Suite, utilize the Cloud Connector. Before using the SOAP endpoint from the WSDL file, replace the hostname and port with the virtual host and port maintained in the Cloud Connector.

While developing the integration flow to call the SOAP endpoint in the backend, use SAP Reliable Messaging (SAP RM) as the message protocol when configuring the SOAP receiver adapter. If the message protocol is SOAP 1. X, ensure that the message ID is populated and passed during the SOAP service call. Failure to do so may result in a runtime error stating "Reliable messaging configured but no message ID and no WSRM assertion provided.

Consumer (outbound) Proxy:

To call the integration flow endpoint in Integration Suite from the backend web service, create a logical port that points to Integration Suite with the target URL as the integration flow endpoint.

Transaction code SRT_UTIL in the backend system allows monitoring of messages exchanged via the SOAP web service. This tool helps troubleshoot any issues with message transfer between Integration Suite and the backend.


Migrating ABAP proxies to web services requires additional effort in both the integration platform and the backend application. However, application integration is a critical aspect of business infrastructure, especially in the context of digital transformation. Converting ABAP proxies to web services provides customers with a future-proof integration platform to support their digital transformation journey. By following the migration steps outlined in this blog and effectively configuring SOAP web services in the Integration Suite, organizations can achieve a smooth transition from SAP PO to Integration Suite, ensuring seamless integration between SAP and other applications.


Labels in this area