#93 – Forced Adoption

This week on the podcast, Kyle recaps the Phire User Group meeting, his PTF talk, and shares a nice tip on integrating Usage Monitor with PTF scripts. Then, Dan and Kyle discuss the latest changes with HR Image 23 and PeopleTools 8.56 and forcing users to adopt new technologies.

Show Notes

Convert the DPK to use Hiera Hash Merging

The way PeopleSoft delivers Puppet and the Hiera backend, is that everything you define in psft_customizations.yaml overrides configuration defined elsewhere. This is a useful setup when getting started with the DPK and Puppet. But when using YAML files to manage your configuration across multiple servers, you’ll quickly find that you are re-entering the same configuration in many files.

Hiera, the tool Puppet uses to read YAML files, has multiple ways to look up data. First, let’s cover what a YAML hash is. A hash is a key-value structure used in the DPK to store configuration. For example, this is the hash for PS_HOME information:

ps_home:
  db_type:    "%{hiera('db_platform')}"
  unicode_db: "%{hiera('unicode_db')}"
  location:   "%{hiera('ps_home_location')}"
  remove:     true

The main hash key is ps_home, and its value is all the configuration below it. The next level down has 4 keys with 4 corresponding values. The appserver_domain_list hash is a large one that contains all the configuration for one or more app server domains.

Under the delivered setup, if you want to change a value for a domain you need to copy the entire appserver_domain_list hash into your psft_customizations.yaml file and make the change. With Hiera hashing, you could define your domains in a file named appservers.yaml and any specific server changes can be defined in hostname.yaml. For example, the hostname.yaml file could contain this hash to override a configuration:

appserver_domain_list:
  DEV:
    feature_settings:
      SERVER_EVENTS: "Yes"
      DOMAIN_GW:     "Yes"

This provides far more flexibility when working with YAML files, but it does introduce some complexity. If you want to give this a try, here is how you can convert the current DPK to use Hiera hasing.

Find/Replace

I used VisualStudio Code to do the find/replace. Open up the etc\modules directory and do these against the modules\pt_profile folder:

  • Find: hiera('tns_admin_list
  • Replace: hiera_hash('tns_admin_list

I repeated this step for the following lookups.

  • tns_admin_list
  • appserver_domain_list
  • prcs_domain_list
  • pia_domain_list

You don’t want to replace all the lookups – that will cause errors. But, you can replace additional lookups if you want. Anything that is a hash in YAML files can use the hiera_hash() lookup function. If you wanted to make the ps_home: key support hash merging, you could replace hiera('ps_home with hiera_hash('ps_home.

Change the Hiera Merge Behavior

By default, Hiera will look at the top-level keys of a hash and not merge the underlying settings. Hiera hashing will merge all the values inside the hash. This means you can you define a hash with default settings in a common file (e.g, default app server settings). Then you can specify server or application specific settings in a YAML file for that domain or server.

To enable the hash merging, open the hiera.yaml file under c:\programdata\puppetlabs\hiera\etc.

Add this line to the file:

:merger_behavior: deeper

Hiera Lookup Order

With Hiera hash merging, we can utilize more than the psft_customizations.yaml file to manage our configuration. We can use multiple YAML files to control our configuration. For example, we could have:

  • [hostname].yaml
  • dev.yaml
  • hr.yaml
  • common.yaml

So, this setup would let us define common configuration that is shared across all applications in the common.yaml. Next, we could define anything related to servers that run HR applications in the hr.yaml. For any settings that are specific to the Development region, we can add them into dev.yaml. Last, for anything that is specific to the server, we can add into the [hostname].yaml file. This setup would let you re-use the common, hr, and dev YAML files across multiple servers, and anything specific to the server would be defined in [hostname].yaml.

In the hiera.yaml file, we can define this setup like this:

:hierarchy:
  - "%{::hostname}"
  - dev
  - hr
  - common

Test Hiera Hashing

On the command line, you can use the hiera utility to test lookups with Hiera. To do a normal Hiera lookup, use

hiera appserver_domain_list

To test a hiera hash lookup, use

hiera --hash appserver_domain_list

If you have multiple YAML files with the appserver_domain_list hash, the first option will only show you the results from the top of the list. The second test should show you a merged appserver_domain_list hash.

#91 – Testing Metrics w/ Frank Dolezal

This week on the podcast, Frank Dolezal joins us to talk about how he measure user testing and how it builds confidence when deploying updates. We also discuss self-service and fast database refreshes, and what skills to look for when hiring a PS Admin.

Show Notes

  • Introducing Frank @ 1:00
  • Creating Metrics for User Testing @ 4:00
  • Getting Users to Test @ 11:00
  • Justifying testing through metrics @ 17:00
  • Data Sources to gather testing metrics @ 23:00
  • Self Service Refreshes @ 28:30
  • Planning Catch-up Projects @ 39:00
  • Changing PT Release Schedule? @ 43:00
    • Oracle said that there was no plans to change, so this is speculation only
  • Skillsets when hiring a PS Admin @ 48:00

#89 – Gotchas

This week Kyle and Dan discuss UI improvements from Sasank and Dan’s new Fluid Stylesheets, using Git and GitLab to manage DPK files, managing Favorites with Unified Navigation and some “Gotchas” Kyle found during his 8.55 upgrade project.

Show Notes

#88 – Fast and Furious w/ Brad Carlson

This week Brad Carlson from the University of Minnesota joins us to talk about some recent projects he worked on. Brad explains why and how they consolidated their PeopleSoft database, an IB Monitoring tool that was recently open-sourced, and how the U of M can deploy CPU patches in 21 days.

Show Notes

  • Introducing Brad @ 1:00
  • Database Consolidation @ 5:30
  • Benefits of a Single Database @ 11:00
  • IB MonitorService @ 34:30
  • Distributing Notifications @ 53:30
  • Fast CPU Patching (21 Days!) @ 58:30

psadmin.io Stylesheets for Fluid

Last year we released a set of stylesheets to brand your non-production environments. Those stylesheets were built for the Classic UI and not for Fluid. Today we are releasing Fluid versions of the stylesheets.

The main colors are the same, but since Fluid uses a darker color for UI the themes are darker than the Classic versions. Here screenshots of the Fluid Homepage with each theme:

Blue

Green

Grey

Orange

Purple

Red

Yellow

Improvements

One change the stylesheets make beyond the color is adding a button style around the Homepage Tab selection. This should improve the usability of the homepage (thanks to Kyle for idea and CSS).

Environments

Use the colors however you want, but the list below is how I’m using the colors:

  • DEV1 – Green
  • DEV2 – Light Blue
  • DEV3 – Purple
  • TST – Red
  • QA/UAT – Grey
  • SBX (Sandbox and Nightly Refresh) – Yellow

Installation

Installing these scripts is simple. All of the changes are included in a single Data Migration project, so you can import all the styles with the Data Migration Workbench.

  1. Download the latest IO_STYLES_FLUID.zip
  2. Unzip the IO_STYLES_FLUID.zip to your Data Migration file location.
  3. Navigate to PeopleTools > Lifecycle Management > Migrate Data > Data Migration Workbench
  4. Select “Load Project From File”
  5. Select the file location and the IO_STYLES_FUILD project.
  6. Select “Submit Project for Copy”

After the Migration Project is loaded, change the theme for your application.

  1. Navigate to PeopleTools > Portal > Branding > Branding System Options
  2. Select the IO_THEME_xxx you want.
  3. Click OK.
  4. Log out and log back in to see the changes.

Change the Logo

To change the logo, you can upload a new image file to use. You have two options:

  1. Replace the IO_WHITE_32 logo with your own image
  2. Upload a new image and change the Theme Macro Set value for PT_LOGO_IMAGE_NAME and PT_LOGO_IMAGE_NAME_SMALL

Community Thanks

A huge “Thank You” to Sasank Vemana for his excellent blog posts on Branding Fluid and Kyle for his feedback and sharing some of his CSS with the project.

#84 – No Agenda

This week on the podcast Dan and Kyle talk with no agenda. We discuss our week and talk about Portal, PeopleTools Bugs, Fluid, Git, Deployment Packages, Puppet, OneNote, Kanban Boards and more.

Show Notes

  • Portal Projects @ 1:45
  • PeopleTools Bugs and Puppet @ 10:45
  • psadmin.io Community @ 21:00
  • Job changes @ 23:30
  • Spreading the Fluid Excitement @ 25:00
  • Selecting Fluid Nav Images @ 28:00
  • The Git “Trojan Horse” @ 31:30
  • Git Hooks, Puppet Server and getting crazy @ 39:30
  • Changes to the DPK? @ 47:00
  • Kanban Boards @ 57:00
  • Svchost.exe @ 58:30
  • OneNote Templates @ 60:30
  • Kanban Boards and Task Management @ 71:00

Fast PeopleBooks Searching

I want to share a tip Daniel Palmer gave on the psadmin.io Community about faster PeopleBooks searching.

“For the Chrome users: If you want a quick PeopleBooks search you can add a custom search engine by right clicking on the address bar and selecting “Edit Search Engines”. I have added one with the name “PeopleBooks 8.55”, the keyword pb855 and the search url is http://www.oracle.com/pls/psft/search?word=%s&lib=pt855pbr1

#83 – DPK – What We’d Do Different Next Time

This week on the podcast Dan and Kyle discuss changes they would make if they started working on the DPK for the first again. They also discuss setting up Elasticsearch clusters, monitoring Tuxedo queues with Elasticsearch and an annoying Bash on Windows bug.

Show Notes

  • Bash on Windows VPN Bug @ 3:15
  • 9.2 Upgrade Process @ 10:00
  • Monitoring Tuxedo Queueing in Elasticsearch @ 13:30
  • Tuxbeat Project @ 17:00
  • Elasticsearch DPK @ 21:45
  • Elasticsearch Clustering @ 27:00
  • Puppet on Linux @ 32:00
  • DPK Extract Only @ 34:30
  • What we’d do differently with the DPK @ 37:30
    • Co-locating Regions
    • Admin-only Test Servers
    • Config Homes
    • Use Git for managing code and YAML changes
    • Integrate all Puppet code into Classes and Modules
    • DPK Course
    • Use ACM via DPK
    • Go Vanilla

App Capacity Visualization