Skip to content

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:
* IO_RCF_HR
* JOB
* PreBuild_Pre
* PreBuild_Post
* SavePostChange_Pre
* JOB_JR
* 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.

6 thoughts on “8.55 – Reduce your Customizations!”

  1. Pingback: 8.55 – Event Mapping Demo – psadmin.io

  2. How would this affect the new PUM Analytic features that identify customizations tied to specific bug fixes within a change package? Would this make identifying impacts when applying updates much more difficult?

    1. Sean – that is a very good question, and I don’t have an answer (yet). I think you would want the PUM to flag objects that have custom code mapped so you know to test that custom code.

      1. Without trying it yet, I believe this feature works by importing “custom” projects into PUM. So I think as long as you included the component, even if it was technically unchanged, in these projects they would be flagged in PUM as a customization.

    2. Sean – had a nice chat with Oracle today and they said “No, the PUM won’t flag objects that are mapped as customizations.” But they are aware of the limitation and know that is something people will want. Kyle’s suggestion to add the objects to the custom project would be one way to have the PUM flag the mappings.

  3. Hi,

    Does anyone have any idea/faced similar issue where a record.save or record.insert does not work with the EMF on a Component SavePostChange code. I mean the code does successfully fire and goes to sucess as well but then at the end the intended changes are not there in the database. I looked at the trace and it clearly shows that the changes are roll backed after the processor exits the code of the EMF.

Leave a Reply

Your email address will not be published. Required fields are marked *