How to implement PeopleSoft Simple Person Search in our application?

Overview:

Most of the times while designing and building our custom pages, where we need to provide the users with a prompt to select person (active/inactive, employee/contingent worker/POI etc.) we end up either using some delivered or defining our own prompt table and using it. A more elegant alternative is to use PeopleSoft “Simple Person Search”. 

 Quite a few of the PeopleSoft delivered components use this functionality.  So it will be a good idea to incorporate it in our custom components to give the end users similar user experience which is the key to any of the bolt-on application that we design.

This small configuration component available at (Set Up HRMS, Common Definitions, Person Search Match, Configure Simple Person Search, Configure Simple Person Search) enables users of an application to search for and select a person to process.

Some of the advantages of using this option are

• An application can easily render a UI that prompts the user for partial names and displays a list of person from which the user can select
• Configurable multiple person select option
• Configurable HR Status (active/inactive) option
• Configurable Per Org(Employees/Contingent workers/Person of Interest) option
• Optional drill-down to additional non-sensitive data
• The configuration is keyed by “Object Owner Id” which further provides the flexibility to use different configuration for different components

Example:

• In this example there is a hyperlink in a page as shown below

• On clicking this hyperlink the user sees the below Person Search Page. The search options available are configurable from the setup page.

• The user can use the above search options to search for person. The selection of person from the search result can then be tied back to the page from which Person Search page is launched.

Steps to do it:

• We add our own Object Owner Id value.  To do that we need to add a translate value to the field OBJECTOWNERID from the following navigation:  Main Menu > PeopleTools > Utilities > Administration > Translate Values. In the screenshot below we have created an Object Owner Id value “SOA”

• Next we have to Configure Person Search page for the Object Owner Id value created above by navigating to Main Menu > Setup HCM > Common Definitions > Person Search Match > Configure Simple Person Search. The details of the configuration options can be found in the PeopleBook - Person Search 

• Once we are done with the configuration we can test the Person Search configuration for our Object Owner Id by navigating to Main Menu > Setup HCM > Common Definitions > Person Search Match > Invoke Person Search API

• Technical Design

1. We add HR_PSS_DUMMY_FIELD of DERIVED_PSS record in level 0 of the page. This is a requirement for using the Simple Person Search functionality
2. We need to add another field at suitable level in the page which will act as the hyperlink which the user clicks to launch the Simple Person Search page
3. We need to use” PersonSearchSimpleUI” class, which belongs to Application Package HR_PERSON_SEARCH_SIMPLE
4. Within the field change event we instantiate the above mentioned class
5. We call SelectPeople () method to make this Search Page work. This method returns an array String (Employee IDs)
6. We need to then traverse through the array to get the employees and do the rest of the processing
7. We can also do some more manipulations by using several properties of the class. For example: to restrict selecting multiple employees from the search page we have to make MultiSelect property of the object as False.
8. Find below the Field Change PeopleCode for reference. Please note that the below code is for selecting only one person from the result set and assigning it to the field SOA_RECOG_ID.EMPLID

/********************************************************************************/

/* We have used custom Text Catalog (OwnerID: SOA )for the page formatting & all*/

/*Import the  Application Class*/

import HR_PERSON_SEARCH_SIMPLE:PersonSearchSimpleUI;

/*Declare the Object of the class*/

Global  HR_PERSON_SEARCH_SIMPLE:PersonSearchSimpleUI &PersonSearchSimpleUI;

/*Object instantiation*/

If &PersonSearchSimpleUI <> Null Then

   If &PersonSearchSimpleUI.propObjectOwnerID <> "SOA" Or

         &PersonSearchSimpleUI.propSubID <> " " Then

      &PersonSearchSimpleUI = create HR_PERSON_SEARCH_SIMPLE:PersonSearchSimpleUI("SOA", " ");

   End-If;

Else

   &PersonSearchSimpleUI = create HR_PERSON_SEARCH_SIMPLE:PersonSearchSimpleUI("SOA", " ");

End-If;

/* Accessing Methods declared in the class. This method helps in Selecting the employee from the search page*/

&arrEmplids = &PersonSearchSimpleUI.SelectPeople();

/*Traverse through the loop and read the employee id in the EMPLID field*/

For &j = 1 To &arrEmplids.Len

   If &arrEmplids [&j] = %EmployeeId Then

      Error ("Self Recognition is not permissible");

   Else

     SOA_RECOG_ID.EMPLID.Value = &arrEmplids [&j];

End-If;

End-For;

/*********************************************************************/

Contributed by Sourav Pal

How to design a file based inbound interface or data conversion process in PeopleSoft?

In our professional life as PeopleSoft consultant, many a time we come across requirement for a data conversion process or an inbound interface where we need to read an input file and then load the data into one or more PeopleSoft components. 

In this blog we list the steps of a very simple but working design approach. 

The requirement based on which this design is illustrated is as follows

• Develop a run control page with file attachment functionality, so that end user can attach the input CSV file before running the Inbound Interface
• Develop an Application Engine Program to insert or update data to the department component using component interface.
• The input file can consists of the following data
• New department information
• New effective dated row for an already existing department
• Changed values for non-key fields for an existing department and effective date combination

Please note in real world for Department component we may not even write an upload process and can make use of Excel to CI.

1.	Create a custom run control page with file attachment functionality (custom run control record, page, component & menu), so that user can attach a file and system physically stores the file to a pre-defined location.
2	Develop an application engine program that performs the following steps.
	·         Delete data from custom staging (STG) table. The structure of this SQL Table will be similar to the input file with additional fields like PROCESS, ERROR_FLG and ERROR_NOS ·         Select the attached file from custom run control record and store that to state record ·         Load the data from CSV file to STG table, and update the PROCESS field of the STG table to “N” and ERROR_FLG to "N" ·         Perform SQL Data validation (mostly referential integrity validations) in the Staging table based on the requirement. Mark the rows which have errors by updating the ERROR_FLG to "Y". ·         Read the rows of data from the staging table where ERROR_FLG="N", and execute the CI and insert data to PeopleSoft component. Mark the PROCESS field value for the successfully processed row to "Y". In case of CI errors, mark the ERROR_FLG to "Y" for those rows in the STG table. ·         Generate Reports by reading the data stored in the Staging table where ERROR_FLG = "Y"

Contributed by Milan

Best Practices - Folder Structure in Worksoft Certify

As we can only share / re-use processes within any given Project in Certify, the best option for end to end testing is to have a single Certify Project.

Below is the proposed folder structure for a typical Project:

Folder	Description
1.1 – Integrated Tests	This folder will contain final / approved versions of test scenarios/business flows. In Worksoft, Integrated Tests act as driver scripts that call one or more transactional tests in sequence and pass in global data elements. The folder will be secured so that only Admins can make changes and promote content from Staging. Sub-folders for each functional team will be present to keep the content organized.
1.2 – Transactional Tests	This folder will contain final / approved versions of transactional tests. In Worksoft, transactional tests are the reusable components that make up test scenarios (Integrated Tests). Transactional Tests may also have associated local data inputs. The folder will be secured so that only Admins can make changes and promote content from Staging. Sub-folders for each functional team will be present to keep the content organized.
1.3 – Utilities	Utilities are elements of logic that can be re-used within Integrated Tests or Transactional Tests. The folder will be secured so that only Admins can make changes and promote content from staging.
1.4 – Master Content	As part of the license agreement with Worksoft, we’ll have access to an existing library of SAP test cases in Certify that will be stored in this folder. Content that is useful from this library can be copied into staging in order to build transactional tests / integrated tests. The folder will be secured with the expectation that there will not be a need to make changes to this content.
2.1 – Sandbox	The sandbox area is where most Certify users will be working, as this is the preferred location for integrated tests and transactional tests development. Each user will have their own sub-folder under the Sandbox. In order to promote to the 1.x level, content must first be executed successfully in a user’s sandbox folder. Users will have full access to their sandbox folder and read access to other sandbox folders.

To know more about Worksoft Certify best practices reach us at info@soais.com

Contributed by Gautam

How to design an incremental/delta outbound interface?

In our professional life as PeopleSoft consultant, many a time we come across requirement for an outbound interface where we need to write/push data that had changed between last run and current run to a third party application. 

In this blog we list the steps of a very simple but working design approach. 

The example below assumes a file based integration but same design approach will also work for other integration. 

For this example, the requirement is to pull changed  active employees personal data (EmplId, Empl_Rcd, Name, Address1, Email ID and Phone) and write to a csv file.

In this approach we will use the following PeopleSoft object definitions:

• SQL Table - PS_SOA_PERSDT_NEW - stores the information of current run.
• SQL Table - PS_SOA_PERSDT_OLD - stores the information of previous run
• SQL Table - PS_SOA_PERSDT_INTF - stores the rows of those employees whose data has changed and thus has to be written to the output file.
• SQL Table - PS_SOA_PERSDT_HIST - maintain the history data
• An application Engine Program with SQL and PeopleCode actions
• A File layout

Below is the working flow of the outbound process:

• Truncate PS_SOA_PERSDT_OLD record
• Populate PS_SOA_PERSDT_OLD record from PS_SOA_PERSDT_NEW
• Truncate PS_SOA_PERSDT_NEW record
• Populate PS_SOA_PERSDT_NEW with employee id from PS_JOB where HR_STATUS=A and using the effective dated logic
• Update the required information for employees in PS_SOA_PERSDT_NEW using Correlated update and taking care of null values
• Update Name 
• Update Address 
• Update Email ID
• Update Phone Number
•  Populate the PS_SOA_PERSDT_HIST table with the previous run data present in PS_SOA_PERSDT_INTF table
• Truncate PS_SOA_PERSDT_INTF record
• Find the employee whose information had changed PS_SOA_PERSDT_NEW minus PS_SOA_PERSDT_OLD) and insert it to PS_SOA_PERSDT_INTF
• Using File Layout based on PS_SOA_PERSDT_INTF record, write to a file using standard PeopleCode built-in functions.
• Write Log Report based on the data in the PS_SOA_PERSDT_INTF

Contributed by Milan