SXMB_MONI_BPE -> Message Payload not visible in container

[Former Member]

I have a message that is failing a mapping within an Integration Process. This is an Async process end-to-end. I have trace_level set to 3, and logging/logging_propagation/logging/sync set to 1.

I view the failed workflow in SXMB_MONI_BPE/list with technical details and see the mapping step that errored. I click this and look under "container". I then drill down to messages and see 1 message going into the mapping. Under this there is some Header information but NO Payload. How can I get this to appear here? Ideally I'd like this to be logged only for error'd workflows.

The mapping exception also does not get propagated back up to sxmb_moni level so the only way to see it is in the alert that's raised/inbox, the defaultTrace or sxmb_moni_bpe. Is there a way to do this (I seem to recall I couldnt do this in XI 3.0/14)? I'm using XI 7.0/12. I do not want a custom alert, just the standard text like you see in the mapping test tool (xxx cannot be produced due to yyy).

Thanks,

James.

[Former Member · Accepted solution]

Do you have a block surrounding the area that has the error? If so, temporally remove it, activate your BPM and run the scenario again. This should allow the error to propagate to SXI_MONI.

[Former Member · Accepted solution]

Thanks for the update Emmett,

Yes the mapping step is within a block, but it's a ParForEach as there's a number of messages being mapped. Unfortunately I dont think I can bring it out of this block. Any other ideas?

Thanks!

James.

[Former Member · Accepted solution]

James,

Well, I'm sure you tried this, but let me just check. Do you know the specific message that's causing the issue? If so, can you pull it out and bring it into IR and run a test in the Interface Mapping?

-Emmett

[Former Member · Accepted solution]

Yep, have done that, but 2 issues:

Firstly, it doesnt help ongoing supportability where seeing why a message failed through quick and simple tools like sxmb_moni is quite important.

Secondly because of other dependancies in predecessor steps, I have to do a bit of fiddling around to test it. Not helped by the fact that the Message Mapping test tool doesnt seem to want to show me the xml it produces from a previous mapping (It shows the grid ok, but not the xml !! ) so actually I can only semi-guess the data passed to the map. Hence why I originally wanted to see the message that was passed in the container variable of sxmb_moni_bpe.

Cheers

James.

[henrique_pinto · Accepted solution]

you can also level up the trace level of the mapping runtime to DEBUG, in Visual Administrator log service, and check the defaulttrace.log file for the actual exception.

Also, as a workaround, you could save all intermediary messages generated in BPM in a file (just add send steps to a file adapter between all the relevant steps in BPM).

Regards,

Henrique.

[Former Member · Accepted solution]

I've never had the message mapping test tool flake out like that. Did you test with DEBUG in the message map? I wonder if something in the mapping is causing the problem. Are you using any user defined functions?

[Former Member · Accepted solution]

No UDF's, is a fairly simple 1:n map, so yes it is a bit strange but then stranger things have happened in the world of xi I'll probably raise a note for it, but it's of lesser importance right now!

Re: Henrique's suggestions, both of these wouldnt be suitable for production issue detection/resolution and hence no good for me

Thanks both,

James.

[henrique_pinto · Accepted solution]

Setting the trace up for production systems isn't that harmful. Just make sure to leave it only for the necessary time (recover the original trace level asap).

Regards,

Henrique.