How to FULLSYNC tables between PeopleSoft databases

This article will explain how to do a FULLSYNC of a table from one PeopleSoft database to another where there is no delivered messages or process to do so. This could be custom records or records which Oracle has not delivered syncs for. We use mostly configuration and a small piece of generic code to accomplish this.

Assumptions

First we assume the following:

• You have a working integration broker setup and working between the two PeopleSoft databases.
• You have access to setup integration broker setups and are familiar with the steps.
• You have access to install some PeopleCode provided in this article.
• The base record(s) being FULLSYNCed exists in both databases.

Publication Steps

This section will outline the steps to send a bulk FULLSYNC from the system or record (i.e. The publisher). We will be syncing a custom table called CHG_POSITION_DATA from one PeopleSoft database to another.

Create Message

First we need to setup a message object will will contain the data. This can be done at the following page:

PeopleTools > Integration Broker > Integration Setup > Messages

Note: We did not call the message just the name of the table: CHG_POSITION_DATA. We are going to rely on some generic handler code to insert this data and there is a bug that if the message name does not match the service operation name, then it will error out.

Create Service

We also had to define a new service.

PeopleTools > Integration Broker > Integration Setup > Services

Service Name: CHG_POSITION_DATA_FULLSYNC

Create Service Operation

We have to create a new service operation.

PeopleTools > Integration Broker > Integration Setup > Services Operations

Service Operation Handlers

There should be no Service Operation Handlers on the publishing database.

Service Operation Routings

You should setup one routing from your publishing node to your subscribing node. This is very specific to your installation and how you define nodes.

Batch Publish Application Engine

There is a delivered process that we can run which will dynamically look at the message object and find any parent child records/tables and gather the data for us and package it up into a service operation. This means you do NOT have to write a custom process just to sync this one record and any child records.

First we must configure our new CHG_POSITION_DATA_FULLSYNC Service Operation in the “Full Data Publish Rules” which tells the integration publication process how to process the message.

Enterprise Components > Integration Definitions > Full Data Publish Rules

Open the “CHG_POSITION_DATA_FULLSYNC” in the search record.

Now we can actually schedule the delivered application engine to run.

Enterprise Components > Integration Definitions > Initiate Process > Full Data Publish

• Create a new run control ID for this service operation.
• Do NOT re-use an existing Run Control ID. This is especially true for processes you intend to schedule on a recurrence. I typically make the Run Control ID match the Service Operation Name which is “CHG_POSITION_DATA_FULLSYNC” in this scenario.

Note: The run control actually has a scroll area where you can insert any number of service operations to publish with the run of the application engine. Here we are just setting up one service operation but you can enter any number of service operations that you want to publish on the same schedule.

Run the Application Engine: EOP_PUBLISHT (Full Table Data Publish)

The Application Engine EOP_PUBLISHT process will run and dynamically gather and publish all the data in the table in the underlying message definition of the submitted service operations. So in this example, the data in table CHG_POSITION_DATA will be read and packaged into a bunch of service operations in the integration broker depending on the size of the table and the app server configuration. At a minimum this application engine will create 2 service operations. 1 header and 1 body.

The FULLSYNC is not considered done until the publication integration broker publishes to the subscriber and the subscriber integration broker handlers complete successfully. This application engine just creates the service operation “operation instances”. The operations then have to publish and get subscribed to. The application engine does not wait around for that or even have a “window” into that integration broker activity. Therefore, the application will run to “success” and you cannot trust the data is actually published until you verify that is published in the integration broker and the subscription contracts in the subscription side completed. If you are not familiar with these steps you should read our High Level Overview of Integration Broker Publishing Steps kb article.

Subscription Steps

The subscription side as very similar setup in regards to the publishing service operation. The only difference is that we create a “handler” to run some generic code that can work for any FULLSYNC message you setup.

Messsage

• Follow the same steps as the publication above.

Service

• Follow the same steps as the publication above.

Create Service Operation

• Follow the same steps as the publication above with the following exceptions

Service Operation Handlers

There should be one active OnNotify handler on the subscribing side which invokes an application class. You will need to create a new application class. You can call the class anything you want per your company’s naming standards. For example sake, let’s call it CHG_INTEGRATION_TOOLS:genericFullSyncSubscription.

import PS_PT:Integration:INotificationHandler;
import HR_INTEGRATION:*;

class genericFullSyncSubscription implements PS_PT:Integration:INotificationHandler
   method OnNotify(&_MSG As Message);
end-class;

method OnNotify
   /+ &_MSG as Message +/
   /+ Extends/implements PS_PT:Integration:INotificationHandler.OnNotify +/

   Local HR_INTEGRATION:HR_Subscription &Subscription;
   &Subscription = create HR_INTEGRATION:HR_Subscription();
   &Subscription.SetExecuteEdits( False);
   &Subscription.HR_Full_Sync();
end-method;  

You will see that this actually just calls some delivered application classes methods that actually does all the work based on the message content. The HR_INTEGRATION application package exists in CS and HCM. If you do not have this in your database take a look at any FULLSYNC application like the COUNTRY_FULLSYNC:countryFullSync as an example and you will see that the onNotify method just calls some functions in FUNCLIB_EOEIP.SUBSCRIBE_MSG_PC FieldFormula. You can use this to create a generic OnNotify handler. (I am not sure why Oracle has not delivered one or I am just not aware of it.)

Service Operation Routings

• Follow the same steps as the publication above.

Web Service Security

Grant web service security to whatever user is going to run the publication application engine or exclude the token on the publication side.

Additional Reading

You may also be interested in this artice about Understanding the difference between SYNC and FULLSYNC integrations