When developing custom or extended functionality in PeopleSoft it is useful to consider invoking Java objects to supplement functionality available in PeopleCode.

PeopleSoft applications are able to invoke static and non-static objects (with some limitations) natively through PeopleCode. There are some nuances and subtleties that require work arounds or wrapper classes — for instance, it is not easy to cast objects when using Java through PeopleCode — but for the most part Java works well with PeopleCode.

There are however certain architectural limitations that require careful design up front when developing more complex Java-integrated solutions.

Standard Java application deployments employ levels of object persistence that have scope for duration of the application itself. An easy example of this is a connection pooling object that is started when the Java application server is started and is accessible until the application server is shutdown. In other words, objects/variables of this nature are said to have application scope.

In general, one could describe the types of variable scope available in PeopleSoft according to the following (in increasing life-span):

• Function/Local – Local variables are available only within the function and are inaccessible outside of the function. In PeopleCode we declare these as Local.
• Class – Class variables are available within any function within a class and may or may not be accessible outside the class (nuances of this are not relevant to this discussion). Usage of these in PeopleSoft are implicit in the context of Application Classes and there is no explicit Class declaration.
• Component – Component variables are declared as Component and are available so long as a user remains within a component. Once the user leaves the component the variable/object is destroyed.
• Global – Variables declared as Global are available so long as a user session is active until a user logs out. Global variables are NOT shared between other users.

There is no level of variable scope beyond Global. In other words, there is no way to declare a variable that has a life time BEYOND a user’s session and/or that is accessible amongst multiple users.

The simple reason behind this is that PeopleSoft employs a stateless set of server processes to process user activity.

First, a quick primer on the PeopleSoft Application Server.

The PeopleSoft Application Server is actually a set of worker processes that perform different functions. These functions are stateless (meaning they don’t store any data). The reason for this is simple — an application designed around a stateless pool of processes is one way to approach highly-available, fault-tolerant design. If a user is working on one application server and that application server dies (or one of the worker processes dies), the user can easily be routed to another application server (or worker process) and things continue without a hitch.

These application server processes are managed through a central “daemon” call the BBL. Without going into detail, the BBL dictates when each application server process starts, restarts, shuts-down and garbage-collects (aka recycles). The server process that brokers the user interaction with a component — the Component Processor – is called the PSAPPSRV process.

So where does a user’s session lie? It is actually the web server that stores all the different user session variables. Every time a user visits a page the data in the user’s session is compared against the data in the database. Inconsistencies lead to the dreaded “Data inconsistent” error message. This is why a user can lose their connection to an application server but can NOT lose their connection to a web server.

Going back to our original discussion, whenever PeopleSoft encounters PeopleCode that calls a Java object, the application server instantiates a JVM process [note: if you are not familiar with "JVM" you need to go back and review the Java runtime model]. Simply, the PSAPPSRV that encounters the Java call will instantiate a JVM. The life of the JVM depends on the life of the PSAPPSRV process which, as we discussed earlier, is at the whim of the BBL.

Where does this leave us? For starters, Java objects have an unpredictable lifespan as the JVM can be destroyed on an ad hoc basis (as viewed from the JVM). In other words, as developers we cannot rely on a scope of a Java object beyond the current PeopleCode being executed. Java objects also cannot be shared amongst users as there is no way for one PSAPPSRV process to access the JVM of another PSAPPSRV process.

In other words, PeopleSoft lacks variables of application scope.

This has several consequences as many useful Java packages (I use the term loosely) rely on application-level persistence to function. Going back to the connection pooling example, if PeopleCode were to call a connection pooling object that object would be created and destroyed EVERYTIME the code was run, thereby negating the benefits of connection pooling. To illustrate:

1. The Component Processor (PSAPPSRV) encounters PeopleCode which calls Java.
2. PSAPPSRV instantiates a JVM.
3. The JVM creates the connection pooling object.
4. Code executes which uses the connection pool.
5. The code completes and the connection pooling object is destroyed (and for all intents and purposes unavailable).
6. The JVM is not necessarily terminated.

Compare this to a typical Java application server scenario:

1. The Java application is started.
2. The connection pooling object is instantiated.
3. Repeated calls to the application make use of the single, shared connection pooling object.
4. The Java application is shutdown sometime in the future (for maintenance, etc) and at that time the connection pooling object is destroyed.

Obviously the use case described here is quite specific but the limitations revealed herein need to be understood before designing any complex Java-based solution for PeopleSoft. One concrete example is trying to use PeopleSoft to call OpenOffice’s document conversion facility (an exercise which is left to the reader — I hated these in University…).

BTW — Anyone who wishes to deploy a turnkey PeopleSoft integrated document conversion solution (i.e. for converting eRecruit/Candidate Gateway resumes from one format to another) are invited to contact Attain Solutions as they offer such a product.