Welcome to the UK Dynamics 365 Partner Team Blog

Connected Field Service - Part 3

Steve Crisp, Manufacturing UK — Sun, 30 Jul 2017 20:21:26 GMT

Remote Monitoring Deployment

This is part of a 3 series blog, the first part can be found here. In this section we will quickly deploy Remote Monitoring, this solution includes telemetry data and map data to display the performance of devices around the globe. Including whether they are health or have recently created alerts. The alert thresholds can also be set. Go to https://www.azureiotsuite.com/ and deploy a new solution. From the options select remote monitoring, make sure that you deploy to the same subscription in Azure where you deployed the Connect Field Service solution previously. The solution will deploy the following Azure resources:

Azure IoT Hub (1 high-frequency unit)
Azure Stream Analytics (3 streaming units)
Azure DocumentDB (1 S2 instance)
Azure Storage (1 GRS standard, 1 LRS standard, 1 RA-GRS standard)
Azure App Services (2 S1 instances, 2 P1 instances)
Azure Event Hub (1 basic throughput unit)

More information can be found here: https://social.technet.microsoft.com/wiki/contents/articles/32941.iot-suite-under-the-hood-remote-monitoring.aspx

Configure Remote Monitoring to use CFS IoT Hub

This section we take the remote monitoring solution that is deployed in Azure and point it at the Connected Field Service solution. This will allow Remote Monitoring to read the data being sent to the CFS IoT Hub, which in turn means that you can have devices being monitored in Remote Monitoring and the same devices creating alerts in CFS! Before pointing to the CFS IoT Hub, go into the remote monitoring solution and remove all the existing registered devices. Once the IoT Hub is changed it won't be possible to remove these. This process is very simple, in the web app go to the application settings. There will be a number of 'App Settings' that can be changed. To repoint the IoT Hub change the iothub.Hostname & iothub.connectionstring to reference the IoT hub that was configured during the Connected Field Service deployment. It is also possible to add the Bing maps API key here. If Remote Monitoring has been deployed before then by default there will be just be an image of a map until this key is updated. A free key can be got through the Azure subscription by searching for Bing in the resources.

Updating the Stream Analytics to use the CFS IoT Hub

There are 3 Stream Analytics Resources that make up the Remote Monitoring Solutions.

-DeviceInfo
-Rules
-Telemetry

Each Stream is now using the wrong IoT Hub as an input so this needs to be changed for the solution to work. Step through each StreamAnalytic resource and change the input to be the CFS IoT Hub. To do this the StreamAnalytic Job must be stopped, it can then be restarted after the change.

Checking it all works

It should now be possible to add a new device through the Remote Monitoring Dashboard. Within the dashboard the button in the bottom left allows for the adding of simulated or real devices. To test add a simulated device, this should create a device in the IoT Hub. Instead of waiting for the temperature to go over 70 degrees based on the simulator it is possible to force its temperature using the simulator deployed in CFS in the 1st part of this blog. When the first service alert appears in CFS it won't have a device associated with it. This is because Dynamics doesn't have a related device to that device ID, however this is easily resolved. Click into the IoT Alert, this should show the Device ID. Now create a new device, it is critical that the same DeviceID is used. This ensures that rather than a new device being created the current record is associated with the already created device in IoT Hub. To complete this click the register device button on the ribbon. It is also possible to add a customer asset, when doing this don't re-register the device, instead add the previously created device as a connection. Taking these steps will mean that in the future any alerts will automatically show the associated customer, this means that service levels and entitlements can be applied to the case which is created by the device raising an alert.

Enhancing the solution

You now have a remote monitoring solution linked to CFS within Dynamics. This blog series will leave it here, however this setup can be enhanced. For example all of the following are easily within reach:-

Point CFS at the Remote Monitoring device rules. This just involves editing the Azure Stream in CFS. The code exists in the RM solution.
Putting a filter on Stream Analytics so alerts are only raised once. A real world device you can get a lot of alerts each time readings go over the threshold.
Add a predictive algorithm. It is easy to add a web service to Stream Analytics, there are predictive models samples available such as Weather Prediction that use Humidity and Temperature. See here.
Add a Power BI stream output so you can easily create custom visuals.

I hope that you have enjoyed this blog series and it has helped you get a better understanding of using Azure IoT with Dynamics. This capability is quick to get started on and can help companies reduce cost of their service departments.

Connected Field Service - Part 2

Steve Crisp, Manufacturing UK — Tue, 11 Jul 2017 18:10:49 GMT

Connecting a physical device

In the first part of this blog series, which can be found here, we looked at how it is possible to rapidly deploy connected field service for Dynamics 365. In this part we will look at connecting a physical device to that environment to provide real world capabilities and bring the solution to life. There are many options when it comes to connecting physical devices, including various boards such as the Raspberry Pi and Spark Electron, and it is possible to buy sensors for them such as the DHT 11 that will monitor Temperature and Humidity.

Before setting up a physical device we need to have a device registered. This can be done directly through D365. With CFS installed from the previous blog go to the 'IOT Device' record. Create a new device and click register, refresh the page after a minute or so and the registration status should change to 'Registered'. You can use the simulator to test or move straight onto connecting a device.

Once the device is registered the connection settings will be available in Azure, these settings allow the physical device to authenticate and send data. These can be found in the IoT Hub resource that was previously configured (there is a screenshot further on when these details are needed)

Connecting a physical device - Pi

A great starting device is a Raspberry Pi 3 with a SenseHat. The SenseHat has sensors including Temperature and Humidity. https://www.raspberrypi.org/products/raspberry-pi-3-model-b/ https://www.raspberrypi.org/products/sense-hat/ https://www.raspberrypi.org/products/raspberry-pi-touch-display/ (whilst it is possible to create headless apps this screen works great for giving real-time feedback) The Pi is able to run Windows core which will allow the Pi to run UWP programs. This works well for the prototype because there are a number of libraries available and IoT core has features such as auto restarting a App if it closes deployed (follow these instructions to setup a device https://developer.microsoft.com/en-us/windows/iot/getstarted ). Having a display allows for real-time visualization of the data on the device before it appears in D365 or PowerBI (more on that later). The code for this has been shared on GitHub so that you can deploy your own device. If you don't want to use a screen then the 'Windows IoT Remote Client' can be used to display what is happening on the device from a windows machine that can see the device. Or a quick internet search and you should be able to find another sample that could run headless. The source code for the physical device can be found on GitHub here: https://github.com/SteveCrisp/CFS-PiSample Using Visual Studio you can review the code and deploy the UWP app to the device. When the app runs you will be prompted for the setting of your device. As there is no onscreen keyboard with IoT Core, a usb keyboard will be required. The parameters will persist so that when the device restarts it can reconnect. However with the source code available you can also hardcode these values if you don't want to change the device. The device IoT Hub details can be found in Azure, a screenshot below shows the device explorer which holds details of each device. The IoT Hub URI can be found on the 'Overview' section within the IoT Hub resource (this is the default section that loads when you first select the IoT Hub in Azure).

With the device details and IoT Hub details entered you can go ahead and test your device, click 'OK' to save the details. Then move the central toggle to 'ON'. If the device is working you should get an IP address in the bottom right and the dials should start registering values. Spiking the temperature should produce alerts in D365.

The source code is commented however here are some highlights to help explain the essentials


public async void InitializeIoTDevice()
{
try
{
deviceClient = DeviceClient.Create(iotHubUri, new DeviceAuthenticationWithRegistrySymmetricKey(deviceName, deviceKey));
}
catch (Exception ex)
{
//Most likely there is no internet.
MessageDialog dialog = new MessageDialog("There was an error setting up the device client with IoT Hub", "Information");
await dialog.ShowAsync();
}
}

The Initialize device function allows the device to register with IoT Hub. Using the secret and correct URI the communication will be encrypted between the device and IoT Hub. If the connection cannot be made then an error message will be displayed this will most likely be because of an error with the connection parameters. For this to work the correct Microsoft.Azure.Client.Library needs to be installed from the NuGet gallery packages. There are a number of great blogs on this including https://blogs.windows.com/buildingapps/2015/12/09/windows-iot-core-and-azure-iot-hub-putting-the-i-in-iot/#yFsIpJEtuHSXkuXv.97

Wrap up

There are many other boards out there that can sense data and pass the information to Azure. This blog has shown how easily a physical device can be connected to a business application in Dynamics. For a manufacturer this opens up possibilities of not just getting information off devices but creating actions. Automating processes around service to shorten the potential down-time of a customer. This can be extended to incorporate preventative capabilities like predictive maintenance that could bring a customers unplanned downtime even lower. In the final part of this blog, which can be found here, we will look at taking an IoT Suite remote monitoring solution and combining it. This will rapidly add some more features, such as a webapp that could be shared with visualisations, device rules, and device management capabilities.

Connected Field Service - Part 1

Steve Crisp, Manufacturing UK — Fri, 12 May 2017 08:22:06 GMT

IoT is a hot topic at the moment, the number of connected devices is set to explode to 30 billion devices by 2020. Recently there have been a number of requests, especially from manufacturing prospects to help with IoT projects. Many manufacturers have been using IoT in a format for years through systems like SCADA, using the cloud we can now extract expand on this and extract more value from connected devices. The cloud has really enabled capturing of vaster quantities of data and running advanced workloads like machine learning at speed. Furthermore the cloud enables companies to develop these workloads in a cost effective manner, testing machine learning experiments, tweaking and re-running. With the ability to discard an experiment (or service) without an ongoing cost. One key area of value is for companies to drive down the cost of their operations, this falls into one of the main pillars of digital transformation. Microsoft is well positioned to help customers like Manufacturers reduce operating costs, a key solution that can enable this is Connected Field Service. Connected Field Service enables customers to monitor devices around the world for changes in status. These statuses can cause thresholds to fire actions which in turn can automatically create a alert within the D365 service and/or another(eg a logic app). At this point it is easy to start applying business impact to that alert, the device that triggered it is known as is the function of the device and who (which customer) it is working for. It is possible with this information to create new premium services that can increase the revenue of a field service operation. Furthermore with early warning to better optimise the service engineers so they can make more visits, reducing the cost which additionally will increase profitability of the field service operations. Over a series of three technical blogs we will step through how to configure 'Connected Field Service' to run with remote monitoring and use a physical device to create alerts. For the first blog we will configure the connected field service solution out of the box and use the simulated device to create alerts.

Requirements

D365 environment with a Plan 1 license (it is possible to use a trial but it will expire after 30 days)
Field Service App in D365
Azure subscription (it is possible to use a trial but it will expire after 30 days)

This configuration can be done in a trial environment however the environment will expire after 30 days. To get an Azure trial environment a credit card is required for verification, by default no money is taken from the credit card. If you have access to an Azure subscription (e.g. with MSDN or other test areas) the overall usage for this solution is about $50 per month, although make sure to downgrade the IoT Hub to S1. S1 can handle multiple devices and should have plenty of messages to survive each day's use.

Connected Field Service [CFS]

CFS can be deployed via AppSource, the installation is simple and going the process deploys both the entities needed in D365 and the Azure elements. The process is really simple to go through and can be deployed in under an hour.

The url below guides admin through the steps to get CFS deployed (the PowerBI section is optional and it is possible to create PowerBI stream easily manually after the install).

https://www.microsoft.com/en-us/dynamics/crm-customer-center/use-connected-field-service-to-remotely-monitor-and-service-customer-equipment-field-service.aspx

Stepping through the guide will deploy a new app within D365. Within the D365 navigation bar there will be an App for Internet of Things. This along with related entities is deployed by CFS. This provides everything that is required to get started with CFS.

The entities deployed are:

Registered Devices - register a device to a customer or customer asset
Device Categories - for grouping, such as Thermostat
Registration History - whether a device has been registered with IoT Hub
Commands - messages that can be sent to a device, such as restart
IoT Alerts - when a threshold limit is exceeded, such as temperature > x
Dashboard - dedicated dashboard that shows Iot Alerts over time and by customer

It is simple to set up a simulated device from here to verify that the solution is working properly. In D365 click registered devices then click 'New'. Complete the device details, making sure that you put a descriptive DeviceID in. Then hit save, this should make a 'Register Device' button appear on the top ribbon. Hitting this will register a device.

There is a simulator deployed with CFS that can be used to quickly test whether a device is registered and sending data into IoT Hub properly. The simulator can also be used to spike Humidity or Temperature to see if an alert is raised in D365 (by default only spiking Temperature will raise an alert).

There is now a device that can be run in the simulator. The simulator runs within Azure and was created as part of the installation process.

A quick guide on using the simulator, it can be launched through the Azure portal (it is easier to go through the portal because the URL has a Unique ID appended to it which makes it hard to find the first time). The simulator is a app service called Simulator. On launch it will require connection to be setup. which includes the 'Hostname', 'Policy Name' & 'Key'. These can all be found in the Azure portal within the IoTHub in the resource group, there is an image below showing the fields. More information on the resources can be found below however to get the simulator working.

The can be found on the overview tab of the IoTHub, its important to note that you only require the hostname. For example .azure-devices.net. The can just be left as iothubowner, this references the 'shared access policy' that will be used to connect. This can be found in the IoTHub under settings, shared access policy. It is important to grab the from within the shared access policy as highlighted in the diagram.

Once this has been configured the drop-down box for 'Device ID' on the simulator will be populate. Selecting a device will push values out and the temperature & humidity dials can be clicked on to change the out going values. NOTE: when there can be differences between browsers, I found that I could click the dials in Edge & Chrome however in Firefox I was unable to, so please try other browsers if you experience the simulator being unresponsive.

Azure Connected Field Service Resource Group

A quick look at the components that have been deployed within Azure show the following components:

3x App Service
2x Logic Apps
1x Stream Analytics
1x Storage Account (includes 1 Blob)
2x API Connection
1x Service Bus
1x Web App
2x App Service
1x IoT Hub
1x Service Plan

More details on the underlying Azure architecture and resources can be found here: https://msdn.microsoft.com/en-us/library/mt744253.aspx

Summary

In this blog we have seen how quickly Connected Field Service can be deployed. Which provides a data model in D365 for monitoring and attaching devices to customer records. This works with standard Field Service capabilities which means core propositions such as SLA's, entitlements, schedule optimisation and customer self-service are all easily available as value additions to D365 customers.

Next time we will look at how to take CFS and connect it to a real physical device so that a Proof of Concept can quickly be run demonstrating data from real sensors triggering a field service response.

The second part can be found here.

Reflecting upon Dynamics 365 for Operations Technical Conference - March 2017

Kevin J Horlock — Wed, 29 Mar 2017 13:41:27 GMT

Two weeks ago I had the good fortune to join our partner community at the annual Technical Conference held in Seattle, which this year was focused solely on Dynamics 365 for Operations. As an event, it catered for 1500+ professionals with over 110 sessions being run over 3 days, with an additional day focused purely on the retail capability of Operations. In Sri’s Srinivasan blog and his keynote he highlighted that we’ve had Operations available in its current form for just over a year, and during that time the momentum we have witnessed I believe is truly impressive for a new cloud based platform and made this the most timely technical conference to continue the focus and innovation. The evolution of the solution from AX2012R3 into Operations not only carries forward the key components of the business logic but is deployed through the proven engine of ‘Lifecycle services’ which works as both a collaborative environment for our Partners, Microsoft and the customer, but also manages the actual production environments. When we then build upon the new modern UI, aspects as integration platform, IOT, PowerBI etc we have a truly powerful ERP platform that our customers that start to derive real value from.

To leverage this wider technology, and truly start to bring the value to the fore for customers by our partner community this is where the Technical conference comes into its own. The sessions are all being delivered by Microsoft’s subject matter experts and have both intermediate and advanced sessions to suite the caliber of individuals in attendance. What I observed from the sessions and the keynotes is how far Operations has come in a year. The momentum of new implementations going live every month is a huge testament to the solution, our Partners and the customers realizing what Dynamics 365 for Operations can bring. It is often easy to lose sight of the diversity and scale of our customers’ businesses. In my own role, I often get asked questions such as ‘how many legal entities can be used in tandem’, ‘what is the maximum volume of transactions’ or integrations we can apply. It was hugely refreshing to hear directly from a customer in person at the conference their own experiences of their deployment where they have deployed across over 400 service sites, for 5000 employees from a single Dynamics 365 instance globally. A positive testament to the scalability of the Microsoft Azure platform and Dynamics 365 for Operations. It was also great to be in an event where we could articulate the full value of digital transformation and empowerment of choice for our customers. This is certainly pertinent where for Operations we will now be providing three deployment scenarios that enable customers to apply the right scenario for their own business environment, utilize the cloud and its complementary technologies and drive innovation to recognizable value. Operations is now a key component of the wider Dynamics 365, and the technical conference had some good content that focused on the Common data services and model (CDS and CDM respectively) that will enable our customers to fully apply their business processes across components such as Sales, field Service and Operations – and utilizing complementary tools such as PowerApps and Flow. As the CDS and CDM evolve and mature, they will underpin Dynamics 365 for all organisation’s enabling the faster creation of business applications without the concern and worry around data duplication and potentially conflicting entities. The first iteration of CDS will be available in our spring wave release, which will start to really add value to Dynamics 365 in my view. The conference also explored other aspects for our Partners. For instance, there was some good sessions on the tools for migrating customers from AX2009 to Operations. This was great to see in action and provide partners confidence in how to position what can be migrated from AX2009. The sessions for PowerBI and reporting were superb also, leveraging the tools and techniques we have available today, but also highlighting where we continue to innovate. I felt also that the conference was a superb opportunity to help partners start to understand the role that Appsource is looking to fulfill for our customers and their own practices. It is our destination for all business users to discover, trial and acquire line-of-business SaaS Apps. From a partner’s perspective, reusable IP that can be applied as an App, or ISV’s who position their complementary solutions on Appsource all now have a global reach to our combined customers. So, from an all-up perspective, the Technical conference is a fantastic forum for our partners to combine networking, re-establish relationships, build new relationships, understand the vast array of innovation that has taken place around Dynamics 365 for Operations and to get to grip with some of the underlying details through the hands on labs and breakout sessions to help all our customers on their journey of Digital Transformation and derive a real value from Dynamics 365 for Operations.

Hello world!

Varsha G — Thu, 01 Dec 2016 15:59:30 GMT

Welcome to Technet. This is your first post. Edit or delete it, then start blogging!