I have generic data object present in the generic constellation comopnent where we built assets inside generic data object like Views,Actions and generic data pages(sourced from activity rule) to update data in the list of records.
Our goal is any data object that inherit the from above generic data type should be able to reuse these assets like actions,constellation views and generic data pages without rebuilding all of these again in thier implementing data types.
Since we have 70+ pega applications that have data objects inherit from the generic(abstract class) data type, we don’t want our 70+ pega apps to rebuild the same logic in thier impelmenting data objects.
Looks like in constellation this generic way of building assets like Actions,UI,data pages not possible, as we tried constellation looking for specific data object actions,data pages and not able to look at the data pages or actions defined in genric data object.
We would like to know is there any possible patteren in constellation to achieve this.
We are on Pega 25.1.3 version
@SritejaS17516613 Could you share a bit more how your setup looks? Inheriting data objects in built on apps is possible in Constellation. You might need to add the data object to your app via the re-use library if you haven’t already done so.
On a separate note: I would highly advice against using 1 generic data object that all things inherit from. I would build it in a modular way with properly defined data objects. You would still reuse these in your business apps, but making sure not to have these generic style data objects. For reference: Pegasystems Documentation
Thanks for your reply, Andrea. The setup is as follows:
At the generic component layer, we have a concrete data class, “Org-Data-Message,” which is not mapped to a table. Therefore, it maps to pr_other at the generic component level. We implemented functionality to display a list of message records on one of the Constellation landing pages and edit the message data when needed.
We defined lookup, list, and savable data pages in the “Org-Data-Message” generic class, using an activity rule as the source. Within the activity, we use dynamic class referencing—retrieving the class name from the data page instead of hardcoding it—to retrieve data from the implementing applications through obj-browse, obj-open, and similar methods. When these data pages run at the implementing application layer, they return data; at the generic layer, they return nothing.
We also defined Constellation List view, Edit, and Update details actions for this generic data object class.
With this setup in the generic application (component) layer, App A was built on the generic component and needs to reuse its data object functionality—displaying the list of message records and editing message data when required—without rebuilding everything implemented at the generic layer.
We tried this approach, but an error occurs when saving a message record in the implementing application.
@SritejaS17516613 Constellation doesn’t work well with DCR. I would stay away from these complex solutions in Constellation, strive to make it simple.
As for yor scenario, make sure it knows what object it is editing. The hint is the “null” as you point out - it doesn’t know what context it is in. The first step I would do is make sure your lookup is properly keyed.
I had a call with @SritejaS17516613 on this issue. We created the relevant data pages on the implementation-layer data object and updated the object’s default data sources to reference those pages. After reselecting the implementation list data page on the landing page, the CRUD operations began working correctly.
What I’m still trying to understand is the broader Constellation pattern here. My current understanding is that Constellation isn’t really optimized for DCR-based designs and seems to expect more explicit relationships between data objects and their list/lookup/savable data pages.
Has anyone successfully implemented landing page CRUD operations using a DCR-based data object pattern, or is the expectation that these data pages should always be defined on the concrete implementation data object?
we found solution to this constellation limitation of reusing generic data object assets(data pages,views) in the impelmentation data objects with simple workaround described below.
The workaround is implemented in the generic lookup data page. When the screen renders the record for editing, the context class is the implementation object class; This occurs because Pega calls the lookup data page while rendering the record for editing. In the lookup data page, we use DCR to open the implementation data object record from the generic component class.
By applying page-change-class in the lookup activity to the generic object class , we no longer receive an error when submitting the edited record. Also because the class is changed to the generic object class,now while saving we are switching back to implementation class through the savable data page activity again, so that the record is still saved to the correct implementation table.
This configuration works without moving data pages to the implementation layer and while retaining DCR.
However, we decided not to use this workaround because it overrides Constellation behavior. Instead, we removed the record-editing functionality from generic component and gave the alternative back end activities to edit records.
