cancel
Showing results for 
Search instead for 
Did you mean: 

Missing sender interface details in sxmb_moni for XI -> ECC ABAP Proxy

Former Member
0 Kudos

I'm hoping there is a simple answer to this, maybe a server side configuration on the ECC box that I'm missing.

My scenario is a File -> File Adapter -> XI -> XI Adapter -> ECC -> ABAP Proxy

Within sxmb_moni on the XI server my sender information looks as I expect, for example:

<SAP:Sender>

<SAP:Service>MYPARTNER</SAP:Service>

<SAP:Interface namespace="urn:MYNAMESPACE">MYINTERFACE</SAP:Interface>

</SAP:Sender>

Receiver information looks as expected, messages is successful.

On the ECC side the message is also successful, processes as expected, however the sender information is no longer being fully propogated. In the ECC sxmb_moni it now looks like:

<SAP:Sender>

<SAP:Service>MYPARTNER</SAP:Service>

<SAP:Interface namespace="" />

</SAP:Sender>

It's like the sender message interface and sender interface namespace are getting discarded! Ironically the sender service is still there, the receiver information is complete (service, interface, namespace) and correct on both the XI and ECC sides.

And while the message is successful, I want to have that sender interface / namespace visible on the ECC sxmb_moni for ease of monitoring purposes. We receive a number of interfaces from a single partner using this same architecture and is they all look very similar at first glance in sxmb_moni.

This thread is similar but not the fix as this related to a config issue on the XI server:

Any help is appreciated, points to be awarded for helpful answers!

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

Go to SXMB_ADM -> Integration Engine Configuration -> Role of Business System -> Make it "Integration Server".

Former Member
0 Kudos

I believe this was also referenced in the link I had in my original post, however I don't think it applies here for the following reasons:

1) The XI server shows the correct sender information in sxmb_moni. When I go to the 'Integration Engine Configuration' it is set to 'Integration Server' as I would expect

2) Its the ECC server that appears to be missing the sender information in its sxmb_moni. When I go to the 'Integration Configuration' on that server it is set to be 'Application Server' which is also what I would expect (given it is the ECC server and used as an application server)

Can you confirm you intended that configuration for the ECC server, not the XI server? I am hesitant to simply make that change in case it then impacts any other interfaces routing into and out of that ECC box. When I reference the following thread (http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/e0ac1a33-debf-2c10-45bf-fb19f6e15649?quicklink=index&overridelayout=true) in section 1.3.2 it appears the ECC system is intended to be 'Application Server'...

Thanks!

Edited by: Darin Anderson on Apr 18, 2011 11:21 PM

baskar_gopalakrishnan2
Active Contributor
0 Kudos

PI monitors entire pipe line steps including request and response messages in SXMB_MONI

Whereas if you use proxy as target message, you can monitor only the target request and response messages only in ECC and not the entire source and target messages.

I think ECC captures information only related to receiver agreement, Where we dont specify sender interface and namespace. So I guess we are not getting it.

Former Member
0 Kudos

Ugh..... I would hope that is not the case, as looking in the ECC SXMB_MONI then only shows you half the story - the receiving side but no idea where it came from. We reuse a lot of our ECC target objects across many inbound partners, sometimes more than once for a given partner. If what you're saying below is true then there is no direct way of determining which interface is which without cracking open each and every payload. Needless to say our Operations and Support team will be less than thrilled.....

Is there some linkage between XI and ECC in the monitoring transactions, like there is for IDocs? For example in a XI -> IDoc -> ECC scenario I can view the message in the XI sxmb_moni transaction. On that same line I can click on 'IDoc' and it takes me to XI's IDX5 transaction and shows me the XI related IDoc. Click on the Idoc number and it then remotely logs me into ECC We02 transaction and I can see the data all the way into ECC. In this manner I have a direct linkage throughout the pipeline for a message, no guessing as to which source XI message it relates to. Is there anything similar to that for my scenario? From playing around with it I don't readily see one but hoping there is one there.

Thanks for the thoughts, would appreciate anyone else's or concurrence if the above explanation is indeed the case (and I won't get the sender info on the ECC proxy side). Thanks!

Former Member
0 Kudos

Points awarded to Baskar, thanks for the help. Question left open pending confirmation of Baskar's thoughts / additional inputs on ways to alternatively track these messages from XI through to ECC.

Former Member
0 Kudos

Darin,

Can you try the following configuration and let me know if you achieve the desired result:

Transaction: SXMB_ADM->Integration Engine Configuration> Category: Runtime--> Logging =1 .

Former Member
0 Kudos

Thanks for the thought. That config was on the XI server, added it to the ECC server and reran the interface. Unfortunately the sender interface and namespace are still missing in the ECC sxi_monitor. Good thought, but looks like the issue remains.

baskar_gopalakrishnan2
Active Contributor
0 Kudos

IMHO, SXI_Monitor in ECC for only proxy communications monitoring. WE02 or WE05 for IDOC communication. Proxy communication does not need to capture sender information. So it captures request and response of just proxy related for synch scenarios and either request or response for asynch scenario.

Former Member
0 Kudos

While the core question remains (fully) unconfirmed, I did note the following in regards to traceability. In either direction (ECC -> XI and vice versa) a proxy message ID on the source server is identical to the initial message ID on the target sysytem. This does indeed help traceability as mentioned in a couple posts above. While true, however, it certainly would be nice not to have to jump between two servers to get all the sender / receiver information...

Darin