Quantcast
Channel: Sam's Activities
Viewing all articles
Browse latest Browse all 3363

Dynamics CRM 2011 Endpoint Deprecation - What does this mean for Dot Net development in CRM going forward??

$
0
0

I've been doing a lot of thinking and investigations into the new WebAPI since it was announced that the 2011 endpoint is going to be deprecated.

What i'm concerned about is the developer experience for Dot Net developers (which makes up probably 80% of code written against CRM) is vastly reduced and working with the WebAPI takes a lot more work than using the OrgService provided by the 2011 endpoint.

For example, updating an entity record in CRM using the orgservice is pretty simple, we have our proxy classes generated by the svcutil and we update the fields we want updated on an instance of the class, and submit this using the OrgService.Update method, and thats the end of it.

With the new WebApi, it not that simple, you now need to send through your object as a JSON string, which is ok for most field types, but when you have a lookup, you need to specify it as detailed here: 
msdn.microsoft.com/.../mt607875.aspx

PATCH [Organization URI]/api/data/v8.1/opportunities(00000000-0000-0000-0000-000000000001) HTTP/1.1
Content-Type: application/json
Accept: application/json
OData-MaxVersion: 4.0
OData-Version: 4.0

{
 "customerid_account@odata.bind":"[Organization URI]/api/data/v8.1/accounts(00000000-0000-0000-0000-000000000002)"
}
Now this is a lot more work from a developer's perspective, nevermind the effort to upgrade from systems extensively using the SDK for both plugins and integration.

SO my question is.. does anyone know if Microsoft is going to provide a proxy class in the SDK for the WebAPI that will work something like the OrgService we currently have?
OR are we as a community going to have to put our own proxy classes to simplify our development when using c#?

I've started playing around with creating my own proxy class, but it's not that straight forward. Retrieve's are fine, but update's and possibly a bunch of the other operations are tricky and it's feeling a little "hacky" as I built it.
I understand Microsoft's motivations around opening up the CRM api to other coding languages, but I hope the .net developers aren't going to have regress to writing c# code as if we were interacting with CRM via JavaScript or another language.


Viewing all articles
Browse latest Browse all 3363

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>