Introduction
The other day I received an Email from fellow SDN member Eddy De Clercq asking for a suggestion with a Web Service problem. He was calling a web service and getting the following exception within SAP - CX_AI_SYSTEM_FAULT. From his partner's side, logging showed that the Web Service call was missing the SOAP Action Header. Now I had never actually encountered this particular SOAP error before. It sure sounded like an intriguing problem, so I started to do a little research.
Eddy and I both thought that information we found in addition to the resolution to the problem might be interesting to others so we decided to share it here as a weblog.
SOAP Action Header
The first action was to find out a little more details about what the SOAP Action Header even was. It turns out that the SOAP Action Header is a HTTP header that is expected to be in included in the SOAP communication. SOAP version 1.1 actually requires the SOAP Action Header. The following is a visualization of what the SOAP Action Header looks like in the context of a SOAP Communication.
As a side note, many of the articles that I read seemed to doubt the overall value of this header field. Originally it was supposed to be used so that firewalls could filter SOAP messages on an individual message basis instead upon just URL. However many sites suggest simply complying with with the standard by placing and empty string in the value.
It didn't really matter if the field was valuable or not at this point. It was required and yet it wasn't being generated. The only other possibility was that the field was actually being added to the HTTP request, but wasn't being processed correctly by the partner system. I did find an article online that said there was a bug in certain releases of Apache that needed the SOAP Action Header to be the very last Header Field.
In order to track down what was really coming out of SAP, I had Eddy turn on detailed tracing from within the SAP Transaction LPCONFIG. From within the trace we found a clue that lead us to eliminate Apache as the problem. The following was what we found:
XRFC> --------------------------------------------------------------------- XRFC> 20050602 143206 U0041098: SOAP Fault Exception caught: : no <XRFC> SOAPAction header! <XRFC> <XRFC> ---------------------------------------------------------------------In addition to the fact that the SAP logs were catching this Exception as well we could also see that it was SAP that was creating an empty SOAP Action Field:
XRFC> INFO 14:32:06: SOAP Transport Binding CL_SOAP_HTTP_TPBND_ROOT <XRFC> ->IF_SOAP_TRANSPORT_BINDING~SEND() Try to send message ( DEST = <XRFC> ,PATH = ,URL = https://procyon.cc.kuleuven.ac.be/webapps/kul <XRFC> -wssap-bb_bb60/nosession/enroll ,SOAP Action = ) <We also now new the ABAP Class that was supposed to be processing the SOAP Action Header. This class CL_SOAP_HTTP_TPBND_ROOT even had a method called SET_SOAP_ACTION. At this point we hadn't been able to find anything in the SAP Online Help or SDN on the SOAP Action Header. But we know knew that SAP had code to process this attribute. Further research showed that Microsoft .Net was very strict in its checks for the SOAP Action Header. I had done several Web Service calls to .Net Objects in the past without ever having encountered this error. Therefore we had to assume that there was some coding or configuration option that was simply missed.
The first place we decided to look as a possibility was the SAP Proxy Object Protocols. The protocols are special classes that expose methods in order to work through and with the generated proxy. The following is some code that gives an example of how to query for and get an instance of one of these Protocol objects.
The following diagram is directly from the SAP On-Line help and shows all the possible protocols. You might notice that some protocols are specific to XI Proxies and some are specific to regular ABAP Web Service Runtime.
Proxy Protocol Overview
Protocol | XI Runtime | WS Runtime |
Yes (asynchronous only) | No | |
Specifies serialization context whether acknowledgments are required |
|
|
Yes | No | |
Specifies sender/receiver |
|
|
No | Yes | |
Opens/closes a session |
|
|
Yes | No | |
Sets/reads attachments |
|
|
Yes | Yes (if configured) | |
Reads message ID of sent message |
|
|
Yes | Yes | |
Activates the enhanced XML handling when serializing/deserializing the payload. Read the payload (request, response, exception) |
|
|
No | ||
Access to particular data segments of the XI message header, such as the hoplist, and so on |
|
|
No | Yes | |
Access to additional fields of the WS SOAP message header |
|
|
At first it appeared that one of these Protocols might fit the bill. Although IF_WSPROTOCOL_WS_HEADER looked promising at first, it turns out this protocol is for the Message Header and not the SOAP Action Header. It turned out that our adventure into the area of Protocols was educational, but ultimately fruitless.
We had finally found something very promising in the On-Line Help. In the section that describes the use of the SAP Transaction LPCONFIG, there was a field called Action. It had the following description: In the SOAP Action field, you can specify a value for the SOAP action of the HTTP header (optional). Firewalls and servers can use this value to filter SOAP messages. I do find it interesting that SAP makes this field optional, while it is required by SOAP version 1.1. It seems like the Logical Port should read the version of SOAP from the WSDL definition and require this field if necessary. Perhaps it is the online sentiment questioning the value of the SOAP Action Header that lead SAP to make this field option.
We should note that the On-Line help makes it sound like this Action field is in the Call Parameters section of LPCONFIG. However it turns out it is actually in the Operations Section.
Sure enough this was the field we had been looking for. After adding a value in the field the Web Service calls completed normally. The question was, why had I never encountered this problem, yet Eddy hit it right off the bat. I looked at all the Logical Ports for Web Services in my system. All of them had SOAP Actions in the Operations section, yet I had never maintained any values for this field. It turns out SAP does pull a value for this field out of the WSDL definition for the Web Service if there is one.
In the end Eddy's problem that originally looked like something wrong with SAP's Web Service Proxies turned out to be information lacking in the partner system's WSDL Definition.
Closing
Hopefully this weblog has shown two things. First if anyone else ever runs into a problem with missing SOAP Action Headers, they now have a resource to turn to. But just as important, this weblog shows the power of SDN. It shows how two members worked together to get down to the bottom of a problem and then share that solution with the rest of the community.
2 Comments
