Multiple message types from JMS adapter

[Former Member]

I am working on an integration scenario between my company's SAP system and an external MQseries queue maintained by an outside business. I have set up XI in the middle to communicate with SAP via RFCs, and to communicate with the external MQseries through JMS.

Here is my problem: according to the SAP documentation on the JMS adapter, the sender communications channel "must have exactly one sender agreement." The problem is, for my scenario I need to be able to receive multiple message types from a single JMS connection and route them to the appropriate service, with each message type differentiated by the doctype of the XML payload.

How can I configure this scenario in XI?

[Former Member]

I found that the message definition on the interface mapping is really sort of meaningless, and that when entering a condition I can ignore the structure list in the condition editor and manually enter a condition. This allows me to determine the receiver based on the message payload, as Nilesh suggested.

Thanks to all!

[Former Member]

Hi Jonathon,

The JMS adapter also supports using a message selector. This means that you can have seperate communcation channels pointing to the same MQSeries queue each waiting for specific values for the message selector (which would be values in the <usr> folder in the RFH2 header).

The downside to this approach is that the application putting the message onto MQ needs to populate the RFH2 Header correctly.

[Former Member]

hi

I have a doubt,if we have same queue for differnt messages.i.e for different outbound message interfaces (MI_OB1,MI_OB2)are placed in same queue.We have differnt receiver determinations for the 2 message interfaces, differnt sender agreement pointing ot 2 JMS sender channels.These 2 channels will have connection parameters.Does this work,is this a optimal solution to handle such scenario.

Thanks in advance

[Former Member]

Jonathan,

I think this is very straightforward scenario.

As far as Sender Agreement is consider, since you have only one sender system, we need only one sender agreement between your sender system and XI.

Now routing them to the appropriate service i.e. receiver is can be done in the Receiver determination. You can put condition in receiver determination base in payload content..in your case base on doctype.

Let me know if you need more details.

Nilesh

[Former Member]

Nilesh,

Do you mean through an enhanced receiver determination and java mapping? I don't see a way of doing this with a standard receiver determination...

[Former Member]

No.

In standard Receiver determination you have an option of putting condition where you can refer to the payload field name in left operand and corresponding conditional value in right operand....

Check out this blog...

/people/prasadbabu.nemalikanti3/blog/2006/09/20/receiver-determination-based-on-the-payload-of-input-dataextended-xpathcontext-object

Nilesh

[Former Member]

XI requires that I select a message interface for a sender agreement. However, the message definition could be very different between message types that are received. The doctype, root element, and dataarea will all be different depending on the type of message.

How can a specify a generic message interface that would allow me to specify a condition based on an element in the message payload on the receiver determination when the message format changes depending on what type of message is sent?

[Former Member]

I think, as mentioned before you need to have common envelope where you can defined a doctype field...which you can use in the receiver determiation.

Nilesh

[Former Member]

Hi Jonathon,

do you have a common envelope in these messages?

best,

wojciech

[Former Member]

They are using OAG's BOD message architecture

[Former Member]

I don't know how it looks like but in case if they have the same envelope you can create generic outbound interface and later split them in interface determination based on some attribute or other condition. Move them to some temporary locations (one per each interface) and in another scenario read them. Maybe that's the bizzare idea ;).

best,

wg