How can we have DYNAMIC Prompt table for Record Fields?

Most of the times we would have faced a requirement of having Dynamic prompt table for Record Fields. Also PeopleSoft itself very much utilizes Dynamic Prompt table. How can we achieve the same in our project????

Here we go

This is accomplished by 2 ways

1. Using EDITTABLE fields for Prompt Table
2. Using Dynamic Views
3.  

1. Usage of EDITTABLE Fields

In this method, Prompt table property of Record Fields should be assigned with %EDITTABLE value. Actually what does it mean????

Prompt Table value for the Record Field is populated from the Record Field DERIVED.EDITTABLE value. The Record Field DERIVED.EDITTABLE should be assigned with value either in one of the Peoplecode events (Either in FieldChange or FieldEdit or RowInit events). This is simply done by

DERIVED.EDITTABLE = “PERSON_NAME”;

Note: EDITTABLE Field should be present in the SAME Page, where Record Field (In this case, The Field is nothing but EMPLID) is also referred. If the Record Field is not coming under Component Search Record Field, there is no need for placing the EDITTABLE field in the Page.

2. Usage of Dynamic Views

As we know, while creating Dynamic view, there is no need to specify the SQL. This SQL should be generated dynamically and the same should be assigned to the Record Field.

Say for example, if we see the above Record Field TASK_PROFILE_ID, it is assigned with dynamic prompt table view TL_TSKGRP_DVW and this view TL_TSKGRP_DVW is dynamically initialized by the following Peoplecode, which can be assigned both in FieldChange and RowInit events of the Record Field TASK_PROFILE_ID.

RECORDNAME.TASK_PROFILE_ID.SqlText = “SELECT T.TASKGROUP, T.TASK_PROFILE_ID, T.DESCR FROM PS_TL_TSKGRP_PRF_W T WHERE T.TASKGROUP = ‘” | &TSKGRP | “‘ AND T.EFFDT =(SELECT MAX(T1.EFFDT) FROM PS_TL_TSKGRP_PRF_W T1 WHERE T1.TASKGROUP = T.TASKGROUP AND T1.TASK_PROFILE_ID=T.TASK_PROFILE_ID AND T1.EFFDT<= %datein( ‘” | &maxdate | “‘) )”;

Both &TSKGRP, &maxdate are dynamic bind parameters.

Read More About  DYNAMIC Prompt Table

Fine Grained Access Control for PeopleSoft database – I

Today, I will demonstrate use of Fine Grained Access Control to create row-level security for the database to mimic the row level security setup in the PeopleSoft application. Let me start with asking a few questions.

In your PeopleSoft database, do you have Oracle ids created for the PeopleSoft users? Most of the PeopleSoft shops create Oracle ids for Functional support teams, so that they can query the database when they are troubleshooting some issues.

If you answered ‘yes’ to the above question then what kind of access has been given to these ids? Most of the PeopleSoft shops will provide the Oracle ids SELECT access to all access id owned tables. Is this how you have setup your ids? This basically allows the Oracle id to bypass the security setup in PeopleSoft and be able to view all the data in the table that the user has access

Won’t you love to have online query row level security available in the database such that it will only retrieve the rowsets that the user should have access?

Providing anyone with SELECT privileges to all PeopleSoft application or tools tables is not recommended. You might want to consider identifying sensitive datasets or tables and implement FGAC policies on them. The below scenario demonstrates the need to have this feature in the database.

1.In this example, I have identified PS_PERSONAL_DATA as the table on which I want to replicate the online security in the database

2.As shown below, the Query Security Record for PS_PERSONAL_DATA is PERS_SRCH_QRY

3.Now, lets try to create a query in Query Manager and check out the SQL generated by PeopleSoft

4.  The Query Manager has automatically added a join with PS_PERS_SRCH_QRY and an additional filter by OPRID.

5.   If I run this query then it fetches 1901 rows

6.  Now, I logon to Oracle database as PS and query PS_PERSONAL_DATA. And below are the results

7.  As we knew, PS has access to all the rows in PS_PERSONAL_DATA when queried from the database.

In my next post, I will share steps to implement the Fine Grained Access Control feature.

How to execute OS Commands in SQR?

Most of the projects have the below mentioned scenarios…..

1. FTPing the file from one server location to another
2. Deleting the file

We can simply execute those in SQR by using CALL SYSTEM built-in…Here is the syntax

CALL SYSTEM Using $del_file #del_status Wait

if edit(#del_status,’9′) = ‘0′
show ‘intfiles.txt was deleted sucessfully’
end-if

$del_file – Specifies the operating system command to execute. The command can be a quoted string, string variable, or column.
#del_status – Represents the status of execution of OS Command. This is always going to be Numeric variable
UNIX/Linux: Zero (0) indicates success. Any other value is the system error code.
PC/ Microsoft Windows: A value less than 32 indicates an error.
Wait – This flag is used to enable to do multitask processing.

(Microsoft Windows only): WAIT specifies that SQR suspend its execution until the CALL SYSTEM command has finished processing. NOWAIT specifies that SQR start the CALL SYSTEM command but continue its own processing while that command is in progress.

For Microsoft Windows, the default is NOWAIT. On UNIX\Linux operating systems the behavior is always WAIT.

Note : While executing OS Commands, we should append the value of Command Environment Settings along with OS Command. This is done by !Command Environment Settings
let $comspec = getenv(‘COMSPEC’) /* For Window OS */
let $comspec = getenv(‘SHELL’) /* For UNIX */
let $del_file = $comspec||’ /c del’||$int_file_name

Read More About  How To Execute OS Commands

How to trace AE and determine which AE has trace enabled?

In this blog, I will answer two questions.

1. How to trace AE?
2.  

There are a few ways to trace an AE program. You can enable the trace using some of the below methods:

1. In the process scheduler configuration file psprcs.cfg
2. You can enable the trace in the“Process Definition”.
3. Grab the Oracle session information and generate SQL Trace
4.  

It is not advised to enable the trace using psprcs.cfg because it will enable trace for ALL AE programs using that scheduler. However, this might be the best choice in an environment where you want to trace multiple AE programs or you do not have access to modify the process definition. Exercise this option with caution knowing that it might generate trace files for all AE programs.

To enable trace using “Process Definition”, make the below change. You can use the “-TRACE” or “-TOOLSTRACESQL” or “-TOOLSTRACEPC” option depending on what information you require.

1.  
2. Which AE program has trace enabled in its process definition?
3.  

The below SQL will help you determine all the AE programs that have TRACE enabled. It will be useful to use this SQL in your monitoring scripts if you notice developers enabling trace using the process definitions and getting the program with its process definition migrated all the way to production or if your analyst or DBA have the tendency to enable the trace and forget about it.

SELECT PRCSNAME, PARMLIST

FROM PS_PRCSDEFN

WHERE UPPER(PARMLIST) LIKE ‘%TRACE%’

AND PRCSTYPE = ‘Application Engine’;

Read More About How To Trace AE

How to create new Manager Self Service Transaction?

As everyone knows, PeopleSoft itself provides a lot of MSS transaction.

For example

1. Transfer Employee
2. Job Change
3. Promote Employee
4. Terminate Employee
5.  

Like that, say for example, if we are getting new MSS related requirements for Paygroup Change, How will we accomplish? Here is an insight!!!

Broadly saying, we should have 3 types of components that needs to be built to accomplish any MSS transaction

1. Transaction Level Components
2. Approval related Components (If Required)
3. Viewing Transaction/Approval Workflow Status related Components
4.  

Each of these components are in turn driven by 2 types of Component Pages, one for Launching Manager’s Direct Reports and the other one for Adding / Approving/ Viewing a (Paygroup change) Transaction.

In order to maintain all these transactional and approval workflow status related data, we should create 2 records to hold the data. As per PS Convention, One of the ways to maintain the data is achieved by having

1. HR_PAYGRPCHG_DAT – This record used to hold all the (Paygroup change related) Transactional data
2. HR_PAYGRPCHG_STA – This record used to hold all the Approval Workflow Status related data
3.  

Transactional Level Components

This type of components is purely meant for doing transactional changes. In our case, transactional change is nothing but Paygroup change for an employee.

1. Launching Page:
2. 
   Manager’s Direct Reports  Launching Component Page is constructed either by Direct Report Setup (Using OPRROWS component to show Direct Reports) or Configure Direct Reports UI Setup (Using HR_DR_SELECTION_UI component to show Direct Reports)
   Navigation: Setup HRMS >> Common Definition >> Direct Reports for Managers
3.  
4. Transaction Page:
5. 
   Transactional Component Page should be manually built as per the Requirements. As a manager, this is where Manager has to change the Paygroup of an employee, which in turn will fire Approval workflows (if required) or insert the data to Job component directly.
   Once the data is saved on this page, it should insert this transaction related data to DAT record and all the Approval workflow related data to STA record.
6.  

Approval related Components / Viewing Approval Workflow Status related Components

1. Launching Page:
2. 
   The Launching Page for both Approval / Viewing Status related Components should be manually designed to populate the Manager’s Direct Reports.
3. 
   Basically Launching pages are used to show the Direct Reports of the Manager. But in this case, Population of Manager’s Direct reports is restricted. For Eg. If the MSS transaction needs an approval, then the corresponding employee for that transaction will be shown as one of the Direct Reports in Launching page. Needless to say, Showing data for Manager’s Direct Reports should be determined by both Transactional (HR_PAYGRPCHG_DAT) and Status (HR_PAYGRPCHG_STA) data records.
4.  
5. Transaction Page:
6. 
   In the case of Approval related components, the main Approval page should be provided with 2 extra buttons to approve or deny the transaction. All other transactional data information should be placed in this page in non editable mode.
7. 
   For Viewing Statuses, the entire page should be in READ only access mode. This page should be used only to view the transaction and approval workflow status related details.

Read More About  Self Service Transaction