Using Electronic Data Interchange Integration with PeopleSoft

This chapter provides an overview of Electronic Data Interchange (EDI) integration with PeopleSoft, and discusses how to:

Click to jump to parent topicUnderstanding EDI Integration with PeopleSoft

PeopleSoft allows you to process EDI transactions using integration broker, which offers a more automated, timely, and efficient way to send data across systems than was previously available. The service-oriented architecture of the PeopleSoft Integration Broker technologies enables more zero-latency data transmittal, direct business-to-business communication, and Extensible Markup Language (XML) adoption.

You can process EDI transactions using flat files or using XML. You can use a middleware product to convert from the EDI format to the PeopleSoft format, or you can use Integration Broker to transform the EDI format directly into PeopleSoft format without using a middleware product.

This section provides an overview for:

Click to jump to top of pageClick to jump to parent topicUnderstanding Inbound and Outbound Flat File EDI Transaction Processes

This overview section provides information about:

Processing Inbound Flat File EDI Transactions Using the PeopleSoft Format

A flat file that uses the PeopleSoft format can be generated by a third-party system in this PeopleSoft format or generated by a third-party system and then converted to the PeopleSoft format by a middleware product. A flat file could also come from another PeopleSoft system. The PeopleSoft inbound file publish utility converts the data from a flat file to an XML file using the PeopleSoft format. The inbound data is then placed in the message queue, checked for errors, and then moved to the inbound staging tables to be processed by the individual PeopleSoft application.

The following diagrams illustrate the inbound flat file EDI transaction process using the PeopleSoft format:

Inbound flat file EDI transaction process using the PeopleSoft format (1 of 2)

Inbound flat file EDI transaction process using the PeopleSoft format (2 of 2)

To process inbound flat file EDI transactions:

  1. The source trading partner initiates a process that generates a flat file containing EDI transactions in the sources format.

  2. The file is passed to a middleware translation tool that generates an outbound file in the appropriate EDI format (X.12, EDIFACT, etc).

    Depending on the relationship with various trading partners' data mapping, transformations may occur at this point to meet trading partner-specific mapping requirements. The formatted file is then sent on to the source trading partner's VAN—a private network used for exchanging EDI transactions. However, networks can also be the Internet, a dedicated link, or a sole-source provider.

  3. The source trading partner’s VAN distributes the flat file to the destination trading partner’s VAN.

    The source trading partner and destination trading partner can use the same VAN.

  4. The destination trading partner receives the flat file from the VAN.

    A middleware tool is used to convert the source file into the appropriate PeopleSoft Business Document file format. This process includes a conversion from the sources EDI format (X.12, EDIFACT, etc). Additional translation requirements may be required if the source trading partner is sending a generic file that does not meet the destination trading partner's data requirements.

  5. The destination trading partner performs the Inbound File Publish process that changes the flat file transactions to XML and then writes them to a message queue.

    The Inbound File Publish process inputs the electronic data flat file, translates the data using the PeopleSoft File Layout Definition and rules, and then publishes the data to the PeopleSoft Integration Broker as XML transactions.

  6. PeopleSoft Integration Broker subscription processes (OnNotify Handlers) are automatically executed that retrieve the data from the message queue and write it to stage tables.

  7. PeopleSoft applications then read the transactions from the staging tables, perform validations, and load the data to the actual PeopleSoft application database.

    If any errors are found in the transactions, use error handling to fix the errors and to resubmit the transactions.

Processing Inbound Flat File EDI Transactions Using X.12 EDI Format

An inbound flat file can be generated by a third-party system in this X.12 EDI flat file format or generated by a third-party system and then converted to the X.12 EDI flat file format by a middleware product. An EDI flat file could also come from another PeopleSoft system. Once received by your PeopleSoft system, the PeopleSoft Integration Broker uses transforms to convert the data from an X.12 EDI flat file format to the PeopleSoft format. The inbound PeopleSoft-formatted XML data is then placed in the message queue, checked for errors, and then moved to the inbound staging tables to be processed by the individual PeopleSoft application.

The following diagrams illustrate the inbound flat file EDI transaction process:

Inbound flat file EDI transaction process using X.12 EDI format (1 of 2)

Inbound flat file EDI transaction process using X.12 EDI format (2 of 2)

To process inbound flat file EDI transactions:

  1. The source trading partner initiates a process that generates a flat file containing EDI transactions in the sources format.

  2. The source trading partner's VAN distributes the flat file to the destination trading partner's VAN.

    The source trading partner and destination trading partner can use the same VAN.

  3. The destination trading partner performs the Inbound File Loader process which changes the X.12 EDI formatted flat file to an X.12 EDI formatted XML transaction and publishes it to the Integration Broker. A pre-defined file layout definition is used by the Inbound File Loader when generating the X.12 EDI XML transaction. The Integration Broker, using pre-defined transform routines then generates an XML transaction in PeopleSoft's format.

    Pre-defined file layout definitions and Transformation examples are provided for the inbound 840 (Sales Quote Load) and 850 (Sales Order Load) X.12 EDI formats.

    Note. These examples require customizations for individual trading partner requirements. Other inbound X.12 EDI transactions can be supported by creating transforms using the same concepts provided in the example transform programs.

  4. PeopleSoft Integration Broker subscription processes (OnNotify Handlers) are automatically executed that retrieve the data from the message queue and writes the data to stage tables.

  5. If any errors are found in the transactions, use error handling to fix the errors and to resubmit the transactions.

Processing Outbound Flat File EDI Transactions Using the PeopleSoft Format

PeopleSoft can generate a PeopleSoft-formatted flat file. This flat file can be received by a third-party system or processed by a middleware product and then received by a third-party system.

The following diagrams illustrate the outbound flat file EDI transaction process using the PeopleSoft format:

Outbound flat file EDI transaction processing using the PeopleSoft format (1 of 2)

Outbound flat file EDI transaction process using the PeopleSoft format (2 of 2)

To process outbound flat file EDI transactions using the PeopleSoft format:

  1. The source trading partner initiates a PeopleSoft application process that retrieves the transactional data from the PeopleSoft application database tables and loads those EDI transactions into PeopleSoft staging tables, or prepares the data so it can be picked up by the Publish Outbound Message process.

  2. The source trading partner performs the Publish Outbound Message process that retrieves the transactions from the staging tables or application tables and creates a flat file.

    The Outbound File Publish process reads the staging tables, translates the data using the PeopleSoft File Layout Definition and rules, and generates a flat file. The flat file is then sent to the VAN.

  3. The file is passed to a middleware translation tool that generates an outbound file in the appropriate EDI format (X.12 EDI, EDIFACT, etc).

  4. The source trading partner’s VAN distributes the flat file to the destination trading partner’s VAN.

  5. The destination trading partner receives the flat file from the VAN.

    A middleware tool is used to convert the source file into the format required for the destination trading partner’s business application software.

  6. The destination trading partner loads the flat file into its business application system.

Processing Outbound Flat File EDI Transactions Using X.12 EDI Format

PeopleSoft can generate a X.12 EDI formatted flat file.

The following diagrams illustrate the outbound flat file EDI transaction process:

Outbound flat file EDI transaction processing using X.12 EDI format

To process outbound flat file EDI transactions using X.12 EDI format:

  1. The source trading partner initiates a PeopleSoft application process that retrieves the transactional data from the PeopleSoft application database tables and loads those EDI transactions into PeopleSoft staging tables, or prepares the data so it can be picked up by the Publish Outbound Message process.

  2. The source-trading partner performs the Publish Outbound Message process that reads the staging tables or application tables, and publishes the data as XML to the Integration Broker, based on the options set in the batch publish rules (XML options).

  3. The Integration Broker then transforms the data as specified on the active routings for the service operation and delivers the transformed data using the connector designated on the routing or node. For X.12 EDI data, this connector will often write a file to a directory or FTP server, but could be sent directly to a trading partner's gateway.

    Transformation examples are provided for the outbound 810 (Billing Invoice), 845 (Sales Quote Notice), 855 (Sales Order Acknowledgement), and the 856 (Advanced Shipping Notice).

    Note. These examples require customizations for individual trading partner requirements. Other outbound X.12 EDI transactions can be supported by creating transforms using the same concepts provided in the example transform programs.

  4. The source trading partner's VAN distributes the flat file to the destination trading partner's VAN.

  5. The destination trading partner receives the flat file from the VAN. A middleware tool is used to convert the source file into the format required for the destination trading partner’s business application software.

  6. The destination trading partner loads the flat file into its business application system.

Click to jump to top of pageClick to jump to parent topicUnderstanding Inbound and Outbound XML-Based EDI Transaction Processes

This overview section provides information about:

In a perfect world, the source trading partner and the destination trading partner would use the exact same format for the XML (EDI transactions) that they exchange between themselves, whether the XML is inbound or outbound. In this case, no mapping of the XML to the other trading partner's format would be required. XML would be exchanged between trading partners utilizing their web servers.

In a more realistic scenario, trading partners would still use XML to exchange information between each other, but one side would have to perform a transformation of the XML using their middleware product, such as that traditionally provided by VANs or, starting with PeopleSoft 9, using the mapping capabilities provided with the PeopleSoft Integration Broker.

In either of the scenarios above, the processing of EDI transactions utilizing XML eliminates a lot of system processing and offers a more direct exchange of information. The XML method provides for quicker turn around of information between trading partners and reduces logistics and control issues inherent in flat file processing.

Processing Inbound XML-Based EDI Transactions Using the PeopleSoft Format

An XML file can be generated by another PeopleSoft system, generated by a third-party system in this PeopleSoft XML format, or generated by a third-party system and then converted to the PeopleSoft XML format by a middleware product. Once received by your PeopleSoft system, the inbound data is placed in the message queue, checked for errors and then moved to the inbound staging tables to be processed by the individual PeopleSoft application.

The following diagram illustrates the inbound XML-Based EDI transaction process:

To process inbound XML transactions using the PeopleSoft format:

XML-Based EDI inbound transaction process using the PeopleSoft format

  1. The source trading partner publishes data to PeopleSoft’s Integration Broker Gateway.

    If one of the industry standard connectors compatible with PeopleSoft’s Integration Broker Gateway is being used and the data is compatible with PeopleSoft’s XML format, then it may be sent directly from the source site’s gateway to the destination’s (PeopleSoft system) gateway. If a compatible connector is not available then communications must be made using a middleware vendor that provides this connector. Also, if the data is not in PeopleSoft’s XML format a transformation (data mapping) to PeopleSoft’s XML format must be made either at the source site or at the destinations site.

    Note. Transformations to and from the trading partner formats can be performed using the PeopleSoft Integration Broker.

  2. If a middleware transformation is being performed, transform the source XML format to the destination PeopleSoft system's XML format.

    Note. Many middleware products can convert from standard EDI formats (X.12 EDI or EDIFACT) to XML and then post to the PeopleSoft system. When using these products, you can still eliminate the use of flat files coming in and out of the PeopleSoft system even when working with trading partners that are not ready to move to the new technology. When utilizing this approach, flat files would still be used between the middleware product and the trading partner.

  3. PeopleSoft subscription processes (OnNotify Handlers) are automatically executed that retrieve the XML from the message queue and then load the information into staging tables.

  4. Different PeopleSoft applications read the transactions from the staging tables and load the data to the actual PeopleSoft application database .

Processing Inbound XML-Based EDI Transactions Using the X.12 Format

An XML file can be generated by a third-party system in this X.12 EDI XML format or generated by a third-party system and then converted to the X.12 EDI XML format by a middleware product. An EDI XML file could also come from another PeopleSoft system. Once received by your PeopleSoft system, the PeopleSoft Integration Broker uses transforms to convert the data from X.12 EDI format to the PeopleSoft format. The inbound PeopleSoft-formatted XML data is then placed in the message queue, checked for errors, and then moved to the inbound staging tables to be processed by the individual PeopleSoft application.

The following diagram illustrates the inbound XML-Based EDI transaction process:

XML-Based EDI inbound transaction process using X.12 EDI format

To process inbound XML transactions using X.12 EDI format:

  1. The source trading partner publishes data to PeopleSoft’s Integration Broker Gateway.

    If one of the industry standard connectors compatible with PeopleSoft’s Integration Broker Gateway is being used and the data is formatted in a compatible X.12 EDI format, then it may be sent directly from the source site’s gateway to the destination’s (PeopleSoft system) gateway. If a compatible connector is not available, communications must be made using a middleware vendor that provides this connector. Also, if the data is not in an X.12 EDI format, a transformation (data mapping) to an X.12 EDI format must be provided using a middleware product.

  2. If a middleware transformation is being performed, transform the source XML format to X.12 EDI XML format.

  3. PeopleSoft Integration Broker processes the data.

    Using pre-defined transformations, the PeopleSoft Integration Broker will convert the source trading partner's X.12 EDI XML format to a PeopleSoft XML format, leaving the final product in the message queue.

    People Soft subscription processes (On Notify Handlers) are then automatically executed to retrieve the data from the message queue and load it into staging tables.

    Inbound transformation examples are provided for the 840 (Sales Quote Load) and 850 (Sales Order Load) X.12 EDI transaction set formats.

    Note. These examples require customizations for individual trading partner requirements. Other inbound X.12 EDI transactions can be supported by creating transforms using the concepts provided in the example transform programs.

  4. Different PeopleSoft applications initiate processes that read the transactions from the staging tables and load the data to the actual PeopleSoft application database tables.

Processing Outbound XML-Based EDI Transactions Using the PeopleSoft Format

PeopleSoft can generate a PeopleSoft-formatted XML file to be received by another PeopleSoft system, such as CRM, or a third-party system with or without conversion by a middleware product.

The following diagram illustrates the outbound XML-Based EDI transaction process:

XML-Based EDI outbound transaction process using the PeopleSoft format

To process outbound XML-based EDI transactions using the PeopleSoft format:

  1. The source trading partner initiates a PeopleSoft application process that retrieves the transactional data from the PeopleSoft application database tables and loads those EDI transactions into PeopleSoft staging tables, or prepares the data so it can be picked up by the Publish Outbound Message process.

  2. The source trading partner performs the Publish Outbound Message process that retrieves the transactions from the staging tables or application tables, and publishes the data as XML to the Integration Broker, based on the options set in the batch publish rules (XML options).

    If one of the industry standard connectors compatible with PeopleSoft’s Integration Broker Gateway is being used and the destination's XML format is compatible with PeopleSoft’s XML format then it may be sent directly from the source site to the destination’s gateway. If a compatible connector is not available then communications must be made using a middleware vendor that provides this connector. Also, if the data is not in PeopleSoft’s XML format a transformation (data mapping) “from” PeopleSoft’s XML format must be made either at the source site, a middleware site or at the destinations site.

    Note. Transformations to and from the trading partner formats can be performed using the Integration Broker. In this situation the Integration Broker can perform the transformation and then with the correct connector can post directly to the destination trading partner's system.

  3. If a middleware transformation is being performed, transform the PeopleSoft XML format to the destination’s XML format.

    If a middleware connector is required the middleware product will post to the destinations gateway or will create a flat file to be received by the trading partner through their VAN.

    Note. Many middleware products can convert from the PeopleSoft XML format to standard EDI formats (X.12 or EDIFACT) required by trading partners. When using these products you can still eliminate the use of flat files coming in and out of the PeopleSoft system even when working with trading partners that are not ready to move to the new technology. When utilizing this approach flat files would still be used between the middleware product, VAN and the trading partner.

Note. See PeopleTools documentation for information about PeopleSoft XML formats, PeopleSoft listening connectors, and PeopleSoft target connectors.

Processing Outbound XML-Based EDI Transactions Using the X.12 EDI Format

PeopleSoft can generate an EDI X.12-formatted XML transaction to be received by a third-party system with or without conversion by a middleware product. As delivered, the outbound EDI service operation routings convert the PeopleSoft-formatted XML data into a X.12 EDI formatted flat file using transform programs; first by converting to an EDI XML format and then to a flat file format. However, by removing the second transform program from the routing you can change the system to output X.12 EDI data using XML.

The following diagram illustrates the outbound XML-based EDI transaction process:

XML-based EDI outbound transaction process using X.12 EDI format

To process outbound XML-based EDI transactions using X.12 EDI format:

  1. The source trading partner initiates a PeopleSoft application process that retrieves the transactional data from the PeopleSoft application database tables and loads those EDI transactions into PeopleSoft staging tables, or prepares the data so it can be picked up by the Publish Outbound Message process.

  2. The source-trading partner performs the Publish Outbound Message process that retrieves the transactions from the staging tables or application tables, and publishes the data as XML to the Integration Broker, based on the options set in the batch publish rules (XML options).

  3. The PeopleSoft Integration Broker then transforms the data as specified on the active routings for the service operation and delivers the transformed data using the connector designated on the routing or node.

    The Integration Broker posts the X.12 EDI XML to the trading partner's gateway. If the trading partner requires transformations of the X.12 EDI XML into their proprietary format, they will use a middleware product at this point. Otherwise the XML is posted directly into their application system.

    Transformation examples are provided for the outbound 810 (Billing Invoice), 845 (Sales Quote Notice), 855 (Sales Order Acknowledgement) , and the 856 (Advanced Shipping Notice).

    Note. These examples require customizations for individual trading partner requirements. Other outbound X.12 EDI transactions can be supported by creating transforms using the same concepts provided in the example transform programs.

Click to jump to parent topicSetting Up EDI Transactions Using Flat Files

This section discusses how to:

Click to jump to top of pageClick to jump to parent topicSetting Up Inbound EDI Transactions Using Flat Files

To set up an inbound EDI transaction using flat files:

  1. If trading partner is not delivering data in PeopleSoft’s business document file format, set up mapping software to transform the trading partner's format to the PeopleSoft format.

    For a definition of PeopleSoft’s business document file format, obtain the file layout for the EDI transaction. For information about obtaining the file layouts, see Obtaining File Layouts, which appears later in this document.

    For the appropriate file layout definition for each transaction, refer to the table in the Reviewing PeopleSoft Supported EDI Transactions section.

  2. Perform application specific setup.

    Refer to the table in the Reviewing PeopleSoft Supported EDI Transactions section for information on locating documentation explaining application-specific setup instructions for each EDI transaction.

  3. Perform Integration Broker setup.

    You must set up and activate nodes, service operations, handlers and routings before you can begin processing inbound transactions.

    1. Set up nodes.

      PeopleSoft delivers a sample external inbound node (PSFT_XINBND) used to deliver sample routing definitions for each service operation. For inbound transactions using flat files you need the default local node only. The default local node (PSFT_EP) is packaged with initial delivery of the system. Unless you are changing the local node, no additional node setup is required. If for auditing purposes you wish to differentiate the node from which transactions are received, you may do so by creating a node definition and inbound file rule for each external trading partner or VAN you plan to integrate with, and specifying the sender node name on each inbound file rule.

    2. Activate Service Operations.

      PeopleSoft provides Service Operation definitions for each EDI transaction that you must activate before use.

    3. Activate Service Operation Handlers.

      OnNotify Service Operation Handlers are subscription processes that are automatically executed by Integration Broker when an inbound asynchronous transaction is received. PeopleSoft provides OnNotify Handlers on each asynchronous service operation that supports inbound integration. You must activate the appropriate OnNotify Handler on each Service Operation before use.

    4. Activate Service Operation Routings.

      Service Operation Routings define the sending and receiving nodes for an integration, the external name of the integration, and optionally specify inbound and outbound transformations to be invoked on each transaction. The sender node on inbound routings can be specified as “ANY” node allowing transactions to be received from any valid node. For each trading partner or VAN sending data into PeopleSoft, a routing must be activated either from a specific sender node, or from “ANY” node.

  4. Set up Inbound File Rule.

    For integrations using the PeopleSoft flat-file format, the Enterprise Components Inbound File Publish process uses an inbound file rule to identify information about the source file. Most EDI transactions are already set up on the SCM Inbound EDI file rule. If you are processing one of these transactions, then enter the file name on the file rule and activate the file rule.

    For integrations using the X.12 EDI flat-file format, the PeopleTools Integration Broker Inbound File Process uses an inbound file loader rule to identify information about the source file. Each sample inbound EDI transaction has been delivered with a sample inbound file loader rule. If you are processing one of these transactions, then enter the file name on the file rule and activate the file rule.

  5. When you are ready to process a trading partner's file, run the Inbound File Publish process.

    After you run the Inbound File Publish process, run the appropriate application process to validate and load the transactions.

Click to jump to top of pageClick to jump to parent topicSetting Up Outbound EDI Transactions Using Flat Files

To set up an outbound EDI transaction using flat files:

  1. If trading partner does not accept data in a PeopleSoft business document file format, set up mapping software to transform the PeopleSoft format to the trading partner's format.

    For a definition of a PeopleSoft business document file format, obtain the file layout for the EDI transaction. For information about obtaining the file layouts, see Obtaining File Layouts, which appears later in this document.

    For the appropriate file layout definition for each transaction, refer to the table in the Reviewing PeopleSoft Supported EDI Transactions section.

  2. Perform application specific setup.

    Refer to the table in the Reviewing PeopleSoft Supported EDI Transactions section for information on locating documentation explaining application-specific setup instructions for each EDI transaction.

  3. Perform Integration Broker Setup.

    You must set up nodes and activate service operations, handlers and routings before you can begin processing inbound transactions.

    1. Set up nodes.

      PeopleSoft delivers a sample external outbound node (PSFT_XOUTBND) used to deliver sample routing definitions for each service operation. For each external trading partner or VAN you plan to integrate with, a node definition must be set up and activated.

    2. Activate Service Operations.

      PeopleSoft provides Service Operation definitions for each EDI transaction that you must activate before use.

    3. Activate Service Operation Handlers.

      OnRoute Service Operation Handlers are processes that are automatically executed by Integration Broker when an outbound transaction is published. PeopleSoft provides OnRoute Handlers on each asynchronous service operation that supports chunking. For each Service Operation requiring chunking, you must activate the OnRoute Handler before use.

    4. Activate Service Operation Routings.

      Service Operation Routings define the sending and receiving nodes for an integration, the external name of the integration, and optionally specify inbound and outbound transformations to be invoked on each transaction. For each trading partner or VAN you will be sending data to from PeopleSoft, an outbound routing must be activated.

  4. Set up Batch Publish Rules.

    The Publish Outbound Message process uses the batch publish rules to identify information about the transaction being published. Batch publish rules have been prepackaged to work with each outbound transaction that is initiated using the Publish Outbound Message process. You must activate these rules and set the intended output format (flat file) before you can use them.

    Refer to the table in the Reviewing PeopleSoft Supported EDI Transactions section for information on the names of the batch publish rules associated with outbound EDI transactions.

    When using an output format of flat file (PeopleSoft format) on the batch publish rule, the data is never sent to the Integration Broker—the output goes directly to a flat file. Consequently, the node, queue and routings do not need to be set up for outbound transactions published from the Publish Outbound Message process that are going to flat files using the PeopleSoft format. However, you must activate the service operation, as the system performs validations to prevent unexpected transactions from being generated. In all other scenarios, the output format should be set to message.

    Note. Batch Publish Rules optionally use a feature called chunking, which enables you to break up data based on unique field values within it. For example, if you were sending purchase orders directly to a trading partner without going through a middleware system (VAN), you must ensure that only that Vendor's data is included on the transactions sent to that trading partner. If you were not using chunking, and you had separate nodes set up for each of your trading partners, then every transaction would go to every trading partner. Chunking provides a mechanism to ensure that transactions contain only information for a single trading partner and enables them to be routed to the node of that trading partner.

    When using a single middleware product (VAN), you use a single node to identify that product's destination URL; in this scenario, chunking is not required. In this case, all trading partner transactions can be sent together as the segregation and routing by trading partner is performed in the middleware product.

  5. When you are ready to generate EDI transactions, run the appropriate application processes.

    Refer to the table in the Reviewing PeopleSoft Supported EDI Transactions section for information on where to find the documentation explaining the application specific information for each EDI transaction.

Click to jump to parent topicSetting Up EDI Transactions Using XML

This section discusses how to:

Click to jump to top of pageClick to jump to parent topicSetting Up Inbound EDI Transactions Using XML

To set up an inbound EDI transaction using XML:

  1. If the trading partner is not delivering XML data in a PeopleSoft format, then set up mapping software to transform the trading partner's XML to a PeopleSoft format.

  2. Configure the Integration Gateway and identify the connector to use when communicating between gateways.

    Use the Integration Broker Gateway for all transactions in and out of the PeopleSoft system. Detailed definitions and setup information can be found in the PeopleTools Integration Broker PeopleBook.

    If you use one of the industry standard connectors compatible with Integration Broker, then transactions may be sent directly from the source site's gateway to the PeopleSoft Integration Broker Gateway. If a compatible connector is not available, you can develop a custom connector, or complete communications using a middleware vendor that provides this connector.

  3. Perform application specific setup.

    Refer to the table in the PeopleSoft Supported EDI Transactions section for information on locating documentation explaining application-specific setup instructions for each EDI transaction.

  4. Perform Integration Broker setup.

    You must set up and activate nodes, service operations, handlers and routings before you can begin processing inbound transactions.

    1. Set up nodes.

      PeopleSoft delivers a sample external inbound node (PSFT_XINBND) used to deliver sample routing definitions for each service operation. For inbound transactions using flat files you need the default local node only. The default local node (PSFT_EP) is packaged with initial delivery of the system. Unless you are changing the local node, no additional node setup is required. If for auditing purposes you wish to differentiate the node from which transactions are received, you may do so by creating a node definition and inbound file rule for each external trading partner or VAN you plan to integrate with, and specifying the sender node name on each inbound file rule.

    2. Activate Service Operations.

      PeopleSoft provides Service Operation definitions for each EDI transaction that you must activate before use.

    3. Activate Service Operation Handlers.

      OnNotify Service Operation Handlers are subscription processes that are automatically executed by Integration Broker when an inbound asynchronous transaction is received. PeopleSoft provides OnNotify Handlers on each asynchronous service operation that supports inbound integration. You must activate the appropriate OnNotify Handler on each Service Operation before use.

    4. Activate Service Operation Routings.

      Service Operation Routings define the sending and receiving nodes for an integration, the external name of the integration, and optionally specify inbound and outbound transformations to be invoked on each transaction. The sender node on inbound routings can be specified as “ANY” node allowing transactions to be received from any valid node. For each trading partner or VAN sending data into PeopleSoft, a routing must be activated either from a specific sender node, or from “ANY” node.

  5. When the trading partner sends XML to the PeopleSoft Integration Broker Gateway, it will automatically be processed by a handler.

    In most cases the transactions are loaded into staging tables where they wait for you to run the appropriate application process to validate and load them into the PeopleSoft application database.

Click to jump to top of pageClick to jump to parent topicSetting Up Outbound Transactions Using XML

To set up an outbound EDI transaction using XML:

  1. If the trading partner is not accepting XML data in a PeopleSoft format, then set up mapping software to transform the PeopleSoft XML to the trading partner's format.

  2. Configure the Integration Gateway and identify the connector to use when communicating between gateways.

    Use the Integration Broker Gateway for all transactions in and out of the PeopleSoft system. Detailed definitions and setup information can be found in the PeopleTools Integration Broker PeopleBook.

    If you use one of the industry standard connectors compatible with Integration Broker, then transactions may be sent directly from the PeopleSoft Integration Gateway to the destination’s gateway. If a compatible connector is not available, you can develop a custom connector, or complete communications using a middleware vendor that provides this connector.

  3. Perform application specific setup.

    Refer to the table in the PeopleSoft Supported EDI Transactions section for information on locating documentation explaining application-specific setup instructions for each EDI transaction.

  4. Perform Integration Broker Setup.

    You must set up nodes and activate service operations, handlers and routings before you can begin processing inbound transactions.

    1. Set up nodes.

      PeopleSoft delivers a sample external outbound node (PSFT_XOUTBND) used to deliver sample routing definitions for each service operation. For each external trading partner or VAN you plan to integrate with, a node definition must be set up and activated.

    2. Activate Service Operations.

      PeopleSoft provides Service Operation definitions for each EDI transaction that you must activate before use.

    3. Activate Service Operation Handlers.

      OnRoute Service Operation Handlers are processes that are automatically executed by Integration Broker when an outbound transaction is published. PeopleSoft provides OnRoute Handlers on each asynchronous service operation that supports chunking. For each Service Operation requiring chunking, you must activate the OnRoute Handler before use.

    4. Activate Service Operation Routings.

      Service Operation Routings define the sending and receiving nodes for an integration, the external name of the integration, and optionally specify inbound and outbound transformations to be invoked on each transaction. For each trading partner or VAN you will be sending data to from PeopleSoft, an outbound routing must be activated.

  5. Set up Batch Publish Rules.

    The Publish Outbound Message process uses the batch publish rules to identify information about the transaction being published. Batch publish rules have been prepackaged to work with each outbound transaction that is initiated using the Publish Outbound Message process. You must activate these rules and set the intended output format (message) before you can use them.

    Refer to the table in the PeopleSoft Supported EDI Transactions section for information on locating documentation explaining application-specific setup instructions for each EDI transaction.

    Note. Batch Publish Rules optionally use a feature called chunking, which enables you to break up data based on unique field values within it. For example, if you were sending purchase orders directly to a trading partner without going through a middleware system (VAN), you must ensure that only that Vendor's data is included on the transactions sent to that trading partner. If you were not using chunking, and you had separate nodes set up for each of your trading partners, then every transaction would go to every trading partner. Chunking provides a mechanism to ensure that transactions contain only information for a single trading partner and enables them to be routed to the node of that trading partner.

    When using a single middleware product (VAN), you use a single node to identify that product's destination URL; in this scenario, chunking is not required. In this case, all trading partner transactions can be sent together as the segregation and routing by trading partner is performed in the middleware product.

  6. When you are ready to generate EDI transactions, run the appropriate application processes.

    Refer to the table in the Reviewing PeopleSoft Supported EDI Transactions section for information on where to find the documentation explaining the application specific information for each EDI transaction.

Click to jump to parent topicCustomizing Transforms for Specific EDI Implementations

This section discusses how to:

Click to jump to top of pageClick to jump to parent topicUnderstanding Custom EDI Integrations

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:

Click to jump to top of pageClick to jump to parent topicMapping Custom Integration Requirements

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. Each worksheet 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.

An example from one of the worksheets is shown here below:

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.

Click to jump to top of pageClick to jump to parent topicCreating Sample EDI Transaction Files

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 example shows the first few lines of a sample EDI file:

Click to jump to top of pageClick to jump to parent topicCustomizing Messages and File Layouts

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 and PIA 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.

Note. It is very important that the file layout and the message definition match exactly. If they do not, the transformation process may fail with unpredictable results.

Click to jump to top of pageClick to jump to parent topicCustomizing XSLT Transforms

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.

Note. This new transform AE will then be used in place of the sample one when creating a service operation routing for the integration to the trading partner.

Click to jump to top of pageClick to jump to parent topicCustomizing the EDI File Loader Utility

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.

Note. In rare cases, a trading partner's integration requirements may be so unique as to require some customization of the EDI_FileLoader application class, but that should be done only in cases where the requirements go beyond what can be customized in the layouts and XSLT.

Click to jump to top of pageClick to jump to parent topicCustomizing the XML to File Utility

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, etc) as appropriate for the specific implementation at their site.

Note. In rare cases, a trading partner's integration requirements may be so unique as to require some customization of the XMLtoFlatFile application class, but that is not anticipated and should be done only as a last resort.

Click to jump to parent topicProcessing Error Handling

Most inbound asynchronous transactions, no matter which technology delivers them to the PeopleSoft system, are loaded into staging tables, where they are validated by background routines scanning these staging tables awaiting incoming work. If errors are found, the transaction status in the transaction log is changed to Error, and rows are inserted into error tables for each error message.

In PeopleSoft, error messages appear on the Transaction Maintenance page for transactional type data, such as inventory adjustments and purchase order receipts. To review definitional type data, such as item master and bills of material, you can use the Data Definition page correct the erroneous information.

Once you have corrected the information and saved the page, the transaction is ready to be reprocessed.

Some transactions provide functionality to immediately validate and update application tables from subscription processes (OnNotify Handlers). For example, the Consumer and Par Location Count transactions both attempt to update the application tables, but if errors are found, the transactions write the data to the error tables so that corrections can be made.

See Also

Enterprise PeopleTools 8.48 PeopleBook: Integration Tools

PeopleSoft Enterprise Components for Financials, Enterprise Service Automation and Supply Chain Management 9.0 PeopleBook, “Enterprise Integration”

Issuing Material to Production

Recording Completions and Scrap Using Electronic Data Collection

Understanding PeopleSoft Supply Chain Management Enterprise Integration Points