Activating Integration Points

This chapter discusses how to:

Click to jump to parent topicSetting Up PeopleSoft Integration Points

This section discusses how to:

Note. For more information and technical details about these integration points, and for information on how and with what applications to use them, consult the relevant application PeopleBook.

Click to jump to top of pageClick to jump to parent topicPages Used to Set Up PeopleSoft Integration Points

Page Name

Object Name

Navigation

Usage

Batch Publish Rules

EO_MSGPUBATCH

Enterprise Components, Integration Definitions, Batch Publish Rules

Set up publication rules.

You must activate a publication rule for the publication messages that you create to follow. This rule includes instructions on message chunking, if necessary.

Add Nodes to Chunk Rule

EO_ADNODECHUNK_PNL

Enterprise Components, Integration Definitions, Map Chunking Rules, Node to ChunkRule

Map PeopleSoft message nodes to chunking rules.

Click to jump to top of pageClick to jump to parent topicSetting Up Publication Rules

Access the Batch Publish Rules page.

If the data that you’re transmitting does not fit in a single message, or if you want to send different parts of the message to different target systems, set up the rules to chunk the message and associate it with the publish rule. The business unit and setID chunking rules are standard in PeopleSoft applications, but you can configure chunking rules.

Publish Rule ID

Select the name of the message for which you’re setting up rules.

Status

Select Active to activate this publish rule definition for this message. Select Inactive to prevent this rule from applying to this message.

Chunking Rule ID and Alternate Chunk Table

Enter the unique chunking rule name that is set up when you created the chunking rule. The message that you publish is routed based on this field. If necessary, enter an additional field in the Alternate Chunk Rule ID field by which to chunk the message.

Message Options

Many PeopleSoft systems rely on a message header and message trailer to trigger subscription PeopleCode to discard old table data and insert the new incoming data. As a general rule, all FullSync messages should use a header and trailer. Sync messages don’t need headers and trailers.

Output Format

The Application Engine program used to chunk messages can create either an XML message that flows through messaging architecture or a flat file that is generated in PeopleSoft Process Scheduler and not published elsewhere. Always select Message as the format when you send data to PeopleSoft systems.

Click to jump to top of pageClick to jump to parent topicMapping Nodes to a Chunking Rule

Access the Add Nodes to Chunk Rule page.

To map nodes to a chunk rule:

  1. In the Add column, select the check box next to the nodes that you defined earlier.

    After you select a node, use the Add button in the Add Chunk Values column to open the Quick Map page for the message you defined earlier.

  2. Click Save.

Click to jump to top of pageClick to jump to parent topicAssigning Business Units or SetIDs to a Chunking Rule

See Assigning Business Units or SetIDs to a Chunking Rule.

Click to jump to top of pageClick to jump to parent topicSpecifying OnRoute PeopleCode

Create a service operation handler to route the message chunk to the correct subscriber node.

To do so, extend the IRouter application class and use the OnRouteSend method. Then in the appropriate service operation, define a handler and specify the application class.

See Also

Enterprise PeopleTools 8.48 PeopleBook: PeopleSoft Integration Broker,“Sending and Receiving Messages,” Understanding Integration PeopleCode

Enterprise PeopleTools 8.48 PeopleBook: PeopleSoft Integration Broker,“Sending and Receiving Messages,” Messaging Handlers

Enterprise PeopleTools 8.48 PeopleBook: PeopleSoft Integration Broker, “Managing Service Operations,” Configuring Service Operation Definitions

Click to jump to parent topicSetting Up Related Languages

This section provides an overview of related language tables and related language guidelines for PeopleSoft messaging and discusses how to:

Click to jump to top of pageClick to jump to parent topicUnderstanding Related Language Tables

There are several possible scenarios that you can use to familiarize yourself when setting up related languages for a message.

A department table, for example, must publish information in German as well as English. In the following screen shot, the base application tables and related-language tables have a parent-child relationship. The related-language table has the same name as the parent table, but is suffixed with _LANG, in accordance with PeopleSoft naming conventions.

Related-language record definitions

Consider the following:

Click to jump to top of pageClick to jump to parent topicUnderstanding Related Language Guidelines for Messaging

When publishing a full message, generate messages that contain the contents of an entire table by first generating a message in the base language of the system that contains the full table contents. Then generate messages for each of the related languages that are supported by the publishing system. Each message should contain the full message structure for that message object (levels 0, 1, 2, and so on). The language-specific messages should contain the translatable field values for that language and include the base language fields that are not translatable.

When subscribing to a full message, specify the language code only at level 0 of the message. This captures and sets the user’s preferred language to level 0 of the PeopleSoft Common Application Message Attributes (PSCAMA) message header. All data within the message must be in the same language. Follow these steps:

  1. Delete the base language tables and related-language tables.

  2. Replace these tables with data from the messages as appropriate.

  3. Place only those related-language field values that are supported by the subscribing system into the related-language tables.

  4. Add the related-language table entry only if the base language table entry already exists.

When publishing an incremental message, the PeopleSoft system generates base messages in the user's preferred language by using the user ID’s language code. Putting the user’s preferred language code in the message header PSCAMA record defines the message language for the subscribing system.

When subscribing to an incremental message using PeopleSoft Component Interfaces, use a simple PeopleCode program that performs a SetLanguage (messagelanguage) call to a component interface with the message definition. This enables the subscribing system to process the data in the appropriate related or base language for that system.

When subscribing to an incremental message using PeopleCode only, the PeopleCode program must simulate what the component processor does. The PeopleSoft system provides a generic Subscribe_IncrReplication PeopleCode function that provides basic language-related ability for incremental message subscriptions.

Note. All PeopleSoft subscription processes that are associated with textual information work as if the content is related-language enabled; thus the processes provide support for customer related-language extensions and future PeopleSoft enhancements.

For PeopleSoft-to-PeopleSoft system integration, you do not need to specify the language-sensitive data on either system.

All of the PeopleCode functions that are needed for related language processing of incremental and full messages are in the FUNCLIB_EOEIP record. The record contains two functions:

Click to jump to top of pageClick to jump to parent topicInterpreting Component Processor Behavior

When you open a component, the component processor:

  1. Compares the user's preferred language against the base language for the database.

  2. Uses the record information from the base application table (DEPARTMENT_TBL).

    If a record in the base application table exists for the user's preferred language, the fields on the related-language table (DEPARTMENT_LANG) overlay the record information. For example, a German user sees German descriptions even if the base language for the database is English.

When you change the user's preferred language and save the component:

  1. The component processor writes all the data for related-language fields back to the related-language table.

  2. The component processor writes the rest of the data back to the base application table.

  3. The German user’s entries for the DESCR and DESCRSHORT fields are saved back to the DEPARTMENT_LANG table with its key values and the LANGUAGE_CD field in German.

  4. The data that was entered by the German user in the key fields, as well as MANAGER_NAME and ACCOUNTING_OWNER fields, are saved on the parent record DEPARTMENT_TBL.

Click to jump to top of pageClick to jump to parent topicPublishing a Message from a Component

The PeopleSoft system employs the user's preferred language to determine the language of a message that is published from a component. The default for LANGUAGE_CD is set to the preferred language code (OPERATOR.LANGUAGE_CD). The standard for incremental changes is to publish only the data that has changed, in the language to which it was changed. Changing the preferred language to translate data generates new messages appropriately.

Click to jump to top of pageClick to jump to parent topicPublishing a Message from Batch Programs

Application Engine and Structured Query Report incremental message programs should use the base language of the system. These programs perform their accesses and updates on the base tables only, even if related-language tables are supported for those business objects. Related-language tables are featured in batch program processing only in generating warnings or errors that use the message catalog.

When a batch application program runs, the processing is done in the base language of the system, and messages are generated in only the base language.

Click to jump to top of pageClick to jump to parent topicSubscribing to Data in a PeopleSoft Multilingual Environment

The subscription process sets the language for processing the message to the language needed by the subscriber system. For example, if the subscribing system’s base language is French, and the PeopleSoft system is sending German data, the subscription process must store the German data in a related-language table and the nontranslatable data in the French base application tables. Neither system’s base language matters; only the base language of the subscribing system and the actual message language are used.

Click to jump to top of pageClick to jump to parent topicSubscribing to Data in a Non-Multilingual Environment

When handling subscribing systems that do not support multiple languages, you can subscribe to data in these ways:

Setting Message Publish Routing PeopleCode

Set message publish routing PeopleCode to send only messages in a particular language code to a subscribing node.

The subscribing node does not need to check the language in which the message was generated; any message that it receives is in its language is automatically used to update the subscribing system’s database. To implement this option:

The publish routing PeopleCode guarantees that the message is sent to the correct subscribing nodes by using the message language code.

Sending Service Operations to All Appropriate Nodes

Send service operations to all appropriate nodes regardless of the language and have the subscription routing PeopleCode filter out messages in different languages.

PeopleCode on the subscription routing checks the language code of the first occurrence in the message and controls whether the node should receive the message. To implement this option:

The advantage of putting the logic within the subscription routing PeopleCode is that every message is checked for a language value match.

Permitting the Subscription to Process Itself

You can permit the subscription process itself, rather than the routing PeopleCode for the service operation and queue, to determine whether the message should be processed for the subscribing system.

The subscription process checks the language code of the PSCAMA record for the first instance of the message against a hard-coded value for the subscribing system. If the language code does not match, the message is ignored. If the message language code does match, it’s considered a base language message, and it replaces all data on the subscribing system according to the audit action flags on the message records.

Note. Generic subscription processes should not filter messages based on language code, to avoid data integrity issues.

Subscribing to Data That Is Specific to an External System

Subscribe to data that is specific to an external system for language code, business unit, or setID requirements that are specific to an external system.

Use the chunking rule and the routing control tables that PeopleSoft supplies to select a portion of the data and send it to a specific node.

Use the PeopleSoft-supplied Publish Header (PublishHdr) component to enter the partitioning views and fields for a message. This chunks the message so that all contents within a single message contain the same partitioning value (such as business unit, setID, or application-specific fields).

Set up the routing control for the message so the message is sent only to the appropriate nodes. The PeopleSoft system supplies a business unit routing control (BU Routing Control) component and a setID routing control component that enable applications to specify for each message which nodes should receive the partitioned message data.

After you set up the chunking rule and routing rules, both the full data publish and batch publish programs partition the data according to the appropriate value and route it accordingly. You can now publish and subscribe to the message.

Click to jump to parent topicExamining Related-Language Messaging Scenarios

Actual related-language messaging scenarios include publishing a non-base language message and switching a preferred language.

This section discusses how to:

Click to jump to top of pageClick to jump to parent topicPublishing a Non-Base Language Message to a Subscribing System With a Different Base Language and No Prior Data

In the following example, the publishing system base language is English, the subscriber base language is Japanese, and the user’s preferred language is German.

To publish a non-base language message:

  1. An online user adds a new level 0 key on a page.

    The data is stored in both the base language table (English) and the related-language table (German).

  2. The system publishes a message in the user’s preferred language (German).

  3. The data is inserted into the subscribing system.

    The data is inserted into both the base language table and related-language table (German) because it is added for the first time; data cannot reside in a related-language table without corresponding data in the base table.

Click to jump to top of pageClick to jump to parent topicSwitching the Preferred Language to Japanese and Updating the Same Employee's Name and Address

To switch a preferred language:

  1. A user switches the preferred language from English to Japanese.

    The user updates the same record as in the previous scenario. Data that is not language-sensitive is updated in the base table (English). Language-sensitive data is inserted into the related-language table (Japanese).

  2. A system publishes a message in the user’s preferred language (Japanese).

  3. Data is inserted into the subscribing system.

All data goes to the base table (Japanese), because the message was sent in the same language as the subscribing system’s base language.