When creating custom single signon PeopleCode it can often appear that the code is not firing.

Single signon PeopleCode is very fickle code, and some regular PeopleCode functions will cause major issues. For example putting in popup messages to debug the code will actually cause the code to fail. Make sure functions like WinMessages, MsgGet, MessageBox, and other interactive information function are not in your code.

Make sure all your function references are actually within the same Record/Field/PeopleCode Event, Single Signon Peoplecode will fail if you put in a function call that is stored within another Record/Field/PC-Event. You also should make sure that the Signon PeopleCode is stored in the FieldChange or FieldDefault event, I always put my code in the FieldDefault.

Make sure the you have a valid userid/password within the execute peoplecode as area of the signon peoplecode activation page or make sure that the user logging into the system has the appropriate privileges to execute the signon peoplecode.

Lastly, Shutdown the application server, clear cache, and restart before attempting another test.

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 in a production environment there are times when it is not beneficial to have the previous login userid showing on the login page.  This is especially true when in kiosk mode where you really don’t want people to know other accounts within the system.

In order to change this setting you need to go into the web profile configuration for the PIA site in question.  The web profile being used will be in the configuration.properties file of the PIA site you are working on.  Typically the web profile will be DEV or TEST or KIOSK or PROD.

Navigate to:  Home > PeopleTools > Web Profile > Web Profile Configuration, select you web profile you want to change:

Under the Security Tab: change parameter – “days to auto fill userid” to 0 (zero).

Save the change and reboot your application server and web server, probably not a bad idea to clear cache here as well.

When you sign onto a PIA servlet, a new connection is established within the application server.  This error can occur occurs when that new connection cannot be established between the Web Server and the Application Server. Some reasons this occurs:

1. In the configuration.properties file for the PIA site the server/jolt port identified is invalid or the web server is unable to communicate to the application server identified in the file.  Web Servers are sometimes configured on a separate subnet in what is referred to as a DMZ to protect outside attacks from the backend systems, the firewall rules will sometimes need to be adjusted to allow this specific communication from web to app server to occur.

The configuration.properties file is located: %PS_HOME%\webserv\{DOMAIN}\applications\peoplesoft\PORTAL\WEBINF\psftdocs\{PIA-Site}\

2. In order to make PIA more dynamic and manageable PeopleSoft introduced web-profiles a few years back.  Web Profiles allow for PIA to managed online within the PeopleTools.  However, in order for the Web Server to access the database to get the web profile settings there needs to be a security user that has access to this information.  PeopleSoft by default has the user PTWEBSERVER with a default password of PTWEBSERVER, there is a delivered role:  “PeopleTools Web Server”, which is linked to the delivered permission list: “PTPT1500”.  You can still log into the site with other user profiles but the defaults from the web profile are not in effect because this user is invalid.  In the configuration.properties file there is a line item for the web profile user and password, and typically they are both encrypted.  Encrypted values start with {V1.1}.  You can enter these values un-encrypted, noting that they are both case sensitive.

In order to encrypt the userid and password, you need to run the PSCipher utility.

3. Make sure the PTWEBSERVER user account is not locked.  Check PSOPRDEFN.ACCTLOCK field it should be = 0. (zero).

4.  Another reason this can also happen is that the web profile listed in the configuration.properties file is not actually listed in the web profile configuration tables.  This happens sometimes during environment refreshing where profiles are renamed/deleted and the reference is no longer there.  Change the configuration.properties file to a valid web profile.

I believe with release of PeopleTools 8.44, they introduced a new feature that requires a user id for internal web server communication to load web profile information from the database and also performance agent information.

By default PeopleSoft delivered the product with the default userid PTWEBSERVER.  Which uses a default delivered role of “PeopleTools Web Server”, which links to the delivered permission list “PTPT1500”.

When you build your PIA (PeopleSoft Internet Architecture) you will be asked to enter a userid and password for this internal web server communication.  If the information is incorrect you will often see the error: “CHECK APPSERVER LOGS. THE SITE BOOTED WITH INTERNAL DEFAULT SETTINGS, BECAUSE OF: bea.jolt.ApplicationException: TPESVCFAIL – application level service failure”.

This user information is stored in the configuration.properties file, which is located in the:

<webserv root>/applications/peoplesoft/PORTAL.war/WEB-INF/psftdocs/<piasite>/ folder (for weblogic)

You will notice that the userid/password are encrypted.  This encryption is done using the PSCipher utility that is delivered with the pia.  I haven’t verified this but in past releases you could enter the userid and password unencrypted and it worked fine, however, I always encrypt them now, so I have tested this against 8.5x.  It should also be noted that the userid and password are both case-sensitive.

To encrypt the password use the PSCipher script located at <webserv root>/bin. PeopleTools 8.51 moved utility files to the folder <webserv root>/piabin. I usually run the setENV first (however, it usually does it for you now) and then run PSCipher <newpasstoencrypt>.  It will return an Encrypted password in the form:   {V1.1}xxxxxxxxxxx= copy this password and place it into the configuration.properties file.

If you are still experiencing a problem, make sure that the user you are trying to connect with has the correct password entered into the user security screens, and that the account is unlocked.

With the release of the 8.51 Tools they also introduced a password for the domain.  You set this password in the configuration of the application server, and you have to enter it for things like integration broker and also in the PIA web configuration.  This password is encrypted the same way in the configuration.properties file.

Happy Configuring!