In real business applications, very frequently we will
encounter situations where the prompt for some fields needs to be controlled
based on the values on other fields or based on the logged in user. PeopleSoft
has delivered built-in mechanisms to handle dynamic prompting. Most of the
readers will be already aware of this as this is one of the basic lessons in
People Tools. However recently I had an interaction with PeopleSoft developer
community, where most of them shared the same experience. People either don’t
know dynamic prompting or they are not sure about the underlying technology to
be used. I thought it will be worth explaining it over here so that people who
are new to PeopleSoft may get a fair understanding on dynamic prompting.
There are widely two different techniques used for
generating dynamic prompting. First method is using DERIVED record fields or
popularly known as Edit Table method. The second popular method is using
Dynamic Views. Both methods have its own advantages are used in different use
cases.
Derived record
field method
There can be business case where based on the value on one
field, the prompt for other field should change. The change may include the search
fields or list box values displayed on the prompt page. It can also demand an
entirely different data set to be prompted for the user. In this type of
scenarios the action that we require at the back end is to point the prompt of
the fields to different tables or views. To tackle this kind of scenarios you
need to use derived work record fields.
Suppose there is a scenario where you have a check box
(called effective dated) and a department field on the page. If the check box
is checked you need to show only all the effective dated departments on the
prompt. Otherwise the prompt should list all the department codes and user
should also have a search option to search with the effective date. This is an
ideal scenario where you can use derived record field method. The steps to be
followed are as below.
1.
Create a view, say DEPT_VW1, which will fetch
the effective dated departments.
2.
Create another view, say DEPT_VW2, which will
fetch all the departments. Make sure to check the alternate search key and list
box item property for the EFFDT field (this is for the stated requirement. You
may have to create both the views as per your real requirement).
3.
On the record field properties of the field
department, give the prompt table name as %EDITTABLE (it is not mandatory to
give %EDITTABLE all the time. You can give % and any field name present on the
table DERIVED).
4.
Place the field EDITTABLE (or other fields which
you have mentioned in the previous step) to the page where your department
field is present. This is mandatory because we will be referencing the field in
PeopleCode program in next step. To reference the field in PeopleCode, it is
required that the work record field is present on the component buffer. You can
hide this field, because it will not make any sense to the business user.
5.
Now on the field change event of the check box
field, write the below code.
/* If it is checked then use first view
else use second view */
If RECORD.EFFECTIVE_DATED.Value = “Y”
Then
/*Specify the prompt record name here. Appropriate field name should be used in place
of EDITTABLE */
DERIVED.EDITTABLE.Value = “DEPT_VW1”;
Else
DERIVED.EDITTABLE.Value = “DEPT_VW2”;
End-If;
This way you will be able to change the prompt record of a
field programmatically. If you want to change the prompt of multiple fields in
a page, you can use other fields such as EDITTABLE2 which are present in the record
called DERIVED. The % symbol will signal the system that the prompt table for
the field is the value present in the specified field in the record DERIVED.
Dynamic Views
Dynamic Views can prove to be powerful prompting mechanism
when you come across a requirement where the values fetched by the prompt table
needs to be changed based on some system variables such as %OperatorId or
%EmployeeId. Take a situation where you want to filter the data present in the
prompt table based on the logged in user. In this case you need to use dynamic
views as a prompt table.
Take a situation where you have an address id as a field on
the page. Your requirement will be to bring up the address id’s for the
particular logged in user alone. But if a system administrator logs in, then
you should display address id’s corresponding to all the users. In this case
you have to use up dynamic views. The step should be followed will be as
follows.
1.
Create a record (say PROMPT_DVW) and add necessary
fields that need to be prompted.
2.
Set up the key structure in the way you would
like the prompt page to be appeared.
3.
Save the record as dynamic view type. No need to
build or write sql for these kinds of records.
4.
On the record field property of the address id
field, set the dynamic view as the prompt table.
5.
Now on the appropriate event (RowInit,
FieldChange etc) write the below code.
/* Note: ADDRESS_ID is the field which
requires prompt. We are not writing anything on the dynamic view people code
events. */
If %OperatorId = “Admin” Then
RECORD.ADDRESS_ID.SqlText = “select
ADDRESS_ID, DESCR from PS_BASE_TABLE”;
Else
RECORD.ADDRESS_ID.SqlText = “select
ADDRESS_ID, DESCR from PS_BASE_TABLE where EMPLOYEE_ID = ‘”|%EmployeeId|”’”;
End-If;
The SqlText property will dynamically act as a view sql and
bring up the corresponding result in the prompt page.
Complex Scenarios
There can be very complex scenarios where you need to change
the prompt based on the logged in user or system variables and other multiple
conditions based on selections user make in the page or setups. In such
scenarios you can use a mix of both dynamic views and derived record fields.
These kind of scenarios are very rare in nature and I have
seen only this once in my carrier.
If you have encountered/done any challenging or innovative
method of creating dynamic prompts, please share it in the comments section so
that others will get benefitted too.
