A while back I presented a solution to manage configuration data on the web server. This solution involved a servlet-based cache managing utility that was responsible for the storage and caching of data to the PeopleSoft web server. I have been experimenting with ways that I can get custom data cached to the PeopleSoft web server without being so intrusive to the web-tier. I recently came across the PT_METADATA app package which can be used to create object types such as HTML, Style Sheet, and Images. These object types are nice because they are PeopleTools-managed and they have the flexibility to store custom data expressed in any form. Another great perk of these object types is that they can be cached to the web server using the %Response class. I am going to demonstrate a technique that I use to get PeopleTools to manage and cache my custom data.
Some of the servlet filters that I have previously demonstrated make use of configuration data that originates from the PeopleSoft application. This configuration data consists of things like which fields to mask and what components to restrict access to. This data is ultimately what controls how the servlet filters behave. In this post, I would like to discuss how I go about communicating configuration data from the PeopleSoft application to the web server and the techniques that I use to manage this data. First I will go over the design, installation, and use of a caching utility that I wrote to manage the configuration data. Last I will discuss how I integrate my servlet filters and PeopleSoft application with this solution.
I recently discovered a good piece of information provided by Nate Werner on the psadmin.io community. He explained how he has defined his own custom properties on the web profile in PeopleSoft. I always thought that the custom property names had to be predefined under the hood by Oracle in order for you to make use of them. It turns out that this is not the case. You can define your own custom properties on the web profile so that you can use them as meta-variables anywhere on the web server. This becomes very useful for getting rid of hard-coded values that might exist on the static html pages on the web server. I will demonstrate how this can be done.
This is the step-by-step process that I took to install the Campus Solutions 9.2 application to a Windows operating system using the Native OS deployment package (DPK). Using the DPK to deploy the environment took several failed attempts before I was able to get it working properly. So I decide to document what worked for me.