PeopleSoft Global Payroll Performance

PeopleSoft Global Payroll Performance TATA CONSULTANCY SERVICES1

PeopleSoft Global Payroll Performance

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 effi cient to be able to process a few hundreds to multi thousands of employees’ records.

The performance tuning of the PS payroll engine is well documented under various subjects. However, due to different needs of customers, some topics may not be relevant at a particular instance. At times this leads to customers trying out various possibilities to tune the engine, looking for multiple subjects, doing a hit and trial and in most cases getting lost in the vast span of subjects, possibilities, responsibilities and case studies.

The paper discusses the building blocks that ensure a time saving performance tuning exercise applicable at a particular installation. The paper does not focus much on the range of resolutions to a poorly performing payroll engine. Instead it talks about a performance diagnostic and tuning approach that can be used at any PS Payroll 8.3 (DB2 - z/OS) installation.

Analysis & Tuning Approach


About the Author

Jitesh KohliJitesh has been working with TCS since 2001. He holds a Bachelors degree in Mechanical Engineering from REC Kurukshetra.

Jitesh has worked on PeopleSoft applications with several engagements of TCS. Additionally, his credentials includes working on Microsoft and e-Learning technologies.


Table of Contents1. Introduction 3

2. Recap-Global Payroll Fundamentals 3

Brief Introduction to PeopleSoft Payroll Architecture 3

Global Payroll Organizational Structure 4

Global Payroll Processing Structure 5

Calendars 6

Payroll Processing Preparation 7

Processing Steps 8

3. Problem Statement 8

4. Solution 8

Benchmark the Target 9

Identify the Task Force 9

Find the Culprit Area 10

Identify the Best Fit Solution 10

5. Summary & Conclusion 21

6. References 21


IntroductionPS payroll core engine is the heart of payroll processing for systems utilizing the PS payroll product. PS payroll core engine is a calculation COBOL program that processes its calculations based on rules set up in the PS global payroll set up pages.

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.

Recap - Global Payroll FundamentalsBrief introduction to PeopleSoft Payroll ArchitecturePS Global Payroll essentially is a coupling of two components:

Core Payroll Application(a) Flexible payroll rule engineThe rule based engine is a fl exible tool that defi nes and executes payroll and absence calculations. All business application logic such as earning, deduction, absences and accumulators are specifi ed in terms of payroll and absence rules. These rules can be entered and maintained through a set of pages.

(b) Processing frameworkThe core Global Payroll application is a common foundation and structure that organizations in every country can use to build their own calculation rules. The core application determines the basic framework for payroll and absence processing. This basic framework supplies the normal processing structure for the calculation of a payroll or absence.

Country ExtensionsCountry 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


Fig 1 Global Payroll comprehensive diagram

Global Payroll Organizational StructureThe PS Global Payroll core application determines the organizational structure for payroll processing. The organizational structure comprises a hierarchy of components.

Fig 2 Global Payroll Organizational structure


The following table will help recall the various components shown in Fig2 above.

Pay Entity • The organization that makes the payment• The currency to be used as the processing currency for every calculation• The country associated with the Pay Entity

Pay Group • Associated with single Pay Entity• Grouping of Payees to process together• Linked with pay calendar in order to process a payroll

Eligibility Group • Group of Element Groups • Indicates the Elements for which a certain payee is eligible• Default Eligibility Group is defi ned at the pay group level• Payees are assigned to a default Eligibility Group, but it can be overridden

Element Group • Group of Elements• Any number of Element Groups can be assigned to an Eligibility Group

Element • The basic building blocks of Global Payroll• First component to be defi ned

Global Payroll Processing StructureThe processing structure of Global Payroll determines which elements are used for calculation of a particular payee and in what order.

Fig 3 Global Payroll Processing structure


The processing structure is comprised of the components specifi ed in the table below:

Process List • Calculation type indicates whether the process list is for an absence or a payroll run• Specifi es 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 diff erent section types available that can be used for diff erent types of processing• Sections can be reused in multiple process lists

Element • The basic building blocks of Global Payroll• First component to be defi ned• The system resolves each element in the Process List for each payee if they are eligible to receive it

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

Fig 4 Global Payroll Calendars


Through the use of various selection criteria, you can defi ne who is going to be paid:

Calendar Run Types • Enable defi ning what is being paid• Linked to the ‘Processing Structure’

Calendar Period IDs • Enable defi ning the period of time for which the payment is being made

Calendar ID • Enables defi ning the payees going to be processed• Linked to ‘Organizational Structure’

Calendar Group ID • Groups the calendars that are to be process at the same time

Payroll Run Control • Identifi er used to run the payroll or absence processing

Payroll Processing PreparationNow that we have recalled how the payroll run controls, payees and run types are linked together, let us look at how we prepare our system before we run a payroll process.

Fig 5 Global Payroll Processing Preparation

Create Calendars (Required)

• Calendars tell the system which pay group, run type, process list, and calendar period to process.• Pay groups, run types, and process lists are defi ned during system implementation. • Calendar periods can be defi ned during implementation or when calendars are being setup.

Create the calendar Group ID (Required)

• The calendar group ID identifi es the set of calendars that run together and the 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 (Required)

• To use stream processing, the range of employee IDs for each stream is identifi ed.• Stream set up is a one-time process that may require the assistance of a database administrator.

Create Group Lists (Optional)

• To use the group list feature, clerks who run the payroll process select the payees for each group list. (Group lists are tied to user IDs.)

Enter Positive Input (Optional)

• Positive Input (PI) for the pay period can be entered before or after you begin processing.• If PI is entered after running the Calculate phase, then Calculate must be run again to pick up the new entries.


Processing StepsFig 6 below shows how payroll processing happens starting from identifying payees to fi nalizing the process.

Fig 6 Global Payroll Processing Steps

Perform Payees (Identify Phase)

The payroll cycle begins when you run a process that identifi es all payees that are to be processed.

Perform Calculations (Calculate Phase)

This phase computes each payee’s gross and net earnings (for a payroll run) or absence take or entitlement units (for an absence run).

Review Results If the system encounters problems during the Calculate phase—for example, invalid element defi nitions 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 & Recalculate

To correct errors, you may need to update the Positive Input pages or make changes 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 satisfi ed with the processing results, run the Finalize phase to close the calendar group ID.

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


Kindly note that in this paper we are discussing the ‘approach to fi nd a solution’ more than the solution itself. The reason for this is that the solution belongs to a problem and there is no single problem which is always the culprit for poor performance of the payroll engine.

What we would instead focus on is how to help ourselves fi nd the right cause of our problem and how to fi nd the right fi x for the identifi ed problem.

The following are the 6 steps to success: 1. Benchmark the target2. Identify the task force3. Find the culprit area 4. Identify the best fi t solution5. Fix and compare against the benchmark6. Freeze

Benchmark the TargetPerformance is a fairly relative term. To be able to comment on the performance of the payroll engine at a particular installation, we fi rst need to know what the corresponding benchmarks are.

Please note that all performance tuning benchmarks are environment and data volume/distribution specifi c.

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

Identify the Task ForceBy comparing the time the payroll engine takes to process against the time in the corresponding benchmark in previous section, we should, by now, know if we need any performance improvement tasks at all. If yes, then the next step is to identify the human resources required to bring the performance up and close to the benchmark results.

The payroll performance tasks can include application level tuning, SQL changes, database confi guration 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.


The following list demonstrates an example task force for the tuning activities:

● Team lead/coordinator● PS payroll business analyst● PS payroll technical developer● PS DBA● Systems Engineer with server capacity, utilization insight

Find the Culprit Area On the mark, get set. Go!

The fi rst step in tuning is to fi nd 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

Identify the Best Fit SolutionBroadly, the payroll engine processing can be distributed time-wise into system idle time, DB2 wait time and processing time.

Fig 9 Payroll Engine Processing Time (High Level)

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.

http://www.db-consulting.com

http://www4.peoplesoft.com/2001presentsamer.nsf/SessionTrack?readform


System Idle time (tuning z/OS, Disk I/O etc) – Diagnostic step 1a) Wait for OS related system services – As with any other process, there are some

operating system related activities with the payroll engine processing. An example of such activities would be opening/closing fi les. In most of the cases, this is not a problem, however if it is considered high by the system administrator, then the emphasis needs to be laid at the hardware aspects, abnormal system behavior (virus!, network) etc.

b) Wait time for shared memory – Host environments are expensive and in most of the cases shared amongst multiple applications. While analyzing the statistics please note which CPU (In multiple CPU scenario) the wait time belongs to. If you are not using payroll streaming, then you would fi nd that most of or all the wait time belongs to a single CPU. Study the statistics against this single CPU only and do not average it amongst all the CPUs in place (which would increase the %age wait time and give incorrect impression). If the system administrator still fi nds that the %age wait time is high, then analyze the factors behind high wait time. In most of the cases you would fi nd another job running on the CPU with priority higher than the payroll job. Readjust the application priorities based on your business requirements. In worst case, you may also look at the option of utilizing a dedicated (against shared) environment for payroll (or PeopleSoft application).

DB2 wait time – Diagnostic step 2In a way, the system idle time and DB2 wait time are interdependent. Therefore while analyzing the statistics gathered for these two components, it is important that your DBA and the system administrator work in tandem.

If your DBA fi nds 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 fi rst 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 confi guration 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)

http://www.peoplesoft.com/psp/portprd/CUSTOMER/CRM/c/RC_SELF_SERVICE.RC_SOLNSRCH_SW_

http://www.peoplesoft.com/psp/portprd/CUSTOMER/CRM/c/RC_SELF_SERVICE.RC_SOLNSRCH_SW_


Processing TimeOnce the ‘System Idle time’ and ‘DB2 wait time’ are tuned, we get much closer to the application tuning. Please see the chart below, detailing the preferred sequence and drill down of diagnostics steps.

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.

Fig 10 Payroll Engine Processing Time (Low Level)

Environment health check – Diagnostic step 3With the help of the DBA and the system administrator, review the health of the DB2 z/OS environment. A typical health check in the DB2 z/OS environment would include:

● 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

Additional precautionary health check steps could be to:

1. recreate indexes to be sure none are corrupt2. update Statistics

Both these activities are affected by the volume of data. During the fi rst 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.


Database statistics – Diagnostic step 4In the previous section, we noticed that one of the measures to ensure good health of DB2 is to run the database statistics at regular intervals. However with respect to the payroll engine there is an exception - DB2 statistics handles some tables not as they should be handled. These are the tables used as temporary tables during the payroll run, which start with a record count of 0 and end with a record count of 0. But during a payroll run they may have a record count of several hundred thousand or even more.

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.

The solution to this problem could be to:

● Identify the tables used in the payroll engine● Separate out these tables from other tables by putting these tables in independent tablespaces

(1table per tablespace)● For the tables identifi ed in the previous step, set the statistics related rowcount to a value of -1. This

is a more generic way to set the statistics to an optimum for tables which can store up to 10,000 or 20,000 rows.● Set the rowcount to a realistic value. This requires a manual ‘catch’ of the real fi gures during a

payroll run which has to be manually monitored.

Thus, we can ensure that the database statistics do not negatively affect the tables.

Payroll partitioning – Diagnostic step 5In simple terms, payroll streaming can be defi ned as segmenting employees into defi ned streams. These streams are processed in parallel, reducing the processing time for the complete population.

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:

Fig 11 Payroll Engine Processing Without Streaming

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


Fig 12 Payroll Engine Processing With Streaming

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:

CPU states before implementing payroll streaming (sequential processing):-

CPU USER SYS IDLE

0 0.0% 0.0% 100%

1 92.4% 5.8% 1.8%

2 10.8% 2.2% 87%

3 0.0% 1.6% 98.4%

Average 25.8% 2.4% 71.8%

CPU states after implementing payroll streaming (parallel processing):-

CPU USER SYS IDLE

0 94.0% 2.8% 3.2%

1 92.4% 5.8% 1.8%

2 96.4% 2.2% 1.4%

3 89.2% 3.6% 7.2%

Average 93% 3.6% 3.4%

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


The solution referred above includes the reference to the list of the tables required to be partitioned for streaming to run successfully.

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_WRK2. PS_GP_GRP_LIST_RUN3. PS_GP_HST_WRK4. PS_GP_JOB2_WRK5. PS_GP_MESSAGES6. PS_GP_NEW_RTO_WRK7. PS_GP_OLD_RTO_WRK8. PS_GP_PI_GEN_DATA9. PS_GP_PI_GEN_HDR10. PS_GP_PI_GEN_REF11. PS_GP_PI_GEN_SOVR12. PS_GP_PYE_PRC_STAT13. PS_GP_PYE_RCLC_WRK14. PS_GP_PYE_RUN15. PS_GP_PYE_SEG_STAT16. PS_GP_PYE_STAT_WRK17. PS_GP_RSLT_ABS18. PS_GP_RSLT_ACUM19. PS_GP_RSLT_DELTA20. PS_GP_RSLT_ERN_DED21. PS_GP_RSLT_PIN22. PS_GP_RTO_PRC_WRK23. PS_GP_RTO_TRG_CTRY24. PS_GP_RTO_TRGR25. PS_GP_RTO_TRGR_WRK26. PS_GP_RUNCTL27. PS_GP_SEG_WRK28. PS_GPCH_RP_FK0129. PS_GPCH_RP_FK0230. PS_GPCH_RP_SI0731. PS_GPCH_RP_SI0832. PS_GPCH_RP_TX0133. PS_GPCH_RP_TX0534. PS_GPCH_RP_000135. PS_GPCH_RP_000236. 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 fi nd out if the table was partitioned or not. Partition the table, run the streams again and check for success.


Another learning drawn from this exercise is the run control table for payroll engine - PS_GP_RUNCTL. This table needs to have lock size of not more than 1 row per page for 2 or more streams to run in parallel. This is required to avoid one of the processes from locking the run control table while reading the parameters which can happen because the table size is small (usually not more than a couple of rows).

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 defi nitions 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 defi nitions 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 defi nitions) 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 specifi c 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 specifi c partition or can process the partitions in parallel to reduce elapsed time.

Case ends.

SQL Tuning – Diagnostic step 6The above 5 diagnostic and tuning exercises should result in fairly high degree of performance gain. Further tuning can be made by diagnosing and tuning long running SQLs in the program.

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


More information on the topic can be obtained from the PS customer connections. Below is a brief guide to using TraceSQL for trouble shooting.

TraceSQL is not normally invoked during processing so the fi rst step is to recreate the problem with TraceSQL invoked. For COBOL processes, this is normally set in the fi le which sets parameters for the Process Scheduler. The parameter name is TraceSQL with value set as desired according to the following:

TraceSQL is implemented as a bit map with the following values -1=SQL statements - 2=SQL statement variables - 4=SQL connect, disconnect, commit and rollback - 8=Row Fetch (indicates that it occurred, not data) - 16=All other API calls except SSBs - 32=Set Select Buffers (identifi es the attributes of columns to be selected. - 64=Database API specifi c calls -128=COBOL statement timings - 256=Sybase Bind information - 512=Sybase Fetch information

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 specifi c settings. Once you have the cobsql fi le -- 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 fi nd the point of the problem, note the cursor number -- for example #12.

Working your way on up in the fi le, 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.

Commit level – Diagnostic step 7To access the commit frequency for the payroll engine: Browse to ‘Set up HRMS’, select ‘Product Related’, then select ‘Global Payroll’ and then click ‘Installation Settings’.

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


Other payroll setups – Diagnostic step 8Having worked on most of the possible technical tuning options, if you do not see a considerable performance gain, it becomes essential to look for potential payroll setup improvements.

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 fi rst 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 fi elds - 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 fi nd 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 fi eld 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 fi rst reading before handing the array.


● Formulas Consider the following options:

(a) using variables with default values

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

● Generation Control versus Conditional Section LogicAs you know, generation control and conditional section logic are two of the various ways that you can control if an element is resolved for a payee. However, there is a big difference between generation control and conditional section logic. In fact, the conditional sections skip element resolutions. If you have PI for an element in a section and the condition is false, the element will not be resolved, so the PI will be ignored. The same concept is true for retro adjustments. Conversely, if you have a group of elements that you know should never be resolved except in a specifi c situation, such as a termination, it might make sense to use conditional section logic because it is easier and faster to bypass a subset of elements than to resolve generation control for each. If you are sure about your needs it is quicker to use a conditional section. But make sure that you understand the implications of conditional section logic before using it.

● Historical RulesBefore 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/CountsIf 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.

● Checking the Performance of Your RulesTo check the performance of your rules, select the Trace All option on the Payroll/Absence Run Control and execute your calculation.


After that you can utilize the SQL below to help analyze the performance of your rules.

DECLARE @CAL_RUN_ID VARCHAR (18)SET @CAL_RUN_ID = ‘KD%’SELECT A.CAL_RUN_ID, B.PIN_NM, B.PIN_TYPE, B.RECALC_IND, A.SUM_INSTANCE_IND “Call From Process”, COUNT(*) “Count Nb”, SUM (A.DIFF_SECONDS) “Delay in Second”, AVG (A.DIFF_ SECONDS) “Average “FROM PS_GP_AUDIT_TBL A, PS_GP_PIN BWHERE A.CAL_RUN_ID Like @CAL_RUN_ID and A.PIN_NUM = B.PIN_NUMand A.DIFF_SECONDS > 0GROUP BY A.CAL_RUN_ID, B.PIN_NM, B.PIN_TYPE, B.RECALC_IND, A.SUM_INSTANCE_INDORDER BY 1, 8 DESC

No. CAL_RUN_ID PIN_NM PIN_TYPE RECALC_IND Call From Process

Count No.

Delay in Second

Average

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

Fig 13 Payroll Engine – Performance of Payroll Rules

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 fi nd details on the sections mentioned above and also to fi nd information on ‘Methods for Reducing the Size of Result Tables’ and ‘List of Tables to Aid in Archiving Solutions’.


Summary & ConclusionPS payroll engine performance tuning is a vast subject with multiple nodes. Some of the nodes may not be applicable at a particular installation.

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 fi t solution 5. Fix and compare against the benchmark6. Freeze

The following would be an optimal task force for the tuning activities to guarantee success:1. Team lead/coordinator2. PS payroll business analyst3. PS payroll technical developer4. PS DBA5. Systems Engineer with server capacity, utilization insight

Also, identifying the loophole and applying the best fi t 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 12. Address the DB2 wait time – Diagnostic step 23. 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

ReferencesPS 8.3 Global Payroll PeopleBookOracle PeopleSoft website - http://www.peoplesoft.comhttp://www.db-consulting.com/

http://www.peoplesoft.com

http://www.db-consulting.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, modifi ed, 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.

Copyright © 2004-05 Tata Consultancy Services Limited

About PeopleSoft PracticeBuilding an internet-based real-time enterprise is a DREAM! Connecting and synergizing the enterprise, its internal systems with its customers, suppliers and business partners is a huge challenge.

The PeopleSoft practice at TCS helps organizations translate this dream into reality through PeopleSoft applications. The PeopleSoft Practice specializes in implementation, upgrade and production support services of PeopleSoft applications.

PeopleSoft Practice consists of more than 350 consultants addressing the needs of global customer base in verticals as Telecom, Pharmaceuticals, Banking, Financial Services / Insurance, Retail and Healthcare. The 350+ consultants in TCS PeopleSoft are spread across different geographies and they offer solutions focusing on Human Resource Management (HRMS), Financials, Supply Chain Management (FSCM) and Customer Relationship Management (CRM).

About Tata Consultancy ServicesTata Consultancy Services (TCS) is among the leading global information technology consulting, services and business process outsourcing organizations. Pioneer of the fl exible global delivery model for IT services that enables organizations to operate more effi ciently and produce more value, TCS focuses on delivering technology led business solutions to its international customers across varied industries.

For more information contactNatarajan SrinivasanTata Consultancy Services LimitedSJM Towers, No.18, Sheshadri Road, Gandhinagar, Bangalore - 600 009, Karnataka, India

Phone: +91-80-5660 6421Fax: +91-80-2220 7510

Email: [email protected] : www.tcs.com

mailto:[email protected]

http://www.tcs.com

Documents

PeopleSoft Global Payroll Performance