The 2011 SOAP based endpoint is on its way out and the new 2016 REST based endpoint is on its way in. But don’t panic, this isn’t something you need to worry about right now if you’re already doing CRM development as the current SOAP endpoint is still going to work in 2016. Eventually this might lead to another major change like we saw going from v4.0 to 2011 but it’s really too early to tell.
If you are using CRM or are thinking of acquiring it soon and happen to be doing development outside of the .NET world, then this is something you’ll want to pay attention to right away. Trying to connect to CRM outside of .NET up until this point has been a fairly unpleasant experience. Everyone has undoubtedly seen at this point that Microsoft is doing it’s best to make sure its products and services can work on the broadest range of platforms that it can. This extends to being able to consume those services (like CRM) from as many different languages as it can. Building on top of RESTful web services goes along way in accomplishing that goal. To show how easy it can be I’ll be posting the same examples in a variety of different languages and scenarios.
Examples:
https://msdn.microsoft.com/en-us/dynamics/crm/webapipreview.aspx
To get started you’ll need to pre-register an application with Azure / On Premise Active Directory in order to get the Client Id the application needs. The steps can be found here:
https://msdn.microsoft.com/en-us/library/dn531010.aspx
This C# example really isn’t doing much different from the samples Microsoft provides. Both use ADAL (Active Directory Authentication Library) (get it from NuGet) to handle authentication and both do similar operations (Create, Read, Update, Delete & WhoAmI) but the one thing my sample shows is using one of the overloads for the AcquireToken method to actually get authenticated. The Microsoft sample shows how an interactive authentication would work by popping open the A/AD login page. I’ve also included a sample of how this can look when using a hardcoded username and password combination for an integration type scenario where user interaction wouldn’t make sense.
Of course the other cool feature to consider is that there is no longer any dependency on the CRM SDK assemblies. Hopefully 2016 SDK will not ship with ADAL in the set of binaries, hopefully forcing everyone to get it from NuGet and preventing a some of those dreaded missing assembly reference errors when you get someone else’s code from source control that didn’t use NuGet.
You can check out the code on GitHub:
https://github.com/jlattimer/CrmWebApiCSharp![]()
If you are using CRM or are thinking of acquiring it soon and happen to be doing development outside of the .NET world, then this is something you’ll want to pay attention to right away. Trying to connect to CRM outside of .NET up until this point has been a fairly unpleasant experience. Everyone has undoubtedly seen at this point that Microsoft is doing it’s best to make sure its products and services can work on the broadest range of platforms that it can. This extends to being able to consume those services (like CRM) from as many different languages as it can. Building on top of RESTful web services goes along way in accomplishing that goal. To show how easy it can be I’ll be posting the same examples in a variety of different languages and scenarios.
Examples:
- C# (Console)
- C# Windows Universal – Coming Soon
- Java (Console) – Coming Soon
- Python (Console) – Coming Soon
- Python (Django) – Coming Soon
- JavaScript (Inside CRM) – Coming Soon
- JavaScript (Outside CRM) – Coming Soon
https://msdn.microsoft.com/en-us/dynamics/crm/webapipreview.aspx
To get started you’ll need to pre-register an application with Azure / On Premise Active Directory in order to get the Client Id the application needs. The steps can be found here:
https://msdn.microsoft.com/en-us/library/dn531010.aspx
This C# example really isn’t doing much different from the samples Microsoft provides. Both use ADAL (Active Directory Authentication Library) (get it from NuGet) to handle authentication and both do similar operations (Create, Read, Update, Delete & WhoAmI) but the one thing my sample shows is using one of the overloads for the AcquireToken method to actually get authenticated. The Microsoft sample shows how an interactive authentication would work by popping open the A/AD login page. I’ve also included a sample of how this can look when using a hardcoded username and password combination for an integration type scenario where user interaction wouldn’t make sense.
AuthenticationContext authContext =
new AuthenticationContext(_authority, false);
//Prompt for credentials
//_authResult = authContext.AcquireToken(
// _serviceUrl, _clientId, new Uri(_redirectUrl));
//No prompt for credentials
UserCredential credentials = new UserCredential(_username, _password);
_authResult = authContext.AcquireToken(
_serviceUrl, _clientId, credentials);
var token = _authResult.AccessToken;
Of course the other cool feature to consider is that there is no longer any dependency on the CRM SDK assemblies. Hopefully 2016 SDK will not ship with ADAL in the set of binaries, hopefully forcing everyone to get it from NuGet and preventing a some of those dreaded missing assembly reference errors when you get someone else’s code from source control that didn’t use NuGet.
You can check out the code on GitHub:
https://github.com/jlattimer/CrmWebApiCSharp