soap:Header elements (implicit soap:Header) not present after proxy generation for json to soap to json

[#1]

We've had this issue with this WSDL before with other proxy generation services and it ends up taking some extra work. So, this is likely possible here at Apigee as well, but I could just be missing how it's done. I searched for a while, but couldn't find the solution. Here is a snippet of the soap:header portion of a "valid" request to the service, taken from SoapUI:

   <soapenv:Header>
      <urn:password xsi:type="xsd:string">?</urn:password>
      <urn:accesskey xsi:type="xsd:string">?</urn:accesskey>
   </soapenv:Header>

The only way to get SoapUI to put the password and accesskey elements into the soapenv:Header body is to do this in the binding->operation->input element

        <soap:header message="tns:AuthenticationRequestHeaders" part="accesskey" use="encoded" />
        <soap:header message="tns:AuthenticationRequestHeaders" part="password" use="encoded" />

This doesn't seem to work here at Apigee. This is from the API Proxy, develop tab, build soap, for one of the WSDL services:

        <Payload contentType="text/xml">
            <soapenv:Envelope xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tns="urn:OnForce_WorkOrder" xmlns:xsd="http://www.w3.org/2001/XMLSchema" soapenv:encodingStyle="{encodingStyle}">
                <soapenv:Body>
                    <tns:WorkOrderGet>
                        <workorderid xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="{type}">{workorderid}</workorderid>
                    </tns:WorkOrderGet>
                </soapenv:Body>
            </soapenv:Envelope>
        </Payload>

You can see there is no soapenv:Header section where password and accesskey would be accessible and available to populating with a value. The idea in this json to soap to json example would be to accept the accesskey and password through a json payload and inject them into the soapenv:Header element values.

A copy of the full WSDL is found here, but doesn't have the mods I've added into the binding->operation->input sections and extra complex types.

Thanks for any pointers and suggestions you can give.

[DChiesa]

I understand what you're saying.

It could be that the WSDL import Wizard is just failing to do the right thing for the WSDL you provided it.

We can take the WSDL and file a bug and see if we can get that fixed.

On the other hand if you are experiencing this as a blocking problem, then, the workaround seems to be pretty clear: hand-modify the AssignMessage policies that have been generated to insert the username/password into the SOAP payload in a Header.

Do you understand how you'd go about doing that? If not I can explain in greater detail.

[Former Community Member]

SOAP Headers present an interesting challenge. First off, the information you have in the SOAP header are from what I can tell, custom SOAP Header elements.

Customer SOAP Header elements are not part of the WSDL. Apigee is only parsing information that is in the WSDL. Maybe this is possible in WSDL 2.0 (I haven't looked at it closely enough). Either way, we don't support WSDL 2.0 as yet and the WSDL is question is not WSDL 2.0.

The second problem with SOAP Header is - how do you represent that in JSON? JSON does not concept of headers and body (or a data envelope). Anything we do there will have to be a custom convention.

I agree with @Dino's solution. You can modify the Assign Message or XSLT policies to add the SOAP Header for this web service. If all you web services take the same type of parameter, you might want to consider adding this in a shared flow.

[#4]

So, @Dino, @Srinandan Sridhar ... with some work, I tracked down the problem. Here's a screen grab of the header elements being generated automatically, successfully:

It was failing because in the binding->operation->input element, originally the soap:header elements were referencing simpleType string parts and they needed to be complexTypes.

<input>
[snip]
  <soap:header message="tns:AuthenticationRequestHeaders" part="accesskey" use="literal"/>
  <soap:header message="tns:AuthenticationRequestHeaders" part="password" use="literal"/>
[/snip]
</input>

The <message />:

<message name="AuthenticationRequestHeaders">
  <part name="accesskey" element="tns:accesskey"/>
  <part name="password" element="tns:password"/>
</message>

The simpletype string XSD elements, causing generation failure:

<element name="accesskey" type="xsd:string"/>
<element name="password" type="xsd:string"/>

So, the fix was to convert them to complexType with simpleContent

<element name="accesskey">
  <complexType>
    <simpleContent>
      <extension base="xsd:string"/>
    </simpleContent>
  </complexType>
</element>
<element name="password">
  <complexType>
    <simpleContent>
      <extension base="xsd:string"/>
    </simpleContent>
  </complexType>
</element>

After this, the header elements were generated normally during proxy generation. I solved this by trying to consume the WSDL in Force.com in Salesforce. Enough other people had similar problems and the suggestions surrounded changing the :string elements to complexTypes. Luckily you can just define a complexType with simpleContent and everything work out great.

A change here that I think would be helpful - at least put out some errors or warnings of some kind - or maybe you do and I just don't know where to look for it. That would have helped me and helped others to know what to suggest to get me past it.

Hopefully this helps!

[DChiesa]

Wow, this is great information, Dave, thank you for taking the time to document the fix. @Srinandan Sridhar - what do you think we should do with this?

[#6]

As an aside - after I got my initial test working which consisted of a WSDL with one service in it, I added all the others with the new arrangement. I tried to build the proxy and ended up with this:

screen-shot-2017-03-03-at-111919-am.png

Keep in mind that the full WSDL works with SoapUI and Salesforce consumes and generates proxy classes off of the full WSDL.

Here is a copy of full WSDL attached:

full-wsdl.txt

Here is a copy of initial test smaller WSDL:

minimalwsdl.txt

Could it be possible that the proxy generation is running out of memory? The WSDL is fairly large...is there a log I can look at? Can we get to what that error is trying to indicate?

Thanks