A RMS publishes the Partner message family to describe the attributes of a business partner. RWMS needs location information for all partners referenced in Item, POs, ASN, and/or Stock Order messages.
Each published partner has a partner type attribute and an array of addresses. Each address has a primary address indication detailing whether this address is the primary address for the partner. There may be only one primary address for a partner. The partner type of external (denoted with a value of “e”) need to be passed on as other partner types are not of interest to RWMS.
Partner addresses input to RWMS use the Location message family. Hence, the primary functionality of the PartnerToLocation TAFR is to filter partner messages regarding non-External partners and to publish Location messages for all RWMS instances.
Input message Routing
information: The routing information
for an input Partner message must contain the following routing info
records:
A “partner type” routing info record detailing the type of the partner referred to in the payload. A value of “e” implies this record is for an external partner type and needs transformation into a Location message. Any other value will result in the message being dropped.
Output message Routing Information: The following routing information records must be present in output messages as per the specifications below:
A “location
type” routing info record (<name> tag value of “loc_type”) will have a
<value> tag value the same as the input “partner type” routing info
record. Currently, all messages must have an output location type value of “e”,
since all input messages with other values will be filtered.
RibMessage envelope header fields: Outbound messages will have the same values as the input messages for the RIB message envelope tags of : <ribmessageID>, <customFlag>, <customData>, <id>. If one of these input fields is not present, then the output message will also not contain this tag. Nested tags within these fields will also be copied. An input message may contain a null or missing <publishTime>, while the output message may contain a set publishTime. All output message <publishTime> fields must be set to a date/time equal to or after the input publishTime.
Message payload XML schema declaration: The <messageData> or “payload” 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 must be “LocationDesc.xsd” for output “LocationCre”, “LocationMod”, and “LocationDtlMod” message types. The name of the XSD file specified must be “LocationRef.xsd” for output message of the type “LocationDel”.
No Primary Address Indication. Any input Partner payloads that
a) do not contain an address record with a “primary address indication” of true and
b)
reference an external partner type
will result in an error. The TAFR MDB framework will handle the error.
Note: this implies that RMS will publish “partnermod” messages with a
primary address record, even if the modification is only with one of the “header”
fields (such as description or currency_code).
Message type
transformation: Capitalization
differences of the input message <type> value will be ignored. Input
messages types will be mapped to output message types as per the table below.
|
Input type |
Output Type |
|
partnercre |
LocationCre |
|
partnermod |
LocationMod |
|
partnerdel |
LocationDel |
|
partnerdtlmod |
LocationMod |
partnercre and partnermod,
partnerdtlmod payload processing:
The input payload class type for partnercre, partnermod, and partnerdtlmod
payloads will be the com.oracle.retail.integration.base.bo.partnerdesc.v1.PartnerDesc
class. The output payload class will be the com.oracle.retail.integration.base.bo.locationdesc.v1.LocationDesc
class.
The tables below detail the conversion between the PartnerDesc fields and the LocationDesc fields. The <PartnerDesc > element contains an array of <AddrDesc> elements which are mapped to
|
PartnerDesc field |
LocationDesc field |
Required for |
Comment |
|
partner_id |
dest_id |
|
|
|
partner_type |
dest_type |
|
|
|
partner_desc |
description |
|
|
|
currency_code |
currency_code |
|
|
PartnerDesc records also contain one or more AddrDesc records. The first AddrDesc input record containing an “primary_addr_ind” with a value of “Y” or “y” will be mapped to the output LocationDesc field. Only a single output AddrDesc record will be output. All other input AddrDesc elements will be ignored.
Any input AddrDesc field not included in the table below will be ignored.
|
Input AddrDesc field |
Output LocationDesc field |
Required for |
Comment |
|
add1 |
address1 |
|
|
|
add2 |
address2 |
|
|
|
city |
city |
|
|
|
state |
state |
|
|
|
country_id |
country_code |
|
|
|
post |
zip |
|
|
|
contact_name |
contact_person |
|
|
|
contact_fax |
dest_fax |
|
|
|
contact_phone |
phone_nbr |
|
|
|
primary_addr_ind |
|
|
Used to determine if this record is to be output. No field in the output record is mapped to the input field. In order for an address record to be considered primary, this field and the primary_addr_type_ind field must both contain a value of “y” or “Y”. |
|
primary_addr_type_ind |
|
|
Used to determine if this record is to be output. No field in the output record is mapped to the input field. In order for an address record to be considered primary, this field and the primary_addr_ind field must both contain a value of “y” or “Y”. |
partnerdel message processing: The input payload class for partnerdel messages will be the com.oracle.retail.integration.base.bo.partnerref.v1.PartnerRef class. The output payload class will be the com.oracle.retail.integration.base.bo.locationref.v1.LocationRef class. The table below details the conversion between the PartnerRef fields and the LocationRef fields. Any PartnerRef field not contained in the table will be ignored.
|
PartnerRef field |
LocationRef field |
Required for |
Comment |
|
partner_id |
dest_id |
both |
|