Setting Up Related Languages
This section provides overviews of related language tables and related language guidelines for PeopleSoft messaging and discusses how to:
Interpret component processor behavior.
Publish a message from a component.
Publish a message from batch programs.
Subscribe to data in a PeopleSoft multilingual environment.
Subscribe to data in a non-multilingual environment.
You can use several possible scenarios to familiarize yourself with related languages 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 example, 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.
This example illustrates the fields and controls on the Related-language record definitions. You can find definitions for the fields and controls later on this page.
Consider the following points:
The parent table, DEPT_TBL, has the related-language child table, DEPT_TBL_LANG.
The child table has the same fields as the parent table, plus an additional field of LANGUAGE_CD.
The attributes of the child table are all of the translatable textual fields of the parent record.
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:
Delete the base language tables and related-language tables.
Replace these tables with data from the messages as appropriate.
Place only those related-language field values that are supported by the subscribing system into the related-language tables.
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 language code of the user ID. 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:
Subscribe_IncrReplication has related-language processing for an incremental message subscription process.
Subscribe_FullReplication has related-language processing for a batch subscribe process.
When you open a component, the component processor:
Compares the user's preferred language against the base language for the database.
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:
The component processor writes all the data for related-language fields back to the related-language table.
The component processor writes the rest of the data back to the base application table.
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.
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.
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.
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.
The subscription process sets the language for processing the message to the language needed by the subscriber system. For example, if the base language of the subscribing system 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.
When handling subscribing systems that do not support multiple languages, you can subscribe to data in these ways:
Setting message publish routing PeopleCode.
Sending service operations to all appropriate nodes.
Permitting the subscription to process itself.
Subscribing to data that is specific to an external system.
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 in its language is automatically used to update the subscribing system’s database. To implement this option:
Determine the languages in which messages are published.
Determine the message language that a subscribing node receives.
Add PeopleCode routing logic on the publish side to check the language code of the first occurrence in the message record and return a list of subscribing nodes that should receive the message for that language.
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:
Ensure that service operations in all languages are sent to all appropriate nodes.
Add the PeopleCode to compare the message language against a hard-coded language value for the subscribing system.
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: To prevent data integrity issues, generic subscription processes should not filter messages based on language code.
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 Oracle 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 that 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.