Integrating Oracle's PeopleSoft Manufacturing with Product Life Cycle Management Applications Using PDX 1.0 XML

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

• Set up PeopleSoft Manufacturing for use with the integration.

• Run the PeopleSoft integration.

• Review and correct PDX change order exceptions.

• Review important implementer and end-user guidelines.

Understanding the PDX Integration

You can use PeopleSoft Manufacturing to receive item, revision, and manufacturing bill of material (BOM) information from 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 Product Data Exchange Integration

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

Specifically, the PeopleSoft 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 Manufacturing. This integration is one-way only (inbound to PeopleSoft), and supports one PLM system to one PeopleSoft 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 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 Manufacturing with PDX

Overview of Required Setup and Considerations for Integration

This section discusses:

• PeopleSoft Manufacturing.

• The integration checklist.

PeopleSoft 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 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 Integration Broker and messaging information is also required, which enables PeopleSoft to receive the — service operation 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 service operations) for items and BOMs sent in PDX format into PeopleSoft master tables.

Integration Checklist

Use this checklist is useful to configure the PDX integration.

PeopleSoft Manufacturing

Prerequisites

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

• PeopleSoft Manufacturing software.

• PeopleSoft Integration Broker gateway supporting inbound service operations 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 system prior to synchronizing data. In sync implies that the revision start dates in PeopleSoft 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 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 system:

1. On the PeopleSoft 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 service operations.

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

   While areas that pertain to the service operations are contained in this document, basic understanding of setting up and using PeopleSoft gateway and service configuration is assumed.

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

The table in the next section contains a general list of the pages used to set up PeopleSoft 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.48 PeopleBook: PeopleSoft Application Engine

Pages Used to Set Up PeopleSoft 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 service operations required to enable inbound messaging for PDX 1.0.

See Also

Managing Inventory by Item Status

Viewing Service Operations

Access the Service Operations - General page.

Review or edit general information such as service and operation type, handlers, and routings associated with the BOM_SYNC and ITEM_SYNC service operations.

Activating Routings

Access the Routing Definitions page or the Service Operations - Routings page.

Active	Select this check box.
Save	Click this button to save your changes and activate the routing.

Important! You must activate the BOM_SYNC_PDX and ITEM_SYNC_PDX routings.

If you are activating the routings by using the Service Operations - Routings page:

1. Select the check box for the BOM_SYNC_PDX routing definition.

2. Click the Activate Selected Routings button.

   The routing Status changes to Active.

3. Click the Save button.

Perform these same steps for the ITEM_SYNC service operation and ITEM_SYNC_PDX routing.

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 service operations 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 transaction (from a PDX service operation) 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 when the service operation is processed

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 data 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 service operation 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 by incoming transaction. 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 PDX transactions that are ready to be processed. This ensures that all items for the same transaction are ready to be processed with the BOMs being sent.

   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 PDXJOB 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 PDXJOB process.

   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. Access the Role Definition page (PeopleTools, Security, Permissions and Roles, Roles).

   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.48 PeopleBook: Security Administration

4. Access the PDX Alerts page (SCM Integrations, Transaction Error Handling, PDX Alerts).

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

   2. Enter the role name created in step 3a.

      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 service operation 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.

5. 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 service operations to be monitored without the overhead of starting a job to check each time.

6. 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.48 PeopleBook: PeopleSoft Application Engine

Reviewing and Correcting Change Order Exceptions

This section provides an overview of change order exceptions, and discusses how to:

• View change order exceptions.

• View PDX change order exceptions error details.

• View completed change order exception errors.

• Correct change order errors.

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 Manufacturing system:

1. Service operations are posted to the PeopleSoft service operation gateway (PDX_MSG), which contains the PDX change order data.

   The PDX service operation is processed. It is translated and subscribed to as ITEM_SYNC and BOM_SYNC service operations.

2. Item sync and BOM sync service handlers write results to new entries by transaction (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 transaction). This job processes the earliest transactions in the system 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 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 system.