Data Interchange Services client supports three types of maps that you can use to transform data that you exchange with other business and trading partners: data transformation maps, validation maps, and functional acknowledgment maps.
The following table describes each type of map supported by Data Interchange Services client.
Map types supported by Data Interchange Services client
Map types | Description |
---|---|
Data transformation map | Data transformation maps are the primary type of map used by the translator component of WebSphere Partner Gateway to convert a document from one format to another. They provide the information needed to gather data from a source document and create a target document using the source data. These maps provide a powerful method of mapping data from one document format to another. |
Validation map | Validation maps provide the instructions needed to perform additional validation beyond what is specified in the EDI Standard. The name of the validation map is specified in WebSphere Partner Gateway when it is used to perform additional validation on the source or target document in a translation. Validation maps contain mapping commands that are instructions used to provide additional validation of an EDI document. |
Functional acknowledgment map | Functional acknowledgment maps provide the instructions to the translator component of WebSphere Partner Gateway on how to produce a functional acknowledgment. A functional acknowledgment map is a special data transformation map used in creating EDI acknowledgments. |
All three map types provide the ability to perform the following tasks:
Data transformation maps are the primary type of map used by the translator component of WebSphere Partner Gateway to convert a document from one format to another.
Data transformation maps consist of commands specifying how to transform a source document into a target document. In each data transformation map, a source document definition and a target document definition is specified. The source document definition describes the layout of the source document (the document to be translated). The target document definition describes the layout of the target document (the output document). Source and target document definitions are specified when the map is first created. You can change the source and target document definitions after a map is created, but you can not change the source syntax type or target syntax type. For instance, if you are using an EDI document definition as your source document definition, you can change which version of the EDI Standard you are using, but you cannot indicate that you want the source document syntax type to be a Record Oriented Data instead of EDI.
You indicate whether a data transformation map is source or target-based when you create it. This cannot be changed after the map is initially created.
Validation maps provide the instructions needed by the translator component of WebSphere Partner Gateway to perform additional validation beyond what is specified in the EDI Standard.
A validation map is similar to a source-based data transformation map. Unlike a data transformation map, however, a validation map has no target. Certain specific commands such as MapTo() are not available in a validation map. The command FAError() is available in a validation map, allowing errors to be reported in an EDI acknowledgment.
Each validation map has an associated source document definition. The source document definition describes the layout of the document to be validated. It is specified when the map is first created. The source document definition is always an EDI document definition. You can change the source document definition after a map is created, but you can not change the source syntax type. For instance, you can change which version of the EDI Standard you are using, but you can not indicate that you want the source document type to be a Record Oriented Data instead of an EDI Standard.
The following validation maps are provided by Data Interchange Services, but they are selected by an attribute in the WebSphere Partner Gateway configuration. They are used to perform service segment validation during data transformation processing.
Validation maps
Map name | Description |
---|---|
&WDI_E99AENV_VAL | UN/EDIFACT based on E99A service segments and code lists |
&WDI_UCSENV_VAL | UCS based on UCS 4050 service segments and code lists |
&WDI_X44ENV_VAL | X12 based on X12 4040 service segments and code lists |
WebSphere Partner Gateway may be configured to validate received EDI documents. This is called "source validation." When source validation is performed, WebSphere Partner Gateway may be configured to generate EDI acknowledgments, which may include functional or interchange acknowledgments. Basic EDI validation includes checking things like the minimum and maximum lengths of each element, checking for missing mandatory segments and elements, and so on. Validation maps can provide additional types of tests if needed. Service segment validation can be selected, and a user-specified validation map can also be selected.
WebSphere Partner Gateway may also be configured to validate EDI documents that were generated by WebSphere Partner Gateway, to ensure the documents are correct before they are sent to trading partners. This is called "target validation." The goal of target validation is simply to pass or fail the document in question. No acknowledgments are generated for target validation. A user-specified validation map can be specified for target validation, but service segment validation does not apply. (The service segments have not yet been generated when target validation is applied.)
The Error() mapping command is used in validation maps to indicate that an error exists in the document. The Error() command can be used by a validation map when a source EDI document is going to be translated or when validating an EDI document that is produced by a translation. The Error() command will not produce information that can be used in a functional acknowledgment. If an error should be included in a functional acknowledgment, you must use the FAError() mapping command instead. It works like the Error() command except that functional acknowledgment information is specified in the command. The functional acknowledgment information is stored internally and becomes the source document when creating the EDI functional acknowledgment target document. Both Error() and FaError() commands log message UT0033 and write the message to an internal file.
Functional acknowledgment maps provide the instructions to the translator component of WebSphere Partner Gateway on how to produce a functional acknowledgment.
The translator component of WebSphere Partner Gateway can automatically generate EDI Standard functional acknowledgments for EDI documents received from a trading partner. To produce a functional acknowledgment, a functional acknowledgment map must be associated with the source document that is being translated in WebSphere Partner Gateway. The source document must be an EDI document. When a document is going to be translated, it is first validated as specified in WebSphere Partner Gateway. The translator component of WebSphere Partner Gateway provides a standard level of validation on the EDI document. If a functional acknowledgment is going to be generated, results from validation of an EDI document are written to an internal document. Validation maps are created to provide additional validation on an EDI document. Results of the validation map are also written to the internal file. The generation of a functional acknowledgment uses the functional acknowledgment map specified in WebSphere Partner Gateway and this internal file as its source document. The functional acknowledgment map contains mapping commands that indicate how to use the validation results contained in this internal file to create a specific functional acknowledgment. If a document is accepted for translation by the validation process, then the appropriate data transformation map is used to translate the source document. All of this is controlled by the association of the source document and the data transformation map in WebSphere Partner Gateway.
The source document definition for all functional acknowledgment maps is a Record Oriented Data (ROD) document definition with the name &FUNC_ACK_META contained in the dictionary &FUNC_ACK_METADATA_DICTIONARY. It describes the layout of the internal file generated by the validation process. The name of the source document definition cannot be changed. You cannot create a functional acknowledgment map without this ROD document definition in your database.
The target document definition in a functional acknowledgment map describes the layout of the functional acknowledgment. It must be an EDI document definition with a name of 997, 999 or CONTRL.
Normally, you should not need to create or modify a functional acknowledgment map. Data Interchange Services client provides several maps to produce the most common functional acknowledgments. Create a functional acknowledgment map only when a custom functional acknowledgment is required. The functional acknowledgment maps provided by Data Interchange Services are listed in the following table.
Functional acknowledgment maps
Map name | Description |
---|---|
&DT_FA997V2R4 | Functional Acknowledgment 997 - X12 Version 2 Release 4 |
&DT_FA997V3R5 | Functional Acknowledgment 997 - X12 Version 3 Release 5 |
&DT_FA997V3R7 | Functional Acknowledgment 997 - X12 Version 3 Release 7 |
&DT_FA999V3R3 | Functional Acknowledgment 999 - UCS Version 3 Release 3 |
&DT_FACONTRL | Functional Acknowledgment CONTRL - UN/EDIFACT prior to D94B |
&DT_FACONTRL94B | Functional Acknowledgment CONTRL - UN/EDIFACT Version 2 Release 1 (D94B) |
&WDI_TA1_ACK | This map is used to generate a TA1 |
The &DT_FA997V3R7 functional acknowledgment map is used to generate functional acknowledgments for X12 version 3, release 7 and higher. The &DT_FACONTRL94B functional acknowledgment map is used to generate functional acknowledgments for UN/EDIFACT version 2, release 1 (D94B) and higher. All of the functional acknowledgment maps listed above should not be modified or deleted. If you need to make a customization, it is recommended that the appropriate map is copied and the needed change is made in the copied map.