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