cancel
Showing results for 
Search instead for 
Did you mean: 

EOIO Implementation in custom adapter

Former Member
0 Kudos

Hi all,

I'm writing a custom TCP/IP based adapter for the PI.

Everything works, except EOIO processing on the sender channel behaves like EO (without the IO part). For example, if I send 4 Messages and the second is faulty, I expect the following behavior: Process Message 1, Error on Message 2, Wait with Message 3, Wait with Message 4. The current behavior is: Process Message 1, Error on Message 2, Process Message 3, Process Message 4

What do I need to do in order to make the adapter framework delay the processing of messages 3 and 4 until after message 2 has been processed successfully?

I've called the methods

msg.deliverySemantics(DeliverySemantics.ExactlyOnceInOrder)

msg.setConversationId(queueName).

Am I missing anything else?

Is the adapter framework responsible for holding up the messages or do I have to implement it myself?

Best Regards

Sven

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi,

Interesting question.

I assume that in your scenario, your adapter is creating an XI message and then sending it to the Integration Engine using the Adapter Framework APIs and that is where you are setting the delivery semantics to Exactly Once in Order.

In the Integration Engine, the IE needs to recognize a message context and create a queue to process all the 4 messages. So, there needs to be something in the message that says that it is the 1 of 4, 2 of 4, 3 of 4 and 4 of 4 message and there needs to be a context that identifies that all the 4 messages should go into the same queue in the IE and should be processed as EOIO.

I do not remember whether there are APIs available to set this additional context. This is worth checking.

I believe that in your example, PI is still treating them as EOIO (and you can check the message headers to verify that the delivery semantics or QoS is mentioned there). But, PI might be treating each of them as separate messages and processing them "correctly".

Regards,

Venki

Former Member
0 Kudos

Hi Venki,

thanks for your thoughts.

I always thought that setting the conversationID would be sufficient for the IE to treat the messages in EOIO. I also assumed that the AE or IE would manage the hashtable with the message ids (containing date and time and so giving the correct sequence of the messages).

Am I wrong, do i have to do anything else in the coding of the custom adapter?

Best Regards

Sven

Former Member
0 Kudos

Hi,

That is my understanding as well.

Just to make sure, are you setting the same conversation id for all the four messages that you are sending?

Regards,

Venki

Former Member
0 Kudos

Hi,

we're setting the ConversationID through a property in the communication channel and all messages are sent through this channel, so the conversation Id is always the same.

Regards

Sven

Former Member
0 Kudos

Hi,

I'm programming the custom adapter together with Sven, and I too think that for EOIO to work it should be enough to accept a message from the sender and then:

Message msg = XIMessageFactory.createMessageRecord(...);
msg.setDocument(...);
msg.setDeliverySemantics(DeliverySemantics.ExactlyOnceInOrder);
msg.setConversationId("some constant");

ModuleData md = new ModuleData();
md.setPrincipalData(msg);

txMgr.begin();
mp.process(channelId, md);
txMgr.commit();

I do not see a way to set a sequence id for the PI message, but I assume that the messages get queued up in the order in which they get processed. If we now send four messages and the second one has an error, then messages 1, 3 and 4 get processed immediately and message 2 gets retried every 5 minutes. If we look at the details of these messages, all are tagged with the delivery semantic EOIO and all are tagged with the queue name "some constant".

So they were processed by the AF as EOIO messages through the same queue, but the error in message 2 did not cause messages 3 and 4 to be held...

Does anyone have any suggestions?

Thank you very much in advance,

Bojidar

Former Member
0 Kudos

Hi once again,

I've figured out that our adapter is working properly and that to get EOIO processing you really only need to set the delivery semantics to EOIO and set the same conversation ID (aka queue name) for all messages.

For our tests of the EOIO feature we sent four messages, the second one being wrong on purpose. We expected that the AF would process message 1, show message 2 as erroneous and hold messages 3 and 4. What happened is that in the message monitor we saw all four messages: 1 processed, 2 with an error, and 3 and 4 as processed.

The reason that this behavoir is correct lies in the fact that when the adapter recognizes that a message is not well-formed, it throws a ResourceException and does not attempt to deliver it to the AF. So when messages 3 and 4 pass through the adapter and get delivered to the AF, the AF has no knowledge of message 2 and naturally processes messages 3 and 4 normally.

So, right behavior from the PI and our adapter is now ready.

Cheers,

Bojidar

Answers (0)