What it is?
Event Mapping is a new subcomponent of the Related Content Framework. PeopleTools released Event Mapping with version 8.55. What makes it relevant today is enhancements for 8.56.
Imagine this scenario:
A functional user approaches you with changes he or she would like you to make to a PeopleSoft page. These changes include hiding a couple of fields and changing some labels. For the most part, this is a simple request, but you hesitate to accept the request. Why? Because the user just asked you to modify a delivered definition and you know that you will spend the rest of your PeopleSoft life paying for any simple change you make today.
Because there is business value (and you prefer to remain employed), you choose to implement the requested changes. But you ask yourself, how can I make these changes while minimizing upgrade impact? Historically speaking, a good developer, recognizing that these changes are possible through PeopleCode, would create a FUNCLIB or Application Class to hold custom code, and then call that reusable definition from the appropriate location within the delivered event PeopleCode. With the introduction of Event Mapping in PeopleTools 8.55, we now have a new option: we can map an Application Class event handler into a delivered PeopleCode event. This is a configuration that won’t dirty your compare reports. Since your code is no longer merged into Oracle’s code, your changes remain after applying updates.
What is new for 8.56?
PeopleTools 8.56 introduces the following long awaited enhancements to 8.56:
- You can now configure multiple handlers for the same event,
- PeopleTools exposed the PageActivate event, which is important for some scenarios to work properly,
- Event mapping now supports the Component Record Field FieldChange event, and
- Event mapping works in Component Interfaces (technically arrived in 8.55.09).
How are developers using this new feature?
The most obvious use cases involve changing labels and hiding fields. However, every component customization should be reviewed through the lens of Event Mapping. PS WebSolutions is using Event Mapping with their clients to make the address change effective date display only.
Probably one of the most exciting enhancements to Event Mapping is that it now works with Fluid. Technically, it has been supported on Fluid since its initial release, but demonstrated reliability issues until 8.55.15. What makes Fluid Event Mapping so compelling is that, with Fluid, everything is a component. This includes Homepages, Fluid forms builder, and so on. Logesh Balasubramaniam, from Presence of IT, is using Event Mapping to enhance forms created by the Fluid Forms Builder. Colten Fischer is using Event Mapping to send administrators to a classic homepage from the Fluid homepage. Some GreyHeller customers are using Event Mapping to extend Personal Details to collect additional attributes about employees.
What use cases should I avoid?
Many PeopleCode customizations exist to change business logic. These customizations often require changes to reside somewhere in the middle of an existing event. Event mapping only allows for Pre and Post processing. There are no “inject in the middle” or “replace” options. With that in mind, any PeopleCode change that can’t be categorized as pre or post processing is not a candidate for Event Mapping.
Are there any concerns with Event Mapping?
Yes. One concern is lack of lifecycle management support. When patching or updating a component, there is no indication that an event handler may exist in the event mapping framework. Theoretically speaking, that is the point. Event mapping is supposed to simplify lifecycle management, not create additional tasks. The reality, however, is that any change to a component may impact event mapping PeopleCode. If Oracle removes a field from a page, for example, that field is no longer in the component buffer. Any PeopleCode that references that field will fail at runtime. At this time, Oracle offers no tools to make you aware of this. Nor does it provide any indication that a component has event mapping PeopleCode.
Another concern I have is that code that doesn’t behave as expected. Consider this example:
A user logs a service request because a component is not behaving properly. Based on the timing of the improper behavior, you identify that the errant PeopleCode is in the RowInit event of a level 1 rowset. Armed with that knowledge, you open the RowInit PeopleCode of the component, review the code, and everything looks normal. In fact, there is nothing in that code that would cause the behavior you are seeing in the component. Now what?
If you are like me, you will scratch your head, probably burn a few more hours on it, and then spend even longer digging through a PeopleCode trace, only to discover that some App Class is being invoked even though there is no indication of that App Class in the RowInit event. That App Class is configured into the event through event mapping. Users of dynamic languages are quite familiar with this scenario as the impact is akin to something known as Monkey Patching or Duck Punching. We expect a single source for the truth, but what we discover is there are multiple versions, and it is the last version that wins.
Even with these concerns, do I still use and recommend event mapping? You bet! Event mapping is one of the best features introduced to PeopleTools.