Object types

Data Interchange Services client provides the following types of objects that you can use when creating or editing maps: User Exit profiles, code lists, transformation tables, and global variables.

The following table describes each available object type.

Object types

Object type Description
User Exit A User Exit profile is used to identify a user exit that can be called during a translation.
Code list A code list defines a list of acceptable values that are used in maps to validate any source simple element or variable.
Translation table A translation table is used to change one value into another corresponding value during translation of a document.
Global Variable Global variables are used with data transformation maps, validation maps, and functional acknowledgment maps. During translation, you can put data into a global variable. The data contained in a global variable is available to other translations.

User Exit profiles

A User Exit profile defines a field exit routine to Data Interchange Services client. It provides Data Interchange Services client with the information it needs to call a field exit routine. A field exit routine can be called from data transformation maps, validation maps, and functional acknowledgment maps. Field exit routines are invoked during the translation of a document when the Exit() function is encountered in a mapping command.

You need a User Exit profile defined for each user provided field exit routine you use. The name of a User Exit profile is used as a logical name for the field exit routine throughout Data Interchange Services client. A User Exit profile identifies the name of the class and method used to invoke the exit routine.

You call a field exit routine to perform special processing of almost any nature. Field exits are expected to return a character string if they complete successfully, though it is not required. The returned character string can be used in a mapping expression or can be used to update a variable or a simple element in the target document. The field exit can be used for almost anything. Field exits can accept several parameters. Parameters can be variables, constants, the result of an expression, or a path that identifies a simple element in the source document definition.

Field exit routines

Field exit routines are used within data transformation maps, validation maps, and functional acknowledgment maps in the Exit() function. They are defined by creating a User Exit profile. The class and method within the class to be executed are specified in the User Exit profile. A field exit routine is written in Java.

Code lists

A code list is a list of acceptable values that is used in maps to validate any source simple element or variable. Code lists are provided by EDI Standards. They indicate which values are valid for a specific EDI data element. A code list can also be created to specify any list of valid values. When the translator component of WebSphere Partner Gateway validates or translates a document, and the use of a code list is specified to validate a piece of data, the specified code list is searched to see if it contains the value.

Translation tables

A translation table is used to translate a value into a corresponding value. Translation tables are used in data transformation maps, validation maps, and functional acknowledgment maps. Translation tables contain a list of unique values called source values. Each unique source value has a corresponding target value assigned to it. The target values do not have to be unique. You should always define all possible values in the translation table.

Use a translation table in a map to indicate that an alternate value is to be used instead of the value contained in a simple element or variable. An example of where a translation table might be useful is when a simple element contains an internal part number that must be converted to a trading partner's corresponding part number. When the instruction to use a translation table is encountered during translation, the value in the source simple element is looked up in the specified translation table. If it is found in the table, the corresponding value is then substituted for the original source value. If it is not found, there is an option that allows you to specify a default value.

In data transformation maps, validation maps, and functional acknowledgment maps, the lookup of a value is normally done against the source values in a translation table. When a matching source value is found, the corresponding target value is substituted for the original value. There is an option that allows you to perform a lookup using the target value. This allows you to use the same table to translate a value to a trading partner's equivalent value and also to translate a trading partner's value to your equivalent value. Using the target value for a lookup is useful only when target values are unique. When the option to perform a lookup using the target value is used, the lookup attempts to locate a target value in the translation table that matches the value in the simple element or variable. When found, the corresponding source value is substituted for the original value.

Global variables

A global variable defines a variable that can be used across mapping translations. These variables are used much like variables in most programming languages. They can hold and manipulate data in data transformation maps, validation maps, and functional acknowledgment maps. While a document is being translated, data can be put into a global variable. After the translation of the document ends, the data remains in the global variable. The data in the variable may be available in the next translation, depending on the scope of the variable, regardless of the map that is used to perform the translation. During subsequent translations within the scope of the variable, the data in the global variable can be obtained, manipulated and changed.

One attribute of a global variable is scope. The scope of a global variable can be group or interchange. Global variables that have a scope of interchange are created and initialized when an interchange is encountered. They are reset at the start of the next interchange. Variables with a scope of group are created and initialized when a group is encountered. They are reset at the start of the next group. Not all syntax types support the concept of groups or interchanges. When the source document type does not support groups, the scope of group is treated the same as interchange. If the document type does not support interchanges, the variable is reset at the start of each input document. For example, if the input file contains multiple documents and is split into separate documents by the RODSplitter or XMLSplitter, the global variables are reset for each input ROD or XML document in the file.

Other attributes of global variables include data type, maximum length, and initial value. Maximum length dictates how long the data within a global variable can be. The maximum length is only available for certain data types. Global variables can also have an initial value. When a global variable is created or reset automatically (goes out of scope), the initial value will automatically be put into the global variable. The default initial value for a numeric data type is zero. An empty string is the default initial value for character string and binary data types.

Data transformation maps, validation maps, and functional acknowledgment maps use global variables in map commands. Every global variable is available to every map. A global variable must be defined before it can be used in a map command. They can be defined from the Global Variables list window of the Mapping Functional Area, the Data Transformation Map Editor, the Validation Map Editor, or the Functional Acknowledgment Map Editor.

A global variable must reside in the database accessed by the translator component of WebSphere Partner Gateway before a map using the global variable can be used successfully to translate a document. Ensure the global variable exists in the database by defining the global variable in the database using Data Interchange Services client, or use export and import functions to copy the global variable to the database. Global variables can be exported by themselves or with maps or map control strings.

Certain changes to a global variable affect all maps that utilize the global variable. All maps that use a global variable that have had certain changes must be recompiled. The resulting map control string must then be exported to the database accessed by the translator component of WebSphere Partner Gateway. A map must be recompiled when the name, scope, or data type of a global variable has been changed.

Copyright IBM Corp. 2003, 2005