Question in Message Id.

[vijay_b4]

Hello, Today morning I received an alert which consists of Sender Service,sender interface, error code and message id. I took the message id from alert and added it in message monitor database tab-->identifiers, by giving today time-period with status all, but unfortunately nothing is getting displayed, not sure why. And i check the configuration, the scenario is one sender to 3 receivers. So here now am not sure which receiver interface the issue is with, as sender details are same for all the 3 receivers and there are no failures registered for this interface in message monitor.Any help in finding with the message id.

Thanks in advance!

[vadimklimov · Accepted solution]

Hello Vijay,

A reason for this is, by default, in Adapter Engine, messages are first time persisted after receiver determination step, even though they get message ID assigned to them when entering Messaging System (which happens before receiver determination step). If receiver determination fails, corresponding alert is produced (the one you receive), but since message is not yet persisted at this time, Message Monitor shows no messages by a given message ID (since literally speaking, there are no messages that would have been persisted with that message ID).

If you would like to see messages in Message Monitor for such described situations, it is necessary to enable staging for a step preceding receiver determination (for example, for message preparation step) so that at least one version of a message is already persisted before a message reaches receiver determination step and fails. Examples of staging configuration can be found in a blog . Please enable additional staging with caution since it has impact on database (amount of message related data persisted) and performance (every staging and logging step contributes to overall message processing time) - it is not recommended to enable extra staging unless it is really required.

Regards,

Vadim

[vijay_b4 · Accepted solution]

Thank you very much Vadim! If its not recommended then i will not go for it and more over its production system cant take risk. What would be the cause for error

"Interface Determination did not yield to actual interface" , as I did not find any failures either in message and CC monitoring, should it be ignored or considered. Any idea. Thanks.

[vadimklimov · Accepted solution]

Vijay, this error shall definitely be investigated: the error means there was no receiver found for an incoming message. I suggest you checking conditions in receiver determination configuration and cross-checking them against sent message. Then you can decide if it is due to misconfiguration of receiver determination, improper content of transmitted message that leads to receiver determination failure, or an expected error for that kind of valid messages.

Regarding enabling staging... Well, it is not stated that it is not recommended to enable additional staging / logging since there are some requirements when it is necessary to do so. Recommendation is, not to enable superfluous message staging and logging to avoid unnecessary message staging and logging.

In situations like yours, it may be helpful to enable staging before receiver determination temporarily in order to capture received message and progress with investigation of root cause of receiver determination failure. As an alternative to this, you can also use XPI Inspector tracing for a sender channel with enabled Messaging System and Module Processor options to capture received message details.

Regards,

Vadim

[former_member186851 · Accepted solution]

Vadim,

But it should be displayed right? since the message is failing for interface determination.

And why no messages in CC as well.

[former_member186851 · Accepted solution]

Vijay interface deterimation erro can be elimnated by removing SWCV from ICO.

[vadimklimov · Accepted solution]

Raghuraman, there are entries about that message processing in Communication Channel Monitor - that's right (since XI message was already composed by that time), but since there was no persistence of a message, it is not seen in Message Monitor.

Here is a small test. Initially, I use default staging configuration globally in Adapter Engine and do not overwrite it by scenario specific settings:

After triggering an interface with specifically broken receiver determination, I can see log entries in Communication Channel Monitor that correspond to the message processed by respective sender channel:

But I will not find any message with observed message ID in Message Monitor:

Next, the only change I do, is I enable scenario specific logging for message preparation step:

I again trigger an interface and again see log entries for a newly accepted message in Communication Channel Monitor:

But this time, I can also see a persisted message in Message Monitor:

More precise look into this message, particularly into persisted message versions for it, gives evidence it was persisted at message preparation step (BI) only - according to recent adjustment in scenario specific staging and considering message hasn't passed next step where staging for it was configured (receiver determination):

Regards,

Vadim

[former_member186851 · Accepted solution]

Thanks Vadim.

[vijay_b4 · Accepted solution]

Hi Vadim,

But in my case, the message id not even shown up in the communication channel monitoring.

There are some message ids in that but which are not matching to the id in the alert i received.

Thanks in advance!

[vadimklimov · Accepted solution]

Raghu, can you clarify how deletion of SWCV in ICo can help in resolution of receiver determination error? It can be a workaround for pass through scenarios where mapping is not used at all, but is not a common case in PI, so I'd rather treat it as exception and suggest looking into context of what receiver determination conditions are (if any) and if the accepted message conforms to them or not.

Regards,

Vadim

[vadimklimov · Accepted solution]

Vijay,

Can you provide screenshot from Communication Channel Monitor for cases when there are no message IDs? This may happen, but I used to face it when there was an error in adapter logic, not in receiver determination - if an exception was caught during receiver determination step, corresponding entry in communication channel log used to contain details about generated message ID.

If message ID in communication channel log doesn't match to those mentioned in alert messages, this is likely to be a message that was processed by a channel and also successfully passed other processing steps in PI (as a result, not resulting in error and not producing alert). Can you find such messages by their IDs in Message Monitor?

Regards,

Vadim

[engswee · Accepted solution]

I agree with Vadim. Interface determination error could be due to many different root causes.

While removing the sender SWCV from the ICO might solve certain cases, it is a bit premature to suggest such a poor man's solution without a thorough understanding of the cause of the issue. At best it might solve the current issue, but at worst it could lead to unseen issues in the future. I'm amazed why such a response is marked as helpful at all because IMHO it definitely is not.

Btw, Vadim, I've never thought of using staging temporarily to assist in troubleshooting such issues - nice trick indeed!

[former_member186851 · Accepted solution]

@Vadim,Its Interface determination error I guess.As per this note Vadim-1933223.

@Engg..Correct,I just gave a start up solution.it might be due to other issues as wel.

[bhavesh_kantilal · Accepted solution]

Vadim,

Appreciate the patience you have to demonstrate this!

People like me just tend to be lazy and say - hey this is why it fails, do this and and provide the theoretical and experience know how.

If someone questions the prognosis as has happened in this case, I typically tend to say, heck not my problem and move on! Love the fact that you went into such details to confirm your solution and stand by it! Good Job!

Cheers,

Bhavesh

[engswee · Accepted solution]

If you take some time to read carefully the note that you provided, there is no mention of any "remove SWCV" in the resolution section or anywhere else in the note. Furthermore the note talks about a migrated scenario which is not mentioned anywhere in this thread.

As I have repeatedly pointed out to you, such wild guesses and misleading answers are not helpful at all to the OP or other community members. It just decreases the quality of content in the space.

[former_member186851 · Accepted solution]

Oh Ya Engg..I shared a wrong note.My bad. (

And it was not wild guess ,It has solved in our cases so just gave as a solution, never mentioned that is the only solution.

Anyways am still a beginner, will take care of it Engg, Thanks for pointing it everytime.

[vadimklimov · Accepted solution]

Thank you, Bhavesh. Few screenshots with demonstration of functionality in live system are commonly more convincing. And since I already had a working interface, for which I only had to break receiver determination and capture screenshots, it was a fast exercise this time.

Regards,

Vadim

[bhavesh_kantilal]

To add to what Vadim, Eng Swee have provided,

• The error - Interface Determination did not yield an Interface could mean - that the Root Node of your XML does not match any of the "Operations" in your Interface.
• PI 7.1 onwards an Interface enabled you to define multiple Operations. What this meant in the runtime was that when a message would come to the Interface Determination Step, to identify what Operation has been triggered, PI would check whether the Root Tag of your XML matches that of any of the Operations of your Inbound Service Interface. If yes, it uses your Inbound Interface and marches ahead. If no, it triggers an error stating Interface Determination Did not yield an Interface.
• From your Alert screen shot, channel name, I think its a ABAP Proxy trigger. Finally, while you haven't got the Logs on PI Side due to the detailed explanation from Vadim, as this is a Proxy Based Interface, you can use the message id on ECC to see what the payload was. Check the XML payload and then use this XML Payload to understand what would have happened with regards to this error.
• Obviously if this keeps repeating, I would recommend to enable Interface Specific Logging to capture more logs within PI!

Regards,

Bhavesh

[vijay_b4]

Thanks all.I really appreciate you all taking time and providing detailed solutions!

Sorry for the late reply. The error was yesterday's and which was not yet resolved. First coming to Vadim's point, I wanted to take the screen shot of message ids in the communication channel monitoring, but unfortunately when I login into  into communication channel monitoring, it is showing up today's recent memory logs, Any help in finding yesterdays memory logs in the communication channel monitoring.

Meanwhile as Bhavesh said I will check in ECC for the payload and I will try to analyze and will post the results.

[vijay_b4]

The message id from the alert i received, matches to the message id in the ECC. In ECC sxmb_moni with that message id: the message is in failed status:

Error:

<SAP:Stack>com.sap.engine.interfaces.messaging.api.exception.MessagingException: com.sap.aii.adapter.xi.routing.RoutingException: InterfaceDetermination did not yield any actual interface at com.sap.aii.adapter.soap.web.SOAPHandler.processSOAPtoXMB(SOAPHandler.java:772) at com.sap.aii.adapter.soap.web.MessageServlet.doPost(MessageServlet.java:530) at javax.servlet.http.HttpServlet.service(HttpServlet.java:754) at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)

Thanks!

[bhavesh_kantilal]

Can you check the message payload in SXMB_MONI on ECC? Is the payload a valid payload that is expected by your Interface Determination? This would then help you decipher what could be going wrong.

[vijay_b4]

This is what I see in the payload section:

[bhavesh_kantilal]

The payload contains no data except for the root node.

Check if there is a condition in the interface determination or receiver interfaces in your ICO.  ideally your ECc proxy code should not be triggering the call to PI if there is no data to send. Your proxy report would need to be fixed to avoid sending this empty payload to PI.

[vijay_b4]

No condition in Receiver Determination, but has some conditions specified in Interface Determination:

[bhavesh_kantilal]

Explains why the error. your input payload has no data and hence the conditions fail and the error : Interface determination did not yield an interface.

You would need to get this fixed in ECC as the proxy should not be triggering an empty payload.

[vijay_b4]

Thanks Bhavesh! I will explain same to Abapers to modify their code.

One more question in the alert what i received is not having the PI message id right. Normally all the other alerts i receive are having PI message id. For this particular one, the message id is matching with the message id in SXMB_MONI ECC.

[bhavesh_kantilal]

• Message id in both ECC and PI will be the same.
• Why you don't see this failed message in PI, Valdim has already provided an extremely helpful answer.
• If you check a successful message the message id will be same.

[vijay_b4]

I have not tried Vadim steps yet. I will try now.

I did not understand your 3rd point...what successful message should i check?

[bhavesh_kantilal]

If you check the message id of a successful message in ECC sxmb moni, the same message id can be used to view the message in PI

[vijay_b4]

Thanks Bhavesh.You are talking about other successful messages right. Not about this failed one.

And in Vadim's first screen shot, where should i do the setup for that, i searched in Adapter Engine-> message monitor, but could not find the Kernal, services etc.,

[bhavesh_kantilal]

• Yes, I was talking about successful messages.
• The Services are available in NWA. Go to NWA --> Configuration --> Infrastructure --> Java System Properties to see these properties described..

Regards

Bhavesh

[vijay_b4]

GM Bhavesh, I searched all tabs, but not seen the Java system Properties. Please guide me further.

Thank you,

Vijay.

[bhavesh_kantilal]

You have logged into PI Monitoring. You need to login to the Netweaver Administrator at http://host:port/nwa

Regards

Bhavesh

[vijay_b4]

Hi Bhavesh,

Its not PI monitoring screen, its SAP NWA screen,itseems I dont have authorization for Java system properties, I requested Basis to add the following roles:

SAP_XI_RWB_SERV_USER

SAP_XI_ADMINISTRATOR_J2EE

Thanks!

[former_member182412]

Hi Vijay,

You need to have below role in order to change anything in NWA. Check the below link for more details

Monitoring Roles - Advanced Adapter Engine - SAP Library

display and modify

SAP_XI_DEVELOPER_J2EE,SAP_XI_CONFIGURATOR_J2EE,SAP_XI_CONTENT_ORGANIZER_J2EE, NWA_SUPERADMIN

Regards,

Praveen.

[former_member186851]

Hello vijay,

Go to the CC Monitoring ,see from there if you can get the message.

[vijay_b4]

Hi Raghu, nothing showing up even there. I check the 3 receiver channels in communication monitoring, but the message id in the alert is not matching with the message id's in the communication channel monitoring. and all the 3 receiver CC's are running with out errors.

[former_member186851]

Hello Vijay,

Thats strange,

CC should have this message,Are search using the service interface.