In episode #120 of the PeopleSoft Administrator Podcast, there is a discussion on the deltas in the PTEM_CONFIG App Package from 8.55 to 8.56. In 8.56 there appears to be a ton of delivered ACM Plugin App Classes, but as Dan explains, these App Classes are completely empty. This is a major tease because there are some really interesting ACM Plugin App Class names such as PTScriptExecutor and PTWebServerConfigUpdate that have no implementation code in 8.56.
I am finally starting to get up to speed with Automated Configuration Management (ACM) Plugins. ACM is something that the guys over at psadmin.io have been talking about for some time now and I think this is a great new PeopleTools functionality. I have experienced an unfortanute limitation around the allowed character length of the input configuration properties for the some of the ACM plugins that I am currently working on. It turns out that the input configuration properties for ACM plugins are limited to a measly 254 characters. This is a problem for plugins that require lengthy configuration properties. For the plugins that I am creating, I wanted a way to easily create and mange plugin configuration properties without having any character length constraints.
What in the world is the Portal Custodian? I asked myself this very question when I came across a delivered file named portalCustion.xml on the PeopleSoft web server. The Portal Custodian is an undocumented functionality that allows for regular expression pattern matching replacements on the portal content served by the web server. The portal content is the “wrapper” that the psp servlet puts around the page content. This means that we have the ability to modify the contents within the portal header and footer before the client receives the response from the web server. I discovered and tested this functionality in a PeopleSoft application running PeopleTools 8.56, but it is quite likely that this feature exists in older Tools releases. In this post, I will walk through how we can use this interesting feature to manipulate response data.
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 a member of the psadmin.io community. They explained how they have defined their 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. This tutorial was done using CS PUM image 1 and it is likely that the deployment steps will change in future PUM images.