Using the Publish Utility

This chapter provides overviews of the Publish utility and publishing rules and discusses how to:

• Use sequential and parallel processing.

• Assign full table publishing rules.

• Assign batch publishing rules.

• Perform pre-processing and post-processing tasks.

• Set up message chunking.

• Create custom chunking tables.

Important! Using pre-processing and post-processing in conjunction with the parallel processing feature of the Publish Utility is currently available in the HCM application only. To use pre- and post-processing in conjunction with parallel processing you must apply one of the following resolutions to both the publishing and subscribing systems: HCM 9.0 systems – Resolution 827074; HCM 9.1 systems – Resolution 827350.

Understanding the Publish Utility

The Publish utility automates the process of copying the contents of an entire table into a remote database or legacy system.

Use the utility to synchronize data from an existing system when a new PeopleSoft system is installed.

The Publish utility is built upon the PeopleSoft Integration Broker services-oriented architecture and publishes service operations to target systems. The service operations published contain messages that store the table data.

Use the Publish utility to perform full table publish or batch publish processing. These process are defined as:

To use the utility you use the PeopleSoft Pure Internet Architecture to create publishing rules and then assign them to service operation messages to control how the utility manages the messages it is publishing.

Understanding Publishing Rules

You control the size and number of, and the frequency at which data full table or batch data is published by creating and using a series of data publishing rules.

The PeopleSoft Pure Internet Architecture component that you use to create publishing rules depends on the type of processing that you want to perform. For full table publish processing, use the Full Table Publish Rules component (EOIU_SOPUBFULL) to create publishing rules; for batch publish processes, use the Batch Process Rules component (EO_MSGPUBBATCH).

The pages in the Full Table Publish Rules and Batch Process Rules components are very similar. You use these components to specify:

• Pre-processing and post-processing tasks.

• The source of the data.

• Whether to chunk the message.

• Record mapping.

• Output format.

• Related languages in which to publish the data. (Full table publishing rules only)

Pre-Processing and Post-Processing

Often, performing pre-processing and post-processing tasks on the subscribing system before or after it processes a service operation message is desirable. Pre-processing tasks can include actions such as deleting existing data. Post-processing actions can include data clean-up.

Performing pre-processing and post-processing tasks is optional. However, if you choose to perform them, you must enable the Message Header or Message Trailer options on the Full Table Publish Rules or Batch Publish Rules page, as well as code the processing logic on the service operation handler.

You can perform pre-processing and post-processing tasks on service operations that are processed sequentially or in parallel.

Note. Using pre-processing and post-processing tasks in conjunction with the parallel processing feature of the Publish Utility is currently available in the HCM application only. To use pre- and post-processing tasks in conjunction with parallel processing you must apply one of the following resolutions to both the publishing and subscribing systems: HCM 9.0 systems – Resolution 827074; HCM 9.1 systems – Resolution 827350.

Using pre-processing and post-processing logic is discussed in greater detail elsewhere in this chapter.

See Performing Pre-Processing and Post-Processing Tasks.

Data Sources

The data to publish using the Publish utility can be from the following sources:

• A staging table.

• A temporary table.

• A view.

Message Chunking

This section discusses message chunking as it pertains to specifying chunking options in publishing rules. Setting up message chunking is discussed elsewhere in this chapter.

See Setting Up Message Chunking.

Chunking

Chunking refers to the automatic breaking of a message into several smaller messages based on values in fields in the level zero record.

You can perform chunking based on setID, business unit, or record group.

Chunking on business unit means that all transactions within the message are for the same business unit value.

The system chunks message data based on the MaxMessageSize parameter.

The MaxMessageSize (maximum message size) field in the PeopleSoft Option (PSOPTIONS) table limits the size of the message. Before processing each level zero record, the Full Table Publish utility compares the size of the message against the value in the MaxMessageSize field. When the message size exceeds the value in the MaxMessageSize field, the service operation publishes, and a new service operation starts.

You can also specify message chunking in the publish rules for the service operation, which enables the message to publish when the value of a chunk field changes.

Chunking Field

Chunking fields are key fields in the level zero record that are used to break the message into parts.

Chunking Table

A chunking table is a derived or Structured Query Language (SQL) table that contains the fields by which the message is chunked. SQL chunk tables define the valid values of the chunking fields and the nodes to which the message is published.

Oracle provides three standard chunking tables: EO_BUSUNIT_EOC for business unit values, EO_SETID_EOC for setID values and EO_RECGRP_EOC for record groups values. Oracle provides chunking tables for business unit, setID and record group that are maintained by a series of components (such as components that are created for maintaining the business unit chunking table).

Alternate Chunking Table

An alternate chunking table is a secondary chunk table. It provides a separate view of an existing chunk table, but with one or more field names customized. It enables you to reuse an existing chunk table. For example, if the record EO_BUSUNT_EOC has BUSINESS_UNIT as the chunking field, you can create a view of this table that has BUSINESS_UNIT_IN as the chunking field.

When the field being chunked doesn't use the normal field names for business unit and setID, the alternate chunk table enables you to use the existing chunk tables and maintenance pages for business unit and setID. The alternate chunk table enables the user to use the existing chunk tables and maintenance pages for business unit and setID when the field being chunked doesn't use the normal field names for business unit and setID, for example, BUSINESS_UNIT_IN. Use the _EOV suffix for alternate chunk tables.

Chunking Rule

A chunking rule points to the chunking table. Multiple chunking rules can point to the same chunking table.

Record Mapping

You should use the record mapping feature in a publish rule because:

• The published data comes from staging tables or temporary tables.

  Using staging tables is the only way to publish rows that have been deleted from application master tables.

• The published data needs an order sequence that differs from that of the records in the message.

• You must create a view that selects only current effective-dated rows in situations in which the application table is effective-dated and the subscribing database cannot process future-dated transactions.

Output Format

You can choose the output of the Full Table Publish utility to be in the following formats:

• Message (default value).

• Flat file.

• Flat file with control record.

You can create multiple publish rules with different output formats for the same service operation.

Flat File Output

You select the flat file option when you set up publish rule definitions for the service operation. If a file layout object exists with the same name as the message object, you can modify the output format field on the Publish Rule Definition page.

If you select flat file output, the header and trailer messages aren’t created, and a single output flat file is created even if you already specified the chunking rule.

The file layout definition must have a record structure identical to that of the message; if the AUDIT_ACTN field does not exist in the record, you must add it to the file layout record definition.

The option becomes modifiable if a file layout object exists with the same name as the message definition.

The directory location of the flat file is determined by the value in the OUTPUT parameter in PeopleSoft Configuration Manager.

The flat file name is messageName_SequenceNumber.out, where messageName is the message name and SequenceNumber is the next available sequential number for files with that message name.

Publishing Data in Related Languages

The Publish utility provides the option to publish data in related languages.

If you choose to use the related language feature, the system creates the following related language messages:

• One message in the base language of the publishing system.

• One message for each language in the related language tables for the base tables.

The subscribing system receives the messages in the order in which they are published. For example, if the base language is English, with French and then German as related language tables, the Publish utility creates the messages in this order:

1. (Optional) Header message.

2. English message 1.

3. French message 1.

4. German message 1.

5. English message 2.

6. French message 2.

7. German message 2.

8. (Optional) Trailer message.

Prerequisites for Using the Publish Utility

The Publish Utility uses the PeopleSoft Integration Broker services-oriented architecture and to publish service operations to target systems. As such, to use the utility you must have:

• An understanding of PeopleSoft Integration Broker.

• PeopleSoft Integration Broker configured for your integration requirements.

• Service operations, including messages, handler, and routing definitions, setup on sending and receiving systems.

• Using pre-processing and post-processing tasks in conjunction with the parallel processing feature of the Publish Utility is currently available in the HCM application only. You must apply one of the following resolutions to both publishing and subscribing systems:

  • HCM 9.0 systems: Resolution 827074.

  • HCM 9.1 systems: Resolution 827350.

Common Elements Used in This Chapter

Using Sequential and Parallel Processing

This section discusses how to:

• Use sequential processing.

• Use parallel processing.

• Changing processing modes.

Understanding Using Sequential and Parallel Processing

Subscribing systems can process service operations sequentially or in parallel.

In sequential processing, the subscribing system processes messages defined in inbound service operations in the order received.

In parallel processing, the subscribing system processes messages defined in service operations in parallel, in no specific sequence.

You can use sequential or parallel processing when using either full table publishing or batch publishing.

You configure sequential or parallel processing at the queue level on the subscribing system.

Prerequisites for Using Parallel Processing

Note the following prerequisites for using pre-processing and post-processing tasks in conjunction with the parallel processing feature of the utility:

• The pre-processing and post-processing task functionality of the parallel processing feature of the Publish Utility is currently available in the HCM application only.

• To use pre-processing and post-processing tasks in conjunction with parallel processing you must apply the following resolutions to both the publishing and subscribing systems:

  • HCM 9.0 systems: Resolution 827074.

  • HCM 9.1 systems: Resolution 827350.

Using Sequential Processing

To implement sequential processing, on the subscribing system associate the message on the inbound service operation with an ordered queue.

See PeopleTools: PeopleSoft Integration Broker PeopleBook, “Managing Service Operations,” Defining Service Operation Version Information, “Specifying Messages for Service Operations”

Using Parallel Processing

To implement parallel processing, on the subscribing system associate the message on the inbound service operation with an unordered queue. If the message is currently assigned to an ordered queue, assign it to a unordered queue.

In order to realize any performance gain from parallel processing, multiple subscription handlers must be set up for the subscription node to process messages on the unordered queue.

Only Messages that utilize functions inside the PeopleCode function library FUNCLIB_EOEIP for their pre-processing, post-processing and subscription handler logic will have the order of processing logic enforced when using the parallel processing mode.

See PeopleTools: PeopleSoft Integration Broker PeopleBook, “Managing Service Operations,” Defining Service Operation Version Information, “Specifying Messages for Service Operations”

See PeopleTools: PeopleSoft Integration Broker PeopleBook, “Managing Service Operation Queues,” Adding Queue Definitions

Changing Processing Modes

If your business requirements change, you can change the processing mode from sequential processing to parallel processing or vice versa, by moving the message associated with the service operation to the appropriate queue type.

If you have coded pre-processing or post-processing tasks, you must move the code for those tasks in the service operation message. More information is provided elsewhere in this chapter.

See Coding Pre-Processing and Post-Processing Tasks.

Assigning Full Table Publishing Rules

All PeopleSoft applications use common, centralized tables and pages to define how to publish full table messages. The Publish utility uses publishing rules to process the data.

This section discusses how to:

• Associate full table publishing rules with messages.

• Map a full table message record to another record.

• Specify languages in which to publish messages.

Note. You can create multiple publish rules for the same message. The Full Table Publish utility treats each publish rule as a separate publishing cycle.

Pages Used to Assign Full Table Publishing Rules

Associating Full Table Publishing Rules with Messages

Access the Full Table Publish Rules page (Enterprise Components, Integration Definitions, Full Data Publish Rules).

Use this page to associate a rule to a message and characterize the rule.

Mapping Full Table Message Records to Other Records

Access the Record Mapping page (Enterprise Components, Integration Definitions, Full Data Publish Rules, Record Mapping).

Use this page to map a message record to another record.

Regardless of which source table you use (staging table, temporary table, or a view), ensure that the source table field names are identical to the field names in the target message record. Key fields must also adhere to the parent and child relationship. (Keys of a parent record must exist in the child record, in the same sequence.) The Publish utility uses the Source/Order By Record Name field to select rows for publishing. You use key matching to find all child rows of a parent.

The chunk field should be the primary key field in all Source/Order By records. If the chunk field is not a key field of the level zero record, join the chunk field to all records in which the chunk field does not exist by using views in PeopleSoft Application Designer.

Enter only those message records with a different source or ordering record. If the message record name and the source or ordering record name are identical, do not insert a row for that record on the Record Mapping page.

Specifying Languages in Which to Publish Messages

Access the Languages page (Enterprise Components, Integration Definitions, Full Data Publish Rules, Languages).

Use this page to specify languages in which to publish a message.

Assigning Batch Publishing Rules

All applications can use common, centralized tables and pages to define how to publish incremental messages from an application program. The Publish utility uses batch publish rules to process the data from the application program.

This section discusses how to:

• Associate a rule with a message and characterize the rule.

• Map a batch publishing message record to another record.

• Assign an application program to a publishing rule.

Note. You can link application programs to multiple publishing rules for the same message or different messages. The Publish utility treats each publishing rule as a separate publishing cycle.

Pages Used to Assign Batch Publishing Rules

Associating Batch Publishing Rules with Messages

Access the Batch Publish Rules page (Enterprise Components, Integration Definitions, Batch Publish Rules).

Use this page to associate a rule to a message and characterize the rule.

The page elements and controls that you use on the Batch Publish Rules page are described elsewhere in this chapter.

See Common Elements Used in This Chapter.

Mapping Batch Publishing Message Records to Other Records

Access the Record Mapping page (Enterprise Components, Integration Definitions, Batch Publish Rules, Record Mapping).

Use this page to map a message record to another record.

Note. When running a batch publish rule, the Publish utility runs cleanup logic, which either updates fields or deletes rows in the source tables. If the source table is a view that contains a join, then the option to delete published rows fails.

This page specifies the source data for a record in a message. It works in the same manner and accomplishes the same purpose as the Record Mapping page for a full table publish.

Assigning Application Programs to Batch Publishing Rules

Access the Batch Programs page (Enterprise Components, Integration Definitions, Batch Publish Rules, Batch Programs).

Use this page to assign an application program (PROCESS_NAME) to the publish rule.

Performing Pre-Processing and Post-Processing Tasks

This section discusses how to:

• Set general pre-processing and post-processing options.

• Code pre-processing and post-processing tasks.

Setting General Pre-Processing and Post-Processing Options

To perform pre-processing and post-processing tasks, you must select the appropriate Message Header or Message Trailer option on the Full Table Publish Rules page or on the Batch Publish Rules page.

To set general pre-processing and post-processing options:

1. Access the Full Table Publish Rules page or the Batch Publish Rules page.

   • To access the Full Table Publish Rules pages, select Enterprise Components, Integration Definitions, Full Table Publish Rules.

   • To access the Batch Publish Rules pages, select Enterprise Components, Integration Definitions, Batch Publish Rules.

2. In the Message Options section, select the appropriate options:

   Message Header	Select this option to perform pre-processing tasks on a service operation message.
   Message Trailer	Select this option to perform post-processing tasks on a service operation message.

3. Click the Save button.

Coding Pre-Processing and Post-Processing Tasks

The type of processing that you are performing determines the location in the message where you insert the pre-processing and post-processing logic.

Using PeopleSoft-Delivered Functions for Pre-Processing and Post-Processing

Consider using the following PeopleSoft-delivered functions in pre-processing logic:

Coding Pre-Processing and Post-Processing Tasks

The type of processing that you are performing, sequential or parallel, determines the location in the message where you insert pre-processing and post-processing logic.

The following code example shows sample pre-processing and post-processing code. Section numbers have been entered as remarks to show the location to insert code based on the processing that you are performing.

Important! If you change processing modes from sequential processing to parallel processing or vice versa, you must move any pre-processing and post-processing code to the appropriate section in the message, as described in the table.

If &ParallelFS Then
   ...
      If &Pre_Process_Flg = "Y" Then

         rem ****** Begin Pre-Processing Logic for parallel-enabled FullSync *****;
         Delete_Existing_Data(&MSG);

				 /************************************************************************/
         /*                                                                      */
         /*                            Section 1                                 */
         /*                                                                      */
         /************************************************************************/

         rem ****** End Pre-Processing Logic for parallel-enabled FullSync ******;

      End-If;
   ...

End-If;

&MSG_ROWSET = &MSG.GetRowset();
&MSG_LANG_CD = &MSG_ROWSET(1).PSCAMA.LANGUAGE_CD.Value;
&MSG_BASE_LANG_CD = &MSG_ROWSET(1).PSCAMA.BASE_LANGUAGE_CD.Value;
&FULL_INCR = "FULL";

Evaluate &MSG_ROWSET(1).PSCAMA.MSG_SEQ_FLG.Value
When "H"
   If Not &ParallelFS Then

   rem ****** Begin Pre-Processing Logic for nonparallel-enabled FullSync ******;
   Delete_Existing_Data(&MSG);


		 /*************************************************************************/
    /*                                                                       */
    /*                                Section 2                              */
    /*                                                                       */
    /*************************************************************************/

   rem ****** End Pre-Processing Logic for nonparallel-enabled FullSync ******;

   End-If;
   Break;
When "T"
   If Not &ParallelFS Then 


    /*************************************************************************/
    /*                                                                       */
    /*                                Section 3                              */
    /*                                                                       */
    /*************************************************************************/


   rem ** Insert Post-Processing Logic Here for nonparallel-enabled FullSync **;

   End-If;
   Break;
When-Other
   Proc_Sub_Rowset(&MSG_ROWSET);
   rem ****** put additional process like editing here ********;

If &ParallelFS Then
    ...

   If &Post_Process_Flg = "Y" Then


    /*************************************************************************/
    /*                                                                       */
    /*                                Section 4                              */
    /*                                                                       */
    /*************************************************************************/


   rem *** Insert Post-Processing Logic Here for parallel-enabled FullSync ***;

   End-If;
   ...
   Break;

End-Evaluate;

Setting Up Message Chunking

This section provides an overview of message chunking and discusses how to:

• Identify when to use chunking.

• Select chunking fields.

• Create chunking rules.

• Define the chunking rule description.

• Maintain chunking data for business units.

• Maintain chunking data for setIDs.

• Maintain chunking data for record groups.

• Add nodes to existing chunking rules.

• Assign business units or setIDs to a chunking rule.

• Assign chunking rules to a business unit.

• Assign chunking rules to a setID.

Understanding Message Chunking

If you publish to multiple nodes, you might want the messages to be routed based on a specific field. Chunking rules direct the message. You can use the same chunking fields for breaking a large message into smaller messages, as well as for associating messages with a node (based on those same fields). You set up this kind of relationship between nodes and the fields used to break the message apart (break fields) by using chunking message pages.

You can, depending on some XML content-based logic, use message chunking to route and deliver groups of transactions to different third-party nodes.

For example, consider purchase orders. If you run the full batch publish, each third-party node receives an XML message containing all purchase orders that are dispatched, regardless of whether any purchase orders are intended for that particular customer. With chunking, however, you can set up a chunking rule to chunk a message by customer ID. This creates an XML message for each customer that contains only purchase orders intended for that particular customer.

Note. Do not confuse message chunking with queue partitioning. You use queue partitioning to partition a queue by a level zero key field. If a field exists on level zero of the record in the message by which you can uniquely distinguish and group transactions to be processed in parallel, partitioning the message by this field increases performance. Without partitioning, a PeopleSoft subscribing system must process each incoming service operation and its associated message in the order in which the service operation is received according to the Publication ID (PUBID) field.

Pages Used to Set Up Message Chunking

Identifying When to Use Chunking

Use chunking when:

• The message data is large, and the subscriber is consistently interested only in part of the data.

• Subscribers can more efficiently process the message data by chunking messages.

• You have trading-partner-specific content and legally do not want data to be shared among vendors.

You can chunk messages by:

• Locations and inventory shipments by business unit.

• Customers by setID.

• Employees by department or company.

• Sales order acknowledgements by setID and customer ID.

• Purchase orders and purchase order changes by setID and vendor ID.

Selecting Chunking Fields

To maximize performance and prevent application developers from maintaining complicated views of the data, create staging or temporary tables that contain the chunking fields as the highest order key fields.

Chunking fields can affect performance and alter the options that are available to the Publish utility. The Publish utility creates SQL for each table that is defined in the message object. Tables that are defined in the message can be mapped to an alternative source table or viewed on the Record Mapping page under the Publish Rule Definition page.

The source table (or view) serves two purposes:

• It enables the data that must be published to come from a source other than the table that is defined in the message.

• It enables the data to be ordered so that the Publish utility can process rows in the correct sequence.

Because the SQL is run only once and includes a subquery against the values in the chunking table, you must define all chunking fields in every table that is used to retrieve data for the message. The SQL order-by clause is set according to the key fields that are defined in the table. The result is that chunking fields must be defined as key fields for the Publish utility to work.

Example of Generated SQL for Chunking

This is an example of SQL that is generated for chunking:

Select * from PS_INV_ITEMS A
where EXISTS (Select 'Y' from PS_EO_SETID_EOC B 
where B.CHUNK_RULE_ID = 'SETID' 
and B.EFFDT = '20000201' 
and A.SETID = B.SETID) 
order by A.SETID, INV_ITEM_ID, EFFDT

The field that you select to chunk on determines the view table that you must create:

Example

The following sample SQL code creates a view table that joins the PS_OMEC_CP_OPT_DET source table to an existing PS_OMEC_HDR_OUT table that contains the chunking fields. The B.SETID_CUSTOMER and the B.CUST_ID chunking fields are the highest order key fields from the joined table (PS_OMEC_HDR_OUT), followed by the rest of the key fields from the source table (PS_OMEC_CP_OPT_DET).

SELECT B.SETID_CUSTOMER 
, B.CUST_ID 
, A.BUSINESS_UNIT 
, A.ORDER_NO 
, A.ORDER_INT_LINE_NO 
, A.CP_MODE 
, A.CP_COMP_SEQ 
, A.OPTION_NAME 
, A.OPTION_VALUE 
, A.OPTION_DESC 
, A.VAR_TYPE 
, A.VAR_LENGTH 
, A.VAR_DECIMAL 
, A.PROCESS_INSTANCE 
, A.AUDIT_ACTN 
, A.IN_PROCESS_FLG 
FROM PS_OMEC_CP_OPT_DET A 
, PS_OMEC_HDR_OUT B 
WHERE A.BUSINESS_UNIT = B.BUSINESS_UNIT 
AND A.ORDER_NO = B.ORDER_NO

Creating Chunking Rules

The chunking rule consists of four tables:

Note. All user-defined chunking table names must end in _EOC.

Oracle provides three standard tables: EO_BUSUNIT_EOC for business unit values, EO_SETID_EOC for setID values, and EO_RECGRP_EOC for record group values. The different types of user-defined chunking tables are:

Defining the Chunking Rule Description

Access the Chunking Rule page (Enterprise Components, Integration Definitions, Map Chunking Rules, Define Chunking Rules).

Use this page to define a chunking rule description.

Chunk fields are the chunking fields that are defined in the Chunk Table field.

The chunking fields appear in this scroll area to verify that the correct chunking table was entered. Oracle provides chunking rules for business unit and setID for all application databases. Adding a new chunking rule inserts a row into the EO_CHUNKEFFDT table, with a default effective date (EFFDT) of the current date.

Maintaining Chunking Data for Business Units

Access the BusUnit Mapping page (Enterprise Components, Integration Definitions, Map Chunking Rules, Business Units).

Use this page to maintain chunking data for business units.

All four levels of the chunking rule tables appear.

Oracle provides chunking tables for business unit, setID and record group that are maintained by a series of components (such as components that are created for maintaining the business unit chunking table).

You can use each component to update the underlying relationship between the business unit and the subscribing nodes. You can maintain the data either by business unit or by node, individually or as a group, to reduce the amount of entry work.

Maintaining Chunking Data for SetIDs

Access the SetId Mapping page (Enterprise Components, Integration Definitions, Map Chunking Rules, SetIds).

Use this page to maintain chunking data for setIDs.

All four levels of the chunking rule tables appear.

Oracle provides chunking tables for business unit, setID and record group that are maintained by a series of components (such as components that are created for maintaining the business unit chunking table).

You can use each component to update the underlying relationship between the business unit and the subscribing nodes. You can maintain the data either by business unit or by node, individually or in a group, to reduce the amount of entry work.

Maintaining Chunking Data for Record Groups

Access the Eo Recgrp page (Enterprise Components, Integration Definitions, Map Chunking Rules, Record Group).

Use this page to maintain chunking data for record groups.

All four levels of the chunking rule tables appear.

Oracle provides chunking tables for business unit, setID and record group that are maintained by a series of components (such as components that are created for maintaining the business unit chunking table).

You can use each component to update the underlying relationship between the business unit and the subscribing nodes. You can maintain the data either by business unit or by node, individually or in a group, to reduce the amount of entry work.

Adding Nodes to Existing Chunking Rules

Access the Add Nodes to Chunk Rule page (Enterprise Components, Integration Definitions, Map Chunking Rules, Node to ChunkRule).

Use this page to add nodes to existing chunking rules.

To add nodes to an existing chunking rule:

1. Select the check box in the Add column of the nodes that you defined earlier.

2. Click the Save button to display the Add Chunk Values column.

   When you select a node and then click Save, the ADD button in the Add Chunk Values column appears.

3. Click the Add button in the Add Chunk Values column for the nodes that you want to add.

   The Quick Map page appears.

Assigning Business Units or SetIDs to a Chunking Rule

Access the Quick Map page (Click the Add button on the Add Notes to Chunk Rule page. This button is available after you add nodes to the chunking rule).

Use this page to a Assign business units to a chunking rule.

If you previously accessed business unit chunking rules, you can add business units to a chunking rule. If you previously accessed setIDs, you can add setIDs to a chunking rule.

Note. You cannot access the Quick Map page without first using either the BusUnit Mapping page or the SetId Mapping page to add an effective-dated node to the chunking rule ID.

Assigning Chunking Rules to a Business Unit

Access the Map Business Unit page (Enterprise Components, Integration Definitions, Map Chunking Rules, ChunkRule/Node).

Use this page to assign chunking rules to a business unit.

Assigning Chunking Rules to a SetID

Access the Map Set IDs page (Enterprise Components, Integration Definitions, Map Chunking Rules, ChunkRule/Node).

Use this page to assign chunking rules to a setID.

Creating Custom Chunking Tables

This section discusses how to:

• Create a custom chunking table.

• Create a view for the component search record.

• Create maintenance pages.

• Create a component.

• Create routing PeopleCode.

Creating a Custom Chunking Table

To create a custom chunking table:

1. Select File, Open in PeopleSoft Application Designer.

2. Select Record in the Definition drop-down menu.

3. Open the EO_BUSUNT_EOC record.

4. Save the record as YOUR_TABLE_EOC.

5. Remove the BUSINESS_UNIT field.

6. Insert the custom chunking fields at the bottom of the record.

7. Select File, Save.

8. Build the SQL table.

Creating a View for the Component Search Record

To create a view for the component search record:

1. Select File, Open in PeopleSoft Application Designer.

2. Select Record in the Definition drop-down menu.

3. Open the EO_CHUNKBU_VW record.

4. Save the record as YOUR_TABLE_VW.

5. Select the Record Type tab.

6. Open the SQL editor.

7. Modify the Where clause.

   Change WHERE RECNAME_CHUNK=EO_BUSUNT_EOC to WHERE RECNAME_CHUNK=YOUR_TABLE_EOC.

8. Select File, Save.

9. Build the SQL view.

Creating Maintenance Pages

You can also create maintenance pages.

To create maintenance pages:

1. Select File, Open in PeopleSoft Application Designer.

2. Select Page in the Definition drop-down menu.

3. Open the EO_CHUNKBU page.

4. Save the page as YOUR_PAGE.

5. Select the Order tab.

6. In the Type column, double-click Grid to open the Grid Properties dialog box.

7. Change the value in the Main Record and Page Field Name fields to YOUR_TABLE_EOC.

8. Click OK.

9. Delete the business unit and description columns.

10. Add chunking fields from YOUR_TABLE_EOC.

11. Select File, Save.

Creating a Component

To create a component:

1. Select File, New in PeopleSoft Application Designer.

2. Select Component in the New Definition box.

3. Select Insert, Page Into Component.

4. Enter YOUR_PAGE.

5. Click Close.

6. Select File, Definition Properties

7. Select the Use tab to edit component properties:

   1. In the Search record field, enter YOUR_TABLE_VW.

   2. Select the Update/Display, Update/Display All, and Correction check boxes.

8. Click OK.

9. Select File, Save As, and save the page group as YOUR_COMPONENT.

10. Add YOUR_PAGE_GROUP to YOUR_MENU that is used by your application.

Creating Routing PeopleCode

OnRouteSend (and OnRouteReceive) are PeopleCode methods that are tied to the message for routing, based on the message contents. If you want the contents of the message (such as a message chunking field value) to determine the subscribing nodes that should receive the message, OnRouteReceive PeopleCode must contain the logic to examine the message and return a list of subscribing nodes.

The OnRouteSend and OnRouteReceive methods are contained in the IRouter application class. The IRouter application class is located in PeopleSoft Application Designer in the Integration subpackage of the PS_PT application package.

PeopleCode functions provided by common components, GetNodes and RtnNodes, work with any message and chunking rule. For a given message, these nodes select the chunking rule for the publish rule that is assigned to the message.

The functions:

• Build SQL based on the chunking fields as defined in the chunking table.

• Extract chunking field values from the message.

• Run the associated SQL.

• Compare the array of nodes returned to the application server against the list of nodes for the message channel.

• Create a publish contract for nodes in both arrays.

  You can override the publish rule from the message, specifying an optional parameter when calling the functions.

• Return an array of nodes that is based on the nodes that are assigned to the message channel if the publish rule is invalid or does not contain a chunking rule.

  Returning an array of nodes enables the functions to work regardless of whether chunking is set up for the publish rule.

To route any message that uses chunking, use generic PeopleCode functions.

These functions are called from routing PeopleCode:

These functions are internal functions:

The following code example shows the logic that you can add to SavePostChange PeopleCode for the Customer_General component to verify that the setID can publish the message by calling the HasNodes() function:

Declare Function HasNodes PeopleCode FUNCLIB_EOEIP.PUBLISH_ROUTE_PC 
FieldFormula;
Local Message &MSG;
Local Rowset &RS0;
Local string &PublishRule;
&MSG = CreateMessage(MESSAGE.CUSTOMER_MSG);
/* Check if message is active */
If &MSG.IsActive Then
     &RS0 = GetLevel0();
     &PublishRule = "CUSTOMER_SYNC";
     /* Call function passing publish rule and rowset, which returns 
     true if this setID can publish the message */
     If (HasNodes(&PublishRule, &RSO)) Then
          &RS0 = GetLevel0();
          &MSG.CopyRowsetDelta(&RS0);
          &MSG.Publish();
     End-If;
End-If;

The following code example shows the logic that you can add to service operation APC handler PeopleCode to chunk the message by nodes as defined in the chunking rules by calling the RtnMsgNodes function:

import PS_PT:Integration:IRouter;

class ChunkSetidByNode implements PS_PT:Integration:IRouter
   method RoutingHandler();
   property array of any destinationNodes;
   method OnRouteSend(&_MSG As Message) Returns integer;
   method OnError(&_MSG As Message);
end-class;

Declare Function RtnMsgNodes PeopleCode FUNCLIB_EOEIP.PUBLISH_ROUTE_PC 
FieldFormula;

/* constructor */
method RoutingHandler
end-method;

method OnRouteSend
   /+ &_MSG as Message +/
   /+ Returns Integer +/
   /+ Extends/implements PS_PT:Integration:IRouter.OnRouteSend +/
   /* Variable Declaration */
   Local string &PublishRule;
   
   %This.destinationNodes = RtnMsgNodes(&PublishRule, &_MSG);
   
   If %This.destinationNodes.Len > 0 Then
      Return (%IntBroker_ROUTE_SOME);
   Else
      Return (%IntBroker_ROUTE_ALL);
   End-If;
   
end-method;

/** If an error occurs the OnError method if implemented will be automatically⇒
 invoked. The type of exception can be viewed by using the Message object to⇒
 retrieve the Exception object (&Message.IBException)
  * @param   MSG Message object containing the operation instance where⇒
 the error occured while being routed
  */
method OnError
   /+ &_MSG as Message +/
   /+ Extends/implements PS_PT:Integration:IRouter.OnError +/
end-method;