Managing PeopleSoft Customer Relationship Management Integration Points

Appendix: Managing PeopleSoft Customer Relationship Management Integration Points

This chapter provides an overview of the interactive services repository, PeopleSoft Customer Relationship Management (PeopleSoft CRM) integration points, and discusses how to:

Process PeopleSoft Business Interlinks transactions.
Process inbound service operations.
Process inbound transactions.
Process outbound service operations.
Set up chunking.
Publish outbound service operations.

Understanding the Interactive Services Repository

The Interactive Services Repository (ISR) is a compilation of information about the numerous service endpoints exposed by Oracle's PeopleSoft Enterprise, JD Edwards EnterpriseOne and JD Edwards World product families. Integration Points, also known as EIPs or XPBs, are the web service connections that allow PeopleSoft and JD Edwards applications to work smoothly with third-party systems and software, as well as other Oracle applications.

ISR works in conjunction with PeopleBooks to help users and implementation specialists fully explore the integration capabilities of our products. ISR has replaced the Enterprise Integration Points Catalog on Customer Connection.

Developers use ISR to document the technical structure of an integration point, its design patterns, and underlying technology. Analysts will use ISR to explore and understand integration points from a business process context. This is especially useful when implementing an Oracle-supported reference business process across multiple products and release versions.

Key Search Features of ISR

ISR contains high-level information about each integration point, including:

Brief description.
Product family.
Product owner.
Business Process association.
Data rules.
Setup rules.

ISR enables you to quickly discover the integration points that are relevant to your specific needs. You can search for integration points by name, integration set, product, between products, business process, and technology type. To access ISR, go to Customer Connection and select Implement, Optimize, and Upgrade, Implementation (or Optimization, or Upgrade) Guide, Implementation (or Optimization, or Upgrade) Documentation and Software, Interactive Services Repository (ISR).

Understanding PeopleSoft CRM Integration Points

PeopleSoft CRM integration points enable you to:

Send or publish service operations to a third-party system.
Accept or subscribe to service operations from third-party systems.
Send a synchronous request and reply transaction to a third-party system for processing.

Processing PeopleSoft Business Interlinks Transactions

Sometimes PeopleSoft CRM needs to call an external system vendor's application to request information. This information must be provided in a realtime, synchronous mode. The PeopleSoft application waits for the answer from the other application in realtime, before the PeopleSoft application can continue processing.

These transactions use PeopleSoft Business Interlinks definitions to specify the data passed to this external system as well as to define the output to be received from the external system. The data that is passed from the interlink object is interpreted by an interlink plug-in, which then contacts the external system, passes the data in the correct form, retrieves the data, and then passes it, in the correct form, back to the interlink object.

Note. Business Interlink are just one of the ways you can process realtime transactions. There are many different ways you can capture this kind of information. Please refer to the ISR section on Customer Connection for more information.

Processing Inbound Service Operations

Third-party systems can send PeopleSoft applications information using a number of integration points established throughout the system. Depending on the application, various technologies provide multiple options for interacting with the PeopleSoft system. Each option provides audit trails, validations, and error handling to insure that data integrity is maintained within the PeopleSoft database.

See http://www.peoplesoft.com/corp/en/iou/optimize/doc_software.jsp

Understanding the Inbound Transaction Architecture

Depending on the requirements of the interacting system and the integration point within the PeopleSoft system, various technologies are used to receive transactions into the PeopleSoft system:

Application Message Based Transaction

The PeopleSoft Application Messaging functionality provides a method for asynchronous communications between external systems and PeopleSoft applications using industry standard XML-formatted messages. XML messages are automatically loaded into the PeopleSoft system by setting the queue status to run for each message type. You can view all transactions in the transaction log and access the detail pages that enable you to correct transaction errors. Most subscription processes get associated to handlers. Handlers are then defined on a service operation.

The Inbound File Publish utility, which utilizes the File Layout Object tool, may also be used to automatically convert flat file input to XML-based application messages.

Electronic Data Collection Transaction Pages

PeopleSoft CRM includes transaction pages for many of the inbound transactions. The transaction pages are designed for quick data entry. There are minimal edits, and no application database updates are performed in these pages as the background programs scanning the transaction logs handle detail processing. The transaction pages provide a method of quick data entry for much of the transaction-based information processed by the system. You can enter the transactions directly onto the page, or attach a wedge and bar code reader to take advantage of bar code scanning benefits.

System-Generated Transactions

Several transactions that are fed in the transaction log are generated from internal application programs. By generating these transactions, applications push heavy processing functions to a background mode.

Validations, Error Handling, and Database Updates

Most inbound 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 transaction logs 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.

Error messages appear on the Transaction Maintenance page for transactional type data such as, inventory adjustments and purchase order receipts (select PeopleTools, EDI Manager, View EDI Audit Trail, Transaction Maintenance).

For definitional type data such as item master and bills of material, the Data Definition page is used to review and 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. 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.

Processing Outbound Service Operations

Outbound EIPs exist throughout the PeopleSoft system, providing interface points for third-party applications requiring information as activity occurs within the PeopleSoft system. The PeopleSoft Application Messaging technology is utilized to format and publish industry standard XML messages. For example, as item master information is entered into PeopleSoft applications, the system generates XML-based messages and delivers them to third-party systems requiring this information to set up their own item master tables.

Understanding the Outbound Transaction Architecture

PeopleSoft CRM applications as well as interacting third-party systems have various processing and timing requirements that dictate when information can be generated or received. For this reason, the integration points provided by PeopleSoft utilize a number of different approaches when generating outbound application messages.

For example, a third-party system requiring item master information from the PeopleSoft Inventory application may want immediate incremental updates as information is changed online or may want periodic updates on a nightly or weekly basis. The Item Master EIP provides both options, giving the third-party system the choice as to how it wants to receive this information.

Component or Incremental Publish

The system generates Component Published messages immediately upon saving a component in various PeopleSoft applications. Components used to maintain setup type information such as items or customers utilize the Component Publish approach.

Batch Publish

Batch Publish messages provide the functionality to group many like transactions into a single message.

Background processes that work on batches of transactions at one time utilize this approach.

In addition, other processes use this approach where interface requirements demand various groupings of like transactions based on common information within each transaction. For example, an Advanced Shipping Notice message can be published to a customer when the customer's order is shipped within the PeopleSoft Inventory system. This message may go directly to the customer or it may go through third-party software that converts the XML message to one of the industry standard EDI formats, such as X.12, before passing it on to the customer. Using the options available with the Batch Publish approach, users can dictate whether to create a single message for all customers to send to the third-party software or create individual messages to send directly to each customer.

PeopleSoft CRM applications all use the Publish Outbound Message process to initiate the Batch Publish messages. Built into this routine is the Batch Publish utility, a common PeopleSoft tool that provides the functionality to group and filter or “chunk” messages as noted in the previous example.

The Batch Publish utility also provides the option to create flat files instead of XML messages, when file layout objects exist for transactions being generated. File layout objects are easy to modify, and PeopleSoft provides examples for all transactions included in the EDI feature.

Full Data Replication

Full data replication is the process used to seed, or initially populate or repopulate, a copy of an entire table onto a remote database or legacy system. The entire contents of the table are published to all systems that require a copy of the table. Generally, full data replication occurs with setup tables—that is, relatively static, low volume tables keyed by setID.

Once a copy of the table exists, incremental updates provide a mechanism or process to keep the copy up-to-date with changes made on the master. Incremental updates occur most often with transaction tables—that is, frequently updated tables keyed by business unit.

Most full data replication message names end in _FULLSYNC.