Understanding the Effective Date Publish Utility

The Effective Date Publish utility enables you to design processes to update external systems that process only current data and don't use or recognize effective dating.

When working with effective dating and effective date publishing, you need to understand the following terms:

Field or Control


Current Row

The current row is the first row of data with an effective date equal to or prior to the system date. Only one row can be the current row.

Future Rows

Future rows have effective dates later than the system date (usually the current date).

Historical Rows

Historical rows have effective dates prior to the current row.

Effective Date

An effective date is when a table row becomes effective, or the date that an action begins. The PeopleSoft system supports the concept of effective-dated rows.

Note: The EFFDT field is almost always a key. Specify the descending key attribute to display the row with the most recent effective date first.

Effective Dating

Automated effective dating saves changed data in a staging table for subsequent processing when the effective date becomes current. (Although data can be historical, current, or future, some third-party applications may support only current data. Thus, if a future-dated row is created within the PeopleSoft system, it must be delayed before transmission to the other system.)

Effective Sequence

An effective sequence serves two purposes:

  • If EFFSEQ is a required field, it enables the entry of more than one row with the same effective date when paired with EFFDT. The system assigns a unique sequence number to each row that has the same effective date. It also enables the first EFFSEQ to be zero.

  • If EFFSEQ is not a required field, it is not paired with EFFDT, has no special function, and can be used as a simple sequencing field.

Effective Status

Effective status enables the system to select the appropriate effective-dated rows, when combined with the effective date field.

Full Data Publish

The full data publish process seeds, or initially populates or repopulates, 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 (relatively static, low-volume tables that are keyed by setID) and occurs in an asynchronous manner.

When a full copy of the table exists on the external system, an incremental update provides a mechanism to keep the copy up-to-date with changes made on the master.

Incremental Publish

The incremental publish process sends a message that contains only the rows where the data has been modified, plus the corresponding anchoring parent and grandparent rows. When a particular transactional event occurs, an incremental update of the transaction data is sent to other systems to notify them of the changes.


Each node represents a publishing or subscribing system of a service operation. For example, the PeopleSoft Human Resources and PeopleSoft Financials databases are each defined as a node, even if they are both on the same server.

Service Operation Queues

Service operation queues group messages and the nodes to which they are published, so that messages are published sequentially. Each message must belong to only one queue. Queues control the ordering of messages and define timeout parameters and error thresholds. Assign nodes to a queue when you define the message in the service operation.

Message Chunking

Chunking automatically breaks a message into several smaller messages based on the values in one or more of the fields in the level zero record. When publishing the entire contents of a table, you can use message chunking to publish only certain sets of data if, for example, a particular subscriber is interested in only a portion of the table.

Request ID

Use the request ID to specify multiple requirements within the same run control.

Run Control

You use run controls to produce full messages for objects at the same time. Run controls also associate publish rule definitions with the scheduled full publish process run. For example, you can set up a run control to publish both customer full messages and sales order full messages on a daily schedule.