Logic App and Service Bus

Logic App
Service Bus

This week I started working with Logic Apps.  I have a project with a specific end goal in mind for my first Logic App application.  This post will cover the first part of the process, moving data from a webhook to Azure Service Bus with Logic Apps.

When I started this process I thought it would be fairly simple and assumed documentation would be plentiful.  I was wrong.   It is not complicated for anyone who has some basic understanding of each concept.  Documentation, however, is limited, outdated or just not complete.  It took me a lot longer than I expected to get a functional example.  This post outlines the steps I took to get to a working example.  Before getting into that, let’s cover each component for reference.

  • Webhook – HTTP call that starts a process.  The body of the HTTP call contains the data.
  • Logic App – An Azure workflow or orchestration tool that moves data along a path or starts processes with the use of connectors.
  • Service Bus – An Azure based messaging service that reliably passes messages between applications and services.
  • Service Bus Topic – Service Bus that leverages a publisher, subscriber method for passing messages.  Messages are sent to a Service Bus Topic and rules are applied to the messages that filter them to specified subscriptions.

Process Overview

Now that’s out of the way, let’s cover what I’m trying to do in more detail.  My goal is to pass data from a webhook to a Service Bus Topic.  Logic Apps brokers the connection, accepting the data from a webhook and passing it to the Service Bus.  Here is an overview of the process:

Webhook To Logic App to Service Bus
Logic App Project Flow

This post stops at getting data into the Service Bus.  What I do after that is the topic for a future post.  To be honest, I’m writing this as a reference to myself as much as for anyone else. 

Logic App Configuration

I start with the Logic App.  Create one and give it a name.  Once deployed, open and create a blank Logic App.  Search for HTTP request and select the trigger When an HTTP request is received.  This creates a trigger that responds to Webhooks.  Notices that the URL is avaialble on save.

New HTTP Request
New HTTP Request
Logic App HTTP Request
Logic App HTTP Request

Next, I’m going to set up the JSON schema for the data I’m sending.  Two pieces of information are passed into the Logic App for this example, a department name and a message.  A sample payload will look like the JSON below:

{
    "dept": "IT",
    "message": "This is a test"
}

Click on Use sample payload to generate a schema and add the sample payload above or create your own.

JSON Sample Payload
JSON Sample Payload

Next, select Add new parameter and select the Method option.  Change the Method option to Post. Once finished, it should look like this:

Finished HTTP Request
Finished HTTP Request

This should be enough to get the department and message into Logic Apps.  By default, the HTTP endpoint will respond to a Post Webhook with a 202 accepted status message.  I am going to add a 200 response to the HTTP Post that returns the data passed in the request.  This is as simple as adding a new HTTP Response step.  Click on the Plus ‘+’ sign under the HTTP request step and search for Response.  Select the Response Request action.

Leave the status code at 200 and click in the Body section.  A list of dynamic content will appear.  Select Body from the list.  Once finished it should look like below.

Logic App 200 Response
Logic App 200 Response

Now, the data passed to the Logic App is returned in the response.  This is handy for troubleshooting.

Test Webhook

This step will test the webhook.  Save the Logic App if you have not done so already.  Once saved, there will be a URL in the HTTP POST URL field.  Copy this and save it for later.

I used Postman to test the Logic App.  An online tool like apitester.com or even invoke-webrequest in PowerShell could also be used.  Postman is a free tool and good for testing webhooks and other online services.  Create a new test and set the method to Post.  Enter the URL in the URL section and go to the body section.  Select raw and set the type to JSON.  Past the sample payload from above.   Once finished, it will look like below.

Test with Postman
Test with Postman

Once that’s entered, click on Send to start a test.  Postman will display a 200 message and output the sample data as shown below if everything is correct.  This indicates Logic Apps accepted the data and returned the body with a 200 message. 

Test Webhook Output
Test Webhook Output

Service Bus

Now that data is getting into Logic Apps, the next step is to send that data to Service Bus.  If you have not set up a service bus, do so now.  Topics are only available with the Standard version of Service Bus or higher.  The free tier does not support Topics.  This example uses Topics and requires Standard tier of Service Bus. 

Once the Service Bus is provisioned, go to Topics and add a new topic.  Give it a name and leave the rest as default.

Create Topic
Create Topic

Next, go into the topic and select Subscriptions.  Click on the plus ‘+’ sign to create a subscription.  Give the subscription a name, the rest can stay as default.

Create Subscription
Create Subscription

There are many other topics related to subscriptions and queues that won’t be addressed in this post.  The focus of this article is getting data into the Service Bus. 

Logic App To Service Bus Connection

Go back to the Logic App after the topic and subscription are configured.  Add a new step under response and search for Service Bus.  Select the Send Message option under Actions.  This action will send the body JSON data to the service bus.

New Send Message Action
New Send Message Action

Give the connection a name and select the Service Bus Namespace from the list.  The Service Bus setup in the previous step will show on the list.  Use the default Shared Access Key and click Create.  This will create a connection to the Service Bus.

Select Shared Access Key
Select Shared Access Key

Once created, select the Queue/Topic name from the list, it will be pre-populated with information from your Service Bus.  Remove System Properties from the window by clicking the ‘X’ next to it.  Click the drop-down arrow next to Add new parameter and select Content Type and Properties.    Under Content Type, type “application/json”.  Next, go to Properties.  A list of dynamic content will appear.  Select Body from the list.  Once finished it will look like below.  Save before continuing.

Finished Logic App Send Message
Finished Logic App Send Message

Now for a test.  Go back to Postman or whatever tool you’re using to send webhooks.  Run the same test again.  You should get the same 200 response. 

Verify Test Data

The 200 response was received, but how do we know if the data was passed successfully to the Service Bus?  The following section covers a few different steps that will verify the process worked as expected.

Logic App Status

In the Overview section of the Logic App, view the status for the Logic App.  It should show Succeeded if it ran without error. 

Logic App Status
Logic App Status

Next, click on the job that was most recently ran.  From here we can see each step of the process, getting an indication of where a problem occurred if there was one.  Also, notice that you can select each step to view raw input or output.  The Run History is very useful for troubleshooting issues with Logic Apps.

Logic App Run History
Logic App Run History

Service Bus Status

Now that we have confirmed that the Logic App ran successfully, let’s move onto the Service Bus. Go to your Service Bus, Topics and go to the Subscription.  Under Message Count for the Subscription, it should show 1 message.  This is the message from the job that just ran and indicates the message got to the topic correctly.

Service Bus Message Count
Service Bus Message Count

Service Bus Explorer

At this point, we see there is a message in the Topic but we can’t actually see the message.  For that, and to perform other advanced activities on the Service Bus, we need to run the Service Bus Explorer.  Service Bus Explorer can be downloaded here

Install and run Service Bus Explorer. To connect, first get the connection string from the Azure portal. Go to your Service Bus and select Share Access Policies.  From there, select RootManageSharedAccessKey. A window will appear that lists Keys and Connection Strings.  Copy one of the Connection Strings. Please note, in production, you may want to create a new access policy with permissions limited to just what is needed.

Get Connection String
Get Connection String

In Service Bus Explorer, go to File, Connect to create a new connection.  Change the Service Bus Namespace dropdown to Enter connection string.  Paste the connection string into the Connection String window and click OK.

Connect to Service Bus Namespace
Connect to Service Bus Namespace

Service Bus Explorer will now show the topics and subscriptions in the Service Bus.  Click on the topic you set up and go into the subscription.  Click on the Messages button.  Leave settings in the Retrieve messages from subscription box as default and click OK

Retrieve Messages from Subscription
Retrieve Messages from Subscription

Double click on the message in the Message List to view details of the message.  Here you can see the key’s and values passed to the Topic.  This is confirmation that the data sent by a webhook was passed successfully to the Service Bus.  Notice that there are many other features available with the Service Bus Explorer.  I’ll come back to it in future posts.

Service Bus Message Detail
Service Bus Message Detail

Summary

This is where the post ends.  At this point, you should have a working Logic App that updates a Service Bus Topic from data passed by a webhook.  These steps could be modified fairly easily to update a Service Bus Queue on the Free Service Bus Tier.  Stay tuned for my follow up post where I take action on the data passed into the Service Bus.

One thought on “Logic App and Service Bus

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.