I am currently working on a requirement in Pega Constellation where I am developing a custom Landing Page using DX API Components.
Requirement:
• Pass input parameters dynamically to a Data Page (D_Page)
• Fetch data based on the input parameters
• Display the retrieved results within the Landing Page widget/component.
Could anyone please suggest the recommended implementation approach or share any reference documentation/examples related to parameterized Data Pages with DX API Components in Constellation?
Additionally, if there are any best practices or limitations to consider while implementing this approach in Constellation, your guidance would be greatly appreciated.
Just to confirm—this is about a custom DX Component, and the requirement is to invoke a parameterized Data Page from that component using DX APIs, correct?
If the goal is simply to pass parameters, retrieve data, and display the results on a Landing Page, you may want to first consider the OOTB Insights capability. Insights are well‑suited for this type of use case and can be directly embedded into Landing Pages without custom UI development.
However, if a custom DX Component is required, then the correct approach in Constellation is to invoke the DX API Data View endpoint from within the component code, passing the required parameters dynamically.
In Constellation, parameterized Data Pages cannot be consumed directly by UI components. They are exposed and accessed only through DX API Data View endpoints. A custom DX Component can call these endpoints and pass the necessary parameters, but the response handling—mapping the returned data to the UI fields—must be managed explicitly within the component.
This aligns with the supported Constellation architecture and ensures upgrade‑safe, compliant behavior. Let me know if this answers your question
Thank you for your response and for sharing the suggested approach.
In our requirement, we are specifically implementing a custom DX Component within a Constellation Landing Page. We are already invoking the DX API/Data View endpoint and passing parameters dynamically from the component.
However, the challenge we are facing is related to handling and rendering the returned data correctly within the custom component on the Landing Page.
We explored the OOTB Insights capability as well, but our use case requires additional custom behavior and UI handling that cannot be achieved through Insights alone.
Currently, we are looking for guidance or reference implementations specifically around:
• Parameter handling in custom DX Components
• Rendering D_Page response data dynamically in the Landing Page
• Best practices for integrating parameterized Data Views with custom Constellation components
Please let me know if you have come across any similar implementation examples or documentation related to this scenario.
@VijayG17537995 - Thanks for the clarification — that helps narrow the focus.
Since you are already invoking the DX API Data View endpoint from a custom DX Component and passing parameters dynamically, the overall integration approach is correct. At this stage, the challenge is primarily on the client-side handling and rendering of the response, rather than how the parameterized Data Page is invoked.
Based on experience, when using a custom DX Component for data display, all responsibilities such as parsing the response, managing state (loading, pagination, errors), and mapping fields to UI elements must be handled explicitly within the component, as Constellation does not provide automatic data binding for custom components.
One approach that worked well for us in similar scenarios was to preconfigure the Landing Page with fields bound to properties (editable or read-only), and then populate those properties by mapping the DX API/Data View response using a Response Data Transform or post-processing DT. This allows Constellation’s native property-to-field binding to render the data, reducing the amount of custom rendering logic required in the DX Component itself.
This pattern is particularly effective when the requirement is primarily data presentation with controlled UI behavior.
For more advanced or highly dynamic UI needs, handling the Data View response directly within the custom DX Component remains valid, but it does require full client-side state and rendering management using standard React patterns.
In summary, your architecture is sound and supported. The remaining effort is mainly around choosing the right balance between direct client-side rendering and leveraging property-based binding to simplify UI behavior in Constellation.
@VijayG17537995 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.
This will be very helpful for my learning and understanding of the approach. I appreciate you taking the time to share these insights. It really adds clarity to the concept I was exploring.
