Last week I was giving a demonstration on Enterprise Portal or as some like to call it the “Interaction Hub”, and as I was asking some questions about their existing architecture I found they had an odd issue.  In their demo environments the new Integration Broker Workcenter comes up without a problem, but in their existing production environments the workcenter page comes up but the left navigation collection pagelet renders with the following message:

This struck me as an odd error message, and after some google searches and a good look through MOS, I could not find anything that generated a solution to the problem.  I did find some notes where invalid XSL caused issues, and I found another issue where the temp directory was invalid on windows 2008 (make sure temp directory exists).

I had the client check to make sure that the production installation table was correct and that the license code was correct, and in both cases they were fine.  So this left me with no answer without digging in.  However, I was working on an upgrade for another client on the weekend and as I was doing the last touch ups on the system I found a DMS script that had the following statement in it:

This statement enables Navigation Collections and the Pagelet Wizard pagelets within an environment. Once this statement was ran, we had success.

There are many reasons node pinging can fail but one of the most common issues I have found for this is caused by the keystore on the weblogic web instance.

Most organizations will load in there SSL certificates and change the default passwords of the keystore. When this happens you have to modify the integrationGateways.properties file to tell it the keystore file name and path and the password for the keystore.

You can modify the file online in PeopleSoft from the gateway setup page or on the backend system by navigating to the PSIGW applications folder on the weblogic instance.

Look for the lines and update them accordingly:

Save the file and try the ping again. They should now successfully ping.

I like to setup the integration broker gateway to use HTTPS, however, usually when you enter in the https gateway:

It will return an error that there is a failure loading the gateway connectors. This is because the SSL Certificate used to secure the website does not have a trusted root certificate within the digital certificates page in PeopleSoft.

Open the certificate and view the root level of the certificate. In windows you can open the certificate and it will allow you export the certificate. Once you get the root certificate (top-level) open click on the export button and select the base 64 x.509 format. Open that certificate file up in a text editor and it should have a BEGIN and END section and a bunch of characters in the middle. Select all the information in the file and log into PeopleSoft and navigate to:

Click on the + button and on the new blank line add a certificate type “ROOT CA” and enter in alias for the certificate you are going to enter. Then click the button to add the certificate and that will open a page where you can paste in your certificate that should be on your clipboard. Click Save and you should now see your root certificate in the listing.

Reboot your application server and clear the cache, and then go back to the gateway and load in your connectors. They should now load without an issue.

I have a site setup that requires SSL in order to show all the functionality of my demo PeopleSoft environments.  However, I have several other requirements for SSL, so I have a WildCard SSL certificate.

According to PeopleSoft wildcard certificates are unsupported however, I have had no problem using them with Weblogic 10.3.0.1 or higher.  I have not tried it with earlier versions, but I really don’t see why they wouldn’t work.

On my first environment I create a CSR (Certificate Signing Request) using the pskeymanager tool.  Next I submit that CSR into my provider (in my case GoDaddy), and I generate a signed certificate which I import using the pskeymanager tool.

Next I go into the console and turn the SSL on and set it to use the custom identity custom trust settings and enter the alias and my vault passwords.  After committing the changes the certificate should be working correctly.

On my next system I install my PIA as per normal, but before I start things up, I copy the pskey file from server 1 to server 2.  This file is located in the <webserver_home>/<domain>/piaconfig/keystore folder.  Now I start the server up and go into the console and setup the SSL exactly the same as I did on server 1.

I have not found a clean way to export the signed certificate out of one vault and import it into a second vault.  But this procedure works like a charm.

When creating a windows server that is going to run application and process servers for PeopleSoft I find a great way to automate the starting and stopping of services.  PeopleSoft delivers a method of installing a service to stop/start the services, which I have seen many people use, but I personally think it is a little buggy. I have experienced weird issues with the services not stopping properly, or if you have multiples and one has a problem you either effect all of them or you have to manually go to psadmin to administer the problem domain. I have also found that having non-administers trying to use the service/psadmin to be tricky.

As a solution to this problem, I have always liked using Windows Scheduled Tasks.  Scheduled tasks can be setup in advanced and you can run either a batch program (script) or the psadmin.exe utility.  When you scheduled a task you also set what user it will run as regardless of who runs it thus allowing a developer to run the script without being the administrator.

The only problem I have had with this is with the introduction of ps_cfg_home and ps_app_home variables.  Typically these can vary for every environment in which case I will create a batch program that sets the variables and then call psadmin in the script.  Then I schedule the task to run the batch program.  In order to run psadmin correctly after 8.50 you have to make sure the ps_cfg_home is set before running psadmin, otherwise it won’t know where the domains are.

For example on my environment I have an environment variable for the ps_cfg_home=c:\oracle\psoft\pt852cfg and my scheduled task is setup to run c:\oracle\psoft\pt852\appserv\psadmin.exe -p stop -d HRDEMO.  This basically tells the system where the HRDEMO domain is stored and to stop the process scheduler.

Other commands:

Application Server Start:  psadmin.exe -c boot -d {Domain}

Application Server Stop: psadmin.exe -c shutdown -d {Domain}   (to “force” down use shutdown! <-note exclamation point)

Process Server Start: psadmin.exe -p start -d {Domain}

Process Server Stop: psadmin.exe -p stop -d {Domain}