LO59433: ARRAY OF BYTES IN XML REQUEST GENERATED BY WEB SERVICE CONSUMER

APAR status

• Closed as fixed if next.

Error description

• The two attached XSD files are part of a WSDL that was generated
  by a .Net Web Service provider. The binary data is defined as :
  
  <xs:element minOccurs="0" name="data" nillable="true"
  type="xs:base64Binary"/>
  
  If a Domino consumer is built using this WSDL, the request XML
  that Domino generates is in the format:
  
  <?xml version="1.0" encoding="UTF-8"?>
  <soapenv:Envelope
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soapenv:Body>
    <Upload xmlns="urn:DCCS.AttachmentsPOC">
     <attachments>
      <ns1:Attachment
  xmlns:ns1="http://schemas.datacontract.org/2004/07/DCCS.Attachme
  ntsPOC">
       <ns1:data xsi:type="xsd:byte">71</ns1:data>
       <ns1:data xsi:type="xsd:byte">73</ns1:data>
       <ns1:data xsi:type="xsd:byte">70</ns1:data>
       <ns1:data xsi:type="xsd:byte">56</ns1:data>
       <ns1:data xsi:type="xsd:byte">57</ns1:data>
       .......
       <ns1:data xsi:type="xsd:byte">0</ns1:data>
       <ns1:data xsi:type="xsd:byte">59</ns1:data>
       <ns1:fileName>E:\temp\dtt32.gif</ns1:fileName>
      </ns1:Attachment>
     </attachments>
    </Upload>
  </soapenv:Body>
  </soapenv:Envelope>
  
  It literally generates an array of bytes ? which is clearly
  wrong. Comparing the XSD to how Domino generates a WSDL for the
  same functionality, it appears that this is caused by the
  minOccurs="0" and nillable="true". When the line in the XSD is
  modified to:
  
  <xs:element name="data" type="xs:base64Binary"/>
  
  It then correctly generates the request in the format:
  
  <soapenv:Envelope
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <soapenv:Body>
       <Upload xmlns="urn:DCCS.AttachmentsPOC">
           <attachments>
              <ns1:Attachment>
  
  <ns1:data>VEhpcyBpcyB0byB0ZXN0IGF0dGFjaG1lbnRzIHdpdGggc29hcFVJLg
  ==</ns1:data>
                 <ns1:fileName>Creek.jpg</ ns1:fileName>
              </ns1:Attachment>
           </attachments>
        </Upload>
     </soapenv:Body>
  </soapenv:Envelope>
  
  
  
  According to the Designer Help Guide, for "literal" services,
  arrays map to "literal" arrays (<complexType>) with a single
  <element> whose "maxOccurs" attribute value is "unbounded":
  <wsdl:types>
   <schema targetNamespace="urn:DefaultNamespace"
    xmlns="http://www.w3.org/2001/XMLSchema">
  
     <complexType name="xsd_intArray">
       <element name="item" minOccurs="0" maxOccurs="unbounded"
  type="xsd:int"/>
     </complexType>
  
   </schema>
  </wsdl:types>
  
  Based on that documentation, the type should only get cast into
  an array if there is a 'maxOccurs' attribute. Since the above
  WSDL does not have that attribute:
  
  <xs:element minOccurs="0" name="data" nillable="true"
  type="xs:base64Binary"/>
  
  It would appear that casting it into an array on the import of
  the WSDL is a bug.
  

Local fix

• Using:
  
  <xs:element name="data" type="xs:base64Binary"/>
  
  Instead of:
  
  <xs:element minOccurs="0" name="data" nillable="true"
  type="xs:base64Binary"/>
  
  Appears to prevent the problem.
  

Problem summary

• This APAR is closed as FIN. We have deferred the fix to a
   future release.
  

Problem conclusion

Temporary fix

Comments

• This APAR is associated with SPR# LAMY8F7P66.
  
  This APAR is closed as FIN. We have deferred the fix to a
   future release.
  

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

Applicable component levels

• R852 PSN

     UP