Idocs "lost" when two servers are in use

[Former Member]

We have two MII servers (N1 and N2) and each server has 4 server nodes. When only N1 is up, all idocs are received from R/3 system and processed fine. When both N1 and N2 are up, only some of the idocs are received. For example, should always be 135 idocs but when both servers are running, only 112 will be processed. The rest end up in SM58 with trfc error. Errors show up in the mii log saying that the gateway connection is lost.

We've also noted that the message listener on one server will say 'stopped' but if you logon to the other server, it will say 'running'. (I did not think it would be possible for this to be different!)

Anyone seen this error or have suggestions for correction? MII version 12.0.

[Former Member]

We are at MII 12.0.10.2. I reviewed more recent patches but they don't sound like they would help with this issue. Time to open a new message, I guess.

[agentry_src]

Kirsten,

There is a document for configuring 12.0 for IDoc Listeners, but you should also read the 12.1 for the errors which have been identified and commented.

Musarrat is correct in his comment on the Program ID. That applies regardless of MII version. The Program ID needs to be specific to a single MII server destination (IDoc Listener).

Why are you using two MII servers to receive the IDocs? I am curious about your architecture.

Regards,

Mike

Edited by: Michael Appleby on Aug 2, 2010 1:58 PM

[Former Member]

Hi Michael,

It has two servers for high availability since this is a critical application for us. N1 runs db and central instance, N2 runs dialog instance and in case of N1 disaster becomes the failover server.

We currently have 1 RFC destination/program id (XMIIJCO1). Do you think we should have two and configure the message listener on N1 and N2 differently? We thought that the message listener was a single entity and only 1 RFC destination was necessary but now I am starting to wonder...

[agentry_src]

Hi Kirsten,

The biggest problem that users have experienced setting up IDoc Listeners is this very issue. Though usually it is because someone manually adds the Prog ID in NW or copies an image from one MII server to another.

I am not an ALE expert, but I had a discussion with one a couple of years ago. What he told me is that the ECC system broadcasts a notification that there is a document for that specific Prog ID. Then the MII IDoc Listener tries to pull it from ECC. When you have two systems that recieve the message and both try to retrieve it and hit ECC at the same time, an error will occur. I welcome corrections by anyone who understands this mechanism better. However the point is that the Prog ID must establish a unique connector between an MII server instance and an ECC configured RFC destination. If you only have one MII instance running the IDoc LIstener using the Prog ID, you are fine. If your primary server fails and the backup kicks in and activates the IDoc Listener, you should still be fine. If both are running and they both have IDoc Listeners active using the same Prog ID, then errors will occur when they hit ECC concurrently.

So you can either manage the fail over process to enable the backup IDoc LIstener only after the primary goes down. I am not sure how to manage that, but I don't doubt it can be done. Or you need to configure the two servers receiving the IDocs, with two different Prog IDs. (And add the logic for not processing them twice.)

Regards,

Mike

[Former Member]

Thanks, Mike. Great information and this gives me two ways to, hopefully, solve our problem. I'll update with results after we've tried them out.

Kirsten

[Former Member]

No joy. We had N2 server down for several weeks and all idocs were processing fine. On Sunday, I started services on N2 server. When I logged onto MII using N2 URL, message listener said 'stopped'. When on N1, message listener said 'running'. So I thought all would be good. No luck, only 109 of the 135 idocs were received and processed.

I tried this morning to change the N1 and N2 message listeners to give each a unique R3 gateway and PROGID to pull from but if I change in one and save, it is immediately reflected in the other. No way to change them to be different.

Next suggestions?

[agentry_src]

Hi Kirsten,

I think you need to open a ticket. Once it is open, let me know the ticket number and I will see about getting some additional (and more technical) resources to look at it.

Regards,

Mike

Edited by: Michael Appleby on Aug 16, 2010 4:23 PM

[jcgood25]

Kirsten,

What specific version of 12.0 are you running? The message listener aspect of MII has been through updates in latter versions of 12.0 and within 12.1 due to issues like this, as well as some throttling to avoid server slowdown when bursts of large documents are sent.

I would suggest looking through the SAP Notes associated with the different patch levels newer than the version you're running. It is quite possible that it has already been addressed and you could test it out on your sandbox or dev system.

Regards,

Jeremy

[Former Member]

Thank you, but this document is for MII 12.1 so a lot of the configuration doesn't apply to my version.

I only have one RFC destination in the SAP R/3 system and the program id is used only in that RFC.

Is there a unique message listener on each MII server? Do I need to configure each message listener to use a different RFC destination with different server/gateway?

[Former Member]

Are you using same program-id for both the RFC destinations? Please see [this document|http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/a02bc706-15f2-2c10-1aab-a1927ada11f0?quicklink=index&overridelayout=true] . There's a note in there which says:

Your Program ID can only be used for a single RFC Destination. Using the same Program ID in multiple destinations will cause errors.

Regards,

Musarrat