If you use fetchxml with the latest web api, you may be surprised that sometimes you do not get the paging cookie back when your results are > 5000 records. There are alot of articles on the web about using the paging cookie once you do have it.
How do you make sure you get your cookie?
Some people suggest just sticking the paging number into the fetchxml is the answer, but that causes thrash on the server (even if its in the cloud) if you have alot of results to page through.
<fetch page="20" ...>
...
</fetch>
That’s not great as its possible that the server may need to keep running the same query and tossing aside results–maybe a cache will save the day, but maybe not.
The real answer to always generate a paging cookie is contained on MSDN.
You need to add the right odata annotation to have the paging cookie generated.
...code to generate the request
content += 'Prefer: odata.include-annotations="Microsoft.Dynamics.CRM.*"\n'
...
I have not seen this mentioned anywhere so far, so I thought I would write this up. Note that you can use the fully specified annotation Microsoft.Dynamics.CRM.fetchxmlpagingcookie but the .* version picks any other CRM specific annotation that may be out there so I use the .* version vs the specific one. The OData spec has alot of notes on annotations and how to add and remove them. It’s worth a read of course. Don’t forget to add your other annotations e.g. FormattedValues.
There are many API libraries out there that are quite poor in that they do not allow you to easily batch request your fetchxml if your fetchxml string length is too large for the URL variety. Be aware of you what tools you use and their limitations. There is still a URL length limitation in batch requests but it is much larger than the URL limitation. You’ll still need to chunk your fetchxml somehow if you are retrieving, for example, something that requires a large list of values in a condition clause.
No comments:
Post a Comment