Microsoft Dynamics 365 Extensions Cookbook

Rami Mounla

• Publisher: Packt Publishing
• Year: 2017
• ISBN:
  9781786466747
• Edition: 1
• Topic: Business
• Subtopic: Business Intelligence
• Index: Business

More than 80 recipes to help you leverage the various extensibility features available for Microsoft Dynamics and solve problems easilyAbout This Book• Customize, configure, and extend the vanilla features of Dynamics 365 to deliver bespoke CRM solutions fit for any organization• Implement business logic using point-and-click configuration, plugins, and client-side scripts with MS Dynamics 365• Built a DevOps pipeline as well as Integrate Dynamics 365 with Azure and other platformsWho This Book Is ForThis book is for developers, administrators, consultants, and power users who want to learn about best practices when extending Dynamics 365 for enterprises. You are expected to have a basic understand of the Dynamics CRM/365 platform.What You Will Learn• Customize, configure, and extend Microsoft Dynamics 365• Create business process automation• Develop client-side extensions to add features to the Dynamics 365 user interface• Set up a security model to securely manage data with Dynamics 365• Develop and deploy clean code plugins to implement a wide range of custom behaviors• Use third-party applications, tools, and patterns to integrate Dynamics 365 with other platforms• Integrate with Azure, Java, SSIS, PowerBI, and Octopus Deploy• Build an end-to-end DevOps pipeline for Dynamics 365In DetailMicrosoft Dynamics 365 is a powerful tool. It has many unique features that empower organisations to bridge common business challenges and technology pitfalls that would usually hinder the adoption of a CRM solution. This book sets out to enable you to harness the power of Dynamics 365 and cater to your unique circumstances.We start this book with a no-code configuration chapter and explain the schema, fields, and forms modeling techniques. We then move on to server-side and client-side custom code extensions. Next, you will see how best to integrate Dynamics 365 in a DevOps pipeline to package and deploy your extensions to the various SDLC environments. This book also covers modern libraries and integration patterns that can be used with Dynamics 365 (Angular, 3 tiers, and many others). Finally, we end by highlighting some of the powerful extensions available.Throughout we explain a range of design patterns and techniques that can be used to enhance your code quality; the aim is that you will learn to write enterprise-scale quality code.Style and approachThis book takes a recipe-based approach, delivering practical examples and use cases so that you can identify the best possible approach to extend your Dynamics 365 deployment and tackle your specific business problems.

Enhancing Your Code

In this chapter we will cover the following recipes:

• Refactoring your plugin using a three-layer pattern
• Replacing your LINQ data access layer with QueryExpressions
• Logging an error from your customization
• Converting your plugin into a custom workflow activity
• Unit testing your plugin business logic
• Unit testing your plugin with an in-memory context
• Integration testing your plugin end-to-end
• Profiling your plugin
• Building a generic read audit plugin
• Using Cross-Origin Resource Sharing with CRM Online

Introduction

Most customization examples that you will find in books and official articles will mainly focus on the basics to get you started. They seldom delve deeper into how to structure your code for clean code and best practices. Any customization you build--whether using JavaScript, C#, or any other language or framework--should follow best practices. Plugins, for example, can very easily get too large and difficult to maintain if no thought is put into structuring them properly.

In this chapter we will start by refactoring our one class C# plugins into three layers: entry point, business logic, and data access layer (DAL). We will also introduce design patterns, such as dependency injection, singleton, and factory. Most of the enhancements will leverage fundamental object-oriented paradigms including: inheritance, encapsulation, and polymorphism, among others. A basic understanding of these patterns and paradigms is recommended, but not necessary.

The first recipe is key to the rest of the chapter, as it will enable some new capabilities. Most notably, this includes the ease of unit testing and the ease of swapping classes' implementations with minimum, if any, alterations to the rest of the dependent classes.

We will look at how easy it is to replace a complete DAL implementation in Replacing your LINQ data access layer with QueryExpressions, how easy it is to replace our logging class in Logging error from your customization, and how easy it is to convert a plugin into a custom workflow activity in Converting your plugin into a custom workflow activity, all in this chapter.

From a unit-testing perspective, we will be running a business logic unit test, a live integration test, and an end-to-end plugin test by using an in-memory organization service. Think of in-memory as a fake Dynamics 365 instance built in milliseconds for the purpose of our unit test.

The following simplified sequence diagram highlights some of the layers used in this chapter:

• The first sequence at the top traces the layers traversed when unit testing the business logic. As a true unit test, all dependent layers are either skipped or mocked.
• The second sequence in the middle highlights the live integration test, where the plugin is deployed to Dynamics 365 and triggered through the API to mimic a use case. All layers are invoked and the results are verified back in the live Dynamics 365 instance.
• The last sequence at the bottom traverses all the layers; it bypasses Dynamics 365 and uses an in-memory service context as shown here:

Different combinations are possible because of the multilayered refactoring. Regardless of whether you are building a pure .NET application or a Dynamics 365 extension, best practice and clean code rules apply.

Refactoring your plugin using a three-layer pattern

In previous recipes, we implemented our plugins in the easiest and fastest way to demonstrate specific scenarios. The purpose of this recipe is to enhance the structure of your code and turn it from a one class code behind (spaghetti code where all logic and layers are tangled in one class) to a layered code (lasagna code where each layer is separate and well defined without entanglement). The three layers we will be implementing are the entry layer (the actual plugin), the business logic, and the data access layer. We will also create a few other utility classes to increase reusability.

This recipe will be based on the first plugin we implemented in the Creating your first plugin recipe in Chapter 4, Server-Side Extensions. We will refactor it to use the inversion of control (IoC) pattern, which will facilitate unit testing. We will be able to easily swap between different DAL implementations and easily convert our core code from a plugin to a workflow or console application.

More specifically, we will extract interfaces for each of the data access layers, along with a base data access class that bundles common methods. A factory class will help resolve concrete classes based on requested interfaces. Separate business logic class will separate the logic from the plugin, and finally a base class for all plugins will contain common logic used by most plugins.

Getting ready

To refactor our existing code, we will base this recipe on the plugin code written in the Creating your first plugin recipe in Chapter 4, Server-Side Extensions. The usage of a compatible Visual Studio IDE is strongly recommended. We will be using Visual Studio 2015. The solution must have the Microsoft.CrmSdk.CoreAssemblies NuGet package installed. Optionally, if you are using an organization service context, then you will need the CrmSvcUtil early bound classes generated. In this example, we are using the Pact.Xrm.Entities namespace for the early bound classes and optionset enums generated in the Creating early bound entity classes and Extending CrmSvcUtil to generate optionsets enum recipes respectively of Chapter 3, SDK Enterprise Capabilities.

Alternatively, if you are writing your code from scratch, you can just follow the same patterns for your new plugin.

How to do it...

1. Create a public interface called IBaseDataAccessLayer in a folder called DataAccessLayer.
2. Add the following using statement:

 using Microsoft.Xrm.Sdk; 

3. Add the following two signatures:

 void UpdateEntity(Entity entity); 
 void Commit(); 

4. Create a public base class called BaseDataAccessLayer that implements IBaseDataAccessLayer and IDisposable in the same folder.
5. Include the following using statements:

 using Microsoft.Xrm.Sdk; 
using Packt.Xrm.Entities; 

6. Remove the organization server and organization proxy from your old plugin and then add a protected variable to your abstract class, as follows:

 protected IOrganizationService OrganizationService; 
protected OrganisationServiceContext OrganizationContext; 

7. Create the following constructor for your class:

 public BaseDataAccessLayer(IOrganizationService organizationService) 
{ 
 OrganizationService = organizationService; 
 OrganizationContext = new OrganisationServiceContext(organizationService); 
} 

8. Move the methods highlighted here from your original plugin to the newly created parent class, while ensuring that the organization service ...

Table of contents

• Title Page
• Copyright
• Credits
• Foreword
• About the Author
• About the Reviewer
• www.PacktPub.com
• Customer Feedback
• Preface
• No Code Extensions
• Client-Side Extensions
• SDK Enterprise Capabilities
• Server-Side Extensions
• External Integration
• Enhancing Your Code
• Security
• DevOps
• Dynamics 365 Extensions
• Architectural Views
• Dynamics 365