#111 – ACM Plugins

This week on the podcast, Kyle and Dan revisit the ACM (Automated Config Management). We discuss what the ACM is, how ACM works with the DPK, building custom ACM plugins and how to share ACM plugins.

Show Notes

  • Revisiting ACM @ 1:00
  • Using ACM with the Search Framework @ 5:00
  • ACM and the DPK @ 9:00
  • Building ACM Plugins @ 13:30
  • Plugins that are missing @ 21:45
  • GitHub Repository to Share ACM Plug-ins @ 30:00
  • IDEA – More options for “Copy to File”

Enable Fluid Navigation

If you are on PeopleTools 8.55 or later, Fluid Navigation is enabled by default. But, there are ways to revert back to the Drop-Down Navigation. If you have kept the Drop-Down navigation and want to revert back to Fluid Navigation, there are three configuration changes to make:

  1. Navigate to “PeopleTools > Portal > Branding > System Branding Options” and select DEFAULT_THEME_FLUID for the “Default Branding Option”.
  2. Expand the “PeopleTools Options” Grid (this is collapsed by default) and verify the Branding Application Class:
    • Package Name: PTBR_BRANDING
    • Application Class ID: Branding
  3. Navigate to “PeopleTools > Personalization > Personalization Options” and select PPTL for the “Option Category Level”.
  4. For the User Options HPPC and HPTABLET, change the Default Value to “Fluid”. (Under the “Format” tab).

Log out of the application and log back in to see the changes.

#106 – Purging Cache

This week on the podcast, Kyle finds the ProcessRestartMemoryLimit does not work as expected, Dan finds that the Purge Cache command has changed in 8.56, and Kyle recaps a successful Go-Live for PeopleTools 8.55 and Fluid Navigation.

Show Notes

  • Page and Field CONFIGURATOR Follow-up @ 1:00
  • October CVE Details @ 6:00
  • Understanding ProcessRestartMemoryLimit @ 11:30
  • Purge Cache Change in 8.56 @ 19:45
  • Elasticsearch 04 DPK, POC Patches @ 25:30
  • Unified Nav and My Favorites @ 31:30
  • 8.55 and Fluid Nav Go-Live Success and Issues @ 38:15

#103 – OOW 2017 All-Star Recap

This week on the podcast, an All Star cast joins Dan and Kyle to recap OpenWorld 2017. Mike Ripley, Graham Smith, Sasank Vemana, Wayne Fuller, and Brad Carlson share their thoughts on announcements and sessions from OpenWorld.

Show Notes

  • Mike Ripley on Oracle 18c Announcements @ 2:00
  • The Future of Change Assistant @ 6:00
  • PeopleTools Platform Changes @ 15:00
  • Graham Smith on Cloud Manager’s Value @ 17:30
  • How do we run PeopleSoft Images? @ 25:00
  • Elasticsearch Panel @ 32:45
  • Where to start working with the DPK @ 38:30
  • Graham Smith’s backyard office
  • Sasank on Starting Fluid Development @ 42:00
  • Wayne Fuller on the “2027” Support Date @ 48:00
  • More Details on ClassicPlus @ 58:30
  • Brad Carlson on Fast CPU Patching @ 67:00
  • Brad and Sasank on Syncing People in PeopleSoft @ 77:00
  • Personalizing the User Interface @ 84:00 Location and Time Specific Tiles @ 94:30

#98 – Failover Testing

This week on the podcast, Dan has follow-up on using Hiera with Puppet environments, capturing WebLogic logs in Elasticsearch, and Kyle shares his thoughts on the Solaris “change”. Then Kyle discusses the in depth failover testing and how Unified Navigation behaves when app servers fail.

Show Notes

#97 – Dozens of Us

This week on the podcast, Dan and Kyle discuss strategies to organize and manage Event Mapping code, writing code that other people will use, trying to work with Push Notifications and custom ACM modules. Kyle ends the podcast with a funny story about searching for images.
 

Show Notes

 

#96 – Mom, I’m a spaces guy

This week on the podcast, Kyle discusses how he kept the Supplier Portal in Classic while going Fluid Nav for the rest of the application, Dan shares some Related Content feedback and some App Designer filtering tips.
 

Show Notes

 

Using Puppet Environments with the DPK

Since the Deployment Packages were released with PeopleTools 8.55, one of my criticisms has been that the DPK is a bit of a sledgehammer. If you define multiple PeopleSoft environments on a server and you want to configure one web server, ALL the domains that the DPK knows about are shut down.

Puppet has an Environments feature that lets you segregate your code and data. While the DPK does not support Puppet Environments out of the box, we can use them to make the DPK less of a sledgehammer when managing our domains. (There is still some sledgehammering going on, so go vote for this idea).

While environments let you separate the modules, manifests and data folder, in this post we’ll separate just the data folder. This will let us share a common set of code (the manifests and modules folders) but the configuration of each domain will be different.

If you want to extend this to the modules and manifests folder, copy those into the environment folders with the environment-specific changes. This is useful for testing new code changes or if you want an environment to use a different DPK Role in the site.pp file.

Create Environment Folders

  1. Make a new dev and tst folders under c:\programdata\puppetlabs\puppet\etc\environments

You can have multiple environments under this folder – as many as you want. A strategy that I’m testing is using the database name as the environment name. For this post, I’ll stick with dev and tst

  1. Copy your YAML files from puppet\etc\data to puppet\etc\environments\dev\data and puppet\etc\ environments\tst\data.

Configure Puppet Environment

Under the puppet\etc folder, add (or modify) the puppet.conf file to look like this:

[main]
environment=production
parser=future
environmentpath=c:\programdata\puppetlabs\puppet\etc\environments
hiera_config=c:\programdata\puppetlabs\hiera\etc\hiera.yaml
basemodulepath=c:\programdata\puppetlabs\puppet\etc\modules

This file tells Puppet where to look for your environments, your Hiera configuration, your default module location, and the default Puppet Environment.

Last, we’ll modify the hiera.yaml file in c:\programdata\puppetlabs\hiera\etc to include environments:

---
:backends:
  - yaml

:hierarchy:
  - "environments/%{::environment}/data/psft_customizations"
  - "environments/%{::environment}/data/psft_configuration"
  - "environments/%{::environment}/data/psft_deployment"
  - "environments/%{::environment}/data/psft_unix_system"
  - "environments/%{::environment}/data/defaults"

:yaml:
  :datadir: c:\programdata\puppetlabs\puppet\etc

If you want to share some of the files, like the defaults.yaml or the psft_unix_system.yaml file, you could keep those under the main puppet\etc\data folder. Your hiera.yaml file would look like this:

---
:backends:
  - yaml

:hierarchy:
  - "environments/%{::environment}/data/psft_customizations"
  - "environments/%{::environment}/data/psft_configuration"
  - "environments/%{::environment}/data/psft_deployment"
  - data/psft_unix_system
  - data/defaults

:yaml:
  :datadir: c:\programdata\puppetlabs\puppet\etc

Test the Environments

Once our Puppet changes are complete we can test some builds. When we run puppet apply, we’ll add an additional paratemer: the environment. To build my dev environment domains, I’ll use this procedure:

cd c:\programdata\puppetlabs\puppet\etc\manifests
puppet apply .\site.pp --environment=dev --debug

Once the dev domains are built and running, you can kick off the tst build with:

puppet apply .\site.pp --environment=tst --debug

As the tst environment is building, your dev domains should stay up and not be affected by the Puppet run. If they are affected, you may have some YAML changes that need to be made. Make sure your configuration’s between the environment don’t overlap (e.g, same PS_CFG_HOME and domain names).