Effectively Customizing Online Pages with PeopleCode

Effectively Customizing Online Pages with PeopleCode

Customizing delivered pages and components can be a pain for long term support. Every time you customize a delivered pages there are long term costs. Every time you upgrade or apply bundles and patches, those changes have to be reapplied. This reapplication can take time to research, analyze, merge, implement, and migrate. There are several technical approaches to customizing a delivered page. Here are some thoughts on how to implement these with a reduced long term cost in mind.

Let’s say that you have a requirement to hide several un-needed or confusing fields on a page. Imagine this is a self-service page and there are some fields that your organization does not use. The technical staff could take several approaches.

1. Open the page in application designer and change the record field property of visible to false
2. Open the page in application designer and remove the record field from the page
3. Write some Peoplecode to hide the fields

The first two options are going to have some pain points for your upgrade and/or patch team. Every time Oracle delivers a fix to that page, a developer will have to get involved to reapply the customizations. They may have to do further research to figure out why the customization is made. This takes time and effort which equals costs in terms of resources and opportunity costs on other projects at the organization.

The last option (if done correctly) can reduce the long term costs of bundles and upgrades. Let’s explore it in depth.

Let’s say you have a page and your functional staff wants you to hide 3 fields on it because the self service user does not know what the values mean and they just add noise to the page. Let’s say the fields to hide are CURRENT_JOB.POSITION_NBR, CURRENT_JOB.BUSINESS_UNIT and CURRENT_JOB.SALARY_PLAN. We will assume that the page name is SELF_SERVICE_JOB and we will assume that the fields are at level zero.

Here is the best approach you should take.

1. Create a new derived work record. We will name ours Z_PAGE_CUSTOM.
2. Put the FUNCLIB field on the Z_PAGE_CUSTOM record
3. Create a new PeopleCode function in this funclib.

  function customize-self-service-job()
     /* Assuming that CURRENT_JOB is at level 0 */
     getlevel0()(1)CURRENT_JOB.POSITION_NBR.VISIBLE = FALSE;
     getlevel0()(1)CURRENT_JOB.BUSINESS_UNIT.VISIBLE = FALSE;
     getlevel0()(1)CURRENT_JOB.SALARY_PLAN.VISIBLE = FALSE;
  end-function;

Now we have the PeopleCode function to hide the fields we want we just need to call the function. Where should we call this function from? The ideal place is to call it after last piece of delivered code that fires. I generally like to do this from the Component PostBuild event. However there are times where you actually need to put this in the Page Activate code if there is delivered code running there. (See my thoughts on Page Activate Code) The only time I use the Page Activate event is when I am customizing an existing page that has code firing there.

What do we gain from doing it this way?

First by not putting our peoplecode customization in the delivered peoplecode event, it will never be lost during a bundle or upgrade. During a bundle or upgrade application, bolt-on objects are carried forward un-touched. So we are never at risk of loosing the logic inside the customize-self-service-job function. We only have three lines of code in there but imagine if we had 30 or 40. The only risk we run is loosing the call to the function which can easily be put back with one line of code. Since PeopleTools has no version control support out of the box having your core logic isolated from delivered code is a good approach.

Secondly, We let the delivered code changes run to completion then at the very end we override whatever the delivered behavior is. Many developers would figure out some delivered code that was running which may be hiding an un-hiding fields based on some condition and place their code inter-mingled with that vanilla code. This technically works but introduces issues with long term cost of support. If you just let the delivered code run to completion. Then inject your own code at the end of the vanilla code sequence to hide and un-hide fields you get the same end result.

Here are some scenarios where this can be useful:

• Changing page field labels from vanilla
• Hiding and unhiding fields or group boxes
• Overriding text instructions on a page
• Hiding rows of data loaded into a grid or scroll area.