Lately, I’ve been using the MsgGetText() built-in function to concatenate adhoc strings in PeopleCode. For example, instead of the following:
Local string &TEXTLINE = "Value of " | &fld1name | " is " | &fld1value | ".";
Using MsgGetText, it can be re-written as follows:
Local string &TEXTLINE = MsgGetText(0, 0, "Value of %1 is %2.", &fld1name, &fld1value);
I find that the latter is easier to read and modify compared to the first, especially if there are a lot of values being concatenated.
What about performance? Wouldn’t the MsgGetText code needlessly query the database for message (0, 0)? Fortunately, I think not. Some tests with SQL trace turned on — and the cache freshly cleared — show that a query to the message catalog for message (0, 0) is never performed by the application server. A wonderful optimization.
The following are a couple of I believe not well-known coding standards for PeopleCode that I strictly adhere to. These are something I don’t see most people or teams are adapting, but something I really recommend looking into for the benefits that they offer.
read more…
When I was reading the What’s New with Batch Processing in PeopleSoft Enterprise Oracle OpenWorld presentation some time ago, the following slide caught my attention:
What are the Problems with AppEngine
- These programs can be complicated – and for a programmer they’re different
- Same logic can be used Batch and Online – Really?
- Different transactional model
- Temp table behavior is very different
- No restartability
- Easy to write a poor performing App Engine Program
- Since the introduction of PeopleCode, poor performing programs are the norm
Admittedly, I don’t have a lot of experience writing batch programs on Application Engine. But I believe the primary reason it is so easy to write poor-performing AE programs is that AE batch programs are better suited to be programmed using set processing. Set processing requires a different mind set to what procedural programmers are used to. I am new to it as well, so I find that this discussion in ITToolbox, and this followup provides valuable insights on how to perform set processing. Steve’s technique of what he calls partial cartesian joins is quite useful as well, especially for those not running an Oracle database.