Question
Full text search of work objects: how to add columns of data to search results?
I am upgrading from 6.1 to 7.1.8. I have the following requirements implemented in 6.1
Show these columns in the search results from the Work Object search gadget:
- Case Type (class of work object)
- Work ID (pyID)
- Work object status (.pyStatus )
- Originator (OperatorID who created the work object)
- Creation Date (when object was created)
- Updated By (operator who last updated the work object)
The Problem
I cannot seem to implement this requirement, for two reasons:
- I can retrieve the Originator but I cannot display it
- I cannot retrieve data for Creation Date or Updated By
Details
In 6.1, work search results are returned in instances of Data-Work-Summary. This table maps the columns in my requirements to the corresponding properties in Data-Work-Summary and Work-
Column | Data-Work-Summary |
CaseType | pyClass |
WorkID | pyID |
WorkObjectStatus | pyStatus |
Originator | pyOriginator |
CreationDate | pyCreatedOn |
UpdatedBy | pyUpdateOperator |
In 7.1, work search results are returned on a page, of Code-Pega-List, called pySearchResultsWork
They are displayed in section Work-.pyShowResultsInNewWindow, with the following columns:
At runtime, the results list, pySearchResultsWork.pxResults, appears to be of Work- on the clipboard. However, it is actually of either Pega-Search-Work-Results or Data-Find-ResultsWork
The mapping of columns to properties is as follows:
Column | Property |
CaseType | pyCategory |
Description | pyLabel |
ID | pyID |
Status | pyStatusWork |
Updated | pxUpdateDateTime |
To match my requirements, I remove Description and Updated/pxUpdateDateTime. No problem.
The Problem Starts Here
Next I choose fitting properties for the columns I need to add. I had to try a few. We get this mapping (including several alternatives that I tried):
Column | Property | Problem |
CaseType | pyCategory | ok |
ID | pyID | ok |
Status | pyStatusWork | ok |
Originator | pyOriginator | |
pxCreateOperator | Null data (see below) | |
pxOrigUserID | Null data (see below) | |
Creation Date | pzWorkCreatedOn | |
pxCreateOperator | Null data (see below) | |
Updated By | pxUpdateOperator | Null data (see below) |
The reason for the invalid property references is the class of the List .pyWorkResults - which is Work-:
Those properties don't exist in Work- because they are from Pega-Search-Work-Results.
I tried changing declaring pyWorkResults as Pega-Search-Work-Results without success. That fails because pyWorkResults is actually of $ANY. And I can't override pyWorkResults in my own ruleset because it starts with "py".
As for the alternate properties I tried above, they return no data:
I checked the work objects in the results to ensure that those properties do, indeed, have values. It would take some strange coding choices to prevent a work object from being created with those properties populated, but it's best to be sure. The following screenshot is excerpted from the clipboard with work object G-4 open:
I have looked for a way to add these columns to the results that are returned, but I run into a wall of Final rules and, ultimately, a call to the search service, which is a SOAP service and opaque to me.
These are the properties returned by search results.
At the risk of sounding flippant, I'll observe that I can retrieve the class and ID five different ways each, but I cannot retrieve the properties I am looking for.
Summary
- I can retrieve the Originator as pzWorkCreatedOn, but I cannot display it because I can't add pzWorkCreatedOn to a rule
- I cannot retrieve the creation date or update operator
I originally submitted a less-detailed version of this request to GCS. I was directed to post my question here.
I am hoping that someone can tell me how to configure search to
- populate the missing data
- populate a value for Originator into a property that I can use
If not, then I think these issues are odd design/feature choices at best. I didn't dive into it, but I believe some of the other values returned by the search are also invalid for Work- and would therefore run into the same catch-22 if one tried to display them.
Hi Elliott,
First, I hope you don't mind me telling you how consistently awesome your posts are to this community. And I thank you for being open-minded to using the PSC to have this discussion in more detail, instead of your original SR.
Before you get too excited, I don't have an answer to this discussion. However, I did want to make sure that you are aware we will be having an Ask the Expert session specifically on Full Text Search in the month of April.
Which isn't to say I think discussion on this should wait. But, I do hope if this does spark a good dialog, you'll be open to continue sharing your thoughts, opinions, and questions during next month's session.
Thanks.
B.