Debugging HTTP Actions – Logic Apps

I just wanted to share some details on debugging HTTP Actions within Azure Logic Apps. This because I recently provided some guidance on constructing Logic Apps workflows for non-developer minded group of people. The information within this post should give some insights on what steps to take when running into problems.

Debugging HTTP Actions – before we begin

In case you would like to initiate an HTTP call within your workflow, it’s required to use the HTTP action unless someone, some organization, or your organization published a custom Action (API App) specifically designed to streamline the process. As you can imagine, this specific Action isn’t available most of the time and therefore limited to two options.

• The first option involves developing an Azure API App, which might simplify building workflows depending on the complexity of the calls and the type of implementation. It might be worth investing some time developing a simple web service and expose this service as a Logic Apps API. The majority of the plumbing work, including debugging failed calls, will be included within the creation of the web service.
• The second option will be using the generic HTTP Action to make the call or calls. Which is not that hard, however having some knowledge of the HTTP protocol and REST will come in handy but not required. This mainly depends on the available documentation for the service, which will be called.

As the title suggests, we will be focusing on the second option.

HTTP Message details

Probably the most important step when debugging HTTP calls is being able to see the message details. Currently, there are a couple of ways of retrieving the message. All have their advantages and disadvantages, which I will explain below.

• The Azure Management Portal
• Using a free service like requestBin
• The Azure Logic App Workflow Management API (Rest API)
• Microsoft Azure Logic App Management Library (.NET API)

Now the last two options are out of scope and therefore staring with covering The Azure Management Portal and requestBin after that.

The Azure Management Portal

Note:
The sample application I’m using is very simple and only contains a manual start option and a single HTTP Action.

Within the Management Portal, the message detail can be found on the details section of a run. To access this information, locate your Logic App, and scroll down to see the Operations section within the details window. Here you will find a list containing all runs. Clicking on a run will expand a new window which contains the execution status for every Action. Clicking on an execution status entry will open a new window containing two important sections named; INPUTS LINK and OUTPUTS LINK.

For the HTTP Action, the inputs link contains the information which will be sent to the URL specified within your Action. The format is not a RAW HTTP request, but just the data used within a request.

The Outputs link represents the request result, as the example below shows.

As you can see, there are a relatively large number of steps involved in getting the data, which can be somewhat annoying during debugging. Not being able to see the RAW HTTP data is also somewhat annoying, and this is where requestBin comes to help.

Note:The inputs and output links aren’t exclusively for the HTTP Action, they will be used for all action types and can be used for all your Logic Apps debugging work.

Using requestBin

RequestBin is a service which gives you a URL that will collect requests made to it and let you inspect them in a human-friendly way. So instead of posting to the definite URL, a special RequestBin URL will be used to validate the RAW request.

Using RequestBin is simple; visit http://requestb.in and click in the Create a RequestBin button located in the middle of the page. The service will provide you with a personal Bin URL session and refresh the page to see the incoming request, as explained on the page.

Within the HTTP Action, replace the URL with your RequestBin session URL (HTTP://requestb.in/{code}), then save and run the workflow. Now go back to the browser and refresh the page pointing to your RequestBin session. After updating the page, a new entry should be displayed containing the Request data in a human-readable format.

For simple GET requests, this might be overkill, but when having dynamically building complex HTTP requests, having a way to see what’s going on can save lots of debugging time.