The Background Process Model

Many functions in Oracle's PeopleSoft General Ledger, such as journal editing and posting, allocations processing, financial consolidations, year-end closing, and creation of summary ledgers are run as background processes using a process request page. A common processing model is incorporated into all PeopleSoft background processes to initiate processes, monitor their progress, and track their history. In addition, through commits, this model frees shared resources as quickly as possible to facilitate concurrent activity.

The model includes the following elements:

  • Unit of work.

  • Process instance (run ID).

  • Request records.

  • Message log.

PeopleTools Documentation: PeopleSoft Process Scheduler, "Understanding PeopleSoft Process Scheduler"

The unit of work is the interval of processing that takes place between commit points. All PeopleSoft General Ledger background processes use a functional approach to defining the unit of work. This guideline is the basis for the restart and recovery process. If a program encounters an error during the unit of work interval, the system rolls back all processing to the previous completed unit of work. If a rollback occurs as a subset of the request criteria, this point is indicated on the request record for that background process.

For the Allocations and Year End Close background processes, the unit of work is defined as a subset (a process step) within the request level. The program can successfully complete an allocation step or close a ledger for a fiscal year without completing all the steps or business units specified in the request record. The Year End Close and Journal Posting processes commit the work for each unique ledger and business unit combination. This enables you to continue an interrupted job by starting from the failed business unit. In these cases, several commits could be issued before the request record is updated. For the Consolidations and Equitization process, the unit of work is the same as the request level.

The amount of time required to complete a unit of work is critical when determining which processes can run concurrently. Because this is a function of the data, the nature of the requests, and the database environment, you should run tests of typical units of work to see how long they take in the absence of conflicting processes.

The system assigns a unique process instance number to each background run. The number uniquely identifies data within shared work and log tables. The process instance field counter resides in PS_PRCSSEQUENCE.SEQUENCENO. At the start of a background process, a program updates the counter (incrementing it by 1), selects the value, and then commits the work.

The request record stores information about the status of a background process. A request record defines the input data that a background process uses to complete a unit of work, and it contains these fields:

Term

Definition

OPRID and RUN_CNTL_ID

Identifies a request set, which can be made up of multiple requests.

REQUEST_NBR or REQUEST_ID

Identifies the individual requests within that request set.

PROCESS_FREQUENCY

Indicates whether to process a request every time the request set is processed or only the next time.

PROCESS_STATUS

Indicates the success or failure of the request once it is processed.

DTTM_STAMP_SEC

Stores the date that the request was last processed.

When a background process starts, it reads the first request record that is flagged for processing. After the record is read, it is immediately updated as In Process and committed by the background process. This prevents other instances of the process from reading and processing the request, and provides information about the current status.

If the PROCESS_FREQUENCY field value is Process Once, the process changes the value to Don't Process when the request is complete. The process updates the PROCESS_STATUS field to reflect the success or failure of the run, and it issues a commit immediately after the update.

Each background process generates informational and error messages related to the process run. Because all processes share the tables where the system logs these messages, a commit occurs after an insert into the Message Log table to prevent locking by one process.