cancel
Showing results for 
Search instead for 
Did you mean: 

R3 Outbound IDOC status not changed

Former Member
0 Kudos

Hi,

I was able to correctly setup the communication between the ERP and MII (configuring both sides), to send IDOC from R3, getting messages xMII Side. My only problem is related to IDOC Status in R3, I really don't know if I have to expect an automatic status change (3-->12) done maybe through the listener on Netweaver or if I have to look for some BAPI to be added/called inside logic processing the idoc or what else...practically mi IDOCS are correctly received and processed xMII side, but no status change in R3.

I'm using SAP 4.6 and MII 12.1

tnx a lot

Accepted Solutions (1)

Accepted Solutions (1)

agentry_src
Active Contributor
0 Kudos

Since you are using the RKT release (12.1.0 build 201), I can't begin to tell you whether the problem is with your installation or your version of the MII software. However, I do have a few comments regarding MII and IDoc Listeners.

MII 12.1 is based on NW CE and most functions related to IDoc and RFC listeners were moved out of MII and into NetWeaver (CE). The processing rule editor and message cleanup functions remained in MII, but configuration and management of the Listener interfaces are now in NW CE.

Early in the release history of MII, NW CE changed how the listeners functioned and so specific versions of MII require corresponding specific versions of NW CE so the way MII handles Listeners has to correspond to how NW CE is set up for Listeners.

As you may have known from researching other threads on this forum, MII 12.1.4 requires NW CE SP3 in order for both types of Listeners to function properly. With other combinations of MII releases and earlier NW CE releases, the RFC Listener worked, but had "issues" and the IDoc Listener did not work at all.

I believe that the initial RKT and first GA versions of MII may have had working listeners of both types, but don't have specific evidence supporting that belief.

As suggested before, you should upgrade your MII (and NW) installation to something remotely current. However, I will leave it to others to determine whether the RKT release performed the IDoc status update you are asking (or even whether it is done in the current NW CE/MII combinations).

Regards,

Mike

Former Member
0 Kudos

I have the feeling that I'm lucky getting at least IDOC Messages on MII, with the RKT Release we are using...

Anyway, except these considerations on versioning, do you know if that feature I'm looking for should be in theory provided through RFCListener (configured aside of IDOCListener) or directly through the IDOCListener ?

tnx a lot

agentry_src
Active Contributor
0 Kudos

While I know a fair bit about how to set up and use IDoc Listeners, the underlying functionality of the how NW and ECC exchange IDocs and the administration is not something I know very much about.

But if I understand the issue, I would think that the status update would occur after the broadcast notification and at the time NW retrieves the IDoc successfully from ECC. It could be that NW is failing to send a message back after a successful retrieval. And so you would see ECC continuing to broadcast IDoc available notifications (or at least that is how I interpret your issue).

You should be able to trace the execution via the logs in NW and a Trace in ECC. I think a discussion with a Basis or ALE expert would be required to make that determination.

Former Member
0 Kudos

...well, I really would like to have a Basis/ALE expert next to me...

...my idea of the issue too, it was related to an ack missing to R3 from NW, I'll take a look on NW logs

IDOC it should pass from status 3 (passed to port) to 12 when the target system notifies the reception of the message;

regarding what I can see in my situation, R3 isn't trying to send it again

tnx a lot

Former Member
0 Kudos

...looking at NW logs, according to sending datetime of last IDOC I found (I replaced @ with *, to be able to post on the forum)

Message: trace critical [JCoRFC] onConfirm failed: java.lang.ClassCastException: class com.sap.mw.jco.jra.JRA$ReaderThread:sap.com/tcsapjratempcom.sap.engine.boot.loader.ResourceMultiParentClassLoader767a1196alive incompatible with interface javax.resource.spi.endpoint.MessageEndpoint:library:j2eecacom.sap.engine.boot.loader.ResourceMultiParentClassLoader6c408893alive java.lang.ClassCastException: class com.sap.mw.jco.jra.JRA$ReaderThread:sap.com/tcsapjratempcom.sap.engine.boot.loader.ResourceMultiParentClassLoader767a1196alive incompatible with interface javax.resource.spi.endpoint.MessageEndpoint:library:j2eecacom.sap.engine.boot.loader.ResourceMultiParentClassLoader6c408893alive

at com.sap.mw.jco.jra.JRA$ReaderThread.confirmTID(JRA.java:7150)

at com.sap.conn.jco.rt.DefaultServerWorker.onConfirmTID(DefaultServerWorker.java:203)

at com.sap.conn.jco.rt.MiddlewareJavaRfc$JavaRfcServer.handletRfcConfirm(MiddlewareJavaRfc.java:2355)

at com.sap.conn.jco.rt.MiddlewareJavaRfc$JavaRfcServer.listen(MiddlewareJavaRfc.java:1920)

at com.sap.conn.jco.rt.DefaultServerWorker.dispatch(DefaultServerWorker.java:259)

at com.sap.conn.jco.rt.DefaultServerWorker.loop(DefaultServerWorker.java:321)

at com.sap.conn.jco.rt.DefaultServerWorker.run(DefaultServerWorker.java:220)

at com.sap.mw.jco.jra.JRA$ReaderThread.run(JRA.java:7233)

at com.sap.engine.services.connector.jca15.work.TaskImpl.run(TaskImpl.java:255)

at com.sap.engine.core.thread.execution.Executable.run(Executable.java:109)

at com.sap.engine.core.thread.execution.CentralExecutor$SingleThread.run(CentralExecutor.java:314)

Date: 2010-11-24

Time: 14:14:56:148

Category: /System/Server/Connector/Rfc

Location: com.sap.conn.jco

Application: sap.com/xappsxmiijraapp

Thread: Thread[Managed_Application_Thread_11,5,Managed_Application_Thread]

Data Source: j2ee\cluster\server0\log\defaultTrace_00.trc

Arguments:

DSR Transaction: 8370fff7f0b211df95cb0026b97f25f2

Message Code:

Session: 0

Transaction:

User: Guest

Time Zone: +0100

CSN Component: BC-MID-CON-JCO

DC Component: tc~com.sap.conn.jco

Correlation ID: 2736750000001592

DSR Root Context ID: 8370FFF7F0B211DF95CB0026B97F25F2

DSR Connection: 8370fff7f0b211df95cb0026b97f25f2

DSR Counter: 0

Log ID: 0026B97F25F200FE0000004300000C64

Host: 39BGAS04-8

System: CE1

Instance: J00

Node: server0

Former Member
0 Kudos

Hi Michael,

finally I got resources to plan and run MII Upgrade.

At the moment I'm running:

MII: Ramp up Knowledge Transfer release (12.1.0 build 201)

NW: SAP NetWeaver CE 7.1 EHP1

My Idea is to upgrade to last 12.1 version available and (if i'm not wrong) it should be

MII: General Availability release (12.1.7)

NW: SP5

I started looking at SAP Service Marketplace and added to my download basket, from Software Downloads-->Installation and Upgrades::

Installation 51036187 (only to have full install package)

Upgrade 51036176 (the things I shuold probably need)

Help 51002899

I have to upgrade from 12.0.1 to 12.0.X, Am I going to the right direction or my activity has to be considered more a "patch" to my RKT version?

I will find something also related to NW upgrade or should I refer to NetWeaver sites?

regards

agentry_src
Active Contributor
0 Kudos

Sorry, but I am a bit confused by your last posting. Are you running two separate instances of MII(12.0.1, and 12.1.0)?

As far as the upgrade, yes you should go to 12.1.7 and NW SP5. I did it a few months ago and it was pretty easy. However, you may want to get more details on the installation prior to starting. I think there are quite a few folks here who have done it, but posting on the NW site is not a bad idea either.

Regards,

Mike

Edited by: Michael Appleby on Feb 1, 2011 8:28 PM

Former Member
0 Kudos

no no, absolutely my fault!

My upgrade it will be from 12.1.0 (RKT) to 12.1.7 (12.0 it was a mistake!).

Am I right using files coming from Software Downloads --> Installation and Upgrades?

It's not a patch, isn't it. It is considered an upgrade? (even if I'm not upgrading from a previous version...11.5 or 12.0)

regards

Former Member
0 Kudos

... at the end we went OT

now I'm finally on 12.1.8 and I'm trying unsuccessfully to have IDOC status change R3 side after IDOC reaches my MII system...

does anyone have this feature working?

regards

agentry_src
Active Contributor
0 Kudos

Part of the problem with what you are trying to do is that MII no longer communicates directly with ECC. NW handles all the communications. So to see where the status changes you will need to look on the NW system and not the MII application on top of it. This question has come up before in the last year or two. You may want to research it over a longer timeframe in the search parameters.

If the status of the IDoc is not changing, I would first look at NW and then back to the setup in 4.6 (unfortunately, I have not configured an IDoc Listener in R3 in about 5 years).

Regards,

Mike

Edited by: Michael Appleby on Mar 28, 2011 4:34 PM

Former Member
0 Kudos

ok, definitely, I felt I had to look only on top of MII, NW or R3.

I just wanted to look for someone who had it working and to understand how them did it.

anyway, tnx for answering, it make no sense to continue this thread

regards

Answers (0)