Locate the new component definition in the new menu definition.
If you need to have the component available from multiple Portal Folder Hierarchies, create a new menu definition for each new location with the same name as the component with a numeric suffix (Ex. _1;_2, etc.).
Background Information:
What problems are we solving here?
Change Management: Ever since PeopleSoft applications arrived, customers have been adding new components and web pages (previously knows as panel groups and panels respectively) to their applications.
Prior to the advent of PeopleSoft Portal Navigation, it was not uncommon for customers to add new components (panel groups) to delivered PeopleSoft menu definitions.
It didn't take very long to determine that this practice would increase the Total Cost of Ownership (TCO), when customers found it necessary to re-integrate the new customer built components into the new versions of the same delivered PeopleSoft menus during an upgrade.
The recommended approach came to be "Whenever possible, customers should add new components to custom(er) built menus. Prior to the introduction of PeopleTools 8.4x this was not considered an optimal solution since menu definitions and navigation within a PeopleSoft application were essentially the same thing.
With the general availability of PeopleTools 8.4x, the linkage between a component definition and a menu definition was decoupled from Portal Navigation.
Thus the recommendation became "Whenever you create a new component definition, place it in a new custom(er) built menu definition." Unfortunately, many customers interpreted this in a very single-threaded manner. Thus they created one or two new menu definitions and added hundreds of components to them.
So what? What's wrong with that?
Just this: When migrating a component from source to target, it should be migrated with its menu definition, portal registry structure, constituent pages and even (under some circumstances) permission lists.
If you have more than one new component under development and both are connected to the same menu, but for whatever reason, not all of the new components are supposed to be migrated from source to target, you would be faced with migrating a menu definition that points to one or more components that are not being migrated.
Prior to PeopleTools 8.4x, this could cause problems. This is no longer the case.
Old habits die hard. Developers refuse to migrate a menu definition that points to a component that isn't there. I can't argue against this if for no other reason than SYSAUDIT will flag this condition as an issue.
If they don't migrate the menu containing the new component, that means that they will have to add the new component to the existing menu definition in the target database, using Application Designer. This is wrong on so many levels. If you want to read more details about why this is a problem, read the first post on this blog.
When faced with the choice of adding 400+ new components to 1 menu definition or 400+ new components to 400+ menu definitions, go with the second choice. I promise you that you will find life so much more enjoyable.
