Sunday, 23 March 2014

What is an HGrid in PeopleSoft?

HGrid is one of the less talked about and most useful feature in PeopleSoft page designs. HGrid stands for Hierarchical Grid. Some may even interpret it as horizontal grids. HGrids can introduce hierarchy or horizontality in PeopleSoft grids. These kind of grids are often very useful in presenting roll up values and child values for a specific item in the same grid.

HGrid is no different than the normal PeopleSoft grid except it provides a roll up/ expansion feature within the same grid. The same is true with the designing of HGrid as well. To create an HGrid, all you need to do is to create a normal PeopleSoft grid, add a HTML field to the grid (which performs the expansion/collision) and then import the delivered packages to configure the grid.

A typical HGrid in PeopleSoft will look as below.
PeopleSoft HGrid
PeopleSoft HGrid

There are many delivered methods which will do all the fancy jobs like cut, copy, paste, expand all, collapse all, move up/right/down/left etc… There is a delivered work record POOL_HGRID_WRK which can be added to the page for designing these fancy buttons.

While designing your HGrid, you should be having a physical table to store the hierarchy (level) information of the HGrid, for this you might have to introduce two fields to capture the level number and the row number of any particular row. There is also a delivered sub record (HGRID_LEVEL_SBR) which can be used to capture the level details of the rows. Once you have the Table/View ready, all you have to do is to configure the HGrid package.

The main properties which you would need to configure will be as below.


DisplayOnly: Specify whether the grid is read only or editable
CreateLevelSeqNumHierarchy: Specify whether the level sequencing is handled manually or not
HGridRowRefNumFieldName: Field which carries the row number
HGridRowRefNumRecordName: Record which carries the row number
AssignRefNum: Specify whether the row number is generated automatically or not
HGridLevelFieldName: Field which stores the level information
HGridLevelRecordName: Record which contains the level field
HGridLevelSeqNumRecordName : Record which contains the detail level fields

Grid Properties

HGridRowSelRecordName: Record Used for selection indicator
HGridRowSelFieldName: Field Used for selection indicator
HGridDescrRecordName: Record which contain the actual description field
HGridDescrFieldName: Actual description field
HGridDescrDisplayRecordName: Record which is used to display the decription as HTML
HGridDescrDisplayFieldName: Field which is used to display the description as HTML
DescrChangeControlFieldName: Control field to handle the description (will be invisible)
DescrChangeControlRecordName: Record which contains the control field
DescrChangeControlPageFieldName:  The page field name of the control field

Control Properties

ExpCollControlFieldName: The control field to expand/collapse the hierarchy (invisible)
ExpCollControlRecordName: Record which contains the control field
ExpCollControlPageFieldName: Page field name of the field
ExpCollFlagFieldName: Field which stores the expansion/collapse information
ExpCollFlagRecordName: Record which contains the above field
DisplayWBSColumn: Specify whether you need to add bullet points for the hierarchy
WBSFieldName: Field which contains the bullet information
WBSRecordName: Record which contains the above field

Having done the above, you are 90% done with the HGrid design and configuration. All the rest you need to do is to invoke the appropriate methods from the appropriate events.

If you have your own requirements of manipulating the data based on rolling up/down, then you may have to create your own methods and extend the delivered one. For all the basic functionality the delivered ones should be working fine.

When you design a HGrid, consider all the facts including the data set, data model, real requirement and then come to a conclusion of designing an HGrid. A wrong design might take a toll on the performance of the application.

Saturday, 22 March 2014

Adjusting Timeout and Auto saving of PeopleSoft page

I was working on a requirement where for some particular self service pages which are exposed to the public, I need to extend the time out of that particular component alone as there are many data entry fields and it is obvious that the user will be taking more time to fill out the form. While working for the same, another requirement came in picture from the users that, the page needs to be saved after particular time frame.

Obviously the first thing which came to mind is tweaking of delivered javascript libraries, however it is going to be a customization and will be having a global impact. So thought of having a custom javascript for the particular page alone. There are many scripts available over the net to tweak the time out or to do an auto save functionality.

However I came across a simpler article which provides the script to do both the functionality, tweaking timeout as well as autosaving. I thought it will be worth sharing it over here so the readers could also make benefit of it.

The script is coded to make a save after specified time and then do a time out again after the same time frame. You could tweak the script to achieve the timeout immediately after the save or some other way based on your requirement.

Thursday, 20 February 2014

Change Control for PeopleSoft Developers

If you are working in a large PeopleSoft development team and if you and your team members are working on same area or objects it is very obvious that you might have encountered scenarios where the changes of one developer overwrites the changes of other developer. It is a very frequent scenario and always results in finding root cause of missing changes and the re-writing the original changes. There is a sort of control provided by PeopleSoft to control this scenario to an extent. I’m not sure whether every organization is aware of this or if they are utilizing this feature. This post is primarily targeted for those who are not aware of this.

The mechanism provided by PeopleSoft to avoid overwriting of the changes is called Change Control in PeopleSoft. This needs to be setup by the PeopleSoft Administrator of your team.

To activate this feature, the admin needs to log in to the app designer and select the Administrator item available in the Tools menu.

Tools > Change Control > Administrator

Select the Use Change Control Locking to enable the change control for the development database. If you want to audit the changes made to each object in application designer, then you may have to enable the Use Change Control History option as well.

Once this option is enabled for your database, in order to work on any object in the application designer, developers has to lock the object definition first. Once an object definition is locked by a developer, no other developer will be able to modify/edit that particular object unless the first developer finishes his work and unlocks the same object. There by the locking will make sure that no other developer will be modifying the same object at the same time you are working on it. So once you save your changes, you can be sure that no other person will be overwriting your changes. Once you unlock the object definition and the second person locks it for editing, the second person will be getting a local cache of the object which contains the changes added by the first person (So no app designer cache issueJ).

There are two popular ways to lock an object definition in PeopleSoft. The first method is to add the object to the project and under the Development tab of the project sidebar, right click the object definition. You will get an option to lock the object. The Unlock option will be enabled once the object is locked and vice versa.

The second method is to open the object in application designer and check the tool bars menu, you will get an icon to lock the object, unlock the object and to see the change history (if enabled by the admin).

Click the first icon (locked) to lock the open object, second icon (Unlocked) to unlock the open object, third icon (comment) to add a comment to the change history and the fourth icon (code) to see the revision history of the open object.

Whenever you use change control for development, ensure that each developer has a unique id to log in to app designer. I believe most of the organizations have a unique id for developer, but there are cases where individual developers do not have a PeopleSoft id and every one in a team logs in using a common developer id. If you are using a common developer id, then the change control is of no use.

Once you a developer is done with the editing, make sure that you unlock the object so that the next person could start on working on the same object.