The QAD MFG/PRO data handler performs transformations between QAD MFG/PRO messages and business objects in the following ways:
The sections below describe:
The rules below apply when the QAD MFG/PRO data handler's mapping engine converts triplet messages to QDoc XML:
<orderQuantity xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:enc="http://www.w3.org/2002/12/soap-encoding" xmlns:qcom="http://www.qad.com/qdoc/common" enc:itemType="xsi:decimal" enc:arraySize="6" > <!-- Entries 1, 3 are set to empty and 4, 6 are skipped --> <qcom:entry index="1"/> <qcom:entry index="2">10.583</qcom:entry> <qcom:entry index="3"/> <qcom:entry index="4" skip=ìtrueî/> <qcom:entry index="5">22</qcom:entry> <qcom:entry index="6" skip="true">ignore!</qcom:entry> </orderQuantity>
In order to accomplish the mapping, triplet data from the parent
table is mapped to the highest-level XML element inside the QDoc.
Data from the child table triplets are mapped to lower-level child
elements. However, the QDoc XML data is represented in a
structured, de-normalized fashion, with elements for the common
keys in the parent and removed from the child elements. Such
redundant foreign keys are unnecessary in XML, in which the
parent-child relationship is implicit in the structured nesting of
elements. The mapping algorithm recognizes the common key fields
for each MFG/PRO table at run-time. If the Triplet document updates
child, rather than parent, table records, the common key values are
moved from the child XML element to the parent XML element in the
resulting QDoc. Mapping of fields representing common keys that
appear in the triplet at the child table level is performed by
replacing the child table prefix with the parent table prefix. By
MFG/PRO convention, all field names have a prefix that is an
abbreviation for the database table name, followed by an underscore
character, followed by one or more underscore-delimited tokens that
together identify the field. Common keys across parent and child
tables always have the same field name, except for the
table-specific prefix. For example, the costSimulation
(sct_det) fields equivalent to the spt_det
foreign key fields are sct_sim for spt_sim,
sct_part for spt_part, and sct_site for
spt_site.
The rules described for triplet-to-QDoc processing are applied during runtime and guided by mapping metadata. The mapping logic resides in the OutboundMappingClass, which is also a child attribute in the QADDataHandlerMO, and the metadata resides in the mapFile, which is a child of the OutboundMappingMO. The mapFile is an XML file containing metadata that:
Table 8 below describes this information, which is stored in the mapFile.
Table name | QDoc name | BO name | Parent object | Foreign keys |
---|---|---|---|---|
ac_mstr | maintainAccount | account | ||
an_mstr | maintainAnalysisCode | analysisCode | ||
anl_det | maintainAnalysisCode | analysisCodeLink | analysisCode | anl_type, anl_code |
ans_det | maintainAnalysisCode | analysisCodeSelection | analysisCode | ans_type, ans_code |
bom_mstr | maintainBillOfMaterial | billOfMaterial | ||
cc_mstr | maintainCostCenter | costCenter | ||
ccd1_det | maintainCostCenter | costCenterAcct Validation | costCenter | ccd1_cc |
ccd2_det | maintainCostCenter | costCenterSubacct Validation | costCenter | ccd2_cc |
cd_det | maintainMasterComments | masterComment | ||
cm_mstr (published with related ad_mstr data) |
maintainCustomer | customer | ||
ad_mstr (also accessed to synchronize customers, suppliers) |
maintainAddress or maintainCustomer or maintainSupplier | |||
ls_mstr (also accessed to synchronize customers, suppliers; synchronized independently only for non-MFG/PRO address types) |
maintainAddressList | addressList | ||
code_mstr | maintainCode | code | ||
cp_mstr | maintainCustomerItem | item | ||
cs_mstr | maintainCostSet | costSet | ||
cu_mstr | maintainCurrency | currency | ||
dpt_mstr | maintainDepartment | department | ||
en_mstr | maintainEntity | entity | ||
exr_rate | maintainExchangeRate | exchangeRate | ||
fcs_sum | maintainForecastSummary | forecastSummary | ||
glc_cal | maintainGeneralLedger Calendar | generalLedger Calendar | ||
is_mstr | maintainInventoryStatus | inventoryStatus | ||
isd_det | maintainInventoryStatus | inventoryStatus | inventorySta tus | |
pc_mstr | maintainPurchasingPrice List | purchasingPriceList | ||
pi_mstr | maintainPriceList | priceList | ||
pid_det | maintainPriceList | priceListDetail | priceList | |
pl_mstr | maintainProductLine | productLine | ||
ps_mstr | maintainProductStructure | productStructure | ||
pt_mstr | maintainItem | item | ||
ro_det | maintainRoutingOperation | routingOperation | ||
sb_mstr | maintainSubAccount | subAccount | ||
sbd_det | maintainSubAccount | subAccountDetail | subAccount | |
si_mstr | maintainSite | site | ||
sct_det | maintainCostSimulation | costSimulation | ||
spt_det | maintainCostSimulation | costSimulationItem | costSimula tion | |
um_mstr | maintainAlternateUnitOf Measure | alternateUnitOf Measure | ||
vd_mstr (published with related ad_mstr data) |
maintainSupplier | supplier | ||
vp_mstr | maintainSupplierItem | supplierItem | ||
wc_mstr | maintainWorkCenter | workCenter |
The following sample fragment shows how the metadata in mapFile maps items:
<!-- Master table record - no parent --> <record name="ac_mstr"> <qdoc name ="maintainAccount" version="1.0"/> <bo> account</bo> </record> <!-- child table record ñ parent and foreign keys required --> <record name= "anl_det" > <qdoc name = "maintainAnalysisCode" /> <bo> analysisCodeLink </bo> <parent>an_mstr</parent> <fkey>anl_type</fkey> <fkey>anl_code</fkey> </record> <!-- Customer Master table record - no parent --> <record name= "cm_mstr"> <qdoc name="maintainCustomer" /> <bo> customer </bo> </record> <!-- Address master table record --> <record name= "ad_mstr" > <qdoc name="maintainAddress" version="1.1"/> <bo>address</bo> </record> <!-- exception cases mapping --> < record name= "customer" > <qdoc name="maintainCustomer" /> <bo> customer </bo> </ record > < record name= "customeraddress"alias="ad_mstr" > <qdoc name="maintainCustomer" /> <parent>customer</parent> </ record > < record name= "ship-toaddress" > <qdoc name="maintainCustomer" /> <parent>customer</parent> <bo>shipToAddress</bo> </record> <exit_on_error> <bo> customer</bo> <bo> analysisCodeLink </bo> </exit_on_error>
The exception cases in the fragment are mapped using the same syntax as that for the regular records. The difference is that the triplet token is specified instead of the table name. The alias attribute will contain the actual table name and will be used to retrieve the prefix for building the corresponding QDoc element names. For primary customer and supplier addresses, no business object name is specified. This forces the address fields to appear within the customer and supplier fields at the same level.
The exit_on_error tag indicates whether the connector should shutdown when it encounters an error during the processing of the specified business object. By default, the connector ignores the such errors and continues event retrieval and processing.
Table 9 illustrates the mapping of the QDoc header elements to QAD MFG/PRO control tags in the triplet message header.
Table 9. QDoc-triplet header mapping
QDoc element | Description | Triplet content |
---|---|---|
senderId | Sender URI | @SYSID tag |
receiverId | Receiver URI | @TRADPTRID tag |
senderDocumentId | QAD MFG/PRO's internally assigned document ID | The senderDocumentId on QDocs must be referenced on QDoc Confirmation messages so that the QAD MFG/PRO application can cross -reference and confirm the original QDoc |
descriptor | Multiple-occurrence text string describing the type of document contained in the message. First occurrence: Document Standard Second occurrence: Document Type Third occurrence: Document Revision | Not used. |
confirmationLevel | Designates under what circumstances a QDoc Confirmation document is requested. Possible values are none, error, or all. | @ACKLVLREQD tag |
dateTimeCreated | Contains the date- and time-stamp for the creation of the document, expressed using the DateTime type prescribed by XML schema | Combination of the following triplet header tags: @DATECREATE, @TIMECREATE, and @TIMEZONE |
senderDocumentRef | Multiple occurrence (up to two occurrences) string providing a reference to the sending application | @MFGPROSITE (if specified)@MFGPROKEY |
receiverDocument Ref | Multi-occurrence string (up to two occurrences) providing a reference to the receiving application. | @MFGPROSITE (if specified)@MFGPROKEY |
This mapping data is stored in a text file that is referenced in the outbound mapping meta-object. The file's content is as follows:
senderId @SYSID receiverId @TRADPTRID senderDocumentId @DOCID confirmationLevel @ACKLVLREQD dateTimeCreated @DATECREATE:@TIMECREATE:@TIMEZONE senderDocumentRef @MFGPROSITE:@MFGPROKEY receiverDocumentRef @MFGPROSITE:@MFGPROKEY
Once the QDoc is retrieved, the QAD MFG/PRO data handler invokes the XML data handler to create the corresponding business object. The business object verb is based on the value of the corresponding operation tag in the QDoc:
For a full description of XML data handler processing, see the Data Handler Guide.
For request processing, the connector passes the request portion of a TLO to the QAD MFG/PRO data handler. The data handler calls the XML data handler to transform the header and body portions of the request into XML. It assembles these pieces together to build a SOAP-XML 1.2 message and returns it to the connector. The connector then makes an HTTP request to the QXtend web service and wait for a reply. The reply message is converted to a BO by the QAD MFG/PRO data handler, which again calls the XML data handler to do part of the work. This BO is put into the response attribute of the TLO, and the TLO is returned to the broker. If the QXtend web service returns a fault QDoc message instead of a reply QDoc message, the QAD MFG/PRO data handler converts it into a BIA_FaultBO business object. The protocol handler sets this BO as the value of the fault attribute of the TLO, and the header is removed.