This week on the podcast, Kyle and Dan talk about learning to use Git and GitHub, strategies to work as different users in non-production environments, and how to use PSPing to help diagnose performance issues.
This week on the podcast, Kyle shares his experience working with the CompanyInfo Banner, his thoughts on Branding Roles, and his discovery of the Introspection Page for Integration Broker.
This week on the podcast, Jim Marion joins us to talk about upcoming improvements to Page and Field Configurator, and how Federation and Application clustering work with PeopleSoft.
- Training w/ Jim Marion @ 1:00
- Page and Field Configurator Updates @ 7:45
- Federation and Clustering @ 16:15
This week on the podcast, Matthew Haavisto joins us to talk about Fluid, Interaction Hub, Federation and planning for new PeopleTools releases.
This week on the podcast, Sasank Vemana joins us to talk about Event Mapping performance, not doing Selective Adoption to make Selective Adoption easier, and how the Fluid Back button works.
- PeopleSoft Customers @ 2:00
- Chatbot integration @ 5:00
- EM Perf @ 9:30
- Selective Adoption @ 20:15
- Unpublished Bugs @ 27:30
- The Back Button @ 34:15
This week, Kyle and Dan discuss SSH port knocking, a possible MOS API for Weblogic patching, and the excellent DMSViewer tools. Dan also shares some thoughts on the Unified Compare Reports in PeopleTools 8.56+.
This week on the podcast, Dan talks about running scheduled ACM jobs and how that led him to build a powershell wrapper for the process scheduler. Kyle and Dan also talk about spear fishing and being hyper aware for new attacks.
Process Scheduler and Powershell Scripts
The PeopleSoft Process Scheduler supports many different types of tools to run, but one thing it lacks is support to run shell scripts. Thankfully, David Kurtz offered a solution for that a while back, and revisted the solution recently. While making the process scheduler run shell scripts or Powershell scripts isn’t hard, the best part of David’s wrapper script is that it adds a layer to make your scripts API aware with the Process Monitor.
In my case, I have a number of Powershell scripts to run so I re-implemented David’s solution in Powershell. For a detailed description of how to configure shell scripts to run, visit here. The instructions below are an abbreviated version with small changes specific to Powershell.
All of the code is posted on GitHub in the
ps-powershell repository. This is an Oracle-specific script, but it could easily be updated to work with SQL Server or DB2. To get started, download the scripts in the repository to
There are a number uses for bringing Powershell scripts into the Process Monitor. The main use case I see is interfaces that are run from the OS you can now schedule and execute from within PeopleSoft. It’s common to use the Windows Task Scheduler to run Powershell scripts, but users have no visibility as to when the scripts run or if they completed successfully. Scheduling and executing those interfaces from the Process Monitor brings the visibility of the scripts into PeopleSoft where all your batch jobs are logged.
Configure the Process Type
To configure your process scheduler to run Powershell scripts, we need to configure a new Process Type and enable the server to run the new type.
- Navigate to PeopleTools > Process Scheduler > Process Type
- Add a new type called
ORACLEas the Database Type and the Platform as
Otheras the Generic Process Type
- For the Command Line, set it to
The Parameter List is where we pass all of the arguments to our wrapper script. This is a longer string that I’ll break down:
-NoProfile: This tells Powershell to not run any profile scripts that could change your environment. It also helps speed up the start of Powershell scripts.
-ExecutionPolicy Bypass: Depending on your systems security level, you could exclude this option. This temporarily lowers the security policy for Powershell for the script you are running (but only for this script).
-File c:\psft\tools\psft.ps1: This is the location of the wrapper script.
-DBNAME %%DBNAME%% -ACCESSID %%ACCESSID%% -ACCESSPSWD %%ACCESSPSWD%% -PRCSINSTANCE %%INSTANCE%%: These are the required parameters the process scheduler will pass to the wrapper script.
The full Paramter List is this:
-NoProfile -ExecutionPolicy Bypass -File c:\psft\tools\psft.ps1 -DBNAME %%DBNAME%% -ACCESSID %%ACCESSID%% -ACCESSPSWD %%ACCESSPSWD%% -PRCSINSTANCE %%INSTANCE%%
Set the working directory to
Save the new Process Type
Next, we need to allow the new Process Types to run on your process scheduler.
- Navigate to PeopleTools > Process Scheduler > Servers
- Open your server definition (
- In the “Process Types run on this Server” grid, add the
PowershellProcess Type and Save
Last, let’s configure the output format for the
Powershell Process Types.
- Navigate to PeopleTools > Process Scheduler > System Settings
- Click the Process Type Output tab
Otherfor the Process Type
- Check the Active checkbox for “Web” and also the Default checkbox
- Click the Process Output Format tab
Web, and then check the Active and Default checkboxes for the “Text Files (.txt)” row
- Save the changes
Our wrapper script is now configured for use.
Run Powershell Scripts
The wrapper script itself doesn’t do any process besides updating the Process Monitor tables. Next, let’s built a test script to verify we can run Powershell scripts. From the GitHub repository, we will use the
test.ps1 script. Copy the
test.ps1 script to
Next we will create a new Process Definition for the test script.
- Navigate to PeopleToos > Process Scheduler > Processes
- Click “Add a new value”
Powershellas the Process Type
- Set the Process Name to
- Add a Description:
Test Powershell Script
- Click the Process Definition Options tab
- In the Process Security group box, set the Component to
PRCSMULTIand the Process Group to
- Click the Override Option tab
Select “Append” for the Parameter List
The append list is where we pass in commands that the
psft.ps1script will run for us. For our test script, we have one parameter to pass in addition to calling the script. We pass the database name to
test.ps1so it can print the database name.
"c:\psft\tools\test.ps1 -DBNAME %%DBNAME%%"
Make sure to wrap the parameter list in double quotes so that our wrapper script passes the entire string to our
Save the new Process Definition.
Last, let’s test our new
- Navigate to PeopleTools > Process Scheduler > System Process Request
- Add a new run control
- Click the Run button
- In the list of processes, select
PSTESTand verify the output is “Web” and “TXT”
- Click OK
Go watch the process in Process Monitor and refresh the page. You should see the status of the process change from
DONE. When the process is done, go view the output under “View Log/Trace”.
This week on the podcast, Dan talks about a Terraform and Azure lab he attended, and some PeopleSoft 9.2 experiences. Kyle discusses the new Phire Scheduled Migrations and some great use cases for the new feature.
This week on the podcast, Dan shares some Cloud Manager installation issues, we discuss David Kurtz’s PeopleTools Metadata Generator project, and Kyle talks about building community DPK standards.