Need your suggestions: Closing sync-async bridge with custom response in sender channel

[former_member190293]

Dear Experts!

I have a requirement to send back response message to sender system in adapter sync-async bridge without waiting for receiver system response from async outbound interface. It's just some kind of technical response which indicates that message has been put to PI messaging system for further processing in asynchronous mode.

At this moment I'm able to send response back to sender system using custom adapter module in sender channel. For now it's just a "proof-of-concept".

Before moving further with my custom module development I'd want to ask if this concept is appropriate from the point of PI "good practices".

Waiting for your suggestions.

Regards, Evgeniy.

[former_member194786 · Accepted solution]

Hi Evgeniy,

So, the caller doesn't need a response from the receiver system at all? If so, what is the point of sync-async bridge? Why not make it asynchronous and ask the calling system to use the HTTP acknowledgement as response.

Or, is it that they need multiple responses, as in application and system acknowledgement?

Irrespective of above questions, I would suggest to consider the volume of interface as a consideration point as well. Imagine receiving thousands of SOAP or HTTP calls and each one trying to send back the acknowledgement for each call. However, if it is a low volume scenario, I wouldn't be worried too much about that aspect.

Regards,

Sanjeev.

[former_member190293 · Accepted solution]

Hi Sanjeev!

Thanks for your response.

Scenario is SOAP(Sync)-PI-IDoc(multiple ones of different types).

Consumer system calls PI in synchronous mode with request containing set of documents. For each of these documents one or more IDocs are created at ERP side. So ERP can't send response for each posted IDoc to one SOAP sender.

Another option I think of is to set EO mode in SOAP sender channel so it will send empty SOAP response back  to sender.

Regards, Evgeniy.

[former_member186851 · Accepted solution]

Hello Eve,

In case if you don't require any text in response and for responses only whether message has reached PI successful EO option you mentioned should be good,You will empty response like the one we get in SOAP UI.

but I would suggest you do a POC before confirming the same as I never tried getting a response back using EO.

[former_member190293 · Accepted solution]

One thing: sender system developers use received documents count as response to build their application logic for data transfer and they don't like any changes in that logic .

Regards, Evgeniy.

[former_member186851 · Accepted solution]

Eve,

You can try IDOC Acknowledgements also,see if it helps

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/903a0abc-e56e-2910-51a8-9dc616df5...

[former_member182412 · Accepted solution]

Hi Evgeniy,

In your adapter module you receive synchronous message, after you send the response to the sender with their expected response if you close the synchronous bridge and send the message to messaging system asynchronously then this approach will be good because we are doing same like sync-async bridge modules like RequestResponseBean only difference the standard modules will close the bridge after we get the response from the receiver but we are closing with in sender adapter.

Regards,

Praveen.

[former_member190293 · Accepted solution]

Hi Praveen!

It's exactly what I want to do. Now I can send custom response back to sender using XSL transformation for source message. I've checked out: if message fails during further processing I'm able to fix the problem and restart the message. And the sender doesn't get any errors in this case.

By the way, I've just simulated NotifyResponseBean's behavour with some changes in my module.

One problem, that makes me worry, is that I have to use my module before standard SAP module since I have no possibility to use it after standard module in asynchronous processing (actualy I can but I can't get access to message payload).

Regards, Evgeniy.