Ever since Microsoft has published the “Important Changes Coming..” article that provides a very nice overview of what we should expect in the updated version of Dynamics, I could not stop wondering what does this mean:
With all the great reviews of this new release published on the web so far, I’ve never seen anyone asking a very basic question: so, what is going to happen to all the customizations which were supposed to be “supported” during the upgrades?
From the upgrade perspective, if you look at that screenshot above, you might think you just woke up to see your worst nightmare alive. Because if you have any client-side customizations at all, you’ll be most definitely using Xrm.Page.. which is now becoming deprecated.
So.. why don’t I speculate a little. And, if you have any specific details, please drop me a note, and I’ll update this post to reflect them.
1. What is a deprecated feature?
A deprecated feature is not, really, a feature that is immediately removed. More often than not, it’s a feature that’s not recommended for use anymore since it will be removed later. That’s my understanding, and, even though I can’t find a reference right now, I believe this is how Microsoft is treating “deprecated” features.
In other words, it seems we don’t need to worry about our javascript customizations stopping to work once V9 is here. On the other hand, we still have to start planning how are we going to deal with the removal of those deprecated features in the future.
2. What’s the story with the supported customizations vs unsupported customizations
From my standpoint, the difference between supported and unsupported customizations was, really, the corner stone in the foundation of all those business cases which we used to build in favor of using java script and / or plugins when we were talking to the clients.
If Xrm.Page is deprecated and meant for removal.. that’s going to be the last huge blow to that line of argumentation. There have been a few so far:
- We had to recompile our C# code for new SDK assemblies when 365 came around
- We had to switch from using ODATA / SOAP to using Web API on the client side (well, at least we had to start planning for the removal of the ODATA & SOAP endpoints)
In a way, that makes any javascript / plugin customization a potentially unsupported customization, so there is no certainty now. We are only working with the probabilities:
- The probability of business rules stopping to work is, say, 5% (with the updated business rules designer, some features stopped to work, actually)
- The probability of “supported” javascript stopping to work is, say, 10%
- The probability of “supported” SDK stopping to work is, say, 10%
- The probability of unsupported javascript stopping to work is, say, 30%
Etc.. See what I mean? It’s a shift of the paradigm – in terms of supported vs unsupported, nothing is certain anymore (and I mean nothing.. how about the whole Service Module being deprecated in v9? We could have guessed it would happen, eventualy, but still)
Another story has to be written now instead of that old one about supported vs unsupported – I’m not sure what the story is going to be.
But I got distracted..
3. What does Xrm.Page mean on that screenshot above?
That’s what I am really not sure about. It seems that the majority of those changes are focused on the “context”. Which is understandable – if you are in the context of the form, you have access to the form attributes. If you are in the context of the editable grid, you should have access to the grid attributes. However, how do you access form context from the ribbon button if there is no Xrm.Page? If there is an alternative global object that will allow that kind of access, then why not to keep Xrm.Page.. Besides, there are methods from the Xrm.Page namespace which are mentioned on the right side in that table (in other words, in the “replacement API” column):
In other words, it seems that, even though Xrm.Page is deprecated, some of the functionality is supposed to stay there.
I guess we’ll see what’s going to happen really soone, once V9 is here. But, like I said, if you have any more details for now, I’d really appreciate if you could drop me a note so I could share those details here.
My read of that is Xrm.Page is just a container that a lot of things have been stuffed into, sometimes things that don’t “belong” in a page. You’ll call that “getContext” method and –on a form– you’ll get the same object you got when referencing Xrm.Page before (perhaps minus all the non-Page stuff you didn’t use, like stuff about grids). In a grid, the same method will return you an object that gives you the grid functions without all the ui stuff about tabs and sections.
This is just supposition, but I admit Xrm.Page is getting kind of bloated; this will just give you the parts of Xrm.Page you need without referencing this global object everywhere.
I agree it probably makes sense to rearrange some of the XRM namespaces.. but I’m wondering how the upgrades are going to work (especially when someone goes from 2013/2015 to that v9+)
https://docs.microsoft.com/en-us/dynamics365/get-started/whats-new/customer-engagement/important-changes-coming#some-client-apis-are-deprecated