Sometimes you need to do processing logic in RowInit PeopleCode that looks as though it is pretty harmless. But is it? Is RowInit always the correct place to do that logic?
Personally, I would nearly always recommend using RowInit PeopleCode as it is the “Peoplesoft Way” and PeopleSoft developers and functional consultants are more familiar with it. It is also generally easier to maintain and is database agnostic. But there are certain design patterns where I would consider moving logic to the database. Here is one such example:
A Pagelet that by default shows over 3600 rows. The displayed grid has a HTML area column that is populated during RowInit. This HTML is built with string concatenation operators, the actual HTML being based on some simple criteria. The function used is literally 10-15 lines of PeopleCode. No SQLExec logic or anything that could make the processing slow. Nevertheless, executing this logic 3600 times results in a 5 second delay in the Pagelet build. The underlying SQL executes in under 1 second – the “bottleneck” in this case is in the PeopleCode.
One way to address this is to eliminate the RowInit code completely by including the necessary logic in the the SQL used to populate the grid data through a calculated column in a view. This required adding another table to the view to provide the values used to decide the value of returned HTML string. The join had little or no impact on the SQL execution and even adding the relatively complex CASE statement to build the HTML string had minimal impact.
So what happened when we moved the RowInit logic into the view and just opted to display the value in a HTML area on the grid? Well … the obvious really. We eliminated almost all of the 5 second delay from the presentation of the pagelet. Job done.