Extending SmartHire (Template Based Hire) with custom Field Change & Field Prompt Events

Extending SmartHire (Template Based Hire) with custom Field Change & Field Prompt Events

‘Hiring new employees or adding contingent workers into the system is one of the most time-consuming tasks for Human Resources departments. Template-Based Hire reduces the current labor-intensive data entry process through the Personal Data and Job Data
pages by providing a configurable, template-driven approach. Template Administrators can define default data for various sections or fields in the hiring process and they can determine what sections should be displayed, hidden and made equired to the end-user.
This allows organizations to deploy policy control and flexibility in multiple template configurations for the end-users. This flexibility provides Human Resources departments the ability to decentralize the hiring process out to line managers or HR representatives
in the field, rather than only allowing centralized hiring.’

Source: Red Paper Template Based Hire Red Paper for Human Resources 9.0.

With the SmartHire you can configure templates with common fields that are required for hiring an employee/contingent worker. On these templates you configure (predelivered) sections with fields, corresponding the PERSON, JOB etc record fields. These fields
contain hardcoded validation, where available. Fortunately Oracle has also created a user exit, which you can use to build and configure your own business process validations and prompts. Unfortunately this not been documented. When you look at the
screenshot below, you have two sections, where you can configure your own FieldChange event and Field Prompt event.




But what are the prerequisites for the Event class? Which methods need to be used? Which parameters need to be used? Does it need to have return values?

First thing you start to do, is start looking for documentation. There is a red paper available on Oracle Support document 747744.1, Template Based
Hire Red Paper for Human Resources 9.0. This states:

The Field Change App Class provides a user exit for field change code to be added. Some delivered section fields include field change code. For example, the Company field on the delivered Work Location – Job Fields section has field change code that builds
prompt lists for other fields in the section, such as Location and Establishment ID. It is recommended that any validation methods added at implementation be stored in customer-created application classes.

The Field Prompt App Class section provides a field prompt user exit. Normally the prompt values come from a prompt table, but a program can be written instead to supply these values. We did not ship any field prompt code, but customers can add their own, if
needed. We may actually deliver some field prompt code as system data in future as part of fixes for performance issues.

When you look at PeopleBooks for this subject, it states:

The Field Change App Class provides a user exit for field change code to be added. Some delivered section fields include field change code. For example, the Company field on the Work Location – Job Fields section has field change code that builds prompt
lists for other fields in the section, such as Location and Establishment ID.

Note. Oracle recommends that any validation methods added to the PeopleSoft application at implementation be stored in a
customer-created application class.

So I had to dig into the code, to see what was needed to build a custom Event class. After a couple of hours, I stumbled upon the Package HRTMPL. This package contains all classes to build the UI of SmartHire and set all FieldChange and Field Prompt Events.
These (hardcoded) FieldChange and Field Prompt events get set by the class FieldChangeFactory and
FieldPromptFactory. Let’s take a closer look at the FieldChangeFactory class, here is a portion of the class.

import HRTMPL:TMPL:hrTmplEvent;
import HRTMPL:FC:*;

class FieldChangeFactory extends HRTMPL:TMPL:hrTmplEvent
   method FieldChangeFactory();
   method execute();
end-class;

method FieldChangeFactory
   %Super = create HRTMPL:TMPL:hrTmplEvent();
end-method;

method execute
   /+ Extends/implements HRTMPL:TMPL:hrTmplEvent.execute +/

   Local string &FieldName, &RecordName;
   Local object &lObjEvent;
   Local HRTMPL:FC:FieldChange &objFieldChange;

   If %This.getSectionField().isFieldEvent() Then
      &lObjEvent = CreateObject(%This.getSectionField()
      .getEventClassPath() | ":" | %This.getSectionField()
      .getEventClassID());
      ObjectDoMethod(&lObjEvent, "setTmplRowSet", %This.getTmplRowSet());
      ObjectDoMethod(&lObjEvent, "setSectionField", %This.getSectionField());
      ObjectDoMethod(&lObjEvent, %This.getSectionField().getEventMethod());

   Else

      &FieldName = %This.getSectionField().getName();
      &RecordName = %This.getSectionField().getParentRecord().getName();

      Evaluate &RecordName
      When Record.JOB

         Evaluate &FieldName
         When Field.BUSINESS_UNIT
            &objFieldChange = create HRTMPL:FC:JobBusinessUnit();
            Break;
         When Field.REG_REGION
            &objFieldChange = create HRTMPL:FC:JobRegRegion();
            Break;
         Evaluate [OTHERFIELDS, ETC, ETC]
         When-Other
         End-Evaluate;
         Break;

      When-Other;
      End-Evaluate;

      If All(&objFieldChange) Then
         &objFieldChange.setTmplRowSet(%This.getTmplRowSet());
         &objFieldChange.setSectionField(%This.getSectionField());
         &objFieldChange.execute();
      End-If;
   End-If;
end-method;

When you look at this code, you’ll see that if a custom FieldChange is set on a field, the code runs the following lines

1 &lObjEvent = CreateObject(%This.getSectionField().getEventClassPath() |
  ":" | %This.getSectionField().getEventClassID());
2 ObjectDoMethod(&lObjEvent, "setTmplRowSet", %This.getTmplRowSet());
3 ObjectDoMethod(&lObjEvent, "setSectionField", %This.getSectionField());
4 ObjectDoMethod(&lObjEvent, %This.getSectionField().getEventMethod());

On the first line the Object is created that you defined in the FieldChange section of the field configuration. After this, the method setTmplRowSet is executed and after this the method setSectionField is executed. After this your custom method is called, you
defined in the FieldChange section of the field configuration. You might think you need a custom class with three methods.

When you look at the predelivered FieldChange classes, you can create the following class hierarchy diagram.




You can see the predelivered FieldChange classes (PersonBirthCountry, PersonNIDCountry, etc) get extended from FieldChange class, which in it’s turn get extended from the hrTmplEvent class. The hrTmplEvent class already contains the setTmplRowSet and setSectionField
methods.

So, if you were to create your custom class, you should extend the HRTMPL:FC:FieldChange class. You would have to create only one custom method, since the other two methods are inherited from the superclass.

Now that we know what the class needs to look like and where it should reside, let’s create a custom package and class for the field Position Number. Whenever you change the Position Number, I would like to default the Salary Admin Plan, Grade and Step from
the PositionData table. The following example will execute this.

import HRTMPL:FC:FieldChange;
class hrTbhFieldChangePosition extends HRTMPL:FC:FieldChange
   method hrTbhFieldChangePosition();
   method execute();
end-class;
/* Constructor */
method hrTbhFieldChangePosition
   %Super = create HRTMPL:FC:FieldChange();
end-method;

method execute
   /+ Extends/implements HRTMPL:FC:FieldChange.execute +/
   Local string &PosNbr;
   Local Record &rPositionData;
   Local string &SalAdminPlan, &Grade, &Step;

   /* Get selected position number */
   &PosNbr = %This.getTmplRowSet().getField(Record.JOB, 1, Field.POSITION_NBR)
   .getValue();

   /* Check if position has a value, onload this in empty */
   If All(&PosNbr) Then

      /* Get Position defaults from POSITION_DATA record */
      &rPositionData = CreateRecord(Record.POSITION_DATA);
      &rPositionData.POSITION_NBR.Value = &PosNbr;
      &rPositionData.SelectByKeyEffDt(%Date);

      /* Get default values from Position Data */
      &SalAdminPlan = &rPositionData.SAL_ADMIN_PLAN.Value;
      &Grade = &rPositionData.GRADE.Value;
      &Step = &rPositionData.STEP.Value;

      MessageBox(0, "", 0, 0, "Choosen position: " | &PosNbr |
      "; Set SalAdminPlan/Grade/Step to: " | String(&SalAdminPlan) |
      " / " | String(&Grade) | " / " | String(&Step));

      /* Set Field Values from Position Data */
      %This.getTmplRowSet().getField(Record.JOB, 1, Field.SAL_ADMIN_PLAN)
      .setValue(&SalAdimPlan);
      %This.getTmplRowSet().getField(Record.JOB, 1, Field.GRADE)
      .setValue(&Grade);
      %This.getTmplRowSet().getField(Record.JOB, 1, Field.STEP)
      .setValue(&Step);
   End-If;
end-method;

The same way the Field Prompt event is constructed.

When you look at the FieldPromptFactory class, you will see the following lines:

If %This.getField().isPromptEvent() Then
   &lObjEvent = CreateObject(%This.getField().getPromptClassPath() |
   ":" | %This.getField().getPromptClassID());
   ObjectDoMethod(&lObjEvent, "setTmplRowSet", %This.getTmplRowSet());
   ObjectDoMethod(&lObjEvent, "setField", %This.getField());
   ObjectDoMethod(&lObjEvent, %This.getField().getPromptMethod());

This class creates your custom FieldPrompt class, executes method setTmplRowSet and setField and then executes your custom method.

The following class diagram illustrates the hierarchy.




So, if you were to create your custom class, you should extend the HRTMPL:FP:FieldPrompt class. You would have to create only one custom method, since the other two methods (setField, setTmplRowSet) are inherited from the superclass.
Let’s say we want the Position Number to have only three positions eg 19000017, 19000018, 19000019. The custom class would look like this:

import HRTMPL:FP:FieldPrompt;
import HRTMPL:TMPL:hrTmplField;
import HRTMPL:TMPL:hrTmplCodeList;
import HRTMPL:TMPL:hrTmplCode;
class hrTbhPromptPosition extends HRTMPL:FP:FieldPrompt
   method hrTbhPromptPosition();
   method execute();

   property HRTMPL:TMPL:hrTmplField objTmplField;
end-class;
/* Contructor */
method hrTbhPromptPosition
   %Super = create HRTMPL:FP:FieldPrompt();
end-method;

method execute
   /+ Extends/implements HRTMPL:FP:FieldPrompt.execute +/
   Local integer &i;
   Local HRTMPL:TMPL:hrTmplCodeList &lobjCodeList;
   Local HRTMPL:TMPL:hrTmplCode &lobjCode;
   Local Rowset &rsPositionData;
   Local string &PositionNbr, &PositionDescr;

   /* Get current field executing this method */
   &objTmplField = %This.getField();

   /* Create custom rowset for dropdown values */
   &rsPositionData = CreateRowset(Record.POSITION_DATA);
   &rsPositionData.Fill("WHERE POSITION_NBR IN
   ('19000017','19000018','19000019')");

   /* Create runtime list of values object */
   &lobjCodeList = create HRTMPL:TMPL:hrTmplCodeList();

   /* Loop through custom rowset positions */
   For &i = 1 To &rsPositionData.ActiveRowCount
      /* Get Position Number & Description */
      &PositionNbr = &rsPositionData(&i).GetRecord(1)
      .POSITION_NBR.Value;
      &PositionDescr = &rsPositionData(&i).GetRecord(1)
      .DESCR.Value;

      /* Create runtime value object */
      &lobjCode = create HRTMPL:TMPL:hrTmplCode(&PositionNbr,
      &PositionDescr);

      /* Add runtime value object to list of values object */
      &lobjCodeList.addCode(&lobjCode);

   End-For;

   /* Set runtime list of values object to current Field */
   &objTmplField.setCodeList(&lobjCodeList);

end-method;

I have created these two classes in a custom package CUSTOM_HRTMPL.




These classes are configured on the Position Number field, as seen in the second screenshot of this post.

Now let’s see it in action on a PeopleSoft Vanilla Demo environment using Template KUEMP_MGR_POSITION, with custom events on section WORK_LOC_POS_NBR on field Position Number.

FieldPrompt with only the position numbers 19000017, 19000018, 19000019




Finally the FieldChange event when selecting a position number.




Viewed 1515 times by 597 visitors

Share this:
Email
Print

inShare

Facebook

Related posts:

Extending PSQuery productivity with Drilling Url
Create interactive dashboards with InterWindow Communication
(IWC)
Adjust Change Assistant to Oracle Metalink
PeopleSoft export to formatted MS Word file using
XML templates
Generic prompting PeopleTools 8.50

Category:
General /
HR /
Technical

Tags:
customization,
peoplesoft,
smarthire,
TBH,
template based hire


Posted
by:
Hakan Biroglu (56 post(s)).

«
Oracle extends Oracle Fusion Applications UPK
Fusion Applications – How to get Sizing Requirement? »

You can follow any responses to this entry through the
RSS 2.0 feed.You can skip to the end and

leave a response. Pinging is currently not allowed.

2 Responses (last comment shown first)

July 9, 2012
Julien



It’s me again.

I adapted your Field Prompt user exit and it seems that we can default the prompt values only if the field prompt Display Type is set as a drop down. I first tried with a prompt table, and the values were not shown when searching for a value, even if the
code was working properly (I put a lot of messagebox to follow it)

Julien

[Reply to this comment]

July 9, 2012
Julien



Very good article.

I am starting to build a template and to configure it. I will have to use the Field Prompt user exit to limit the choice for some prompt values.

For the moment, I have been using the Validation user exit, which is directly on the template section. It is working the same way as the Field Change and Field Prompt. For my first use, I had to validate that the phone number was made of 10 digits.

I also used the Validation user exit as a work around to default some values dynamically. In fact, my template is made of two pages, and on the validation of one section on the first page, I added some code to set the value of some fields on the second page.
I don’t know if there is a better way to do that without modifying vanilla code.

Thanks again for your article,

Julien

[Reply to this comment]