Multiple IDoc Message Listener

[Former Member]

I am using XMII Version 12.1.8 Build(46) and I have the following problem.

I need to send information from LOIPRO to XMII to be handled by different transactions.

First, I have configured XMIIIDOC01 and it was working well. After I configured the XMIIIDOC02.

Both have the same partners configured, which means LOIPRO is configureds in both listeners in SAP). I followed the article "How to Send an IDoc from SAP ECC to SAP MII IDoc Listener (MII 12.1 to ECC6.0)" - Updated on 8 Aug. 2011 - to configure XMIIIDOC01 and XMIIIDOC02.

When the second listener was configured I created a second Processing Rule for LOIPRO. What I have for rules are:

Server Name XMIIIDOC01:

- Rule LOIPLO; Message Name: LOIPLO

- Rule LOIPRO; Message Name: LOIPRO

- Rule LOIBOM; Message Name: LOIBOM

Server Name XMIIIDOC02:

- Rule LOIPRO; Message Name: LOIPRO

After XMIIIDOC02 was created all messages were sent to XMIIIDOC02, whatever we do in POIT. The message monitor shows ALL messages as from server XMIIIDOC02, whatever if it is LOIPRO, LOIPLO or LOIBOM.

What I did not understand is when I saved the incoming XML and open it, the EDI_DC40_SEGMENT shows the correct server.

We need to separete the LOIPRO records in different systems and this strange behavour is avoiding us to do this.

Is there any reason for this? How could I acheave the correct result?

Regards

Italo Stefani

Vetta Group

[Former Member]

We followed the Michael suggestion to parse the incoming message and redirect it to the right transaction.

[former_member193328]

Hi Italo

I know the thread is answered and your problem is solved but still wanted to point out a few things to you.

1. As your sender system is the same ERP you should not create multiple (Read XMIIIDOC*) connections as this eats up connection to the ERP System and is wrong from performance point of view.

2. Also this is not required for your routing rules.

Your scenario as I understand it is that the same ERP System is sending several IDOCs (LOIPLO, LOIPRO ...) and you want different processing rules to process them.

Mike Appelby's solution already works but you need to create a separate transaction that does the routing. I have a different approach and you can think which is better for you.

Here is what I do to solve this.

Create separate Processing Rules in MII with the following entries

Message Name : Complete Name of the IDOC (LOIPLO, LOIPRO etc) so that the message is uniquely identified.

Server Name: XMIIIDOC01

Message Type: IDoc

Transaction Path: Select the transaction to process the selected IDoc

Continue this process till you have processing rules for all the IDocs that you receive.

This should solve your problem without creating various connections to ERP and eating up connection params. Also there are only 10 IDoc Adapters. Use them judiciously else they will run out if you have more than 10 IDoc Types.

Please let me know if this helps you.

Regards

Partha

[Former Member]

Hi Partha.Thank you for your attention.

Actually this is the scenario I have. I have created Processing Rule for each IDoc I want.

So, I have separeted rules for LOIPRO, LOIPLO, LOIBOM, LOISTD, LOIWCS and LOIROU with the Server name XMIIIDOC02.

My problem is: I need to send LOIPRO records to differents transactions, and what records will be sent to what transaction is manually defined, there is no information in the data that indicate the receiver transaction.

So, we had the approach to send using XMIIIDOC01 for one transaction em XMIIIDOC02 for the other transaction. As workaround, we are still using this approach and configuring all rules to get the message from XMIIIDOC02 (where all msgs go). But the XML keeps the information of the intented listener (XMIIIDOC01 or XMIIIDOC02). Then, we can route the message to the correct transaction.

I know this not a good solution, but we will find a better one later when we have enough time.

Regards.

Italo Stefani

Vetta Group

[agentry_src]

Hi Italo,

You are not the first to run across this. The underlying NW based MII structures changed quite a bit when MII moved from NW 2004s to NWCE 7.1. The present IDoc Listeners only use the ERP system and client to distinguish between Listener systems. So despite creating unique Program IDs for each of the two listeners, the IDoc Messages are being routed to only one.

The best solution is to create a parsing transaction for the one listener which receives the LOIPRO IDocs. Apparently there are some other system issues which the developers identified that cause them to be reluctant to make the IDoc Listeners function the way they did in 12.0 and earlier MII versions, but I do not know the specifics.

The good news is that the fix is usually pretty easy and rapidly implemented.

Regards,

Mike

[Former Member]

Hi Michael.

It sounds strange for me. I was expecting a different behavior. I thought we could create listeners according the pair (Server Name, Message Name) and define the transaction to handle the proper incoming message.

Anyway, we will follow your advice and create a transaction to parser the incoming message and call the right transaction. The problem is I am not sure if I can find a value which will give me this information. We would like to let the user define it.

One more thing: in the NWA I found the BindingKey configuration and I did not understand what this is for. We set it as the same for XMIIIDOC01 and XMIIIDOC02. I was wondering if it could be a problem, despite the fact we could not use another value. Could you give me an idea what is this for and where I can find the right value?

Thank you very much

Italo Stefani

Vetta Group

[agentry_src]

Hi Italo,

The binding key is set of for the type of Listener (IDoc or RFC) and should be left as the default value.

You may want to look at building a UI for users to view the IDocs in a table/grid display and then let them select which ones to process and by which method. This would require using the Category instead of Transaction processing to queue the IDocs for later processing. Not sure if that would work for your users, but certainly an option to look at. It will take a bit more development than the parsing transaction.

Regards,

Mike

Edited by: Michael Appleby on Jan 26, 2012 12:59 PM

[Former Member]

Thanks Michael!