ICO with multiple receivers and adapter engines

[markbernabe]

Hi Experts,

My scenario is that we have to send an IDOC from ERP to 2 receivers. The catch is that, the 2 receivers are using  different adapter engines, one is central, the other is non-central. As you may know, this is not possible in 1 ICO since the adapter engines of the receiver channels are different. I also can't create 2 ICOs since I'm using the same sender system and sender IDOC interface.

Has anyone encountered a similar situation before? Appreciate any inputs.

Thanks in advance.

Mark

[former_member184720 · Accepted solution]

Either move the other channel to central AE

or

Drop the file at a temporary work space and then create a second ICo which would pick the file from temp space to actual receiver.

1. IDOC -> PI -> Receiver 1 ( two inbound interfaces - One actual and other points to temp location)
2. File(Temp location) -> PI -> receiver B ( pass through/no mapping)

[markbernabe]

Hi Eng Swee, Hareesh,

I got it to work. I've created 2 ICOs as per note 1977420. The receiver channel's Target URL follows the format http(s)://<host>:<port>/XISOAPAdapter/MessageServlet?ximessage=true

Thank you both for the very helpful insights!

BR Mark

[former_member184720]

Yes.. Usage of SOAP adapter makes it ream time. Thanks for updating the thread.

You might want to close the thread -

[engswee]

Great! Didn't know the two ICO approach was also SAP's official stand for separate adapter engines. Good to know about that SAP Note.

[Chandra_Hota]

Hi Mark,

I am in a similar situation.

I created 1st ICO with file sender and SOAP receiver(target URL in the format you gave above) .

I want the 1st ICO to trigger the 2nd ICO (SOAP sender and SFTP receiver).

I am currently getting a HTTP 500 error message on 1st ICO and 2nd ICO is not even getting triggered.

Is the target URL you gave above sufficient to trigger 2nd ICO? How will it know which interface/ICO to trigger?

What is the link between both these ICOs?

Thanks

Chandra

[markbernabe]

Hi Chandra,

Did you select Virtual Receiver on the 2nd ICO?

The 2 ICOs have the same sender component and interface as well as receiver (via the Virtual Reeiver). That would be the link.

[Chandra_Hota]

Hi Mark,

I did not use virtual receiver for 2nd ICO.

I can try that but, looks like the 1st ICO has a virtual receiver (logically), as it is not an actual receiver, and is triggering 2nd ICO.

Can you pls confirm if 2nd ICO should have virtual receiver specified, as it has the actual interface target as the receiver?

Also, can you please tell me the SOAP receiver target URL?

Many Thanks for your reply.

Regards,

Chandra

[Former Member]

Hi Chandra,

May I know the exact requirement, I mean what you want two ICO's for and if you want the first ICO only to trigger the second ICO then in that case, I guess, it is possible to use a file adapter in the second ICO for triggering.

Can you please explain you scenario, if possible.

Thanks,

Prajwal

[engswee]

Chandra

The solution for Mark's issue is only applicable for you if the SOAP receiver of your first ICO and the SOAP sender of your second ICO are on different PI system or Adapter Engines.

If both channels are on the same system, you cannot use SOAP with XI 3.0 protocol. You need to use SOAP 1.1 protocol instead. My document below covers some part of connecting SOAP to SOAP in a loopback manner.

If that still does not help you resolve your issue, I'd suggest you open a new thread and provide your configuration screenshots and error screenshots.

Rgds

Eng Swee

[markbernabe]

Hi Chandra,

I've used virtual receiver on the 2nd ICO and I've also put the mapping on the 2nd ICO.  So basically, the 1st ICO is only for routing. This is the target URL of the Receiver SOAP used by the 1st ICO.

http(s)://<host>:<port>/XISOAPAdapter/MessageServlet?ximessage=true

The Sender SOAP uses XI protocol btw.

[Chandra_Hota]

HI Eng Swee,

In my scenario, both my ICOs are on different adapter engines (central and non central).

Regards

Chandra

[Chandra_Hota]

Thanks Mark.

I have made these changes, but I am still getting HTTP 500 error on 1st ICO SOAP receiver comm channel, and 2nd ICO is not getting triggered. I will explain further with screenshots. Please let me know if you see anything wrong.

1st ICO (on central adapter engine):

File sender picks the file. No FCC here. So, file content is in raw format (which is what we want)

It is sent to SOAP receiver. In the target URL, I am giving the host name of the Non Central adapter engine. Because, the 2nd ICO (both the channels in this ICO) is on the non central adapter engine. Is this correct?

2nd ICO uses same sender component, sender interface & receiver component as 1st ICO. Also, 2nd ICO has receiver component as virtual receiver. 2nd ICO has SOAP receiver with XI3.0 message protocol, and the adapter engine for this SOAP sender is Non central adapter engine:

with the above config, i am getting the following error on 1st ICO SOAP receiver channel, and 2nd ICO is not getting triggered:

Any help/pointers is appreciated.

Thanks,

Chandra

[markbernabe]

Hi Chandra,

The message protocol of your Receiver SOAP for 1st ICO must be XI 3.0 as well.

[Chandra_Hota]

Changed message protocol of both SOAP receiver in 1st ICO and SOAP sender on 2nd ICO to XI3.0

Still getting same error, now with additional parsing error.

I am trying to read a file from 1st ICO (no FCC. So, it would stay in the same raw format without getting converted into XML in the payload), and write the same file to destination in 2nd ICO.

Previously when using SOAP1.1 as message protocol in SOAP receiver in 1st ICO, I was specifying 'Do Not use SOAP envelop' to specify that the payload is not XML and is plain test. Now with XI3.0 message protocol, I dont even that that option. Looks like this is the cause of the parsing issue.

And I am unable to understand why we are getting HTTP 500 error. Non Central adapter is up and running, and when i try to use the Target URL in browser, after giving user and password, I can see 'Message servelet OK' message.

Any pointers appreciated.

Thanks

Chandra

[markbernabe]

Hi Chandra,

Can you do the FCC in the 1st ICO so you'll be sending the XML message already to the 2nd ICO?

[markbernabe]

Hi Eng Swee,

I guess it's the same thing that is explained in note 1977420 right? Just didn't say much about the details needed in the receiver SOAP XI channel (i.e. correct Addressing Type, Target URL, path prefix, etc.).

BR Mark

[engswee]

Hi Mark

Under certain scenarios, it is possible to create more than 1 ICO for the same sender and IDoc interface, with the use of virtual receiver.

Do you know how the partner profile for the IDoc is configured in the sender ERP system for the two scenarios? In particular, do you know if it is using type Customer (KU), or Logical System (LS)?

Do check out the following thread, it's a long one but it should be useful.

If at least one of the interface is using non-LS IDoc (or possible to change it to such), it should be possible to use the solution in the thread. From your post, since you are using a DAE, I'm actually guessing that one of the interface goes to a receiver that is outside your organization.

Rgds

Eng Swee

[markbernabe]

Hi Eng Swee,

Thanks as always for the feedback. Both are using logical system LS. And I'm afraid neither of them can be changed to non - LS. In that case, is still possible to follow your very nice solution? Or shall we opt for enhanced receiver determination?

Yes you're right. The other system is actually C4C on public cloud network.

Thanks and Regards,

Mark

[engswee]

Hi Mark

If both are LS then you can't use virtual receiver in the ICO

I'm not sure if Enhanced Receiver Determination will work in your case with one interface on DAE. I don't have a DAE in my landscape to test this out - maybe you can try and let us know if it works or not

If it doesn't, Hareesh's suggestion on using two ICOs seems to be the way forward. Just to add on to that, if you don't want to store the payload in a temporary file location, you can opt to forward the payload from the first ICO to the second ICO via SOAP instead.

Rgds

Eng Swee