What Are The Permissions For The Purge Process, Prcsyspurge?

Purge process - Required permissions

The PeopleSoft Oprid used to start the Process Scheduler, as defined in the Scheduler's psprcs.cfg file, must have the following permissions to be able to submit the purge process:

1) "ProcessSchedulerAdmin" Role.
2) "ReportDistAdmin" Role.
3) The Oprid must have the "Can start Application Server" permission assigned.

4) The Oprid must have the TLSALL Process Group permission assigned.
5) The Oprid must have a valid Process Profile and Primary Permission List.


NOTE: "Can start Application Server" and TLSALL process group permissions must be part of a Role assigned to the Oprid.

Steps to add the necessary permissions:

1) Navigate to PeopleTools - User Profiles - User Profiles.
2) Bring up the record for the affected Oprid.
3) Navigate to the Roles tab.
a) Select the + button to add a new row.
b) Assign the "ProcessSchedulerAdmin" role.
c) Select the + button to add a new row.
d) Assign the "ReportDistAdmin" role.
e) Select the + button to add a new row.
f) Assign the "PeopleSoft User" role.
g) Select the + button to add a new row.
h) Assign the "PeopleTools" role.
i) Save the record.
4) Navigate to the General tab.
a) Take note of the Process Profile value.
5) Navigate to PeopleTools - User Profiles - Permissions & Roles.
6) Select Permission Lists and search for the Permission List from step 4a.
7) On the General tab, select the "Can Start Application Server?" checkbox.
8) Select the Process tab.
a) Select the "Process Group" link.
b) Enter a new value: "TLSALL".
c) Hit Ok to return to the previous page.
d) Save the record.

Check which user is having access to start an app server or process scheduler.

Below is a SQL statement that will help you find what users already have access to start an app server or process scheduler.

select DISTINCT ROLEUSER from PSROLEUSER where Rolename in (select ROLENAME from PSROLECLASS where CLASSID in (select CLASSID from PSCLASSDEFN where STARTAPPSERVER = '1'))

How to Migrate or Copy Security From One Database to Another

NOTE for PeopleTools 8.4x and 8.5x:

Question in 8.4x/8.5x. In PT 8.1x there were scripts to migrate security called IMPOPR.DMS, EXPOPR.DMS, USERIMPORT.DMS, and USEREXPORT.DMS. Where are these scripts for PT 8.4x/8.5x?

Answer: The USERIMPORT.DMS, and USEREXPORT.DMS scripts are still available but have a few new tables. The scripts used in PT 8.4 for migrating ALL security tables are called SECURITYEXPORT.DMS and SECURITYIMPORT.DMS.

In PeopleTools 8.4x/8.5x you MUST also update the Portal registry in the target database in order for your new security to take affect correctly. You will need to run the Application Engine program PORTAL_CSS. See Document:624004.1 - E-PORTAL: PT 8.4x and 8.5x: How to Run Portal Security Synch PORTAL_CSS Process for how to do this. But there are some known issues with this process when copying security. see the PORTAL_CSS resolution above for more information on that.

Also, you will want to have the Access ID, Access Password and Symbolic ID the same between the source and target databases in order to alleviate confusion after migration.  If you choose not to have this before the migration, then you will have to make manual updates to the PSOPRDEFN, PSACCESSPRFL, and PSSTATUS in order to be able to log in.  If you are on Oracle or DB2 databases, then you need to update the PSDBOWNER. 

These scripts export and import all of the PeopleTools security tables.

Here is a list of the tables. Note: For an up-to-date list of tables, please refer to the scripts themselves, that are delivered for your PeopleTools Release.

-- ACCESS PROFILES
PSACCESSPRFL

-- USERS
PSOPRDEFN
PSOPRALIAS
PSROLEUSER
PSUSERATTR
PSUSEREMAIL
PSUSERPRSNLOPTN
PS_ROLEXLATOPR
PS_RTE_CNTL_RUSER

-- ROLES
PSROLEDEFN
PSROLEDEFNLANG
PSROLECANGRANT
PSROLECLASS

-- PERMISSION LISTS
PSCLASSDEFN
PSAUTHBUSCOMP
PSAUTHCHNLMON
PSAUTHCUBE
PSAUTHITEM
PSAUTHOPTN
PSAUTHPRCS
PSAUTHSIGNON
PSPRCSPRFL
PS_MC_OPR_SECURITY
PS_MC_OPRID
PS_SCRTY_ACC_GRP
PS_SCRTY_QUERY

-- DEFINITION SECURITY

EXPORT PSPTDEFSEC_GRPS;

EXPORT PSPTDEFSEC_GRP;

EXPORT PSPTDEFSECINRL;

EXPORT PS_APP_DES_OBJ_CST;

EXPORT PSOPROBJ;

-- PERSONALIZATIONS
PSUSEROPTNDEFN
PSUSEROPTNLANG
PSOPTNCATGRPLNG
PSOPTNCATGRPTBL
PSOPTNCATTBL
PSOPTNCATLANG

-- SECURITY OPTIONS
PSSECOPTIONS

-- SECURITY LINKS
PSUSEROTHER
PSUSERSELFOTHER
PSROLEOTHER
PSPERMLISTOTHER

-- USER ID TYPES
PSOPRALIASTYPE
PSOPRALIASFIELD

-- DELETE USER BYPASS TABLE
PS_BYPASS_TABLE

-- FORGOT EMAIL TEXT
PSPSWDEMAIL

-- PASSWORD HINTS
PSPSWDHINT

-- SIGNON PEOPLECODE
PSSIGNONPPC

-- DIRECTORY
PSDSDIR
PSDSSRVR
DSCONNECTID
PSDSEXT_INSTALL
PSDSSECMAPMAIN
PSDSSECMAPSRVR
DSUSRPRFLMAP
PSDSUSERPRFL
PSDSSECROLERULE
DSSRCH_SBR
DSSRCHATTR
DSSECFILTER
PT_WF_NOT_DSCFG

Please note, that in PT 8.4x/8.5x, it is NOT recommended to use these scripts (userimport/export and securityimport/export) to migrate users/security between two different Tools versions.  The recommendation to sync up users between databases that are on two different Tools version is as follows:

If customers are to migrate data from a content DB at a lower Tools  release to a Portal DB at a higher Tools release, the recommended procedure is as follows:
a) Make a copy (clone) of the content DB.
b) Run a Tools-only upgrade on that DB copy, in order to bring it up to the same release as the Portal DB (which should never be lower than that of  the content DB).
c) Run the UserExport / UserImport dms scripts to copy the Security data from the upgraded DB to the Portal DB (both at the same Tools release)
d)Discard the cloned (content) DB once the Portal DB has received the desired data.
Please note that the Security tables on the content DB should be locked down until this process is completed to avoid updates which would not get propagated.

PeopleSoft Deployment Package command lines

It is possible to install these domains separately on different machines using a DPKs. The DPK will have to be executed on each server with the proper install command.

the bootstrap has options to specify the domain_type (the default is all). You can execute the following command in PowerShell or Linux Batch process:

1. For App Server domain

--env_type midtier --domain_type appserver

2. For App Batch Domain (for App Server & Process Scheduler on on one machine)

--env_type midtier --domain_type appbatch

3. For PIA Domain

--env_type midtier --domain_type pia

4. For a Process Scheduler Domain

--env_type midtier --domain_type prcs

5. This command setups a fulltier (database and midtier) PeopleSoft environment using the DPK zips from the directory /opt/psft/dpks.

--dpk_src_dir /opt/psft/dpks

7. This command deploys just the PS_HOME. It does not setup any PeopleSoft environment. Just installs PS_HOME and none of the other 3rd party components.

--env_type midtier --deploy_only --deploy_type tools_home

[NOTE] For --deploy only commands, above, the “--deploy_type --deploy_only” option is broken in 8.55.01 which is bundled with PUM –HCM Image 16.

There is no workaround. If a customer is taking PUM image, this deploy-only option is not even valid as they need fulltier components.

The issue has been addressed in the 8.55.03 patch of PeopleTools. The Bug# is 22535736 - SERVER DPK - DEPLOY_ONLY WITH APPS DPKS CREATES PI_HOME.

Bad Request

Post go-live of project, some of the users were facing below issue when they were trying to access the application.

Bad Request

Your browser sent a request that this server could not understand.
Size of a request header field exceeds server limit.

Authorization

Reason : Request Header size was big for some profiles which server was refusing

Fix: To fix we have make modification in httpd.conf

  LimitRequestFieldSize 16384


we need to add this parameter under virtual host
<VirtualHost *:80>
   ServerName xxxxxxxxx
   LimitRequestFieldSize 16384
   RequestHeader set WL-Proxy-SSL true
   RewriteEngine on



Use below links for more help
https://stackoverflow.com/questions/10309751/bad-request-your-browser-sent-a-request-that-this-server-could-not-understand

https://serverfault.com/questions/413984/increase-the-value-of-limitrequestfieldsize-in-apache

New Applicant registration fails when registering through IScript_NewApplicant

The problem happens when the applicant tries to register from the link sent as a notification, when a back office user link the applicant to a JOB. The link directs to an Iscript and through the IScript the details are prepoulated for registration. An error occurs when you register where by the applicant is not allowed to register.

The issue is due to a code reference to CLASSIC being executed for FLUID CG. This issue will occur when CG is FLUID only.

Solution: Force the peoplecode to execute only for CLASSIC.

After installing patch 10 and starting servers I was getting JVM not started issue with some iscript issue in it

To fix that you need to reconfigure app servers and process scheduler server domains.

Later Navigate to :

Enterprise Components > Page Composer Administrator > Installation Administration > Synchronize with Installation button 

click the button "Synchronize with Installation button"

Data Integrity Issue on Internal Candidate Gateway

To fix the data integrity issue generally we need to clear app/web server caches, if required run the Version Application engine. But here this issue is more related to particular page only so we followed below document to fix it. As we found this document after checking error in appserver log.

Data integrity issue while applying job.

Data Integrity error

The data structure from the page does not match the data structure in database.This can be caused by a change in record definition while you were viewing the page.This is a non-recoverable error and current transaction will be aborted.

Getting 'Data Integrity Error' After Attaching Resume In Candidate Gateway (Doc ID 2393677.1)

Cause:

It was determined that the cause was due to PeopleCode program version changed in component HRS_CG_APPLY_FL.

Fix :

To resolve this issue, please perform the following:

1. Manually update HRS_CG_APPLY_FL.GLB.HRS_UPDNMFL_DVW.SECOND_LAST_NAME.FieldChange so its version updates from 1 to 129.
2. Re-test applying for a job
3. Verify that adding a cover letter doesn't log out the applicant and no errors occur

Unauthorized Token has been detected by the System. Please signon with your Userid and Password

Fix:

Please follow the document E-PORTAL: "Unauthorized Token has been detected by the System. Please signon with your Userid and Password" when clicking on pagelet links after upgrade to PT 8.56 (Doc ID 2423420.1)

Delete/empty all the hardcoded URIs from all Node definition under the Portal page and retest the functionality.

         Note there is no real Pcode or standalone application setup need to set these URIs, except the case one             wants to set a portal cluster and/or the developer wanted to fix/hardcode the link PCode generation                   towards a single site.

         However the same coding effect can be achieved in PCode without setting the URI's in such standalone               (non clustered) PS database implementation

Cause of the issue:

New security of PT 8.56 will not allow the site to be switched if this is not part of a portal cluster due to the new PT 8.56 node CheckToken being not validated by such site switch.

Setting the URI's for nodes definitions in such non clustered implementation is not expected.

Oppositely, the URIs are expected to be populated in a clustered PS setup, but in such the new node check token value is expected to be set for all the Default local nodes in the cluster

As far the URI for CRM node is pointed (hardcoded) to the Internet site URI, the PeopleCode Generate: PortalURL and ContentURL PCode functions used in the custom pagelet links are always pointed at run-time to the external site.

All this as far the first place that Pcode looks for at runtime, is to the node URI being set or not, and for a standalone PS app these URIs are not expected to be set..

As far here is not a about a portal cluster (PIH <> CRM) but just a standalone/single PS CRM application (with two sites)  there is no real need to set the node URI!

However, be aware that when using the new ACM templates for setting the IB, could pre-populate the node / portal and content URI's with some, values and this is not expected by the portal and security code if you do not really implement a Portal cluster.