Interview Question: FieldEdit vs FieldChange

FieldEdit and FieldChange are two events that are triggered when a user changes the contents and leave a field on the page.

So why do we need two events after the field content is modified?

We know that FieldEdit is usually used to perform validations  other than standard system edits (such as Required, data type etc) and FieldChange is used to recalculate page field values.

What happens if I use FieldEdit to recalculate the page field values or FieldChange for validations?

In order to understand the reason for why there are two events, we need to understand how the component processor handles field modification.

When a user modifies the field value and tab out (or leave the field), following processing happens in sequential order.

• Standard system edits are performed .
• If there are no system edit errors, FieldEdit event is triggered.
• If there are no errors triggered from FieldEdit peoplecode, modification to the field value is accepted by the component processor and is updated to component buffer.
• FieldChange event is triggered.

Note that during FieldEdit, content of the field is not accepted by the component processor yet. It is only after successful completion of the FieldEdit without any error message, the content of the field updated to component buffer. This is exactly why we are using FieldEdit for validation.

During FieldChange, field value is already accepted by component processor and is updated to component buffer, hence it make sense to recalculate any other dependent field values in FieldChange peoplecode.

I hope the difference is clear, now please answer my questions. :)

What happens if I use FieldEdit to recalculate the page field values or FieldChange for validations?

PeopleSoft Tracing & Logging

Tracing online People Code and SQL

1. Select Trace at the login screen or add “&trace=Y” to the login URL OR - To set trace flags, click here (use this link.

2. Choose the options in the tracing screen and login.
3. Perform the actions you wish to record.
4. Once complete logout and retrieve the file from the /appserv//LOGS directory. 
The trace file name will include your login name.


Tracing online PeopleCode and SQL (Alternative)

1. Login to PeopleSoft and navigate to PeopleTools > Debug.
2. Choose the options and save.
3. Perform the actions you wish to record.
4. Once complete logout and retrieve the file from the
/appserv//LOGS directory. The trace
file name will include your login name.


Application Engine Tracing
1. Open the process definition
2. Select the overrides tab.
3. Select Append on the parameters field.
4. Enter -TRACE 131 -TOOLSTRACEPC 3596 -TOOLSTRACESQL
143
5. Save the record.


SQR Tracing
1. Open the process definition
2. Select the overrides tab.
3. Select Append on the parameters field.
4. Enter –DEBUG[ABC]… (replace ABC with the debug letters
provided in the sqr, sqc source).
5. Save the record.


Cobol Tracing
1. Open the Cobol SQL process type for the platform you are running on.
2. Enter 255 in the command line field between two forward slashes “//”.
3. Save the record.
%%PRCSNAME%% %%DBTYPE%%/%%DBNAME%%/%%OPRID%%/%%OPRPSWD%%/%%RUNCNTLID%%/%%INSTANCE%%/255/%%DBFLAG%%
4. Run the process and retrieve the COBOL sqltrace from the process monitor.


Tracing Settings
1. Both the process scheduler (psprcs.cfg) and application server (psappsrv.cfg) config files allow for permanent tracing settings as well as setting up trace Masks. psprcs.cfg - /appserv/prcs// psappsrv.cfg - /appserv//

2. Trace Masks are setup to limit the amount of tracing allowed when a user wants to trace through the front end package (see all methods
above).

3. LogFence allows for lower and higher detail tracing with regards to application server standard logging. This is ideal for identifying problems on the application server.

4. To enable the trace link in the Sign on page.
    People-tools > Web-profile.
  
   Web profile > Debugging Tab -> Check the Option - Show Trace Link at Signon

Peoplesoft Row Level Security Search Records

PeopleSoft Row Level Security Search Records

If an organization we are working with is using PeopleSoft as it's ERP solution then depending upon what role we play we do online transactions through various components in PeopleSoft. For example, HR users usually work in Production environment hence use components under Workforce Administration, Organizational Development, Workforce Development, Benefits etc… in order to carry out their daily business.

A Consultant (Technical or Functional) however will mostly works in Non-Production environment hence the components under the menus – Workforce Administration, Set Up HRMS, PeopleTools etc… are the ones where they visits most often to do transactions as required. A consultant at times needs to play various roles in order to expedite certain tasks part of theirassignment. For example: 

• Resolving a production issue by simulating it into Non Prod environment
• Validating a test scenario which is part of implementation
• Fig-Gap analysis

If we just forget about the role that one plays and list out few most common components a user deals with to carry out various transactions then the list will contain:

Transactions on Job data

·       JOB_DATA (Navigation: Main > Workforce Administration > Job Information > Job Data)

·         JOB_DATA_CURRENT (Navigation: Main > Workforce Administration > Job Information > Current Job)

·         ADD_PER_ORG_ASGN (Navigation: Main > Workforce Administration > Job Information > Add Additional Assignment)

·         ADD_HOST_ASSIGN (Navigation: Main > Workforce Administration > Global Assignments > Track Assignment > Add a Host Assignment)

Etc…

Transactions on Personal data

·         PERSONAL_DATA (Navigation: Main > Workforce Administration >Personal Information > Modify a Person)

·         DEPEND_BENEF (Navigation: Main > Workforce Administration >Personal Information > Personal Relationships >Dependent Information)

·         EMERGENCY_CONTACT (Navigation: Main > Workforce Administration >Personal Information > Personal Relationships > Emergency Contact)

·         DISABILITY (Navigation: Main > Workforce Administration >Personal Information > Disabilities)

Etc…

Hold on.. Why am I explaining all this when our topic here is “Row Level Security Search Records in PeopleSoft”?

Well, because all the components mentioned above, use security views as their search record and that is to ensure that a particular user who is doing transactions through these components, can see only those employees that they are allowed to see.I would like to list down those security views along with the components where they are used as search record:

   Components for Job data transactions

·         Job Data (JOB_DATA)  - EMPLMT_SRCH_GBL

·         Current Job (JOB_DATA_CURRENT ) - EMPLMT_SRCH_COR

·         Add Additional Assignment (ADD_PER_ORG_ASGN ) - PERS_SRCH_GBL

·         Add a Host Assignment (ADD_HOST_ASSIGN ) - PERS_SRCH_GBL

            Etc…

   Components for Personal data transactions

·         Modify a Person (PERSONAL_DATA)  - PERS_SRCH_ALL 

·         Dependent Information (DEPEND_BENEF) - PERS_SRCH_GBL

·         Emergency Contact (EMERGENCY_CONTACT) - PERS_SRCH_ALL

·         Disabilities(DISABILITY) - PERS_SRCH_ALL

            Etc…

As you can see, there are various security views created and are used in these components. Based on the component requirement, some of these views search for the employee data rows by EMPLID and EMPL_RCD and others just by the EMPLID.

For example, The view EMPLMT_SRCH_GBL used in Job data component considers EMPL_RCD field while searching the data row when a user hits on the “Search” button in the component search page whereas the view PERS_SRCH_ALL used in Personal Data component doesn’t consider EMPL_RCD filed while searching the data rows.

One easy way to find out the search record for a component, Just open the menu definition under which the component exists, in the Application Designer and locate your component, then right click on it and open the “Menu Item Properties”. Check what the search record for the component is and whether it has been overridden.

So, when the so called “Row Level Security Search Records” come in picture and how they secure the data from a user (HR Admin, Consultant etc…). This is also called Row Level Security in PeopleSoft.

Securing Data rows using Security Search Records (Row Level Security in PeopleSoft)

Let’s take any one of the component mentioned earlier. A new employee “ST01ST20” has been hired in the organization but when HR tries to open their job data through JOB_DATA component:

 

Oops..!  looks like employee doesn’t exist.

Is that what it looks like?  No, instead the HR user is not able to see the newly hired employee because they don't have access to them and this restricted access has been enforced with the use of the row level security view EMPLMT_SRCH_GBLas search record in this component. 

So let’s find out what exactly happens behind the scene and how the security search view works to ensure the unintended employee data shouldn’t be displayed to HR user.

   In the search page, when we enter the EMPLID ‘ST01ST20’ and hit enter:

     

   Hope everything is clear so far and if it is then let’s give data access to the HR user so that they can see the data rows of employee ST01ST20. There are various different ways such access can be given and for now we will just add business unit “AUS01” to the Permission list TEST_PERMSN (Navigation: Main > Set Up HRMS > Security > Core Row Level Security > Security By Permission list).  

  Note that, this access can also be given through “Security by Dept Tree” component    which exists under the same menu. In this method, the HR users are given access to the intended department defined in a Department tree where a particular employee belongs.
After the access is given to HR user let’s see what happens: