Pass Dynamics 365 execution context to Azure Service Bus (OneWay) and read through Console Application (Listener)

In previous post, we understood how to pass the Dynamics 365 execution context to Azure Service Bus Queue and read through a Console App. Lets see how to pass the execution context to be read through a Listener bind to the endpoint. Here we don't use a Queue. (In our previous post we have also shown how to configure ASB from scratch).

1) Create a Service Policy in ASB

This time create a Shared Access Policy for Azure Service Bus in root level.

Once created, we can see all the details once open it. Copy Primary Connection String of the Policy.

2) Register Service End Point

Now Open the Plug-in Registration Tool and go to Register > New Service Endpoint which results a pop-up. Now paste the Primary Connection String we copied in previous step.

Now do below changes in resulting Service Endpoint entry;

a. Select OneWay for the Designation Type
b. Add https: to Namespace Address
c. Give a name to Path.

Now register a step for Lead entity for Create message. Make sure you register this in Asynchronous mode.

Now go to D365 and create a Lead record and check System Jobs, where you will notice an exception since there is no listener for endpoint as below;

3) Implement Listener to Endpoint

Let's implement a listener for the endpoint through a Console Application.

For that below NuGet Packages needed to be installed;
a. Microsoft.Crm.Sdk.CoreAssemblies
b. WindowsAzure.ServiceBus

Also notice that we have used Policy Name and Key (i.e. Primary Key) from the Policy we created.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Microsoft.Xrm.Sdk;
using Microsoft.ServiceBus.Messaging;
using System.Runtime.Remoting.Contexts;
using System.ServiceModel;
using Microsoft.ServiceBus;

namespace AzureServiceBusListener
{
    class Program 
    {
        static void Main(string[] args)
        {
            string asbAccessKeyName = "Sum1ServiceBusPolicy";
            string asbAccessKey = "7WxSLRMvYF0myA3HbLUgfQeqIEb1eKsHgg5mrUwc=";
            string asbEndPoint = "https://sumeservicebus1.servicebus.windows.net";

            var serviceHost = new ServiceHost(typeof(TestRemoteService));
            var transportClient = new TransportClientEndpointBehavior(
                TokenProvider.CreateSharedAccessSignatureTokenProvider(asbAccessKeyName, asbAccessKey));
            serviceHost.AddServiceEndpoint(typeof(IServiceEndpointPlugin),
                new WS2007HttpRelayBinding(), asbEndPoint).EndpointBehaviors.Add(transportClient);
            serviceHost.Open();
            Console.ReadLine();
        }
    }

    public class TestRemoteService : IServiceEndpointPlugin
    {
        public void Execute(RemoteExecutionContext executionContext)
        {
            Console.WriteLine("Entity Name : {0}, Record Id : {1}", 
                executionContext.PrimaryEntityName, executionContext.PrimaryEntityId);
        }
    }
}

Now run this program and start Creating Leads. Now you will notice Listener is picking the context each time a new Lead is Created.

References;
https://blogs.msdn.microsoft.com/swetagu/2016/04/12/crm-azure-service-endpoint-and-listener-deep-dive/
https://nishantrana.me/2017/03/22/configure-dynamics-365-and-azure-service-bus-integration-using-oneway-relay-and-listener/
https://msdn.microsoft.com/en-us/library/gg334377.aspx

Pass Dynamics 365 execution context to Azure Service Bus Queue and Consume through a Console Application

This is the first exercise I performed to see how Dynamics 365 can be integrated with Azure Service Bus.

1) Configure Azure Service Bus and a Queue

Search for Azure Service Bus in Azure and create one. I have given below details. SumeRG1 is my existing Resource Group.

One its ready I would like to create a Queue by selecting it through menu items as below.

Below shows details I gave in in Queue.

Now I create a Shared Policy.

Once save the policy you will be able to see all the policy details including the Primary Connection String, which we need to copy.

2) Pass the context through

Now connect to your Dynamics 365 instance in Plug-in Registration Tool and go to Register > New Service Endpoint which result a dialog box. Now Paste the Primary Connection String we copied in previous step.

Then you will see how Service End Point Details get populated.

Now add a new step to newly registered Service End point entry in Plug-in Registration Tool. In my example I am adding Create Message of Contact.

Now Create a Contact in Dynamics 365 and notice one message has been pushed to d365azurequeue as below;

3) Consume the Queue Item through a Console Application

To consume the Queue Item I am creating a Console Application. Make sure you add below NuGet Packages to your application.

..and below is my code. Please note this Connection String is the same one we used to connect to Plug-in Registration Tool, which we copied from SAS Policy.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Microsoft.ServiceBus.Messaging;
using Microsoft.Xrm.Sdk;
using System.Runtime.Remoting.Contexts;

namespace ReadAzureServiceBus
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Testing Azure Service Bus Queue Records pushed from D365");

            var connectionStr = "EntityPath=d365azurequeue;Endpoint=sb://sumeservicebus1.servicebus.windows.net/;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=FcM+XYZSL7FOVIMXJIdg0Gk1uK3ipU51hUSrC50N4UyCTo=";

            var client = QueueClient.CreateFromConnectionString(connectionStr);

            client.OnMessage(message =>
            {
                var context = message.GetBody<RemoteExecutionContext>();
                Console.WriteLine("Entity Name : {0} and Id : {1} ", context.PrimaryEntityName, context.PrimaryEntityId);
            });
            
            Console.ReadLine();
        }
    }
}

Once execute I get below result as expected;

Interestingly, if you refresh the Queue in Azure Service Bus, we can see Queue Item has been consumed (i.e. removed).

This is actually the fundamental idea of using Azure Service Bus for integration of Dynamics 365 with third party applications. I find this cool ! You know why, not like many other integration techniques we use, here we can see message is being added to the queue and stay in waiting status to be consumed. In fact, this decoupling is significant and nothing get lost in thin air.

References;
https://community.dynamics.com/365/b/xrmandbeyond/archive/2017/11/11/message-queueing-in-dynamics-365-with-azure-service-bus
https://nishantrana.me/2017/03/22/configure-dynamics-365-and-azure-service-bus-integration-through-queue-and-queueclient/

Filtered Lookup in Resco Mobile App

We have talked about Lookup filters for Dynamics 365 web app for many occasions in this blog. Now we will see how to implement this in Resco Mobile app for Field Service. This customisation has to be done through Resco Woodford Solution Customisation application.

Suppose we have below related entities in our scenarios;

What this means is Locations are associated to Accounts. When we set a Location to an Asset we don’t need to see entire list of Locations, but can pick one from the list which are associated to the Account of the Asset. Now this is a typical candidate for a Filtered lookup.

This filtering needs two steps;

1) Create new Lookup view in Location Entity

Create a new View, in fact Clone from Default View. Then Rename the view name accordingly and select Lookup as type.  Check Hide in View Selector since we don’t need to list this as a view in usual browsing.

Now Click Edit filter and add Condition to set Account and click Set Variable which result you with a pop-up to set it. Now select Asset from the Variable Selector and set Account field within it. This is because we are planning to use this to filter by Account Id when we are in Asset Entity.

2) Set newly created Lookup view to Lookup field in Asset

Now go to Asset Entity and Open the form we need to set the filter. Add the Location field and Open the Properties. Then we have to set newly created Lookup as the Initial View by clicking relevant checkbox. Also we have the option to keep the other view or hide it by clicking the check of in the beginning of the row.

Now click Publish All and check the Mobile App after synchronising.

Track Field Technicians locations through Resco Mobile App

We are provided a very strong insight in to Scheduled Jobs’ location and Resource’s suggested path in Dynamics 365 Field Service Schedule Board. In fact, we can optimise the route, prioritise Bookings in terms of geographical location considering and travel time and etc. Anyway, how we going to track what Field Technicians’ real locations are?

Here I am going to explain how to do that.

1) Associate Google Map API Key to Woodford Solution

a. If you don’t have a Google Map API key, sign-up here and retrieve one. Once you register you get $300 worth credits free. It will ask for a credit card number for authenticity, just like in Azure registration, but nothing will be charged, without your consent after fully consumption of free credits.

b. Now go to Settings > Solutions and Open Resco MobileCRM Woodford solution and click Configuration. Then paste the key and save.

c. Now there is a way to check if Key is valid and correctly associated. Browse to Settings > MobileCRM > Mobile Auditing. Then click Mobile Auditing Map link. If a Map is loaded without any issue, everything is in order.

Otherwise you will get below error message.

2) Configure Map for Users

Now go to User Form Customisation and click Web Resource.

Allocate resco_MobileCRM/MapIframe.html web resource as shown below. Also make sure to click “Pass record object-type code and unique identifier as parameters” Then save and publish.

3) Check how its working

Now Browse to User Form of the Field Technician you want to track the location. You will see points within the map in newly added Iframe where User/ Field Technician performed any action with the Resco Mobile App as below.

Schedule Web Job with Azure Scheduler

In this example, I am using a console application since it’s easy to demonstrate. Below is the simple Console Application I am using.

Now publish the Console Application as a Azure Web Job.

Select Run on Demand as the run Mode.

Then select Microsoft Azure App Service as publish target.

Now select Subscription, Resource Group as View and existing App Service in next window.

Now validate the connection before publishing.

Now login to Azure (https://portal.azure.com/) subscription used to publish this app.
Now browse to App Service > Web Jobs where you will see the Web Job just published.

Here we able to Run and check the Logs, which will show the execution steps.

Here we see the text in log, we intended to write in our Console application.

Anyway, our plan is to schedule this execution. For that we need to go to Scheduler as below.

Once we press Create, resulting page requires a lot of details like Subscription, Job collection, Action Settings and Schedule data. One of the import detail is URL.

This is how you need to compile the URL;
Go to Properties of the Web Job and read these important parts and compile the URL as below format.

https://<B>:<C>@<A without "https://" part>

Once scheduler is enabled, you will see its recurring execution as expected.