Dynamic Roles:

Why Dynamic roles ?

1) The assignment of roles to User Profiles based on your business rules.

2) These business rules run against system(s) to assign PeopleSoft access.
3) PeopleSoft security changes in an automatically.
4) The dynamic role rule process removes and grants access to User Profiles

PeopleTools > Security > Permissions & Roles >Roles (Dynamic Member Tab/Page).

There are three ways can use to execute your rules to find the dynamic role users.
o PS/Query
o LDAP Plug-in
o PeopleCode

PS/Query

1) Access is removed or granted based on the User Profile IDs retrieved by the query.
2) Logic to select the dynamic role users will be present in the SQL of the Query.

Note: -
a) Use PSOPRALIAS_VW or PSOPRALIAS record to create the dynamic role queries.
PSOPRALIAS - Used to store ID values corresponding to various ID types. For example, stores EMPLID
for Employee type, CUST_ID for customer ID. It will be easy to join the tables based on the type of the
Userid.

b) Don't use any Bind variables in the role queries. They are not designed for resloving the bind variables.

c) Use Disntict caluse in the SQL to make you always retrive uniques id only. Any duplicate will the the
dynamic role asssignement.

PeopleCode

1) Access is removed or granted based on the User Profile IDs pushed in to the system array variable
%RoleDynamicMembers.
2) This is used when logic is complicated and cannot be retried from the Query.
3) Logic to select the dynamic role users will be present in the Peoplecode event (Record name, Field name
, Event name , Function name.) should be provided in the dynamic members tab. 4) fetch the value using
create sql fetch the oprid values and push in to the system variable.
Eg:- %RoleDynamicMembers.Push(&Userid);

LDAP Plug-in

With a directory-based rule, you must assign directory groups. The PeopleCode Rule group box appears
because directory rules are implemented using the DynRoleMembers PeopleCode program. This program
uses the Directory business interlink to retrieve user and group information from the directory. To view the
program, open the FUNCLIB_LDAP record in PeopleSoft Application Designer. Click Assign Directory
Groups to select a particular directory group that exists in your LDAP server hierarchy. For example, if you
have your LDAP server grouped by geographic region, your rule could assign a new self-service role to all
users in the North America group. Use the Directory Group drop-down list box to select the appropriate
directory group value. The values are derived from the LDAP data that you import using the Directory Group
Import process.

Note :-
When you click the button execute Dynamic rules button DYNROLE_PUBL Application engine is exequted.
This app engine program reads Dynamic Role Rules, executes the rules, and publishes the results. The
messages are then subscribed to and the users are assigned to the appropriate roles. This program is
designed to run in an asynchronous mode, via the process scheduler.
The DYNROLE_PUBL Application Engine does not update the database directly.
Integration broker must be configured to handle Application Messaging.

DYNROLE_PUBL application engine publishes messages to ROLESYNCH_MSG.

F1 Context Help for Peoplesoft Application Designer

Access Peoplebooks from Applicaiton Desinger.

Context Help for Application designer.

Follow the setps to configure F1 - context help for the application designer.
Press F1 in the application designer to get the help based on the URL configuration below.
It can take to the peoplebooks based on the context.

Navigate to PeopleTools > Utilities > Administration > PeopleTools Options

Under the help option you can set the URL to the People books.

URL needs to be in the following format.

http://helpwebserver:port/productline/f1search.htm?contextID=%CONTEXT_ID%&LANGCD=
%LANG_CD%

%CONTEXT_ID% is the object name or context ID of the currently displaying page or dialog box.
%LANG_CD% is the three-letter language code for the user's preferred language.

Cntrl+F1 - can be used as alternative help URL to the website on the internet or the company's internal
website.

Invoking the Remote call from AE/CI Process

In PT 8.4x you need to follow a certain sequence prior to invoking the PushButton field. The basics on
calling COBOL from AE/CI PeopleCode is as follows. Note that "tweaking" may be necessary to get it to
work.

1. AE (Application Engine) needs to have restart disabled in order to use CommitWork() to force a commit to
the DB of the CI data.
2. Set the CI's properties, except for the "Pushbutton" field (usually Y/N) used to kick off COBOL.
3. Save the CI (call Save()).
4. If Save is successful, call CommitWork().
5. Set the CI pushbutton property (toggle it) to trigger the COBOL process.
6. COBOL will run asynchronously. So you usually need to put a dummy loop to wait until it's done
processing to avoid having the next CI record "bump" into COBOL or in case you need to perform some post
COBOL processing of the record.
GenerateComponentContentURL /
GenerateComponentPortalURL return NULL / Blank
PeopleTools > Portal > Node Definitions

The Base URI (e.g. http://www.myserver.com/psp/mysite/) is only available automatically

in the context of a web server. If a process is not signed in via the web (e.g. Application
Engine), the Node definition specified in the function is checked for that Base URI. <!--[if !
supportLineBreakNewLine]--> <!--[endif]--> Open the Node Definition (PeopleTools > Portal >
Node Definitions) and enter the Content URI (.../psc/...) and Portal URI (.../psp/...) on the Portal
page. These are used by the GenerateComponentContentURL and
GenerateComponentPortalURL functions, respectively. By default these fields are empty. <!--[if
!supportLineBreakNewLine]--> <!--[endif]-->

%UpdateStats is not working or it is Ignored

PeopleSoft Application Engine replaces this meta-SQL construct with a platform-dependent SQL statement
that updates the system catalog tables used by the database optimizer in choosing optimal query plans.
Peoplesoft intends that you use this construct after your
program has inserted large amounts of data into a temporary table that will be deleted before the end of the
program run.

For databases that either execute an implicit commit for %UpdateStats or require a commit before and/or
after this meta-SQL, PeopleSoft Application Engine skips %UpdateStats in the following circumstances:
• A commit is not allowed, as in within an Application Engine program called from
PeopleCode.
• The program issues a non-select SQL statement since the last commit occurred. In such a situation, data
is likely to have changed.
• You are deferring commits in a select/fetch loop in a restartable program. PeopleSoft Application Engine
skips %UpdateStats even if the previous condition is false.
Points to remember in Scroll peoplecode
hierarchy of the component buffer/scrolls the way people code should navigate to

1)ROWSET
2)ROW
3)RECORD
4)FIELD

A rowset contains one or more rows

A row contains one or more records And zero or more child rowsets,
And a record contains one or more fields.

sample scroll people code.

First you need to define ROWSET objects:

Local Rowset &LEVEL_0;

Local Rowset &PERFORM;
So now you have to seed or instantiate the Rowset:

&LEVEL0 = GetLevel0();
&PERFORM = &LEVEL0(1).GetRowset(Scroll.SCROLL);

Step through your Rowset.

For &i = 1 To &PERFORM.ActiveRowCount

End-For;
Extract data.

&COMPETENCY =
&PERFORM(&i). SCROLL.COMPETENCY.Value;

Update the data on the grid:

&PERFORM(&i). SCROLL.N_RVW_ACCEPT.Value = “Y”;

How to Implement Record level Audit in Peoplesoft

Record level auditing allows you to have separate audit tables dedicated to one database record.

Below are the steps to turn on record level auditing

1) Clone the record you wish to edit

2) Add the audit fields: (Key Fields)
AUDIT_OPRID
AUDIT_STAMP
AUDIT_ACTN
And make sure you check off the "system maintained" check mark on the record field properties
3) Delete fields that won’t be audited
4) Remove all key structures
5) Save and build the record
6) Link the base record to the audit record
Open- original record definition
Now all of your changes for that record will be tracked in the new audit record you just created
AET records in the Application Engine.
Auto populated Fields in the AET record. Fields that are populated in the AET record.

1) Process Instance
2)OPRID
3)RUN_CNTL_ID

are the fields that are auto populated in the AET record. Process Instance is mandatory key field in the AET
record.PROCESS_INSTANCE field value cannot be changed by the Application Engine. OPRID &
RUN_CNTL_ID field is optional fields in the AET record. These fields are auto populated in the AET record
and need not use SQL and populate these fields.

In the First SQL step of the Application Engine we can use %Bind(OPRID) and %Bind(RUN_CNTL_ID)
instead of the %operatorID and %Runcontrol

PeopleSoft Application and PeopleTools maintenance releases are intended to address defects,
performance enhancements, regulatory changes (such as tax updates), or security issues. In general,
feature enhancements are part of new releases which require a product upgrade.

Application fixes and changes are delivered in a variety of means; these include individual postings
(Patches), Bundles, Maintenance Packs and Service Packs.

Fixes

Fixes for specific issues with an application may be posted as a standalone fix intended to address that
specific issue; these are generally referred to as Patches.

Patches

Patches almost always have pre-requisites that are included in the documentation for that Patch. Patches
are created by development using the most recently released bundle, this means they may list that bundle
as a prerequisite. There may be other pre-requisites that are also required, all pre-requisites are clearly
documented in the notes for the Patch.

Bundles

Bundles are periodic accumulations of fixes resolved in that time period and applied to the application as a
group. For most applications, the interval has been about every 6 weeks or 12 weeks for posting these
Bundles. When Bundles are applied using Change Assistant, information about the Bundle is recorded in the
Maintenance Log table for future reference. Bundles will typically require pre-requisites and occassionally
post-requisites. These are documented in the notes for the Bundle. Information about the individual Report
ID s associated with a Bundle is available in the supplemental information posted on Customer Connection
related to that Bundle.

Maintenance Packs

Maintenance packs are less frequent updates that aggregate Bundles to minimize the number of Bundles
that need to be applied. For most applications, maintenance packs are delivered once a quarter for the two
most current releases.

Service Packs

Service Packs serve as a vehicle for an even larger aggregation of fixes than Maintenance Packs.
In all cases, the PeopleSoft tool Change Assistant is a valuable tool in identifying dependencies of Patches,
Bundles, and Maintenance Packs.