Question
Groupama
FR
Last activity: 9 Jan 2025 9:27 EST
POST /data_views/{data_view_ID} filter on joint table
Hello, Do you know how to access joint table data using this method ? We need to retrieve properties on the linked work parties of our case and be able to use "orderby" on them. Unfortunately we just managed to retrieve data using the response datatransform but we can not put orderby on it.
Updated: 7 Jan 2025 22:02 EST
Maantic
US
@maximeBricet A table join can be accessed via configuring report definition. You can use this report definition as a source to the Data Page by which you would retrieve the records from the table. And I think Data view id is the data page name that you have to pass to this api. Try by implementing the same and confirm if it works. Refer to pega docs: https://docs.pega.com/bundle/dx-api/page/platform/dx-api/endpoint-post-data-views-data-view-id.html
Groupama
FR
@AnupamP16735362 Hello, thanks for the answer but my question was more about how to specify an order by on the joint table in the request schema itself. The request work for every other property retrieved in the data page except for the joint table ones. The doc specify only how to use the data views with the properties of the object, nothing about joint tables nor about page lists (that doesn't seems to work either). As our client wants to have the choice on the order by we can't hardcode an order by on the report definition.
Pegasystems Inc.
CA
May I know why you're not defining the Order By in the Report definition? I think the workaround is to handle the response data transformation and use the sort condition. However, you must copy the data required for sorting from pxPages to pxResults to handle the sort.
Groupama
FR
@RameshSangili Hello, the reason why we decided to use the data_views is to use it's ability to mix pagination and the flexibility on the retrieved and ordered by properties. All the logic of the report definition (properties, filter, order by, size, count ...) is now hold by the request. Allowing us to reduce the pega impact on front listing changes. We are now using using 2 datapages/repport definitions where we needed 10 of them when using "data/{ID}". It's way easier to maintain, the impacts on our data model are way quicker to implement and front dev can test their dev without waiting for pega changes implementation. About the response data transform we can not implement a sorting here as we are using pagination (we are only doing post process on the elements that are displayed to the client and not on the datas that are on the next/previous pages). Removing pagination is not an option as performances and flexibility on the filter criterias are critical for our client.