Attributes go missing when creating SOAP header using SET-NODE / ADD-HEADER-ENTRY

[Phil Dunn]

Hi there

I’m in the process of trying to communicate with a web service that requires a user login.

The login information has to be passed as part of the SOAP Header of the message when the Login method of the web service is called.

So after connecting successfully to the web service I’ve set a callback procedure on the web service that builds the XML for the SOAP request header.

When I’m building the SOAP header elements I output the XML I’ve built to a file to check that I’ve built it correctly (with all the correct elements and attributes). I'm using the usual X-DOCUMENT / X-NODEREF objects to buid the XML manually.

I’ve run the code and trapped the XML that is being passed to the web service by using a network analyzer program called Ethereal.

What I’ve noticed (and what is causing me an issue as the web service is expecting this to be passed) is that the elements in my SOAP header do not contain any of the attributes that I’ve assigned to them.

For example, the XML file that I’ve saved directly from my code using the x-document:save("FILE", "header.xml") method contains the following XML element

<ns0:Security soap:misUnderstand="1"
xmlns:ns0="http://schemas.xmlsoap.org/ws/2002/07/secext">
<ns0:UsernameToken
wsu:Id="LOGIN"
xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility">
<ns0:Username>abc</ns0:Username>
<ns0assword>12345</ns0assword>
<wsu:Created>2006-08-15T12:12:32Z</wsu:Created>
</ns0:UsernameToken>
</ns0:Security>

This is exactly what I want. Notice the 2 attributes of the UsernameToken element (wsu:Id and xmlns:wsu). I’m no SOAP expert, and I’m not really interested in whether this is good or bad SOAP XML, all I know is that this is what the web service requires (I have a sample XML file showing what the header needs to be, and this is it).

This element was built as an X-NODEREF object, added to a SOAP-HEADER-ENTRYREF object using the SET-NODE method, and then this SOAP-HEADER-ENTRYREF added to the SOAP-HEADER object using ADD-HEADER-ENTRY, and it is this SOAP-HEADER that is returned by the callback procedure to create the header of the SOAP message.

When I intercept the SOAP message going to my web service, this is what I see as part of the soap header for the element above

<ns0:Security soap:mustUnderstand="1"
xmlns:ns0="http://schemas.xmlsoap.org/ws/2002/07/secext">
<ns0:UsernameToken>
<ns0:Username>abc</ns0:Username>
<ns0assword>12345</ns0assword>
<wsu:Created>2006-08-15T12:13:50Z</wsu:Created>
</ns0:UsernameToken>
</ns0:Security>

The attributes I mentioned earlier are now no longer part of the UsernameToken element that is being sent to the web service. It’s as if the SET-NODE or ADD-HEADER-ENTRY methods that added my X-NODEREF object to the SOAP header have removed / ignored any attributes that I set when building the X-NODEREF object.

Does anyone have any ideas as to how I can ensure that these attributes remain in my SOAP header message ?

 

[Phil Dunn]

After some further invetigation it appears that SET-NODE and ADD-HEADER-ENTRY do create the the XML element as required.

Its the call to the web service method that seems to truncate the atrributes from the SOAP header.

I create the SOAP-HEADER object (and populate it with all my SOAP-HEADER-ENTRYREF elements) at the start of the program, and then assign this header to the "header" output parameter of "REQUEST-HEADER" callback procedure.

So just prior to the call the the web sergice login method, I can check the contents of the SOAP-HEADER object using the following code (hLoginHeader is my SOAP-HEADER object that has been populated with all my XML elements)

DEF VAR i AS INTEGER.
DEF VAR ref AS HANDLE.
DEF VAR l AS LONGCHAR.

CREATE SOAP-HEADER-ENTRYREF ref.

OUTPUT TO LONGCHAR.txt.

DO i = 1 TO hLoginHeader:NUM-HEADER-ENTRIES:
hLoginHeader:GET-HEADER-ENTRY(ref, i).
l = ref:GET-SERIALIZED().
EXPORT l.
PUT SKIP (1).
END.

OUTPUT CLOSE.

DELETE OBJECT ref.

Checking the contents of the LONGCHAR.txt file, all the elements and attributes are in place, exactly as I created them.

But when I intercept the XML sent by the call the the Login web service method, the attributes are no longer present.

So maybe its the structure of the XML elements that Progress does not like. It seems as if there is not a lot that can be done about this.