Azure App Services Series – Finding #5: Changing the order of connectors in your Logic APP not possible in designer view

This blog post is one of many of a series we have about Microsoft Azure App Services. See a list of all our findings here.

Introduction

Developing Logic Apps requires you to put a chain of API apps in place. This chain can of course be changed.
The reasons why this chain could be changed could be

  • An API app has changed.
  • A connector is not working anymore
  • The connector is not required anymore
  • The flow has changed and therefore maybe the order of API apps.
  • etc.

Some of the points in the list above such as if a connector is still working or not can be monitored by Integration Manager.

The Problem

The designer the current state of Logic Apps is offering does not offer drag and drop and therefore changing the order of API apps or inserting a new API app in between is not possible.

The Solution

Luckily for us the designer view is not the only view available the Logic App designer offers – we also have the code view. You can achieve changing the order of API apps / connectors in your Logic App by changing the JSON workflow definition.

To learn more about the Workflow definition click here.

What we would like is of course the possibility to drag and drop the different connectors and put them in the order we want instead of needing to change the JSON workflow definition.

Azure App Services Series – Finding #2: Logic App Workflow API documentation is incomplete

This blog post is one of many of a series we have about Microsoft Azure App Services. See a list of all our findings here.

Introduction

With the release of Logic Apps, Microsoft also releases the Workflow Management API. An API to use for getting access to the workflow of your logic apps allowing you to easily enable, disable workflows, get the status, etc.

Microsoft’s documentation of the API is incomplete and not clear which of the API calls are working in the current release of the API.

This API is allowing you to monitor Logic Apps with Integration Manager’s monitoring feature!

The Problem

Problem #1: Incomplete documentation

According to the documentation the URI to the calls is:

https:///subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Logic/workflows/{workflowName}?api-version=2015-02-01-preview

This is wrong of course, you can clearly see that something is missing in the beginning of the URI.

It’s the URI to the region of the Logic App. For example: northeurope.logic.azure.com. The URI to call the API should look like this (example below):

https://northeurope.logic.azure.com/subscriptions/72bad97c-b0ce-40a3-a300-d36e50de34fe/resourceGroups/Default-Web-NorthEurope/providers/Microsoft.Logic/workflows/FTP2BTnoIM?api-version=2015-02-01-preview
Problem #2: Not all of the API calls documented are working (yet)

We did not manage to get many of the API calls to work. In fact, we only did manage to get one call to work – triggering the action by calling the /run method of the API. Most of the others (we did not test all) return 404 not found when calling the API.

Problem #3: There is no documentation about authenticating against the API

The documentation says nothing about how the authentication looks like, which makes the documentation somewhat useless!

For your interest, the authentication type supported is Basic. A username is created on logic app create which is ‘default‘ and the password to use is the primary key (not sure if the secondary works as well) which you can find in the logic apps properties blade of the Azure portal (see screenshot 1).

Screenshot 1 - Primary Access Key

Screenshot 1 – Primary Access Key

So the proper way of authenticating against the API is to send the Authorization header with your Basic username/password value – see example below:

Authorization: Basic YOURENCRYPTED(default:primaryAccessKey)

Azure App Services Series – Finding #1: Problems using Workflow Definition Language in Logic Apps

This blog post is one of many of a series we have about Microsoft Azure App Services. See a list of all our findings here.

Introduction

With the preview-release of Logic Apps, Microsoft also releases a new language used in the work flows of your Logic Apps – Workflow Defintion Language (WDL).

The language is used in your work flow code in both conditions and action inputs.

Using it in coditions

Conditions are used to perform the action on which you add the condition when the condition matches the requirements. This is especially important when it comes to exception handling.

Per default if one of the action fails in an Azure Logic App, the message is thrown away when one of the actions fail, so what you need to do is to create actions that are performed when error occur in order to not loose data. In most cases the data itself is still accessible in the operation logs (this depends on the API apps!) and can be extracted from there with the Workflow Management API (the Workflow Management API will be covered in an upcoming blog post).

An example:
The above example is a condition for an action that is executed when the status of the action “YOURACTION” equals ‘Failed’.

Using it in an action’s input

WDL is not only used in conditions, but also when sending input data to the defined actions. For instance, you might have an FTP connector that is triggered as soon as a file is available on the FTP, what you want is to send the file’s content or file name to another action (logging purposes maybe). In this case the FTP connector would be the trigger and another API App the action. An example of getting the FTP triggers file name:

The above example is a WDL expression to get the triggers output body, which you can send into an action as input.

The Problems

Problem #1

There is basically no Intellisense/help at all when it comes to writing expressions with WDL . The only Intellisense/help you get is when using a trigger’s/action’s output in another action and the only thing you get there are the available output alternatives (output body of succeeded actions! Let me get back to that later in Problem#2 below!) shown in screenshot 1 below. In many cases this is enough, but what happens if you want to use functions to concatenate strings or you want to write conditions? Well, you are on your own body!

available_trigger_outputs

Working with concat or any other function provided by the WDL is not giving you any alternative in the input fields – no help, no nothing except the output of the triggers or actions that have run before the action you are editing, making it very hard to work with WDL!

Problem #2

As described above and shown in the Screenshot 1, we get the triggers’ and actions’ outputs as alternatives in the actions inputs (NOT IN THE CONDITIONS!!!). But the available outputs are the outputs for succeeded actions! But if you have an action that fails based on a condition and you want to send the error message to third-party tools like Integration Manager using Integration Manager’s connector (Coming soon), what is the WDL expression for that? Well and how can we test the expressions (see Problem#3)? The documentation shows us that there is the errors attribute containing an array of errors, but there is no help in the interface on what the WDL expression is for that.

Problem #3

The third problem we see in the current version of Logic Apps are the not yet existing way of testing your WDL expressions, there is some kind of validation on saving your workflow, but no direct way of testing it.

Our wishes

Problem #1: Full intellisense in both action input text fields and condition text fields.

Problem #2: All available outputs for both when an action failes and succeeds. (when building a condition you might want to choose “action(‘ftpconnector’).status”)

Problem #3: Testing of WDL expressions and improved validation.

 

Vote for our feedback

http://feedback.azure.com/forums/287593-logic-apps/suggestions/7592121-intellisense-help-on-wdl-expressions

Twitter
YouTube
LinkedIn