How to manipulate SOAP-HEADER?

Posted by melinav on 24-Apr-2014 07:44

I can generate my own soap-header, the problem is that Progress 4GL added to each element of the header prefix resulting in the following structure:

<SOAP-ENV:Header>
<ns0:user xmlns:ns0="http://someurl.com">usuario</ns0:user>
<ns0:pwd xmlns:ns0="http://someurl.com">password</ns0:pwd>
</SOAP-ENV:Header>

And the structure that i need, without the prefix's and namespace's, is the next:

<SOAP-ENV:Header>
<user>usuario</user>
<pwd>password</pwd>
</SOAP-ENV:Header>

Sorry for my bad english.

Can anyone help me?

This is the procedure that i use for create the soap-header:

/* procedure that creates a soap-header */
/* Define procedure parameter */
   DEFINE OUTPUT PARAMETER hHeader AS HANDLE.
   DEFINE VARIABLE hHeaderEntryref AS HANDLE.
   DEFINE VARIABLE hXnoderef1 AS HANDLE.
   DEFINE VARIABLE hXnoderef2 AS HANDLE.
   DEFINE VARIABLE hXnoderef3 AS HANDLE.
   DEFINE VARIABLE hXNameAttr AS HANDLE.

   DEFINE VARIABLE hXtext AS HANDLE.
   DEFINE VARIABLE hXdoc AS HANDLE.

   CREATE X-NODEREF hXnoderef1.
   CREATE X-NODEREF hXnoderef2.
   CREATE X-NODEREF hXnoderef3.
   CREATE X-NODEREF hXtext.
   CREATE X-DOCUMENT hXdoc.

   /* Create SOAP header and server objects */
   CREATE SOAP-HEADER hHeader.
   CREATE SOAP-HEADER-ENTRYREF hHeaderEntryref.
   /* Create the header entry */
   hHeader:ADD-HEADER-ENTRY(hHeaderEntryref).      

   /* Create the Username/Password data */
   hXdoc:CREATE-NODE-NAMESPACE(hXnoderef1, "http://www.w3.org/BaufestProductivityFramework", "ContextInformation", "ELEMENT").
   hXnoderef1:SET-ATTRIBUTE("xmlns:i", "http://www.w3.org/2001/XMLSchema-instance").
   hXdoc:INSERT-BEFORE(hXnoderef1, ?).   

   hXdoc:CREATE-NODE-NAMESPACE(hXnoderef2, "http://schemas.datacontract.org/2004/07/Bpf.Common.Service", "ClientIp", "ELEMENT").
   hXnoderef1:APPEND-CHILD(hXnoderef2).
   hXdoc:CREATE-NODE(hXtext,"","text").
   hXnoderef2:APPEND-CHILD(hXtext).
   hXtext:NODE-VALUE = "000.00.00.00".

   hXdoc:CREATE-NODE-NAMESPACE(hXnoderef2, "http://schemas.datacontract.org/2004/07/Bpf.Common.Service", "CompanyId", "ELEMENT").
   hXnoderef1:APPEND-CHILD(hXnoderef2).
   hXdoc:CREATE-NODE(hXtext,"","text").
   hXnoderef2:APPEND-CHILD(hXtext).
   hXtext:NODE-VALUE = "1".

   hXdoc:CREATE-NODE-NAMESPACE(hXnoderef2, "http://schemas.datacontract.org/2004/07/Bpf.Common.Service", "Culture", "ELEMENT").
   hXnoderef1:APPEND-CHILD(hXnoderef2).
   hXdoc:CREATE-NODE(hXtext,"","text").
   hXnoderef2:APPEND-CHILD(hXtext).
   hXtext:NODE-VALUE = "en-US".

   hXdoc:CREATE-NODE-NAMESPACE(hXnoderef2, "http://schemas.datacontract.org/2004/07/Bpf.Common.Service", "HighCode", "ELEMENT").
   hXnoderef1:APPEND-CHILD(hXnoderef2).
   hXdoc:CREATE-NODE(hXtext,"","text").
   hXnoderef2:APPEND-CHILD(hXtext).
   hXtext:NODE-VALUE = "0".

   hXdoc:CREATE-NODE-NAMESPACE(hXnoderef2, "http://schemas.datacontract.org/2004/07/Bpf.Common.Service", "MaxId", "ELEMENT").
   hXnoderef1:APPEND-CHILD(hXnoderef2).
   hXdoc:CREATE-NODE(hXtext,"","text").
   hXnoderef2:APPEND-CHILD(hXtext).
   hXtext:NODE-VALUE = "0".

   hXdoc:CREATE-NODE-NAMESPACE(hXnoderef2, "http://schemas.datacontract.org/2004/07/Bpf.Common.Service", "OfficeId", "ELEMENT").
   hXnoderef1:APPEND-CHILD(hXnoderef2).
   hXdoc:CREATE-NODE(hXtext,"","text").
   hXnoderef2:APPEND-CHILD(hXtext).
   hXtext:NODE-VALUE = "0".

   hXdoc:CREATE-NODE-NAMESPACE(hXnoderef2, "http://schemas.datacontract.org/2004/07/Bpf.Common.Service", "TerminalId", "ELEMENT").
   hXnoderef1:APPEND-CHILD(hXnoderef2).
   hXdoc:CREATE-NODE(hXtext,"","text").
   hXnoderef2:APPEND-CHILD(hXtext).
   hXtext:NODE-VALUE = "0".

   hXdoc:CREATE-NODE-NAMESPACE(hXnoderef2, "http://schemas.datacontract.org/2004/07/Bpf.Common.Service", "TimeZone", "ELEMENT").
   hXnoderef2:SET-ATTRIBUTE("i:nil","true").
   hXnoderef1:APPEND-CHILD(hXnoderef2).

   hXdoc:CREATE-NODE-NAMESPACE(hXnoderef2, "http://schemas.datacontract.org/2004/07/Bpf.Common.Service", "UserId", "ELEMENT").
   hXnoderef1:APPEND-CHILD(hXnoderef2).
   hXdoc:CREATE-NODE(hXtext,"","text").
   hXnoderef2:APPEND-CHILD(hXtext).
   hXtext:NODE-VALUE = "0".

   hXdoc:CREATE-NODE-NAMESPACE(hXnoderef2, "http://schemas.datacontract.org/2004/07/Bpf.Common.Service", "UserName", "ELEMENT").
   hXnoderef1:APPEND-CHILD(hXnoderef2).
   hXdoc:CREATE-NODE(hXtext,"","text").
   hXnoderef2:APPEND-CHILD(hXtext).
   hXtext:NODE-VALUE = "Cliente RMBroker".   

   /* Fill the header entry using a deep copy */
   hHeaderEntryref:SET-NODE(hXnoderef1).

       CREATE X-DOCUMENT hXdoc.
       CREATE X-NODEREF hXnoderef1.
       CREATE X-NODEREF hXnoderef2.
       CREATE X-NODEREF hXtext.
       CREATE X-NODEREF hNoderef.
       CREATE X-NODEREF hXNameAttr.
       CREATE SOAP-HEADER-ENTRYREF hHeaderEntryref.

       /* Create the header entry */
       hHeader:ADD-HEADER-ENTRY(hHeaderEntryref).    

       hXdoc:CREATE-NODE-NAMESPACE(hXnoderef1, "http://www.w3.org/BaufestProductivityFramework", "TokenInformation", "ELEMENT").
       hXdoc:APPEND-CHILD(hXnoderef1).

       hXdoc:CREATE-NODE-NAMESPACE(hXNameAttr, "http://www.w3.org/2000/xmlns/", "xmlns:i", "ATTRIBUTE").
       hXNameAttr:NODE-VALUE="http://www.w3.org/2001/XMLSchema-instance".
       hXnoderef1:SET-ATTRIBUTE-NODE(hXNameAttr).


       hXdoc:CREATE-NODE-NAMESPACE(hXnoderef2, "http://schemas.datacontract.org/2004/07/Bpf.Security.Common", "creationDate", "ELEMENT").
       hXnoderef1:APPEND-CHILD(hXnoderef2).
       hXdoc:CREATE-NODE(hXtext,"","text").
       hXnoderef2:APPEND-CHILD(hXtext).
       hXtext:NODE-VALUE = cdate.

       hXdoc:CREATE-NODE-NAMESPACE(hXnoderef2, "http://schemas.datacontract.org/2004/07/Bpf.Security.Common", "id", "ELEMENT").       
       hXnoderef2:SET-ATTRIBUTE("xmlns:d4p1", "http://www.w3.org/2001/XMLSchema").

       hXdoc:CREATE-NODE-NAMESPACE(hXNameAttr, "http://www.w3.org/2001/XMLSchema-instance", "i:type", "ATTRIBUTE").
       hXNameAttr:NODE-VALUE="d4p1:string".
       hXnoderef2:SET-ATTRIBUTE-NODE(hXNameAttr).

       hXnoderef1:APPEND-CHILD(hXnoderef2).
       hXdoc:CREATE-NODE(hXtext,"","text").
       hXnoderef2:APPEND-CHILD(hXtext).
       hXtext:NODE-VALUE = token.

       /* Fill the header entry using a deep copy */
       hHeaderEntryref:SET-NODE(hXnoderef1).  


   /* Procedure/header cleanup */ 
   DELETE OBJECT hXdoc.
   DELETE OBJECT hXnoderef1.
   DELETE OBJECT hXnoderef2.
   DELETE OBJECT hXnoderef3.
   DELETE OBJECT hXtext.
   DELETE OBJECT hHeaderEntryref.

OpenEdge Development - Forum

All Replies

Posted by Brian K. Maher on 24-Apr-2014 07:50

 
I think we will need to see your code in order to resolve this.  Please open a case with Tech Support.
 

Posted by melinav on 24-Apr-2014 07:53

Can you indicate how to open a case with Tech Support?

Posted by Brian K. Maher on 24-Apr-2014 07:59

 
If your account corresponds to a license under maintenance there should be an option on the topic page to open a support call.  If there isn't you should open a support call via the normal channels for your region/country.  Go to www.progress.com/support and use any of these options ... "Get Support - SupportLink", "Support Guide" or "Contact Support".
 

Posted by melinav on 24-Apr-2014 08:04

Thanks!

Posted by Brian K. Maher on 24-Apr-2014 08:06

 
You're welcome.
 

Posted by hmariwa on 01-May-2014 10:43

The prefix's and namespace's are part of SOAP's W3C  requirement; As stated in W3C SOAP Header specification:

"All immediate child elements of the SOAP Header element MUST be namespace-qualified. "

Posted by Marian Edu on 02-May-2014 10:25

true, problem is telling this to the other end usually doesn't help and we have to come-up with solutions in order to consume all those 'standard' web-services :(

we had a similar issue with a wsdl using iso-8859 encoding while Progress only supports utf-8, utf-16 (knowledgebase.progress.com/.../P97707)... requesting the 3-rd party to change their service is not a resolution though.

in this particular case no error seems to be raised if a non namespace-aware node is attached to the soap-header reference, the reference is valid, the attached node looks valid but serialization is null... this is not to say you should enforce that by throwing an error, it should be an easy fix to accept those nodes and leave the 'wrong' message get sent to the other end (let them validate the specifications) - something like the 'strict' attribute for sax :)

Posted by hmariwa on 02-May-2014 14:40

We can only do validation  of the SOAP-HEADER when we are about to send the  SOAP request; otherwise there is no way
to tell when SOAP-HEADER creation is completed. For example, you can attach a ‘non namespace-aware node’ and later
on add a namespace to it when it is available, or passing on the SOAP-HEADER object to another function to add a namespace.
 
[collapse]
From: medu [mailto:bounce-medu@community.progress.com]
Sent: Friday, May 02, 2014 11:26 AM
To: TU.OE.Development@community.progress.com
Subject: RE: How to manipulate SOAP-HEADER?
 
Reply by medu

true, problem is telling this to the other end usually doesn't help and we have to come-up with solutions in order to consume all those 'standard' web-services :(

we had a similar issue with a wsdl using iso-8859 encoding while Progress only supports utf-8, utf-16 (knowledgebase.progress.com/.../P97707)... requesting the 3-rd party to change their service is not a resolution though.

in this particular case no error seems to be raised if a non namespace-aware node is attached to the soap-header reference, the reference is valid, the attached node looks valid but serialization is null... this is not to say you should enforce that by throwing an error, it should be an easy fix to accept those nodes and leave the 'wrong' message get sent to the other end (let them validate the specifications) - something like the 'strict' attribute for sax :)

Stop receiving emails on this subject.

Flag this post as spam/abuse.

[/collapse]

Posted by Marian Edu on 05-May-2014 00:33

Think I just said the pursue shouldn't be in throwing an error to enforce the rule... this is just an explanation on why things works as they do now, not the slightest attempt to find a solution :(

Also mentioned 'strict' in sax-writer because that also gives one the possibility to build an invalid XML document, this is in no way any different... a simple strict property can be added to SOAP-HEADER and if not set then that namespace-aware restriction can be lifted, let the other end or the developer deal with it. The main idea is yes, we know they don't follow standards but you can't just go ahead and tell everyone to fix their system just because you need to integrate as long as they are doing with the rest of the world already... no one will change their system because of that.

This thread is closed