Message Sets: Importing from WSDL: generated objects and restrictions

Several objects are generated when you import from WSDL but restrictions might apply.

Generated objects

Files copied by command line import
The mqsicreatemsgdefsfromwsdl command copies the WSDL files it needs into the workspace before running the import process. These files are the top level WSDL files and any imports resolved from a relative location. The files are copied under the specified application, library, or message set into a folder called importFiles.
Report file

The WSDL importer appends the result of the import operation to a report file, listing all errors that occurred during the process. The file name of the report file is application or library.wsdl.report.txt or message set.wsdl.report.txt.

SOAP message definitions

The required SOAP .xsds files are added to the application or library. If you are using a message set, .mxsds files are added to the message set.

To parse SOAP 1.2 instance documents, manually remove the SOAP 1.1 definitions and import the SOAP 1.2 definitions by using the Message Definition File wizard, selecting IBM supplied message.

If your application, library, or message set has TDS or CWF layers, you might find that you get a number of warnings against the imported SOAP definitions. Most of these can be ignored, but take account of the allowed values for Boolean attributes. In SOAP 1.1 the Boolean values are 1 or 0, while in SOAP 1.2 the values are true and false. The XML representation of Boolean values for an application, library, or message set is specified in the physical properties for the XML physical format, and might need to be set accordingly.

Message roots or message definition files
If you are using a message set, message definitions are created. If you are using an application or library, message roots are created instead. Other message root or definition file names are created as input file name.xsd (for applications and libraries) or input file name.mxsd (for message sets) and their content depends on the WSDL style.
document-style
WSDL message parts for style="document" (which includes all SOAP header, fault and headerfault parts) refer to an element defined in XML Schema. This element is imported as a global element and integration node message in the .xsd or .mxsd file.

The xsi:type output policy on the message is set to "Never".

rpc-style
WSDL message parts for style="rpc" (and exclusively those allocated to the SOAP body) refer to a type defined in XML Schema. In this case, input and output messages are created as shown in the following table.
  An input message An output message
Derived From The wsdl:input child (if any) of WSDL operation, and the WSDL message and parts that it identifies The wsdl:output child (if any) of WSDL operation, and the WSDL message and parts that it identifies
Name of Element The value of the name attribute on the WSDL operation element The value of the name attribute on the WSDL operation element suffixed by "Response"
Namespace of Element The value of the namespace attribute on the corresponding soap:body element The value of the namespace attribute on the corresponding soap:body element

Each message is of local complex type, being a sequence of elements. The name of each element is the value of the name attribute on the WSDL parts of the message identified by either the input or output element. These elements have no namespace (the underlying schema representation has form="unqualified"), and are locally scoped to avoid name clashes. The type of these local elements is the XML schema type referred to by the type attribute of the corresponding part element. The type is global in the WSDL schema.

If the soap:body element was defined with use="encoded" in the WSDL definition, the message definition includes a reference to the attribute group encodingStyle in the SOAP-ENV namespace and the xsi:type output policy on the message is set to "Follow SOAP encoding rules". Otherwise, the xsi:type output policy on the message is set to "Never".

WSDLs generated using .NET
In some instances, WSDL files that are generated by using .NET include element references to the schema itself; for example: 
<xsd:complexType>
		<xsd:sequence>
			<xsd:element ref="s:schema"/>
		</xsd:sequence>
</xsd:complexType>
For WSDL files of this type to be successfully imported into the IBM® App Connect Enterprise Toolkit without validation errors, you must manually add a namespace import statement to the namespace of the schema; for example:
<xsd:import namespace="http://www.w3.org/2001/XMLSchema"/>

Place the import statement first in the schema element, and ensure that it appears before any complex type or element definitions. Revalidate the WSDL by right-clicking the updated WSDL and clicking Validate.

Restrictions

Restrictions related to importing WSDL definitions exist where the WSDL definitions are not WS-I compliant.
SOAP Arrays
A WSDL 1.1 definition can define a SOAP array (applicable only to the WSDL rpc-encoded style, and not WS-I compliant):
    <xsd:complexType name="t">
          <xsd:complexContent>
            <xsd:restriction base="SOAP-ENC:Array">
              <xsd:sequence>
                <xsd:element name="item" type="string" maxOccurs="unbounded"/>
              </xsd:sequence>
              <xsd:attribute  ref="SOAP-ENC:arrayType" wsdl:arrayType="xsd:string[]"/>
            </xsd:restriction>
          </xsd:complexContent>
    </xsd:complexType>

Some uses of SOAP array syntax are not fully supported. Although a useful tree is created during parsing and can be serialized when writing, the following restrictions apply.

  • The model does not take any account of the SOAP-ENC:arrayType attribute.
  • The model for partially transmitted arrays does not take account of the SOAP-ENC:offset attribute.

    For example, the first element of an array specified with offset[2] must be accessed in ESQL, not as InputRoot.MRM.array.item[3], but as InputRoot.MRM.array.item[1].

  • The model for multi-dimensional arrays flattens the representation into a single dimension. For example, a 2-dimensional array is accessed in ESQL, not as InputRoot.MRM.array.item[x][y], but as InputRoot.MRM.array.item[i] where the index i has to be calculated appropriately.
Anonymous elements
The WSDL excerpt above describes a SOAP instance document of the following form:
    <SOAP-ENC:Array SOAP-ENC:arrayType="xsd:string[3]">
       <item xsi:type="xsd:string">A general text string</item>
       <item xsi:type="xsd:token">A restriction of the string type</item>
       <item xsi:type="xsd:Name">ARestrictionOfTheTokenType</item>
    </SOAP-ENC:Array>

The integration node model handles this document as expected, but in SOAP encoding array, elements are also allowed to use the type-elements from the SOAP encoding namespace. Therefore, an application using the same WSDL definition might create an instance document of the following form:

    <SOAP-ENC:Array SOAP-ENC:arrayType="xsd:string[3]">
       <SOAP-ENC:string>A general text string</SOAP-ENC:string>
       <SOAP-ENC:token>A restriction of the string type</SOAP-ENC:token>
       <SOAP-ENC:Name>ARestrictionOfTheTokenType</ SOAP-ENC:Name>
    </SOAP-ENC:Array>

To handle this case, you must manually edit the integration node model that is created by importing the WSDL, unless it is acceptable to have the parser treat it as a self-defined element.