cancel
Showing results for 
Search instead for 
Did you mean: 

SAP PI EOIO forcing FIFO

0 Kudos

Hello All,

I hope you can help me. In other posts I could not directly find the answer to this question.

We have a situation where we send Hl7 from our ECC by an proxy to mutliple receivers. We have done the proxy serialization and on PI-side we have EOIO order and used the option maintain order at runtime.

We saw that messages go to PI in the correct sequence and with the correct sequence number, but that an later received message is processed earlier then an earlier received one. We saw in the message log also this tekst:

Sequencer triggered by another cluster node; status will be updated to TBDL and message will be put in queue

We read in the Tuning the PI/PO Messaging System Queues blog that:

The queues in the Messaging System behave different then the qRFC queues in ABAP. The ABAP queues are strictly First In First Out (FIFO) queues and are only processed by one Dialog work process at a time. The Messaging System queues have a configurable amount of so called consumer threads that process messages from the queue. The default number of consumer threads is 5 per adapter (JDBC, File, JMS, …), per direction (inbound and outbound) and Quality of Service (asynchronous (EO, EOIO) and synchronous). Hence in case a message is taking very long other messages that arrived later can finish processing earlier. Therefore Messaging System queues are not strictly FIFO.

Our question is, if it is possible to avoid this, and force FIFO in some way?

We are on an 7.5 SP 14 system.I hope you can help me.

Regards,

Paul

Accepted Solutions (0)

Answers (2)

Answers (2)

former_member608139
Active Participant
0 Kudos

All the messages probably were processed in FIFO mode, but, when you have more nodes to process all the messages you need JMS Adapter as can you see in the SAP KBa 2408581 ( EOIO cluster lock for JMS communication channel)

0 Kudos

Thanx Carlos,

The node you gave is specific for the JMS Adapter. In this case we are not using this adapter.

former_member608139
Active Participant
0 Kudos

But in your case, when you are using more then 1 server node, JMS is obligatory to keep the messages exactly once in order

0 Kudos

Thanx again Carlos, I have taken a look at the JMS adapter, and don't get how does would exactly be cofigurred.

could you give me an outlook on how this would work? Because I need me receiver adapter to eventually send the message?

So how would the flow of messaging look? Would I route the message back with an JMS receiver and sender to my originally receiver adapter. And if so would'nt it then be the same problem?

former_member190293
Active Contributor
0 Kudos

Hi Paul!

This looks strange. EOIO Quality of Service must ensure that messages are processed in the same order it were received. Do you have just the only interface for each receiving system? What is the aim of setting "Maintain Order at Runtime" option?

Also, do you see incorrect sequence order for the same receiver system?

Regards, Evgeniy.

0 Kudos

Hi Evgeniy,

We have multiple receivers with all the same interface. We also see that the same problem occurs for the same messages for all the receivers.

As example:

Message with Sequenc ID: 290

Start Time 1/8/2020 2:04:51.583 PM

End Time:1/8/2020 02:04:55.977 PM

Message with Sequence ID: 291

Start Time 1/8/2020 02:04:53.277 PM

End Time: 1/8/2020 02:04:55.870 PM

The setting maintain order at runtime is because we thought that by using the serialization in the proxy the order which XI receives it will automaticaly be the correct order for processing.

former_member190293
Active Contributor
0 Kudos

Hi Paul!

"Maintain Order at Runtime" option makes sense when multiple interfaces for the same receiver system are used. In this case dedicated queue with EOIO QoS is created for each split sequence.

Sender EOIO sequence order is maintained for each receiver separately. So, in case of splitting the same message to multiple receivers Receiver2 can process the message before Receiver1. Or in your case the sequence order for the one receiver is incorrect?

Regards, Evgeniy.

0 Kudos

Yes for each individual receiver, we see that within an individual receiver the sequence order is incorrect