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!

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

When starting the install of Oracle Database Server there always seems to be a few items that either you are just suppose to know or you spend a day banging your head against the wall trying to figure out what you need to do to get the install up and running.

First item, is creating a database user and group for the install. Do this as the root user:

# groupadd -g 1001 oinstall
# groupadd -g 1002 dba
# useradd -u 1002 -g oinstall -G dba oracle
# passwd oracle

Next, you need to setup X11 forwarding. Modify the /etc/ssh/ssh_config file to allow forwarding: ForwardX11 yes. I personally use BitVise SSH Client and Xming in order to access my SSH environments. In the Xming client, I change the offset to 10 from the default of 0. In the SSH Client, enable X11 Forwarding and set it to 127.0.0.1:10. On the Unix box, install the xauth rpm using yum install xauth. Connect as the oracle user (or psoft) and create the xauthority file, command: xauth add 127.0.0.1:10 . 12345678900987654321123456789009 – you should be able to validate that x11 works by running xclock – if you see a clock, you are golden! If you see the error: Warning: Cannot convert string “” to type XftFont, do a yum install xorg-x11-fonts*

Firewalls can be a bit of a problem, and you will want to make sure that the iptables firewall allows the database to talk to machines that will be connecting to the database. In this example 10.100.120.10 is my application server connecting to the database server 10.100.120.20:

-A INPUT -s 10.100.120.10 -p tcp -m state –state NEW,ESTABLISHED -m tcp –dport 1521 -j ACCEPT
-A OUTPUT -s 10.100.120.20 -p tcp -m state –state ESTABLISHED -m tcp –dport 1024:65535 –sport 1521 -j ACCEPT

RPMs need to installed in order to make the install work correctly, you can manually do everything or you can automate the application by:

# cd /etc/yum.repos.d
# wget https://public-yum.oracle.com/public-yum-ol6.repo –no-check-certificate
# yum install oracle-rdbms-server-11gR2-preinstall
wget https://public-yum.oracle.com/RPM-GPG-KEY-oracle-ol6 -O /etc/pki/rpm-gpg/RPM-GPG-KEY-oracle –no-check-certificate

RPM Libraries need to be installed in order to make the OUI work:
binutils-2.17.50.0.6
compat-libstdc++-33-3.2.3
compat-libstdc++-33-3.2.3 (32 bit)
elfutils-libelf-0.125
elfutils-libelf-devel-0.125
gcc-4.1.2
gcc-c++-4.1.2
glibc-2.5-24
glibc-2.5-24 (32 bit)
glibc-common-2.5
glibc-devel-2.5
glibc-devel-2.5 (32 bit)
glibc-headers-2.5
ksh-20060214
libaio-0.3.106
libaio-0.3.106 (32 bit)
libaio-devel-0.3.106
libaio-devel-0.3.106 (32 bit)
libgcc-4.1.2
libgcc-4.1.2 (32 bit)
libstdc++-4.1.2
libstdc++-4.1.2 (32 bit)
libstdc++-devel 4.1.2
make-3.81
sysstat-7.0.2

Well, I have just had my first full exposure to the glory they call Oracle Secure Enterprise Search!  All I can say is damn, that was NOT easy.

The documentation is pretty good that I found, and maybe it is easier on a fresh install but I was doing the setup on an existing environment that I had just upgraded.  The upgrade was for Finance from 8.9 to 9.2.  In the 9.2 application VERITY is no long supported, and the PeopleSoft Search Framework only supports Oracle Secure Enterprise Search (O-SES).  The first trick is to download it from edelivery and in my case I installed the software on my batch processing server.  This install will install a full Oracle database with a webservice that by default runs on port 7777.  There is a bunch of setup that needs to be done to get this working, but the documentation I had for the install was very good for this part.

Some of the next parts I thought were a little difficult to follow, and so the first item is, I used my system start user as my main user, and made sure it had the following roles:

Search Administrator, Search Developer, Search Query Administrator, Search Server

I also have a custom permission list that this user has access to and I made sure that the permission was assigned the search group: PTPORTALREGISTRY.  This appears to be a new security element in the permission lists.

The new Search Framework uses a ton of IB service operations to do all of its work, and one element you need to do is set the Portal Content & Portal URI text fields on the Node for all the local nodes, otherwise the search results will return incorrect content reference paths (extra:  don’t forget the “/” at the end of the URI).

Now, I also inactivated all my integration broker routings for the default local node after the upgrade so no IB would unnecessarily be taking place.  This might have been a bad idea, but old habits are hard to break.  Since O-SES uses the IB for its Search Framework, the following Service Operations need to be active with the routing turned on!

Service: PT_SES – Service Operation: PT_SES_CREF_GET, PT_SES_USERSEC_GET, PT_SES_INIT,

Service: PTSF_META_DATA: Service Operation: PTSF_GET_GROUP_CAT_LBLS, PTSF_GET_SRCH_CAT_DET, PSFT_GET_SRCH_GROUPS

Service: PTSF_SECURITY: Service Operation: PTSF_AUTHENTICATEUSER, PTSF_GETSECATTRVALUES, PTSF_GETUSERROLES, PTSF_POSTPROCESS_FILTER, PTSF_VALIDATESRCHUSER, PTSF_VALIDATEUSERROLE,

Service: PTSF_SES_FEED – Service Operation: PTSF_CRAWLER_CFG, PTSF_SES_CRAWLSTATUS, PTSF_SES_GET_CONTROL_FEED, PTSF_SES_PROCESS_ERRS, PTSF_SES_SCHEDULED_FEED

Service: ADMINSERVICE:  Service Operation: CREATE, CREATEALL, DELETE, DELETEALL, EXPORT, EXPORTALL, GETAPIVERSION, GETSTATE, START, UPDATE, UPDATEALL

Service: PTFP_FEED – Service Operation: PTFP_GETPREPUBFEED  (not 100% sure on this one, but I turned it on along the way).

Make sure you add the PTPORTALREGISTRY to the Home Page Context Type, I added mine and made it default.  I also found that I was getting no returns and then after a day of thinking about things I tried again and everything appeared to be working fine.  I believe that the system was bounced web and app during that time, so if all else fails that might work!

Good Luck!