Customizing Transforms for Specific EDI Implementations

Each trading partner using integrations conforming to an EDI specification usually has unique integration requirements. These unique requirements are commonly due to codes or data fields unique to a trading partner, or field lengths that do not map well into the EDI specification. Trading partners often vary the format of a transaction set to meet their specific needs. PeopleSoft Integration Broker provides the flexibility required to implement these trading partner specific integrations without requiring a middleware product to transform data.

Customers should expect to perform the following tasks for each trading partner with unique implementation requirements:

1. Identify the integrations to implement for the trading partner.

2. Create a copy of the delivered attribute mapping worksheets and customize the attribute mappings for each integration to match the trading partner's EDI implementation.

3. If the trading partner's implementation requires adding, deleting, or modifying any fields or segments for an integration, create copies of the delivered file layouts and messages for the integration, customize them to match the attribute mappings, and create a message schema.

4. Create a service operation for any new copies of the inbound integrations.

5. For all integrations requiring transformations unique to the trading partner's implementation, create copies of the delivered transforms, and use the graphical mapper or any XSLT editor to customize them to match changes to the delivered attribute mappings.

6. Create a message node for the trading partner.

7. Using the delivered sample routings as a guide, create routing to or from the trading partner's node for each integration, and indicate the transforms to use for each routing.

8. Create and activate a batch publish rule for each outbound integration.

9. Create inbound file rules for each inbound EDI integration.

10. Create run controls (schedules) for inbound and outbound processing.

To better understand how to take advantage of the transformation features available in the PeopleSoft Integration Broker, six of the more common EDI supportive integrations have been delivered with sample transforms to or form native X.12 EDI flat files:

• 810 out: Billing Invoice

• 840 in: Sales Quote Load

• 845 out: Sales Quote Notice

• 850 in: Sales Order Load

• 855 out: Sales Order Acknowledgement

• 856 out: Advanced Shipping Notice

One Excel workbook is delivered in the Excel directory of SCM 9.0 containing a tab (worksheet) for each of the sample EDI X.12 transaction sets that have been mapped to PeopleSoft.

The following figure shows an example from one of the worksheets that shows the relationship between the segments and elements of the transaction set and the segments and fields of the corresponding PeopleSoft message, and any logic required to transform between them. Each worksheet provides documentation of the delivered XSLT transforms between PeopleSoft and EDI X.12 transaction formats.

This example illustrates the fields and controls on the Example of a worksheet for EDI X.12 transaction sets. You can find definitions for the fields and controls later on this page.

The first step to implementing custom integrations for a trading partner is to create a field-by-field attribute mapping worksheet for each integration. A copy of the relevant sample worksheets should be made for each trading partner, and then modified by a functional analyst to meet the unique needs of the trading partner.

Sample EDI files have been generated to map the sample EDI File Layouts. The Sample EDI Files contain delimiters for all fields, but do not contain data. This allows adding test data to the sample files without having to remove extraneous data from them. Copies of these sample files should be populated with sample data and used during testing.

The following figure shows the first few lines of a sample EDI file.

This example illustrates the fields and controls on the The first few lines of a sample EDI file. You can find definitions for the fields and controls later on this page.

File Layouts and Message definitions have been delivered for each of the X.12 EDI transaction sets. They are named EDI_TXN_xxx where xxx is the EDI transaction set number.

Occasionally, the trading partner's unique implementation will require adding, deleting, or modifying fields or segments for an integration. When this happens, you need to use the PeopleSoft application designer to create trading partner specific copies of the delivered file layouts and messages for the integration, customize them to match the attribute mappings, and generate a schema for the new message.

Customizing messages and file layouts often requires creating new copies of the EDI records and fields to use in place of the delivered ones. To assist in this process, some background on the process and naming standard should be explained. All records required to create the file layouts and messages have been implemented as derived-work records.

Fields are assigned a unique field number in the X.12 EDI specification, and reused throughout the EDI segments. As one segment can contain many occurrences of the same field, and each occurrence of a field in PeopleSoft record must be unique as multiple copies of each field may exist. Fields will be named EDI_FLD_xxx_yyyyyy where xxx is the EDI field number and yyyyyy is a unique occurrence identifier. Field types will be either numeric or string. Dates will be declared as strings.

These types of records support the needs of the file layouts and messages.

• EDI composites are defined as sub-records and named EDI_SBR_xxx_yyy where xxx is the EDI field number and yyy is a unique occurrence identifier. Similar to fields, composites can occur multiple times in a segment so there may be multiple instances of each composite.

• EDI segments are defined as work records and named EDI_SEG_xxx where xxx is the segment number.

• To support the looping structures defined by the X.12 EDI transaction sets, additional work records have been created and named EDILOOP_xxxxxxx where xxxxxxx is a unique lop identifier. PeopleTools requires at least one field, so one field exists on these records (DUMMY_FIELD).

XSLT has been delivered for each of the sample EDI integrations to transform XML between the EDI and PeopleSoft message layouts and data values. Application Engine (AE) programs acts as a delivery mechanism for each of the transforms. Each AE program is named EDI_xxx_y where xxx is the EDI transaction set number, and y is the direction of the transform (either In or Out). This shortened name format allows room for a unique identifier to be appended to the end of the name as users create customized copies of the AE and XSLT for each trading partner with unique transformation needs.

The XSLT for the trading partner must then be modified using the graphical mapper or any XSLT editor to match any changes to the delivered attribute mappings.

The EDI_FileLoader application class is an alternate processing application class that may be specified on an inbound file loader rule to load data formatted using the X.12 EDI specification. It uses the File Layout Definition and Service Operation name specified in the inbound file loader rule convert the inbound file into XML and publish it to the PeopleSoft Integration Broker for inbound processing.

XML_TO_FILE is a generic AE transform program used in the outbound EDI routings to transform XML to a flat file. It uses a File Layout Definition by the same name as the result message out of the transform to convert the XML into a flat file. The AE uses the XMLtoFlatFile application class to actually do the transformation. The AE is used on the sample outbound EDI service operation routings as a second transformation, resulting in an outbound flat-file as opposed to outbound XML. This approach allows users to direct the flat-file instead of outbound XML. This approach allows users to direct the flat-file to any target connector (file, FTP and so on) as appropriate for the specific implementation at their site.