Monday, June 18, 2007

PeopleCode Basics

Component Buffer:

Only search Record Fields are available, remaining which are not search key or Alternate Search keys are not available in this buffer.

All Field values of Level-0 record are available, whether all record fields are placed in a page or not.

Primary scroll record fields are available

Only fields of derived work record placed on a component are available. Remaining are not available.

Declared translate fields are available remaining not.

Component Processor:

PeopleTool runtime engine controls the processing of the application from the time the end user requests a component from an application menu through the time that the DB is updated and processing of the component is complete.

Application Processor:

The engine dictates when PeopleCode executes; take care of which event has to fire in which situation.

The Application Processor controls how PeopleSoft manages applications from initial data retrieval through updating the DB.

Through this process the Application Processor applies PeopleCode at specific times.

PeopleCode is PeopleSoft’s own proprietary language, used to incorporate sophisticated business rules into PeopleSoft applications. The language is designed specifically to interact with Component Processor, giving the capability to enhance applications beyond the capability of the PeopleTools.

Using PeopleCode, we can accomplish virtually any editor or validation, in addition to a tremendous amount of online processing. PeoleCode gives the flexibility to set default values, set display characteristics of fields, dynamically derive values for pages, and update other tables based on sophisticated business rules.

We can also place PeopleCode on Application Message, Component Interface and Application Engine Program.

Accessing PeopleCode
PeopleCode programs are accessed using the Application Designer. PeopleSoft treats PeopleCode programs as an attribute of an object definition. PeopleCode may be placed on all of the following:

· Record filed
· Page
· Component (at the component, record, and record field level)
· Menu item (for pop-up menus only)
· Component interface
· Message and Message Channel
· Application Engine

There are 2 ways to access PeopleCode programs by drilling down in the Project Workspace.

1. Existing PeopleCode programs are displayed beneath their associated record field with a lightning bolt icon. Double-click one of these items in the project to display the corresponding PeopleCode program.
2. Right-click a record, field, or PeopleCode event and select view PeopleCode from the popup menu. This displays the corresponding program, or the first encountered, if more than one applies.

PeopleCode is case-insensitive, except for quoted literals.

Referencing Fields in PeopleCode:

PeopleCode programs can refer to any field on any record definition. However, for the program to work, all of the fields referenced must be in the component buffer on the application server while the program is being performed. This is controlled by a process called Buffer allocation.

There are 3 methods of referencing to a field when entering PeopleCode. Regardless of the method used, in PeopleTools 8.4, all fields in a program must be fully qualified. That is, they must reference a specific record in the format RecordName.FieldName.

We can use a shortcut to refer to the field on the current record, instead of typing the entire field name, use the caret (^) character. When the editor formats your PeopleCode, it will replace the caret with the appropriate field name.

Referencing a field Meaning
^ The field is on the current record definition.
FieldName The field is on the current record definition.
RecoreName.FieldName The field is on the different record definition.


As in all types of program code, commenting can prove useful and imformative in PeopleCode. There are 2 different ways to insert comments in PeopleCode.

Remark ;


/* */


Fieldsname = |&||;
&variable = |&||;

If condition Then

PeopleCode applies NOT first, then AND, then OR.

The ERROR & WARNING statements

Error statements display a message to the user, informing him or her of invalid data. Processing stops until the user corrects the data and passes the error test.

Syntax: Error(‘’);

Warning statements displays a message to the user, informing him or her of data that may be invalid. Unlike Error, warning allows processing to continue.

Syntax: Warning(‘’);

The EVALUATE statement

There may be times when we need to analyze the different values of a field. Based on these different values, we many need the system to perform more complex logic. Many nested If statements could be used to accomplish this processing, but the code could become quite messy. A single Evaluate statement can check all possible values of a field.

An Evaluate statement is a more straightforward approach than having a series of If Statements. The syntax for an Evaluate statement is as follows:

When =
When =
When =

An Evaluate statement can have unlimited When clauses.

Evaluate field
When = 1
When = 2
When = 3

Multiple When clauses with no code between them act as an implied Boolean OR. Otherwise no Boolean logic used in a When clause.

The BREAK Statement

In an Evaluate statement, PeopleCode always examines each When clause, even after a match is found. If the values in the different When clauses can never be true at the same time, processing time can be saved by jumping out of the Evaluate statement; to the next PropleCode statement when a match is found. This can be accomplished with a Break statement.

Evaluate field
When = “1”
When = “2”
When = “3”


1. Every PeopleCode program is associated with an Application Designer component and with an event.
2. PeopleCode programs are input or modified in the PeopleCode Editor.
3. PeopleCode is not case-sensitive, except for quoted literals
4. The ‘^’ caret character can be used to refer to the current field in a PeopleCode program.
5. To comment PeopleCode, the /*..*/ or the REMARK (or REM) statement can be used
6. The Evaluate statement allows to check for all possible values in a field
7. Each Evaluate must have a corresponding End-Evaluate.
8. The Break statement takes you immediately out of an Evaluate or looping statement.

The Component Processor

The Component Processor controls how PeopleSoft manages applications from initial data retrieval through updating the database. Throughout the process, the Component Processor applies PeopleCode at specific times.

Reset State and the Search Record

After logging on to the application (or exiting a component), application data is cleared from the buffer. This is called reset state. When the user selects a component from the portal menu, the Component Processor displays an Add or Search page. The Component Processor uses the entered or selected search criteria to identify what data to retrieve.

After the Search

At this point, the Component Processor can retrieve all the data needed for the entire component. It knows which tables to get data from based on the record definitions in the component. It also knows which rows of data to retrieve based on the search key selected. All the rows from the tables used in the component where the search key matches the search key entered in the search process will be selected.

Once all the data is selected, the Component Processor needs to allocate buffer space to hold the application data temporarily on the WebServer while the component in use. The amount of data allocated is determined by the rules of buffer allocation. After the Component Processor has allocated buffer space and loaded the appropriate data, it applies any record defaults, displays the component to the user, and waits for an action.

Field Action Events

The user may then decide to change one of the values of a field. In edit boxes and long edit boxes, a field is considered to be changed when we exit the box and the value is different from when the field was entered. Check box and radio buttons will record a change immediately. Drop-down lists are considered changed immediately when you select a different value.

After each field is changed, the Component Processor does some standard edits, such as formatting and checking against prompt tables. If the contents of the field don’t pass the standard system edits, the Component Processor displays the page with an error or warning message and turns the field red. Until the error is corrected, the Component Processor will not let the changes be saved. If the contents of the field pass the standard system edits, the Component Processor accepts the change into the buffers and displays the page again.

Row Action Events

Scroll areas are used to move through rows of data online. Rows of data within a scroll area can either be added using a Row Insert or deleted using a Row Delete. The Component Processor adds or removes a row of data, then displays the page again and waits for another use action.

Save Action Events

A Component will be saved when the user clicks the Save Button

After the component is saved, the component issues the appropriate SQL updates to the database, after which a SQL Commit command is performed to finalize the changes. The Component Processor then evaluates whether it needs to display a new component. If the user has not requested a new component, the Component Processor displays the page and waits for another user action.

Pop-up Menu

If the end user clicks the pop-up icon next to a field a pop-up menu appears. This can be a default pop-up menu or one that has been defined by the developer. If the user clicks the Related Links button in the component toolbar, the pop-up menu for the page displays. PeopleCode may be placed on pop-up menus. The ItemSelected event is triggered when the user chooses a menu item from a pop-up menu.

PeopleCode and the Component Processor Flow

Every PeopleCode program is associated with one object and one PeopleCode event. PeopleCode events fire at particular times and particular sequences during the course of the Component Processors flow of execution. When an event fires, it triggers PeopleCode programs on specific objects.

Whenever we are coding PeopleCode to enforce a business rule governing your data, you will need to know 3 things.

· WHEN you want the PeopleCode to execute
· WHERE to place the PeopleCode
· WHAT PeopleCode syntax to use

1. Record PeopleCode Events 2. Page PeopleCode Events 3. Component PeopleCode Events
SearchInitSearchSaveRowSelectFieldDefaultFieldFormulaRowInitFieldEditFieldChangeRowInsertRowDeleteSaveEditSavePreChangeWorkflowSavePostChangePrePopup Activate PreBuildPostBuildSavePreCahngeWorkflowSavePostChange

4. Component Record PeopleCode Events 5. Component Record Field PeopleCode Events 6. Component Search Record PeopleCode Events 7. Menu Item PeopleCode Events
RowSelectRowInitRowInsertRowDeleteSaveEditSavePreChangeSavePostChange FieldDefaultFieldEditFieldChangePrePopup SearchInitSearchSave ItemSelected

PeopleCode Categories

The Component Processor performs PeopleCode as it processes a page. There are 6 general areas where the Component Processor performs PeopleCode.
1. During the Search Process
2. Before displaying the Page
3. After field changes
4. After inserting and deleting a Row
5. After page is saved
6. After processing pop-up menus

Search Events

Once a page and action have been selected, a search dialog is displayed. SearchInit PeopleCode performs right before the page is displayed to initialize fields or apply defaults to the search page.

After the appropriate values have been entered into the dialog and the Search push button is clicked, SearchSave PeopleCode will perform.

SearchSave PeopleCode can be used to force the user to enter a value into the dialog, restrict the ranges of codes that can be added, or edit the values entered. Both Search PeopleCode events will only perform if the code is attached on the search record to fields that will appear in the dialog.(search keys and alternate search keys)

Page Startup Events

Before a user can work with a component, he or she must choose a page and action, and then enter a search key. The Component Processor uses that information to load all the data fro the component into the buffers. Before displaying the component to a user, 7 PeopleCode events are invoked:

1. RowSelect
2. PreBuild
3. FieldDefault
4. FieldFormula
5. RowInit
6. PostBuild
7. Activate

After a user completes an action, the Component Processor displays the page incorporating whatever the user changed. As part of displaying the page again, the Component Processor performs, FieldDefault, FieldFormula, and RowInit, PeopleCode again if appropriate. PreBuild and PostBuild are executed only once when the component is built. Activate fires only when the user selects the page.

Field Action Events

2 PeoleCode events are activated when the value of a field is changed; FieldEdit and FieldChange. As its name implies, FieldEdit validates the new value. FieldChange does processing based on the new (and valid) value of the field.

Row Action Events

RowInsert PeopleCode is performed after inserting a new row of data. When a row insert is performed, the Component Processor will also perform RowInit PeopleCode on just the one new row as part of displaying the page.

RowDelete PeopleCode is performed after deleting a row of data.

Save Action Events

The Save icon button tells the Component Processor to take the information that has changed in its buffer and update it to the database. Before it updates the database, it goes through 3 PeopleCode events:

1. SaveEdit
2. SavePreChange
3. Workflow

SaveEdit performs consistency, or relational, edits among multiple fields on a record definition and can also edit multiple rows of data in the buffer. SavePreChange does last minute processing just before the Component Processor updates the Database.

At this point Workflow PeopleCode can trigger a business event. Workflow PeopleCode programs typically review the data in the saved record then decide which business event to trigger if any.

A fourth PeopleCode event, SavePostChange, happens after the Component Processor issues the appropriate SQL commands to update the database. SavePostChange mainly updates other tables based on the new values that were just updated. After SavePostChange successfully executes, an SQL Commit command will be performed on the database.

Pop-up menu Events

If a user accesses a pop-up menu that was defined in the Application Designer, then the PrePopup event fires before the pop-up menu is displayed. This allows a PeopleCode program to conditionally alter the appearance of one or more menu items. For instance, a menu item can be disabled or hidden temporarily. Also, check marks can be placed next to the menu item text. This appearance will only last until the pop-up menu is dismissed. The next time it appears, menu items will start out in a default state.

If the user selects a menu item from the pop-up list that has a PeopleCode program attached to it, then the ItemSelected event will fire.

Using the Add Action

Add Mode processing is handled quite a bit differently by the Component Processor. For rows added with a new search (high-level) key, a flow of RowInit, SearchInit, FieldEdit, FieldChange, SaveEdit, and then finally, SearchSave is processed prior to the user receiving the GUI.

Deferred Processing:

A very important change in PeopleSoft 8 is deferred processing. In PIA all the component buffers are on the application server, and all PeopleCode executed on the application server. This can result in a performance impact when there is a lot of field action processing – that is FieldEdit and FieldChange PeopleCode, along with standard system field edits.

PeopleSoft provides 3 ways to mitigate the performance impact.

First, a field change no longer automatically results in a trip back through the component build stream. In the PeopleSoft Internet Architecture, if an end-user changes a field, but there is nothing to cause a trip to the server on that field, default processing and FieldFormula PeopleCode don’t run. They only run when some other event causes a trip to the server. In other words, if a field is changed and there is no FieldEdit or FieldChange PeopleCode on the field, record defaults and FieldDedault PeopleCode will not be run until some other action causes a trip to the server.

Second, developers are encouraged to put FieldEdit validations in SaveEdit much as possible to save trips to the server.

Third, developers have the option to enable deferred processing, which will automatically defer field change processing until the user save the component. This means that standard field edits, as well as FieldEdit and FieldChange code, will be deferred.

Deferred processing is enabled in the Component Properties dialog, on the Internet Tab. By default, under Processing Mode, the Deferred radio button is selected.

The topic will be continued in the second part.