Pointers for developing selfservice in PeopleSoft

Pointers for developing selfservice in PeopleSoft

More and more companies use selfservice funcionality. PeopleSoft deliveres some out-of-the-box selfservice functionality, but what if you want to develope some yourself?

Here are some pointers to get you on the right track:

Roles
One of the most distinctive trademarks of selfservice functionality are the different roles an enduser can have, for instance:
- employees enter / adjust their own specific data
- managers can approve changes made by employees
- functional managers can setup/change configuration items, correct entered data and support employees and managers

Make sure you set up your permission lists & roles in PeopleSoft according to the roles you define for your selfservice customization.

User profiles
PeopleSoft users the OperatorID (OPRID) for logging on a user. On the other hand, the employee nr (EMPLID) is used when saving transactional user data. The link between the OPRID and the EMPLID of a user is made in the User Profile page. However, PeopleSoft does not force you to specify an EMPLID for every OPRID. You can even add the same EMPLID to different OPRIDs. This can cause errors in a self service module. In order to prevent this, create a process that checks for these things and schedule it daily.

Developing Self Service pages
The develoment of a self service page differs from a ‘normal’ page. Normally, you create a page object and put it into a component object. If you need a second scree, you define a second page and put it in a second component. In selfservice screens however, the information on a screen can be almost identical, but differs a bit depending on the role of the user. An example:
- an employee wants to request an absence of leave, so a page has to be created with all relevant input fields and a button to request the absence of leave.
- the corresponding manager has to approve or deCline the request. A page has to be available identical to the page where the use has entered the request, only the fields have to be display-only and the manager needs a button to approve and a button to decline.
- the functional manager at least must have the ability to look at the request (display-only) or even may have the ability to correct it (input fields available).

When using the normal way of creating a screen, you will have to create three more or less identical pages and three new components. It is easier however to create one page with all necessary fields / buttons for all roles, and put that page into three components (one for every role). With the use of PeopleCode you can then finetune the page for each role.

Using Component and Application Package PeopleCode
By using Component PeopleCode you can determine which fields / buttons are available based on the role. You can then use Application Package PeopleCode to define code that can be shared amongs all the components.

For instance, you can define a method called DisplayPage which accept the name of a component as a variable. In this method you can turn field on or off based on the given parameter. In the Component PostBuild event of each of the three components you can call this method providing the name of the component it is called from.

In the same way you can define for instance input checks in an Application Package and call it with Component Field Peoplecode from the relevant components.

 Viewed 14728 times by 2761 visitors