Integrating PeopleSoft Enterprise Manufacturing with Product Life Cycle Management Applications Using PDX 1.0 XML

This chapter provides overviews of the integration of PeopleSoft Enterprise Manufacturing to Product Life Cycle Management (PLM) applications and discusses how to:

• Set up PeopleSoft Enterprise Manufacturing for use with the integration.

• Run the PeopleSoft Enterprise integration.

• Review and correct PDX change order exceptions.

• Review important implementer and end-user guidelines.

Understanding the PDX Integration

You can use PeopleSoft Enterprise Manufacturing to send item, revision, and manufacturing bill of material (BOM) information to external applications This integration uses the product data exchange (PDX) version 1.0 XML format.

Note. The term PDX refers to the XML files containing change order information that is sent from the product life cycle management application to PeopleSoft.

See Also

Reviewing and Correcting Change Order Exceptions

Reviewing Important Implementer and End-User Guidelines

Overview the PeopleSoft Enterprise Product Data Exchange (PDX) Integration

PeopleSoft Enterprise Manufacturing integrates with PLM applications enabling you to send item, revision, and manufacturing BOM information using change orders.

Specifically, the PeopleSoft Enterprise system integrates with engineering change order (ECO) and manufacturer change order (MCO) subclasses of PDX to support inbound item (part) and BOM information into PeopleSoft Enterprise Manufacturing. This integration is one-way only (inbound to PeopleSoft), and supports one PLM system to one PeopleSoft Enterprise system (single business unit).

In general, implementing a PLM integration implies that the PLM system is the master data source for items, revisions, and BOMs instead of PeopleSoft. Therefore, when this integration is implemented, use PeopleTools security to severely restrict access (disallow changes) to item, revision, and BOM maintenance functions within PeopleSoft. Generally, these maintenance functions should only be done in PeopleSoft Enterprise for the data elements that are not maintained through the PLM system, for example, costing, purchasing or planning attributes on the Item Master. This maintenance depends on the specific implementation of the PLM application, as well as any modifications that you have made.

Integrating PeopleSoft Enterprise Manufacturing with PDX

Overview of Required Setup and Considerations for Integration

This section discusses:

• PeopleSoft Enterprise Manufacturing.

• The integration checklist.

PeopleSoft Enterprise Manufacturing

Once you have defined usage of a valid Life Cycle status within the product life cycle management application, you can then set up PeopleSoft Enterprise Manufacturing by defining default and mapping information within the Installations Options - Manufacturing page. These mappings look for custom fields in the XML as a system such as Agile™ would write them within the PDX 1.0 standard.

In addition, certain PeopleSoft Enterprise Integration Broker and messaging information is also required, which enables PeopleSoft Enterprise to receive the XML messages in the PDX 1.0 format.

Within PeopleSoft, you also set up a Daemon program and related job designed to process inbound change orders (within the PDX 1.0 messages) for items and BOMs sent in PDX format into PeopleSoft Enterprise master tables.

Integration Checklist

Use this checklist is useful to configure the PDX integration.

PeopleSoft Enterprise Manufacturing

Prerequisites

Prior to integrating PDX with PeopleSoft Enterprise Manufacturing, you must first install:

• PeopleSoft Enterprise Manufacturing software.

• PeopleSoft Integration Broker gateway supporting inbound messages for the manufacturing installation.

Important! You must also ensure that the current existing released items, revisions, and BOMs in the product life cycle management application are already present and in sync with the PeopleSoft Enterprise system prior to synchronizing data. In sync implies that the revision start dates in PeopleSoft Enterprise match the effective dates of those that were released previously from the product life cycle management application—if releases do exist—and that component effectivity for components on the BOMs also align with the date, revision, and markup information.

Setting Up PeopleSoft Enterprise Manufacturing for Use with a Product Life Cycle Management Application

These are the high-level steps that you must follow to set up the PeopleSoft Enterprise system:

1. On the PeopleSoft Enterprise Installation Options - Manufacturing page, define the general mappings for PDX data to be sent to PeopleSoft.

2. Set up the PeopleSoft messaging gateway to receive PDX messages.

   The PeopleSoft connectivity is accomplished by using inbound XML (PDX 1.0 standard) messaging which requires the set up of a messaging gateway.

   While areas that pertain to the XML messaging are contained in this document, basic understanding of setting up and using PeopleSoft messaging is assumed.

3. Define a Daemon group for the PeopleSoft Enterprise Process Scheduler to manage the processing of inbound items, revisions, and BOMs received by using PDX messages.

The table in the next section contains a general list of the pages used to set up PeopleSoft Enterprise Manufacturing to integrate with a life cycle management application. Many of these pages are delivered with the correct default information, and you are not be required to change them. These are included for informational purposes only. However, any additional setup related to these pages is included in this document, and is also noted within the Usage column.

See Also

Enterprise PeopleTools 8.46 PeopleBook: PeopleSoft Application Engine

Pages Used to Set Up PeopleSoft Enterprise Manufacturing to Integrate with a Product Life Cycle Management Application

Setting Up PDX Installation for Integration

Access the Installation Options - Manufacturing page.

PDX Defaults

User Defined Fields Mappings

PDX 1.0 supports user-defined fields within it. In version 1.0 of PDX, the Item Source Code and Unit of Measure are not standard fields. Some life cycle management systems (such as Agile™) will automatically populate custom attributes of the XML when you define these fields within the PLM system. If this is the case, you can use this group box to define additional mappings for the integration to reduce configuration. Item Source Code and Unit of Measure are required fields for PeopleSoft.

Note. These several pages describe the node and message relationships required to enable inbound messaging for PDX 1.0.

See Also

Managing Inventory by Item Status

Maintaining Node Information

Access the Node Definitions page.

Note. These relationships have already been defined and are delivered to you; however, you must activate them.

The PDX_MSG is delivered as part of the standard inbound PSFT_XINBND node definition. A node is required so that the PDX XML can be posted to the PeopleSoft system.

See Also

Enterprise PeopleTools 8.46 PeopleBook: Integration Broker

Maintaining Node Transaction Information

Access the Transactions page within the PSFT_XINBND node.

Click the Edit link to access the Transaction Detail page within the PDX_MSG.

Viewing Node Transaction Details

Access the Transaction Detail page.

Defining the PDX Relationship to PeopleSoft

Access the Relationships page for PSFT_XINBND.

The PSFT_XINBND relationship (within the node definition) has been defined for use with the integration. This relationship is associated with the PSFT_XINBND which enables conversion of the PDX 1.0 XML file into PeopleSoft inbound asynchronous ITEM_SYNC and BOM_SYNC messages.

Viewing the Transaction Modifiers

Access the Transaction Modifiers page for relationship PSFT_XINBND.

This page is display only.

Click the Edit link for the PDX_MSG message names to access the Transaction Modifiers page.

Maintaining Transaction Modifier Information

Access the Transaction Modifiers page.

Use this page to maintain the modifier that needs to be applied to each transaction for the initial node specified. Two transaction modifiers are defined: one to transform the PDX file into a BOM_SYNC message and the other to transform the same PDX file into an ITEM_SYNC message.

Transformations

See Also

Enterprise PeopleTools 8.46 PeopleBook: Integration Broker

Activating Messaging Within PeopleTools Application Designer

The PDX_MSG message is defined in the PeopleSoft Application Designer for use with PLM inbound messages. This message is transformed into two PeopleSoft inbound asynchronous messages: ITEM_SYNC and BOM_SYNC. These two messages must also be activated within PeopleTools Application Designer. In addition, the subscription properties for ITEM_SYNC and BOM_SYNC messages must be activated.

The channels of ITEM_MAINTENANCE, BOM_MAINTENANCE, and PDX must also be activated.

Setting Up and Running the Daemon Group and Related Job to Process Inbound PDX Files

This section discusses how to set up and run a Daemon group to process the transformed BOM_SYNC and ITEM_SYNC messages into PeopleSoft master tables (after the change has been sent).

The Daemon application engine program checks the stage table to determine whether there is any inbound set of change orders, which would result in items or BOMs being processed. It processes the changes for items, revisions, and BOMs received from the PLM by initiating the PDXJOB when necessary. The PDXJOB then drives the processes to ensure that one inbound pub ID (from a PDX message) is treated collectively and processed sequentially through the Item Loader (IN_ITMLOAD) and BOM Loader (EN_BOM_MSG) processes as part of the PDXJOB.

In addition, the PDXJOB includes an Alert process (PDXALERT) which notifies you of any processing errors.

This job should already exist and should be defined exactly as indicated in this screenshot:

See Step 2.

The processing sequence is very important when items, revisions, and BOM changes are sent to PeopleSoft. For example, item and revision information must be processed for a given change order prior to any BOM updates.

To set up item and BOM processing so that they do not automatically attempt to load at message subscription time:

1. Access the Data Maint Setup 1 page for transaction type ITEM and then for BOM.

   1. Clear the Flag 1 check box to prevent items and BOMs from being processed automatically. Clear this check box for both the item and BOM transaction type. This prevents item and BOM messages from being processed immediately and allows the PDX information to be properly staged for processing in PeopleSoft

      Clearing this check box provides greater reliability of the integration, because PeopleSoft items must exist or the BOM processing fails.

   2. Save the page after you have cleared the Flag 1 check box for both the Item and BOM transaction types.

      Important! This setup is done because it is highly recommended that you schedule the Item Load process and BOM Load process independent of the send process to ensure the reliability of back end processing. This is because the Item and BOM Loader programs are designed to process large sets of changes at once, but not multiple sets of the same items or BOMs.

      Note. If you have other ongoing uses of the ITEM_SYNC message outside of the integration, the setting of this flag may have an impact on those non-PLM areas. When the Daemon is enabled, it creates instances of the Item Loader process that process any inbound set of items staged for processing. Therefore, take this into consideration during the implementation.

2. Access the PeopleTools Job Definition page and review the job named PDXJOB.

   This PDXJOB job controls the processing of individual change order packages sent to PeopleSoft using a pub ID. The PDX_CONTROL controls the flow of these change orders by picking up item and BOM changes (IN_ITMLOAD and EN_BOM_MSG) from data maintenance in a FIFO (first in, first out) manner based on pub IDs that are ready to be processed. This ensures that all items for the pub ID are ready to be processed with the BOMs being sent.

   Note. The PDX_CONTROL job automatically creates a run control and sets the appropriate values for processing for both the Item and BOM Loader processes with the run control ID of PDX. The PDX alert run control must be created manually and is used to establish parameters for the alert.

   Note. Do not enter a value in the Recurrence Name field on the Job Definition Options page.

3. Set up the PDX Alert utility.

   The PDXJOB job includes the PDX_ALERT program designed to search for any processing errors and send an alert to the appropriate users.

   To facilitate exception processing, this email notification job is provided, which is included as the last process in the PDX_JOB initiated by the PeopleSoft Daemon. Each time a package is processed, this job searches for any recent processing errors found in the PDX Change Order Exceptions page. If any errors are found, an email notification can be sent to users associated with the specified role. This email also includes a URL link back to the PDX Change Order Exceptions component where users can view the details of the errors. The email also includes a list of change orders that are in error, as well as the date and time that they were staged within PeopleSoft.

   Important! The run control ID for this process must be manually created with the name of PDX to run as part of the PDX_JOB process.

   See Viewing Change Order Exceptions.

   Note. This notification is intended for use by a central administrator type role for any change order errors in PeopleSoft regardless of who released the change order.
   
   Using the notification requires setup of the SMTP mail server for the PeopleSoft Process Scheduler.

4. Access the Role Definition page.

   1. Create a new role that can be associated with all users who want to receive this email alert.

      This role does not need to contain any permission lists.

   2. Associate this role with appropriate user profiles that should be included in the email notification.

      Important! Make sure that each user has a valid default email address in the user profile. The mail is sent to the email entry that is marked as primary in the user profile.

      See Enterprise PeopleTools 8.46 PeopleBook: Security Administration

5. Access the PDX Alerts page.

   1. Create a run control ID that is to be used for each run of this utility.

      To run this as part of the PDX_JOB, the run control ID must be named PDX.

   2. Enter the role name created in step 4a. All users associated with this role are included on the email distribution.

   3. The Show errors occurring within the last ‘n’ Minutes value is used to determine how far back to look for change order errors on the PDX Change Order Exceptions page. This setting can help determine how many times you are notified if there are errors. Because this program (by default) is set up to run any time a message is processed, you may want to set this value to a minimum number of minutes to include only the latest change order errors and to send an email only once.

      If you want to be reminded of all errors in the PDX Change Order Exceptions page from the last day and receive notification each time the adapter is run, set this value to 480 minutes, assuming that the adapter is running 8 hours a day.

   4. The URL field automatically changes to the current machine (web server) being accessed at this time, combined with the PDX Change Order Exceptions page. This URL is included in the exception emails to be sent.

      To direct the user to log into a different machine or web server, change the beginning part of the string, but leave the latter portion untouched as this directs the user to the correct component.

6. Access the Daemon Group page and set up the Daemon group.

   1. Create a Daemon group named PDXDMON.

   2. Add the program name PDX_DMON to the Daemon group.

      PDX_DMON is a PeopleSoft Application Engine program that determines whether there is anything to be processed by the Item Loader and BOM Loader processes respectively. This Daemon is linked to PeopleSoft Process Scheduler and allows the inbound messages to be monitored without the overhead of starting a job to check each time.

7. Access the Servers page.

   Define the Daemon servers page as indicated for an appropriate server and use the Daemon group created in the previous step.

   Daemon Enabled	Select this check box.
   Daemon Group	Select the PDXDMON value.
   Daemon Sleep Time	Enter a value of 2.
   Recycle Count	Enter a value of 10.

   Note. After the Daemon group is assigned to a server, the Process Scheduler for that server must be restarted or rebooted.

   Important! You should set up only one server with this Daemon. It requires a single instance per PeopleSoft database.

See Also

Enterprise PeopleTools 8.46 PeopleBook: PeopleSoft Application Engine

Reviewing and Correcting Change Order Exceptions

This section discusses:

• How to review and correct any change order error exceptions after the change order information has been properly received by the PeopleSoft Enterprise Manufacturing system.

• How to define an email alert, which notifies you of load-time processing exceptions related to change orders for items and BOMs.

Overview of Change Order Exceptions

While the intent is obviously to not have any exceptions, the PDX Change Order Exceptions component is provided to identify and correct any errors that may occur.

This outlines the flow of change order information once it is received into the PeopleSoft Enterprise Manufacturing system:

1. Messages are posted from to the PeopleSoft message gateway (PDX_MSG), which contains the PDX change order data.

   The PDX message is processed. It is translated and subscribed to as item sync and BOM sync messages.

2. Item sync and BOM sync subscriptions write results to new entries by Pub ID (which relate to the PDX change data) within Data Maintenance as item for items and revisions, and BOM for bill of material changes.

3. The Daemon defined for the PeopleSoft Process Scheduler determines when to run the PDXJOB defined in “Steps to define and PDX Daemon.”

   The PDXJOB selects and processes the change order package (by Pub ID). This job processes the earliest transactions in the system (FIFO by Pub ID) by running the Item Loader and BOM Loader processes in PeopleSoft together sequentially.

4. Any exceptions processing the PDXJOB are visible within the PDX Change Order Exceptions component defined in this section.

Note. This component provides a special view of the item and BOM data maintenance information in the context of ECO numbers containing Revision information. If the PDX sent contains manufacturing change orders (such as MCOs that have no revision information), these changes are consolidated into a single line within the exception page with the value'***MCO***' if in error. The generic value '***MCO***' is configurable in the Message Catalog utility under message set number 7026 and message number 204.

See Also

Viewing Change Order Exceptions

Pages Used to Review and Correct PDX Change Order Exceptions

Viewing Change Order Exceptions

Access the PDX Change Order Exceptions page.

This page provides you visibility of incoming staged items and BOMs within the context of change orders only. This page is a view of the information by item or BOM in the Data Maintenance component.

Viewing PDX Change Order Exceptions Error Details

Access the PDX Change Order Exceptions - Error Detail page.

Viewing Completed Change Order Exception Errors

Access the Completed by Change Order page.

This page identifies completed items based solely on the presence of new entries in the item, revision, and BOM production tables within PeopleSoft. This is identified in the system by storing the change order number within the Revision and BOM additional text fields.

Correcting Change Order Errors

It is highly recommended that when there is a BOM processing (data entry) error the error should be corrected within the product life cycle management system and the change order resent to PeopleSoft. In this case, click the Cancel button on the PDX Change Order Exceptions page to cancel all remaining unprocessed and errored entries in the ITEM and BOM staged tables and then resend the entire change order.

Note. Cancel the change order first in PeopleSoft so that subsequent sends of the same change order are not confused with the earlier send, which had an error.

For example, you send two new component items (C1 and C2) and one assembly item (A123), along with one BOM markup for the assembly item A123. It is possible that the two component items process correctly yet the BOM markup fails (for example, a third component (C3) is referenced on BOM A123, but is missing). In this case, canceling the errored change order rows, repairing the change order by adding the third component, and resending the change order to PeopleSoft is a preferred method of correction.

Data Entry Errors

Engineering Errors to Released and Sent Change Orders

There is no “undo” capability for change orders applied to PeopleSoft. Therefore, you should not make any engineering-type changes to a change order (such as BOM markups) after it has already been sent and processed successfully within PeopleSoft. For example, successfully sending a markup to PeopleSoft and then subsequently unreleasing the change order, changing the markup, and resending the same change order to PeopleSoft is not allowed. Doing so causes both systems to be out of sync.

Note. If additional engineering changes are required to repair a change order, a subsequent change order and release to PeopleSoft is the proper method of correction.

Change Order Errors - Examples

These are some common change order errors that you may encounter:

• A component listed on the BOM was mistakenly left off the change order that was corrected within Agile™, and then the change order was resent to PeopleSoft.

  In this case, click the Cancel button on the PDX Change Order Exceptions page to cancel all remaining unprocessed and error entries in the item and BOM staged tables and resend the change order.

• You sent two new component items (C1 and C2) and one assembly item (A1), along with one BOM markup for the assembly item A1.

  It is possible that the two component items processed correctly, but the BOM markup failed (perhaps a third component, C3, is referenced on BOM A1 but is missing).

  In this case, canceling the change order rows with an Error status, repairing the change order by adding the third component, and resending the change order to PeopleSoft is a preferred method of correction.

Reviewing Important Implementer and End-User Guidelines

When integrating two software systems, it is very important to understand and work with the differences of the two systems to maximize the integration success. This is most notably due to subtle functional differences between the two systems.

Here are some important guidelines to help with the integration:

• Determine transaction size, volume, and frequency.

  The typical size and volume of the change orders determines how often and how much to process through the PeopleSoft within a single PDX file. Care should be taken to reduce the chance of extremely large files (files over 8 megabytes not recommended). PeopleSoft recommends sending more PDX files with smaller numbers of change orders more frequently rather than very large files containing volumes of changes with less frequency.

  Schedule the PDX Daemon (PDXDMON) within PeopleSoft to compliment the typical flow of change orders being sent.

  For example, if you typically have 6 to 10 change orders released each hour (interval), you should schedule the PDXDMON to look for new change orders more frequently (such as wake up perhaps every 5 minutes so a maximum of 20 change orders per hour could be processed). Again, if you want to process changes more quickly, you can schedule the Daemon to look more frequently for new packages.

• Avoid the redo and resend markup pitfall.

  Once a change order has been processed and sent to PeopleSoft, it is highly recommended that you never back out and unrelease a change order in the PLM, change the BOM markup data, and then resend it to PeopleSoft. This will frequently cause unpredictable integration errors and BOM synchronization problems, because PeopleSoft has already successfully processed each of the original released markups for the initial change order.

• Define field lengths and required fields in the PLM.

  This is critical to the reliability of the integration to ensure that all PeopleSoft required fields have valid values, and that these values have the correct lengths for PeopleSoft. If they do not, transaction errors occur on the back end (PeopleSoft side) of the integration.

• Use caution regarding processing multiple revisions for an item in one day.

  The PeopleSoft Manufacturing revision scheme supports only one revision per day. Some environments may require that multiple revisions be released for the same item in one day. If this occurs in the environment, note that by default only the latest revision number can be tracked within PeopleSoft for that day. Furthermore, all the revision changes for a BOM are combined with the latest revision for the day. For example:

  • Revision A on 6/1/2003, 9 am: Adds component XYZ-1 to BOM 123

  • Revision B on 6/1/2003, 10 am: Adds component XYZ-2 to BOM 123

  • Revision C on 6/1/2003, 1 pm: Adds component XYZ-3 to BOM 123

    Within PeopleSoft Enterprise Manufacturing, the net effect is revision C showing XYZ-1, XYZ-2, and XYZ-3 added for BOM 123 under revision C.

    If a prior revision (such as revision A or B in the previous example) has already been used within production (on a production ID or production schedule) and a new revision for the same item and effective date is sent, the change order will error out within PeopleSoft (PDX Change Order Exceptions page) as seen in this screenshot. This occurs because when you send multiple revisions during one day, you are overwriting an original revision, for example, the production ID would be left tagged with a revision that no longer exists in the system.

Send multiple revisions each day in an environment where you can anticipate that this is not a problem, because you normally want to pick up the latest revision for existing production IDs created on that day.

In this case, use these PDX exceptions as an alert that the production IDs must be unreleased (blank revision) and allow the newest revision to be assigned to the production ID once the revision is sent to the PeopleSoft Enterprise system.