How YOU can build your first Serverless Logic app, part I

Chris Noring - Sep 9 '19 - - Dev Community

Follow me on Twitter, happy to take your suggestions on topics or improvements /Chris

This article is part of #ServerlessSeptember. You'll find other helpful articles, detailed tutorials, and videos in this all-things-Serverless content collection. New articles are published every day — that's right, every day — from community members and cloud advocates in the month of September.

Find out more about how Microsoft Azure enables your Serverless functions at https://docs.microsoft.com/azure/azure-functions.

Imagine you need to build an app. To build your app you need it to integrate with a lot of things like Dropbox, Excel, Twitter, Slack, Cloud services and so on. You roll up your sleeves and know that you need to spend a lot of time learning how to talk to each of these APIs, you need to generate API tokens and write connection code. A few weeks later you are probably done writing all the integrations and you can probably start to think of the actual business logic that you want to implement. STOP, like full STOP. If this is your app, a bunch of integrations and then just a little business logic in there then there's a framework out there for you. It's part of the Serverless offering and it's called Logic Apps.

This is part of series

  • Part I, we are here, scaffolding a database and building the Logic App
  • Part II, this part covers how to build our Serverless App

TLDR; this article will spend time describing Logic Apps, when it's a good candidate and what parts it consists of. We will end by building something in it.

In this article we will cover:

  • Why, here we try to describe situations where a framework like logic apps really shines and when it doesn't shine and when you have a case when it's not so clear cut whether to code it all yourself or go with Logic Apps.
  • What, we will describe what parts logic apps consist of so you have a good sense of what you can build with it
  • Demo, we will be building something in Logic apps consisting of a Twitter integration and a database. This is a fun thing to build that takes you very little time and can be easily extended with more logic

Resources

Why

As we stated at the beginning of the article: having a lot of integrations that you need to do in your app means, you either spend a lot of time building connection points to those integrations, or you rely on an integration framework like Logic Apps and other similar frameworks.

There's a connector for that

Your job is to find the sweet spot in which it makes sense to use an integration framework versus writing it all yourself. One telltale might be the sheer number of integrations and maybe a better sign is the integrations you need are in this list:

  • Salesforce
  • Office 365
  • Oracle
  • Twitter
  • YouTube
  • Dropbox
  • Google services
  • Azure Cognitive Services

They are? Great then Logic Apps might be for you.

NO? There are 100+ connections points or connectors as Logic Apps calls them. Here's a link so you can read more on which connectors are supported

Docs on Connectors

 How do we write business logic?

Ok, so you are considering Logic Apps? The next question on your mind is probabably how you can get your business logic in there. There are two answers to that:

  1. Control actions, there are specific actions in Logic Apps called Control Actions that allows us to express branching logic like IF THEN.. or LOOP UNTIL, you get the idea
  2. Custom connectors, if an integration we are looking for is missing and/or we got very specific logic we need to carry out, then we can write our own connector and make that happen. You can read more about that case here Create a custom connector

All this becomes very theoretical so let's try to explain what the core concepts of Logic Apps are and how it works so you get a better hang of it.

What

Ok then. Logic apps. The easiest way to understand all the concepts is to look at a business process that we mean to turn into a Logic App. Like so:

Above we have a process a social media manager. That looks for a new tweet on a topic. IF that happens then we try to determine whether the content is positive or negative. IF Positive then we store the link to the tweet in the database. IF it's negative then we email our customer department for a follow-up.

This relatively simple process lends itself to easily be written in Logic Apps and the first thing we do is to identify what is what, what stage in the process corresponds to what concept.

Let's go through it from the top.

Trigger

A trigger is something that starts the whole process and it activates based on a condition. In this case, it activates because a tweet is posted on a certain topic.

Action

In the action step we carry something out. In this case we are sending the tweet text as an input parameter to a Cognitive Service to determine sentiment, e.g whether it was a positive or negative tweet.

Control

A control is a type of action, also referred to as a control action. In this case, it's trying to determine based on a score value it gets from the Cognitive Service whether to store something in a Database or to email customer service.

More actions

Our last step consists of two different actions Store link in database and Email customer service. As with the action Detect sentiment, this is something we need to carry out.

How do we create a Logic App?

Ok, you might have a better idea at this point what the building blocks are. So how do we do it? How do we create a Logic App?

We use something called Logic Apps Designer

This is a visual tool that lives in the Azure Portal and yea it's pretty much drag n drop of components and configures inputs and outputs. But it's powerful, really powerful when you can connect different connectors like Slack or Twitter with Cloud Services.

What does it look like, I need a Visual, gimme a Visual !

and a Visual you shall have!

From the above picture, we can see that we lay out different components/connectors from the top. Just by taking a quick look at it we can almost get a basic understanding of what it does.

Enough theory, the best way to learn is to do. :)

 Demo

In this demo we will do the following:

  1. Provision and Create a database, the SQL Server database will contain some columns that will help us store information about the tweet
  2. Create a logic app, the app will listen to specific tweets from Google and place those in a database
  3. Build a Serverless API, The serverless function app will serve as an API that reads from the Sql Server database
  4. Implement a UI, we will build a SPA Application using Angular that consumes the Serverless API

Provision and Create a database

Ok then, let's create a database. We need to do two things:

  1. Provision a database
  2. Add a table with columns that help us store what we need

Provision a database

Go to portal.azure.com. Log in, then click Create a resource. Thereafter select SQL Database as indicated below.

Fill in all the fields indicated in red. If you need to create a server you will get the New Server dialog on the right.

Finally press Review and Create. This will take you to a screen where you are asked to look that everything looks correct. At this final screen press Create and it should start provisioning.

Add a table

We've got one more thing to do when it comes to our database. It needs a table. So what columns do we need and what should our table do? Well, we mean to use it to store information on a tweet so the following could be good:

  • Tweet id, so we can find the actual tweet if we need to
  • Tweet date, it's nice to know when it was tweeted so we understand what happens over time
  • Location, knowing where it was tweeted will give us a good indication on what parts of the world care about a certain topic
  • Tweet text, of course, we need the tweet content so we can analyze it later

Ok, then let's head over to our SQL Server resource.

We will be asked to log in given the credentials we have set up for the database.

The first time around it will tell us we don't have access. To get access we need to set up a firewall rule. Luckily that's easy. Just click the blue link under the Password field that appears when it tells you you don't have access. This will take you to a page looking like this:

Above we have a label Client IP Address. To the right of that is our machines IP. Take that IP and enter it in the fields START IP and END IP. Then fill in a name for your rule in the field RULE NAME. Ok, we are done, let's head back to the log in screen. We fill in user name and password and this time around we are presented with the query editor.

We don't have any tables but we have a large text area to the right. We need to define a table with some columns.

In the textarea, add the following:

create table Mentions(
 id INT PRIMARY KEY IDENTITY,
 TweetText varchar(500) NULL,
 TweetId varchar(100),
 TweetDate DATE NULL,
 TweetLocation varchar(100)     
);

and press Run to create our table.

Now we have a table. Great, next step is to build our logic app.

 Create a logic app

We stay in the portal for this one. To create a Logic App we just need to go to Create Resource. type Logic App and select it, like so:

At this point, you fill in the needed data for your logic app which is name, resource group and location. Then it should start provisioning your Logic App.

At this point, we need to scroll and select Blank Logic app

Let the fun begin :)

We need to carry out the following:

  1. Select a Twitter trigger that triggers on a keyword, i.e a hashtag
  2. Connect a SQL Server and map it's columns to Twitter fields.

Select a Twitter trigger

Search for Twitter and select the Twitter icon that comes up, it should say When a new Tweet is posted. At this point this should display:

You need to sign into Twitter as indicated. After you've done that it should change appearance to look like this:

Indicate the text you want to search for #brexiteer, yes the database will fill up in no time :D

Fill in a suitable interval, we go with 1 minute.

Next, we need to connect our SQL server, which we do by clicking New Step.

If we now search for SQL server we should get something like this:

Below you can see that SQL server comes in two flavors Trigger and Actions. That's worth noting for the future if we wanted to build an app based on something that changes in a database, ideas ideas :)

Back to our app, select Actions and choose Insert Row v2. It should now look like this:

Now click Manually enter connection info:

At this point choose your Server name, Database name and Table name.

Now comes the fun part, the matching of twitter parameters to our columns :)

First click Add new parameter and check all the columns from your database. Then click in a field and a dialog should pop up from the right with choices of Tweet fields. Keep clicking on a database field and the corresponding tweet field until it looks like the below:

Finish this off by pressing Save. This concludes the logic app part.

Summary

This ends part I, in our next part we will build the Serverless API

PartII

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .