Recently I have seen several customers have problems after upgrades/splits/maintenance where after they login the homepage is returning not authorized errors or the homepage styling is completely messed up.

I was a little surprised to find that the root of many of these issues was actually based on security. In several cases the upgrades or the HR / CS separation process caused a removal of a permission list from the PSCLASSDEFN table, however, the reference to that permission list on the PSROLECLASS table which ties Roles to Permission lists does not remove the reference. This causes the security to have invalid (null) pointers which causes a serious problems for items that are associated to that security and effects the rendering of the home page among other things.

I found that in my case that after we ran a sysaudit report that the entries that showed up in the Security #31 section were the permission list references that were causing the problem. Once resolved all the renderings starting to perform as expected.

PeopleSoft has introduced new functionality in 8.53 and the 9.2 applications called the Data Migration Workbench. This functionality allows for easier migration of data which is directly related to the use of the new PeopleSoft Upgrade Manager (PUM). There has always been issues try to migrate “non” PeopleSoft meta-data objects from environment to environment. So items like data mover scripts and SQR’s always had to be manually migrated.

Part of the Data Migration Workbench is Application Data Sets (ADS). These data sets can be compared and copied, however, there is a whole new security element just for ADS. PeopleSoft delivered the permission list PTPT3500, which ties to the role ADS Designer. Make sure that your Upgrade user has access to this role/permission. Also make sure that the ADS permissions are turned on. Navigate to PeopleTools->Security->Permissions&Roles->Permission Lists, select the PTPT3500 permission, and go to the new Data Migration tab. Add in any access group permissions and under the copy compare permissions make sure it is set to Full Access.

During the application patching I was doing, the PTADS{BUG#} compare step was failing.

PeopleTools 8.53.06 – Application Engine
Copyright (c) 1988-2013 Oracle and/or its affiliates.
All Rights Reserved
Begin Application Engine Process (257,401)
Compare project from repository/area/project: USKANWD21374/Area/PTADS16299507 (257,400)
Message Set Number: 257
Message Number: 400
Message Reason: Compare project from repository/area/project: USKANWD21374/Area/PTADS16299507 (257,400)
User does not have permission to perform Compare from File (257,308)
Message Set Number: 257
Message Number: 308
Message Reason: User does not have permission to perform Compare from File (257,308)
Load from file failed (257,298)
Message Set Number: 257
Message Number: 298
Message Reason: Load from file failed (257,298)
End Application Engine Process (257,402)
Application Engine program PTADSAEPRCS ended normally

After turning on this new security, I ran it again and received the same error. Just to ensure that I was on the right track, I went and deleted the 2-Tier cache (usually c:\ps\{dbname}), and re-ran and everything worked!

Oracle Database will typically initialize and running on the default ip address and port: 1521. However, since this is pretty common knowledge you may wish to change up the ports and/or ip address to force it listen somewhere else.

1) Modify the TNSNAMES.ora file to listen to the specific address and port that you want:
{DBNAME}=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST={IPADDRESS})(PORT={PORT})))(CONNECT_DATA=(SERVER=DEDICATED)(SID={ORACLE_SID})))

2) Modify (create) the LISTENER.ora file to listen to the specific address and port that you want:
my_listener=(DESCRIPTION_LIST=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST={IPADDRESS})(PORT={PORT}))(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1522))))

3) Add the following line to the init{ORACLE_SID}.ora file to force it to listen:
LOCAL_LISTENER='(ADDRESS=(PROTOCOL=TCP)(HOST={IPADDRESS})(PORT={PORT}))’

Replace the {DBNAME}, {ORACLE_SID}, {IPADDRESS} and {PORT} variables. NOTE: this is just an example you may need to tweak this a bit for your specific environment. Restart the database and listener and you should be good to go! Not make sure that your firewall knows about the change otherwise you may cause things to break!

You can use the PeopleSoft classes to encrypt and decrypt values.

To Encrypt a value:

Local JavaObject &SPCipherIn = CreateJavaObject("com.peoplesoft.pt.integrationgateway.common.EncryptPassword");
&vte = "valuetoencrypt";
&encryptedValue = &SPCipherIn.encryptPassword(&vte);


To Decrypt a value:

Local JavaObject &SPCipherOut = CreateJavaObject("psft.pt8.pshttp.PSCipher");
&decryptedValue = &SPCipherOut.decodePassword(&encryptedValue);


When doing the upgrade the upgrade template has you modify the  PTIBUPGRADE.DMS script and you are to set it according to your environment but if you are like most people you won’t have a clue what to set in the script. This script I believe occurs if you are upgrade from anything before 8.49, but that is somewhat unclear from what I have read.  I know I have been encountering this dms for years now and everytime I just shake my head.

Here is what it says: “Edit PS_HOME\SCRIPTS\PTIBUPGRADE.DMS and make the necessary modifications as documented in the script. User level node security and transactional security have been added as of PeopleTools 8.48. Service namespace information, a low-level user on the node, and a low-level permission list for service operations, need to be specified. Consult with your Integration Broker specialist for assistance.”

Most likely you are considered the IB specialist so that is why you are now reading this post.

Firstly, the script is a tools base script so you will want to look for it in your PS_HOME\scripts directory.

Default Namespace – This is based on the XML standard “XML namespaces provide a simple method for qualifying element and attribute names used in Extensible Markup Language documents by associating them with namespaces identified by URI references” see http://www.w3.org/TR/1999/REC-xml-names-19990114/. When IB generates WSDL, SOAP messages we refer to the namespace provided in the service , during the upgrade all the service’s that are created are assigned to this namespace.  Interestingly there is no validation done against this namespace value, and it does not even have to be an HTTP URL,  however, it is a best practice to name one.

Finance: http://xmlns.oracle.com/Enterprise/ERP/services

HRMS: http://xmlns.<yourcomanyname>.com/Enterprise/HCM/services

Default UserID – Starting with 8.48 PeopleTools an inbound service operation can be invoked as a particular user , previously it was the user assigned in integrationGateway.properties.

The user assigned should have permissions to all messages and CI’s.

Finance: VP1  (or a customized user id that has similar permissions)

HRMS: PS (or a customized user id that has similar permissions)

Permission list – IB has now introduced user based security to follow the Peoplesoft security model, by assigning services to permission lists, assigning permissions to roles, and assigning roles to users who in turn invoke the service. All services created during the PeopleTools upgrade will be assigned this permission list:

Finance: PTPT1000

HRMS: HCPPALL