Moving scenario to ICO from classical

[PS23]

hi

As a pre-task to PI (7.31) upgrade we are moving classical (soap to idoc) scenario to java stack .

For which new ICO with different adapters(java based) are created.

Inorder to test one setup (classica or JAVA only) at a time we are disabling adapters of classical to test ICO and vice-versa.

BUt in all the cases only java setup gets triggered. Classical doesn't, even when adapters in ICO are disabled.

CAn anyone give some idea what could be wrong.

Thanks

[iaki_vila · Accepted solution]

Hi,

I had problems having the two kind of configurations active, i think you should change the sender communication channel to do classical or ICO test for your SOAP-IDOC scenarios, therefore you shouldn't set inactive anything.

Regards.

[former_member186851 · Accepted solution]

Inaki a small doubt,Soap channel doesn't need a change right.It is same for Dual and single stack expect the version change.

[iaki_vila · Accepted solution]

Hi Raghu,

The SOAP channel is the same as you said, i didn't explain right, if i want to test the same scenario with two different configurations, i need to have to have the entry point different in order to assure the PI knows what configuration to take.

Regards.

[former_member182412 · Accepted solution]

Hi Inaki,

Changing the soap sender channel will not change the endpoint for the interface because endpoint is dependent on Sender Party, Sender Component, Sender Interface, Receiver Party, Receiver Communication Component but not the communication channel.

The only way to differentiate is change one of the key fields by creating virtual receiver for the same interface like below. This will give you different endpoint for the same interface and we can test both scenario's.

Regards,

Praveen.

[bhavesh_kantilal · Accepted solution]

Hello Praveen,

There are 2 URLs supported by the SOAP Sender Channels,

http:// <host name> : <port name> /XISOAPAdapter/MessageServlet?channel= <party name> : <service name> : <channel name> . If you have not created a party, enter channel=: <service name> : <channel name> 
http:// <host name> : <port name> /XISOAPAdapter/MessageServlet?senderParty= <name of the sender party> &senderService= <name of the sender service> &interface= <name of the interface> &receiverParty= <name of the receiver party> &receiverService= <name of the receiver service> &interfaceNamespace= <name of the interface namespace> 

So, yes if the 2nd URL is being used, what you suggest makes absolute sense while if the URL being used is the URL that uses the communication channel name, then the Sender Channel has to be assigned to either a Sender Agreement or to a ICO.

In Summary - to the PI User who raised this question : What URL are you using to test the Interface?

Regards,

Bhavesh

[PS23 · Accepted solution]

HI Bhavesh

Yes URL2 is used.

[bhavesh_kantilal · Accepted solution]

If URL2 is used, you need to do what Praveen has pointed out,i.e, set up a Virtual Receiver Service  Basically, the URL does not have any info on the Sender Channel and hence the ICO will be triggered. Praveen has explained this pretty well..

If you want to switch between both ICO and Classical without adding any Virtual Receivers, URL 1 has to be used! I would recommend URL#1 as that way this is a pure as-is migration with no changes!

Regards

Bhavesh

[former_member182412 · Accepted solution]

Thanks Bhavesh,

I did not think about first URL because after XI 3.0 i am not using that URL any more because SAP recommends second URL only.Configuring the Sender SOAP Adapter - Advanced Adapter Engine - SAP Library

You have configured the SOAP sender adapter. You can trigger a call to the sender SOAP adapter using either of the following URLs. However, SAP recommends you to use the second option.

http:// <host name> : <port name> /XISOAPAdapter/MessageServlet?channel=<party name> : <service name> : <channel name> . If you have not created a party, enterchannel=: <service name> : <channel name>
http:// <host name> : <port name> /XISOAPAdapter/MessageServlet?senderParty= <name of the sender party> &senderService= <name of the sender service> &interface= <name of the interface> &receiverParty= <name of the receiver party> &receiverService= <name of the receiver service>&interfaceNamespace= <name of the interface namespace>

Regards,

Praveen.

[former_member182412 · Accepted solution]

Hi

• First of all system wont allow you to create the ICO when the sender agreement is activate in the system for same interface key fields. When i try to create the ICO, system does not allow me to create when the sender agreement exist for same interface.     

If the third party already using the second URL then if you use first URL then third party needs to change the existing URL. So you have three options.

• If you want test your self using soap ui to test ICO is working or not then create a virtual receiver as i explained before and get the new URL and test the interface in soap ui.
• If the third party can able to change the existing URL then also give the virtual receiver URL to them to test this interface both cases you can have both interfaces you can test, you no need to change anything in PI, only URL change in third party side, generally their side also configuration change not the code change.
• If third party dont want to change the existing URL then just delete the sender agreement and create ICO for the same interface and test the interface using same URL.

Regards,

Praveen.

[PS23 · Accepted solution]

Hi Praveen

I have classical and ICO  setup in ID and I tried testing using soap ui using url1.

I have 2 soap sender and 2 idoc receiver ( idoc classical receiver and idoc AAE receiver).

URL1 : As I am using url2 I am using separate sender soap channel to test.

But am testing using soap UI in non -citrix desktop than on citrix , and getting java.net.UnknownHOstException error.

Am I going correct.

Thanks

[PS23 · Accepted solution]

hi

We access PI using citrix whereas am testing using soap ui in my non-citrix desktop.

Do we need to test from citrix desktop, i.e, soapUI has to be there on citrix desktop?

If tested from non-citrix desktop, will it not bypass and execute?

Now I have

1.classical setup

2.ICO with virtual receiver as receiver

And testing using url 1, the url as per channel name(different for ICO and classical) identify which scenario to execute.

Is It correct?

Thanks

[former_member186851 · Accepted solution]

Hello SAP PI,

The best way to get URL will be select Display WSDL from Sender agreement in case of Classical and From ICO in case of Integrated Scenario.

Or you can simply copy the WSDL URL and use the same in SOAP UI ,End point will come automatically.

[PS23 · Accepted solution]

HI Raghuraman

Getting the url isn't a problem, but I m testing using soap ui which is not on my citrix desktop .As  PI is accessed via citrix.

I am not sure if my understanding and approach is correct r not for following:

1.  Testing from soap ui from non-citrix desktop is leading to this Unknownhost exception error.

2. Also as per the primary discussion of testing ICO and classical at the sametime , my approach/understanding now opted as per Praveen is correct or not .

Thanks

[bhavesh_kantilal · Accepted solution]

We still use the Older URL and it works like a charm. FYI.

• On XI 3.0 and PI 7.0, a Sender Agreement was not mandatory on SOAP Sender Adapter. Reason was SOAP Sender Adapter had fields for Sender Interface and Interface NS.
• So, when a message was sent to the URL Using the SOAP Sender URL that points to the channel, the Interface details were read from these fields and pushed over to the Integration Engine.
• From PI 7.1 onward, these 2 fields were no more present in the SOAP Sender adapter. Hence, it became mandatory to have a Sender Agreement for the SOAP Sender Channels.
• When we did our inline upgrade to XI 3.0 to PI 7.0, as long as we continued to use SAP Basis 6.40 metadata in the channels, we did not have to create a Sender Agreement, once we changed it to Basis 7.30 we had to make sure a Sender Agreement exists.

Hope this tidbit also helps!

Regards

Bhavesh

[bhavesh_kantilal · Accepted solution]

Citrix demands all your servers and test tools are within Citrix.

So yes, SOAP UI will not work from your local desktop.

You either need to use the SOAP UI on a Remote Desktop in Citrix or you need to use WSNavigator.

Go to http://pihost:port/wsnavigator and from there,

• Select WSDL
• Provider your WSDL URL from SOAP Sender Channel
• Provide your credentials and data and test the same.

[PS23 · Accepted solution]

Hi Bhavesh

I did try as suggested , gives the attach error.

[bhavesh_kantilal · Accepted solution]

The WSNavigator is probably not able to connect to the WSDL URL you are providing. The error received says , HTML Response receieved.

What is the URL you are providing? If it contains the hostname, can you change it to the fully qualified hostname or IP address?

[PS23]

Thanks Everyone for replies,

Testing as virtual receiver helped.

Thanks

[bhavesh_kantilal]

What do you mean by disabling the adapter? You need to make sure the sender adapter for your scenario  is either assigned to the sender agreement for classical scenarios or to your Integrated configuration for your single stack scenarios.

Also what is sending system and adapter?

[PS23]

HI Bhavesh

Thanks for the reply.

Sending system is third party and receiver in R3. I have created 2 soap and 2 idoc receiver for classical and ICO respectively.

Disabling mean I make channel inactive , if testing classical I make ICO channels inactive and vice-versa.

Thanks

[bhavesh_kantilal]

So in that case, what is the URL being used by the 3rd Party to trigger the message?

If they are using the URL to point to the ICO, the message will go to the ICO.

If you want to distinguish between the ICO and Classical Configuration, the URL needs to be of format -

• http:// <host name> : <port name> /XISOAPAdapter/MessageServlet?senderParty= <name of the sender party> &senderService= <name of the sender service> &interface= <name of the interface> &receiverParty= <name of the receiver party> &receiverService= <name of the receiver service> &interfaceNamespace= <name of the interface namespace>

[former_member182412]

Hi

When you call the PI hosted web service you will provide sender system, sender interface and sender namespace in the endpoint URL, when this call come to PI system will search for interface with these key fields in CPA Cache because you did not delete the classical configuration, you keep both classical and ICO in the system for the same key combinations so both entries will be there in the CPA Cache and system is taking the first entry which is classical scenario always, it is not dependent on channel inactive whether is active or inactive the entry will present in CPA cache, so only when you remove from the CPA cache then it will work.

When you create ICO are you giving any difference in the above key fields?? if not create the ICO with virtual receiver and get the WSDL from ICO and test the interface with new endpoint URL for testing the ICO, get the WSDL URL from sender agreement and test the interface for classical scenario.

Regards,

Praveen.

[PS23]

HI Praveen

I have configured as suggested:

Classical and ICO have same sender/Interface/Namespace /only adapters have different name:

1.classical scenario has different URL (from display url)

2.ICO has different URL (from ICO)

tested using soap ui from non-citrix desktop , I get an unknownHOst Exception error, which is possibly due to soap ui test not done from citrix as it is unable to identify host.

Is it correct.

if yes, any other way out to test the above setup. As suggested in other threads can wsnavigator be used .

thanks

[former_member182412]

Hi

• Can you able to ping pihost from your laptop?? maintain pihost and IP address in the hosts file in your laptop.
• Alternatively you can send the test message from NWA->SOA->Monitoring->Send Test Message

Regards,

Praveen.