Sunday, November 27, 2016

Enhancements to Client side Notifications in Dynamics 365

Microsoft introduced client side notifications in CRM2013. Dynamics 365 has introduced enhancements to this functionality.
A new method addNotification has been added to to the client side API. This method can:
  1. Display a error or recommendation notification. In the earlier version the only option available was error notifications.
  2. It also allows you to specify and execute actions based on the notification. The new method not only display the notification, it also display 2 buttons:
    • “Apply” to execute the action
    • “Dismiss” to close the notification

Code

The following sample code will display recommendation notification if there are numbers in the “name” of the account. If the user clicks on “Apply” button, it will remove the numbers from the name and clear the notification. If the user clicks on “Dismiss” button, the notification will be closed.
 function addNotification() {  
   //get the name control  
   var myControl = Xrm.Page.getControl('name');  
   //get the name attribute  
   var accountName = Xrm.Page.data.entity.attributes.get('name');  
   //get the value name attribute  
   var accountNameValue = accountName.getValue();  
   //if the account name is null then return  
   if (accountName.getValue() == null) {  
     return;  
   }  
   //regular expression to find numbers  
   var r = /\d+/;  
   var s = accountNameValue.match(r);  
   //if match the display the message  
   if (s != null) {  
     var actionCollection = {  
       message: 'Remove the numbers from the name?',  
       actions: null  
     };  
     actionCollection.actions = [function () {  
       //remove the numbers  
       accountName.setValue(accountNameValue.replace(/[0-9]/g, ''));  
       myControl.clearNotification('my_unique_id');  
     }];  
     myControl.addNotification({  
       messages: ['Number/s in the account name'],  
       notificationLevel: 'RECOMMENDATION',  
       uniqueId: 'my_unique_id',  
       actions: [actionCollection]  
     });  
   }  
 }  

Results

2016-11-25_22-36-28

When the user clicks “Apply”, the system removes the number 7 from the name.
2016-11-25_22-36-56

This functionality will be very useful in number of scenarios, for e.g. validating a field and recommending a value, moving the focus to specific tab or field, validating the field value on the parent entity, and opening the parent form to update the fields etc..

Wednesday, November 16, 2016

Interesting integration scenarios for Dynamics 365

The release of Dynamics 365, along with the general availability of Microsoft Flow, Power Apps with CDM(Common Data Model), and the vast range of Azure services have opened up a whole new world of integrated solutions.

I will go through the following 3 scenarios to show case the integration possibilities for Dynamics 365. This blog will only discuss the architecture of the solution, not the actual implementation. The aim of this blog is highlight the solution possibilities using Dynamics 365 and Azure cloud.

Integration of Dynamic 365 with Power apps

Technologies used

  • Dynamics CRM 365
  • Microsoft Flow
  • Common Data Model (Part of Power Apps)
  • Power Apps
  • PowerBI

Solution Overview

The following depicts the solution architecture of Dynamics 365 and PowerApps.
2016-11-17_11-15-32
Steps
  1. A record is created/updated in Dynamics 365 which triggers Microsoft Flow workflows to create/Update the record in CDM.
  2. The PowerApps’s mobile app connected to CDM presents the data to end users.
  3. The end users read,create or update the data on the mobile app.
  4. The changes are saved in CDM that triggers the Microsoft Flow workflows to create/update the data in Dynamics 365.
The data in CDM can be used by PoweBI for analytics. You can also add the data into CDM from different sources to get the consolidated view of the data.

Integration of Dynamics 365 with Microsoft Bot framework

Technologies used

  • Dynamics CRM 365
  • Microsoft Flow
  • SharePoint Online
  • Azure Storage
  • Azure SQL database
  • Azure Search
  • Cognitive Services
  • Microsoft Bot Framework
  • Skype.

Solution Overview

I am very impressed with this solution. This scenarios depicts the business process of an insurance company where users have applied for the policy online. The business process workflow creates profiles in Dynamics 365 and stores the customer application in SharePoint Online.

A Microsoft Flow workflow will push structured data into the Azure SQL Database and the unstructured data into Azure Blobs.

Azure Search crawls the data at regular intervals and keeps it current for querying.

End users interact with the Bot application using Skype. The Bot application processes the user requests without any human interaction using cognitive services.

The whole solution is taken from the following blog:
https://msdn.microsoft.com/magazine/mt788623. Please check the blog for solution details.

The following depicts the architecture of the solution. The diagram is taken from the same blog.
Print

Integration of Dynamics 365 with Azure Search (Relevance Search)

Technologies used

  • Dynamics CRM 365
  • Event Hub
  • Azure Search

Solution Overview

This solution is a preview feature available in Dynamics 365 named “Relevance Search”. Relevance search delivers fast and comprehensive search results in a single list sorted by relevance. It is designed to boost Dynamics 365.

All this information is available at TechNet.
https://technet.microsoft.com/en-us/library/mt723654.aspx#BKMK_Architecture

The following diagram depicts the solution architecture of the relevance search. The diagram is taken from the Microsoft TechNet site
Relevance Search

Thursday, November 10, 2016

Duplication Detection Bugs in Dynamics 365

Duplicate Detection functionality has a bug in Dynamics 365. If you run a duplicate detection job or try to create a duplicate record, the system will display an empty duplicate detection dialog as shown in the screen shot below.

2016-11-11_15-00-25

The Updated Record and Potential Duplicate Records grids do not show any records.

Also if you are updating records in the editable grid the system does not trigger the duplicate detection rules. The system will not display any duplicate detection dialog.

Monday, June 27, 2016

CRM and Azure Service Bus Integration Part 3

This is the third part of the series. Please check the last blog first, if you haven’t already.In this blog we go through a step by step tutorial to setup a CRM-Azure integration using service bus queue via SAS(Share Access Signature).

Prerequisite

  • A CRM Online instance
  • Microsoft Azure account
  • Microsoft Azure SDK
  • Visual Studio 2013/2015
  • CRM2016 SDK V8.1 or later ( We will be using the plugin registration tool and sample code from the SDK 8.1 as the SAS featured is added to CRM2016 Update 1)

Setting up a Service Bus Namespace and Queue

For this post we will using the same Service Bus namespace we have created in the last post http://mscrmshop.blogspot.com.au/2016/06/crm-and-azure-service-bus-integration_20.html. We will add a new queue to the existing Service Bus namespace.
  1. Login to Azure Portal.
  2. Select the Service Bus namespace. Click the “Queues” tab and select “Create A New Queue”

    2016-06-22_14-28-05
  3. Enter the values as shown in the following screenshot and click “Create A New Queue”
    2016-06-22_14-30-18
  4. A new queue will be created as shown in the screenshot.
    2016-06-22_14-30-58
  5. Double click on the queue name and select “Configure”. Change the general settings as required. I am using the default settings. Create a new policy to mange the access to the queue.
    2016-06-27_13-40-12

    2016-06-27_13-44-54
  6. Click on “DASHBOARD” and select “View Connection String” as shown in the screenshot.
    2016-06-27_13-51-04
  7. It will display the "access connection information" as shown in the following screenshot. Copy the connection string. It will be used in the next step.

    2016-06-27_13-53-43

Setting up the CRM Service Endpoint

Here are the steps
  1. Start the plugin registration tool. It is available in the \SDK\Tools location of the SDK. I am using SDK v8.1
  2. Click on Register>>Register New Service Endpoint
    2016-06-28_10-45-05 
  3. It will prompt for the connection string. Paste the connection string for the queue here and click “Next”
    2016-06-27_13-59-12
  4. The registration tool will display the following page. It will prefill most of the values. I have updated the message format to JSON for this post. Click “Save” to save the service endpoint.
    2016-06-27_14-08-15
  5. Select the service endpoint and select "Register New Step", as shown in the screenshot.
    2016-06-28_10-48-23
  6. For this blog post I am using create message on account entity. You can chooses the other messages and entities as required. Click “Register New Step” to complete the registration.
    2016-06-22_14-37-09

Test the Integration

Queue integration does not require an active listener. So just create a new account from the front end. It should post a message to the queue. You can check status of the integration in the CRM system jobs. view.
Also, you can login to azure. Navigate to the queue and check the queue length. This column displays the number messages received by the queue.
2016-06-22_14-44-17

Reading from the queue

Microsoft has provided the Azure sample. For this post, I am using the Azure sample code that comes with the CRM SDK. Here are the steps
  1. Open the “PersistentQueueListener” project from the location  \SDK\SampleCode\CS\Azure\PersistentQueueListener.
  2. Resolve the missing reference as done in the last blog post (http://mscrmshop.blogspot.com.au/2016/06/crm-and-azure-service-bus-integration_20.html)
  3. Run the code. Provide the values for service namespace, issuer name and issuer secret.The code will read the message from the queue and display its contents.
    Note: The CRM sample code is using the ACS issuer name and issuer secret to generate SAS token. So please provide the ACS values as explained in the last blog.
    2016-06-22_14-59-06

Monday, June 20, 2016

CRM and Azure Service Bus Integration Part 2

This is the second part of the series. We have discussed the contract types, security and a general overview of CRM–Azure Service Bus integration in the previous blog. Please read part 1 for the context.
In this blog we go through a step by step tutorial to setup a CRM-Azure Service Bus one way listener contract using ACS.

Prerequisite

  • A CRM Online instance
  • Microsoft Azure account
  • Microsoft Azure SDK
  • Visual Studio 2013/2015
  • CRM2016 SDK V8.0.1 or less ( We will be using the plugin registration tool and sample code from the SDK. The plugin registration tool does not have ACS options from SDK v8.1 onwards)
Here are the steps to create the integration.

Setting up a Service Bus Namespace

The first thing you need for the integration is a Service Bus namespace. If you already have an ACS namespace, you can skip this step.
In the past you could login to the Azure portal and create an ACS namespace. But now, Azure portal does not allow the creation of ACS namespaces from the portal. It only creates a SAS namespace by default. We need to use PowerShell to create an ACS namespace.
  1. Open “Windows PowerShell ISE”
  2. Type Add-AzureAccount. It will open the login dialog. Enter the username and password for your Azure account and press login.If everything goes smoothly, the PowerShell output will look like the following screenshot.

    2016-06-17_16-38-46
  3. Type the following command below to create a Service Bus namespace. Replace ‘MSCRMShopBus’ with the namespace you want and press enter

     New-AzureSBNamespace -Name "MSCRMShopBus" -Location "Australia East" -CreateACSNamespace $true  -NamespaceType Messaging. Replace the parameters values as required. 
  4. The output screen will look like the following screenshot. It will create a namespaces for both ACS and SAS.

    2016-06-17_16-44-52
  5. This step is optional. Login to your Azure account and check the connection information of the Service Bus namespace. It will look like the following screen.

    2016-06-20_09-28-49

    2016-06-20_11-35-17

Get the Certificate file and Issuer name for CRM

For CRM Online
To get the security certificate and the issuer name for CRM go to Settings>>Customizations>>Developer Resources. Download the certificate file and also notice the issuer name of the certificate.

2016-06-14_23-05-37
For CRM On Premise
For CRM on premise, follow the following article for step by step instructions.
https://msdn.microsoft.com/en-us/library/gg328249.aspx

Setting up the CRM Service Endpoint

Here are the steps
  1. Start the plugin registration tool. It is available in the \SDK\Tools location of the SDK. I am using SDK v8.0.1.
  2. Click on Register>>Register New Service Endpoint
    2016-06-20_10-29-12
  3. It will open the the following page. Enter the Values as required and press “ Save & Configure ACS”.
    2016-06-20_10-31-46
    Solution Name is the Service Bus namespace we created in the beginning of this blog.

    Path is the path of your listener project. For example, when you run the listener project for a one-way listener for this blog, the service endpoint URL will look like https://mscrmshopbus.servicebus.windows.net/RemoteService
. The red part of the URL represents the path.

Contract is the type of contract we are using for the service endpoint. For the difference types of contracts check the last blog.
  • The registration tool will display the following screen. Enter the information below and press “Configure ACS”. Management Key is the default key when you create a Service Bus namespace. The certificate file and issuer name comes from the “Get the Certificate file and Issuer name for CRM” section of the blog.
    2016-06-20_10-55-54
  • Press “Yes” on the following screen.
    2016-06-15_22-39-57
  • It will create the management service, rulegroup and sample rules for the service endpoint. Press “Close”.
    2016-06-20_11-04-02
  • Press “Save & Verify Authentication”.It will test the authentication and save the configuration of the service endpoint. Press Close to close the screen.

    2016-06-20_11-08-40
  • Press “Save” to close the service endpoint registration screen.
  • Add a new step to the service endpoint as shown in the screenshot below. It is exactly the same as registering the step for a plugin assembly.

    2016-06-20_11-11-56
  • For this blog, I am creating a step for on creation of a new account. Choose the step values as required or copy the values as shown in the screenshot.
    2016-06-20_11-15-15

    Setting up a listener application

    1. For this blog, I am using the Azure sample code that comes with the CRM SDK. Open the “OnewayListener” project from the location  \SDK\SampleCode\CS\Azure\OneWayListener.
    2. Resolve the missing references. The 2 highlighted DLLs are available in the Azure SDK.

      2016-06-20_11-25-39
    3. Run the sample code. It will prompt for the following information.

      2016-06-20_11-29-27
      Service Namespace is the Service Bus namespace.
      Issuer name is the “Default Issuer”  on the Service Bus connection information as shown in the step 5 of “Setting up a service bus namespace”. It is not the issuer name in CRM Online.
      Issuer Secret is the “Default Key” on the Service Bus connection information.
    4. If everything is working properly it will display the service address as shown in the screenshot of step 3.

    Testing the integration

    1. The listener application should be up and running.
    2. Login to CRM and create a new account. If everything is working properly, it will display the data context in the listener application.
      2016-06-20_13-41-25
    3. To check the status of the jobs you can go to the “System Jobs” view.
      2016-06-20_13-44-56
    4. If the listener application is not available, the status of the job will change to “Waiting for Retry”. It will keep trying to post the message and ultimately change to “failed” if it is not successful after X number of tries. The screenshot below display the details of the job with the status “waiting for retry”.

      2016-06-20_13-53-14
  • CRM and Azure Service Bus Integration Part 1

    I am writing a series of blog posts to look at different ways to integrate CRM and Service Bus. Most of the contents/code I will cover in this series is available on the MSDN site and in the CRM SDK. There is a lot of information on the internet regarding CRM and Service Bus integration but it is scattered everywhere. I am trying to create a beginners guide for the integration.

    Prerequisite

    You have to have knowledge of CRM Plugins and Workflow Assemblies to understand integration discussed in this blog. The blog will refer to IpluginExecutionContext, which will be posted to the Service Bus as a part of the integration. In short, the IpluginExecutionContext defines the contextual information passed to a plugin at runtime. It contains the information about the runtime environment that the plug-in is executing in, information related to the execution pipeline, and entity business information.

    Common Integration Scenario

    The most common scenario for this integration is to post the CRM data to Service Bus, to be used by the line of business (LOB) applications. The integration uses the data context available in Plugins and custom workflow assemblies, that will be posted to the Service Bus and Microsoft Azure Service Bus “CRM aware” solutions can listen and read the data from Service Bus and integrate with the other LOB applications.

    How does it work

    Dynamics CRM provides the functionality to create the service end points that connect CRM and Azure Service Bus. These service endpoints are the contracts between CRM and Service Bus that defines the handling and security of the messages. Registering a service endpoint in CRM is exactly like registering a new plugin assembly. Once the service endpoints are registered, you have to register the plugin ‘step’/steps in the event execution pipeline.
    Once these steps are initiated (when a record is created or updated etc.) by the user, workflow or custom application, the service endpoint notification service notifies the Asynchronous service to post the data context to Service Bus, based on your registered step. Each post is performed by the system job of the Asynchronous service and the status of each job can be checked using the System Jobs view in CRM. If the listener or endpoint is not available then the message won’t be posted to the bus. The Asynchronous bus will keep trying to post these messages to Service Bus
    The following diagram from Microsoft describes the physical elements of the integration

    The sequence of events are as follows:
    1. A listener application is registered on a Microsoft Azure Service Bus solution endpoint and begins actively listening for the Microsoft Dynamics CRM remote execution context on Service Bus.
    2. A user performs some operation in Microsoft Dynamics CRM that triggers the execution of the registered OOB plug-in or a custom Azure-aware plug-in. The plug-in initiates a post, through an asynchronous service system job of the current request data context to  Service Bus.
    3. The claims posted by Microsoft Dynamics CRM are authenticated. Service Bus then relays the remote execution context to the listener. The listener processes the context information and performs some business-related tasks with that information. Service Bus notifies the asynchronous service of a successful post and sets the related system job to a completed status.

    Contract Types

    The service endpoints support the following types of contracts. Most of the definitions in this section come from Microsoft’s documentation.
    • Queue
      A queue contract provides a message queue in the cloud. With a queue contract, a listener doesn’t have to be actively listening for messages on the endpoint. For queues, there is a destructive read and a non-destructive read. A destructive read reads an available message from the queue and the message is removed. A non-destructive read doesn’t remove a message from the queue. It does not require an active listener.
    • One way
      Requires an active listener on the endpoint, otherwise the post to Service Bus fails.
    • Two way
      Similar to a one way listener except it can return a string to the plugin or workflow assembly.
    • REST
      Similar to two way listener but on REST endpoints.
    • Topic
      Similar to queue except one or more listener can subscribe to receive a message
    • Event Hub
      This contract applies to Azure’s Event Hub Solution

     

    Security

    Service Bus uses Shared Access Signature (SAS)  or Microsoft Azure Active Directory Control Service (ACS) for authentication and authorization.
    The support for SAS authorisation is added in CRM Online 2016 Update 1 and CRM 2016 Service Pack 1 (on-premises), Before that, CRM only supported ACS for authentication and authorisation. For further information please check the following link
    https://azure.microsoft.com/en-us/documentation/articles/service-bus-authentication-and-authorization/
    It looks like SAS is the preferred method to work with Service Bus.
    Use the SDK Plugin registration tool to configure Microsoft Azure Service Bus issuer, scope, and rules, which allow a listener application to read the Microsoft Dynamics CRM messages posted to the Microsoft Azure Service Bus.
    For ACS configuration use the registration tool from SDK v8.1, and for SAS configuration SDK v8.1 or later.
    For a CRM Service bus integration walkthrough for one way service contract, check my next blog CRM and Azure Service Bus Integration Part 2.

    Note: I am no expert on CRM and Service Bus integration. I am learning myself. Please feel free to correct me if I am writing anything wrong.

    Monday, June 6, 2016

    Auditing Security Roles in CRM

    If you are a CRM professional, you would know about the auditing feature of CRM. There are hundreds of blogs that tell you how to enable/disable auditing in CRM. In general, we don’t think about auditing the security roles. How many times have you heard from the customer that they had access to feature x yesterday, but they can’t do it now? You have no clue if someone has updated the security role or removed access to a specific role.
    Auditing of security roles can provide the answers to all those questions. You can enable the the auditing of the security roles entity by selecting the audit checkbox as shown in the following screenshot.

    2016-06-07_15-32-36
    You can also enable the auditing for the Field Security Profile and Field Permission entities.
    Now auditing is enabled and you can tell when a new security role is created. If a permission is added or updated in the security role, It will tell you when you assign this security role or remove the security role from the the user or the team record. The following screenshot displays the some of the events associated with security role auditing.
    2016-06-07_15-39-00
    In the screenshot above, we can see:
    • A ”Create” event when a new security role is created.
    • A ”Add Privileges to Role” event when new privileges are added to the security role.
    • A ”Replace Privileges to Role” event when the privileges are updated to the security role.
    • A ”Associate Entities” event when the security role is assigned to a user/team.
    • A ”Disassociate Entities” event when the security role is removed from a user/team.
    This is very valuable information for the system administrator.