Random Notes on Development Tools

Draft Article Needs Editing

Maybe this is the start of comparing the different technologies used by PeopleSoft over the years.

SQR is nice because you can have nested SQL – that can run another SQL for each row returned by your first SQL – and can format the output as a PDF or CSV. But you can generally get similar results through SQL. Writing SQL is more straightforward than using PS Query if you know how to write SQL.

The Periodic Process is logical, at least to me. It performs a series of processing steps based directly on the configuration – starting with the Plan Implementation and working through each Function Result in order. It looks at the Function Result configuration, resolves the group definitions using the member’s data, and determines which, if any, definitions apply. There are 19 core pension functions, each with a different configuration page and a particular pension functionality purpose. Function Results are processed in the periodic Process, calculation, or both depending on the type.

Then we customize…getting a data value from the system is often configured as a database alias…but some customization may be implemented to get precisely what we want…often using views…sometimes modifying the program directly. Configuration may include the option to use a User Code method when a selected custom COBOL is executed. The COBOL talks with the database through stored SQL Statements – if we have the same primary inputs and outputs, we can modify the SQLs without changing the program directly – for example, get data from a custom table instead of JOB. Finally, there are many COBOL code changes to fix bugs, add functionality, implement specific rules, workaround bad data, keep different plans from colliding, etc.

PeopleBooks explains what the application can do. The configuration directs the path through the programs. The code and customizations of the Process generate the results.

The Stored Statements hold the story of what tables the data comes from and what tables get updated as a result.

The application trace output for a process can describe in words what is happening as the Process runs, and a SQL trace can show what SQL commands are being executed as the Process runs. For App Engine, we can also get a PeopleCode Trace showing what PeopleCode was performed as the Process runs.

All these development tools string together SQL and let you act on the data in between. SQR and COBOL typically run through steps for each EMPLID, but App Engine can be designed slightly differently. It may perform a SQL on the whole population to update a value or populate a temporary table; some PeopleCode might be performed for each row and then back to updating the entire population with another SQL. App Engine may string together PeopleCode code, Views, SQL Objects, SQL text, Application Packages (object-oriented PeopleCode), and BI Publisher calls.