Understanding Value Maps
The Define Value Maps component enables users to define and classify value maps and elements. Each value map must be defined as either dynamic (cross-reference) or static (DVM).
Value maps support the following types of maps:
One-to-one
One-to-many
Multiple elements per domain
One-to-One Cross-Reference
Cross-reference maps support a one-to-one relationship between two systems. For example, the PeopleSoft system uses one ID for customer A, the enterprise business object (EBO) or common value uses a GUID, and the external system uses another ID for the same customer.
The cross-reference map would be defined like this:
PeopleSoft |
UniqueGUID |
External System |
---|---|---|
PS |
UniqueGUID |
EXT |
PS100 |
<guid1> |
EXT-100 |
PS102 |
<guid2> |
EXT-102 |
In this scenario, when a PeopleSoft application creates a new customer and sends the create customer message to the external system, the routing includes a transformation program that uses the cross-reference map to translate the data.
One-to-Many Cross-Reference
Cross-reference maps support a one-to-many relationship between two systems. Two or more values in a system may correspond to a single value in another system. For example, three different job codes might exist in the PeopleSoft system that correspond to one job code in the external system.
The cross-reference map would be defined like this:
PeopleSoft |
UniqueGUID |
External System |
---|---|---|
PS |
UniqueGUID |
EXT |
AS01 AS02 AS03 |
<guid1> <guid2> <guid3> |
ASST |
MG01 |
<guid4> |
MNGR |
In this scenario, when the PeopleSoft application assigns or changes a job code and sends the message to the external system, the routing includes a transformation program that uses the cross-reference map to translate the data. If the integration requires translation from the external system value to a PeopleSoft value, the developer is responsible for determining how to handle the multiple PeopleSoft values returned from the lookup. Options include replicating the source data for each value, implementing a method of choosing a default value, and generating an error for the transaction.
Cross-Reference with Multiple Domains
Many times a system implements functionality using compound keys. This is supported in the cross-reference framework by means of multiple elements to identify the value set. For example, item integrations from a PeopleSoft application to an external system would use a cross-reference map to translate SetID/ItemID on the PeopleSoft system to Product on the external system.
The cross-reference map would be defined like this:
PeopleSoft |
PeopleSoft |
UniqueGUID |
External System |
---|---|---|---|
SETID |
ITEMID |
UniqueGUID |
Product |
SHARE |
1001 |
<guid1> |
RP001 |
SHARE |
1002 |
<guid2> |
RP002 |
SHARE |
1003 |
<guid3> |
RP003 |
SHR03 |
1000 |
<guid4> |
RP006 |
In this scenario, when the PeopleSoft application creates an item and sends the message to the external system, the routing includes a transformation program that maps the setID and itemID to a common element (UniqueGUID) and the external system receives the translated data.
One-to-One DVM
In a domain value map, the one-to-one relationship contains the actual data values. For example, the PeopleSoft application uses the short name for the state code, the EBO defines state code using the full name as the common value, and the external application uses an abbreviated name for state code.
The DVM would be defined like this:
PeopleSoft |
Common |
External System |
---|---|---|
Short |
Full |
Abbrev |
MA |
Massachusetts |
Mass |
CA |
California |
Calif |
In this scenario, when a PeopleSoft application creates an outbound message to the external system that includes the state code, the routing includes a transformation program mapping the short name to the full name and the external system requires a transformation from the full name to the abbreviated name. The transformation for the external system can be done by means of the AIA middleware or a proprietary transformation on the external system.
One-to-Many DVM
In the domain value map, a one-to-many relationship is created by entering multiple values for one domain mapping to a single value in another domain. For example, in the PeopleSoft application, multiple person types can map to a single person type in the external application.
The DVM would be defined like this:
PeopleSoft |
UniqueGUID |
External System 2 |
---|---|---|
PS |
UniqueGUID |
EXT2 |
PS001 PS002 |
<guid1> |
SB001 |
PS003 |
<guid2> |
SBL002 |
In this scenario, when a PeopleSoft application creates an outbound message to an external system that includes the person type, the routing includes a transformation program to translate the data values.
DVM with Multiple Elements Per Domain
In the DVM, you can map multiple elements to define a value set. For example, in the PeopleSoft application, the Business Unit/Chartfield combination could map to a Ledger/Segment combination in an external application.
In this scenario, when a PeopleSoft application creates an outbound message to the external system that includes the person type, the routing includes a transformation program providing the data translation.
The DVM would be defined like this:
PeopleSoft |
PeopleSoft |
UniqueGUID |
External System 1 |
|
---|---|---|---|---|
Business Unit |
Chartfield |
UniqueGUID |
Segment |
Ledger |
US001 |
ACCOUNT |
<guid1> |
SEGMENT1 |
Ledger1 |
US001 |
DEPARTMENT |
<guid2> |
SEGMENT2 |
Ledger1 |
US001 |
PRODUCT |
<guid3> |
SEGMENT3 |
Ledger1 |
US002 |
ACCOUNT |
<guid4> |
SEGMENT1 |
Ledger2 |
In this scenario, when a PeopleSoft application creates an outbound message to an external system that includes the Business Unit/Chartfield, the routing includes a transformation program to translate the data values for the multiple elements to a single UniqueGUID. The external system would then need to transform the UniqueGUID to the equivalent Segment/Ledger.
DVM with Qualifiers
Qualifiers provide additional context to uniquely identify mapping values. A mapping may not be valid unless qualified with additional contextual information. For example, a domain value map containing city code to city name mapping may have multiple mappings for a city based on the country. For example, Kensington is a city in Canada as well as the United States.
The DVM would be defined like this:
EXT (Qualifier 1) PSFT (Qualifier 1) |
EXT (Qualifier 2) PSFT (Qualifier 2) |
Common |
EXT |
PSFT |
---|---|---|---|---|
Country |
State |
Common |
CityCode |
CityName |
USA |
Minnasota |
BELG_MN |
BELG |
Belgrade |
USA |
North Carolina |
BELG_NC |
BELG |
Belgrade |
USA |
Kansas |
KN_KS |
KN |
Kensington |
Canada |
Prince Edward Island |
KN_PEI |
KN |
Kensington |
In this scenario, when the PeopleSoft application creates an outbound message to an external system that includes the Business Unit/Chartfield, the routing includes a transformation program mapping city name, country, and state to a common value.