Understanding PeopleCode Current Context functions
By Chris Malek | Sat, Mar 17, 2012
When you start writing more advanced PeopleCode, you will often have the need to pass objects as parameters to functions and class methods. We have a good example of using a Record objects as a parameter that will give you a concrete example of using objects in parameters.
PeopleTools provides several “current context” functions that allows the PeopleCode processor to basically ask “what rowset/row/record/field is trigging this event?” and return that object. This can be very useful when writing generic peoplecode or even basic PeopleCode.
The important thing to note is that these current context function DO NOT return where the current PeopleCode program lives but returns what event and field triggered the event. For example, if you have some fieldChange PeopleCode that calls “myFunction” which lives in “DERIVED.FUNCLIB.FIELDFORMULA” these current context functions will return the objects relating to the rowset/row/record/field that triggered the event. This will make more sense shortly.
Here are the current context functions that I use all the time.
- GetRowset() - Returns the current rowset that triggered the event.
- GetRow() - Returns the current Row object that triggered the event.
- GetRecord() - Returns the current Record object that triggered the event.
- GetField() - Returns the current Field object that triggered the event.
The key thing to note here is the lack of any parameters in the parenthesis on these functions. These are functions and not class methods so they “stand alone” as functions and they have no parameters.
Lets say you have a component buffer that looks like this.
- Z_HEADER (level 0)
- Z_DETAIL (level 1)
Imagine you have a page where Z_DETAIL is on a level 1 grid and you have 5 rows.
KEY1 (field) | KEY2 (field) | SOME_VALUE (field) |
---|---|---|
1 | 1 | 123 |
1 | 2 | 234 |
1 | 3 | 456 |
1 | 4 | 567 |
1 | 5 | 789 |
Now imagine you have some fieldChange PeopleCode on
Z_DETAIL.SOME_VALUE.fieldChange
and the code makes a call
to a function called DERIVED.FUNCLIB.fieldFormula Logger()
whose purpose is to log to a file what happened.
/* DERIVED.FUNCLIB.fieldFormula */
Function Logger()
local file &f = getFile("logger.txt", "A", %filePath_relative);
&f.writeline(GetField().Name); /* Will write out "SOME_VALUE" */
&f.writeline(GetRecord().Name); /* Will write out "Z_DETAIL_" */
&f.writeline(GetRowset().Level); /* Will write out "1" */
end-function;
When some fieldChange event triggers, we would see a file that looks liked this:
SOME_VALUE
Z_DETAIL
1
In the function above, the code actually lives in DERIVED.FUNCLIB.fieldFormula. However, we could “get the current context” by using those current context functions and get information at run time about what is happening.
If you take a look at the source code for the DataDumper Application Package you will see some use of these.
Article Categories
Chris Malek
Chris Malek is a PeopleTools® Technical Consultant with two decades of experience working on PeopleSoft enterprise software projects. He is available for consulting engagements.
About Chris Work with ChrisPeopleSoft Simple Web Services (SWS)
Introducing a small but powerful PeopleSoft bolt-on that makes web services very easy. If you have a SQL statement, you can turn that into a web service in PeopleSoft in a few minutes.
Integration Broker - The Missing Manual
I am in the process of writing a book called "Integration Broker - The Missing Manual" that you can read online.