Introduction

Have you ever wanted to test one inbound ABAP Proxy interface, but before sending one single message you first had to prepare a PI, PO, or SAP Cloud Integration flow?

I have run into this many times.

Sometimes I only want to answer a simple question: can this SAP system receive this XI message, and does the payload match the expected interface? But the setup ends up bigger than the test itself. You may need a sender flow, a receiver channel, routing, credentials, certificates, sample payloads, and sometimes help from another team.

For daily development, SAP AIF testing, and incident analysis, this is slow.

So I built a small local tool: an XI (ABAP Proxy) Sender Simulator.

It sends SAP XI 3.0 multipart messages directly to the ABAP XI Engine endpoint. 

The goal is not to replace middleware. The goal is to make local testing and troubleshooting faster.

Where the tool sits

In a normal landscape, a client system reaches the ABAP inbound proxy through CPI / PI / PO. The simulator skips that whole sender flow and talks straight to the XI engine on the receiver:

This is not a replacement for the real middleware path. It is a focused shortcut for the cases where you only need to test the receiver side.

Why I built it

This idea is not new for me. I wanted to build this kind of tool many years ago.

The pain was already clear. I often needed a quick way to send one XI message to one SAP system, especially when working on SAP AIF and ABAP Proxy interfaces. I knew a small sender simulator would save time.

But I never had enough time to build it properly.

AI coding assistants change that. AI does not replace SAP integration knowledge. I still need to understand XI 3.0, ABAP Proxy, AIF, payload namespaces, QoS, authentication, and how to test all of it. But AI helps a lot with implementation, refactoring, tests, UI work, and documentation.

It lets me finish ideas I had for years but could not complete before because of limited time and energy. This tool is one of them.

What the tool does

The tool gives you a local web UI for sending XI 3.0 messages.

The basic flow is simple:

1. Enter the SAP XI Engine URL and user.
2. Enter sender and receiver routing information.
3. Paste or choose a WSDL.
4. Parse the WSDL.
5. Generate a sample payload.
6. Edit the payload.
7. Send the XI message.
8. Check the SAP response and local history.

Visually, one round-trip looks like this:

The tool builds the XI 3.0 request for you:

• XI SOAP envelope
• message ID
• sender and receiver party / component
• interface namespace and name
• QoS mode
• multipart/related HTTP body
• payload cid: reference

Then it sends the request to an endpoint like:

/sap/xi/engine?type=receiver&sap-client=

How it works

An XI 3.0 HTTP request is a multipart/related message.

It contains two main parts:

• Part 1: the XI SOAP envelope, with protocol and routing metadata.
• Part 2: the business payload XML.

The SOAP envelope references the payload by cid:.  Visually:

The tool reads the WSDL and pulls out the information it needs:

• service interface name
• interface namespace
• request payload element
• payload namespace
• synchronous or asynchronous mode

For asynchronous interfaces the tool uses ExactlyOnce. For synchronous interfaces it uses BestEffort. The tool decides this from the WSDL operation: if the operation has an output message, it treats it as synchronous.

This WSDL parsing is important. In real SAP projects, the service interface namespace and the payload message type namespace are not always the same. Mixing them up leads to errors like INTERFACE_REGISTRATION_ERROR or INTERFACE_SIGNATURE_ERROR.

If you want to dig into the wire format itself (every field in the SOAP envelope, what type=receiver does, how to read  codes), I keep my own working notes here: docs/xi-protocol.md. Those are not official SAP documentation, just what I have learned from debugging.

When it is useful

This tool is useful when you want to:

• test an inbound ABAP Proxy interface quickly
• reproduce an SAP AIF inbound issue
• check whether the interface namespace and name are correct
• check whether the payload root element and namespace are correct
• generate a first sample payload from a WSDL
• separate transport / protocol errors from application errors
• do a quick regression test without rebuilding a full middleware flow

The main value is a shorter feedback loop.

Try it

GitHub https://github.com/LF-LLL/xi-abap-proxy-sender-simulator

Safety and scope

This tool is not an official SAP tool.

It is not delivered, supported, or endorsed by SAP.

It is not designed for production message processing.

It should not be used as a production integration component, retry tool, or monitoring tool.

It is a local development and testing helper. The target users are developers, integration consultants, and operations / support colleagues who need to validate or reproduce integration messages more efficiently.

The tool can send authenticated HTTP requests to SAP systems, so it has some safety boundaries:

• It listens on saptix.com by default.
• It refuses non-localhost binding unless the user explicitly opts in.
• It uses a per-start token to reduce accidental local or cross-site calls.
• It only accepts send URLs whose path looks like a SAP endpoint, such as /sap/... or /XISOAPAdapter/....
• It does not return password defaults from the local config file back to the browser.
• It does not store passwords in history.
• It redacts sensitive response headers.
• It truncates large payloads and responses before storing them in local history.

Even with all of that, please treat it as a lab tool. Run it only on your own machine, or in a controlled test environment.