on 01-09-2020 7:14 AM
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
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)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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?
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
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.
User | Count |
---|---|
84 | |
25 | |
12 | |
9 | |
6 | |
6 | |
5 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.