Quality of Service 

The sender of a message uses the attribute Quality of Service (QoS) to determine how a message is delivered. The following delivery types are supported:

·        BE (Best Effort):

The message is sent synchronously; this means that the sender system waits for a response before it continues processing.

·        EO (Exactly Once):

The message is sent asynchronously in this case; this means that the sender system does not wait for a response before continuing processing. The Integration Engine guarantees that the message is sent and processed exactly once.

·        EOIO (Exactly Once In Order):

In addition to Exactly Once, messages with the same queue names (supplied by the application) are assigned in the same sequence that they were sent from the sender system.  Message processing is asynchronous in this case.

In the case of delivery type BE, if more than one receiver is determined for a message, an error occurs. In the case of delivery types EO and EOIO, the message is copied correspondingly and sent to the individual receivers.

Synchronous Message Processing (BE)

Messages are not persisted by the Integration Engine in synchronous message processing. Once a message has been processed in the target system it performs an implicit database commit.

Asynchronous Message Processing (EO, EOIO)

In asynchronous message processing, messages are persisted by the Integration Engine at a predefined time and scheduled for processing using the queued RFC (qRFC).

The qRFC requires the technical names of the different Integration Engine queues for this. These are different depending on the role of the Integration Engine:

The qRFC requires the technical names of the inbound and outbound Integration Engine queues for this. These names are different depending on the role of the Integration Engine:

·        Central Integration Server.

In this case the Integration Engine has an inbound and outbound queue.

·        Local Integration Engine without integration logic.

In this case the Integration Engine has a sender and receiver queue.

In addition to these queues, two further queues are required for the processing of acknowledgment messages.

So that all XML messages (including acknowledgment messages) can be processed automatically, you must register queues that are used by the Integration Engine with transaction SMQR. Choose Administration ® Register/Deregister Queues from the Integration Engine menu.

Adhere to the following conventions for prefixes when naming these queues.

Queue Name (maximum 24 characters)

	Sender	Inbound	Outbound	Receiver	Acknowledgment
EO	XBTSx	XBTIx	XBTOx	XBTRx	XBTBx
EOIO	XBQSx	XBQIx	XBQOx	XBQRx	XBQBx

The suffix “x” in the queue name is determined differently depending on the type of delivery; the suffix for the sender, receiver and inbound queues is determined in the same way.

Delivery Type EO

For delivery type EO, a four-digit number is generated with a random algorithm to determine the suffix of the sender, receiver and inbound queues (in other words the queues in which an inbound message is placed for inbound processing) to complete the queue name. This enables you to process multiple messages simultaneously in different queues.

Example:

Random number: 38

Queue name: XBTI0038

You can determine the area valid for the random algorithm using the configuration parameter EO_INBOUND_PARALLEL from the category Tuning. Using the subparameters SENDER, CENTRAL and RECEIVER you can define separate areas for the sender queue, inbound queue, and receiver queue.

On the central Integration Server, messages are persisted again after inbound processing and scheduled for sending to the receiver determined in technical routing. To avoid them being blocked, messages are bundled according to receiver and then placed in outbound queues assigned to the respective receivers. The corresponding queue is determined using a four-figure encryption (a hash value) of the receiver name.

Example:

Receiver name: CLIENT_XYZ

Encrypted name: E8B9

Queue name: XBTOE8B9

If more than one message is sent to the same receiver, use the configuration parameter EO_OUTBOUND_PARALLEL to set the category Tuning so that you can process messages simultaneously in different queues. A random algorithm is also used here to generate a four-figure number to complete the queue name. You must also enter the receiver in the column Subparameter and the area valid for the random algorithm in the column Value.

Example:

Receiver name: CLIENT_XYZ

Encrypted name: E8B9

Random number: 17

Queue name: XBTOE8B90017

If all messages are to be processed in parallel outbound queues, using the configuration parameter specify the area for the random algorithm only, without entering a special receiver.

The message is persisted again once it has been sent successfully. Once the message has been processed successfully in the target system, the Integration Engine executes an implicit database commit. If an error occurs during message processing, the Integration Engine executes an implicit database rollback.

Delivery Type EOIO

In contrast to delivery type EO, with delivery type EOIO the queue name supplied by the application is used to determine the suffix of the sender, receiver and inbound queues.  This name must not be more than 16 characters long and it is added to the prefix of the queue name. You can use the following characters in the name: numbers (0-9); uppercase letters (A-Z); underscores (_); and forward slashes (/).

Example:

Queue name from the application: APPQUEUENAME (maximum 16 characters)

Inbound queue name: XBQIAPPQUEUENAME

The name of the corresponding outbound queue is then determined from the central Integration Server to bundle the messages according to receiver. In the same way as for delivery type EO, this takes place using the name of the receiver taken from technical routing. In this case the name of the application queue is transferred as well.

Example:

Receiver name: CLIENT_XYZ

Encrypted name: E8B9

Outbound queue name: XBQOE8B9APPQUEUENAME (maximum 24 characters)

Delivery type EOIO guarantees that inbound messages with the same receiver are processed in the same sequence that they entered the Integration Engine. The messages are also sent in this sequence to their respective receivers; because they have the same queue name that was supplied by the application, they are placed in the same outbound queue.

If the receiver is not the same, then this sequence can no longer be guaranteed.

The message is persisted again once it has been sent successfully. Once the message has been processed successfully in the target system, the Integration Engine executes an implicit database commit. Otherwise, it executes an implicit database rollback.