You’re offline. This is a read only version of the page.
Hi,
Within my model driven app (solution), I want to update an XML WebResource i.e. update the XML.
How can I do this using JavaScript and WebAPI.
Thanks
- Rory
It's definitely working this end when not sending the
odata.include-annotations:
You see above it's returning 304
When sending the odata.include-annotations:
It returns 200.
Ideally we would have a way of controlling which headers are sent by Xrm.WebApi so we could benefit from the caching that it does. Since this recent change to CDS, Xrm.WebApi will never return a cached record.
It is interesting that if you send an $expand with the query, then the etag 304 responses will not be sent either - this was always an issue with the Xrm.WebApi - in that if a related record was updated and included in $expand - you would still get the old verison.
Hi @ScottDurow
Thank you for your help and for the feedback. We tried to verify your findings on our side, but we didn't made it.
We tried the webApi Requests without Xrm.WebApi client sdk (own XMLHttpRequests), with a few include-annotations combinations like (
odata.include-annotations=OData.Community.Display.V1.FormattedValue
odata.include-annotations=Microsoft.Dynamics.CRM.lookuplogicalname
odata.include-annotations=OData.Community.Display.V1.FormattedValue,Microsoft.Dynamics.CRM.lookuplogicalname
) and also tried without any include-annotations header, nothing helped: we get always a response 200.
It definitely worked before. We have this unit test since a few years already. Not sure when it started failing, but in January still worked.
If the behaviour is by design, then I guess that there is no chance to get cached data anymore...
Best regards,
Diana
Ok - a little more info - apparently this behaviour is intentional because the include-annotations header will mean data from related entities could be potentially different even though the etag is the same - hence it disables the 304 response.
Interestingly I've found why it's not returning 304 - it's because the Xrm.WebAPI sends odata.include-annotations="*" - without this CDS will return 304 if the etag matches.
Hi @ben-thompson @DianaBirkelbach
I've done some tests and also see that although If-None-Match is in the request, CDS is not returning 304 as expected if the Etag is the same. I would raise a support call because this not how it's supposed to work - https://docs.microsoft.com/en-us/powerapps/developer/common-data-service/webapi/perform-conditional-operations-using-web-api
Reads are definitely counted towards your API Entitlement limit! The dashboard in the admin centre doesn't yet show all the API entitlement calls - so it won't always reflect what's happening. This will change soon I hope!
I suspect read only requests are not being counted. As an example - this is the last hour for the dev box I'm currently trying to debug a none PCF piece of javascript on
Now there is a lot of read calls within the javascript and I'm continually refreshing the page (which is resulting in a lot of status 200 requests) but the number of webapi calls isn't increasing.
And that to me is exactly how the webapi limitations should be working - anything that touches the record should be charged for but anything that is simply reading data should be at no cost and it was the idea that read calls would be charged that was the problem I had with the change here, you can estimate how many records are created / updated on a daily basis, it's hard to tell how many records you may need to quickly check something on.
That's a very interesting thought @ben-thompson !
That would explain why the update unit tests containing ETAG are still succeeding.
So there is no cache for the requests anymore...?
Does this also means that the WebAPI Limit will easily be reached, and Licenses are therefore more expensive?
Does the introduction of the t-sql CDS connection vaguely correspond with the tests starting to fail?
If it is then I suspect the answer is that Microsoft have switched their architecture and read requests are being sent from a read only replica of the database rather than being sent directly from the master database.
Hi @ScottDurow ,
@ben-thompson was kind and showed me your blog about automatically caching using ETAG and Xrm.WebApi sdk.
But I tried it out, and making the same request a few times in the console, it returns always the status 200. If it was cached, it should have returned 304, right?
Not sure if it's the same issue, but actually our Unittests about making WebApi HttpRequests with optimistic concurrency suddenly started failing a few weeks ago (maybe already a few months ago) in all our Systems, because the response Status is always 200.
Are you aware of this issue? Am I missing something?
Kind regards,
Diana
@DianaBirkelbach Xrm.WebApi has it built in see https://develop1.net/public/post/2018/12/31/reasons-to-use-xrm-webapi-1-etag-magic I've played around with it enough to know what it's doing but not enough to be happy to write about it.
As for environment settings - I think it depends on how much control you have over the whole environment. Being an ISV I find config entities provide a more configurable solution.
And as for field service being a bad design, it's useful when you want to argue that your design isn't complete rubbish.
#1
WarrenBelz
109
Most Valuable Professional
#2
Michael E. Gernaey
82
Super User 2025 Season 1
#3
MS.Ragavendar
72
Share
Report
All responses (
Answers (
