In order to bring you the best possible user experience, this site uses Javascript. If you are seeing this message, it is likely that the Javascript option in your browser is disabled. For optimal viewing of this site, please ensure that Javascript is enabled for your browser.
Login  |   Cloud ERP  |   Home  |   qad.com



  •     QAD Glossary

  • QDoc Schema 1.1
    For QDoc syntax specification 1.1 one schema is created. For the first version of maintainSalesOrder QDoc on QAD EE, this would be titled maintainSalesOrder-eB2_2.xsd.
    QGen combines the name of the QDoc with the target QAD Enterprise Applications version to create the file names.
    Flat Structure
    Schemas defined in the 1.0 Qdoc standard use multiple levels of include and import elements to allow a level of abstraction and make it easier to read and analyze the schemas. Because Progress OpenEdge has problems importing some XML schemas in this format, Qdoc schemas in the 1.1 standard use a flat structure resulting in schemas being self-contained.
    Complex Types
    In the 1.1 specification, the complexContent and extension elements have been removed. The annotation and documentation elements also have been removed due to a restriction in the number of annotations that can be read from a schema.
    <complexType name={name}>
    <sequence>
    <element name={element name} type={type}/>
    <sequence>
    </complexType>
    Keys and Relationships
    In the 1.0 QDoc standard relationships between tables cannot be defined, only inferred. Primary keys for each iteration are stored in the complexType element.
    To create datasets from XML schema, primary keys and relationships must be defined in the schema. Standard XML schema notation is defined as:
    <unique name=”PK_{complex type name}”/>
    <selector xpath=”.//{complex type name}”/>
    <field xpath=”{primary key field name}”/>
    </unique>
    Multiple primary key fields are defined by adding more field elements. Relationships between tables are defined as:
     
    <keyref name=”{complex type name}” refer=”qdoc:{unique name of parent}” prodata:nested=”true”>
    <selector xpath=”.//{child complex type name}”/>
    <field xpath=”{common field name}”/>
    </keyref>
    The name attribute of keyref is only used by .NET when building datasets—OpenEdge does not require it.
    To support relationships such as these, the primary key of the parent table must also be included in the child table. This is not the case with the 1.0 Qdoc standard.
    Transaction Comments
    The XML schema for the transaction comments resides in
    qdocCommon-eB_1.xsd. With the 1.1 schemas having a flat structure, this file is no longer required to be accessible.
    In 1.0 the iteration names for the transaction comments always started with transComment. To be able to create a dataset from a schema, for each iteration—equivalent to a table—the name must be unique. Therefore all node names of transComment now have a prefix of the parent table name. For example, transaction comments for the <salesOrder> node is now <salesOrderTransComment>.
    Session Context
    In the QDoc 1.1 syntax specification, session context information is not included in the schema of each QDoc. This is due to a limitation when creating dataset schema from an XML schema that it cannot have a nested dataset.
    Consequently the session context schema is excluded from the QDoc schema but included in the WSDL. Automated tools to generate datasets from XML schema to create QDocs using standard Progress features must take into account that the session context must be added separately.
    dsSessionContext has the following structure:
     
    <dsSessionContext>
    <ttContext>
    <propertyQualifier/>
    <propertyName/>
    <propertyValue/>
    </ttContext>
    </dsSessionContext>
    Application-specific parameters are now passed as part of the dsSessionContext structure. This structure includes the following attributes:
    domain. Domain has been moved to dsSessionContext as a property name of domain. Previously it was a parameter in the URL in the receiverId.
    scopeTransaction. This attribute has been added to dsSessionContext as a property name of scopeTransaction. For details see scopeTransaction.
    documentVersion. This attribute has been moved to dsSessionContext as a property name of version. Previously it was part of the root node. For details see documentVersion.
    mnemonicsRaw. This attribute has been added to dsSessionContext as a property name of mnemonicsRaw. For details see mnemonicsRaw.
    Requestor id. This attribute of requestor has been moved to dsSessionContext as a property name of username. For details see Requestor Element.
    Requestor password. This attribute of requestor has been moved to dsSessionContext as a property name of password. For details see Requestor Element.
    Arrays. For details see Array Representation.
    Note: For Service Interface APIs, the session context is returned to the caller. This helps to speed up processing, since the session context will contain the Session ID code, and this can be extracted from the response and re-used in subsequent requests. Username/password authentication is slightly slower than when providing a valid Session ID code in the request.