PeopleSoft Selective Adoption is both a huge change and opportunity for PeopleSoft customers. Another video in the PeopleSoft Spotlight Series outlined important elements of how PeopleSoft works now with Selective Adoption and how customers should adopt to take advantage of the new delivery model.

There are several tools associated with Selective Adoption, which were discussed in the “PeopleSoft Spotlight Series: Selecting and Applying Maintenance Best Practices and Recommendations” video. This video talked through how to work with PeopleSoft Updates Images, important concepts for keeping your system updated and as current as possible, and how to apply change and determine the impact that it may have on your system. It also explained how some changes are dependent on others and how to deal with those interdependencies.

Selective Adoption represents a new way for your IT and business units to work together in order to be as responsive to and proactively meet the needs of your users. There are so many tools and resources available to you to help you embrace and adopt the changes and innovations that your users will find most valuable, select those features and determine all of their interdependencies, and test and apply those changes to your PeopleSoft system.

There are significant changes in the maintenance process as a result of Selective Adoption. PeopleSoft changed the way that maintenance is delivered, and it’s ultimately for the better. However, it will result in a change in the way you maintain your PeopleSoft applications. In some cases, you’ve been maintaining applications with processes that have been in place for many years, but with these changes, there are a lot of new opportunities.

This episode in the PeopleSoft Spotlight Series will cover the following topics:

• Working with a PeopleSoft Update Image (PI)
• Update vs. PeopleSoft Upgrade process
• What environments should be maintained
• How to apply a PeopleSoft Release Patchset (PRP)
• Language updates
• Guidelines for applying maintenance and features
• Understanding dependencies
• Understanding PeopleTools releases and patches
• Additional information

Working With a PeopleSoft Update Image (PI)

The first thing that you need to know about a PeopleSoft Update Image is what it is and where to find one. PIs are found on My Oracle Support. The easiest way to find one is to start on the PeopleSoft Update Manager homepage in MOS and follow the link for your pillar. The Doc ID for the PeopleSoft Update Manager homepage is 1641843.2, and it can also be found through the PeopleSoft Information Portal at www.peoplesoftinfo.com.

A PI is a fully operational, running PeopleSoft system that runs as a virtual instance in Oracle’s VirtualBox. It has a database middle tier, which is the App Server and Web Server, and complete copies of all supported versions of PeopleTools and lifecycle utilities like Change Assistant. The PeopleSoft Update Image found on My Oracle Support is the most current version of an application.

There is also a new way of referring to PeopleSoft version numbers. Technically, each PeopleSoft Update Image is a new version. When referring to one, it is called 9.2 PI, which stands for PeopleSoft Update Image. Then the version number, which is written as a three-digit number, follows. For example, HCM version 9.2 update Image 009 is simply referred to as HCM PI 9.

It’s important to remember that releases are cumulative, so each PI includes everything that was released in the previous Images. In most cases, an Image will also be running the most current version of PeopleTools. However, since Tools versions are released outside of PeopleSoft Update Images, there might be a newer release or patch of PeopleTools that is not in the Image.

Once an Image is up and running in your environment, it can be used for many things, including:

• Selecting maintenance and enhancements for updates
• New feature demonstrations
• Conference room prototypes
• Recreating incidents on vanilla releases

There are a few key takeaways to remember about PeopleSoft Updates Images:

• COBOL is not compiled, and there is no COBOL license.
• This is an English-only instance that runs with the Oracle database. Language data is kept in files and is not available until applied.
• Both maintenance and new enhancements are included in Images.
• Images are cumulative, so each Image also contains everything from previous Images.

The video also walked through maintenance best practices for working with a PeopleSoft Update Image:

• Download new Images when they are made available.
• Don’t keep old Images around. Images are cumulative, so there is no need to.
• Follow the instructions in Using the PeopleSoft VirtualBox Images when downloading and installing an Image.
  • Go to the PeopleSoft Update Manager homepage (Doc ID 1641843.2).
  • Choose your application homepage (HCM, FSCM, etc.).
  • Select the Installation Documentation section.
  • Download Using the PeopleSoft VirtualBox Images PT 8.54.05 or Higher or updated version of the installation document.

PeopleSoft Update Images are a valuable resource that you can take advantage of at any time. You have the latest version of an application without the overhead of going to the systems team to create a new environment.

Update vs. Upgrade

It’s important to understand the differences between an update and an upgrade. They are two different processes and should be thought of differently.

An upgrade is a major release that involves moving from an older version of PeopleSoft to a newer one. For example, you would upgrade from PeopleSoft 9.1 to 9.2. You would need to use a certified Upgrade Source Image as the starting point for an upgrade. Not every PI is an Upgrade Image Source. You could also use the source database delivered on OSDC.

The PeopleSoft upgrade process looks like this:

• Upgrade to the latest certified upgrade release.
• Do a “get me current” to the latest PeopleSoft Update Image (PI).
• Apply ongoing maintenance and features going forward.

Each product team delivers certified upgrade paths at different intervals. Once you have upgraded to PeopleSoft 9.2, there are no more upgrades. All maintenance from that point on is done through updates, not upgrades.

An update takes place when you apply maintenance or new features to an existing PeopleSoft 9.2 application. They are done once the application is PeopleSoft Update Manager (PUM) enabled. Use a PeopleSoft Update Image to search for and select maintenance and new features. Maintenance should be performed regularly throughout the lift of the product.

There are many different maintenance strategies, but Oracle recommends the following maintenance best practices for getting current:

• Do not go more than two years without getting current.
• Stagger different products so a get current is not done on the entire product line.
• Products that are not used do not have to be maintained.
• Delaying maintenance may affect your ability to select and apply updates and features.

Each product team delivers PIs at different times and intervals. Check out the PUM homepage for planned delivery schedules.

What Environments Should Be Maintained

Every customer should maintain several different PeopleSoft environments. In the past, you may have heard the suggestion to use the update Image as the demo environment. That’s still the case. Oracle recommends having five available PeopleSoft environments for each product that you run.

The first environment is the PeopleSoft Update Image (PI). You should download new versions when available and keep it around until the next available version is posted.

DEV, TEST, and PROD environments should be maintained the way they always have been. DEV is the environment where the initial change package is applied and where customizations are made. From DEV, changes are migrated to a TEST environment for regression testing. Typically, there’s a bit of back and forth between the two. Finally, the changes are propagated to the PROD environment. It’s common for DEV and TEST to have copies of PROD data with sensitive fields masked for security reasons.

Oracle also recommends keeping a DEMO environment. The DEMO environment does not have any customizations. It only consists of the base 9.2 system with all maintenance and features from PeopleSoft that have been applied to PROD. It’s essentially the PROD system with no customizations. You create it by taking a generic copy of the Upgrade Source Image or the Source Database at upgrade time. You then keep it current by applying the same change package that’s applied to the DEV environment. Remember, it wants to match the maintenance in your PROD system, so don’t apply the change package until you update PROD.

In the end, there are two different PeopleSoft-only environments—one that is fully patched and current and the second that is only maintenance and features applied in your system. What are the benefits of keeping all of these systems? Keeping these environments up and available makes it easier to find the source of a bug. When you come across a bug, it could be in PeopleSoft core product, could be the result of a customization, or could be from not taking enough maintenance from PeopleSoft.

To determine if a discovered bug is the result of customization or is in the delivered system, follow these maintenance best practices:

• Use the PI to see if the problem exists in the latest version of PeopleSoft with all maintenance applied.
• Use DEMO to see if enough maintenance has been applied to fix the problem. This can help narrow the problem to customization or incomplete maintenance.

Having five environments available will help you track down the incident to the source.

How to Apply a PeopleSoft Release Patchset (PRP)

A PeopleSoft Release Patchset is a system fix that is delivered outside of a PeopleSoft Update Image. They are used to deliver critical fixes to you in between update Images. A PRP should not be applied directly to your system because there may be dependencies for objects that are delivered in the PRP that need to be applied in your environment prior to the PRP.

With Selective Adoption, the source system may be in a state where partial maintenance has been applied and in order to successfully apply a PRP, additional dependencies must be brought in. There’s a simple, standard way to do this—by letting the dependencies be calculated with the latest update Image. The Image to use will be in the instructions for the PRP.

To apply a PeopleSoft Release Patchset (PRP), you must follow the directions provided by Oracle Support. The following steps are suggested maintenance best practices for applying a PRP:

• Apply the updates to the most current PI, not directly to your environment.
• Use the PeopleSoft Update Manager (PUM) application to find and select the update.
  • PUM will include any relevant dependencies.
• Generate a change package definition that includes your changes.

A Proof of Concept (POC) patch is different. They are usually created just for you and should be applied directly to your environment. They are considered to be done outside of the standard PeopleSoft maintenance process. It’s best to think of them as a customization.

Language Updates

The application running in the update Image is always English, but you can use it to apply language updates. Language updates are delivered as files and are either included in the update Image or in a subsequent update Image. All language data is loaded based on the language that you selected in your target environment. If you run more than one system with different languages, you must have a PI for each different system. This allows customers to apply critical program fixes in the base language and adding non-critical language components in a later release.

There is a search option in the PeopleSoft Update Manager PIA application to add the multilingual updates to your system based on the languages in the target environment. When you first configure the update Image, it will automatically load the required languages based on the language selection in the target environment. You can use the PeopleSoft Update Manager PIA application to search for and catch up on multilingual updates that should be applied in your environment.

Guidelines for Applying Maintenance and Features

The recommended process for applying maintenance and features is the same. Maintenance best practices for doing so include:

• Have all environments deployed and ready for maintenance.
• Download and set up the latest Update Image.
• Configuring EMF is an optional step that you can do to help distribute files.
• Configure Change Assistant using the current PI as the source and DEV as the target.
  • Change Assistant will synchronize the maintenance history in the PI.
• Select maintenance using the PUM PIA application and create a change package definition.
• Use Change Assistant initial pass to apply the update to DEV.
• Compare, merge, and retrofit customizations in DEV.
• Use the Change Assistant Upgrade Compare process to create a modified version of the change package in DEV that includes customizations.
• Perform a test application of the new change package using DEV as the source and TEST as the target.
• Test the changes in the TEST environment. For best results, use the PeopleSoft Test Framework as the automated testing tool.
• Use the change package created for the TEST application pass to apply changes to your PROD environment.
• Apply the initial change package that was originally used to update DEV to the DEMO environment.

Understanding Dependencies

Dependencies are a very misunderstood part of the new Selective Adoption maintenance process. The concept of dependencies is actually pretty simple. If more than one bug changes the same PeopleTools object, such as a record, PeopleCode program, or page component, then the two bugs are dependent on each other. If two bugs are dependent on each other, you must apply both bugs in order to get one of them to work. Add to that the fact that a single bug could be fixed by changing several PeopleTools objects and you can see how dependencies can expand rapidly. Dependencies are calculated for each bug you select and may include bugs from more current PIs.

The second important note is that there is no version control in the delivered Images. There is no copy of what the system looked like for a certain PI. Every PI has only one version. Therefore, dependencies work in two directions:

1. Prerequisite dependencies: Dependencies on bugs that were in the system prior to the bug that you chose was added.
2. Post-requisite dependencies: Dependencies that are introduced in later releases.

The type of the dependency depends on the time that fixes are added to the system. Anytime a bug is selected to be applied, the system is asked for two things first:

1. All of the bugs that you are dependent on
2. All of the bugs that are dependent on you

For each of the bugs that are returned, you go through the same process. Think of it as a recursive process. However, there’s a slight exception because any bug that shows up in the list as having already been applied is pulled out. No additional dependencies are necessary.

There is only a single version included in each PI, so dependencies may include bugs from more current PIs. Some helpful maintenance best practices to follow when handling dependencies include:

• Setting an Image number in the search criteria to return bugs based on the Image number but may include dependencies from more recent Images.
• Never mix and match or go backwards when applying maintenance and new features. That is not supported.

Understanding PeopleTools Releases and Patches

The first important note is that your environment should be running a supported version of PeopleTools. If your PeopleTools version is out of support, the update process might not work. A quick review of the PeopleTools Support Policy shows that a version of PeopleTools is supported for 12 months after the more current version is released and is then supported for an additional 12 months for critical errors. This is known as the “Next Release + 12 + 12.”

It’s very unlikely that the release of PeopleTools that you’re using is different than the PeopleTools in the Update Image. For example, you may be on PeopleTools 8.53 while the current Update Image is running PeopleTools 8.54. Don’t worry, that’s okay and is expected. To compound the problem, each PeopleTools release will have a number of PeopleTools patches. So, even if you are on the same PeopleTools release as the Update Image, you could be on a different patch.

PeopleSoft is constantly fixing issues with PeopleTools, and some of the issues that are fixed may have to do with the update process. Instead of requiring you to upgrade or pass your PeopleTools version in order to apply maintenance, PeopleSoft delivers complete PeopleTools versions in the Update Image that’s used exclusively for the maintenance process.

When you’re configuring Change Assistant, make sure you use the version of PeopleTools that was delivered in the Update Image rather than your local version. This will ensure that you are using the latest version that has been certified to run the update process properly. For example, if your application is on PeopleTools 8.53, use the PeopleTools 8.53 version that is included in the Update Image. Similarly, if you are running PeopleTools 8.54, use the 8.54 version delivered in the PI.

Some maintenance best practices to keep in mind when handling PeopleTools releases and patches include:

• A PeopleSoft Update Image (PI) comes with multiple versions of PeopleTools.
  • The most current version of PeopleTools runs with the PIA application.
  • All supported versions of PeopleTools are delivered with each PI.
  • The version of PeopleTools delivered with each PI will be the latest patch.
• Always use the versions of PeopleTools delivered with the PI as the target PeopleTools version when applying maintenance and new features.

Knowing how PeopleTools releases are used and pointing to the proper PeopleTools version is an important step that can make your updates go smoothly without requiring PeopleTools version or patch upgrades.

Additional Information

There are so many helpful tools and documents that can provide you with a better understanding of Selective Adoption, PeopleTools, and other aspects of maintenance best practices. Check out some of these helpful resources for more information:

• PeopleSoft Online Help – PeopleSoft PeopleTools 8.54
  • Change Assistant and Update Manager
• PeopleSoft Update Manager (PUM) homepage
• PeopleSoft upgrade training on Oracle Learning Library
• Oracle University Training
  • PeopleSoft Lifecycle Management Rel 8.43 (4-day course)
  • PeopleSoft Update Manager Rel 8.54 (2-day course)
  • PeopleSoft Lifecycle Management & Update Manager Accelerated (5-day course)