Logging What Users Are Searching For
Keeping a record of the transactions that are occurring in your PeopleSoft applications is a great way to prepare yourself for the inevitable security investigations that will need to occur after a security-related incident. While most logging can be done at the database level with triggers and audit tables, there are still some transactions that the database is not capable of capturing. One example of this is a transaction where a user inputs data into a search record on a component. I would say that logging this information is very important for certain components in PeopleSoft. Even though users are not altering the data in these situations, just knowing what the users are searching for can be useful information.
I previously achieved this sort of logging functionality with the use of servlet filters. Logging this information with servlet filters works great, but I decided to try to achieve this functionality solely within the application with the use of the event mapping framework provided by Oracle in the 8.55 PeopleTools. I am very impressed with how easy it is to implement this sort functionality within the application with this framework.
Below is a video demonstration of the event mapping framework and how you can use it log what users are searching for. If you are interested in this functionality, then CLICK HERE to download the app designer project. Import this project into app designer and follow along in the video to see how to map the app class code to components across the system. Note: The code in the project assumes that you are on a Windows machine with a C:\temp directory. This is where the logs are written to. A minor change will will be needed if your machine does not have this directory.
Comments
Bart
Colton, Thanks very much for this - it will be very useful, and not just for monitoring searches: in your video you made it very clear how to use event mapping. I put your project in one of our sandbox dbs for testing, and noticed that if a user does an open search in “User Profiles”, and then picks a user from the generated list, the resulting in the text (log) file returns a blank userID. When I do a return to search, pick another user, then the previous user search is logged. That way we’re one row out-of-sync. You’ll see the lines with the blank userID below. Do you have a easy fix for this?
| User | Component | Record.Field | Value | Timestamp |
| PS | USERMAINT | PSOPRDEFN_SRCH.OPRID | USER123 | 1497344986 | | PS | USERMAINT | PSOPRDEFN_SRCH.OPRID | PS | 1497346553 | | PS | USERMAINT | PSOPRDEFN_SRCH.OPRID | PS | 1497368000 | | PS | USERMAINT | PSOPRDEFN_SRCH.OPRID | | 1497368132 | | PS | USERMAINT | PSOPRDEFN_SRCH.OPRID | DELIO11 | 1497368146 | | PS | USERMAINT | PSOPRDEFN_SRCH.OPRID | MONSTONE | 1497368184 | | PS | USERMAINT | PSOPRDEFN_SRCH.OPRID | | 1497368203 |
Many thanks
Colton Fischer
Hello Bart. Thank you for bringing this issue to my attention. Unfortunately, I am not sure if there will be an easy fix for this.
This is due to a limitation in the amount of data that is presented in the client request that we parse in the event mapped code. When a user does an open search and selects a row from the search record, the posted key fields (PSOPRDEFN_SRCH_OPRID for example) in the request message are going to be blank. This is the reason for the blank value for the PSOPRDEFN_SRCH.OPRID field in your case. The actual OPRID value for the row that the user clicks on is not exposed in the request message.
You could possibly expand the code to log/examine the ICAction parameter. This parameter will contain what appears to be the row number that the user clicked on after the open search. The value for the ICAction parameter will look something like #ICRow0, #ICRow1, #ICRow2, etc. where the last digit seems to express the ith row of data that the user clicked after the search. While this parameter does not contain the actual key data searched for, you may be able to use this information along with the posted partial key values to query to search record yourself in the code to extract the key values for the record that the user is viewing.
Update:
After some further investigation of the ICAction parameter, it seems that it has the value of #KEY in the event that the user provides search key(s) that are an exact match to a row in the search record. Otherwise, it will have the #ICRow value when the user posts search key(s) that are not an exact match for to a row in the search record.
I believe the code I provided in this post can definitely use some reworking! I will be sure to share what I am able to get done. If you are able to devise a way to overcome this issue, then I would be interested hearing.
Leave a comment
Your email address will not be published. Required fields are marked *