Professional Documents
Culture Documents
PeopleSoft Global Payroll Performance
PeopleSoft Global Payroll Performance
Payroll Performance
Analysis & Tuning Approach
Payroll processing is the backbone of an organization’s
employee operational and satisfaction focus. With the
growing market hold, Oracle’s PeopleSoft (PS) Global
Payroll has become a value for money choice for a
wide range of the market. The product is intelligent and
efficient to be able to process a few hundreds to multi
thousands of employees’ records.
Calendars 6
Processing Steps 8
3. Problem Statement 8
4. Solution 8
Benchmark the Target 9
Performance of this critical PS component is of vital concern considering the importance of the output of
the program and dependencies other systems may have to the timely completion of the processing of the
engine. Most important, it is a reputation concern for an organization to be able to compensate its employees
on time.
The objective of this paper is to talk about an approach that shall help diagnosing, analyzing and tuning the
performance of a payroll engine. At pit-stops, the paper also refers to possible solutions that shall contribute
in improving the performance of a long running payroll engine.
Country Extensions
Country extensions are built using the core application. Included in the country extensions are:
● Statutory and customary rules including earnings, deductions, absence entitlements, accumulators
and so on.
● Online ’look and feel‘ for the country
● Self service applications
● Reports
Process List • Calculation type indicates whether the process list is for an absence or a payroll run
• Specifies the Elements via sections in the order in which they are to be processed and
resolved
• Provides ability to conditionally execute sections
• Indicate the gross and net pay elements
Sections • Group of elements
• Control the order in which these Elements are processed on the Process List
• Section use indicates whether the section can be used in payroll processing, absence
processing or both
• There are four different section types available that can be used for different types of
processing
• Sections can be reused in multiple process lists
Element • The basic building blocks of Global Payroll
• First component to be defined
• The system resolves each element in the Process List for each payee if they are eligible
to receive it
Calendars
To run a payroll or absence process, the relevant components of the system are tied together through the
use of calendars. A calendar controls who is to be paid, what amounts are to be paid, and the period of time
for which the payment is being made. Only one pay group can be associated with a calendar.
Create Calendars • Calendars tell the system which pay group, run type, process list, and calendar
(Required) period to process.
• Pay groups, run types, and process lists are defined during system implementation.
• Calendar periods can be defined during implementation or when calendars are
being setup.
Create the calendar • The calendar group ID identifies the set of calendars that run together and the
Group ID (Required) sequence in which the calendars are to be processed.
• If stream processing is required, then it is necessary to indicate it when setting up
the calendar group ID.
Create Streams • To use stream processing, the range of employee IDs for each stream is identified.
(Required) • Stream set up is a one-time process that may require the assistance of a database
administrator.
Create Group Lists • To use the group list feature, clerks who run the payroll process select the payees for
(Optional) each group list. (Group lists are tied to user IDs.)
Enter Positive Input • Positive Input (PI) for the pay period can be entered before or after you begin
(Optional) processing.
• If PI is entered after running the Calculate phase, then Calculate must be run again
to pick up the new entries.
Perform Payees The payroll cycle begins when you run a process that identifies all payees that are to
(Identify Phase) be processed.
Perform Calculations This phase computes each payee’s gross and net earnings (for a payroll run) or
(Calculate Phase) absence take or entitlement units (for an absence run).
Review Results If the system encounters problems during the Calculate phase—for example, invalid
element definitions or payee eligibility problems—it places the payee in error. You
can use various PS payroll pages to review summary results, errors, and warning
messages.
Correct Any Errors & To correct errors, you may need to update the Positive Input pages or make changes
Recalculate to the data in other applications that are integrated with PS Global Payroll, such as
Human Resources or Time and Labor. You can then run the Calculate phase again to
process only the payees that need to be recalculated.
Finalize the Run When you’re satisfied with the processing results, run the Finalize phase to close the
calendar group ID.
Problem Statement
The subject of payroll tuning involves multiple nodes, for example - database level tuning, server capacity
utilization and application level setup improvements. A wide range of documents on these various subjects
are available on the PS site already.
There is, however, no single answer to the problem statement of a poorly performing payroll engine.
Performance engineers are required to be able to catch the right spot(s) where there is need for improvement
and apply the corresponding resources and solution(s).
In simple terms, the quest is for an approach that leads an engineer to the performance tuning measures
applicable in a particular scenario.
Solution
“How can we improve performance?” - The big question has multiple immediate child questions like:
● Is the performance currently really poor?
● Who would start?
● Where is the problem? Where do we start?
● How do we resolve the problem? Is this the correct solution?
● Is this a success?
The approach to the solution discussed in this paper is simple and fruitful. All we need to do is to answer
questions listed above in the correct order.
What we would instead focus on is how to help ourselves find the right cause of our problem and how to find
the right fix for the identified problem.
Please note that all performance tuning benchmarks are environment and data volume/distribution
specific.
To access the benchmark reports on the PS site, please follow the steps mentioned below:-
1. Logon to the PS site (http://www.peoplesoft.com) using your connection user ID and password
2. Click on the link ”Implement, Optimize, and Upgrade”
3. Click on the link ” Optimization Guide”. On the following page, choose the link ”Performance Tools “
4. Click on the link ”Benchmark Performance Reports”.
Needless to say, the person responsible for the payroll engine tuning needs to verify the total time the payroll
engine takes against the benchmarks established in the above mentioned reports directory.
Deciding the target for performance improvement depends on the reasons due to which the current
performance is not acceptable. It also depends on how much deviation is found between the installed
version and the corresponding benchmark results.
What is now crucial is to brainstorm on these factors and decide a target for the tuning exercise.
The payroll performance tasks can include application level tuning, SQL changes, database configuration
changes, server capacity review tasks and so on.
Before drilling down to the problem, make sure that a competent task force capable to cover all the aspects
mentioned above is available. You may or may not deploy one or more members depending on the kind of
performance improvement potential at your installation.
● Team lead/coordinator
● PS payroll business analyst
● PS payroll technical developer
● PS DBA
● Systems Engineer with server capacity, utilization insight
The first step in tuning is to find out what is to be tuned. In other words identify the area deteriorating the
performance of the payroll engine.
The domain pertains to DBAs and System Administrators. The idea is to trace the payroll engine programs
to identify the area impacting the overall processing time.
There are multiple tools to study this behavior like – Strobe, OMEG, TMON, Apptune, Detector and so on.
Your System Administrator should be able to suggest a tool suitable to your environment. For information on
the various tools in the z/OS environment and their usage, please use the links below.
http://www.db-consulting.com/
http://www4.peoplesoft.com/2001presentsamer.nsf/SessionTrack?readform
Out of the three components - system idle time, DB2 wait time, processing time, the most debatable is the
‘processing time’. Therefore, let us for the moment park this aside and look at the other 2 components.
If your DBA finds this time abnormally high, then review is required in the areas of disk I/O, DB2 connect
parameters, PTPSQLRT package bind parameters etc. Following case discusses such a case where one of
the PTPSQLRT bind parameter was found to be the culprit causing the DB2 wait time to grow up to 64%.
Case begins:-
In one of the scenarios, following was the time distribution noticed (the statistics were gathered using
STROBE tool).
System idle time – 23.5% (Waiting for the shared memory – 11.5%, System services (OS related) – 12%)
DB2 wait time – 64%
Processing time – 12.5%
This clearly indicates that one of the first diagnostic targets is the ‘DB2 wait time’.
Upon investigation it was found out that one of the bind parameters of PTPSQLRT package - IMMEDWRITE
was incorrectly set to IMMEDWRITE (YES) by the local configuration management tool (SCM). Once the
parameter was reset to IMMEDWRITE (NO), the statistics changed to the following:
System idle time – 23.5% (Waiting for the shared memory – 11.5%, System services (OS related) – 12%)
DB2 wait time – 10.5%
Processing time – 66%
Case ends.
For more information on the DB2 connect parameters, please see the Solution ID – 47387 on the PS site
(http://www.peoplesoft.com/psp/portprd/CUSTOMER/CRM/c/RC_SELF_SERVICE.RC_SOLNSRCH_SW_
SS.GBL?portalispagelet=true)
Diagnostic steps 1 & 2 are already discussed in section 5.4.1 and 5.4.2. Steps 3 to 8 relate to the time spent
in processing the payroll engine program.
● Zparm check for example edmpool, lock thresholds, sort pool, rid pool, parallelism
● Buffer Pool Check for example non-catlg tsps in BP0
● Tablespace Locksize
● Compressed tablespaces
● Non-clustered clustering indexes
Both these activities are affected by the volume of data. During the first cycle, following the upgrade or
implementation operation, it could be helpful to often rebuild the indexes and update statistics.
The tables used in Payroll Calculation are constantly being updated, deleted, tested, or restored. This makes
the statistics useless and, in many cases will lead the optimizer in the wrong direction. Hence, it would be
advisable to rebuild indexes and update statistics at regular intervals of data loading or conversion.
In such a case the statistics calculation always sees 0 and therefore these tables are handled as unused or
seldom used. For temporary payroll tables this is clearly incorrect and it ends up in huge and time consuming
‘insert’, ‘update’ and ‘delete’ statements.
Thus, we can ensure that the database statistics do not negatively affect the tables.
Let us take a case where an employee-range GP00001 – GO00400 falls under one pay run ID. In a typical
sequential processing, this is how the employees would be processed in the payroll engine:
On the other hand, if we segregate the employee range into 4 streams (GP000001 to GP000100, GP000101
to GP000200, GP000201 to GP000300, GP000301 to GP000400), the pattern of parallel processing would
be as follows:
In the case shown below, an ideal parallel processing (implemented through streaming) should reduce the
total processing time to approximately ¼.
Having said that, please note that the amount of time saved by implementing streaming, among other
factors, depends upon the employee population, server capacity and CPU states, under normal sequential
payroll run.
The streaming option saves the processing time by making use of the unused server capacity in the sequential
processing. In the case mentioned above, if we assume an ideal scenario with 4 load sharing CPUs; this is like
how the load distribution would change by implementing streaming as opposed to sequential processing:
For details on implementation of payroll streaming, please refer to solution ID 200748163 on the PS site.
From the database aspect, some of the payroll tables are required to be partitioned in the pattern of the
streams defined. Essentially the tables are partitioned so that two or more processes (payroll streams) are
simultaneously able to make changes to the same table for their corresponding and mutually exclusive
rows.
Case begins:-
In one of the tuning exercises, it was found that the following tables are required to be partitioned for
streaming to run successfully.
1. PS_GP_EXCL_WRK
2. PS_GP_GRP_LIST_RUN
3. PS_GP_HST_WRK
4. PS_GP_JOB2_WRK
5. PS_GP_MESSAGES
6. PS_GP_NEW_RTO_WRK
7. PS_GP_OLD_RTO_WRK
8. PS_GP_PI_GEN_DATA
9. PS_GP_PI_GEN_HDR
10. PS_GP_PI_GEN_REF
11. PS_GP_PI_GEN_SOVR
12. PS_GP_PYE_PRC_STAT
13. PS_GP_PYE_RCLC_WRK
14. PS_GP_PYE_RUN
15. PS_GP_PYE_SEG_STAT
16. PS_GP_PYE_STAT_WRK
17. PS_GP_RSLT_ABS
18. PS_GP_RSLT_ACUM
19. PS_GP_RSLT_DELTA
20. PS_GP_RSLT_ERN_DED
21. PS_GP_RSLT_PIN
22. PS_GP_RTO_PRC_WRK
23. PS_GP_RTO_TRG_CTRY
24. PS_GP_RTO_TRGR
25. PS_GP_RTO_TRGR_WRK
26. PS_GP_RUNCTL
27. PS_GP_SEG_WRK
28. PS_GPCH_RP_FK01
29. PS_GPCH_RP_FK02
30. PS_GPCH_RP_SI07
31. PS_GPCH_RP_SI08
32. PS_GPCH_RP_TX01
33. PS_GPCH_RP_TX05
34. PS_GPCH_RP_0001
35. PS_GPCH_RP_0002
36. PS_GPCH_RP_MT
This list may need addition or deletion for a different version of payroll or for customized applications. The
shortest way of getting to know which tables have to be partitioned is by hit and trial method.
Let us suppose you partition the tables listed above and still at least one of the payroll engine streams
fails indicating that a table is locked by another process. In this case, you need to find out if the table was
partitioned or not. Partition the table, run the streams again and check for success.
From the database perspective, partitioned tables had the following disadvantages:
● In a partitioned tablespace, only one table can be created (table space (TS) and table definitions are
related and dependent).I In a normally segmented TS you can create more than one table.
● In partitioned TS, a table cannot be dropped explicitly. It needs the TS to be dropped which drops
the table implicitly.
● PeopleSoft application does not support making table partitioning through its development
environment. Therefore after the tables are partitioned at the database level, the PeopleSoft
metadata would not match with the table definitions on the database.
● If a table is not partitioned, this is how you alter it with ‘alter by rename’ option:
1. Create a table with the new structure (new attribute definitions) with a similar name in the same table
space as the original table.
2. Populate the new table with the ‘old’ rows from the original table (insert into tab new select ... from
tab old).
3. Drop original table.
4. Rename new table to original name
This process is no longer possible with tables in a partitioned TS. One solution is to change the
original table with an ALTER Table command. This is possible only if new
attributes are added to the table or if varchar attributes are to be enlarged. It is not possible if an
attribute needs to be eliminated or if changes are done for attributes with
the types CHAR, DECIMAL, FLOAT or if a varchar is being reduced in length.
Another time consuming solution, but the only solution for all kinds of changes, is to
create a new table space (with the specific partitioning parameters set) and create the
new table in it (partitioning index is mandatory, new index name is needed because
original one cannot be dropped). The new table may then be populated and the old table
space dropped. Rename the new table to original table name. For empty tables (work
tables, temp tables) in a partitioned TS the process is shorter because no data is affected; drop TS
(table included), create new TS, new table, indexes.
There is one advantage related with partitioned TS for the housekeeping process. Utilities like image copy,
re-organization, unload, load can be processed on a specific partition or can process the partitions in parallel
to reduce elapsed time.
Case ends.
However, please note that this exercise can be time consuming. Also it needs precise impact analysis since
the dynamically generated SQLs in payroll engine may impact the performance in multiple dimensions at
multiple instances.
You can find out which SQL is running slow using PS traces, DB2 historical traces or DB2 real time traces.
Diagnostic tools to be used in conjunction could be DB2 explain or any other tool recommended by your
DBA.
TraceSQL is not normally invoked during processing so the first step is to recreate the problem with TraceSQL
invoked. For COBOL processes, this is normally set in the file which sets parameters for the Process
Scheduler. The parameter name is TraceSQL with value set as desired according to the following:
So, if you want statements, Row Fetch and COBOL timings, you would specify TraceSQL=137 (1+8+128).
For troubleshooting, sometimes it is best not to guess which values you want so 255 will set all values on
-- except for the Sybase specific settings.
Once you have the cobsql file -- and the COBOL TraceSQL results, the next step is locating the clues
provided for the problem at hand. Locate the SQL consuming high processing time. Once you find the point
of the problem, note the cursor number -- for example #12.
Working your way on up in the file, locate the SQL statement that established this cursor. It is that statement
that needs to be further analyzed for the cause of the problem. Start by copying that statement into your
SQL tool and replacing any variables (:1, :2 and so on) with appropriate values. Break down the statement
into smaller statements as needed to determine the cause of the problem.
This is the basic for problems with SQL. Tracing can be used for trouble shooting logic issues also, but that
is another chapter.
A high commit frequency set at this place degrades the engine’s performance. Review the frequency set
here and revise it to the optimal for a successful run.
Note that, on the other hand, having a low commit frequency (committing less often) may result in a conflict
with payroll streaming.
As discussed above, the two (or more) streams run in parallel in case of streaming access the same tables
at almost the same time. Therefore there remains a risk of clash on a un-partitioned table. Lower the commit
frequency, higher the chances of such a clash.
The following sections have some tips to revise your payroll setup.
● All Elements - There are two attributes on the Element Name page that can affect performance and
data volume: Always Recalculate and Store/Don’t Store.
(a) Always Recalculate - You should select the Always Recalculate option (on the Element
Name page, GP_PIN record) only when it is required in situations where you encounter
the element multiple times within the same slice or segment and you expect its resolved value to
change.
When the PIN manager encounters an element, it first checks to see if that element has already
been resolved for the payee for the appropriate slice, segment or period.
If the element has not been resolved, the system automatically resolves the element, regardless
of the Always Recalculate setting. If the element has been resolved, the system checks the
Always Recalculate setting. If the setting is ‘No’, the system uses the previously resolved value.
If the setting is ‘Yes’, the system resolves the element. Each resolution slows down the
performance.
(b) When to store data - You should only be storing an element if it is needed in one of these
situations:
- Reporting, either in result tables or in a writeable array
- Retroactivity
- Historical rules
- Fictitious calculations
- Chart fields
- Audits
In addition, with earnings and deductions you can indicate whether you want to check the resolved value or
all individual component values to determine whether to store the element. Unless you need the individual
component values for purposes of reporting or historical rules, you should only be storing earnings and
deductions if the resolved value is not zero.
● Arrays
Arrays must be set up correctly in order to maximize performance.
(a) Calling the Lookup Processing Option Formula - There are multiple ways to set up an array. The
most important thing you can do to enhance performance is to reduce the number of times you call
the lookup formula.
If the goal of your array is to return only one row by segment or slice, it is best to avoid the lookup
formula process by using the key page with the appropriate conditions and the return page with the
appropriate logical order.
(b) Ordering the Fields Retrieved - It is important to find the appropriate order of your rows to
minimize the call to the formula. Usually, when you check an effective date it is better to order the
date field by descending value.
(c) Using the By Formula, Apply All Rows and the By Row, Apply All Formulas Options - You may use
By Formula or Apply All Rows if you need a first reading before handing the array.
(b) formulas that use other formulas - You should always think about this when making the decision
on whether to create a separate formula. Maintenance is also a consideration.
(c) exit functions - When you are using If logic in a formula, you should remember to use exit logic
whenever applicable so that the system does not resolve any unneeded elements.
(d) IF functions - When you have multiple conditions, you should always put the most popular
condition at the top so that you match the majority of your population at the very beginning.
(e) Min/Max functions - When you need to retrieve the smaller or larger value of two or more
elements, it is better to use the Min/Max function as opposed to IF/Then logic.
● Historical Rules
Before deciding whether to use a historical rule, you need to consider the following:
(a) the number of periods or segments that your historical rule must read.
(b) the frequency at which your historical rule will be resolved.
This will help you determine whether using a historical rule makes sense.
● Proration Rules/Counts
If you must access Work Schedule information, such as scheduled hours and so on, in order to help resolve
Proration Rules, you should try to read the work schedule only once in order to improve performance.
You typically read a Work Schedule through a Count Element (which uses a formula that checks to see
Scheduled Hours and so on).
When you need to have multiple proration rules such as calendar days, workdays and work hours for the
same slice periods, it is better to have one count element to resolve all proration rules. Thus you read the
work schedule information only once.
No. CAL_RUN_ID PIN_NM PIN_TYPE RECALC_IND Call From Count Delay in Average
Process No. Second
1 KDG0101 DE_DV_DATA AR Y Y 1 .370000 .370000
2 KDG0101 DE_SI_SETUP FM Y Y 25 4.550000 .182000
3 KDG0101 DE_INIT_PA FM Y Y 1 .150000 .150000
4 KDG0101 DE_GR_EE AR Y Y 1 .150000 .150000
5 KDG0101 DE_SI_EE_DATA AR Y N 1 .140000 .140000
6 KDG0101 DE_FL_INIT_ELIG FM Y Y 1 .130000 .130000
7 KDG0101 DE_AB_DISABILITY_G AR Y N 1 .130000 .130000
8 KDG0101 DE_SI_RATE_FUND FM Y N 25 3.120000 .124800
9 KDG0101 DE_SI_K_STATUS VR N N 25 3.110000 .124400
10 KDG0101 DE_SI_PROV_KEY VR N N 25 3.110000 .124400
11 KDG0101 DE_SI_A_PROV VR N N 25 3.110000 .124400
12 KDG0101 DE_CC_COND FM N Y 1 .100000 .100000
Brackets - It is recommended that you do not have more than 100 rows for the same effective date by
bracket. If you have more than 100 rows for a bracket, you should consider using an array instead.
The payroll setup recommendations above have been extracted from the ‘Tuning PeopleSoft Global Payroll’
document available over customer connections.
Additionally please see the document referred above to find details on the sections mentioned above and
also to find information on ‘Methods for Reducing the Size of Result Tables’ and ‘List of Tables to Aid in
Archiving Solutions’.
To ensure that the correct node is looked at and the culprit issue is found and corrected without wasting effort
at non important subjects, the tuning exercise can be structured in the following way:
1. Benchmark the target
2. Identify the task force
3. Find the culprit area
4. Identify the best fit solution
5. Fix and compare against the benchmark
6. Freeze
The following would be an optimal task force for the tuning activities to guarantee success:
1. Team lead/coordinator
2. PS payroll business analyst
3. PS payroll technical developer
4. PS DBA
5. Systems Engineer with server capacity, utilization insight
Also, identifying the loophole and applying the best fit solution should be carried out in the following sequential
fashion:
1. Address the system Idle time (tuning z/OS, Disk I/O etc) – Diagnostic step 1
2. Address the DB2 wait time – Diagnostic step 2
3. Address the processing time
3.1 Environment health check – Diagnostic step 3
3.2 Database statistics – Diagnostic step 4
3.3 Payroll partitioning – Diagnostic step 5
3.4 SQL Tuning – Diagnostic step 6
3.5 Commit level – Diagnostic step 7
3.6 Other payroll setups – Diagnostic step 8
References
PS 8.3 Global Payroll PeopleBook
Oracle PeopleSoft website - http://www.peoplesoft.com
http://www.db-consulting.com/
Email: natarajan.srinivasan@tcs.com
Website : www.tcs.com
All content / information present here is the exclusive property of Tata Consultancy
Services Limited (TCS). The content / information contained here is correct at the time
of publishing. No material from here may be copied, modified, reproduced, republished,
uploaded, transmitted, posted or distributed in any form without prior written permission
from TCS. Unauthorized use of the content / information appearing here may violate
copyright, trademark and other applicable laws, and could result in criminal or civil
penalties.