in 15.4, slice information is wrong when invoking NSQL (via SOAP) - cannot determine "has next page"
Article ID: 111891
Clarity PPM SaaSClarity PPM On Premise
Our company maintains an integration tool that interfaces with CA PPM (on a read and write basis), and uses NSQL for reading (since XOG would not work for performance reading). We use NSQL queries for all sorts of things...pulling in data like projects, tasks, incidents,..., but also configuration data like options for lookup fields based on dynamic nsql queries. We use slicing (paging) to limit the response size, and we, up until now, relied on the slice return value to tell us how many more pages there are. Steps to Reproduce: Pick any NSQL query with multiple results. When requesting (via SOAP API), pick a slice size that's lower than the total results. Observe that the last page retrieved will have a Slice size that's not the requested size anymore, but the actually returned number of items. On version 14.4, this wasn't the case, the slice size returned was always the requested one (no matter if less items were retrieved). Why is this a problem? We use the Slice.Number and Slice.Size fields to determine whether there are more pages to retrieve. Up until now, "if Number x Size isLessThan Total" means, there are more pages. This isn't true anymore with 15.4, because even though we know which page we are at and how many results there are, we have no way of knowing, when simply looking at the response document, if there is another page. I attached 2 examples, one using a 14.4 server, the other using a 15.4 server, to highlight the problem
Our Engineering team has analyzed this problem and has dispositioned it as "Not a Bug" (NAB). As part of fixing the defect DE37990, the 'size' element in the response was changed to represent the 'returned records count' instead of the 'requested size'. That has caused the issue you discovered; you were not able to identify if there is a next page or not via your integration scripts. The current implementation (size representing the records count) seems right because it represents exactly how many records are there in the slice. We consider the current defect as NAB. I presume you have already modified your integration code to adapt to this change. Let me know if you have any follow-up questions.