The following is a list of 9 habits of highly effective PeopleSoft developers, which promote successful migrations.
1.Always set your PeopleSoft Application Designer Tools Options to:
a.Insert object into project when modified and saved.
b.Prompt for related objects
The benefit of setting these Tools parameters is that the work the developer just did stands a much better chance of actually being stored in the project. Absent these settings, it is incumbent upon the developer to manually insert objects into the project. When taking the manual approach, it is not uncommon for record definitions, component definitions and Application Engine Program definitions to be successfully migrated to the target data base, absent new or modified PeopleCode.
2.Use the Save All feature early and often in order to reap the benefit of the above recommendation.
3.Use the Registry Wizard to register your component in the Portal Registry of your source (Development) data base. Don’t use the Portal Structure and Content component on-line.
The benefit of this approach is that you will be able to insert the Portal Registry Structure for the component you just registered into your project, as well as the menu and component definitions. Permission Lists may be inserted into the project during portal registration as well, though not always desired.
If you don’t use the registry wizard, you will have to register the component again in the target data base, which is wrong on so many levels. Portal registration is a development task, which is supposed to take place in the development data base (source), not System Integration, User Acceptance Testing or Production. If you register a component in any target data base, you have invalidated any testing performed in any source data base.
4.Whenever migrating Permission Lists containing menu/component permissions from source to target, make sure that either:
a.The menu definition, component definition and page definition(s) already exist in the target database.
or
b.The menu definition, component definition and page definition(s) are in the same project as the Permission List.
The benefit of this is that it will ensure a successful migration of the menu/component authorizations stored in PSAUTHITEM for the Permission List you are trying to migrate.
If you don’t satisfy requirement a. or b. above, the Permission List will only be partially migrated. The PSAUTHITEM rows will not be present in the target data base. There will not be any indication of this problem within Application Upgrader in the source data base. The Permission List will appear to have been successfully copied.
5.Always annotate your Application Designer Object Definitions (Object Properties descriptions, both long and short) thoroughly. It’s just plain wrong to leave them blank, and insufficient to simply place your name and a date in the description.
If an object was created or modified based upon a formal change request, copy/paste an appropriate amount of the requirement documentation into the long description, as well as what portion of that requirement is satisfied by the addition or modification of the object.
This might not mean much to the developer, but will mean a great deal to project managers downstream during the next upgrade cycle when they need to decide whether or not to carry forward new objects or modifications.
6.Developers should purge workstation cache files early and often, especially before and after a migration or the occasional execution of the VERSION Application Engine program, which is used to reset all VERSION numbers to 1.
Workstation cache should be purged as a precaution before running Upgrade/Compare Reports between source and target data bases, in order to ensure data integrity during the compare operation.
Workstation (2Tier) cache must be cleared after running the VERSION Application Engine Program, and before logging onto Application Designer (in 2Tier mode).
The VERSION Application Engine Program is used to repair Application Server Caching, which can become problematic due to VERSION corruption, which occurs when Application Designer objects are migrated from multiple source data bases into the same target data base.
If a developer does not purge workstation cache before logging onto Application Designer after the execution of the VERSION Application Engine Program, there is a very good chance that this action will result in VERSION corruption once again.
7.Always run Compare Reports between source and target data bases before migrating (copying) projects.
Review the compare reports carefully and make sure that the flags have been set according to your wishes. You have nobody to blame but yourself if you unintentionally delete objects during a “Copy” process.
8.Always read the Copy Reports carefully in order to verify that the copy ran as planned.
Just because the copy process “successfully” ran to completion does not mean it ran successfully.
It only ran successfully if your project and its contents were copied from source to target.
9.Immediately following a project migration, run the SYSAUDIT report. Be certain to check only those flags that correspond to the objects that were just migrated. For example, if you just migrated menus, components and page definitions, you don’t need (nor do you want) to search for problems with query definitions.
The SYSAUDIT program detects inconsistencies between tools tables, which contain the definitions of the objects you just migrated from source to target. It is most useful for identifying what’s missing from your project.
If objects like PeopleCode programs, Application Engine Program sections, etc. are missing from the project after it has been migrated from source to target, the SYSAUDIT program will probably detect this issue before your customer does.
