Integration Engine and Queue Configuration on ABAP systems for AEX scenarios
All ABAP systems (release >= 6.20) contain a “local” Integration Engine. This integration engine enables the system (when used as an application system) to connect to another system via SAP PI or AEX. This connectivity is connectivity based on the proxy runtime. All other systems – either SAP or third-party – connect to the SAP NetWeaver PI using adapters. The local Integration Engine controls the messaging process (receiving, processing, and forwarding) to and from AEX.
This blog gives an overview how the local integration engine needs to be configured and what the most important options are.
The following pre-requisites are required to use a local Integration Engine of an ABAP backend system:
- The business systems and the AEX are maintained in the System Landscape Directory (SLD).
- The ABAP backend is connected to the AEX (please refer to my Proxy Setup Guide blog)
- Activation of an HTTP Service on the Receiver System (transaction SICF)
- Configuration of the role of the Business System (see below steps)
- Registration of ABAP backend queues (see below steps)
- Setup of all SLD connections (please refer to to my SLD Setup Guide blog)
Integration Engine / Business System configuration:
1. Start transaction SXMB_ADMIN -> Integration Engine Configuration
2. Enter the role of the business system as “Application System” as shown below and enter the http-destination
created earlier for connecting the ABAP system to the PI/AEX (out of transaction SM59) with prefix dest://
3. Goto Edit -> Change Configuration
4. In the following table, different runtime configuration parameters can be added, i.e. to increase the trace level, etc.
The most important and recommende settings are the following:
| Parameter | Description | Possible Values | Recommended Value |
|---|---|---|---|
| ENGINE_TYPE | This parameter determines the Integration Engine type of the current client. | UNDEFINED – Client not configured as Integration Engine. HUB – Client configured as Integration Server. LOC – Client configured as sender/receiver system |
LOC |
| IS_URL |
This parameter defines the URL or HTTP destination for the Integration Server or Advanced Adapter Engine. This parameter is evaluated in the HTTP communication path Sender -> Integration Server/Advanced Adapter Engine. |
Either enter a URL in the format http://<host>:<port>/sap/xi/engine?type=central or an HTTP destination in the format dest://<destination name>. |
dest://<RFC destination name> |
| HTTP_TIMEOUT | Timeout default for HTTP connections (time between two data packages passing along a cable). This value overrides the system profile parameter icm/server_port_n (for example, icm/server_port_0 : PROT=HTTP, PORT=50044, TIMEOUT=900). If the parameter HTTP_TIMEOUT is not set or if you enter the value 0, then the setting for the system profile parameter is applied. | n seconds | 0 |
All other recommended runtime parameters are more optional ones which are usually used for development
or test systems to increase tracing and logging. These are the following:
| Parameter | Description | Possible Values | Recommended Value |
|---|---|---|---|
| LOGGING |
With the parameter LOGGING the logging of asynchronous messages for all pipelines of an Integration Engine can be activated. |
0 – deactivated 1 – activated |
1 |
| LOGGING_SYNC |
With the parameter LOGGING_SYNC the logging of synchronous messages for all pipelines of an Integration Engine can be activated (which improves error analysis and tracing) |
0 – deactivated 1 – activated |
1 (for test systems) 0 (for production systems) |
| TRACE_LEVEL |
The parameter is set to analyze the message processing so that individual and/or all steps of a pipeline are documented. IMPORTANT: A high trace level (2 and especially 3) is only recommended for development and test systems for detailed error analysis. Since tracing requires a lot of system performance, this should only be activated temporarily on a Production environment to discover any issues, afterwards tracing should be set back to a default level 1. |
0 – Trace deactivated |
2 or 3 for development systems 0 or 1 for production systems |
5. Make a check afterwards:
6. The status should be green at the end of the check:
Registration of ABAP backend queues:
For the different types of message processing, different types of RFC queues need to be configured on the ABAP backend system. The following table gives an overview about the possible types of message processing:
|
Message Processing |
Type of Processing |
Description |
|
BE (Best Effort) |
Synchronous |
Sender waits for an answer before processing is continued. |
|
EO (Exactly Once) |
Asynchronous |
Message is only sent and processed once. Sender doesn’t wait for an answer. |
|
EOIO (Exactly Once In Order) |
Asynchronous |
Messages are delivered with the same queue names (supplied by the application) in the same sequence that they were sent from the sender system. Sender doesn’t wait for an answer. |
The message processing type (BE, EO, EOIO) also defines the name of the backend queues. These queue names can be found in the SAP Help.
The technical queue identifiers depend on the role of the Integration Engine, either the queues are identified as outbound/inbound queues or sender/receiver queues:
|
Role of Integration Engine |
Technical Queue Names |
|
Central Integration Server |
Integration Engine has inbound and outbound queues |
|
Local Integration Server |
Integration Engine has sender and receiver queues |
Furthermore there are also queues required to process acknowledgement messages as well as queues for processing very large messages.
For a standard scenario together with AEX, the Business System is configured as “Local Integration Server” (see steps above for “Integration Engine Configuration”) and since the Integration Engine integration is based on the proxy runtime (XI 3.0 protocol) message processing type is EO or EOIO (XI 3.0 is EO or EOIO which is all asynchronous, see table above).
The XI 3.0 asynchronous queues need therefore be activated on the ABAP backend system as follows:
- Go to transaction SXMB_ADMIN -> Manage Queues: Depending on the role of the Integration Engine (here: a local Integration Engine), the relevant queues are proposed.
- Choose “Register Queues”
Really nice and full document.
Congrats Harald 😀