How to force Constellation to send Promoted Filter payloads to a Data Transform-sourced Data Page?

User Experience
1

Hi everyone,

I am trying to capture the values entered into Promoted Filters in a Constellation Portal UI. My List View is backed by a Data Page that is sourced by a Data Transform.

Currently, adding a value in the promoted filter does not trigger a network payload. Because of this, pyQueryPage is never created, leaving me unable to extract the Logic, field and value to set my parameters.

Has anyone successfully forced Constellation to send the query payload to a Data Page sourced by a Data Transform, or is there a recommended pattern to intercept these Promoted Filters natively without relying on a REST Connector?

Any guidance would be greatly appreciated!

2

Could you please confirm if the data page is configured to Queryable?

3

Yes, Data Page has the checkbox on “Allow query using a JSON object (recommended for queries using many fields)“ and also the status set to API.

4

Ranjay_Singh_1 and SebastiaanH your question from Empty List on Load in Constellation Landing page - let get it answered here.

I was under the impression from Source data for a table or list and CS docs like Authorization Inquiry that you could. However, based on:

  1. this unanswered post AND
  2. Question on this Constellation 101 Empty List on Load in Constellation Landing page - #5 by Ranjay_Singh_1
  3. This Pega doc Request Data Transforms for queryable Data Pages AND
  4. And this confusing mention of pySearchPageName Specifying a searchable Data Page

I am unsure there is clear direction. I won’t be able to answer today, it will need some time to investigate.

@JorgeAlbertoR did you ever find an answer?

5

@JorgeAlbertoR that’s why I missed this one originally! (its in General category :laughing:)

Are you in the User Experience Expert Circle? I would like to move this under that area, so it can be found with other Constellation questions. However, if you are not a member you won’t be able to respond (until you join), so don’t want to just move on you.

Please let me know if you join and i’ll move.

6

No, we had to block this requirement for the moment as all approaches followed didn’t gave the initial needed empty result.

7

I am not on the User Experience Expert Circle, I don’t mind if you move it, if that helps to get an answer to it.

8

We also tried this a lot but query page only construct when source is connectore or Local db report (as far as I remember) there is an article in 101 trying that approach of having a connector and service in own app and call connector from dpage and put data transform logic in service.

9

Can’t you suffice with using the param.pySearchPageName?
In the view, you have a filter with some fields, and as a source, you have a queryable datapage.

  • In the queryable datapage, as a source, you have a datatransform (pass parameters = true).
  • In the datatransform, you have parameter pySearchPageName (of type page), which is of the same class as the results usually.
  • The pySearchPageName page contains the fields you typed in in the UI (view), and you can use this page to map to parameters, which you can feed in the same datatransform to another datapage to give you the correct results.

This is nicely explained here:

Hope this helps, best regards,

Rogier Simonis

10

Hi @RSIMONIS this only works inside a case. The steps you describe is used by us in a similar way in a search and select solution. However on a Landing page with a list view and promoted filters there is no parameter that can be used. At least I can’t find it anywhere.

11

OK, so short answer: If your source is a datatransform and you are using Pega 25.1.2 and you are using promoted filters in a landing page, Pega will not refresh the query (/datapage) because it doesn’t think the datapage is queryable (it will disregard the datapage checkbox), so the filtering happens client side.

So my advise would then be, use a different source (like a report definition), and throw the rest in the response data transform.

Now how does Pega determine for promotable filters if it should filter client side (when source is data transform) vs server side (when source is report definition f.e.)?

It does this in the sdk, not by looking at the data_view api response, but at the pages api response of your landing page view.

Lets say I have my list as a subview of the pyHome landing page / view.

Pega will request this data via the following pages api call:

{domain}/prweb/PRAuth/app/{app-alias}/api/application/v2/pages/pyHome?pageClass={app-ui-class}

for example:

https://myenvironment.pegace.net/prweb/PRAuth/app/my-first-app/api/application/v2/pages/pyHome?pageClass=MyOrg-MyFirstApp-UIPages

In the response, in uiResources.resources.datapages you will see your datapage, and if it is either isSearchable (when sourced by a datatransform) or isQueryable (when sourced by a report definition f.e.).

Here a response if it is sourced by a report definition:

image
image407×257 5.83 KB

Here a response if it is sourced by a data transform:

image
image399×214 6.2 KB

This is all determined in the java of step 5 of pzGetShowPageData.

Lets hope Pega will enhance this in a future release so developers have a choice, like it works in a case, meaning, determination of a datapage being queryable is done by checking the value of the checkbox in the datapage rule itself:blush:. Performance-wise, client side filtering has its own benefits of course.

Thanks @SebastiaanH for clearing that up that the question was about landing pages.

12

@RSIMONIS I have tried your approach by configuring a data page with source report definition. However in my application that is using a native Constellation portal and not a SDK Constellation portal I am not able to get the expected parameter page in my response data transform.

In short the suggested approach does not work in my usecase.

@MarcCheong I hope you can provide some direction in how to solve this use case.

13

@SebastiaanH My comments were regarding using constellation-ui design system.

Here is some more explanation how to exactly establish your usecase.
Datapage should be set up as follows:

  • Source must be set to report definition
  • ‘Allow querying’ must be set to true
  • Post datatransform must be set to parse parameters

In the datatransform, you want to handle parameter param.pyImplicitParameter which can have a value like {“dataAPI” : { “dataAPIRequestPage” :“dataRequest_O6ZRF”}}

This (dynamically named) request page name mentioned in this param can be used in your datatransform, and contains all the filter configurations.

Here is a short example of how to map such a thing.

Screenshot 2026-05-07 165840
Screenshot 2026-05-07 1658402212×643 58.7 KB

image
image2210×432 27.8 KB

In the tracer you will see that this data request page looks as follows (in this example there was a property ‘Title’ and I filtered on the letter ‘k’:

image
image1423×800 61.2 KB

If you don’t succeed in this, please let me know.

14

@RSIMONIS

Awesome explanation. Nice trick to deserialize the JSON string and use that page. Did not think it would work like this. I have build this solution in my application. I am now able to load my landing page with an empty list. When I enter a parameter data is fetched from the database.

Only thing I need to change in my application is the setup of the data page. The class of the report definition needs to be the same as the class of the datapage. If this does not match the “Allow Querying” cannot be ticked. That is something we can do and has nothing to do with the query parameter issue :slight_smile:

15

@RSIMONIS this is amazing insight! This is the first I’ve seen someone do it without REST.

If you have time to create a new conversation under the “user experience knowledgeshare” category with this detail, I will link it in our Constellation 101 series ans to our REST connect implementation. Give our community more options.

Thabks again for all your contributions! (@Kamil_Janeczek :raising_hands:)

16

Thanks for detailed explanations.

17

Important Constellation 101’s on this topic - for those looking at this in the future:

Thanks @RSIMONIS for your addition to the knowledge on this topic!