| To edit XML Schema Files (BOR) |  |
| This document describes how XML Schema's that make up the arguments of the methods of a business object must be edited. Introduction If you generate a method or save a method you created manually, XML Schema Files are generated for the arguments of that method. These files actually store the arguments. Through the Generate XML Schema command in the specific menu of the Business Object Method Arguments (ttadv7113m000) session you can generate a filled XML Schema file. This file must however be edited manually, because not everything can be generated automatically. When a (filled) XML Schema is generated for a specific argument, the following actions are taken: The public attributes are added as separate declaration elements after the <RequestDataArea> group in the Schema file. The name information and domain information is stored. The business object is added as child of the RequestDataArea element. If components are present in the protected layer of the business object, the components are linked as child of the business object element. If components are present, the public attributes are added as child of the component element. If no components are present, the public attributes are added as child of the business object element. Note The component structure is not taken into account in this process. All components are placed at the same level below the business object element. Example of a filled XSD structure
    <xs:element name="CreateRequest" type="CreateRequestType"/>
    <xs:simpleType name="Attribute1DT">
        <xs:restriction base="xs:long">
            <xs:totalDigits value="10"/>
        </xs:restriction>
    </xs:simpleType>
    <xs:simpleType name="Attribute2DT">
        <xs:restriction base="xs:string">
            <xs:maxLength value="5"/>
        </xs:restriction>
    </xs:simpleType>
    <xs:simpleType name="Attribute3DT">
        <xs:restriction base="xs:string">
            <xs:maxLength value="9"/>
        </xs:restriction>
    </xs:simpleType>
    <xs:simpleType name="Attribute4DT">
        <xs:restriction base="xs:string">
            <xs:maxLength value="9"/>
        </xs:restriction>
    </xs:simpleType>
    <xs:simpleType name="Attribute5DT">
        <xs:restriction base="xs:string">
            <xs:maxLength value="9"/>
        </xs:restriction>
    </xs:simpleType>
    <xs:simpleType name="Attribute6DT">
        <xs:restriction base="xs:string">
            <xs:maxLength value="9"/>
        </xs:restriction>
    </xs:simpleType>
    <xs:simpleType name="Attribute7DT">
        <xs:restriction base="xs:string">
            <xs:maxLength value="9"/>
        </xs:restriction>
    </xs:simpleType>
    <xs:complexType name="CreateRequestType">
           <xs:sequence>
               <xs:element name="ControlArea" type="bo:CreateRequestControlArea" minOccurs="0"/>
               <xs:element name="DataArea" type="bo:CreateRequestDataArea"/>
           </xs:sequence>
        </xs:complexType>
    </xs:complexType>
    <xs:complexType name="CreateRequestDataAreaType">
        <xs:sequence>
            <xs:element name="BusinessObject" type="CreateRequestBusinessObjectType"/>
        </xs:sequence>
    </xs:complexType>
    <xs:complexType name="CreateRequestBusinessObjectType">
        <xs:sequence>
            <xs:element name="Component1" type="CreateRequestComponent1Type"/>
            <xs:element name="Component2" type="CreateRequestComponent2Type"/>
        </xs:sequence>
    </xs:complexType>
    <xs:complexType name="CreateRequestComponent1Type">
        <xs:sequence>
            <xs:element name="Attribute1" type="Attribute1DT" minOccurs="0"/>
            <xs:element name="Attribute2" type="Attribute2DT" minOccurs="0"/>
            <xs:element name="Attribute3" type="Attribute3DT" minOccurs="0"/>
        </xs:sequence>
    </xs:complexType>
    <xs:complexType name="CreateRequestComponent2Type">
        <xs:sequence>
            <xs:element name="Attribute4" type="Attribute4DT"/>
            <xs:element name="Attribute5" type="Attribute5DT" minOccurs="0"/>
            <xs:element name="Attribute6" type="Attribute6DT" minOccurs="0"/>
            <xs:element name="Attribute7" type="Attribute7DT" minOccurs="0"/>
        </xs:sequence>
    </xs:complexType>
    <xs:complexType name="CreateRequestControlArea">
           <xs:sequence>
               <xs:element name="ApplicationControlData" type="bo:CreateRequestApplicationControlData" minOccurs="0"/>
               <xs:element name="processingScope" type="bo:processingScopeDT" default="request" minOccurs="0"/>
           </xs:sequence>
    </xs:complexType>
    <xs:complexType name="CreateRequestApplicationControlData">
           <xs:sequence/>
        </xs:complexType>
        <xs:simpleType name="processingScopeDT">
            <xs:restriction base="xs:string">
                 <xs:enumeration value="not_applicable"/>
                 <xs:enumeration value="request"/>
                 <xs:enumeration value="business_entity"/>
                 <xs:enumeration value="business_entity_component"/>
            </xs:restriction>
    </xs:simpleType>
Manual Corrections The generated XML Schema's require manual correction, because not everything can be done automatically, and not every attribute is important for external connections. The changes are related both to the structure and the content of the XML Schema's. The following sections detail the changes. Structure Important! The following rule is important for the structure of the XML Schema's. All components of the business object must be present in the XML Schema as group elements. For example, an element Order has a repeating sub-element Line. According to XSD rules, the attributes of the Header component can be linked directly to the Order element, and the repeating attributes of the Lines must be linked to the repeated Line element. The sub-element Header can be inserted to map the order specific attributes to the Header component. Refer to the following figures for a visualisation of the differences. Both constructions are allowed, but the first one is given preference to.
Business object "Order", valid according to XSD rules
Order | orderNumber |
| businessPartner |
| country |
| Line* | lineNumber
|  | quantity
|  | unitOfMeasure
Business object "Order", valid according to specified rule
Order | Header | orderNumber
|  | businessPartner
|  | country
| Line* | lineNumber
|  | quantity
|  | unitOfMeasure
General Checks The following changes are required for all methods. For a repeating element, the maxOcc property/attribute must be set to unbounded. For grouping elements of mandatory components, the minOcc property/attribute must be set to one. For grouping elements of non-mandatory components, the minOcc property/attribute must be set to zero. Identifying fields which are already defined in the parent component must be removed from the elements that belong to a sub-component. For example, the attribute orderNumber, which is present in the Header element, must not be repeated in the Line element. Changes per Method The following sections describe the changes for each specific method. Create Change Delete List Show CreateRef DeleteRef Create For the request argument, the following changes are required: If the business object element is repeating, remove the groups that do not have a Create method in the business object of the corresponding component. If a sub-component is repeating and mandatory, move it to the right so that it is at the same level as the attributes of the parent component. Remove the following unnecessary attributes: Attributes that are filled by means of a DAL2 logic. All read-only attributes. All derived fields. Refer to the DAL2 hook fieldX.is.derived. Note that conditional derived fields can be left. For the response argument, the structure must be the same as for the request argument. However, depending on functional requirements, extra attributes can be required, which are filled with defaults by the application logic. Change Refer to the Create method. The Change method must have the same structure as the Create method, and can have the same attributes. Delete For the request argument, the following changes are required: If the business object element is repeating, remove the groups that do not have a Delete method in the business object of the corresponding component. If a sub-component is repeating and mandatory, move it to the right so that it is at the same level as the attributes of the parent component. Remove all attributes, except the identifying ones. For the response argument, the structure must be the same as for the request argument. However, depending on functional requirements, extra attributes can be required, which are filled with the table fields of the deleted business object. List For the request argument, you must remove from the filterAttributeList the attributes of related business objects that are selected by a Read method. Whether business objects are selected by a Read method can be checked in the List function of the st program script. You must also remove all other attributes that cannot be used in a filter (such as description type attributes). For the response argument, the following changes are required: If the business object element is repeating, set it to "Unbounded". If the component is a sub-component, move it to the right so that it is at the same level as the attributes of the parent component. If an element is not mandatory, set it to "Optional". Make sure that all mandatory elements are not set to "Optional". Note In the List method, the Response XSD reflects the structure of the business object. The Request XSD contains selection attributes and logic for the definition of filter conditions with the attributes of the business object. Show For the request argument, you must remove from the filterAttributeList the attributes of related business objects that are selected by a Read method. Whether business objects are selected by a Read method can be checked in the Show function of the st program script. You must also remove all other attributes that cannot be used in a filter (such as description type attributes). For the response argument, the following changes are required: If the component is a sub-component, move it to the right so that it is at the same level as the attributes of the parent component. If an element is not mandatory, set it to "Optional". Make sure that all mandatory elements are not set to "Optional". Note The Show method is closely related to the List method. Only, the Show method retrieves just one occurrence of the business object, and optionally several occurrences of the sub components, if these are available. CreateRef For the request argument, the following changes are required: If the business object element is repeating, remove the groups that do not have a CreateRef method in the business object of the corresponding component. If a sub-component is repeating and mandatory, move it to the right so that it is at the same level as the attributes of the parent component. Remove all attributes, except the following ones: The identifying attributes. For the response argument, the structure must be the same as for the request argument, and only the attributes of the request argument must be used. No other attributes are required, because the methods only operates on the reference table, and not on the other tables of the business object. Extra arguments can only be used if extra read actions are added in the DAL of the reference table. DeleteRef For the request argument, the following changes are required: If the business object element is repeating, remove the groups that do not have a DeleteRef method in the business object of the corresponding component. If a sub-component is repeating and mandatory, move it to the right so that it is at the same level as the attributes of the parent component. Remove all attributes, except the identifying attributes. For the response argument, the structure must be the same as for the request argument. The attributes of the reference table can be used. Extra arguments can only be used if extra read actions are added in the DAL of the reference table. Related topics To Model a Business Object How to test protected methods for Infor ERP LN How to test public methods for Infor ERP LN |