Inbound messaging

Push-based Inbound processing using ASAPIO HTTP endpoint

Note:
Inbound processing is a generic feature of the ASAPIO Integration Add-on framework, and not specific to a connector.
Some connectors support additional or different approaches, e.g. pull mechanisms to implement the inbound scenarios. Please see Connector-specific documentation.

Activate SICF Node

The HTTP endpoint is delivered with the ASAPIO Integration Add-on but has to be activated.

• To use the inbound channel please activate the node in transaction SICF.
• The endpoint can be called with URLs starting with: https://<saphost>:<port>/asadev.

Configure Inbound Object

The path of the endpoint is mapped to the customizing using:

• Cloud instance / Connection name (1)
• Inbound Object name (2)

With this information the Function Module to process the payload is determined (3):

Example: https://<saphost>:<port>/asadev/solace_demo/sdorder_create ➔ processed by Z_ACI_SDORDER_CREATE

Example interface for inbound processing function modules

A custom remote-enabled function module is required, with the following interface, which receives the inbound event payload for further processing:

*"----------------------------------------------------------------------
*"*"Local Interface:
*"  IMPORTING
*"     REFERENCE(IV_INSTANCE) TYPE  /ASADEV/AMR_ARIBA_ARIBA_INST
*"     REFERENCE(IV_OBJECT) TYPE  /ASADEV/AMR_ARIBA_ARIBA_OBJECT
*"     REFERENCE(IV_FILEINTERN) TYPE  FILEINTERN
*"     REFERENCE(IT_CONTENT) TYPE  /ASADEV/AMR_TT_DOWNLOAD
*"     REFERENCE(IT_ATTACHMENT) TYPE  /ASADEV/ACI_TT_ATTACHEMENT
*"       OPTIONAL
*"  EXPORTING
*"     REFERENCE(ET_RETURN) TYPE  /ASADEV/ACI_TT_BAPIRET2
*"----------------------------------------------------------------------

An example function module is available, which you can use as a starting point for your own implementation: /ASADEV/ACI_SAMPLE_IDOC_JSON

Inbound processing

We recommend to store the inbound data first and without any processing logic. That way the HTTP connection can be released quickly, and processing can take place asynchronously in parallel/afterwards.

The ASAPIO-specific generic IDoc type /ASADEV/ACI_GENERIC_IDOC can be used to store the message with payload.

Note

IDocs have the advantage that they can be processed multi-threaded afterwards.

Optional – Assignment of FM to Log. Message and IDoc Type

Note:
Only needed in case of a custom message type

• Transaction: WE57

Optional – Create Inbound process code

• Transaction: WE42

Optional – Maintain function modules (inbound)

• Transaction: BD51

Optional – Maintain function modules (inbound)

• Transaction: BD67

Reprocess failed inbound processing

If no processing information can be determined when the message is received, the payload is automatically staged by the ASAPIO Integration Add-on framework.

ASAPIO provides two features to handle such data:

• view staged inbound payloads with program /ASADEV/ACI_INB_MSG_COCKPIT
• reprocess them with program /ASADEV/ACI_INBOUND_PROCESSING