Prevent WebLogic Install with prcs and app-only DPK Deployments

In this post, I introduced the site.pp file and how that relates to the DPK. I used the example of deploying a process scheduler with the DPK by using the bootstrap command psft-dkp-setup -env_type -domain_type prcs. This command will populate the site.pp file with the role ::pt_role::pt_tools_prcs.

For the most part, this works well. The DPK/Puppet will install Tuxedo, Java, Oracle Client, WebLogic and create your process scheduler domain. But there is one problem – we don’t need (or want) WebLogic on our process scheduler! Why does the DPK do this? The base profile that applies to all DPK server builds includes WebLogic and doesn’t check to see what type of install is happening.

Finding the WebLogic Deployment Manifest

Open the file for the role pt_tools_prcs. The file is under c:\programdata\puppetlabs\puppet\etc\modules\pt_role\manifests\ and named pt_tools_prcs.pp. This Puppet manifest lists the profiles that will be applied when creating a process scheduer.

Class['::pt_profile::pt_system'] ->
Class['::pt_profile::pt_tools_deployment'] ->
Class['::pt_profile::pt_psft_environment'] ->
Class['::pt_profile::pt_prcs'] ->
Class['::pt_profile::pt_tools_preboot_config'] ->
Class['::pt_profile::pt_domain_boot']

Each of these classes tied back to file under modules\pt_profile. The class that handles WebLogic and Tuxedo deployment is pt_tools_deployment. The pt_tools_deployment.pp manifest takes the configuration values from deployment.yaml (or psft_customizations.yaml if you overrode the defaults) and prepares the class pt_setup:tools_deployment.

In the file tools_deployment.pp under pt_setup\manifests\, you’ll see the base deployment configuration for any DPK installation. This file will install the software for a DPK run. Even if you aren’t familiar with Puppet (this file is a Puppet manfiest), you can read the file and get an idea of what’s happening.

The important section is roughly half way down and looks like this:

  pt_deploy_weblogic { $weblogic_tag:
    ensure                    => $present,
    deploy_user               => $tools_install_user,
    deploy_user_group         => $tools_install_group,
    archive_file              => $weblogic_archive_file,
    deploy_location           => $weblogic_location,
    oracle_inventory_location => $inventory_location,
    oracle_inventory_user     => $oracle_install_user,
    oracle_inventory_group    => $oracle_install_group,
    jdk_location              => $jdk_location,
    redeploy                  => $redeploy,
    remove                    => $weblogic_remove,
  }

Modifying the Manifest

In Puppet, the ensure variable will takes two options:

  • present – think of this as “install” (that isn’t technically accurate, but at a high level that’s what it means for the DPK)
  • absent – this value would uninstall WebLogic

In this manifest, there aren’t checks for each software package. Everything is installed, or everything is uninstalled. The simple fix is to update the ensure value to absent for WebLogic.

  pt_deploy_weblogic { $weblogic_tag:
    ensure                    => absent,
    deploy_user               => $tools_install_user,
    deploy_user_group         => $tools_install_group,
    archive_file              => $weblogic_archive_file,
    deploy_location           => $weblogic_location,
    oracle_inventory_location => $inventory_location,
    oracle_inventory_user     => $oracle_install_user,
    oracle_inventory_group    => $oracle_install_group,
    jdk_location              => $jdk_location,
    redeploy                  => $redeploy,
    remove                    => $weblogic_remove,
  }

After making this change, you can run puppet apply site.pp. If you are on working on a blank server, the DPK won’t install WebLogic. If WebLogic is installed, the DPK will uninstall WebLogic.

One big disclaimer, this is not supported by Oracle. So, make these changes knowing that Oracle won’t help you if you run into any issues. For my own experience, we made this change before deploying our process scheduler servers and it has worked well. But, that’s only my experience.

A better way to handle this fix would be to read in the domain_type setting from the defaults.yaml file.

Here is what that change would look like:

  if hiera('domain_type') == 'all' or hiera('domain_type') == 'pia' {
    $wl_ensure = 'present'
  } 
  else {
    $wl_ensure = 'absent'
  }
  pt_deploy_weblogic { $weblogic_tag:
    ensure                    => $wl_ensure,
    deploy_user               => $tools_install_user,
    deploy_user_group         => $tools_install_group,
    archive_file              => $weblogic_archive_file,
    deploy_location           => $weblogic_location,
    oracle_inventory_location => $inventory_location,
    oracle_inventory_user     => $oracle_install_user,
    oracle_inventory_group    => $oracle_install_group,
    jdk_location              => $jdk_location,
    redeploy                  => $redeploy,
    remove                    => $weblogic_remove,
  }

A quick lookup to the defaults.yaml file’s domain_type will tell us what type of installation was requested from the bootstrap script.

Closing Thoughts

This bug is annoying. But, one thing I really enjoy with the DPK (and Puppet), is that we have access to the code. That means we can research how the DPK is working and make changes are possible (if technically unsupported). But, we also have Puppet installed our servers and we can leverage it for our own modules. Coming up in future posts, I’ll be documenting some of the custom modules I’ve been writing to extend Puppet for our own use.

I have an SR open on this bug too, so if I get feedback I’ll update this post.

Explaining the site.pp File

If you have customized any settings with the DPK’s, you have encountered the site.pp file. When you run the bootstrap script, there is a question at the end of the process asking you “Do you want to continue the default initialization process?”. If you answer “No”, the bootstrap script instructs you to make changes, and then run the command puppet apply site.pp. So, what is the site.pp file?

site.pp is a Puppet manifest and is what the DPK (aka Puppet) uses to build your server. A manifest describes what state the server should be after Puppet runs. Our site.pp file contains a role that describes how Puppet should configure the PeopleSoft components. We’ll cover those roles in a bit, but first let’s find out how the site.pp is populated.

Boostrap Parameters

When you run the bootstrap script (psft-dpk-setup), you can pass in a few parameters like env_type and domain_type. These parameters determine what components and software the DPK will install. The env_type parameter takes three options:

  • fulltier
  • midtier
  • dbtier

The fulltier option will install everything needed to run PeopleSoft (Oracle DB, Web, App, Batch). This is the default option and used by the PeopleSoft Images. dbtier will only install the Oracle Database software, and midtier will install software to web/app/batch domains.

If you choose midtier, you can also pass in the additional parameter domain_type. This parameter let’s you narrow down the installation even more. You can choose:

  • pia
  • appserver
  • batch
  • appbatch

These options install some of the components rather than all of them.

Last, we can also pass in the deploy_only and deploy_type parameters to the bootstrap script. This option tells the DPK to install the midtier software (WebLogic, Tuxedo, etc) but not configure any domains.

The complete list of parameters can be found in the DPK Guide under the section “Using the PeopleSoft PeopleTools DPK Setup Script.”

Site.pp Roles

So, how do these parameters affect the site.pp file? Each combination of parameter relates to different roles assigned to the site.pp file. Let me explain.

This is a site.pp file after running the bootstrap script with the command psft-dpk-setup -env_type midtier -domain_type prcs:

node default {
  include ::pt_role::pt_tools_prcs
}

The second line is the important one. ::pt_role::pt_tools_prcs tells Puppet to apply the PeopleTools DPK role pt_tool_prcs. These roles are different than PeopleTools security; they are Puppet roles. We can take a look at these roles under the folder c:\programdata\puppetlabs\puppet\etc\modules\pt_role\manifests\.

Under the pt_role\manifests folder, you’ll see a long list of files. Each file is a Puppet role, and each role ties back to the parameters in the bootstrap script.

If we open the file pt_tools_prcs.pp, we can see what actions are taken by Puppet.

if $ensure == present {
    contain ::pt_profile::pt_tools_preboot_config
    contain ::pt_profile::pt_domain_boot

    Class['::pt_profile::pt_system'] ->
    Class['::pt_profile::pt_tools_deployment'] ->
    Class['::pt_profile::pt_psft_environment'] ->
    Class['::pt_profile::pt_prcs'] ->
    Class['::pt_profile::pt_tools_preboot_config'] ->
    Class['::pt_profile::pt_domain_boot']
  }
  • pt_system makes some OS level changes for Linux
  • pt_tools_deployment deploys all the PeopleTools components
  • pt_psft_environment sets up PS_CFG_HOME, PS_APP_HOME and PS_CUST_HOME folders, and user information on Linux
  • pt_prcs configures a process scheduler domain
  • pt_tools_preboot_config runs the ACM app engine
  • pt_domain_boot will start the configured domains

Let’s compare this file to pt_hcm_pum.pp. This file is used by the HCM PeopleSoft Images:

  if $ensure == present {
    Class['::pt_profile::pt_system'] ->
    Class['::pt_profile::pt_app_deployment'] ->
    Class['::pt_profile::pt_tools_deployment'] ->
    Class['::pt_profile::pt_oracleserver'] ->
    Class['::pt_profile::pt_psft_environment'] ->
    Class['::pt_profile::pt_psft_db'] ->
    Class['::pt_profile::pt_appserver'] ->
    Class['::pt_profile::pt_prcs'] ->
    Class['::pt_profile::pt_pia'] ->
    Class['::pt_profile::pt_samba'] ->
    Class['::pt_profile::pt_tools_preboot_config'] ->
    Class['::pt_profile::pt_domain_boot'] ->
    Class['::pt_profile::pt_tools_postboot_config'] ->
    Class['::pt_profile::pt_source_details'] ->
    Class['::pt_profile::pt_opa']
  }

There are many more actions in this file, which explains why setting up a PeopleSoft Image configures everything.

Changing Roles

What can we do with the site.pp file? Quite a bit, actually. If you ran the bootstrap script with defaults but want to change the components on the server, you can update the site.pp file to use another role.

If you ran the bootstrap script with -env_type midtier -domain_type prcs but now you want to add an app server, you can add change the role in site.pp from ::pt_role::pt_tools_prcs to ::pt_role::pt_tools_appbatch. Keep in mind, if you change roles in the site.pp file, you’ll want to verify the configuration settings in the psft_customizations.yaml file are correct.

Once you make the change to site.pp, run the command puppet apply site.pp to have Puppet update your server.

This is just the beginning of what the site.pp file can do for us. If you’ve listened to the podcast, you may have heard that I created a custom role for a webapp domain type. In a future post, I’ll document how we did that and how we used the site.pp file to create our web and app servers.

Managing 32-bit and 64-bit Oracle Client

Beginning with PeopleTools 8.54, the PeopleTools client tools became 64-bit applications. This means the client tools require the 64-bit Oracle client. If are still running on PeopleTools 8.53 (or earlier), you’ll need both 32-bit and 64-bit Oracle clients installed. Managing both versions can be cumbersone, and often times frustrating.

Tim Slater offered a great solution for managing Oracle clients in the psadmin.io Community. Here is Tim’s method for managing Oracle clients:

  1. Install Oracle 32-bit client to c:\oracle2\product\12.1.0\client_1
  2. Install Oracle 64-bit client to c:\oracle\product\12.1.0\client_1
  3. Create a symbolic link c:\windows\system32\oracle to point to the 64-bit installation folder.

    mklink /j c:\windows\system32\oracle c:\oracle\product\12.1.0\client_1
    
  4. Create a symbolic link c:\windows\sysWOW64\oracle to point to the 32-bit installation folder.

    mklink /j c:\windows\sysWOW64\oracle c:\oracle2\product\12.1.0\client_1
    
  5. Set the ORACLE_HOME environment variable to c:\windows\system32\oracle.

  6. (Optional) Set the TNS_ADMIN environment variable to %ORACLE_HOME%\network\admin

This works because of File System Redirection in 64-bit versions of Windows. If you are running a 64-bit application, Windows will route any system calls to c:\windows\system32. But, if you are running a 32-bit application, any system calls are routed to c:\system\sysWOW64 instead. Rather than manually configuring your applications and updating the PATH environment variable, you can let Windows do the work for you.

8.55 – Enable App Server Features with the DPK

A comment on the Build Images with DPK post had a great question. Instead of answering it there, I wanted to share the solution as a post so more people would see it. The question deals with enabling (or disabling) features on the app server using the DPK. With the current PI’s based on PeopleTools 8.55.01, you can change app server configuration when you create the PI’s using the DPK.

If you have already built the PI’s, the 8.55.01 DPK doesn’t handle changes to the current configuration well.

To enable the WSL and Debugger when you build a DPK:

  1. Run the VBox or NativeOS DPK psft-dpk-setup script.
  2. Answer No to the “Do you want to continue with the default initialization” question.
  3. Create the file psft_customizations.yaml in the folder C:\ProgramData\PuppetLabs\Puppet\etc\data or /etc/puppet/data
  4. Add these lines to your psft_customizations.yaml file (notice the lines WSL: "Yes" and DBGSRV: "Yes" are different)
  5. Navigate to c:\programdata\puppetlabs\puppet\etc\manifests or /etc/puppet/manifests.
  6. Run puppet apply site.pp

If you have already build the PI, you can do in manually through psadmin, but that’s no fun ūüėČ In PeopleTools 8.55.03, the DPK (Puppet modules) is better at handling configuration changes in the psft_customizations.yaml file. I’d guess the next PI’s will be based .04 (or higher), so this should be able to make the change after you built the PeopleSoft Image.

Update: If you want to learn more about the DPK, check out our new PeopleSoft DPK QuickStart course. This free course will introduce you to the DPK, show you how to use the DPK with PeopleSoft Images, and show you how to customize the DPK for your servers.

 

8.55 – PeopleTools Client DPK

 

In the Parts one, two, and three of our “Building PeopleSoft Images with the DPK” posts, we focused on installing the application and server components. In this post we’ll dig into the options for installing the PeopleTools Client using the DPKs. Starting with the PeopleTools 8.55-based PeopleSoft Images, there are two new ways to install the PeopleTools Client software.

  1. Update Manager mode when using the VirtualBox or NativeOS DPK
  2. Standalone mode if you download the PeopleTools Patch DPK

Behind the scenes, these options are similar. They run the same DPK scripts but they have variations in how they execute.

Python, not Puppet

The Client DPK does not use Puppet. To use Puppet for the Client DPK, you would need to install Puppet on the client machines. That wouldn’t work well with client installations. Instead, the Client DPK uses Python scripts to run the installation. Python is bundled with the client installer so you don’t need to install it.

Update Manager Mode Client DPK

Running the client install scripts from a PeopleSoft Image is Update Manager mode. The PeopleTools Client DPK will install a source client version and a target client version. The source client will match the PeopleSoft Image and the target client matches your PeopleTools version. The Client DPK script will also install the Oracle Database Client.

VirtualBox Client Install

 

The PeopleTools Client DPK is available through a network share. To install the PeopleTools client, open the tools_client share on the virtual machine.

  1. Map a drive to \\[PeopleSoft Image IP Address]\tools_client (I used T:)
  2. Open a command prompt
  3. Navigate to t:
  4. Run the command SetupPTClient.bat

You will be asked “Is this is a deployment for a Update Manager Environment?”. If you answer Yes, you will be asked to choose a target client version. The version you pick should match your environments PeopleTools major version (i.e, 8.53 or 8.54).

If you selected “Yes” and picked a target client version, next select the database platform for your target environment.

The SetupPTClient script will install both PeopleTools versions, the Oracle client, and Change Assistant. By default, the script uses these conventions:

  • PeopleTools Client Folder: c:\PT8.xx.xx_Client_[db]. The [db] value will be the Database Platform you selected. (E.g, ORA for Oracle).
  • Change Assistant is installed under c:\Program Files\PeopleSoft\Change Assistant. (I’m curious what the default path will be for the next PI’s. You can install more than 1 version of the 8.55 Change Assistant.)
  • The Oracle Client is installed under c:\oracle\ for the target client and c:\oracle2\ if you need the 32-bit client (8.53 customers). If you have an existing Oracle Client on the machine, the Client DPK will add a new client_x folder (x will increment, so you may see client_3 if you had two clients installed.)

NativeOS Client Install

 

The PeopleTools client scripts are located under the base folder. In my case, I chose e:\lm92u012 as the base folder.

  1. Open a command prompt and navigate to e:\lm92u012\pt\tools_client
  2. Run SetupPTClient.bat

The rest of the installation for the NativeOS Client is the same as the VirtualBox Client install.

Standalone Mode Client DPK

If you download a PeopleTools Patch DPK, or if you don’t want to use Update Manager mode, there is a Standalone mode for the PeopleTools Client DPK. With the PeopleTools Patch DPK, this is your only option. Here’s why:

When you download the PeopleTools Patch DPK, you get a .zip file called PTC-DPK-WIN8.55.03-1of1.zip. Inside this folder are the installation files for a specific client version (8.55.03 in this example). If you look at the tools_client hare on a VirtualBox or NativeOS DPK, you’ll see this structure:

  • SetupPTClient.bat
  • \client-853
  • \client-854
  • \client-855
  • source.properties
  • tnsnames.ora

The PTC-DPK-WIN8.55.03-1of1 folder in the PeopleTools Patch DPK is the same as the client-855 folder on the PeopleSoft Image. If you attempt to use Update Manager mode with the PeopleTools Patch DPK, it will fail because it won’t find the files it needs. That’s why Update Manager mode doesn’t work with the PeopleTools Patch DPK.

PeopleTools Patch Client Install

 

To start the PeopleTools Client DPK in Standalone mode:

  1. Run the command SetupPTClient.bat -t
  2. The Client DPK will ask “Do you want to deploy PeopleTools client?”. If you answer “Yes”, pick a database platform.
  3. Next, answer the question “Do you want to configure PeopleTools client?” If you answer “Yes”, you are asked for:

    • Database Name
    • Server Name
    • User ID
    • Connect ID
    • Connect Password

    The DPK script will create the Default profile in Configuration Manager and populate those values for you. If you already have your config file prepared, you can skip this step and import your configuration after you install the client.

  4. Next, select which type of PeopleTools Patch you want included in your client install. “Please make your selection for the PeopleTools Client deployment”

    • PeopleTools Full Upgrade
    • PeopleTools Patch
    • None of the above

    These options will determine what PeopleTools upgrade scripts are included with the client. If you want to install only the client, select 3. None of the above. The only difference between the “Full Upgrade” and “Patch” options is: the “Full Upgrade” option will include the updPTU855.zip project and Install Guide. Both “Full Upgrade” and “Patch” options include the minor patch releases like updPTP85503.zip in the PTP folder.

  5. After selecting options for the PeopleTools Client, answer the questions about Change Assistant, Change Impact Analyzer and PeopleSoft Test Framework.

After you select your options, the PeopleTools Client DPK will install the client tools.

One thing to note: if you choose to configure the PeopleTools Client, the Client DPK will overwrite any configuration you saved in Configuration Manager. I keep all our configuration in a single file (ps.cfg) that everyone imports. This keeps our client configurations the same. If we change or add an environment, everyone who has App Designer installed can import the ps.cfg file.

Script the PeopleTools Client DPK

 

With the PeopleTools Client, you may be pushing the software to many machines (e.g, other developers). To simplify that task, we want to script the installation. There is an undocumented flag -i that let’s you pass in a configuration .ini file.

The default .ini file is located under DPK_HOME\PTC-DPK-WIN8.55.03-1of1\scripts\tools-client and named PTClientSetup.ini. We can change the file and control the installation process.

In the PTClientSetup.ini file, there are a few sections that we can change to change the behavior of the installation scripts.

[GENERAL]

The [GENERAL] section is where we configure the main tasks, like installing App Designer, Change Assistant, etc. If you want to install a single version of App Designer and the other client tools, you can set the src_tools_client = YES.

[GENERAL]
upg_tools_client = NO
src_tools_client = YES
src_tools_config = NO
tgt_tools_client = NO
tgt_tools_config = NO
ca_install = NO
ca_config = NO
cia_install = NO
ptf_install = NO
ptf_config = NO

[SOURCEPTCLIENT] and [SOURCEDB]

Next, make sure you complete the [SOURCEPTCLIENT] and [SOURCEDB] sections. (The [SOURCEDB] section is required for the .ini option.) For example:

[SOURCEPTCLIENT]
pt_version = 8.55.03
dpk_extract_location = C:\DPK_8.55.03\PTC-DPK-WIN8.55.03-1of1
ps_src_home = c:\client-8.55.03
ps_app_home = %(PS_SRC_HOME)s
ps_cust_home = %(PS_SRC_HOME)s
dbtype = ORACLE
pt_icon = NO
pt_program_group = NO
deploy_type = NONE

[SOURCEDB]
tnsalias = HR92DMO
db_client_home = 
dbname = HR92DMO
portnumber(oracle) = 
sid(oracle) = 
service_name(oracle) = 
host = hr92t855.psadmin.io
userid = dan
password = 
accessid = 
accesspwd = 
connectid = people
connectpwd = xxxxxx

If you want to install Change Assistant or PTF, you can set the flags in the [GENERAL] section to YES. Make sure to fill our the configuration section for those installations.

BUG in 8.55.03

In PeopleTools 8.55.03, there is a bug in the Python scripts for an .ini installation. To fix the bug, modify the file scripts\tools_client\INI-Deploy-ToolsClientDPK.py. Change this line:

src_config_tools_client = ClsToolsClientConfig(srctoolsclienthome, srcdbtype, srcdbname, srchost, srcuserid, srcconnectid, srcconnectpwd, srcpsapphome, srcpscusthome)

to

src_config_tools_client = ClsToolsClientConfig(srctoolsclienthome, srcdbtype, srcdbname, srchost, srcuserid, srcconnectid, srcconnectpwd, '', srcpsapphome, srcpscusthome)

The init() call was missing a parameter. The value isn’t used, so we pass in a blank string.

Run the Scripted Installation

To run the installation with your .ini file:

SetupPTClient.bat -i c:\temp\PTClientSetup.ini

Another bug (or design) with the .ini installation, the -i install does not install the Oracle client. The capability is there (it’s in Update Manager mode). The Python scripts for the .ini installation don’t have the Oracle Database Client code. (I have an SR open on that bug and will update if/when that changes.)

Deploy Change Assistant Only

When you run SetupPTClient.bat -t, you can answer N to the question “Do you want to deploy PeopleTools client?”. The script will skip to the next question about installing Change Assistant. You can also script that with the .ini method. Change the flags in the [GENERAL] section and you can script the process.

Final Thoughts

I like the new PeopleTools Client DPK’s. The Update Manager mode is simple and reduces the steps to get new PeopleSoft Image’s running. I would like to have an option to change the folder names for the client tools, but that’s about it.

The PeopleTools Patch DPK and Standalone mode are nice, but I want to see improvements on automation. For organizations who push App Designer to many users, that’s a must-have. We are still pretty early in the PeopleTools 8.55 lifecycle though. I expect the PeopleTools Client DPK to keep improving.

Update: If you want to learn more about the DPK, check out our new PeopleSoft DPK QuickStart course. This free course will introduce you to the DPK, show you how to use the DPK with PeopleSoft Images, and show you how to customize the DPK for your servers.

 

#21 – Temp Tables w/ David Kurtz

We are excited to have David Kurtz join us! David wrote the book PeopleSoft for the Oracle DBA and is a popular blogger. We talked with David for almost 2 hours, so we are breaking his interview into 3 parts. In Part 1, we talk about Temp Tables, PSAESRV, and more. Dan and Kyle also talk about Microsoft and Linux, and Dan’s DPK patching experience with PeopleTools 8.55.03.

We want to make this podcast part of the community discussion on PeopleSoft administration. If you have comments, feedback, or topics you’d like us to talk about, we want to hear from you! You can email us at podcast@psadmin.io, tweet us at @psa_io, or use the Twitter hashtag #psadminpodcast.

You can listen to the podcast here on psadmin.io or subscribe with your favorite podcast player using the URL below, or subscribe in iTunes.

Podcast RSS Feed

Show Notes

#20 – PUM Dashboard

Kyle and Dan discover that PS_CUST_APP_HOME is not supported in 8.55, brainstorm how to use Regular Expressions in PeopleCode, and our impression of the new PUM Dashboard.

We want to make this podcast part of the community discussion on PeopleSoft administration. If you have comments, feedback, or topics you’d like us to talk about, we want to hear from you! You can email us at podcast@psadmin.io, tweet us at @psa_io, or use the Twitter hashtag #psadminpodcast.

You can listen to the podcast here on psadmin.io or subscribe with your favorite podcast player using the URL below, or subscribe in iTunes.

Podcast RSS Feed

Show Notes

#18 – Large Scale PeopleSoft with Wayne Fuller (Part 1)

Wayne Fuller joins us this week to talk about running PeopleSoft in large environment. Wayne shared so much knowledge with us that we are breaking his interview into 2 parts. Dan and Kyle also talk about their experience with the Linux DPK and using the DPK for server maintenance.

We want to make this podcast part of the community discussion on PeopleSoft administration. If you have comments, feedback, or topics you’d like us to talk about, we want to hear from you! You can email us at podcast@psadmin.io, tweet us at @psa_io, or use the Twitter hashtag #psadminpodcast.

You can listen to the podcast here on psadmin.io or subscribe with your favorite podcast player using the URL below, or subscribe in iTunes.

Podcast RSS Feed

Show Notes

8.55 – 9.2 Upgrade Changes

If you are planning to upgrade to PeopleSoft 9.2 AND PeopleTools 8.55, there are changes in the upgrade process.

First, the PeopleTools upgrade is now a separate step. In the past, you could upgrade PeopleTools and the Application in one pass. Starting in 8.55, PeopleTools will be a separate pass. If you look at the FSCM 9.2 upgrade page, the 8.55 upgrade template has only the Application steps. To upgrade PeopleTools, you will generate the upgrade template from Change Assistant.

Second, the databases used in the upgrade process has changed. You no longer use a Copy of Current Demo to create the UPGCUST project.¬†Instead, an app engine will create the UPGCUST project. The app engine will compare the LASTUPDOPRID for the objects and if the user¬†is not PPLSOFT it will be added to the UPGCUST project. One impact, if you’ve deleted delivered objects from the system, you won’t see those in the compare report. (Not sure why you would do that, so this shouldn’t¬†be an issue for you).

Third, you also need a PeopleSoft Image database for the Initial Pass. When you generate the Application Upgrade job in Change Assistant, you will also get a separate change package with all the Required for Upgrade fixes. These come from the PeopleSoft Image. To get a picture of how the new upgrade process works, the PeopleTools 8.55 PeopleBooks has a diagram on the process.    

8.55 – Event Mapping Demo

In PeopleTools 8.55, the Related Content Framework gained a new feature that could change the way developers approach customizations. Event Mapping lets you inject your custom code without modifying any delivered objects. In this demo, we’ll give you a quick overview of how to customize a page without modifying any delivered code.

 

If you have signed up for the What’s New in PeopleTools 8.55 for PeopleSoft Administrators video, this is the same demo. If you haven’t, sign up here or enter your email at the end of this demo. You can read more about Event Mapping here, Kyle and I talk about it on episode 8 of The PeopleSoft Administrator Podcast or at the Cedar Hills blog.