0

Migration of Peoplesoft Objects

1. Overview

The PeopleSoft Object migration process is the method of “moving”, or migrating objects and lines of code from the development to the production environment in phases, after thorough functional testing.

The PeopleSoft DBA generally performs migrations to the production environment at the request of an application developer or functional analyst.  Developers are permitted to perform migrations between the development and test environments. Developers need DBA assistance when updating the database with new tables, views, and PeopleSoft Security other than non-development environment.

After unit testing the change in the Development environment, the PeopleSoft DBA is notified with a request to move the project from the Development environment to the Test environment. The PeopleSoft DBA uses the upgrade copy facility to copy the changed set of objects into the Test environment. The migrated project in the Test database undergoes more rigorous testing.  Usually, one or more regression test sets are run to ensure that the issue is resolved and that the change does not adversely effect mainstream processing.  Finally, the project is migrated into the Production database.  If a problem is found at any stage in the process, then the issue is sent back to the developer and the process begins all over again. It is highly recommended that PeopleSoft objects move from development to test environment and then from Test to Production.

2. Assumptions

Listed below is a set of variables that are referred in the document and what they denote:

1. DMO – Demo Database
2. DEV  – Development database
3. TST  – Test database
4. PRD –  Production database
   

3. PeopleSoft Object Migration Steps

The following section describes the steps for migrating changes and fixes to the production environment and the use of the various databases in each phase.

Step 1 – Copy PRD

In this step, the PeopleSoft Administrator makes copies of the PRD database to create new DEV and TST databases.  These databases should represent the current client configuration in the Production environment, with test transactions in place to facilitate the testing of changes and fixes.

Step 2 – Develop / Install Changes

Client-requested changes are developed and Unit Tested in the DEV database.  PeopleSoft patches & fixes are installed and tested in DMO, then in DEV. The DEV environment is where problems and issues are identified and resolved, and where the Change Control scripts are developed which will ultimately be applied to TST, and PRD databases via change control.

Step 3 – Migrate Changes to TST

Using the Change Control scripts, the PeopleSoft DBA moves Objects, Lines of Code and translate values as per the request from the developer or as required by the PS patch/fix from DEV to TST.

Step 4 – Test Changes in TST

Perform Integration Testing of all changes in the “clean” TST database.  This process tests the validity of the changes/fixes, and the validity of the Change Control scripts.

Step 5 – Create SYS/QA (Depending Upon Client dB standard)

Make a copy of the Production database (PRD) into SYS/QA.  The SYS/QA database provides a final check of the changes and Change Control scripts using the “live” database contents.

In the absence of a SYS/QA database, all system and final testing will be done in TST.  The TST database provides a final check of all changes and Change Control scripts using the “live” database contents.  In such instance, using the Change Control scripts, the PeopleSoft DBA moves all changes from DEV to TST.

Step 6 – Run Scripts to SYS/QA (only if SYS/QA exists)

Using the Change Control scripts, the PS DBA moves all objects, lines of code and translate values from TST to SYS/QA.

Step 7 – Perform Final Testing in SYS/QA (only if SYS/QA exists)

This is similar to the testing done in Step4 in the TST database, only this time it is done against a snapshot copy of the production database. This final test verifies once again that the migration scripts are correct, and that no changes have occurred in the production database that have escaped the Change Control process, such that the testing done in TST is invalid. 

Step 8 – Run Scripts to PRD

Using the Change Control scripts, the PS Apps DBA moves all changes from TST to PRD.

Note:  To “state the obvious”, it should be ensured that a successful backup copy is made of the PRD database before the migration scripts are run.

Step 9 – Delete SYS/QA (only if SYS/QA exists)

Once it is assured that all changes have been successfully installed in PRD, and the production system is stable and operating properly, the SYS/QA database may be deleted.

4. How are objects tracked?

In PeopleSoft 8.x, changes to objects are tracked using the contents of the PSRELEASE table, and the value of two fields, LASTUPDDTTM and LASTUPDOPRID, used in the PeopleTools tables.

The PSRELEASE table contains two fields, RELEASELABEL & RELEASEDTTM.  The second field in this table, RELEASEDTTM, stores a date/time stamp for the current release level and all prior release levels.

The LASTUPDDTTM field in the PS<object>DEFN tables—such as PSRECDEFN, PSPNLDEFN, and so on—stores a date/time stamp of when each object was last modified.  The LASTUPDOPRID field stores the operator ID of the user who made the modification.  If PeopleSoft made the modification, the proprietary ID “PPLSOFT” is used.

Note: Security Administrator prevents the creation of an operator named PPLSOFT.

If an object definition is defined differently in the source database than in the target, check to see whether either object definition has changed since the comparison release.  If the object’s LASTUPDDTTM value is greater than the RELEASEDTTM value for the comparison release level (stored in PSRELEASE) the object has changed.  If the object’s LASTUPDDTTM value is equal to or less than RELEASEDTTM the object has not changed (since the comparison release).

Irrespective of whether the compared object has changed or not, check whether the object has ever been changed prior to the comparison release by an operator other than PeopleSoft (LASTUPDOPRID <> ‘PPLSOFT’).  If yes, the object is identified as a customization.

5. Object Status

After determining the Report Action, Application Designer defines the status—in both the source and the target—of each object to be Compared or Reported.  The following table explains the various status types:

Unknown: Object has not been compared.  This is the default status for all objects inserted manually into a project and the permanent status of all non-comparison objects.

Absent: The object was found in the other database, but not in this one.  When upgrading to a new PeopleSoft release, all the new objects should have absent status in the target database.

Changed: The object has been compared, its LASTUPDOPRID value is ‘PPLSOFT’, and its LASTUPDTIME value is greater than the date/time stamp of the comparison release database.  In other words, PeopleSoft modified the object since the comparison release.

Unchanged: The object has been compared, its LASTUPDOPRID value is ‘PPLSOFT’, and its LASTUPDTIME value is less than or equal to the date/time stamp of the comparison release database.  In other words, PeopleSoft last modified the object prior to the comparison release.

*Changed: The object has been compared, its LASTUPDOPRID value is not ‘PPLSOFT’, and its LASTUPDTIME value is greater than the date/time stamp of the comparison release database.  In this case, the customer has modified the object since the comparison release.

*Unchanged:    The object has been compared, its LASTUPDOPRID value is not ‘PPLSOFT’, and its LASTUPDTIME value is less than or equal to the date/time stamp of the comparison release database.  In this case, the customer last modified the object prior to the comparison release.

The object has been compared and is defined the same in both databases.  When an object in one database has this status, so will its counterpart in the other database.  This status would never be seen when performing a database comparison because in that case, the project is only populated with objects defined differently.  However, it can occur when performing a project comparison because in a project comparison, the project contents are static; the project is not repopulated based on the comparison results.
Click Here To Learn PeopleTools >>
Application Designer assigns default actions for each object, depending on what needs to be done to make the target database consistent with the source—the major goal of a comparison upgrade.  These actions cannot be changed, although it can be decided whether or not to accept each action.  Action types include:

Copy                Object will be added / replaced to the target database.

Delete               Object will be deleted from the target database.

None                No Action

One of these action types is assigned to every object in a comparison project and in the Upgrade Reports.  These actions are not necessarily carried out during the copy process, however.  The Upgrade setting makes that determination.

6. Stamping a Database (Application Upgrade, Major Release)

After successfully copying a project into the target database, it should be “stamped” to reflect the fact that it has changed from its previous customer release level.  This will help identify modifications made subsequent to current version of database.

Note:  When upgrading to a new PeopleSoft release, this step is required, the database would be stamped with the new PeopleSoft release level

To stamp the target database when migrating from Test to QA only

1. In PS 8.x, Select Tools, Upgrade, and Stamp Database.

The Stamp Database dialog is displayed:

Stamp Database Dialog

Use this dialog to specify, and stamp the database, with a new Customer Release level.

 

1. Enter the ASP Issues Reported Customer Release value and click Stamp.  The stamp database option is selected as follows:

Tools>>Upgrade>>Stamp Database

Note: The new Customer Release value must be greater than or equal to the previous value.

7. Synchronize Physical Structures of your Tables

Once the copy has been completed, the physical structure of the tables will have to be synchronized with the new definitions and systems components that were merged into the database.

1. SQL Create Tables – This function should be used to create all new tables that were added to the target database during the upgrade copy

1. SQL Alter Records – This function should be used to alter all tables (without deleting)

8. Audit the Database

Run a SYSAUDIT / DDDAUDIT report on both databases before and after migration to see the difference, and to keep track of the status of the objects within the application. 

This is to ensure that all the object definitions for the application in both the source and target databases are in sync. If there are any problems reported, fix these problems with top priority.

9. Migration Paths

The following flow chart illustrates the recommended migration path for patches, service packs, and PeopleSoft Hosting customizations as well as future upgrade releases.

10. Conclusion

The migration of PeopleSoft objects should be carried out with great care and accuracy. Care should be taken to ensure that any changes made to the objects, does not have any impact on the functionality of the existing application. If the object changes the functionality, then it should deliver the desired functionality. Hence, testing of the application after applying the changes  is a vital step in the migration process.
Click Here To Learn PeopleTools >>