Handling mapping errors in a BPM

[Former Member]

Hi Guys,

We have a BPM that receives a Request Message from a sender DBMS system with serveral rows, it transforms/maps the inbound message to a multiline message type (1 to N multi-mapping), and it handles each line of the multiline message type separately within a BLOCK step in ParForEach mode. Within the block it executes a Synchronous SEND step to an R/3 system (both the request and response message mappings are executed outside of the BPM) and then it sends the response from R/3 to the DBMS system asynchronously via a SEND asynchronous step. Our problem is that if something fails within the mapping (either a mapping data error or an RFC error during an RFC lookup) during the synchronous step execution in a single block, all other blocks hang as well and remain in status "Ready". How can we handle/treat such failures? What happens when we restart business processes in error status that contain synchronous steps?

We thought of creating as many process instances as the number of the message types/Interfaces by executing the 1 to N multi-mapping outside of the BPM for better montoring purposes, but this would have a negative impact on performance compared to our current design, which handles all messages within the same process instance. What do you think?

[nageshwar_reddy]

The solution really depends on what you are currently doing with the errors. What does business do when there is a data error? If you are not doing anything with the data errors currently, my be you can catch the system errors and continue the execution to the end of the loop. This way, you may be able to not remove the blocking issue...

As Michal suggested re-designing the process will help improve performance.

[MichalKrawczyk]

Hi,

there is no need to use a ccBPM in this case I believe,

use this config

http://wiki.sdn.sap.com/wiki/display/HOME/Using+Request+Response+Bean+Module+in+FILE+Adapter

to get the data from jdbc (single line) call the rfc-sync return the data to jdbc (async)

you can split the jdbc call either in the select statement or in another flow - jdbc - multiple files first

and then file - rfc - jdbc

can you replace the ccBPM with this ? it will work much much faster this way,

Regards,

Michal Krawczyk

[Former Member]

Hi Michal,

Thank you for your response. I am aware of this type of configuration. And we've already tried JDBC sender to SOAP receiver (in order to split the JDBC call to multiple messages) and then SOAP sender to synchronous Service call to ECC for each message. We then added the above configuration to the sender SOAP adapter, in order to write the response back to the DBMS system, however it was partially working.

[Former Member]

Hi Michal,

Given also the fact that we have to fetch hundreds of batches (with rows) from the database, XI will be polling the database very frequently, i.e. for 500 batches and let's say polling time every 60 seconds, it will take the interface 500*60 seconds to run. And if we lower down the polling time, it will have a negative impact on the DB's performance. By batch, I mean the message type with the number of rows that is currently produced by the multi-mapping.