Docs / Inbound Messaging

Inbound Messaging Overview

ASAPIO supports receiving messages from external systems into SAP. The framework exposes an HTTP endpoint that external systems push to, and routes each payload to a configurable SAP-side processing function module. Three primary processing patterns are supported: staged IDoc processing, synchronous processing, and asynchronous queue-based processing.

Processing Patterns

Pattern	How it works	Best for
IDoc Staging	Payload is persisted as a generic IDoc (`/ASADEV/ACI_GENERIC_IDOC`) and processed via standard IDoc inbound pipeline	Decoupled, retry-safe processing; high-volume inbound; use cases where WE02/WE05 visibility is required
Synchronous	HTTP request is processed inline; the response carries success/error status back to the caller	Request-reply patterns, low-latency acknowledgements, downstream systems that expect a synchronous response
Asynchronous (queued)	Payload is written to an inbound queue and processed by a background job	High-throughput scenarios, isolation from HTTP timeouts, burst absorption

Common Setup Steps

Step 1: Activate SICF Node

Activate the ASAPIO inbound HTTP service in transaction SICF. The base path is:

https://<saphost>:<port>/asadev

Enable Basic Authentication or client-certificate authentication on the SICF node according to your security policy.

Step 2: Configure Inbound Object

The inbound endpoint URL resolves routing via Instance and Inbound Object:

https://<saphost>:<port>/asadev/<Instance>/<Object>

Create an Inbound Object in Event Studio or via /ASADEV/ACI_SETTINGS. Map the object to the processing function module and select the processing mode (IDoc, synchronous, or asynchronous).

Function Module Interface

Custom processing FMs must implement the following interface:

IV_INSTANCE – connection instance name
IV_OBJECT – inbound object identifier
IV_FILEINTERN – internal file/message ID
IT_CONTENT – message body as string table
IT_ATTACHMENT – optional binary attachments
ET_RETURN – BAPIRET2 return messages

Reference implementation: /ASADEV/ACI_SAMPLE_IDOC_JSON.

Inbound via IDoc Staging

The recommended pattern for most inbound use cases. The inbound payload is immediately staged as a generic IDoc without heavy processing at receive time. The IDoc pipeline then handles retries, error display in WE02/WE05, and reprocessing.

Configuration

Set the inbound object's processing FM to /ASADEV/ACI_SAMPLE_IDOC_JSON (or your custom FM built on this template).
In WE57, assign the FM to the message type and IDoc type /ASADEV/ACI_GENERIC_IDOC.
In WE42, create an inbound process code pointing to your business-logic FM.
In BD51, mark your business-logic FM as inbound-capable.
Optionally maintain additional module mappings in BD67.

Flow

External system → ASAPIO HTTP endpoint → IDoc staging FM → /ASADEV/ACI_GENERIC_IDOC IDoc created → standard IDoc inbound pipeline → business-logic FM → SAP application objects.

Error Handling

Failed IDocs appear in WE02/WE05 with status 51. They can be corrected and reprocessed using standard SAP IDoc tools or via the ASAPIO inbound cockpit.

Synchronous Inbound Processing

In synchronous mode the inbound FM is called directly within the HTTP request context. The caller receives a structured response immediately after processing completes.

When to Use

The external system expects a synchronous HTTP 200/error response before proceeding.
Low-latency acknowledgement is required (e.g. inventory check, availability query, approval response).
The business logic is fast and does not risk HTTP timeout.

Configuration

Create an Inbound Object and set the processing mode to Synchronous.
Implement your processing FM; populate ET_RETURN with the result. An initial entry with type S signals success to the HTTP layer; type E or A returns HTTP 500.
The response body is serialized from ET_RETURN as JSON by default.

Considerations

Keep processing time under the HTTP gateway timeout (typically 30–60 s).
For long-running logic, use the asynchronous pattern instead and return an accepted/queued status synchronously.
SAP work-process limits apply; avoid locking resources that could cause contention under load.

Asynchronous (Queued) Inbound Processing

In asynchronous mode the HTTP endpoint writes the received payload to a persistent inbound queue and returns immediately to the caller. A background job processes the queue independently.

When to Use

High message volume where inline processing would exhaust work processes.
Burst scenarios where the external system sends batches faster than SAP can process them.
Isolation from HTTP timeouts when business logic is potentially slow.

Configuration

Set the Inbound Object processing mode to Asynchronous.
Schedule the background processing job /ASADEV/ACI_INBOUND_QUEUE_PROC via SM36 (recommended: every 1–5 minutes, or event-driven).
Monitor the queue depth via /ASADEV/ACI_INB_MSG_COCKPIT.

Error Handling

Messages that fail during queue processing are retained with error status and can be inspected and replayed from the inbound cockpit without re-sending from the source system.

Inbound via Event Studio

Event Studio provides a no-code interface to configure and govern inbound objects. You can:

Create and activate inbound objects without transaction-based SAP GUI steps.
Monitor inbound message volume and error rates per object.
View payload samples for debugging.

For IDoc-based inbound, WE57/WE42/BD51 configuration still needs to be completed in SAP GUI as these are standard SAP IDoc framework transactions outside ASAPIO's scope.

Reprocessing Failed Messages

Messages that arrive without resolvable routing metadata, or that fail during processing, are staged automatically for manual review.

View staged payloads: /ASADEV/ACI_INB_MSG_COCKPIT
Trigger reprocessing: /ASADEV/ACI_INBOUND_PROCESSING
IDoc-staged failures: WE02 / WE05 with status 51, reprocessable via WE19 or mass reprocessing in WE46.