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 hum An Resources departments. Template-based Hire reduces the current labor-intensive data entry process through the Personal data and Job data pag Es 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 is displayed, hidden and made & Nbsp;equired to the end-user. This allows Organizations to deploy policy control and flexibility on multiple template configurations for the end-us ERs. This flexibility Provides human Resources departments the ability to decentralize the hiring Process out 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 your can configure templates with common fields that is required for hiring a employee/contingent work Er. On these templates-configure (predelivered) sections with fields, corresponding the person, JOB etc record fields. These fields contain hardcoded validation, where available. Fortunately Oracle have also created a user exit, which you can use to build and configure your own business process Valida tions and prompts. Unfortunately this is not been documented. When your look at the screenshot below, you have both sections, where you can configure your own Fieldchange event and Field Prompt event.

What is the prerequisites for the Event class? Which methods need to be used? Which parameters need to be used? Does it need to has return values?

First thing you start-to-do, is the start looking for documentation. There is a red paper available on Oracle support  document 747744.1, template Based Hire Red Pap Er 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 is on the delivered work Location–job fields have field change code that builds Promp The such as location and establishment ID of T lists for other fields in the section. It is recommended this any validation methods added at implementation being 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 is written instead to supply these values. We didn't 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 the future as part of the fixes for performance issues.

When the 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 in the Work Location–job fields have field change code that builds prompt lists fo R other fields in the sections, such as location and establishment ID.

Note. Oracle recommends, validation methods added to the PeopleSoft application at implementation is stored in a cus tomer-created Application class.

So I had to dig into the code and to see what is needed To build a custom Event class. After a couple of hours, I stumbled upon the package Hrtmpl. This is 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, this 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, &recordnam
   E
   Local Object &lObjEvent;

   Local HRTMPL:FC:FieldChange &objFieldChange; If%this.getsectionfield (). Isfieldevent () Then &lobjevent = CreateObject (%this.getsectionfield (). getEvent ClassPath () | ":" |
      %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 your look at this code, you'll see that if a custom fieldchange are 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, the defined in the Fieldchange section of the field configuration. After this, the method Settmplrowset was executed and after this method Setsectionfield is executed. After this your custom method is called, your defined in the Fieldchange section of the field configuration. You might think your need a custom class with three methods.

When you are in 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 Fieldchang E 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 has to create only one custom method and since the other methods is inherited from the superclass.

Now so we know what's 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 the Position number, I would like to default the Salary Admin Plan, Grade and Step from the Positionda Ta table. The following example would 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 have a value, onload this in empty */if All (&POSNBR) and 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 the Field Prompt event is constructed.

When your look is at the Fieldpromptfactory class, you'll 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 has to create a custom method, since the other, methods (SetField, Settmplrowset) is inherited from The superclass. Let's say we want the Position number to has 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 N Umber & 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, &positio

      NDESCR);

   /* 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 II classes in a custom package Custom_hrtmpl.

These classes is 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 URLs Create interactive dashboards with Interwindow Communicati On (IWC) Adjust change Assistant to Oracle Metalink PeopleSoft Export to formatted MS Word file using XML templates Generi C prompting PeopleTools 8.50 category:general/hr/technical tags:customization, PeopleSoft, Smarthire, TBH, template Based hire Posted By:hakan Biroglu ((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, Julien

It ' s me again.

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

Julien

[Reply to this comment]
July 9, Julien

Very Good article.

I am starting to build a template and to configure it. I'll have the-use of the Field Prompt user exit to limit the choice for some Prompt values.

For the moment, I has been using the Validation user exit, which is directly on the template section. It is working the same, the field change and field Prompt. For my first use, I had to validate that the phone number is made of ten digits.

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

Thanks again for your article,

Julien

[Reply to this comment]