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

PUM Dashboard Queries and Backlog Report

Hopefully everyone has had a chance to play around with the new PUM Dashboard delivered in the 8.55 PIs. If not, Logesh from leanITdesigns has a very good write up on it. Dan and I also spend some time discussing it in Podcast #20 – PUM Dashboard. It is basically a new one stop shop for managing the PUM maintenance process. It uses a Fluid dashboard to help keep track of BUGs, customizations and test cases.

I have found the dashboard to be a very nice tool with a lot of promise. That said, I don’t think it is mature enough to really work for ALL your PUM maintenance planning needs. In the near future I can see both Oracle(tweaking the dashboard) and organizations(tweaking their maintenance planning processes) working together to make this dashboard truly useful.

Even before this dashboard, one thing I have been doing for our organization is providing a spreadsheet report that lists all the BUGs we have not yet applied. In theory, this can now be replaced by the dashboard. However, our group is pretty used to this spreadsheet and it gives them a little more personalized control of this data. As the dashboard improves, I’m hoping this report can go away and everyone can just be directed to the dashboard.

Queries

In the past, to generate this report I had to create a “Get Current” change package in PUM. This would of course list all the unapplied BUGs in a grid online. I would export the grid to excel, then copy and paste into the report template. This worked fine, but now there is a better way – leveraging the PUM Dashboard queries.

The PUM Dashboard drives off of a set of queries. These queries all have a prefix of PTIA and can be found under the normal Query Viewer or Manager component in your PI. Here is a list of a few of them:

  • PTIA_BUG_TARGET_DETAIL
  • PTIA_BUG_IMAGE_DETAIL
  • PTIA_BUG_PRODUCT_DETAIL
  • PTIA_STATUS_BY_IMAGE
  • PTIA_STATUS_BY_PROD

I found the PTIA_BUG_TARGET_DETAIL to be the most useful. This query was basically the same output I used to get with my change package grid export. One thing I did add to this detail was a link directly to the BUG Matrix in My Oracle Support(https://support.oracle.com/epmos/faces/BugMatrix?id=YOUR_BUG_ID_HERE). Our group has found this very useful when researching a BUG and wanting a little more detail than what is listed in PUM.

PUM Backlog Report

I have packaged up my spreadsheet report and posted it to GitHub, in case anyone else is interested. Since this report shows all unapplied BUGs from PUM, I have titled it the PUM Backlog Report. The instructions on how to import your PUM data is included in the readme file on GitHub, as well as in the spreadsheet itself. If you have questions or ideas for improvement, feel free to open an issue on GitHub or post in the comments below.

You can find the report on the psadmin.io GitHub site HERE.

pum_backlog_detail

pum_backlog_chart

#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

PeopleSoft System Status Notifications

Do you get notified if an app server, web server or process scheduler go down? If you do, good for you! If you don’t receive notifications, here is a script that will send you notifications.

If you are an admin who doesn’t have access to monitoring tools (and there are lots of you), this post will go over a script I wrote. The script builds a System Status page and sends email notifications. You can run the script on any machine and it will send an email if anything has gone down. A status.html page is also generated so that users can go check on the status for their system.

Status HTML Page

This page and script is something I put together over a few days as a side project. We wanted a page that would give us the status of each component in an environment. This isn’t the most robust script (I’ll explain the limitations in the post), but I wanted to share it so other people could use it. If you rely on end users to tell if you an environment is down, this script can help you out.

All of the code is hosted on GitHub, so go grab it here.

Install Prerequisites

The script is written in Ruby, uses tnsping, uses Mechanize gem for interacting with Peoplesoft, Markdown for formatting, the Redcarpet gem for generating HTML documents, and the Mail gem for emailing status updates. So we’ll need to install all those parts. It sounds like a lot, but it’s pretty simple.

We’ll walk through the installation process. I’m writing the instructions for Windows, but the Linux steps will be similar.

Oracle Client

The script uses tnsping to check the database status. So, we need the Oracle Client installed on the machine. If you don’t have the Oracle Client software, you can download it here

You also need a tnsnames.ora file with entries for all the databases you want to check. You can place the tnsnames.ora file anywhere on the server. The status.bat script sets the TNS_ADMIN environment variable to point to your tnsnames.ora file.

Ruby Dev Kit

We’ll install Ruby and the Ruby Dev Kit (2.2.4 is what I’m using) on the machine where our scripts will run. Download the Ruby installer from here:

http://rubyinstaller.org/downloads/

I installed Ruby to e:\ruby22-x64 and selected the option to “add executables to the PATH variable”.

Next, download the Ruby DevKit from the same site. The DevKit includes tools to build Gems from source code. We need to the extra tools included with the DevKit. I installed the Ruby DevKit to e:\ruby22-x64-devkit.

Open a new command prompt as an Administrator.

  1. e:
  2. cd ruby22-x64-devkit
  3. ruby dk.rb init
  4. notepad config.yml
  5. Add - e:/ruby22-x64 to the end of the file (notice the dash and forward slash)
  6. Save and close the config.yml file
  7. ruby dk.rb install

Follow the instructions here if you have issues with the DevKit installation.

Gems

Ruby has a powerful package manager called “Gems”. The gem command is part of Ruby, so we can install the extra packages we’ll use for our status page.

Open a new command prompt as an Administrator and we’ll install the Gems.

  1. where ruby

Make sure this command returns the e:\ruby22-x64 folder first.

If it’s not listed first, change the PATH envronment variable so `e:\ruby22-x64\bin\ is first.

  1. gem install mechanize
  2. gem install redcarpet
  3. gem install mail

That’s it for the Gems.

Scripts

There are two scripts in the project:

  1. psavailability.rb
  2. status.bat

The first script, psavailability.rb, is the main script. This is where all the processing happens. The second script, status.bat, is a wrapper to set environment variables like ORACLE_HOME, TNS_ADMIN and PATH.

psavailability.rb

Let’s dive into the psavailability.rb script since that is the main part. As I mentioned before, the script is written in Ruby. I’ll be first person to tell you that I’m not an expert in Ruby. If there places where the code could be improved, let me know.

Status Check Flow

I chose to do all my status checking through the application. This is where Mechanize comes into play. I replicate the actions of an user who opens the login page, logs in, and navigates to the Process Monitor page. The main reason for this method was simplicty. I can do all my checks with one library.

+--------------+            +--------------+            +-------------+
|  Web Server  |  +----->   |  App Server  |  +------>  |  Scheduler  |
|    Check     |            |    Check     |            |    Check    | 
+--------------+            +--------------+            +-------------+

The main disadvantage is: if the web server is down, the app server and process scheduler checks will fail. That may not be accurate from a technical perspective, but from a user perspective it would be true. If you can’t log in, you can do anything!

Setup

I’ve moved any variables that will vary from my install to the top. They are:

# ---------------------------
# Change these variables
# ---------------------------
smtpServer              = '<smtp server>'
statusUser              = '<PeopleSoft Username>'
statusUserPwd           = '<PeopleSoft Password>'
homepageTitleCheck      = '<Homepage Title>'
fromEmailAddress        = '<From email address>'
toEmailAddress          = '<To email address>'
deployPath              = '<e:\\path\\to\\PORTAL.war\\>'
# ---------------------------

The script assumes that you will use the same account to access all environments. I created a new account called STATUS and gave it limited permissions. STATUS can log in and open the Process Monitor Server List page. This way I can track logins from the status script, and we give the service account the least amount of security needed.

Another assumption in the script is that your Homepage Title will have similar text. In our case, we use titles like HR 9.2 Demo, FS 9.2 Test, or ELM 9.2 QA for our environments. I check for 9.2 in the Homepage Title to know if the login was successful.

Initialization

The next section is contains some initialization steps. I set the User-Agent to IE 9, but you can change that if you want.

Mail.defaults do
  delivery_method :smtp, address: smtpServer, port: 25
end

affectedEnvironments = Array.new
notify = false

agent.user_agent_alias = 'Windows IE 9'

Then, I create the Markdown table headers for our table. I found it much easier to create the table in Markdown and then convert the table to HTML at the end.

table =          "| Environment | Database | Web Status | App Status | Scheduler | Batch Server | Update Time | Batch Status |\n"
table = table +  "| ----------- | -------- | ---------- | ---------- | --------- | ------------ | ----------- | ------------ |\n"

Last, I read in the URLs.txt file to get the list of environments and URLs to use. The project on GitHub has a sample URLs.txt file to follow.

# Get the list of environments
# the URLs.txt file is a CSV file with the format "DBNAME,baseURL,processMonitorURI"
agent = Mechanize.new
URLs = CSV.read('URLs.txt', {:col_sep => ','})
URLs.shift # Remove Header Row

Checking Status

URLs.each { |environment, loginURL, prcsURI|  

        web_status = 'Running'
        app_status = 'Running'
        database   = 'Running'

We’ll loop through each environment for the status checks. In our environment, we have 25 “environemnts” (prod and non-prod) that we check. I say “environments” because production has 2 web servers and I check each one.

        begin
            t = `tnsping #{environment}`

            if t.lines.last.include? "OK"
                database = 'Running'
            else
                database = 'Down'
            end
        rescue
            database = 'Down'
        end

To test the database, we run a tnsping command. If the response contains “OK” in the last line the ping was a success. If you are thinking to yourself, “that’s not the best way to test the database”, I agree. But this is a the quicket way to get an Up or Down response. (See the Future Improvements section at the end.)

        # Check web server by opening login page
        begin
            signon_page = agent.get(loginURL + '?cmd=login')
        rescue
            web_status = 'Down'
        end

Next, we attempt to load the login page. If the page responds, we know our web server is up.

        begin 
            signin_form = signon_page.form('login')
            signin_form.userid = statusUser
            signin_form.pwd = statusUserPwd
            homepage = agent.submit(signin_form)

            # We updated PeopleTools > Portal > General Settings to include '9.2' in the title (e.g, "HR 9.2 Test"). 
            # If we see '9.2' in the title, we know the login was successful
            if homepage.title.include? homepageTitleCheck
                app_status = 'Runnning'
            else
                app_status = 'Down'
            end
        rescue
            app_status = 'Down'
        end

To check the app server status, the script logs into the application. We grab the form named login and pass in the PeopleSoft user and password. The page returned from the login attempt is stored in homepage. In our case, every environment has “9.2” in the homepage title. If “9.2” is in the title, I know we have logged in and the app server is up.

The field that holds the homepage title is psprdmdefn.descr254.

        begin
            # Build URL for Process Monitor and access the component page directly
            procMonURL = loginURL + prcsURI
            procMonURL.sub! '/psp/', '/psc/'

            server_list = agent.get(procMonURL)
            scheduler_status = ''

            scheduler_status = ['', '', '', 'Down'].join(' | ')
            schedulers = server_list.search(".PSLEVEL1GRID").collect do |html|
                # Iterate through the Server List grid (but skip the first row - the header)
                html.search("tr").collect.drop(1).each do |row|
                    server      = row.search("td[1]/div/span/a").text.strip
                    hostname    = row.search("td[2]/div/span").text.strip
                    last_update = row.search("td[3]/div/span").text.strip
                    status      = row.search("td[9]/div/span").text.strip

                    scheduler_status = [server, hostname, last_update, status].join(' | ')
                end
            end
        rescue
            scheduler_status = ['', '', '', 'Down'].join(' | ')
        end

For the process scheduler, we take the Process Monitor URI and append it to the login URL. In the URL, we pass in ?Page=PMN_SRVRLIST to access to the Server List page. We also substitue /psp/ for the /psc/ servlet. That makes the screen scraping easier since we remove the header frame.

On the Server List page, we grab the grid for the batch servers, drop the header row, and capture the status for each server in the list.

        begin
            logoutURL = loginURL + '?cmd=logout'
            agent.get(logoutURL)
        rescue
        end

Don’t forget to log out!

        table = table + "| #{environment} | #{database} | #{web_status} | #{app_status} | #{scheduler_status} |\n"

        # If a component is down, add the environment to the affectedEnvironments list
        if web_status.include?("Down") || app_status.include?("Down") || scheduler_status.include?("Down")
            affectedEnvironments.push(environment)
        end
}

Last, we append the status for each component into a string and add it to our Markdown table. If any components for the environment are down, we add that environment to affectedEnvironments.

Formatting Output

# Format Markdown table into an HTML table
options = {
  filter_html:     true,
  link_attributes: { rel: 'nofollow', target: "_blank" },
  space_after_headers: true
}

renderer = Redcarpet::Render::HTML.new(options)
markdown = Redcarpet::Markdown.new(renderer, extensions = {tables: true})
tableHTML = markdown.render(table)

This section takes our Markdown table and creates an HTML table.

# Add a style to the "Down" fields
if affectedEnvironments.empty?
    tableStyleHTML = tableHTML
else
    tableStyleHTML = tableHTML.gsub! '<td>Down</td>', '<td class="down">Down</td>'
end

The HTML table has no styles, so it looks plain. I want to highlight any component that is “Down”. We find any <td> with “Down” as the value and add a the class .down to it.

File.write('table.html', tableStyleHTML)

# Combine the header, table, and footer HTML files into one status HTML file
statusPage = `copy /a header.html+table.html+foother.html status.html`

deployFile = `xcopy status.html #{deployPath} /y`

At this point, we write our HTML table to the file table.html. Next, we combine the prebuilt header.html and footer.html files with the updated table.html.

Last, we copy the file to the web location where the status.html file can be viewed.

We have a page with all the links to our envitonments. I added an <iframe> at the bottom of the links page to show the status.html. Anyone who wants to check on an environment can see the status on the links page.

Notify

Now for the fun part – sending a notification. We scheduled the script to run every 10 minutes. But, if an environment is down for maintenace or it’s taking us a while to get it back up, I don’t want to get emails every time the script runs. I want the email to go out once each time an environment is down.

# If the environment is newly down, send the email
# If the environment was already down (exists in 'down.txt'), don't resend the email
if affectedEnvironments.empty?

    # if no environments are down, delete the 'down.txt' file
    if File.exist?('down.txt')
        delete = `del down.txt`
    end
else
    if File.exist?('down.txt')
        downFile = File.read("down.txt")

        affectedEnvironments.each do |env|
            if !(downFile.include?(env))
                # If both conditions (component down, environment not stored in 'down.txt'), send an email
                notify = true
            end
        end
    else # if the file 'down.txt doesn't exist,  the component is newly down
        notify = true
    end

    # Write down environments to file for next status check (will overwrite the existing file)
    File.open("down.txt", "w") do |f|
      f.puts(affectedEnvironments)
    end
end 

If an environment is down, the script writes that environment name to a text file, down.txt. Next time the script runs, it compares the environments marked down (in the affectedEnvironments array) to the file contents. If the environment exists in down.txt, we skip notification. If a new environment is down, we send the email.

if notify
    mail = Mail.deliver do
      from     fromEmailAddress
      to       toEmailAddress
      subject  'PeopleSoft System Status: ' + affectedEnvironments.join(", ") + ' Down'

      # use the markdown table as the text version
      text_part do 
        body = table
      end

      # use the status.html file as the HTML version
      html_part do
        content_type 'text/html; charset=UTF-8'
        body File.read('status.html')
      end
    end 
end # end Notify

Last, create the email and send. I add status.html as the HTML content of the email, and the Markdown table as the plain text version.

status.bat

The status.bat script is a wrapper to set environment variables and invoke psavailability.rb. The status.bat script is what our Scheduled Task calls.

This is the list of environment variables I set:

set ORACLE_HOME=e:\oracle\product\12.1.0\client_1
set TNS_ADMIN=%ORACLE_HOME%\network\admin
set PATH=%ORACLE_HOME%\bin;%PATH%
set PATH=e:\ruby22-x64\bin;%PATH%

After the environment variables are set, we invoke psavailability.rb

e:
cd \
cd psoft\status
ruby ps92availability.rb 

Limitations

There are some (many?) limitations in the script. That is because I wrote the script for current situation (Windows/Oracle) and this was something we built as a side project. Here is a list of the limitations that I know of:

  1. Windows-only
  2. Oracle-only
  3. Does not support HTTPS for websites
  4. Does not support TLS for SMTP
  5. Requires the homepage title to be consistent
  6. Doesn’t check the app server or batch server directly
  7. If an app server is down, and you have Jolt failover set, you may get a false “Running” status.

The Windows and Oracle limitation wouldn’t be hard to fix. If you want to make any changes, I’d be happy to integrate them into the main project.

Future Improvements

Here are a list of future improvements that I’ve thought of:

  1. Slack integration with slack-ruby-client.
  2. Better checks (or second test if web check fails) for database and batch. This could be done via database connections to run SQL statements.
  3. Better checks (or second test if web check fails) for app server domains.
  4. Add Integration Broker checks (messages in Error or Timeout) via SQL.
  5. Add HTTPS support to test Load Balancer URLs.
  6. Add TLS support to SMTP

The project is hosted on GitHub. I’ll merge any pull requests that people want to send.

As I mentioned earlier, this script started out as a way to get notifications. This was a “scratch your itch” type of project. But, if you want to use the script or improve it, you can get all the code over on GitHub.

#19 – Large Scale PeopleSoft with Wayne Fuller (Part 2)

Kyle and Dan talk discuss debugging techniques in SQR’s and App Engines. We also finish our interview with Wayne Fuller this week. Wayne was a great guest and shared tons of great information. We hope you enjoy this rest of his interview.

If you want to contact Wayne, you can email him here.

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