Showing posts with label Search. Show all posts
Showing posts with label Search. Show all posts

Friday, 2 September 2011

PeopleSoft Search

If you’ve been browsing my blog directly, you may have already noticed the PeopleSoft Search link on the site’s header. This is simply a Google Custom search engine pointing to sites containing relevant PeopleSoft technical content. This includes mostly forums and blogs.

I find this useful when I need to search for keywords that are not specifically related to PeopleSoft. Following is an example result when searching for “excel”:
Sample Search result

I still have trouble filtering out RSS from the results, if anyone can help me with that.

Now, if you’re browsing my site using Firefox 2, you may also notice the following auto-discovered PeopleSoft Search item on your search bar:
Firefox Search Engines

Following is how the auto-discovered search would like it IE7:
IE7 Search Engines

This plugin is packaged using the OpenSearch standard, as described in this Mozilla article.

The plugin can also be installed by clicking the following link:

Install PeopleSoft Search

Thursday, 1 September 2011

Prompt Values Specified on Add Mode Search Record is not Enforced When Using ExcelToCI

While creating component interface, by default it will not enforce the prompt values specified on Add search record and will allow you to enter values even though they are not valid. This issue occurs when inserting new rows using ExcelToCI as it allows the user to enter invalid values without giving any error message.


To avoid this issue, open up the Add Mode Search Record for the component and go to Record field properties for the search fields and check the Search Edit check box.  This will enforce the use of valid values when adding a new row using component interface used in ExcelToCI. By default, Search Edit is not enabled.


Below is the description of this field in PeopleBooks.


Search Edit is enabled only if Search Key is selected. Selecting this option enforces the required property and table edits on the search page. It also enforces these edits under circumstances where the search page would normally be bypassed. With this option, the user no longer has the ability to perform partial searches on this field.


Below is the MOS (My Oracle Support) link related to this issue.


E-CI: Component Interface Does Not Validate Record Edits (Against Prompt table) When Using Create [ID 664377.1]


Does Row Level Security Work in ExcelToCI? (Doc ID 972241.1)


As per the above resolution, row level security is not enforced using ExcelToCI.


Wednesday, 31 August 2011

Error in Recruitment – Build Applicant Search


This probably won’t help a great many people, but for the small minority it does help it might save them a lot of time …


There’s a problem with the Applicant Search process in HR9.1 (we’re currently on MP2).  When you build the Applicant Index it starts the HRS_SRCH_IDX process.  This App Engine starts one or more HRS_SRCH_APP processes.  Sometimes HRS_SRCH_APP runs to Success, other times it doesn’t.  Initially we thought this was down to locking (if there are more than one running simultaneously one was trying to delete from a table that the other was inserting into), however we set the concurrency to 1 and this was still occurring.


Examining the log files we could see that it loops through all languages in the system (regardless of how many languages had been installed) and creates a subdirectory under ps_cfg_home\data\search\HRS_ResumeText\\ for each language. The process gets as far as Italian and then fails (it creates an ITA directory and all the containing files, but does not create JPN – the next language).


We checked out customer connection My Oracle Support and there wasn’t a great deal.  The only relevant post we could find was this one which suggested deleting the JPN language from PSLANGUAGES (and I suspect all of those following JPN).  Unfortunately we need multi-language support so this wasn’t a viable option for us.  There wasn’t anything on Google either so we were on our own.


Looking through the log files we found this:
mkvdk - Verity, Inc. Version 6.2.0 (_nti40, Jan 30 2008)
Error   E0-1509 (Drvr): dlopen() returned:
Error   E0-1510 (Drvr): Error loading driver library 'D:\ps_home\verity\winx86\_nti40\bin\locbasis.dll'
Error   E0-1203 (Language): Error reading language definition file: D:/ps_home/verity/winx86/common/japanb/loc00.lng
Error   E0-1230 (Language): Could not create locale japanb
Error    (): Fatal error - exiting
mkvdk done
mkvdk: VDK error -200: couldn't create VDK session
Both of the files referenced in the error message (locbasis.dll and loc00.lng) are present and read/write to the Process Scheduler user account though, so this wasn’t much help.


The code in the App Engine calls a fair sized chunk of Application Package PeopleCode, but eventually I found the logic that creates the directories/Verity Search collections.  The last command issued before the error was:


bin\server\winx86\mkvdk -create -collection -locale japanb d:\ps_cfg_home\data\search\HRS_ResumeText\TST\JPN -logfile d:\ps_cfg_home\data\search\HRS_ResumeText\TST\veritybuild.log


When I run this in a command prompt window (after setting the ps_home env var) I get the following error message:


The program cannot start because MSVCP71.dll is missing from your computer.


Interesting, so I have a missing dll.  Using Process Monitor (the SysInternals one, not PeopleSoft Process Monitor) I can see that it’s looking for the dll in ‘\verity\winx86\_nti40\bin\’.



Once I located a copy of the DLL and copied it there the HRS_SRCH_APP process ran fine and the directories were created for all languages.


So why is this file missing?  I believe it’s an issue of Oracle assuming that Microsoft bundles it in Windows, and Microsoft no longer doing so.  See this from Microsoft:



The shared CRT DLL has been distributed by Microsoft in the past as a shared system component.  This may cause problems when you run applications that are linked to a different version of the CRT on computers that do not have the correct versions of the CRT DLL installed. This is commonly referred to as the “DLL Conflict” problem.  To address this issue, the CRT DLL is no longer considered a system file, therefore, distribute the CRT DLL with any application that relies on it.

Be the first to like this post.