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 Member · 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 Member · 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 Member · 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 Member · 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 Member · 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