Understanding the Effective Date Publish Utility

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 have effective dates later than the system date (usually the current date).

Historical rows have effective dates prior to the current row.

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.

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.)

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 enables the system to select the appropriate effective-dated rows, when combined with the effective date field.

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.

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 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.

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.

Use the request ID to specify multiple requirements within the same 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.