Error handling question

[Former Member]

I have a situation where I'm sending 1 file that contains thousands of lineitems. Each lineitem represents a transaction. I use BPM to split the lines into singular transaction calls to the receiver adapter. Let's say most of the calls on the receiver side are successful but about 15% are unsuccessful. I want to be able to continue processing after each error and later address the errors. How do I best handle these errors? Can I retry a message so that I resend a specific transaction and not send the whole file? Therefore, only send the messages after it has been split by the BPM.

[Former Member · Accepted solution]

Hi Bevan,

we had a similar scenario in our project and we handeled the errors using exception branch in BPM.

Before i explain our approach , i need some more information on your scenario...

1. Call to your receiver is synch or asynch ?

2. Are you using foreach/parforeach blcok for making multiple calls to the receiver ?

As such you cannot retry a specific transaction with in a message but if your each transaction is a seperate message in XI then you can retry...

there are ways by which you can always model your BPM to handle such scenarios...

Regards

Anand

[Former Member · Accepted solution]

Hi Anand,

Currently, the call to the receiver is asynch. I was going to use parforeach however there are more transaction lines than this method can handle so I'm doing foreach. Yes, of course we can handle errors within the BPM but if we need to manually fix something in the external system, we don't want the BPM context to continue to persist. What if we couldn't fix something in the external system until 20 days later, we wouldn't want the BPM process to continue to exist. It would be nice if we could do retry from this specific errored transaction. Any help?

[Former Member · Accepted solution]

Hi Bevan,

You cannot retry from XI since the message would have already gone in success state. And since it is asynchronous message you will not know the status of the call in the application system. But if you can get the immediate response either synchronous or asynchronous (correlation) then we can write a errored out transaction to another file in the exception branch, continue with the remaining transactions and process the file with failed transactions after fixing the errors in the receiver system.

In you scenario the error is occuring in the receiver system and there is no ack back to XI, the receiver system should handle such errors.

One way is to use idoc's i.e create an idoc for each transaction. Failed idoc's (upadte idoc status to 51 if it fails) can be reprocessed again directly in the reciver system after fisxing the erros...

Regards

Anand

[Former Member · Accepted solution]

Thanks Anand. I think an option is to write errors to a file for each transaction and create another scenario to process this file. It would be nice if XI could have retries that begin within a certain point of the business process but then, this would require lots of persistence...:) Why couldn't I receive an acknowledgement back to XI? Can't the receiver system trigger an acknowledgement back to XI or are there limitations within the acknowledgement framework? I saw in BPM application and transport acknowledgement so I assume this is not a problem.

[Former Member · Accepted solution]

Hi Bevan,

The transport acknowledgement only specifies that the message was received successfully.

In case of Application acknowledgement receiver system should have the mechanism to acknowldge the processing status of transaction back to XI. Otherwise we need to trigger the explicit response from reciver system to XI and use correlations to receive the response.

currently what adapter you are using so send your transaction to the receiving system ?

Also

>>I think an option is to write errors to a file for each transaction and create another scenario to process this file.

You do not need a another scenario if you write the transaction in the original format, same scenario can be used...

Another way you can avoid writing a file for failed transactions is by creating a seperate XI message for each transaction so that each can be reprocessed seperately if it goes into error status.

Regrads

Anand

[Former Member · Accepted solution]

My scenario is File->XI->RFC.

Yes, you're right, I could use the same scenario however, for performance sake, I no longer need the BPM splitting so I plan to create another scenario without BPM.

With my scenario, I cannot have a separate XI message for each transaction. The sender business system mandates packaging transactions into 1 file. With this, I don't see of anyway to send individual transactions.

[Former Member · Accepted solution]

Hi Bevan,

There are many ways we can handle this scenario...

In all these cases your async RFC should send back the response to XI back...

Also You could consider ABAP proxy aswell for better performance if your receiving system is based on WAS 6.40.

1. Send the complete file(as import/tables parameter) in a single async RFC call and wait for the async response by activating the correlation. Let RFC in receiving system handle spilitting into individual transactions, executing each transaction, capturing the failed transactions and send the response back to XI in a single message. Perormamncewise this would be better since individual RFC call perormance depends on n/w ,system performance and time for logon/logoff activities. We had a similar scenario where the synchronous RFC call was taking a considerable amount of time to make a RFC call.

2. you can splitt your file into a seperate message using file adapter content conversion or BPM (this depends on your file format), make RFC call and wait for the RFC response. Each transaction can be processed as a seperate message.

3. The current approach i.e splitting into individual transactions in a BPM , making a seperate RFC call and wait for the async response. Once you receive the response collate failed transactions and write it to a another file. This file can be processed using the same interface..

But this approach might have a perfromance issues if the volumes are high.

You need to consider performance, correlation and any other additional requirements like error/audit file generations to choose the appropriate method specified above.

Hope this helps..

Regards

Anand