Work Order messages are published by a merchandizing system, such as RMS to order a known quantity of goods. A merchandizing system produces an order message and it needs to be transformed and routed to various warehouses depending on the warehouse locations as specified by the order.
The Work Order to Work OrderWH TAFR takes Work Order messages and converts these messages to WorkOrderWH messages. Work Order messages are subscribed by Retail Warehouse Management System (RWMS). Besides transforming the message payload formats, the TAFR must also perform routing and filtering operations to insure the message is forwarded to the correct instance of the warehouse with warehouse specific information.
This document describes the functionality of the WOInToWOInWH TAFR. This component has specific methods called to filter, translate, and route a single Rib Message node. These methods are called by the TAFR processing framework. This framework is also responsible for publishing the appropriate message nodes using a single RibMessages message to the correct output topic or topics. The framework requirements are not in scope of this document.
Message type requirement: It is required that the input message to be of type “inbdwocre”, “inbdwomod” or “inbdwodel”. The message will be filtered if the message is type is not the one as specified above.
Payload detail location type: Message routing is dependent upon the physical location as specified by payload detail’s location type. If the physical location type is not “w”, an output detail will not be published
Routing info detail value: Message routing is dependent upon the routing info detail value of the rib message routing info. If the detail value is not “w”, an output message will not be published.
Facility ID requirement: It is an error for a message to contain a facility Id not specified in the configuration file
Message payload XML schema declaration: The <messageData> string will contain a namespace xml schema declaration detailing the URL of a XML schema definition (XSD) file. The directory specification in this URL will reside in the configuration, thus allowing the customer to configure his/her own value. The name of the XSD file specified will be either “WOInDesc.xsd” or “WOInRef.xsd” depending on if the payload class is WOInDesc or WOInRef. Note: the value of this element is defined as an application would read it. When reading it off a JMS topic, or after the payload has been marshaled, one must substitute the appropriate string for these special characters (e.g. ‘<’ is replaced by ‘<’)
Routing requirement: Each message is divided into individual messages depending on the physical location specified by the WOInDtl of the payload. All the other properties of the input RibMessage are copied into the output RibMessage. Routing Info’s value is set as the ID for the output message. A WOIn may contain multiple warehouse locations in the routing info and order line details. This will result in multiple output orders, each to a different topic.
Physical location: Order payload details should only contain physical location referenced within the routing info records. Any detail location not in routing info records will not be copied to an output message.