Understanding Data Translation
Use data translation to modify message content rather than structure, although you can also make local structural changes. It’s most appropriate when the sending and receiving systems use different field values, or different combinations of fields and their values, to represent the same information.
Following is a sample scenario:
-
Application A transmits customer names in four fields: Title, First, Middle, and Last.
-
Application B uses two fields: Last and First. It doesn’t use a title, but includes the middle name as part of the First field.
-
Application C uses only one field: AccountID.
Clearly the representation used by one application won’t be understood by either of the other two. PeopleSoft Integration Broker can apply a transform program to translate each of these representations into a version appropriate to the receiving application.
One Integration Broker node can store in its codeset repository the equivalent fields and values used by another node. When it receives a message from the other node containing a customer name, it can use its codeset repository to translate the information into the form it prefers. It can likewise reverse the process for messages outbound to the other node.
For a given integration, you can allocate the responsibility for performing data translation in different ways. You can distribute the translation activity among the participating nodes, or you can designate one Integration Broker node to do all the data translation as a hub, whether the messages are inbound, outbound, or being redirected between the other nodes. Using a single node, if possible, can reduce the need for duplicating repository data.
Data Translation Elements
The following elements constitute the codeset repository, managed as PeopleSoft Pure Internet Architecture components:
| Term | Definition |
|---|---|
|
Codeset group |
Maintains a list of the significant data fields and their values that a particular node might send in an initial message. These are name/value pairs a translation program might find (match) and use as the basis for determining what the result message should contain. These name/value pairs are known as match names and match values. Each PeopleSoft Integration Broker node that requires data translation must belong to a codeset group. |
|
Codeset |
A specific set of match name/match value pairs selected from an existing codeset group. The selected name/value pairs are the basis for possible field value combinations that you want to match in a message, and to which your translation program can respond by modifying the message content. Each codeset typically represents one set of fields that require translation for a given message. |
|
Codeset values |
A codeset value is a named value you define, also known as a return value. Your translation program can output the return value as a result of matching a specific combination of match values from a codeset. You associate multiple combinations of codeset values with the combination of an initial codeset group, a codeset from that initial group, and a result codeset group. For each permutation of match values selected from the codeset, you define a different combination of codeset values to apply to your result message. |
The other key element of data translation is your translation program, which invokes the codesets and codeset values you’ve defined.
Data Translation Development Sequence
You must initially define these elements in a particular order:
-
Two codeset groups.
-
A codeset based on one of the codeset groups.
-
A set of codeset values.
-
A data translation program, in XSLT or PeopleCode.
However, it’s unlikely that you’ll be able to fully define any of these elements without some trial and error. You may find you’ll have to modify and extend each element in turn as you develop your data translation program.