Event Mapping, Drop Zones, and Page and Field Configurator are features designed to reduce the cost of staying current. These features move customizations into a separate, isolated layer so you may apply maintenance with fewer retrofits. In other words, these features remove customizations from the PeopleSoft-delivered codebase.
When should you refactor your customizations to use Event Mapping, Drop Zones, and Page and Field Configurator?
The answer is case-specific, but here are some guidelines to help:
1. Stop Customizing
For new change requests, look for ways to leverage Page and Field Configurator, Drop Zones, and Event Mapping (in that order).
2. Between Maintenance Cycles
If your system is running PeopleTools 8.55 or later, you can begin leveraging Event Mapping immediately. To apply this approach, identify all of your PeopleCode modifications and ask:
Is this a good candidate for Event Mapping?
"Good Candidates" for Event Mapping are PeopleCode changes that can run before or after PeopleSoft-delivered code. With a list of "Good Candidates," refactor each change to use Event Mapping.
The benefit of beginning this process between maintenance cycles is that it sets you up for success during the next maintenance cycle.
The challenge can be motivation. As they say, "if it ain't broke, don't fix it." Which leads to the next guidance:
3. During a Maintenance Cycle
This may be one of the best opportunities to apply Page and Field Configurator, Drop Zones, and Event Mapping for several reasons:
- Applying maintenance will automatically identify customizations through the Compare and Report process. This is your "isolation strategy" worklist.
- The maintenance process forces you to retrofit and/or refactor your customizations.
- Application updates will include new Drop Zone locations and updated features in Page and Field Configurator.
The challenge of adopting these isolation strategies during a maintenance cycle is the added risk of introducing new concepts on an already-stressed timeline.
4. All of The Above!
The best strategy may be a combination of all three. First, stop customizing and adopt isolation strategies for all new requests. Second, look for customizations you created that you can isolate through Page and Field Configurator, Drop Zones, and Event Mapping. This will give you the experience necessary to comfortably retrofit additional customizations during the maintenance cycle.
PeopleSoft Test Framework
Isolating customizations does not eliminate the retrofit step. It reduces the amount of retrofits required per maintenance cycle. Embedded customizations must be retrofitted with every maintenance cycle. Isolated customizations, such as Event Mapping, Drop Zones, and Page and Field Configurator, however, only require a retrofit when they break. And this is the challenge created by Isolation Strategies: Customizations become invisible. They do not show on compare reports. They don't appear on lists of impacted customizations.
If retrofitting shifts from every customization to just broken customizations, how do we find what is broken? PeopleSoft Test Framework regression tests. Every time you isolate a customization, you create a regression test. Regression tests are usually short and trivial to create. When applying maintenance, you run your regression test library to identify what broke, and that list of broken customizations becomes your new, shorter retrofit list.
Want to learn more? We offer on-demand training for several of these isolation strategies:
Or join us for our next Configure, Don't Customize live virtual course!
