cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

SAP CPI - process direct adapter - Async mode - Fire and forget

6,127

Hi Experts,

I have been working on a requirement where I need to call another iFlow from a parent iflow. I want to use process direct adapter for the requirement. However, process direct doesnt work in fire and forget mode. I want to transfer the data to the second iflow but dont want to get the error back to parent iflow.

Something similar to what we can do with SOAP adapter (async mode), is that possible with Process direct adapter ?

Accepted Solutions (0)

Answers (5)

Answers (5)

jayesh2203
Explorer
0 Likes

I think I have found the solution for this, you can use Escalation end in exception subprocess. This will make sure you achieve below 3 things which you wanted.

- Parent/Caller iflow will be marked as 'Completed' even though there is an error occurred in child iflow.

- Child iflow will be marked as 'Escalated' in case error occurred in the child iflow and you will get to see the error in message monitoring.

- Yo can still use Process direct adapter for your both the integrations.

I have implemented this in our integrations. PFB screenshots for your reference.

jayesh2203_0-1740982978967.png

jayesh2203_1-1740983056539.png

 

Hopefully this helps.

Regards,

Jayesh

 

 

MatthiasFricke
Participant
0 Likes

Hello,

I just stumble over the same issue.

The more I think about it the more I find it a good idea to use JMS to send data from one flow to another in a fire and forget scenario.

JMS is perfectly suited for async communication, and you can even send raw data without having to hassle about wrapping it all in some xml/soap envelope, nor do you need to care about wsdl and authentication.

Any thoughts on this?

Best

Matthias

n_rvsavinashvarma
Participant
0 Likes

Hi All,

I have the same issue.Does anyone found the solution ?

My first iflow is also throwing error as the second iflow is failed.

Kindly assist.

Thanks,

Avinash

r_herrmann
Active Contributor
0 Likes

If it's just about the errors and you are fine with getting back a non error, you could try to add an exception subprocess in the second/called iflow. In side the exception subprocess handle the error and replace the end error event with an regular end message event.

0 Likes

Problem is that if I want to complete the first iflow without worrying about the second iflow. If there is a problem in the second iflow, I have retrigger / resend logic in the second iflow. So the second iflow should still fail if there is a problem but it should not communicate back to the first one.

If I insert exception handling and use error event with end message event, two things happening -

1. Either parent and child both are in error.

2. Or parent and child both are successful.

That's why I wanted to trigger the message in 'Async' mode so that child iflow has no connection with parent iflow. I have achieved this aysnc mode communication using SOAP adpater with parameter 'Processing Setting' = WS Standard.

r_herrmann
Active Contributor
0 Likes

Ok, now I got it. I see three (more or less practical) solutions.

  1. Add an exception subprocess to the calling/first IFlow. In case an error happens in the second/called IFlow the first flow will still be "successful". Unfortunately in that case, even an error in the first flow would show up as successful.
  2. To avoid the problems from solution one, you could add some kind of routing logic in the exception subprocess. In case the error occured inside the first flow, it should be thrown. In case the error occured in the second flow, it should be ignored. Unfortunately this isn't really easy/practical. One idea would be to parse/regex the exception in the subprocess and check if it contains an exchange id. Then try to get hold of the first IFlows message processing log and check if it contains the Exchange ID (not message id!) from the exception. In case the exception contained an exchange id, which isn't part of the current flows message processing log, it's likely to be an exception thrown by the second flow. But this is more a "brute force" than a practical approach.
  3. The third option might be to decouple the first and second IFlow, by using JMS+queues instead of the process direct adapter.

Thanks Raffael for the heads up.

I have now shifted to SOAP Async processing where I am calling the second iflow using SOAP adapter (using processing setting = 'WS Standard'), so that I am not waiting for second iflow response. It gives me the liberty to carry on with first iflow without worrying for second iflow.

I think someday SAP would think about it and we would be able to call process direct in async mode.

Thanks,

Ravi.

Sriprasadsbhat
Active Contributor
0 Likes

Hello Ravi,

Process direct adapter is synchronous so its not possible to configure in fire&forget mode.

Below blog gives all the possible option with Process Direct adapter.

https://blogs.sap.com/2018/02/14/processdirect-adapter/

Regards,

Sriprasad Shivaram Bhat

0 Likes

Hi Sriprasad,

Thanks for the link. I have already seen it but thought of asking if someone had some workaround. Seems there is none.

Thanks,

Ravi.