PeopleTools 8.54 Feature: Application Engine Trace File Enhancements

In this blog, we have been reviewing the new features of PeopleTools 8.54. Today is the turn of Application Engine, particularly on its troubleshooting. This release of PeopleTools include several enhancements on Application Engine tracing, which are outlined below:

• The .AET trace file can now include the PeopleCode trace. This removes the need of checking the .AET file for the the non-PeopleCode steps and the .TRC file for the PeopleCode steps. Surely, .TRC files could also contain the SQL executed in non-PeopleCode steps if needed, but it was significantly more difficult to read as the SQL statements were not formatted.

This new feature is enabled by setting the TraceAECombineOutput parameter in the server configuration file for Application Server or Process Scheduler Server.

TraceAECombineOutput=Y

• You can set the file size of the Application Engine Trace file. This way, if the trace file exceeds the threshold, it splits into a different file. For certain processes, this could be quite handy, as sometimes the trace sizes become unmanageable.

This new feature is enabled by setting the AETFileSize parameter in the server configuration file for Application Server or Process Scheduler Server. The size is measured in Megabytes.

AETFileSize=20

• You can actually select which sections of an Application Engine program should be traced and which not. This can contribute to reduce unneeded trace information, just focusing on the potential error areas.

This new feature is enabled by setting the TraceAEEnableSection parameter in the server configuration file for Application Server or Process Scheduler Server.

TraceAEEnableSection=Y

Then, using Application Designed, you should mark the sections you want to trace. Keep in mind that by default all sections are unmarked:

In order to enable the flag in Application Designer, the Enable Section Trace(g) setting has to be enabled in Configuration Manager:

Note: As far as I can tell, you can only set this flag when you create a new section. If you need to modify an existing one, you would need to copy and paste, and then remove the original one. Have any of you found a more efficient way of setting the flag?

• The Application Engine Trace file name now includes the Date/Time stamp.

These enhancements should simplify troubleshooting of Application Engine program issues, particularly those ones containing a significant amount of PeopleCode processing or generating very large trace files.

The new %SelectDummyTable MetaSQL

Does anyone know a PeopleSoft developer who didn't ever use a SQL statement like the following one?

select %CurrentDateOut
from PS_INSTALLATION;

Where PS_INSTALLATION could be any single-row table in the PeopleSoft data model.

If you look at the previous statement, the SELECT clause is not retrieving any field from the PS_INSTALLATION table, but just using it to comply with ANSI SQL. The same statement could be written in Microsoft SQL Server like this:

select %CurrentDateOut;

In Oracle Database, as:

select %CurrentDateOut
from dual;

In both cases, the sentences are a better performing option. Both solutions do not require accessing any physical table.

The problem with these solutions is that they are platform specific, and we want to avoid platform specific syntax. Believe me, when you perform a platform migration you suddenly have very present in your mind the ancestors of the programmers who used this type of syntax. So, up to now, we had to stick with the SELECT ... FROM PS_INSTALLATION solution.

Until now. PeopleTools 8.54 introduces a new MetaSQL name %SelectDummyTable, which automatically translates into a platform specific sentences. Our previous sample would be written as:

select %CurrentDateOut
from %SelectDummyTable

We now have a platform independent and well performing solution. What else can we ask for? ;-)

Note: I've checked the online PeopleBooks from Oracle and at this point there is no documentation on this Meta SQL. Still, I've conducted some tests and it seems to be working correctly.

Using Global Temporary Tables in Application Engine

One of the new PeopleTools 8.54 features that went probably a bit unnoticed amidst the excitement on the new Fluid interface is the ability of Application Engine programs to take advantage of Global Temporary Tables (GTTs) when using an Oracle Database.

What are GTTs?

The Global Temporary Tables were introduced by Oracle already on the 8i version of its database product. These tables are session specific, meaning that the data inserted in them only lasts until the session is closed (in Oracle Database there is the possibility of using them only until the next commit, but that option is not used by PeopleSoft). The data inserted in the table by each session is not seen by other sessions. In other words, it is a very similar behavior to Application Engine Temporary Tables. The benefit of using a database supported solution rather the traditional temporary tables is better performance, since GTTs are optimized for temporary data.

How is it implemented in PeopleTools?

The implementation in PeopleTools is quite simple. When selecting Temporary Table as the record type, a new option is enabled: "Global Temporary Table (GTT)".

The build SQL generated by PeopleTools is slightly different to traditional tables:

CREATE GLOBAL TEMPORARY TABLE PS_BN_JOB_WRK (PROCESS_INSTANCE

 DECIMAL(10) NOT NULL,

   EMPLID VARCHAR2(11) NOT NULL,

   EMPL_RCD SMALLINT NOT NULL,

   EFFDT DATE,

   EFFSEQ SMALLINT NOT NULL,

   EMPL_STATUS VARCHAR2(1) NOT NULL) ON COMMIT PRESERVE ROWS

 TABLESPACE BNAPP

/

Note: The SQL Build process still creates as many instances of the table as it did with traditional temporary tables. This sounds like a bug to me, as my guess is that the whole idea of using GTTs is to be able to share a table without actually sharing the data, but I may be wrong. In any case, it does not do any harm. Any insight on this? 

Constraints

Due to specific characteristics of GTTs, there are some limitations regarding when they can be used:

• If the Application Engine is run in online mode, then the GTTs cannot be shared between different programs on the same run.
• You cannot use Restart Enabled with GTTs as the data is deleted when the session ends. In its current version, PeopleBooks state otherwise, but I think it is a typo.
• %UpdateStats are not supported. Before Oracle Database 12c, if the statistics would be shared among all the sessions. Oracle Database 12c also supports session specific statistics, which would be the desired behavior in PeopleSoft (from a higher level point of view, programmers are expecting the temporary table to be dedicated to the instance). I guess the %UpdateStats is not supported because Oracle Database 11g is still supported by PeopleTools 8.54 and in that case running statistics would generate unexpected results. Still, the DBA can run statistics outside of the Application Engine program.

Note: As learnt from Oracle OpenWorld 2014, Oracle is evaluating supporting of Oracle Database 12c session specific statistics for GTT’s in a future releases of PeopleTools.

Conclusion

If you are moving to PeopleTools 8.54 and you want to improve the performance of a given Application Engine program, the GTTs may bring good value to your implementation. Please remember that you need to be using an Oracle Database.