A new Serialization Requirement

[former_member189558]

Hello,

We have a requirement :

Messages should be serialized in XI .. that is EOIO (Q) processing...

The requirement is such that in case a message fails in XI then it should not stop the next messages .. however the next messaged to be remained in the sequence.....

Is there any way this can be achieved w/o BPM...? Like for instance once a message fails a new que to be used for the next message onwards...

Thanks and Regards,

Himadri

[stefan_grube]

Could you explain the reason for this requirement?

In a production environment a message should never fail.

Regards

Stefan

[bhavesh_kantilal]

Himadri,

><i>The requirement is such that in case a message fails in XI then it should not stop the next messages .. however the next messaged to be remained in the sequence.....</i>

I dont think this is possible.

Even from a BPM , messages are sent out as EO and only at the adapter level can they be made EOIO , and so there is no direct way to do this.

One option would be to use Application Ack's, wait for the Acknowledgement of first message before sending the next message and so on.

Regards

Bhavesh

[former_member189558]

Hi Bhavesh,

Thanks for the reply...

>>Can you explain on how to wait for Application Ack?

I do not think this will do as we are concerned only EAI failures and application side failure is not our lookout...

Thanks,

Himadri

[bhavesh_kantilal]

Himadri,

Even before I explain what I meant by App Ack's this is something that I would not actually implement as it is an overhead from the way I see it.

Application Ack's like it implies is getting the ack from your application that it has been processed. Adapters like JDBC, Idoc ( using ALEAUDIT idoc), etc do support application acknoweldgements but, again is something that will cause serious questions about perfromance and feasibility.

Like pointed by Stefan, in a prod environment it is "assumed" that no errors should occur and if it does occur , manually deleting the error message would be a better thing to do.

You can refer to stefan's blog on the same,

/people/stefan.grube/blog/2006/04/27/how-to-deal-with-stuck-eoio-messages-in-the-xi-30-adapter-framework

Regards

Bhavesh