Get Started with the New Database Migration Guides to Migrate Your Databases to Azure | Data Exposed

by Contributed | Apr 6, 2021 | Technology

This article is contributed. See the original author and article here.

Database migrations often involve multiple phases, steps, and tools based on various scenarios and workload requirements. To help you migrate your databases to Azure, we have published a set of new Azure Database Migration Guides and a Hub page that provides scenario-based migration content and “How To” guides depending on your source database and target database platforms. In this episode with Mohamed Kabiruddin, he will walk you through the new migration hub page to easily navigate to the content you need based on your scenario, how to use the relevant database migration guides, and how to provide feedback to Microsoft for any specific content.

Watch on Data Exposed

New Migration Hub page
Azure Migration Center

View/share our latest episodes on Channel 9 and YouTube!

Monitoring Air Quality with Azure Sphere and Sysinno iAeris

by Contributed | Apr 6, 2021 | Technology

This article is contributed. See the original author and article here.

Data is king, of course.

IoT technologies have sprung up to collect data from anything you can imagine, from the status of the fan in a building’s air conditioning unit to the noise level of the lathe on a factory floor. Businesses have sprung up turning that data into insights, and those insights into actions that drive value. For example, monitoring the sensors in the buildings on the Microsoft Puget Sound campus, and in the equipment attached to those buildings, has helped Microsoft reduce electrical consumption by over 20 percent. Generally speaking, securely connecting sensors to a cloud-based system with analytics and dashboards is a recipe for improving operations and the environment.

There are two primary ways sensors can connect to the cloud-based system. The most common way is for some separate application to query the sensor for the data, either directly from the cloud or using a on-premises gateway to query the sensor and push the data to the cloud. The other way is for a sensor with more compute power to create a direct connection to the cloud and push the data. Which of these methods is used depends upon the capabilities of the sensor, and the enterprise architecture into which the data is to be pumped. Two concerns that are top of mind with either of these methods are the cost-performance and the security of the data.

Consider the common scenario of monitoring the quality of the air inside or outside of buildings. It is important for understanding the environment and for enabling building owners to provide a healthier place for people to live and work. Sensors are available on the market which measure the levels of harmful chemicals and particles in the air, and the task for the enterprise is to select a sensor and how to get those readings into a centralized system or dashboard that allows the enterprise to take whatever actions are appropriate based upon the levels detected.

Most of the existing air quality sensors are standalone devices that can only respond to queries. The disadvantage of this method in the context of a large enterprise monitoring environment is that it requires a separate application (a gateway) to issue those queries and forward the data.  This introduces additional cost and management effort, as well as potentially increasing security risks if the gateway needs to be accessed remotely (for example over RDP). A company by the name of Sysinno has an alternative to this, with an air quality sensor that can directly and securely connect to the cloud without the need of a local gateway using an onboard Azure Sphere chip from Microsoft. The onboard Azure Sphere thus reduces operating cost and complexity, and it does so
in a highly secure manner.

We’ve written a whitepaper to show how to build an end-to-end solution using the Sysinno iAeris air quality sensor and a number of Azure IoT elements. In addition to showing how to configure the Sysinno detector to send data to Azure IoT Hub, the paper shows how to write an Azure function to send the data to SQL Server, and how to create Power BI and Time Series Insights (TSI) dashboards to display real-time and historical data. At this point, the air quality data could be consumed by any enterprise monitoring system, and furthermore be accessed by a tool such as Dynamics 365 Field Service for generating maintenance work orders or building-wide alerts to occupants. More broadly, the whitepaper shows how to easily build an end-to-end workflow for capturing, storing, and displaying certain types of IoT data. You could use the code shown to display room temperatures, occupancy, noise levels, traffic, or almost any other data for which you have a sensor.

To read the article and see the code, please follow this link to the Sysinno website.

GraphQL on Azure: Part 6 – Subscriptions With SignalR

by Contributed | Apr 6, 2021 | Technology

This article is contributed. See the original author and article here.

In our exploration of how to run GraphQL on Azure, we’ve looked at the two most common aspects of a GraphQL server, queries and mutations, so we can get data and store data. Today, we’re going to look at the third piece of the puzzle, subscriptions.

What are GraphQL Subscriptions

In GraphQL, a Subscription is used as a way to provide real-time data to connected clients. Most commonly, this is implemented over a WebSocket connection, but I’m sure you could do it with long polling or Server Sent Events if you really wanted to (I’ve not gone looking for that!). This allows the GraphQL server to broadcast query responses out when an event happens that the client is subscribed to.

Let’s think about this in the context of the quiz game we’ve been doing. So far the game is modeled for single player, but if we wanted to add multiplayer, we could have the game wait for all players to join, and once they have, broadcast out a message via a subscription that the game is starting.

Defining Subscriptions

Like queries and mutations, subscriptions are defined as part of a GraphQL schema, and they can reuse the types that are available within our schema. Let’s make a really basic schema that contains a subscription:

type Query {
    hello: String!
}

type Subscription {
    getMessage: String!
}

schema {
    query: Query
    subscription: Subscription
}

The subscription type that we’re defining can have as many different subscriptions that clients can subscribe via, and each might return different data, it’s completely up to the way your server wants to expose real-time information.

Implementing Subscriptions on Azure

For this implementation, we’re going to go back to TypeScript and use Apollo. Apollo have some really great docs on how to implement subscriptions in an Apollo Server, and that’ll be our starting point.

But before we can start pushing messages around, we need to work out what is going to be the messaging backbone of our server. We’re going to need some way in which the server and communicate with all connected clients, either from within a resolver, or from some external event that the server receives.

In Azure, when you want to do real-time communications, there’s no better service to use than SignalR Service. SignalR Service takes care of the protocol selection, connection management and scaling that you would require for a real-time application, so it’s ideal for our needs.

Creating the GraphQL server

In the previous posts, we’ve mostly talked about running GraphQL in a serverless model on Azure Functions, but for a server with subscriptions, we’re going to use Azure App Service, and we can’t expose a WebSocket connection from Azure Functions for the clients to connect to.

Apollo provides plenty of middleware options that we can chose from, so for this we’ll use the Express integration, apollo-server-express and follow the subscriptions setup guide.

Adding Subscriptions with SignalR

When it comes to implementing the integration with SignalR, Apollo uses the graphql-subscriptions PubSubEngine class to handle how the broadcasting of messages, and connections from clients.

So that means we’re going to need an implementation of that which uses SignalR, and thankfully there is one, @aaronpowell/graphql-signalr-subscriptions (yes, I did write it :squinting_face_with_tongue:).

We’ll start by adding that to our project:

npm install --save /graphql-signalr-subscriptions

You’ll need to create a SignalR Service resource and get the connection string for it (I use dotenv to inject it for local dev) so you can create PubSub engine. Create a new resolvers.ts file and create the SignalRPubSub instance in it.

import { SignalRPubSub } from "@aaronpowell/graphql-signalr-subscriptions";

export const signalrPubSub = new SignalRPubSub(
    process.env.SIGNALR_CONNECTION_STRING
);

We export this so that we can import it in our index.ts and start the client when the server starts:

// setup ApolloServer
httpServer.listen({ port }, () => {
    console.log(
        ` Server ready at http://localhost:${port}${server.graphqlPath}`
    );
    console.log(
        ` Subscriptions ready at ws://localhost:${port}${server.subscriptionsPath}`
    );

    signalrPubSub
        .start()
        .then(() => console.log(" SignalR up and running"))
        .catch((err: any) => console.error(err));
});

It’s important to note that you must call start() on the instance of the PubSub engine, as this establishes the connection with SignalR, and until that happens you won’t be able to send messages.

Communicating with a Subscription

Let’s use the simple schema from above:

type Query {
    hello: String!
}

type Subscription {
    getMessage: String!
}

schema {
    query: Query
    subscription: Subscription
}

In the hello query we’ll broadcast a message, which the getMessage can subscribe to. Let’s start with the hello resolver:

export const resolvers = {
    Query: {
        hello() {
            signalrPubSub.publish("MESSAGE", {
                getMessage: "Hello I'm a message"
            });
            return "Some message";
        }
    }
};

So our hello resolver is going to publish a message with the name MESSAGE and a payload of { getMessage: “…” } to clients. The name is important as it’s what the subscription resolvers will be configured to listen for and the payload represents all the possible fields that someone could select in the subscription.

Now we’ll add the resolver for the subscription:

export const resolvers = {
    Query: {
        hello() {
            signalrPubSub.publish("MESSAGE", {
                getMessage: "Hello I'm a message"
            });
            return "Some message";
        }
    },
    Subscription: {
        getMessage: {
            subscribe: () => signalrPubSub.asyncIterator(["MESSAGE"])
        }
    }
};

A resolver for a subscription is a little different to query/mutation/field resolvers as you need to provide a subscribe method, which is what Apollo will invoke to get back the names of the triggers to be listening on. We’re only listening for MESSAGE here (but also only broadcasting it), but if you added another publish operation with a name of MESSAGE2, then getMessage subscribers wouldn’t receive that. Alternatively, getMessage could be listening to a several trigger names, as it might represent an aggregate view of system events.

Conclusion

In this post we’ve been introduced to subscriptions in GraphQL and seen how we can use the Azure SignalR Service as the backend to provide this functionality.

You’ll find the code for the SignalR implementation of subscriptions here and the full example here.