Data API performance and limitations
You use data APIs to retrieve the contents and metadata of specific data pages. You can sort, filter, and group data that you request from Pega Platform to specify how you want your data to be organized in the response. To ensure the high performance of your data APIs, review the following guidelines.
Performance considerations
- By default, all data API requests to queryable or non-queryable data pages that you source from a report definition sources will time out after 5 seconds.
When using pagination, consider the following:
- You can specify a maximum of 5,000 results per page in the "pageSize" field of the request.
- If you do not specify a value in the "pageSize" field, by default, the API returns a maximum of 100 results per page.
- If you fetch a total result count of more than 5,000 results, the
data API returns 5,000 results and displays a message that states
that the results are more than 5,000.
You can enable pagination for queryable data pages on the Load Management tab of the data page rule form. For more information, see Defining data page access.
- Any data pages that are configured in built-on layers of an application are only accessible with the data API if you set their status to API. By setting your data pages to the API status, you can control which data pages are accessible at an endpoint. For more information, see Setting rule status and availability.
- If you query a data page that you source from a report definition, you can filter the data to specify the set of data that is returned. However, if you update your data page source from a report definition to a REST connector, you have limited flexibility in controlling the amount of data that the REST connector returns. To control the amount of data that a REST connector returns, ensure that the endpoint has parameters for filtering the data. You can then map those parameters to data page parameters and provide values for the data page parameters as part of the Data API request.
Limitations
- Using a response data transform and post-load processing activity to add
calculated fields and update existing fields in the results is not
recommended for the following reasons:
- If you remove a field that is requested as part of the query to the data API in the response data transform, the column that is returned in the UI displays blank values.
- Sorting or filtering on the fields that you added or updated in the response data transform does not then work as expected.
- You cannot use properties that you define with access control policies for filtering, sorting, aggregating, or grouping data. This applies to the /data_views/{ID} and /data_views/{ID}/count data APIs.
- During the conversion from JSON to a clipboard page, the schema ignores any
additionally provided fields. If a field is not valid in the JSON schema,
the conversion skips the field. In the following example,
"pageType"is not a valid field in the request schema and the conversion skips it:"paging"{ "pageType" : "Single", "pageNumber" : 20 }. - The fields for any data type are considered to be text or string fields in
the request and response JSON in the following scenarios:
- When you filter rhs in the request, for
example:
"lhs":{ "field":"IsRetired" }, "comparator":"IN", "rhs":{ "values":[ "22/10/2020", "21/10/2020" - When there are aggregated fields in the response, for
example:
"query":{ "aggregations":{ "AverageAge":{ "field":"age", "summaryFunction":"AVG" }
- When you filter rhs in the request, for
example:
Previous topic Pega API best practices Next topic Retrieve a flat list of fields from Pega APIs