Managing Your PeopleSoft Customizations

Managing Your PeopleSoft Customizations

With the latest PeopleSoft 9.2 applications, we now have a true pick-and-choose interface, where all dependencies are managed for us, and a true “custom” change package can be built. If I were running 9.2 GA, and needed a fix from PUM Image 16, I would simply choose that fix, and any requisite code is built into my change package.  While this is a phenomenal leap in our ability to rapidly apply either specific or bulk changes in code, there is one very important item that often is not discussed.  Customizations.

I think back to my first “patching” project for PeopleSoft.  For those of us who have been there, it consisted of a significant amount of research on Customer Connection to verify that all of the appropriate pre/post-requisites were being applied and in the correct order.  This was true not only for a single module, but there were also cross module dependencies.  Over the years PeopleSoft has improved on this process by including the requisites within Change Manager.

When applying any sort of maintenance in pre-9.2 applications (bug/fix, bundles, all the way through Maintenance Packs) we needed to be conscious of the customizations which have been applied into the system.  Overlaying these customizations meant that a team of developers would need to evaluate what changed in the new version of the code and determine what would need to be done to “retrofit” these customizations.  This often meant significant hours needing to be added to the “patching” effort, and often would cause the decision to be made to not apply or to defer to be an “annual maintenance project” or something similar.  This does not change with the 9.2 Continuous Delivery model!

As we are looking to upgrade to 9.2, one of the areas which I think demands the most attention is how to manage customizations.  Of course we have heard for years that the best thing to do is to keep PeopleSoft “Vanilla” but I can tell you from my experiences, this is far from the truth for most organizations.  What we have found is that many of the customizations we encounter can be implemented in a less invasive manner.

Before going into the details I would first like to define a “customization.”  In its simplest terms, a “customization” is a change to an object originally delivered by Oracle.  There is another type of change to the system that I often hear grouped in with customization, where a customer will create their own net-new code.  For the purposes of this article, I will term those as “bolt-ons” to the system.

As the PeopleTools versions have improved, so have our options for minimizing customizations.  Even in early 8.4 versions of PeopleTools, a need was recognized for allowing users to create Translate values (via a PIA navigation) to avoid stamping a delivered field as customized.  But what about true changes to the look and feel of the application, or changes to how data is displayed?

Starting with 8.50, PeopleSoft provides the ability to add Related Content into a new frame on most any page or component, without making a modification to that underlying PeopleSoft object.  This content can be a component, PS Query, OBIEE analytic, and even non-PeopleSoft data, and can use key information from the underlying component to drive what is displayed.  An example of this would be to add a query showing the sum of spend on all purchase orders onto the Vendor/Supplier component.  This could easily replace a previous customization which calculated the spend and displayed it into a work field on the Vendor component.  As the Vendor component is re-delivered in future software releases, no modifications need to be re-applied since this is a “bolt-on” using Related Content Service.

While Related Content Service is great for displaying information, many of our customizations are more logic based requiring the use of adding PeopleCode.  Good news in 8.55, as Oracle has added Application Class as a Related Content Service definition, which means we can now insert code to fire on a component, without actually modifying that component!  There are some limitations to what can be done (the Related Content Framework PeopleBook covers much of this) and it is specific to the component, so if you have custom code you wish to have fire on multiple components it would mean registering this many times over, instead of making one record PeopleCode modification.

Add Comment

Your email address will not be published. Required fields are marked *