IoT Hub – REST API – Visual Studio 2017 project template

IoT Hub exposes REST APIs and SDKs to interact with it.

The fact is that production projects sometimes (often) require implementing intermediate layers (logic, security or whatever) between IoT Hub used features and project’s accessible endpoints. This can be done with custom SDKs or in a more service oriented approach, with applicative services (lastly, usually REST oriented).

You will find here a Visual Studio 2017 extension that creates REST APIS (.NET Core 2.1.x) solutions exposing IoT Hub features. Indeed, the template creates a whole solution, ready to use and optimizes effort on creating business value.

Features included in the template are:

  • IoT Hub device management:
    • create and register a device (with default tags)
    • disable a device
    • enable a device
    • delete a device
    • get a given device properties
    • search devices according to given critera
    • list devices
  • Cloud to device communication:
    • call Direct Methods through REST API requests
    • update device twins (tags)
    • update device twin (desired properties)
    • create IoT Hub jobs (ex: device firmware update) and follow up status
    • get IoT Hub’s jobs details

 

All that ready to use.

You only need to set the right IoT Hub connection string (ideally, secured or stored in a KeyVault) in appsettings.json file.

The template relies on works done in a previous VS2017 template, helping to accelerate REST API .NET Core 2.1.x solutions development.

This templates includes features like:

  • Swagger/OpenAPI generation by config
  • API and Swagger versionning
  • .NET Core 2.1.x DI settings (configuration, dependency resolution, IOptions<>, exception management, etc)

 

Next steps

One of the next steps in real world projects should be to secure the REST API, either by adding embedded security management code/settings in the VS solution or using Azure API Management.

 

 

Advertisements
IoT Hub – REST API – Visual Studio 2017 project template

How to measure latency between devices and Azure IoT Hub

In many of my last projects, I wanted to control latency levels among devices and IoT Hub. For many of them, I was just curious and for other, it was a real customer requirement.

How to do it?

What I ended up implementing for a very simple latency control relied on the items below:

  • new message type called “latency” and containing request timestamp
  • new IoT Hub endpoint (Event Hub type) to receive all the routed messages requesting latency control
  • new route based on “latency” message type and sending latency messages to the corresponding endpoint
  • new Azure Function connected to the Event Hub mentioned earlier. This function called an IoT Hub Direct Method. Its payload contained the original request timestamp. That way, the device could math the time spent for the round trip.

 

NOTE: in this case, latency measured device to cloud communication and its corresponding response. Single latency measure (merely device to cloud communication) could be enough in other cases.

If I get some free time in the upcoming days, I will try to package the solution and publish it (at least a kind of PoC).

Hope it helps or gives ideas.

Feel free to complete or comment.

How to measure latency between devices and Azure IoT Hub

How to use VS 2017 REST API Template for .NET Core 2.1.x?

When it comes to building REST APIs we are often confronted to common and repetitive technical issues. That led me to try to industrialize and factorize the creation of REST API solutions.

Visual Studio 2017 REST API Template for .NET Core is the first attempt of building a Visual Studio 2017 project template (solution template actually) for creating a complete .NET Core 2.1.x solution fully usable.

Benefits

  • Industrialization
  • Fast
  • Very simple to use
  • Repeatable structure (easier to handle, understand and maintain)
  • Extendable
  • Allows to concentrate effort on creating value (business value most of the time)

 

How to install it?

Very easy.

Through a web browser

Template
VS 2017 – .NET Core REST API Template

 

Through Visual Studio

  • Open Visual Studio 2017.
  • Go to Tools -> Extensions & Updates.
  • Look for the Extension (for instance, by “.Net Core”).
  • Once found, click the Download button.

 

VisualStudio-SearchExtension
Visual Studio 2017 – Tools and Extensions

 

What does the project template do?

Once the template installed, when we go to File -> New Project, we should see the screen below:

NewProjectAfterTemplateInstallation

Many inputs can be customized:

  • Name
  • Location
  • Solution name

 

After clicking on “Ok”, a Visual Studio solution is created with the structure below:

SolutionStructure_v0.2.1
Template structure

It is what it is; I guess the proposed structure can be discussed, reviewed, completed, etc. I am open to discussions :). The purpose was to propose something usable, simple, fulfilling common REST API projects technical requirements (from the production point of view) and allowing to focus most of our effort on creating business value.

Feel free to change the content, adapt it to your requirements (you should ;)) or to provide feedback in order to evolve the template and share that capitalization.

 

How to use VS 2017 REST API Template for .NET Core 2.1.x?

Azure IoT Hub – Routing

In IoT projects it is quite typical that devices either are from different types or they send messages of different types. No matters the reason, IoT Hub ends up receiving different types of messages.

Before routing features existed, all the messages were treated through a single “pipeline” and eventual routing operations were coded “by hand” over that unique pipeline. Nowadays, things have changed and IoT Hub includes native routing features.

Let us see what it does and how it works.

 

Endpoints

Endpoints can be reached and defined from IoT Hub’s left-side menu (Messaging Section).

RoutesEndPointsQueries
IoT Hub’s Messaging Menu

 

Endpoints management page allows to:

  • create custom endpoints
  • configure custom endpoints
  • delete custom endpoints
  • configure built-in endpoints
    • Default events endpoint
    • Cloud to device feedback endpoint
    • File upload notifications endpoint

 

NOTE: the number of custom EndPoints is limited (as of now, 10 per IoT Hub)

 

Creating a custom endpoint is pretty straightforward. It only requires:

  • an endpoint name
  • choosing its type
    • Event Hub
    • Service Bus Queue
    • Service Bus Topic
    • Azure Storage Container

 

EndpointCreation
IoT Hub – Endpoint creation

 

Routes

Once endpoints are created, it is time create the routes. The process is pretty simple too:

RouteCreation
IoT Hub – Route creation

It requires the settings below:

  • A route name
  • Data Source type:
    • Device Messages
    • Twin Change Events
    • Device Lifecycle Events
  • Endpoint (one of the previously created or a built-in endpoints)
  • Query string the routing is built over

 

Queries are written in a T-SQL-like language and based on:

  • message properties (kind of message metadata properties, settable by IoT SDK when building messages)
  • message content properties (usually, more related to the business core of the project)

 

Ex:  status = 500 and $body.messageType = ‘error’

 

Built-in routes

IoT Hub includes built-in routes that deserve a couple of words:

  • Default route, where devices’ messages go through by default
  • File upload, that can be used by devices to upload “big” messages (ex: any kind of media, collection of messages stored locally, etc).
  • Twin notifications, could be used by IoT Hub every time a twin is updated, in order to monitor or notify changes
  • Device lifecycle, used by IoT Hub to notify device lifecycle oriented messages (ex: device created, deleted, disabled, enabled, etc)

 

Things to keep in mind

If in your project, routing queries need to be based on messages’ content, keep in mind it must be “understandable”. Some device manufacturers or MCUs may have no choice and could send hexadecimal messages (or under any other custom serialization format).

Queries can be based on message properties too.

 

Conclusion

Routing feature is really useful (literally used in all real world projects I have been involved in since the feature was rolled out). It offers the possibility to build separate and customized treatment workflows, depending on message types and project requirements on them.

 

 

Azure IoT Hub – Routing

IoT Hub, Event Hub, IoT Central, IoT Suite, IoT Solution Accelerator….help?!! :)

Many years ago (not so long), IT industry started increasing investments on IoT. Microsoft announced Event Hub, a message concentrator/”hub” with high volume capabilities. We could say it was Microsoft’s first PaaS IoT service in this new IoT era.

Nowadays, many other services (PaaS/SaaS) have completed the IoT family. Let us figure out who they are and what they do.

IoT Hub

Today, the main IoT PaaS service in Azure.

Role:

  • device registry (identity and security)
  • device to cloud communication
  • cloud to device communication
  • IoT solutions entry point at cloud level

 

Event Hub

PaaS Service

Role:

  • Message oriented hub
  • High volume capabilities
  • Parallelization

Note: usually used behind IoT Hub

 

IoT Suite

IoT Suite does not exist anymore. It has been replaced by renamed into “IoT Solution Accelerator”.

 

IoT Solution Accelerator

As its name points out, it is an accelerator for IoT Solutions:

  • instantiates main Azure services for an IoT project
  • configure them to make them ready to use
  • different templates are available
  • builds an operational but “empty” shell as an starting point for building more complete solutions

NOTE: for now, I have never used it in real world projects because of specific requirements “hard” to fulfill with IoT Solution Accelerator templates. This being said, the concept is interesting and deserves to keep it in mind when it comes to designing IoT architectures. In some cases, it could represent a good first step.

 

IoT Central

IoT SaaS solution completely packaged:

  • completely functional and ready to use
  • black box and closed (no customization or integration APIs….for now)

 

NOTE: could be very useful for very fast PoCs or very simple projects. The cost has to be taken into consideration.

The solution is not ready yet for real world IoT projects.

 

IoT Edge

After build cloud-centric solutions (Intelligent Cloud approach), Microsoft decided to “export” intelligence and bring it to the edge (Intelligent Edge), closer to devices. This brings new capabilities and enrich functional scenarios.

IoT Edge is the solution making that possible. It is based on containerization (Docker or Balena, a Moby-based container engine for IoT).

The approach is quite smart and even if it requires devices with minimum hardware requirements, it opens the doors to very rich functional scenarios.

Types of modules that can be deployed on IoT Edge:

  • Azure Functions
  • Machine Learning
  • Stream Analytics
  • Cognitive Services

For more details about how IoT Edge runtime works, follow this link.

IoT Hub, Event Hub, IoT Central, IoT Suite, IoT Solution Accelerator….help?!! :)

How to use Azure Calculator

Need to figure out how much could cost an Azure solution?

Take a look at Azure Calculator.

Products1
Azure Calculator

 

Pay special attention to the Estimates tab, that allows to:

  • save configurations
  • export configurations and costs
  • copy configurations
  • reload configurations

 

Estimates
Azure Calculator – Estimates

 

 

 

 

How to use Azure Calculator

Visual Studio 2017 .Net Core 2.1.x API template

Nowadays, it is quite common to have to develop Web APIs.

Having always put special attention in ALM and DevOps (and easing developers’ work :)), I published a while ago a Visual Studio template for creating Web APIs (ASP.Net MVC).

Since then, .NET Core has been taking more and more importance. So, you will find here a new Visual Studio 2017 template to create APIs over .Net Core 2.1.x.

This first version includes:

  • DI settings (.Net Core 2.1.x way, quite different from earlier versions)
  • AppSettings (.Net Core 2.1.x way)
  • mapping settings (based on Automapper)
  • OpenAPI/Swagger basic configuration (can be disabled by configuration)
  • exception handling basic settings (.Net Core 2.1.x way)

 

The template is built for Visual Studio 2017 and it is available at Visual Studio Market Place.

And that is all :). The template should be ready to use:

DotNetCore2_1_Template
Visual Studio 2017 – .Net Core 2.1.x template

 

 

Visual Studio 2017 .Net Core 2.1.x API template