Setting Up Parallel Processing
Page Name |
Definition Name |
Usage |
---|---|---|
Server Definition Page |
SERVERDEFN |
Define the maximum concurrent processes for Application Engine processes. See Defining the Maximum Concurrent Processes for the Server. See the product documentation for PeopleTools: Process Scheduler for more information. |
AR Parallel Processing Options Page |
PARALLEL_AR_SBP |
Define the exact number of parallel processes or partitions that you want for Receivables Update and Pending Group Generator. |
Job Definition Page |
PRCSJOBDEFN |
Add additional Pending Group Generator and Posting process definitions to the AR_PGG and AR_POST multiprocess jobs. See Adding More Parallel Processes to the AR_PGG and AR_POST Multiprocess Jobs. |
Process Definition Page |
PRCSDEFN |
Add additional Pending Group Generator and Posting process definitions if you need to run more than eight parallel processes. See Adding Additional Pending Group Generator and Posting Process Definitions. |
This section discusses:
Parallel processing.
AR_UPDATE process.
AR_PGG and AR_POST multiprocess jobs.
Parallel Processing
PeopleSoft Receivables enables you to break up the data that Receivables Update processes into multiple pieces (partitions) to be processed in parallel, achieving higher performance. You initiate the parallel processes by using a single run control, and the process automatically divides the work between the number of partitions that you specify in your setup.
The Receivables Update multiprocess job (ARUPDATE) includes:
The AR_UPDATE Application Engine process.
The AR_PGG multiprocess job.
The AR_POST multiprocess job.
The AR_UPDATE2 process.
Note: The ARUPDATE multiprocess job also includes the Revenue Estimate process and the Budget Processor process. The AR_UPDATE2 process calls the Revenue Estimate and Budget Processor processes if you have enabled commitment control for PeopleSoft Receivables and the business unit. The AR_UPDATE2 process also calls the Journal Generator process if you select the Process GL Journal Generator field on the run control. You cannot divide the work for these processes into multiple partitions.
This diagram illustrates how the Receivables Update (AR_UPDATE) process works if you have three partitions. The process builds groups from worksheets and the parallel preprocessor partitions one job into three jobs to create accounting entries. AR_POST runs and posts the transactions for each job and calls the Entry Event Generator, if applicable. Receivables Update can then optionally generate customer history, call the Revenue Estimate and the Budget Processor process if Commitment Control is enabled, and call the GL Journal Generator. Finally, the Receivables Update process performs cleanup.
How the Receivables Update (AR_UPDATE) process works if you have three partitions
![Running parallel processing using Receivables Update (AR_UPDATE)](img/i2a517932n-75c1.png)
When you use Process Monitor to check the status of the Receivables Update process, you view the status of the ARUPDATE multiprocess job and each process within the AR_PGG and AR_POST multiprocess jobs. The system does not indicate that the ARUPDATE multiprocess job is successful until each parallel process finishes. The Job Message Log Summary page summarizes all the individual parallel-process message-log messages for the entire ARUPDATE job.
AR_UPDATE Process
The AR_UPDATE process is the first process that is run within the ARUPDATE job. The AR_UPDATE process acts as a preprocessor for the actual AR_PGG and AR_POST processes and does these tasks:
Builds groups from all worksheets set to post.
Identifies all groups set to post.
Partitions the data between all the child parallel processes for both AR_PGG and AR_POST.
The distribution of data among the child parallel processes is based on the composition and volume of the data. The process considers which groups are eligible for Receivables Update, based on the standard Receivables Update run control, and automatically partitions the data.
AR_PGG and AR_POST Multiprocess Jobs
The AR_PGG and AR_POST multiprocess jobs contain all the PeopleSoft Application Engine process definitions, such as AR_PGG1, that you use for parallel processing.
Each process definition for AR_PGG calls the AR_PGG_SERV Application Engine process. PeopleSoft Receivables delivers eight process definitions for AR_PGG_SERV: AR_PGG1 through AR_PGG8. Each process runs the appropriate Application Engine program to process a specific partition of data. For example, the AR_PGG2 process processes data only in partition 2.
Each process definition for AR_POST calls the AR_POSTING Application Engine process. PeopleSoft Receivables delivers eight process definitions for AR_POST: AR_POST1 through AR_POST8. Each process runs the appropriate Application Engine program to process a specific partition of data. For example, the AR_POST2 process processes data only in partition 2.
If you want to run more than eight parallel instances of the Pending Group Generator or Posting process at once, you must define additional process definitions by using the PeopleSoft Application Designer.
The standard setup for the AR_PGG multiprocess jobs is to run a single process that contains only the AR_PGG1 process definition. The standard setup for the AR_POST multiprocess job is to run a single process that contains only the AR_POST1 process definition. If you want to use parallel processing for these processes, you must assign additional process definitions to the job definition. Working with your system administrator and based on your system configuration, you must specify the number of parallel processes that your organization will use. Specify the number of parallel processes equivalent to the number of processors within your system. You will probably need to experiment with the number of parallel processes to find what works best. Oracle recommends that you assign just a couple of additional parallel processes to start with and increase the number if needed.
You may also need to override the server settings for your organization. By default, you can run up to three instances of a process at one time. If you want to run additional instances you must change your configuration. If you also use parallel processing for the Payment Predictor process (ARPREDCT), Aging process (AR_AGING), and Statements process (AR_STMTS), the maximum instances applies to those processes as well. For example, if you want to run eight instances for the Payment Predictor process and four for the Receivables Update process, configure your server for eight instances.
The items assigned to each instance of AR_PGGx are grouped by Business Unit/Group ID, so that the system processes a specific group by a single instance of AR_PGGx.
The items assigned to each instance of AR_POSTx are grouped by Business Unit/Customer ID/Group ID, so that the system processes all groups containing a specific Business Unit/Customer ID by a single instance of AR_POSTx. When a combination of Business Unit/Customer ID is present in several groups to be processed, there is a risk that the groups will be processed by very few instances of AR_POSTx, no matter how many instances are available. Users can obtain considerable performance gains by concentrating items with specific combinations of Business Unit/Customer ID into fewer groups. For the AR_POSTx process, payments assigned to one process instance are grouped by Business Unit/Customer ID/Deposit ID/Group ID.
Open the PSAdmin tool on your server to change the configuration settings.
To change the maximum instances:
Scroll to the section titled Values for config section - PSAESRV.
The section looks like this:
Values for config section - PSAESRV.
Max Instances = 3.
Recycle Count=0
Allowed Consec Service Failures=0.
Change the value for Max Instances to the maximum number of parallel processes that you want to run at once.
Use the Server Definition page (SERVERDEFN) to define the maximum concurrent processes for Application Engine processes.
Navigation:
Field or Control |
Description |
---|---|
Process Type and Max Concurrent |
For the Application Engine process type, enter the maximum number of parallel processes that you run at once. This figure must be the same or greater than the maximum instances that you defined for PSAdmin. |
Use the AR Parallel Processing Options page (PARALLEL_AR_SBP) to define the exact number of parallel processes or partitions that you want for Receivables Update and Pending Group Generator.
Navigation:
Parallel Processing Options link.
and click theField or Control |
Description |
---|---|
Parallel Process and Maximum Partitions |
Enter the exact number of partitions to generate for the AR_PGG_SERV and AR_POSTING parallel processes. The number of partitions must be equal to the number of processes set up for the AR_PGG and AR_POST jobs. For example, if two AR_PGG processes are defined within the AR_PGG job (AR_PGG1 and AR_PGG2), then the AR_PGG maximum partitions must be set to 2. The maximum number of parallel process cannot exceed the maximum concurrent processes for the server. |
Use the Job Definition page (PRCSJOBDEFN) to add Pending Group Generator and Posting process definitions to the AR_PGG and AR_POST multiprocess jobs.
Navigation:
This example illustrates the fields and controls on the Job Definition page.
![Job Definition page](img/i2a517932n-7576.png)
Field or Control |
Description |
---|---|
Process Type and Process Name |
Select Application Engine for the type and select AR_PGG or AR_POST for each separate partition or process that you want to run. The processes must be defined in the job sequentially; for example, AR_POST1, AR_POST2, AR_POST3. A job definition of AR_POST1, AR_POST2, AR_POST5 is incorrect. If you define additional process definitions, select the name of the definitions that you added. Note: You must have the same number of rows in the process list as you enter in the Maximum Partitions field on the AR parallel Processing Options page. |
Run Mode |
Always select Parallel. |
Run Always on Warning and Run Always on Error |
You must select these check boxes. |
See also the product documentation for PeopleTools: Process Scheduler.
Use the Process Definition page (PRCSDEFN) to add Pending Group Generator and Posting process definitions if you need to run more than eight parallel processes.
Navigation:
Complete the fields on this page and the other pages in the Process Definition component (PRCSDEFN) to match the AR_PGG1 and AR_POST1 process definitions with the following two exceptions:
Use another process name.
Oracle recommends that you use this format for the name: AR_PGG# or AR_POST#, for example AR_PGG9.
Use another description.
To add more processes to run in parallel than the eight delivered by PeopleSoft Receivables:
Open an existing Application Engine program definition such as AR_PGG1 or AR_POST1 in PeopleTools Application Designer.
Do a Save As using the new program name, such as AR_PGG9 or AR_POST9.
For an AR_PGG program, you must edit program step MAIN.PGG_SERV.DoWhen to define which partition will have accounting entries generated by that individual process. Change only the last parameter to match the partition. For example:
SelectInit (AR_UPDATE_AET.PGG_MODE, AR_UPDATE_AET.PARTITION)
%Sql (ARUPDATEPARALLELEXISTS,,9)
For an AR_POST program, you must edit program step MAIN.POSTING.DoWhen to define which partition will be posted by that individual process. Change only the last parameter to match the partition. For example, for AR_POST9:
%SelectInit (AR_UPDATE_AET.RP_ACTION, AR_UPDATE_AET.PARTITION)
%Sql (ARUPDATEPARALLLEXISTS, 2,9)
See also the product documentation for PeopleTools: Process Scheduler.