Error Handling in BPM - Send Step

[Former Member]

Hello,

I would like to implement the following two error handlers using BPM:

1. There is a send step which sends a message to an HTTP receiver. If the HTTP server is down I would like to add 3 retries and just in case after the third retry fails there should be an error Email sent. So I am wondering whether a communication error (which happens in the HTTP receiver communication channel) is delivered back to the process engine so that it can be handled using BPM.

2. I also need to apply a validation using XML schema. So if validation fails the error should also be returned to the process engine so that it can be handled in the integration process.

Are those two requirement possible as described (returning communication and validation errors)? Or do I have to follow another approach?

Thank you very much!

[former_member200962 · Accepted solution]

1 ---> if possible make the HTTP cal sync...if any error occurs you will come to know immediately.

In case of Async call, make use of the Transport Acknowledgement property in the Send Step in your BPM. Doubtful about its use in HTTP/ IDOC...

2 ---> are you working on PI7.1? If yes then there is a facility provided to check the XML schema (called XML validation in IE/ AE)

Regards,

Abhishek.

[Former Member · Accepted solution]

Hello thank you for the answer:

- Regarding Question 2: Yes, we use 7.1., I know that we can validate in the receiver agreement, however I am not sure if potential validation errors can be handling using BPM, so the question basically is whether validation errors will be returned to BPM or whether the message just runs on an error.

[former_member200962 · Accepted solution]

I know that we can validate in the receiver agreement, however I am not sure if potential validation errors can be 
handling using BPM, so the question basically is whether validation errors will be returned to BPM or whether the message just 
runs on an error.

Validation can be done even in Sender Agreement (for non-IDOC/HTTP/BPM senders)...

If a validation error occurs in the Receiver Agreement check then your IE will throw the error.

If you want to catch the error in BPM then you need to maintain an exception block for the corresponding Send Step. Then if the process goes in validation error, both IE and BPM will throw/ catch the error.

BPM or IE alone catching the error is not possible (rather not a good design) in case of schema validation.

Regards,

Abhishek.

[Former Member]

I made another test. This time with a synchronous send step. In case of errors the error branch will be taken immediately so this would be the way to go for and fulfills my requirements.

Just another question:

As in the send step there could be several errors possible, e.g. XML validation fails, error in communication channel etc.

Is it possible to have access to the error message that can be seen in monitoring and use this as input parameter for message mapping for example?

Would be helpful because otherwise I just could send back a generic error message to the sender.

[Former Member]

Hi,

In BPM use LOOP step with some success flag if msg sent in 3 attempts then OK otherwise branch to exception handling step;

[Former Member]

Hi devaramaraju,

yes, however the problem is how to find out whether an asynchronous send step was succesful or not in BPM. This is exactly my problem, that I cannot handle the errors in case a message can be restartet and the error therefore is not treated as permanent.

[Former Member]

Interesting Update:

I ran some more tests with error handling BPM send step.

1. When I do not request any acknowledgement on the send step no error is thrown in BPM

2. When I activate transport acknowledgement and there is an error in XML validation outbound channel request I get an system error acknowledgement back however the error branch is NOT taken either!

3. And NOW it gets interesting: When I simulate step 2 again an cancel the error message afterwards then the error branch is taken! Not very useful in my opinion if error messages have to be canceled first. The error branch seems to be pretty useless for me in case of asynchronous send steps.

Do you have any similar experiences or workaround to overcome this problem?

[former_member187339]

Hi Florian,

>>2. When I activate transport acknowledgement and there is an error in XML validation outbound channel request I get an system error acknowledgement back however the error branch is NOT taken either!

Correct send step using transport acknowledgment will check whether the message was transmitted or not

Check this link http://help.sap.com/saphelp_nw04s/helpdata/EN/43/65ce41ae343e2be10000000a1553f6/content.htm

>>3. And NOW it gets interesting: When I simulate step 2 again an cancel the error message afterwards then the error branch is taken! Not very useful in my opinion if error messages have to be canceled first. The error branch seems to be pretty useless for me in case of asynchronous send steps.

Again when you cancelled the message it was not received successfully by the receiver system and hence it raised exception (as mentioned in the Exception of send step.)

I will suggest you to try using Application Acknowledgment in send step. Also If you provide the steps of BPM then it will be more helpful.

Also have a look at this :

Asynchronous send step can raise exception only when

1. Thrown when a permanent system error occurs:

a. In the case of an asynchronous send step, the exception will only be triggered if an error occurs during the transfer to the pipeline. Errors that occur during mapping in the pipeline, do not trigger an exception.

b . In the case of a synchronous send step, the exception is also triggered by permanent system errors that occur in the pipeline or while transporting the message to or from the pipeline.

Regards

Suraj

Edited by: S.R.Suraj on Sep 8, 2009 6:41 AM

[Former Member]

Hi,

thank you very much for your additional explanations.

The steps itself I use are quite simple. There is just one block with a SendStep in between and an error handling branch.

 Asynchronous send step can raise exception only when
1. Thrown when a permanent system error occurs:
a. In the case of an asynchronous send step, the exception will only be triggered if an error occurs during the transfer to the pipeline. Errors that occur during mapping in the pipeline, do not trigger an exception. 

I think this is exactly the problem. When I request transport acknowledgements and there is a problem during pipeline processing (e.g. receiver agreement fails because XSD cannot be found) I get back a negative system acknnowledgement. However obviously this is not treated as permanent error as the message could be restarted. If I cancel the error message, then the error branch is taken as the error is permanent then. Does this make sense?

[former_member187339]

Hi

Yes your understanding is correct.

In your scenario is it possible to use Application acknowledgment? Is yes then try to use that.

Regards

Suraj

[Former Member]

As I use an AS2 receiver I do not think that application acknowledgement will work. But I will give it a try of course.

Based on the discussion and my tests I think the error handling for sending messages in BPM is not really useful if it is necessary to cancel error messages before the error branch is executed.

[Former Member]

Hello,

I just tried to run the process with an error handler around the send step.

I have not yet imported the XSD file (no administrator there today with access to the file system).

I get an error that the XSD cannot be found that is thrown by the receiver agreement. I would have assumed that this error is also then handled by the send step error handler, however this is not the case.

I just see a red flag in message monitoring, but BPM does not handle this error.

Is this correct? Is there no way to make the error handler around a "send step" handle all errors that occur within IE after sending the message?