cancel
Showing results for 
Search instead for 
Did you mean: 

Multiple Messages in Same JMS queue

Former Member
0 Kudos

Hello,

I have interfaces in which different xml messages from the same sender system will be placed in the same MQ queue, is there a way that XI JMS sender channel can differentiate the xml messages based on the payload?

I can create a single communication channel, but the outbound message interface I cannot create a common structure because the xml messages are huge and there will be future interfaces following the same architecture.

1. How can I route in interface determination based on the context in the inbound msg interface?

2. What can I provide as Message interface for the outbound?

3. MessageSelector attribute in Adapter specific properties - any ideas on this? - I can select this in the condition context in interface determination - can I give any values here to differentiate msges?

4. Value mapping - is it possible to define the sender message interface through this?

Any idea is appreciated..THank you..

Accepted Solutions (0)

Answers (3)

Answers (3)

Former Member
0 Kudos

Hi Thanujja,

We have recently completed a project that had this requirement too. We made use of the MessageSelector to solve this problem. You'll need to make use of some advanced (advanced tab)settings in the comm channel. Basically you want to add Additional JMS Message Properties. You can add up to 10 additonal JMS Properties.

Let's say you've added a property called MESTYP. You then need to get the sender to populate the MESTYP property with a text value for each IDoc involved e.g. DELVRY. You would then set your JMS Message Selector field as follows: MESTYP='DELVRY'.

You'll have a comm channel for each IDoc. These comm channels will then connect to the JMS Queue & only pick up messages that meet the criteria at set in the Message Selector.

There was one other problem that encountered with Message Selector, we were on XI version 7.0, the Message Selector was working intermittently & then we applied SAP Note 1256636 & upgraded to 7.01. Everything is working fine after that.

Trevor

Former Member
0 Kudos

Hi Thanuja,

u can try like this way...

for 'n' different messages u create n message mapping.

use reduced XSD of the IDOC XML,

create only 1 sender comm chanel and thus 1 sender agreement,

as u said u have to differentiate the messages with X-path only,

if ur rcving system same for all messages, to differentiate them u can use party....

for example for DELIVERY03 idocs create a party for ORDERS03 create another party....

so it should not be a problem... !!!

Former Member
0 Kudos

Hi,

Even i have a similar issu ewith my interface.I have same sender queue for different message types MT1,MT2,MT3.If i create a message interface(MI_OB) with some message type(say MT1),will my sender agreement be able to pick the data of any message type.

Eg:If the queue has MT3 and the sender communication channels picks tht data ,will i be able to do the content based routing in interface determinations and create diffrent message interfaces and interface mapping.

I have 1 sender queue,3 message types.How will my design configuration be ?

Can you give me some more details how this issue is tacked.

Thanks in advance

Former Member
0 Kudos

Hi:

When you create the SA,you can set value '*' in field "interface" and "namespace".Then the 3 types of MT which are in the same JMS queue will be picked up by one SA.

You create one receiver determination for each MT ,Then the messages with different MT will goto the relevant receiver determination.

regards

yu ming

Former Member
0 Kudos

Hi Thanujja

Whats the difference in payload for both XML. If you know this then you can set the conditional receiver determination to send it to two different targets.

even enhanced interface determination can help.

If you are not able to separate in mapping based on payload is it possible to set XI message ID or JMS message ID for you to differentiate them in mapping.

Thanks

Gaurav

Former Member
0 Kudos

There are two issues in my case..

The XML messages are the IDOC XML messages.Like DELVRY03, ORDER03 etc..These will be put in the queues..The sender system is not SAP system.

Lets say I configure one communication channel and one sender agreement. What is the Message interface I use for the sender agreement? If I use Delvry idoc as MI, then How will I pick up order03 msges? I tried giving conditions for IDOCTYP and MESTYPE to check in the interface determination - but I have to reference to the source interface either delvry or order - so during runtime, If I give orders as MI, the delvry one will fail as the root is not order...

I see there are context objects out of the box for IDOCTYPE, MESTYP - i gave that and it throws error saying XI context not found...

MessageID? How will this help to know the type of message?

Former Member
0 Kudos

Hi Thanujja

For reading two different IDOC type from single queue i think you need to separate them in mapping. But do you have a common meta data for this ? I dont think so.

Then you need to get them separately using different MI and SA.

MessageID - I was thinking that you can set MessageID from MQ so that when it reach JMS sender it load into a different queue .

I think you need to develop custom module to send them to separate queues.

example adapter module for JMS

Thanks

Gaurav

Former Member
0 Kudos

Another problem with 2 diff SA is the channels fight over to pull the messages..So I cant do that too..It got to be one MI, one SA..I am testing a workaround now..and its working..but I am not sure if this is right and will cause any problems later..

I am giving delvry in one SA and have only one channel configured...In Interface determination I have conditions to look for MSG type and IDOc type..The trick here is I have given the Xpath expression hence if Orders idoc comes in it satisfies the condition too..like

ORDERS05/IDOC/IDOCTYP = ORDERS05 - so the MI could still be Delvry - but the msg that the channel picked up is orders so this condition is satisfied and the message is routed...This is a solution as of now..but not sure if this will break..