QAD MFG/PRO data handler processing

The QAD MFG/PRO data handler performs transformations between QAD MFG/PRO messages and business objects in the following ways:

QAD MFG/PRO-message-to-business-object processing

The sections below describe:

Triplet-to-QDoc processing: rules

The rules below apply when the QAD MFG/PRO data handler's mapping engine converts triplet messages to QDoc XML:

Triplet-to-QDoc processing: metadata

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 8. mapFile metadata

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.

Triplet-to-QDoc header mapping

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
 

QDoc-to-business-object processing

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.

Business-object-to-QAD MFG/PRO-message processing

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.

Copyright IBM Corp. 1997, 2004