Azure Logic App – Conditions: Success and Failure

Azure-Logic-App-Con

This is just a very short post explaining how to add conditions within your Azure Logic App. The most common case would probably handle a scenario where it’s required to execute different follow-up actions based on the execution status of the preceding action (success or failure). And therefore I will be using this case as an example. But let’s go over some of the details first.

Azure Logic App – Conditions: Expressions & Dependencies

Update: This article is still relevant! However, due to the latest designer updates, the screenshots aren’t reflecting schema version 2015-08-01-preview. More information can be found here.

Conditions are basically an array of checks that have to be met before an action will execute. They can either be expressions that evaluate to either true or false at runtime, or implicit and explicit dependencies.

Dependencies

Implicit dependencies are created by the Azure Logic App Service in case an Action consumes data returned by another Action. Implicit dependencies will show up within the code view, but you won’t have to worry about managing implicit dependencies as expected.

Explicit dependencies can be used in case you would like to wait for another action to complete however, not having a dependency on the returned data. I’ve included a sample below which can only be inserted while in code view mode.

It’s important to know that adding a depends on will cause the action to only execute if / when the dependency succeeds. This is also the reason why it’s so important to check for the action failure state within the Logic App workflow.

Expressions

The syntax used to build expressions is also known as the Logic App Workflow Definition Language. It’s a very simple language and includes functions to handle collections, strings, dates and logic just like in any other language. More details can be found here: https://msdn.microsoft.com/en-US/library/azure/dn948512.aspx

NOTE: At the moment the Azure Logic App designer doesn’t include a rich expression builder (and I’m not sure it ever will) and therefore it’s required to type your expressions within a Condition text box as shown below;

Azure-Logic-App-Expressions

It’s possible to create multiple conditions instead of building very complex expressions. This will look like the following:

Or just combine the two using the @and() function.

Building the sample workflow

At this point it’s time to start building a simple Azure Logic App which includes the success/failure check. I will keep all simple as possible by using only HTTP actions and no triggers.

  • Create a new Logic App within an existing App Service Plan (or create a new App Service Plan and provision some Azure API Apps). Open the Logic App and click on Triggers and Actions to open the designer/ author mode.

  • I won’t be using triggers and therefore selecting the Run this logic manually checkbox.

Azure-Logic-App-Expressions-2

  • At this point add a new HTTP action, select GET and type http://www.microsoft.com within the URI text box.
  • Azure-Logic-App-Expressions-3

  • Open http://requestb.in and create a new RequestBin which will be used to track our success and failure calls. The URL will look something like this http://requestb.in/1hyc6ss1

  • Add another HTTP Action, select GET and provide the requestBin url however adding a query string parameter like so: http://requestb.in/1hyc6ss1?result=success

  • Before saving, make sure to click on the gear icon in the right upper corner and select Add a condition to be met. A text box will show up with the caption Condition. Provide the expression as shown below and save the action.

  • Add a third HTTP action and repeat the steps as mentioned within step 5 and 6, but this time providing the following URI http://requestb.in/1hyc6ss1?result=failure and the following expression as a condition:

NOTE: As soon as you save the action you will notice that the designer is smart enough to rearrange the logic steps.

  • Save the workflow and open the main properties screen of the Logic App. In this blade press Run Now

At this point it’s time to review what happened. A section called Operations can be found within main properties screen. Here you can review information about the execution of the Azure Logic App. If you select the latest entry, a new blade will appear on the right containing the details.

Azure-Logic-App-Expressions-5

In the details view it’s visible that http1 (the failure action) was skipped. This indicates that the Microsoft website was up and running.

Azure-Logic-App-Expressions-6

By clicking on the individual actions it’s even possible to review the input and output of the call, which is very useful for debugging. At this point you should also be able to see a success request listed within your RequestBin.

Conclusion

This post just quickly covered how to work with conditions within Azure Logic Apps. As you can see it’s very simple to create conditions using dependencies or expressions.

  • StuOfCoburg

    Great post. Thanks. I have some logic apps and consistently, whenever I have a Skipped step it leave the workflow in a Running state. What might be causing that?? Anything I can do to prevent it from happening?

    • StuOfCoburg

      I created a new resource group and built the same workflow in it which didn’t display the skip & run behavior. So, it looks like something to do with the resource group getting into a state where it was not handling skips.

      • Sorry, I haven’t noticed your message until now. Disqus stopped sending me updates.

        I’ve kept all my Logic App assets within the same container, and therefore haven’t seen this behavior. But I would expect that the failed call would return something useful allowing you build a follow-up action and eventually terminate the Logic app automatically. Sounds more like a bug to me, but maybe there is something interesting to discover within the process and call logs.

        • StuOfCoburg

          Hi Kevin, no probs. Unfortunately, even in the new container the behavior has returned. The work around was just to put a forced fail step into the workflow so it exits the running state.

          The workflow is over a dropbox file list: read,write,delete (aka move), and then fires an on-premise SQL stored proc based on the file content. The workflow can set up a skipped condition if there are no files to list or if the content of the files doesn’t require a SQL update.

          I think I need to report it as a bug.

  • Pingback: Azure Logic Apps II: ¿Qué más puedo hacer? | El Blog del Programador()

  • abhishek kumar mishra

    Great post indeed!
    I have about 8 logic apps in my workflow. And I want to send an email to my tech support email id whenever any of the actions failed in my workflow. Do you have any insights on this or could you redirect me to an appropriate resource?

    • Thank you for your comment Abhishek Kumar. For your scenario I wouldn’t recommend adding additional workflow steps after every action given unless rollback logic or other business related logic is required. This will just clutter up your workflows in my opinion.

      The best strategy would be to monitor your workflow instances. Before this was only possible via the API (Azure Automation or Web job responsible for reading the log and sending the notification). Fortunately, since late November last year the Logic apps team included monitoring metrics for Logic apps enabling the option to configure alerts based on the Run status. But if you need advanced logging and alerting, the API might be a better option.

      Details can be found right here: https://azure.microsoft.com/en-us/updates/metrics-for-logic-apps/

      The “new” Azure portal also allows the ability to create dashboards (startboards) for the people at tech support. I’ve written several post in the past on how to achieve this.

      http://devslice.net/2015/01/azure-portal-monitoring-basics/

      • abhishek kumar mishra

        Thank you so much Kevin, for such an elaborate answer! I never thought of having this approach coming from a development background. And I would give this approach a thought.

        But in my original question I forgot to ask one thing. Suppose, I have an “action 2” which gets called only when “action 1” fails. Is there any way to get the detailed error detail in “action 2” about what went wrong in “action 1”. For this I know there are workflow apis for getting a run details based on run name, but I don’t see any option in the logic app to get this workflow run name.

        If you know of any method using which I can get the workflow run name (aka. Identifier in the run list) then that would be great.

        • The Logic App Workflow Definition Language enables the option to access Workflow functions. These functions allow you to get information about the workflow itself at run time, for example @workflow().name. The property .runName is also included within the API documentation however I’m not certain if the data is available at runtime or only when initiating a Run using the API.

          resources:
          https://msdn.microsoft.com/en-US/library/azure/dn948512.aspx
          https://msdn.microsoft.com/en-us/library/azure/dn948513.aspx

          • abhishek kumar mishra

            Thanks Kevin! And I was also able to see that it’s not possible to use the @workflow within an Action.

          • Hi Abhishek Kumar, I’ve up voted your submitting with the title “Ability to access the workflow run id in any action within a logic app” as found on feedback.azure.com. Being able to consume the information from any Workflow action would be interesting for logging and auditing purposes.

          • abhishek kumar mishra

            Thanks Kevin!

  • Dilshad

    Hi

    I have a related question. If I want to kick off an action based on the Http return status of another action. How would the condition expression look like? The kick off status is 412. I tried following but gives me expression error.

    “conditions”: [
    {
    “expression”: “@(equals(actions(‘ExecutePowerBIAction’).code, ‘Precondition Failed’))”
    }]

    • Hello Dilshad,

      In the example above I’m using the generic action status which is can be retrieved using the property called status. If you are interested in the results of the action, you will need to retrieve the information from the action output.

      By default, the HTTP Action provided by Microsoft returns the data from the header and body. This data can be accessed with the expressions listed below:

      @actions(‘action name’).outputs – Returns all output
      @actions(‘action name’).outputs.body OR @body(‘action name’) – Body only
      @actions(‘action name’).outputs.headers – Headers

      • PaulS

        Hi Kevin
        Just taking it one step further, how would you then examine the content of the body? I’ve gotten as far as @body(‘action_name’) but then I can’t seem to get anything else, i.e. @body(‘action_name’).result saves ok, but then doesn’t work, and when I go back into the designer the .result part has been removed. I’m trying to examine the output of the BizTalk XML Validator which unfortunately will produce a 200 success response even if the validation failed, and instead will provide a “result” and an “error description” in the body, which is what I am trying to read.
        Thanks and great article.

        • Hey Paul,

          Thanks for letting me know you liked the article! To answer your question; The HTTP Action result will need to be parsed, otherwise it’s not possible to consume the data using the dot notation. There are several ways of doing this however, this depends on the type of output the service is returning.

          If the output is JSON, it’s simply enough to use the parse function like this: @{parse(your_input).Result}

          Given that BizTalk returns data in XML format, it’s required to use a helper action like the BizTalk XML Validator or a custom Logic App parser. When using the BizTalk XML validator make sure to provide HTTP Action’s content body as the input parameter. After this, The parsed .Result property data can be accessed like this:

          body(“your_xmlvalidator_name’).Result

          Or used within a condition (which I guess is what you would like to do):

          @equals(body(‘your_xmlvalidator_name’).Result,bool(‘True’))

    • Wrote a short article which might be helpful when debugging calls and response messages when using the HTTP Action step within Azure Logic Apps.

      http://devslice.net/2016/02/debugging-http-actions-logic-apps/

Post Navigation