New SAP Training: WIFMS4 – Inbound Interface Management in SAP S/4HANA

We have developed a standard SAP Training about managing inbound interfaces (ABAP Proxies) in SAP S/4HANA and SAP Business Suite (ERP, CRM, …): WIFMS4.


You learn how to implement a robust error handling using already available (and free) SAP standard technology:

  • Forward Error Handling (FEH) and
  • Error and Conflict Handler (ECH)

without the need of implementing a heavy solution, such as SAP AIF.

SAP Blog/Announcement on WIFMS4

SAP Online Training Catalog (with dates)

ABAP Inbound Proxy: Inside-Out vs. Outside-In

Implementing ABAP proxies is quite simple. You generate the ABAP classes via SPROXY (which connects to your ESR) and implement the code.

Regarding the Service Interface Design and Implementation you have a choice:

  • Outside-In: You define the Data Types and Message Types in the ESR and generate into ABAP
  • Inside-Out: You choose what you need in ABAP, import into ESR and use the ABAP perspective. Then you generate into ABAP.

Each approach has pros and cons. Here you see what makes the approaches so different and what fits your requirement best.

Development Process







  • Clear choice if you are using Global Data Types (GDTs) and do not want to deal with the SAP-internal field names in the ESR or towards the Non-SAP applications


  • Complex data structures (e.g. BAPIs) & no need to have an abstraction view in ESR
  • No usage of GDTs



ABAP Outbound Proxy: Set EOIO Queue

In order to use EOIO (Exactly-Once-In-Order), you have to pass the Queue ID to the class before calling the Outbound Proxy in your ABAP Program. It can be a static value like shown below (parameter) or a dynamic object like a document number:


PARAMETERS: p_queue TYPE sxmsqidapp.

DATA: l_proxy TYPE REF TO z…,
async_messaging TYPE REF TO if_wsprotocol_async_messaging.


async_messaging ?= l_proxy->get_protocol( if_wsprotocol=>async_messaging ).
async_messaging->set_serialization_context( p_queue ).

WHINT Proxy FileTransfer


Whenever possible, please try to avoid file-based integration (flat or not, going through the file system is not a good integration pattern), see blog post: Avoid using flat files!. However, sometimes it is still the best fit when the connected system does not provide a clean (RESTful or WebService-based) API….


This solution makes FTP/SFTP(SSH) communication with your SAP Backend system obsolete. Your ABAP programs can still use file-based integration (Import/Export), but the communication with PI/PO is done with HTTP(S). This is especially useful, when you do not want ANY system to connect to the file system of your SAP landscape or you want to make sure only the SAP system itself is accessing the (local/remote) file system, no other system or user.

The integration is done through the ABAP Proxy runtime, which supports multipart messages. The XML data of each ABAP proxy contains the meta data (file name, directory, job/program name) and the data file itself is transferred as an attachment.


  • Import the TPZ file provided by Whitepaper InterfaceDesign into your ESR
  • Import the ABAP transport containing the objects into your SAP Backend system via Transaction SAINT


From SAP

  • Proxy: ManagedFileTransfer_Out []
  • Define an iFlow/Integrated Configuration (ICO) to connect your SAP Backend with a receiver system
    • To map the data from the attachment into the main payload and set the DynamicConfiguration values (ASMA) for FileName and Directory, you can run Operation Mapping FileMessageFromProxy
    • Alternatively you can use your own mapping of course
  • Run: Execute ABAP Program /WHINT/MFT_SEND
    • Enter the file name and source directory
    • Optional: Decide if the file shall be deleted after processing
    • Optional: Enter a scenario id to make routing in the IntegrationDirectory easier. The value will be part of the meta data (XML) as well as a context object (PFTScenarioID)


  • Proxy: ManagedFileTransfer_In []
  • Define an iFlow/Integrated Configuration (ICO) to connect your sender system with your SAP Backend
    • To map the main payload into the attachment and (optionally) read the DynamicConfiguration values (ASMA), you can run Operation Mapping FileMessageToProxy.
      • To set the FileName and Directory from DynamicConfiguration, set mapping parameter to “ASMA”, otherwise enter the value in the Configuration (iFlow/ICO)
      • If you want to execute a program or schedule a job (with variant), you can also specify those with the mapping parameters. To leave the parameters empty, set the parameter value to “IGNORE”.
    • Alternatively you can use your own mapping of course
  • Run: Send the data from your source system

ABAP Inbound Proxy: Extended XML handling

If you can not differentiate between existing XML tags or empty contents or if you use the CDT (Data Type/GDT based on the Core Data Type) Indicator (with values true/false), you might find this useful:

  • Each generated ABAP Proxy structure comes with a CONTROLLER section (internal table).
  • For each field, there is an entry providing information
  • The possible values are:
    • sai_ctrl_initial  => field exists in message with initial value
    • sai_ctrl_nil  => the value xsi:nil is sent
    • sai_ctrl_none => field does not occur in message

See also: SAP Help


ABAP Outbound Proxy: Request Acknowledgements

To request System- or Application-Acknowledgements, you have to request them before calling the Outbound Proxy in your ABAP Program:

DATA: l_proxy TYPE REF TO z…,
acknowledgment_request_details TYPE PRX_ACK_REQUEST_DETAILS,
async_messaging TYPE REF TO if_wsprotocol_async_messaging.


async_messaging ?= l_proxy->get_protocol( if_wsprotocol=>async_messaging ).

acknowledgment_request_details-application_ok = abap_true.
acknowledgment_request_details-application_error = abap_true.

acknowledgment_request_details-system_ok = abap_true.
acknowledgment_request_details-system_error = abap_true.

async_messaging->set_acknowledgment_requested( details = acknowledgment_request_details ).

SAP service provisioning alternatives / direct vs. mediated

This article takes a look at what options exist to expose consumable services from an SAP (ABAP) Backend system.

Services can be exposed like this:

  • RFC (RFC-enabled function modules / BAPIs are using the SAP-propietary protocol which must be known on consumer-side)
  • SOAP (Web-Services based on WSDL and SOAP/http(s) internet standards)
  • REST (Representational State Transfer protocol is a lean http-based protocol and currently state-of-the-art especially when consuming from mobile devices. Big advantages, esp. performance, are achieved when using the JSON format and not the XML-based ATOM format)

The architectural question is wheather the service is consumed directly (point-to-point) or mediated. Mediated means using a middleware between the consumer and the provider. The SAP middleware we look at is mainly

  • SAP NetWeaver Process Integration (PI) / SAP NetWeaver Process Orchestration (PO) or
  • SAP NetWeaver Gateway

Reasons for using a middleware (purely from a runtime perspective, not considering interface modeling):

  • Mapping (conversions/transformation necessary)
  • Protocol-Switch (consumer is using a different protocol than service provider)
  • Routing (dynamic routing is needed, e.g. to select between different systems or services)
  • Stateful Message Processing (allow integration patterns like e.g. async-sync communication or to correlate messages based in their contents)
  • General Rule to NOT allow direct SAP backend connectivity (e.g. for security reasons)

The main reason to implement direct communication is runtime performance (minimizing the infrastructure components at runtime to achieve fast response times and avoid points of failure).