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.
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).
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.
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!
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!
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.
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.
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