Skip to Main Content
Return to Navigation

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 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.