Building XRM solutions for Danish Nature Agency

The Danish Nature Agency (naturstyrelsen.dk) is an agency of the Danish Environment and Food Ministry, managing approximately 200,000 hectares of forests and natural areas in Denmark. It goes without saying that they need a modern IT system that would help them not only with nature areas management and data forecasting, but also with planning the scope of their employees and co-operators’ responsibilities. Netcompany met the challenge to build this system.

Firstly, we have decided to use Microsoft Dynamics 365 platform (previously known as Microsoft Dynamics CRM) as a primary framework to build the application. Dynamics 365 was perfect for the short term delivery and identified relational business domain model. In addition to that, the ESRI ArgGis Server proved itself useful because of another requirement related to presenting maps and working with geometries on the maps. It is responsible for storing geometries data and all the functionalities relatedto managing maps, layers and polygons.

Both platforms have been integrated and they provide single, unified user interface for the end-user.

XRM approach

Most of you may think about Dynamics 365 Customer Engagement (or it predecessor – Dynamics CRM) as an application for managing sales, customer care and marketing processes in the organization. Our solution is about something entirely different,but we decided to use this system as a platform with XRM project approach. This means that in the XRM definition, the "X" is a variable that can represent almost any relationship that a business needs to manage.

Below you will find some statisticsregarding implemented custom components used to deliver required functionalities for our client.

Components	Description
Over 80 custom entities	Dynamics 365 entity is an object which represents business object in the system. It contains both data (represented by SQL database records) and metadata (information about entity forms, views, validation and behaviour).
Over 80 custom web resources	In our case – web resources are mainly HTML & JavaScript libraries. These components are responsible for handling Dynamics 365 client-side form events. They also provide some non-standard UI controls placed inside application user interface.
Over 100 (!) custom plugins	Dynamics 365 plugins are .NET libraries responsible for synchronous and asynchronous data processing and integrations.
15 custom processes (workflows & custom actions)	Our workflows are responsible for processing long-time back-end business flows. Custom actions may be treated as a REST API endpoints which are used in many places inside our system.
3 custom REST endpoints	.NET web application built with ASP.NET MVC Web API framework. Two of them are responsible for internal communication between different system components (facade pattern) and one of them is exposed to the Internet.
11 applications connected to the Dynamics 365 endpoints	.NET components connected to the Dynamics 365 web services responsible for data transformations and integrations.
External web application	JavaScript SPA application based on ESRI ArcGIS libraries integrated with Dynamics 365, responsible for map presentation and processing.
Custom mobile client	Because standard Dynamics 365 mobile client does not meet our client’s expectations we decided to build custom solution which will use the data stored inside Dynamics 365 database. This application is built with Ionic Framework and will provide full off-line data storage and synchronization functionality.

We are still working and building new functionalities, so the numbers mentioned above are growing. An interesting fact for the Dynamics 365/CRM Consultants and Developers: we are using only one (!) standard entity which is… e-mail ☺. As you have probably guessed, it is used for system events notifications for end-users.

System Architecture

As I have mentioned, our system is based on two components: Dynamics 365 server and ESRI ArcGIS server. The following diagram illustrates how these 2 platforms are integrated and how they cooperate with existing infrastructure and other system components.

Dynamics 365 and Esri ArcGis server provide core infrastructure for our solution. They both use web services and REST pattern for data exchange. Dedicated APIs have been created for both systems to provide easy, understandable data flow between them. Currently we have also 3 facade web services connected to the standard CRM API. They were designed to provide required data to the external applications.

Map SPA Application is the heart functionality of our system. It is HTML5 / JavaScript application responsible for most of the maps & geometries-related functionalities inside our system. It is available from the Dynamics 365 interface and it is communicating with both Dynamics 365 and ArcGis servers with the dedicated libraries and REST APIs.

Application security is based on Dynamics 365 security model. However, users’ roles assignment is managed via Active Directory catalogue. Thanks to custom data synchronization module between LDAP and Dynamics 365 database – security role assignment in Dynamics 365 is managed directly from the AD tools.

Dynamics 365 is also responsible for generating mails and text messages - notifications for the SABA system and for other systems inside our client’s environment. Custom event bus has been created inside Dynamics 365 and users may subscribe to notifications about different events types (also from the other, existing systems and applications).

Another interesting part of our solution is custom mobile application for the IOS and Android devices. We are implementing it with the Ionic Framework  based on free, open source development frameworks like: Apache Cordova and Angular. It allows to use standard web technologies (HTML5, CSS3 and JavaScript) to build cross-platform solutions. We use TypeScript for development and SQL Lite as a local, mobile data storage.

Approach to coding, testing and deployment

Our solution is quite complicated, with many dependencies between components, and this is why we had to create architecture that would allow to create of manageable and extendable code. For Dynamics 365 development we use dedicated Netcompany framework which contains many “ready to use” components related to platform logging, error handling, data access and many other areas. The project’s architecture consists of both open source and closed application platforms. That was the reason for adopting many design patterns and methodologies from different schools of programming. We try get the best out ofDomain Driven design, Services Oriented (SOA) and Event Driven Architecture (and from some others, too ?).

A huge code complication and many dependencies between components required automating our quality procedures and processes. Unit testing is a “must have” in our case. We are using NUnit framework (version 3) for the test automation. Additionally, Moq library has been utilized so that our tests are really “unit” ones, independent from any external resources.  

The system contains many different components which may work independently, but from the business perspective they only make sense as a whole. Currently, every developer working on the project has their own local development machine with Visual Studio & JetBrains’ Resharper. We have also one, centralized development environment where Dynamics 365 & ArcGIS servers are installed. This environment is hosted in the cloud on Azure Virtual Machines.

Our code base is stored in GIT repository. After committing code to the source control automated build is executed, all the unit tests are performed and (if everything is ok) new version of application is deployed into central development environment. We use Visual Studio Team Foundation Server 2017 as a Continuous Integration platform and therefore our developers do not have to waste their time deploying any components (or Dynamics 365 solutions) manually. For client’s environments – dedicated installation packages are built automatically and the only thing they have to do to install a new version is to run installation script in the destination environment.

As you can see – we use many coding best practices and techniques, like architectural patterns, continuous integration, testing automation. These factors make Netcompany and its Dynamics 365 projects very different from other integrators where very often the only approach to technical part of solution is “sit down and write code” ?.    

Future

There are some interesting technologies and we’ll be using them for sure in the upcoming future. First thing which is worth mentioning is a system desktop client which will be implemented as a Windows Universal Platform application. We’re also planning to work with Microsoft Azure Cloud, especially Azure App Logic platform to meet some of the client’s requirements. Of course – we’ll still be extending existing functionalities set, so there will be a lot of work for Dynamics 365 & ArcGis consultants and for C#, JavaScript & TypeScript developers on the project.

Join us in this adventure!

Currently we have heaps of Dynamics 365 / CRM projects in Netcompany. Many of them are (like the one described above) pure XRM solutions utilizing Dynamics 365 services as a platform. If you are a Dynamics 365 Consultant or Developer and you are tired of everyday sales processes deployments and “no code” approach during your projects – Netcompany might be a great place for you.

Piotr Gaszewski – Senior Consultant, CRM at Netcompany