#186 – Customization Caboose

This week on the podcast, Kyle and Dan discuss migrating customizations when applying patches, and Kyle shares a solutions for hiding and showing special tiles during system maintenance.

Show Notes

  • Hot Topics Overload @ 2:30
  • Customization Migrations when Patching @ 7:45
  • Drag and Drop Tiles @ 16:00
  • Maintenance Mode Tiles @ 20:30

#156 – Open World 2018 Recap

This week on the podcast, Graham Smith and Jim Marion join us to recap Open World 2018. We discuss the new Drop Zones feature, Graham’s view of smart customizations, Jim’s tips for working with the Fluid Homepage, and a review of Cloud Manager 7.

Show Notes

8.55 – Reduce your Customizations!

In Episode 8 of the PeopleSoft Administrator Podcast, we dug into a new feature in PeopleTools 8.55. The Related Content Framework (RCF) gained the ability to map custom code to Component events. This change could drastically change how developers approach customizations. (Thanks to Chris Malek at the Cedar Hills Group blog for posting about this.) The Related Content Framework in 8.55 has the ability to insert custom code into the component processor. This means you can insert custom code without changing any delivered code. You map a custom app class to an existing Component or Component Record event and your custom code will execute before or after the event. You can code customizations and not touch any delivered code! Your app class has full access ot the the component buffer, so you can modify scrolls, page components and more. You can write any PeopleCode that is acceptable in a FieldChange event (no DoSave, etc). That still leaves a wide range of customization that could be removed from delivered code and dropped into a custom app class. Kyle made a great point in the podcast: You could organize your modifications in app packages. For example, group all of your HR modifications in an app packages and each customization could be it’s own class. That would make documentation and knowledge transfer substantially easier.¬† [Kyle] I was thinking about this more. I think something like this would be awesome. Overall package would be per module. Then sub packages would be per component, then the app class would be the PC for a certain event. You could create¬†Component Record subclass under that as well, with their classes. That way, you group classes by component if those components have multiple events customized. For example:
* PreBuild_Pre
* PreBuild_Post
* SavePostChange_Pre
* InsertRow_Pre
* SaveEdit_Post [Dan] There are some limitations though. You can only insert code before or after a delivered event. With a little creativity I think many of the limitations can be worked around. This won’t replace all your customizations, but it’s a great start!

Update: We posted a demo of Event Mapping in action.