CHAPTER
13
Upgrade Tips and Techniques
ince you are reading this book, you or someone you know has probably been through an enterprise software implementation. It is no secret that software implementations are difficult. You don’t have to look far to find tombstones in the software implementation graveyard!Upgrades are difficult as well. In a sense, an upgrade is a microreimplementation. Upgrades provide an organization the opportunity to change the way they do business or make another pass at aligning software with internal business processes. The way your organization does business should be part of its strategic advantage. You want your software to move your organization toward that strategic advantage.
When you know the location of a dangerous section of road, you can act accordingly. This chapter is full of warning signs. We mark the hazardous sections of the upgrade road map, and, whenever possible, point out an alternative, shorter route.
From the Oracle Support web site, a customer can download a 300-page upgrade guide containing step-by-step instructions for performing an application- and version-specific upgrade. Although the high-level steps involved in an upgrade remain the same across PeopleSoft applications, upgrade details and complexity differ widely. For example, the “Human Capital Management (HCM) 9.0 to 9.1” upgrade guide contains nearly 400 pages, whereas the Enterprise Portal upgrade guide is about 300 pages. Not only do upgrade steps differ by application, but also by version. The steps required to upgrade an HCM 8.9 system to 9.1 differ from those required to upgrade HCM 9.0 to 9.1. Because PeopleSoft installations vary widely among customers, it is impossible to write a standard, “one size fits all” upgrade guide. Given the number of hardware and software configurations available to a customer, it would be difficult to identify a “standard” installation.
Using this chapter to detail all of the steps required for an upgrade would be akin to software malpractice. A complete upgrade reference manual could easily fill 800 pages. Rather than attempt to document every possible step based on an ever-changing and unknown environment, this chapter highlights some tips to help you perform a successful upgrade.
Planning the Upgrade
Your upgrade will be about as unique as your fingerprint. Each customer implements PeopleSoft a little differently. One customer may use Microsoft’s SQL Server on 32-bit Windows, whereas another may implement the same PeopleSoft application on DB2 UDB for z/OS. In this section, you will learn about important considerations for planning an upgrade.
Upgrade Types
PeopleSoft customers perform two types of upgrades: PeopleTools upgrades and application upgrades.
PeopleTools Upgrade
A PeopleTools upgrade is usually easier than an application upgrade. PeopleTools upgrades rarely change the application’s appearance or behavior. This is because PeopleTools upgrades include new features, but no physical implementations of those features. It is entirely possible to upgrade PeopleTools without functional users even noticing the change. Likewise, PeopleTools upgrades are simpler because they rarely touch customer-modified definitions, so there is little customization rework. Because PeopleTools upgrades do not change application behavior, testing requirements are minimal in comparison to an application upgrade.
A PeopleTools upgrade can become complex if the upgrade requires architecture changes, such as 32-bit to 64-bit migration, operating system upgrades, and so on. For example, migrating a database from 32-bit to 64-bit hardware may require a full database export and import.
I prefer small, incremental adjustments over dramatic changes. It is easier to identify the cause of a new error when you’re making small changes. Furthermore, small changes usually require shorter system outages. The more you attempt to accomplish within an outage window, the less margin available for error.
Stay current with PeopleTools and system infrastructure. With all prerequisites met, an administrator can easily apply a PeopleTools upgrade over a weekend.
Application Upgrade
An application upgrade is a lot more complicated than a PeopleTools upgrade. Application upgrades often include changes to existing business processes as well as the addition of new business processes. These changes require a significant amount of functional testing and end user change management.
Application upgrades are further complicated by the fact that they usually require PeopleTools upgrades. PeopleSoft applications always require a minimum PeopleTools version—usually the version released closest to the application’s release date. This is because new application features require PeopleTools enhancements. For example, Human Capital Management (HCM) 9.1 Feature Pack 2 included new operational dashboards. HCM 9.1 Feature Pack 2 required a minimum PeopleTools version of 8.52 because prior versions of PeopleTools did not include the features necessary to build those dashboards, specifically header pagelets and pagelet icons. When planning an application upgrade, ensure that your PeopleTools release is certified for the target application release. If it isn’t certified, you will need to include a PeopleTools upgrade in your application upgrade plan.
Upgrade Timeframe
The amount of time required for an upgrade varies widely by customer. I upgraded an HCM 9.0 application that was running PeopleTools 8.49 to HCM 9.1 FP2 running PeopleTools 8.52.06 over a weekend. I performed this upgrade against a small, vanilla HCM system requiring no hardware changes. The average HCM upgrade, however, requires six to nine months. The Financial/Supply Change Management upgrade averages nine to twelve months. The following factors influence the time required for an upgrade:
■ Amount of data to convert
■ Number of customizations to merge into the upgrade
■ Number and complexity of integrations
■ Availability of resources (testing, development, and so on)
■ Training and documentation (organization change management)
■ Patching and maintenance cycles during the upgrade
■ Multipass migration requirements
■ Software prerequisites
■ Hardware changes
Let’s review each of these factors in detail.
Amount of Data to Convert
Application upgrades often include data conversion routines. The larger your data set, the longer these routines run. Through hardware and SQL tuning, you may be able to shorten conversion runtime, but the amount of time spent optimizing the conversion will likely be greater than the amount of time gained from the optimization. Nevertheless, optimization is often required to make conversion programs complete within the allotted production upgrade downtime.
Another very important optimization technique is to reduce the amount of data prior to performing an upgrade. As demonstrated in Chapter 4, Data Archive Manager is a valuable tool that can reduce the volume of transactions within your PeopleSoft system. Keep in mind that pre-upgrade data structures may not match post-upgrade table definitions. It may not be possible to restore from an archive without also performing a conversion against history tables. Considering that archived data is not accessible from PeopleSoft transaction pages, a history table data conversion can be run after the upgrade go-live date.
Number of Customizations to Merge into the Upgrade
It is very common for an initial PeopleSoft implementation to contain a significant number of customizations designed to align PeopleSoft with an organization’s business model. Oftentimes these customizations are based on the customer’s perception of PeopleSoft and an implementation consultant’s understanding of the customer’s business. With use, a customer will often discover a configuration that satisfies a business requirement.
An upgrade is an excellent time to evaluate customizations. The upgrade process will overwrite customizations, requiring you to reapply any customizations you intend to keep. An upfront customization evaluation will save valuable time in customization rework. Here is a list of a few customizations that you may no longer require:
■ Business process changes you can implement through configuration
■ Customizations requested at implementation, but never used
■ Features you implemented through customization that are now part of the delivered product
Number and Complexity of Integrations
PeopleSoft applications participate in a much larger enterprise software ecosystem. You may have to change integration code to align existing integrations with changes to transactions and data structures.
Availability of Resources
Upgrades require labor: performing upgrades, applying customizations, testing transactions, and so on. Generally speaking, increasing the number of people dedicated to an upgrade project will shorten the overall upgrade project duration. Trying to manage a normal workload while performing functional testing can jeopardize a project.
Training and Documentation
By definition, an upgrade involves change: new features, streamlined business processes, and so on. It is very likely that your organization created step-by-step user guides that an upgrade will invalidate. Likewise, these changes may require additional functional user training.
Patching and Maintenance Cycles During Upgrade
When planning your upgrade, you will pick a target release version. For example, if you currently have HCM 8.9 installed, you may target HCM 9.1. If HCM 9.2 releases two months into your upgrade, will you switch to the newer target release? What about bundles, maintenance packs, and feature packs? Generally speaking, it is best to avoid all but necessary maintenance until after going live on an upgraded system.
Multipass Migration Requirements
A customer applying an upgrade usually chooses the latest version available. Depending on your current version, however, you may not be able to perform a direct upgrade. For example, if your HCM release version is 8.3 and you would like to be using 9.1, you will first have to upgrade to 8.9 and then perform a second upgrade to 9.1.
Software Prerequisites
Application upgrades often require PeopleTools upgrades, and a PeopleTools upgrade may require a newer version of your operating system, database, WebLogic, Tuxedo, or any number of software components.
When planning an application upgrade, be sure to allow time for a PeopleTools and infrastructure upgrade. To ensure maximum system stability, I recommend incremental changes. In regard to PeopleTools upgrades, an incremental change approach would involve breaking the entire upgrade process into smaller architecture changes, such as applying a Tuxedo upgrade to your current PeopleTools version. After each of the software and architecture prerequisites is working in your current PeopleTools version, perform a PeopleTools upgrade. Depending on the gap between your current PeopleTools version and your target release, you may have to upgrade everything as a single unit. Newer versions of prerequisite software may not be compatible with older versions of PeopleTools.
The alternative to small, incremental changes is to upgrade every piece of a PeopleSoft application and its corresponding infrastructure at once; this is known as the Big Bang approach (http://en.wikipedia.org/wiki/Big_bang_adoption). This type of upgrade is risky, but if successful, it can reduce overall upgrade costs. If not successful, the Big Bang approach can exponentially increase costs. The approach is risky because an organization cannot gauge the project’s success rate until go-live. Furthermore, the Big Bang contains no natural early termination points. The incremental approach allows a team to reevaluate future direction at each milestone. If a team chooses to forgo the remainder of an upgrade project, that team can claim each prior milestone as a success. The Big Bang team, on the other hand, has nothing unless the project completes on time and on budget.
Hardware Changes
Oracle certifies and decertifies hardware for PeopleTools based on hardware manufacturer support policies and software requirements. For example, PeopleTools releases 8.50 to 8.52 included more 64-bit software prerequisites. Prior to 8.50, a customer could run PeopleSoft on either 32-bit or 64-bit hardware. As of 8.50, PeopleTools is certified for 64-bit hardware only. If your application upgrade requires a PeopleTools upgrade, be sure to check the target PeopleTools hardware requirements.
Also, be sure to include enough computing resources for at least one “copy of production” system when planning hardware changes. Likewise, include enough space to accommodate backups at various stages of the upgrade.
Upgrade Team
An upgrade often requires a significant investment in talented technical and functional labor. Technical team members apply upgrades, customize the system, and create integrations. Functional team members identify requirements, apply configurations, and make implementation decisions. All members should be flexible and willing to adapt to change during this exciting process. This is a challenging but worthwhile endeavor with great rewards ahead.
An upgrade team often consists of the following roles.
Upgrade Project Manager
The upgrade project manager is responsible for timelines, budgets, status reports, and the overall upgrade big picture. He or she should have a functional and technical understanding of the PeopleSoft product. Patience and a great sense of humor are also helpful. This person often sets the tone for the entire project.
Technical Resources
Upgrade technical staff must be familiar with PeopleSoft upgrades, database systems, SQL, PeopleTools, Change Assistant, Data Management Tools, and Application Engine.
Database Administrator
The DBA position may require either a part-time or full-time employee. A DBA assists technical staff in reviewing scripts, performing backups, and troubleshooting and tuning the database.
Network/System Administrator
The network and system administrator role is often a part-time position. This member manages network security and connectivity, often providing valuable network architecture recommendations.
Developers
A project’s PeopleSoft developers must be familiar with your organization’s customizations and how those customizations will affect an upgrade. Developers should have experience in SQR, COBOL, PeopleTools, Application Engine, and PeopleCode. These members are responsible for reapplying customizations during the upgrade process.
Functional Resources
Functional members represent the broader user community. Functional members should be experts within their modules, with a full understanding of module configuration options. These experts establish the testing strategy used to test the upgraded system. They must acquire knowledge regarding changes introduced with the upgrade, which allows them to create appropriate test cases and documentation for coworkers.
Executive Sponsor
Although not required, an executive sponsor from your organization’s senior management team adds a significant amount of value. A senior manager assists with the procurement of adequate project resources and helps communicate a common vision.
Performing the Upgrade
Here are a few tips to simplify your upgrade.
Creating a New Demo Database
During an upgrade, you perform a comparison between the target version’s demo database and your own copy of production. This allows you to identify changes between the two releases, specifically identifying any customizations affected by an upgrade.
When performing a new PeopleSoft installation, Oracle allows for two options: create an empty database or create a database with seeded, demo transaction data. A demo database allows a customer to interact with new PeopleSoft features without performing configuration steps. A demo database contains a fully implemented, fully functional instance of a PeopleSoft application.
A few years ago, the only way to create a demo database was to perform a complete PeopleSoft installation. Then Oracle released a couple of PeopleSoft Oracle VM (OVM) templates. This allowed OVM customers to import a fully configured demo instance into Oracle’s Xen-based hypervisor. These OVM templates significantly reduce the time required to create a demo instance from two days to 15 minutes. In 2012, Oracle stepped up support for OVM by releasing an OVM template for every PeopleSoft 9.1 application and updating many of them to the latest maintenance and feature packs midyear. Customer adoption of these PeopleSoft templates has been hampered by the OVM requirement. Not every customer has experience with Xen-based hypervisors or hardware available for Xen virtualization.
Don’t worry, though; for those who don’t use OVM, the PeopleSoft community maintains documentation that describes how to convert PeopleSoft OVM templates into Oracle VirtualBox instances that can run on any laptop, desktop, or server. You can find a list of documents on my blog at http://jjmpsj.blogspot.com/2012/08/peoplesoft-ovm-virtualbox-conversion.html.
Today you have several options for creating a demo instance:
■ Install a PeopleSoft demo instance from the Oracle provided installation media.
■ Import a PeopleSoft OVM template.
■ Convert a PeopleSoft OVM template to another virtualization platform—VirtualBox, for example.
■ Apply any combination of the above, such as install a PeopleSoft demo database from Oracle’s installation media but deploy the PeopleSoft middle tier as an OVM template.
A demo instance has minimal hardware requirements. Oracle recommends a minimum of two CPUs and 4 gigabytes of RAM for a full database, application server, and web server installation. For generating an upgrade compare report, we will use the database portion of a demo configuration only.
PeopleTools Upgrade
Unless you’ve kept current with PeopleTools upgrades, your application upgrade will likely require a PeopleTools upgrade. As mentioned, select a PeopleTools version certified for your target application release and ensure that your hardware is certified for the PeopleTools release. You can usually upgrade to a higher version of PeopleTools than the version required for the target application, but this can increase project risk. Some application features extend PeopleTools features. Installing a higher version of PeopleTools may require additional application patches. To reduce risk, upgrade PeopleTools to the application version’s recommended PeopleTools version. After the application upgrade, apply the additional PeopleTools upgrade desired for go-live.
With a decoupled
PS_HOME, PS_CFG_HOME, and PS_APP_HOME, a modern PeopleTools upgrade really isn’t much of an upgrade. It is more like a fresh PeopleTools installation with database upgrade scripts. Oracle provides documentation detailing each step required for a PeopleTools upgrade. Rather than repeat Oracle’s documentation, this section focuses on a virtual upgrade.Virtual Upgrade
The easiest way to perform a PeopleTools upgrade is to skip the installation phase. If you plan to run PeopleSoft on a 64-bit Linux operating system, then you can leverage the work of the PeopleTools OVM team. Oracle’s PeopleSoft OVM templates contain the latest PeopleTools Linux 64-bit binary distribution. Rather than install PeopleTools and all of its required components, mount the OVM
TOOLS.img disk image. The TOOLS.img file contains a complete Tuxedo (TUXDIR), WebLogic, Oracle Client (ORACLE_ HOME), and PeopleTools (PS_HOME) installation.The OVM template mounts the
TOOLS.img disk into /opt/oracle/psft/pt. Depending on your architecture, you may either mount the disk directly using losetup, mount it virtually through your virtual OS media manager, convert the disk to a new format, or temporarily mount the disk so you can copy its files into a different partition.The files within the
TOOLS.img disk are owned by three users: root, psadm1, and psadm2. The following command listing describes the users and groups required by the TOOLS.img disk image. You are not required to use the same users, but you will need an understanding of file ownership so you can make the appropriate changes. It is easiest to use Oracle’s recommendations. Otherwise, you will have to make the same changes for subsequent upgrades.
Part of the reason for separating files into
PS_HOME, PS_CFG_HOME, and PS_APP_HOME is to make it easy to swap application and PeopleTools files without actually performing an upgrade—sort of a virtual upgrade.Virtualizing the Application Upgrade
Through the use of OVM templates and
PS_APP_HOME, you can virtualize a portion of the application upgrade. Just like the PeopleTools OVM template, the application OVM template includes a complete PS_APP_HOME file system that you can mount into your server’s file system, giving you all of the application’s updated scripts, reports, and other application-specific files.Adjusting Upgrade Flags
During the course of an upgrade, you will perform a compare for the purpose of copying upgraded definitions into your copy of the production system. Generally speaking, you want to apply all changes included with an upgrade. Failure to apply an Oracle-delivered change may render a portion of your system unusable. Rather than blindly apply each change, however, it is wise to review and adjust definition upgrade action and upgrade flags. You may find that the compare process set a flag to delete a definition that you intended to keep.
Considering the number of definitions included in an upgrade project, customers often apply the “divide and conquer” approach, with multiple people adjusting flags within the same project. If multiple people are working on the same change project, be very careful to avoid changing the same definition types. Application Designer’s optimistic locking design will allow multiple people to view the same project, but only one user can actually save changes. Successive user save attempts will fail.
Reconfiguring the Application
PeopleTools and application upgrades include their own configuration data. At times, upgrade configuration data will conflict with your own metadata. The remainder of this chapter identifies areas of conflict you should review prior to functional testing.
Verify Security
Application updates include new features and functionality. These new features require security changes. Performing an upgrade may overwrite changes you have made to delivered permission lists and roles. Compare permission lists your organization has modified with your production instance and adjust the permission lists as necessary.
Integration Broker Configurations
PeopleTools upgrades often include node and integration changes. The
WSDL_NODE and ANONYMOUS nodes are examples of delivered nodes that Oracle preconfigures for internal and external integrations. Open these nodes and confirm that the node’s default user ID exists within your database.Application upgrades often replace Integration Broker service operations, handlers, and routings. Be sure to reactivate all service operations your organization uses, including PeopleSoft-to-PeopleSoft integration points.
URL Definitions
Some application processes require URL definitions. An application upgrade will reset these URLs to generic values. Be sure to update them with values appropriate for your environment.
Conclusion
Upgrades are difficult. They require tremendous attention to detail and a significant investment in functional testing. Several factors contribute to the complexity of an upgrade:
■ Amount and complexity of modifications
■ Integrations with other applications
■ Architecture changes, such as hardware and database upgrades
In this chapter, you learned about many of the difficulties encountered during an upgrade as well as tips to help you successfully navigate the upgrade highway.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.