cancel
Showing results for 
Search instead for 
Did you mean: 

Testing XI SOAP scenario via XMLSpy

Former Member
0 Kudos

I've completed the following -

1. Created the scenario SOAP => XI => RFC

2. Using XI config, generated WSDL specifying the Message Interface which triggers the scenario in XI.

http://<serverhost>:<port>/XISOAPAdapter/MessageServlet?channel=<party>:<ServiceName>:<Channel Name>

3. Transported this WSDL to local directory

4. Testing WebService by sending a SOAP message using XMLSpy. Option Soap=>Send request to Server.

I don't see any pop-up to enter xiappluser and password .

I get the following popup error message

HTTP error: could not POST file

'/XISOAPAdapter/MessageServlet?channel=:HTTP_LINK:testSoap&amp;version=3.0&amp;

Sender.Service=HTTP_LINK&amp;Interface=urn%3Agoodyear.com%3AInfoLinkToSAP%5EInfoLink_XML_Req_Sync_Abs' on server 'xi0.goodyear.com' (404).

Please let me know if there is anyway to resolve this error condition.

Thank you.

Accepted Solutions (0)

Answers (3)

Answers (3)

Former Member
0 Kudos

Hey guys,

I would like to bring up again Ivan’s problem.

I have a similar problem trying to call a web service (Get HTTP 404 – Not found error), so following the history of this thread and looking at the component info of my system (http://host:50000/sap/monitoring/ComponentInfo), I realized that we have inconsistencies between XI components as shown below:

SAP_JTECHS 6.40 SP9 (1000.6.40.9.0.20041119045630) SAP AG SAP AG 20041122132741

SAP_JTECHF 6.40 SP9 (1000.6.40.9.0.20041119045516) SAP AG SAP AG 20041122132734

SAP-JEE 6.40 SP19 (1000.6.40.19.0.20061027073233) SAP AG SAP AG 20070123165511

SAP-JEECOR 6.40 SP19 (1000.6.40.19.0.20061027073059) SAP AG SAP AG 20070123174423

SAP_XITOOL 3.0 SP9 (1000.3.0.9.0.20041026233717) SAP AG SAP AG 20060807094410

SAP-XIAFC 3.0 SP10 (1000.3.0.10.0.20050105210706) SAP AG SAP AG 20070123114427

SAP_XIAF 3.0 SP10 (1000.3.0.10.1.20050201060356) SAP AG SAP AG 20070123180856

As you may see the system comes from SP9 to SP19. Using the SDM tool to check SP level, I discovered that all components appear with SP19.

Does any one know how to correct this discrepancy between Component Info page and SDM tool?

Any idea would be helpful.

Thanks and cheers,

Mauricio

Former Member
0 Kudos

Hi Parimala,

Before going for third party tools like XML Spy, you can test ur Scenario in XI itself.

Test your Adapter Engine from "Runtime Work Bench".

Follow the steps for testing the SOAP Adapter from XI.

Step 1 :- Component Monitoring--> Click Adapter Engine.

Step 2 :- Select the "Test Message" Tab

Step 3 :- Give details for send to = http://host:port/XISOAPAdapter/MessageServlet?channel=:<service>:<channel>; ,interface name, service, namespace

Step 4 : Provide the <b>user name</b> & <b>passowrd</b>

Step 5 :- Payload should be Soap Request. and click "send message".

Check the result in SXMB_MONI.

Note : You can create SOAP Request from WSDL using the following tool.

http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=65a1d4ea-0f7a-41bd-8494-e916e...

Regards,

Rakesh.

Former Member
0 Kudos

Hi Parimala -

First, can you access your MessageServlet URL via a browser?

http://<serverhost>:<port>/XISOAPAdapter/MessageServlet

You should get:

"Message Servlet is in Status OK

Status information:

...

..."

Jin

Former Member
0 Kudos

Jin,

Thanks for a quick response. I tried and I get Message Servet is in status ok. I was able to get a bit ahead by going thro' oss note 856597. I now get -

SOAP: call failed: com.sap.aii.af.ra.ms.api.MessageExpiredException: Message 58329a90-9d8a-11da-9e69-00306e4b43ce(OUTBOUND) expired

This is in adapter messaging tool. I see an entry in sxmb_moni but with no return code.

I very much appreciate any help. Thanks.

Former Member
0 Kudos

Hi Parimala -

Does your request take a while to process? The MessageExpiredException can get thrown if a timeout occurs while the messaging system is waiting for a response.

Don't know if your using RFC adapter on the receiver end, but check Note 730870 (Q.14) and, maybe more relevant, Note 791379 (regarding service 'SAP XI Adapter: XI' service, property 'xiadapter.inbound.timeout.default').

Regards,

Jin

Former Member
0 Kudos

Jin,

This is happening on the Sender side. In the messaging tool, the SOAP adapter is failing with MessageExpired. Before I put SOAP, I used HTTP and my RFC was working fine. I don't think its RFC.

Its not even getting to the BPM, its failing in AENGINE.

Any ideas.

thanks,

Pam

Former Member
0 Kudos

Hi Pam -

Then it seems that the error your getting (MessageExpired) in the adapter engine monitoring may be masking the real problem. Are there any more details in the audit log of the message monitoring before the MessageExpired exception? Can you get into the Visual Admin tool (or stand-alone log viewer) to look at the default and xi trace - maybe more details there.

Since it's not even reaching the Integration Engine, you still have problems the SOAP client call via XMLSpy and/or with the sender soap adapter configuration settings. I've never used XMLSpy as a SOAP client so can't provide any feedback there. Do you have another SOAP client to use, like SOAPScope to compare results perhaps?

You mentioned that you weren't able to specify user id/pwd when sending a request via XMLSpy - but a user/pwd is required by default. Maybe someone who has used XMLSpy as a soap client can provide some help in setting up the authentication using XMLSpy.

Regards,

Jin

Former Member
0 Kudos

Thanks Jin for the input. I'm still getting the same error.

Now I'm trying SAP SOAP client and I have few questions on this. Doesn't seem like SOAP is an easy thing to setup compared to HTTP service. I'll start another thread on SAP SOAP client.

Using this link - https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/9b16d790-0201-0010-4e9b-baa...

I would still like to know if I'm missing anything testing SOAP client using XMLSpy.

Thanks. Parimala

Former Member
0 Kudos

Hi Parimala -

I think it's a good idea to try a different client tool to at least find out if the issue is tool specific.

>>><i>I would still like to know if I'm missing anything testing SOAP client using XMLSpy.</i>

Many on this forum have used XMLSpy to send the request so I'm surprised you're not getting more help here.

Thanks.

Jin

Former Member
0 Kudos

I was able to resolve this. I had to change a bunch of things.....a very good learning experience.

Former Member
0 Kudos

Hi Parimala -

That's great! Perhaps you can share some highlights on what you needed to do that the forum can benefit from.

Best regards,

Jin

Former Member
0 Kudos

Jin,

1. I had to enter BE and not EO in the communication channel

2. The WSDL created by IB using 'define webservice...' created the reply part and not the request part....not sure why. I tried several times. We are SP14 not sure if this has anything to do with it.

3. We went through the step below in Visual Admin and the first time the system hung and rebooted things seemed to work ok.

Step 1 is the last thing I changed..

Not sure if the cache had anything to do with all of this. SXI_CACHE show 0 return code at all times.

The adapter's servlet is protected by default. You must use one of the user names assigned in security role xi_adapter_soap_message for component XISOAPAdapter. Please consult the documentation for Visual Administrator to view and change the security setting.

            The user authentication of the SOAP adapter is not part of the SOAP adapter but of the web container of the J2EE engine. The default authentication setting is defined in the web.xml descriptor file of the SOAP dapter web application. This setting may be modified from Visual Administrator with some restriction. Please refer to the security documentation for the J2EE engine.

Former Member
0 Kudos

Hi Parimala,

Could you please elaborate the third step ?

<i> The user authentication of the SOAP adapter is not part of the SOAP adapter but of the web container of the J2EE engine. The default authentication setting is defined in the web.xml descriptor file of the SOAP dapter web application. This setting may be modified from Visual Administrator with some restriction. Please refer to the security documentation for the J2EE engine.</i>

Former Member
0 Kudos

Hi, Jin Shin, hi people!

I have the same problem, but

I can´t access my MessageServlet URL via a browser

. (In fact, I have accessed that in past. This problem apparentily begins to happen after we update the XI packages to SP17).
Please, kindly tell me what are the next steps or checks I have to do. See also this other post where I put other information:

Thanks!

Message was edited by: Ivan Garcia

Former Member
0 Kudos

Hi Raks, hi people,

I tested the Adapter Engine not using XML Spy, as you suggested. The error in Adapter Monitoring when sending a message in the "Test Message" tab was:

Error when sending message: 500 Internal Server Error


In "Component Monitoring" -> "Adapter Engine" -> "Comunnication Channel Monitoring" I see the error message

call failed

. Clicking in the details, it shows:


Message Data

Attribute Value

Status: Canceled with Errors

Repeatable: No

Cancelable: No

Error Category: XI_J2EE_ADAPTER_XI_HANDLER

Error Code: CALL_CONSUMER_ERROR

I point out that can´t access my MessageServlet URL via a browser.

former_member189324
Contributor
0 Kudos

Hi Ivan,

Error seems to be more related to the Adapter Communication in the J2ee engine. The message Servlrt link works fine with NW04-SPS17.

Check the j2ee threads are not maxed out and also check the j2ee file system logs/traces for more detail errors.

Thanks

Prasad

Former Member
0 Kudos

Hi Prasad, thank you.

Niall Guerin wrote me a message in which he explained that some of my XI components are inconsistently patched. I will verify and correct that.

Thanks again.

Ivan

<i>Hi Ivan,

Thanks for the patch level information above. Your components are not

up to date.

As you can see the following XI AFW components are inconsistently

patched:

sap.com SAP-XIAFC 3.0 SP12

sap.com SAP_XIAF 3.0 SP17

ALL XI components MUST be on the same patch level. This means:

XIAFC, XIAF, and XITOOLS must all be on SP17. The same goes for the

ABAP stack. Basis must be on SP17 and so must your J2EE Engine. With

XI, ALL patch levels must be consistent as a prerequisite. Please

refer to attached note: 750511.

In addition, it looks like you've got a PCK deployed on the XI host

as well? A PCK cannot co-exist with an XI installation, so please

ensure you did not do this and undeploy it if it was installed on top

of the XI host.

Please patch the XI Java components correctly and then reproduce the

SOAP Adapter problem after sending a soap request to the adapter.

For more information on the message status in your screenshot, refer

to the weblink below. This is an enhancement with SPS17 for the Runtime

Workbench:

Communication Channel Monitor

http://help.sap.com/saphelp_nw04/helpdata/en/44/2a1a8620323f0ee10000000a114a6b/content.htm

Kind Regards,

Niall Guerin</i>