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

  • Header Block Content
    This section describes the header block content of QDocs. The information in this section applies to both QDoc specification versions, except where indicated.
    Each QDoc header block consists of a root element QDoc containing the elements described in this section. Header blocks may also contain several other attributes:
    In SOAP 1.0 the role attribute may have any legal URI as its value. In SOAP 1.1 this attribute is replaced with the actor attribute.
    In SOAP 1.0 the mustUnderstand attribute is Boolean. In SOAP 1.1 this attribute has a value of either 1 (true) or 0 (false). The absence of the SOAP mustUnderstand attribute is semantically equivalent to its presence with the value “0”.
    Both of these attributes are ignored on inbound QDocs.
    The encodingStyle attribute is a URI, and is set to the following value on all outbound QDoc header blocks:
    http://www.w3.org/2002/12/26/soap-encoding
    This attribute is not used in SOAP 1.1 QDocs.
    While more than one header block inside a single message is syntactically allowed, in the case of inbound QDocs all QDoc headers after the first one are ignored. All outbound QDocs contain only a single QDoc header block.
    Requestor Element
    Note: The requestor element in SOAP 1.1 QDocs has been moved from the header block to dsSessionContext along with requestor password. For details see Session Context.
    The requestor element can contain user ID and password attributes. If authentication credentials are provided in the QDoc, QXI will always use these credentials to verify the QDoc regardless of the setting of useQDocRequestor. This helps in situations where the application needs a detailed audit trail by user, but you do not want to require all QDocs to have authentication information in them.
    You should note the following:
    If useQdocRequestor is set to false and user name and password nodes are specified in the QDoc, QXI will use them for authentication. If the nodes are not specified, QXI will use the user name/password combination in the connection pool setting for authentication. If you do not want Inbound to use the user name and password in QDoc, you have to remove the nodes from QDoc.
    If useQdocRequestor is set to true, QXI always uses the user name and password in the request QDoc.
    Note: In previous versions, QXI used the credentials in the QDoc only if useQDocRequestor was enabled; otherwise the credentials specified in the connection pool were used.
    For XML syntax 1.1 QDocs, if the username and password should not be used in the request, the following nodes must be removed from QDoc:
    <qcom:ttContext>
    <qcom:propertyQualifier>QAD</qcom:propertyQualifier>
    <qcom:propertyName>username</qcom:propertyName>
    <qcom:propertyValue/>
    </qcom:ttContext>
    <qcom:ttContext>
    <qcom:propertyQualifier>QAD</qcom:propertyQualifier>
    <qcom:propertyName>password</qcom:propertyName>
    <qcom:propertyValue/>
    </qcom:ttContext>
    For XML syntax 1.0 Qdocs, if the username and password should not be used in the request, the following nodes must be removed from QDoc:
    <requestor/>
    If the current request QDoc sent from a product has empty user name and password, these must be removed from the QDoc. If they are not removed, QXI will use them for authentication and return the error Invalid Username and Password.
    This password is sent in text form, encrypted within the server, and is encrypted in any response QDocs.
    The requestor element can be omitted from the header if the QXtend implementation does not require user ID and password.
    Note: At the receiver level you can specify that every QDoc that is for a receiver must have authentication information in it. For details see Adding Inbound Receivers.
    sessionId
    Note: The information in this section applies only to the 1.1 specification and QAD EE.
    If a valid QAD Enterprise Application session ID is provided in the QDoc, the QDoc can pass authentication without having the username and password checked. The system also caches and reuses the session ID provided in the response QDoc to further speed up authentication and improve performance. If the session ID is no longer valid, the system checks the username and password.
    For FinAPI connections, you can control whether the system caches the session ID. To do this, edit the qxtendconfig.xml file located in TOMCAT_HOME/ webapps /<QXI webapp> / WEB-INF/conf. Locate the node containing:
    cacheFinSession = “true”
    To allow the system not to cache the session ID, change this to:
    cacheFinSession = “false”
    Note: Caching session IDs enhances throughput of QDocs, but may result in failure of Financials transactions in some circumstances.
    senderId
    Note: In the QDoc 1.1 specification Web Services Addressing (WS-Addressing) is used and consequently there is no senderId (or receive311rId). The information in this section applies only to the 1.0 specification.
    The senderId element identifies the sender of the QDoc or other document and is defined as a URI.
    While most of the URI is not yet used, it must include the query parameter sender in order to identify the sending entity within a given installation. The syntax of the query parameters is similar to that commonly used with any URI, as in the following example:
    http://anyBaseURI/path1/path2?sender=myCompany&amp;…
    The ampersand character separating the query parameters must be written as &amp; in order to pass XML well-formedness parsing rules.
    In the case of outbound documents sent by Q/LinQ, sender is always equal to the Q/LinQ System ID (@SYSID tag) maintained in the Q/LinQ System Control table. This tag must have the same value as the configuration parameter used by the QDoc server to identify a given QAD Enterprise Applications database in a multi-database installation.
    In the case of inbound documents, sender is stored in the Q/LinQ trading partner ID (@TRADPTRID tag) field. The trading partner ID identifies the external owner of the QAD Enterprise Applications object about which Q/LinQ is being notified.
    receiverId
    Note: The receiverId element has been removed in the 1.1 QDoc specification. In QDoc specification 1.0 the receiver was passed as a parameter in the URL in the receiverId node. In QDoc specification 1.0 the receiver is now the third entry in the URN of the To node:
     
    <ns0:To xmlns:ns0="http://www.w3.org/2005/08/addressing">urn:services-qad-com:QADSE</ns0:To>
    receiverId in QDoc Specification 1.0
    The receiverId element identifies the receiver of the QDoc or other document and is defined as a URI.
    While most of the URI is not yet used, it must include the query parameters connection and receiver in order to identify the receiving entity within a given installation. The syntax of the query parameters is similar to that commonly used with any URI, as in the following example:
    http://anyBaseURI/path1/path2?connection=yourQueue&amp;receiver=yourCompany&amp;…
    In addition, the URI can also include the optional query parameter domain in order to identify the receiving domain within the QAD Enterprise Applications database.
    Note: In the QDoc 1.1 specification the parameter domain has been moved from receiverId to dsSessionContext as a propertyName of domain. For details see Session Context.
    The syntax of this query parameter is shown in the following example:
    http://anyBaseURI/path1/path2?connection=yourQueue&amp;receiver=yourCompany&amp;domain=yourdomain&amp;
    If this optional parameter is omitted, the QDoc will use the domain that is specified in the Domain field in the Connection Pool Manager for that procedure. See Configuring Connection Pools.
    In the case of outbound documents sent by Q/LinQ, the receiver is the Q/LinQ trading partner ID (@TRADPTRID tag) for which the export document was published. In many cases, this value corresponds to the external owner of the QAD Enterprise Applications data object that is the main subject of the document. The connection is the Q/LinQ application ID (@APPID tag) through which the document was sent.
    In the case of Q/LinQ inbound documents, the receiver must be set to the Q/LinQ System ID (@SYSID tag) field maintained in the Q/LinQ System Control table, which in turn must be the same as the identifier used in the QDoc server to identify the target QAD Enterprise Applications database. However, it is ignored by the current version of Q/LinQ, as each Q/LinQ installation is associated with one and only one QAD Enterprise Applications database and cannot properly route documents to any other QAD Enterprise Applications database. The connection is defined by the sender, but is mapped by Q/LinQ to the Q/LinQ application ID (@APPID tag) through which the document is received.
    senderDocumentId
    The senderDocumentId element is the sender’s locally unique identifier for the QDoc, meaningful to the sender’s messaging software but not necessarily to the source application. It is required and must be referenced in the originalDocumentRef field on QDoc confirmations so that the receiver of the confirmation—the sender of the original document—can unambiguously identify the document being confirmed.
    The senderDocumentId element is the Q/LinQ internally assigned document ID. It is not significant outside of Q/LinQ, but it provides a potentially useful cross-reference back to the Q/LinQ database.
    Note: This element has been removed in the 1.1 QDoc specification. In this specification each message uses MessageID to convey the MessageID property:
     
    <ns0:MessageID xmlns:ns0="http://www.w3.org/2005/08/addressing">urn:messages-qad-com::2007-02-08T14:10:11.424-08:00:QADSE:</ns0:MessageID>
    documentStandard
    The documentStandard element is intended to identify the standard or specification, if any, to which the document conforms. This could be an externally published standard such as EDIFACT, OAGIS, ANSI X12, or UCCnet. It could also be an internal identifier for a proprietary grammar used at one particular installation, for those QAD application users who have defined standard business objects for use inside their enterprise.
    The special value QDoc is reserved by QAD to designate QDocs. documentStandard is an optional element.
    This element is exactly equivalent to the Q/LinQ document standard or @DOCSTD document control tag. As with Q/LinQ, the special value cim is reserved by QAD to designate documents that can be processed by the QAD Enterprise Applications CIM Interface or the UI-emulation mode of Q/LinQ.
    Note: In the QDoc 1.1 specification the documentStandard element has been moved into the SOAP header ReferenceParameters section.
    documentType
    The documentType element identifies the type of document contained in the message payload (that is, the SOAP Body), and is used to route inbound documents to the appropriate handler for processing. It is semantically equivalent to a message type, action, or service designator. It is an optional element, and may be assigned a default value by the QAD Integration Framework based on the needs of the installation.
    For QDocs, this element should be set to the name of the QDoc; for example, maintainSalesOrder.
    This element is exactly equivalent to the Q/LinQ document type or @DOCTYP document control tag. For documents with a documentStandard of cim, it should be set to the name of the QAD Enterprise Applications program called to process the document.
    Note: In the QDoc 1.1 specification the documentType element has been moved into the SOAP header ReferenceParameters section.
    documentVersion
    The documentVersion element qualifies the documentType with a version or revision designator that permits different variations of the same type of document to be distinguished for special handling. For documents conforming to an externally published standard, such as EDI, it is set to the version or revision level designator assigned by the published standard.
    If documentVersion is omitted, it is presumed to designate the most current commercial or public version of the associated document type. When used with internal, less formal document grammars that do not use any form of version control, it would be omitted.
    For QDocs, this element should be set to the version attribute of the QDoc; for example, eB_1.
    This element is exactly equivalent to the Q/LinQ document revision or @DOCREV document control tag.
    Note: In the QDoc 1.1 specification the documentVersion element has been moved into the SOAP header ReferenceParameters section.
    confirmationLevel
    The confirmationLevel element designates under what circumstances a QDoc Confirmation document is requested. Allowed values are none, error, or all.
    This element has exactly the same meaning as the present Q/LinQ tag @ACKLVLREQD.
    Note: The confirmationLevel element has been removed in the QDoc 1.1 specification.
    dateTimeCreated
    The dateTimeCreated element contains the date- and time-stamp for the creation of the document, expressed using the DateTime type prescribed by XML schema. For example, the following value would apply to a document created on July 1, 2002, at 9:00am Pacific Standard Time:
    2002-07-01T09:00:00-0800
    This element has exactly the same meaning as the present Q/LinQ tags @DATECREATE, @TIMECREATE, and @TIMEZONE in combination.
    Note: The dateTimeCreated element has been removed in the QDoc 1.1 specification.
    senderDocumentRef
    The senderDocumentRef is a flexible-format, multi-occurrence string providing a reference back to the sending application. It is not necessarily unique and serves only to provide a meaningful reference for application end users, as opposed to the senderDocumentId used only for document matching purposes. Accordingly, it should be assigned to one or more values that represent the key fields of the application data objects most closely associated with the document.
    For example, in the case of a sales order document it might contain the sales order number. In the case of inventory balances, it might contain the SKU number of the material as well as the identifier of the warehouse/facility in which the material is stored.
    Q/LinQ populates only two occurrences of this field per document at most. If the corresponding QAD Enterprise Applications data object has a primary site code associated with it, as in the case of inventory, the first occurrence is set to the QAD Enterprise Applications site (@MFGPROSITE) tag and the second occurrence to the QAD Enterprise Applications key (@MFGPROKEY) tag. Otherwise, the first occurrence is set to the QAD Enterprise Applications key (@MFGPROKEY) tag.
    Note: The senderDocumentRef element has been removed in the QDoc 1.1 specification.
    receiverDocumentRef
    The receiverDocumentRef is a flexible-format, multi-occurrence string providing a reference back to the receiving application. It is not necessarily unique and serves only to provide a meaningful reference for application end users. It is analogous to the senderDocumentRef field, and should be assigned to one or more values that represent the key fields of the application data objects most closely associated with the document.
    In most cases, this field is omitted from the message envelope, as the sender application or messaging agent would not normally have a meaningful document reference expressed in terms of the receiver. However, it may be useful for follow-up messages in which two applications are engaged in a long-running dialog about data objects known to both. For example, QAD Enterprise Applications might use this field on a shipment notification to reference an external sales order number and line.
    Q/LinQ expects only two occurrences of this field per document at most:
    If the corresponding QAD Enterprise Applications data object has a primary site code associated with it, as in the case of inventory, the first occurrence is assumed to be a site code and is stored in the QAD Enterprise Applications site (@MFGPROSITE) tag.
    The second occurrence is assumed to be some other key field and is stored in the QAD Enterprise Applications key (@MFGPROKEY) tag. Otherwise, the first occurrence is stored in the QAD Enterprise Applications key (@MFGPROKEY) tag.
    Note: The receiverDocumentRef element has been removed in the QDoc 1.1 specification.