Skip to Content
Former Member
Jul 20, 2007 at 09:23 AM

Getting a mapping error to propogate from loop block within I.P.


OK I kinda asked the question as a sub topic under a different heading SXMB_MONI_BPE -> Message Payload not visible in container but didnt really get an answer I'm happy with, so here goes as a main topic!

The short description:

I have a mapping step that must reside in a loop block, any mapping errors I want propogated back up to the main container so that they error and appear in the trace within SXMB_MONI in the same visibly obvious way as a mapping step that is not inside a block does.

The long description:

I have an Integration Process which splits a source message, then maps the individual messages produced within a forEach block. Unfortunately when there is a mapping error within the block, it does not propogate any meaningful information back to the message trace. Instead it just fails in smq2 with permanent error in inbound bpe processing.

When I search in SXMB_MONI_BPE there are no process steps returned, as though the IP was never called by the BPE.

When I put the whole thing inside a block with an exception path that has an alert step, I do get process steps returned in sxmb_moni_bpe. When I examine the list with technical details I cannot see any "payload" under the table of messages that has been split out, therefor I cannot debug the mappings of individual messages I am looping on. I have LOGGING, LOGGING_PROPOGATION and LOGGING_SYNC set to 1, and TRACE_LEVEL set to 3 for my IE.

I have 2 scenarios/requirements:

1) I put the uncaught mapping exception in the loop blook, and the error is propogated back up and the smq2 error is subsequently not produced (like it would behave if the mapping step was not inside any blocks).

2) I catch exceptions and raise an alert and then the logging is enhanced sufficiently to enable the individual messages the loop block is looping on to be viewed within the container in sxmb_moni_bpe->list with technical details.

The only place I can see the error is in the defaultTrace log file, which is obviously not a suitable method for productive use. Any solution needs to be usable in day-to-day administration of a production system, even though this is a dev issue at present!