DriveSolutions

Listed below are some of the various issues related to security and measures to be taken while and before carrying out an implementation, upgrade or support maintenance in PeopleSoft:

1. 1.       Implementation:

During Initial setup:

• When developmental/prototype systems are initially installed, the system or security manager must change all default Operator IDs and passwords

During Analysis:

• Analyze the functional requirements of the client.
• Checking for feasibility in PeopleSoft system.
• Giving multiple options to the client for implementing a business process.
• Identifying the dependencies due to the implementation of the business process.
• Trying to modify as much as the delivered component rather than implementing the entire new business process.
• Following specific standards (Naming convention, Documentation standards, etc) in development/implementation either PeopleSoft standards or client specific standards.
• Analyzing each implementation work for required hours for development
• Organizing the team which includes both technical and business process expertise
• Studying the security structure of the client.
• Analyzing the department structure followed by the client and creating a security map.
• Map out authorizations that correspond to menus/functions of transactions and functions of the business process
• Compare system supplied authorizations and profiles for each team to business process
• Test and document profiles/rights thoroughly
• Creating a proper unit test documents to test each business process thoroughly.
• Creating a separate test environment which includes all possible client data to test all possible scenarios.
• Providing client demonstration of each business process once implemented
• Keeping track of all the change records to the business process implemented
• Keeping track of all the objects to be migrated. To avoid migrating delivered/unchanged objects and to avoid multiple migration of the same objects
• As a standard, we need to come up with a Techno-Functional task on all our future projects to handle security with much expertise.

1. 2.       Upgrade:

v  In an upgrade, we need to crosscheck with all the permission lists used in the Older Version to that of the Source Version.

• For example, the delivered permission lists like DPALL, PPALL, etc have been replaced with Permission lists like HCDALL, HCPPALL, etc respectively. Henceforth the OPRID being used will also have to be updated along with the new permission lists.
• We can very well identify that the old permission lists are used, when a user is not able to select the appropriate process scheduler or unable to find his process scheduled in the process monitor, once he gets to the run control page.

v  In order to make the Object Security in sync between the development and test environments, it is mandatory to define a clean Migration path.

v  Tables like PSOPRDEFN are critical tables that cannot be in sync between the old version production and our source database.

v  The security faces some real issues when the components are moved, for e.g., from one place in 8.8 to another in 9.0, which eventually changes the Whole Person model.

v  It is recommended to establish a standard to carry forward the changes that would happen in the production environment

• When we do the final cut-over, fields like Operator Password, Account locked indicator, etc. must come from the Old version’s production environment
• Fields like Row Security class, process profile permission lists, Default navigation permission lists, etc. need to come from the source database (Assuming this has been moved from the test environment to the source database).
• New Users added in the production environment needs to be added again in the new version database.
• Users/User Roles added or deleted in production needs to be added/deleted respectively in the upgraded environment.

Listed below are some of the many issues that we come across during an upgrade:

v  Copy user profile does not update fields on PSOPRDEFN table correctly

v  Forgot Password Does Not Trigger a Message for the New Password

v  Password History error ORA-01861: literal does not match format string

v  Copy User Profile adds EMPLID of cloned user to PSOPRDEFN table

v  USER_PROFILE SYNC Not Updating ID Type Correctly

v  Change password does not follow password history rules

v  User Profile Copy does not update the user’s description correctly

v  PASSWORD hints do not translate when using alternate languages

v  USER_PROFILE Message error “Cannot insert NULL into PSOPRDEFN”

v  VERSION Field for OPRID on PSOPRDEFN is Not Getting Updated

1. 3.       Support/Maintenance:

The following steps will have to be performed regardless of if you are using Change Assistant or not:

• Do some sanity checks in Demo
• Run compare reports
• Apply the maintenance in the next environment (development)
• Reapply customizations
• Apply the maintenance plus customizations in the next environment (test)
• Test
• Deploy to Production

• To avoid audit issues, un-check the authorized check box from the relevant permission list for PI_EXTRACT_RULE component of INVENTORY_ASSETS menu if the component still exists.