QoS EO proccessing doubt

[rodrigoalejandro_pertierr]

HI

Quality of Service EO

For quality of service EO, a four-digit number is generated to complete the queue name using a random algorithm to determine the suffix of the sender, receiver, and inbound queues. This enables you to process multiple messages simultaneously in different queues.

Generated random number: 38

Queue name: XBTI0038

You can determine the area valid for the random algorithm using the configuration parameterEO_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 determined receiver. To avoid them being blocked, messages are bundled according to receiver and placed in outbound queues assigned to the respective receivers. The corresponding queue is determined using a four-digit encryption (a hash value) of the receiver name.

Receiver name: CLIENT_XYZ

Encrypted name: E8B9

Queue name: XBTOE8B9

If more than one message is sent to the same receiver, use the configuration parameterEO_OUTBOUND_PARALLEL of the category Tuning to process messages simultaneously in different queues. A random algorithm is also used here to generate a four-digit number to complete the queue name. You must enter the receiver in the column Subparameter and the area valid for the random algorithm in the column Value for this purpose.

A = SAP Backend

lets assume i define the parameter EO_OUTBOUND_PARALLEL/A = 50. this does means that the sistem will generate an EO queue per interface defined in PI. I mean, 10 customer documents are sent to SAP, the system could enqueue this documents randomly, right? so multiples Outbound queue could be used for one interface, no matter if a use one channel per interface or multiples channels.

Regards

Rodrigo

[former_member184720 · Accepted solution]

Hi Rodrigo -

AFAIK - Your assumption is correct but configuration of any higher value may have impact on adapter engine/target system due to overflow as they might not be capable of handling such load.

Also you might not notice any impact if there are not enough work processes.

>>> no matter if a use one channel per interface or multiples channels

I think i'm missing something here. what do you mean by multiple channels per interface?

[rodrigoalejandro_pertierr · Accepted solution]

Harees, thanks for your answer.

I was thinking the same as you about this.

related to define one channel per interface, i think i should not affect the enqueued of messages since its just a connection between PI and the backend. the main key here is the QoS.

but i not fully sure about this because i heard sometimes that the system has an "internal logic" that all message of a particular scenario are enqueued in the same queue, no matter if the QoS is EO or EOIO.

but the problem is not how the message is enqueued in PI, but when the message is enqueued in the backend.

let assume i could define a queue for one interface in PI EO_OUTBOUND_PARALLEL/A = 50 but the backend only support 10, the messages that were sorted in PI will be enqueued de-sorted in backend because the difference of number of processing queues.

Am i Rigth??

standard documentation about this??

Thaks a lot.

Rgds

Rodrigo

[former_member184720 · Accepted solution]

>>>but i not fully sure about this because i heard sometimes that the system has an "internal logic" that all message of a particular scenario are enqueued in the same queue, no matter if the QoS is EO or EOIO.

I don't think this is true. In case EOIO no other messages will get processed if the first message is not successful as all the messages reside in same queue.

>>>let assume i could define a queue for one interface in PI EO_OUTBOUND_PARALLEL/A = 50 but the backend only support 10, the messages that were sorted in PI will be enqueued de-sorted in backend because the difference of number of processing queues.

In a way Yes. If the receiving system doesn't have as many work processes(inbound queues) as the sender then they'll just be waiting in PI. Call adapter step may consume more time though mapping and outbound binding steps would be executed quickly.