Welcome again to another Logic Apps Best practices, Tips, and Tricks. In my previous blog posts, I talked about some of the most essential best practices you should have while working with the Azure Logic App:
- #1 Logic App Naming Convention
- #2 Actions Naming Convention
- #3 Add comments
- #19 Protect your Logic Apps (Part I) – Using API Management to expose the Logic App and Implement IP Addressing Restriction
- #19 Protect your Logic Apps (Part II) – Secure data in the run history by using obfuscation
And some tips and tricks:
- #4 Using Scopes
- #5 Delete comments
- #6 Error handling configure run after settings
- #7 Learn from failures
- #8 Expressions nightmare
- #9 Control your connectors (API connections)
- #10 Fix connectors (or API connections)
- #11 Connectors naming convention
- #12 Choose your developer tools properly
- #13 Logic App (Standard) vs (Consumption)
- #14 Implement good governance policies
- #15 get the error message
- #16 roll back to a previous version of an Azure Logic App Consumption
- #17 using other HTTP Methods then POST
- #18 Foreach Parallelism
- #20 Accessing Runtime Settings (Part I) – Logic App Consumption
- #20 Accessing Runtime Settings (Part II) – Logic App Standard
- #21 Moving or organizing shapes inside Visual Studio Logic App designer
Today I’m going to speak about another important Best practice, Tips and Tricks that you need to consider while designing and enhancing your business processes (Logic Apps): The if() expression function.
The if() expression function
Logic App Expressions can be used to manipulate incoming messages. Such manipulations can be used for strings, dates, and times, XML, or JSON. Functions allow you to do all kinds of expressions, such as:
- String functions
- Collection functions
- Logical comparison functions
- Conversion functions
- Math functions
- Date and time functions
- Workflow functions
- URI parsing functions
- Manipulation functions: JSON & XML
The Workflow Definition Language of the Logic App runtime natively provides all these functions for you. Because they are part of the engine, they execute faster than other strategies like calling an Azure Function. In this series of best practices, tips and tricks, I already wrote a post about expressions; you can read more in detail here.
If I already spoke about expression, you may wonder why I’m dedicating a tip to the if() function. Further in this post, you will see the reason why while I’m explaining the importance of this function.
Sometimes, or (actually) many times, I see developers using Control – Condition action to evaluate a simple condition just to define a variable value. Something as we see in the picture below:
Or using the same approach, in other words, a conjugation of:
- A Control – Condition action and
to define a property of a JSON/XML message:
By themselves, none of these situations is incorrect. This is the normal no-code, low-code approach… and the no-code, low-code approach is good until the point it isn’t anymore and starts to become more of a problem than the solution.
You may be wondering again why this no-code, low-code approach may be a problem.
Well, the main problem with this no-code, low-code approach is that:
- It brings a lot of complexity to our workflows: In an enterprise or more complex scenario, our workflows are not as simple as the pictures you see above. In fact, they are normally more complex, and in some cases, we need to apply complex conditions that we indeed need to perform with the Control – Condition action. So these simple and “unnecessary” conditions will complicate our workflow definition.
- The Visual Studio Logic App designer or Visual Studio Code Logic App Designer will get slower and slower until it may reach a point it will not open (especially in Visual Studio): Too many shapes (actions) inside our workflow will slow down the performance of our Visual Studio and Visual Studio Code Logic Apps designer until a point you cannot work with the designer, especially in Visual Studio and Logic App Consumptions – this is a well-known issue.
To avoid these problems and to enhance not only our developing productivity but the overall performance of our Logic Apps, we can replace these simple conditions with the if() function in a more “first-code” approach.
The if function will check whether an expression is true or false. Based on the result, return a specified value. Parameters are evaluated from left to right.
- if(expression: boolean, valueIfTrue: any, valueIfFalse: any)
So, let’s see this in action and how we can simplify the business logic of our Logic Apps.
In the case of the first scenario, instead of having the Control – Condition action and, in each branch, a Set variable action to define the value according to the condition. We can instead use the Initialize variable action with the following if() function to set the value according to the condition:
Basically, we are doing the same logic in a single expression:
- Check if the value of the property Number is equal to 1.
- If yes, then set the value of the variable to Order.
- Otherwise, set the value of the variable to Invoice.
Instead of having four actions in the workflow, I now only need one.
Now, let’s look at the second scenario. Applying the same if expression but this time directly on the Message Compose action
Instead of having five actions in the workflow:
- An Initialize variable action
- A Control – Condition action
- A Set Variable action on the True branch
- A Set Variable action on the False branch
- And a Compose action
We now only need one: the Compose action.
So, the reason to learn here is that:
- In simple scenarios – aka small Logic Apps – it is not critical to fine-tune the logic of our business processes, and the no-code, low-code approach will work fine despite having a little more overhead.
- In more complex scenarios, you need to be careful with these situations, and I will definitely recommend you use the “code” approach using the if() function.
I hope you enjoy this developer tip and stay tuned for the following Logic App Best practices, Tips, and Tricks.