Identifying Data Transfer Paths

When communicating with your trading partners, you have several options for data transportation. You can use value added networks (VANs), direct internet connections, or FTP. You must decide whether to preserve the data in XML format or transform it into a standard EDI format, such as X.12 or EDIFACT.

This section discusses the following paths:

  • Communicate directly with your trading partners using XML.

  • Integrate PeopleSoft XML and standard EDI formats, such as X.12 or EDIFACT.

  • Continue to exchange flat file information between your EDI translator or FTP system.

Work with each trading partner who transmits data using HTTP. Partners accustomed to exchanging EDI transactions must adapt the PeopleSoft Integration Broker architecture. They may also need to translate between different XML formats.

Note: This path is most useful for bringing new trading partners into your eCommerce network.

Consider the following advantages when using this upgrade path:

  • Batch window elimination: transmit data with near-zero latency between trading partners.

  • Small- to mid-size trading partners use browser-based forms to exchange XML data directly with internal systems.

  • VAN charge elimination.

  • Completely internet-based, using generally available tools (for example, parsers and style sheets).

Consider the following disadvantages when using this upgrade path:

  • Major impact on trading partners.

  • New configuration required to use PeopleSoft Integration Broker technology.

Sending Outbound XML to a Trading Partner

To send outbound XML to a trading partner:

  1. If necessary, use PeopleSoft Integration Broker to build a transformation that maps the PeopleSoft XML to the trading partner's XML format.

  2. Define a PeopleSoft node to represent the trading partner, and set up the PeopleSoft Integration Broker.

    The specified URL points to the trading partner's web server.

  3. If the trading partner uses one of the industry-standard connectors packaged with the PeopleSoft Integration Broker, configure the node to use this connector.

  4. If the trading partner does not support any industry-standard connectors, build a connector to transport XML data, and register the connector on the PeopleSoft Gateway.

  5. Initiate your publish functions within the PeopleSoft applications.

Receiving Inbound XML from a Trading Partner

To receive inbound XML from a trading partner:

  1. If necessary, use PeopleSoft Integration Broker to build a transformation that maps the trading partner's XML to the PeopleSoft XML format.

  2. Define a node within PeopleSoft to receive this data, and set up the PeopleSoft Integration Broker.

  3. If the trading partner uses one of the industry-standard connectors packaged with PeopleSoft Integration Broker, configure the node to use this connector.

  4. Configure the trading partner's system so that it posts to the proper connector on the PeopleSoft Gateway.

  5. Begin receiving data from your trading partner.

In this scenario, PeopleSoft exchanges EDI data utilizing PeopleSoft XML and transformations to or from industry standard EDI formats. Most EDI suppliers now support XML formats and can receive XML, translate the fields to standard EDI field formats, such as X.12 EDI or EDIFACT, and write the data to a flat file (They can also deposit the EDI transactions onto the VAN of your choice). Conversely, they can also receive inbound transactions from the VAN, map the fields to PeopleSoft XML format, and publish to the PeopleSoft Integration Broker Gateway.

Note: This is the best approach for maintaining your investment in translation software while using PeopleSoft Integration Broker architecture. It is not a strong option if your current translation software does not support XML.

Consider the following advantages when using this upgrade path:

  • Batch windows reduction: data can be transmitted between PeopleSoft and the translation software with zero latency, then pooled into appropriate batches for transmission to the VAN.

  • Preserves investment in EDI standards support, minimizing impact to trading partners.

  • Provides a stepping stone to pure XML business-to-business architecture.

  • Uses delivered PeopleSoft EDI XML transactions.

Consider the following disadvantages to using this upgrade path:

  • Requires major EDI maps rewrite for the translation application or the VAN.

  • Still incurs VAN charges.

Converting Existing Outbound Translation Maps to Use XML

To convert existing outbound translation maps to use XML:

  1. Customize new EDI maps to convert the XML data into the customer's required format, such as X.12 or EDIFACT.

  2. Define a node within PeopleSoft to represent the trading partner, and setup the PeopleSoft Integration Broker.

    The specified URL points to the trading partner's web server.

  3. If the translator uses one of the industry-standard connectors packaged with PeopleSoft Integration Broker, configure the node to use this connector.

  4. If the trading partner does not support any industry-standard connectors, build a connector to transport XML data, and register the connector on the PeopleSoft Gateway.

  5. Initiate your publish functions within the PeopleSoft applications.

Converting Existing Inbound Translation Maps to Use XML

To convert existing inbound translation maps to use XML:

  1. Customize new EDI maps to convert the customer format to XML data.

  2. Define a node within PeopleSoft to receive this data, set up the PeopleSoft Integration Broker.

  3. If the translator uses one of the industry-standard connectors packaged with PeopleSoft Integration Broker, configure the node to use this connector.

  4. If the trading partner does not support any industry-standard connectors, build a connector to transport XML data, and register the connector on the PeopleSoft Gateway.

  5. Configure the trading partner's system so that it posts to the proper connector on the PeopleSoft Gateway.

  6. Begin receiving data from your trading partner.

This section discusses setup steps and specific field deltas that occur when translating between PeopleSoft Integration Broker and FLOs.

For outbound transactions, configure the batch publish utility to generate a flat file. Service Operations supporting outbound EDI integration have a file layout definition set up to work with their associated batch publish rules. The flat file is deposited into a subdirectory accessible by the translation software. Most EDI transformation software sweep subdirectories looking for available transaction files.

For inbound transactions, you can load data into PeopleSoft using the Inbound File Publish utility. This utility reads a flat file, then publishes it to the PeopleSoft Integration Broker as XML data for inbound processing. Service Operations supporting EDI integration have a file layout definition and file rules already set up. The files generated in this manner follow the same rules as XML, with these exceptions:

  • A flat file has the same field sequence as the XML, but every field in the XML has a tag.

  • Fields in the flat file do not have a tag, as each field instead has a fixed position in each row within the file.

  • Row IDs.

    ECFILEROWIDs from EDI maps still exist. These typically follow a pattern, though the pattern may differ from EDI transaction to EDI transaction. The ECFILEROWID is the first field for every record in the definition. The convention is as follows:

    Level1  000

Level1  100

Level2  200

etc.

  • Audit action.

    The AUDIT_ACTN field is defined on each record in the FLD. The file utilities copy this field between the record and the appropriate PSCAMA on a level-by-level basis. This field is defined as the second field for every record in the FLD. A blank audit action represents a record that did not have any changes to it; this record is included to preserve parent/child relationships. Thus, a lower level record may contain the changed data.

  • A "control record" that determines the format of the file's layout exists at the top of each flat file.

    This control record is commonly referred to as the "999" or "998" record. The 999 record specifies the trading partner identifiers related to the document's sender and receiver. The 998 record specifies the actual map name and transaction ID.

    The new FLO also supports control records. PeopleSoft Application Designer specifies the format of the record, which then instructs the file object processor how to interpret the record data.

    The following is the record specification:

    AAAAAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBB

    AAAAAAAAAA is the 10-character file layout ID. This is the 998 record.

    BBBB... is the file layout ID name of up to 30 characters.

Consider the following advantages when using this upgrade path:

  • Maintains more legacy investment than other options.

  • Minimizes impact to trading partners because standard EDI formats are still transmitted to the partner.

  • Requires no additional investment in XML-based software.

Consider the following disadvantages when using this upgrade path:

  • Maintains batch processing.

  • Reduced performance due to multiple passes through the data (translator, file utility, and Integration Broker).

  • Does not provide direct trading partner communication.

  • Still incurs VAN charges.

Converting Standard EDI Flat File Outbound Transactions into PeopleSoft Business Document Flat File Format

To convert standard EDI flat file outbound transactions into PeopleSoft business document flat file format:

  1. Modify existing maps making changes for row IDs, audit actions, control records, and any layout changes made in the latest versions.

  2. With standard delivered PeopleSoft service operations, update the appropriate batch publish rule to create a flat file, instead of XML.

  3. Activate the appropriate service operations.

  4. Initiate publish functions within your PeopleSoft applications.

Converting Standard EDI Flat File Inbound Transactions into PeopleSoft Business Document Flat File Format

To convert standard EDI flat file inbound transactions into PeopleSoft business document flat file format:

  1. Modify existing maps making changes for row IDs, audit actions, control records, and any layout changes made in the latest versions.

  2. Create a file rule to determine the directory that will receive the inbound transaction data, or update an existing file rule that is already associated with the message being transmitted with the destination of the subdirectory.

  3. Set up the PeopleSoft Integration Broker.

  4. Begin receiving data from your trading partner.

Reviewing the File Layout Definition Properties Dialog Box

The following is an example of a File Layout Definition Properties dialog box.

This example illustrates the fields and controls on the File Layout Definition Properties dialog box. You can find definitions for the fields and controls later on this page.

 File Layout Definition Properties dialog box

The EDI transaction's data record structure appears as follows:

XXXYAAABBBBB

where:

  • XXX is the three-character ECFILEROWID.

  • Y is the one-character AUDIT_ACTN flag.

  • AAABBBB.... are the fields.

Reviewing File Definitions

The following figure shows a sample file containing three distinct file definitions.

This example illustrates the fields and controls on the Sample file with distinct file definitions. You can find definitions for the fields and controls later on this page.

 Sample file with distinct file definitions

For this file definition example, consider the following:

  • The PO_REQUEST_FOR_QUOTE_RESPONSE control record has a single transaction.

  • The PURCHASE_ORDER_ACKNOWLEDGEMENT record has two transactions.

  • The ADVANCED_SHIPPING_RECEIPT has a single transaction.

Reviewing Impacted Fields

Some message definition control fields are discarded during file processing.

PeopleSoft Integration Broker definitions contain record definitions that reuse or point to a record previously defined in PeopleSoft Application Designer. File Layout Designer, however, creates a copy of the record in a new file layout definition and enables you to add additional fields to each record definition. The File Layout Designer record and the original record definition become separated and do not share attributes.

PeopleSoft Integration Broker also implements a control record of its own, called the PeopleSoft Common Application Message Attributes record (PSCAMA). The PSCAMA contains attributes that specify what language code, process instance, message sequence, and audit action is used. The PSCAMA acts as a sibling record to every regular record in the message definition. One primary use of the PSCAMA is to determine whether a particular record of data has been updated, inserted, or deleted (the AUDIT_ACTN field).

Note: The file layout definition does not require a PSCAMA record.