on 05-17-2016 4:14 PM
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!
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
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
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
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
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
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!
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
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.
To add to what Vadim, Eng Swee have provided,
Regards,
Bhavesh
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
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!
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.
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.
You have logged into PI Monitoring. You need to login to the Netweaver Administrator at http://host:port/nwa
Regards
Bhavesh
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.
Hello vijay,
Go to the CC Monitoring ,see from there if you can get the message.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
93 | |
10 | |
10 | |
9 | |
9 | |
7 | |
6 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.