Working with data structures

Edit online

This group of topics describes issues involved in working with data structures.

Commonly Used Elements and Types

Edit online

This topic describes how Enterprise Service Tools users can include and reference commonly used interface elements (which are derived from COBOL copybooks) using standard XSD and WSDL inclusion mechanisms.

Including and Referencing Commonly Used Elements and Types

Note: This feature applies to the EST Batch processor tools for the "bottom-up" scenario of developing new service interfaces from COBOL applications utilizing "Compiled XML conversion" technology. It is available through the Batch processor configuration files only and only for COBOL sources. The generators used in the Batch generation process must have access to the copybooks referenced in the COBOL source.

It is common in COBOL application development to create reusable sequences of code by putting them into “COPY” files (COPY books) and achieve re-use by including the same COPY book in multiple source files (via the COBOL COPY statement).

Figure 1 is a example of a typical sequence of code to re-use is data definition that repeats in multiple data structures. In this example, the two data definitions re-use the same COPY book named COMMHDR.

Figure 1. Example of COBOL Reuse of Data Definition Element


       01 departmentUpdateRequest.
           COPY COMMHDR.
           COPY DEPTBDY.

             

       01 departmentUpdateReply.
           COPY COMMHDR.
           02 updStatus pic xxx.

Figure 2 and Figure 3 show of the content of the COMMHDR copybook and DEPTBDY copybook.

Figure 2. Example of COMMHDR Copy Book

         05 commHeader.
             10 commId                  PIC 9(4).
             10 commRevDate             PIC X(8).
             10 commDigest              PIC X(40).
Figure 3. Example of DEPTBDY Copy Book

             2 member-count  pic 9(9) binary.
             2 dept-details.
               3 dept-title           pic x(35).
               3 dept-id              pic x(45).
               3 dept-seq             pic 9(4).
               3 dept-hq              pic x(75).

Background for Including and Referencing Commonly Used Elements and Types

Prior to IBM® Developer for z Systems® Version 7.5, service interfaces generated from data structures that referenced COPY books required that complete XML schemas (XSDs) be generated for each data structure.

When using the input shown in Figure 1, previous versions of the Enterprise Service Tools wizards generated the output shown in Figure 4 (departmentUpdateRequest), and Figure 5 (departmentUpdateReply).
Note: For documentation purposes, only the partial schema is displayed.
Figure 4. Example of Part of Schema Generated for WSDL Interface Type for departmentUpdateRequest 

     <schema ... 
targetNamespace="http://www.TST01I.com/schemas/TST01IInterface"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:cbl="http://www.TST01I.com/schemas/TST01IInterface">

      <complexType name="departmentUpdateRequest">
        <sequence>
          <element name="commHeader"
type="cbl:departmentupdaterequest_commheader"/>
          <element form="qualified" name="member_count">
            <simpleType>
              ...
            </simpleType>
          </element>
          <element name="dept_details"
type="cbl:departmentupdaterequest_dept__details"/>
        </sequence>
      </complexType>
      <complexType name="departmentupdaterequest_commheader">
        <sequence>
          <element form="qualified" name="commId">
            <simpleType>
              ...
            </simpleType>
          </element>
          <element form="qualified" name="commRevDate">
            <simpleType>
              ...
            </simpleType>
          </element>
          <element form="qualified" name="commDigest">
            <simpleType>
              ...
            </simpleType>
          </element>
        </sequence>
      </complexType>
      <complexType name="departmentupdaterequest_dept__details">
        <sequence>
          ...          
        </sequence>
      </complexType>
      <element name="departmentUpdateRequest" type="cbl:departmentUpdateRequest">
    </schema>
Figure 5. Example of Part of Schema Generated for WSDL Interface Type for departmentUpdateReply 

      <schema attributeFormDefault="qualified" 
elementFormDefault="qualified" 
targetNamespace="http://www.TST01O.com/schemas/TST01OInterface" 
xmlns="http://www.w3.org/2001/XMLSchema" 
xmlns:cbl="http://www.TST01O.com/schemas/TST01OInterface">
      <complexType name="departmentUpdateReply">
        <sequence>
          <element name="commHeader" type="cbl:departmentupdatereply_commheader"/>
          <element form="qualified" name="updStatus">
            ...
          </element>
        </sequence>
      </complexType>
      <complexType name="departmentupdatereply_commheader">
        <sequence>
          <element form="qualified" name="commId">
            ...
          </element>
          <element form="qualified" name="commRevDate">
            ...
          </element>
          <element form="qualified" name="commDigest">
            ...
          </element>
        </sequence>
      </complexType>
      <element name=" departmentUpdateReply" type="cbl:departmentUpdateReply">
        ...
      </element>
    </schema>
As shown in Figure 4 and Figure 5, the declaration for element commHeader and for its type are duplicated for both departmentUpdateRequest and for departmentUpdateReply. The only differences are:
  1. The complex type name for each element:

    (departmentupdaterequest_commheader. VS. departmentupdatereply_commheader)

    and

  2. The namespaces for the schemas:

    (xmlns:cbl="http://www.TST01I.com/schemas/TST01IInterface. VS. xmlns:cbl="http://www.TST01O.com/schemas/TST01OInterface) .

Because a single COPY book can be used for multiple services the multiplicity of similarly typed elements may lead to unnecessary duplication of code generated for the clients from such WSDL or XSD files.

This feature allows users to specify common COPY book and common XSD types and elements that can be re-used by multiple interfaces without having to have duplicate schema content.

Defining common standard elements and types in generated XSD and WSDL

Edit online

This topic describes the definition parameters for the feature “Including and Referencing Commonly Used Elements and Types”.

The common schema content is defined to the xsebatch command line tool through an XML file that can be specified either on the command line parameter (-commtypes for “Common Types”) or by the “commTypesFile“ attribute specified in the ServiceSpecification.xml file.

The user can override the commtypes xml file specified with the “commTypesFile“ attribute for input and output message elements (InputMessage and OutputMessage) in the Batch processor option specification file (ServiceSpecification.xml).

When the user creates and specifies the commtypes xml file, the WSDL and XSD generation process uses the information specified in the commtypes file to generate elements, types and schema imports instead of the imbedded types, elements and namespaces. The list of common types from the command line parameter can be overridden by the content of the file(s) specified on the commTypesFile attribute.

Table 1 is a listing of the elements and attributes of the Common Types Element.
Table 1. Elements and Attributes of the Common Types Element
Element or Attribute Definition
CommTypes Container element for common groups.
CommGroup Group for listing common type information.
lang Specifies the source language of the application source being processed.
format For source languages that permit fixed or free source formatting, this attribute must specify which format is used. Currently this attribute is reserved and set to "fixed".
CommonType Attributes of this element describe how the common application source data items should be processed (see below).
srcName Specifies the source name of the copybook as it appears in the COBOL application program source. COPY books specified in the srcName attribute are not cross-referenced with the COBOL application source files, but they must be present and accessible to the Batch processor tool when the COBOL application source is processed.
nativeName Specifies the COBOL data item name for which the XML schema reference and type should be taken from the common schema.
commSchemaLocation Specifies the common schema location attribute (xsi:schemaLocation) that is generated in the import statement for the enclosing WSDL or XSD.
Note: For CICS® Webservices scenarios this location must be accessible when the tools are running, Otherwise an error message are displayed and the generation process does not complete.
commNamespace Specifies the value of the namespace declaration that is generated for referring to the common schema.
xmlElementName Specifies the value of the element name from the common schema that should be referred to from the enclosing WSDL or XSD.
commNsPrefix Specifies the value of the namespace prefix that should be generated to qualify the reference of the common elements and types.

Figure 6 is an example of a commtype xml file used to direct the processor to use common types, elements, namespaces, in a COBOL source language sample.

Figure 6. Example of a commtype XML File
 
<?xml version="1.0" encoding="UTF-8"?>
<commtypes:CommonTypes xmlns:commtypes="http://www.ibm.com/xmlent/commxsd/emf/commtypes">
  <commtypes:CommGroup lang="COBOL" format="fixed"> 
    <commtypes:CommonType 
               srcName="COMMHDR" 
               nativeName="commHeader" 
               commSchemaLocation="commHeader.xsd"
               commNamespace="http://www.sample.com/schemas/commHeader"
               xmlElementName="commHeader"
               commNsPrefix="hdr1"
               />
  </commtypes:CommGroup>
</commtypes:CommonTypes>

The commtype xml file schema is shown in Figure 7.

Figure 7. A commtype XML File Schema

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:commtypes="http://www.ibm.com/xmlent/commxsd/emf/commtypes" 
targetNamespace="http://www.ibm.com/xmlent/commxsd/emf/commtypes">
  <xsd:element name="CommGroup">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="commtypes:CommonType" minOccurs="1" maxOccurs="unbounded"/>
      </xsd:sequence>
      <xsd:attribute name="lang" type="xsd:string"/>
      <xsd:attribute name="format" type="xsd:string"/>
    </xsd:complexType>
  </xsd:element>
  <xsd:element name="CommonTypes">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="commtypes:CommGroup"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>
  <xsd:element name="CommonType">
    <xsd:complexType>
      <xsd:attribute name="srcName" type="xsd:string"/>
      <xsd:attribute name="xmlElementName" type="xsd:string"/>
      <xsd:attribute name="nativeName" type="xsd:string"/>
      <xsd:attribute name="commSchemaLocation" type="xsd:string"/>
      <xsd:attribute name="commNamespace" type="xsd:string"/>
      <xsd:attribute name="commNsPrefix" type="xsd:string"/>
    </xsd:complexType>
  </xsd:element>
</xsd:schema>
When the commtype xml file example shown in Figure 6 is applied to the sample COBOL source and copybooks shown in Figure 1 in the topic Commonly Used Elements and Types, then the generated schema for departmentUpdateRequest is shown in Figure 8 and the generated schema for departmentUpdateReply is shown in Figure 9.
Note: For documentation purposes, only the partial schema is displayed.

Figure 10 shows the commHeader schema.

Figure 8. Example of Part of Schema Generated for departmentUpdateRequest Element

<schema attributeFormDefault="qualified" elementFormDefault="qualified" 
            targetNamespace="http://www.TST01I.com/schemas/TST01IInterface" 
            xmlns="http://www.w3.org/2001/XMLSchema" 
            xmlns:cbl="http://www.TST01I.com/schemas/TST01IInterface"
            xmlns:hdr1="http://www.sample.com/schemas/commHeader"> 
      <import namespace="http://www.sample.com/schemas/commHeader" 
            schemaLocation="commHeader.xsd"/>
      <complexType name="departmentUpdateRequest">
        <sequence>
          <element ref="hdr1:commHeader"/>
          <element form="qualified" name="member_count">
            <simpleType>
              <restriction base="int">
                <minInclusive value="0"/>
                <maxInclusive value="999999999"/>
              </restriction>
            </simpleType>
          </element>
          <element name="dept_details" type="cbl:departmentupdaterequest_dept__details"/>
        </sequence>
      </complexType>
Figure 9. Example of Part of Schema Generated for departmentUpdateReply Element

<schema attributeFormDefault="qualified" elementFormDefault="qualified" 
            targetNamespace="http://www.TST01O.com/schemas/TST01OInterface" 
            xmlns="http://www.w3.org/2001/XMLSchema" 
            xmlns:cbl="http://www.TST01O.com/schemas/TST01OInterface" 
            xmlns:hdr1="http://www.sample.com/schemas/commHeader"> 
      <import namespace="http://www.sample.com/schemas/commHeader" 
            schemaLocation="commHeader.xsd"/>
      <complexType name="departmentUpdateReply">
        <sequence>
          <element ref="hdr1:commHeader"/>
          <element form="qualified" name="updStatus">
            <annotation>
              <appinfo source="http://www.wsadie.com/appinfo">
                <initialValue kind="SPACE"/>
              </appinfo>
            </annotation>
            <simpleType>
              <restriction base="string">
                <maxLength value="3"/>
              </restriction>
            </simpleType>
          </element>
        </sequence>
      </complexType>
      <element name="employeeUpdateRequest" type="cbl:departmentUpdateReply">
        <annotation>
          <documentation source="com.ibm.etools.xmlent.batch">8.0.0.V200803251533</documentation>
        </annotation>
      </element>
    </schema>

Figure 10 is an example of the schema for the commonHdr.xsd file.

Figure 10. Example of Schema Generated for commonHdr.xsd File

<?xml version="1.0" encoding="UTF-8"?><schema attributeFormDefault="qualified" 
elementFormDefault="qualified" targetNamespace="http://www.sample.com/schemas/commHeader" 
xmlns="http://www.w3.org/2001/XMLSchema" xmlns:cbl="http://www.sample.com/schemas/commHeader">
  <complexType name="commheader">
    <sequence>
      <element name="commId">
        <simpleType>
          <restriction base="short">
            <minInclusive value="0"/>
            <maxInclusive value="9999"/>
          </restriction>
        </simpleType>
      </element>
      <element name="commRevDate">
        <annotation>
          <appinfo source="http://www.wsadie.com/appinfo">
            <initialValue kind="SPACE"/>
          </appinfo>
        </annotation>
        <simpleType>
          <restriction base="string">
            <maxLength value="8"/>
          </restriction>
        </simpleType>
      </element>
      <element name="commDigest">
        <annotation>
          <appinfo source="http://www.wsadie.com/appinfo">
            <initialValue kind="SPACE"/>
          </appinfo>
        </annotation>
        <simpleType>
          <restriction base="string">
            <maxLength value="40"/>
          </restriction>
        </simpleType>
      </element>
    </sequence>
  </complexType>
  <element name="commHeader" type="cbl:commheader">
    <annotation>
      <documentation source="com.ibm.etools.xmlent.batch">8.0.0.V200803251533</documentation>
    </annotation>
  </element>
</schema>

Rules and Conditions

This topic lists the rules and conditions for the feature “Including and Referencing Commonly Used Elements and Types”.

The rules and conditions are as follows:
  1. Content of the common types XML file must match the schema specified in this document. If it does not, the behavior of the Batch processor is unpredictable.
  2. If common types XML file is specified on the command line and there are common types xml files that are also specified on the commTypesFile attribute, the common types XML file from the command line is overridden by the information from the file(s) specified with the commTypesFile attribute
  3. If the common types XML file or files are specified (on the command line and/or in the Batch processor options file) but they do not actually exist, the Batch processor issues a warning and proceeds, ignoring the specified file(s).
  4. If the common types XML file is specified on the commTypesFile attribute for input and output message elements, common element and type information applies only to the InputMessage or the OutputMessage for which the commTypesFile attribute is specified.
  5. If the common types XML file is specified on the command line or on the commTypesFile attribute but no items are found in the source file that correspond to any itemName specified in the common types XML file, a warning message is issued.
  6. If common types XML file is specified either on the command line or in the commTypesFile attribute, and GEN_ELEMENT_FORM_QUALIFIED property of the CodeGenProperty attribute is set to false (either in the Batch process configuration file or in the GUI preferences for the workspace) the Batch processor issues a warning and proceeds, ignoring the specified common types XML file(s).

Creation of XML schemas from multiple language structures

Edit online

This topic introduces multiple-language structure enterprise applications and how the Enterprise Service Tools component can be used to enable them as Web services.

The Enterprise Service Tools batch processor and single-service project Web service wizards allow for generation of XML Schemas from collections of language structures. When enabling an enterprise application as a Web service, it may be that the interface of the application consists of more than one language structure. In order to expose such an application as a service, in a way that is easily consumable by a Web client, the tool supports aggregation of multiple language structures into single, composite XML Schemas for both the request and response message. The process by which this is accomplished depends on whether the batch processor or the Web service wizard is being used. In general, multiple language structures are specified in the order their equivalent XML Schema representations should appear in the composite XML Schema.

An example of a typical application whose interface consists of multiple language structures is an IMS Message Processing Program or MPP. MPP's typically send and receive messages that consist of multiple segments. Each segment is an instance of a language structure. For example, an MPP could expect to receive three segments each being a distinct 01 level language structure: 01 HEADER, 01 BODY, and 01 SUMMARY.

It is also common for multiple instances of a particular 01 level language structure to be present in a message processed or generated by an MPP. For example, multiple instances of the language structure 01 CUSTOMER-RECORD would be placed one after the other in a response to a query that retrieves information about more than one customer.

When enabling an IMS MPP as a Web service, the Enterprise Service Tools batch processor and single-service project Web service wizards generate composite XML Schemas and XML conversion artifacts for the request and response message of an MPP. The combination of the composite XML Schema and XML conversion artifacts provides a highly-consumable Web service interface which relieves the client from having to understand the MPP's complex multisegment runtime message structure.

The ability of the Enterprise Service Tools batch processor to generate composite XML Schemas can be used independently of generating runtime-specific Web service artifacts. These XML Schemas can then be used as input to the meet-in-middle or top-down scenarios.
Note: The Enterprise Service Tools mapping editor does not support mapping of multiple language structures to an XML Schema at this time.
The ability to create XML Schemas from multiple language structures enables Enterprise Service Tools to support multisegment IMS MPP's in IMS Enterprise Suite SOAP Gateway single-service projects.
Note: Currently, generation of XML Conversion artifacts for multiple language structures is only supported for IMS Enterprise Suite SOAP Gateway single-service, bottom-up projects.
The following topics give further detail on the specifics of creating XML Schemas and Web service artifacts for applications whose interface consists of multiple language structures:

Specification of multiple request language structures

Edit online

If an enterprise applications' input interface is comprised of multiple language structures, it is necessary to include each of them in the request message that clients will transmit when the application is invoked as a Web service. To direct the Enterprise Service Tools (EST) Batch processor to incorporate multiple language structures into the XML Schema (XSD) for the request message—specify multiple, sibling, InputMessage elements. The order in which the InputMessage elements are specified determines the order that their equivalent XSD definitions appears in the composite request XSD.

To further customize the request XSD, attributes on the InputMessage element can be specified. These attributes are:
  • xmlEleName - name of the XML element mapped to instances of the language structure
  • lowerBound - minimum repetitions of the language structure
  • upperBound - maximum repetitions of the language structure
See InputMessage for the complete description of the InputMessage attributes.

Figure 11 demonstrates how to direct the Enterprise Service Tools Batch processor to incorporate multiple language structures when generating the XSD for the request message of a Web service.

Note: Generation of XML Conversion artifacts is supported for the IMS Enterprise Suite SOAP Gateway runtime only when multiple language structures are specified.
Figure 11. Example of Specifying Multiple Language Structures for the Request Message
    <Operation name="PutOrderHistory">
      <InputMessage importFile="ORDRSECR.cpy" importDirectory="."
         nativeTypeName="ORDRSECR-PUT-HIST-HEAD"
         xmlEleName="OrderHistoryHeader" lowerBound="1" upperBound="1">
        <ItemSelectionArray>
          <ItemSelection itemName="ORDRSECR-PUT-HIST-HEAD.SECURITY-CODE"/>
          <ItemSelection itemName="ORDRSECR-PUT-HIST-HEAD.CUSTOMER-ID"/>
          <ItemSelection itemName="ORDRSECR-PUT-HIST-HEAD.CUSTOMER-FIRSTNAME"/>
          <ItemSelection itemName="ORDRSECR-PUT-HIST-HEAD.CUSTOMER-LASTNAME"/>
        </ItemSelectionArray>
      </InputMessage>


      <InputMessage importFile="ORDRRECS.cpy" importDirectory="." 
         nativeTypeName="ORDRRECS-HIST-RECORD"
         xmlEleName="OrderHistoryRecord" lowerBound="1" upperBound="255">
        <ItemSelectionArray>
          <ItemSelection itemName="ORDRRECS-HIST-RECORD.ORDER-DATE"/>
          <ItemSelection itemName="ORDRRECS-HIST-RECORD.ORDER-ITEM-ID"/>
          <ItemSelection itemName="ORDRRECS-HIST-RECORD.ORDER-ITEM-PRICE"/>
          <ItemSelection itemName="ORDRRECS-HIST-RECORD.ORDER-ITEM-QTY"/>
          <ItemSelection itemName="ORDRRECS-HIST-RECORD.ORDER-ITEM-DESC"/>
        </ItemSelectionArray>
      </InputMessage>
      <OutputMessage ../>
      <XseSpec>
        <XsdSpecIn xsdEleName="PutOrderHistoryRequest"
                   targetNamespace="http://www.ibm.com/schemas/weborders"
                   fileName="PutOrderHistory.xsd"/>
        <XsdSpecOut  ../>
      </XseSpec>
    </Operation>

Specification of Multiple Response Language Structures

Edit online

If an enterprise applications' output interface is comprised of multiple language structures, it is necessary to include each of them in the response message that clients receive when the application is invoked as a Web service. To direct the Enterprise Service Tools Batch processor to incorporate multiple language structures into the XML Schema (XSD) for the response message—specify multiple, sibling, OutputMessage elements. The order in which the OutputMessage elements are specified determines the order that their equivalent XSD definitions appears in the composite response XSD.

To further customize the response XSD, attributes on the OutputMessage element can be specified. These attributes are:
  • xmlEleName - name of the XML element mapped to instances of the language structure
  • lowerBound - minimum repetitions of the language structure
  • upperBound - maximum repetitions of the language structure
See OutputMessage for the complete description of the OutputMessage attributes.

Figure 12 demonstrates how to direct the Enterprise Service Tools Batch processor to incorporate multiple language structures when generating the XSD for the response message of a Web service.

Note: Generation of XML Conversion artifacts is only supported for the IMS SOAP Gateway runtime when multiple language structures are specified.
Figure 12. Example of Specifying Multiple Language Structures for the Response Message 
    <Operation name="GetOrderHistory">
      <InputMessage ../>

      <OutputMessage importFile="ORDRSECR.cpy" importDirectory="."
         nativeTypeName="ORDRSECR-GET-HIST-HEAD"
         xmlEleName="OrderHistoryHeader" lowerBound="1" upperBound="1">
        <ItemSelectionArray>
          <ItemSelection itemName="ORDRSECR-GET-HIST-HEAD.CUSTOMER-ID"/>
        </ItemSelectionArray>
      </OutputMessage>

      <OutputMessage importFile="ORDRRECS.cpy" importDirectory="." 
         nativeTypeName="ORDRRECS-HIST-RECORD"
         xmlEleName="OrderHistoryRecord" lowerBound="1" upperBound="255">
        <ItemSelectionArray>
          <ItemSelection itemName="ORDRRECS-HIST-RECORD.ORDER-DATE"/>
          <ItemSelection itemName="ORDRRECS-HIST-RECORD.ORDER-ITEM-ID"/>
          <ItemSelection itemName="ORDRRECS-HIST-RECORD.ORDER-ITEM-PRICE"/>
          <ItemSelection itemName="ORDRRECS-HIST-RECORD.ORDER-ITEM-QTY"/>
          <ItemSelection itemName="ORDRRECS-HIST-RECORD.ORDER-ITEM-DESC"/>
        </ItemSelectionArray>
      </OutputMessage>

      <OutputMessage importFile="ORDRSECR.cpy" importDirectory="." 
         nativeTypeName="ORDRSECR-HIST-SUMMARY"
         xmlEleName="OrderHistoryTail" lowerBound="1" upperBound="1">
        <ItemSelectionArray>
          <ItemSelection itemName="ORDRSECR-HIST-SUMMARY.TOTAL-ORDERS"/>
          <ItemSelection itemName="ORDRSECR-HIST-SUMMARY.TOTAL-SPENT"/>
          <ItemSelection itemName="ORDRSECR-HIST-SUMMARY.REPORT-DATE"/>
          <ItemSelection itemName="ORDRSECR-HIST-SUMMARY.REPORT-TIME"/>
        </ItemSelectionArray>
      </InputMessage>      
      </OutputMessage>
      <XseSpec>
        <XsdSpecIn  ../>
        <XsdSpecOut xsdEleName="GetOrderHistoryResponse"
                    targetNamespace="http://www.ibm.com/schemas/weborders"
                    fileName="GetOrderHistory.xsd"/>
      </XseSpec>
    </Operation>

Generation of composite XML schemas from multiple language structures

Edit online

This topic describes how composite XML Schemas are generated by the Enterprise Service Tools batch processor when multiple language structures are specified for the request and response interfaces of an enterprise application program. The InputMessage and OutputMessage elements of the ServiceSpecification.xml file are used to specify each language structure for the request and response messages respectively.

The Enterprise Service Tools batch processor takes the following steps to generate a composite XML Schema (assume just the request/input message for these steps):
  1. Each InputMessage element is processed and the referenced language structure (nativeTypeName) is converted into an equivalent complex type and stored in the request XML Schema. The name of each generated complex type is not settable.
  2. For each complex type created in step 1, an XML element is defined and stored in the request XML Schema. The minOccurs and maxOccurs attributes of each XML element are set to the values of the lowerBound and upperBound attributes of the corresponding InputMessage element. The name of each XML element is set to the value of the xmlEleName attribute in the respective InputMessage element. If the xmlEleName attribute is not specified or its value is non-unique with respect to other InputMessage elements, a generated name is used.
    Note: When the IMS Enterprise Suite SOAP Gateway Web service wizard is used, the xmlEleName attribute is never specified
  3. Once a complex type and an XML element has been defined for each language structure, a single, top-level complex type is defined that contains all the XML elements in the same order as they appeared in the series of InputMessage elements.
    Note: When the IMS Enterprise Suite SOAP Gateway Web service wizard is used, the order of the InputMessage element series is determined by the layout specified on the “IMS Message Layouts” page.
  4. A global XML element is defined whose type is the top-level complex type created in step 3. The name of the global element is set to the value of the XsdSpecIn/@xsdEleName attribute.
    Note: A generated named is used when the xsdEleName attribute is not specified.

Table 2 illustrates the specification of multiple InputMessage elements and the resulting composite XML Schema.

Table 2. Example of a Composite XML Schema Resulting from the Specification of Multiple InputMessage Elements
ServiceSpecification.xml Composite XML Schema 
<InputMessage 
  nativeTypeName="REQ-HEADER"
  xmlEleName="RequestHeader"
  lowerBound="1" upperBound="1">
  <ItemSelectionArray ../>

<InputMessage
  nativeTypeName="REQ-BODY"
  xmlEleName="REQ-BODY"
  

lowerBound="1"upperBound="10">
  <ItemSelectionArray ../>
</InputMessage >


<InputMessage
  nativeTypeName="REQ-SUM"
  xmlEleName="RequestSummary"
  lowerBound="1" upperBound="1">
  <ItemSelectionArray ../>
</InputMessage >

<XsdSpecIn 
  xsdEleName="ServiceRequest" ../>

<complexType name="REQ_HEADER">
  <sequence ../>
</complexType>

<complexType name="REQ_BODY">
  <sequence ../>
</complexType>

<complexType name="REQ_SUM">
  <sequence ../>
</complexType>

<complexType   
  name="EIS_COMPOSITE_MESSAGE">
  <sequence>
    <element name="RequestHeader"
      type="p:REQ_HEADER"
      minOccurs="1" maxOccurs="1" />
    <element name="RequestBody"
      type="p:REQ_BODY"
      minOccurs="1" maxOccurs="10" />
    <element name="RequestSummary"
      type="p:REQ_SUMMARY"
      minOccurs="1" maxOccurs="1" />
   </sequence>
</complexType>

<element name="ServiceRequest"
  type="p:EIS_COMPOSITE_MESSAGE" >
</element>

Limitations and Error Conditions

This section describes the batch processor limitations and restrictions on generation of composite XML Schemas from collections of language structures.

Multiple InputMessage and OutputMessages are not allowed if mapping files are specified instead of language source files (that is, meet-in-middle is not supported since this function deals with generation of XSDs).

Multiple InputOutputMessage elements are not supported. Use multiple InputMessage and OutputMessage elements instead.

A language structure may not be specified more than once in a series of InputMessage or OutputMessage elements. This means that an XML Schema complex type derived from a language structure cannot reappear later in an XML message with identical or different field level inclusions and/or exclusions.

All language structures specified on InputMessage and OutputMessage elements (nativeTypeName) must have unique names regardless of the language source file (importFile) they reside in.

All XML element names specified on InputMessage and OutputMessage elements (xmlEleName) must be unique with respective to the other InputMessage or OutputMessage elements. It is not an error to have a XML element name that appears both in a series of InputMessage and OutputMessage elements.

Important: Inter-language structure dependencies are not supported.

For example, an OCCURS DEPENDING ON (ODO) subject cannot refer to an ODO object in another structure.