Monday, January 18, 2016

CRM REST Builder 2.3.0.0 Now with Web API

It’s been long overdue for an update and with the recent release of CRM 2016 and the new Web API endpoint it seemed like the perfect time.
For those that might have used the tool before here’s the important info:

New and Changed
  • Web API Support (2016+)
    • Create, Retrieve, Retrieve Multiple, Update, Delete, Associate, Disassociate, & Execute Predefined Queries by Id and using FetchXML
    • Support for formatted values, impersonation, change detection, & count
    • XMLHTTP & jQuery
  • 2011 Enhancements
    • Fixed a lot of bugs, so many bugs
    • Corrected handling of self-referencing N:N relationships
  • General
    • Supporting library updates
    • Removed entities and attributes that weren’t supported be either endpoint
    • 1 click select & copy
    • Better escaping of special characters
    • Generate code to loop through results of included relationships
    • Lots of usability enhancements
Known Issues
  • Web API – Using RetrieveMultiple, any operation that requires expand (select or filter) isn’t supported by the endpoint yet and hasn’t been exposed in the tool. If you need this you’ll need to use the 2011 endpoint. I’m assured it’s coming at a later date by my friends at Microsoft. When using Retrieve, expand works as expected.
  • Web API – Attempting to use RetrieveMultiple and filter on a Date field that is designated as Date Only will fail with a 400 Bad Request error. I’ve been informed this is actually a bug with endpoint. The code being generated should be correct so I left this in hoping Microsoft would sneak a fix in before the next major update.
  • Web API – Using Retrieve, the endpoint doesn’t support using the expand operation using self-referencing N:N relationship so they aren’t displayed. Web API Limitations
  • Web API – Using Associate/Disassociate, again self-referencing N:N relationships are supported yet so they aren’t displayed.
Overview

If you aren’t familiar with the tool it’s essentially a code generator that creates JavaScript to perform actions against CRM’s REST endpoints. It installs as a managed solution into your organization so you’ll get the benefit of working with the entities and attributes that you’ve created. Point and click to specify the parameters and it spits out the code.

Even if you aren’t into coding, the tool can still be valuable if you’re looking to get information out of CRM that you wouldn’t normally be able to see very easily. There are quite a few entities in CRM that aren’t exposed through the UI or via advanced find but can be accessed through the web service calls this tool can perform. So if you need to query (or even create, update, or delete!) data about workflows, solutions, forms, views, etc. you can do that also because the tool has the ability to execute the code it creates and display any results.

Here’s a quick example. You need JavaScript code against the Web API endpoint to query for a list of accounts whose name starts with the letter “L”.
First define the options for endpoint, type of request, the entity to query against, the fields to return, the filter criteria, and any other options.

image

Hit the Create Request button and review the code that was generated. Copy the output to a web resource and use it CRM.

image

If you want to see the results, use the Execute Code button.

image

Get it on CodePlex:

2011 & 2013
https://crmrestbuilder.codeplex.com/releases/view/619461

2015 & 2016
https://crmrestbuilder.codeplex.com/releases/view/619460

Monday, December 21, 2015

CRM Developer Extensions v1.3.0.0

What’s new in this update:
  • New Solution Packager
    • 1 click download and extraction of CRM solution to a Visual Studio project
    • Re-package solution files from project
  • Added Support for CRM 2016 (8.0) NuGet assemblies
  • Added CRM 2016 JavaScript code snippets
  • Various bug fixes & enhancements
The Solution Packager addition provides a front end to the executable provided in the CRM SDK and binds it to a Visual Studio project so you can easily download solution artifacts and get them into source control. Additionally the zipped solution filed can also be downloaded to the project. There is also the option to re-package the file in the project back into a CRM solution.

Thanks again to the new contributors to the project, it's great to see people taking an interest!

Get the CRM Developer Extensions from the Visual Studio Gallery or install from Visual Studio 2012, 2013, or 2015 under Extensions and Updates.

If you are interested in contributing, have a suggestion (please make suggestions), or just want to check out the code you can do so here:
https://github.com/jlattimer/CRMDeveloperExtensions

Wednesday, November 25, 2015

CRM Web API Using Python

Another example using the new CRM Web API this time using Python.

Once again we have the luxury of using a version of Azure Active Directory Authentication Library (ADAL) but this time for Python. You can reference it using Python’s package manager (pip) with this info: https://pypi.python.org/pypi/adal/0.1.0

Again authenticating using a hardcoded username and password.
# CRM URL
RESOURCE_URI = 'https://org.crm.dynamics.com'
# O365 credentials for authentication w/o login prompt
USERNAME = 'administrator@org.onmicrosoft.com'
PASSWORD = 'password'
# Azure Directory OAUTH 2.0 AUTHORIZATION ENDPOINT
AUTHORIZATION_URL = 'https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000'

token_response = adal.acquire_token_with_username_password(
        AUTHORIZATION_URL,
        USERNAME,
        PASSWORD,
        resource=RESOURCE_URI
    )

token = token_response['accessToken']

In this case we aren’t even sending a Client Id as part of the authentication request.  

Additional information about ADAL for Python:

https://github.com/AzureAD/azure-activedirectory-library-for-python

You can check out the code on GitHub:

https://github.com/jlattimer/CrmWebApiPython

Web API Examples:

Tuesday, November 24, 2015

CRM Web API Using Java

Here’s an example that consumes the new CRM Web API from a Java application. I’m not promising this is the best written Java but it appears to get the job done.

Again our friends at Microsoft help us out on the authentication front by providing a version of the Azure Active Directory Authentication Library (ADAL) for Java. You can set up a Maven dependency with the info here: http://mvnrepository.com/artifact/com.microsoft.azure/adal4j

In this case I’m authentication using a hardcoded username and password.

//Azure Application Client ID
private final static String CLIENT_ID = "00000000-0000-0000-0000-000000000000";
//CRM URL
private final static String RESOURCE = "https://org.crm.dynamics.com";
//O365 credentials for authentication w/o login prompt
private final static String USERNAME = "administrator@org.onmicrosoft.com";
private final static String PASSWORD = "password";
//Azure Directory OAUTH 2.0 AUTHORIZATION ENDPOINT
private final static String AUTHORITY = 
    "https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000";

AuthenticationContext context = null;
AuthenticationResult result = null;
ExecutorService service = null;
try {
    service = Executors.newFixedThreadPool(1);
    context = new AuthenticationContext(AUTHORITY, false, service);
    Future<AuthenticationResult> future = context.acquireToken(RESOURCE,
            CLIENT_ID,
            USERNAME,
            PASSWORD, null);
    result = future.get();
} finally {
    service.shutdown();
}

String token = result.getAccessToken();

The other thing I stumbled upon is that Java’s HttpURLConnection for making HTTP requests doesn’t support the PATCH method natively (which is used by the Web API when doing updates to multiple fields). This was solved specifying a POST method and adding an additional “X-HTTP-Method-Override” property.

connection.setRequestProperty("X-HTTP-Method-Override", "PATCH");
connection.setRequestMethod("POST");

Additional information about ADAL for Java:

https://github.com/AzureAD/azure-activedirectory-library-for-java

You can check out the code on GitHub:

https://github.com/jlattimer/CrmWebApiJava

 
Web API Examples:


Monday, November 23, 2015

CRM Web API Universal Windows Platform Using C#

In this example I’m demonstrating how to use the new CRM Web API from a Universal Windows Platform (UWP) application. If you aren’t familiar with the “universal” application concept its Microsoft’s framework for writing a single application that can be run on all the modern Windows devices like phones, tablets, Xbox One, IoT, PC, Surface Hub, etc.

In the application itself the code to call the CRM Web API looks identical to the C# example I had previously posted. The real difference is that this time around we're not using ADAL to handle authentication. UWP applications can use the new WebAccountProvider which is native to Windows 10. If you’re targeting also targeting previous versions of Windows you’ll need to fall back to ADAL. You can check out a great blog post on the subject here:
http://blogs.technet.com/b/ad/archive/2015/08/03/develop-windows-universal-apps-with-azure-ad-and-the-windows-10-identity-api.aspx

Here’s what the basic authentication would look like.

//Azure Application Client ID
private const string _clientId = "00000000-0000-0000-0000-000000000000";
//CRM URL
private const string _resource = "https://org.crm.dynamics.com";
//Azure Directory OAUTH 2.0 AUTHORIZATION ENDPOINT
private const string _authority = "https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000";
private static string _accessToken;

WebAccountProvider wap =
        await WebAuthenticationCoreManager.FindAccountProviderAsync(
            "https://login.microsoft.com", _authority);

WebTokenRequest wtr = new WebTokenRequest(wap, string.Empty, _clientId);
wtr.Properties.Add("resource", _resource);
WebTokenRequestResult wtrr = await 
    WebAuthenticationCoreManager.RequestTokenAsync(wtr);

_accessToken = wtrr.ResponseData[0].Token;

You can check out the code on GitHub:

Web API Examples:

Friday, November 20, 2015

CRM Web API Using C#

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:
For CRM 2015 Online customers with Update 1 installed, you can check out the preview documentation and sample code here:

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.

//Azure Application Client ID
private const string _clientId = "00000000-0000-0000-0000-000000000000";
// Azure Application REPLY URL - can be anything here but it must be registered ahead of time
private const string _redirectUrl = "http://localhost/CrmWebApi";
//CRM URL
private const string _serviceUrl = "https://org.crm.dynamics.com";
//O365 credentials for authentication w/o login prompt
private const string _username = "administrator@org.onmicrosoft.com";
private const string _password = "password";
//Azure Directory OAUTH 2.0 AUTHORIZATION ENDPOINT
private const string _authority = 
 "https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000";
private static AuthenticationResult _authResult;
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

Monday, October 19, 2015

CRM Developer Extensions v1.2.1.0

What’s new in this update:
  • Integrated ILMerge on plug-in and custom workflow projects.

Saw a cool blog post from Nicolas Nowinski on using a an ILMerge build task to merge assemblies inside a plug-in or custom workflow. I thought it would be a cool feature so I added it to the Plug-in Deployer window. Selecting the option will add the proper NuGet package, set the copy local option on the CRM SDK assemblies and then merge referenced assemblies on build. Referenced assemblies still must be signed and CRM Online sandbox compliant (if applicable).


Get the CRM Developer Extensions from the Visual Studio Gallery or install from Visual Studio 2012, 2013, or 2015 under Extensions and Updates.

If you are interested in contributing, have a suggestion (please make suggestions), or just want to check out the code you can do so here:
https://github.com/jlattimer/CRMDeveloperExtensions