Conversation

Pegasystems Inc.
PL
Last activity: 14 Sep 2025 6:32 EDT
Advanced Search Gadget - Limitations and alternate design
When working with Data Reference fields within your case, Constellation offers multiple ways to display and select the data you want to use. Advanced Search offers ways to filter and lookup the referenced data, allowing user to search the records via multiple sets of search criteria.
Unfortunately it has it's limitations - in this article I want to discuss those and possible ways to work around them.
Data Model AssumptionsIn all below examples we will use case MyCase that holds two data objects: Data-ObjA and Data-ObjB. Data-ObjB holds a foreign key to Data-ObjA. We’ve also created an Association between those two objects. [*similar setup can be also achieved by creating a Data Reference property in ObjB] Data-ObjA and Data-ObjB both have two scalar properties: Value and SearchCriteria – used withing the Advanced Search gadget configuration. |
Advanced Search Gadget Overview
As mentioned, Advanced Search offers ways to filter and lookup the referenced data, allowing user to search the records via multiple sets of search criteria:
While it is possible to display reference and associate properties in the search results, currently (as of Inf'24.2), only scalar properties on the searchable object are supported as Search Criteria.
Support for Reference Objects and Associations is currently on the product roadmap. In meantime, there are two ways, developer can provide such functionality to the end-users.
Data Base View approach
This approach requires Data Base level access to the environment, but minimizes the development impact and allows to leverage the Advanced Search gadget as is.
Instead of using the ObjA and ObjB classes directly in MyCase, we create a database view that aggregates both tables. Next, in the application we create a new data class Data-SearchAggregate which point to that view. With all properties exposed in the view (ObjA.SearchCriteria, ObjA.Value, ObjB.SearchCriteria, ObjB.Value), we can add SearchAggregate as reference property to MyCase and configure the AdvancedSearch gadget accordingly. The selected entries can be then copied to MyCase.ObjA and MyCase.ObjB in post-processing as needed.
Custom Search Gadget
This solution requires more complex development, but might be suitable when it’s not possible to alter the database tables and/or the data relations are more complex. It does not leverage the existing Advanced Search gadget – instead uses ootb Constellation controls that simulate similar behavior.
Data Model:
We introduce two new classes:
- Data-SearchAggregator that holds two Single Page (Manual) properties: ObjA and ObjB.
- Data-SearchAggregatorWrapper that holds PageList reference to SearchAggregator and two scalar properties: ObjASearchCritera, ObjBSearchCriteria
Next, we add new parametrized DataPages to ObjA and ObjB that will allow to search the entries by the appropriate Seach Criteria.
Next, we prepare a DataPage on Data-SearchAggregator class, that will accept all Search Criteria as defined on ObjA and ObjB, and merge the results from both tables (via abovementioned DataPages).
With the data model ready – we can configure UI, to display Search Criteria & Results as a separate View on Data-SearchAggregatorWrapper calls, to be reused in MyCase:
And runtime:
I hope you'll find those solutions useful in your projects, while the support for associations is developed within the Advanced Search Gadget itself. Feel free to share other approaches or comments.
Constellation 101 Series:
Enjoyed this article? See more similar articles in Constellation 101 series.