Angular SPA in Dynamics CRM : ngXrmServiceToolkit

Having spent most of this year learning and using AngularJS and Typescript  on the one hand and working on Dynamics CRM projects on the other, I thought it a nice exercise to combine the two.

Every developer that has worked with Dynamics CRM knows, or at least (s)he should, that client side javascript customizations are a valuable addition to get that little bit of extra out of the standard Dynamics CRM package.

I myself have learned to appreciate javascript more by doing just that. Extending the standard functionalities of Dynamics CRM.

If you want to do more than some little cosmetic changes on a form, you can create your own webpages and use them in Dynamics CRM by inserting them as a WebResource. Keep in mind that you can only use HTML webpages to host in Dynamics CRM and they cannot execute server side code. You can reference other WebResources by creating a folder structure in the naming of your WebResources.
More information on that can be found on the MSDN  website.

So yeah, hosting an Angular SPA in Dynamics CRM, it’s possible.

If you don’t want to use any Dynamics CRM data in your Angular SPA, why host one in Dynamics CRM. So I started a simple CRUD application by using the fantastic XrmServiceToolkit library . There even is a Typescript definition file in the wild for that library. So I was good to go, or so I thought.

While the XrmServiceToolkit works great and is useable inside Angular, it relies on callback functions for asynchronous functionalities and has no support for promises. Which is a valid approach, don’t get me wrong, but I wanted those promises.

And so my focus changed from a simple Angular SPA inside Dynamics CRM with some CRUD executions to developing a reusable toolkit based on the XrmServiceToolkit and an Angular SPA that executes each of the SOAP and REST functions that I converted.

I called it the ngXrmServiceToolkit and it exposes the same SOAP and REST methods as the original, minus the SOAP grantAccess, modifyAccess, revokeAccess and retrievePrincipalAccess. Let’s call those work in progress.

So what is available:

• When accessing the Dynamics CRM SOAP endpoint:
  • createEntity
  • retrieveEntity
  • updateEntity
  • deleteEntity
  • execute
  • fetch
  • retrieveMultiple
  • queryByAttribute
  • queryAllByAttribute
  • setState
  • associate
  • disassociate
  • assign
  • getCurrentUserId
  • getCUrrentUserBusinessUnitId
  • getCurrentUserRoles
  • isCurrentUserInRole
  • retrieveAllEntitiesMetadata
  • retrieveEntityMetadata
  • retrieveAttributeMetadata

• When accessing the Dynamics CRM REST endpoint:
  • createRecord
  • retrieveRecord
  • updateRecord
  • deleteRecord
  • retrieveMultipleRecords
  • associateRecord
  • disassociateRecord

The result of my work is hosted on GitHub .

It includes the source code for the reusable Angular factories I created, a demo project created in visual studio and a managed Dynamics CRM solution that is the WebResource representation of the demo project.

This is the demo web page inside Dynamics CRM:

I made the Index-page the configuration page of the Solution. So all functionalities can be tested without touching anything else but the solution.

No custom entities or fields are being used. Both the SOAP and REST test actions can create (and update/retrieve/delete/…) an account and a contact. If you leave the configuration section of the solution without deleting the created test records, they will persist in your environment.

All actions are hardcoded, so there is little to no user input in the demo. It was just easier to create the demo that way.

How does the demo application work?

As there are 2 factories available, one for SOAP actions and one for REST actions, the demo application is divided into 2 sections to demo the available actions.

Each section has a set of dropdown buttons with actions connected to it.

There are test entities available in the angular controller and their JSON representation is shown on the page.

The result of each action is shown with a popup, or in the Fetch Result section or a combination of both.

A separate section is provided for the metadata actions.

Some actions cannot be executed in certain situation. E.g.: update account cannot be executed before the account has been created. The application will notify you with a popup message when that is the case.

Feel free to leave your thoughts, questions, issues about this demo or the toolkit in the comment section of this blog post, or directly in the GitHub repo.