When we consume webservices from another system, we use the SOAP receiver adapter. Even though the configuration seems simple and is well documented in SAP Help, but when something does not work, we are still sometimes at a loss as to where to start.
This blog will attempt to go through a debugging process which has been pretty successful so far for me.
When consuming a webservice from an external systems, problems are normally caused by the following:
- Invalid or missing configuration parameters in the communication channel configuration.
- Firewall/proxy and authorization problem.
- Message/interface structure not compatible with the published webservice interface.
- The webservice on the external system has errors.
When we consume a webservice of an external application, we must have the WSDL file. This file is either given to us, or can be accessed from an URL or a registry/directory (e.g. UDDI). Download or copy the content of the WSDL into a local file, use ".wsdl" as the file type. This WSDL contains the necessary information for us to design and configure our interface scenario.
Before we start on any XI design or configuration, we SHOULD verify that the webservice does work. This can eliminate a lot of headache when trying to determine the source of the problem in the future. If the webservice does not work as advertised, then we should contact the provider. We should not proceed until the webservice problem is resolved, because we could receive a different WSDL file, resulting in interface and mapping changes.
To test the service, a SOAP client tool will be required. There are many on the internet. The one I use is soapUI from http://soapui.org, which is a free and open source desktop application for inspecting, invoking, developing, simulating/mocking and functional/load/compliance testing of web services over HTTP.
Download soapUI and install it on your computer. Create a project and load the WSDL file. Execute or test the webservice. During this process, the proper proxy and authrization parameters will also be needed. These information will be useful because they will also be needed in the communication channel configuration. So, in effect, we are using this tool to determine and verify all the configurations required in our XI configurations. Since XI is not involved during this process, we can eliminate XI as a source of any errors.
Below is a sample of the screen from soapUI: (by double-clicking on "Request 1", the test screen on the right will be shown; also note the left-lower screen which allow us to enter the userid and password to access the webservice application)
If proxy configuration is required to access the external URL, it can be entered using top menu: File -> Preferences:
When the webservice is submitted, by clicking on the green arrow, the response will be return on the right screen.
In this example, there is an error, which is in HTML format and not readable unless we viewed it using a browser. So, we can copy-n-paste the content into a local .HTML file and view it using an internet browser, which we can see an "HTTP 401 Unauthorized" error, caused by invalid userid/password.
After correcting the userid/password, I re-submitted the test and encountered another error: (this error indicated an application error, with an HTTP 500 - Internal Server Error)
Application error will not usually be shown in XI Monitor and is very difficult to determine the cause without a SOAP client test tool. For this case, we should contact the provider with the error encountered.
After the webservice application has been corrected, we can now proceed with our XI design and configuration. To minimize errors:
- In the Integration Repository, it is very important to import the WSDL as "External Definition" in "Interface Objects", and use it in designing your interfaces and mappings. Do NOT define your own datatype when using a webservice. Always use the WSDL file. When there is a problem with payload error, verify that the WSDL file is used and that it is the latest one.
- When configuring the SOAP Receiver Communication Channel:
- The "Target URL" value can be obtained from the WSDL file. Look for the attribute, "location", of the element, "address". Copy-n-paste this value, exactly as is.
- The "SOAP Action" value can also be obtained from the WSDL file. Look for the attribute, "soapAction", of the element, "operation". Some webservices has no value (blank) for soapAction, while others have more than 1. Use the soapAction appropriate to what method needs to be executed, e.g. soapAction can indicate whether a create or a delete is to be performed, so be careful.
- Select the configurations for "User Authentication" and "Proxy" as required.
The above consists of the most common configurations for a SOAP receiver communication channel. In most situations, if the webservice is verified before configuration, and the valid configuration parameters are also validated, we should have minimum problems using webservices during integration.
When error does occur, go through the above checklist and verify the configurations.
Also, when problem occurs during testing of the XI scenario, we can also copy-n-paste the payload, after mapping, into the soapUI tool, replacing the text between the and with the content of the payload (and do not include the 1st line,
6 Comments
