Sync to Sync(1) and ASync(2) Receivers

[sendhil_kumar]

Hi,

I have an existing Synchronous interface, now the requirements is to add an second receiver for which the request is to be sent and no response would be required (Async). How do I achieve this scenario.

Above figure explains the requirement, The flow between ECC and Receiver1 is existing, Now I would have to add Receiver 2 which should be Async.

Has anyone worked on this type of Scenario, please help me with any leads.

Could this be acheived by any standard modules which can supress the response from receiver 2.

Please note, we are using Java only PI.

--

Sendhil

[former_member734105]

Hi,

i have your same problem as you solved?

[Former Member]

Hi,

What about bridging. I havent done this type of bridging but it should work. Have a look at this document. You will need to add the Adapter Modules and then create a second interface that is triggered by them. But the sync call should still work.

Regards,

Jannus Botha

[iaki_vila]

Hi Sendhil,

You have some options to do it, if i understand right, PI always sends the message to the two receiver without any problem in the order of the processing.

You have these options with only one scenario:

1. To implement SYNC/ASYNC bridge.

The idea is to link in the receiver channels the two interfaces, and to sen the async call on the request or response mapping time.

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/80f96dbf-adca-3010-ffb5-daf2d1f0e...

2. To do a lookup at mapping level for the async interface. Depending the interface SAP PI offers JDBC/SOAP/RFC lookup, for other interface there are blogs to do it with UDF, like file lookup

There are more possibilities involving two scenarios or changing the interfaces.

Regards.

[former_member190284]

Hi Iñaki Vila

can u please explain the second way in a more elaborate manner?

Thanks

[aby_jose]

Hi Sendhil,

If I understand you correctly, this is just a receiver split. One sender and multiple receiver.

If this is the case, then you can achieve it by the proper configuration of 'Integrated Configuration'.

Add the extra receiver component in the 'Receiver' tab and corresponding interfaces and OM in the 'Receiver Interfaces' tab. Also add the extra channel in the outbound processing.

Sync/Async bridge or Lookups helps if there is an additional handshake. Means if the response of a sync operation is given as the input of async etc....

Thanks,

Aby

[sendhil_kumar]

Hi Iñaki Vila,

The second receiver would not send any response, and even if I manipulate the interface as per Sync Async bridge, the response from receiver 2 should not be sent to Source. Only the First receiver is expected to send the response. In this case would this be acheived thru' Sync Async Bridge. Ideally I need to send Sync message (Request) to receiver 1 and 2 and take response from receiver 1 only..

The option of look up is the one to look out as a final option, I am looking for options which would not touch the existing interface.

Please suggest.

--

Sendhil

[sendhil_kumar]

Hi Aby,

Yes, the case is One sender and two receivers, but the catch here is Sender is Sync, Receiver 1 is Sync and Receiver 2 is async.

--

Sendhil

[pvishnuvardan_reddy]

Hi Sendhil,

I think you cannot just add async receiver to the current configuration.

Since as you are saying from ECC the communication is RFC, can't you just include a code to pull the data to a file and place it in ECC AL11 directories beside the current functionality of RFC.

Then here, you can configure a file to receiver2 asyc scenario with out any issue.

With these, both interfaces runs with out any issue.

Regards

Vishnu

[former_member184720]

>>>The option of look up is the one to look out as a final option, I am looking for options which would not touch the existing interface.

You can't split a synchronous message which means you definitely have to work with the existing interface.

As already suggested by Inkai, you can write the request file on to a file system during the mapping/ write an adapter module to do the same thing.

[iaki_vila]

Hi Nunu,

You can think that you have for example a Proxy to SOAP sync scenario but in the response you can send a file with the response in secure folder.

You can do your scenario as an usual proxy to SOAP scenario but in the response you send in the mapping the file. Check this wiki http://wiki.scn.sap.com/wiki/display/XI/File+Lookup+in+UDF, obviously you would need to change the code sending the message as file and not retrieving the data as the wiki shows.

I think i used wrong the "lookup" concept, because you don't retrieve any data. But the main idea about the second point is to do manually or by standard function the async interface.

Regards.

[iaki_vila]

Hi Sendhil,

You are right the sync/async bridge doesn't solve your requirement.

You should think that you can't add an async interface to the receiver side in your ID because the scenario interfaces must be sync or async, if i put on SAP standard developer shoes with that possibility  i would lose SOA architecture concept mixing different kind of interfaces in one scenario, even the final product would be fuzzy.

If you don't want to do any java development at mapping or module level the best ways that you have are to do a BPM (this has more sense architectural speaking) or to have two scenarios to be called from your sender system.

Regards.

[sendhil_kumar]

Hi Inaki,

Thanks. I would ask my source team to have two scenarios configured.

--

Sendhil

[pvishnuvardan_reddy]

Hi Sendhil,

Can you reward points if answer has found helpful.

Regards

Vishnu

[sendhil_kumar]

Hi Hareesh,

By not touching the existing interface, I meant existing ESR objects. Ofcourse, I would have to change configuration for this to work.

Another reason for not having lookups to post the message to second receiver is the lack of monitoring. Suppose the second receiver is not able receive the request, it should not stop the data flow to first receiver, if the lookups would be configured in a way that irrespective of the availablity of the second system the message would processed to first receiver, then monitoring them would become cumbersome. Do we have any ways to monitor the interface if called within udf?

--

Sendhil

[former_member184720]

>>>Do we have any ways to monitor the interface if called within udf?

How about soap lookup? Call the soap sender URL(create another interface in PI soap -> second receiver) from the UDF to send the message.

That way you can even monitor the second interface?

[pvishnuvardan_reddy]

Hi Sendhil,

Can you let us know which type of communication you are using between ECC & PI, is it proxy or IDOC or RFC?

Regards

Vishnu

[sendhil_kumar]

Vishnu,

It is RFC.

[former_member190284]

Hi Sendhil

I guess in that case you have to make another SI and thereby another OM.

same OM you can use in the another communication channel which you will make for another receiver.

[sendhil_kumar]

Hi Nunu,

I did try that, I am getting an Error, unable to split a synchronous message. Any other leads.

--

Sendhil