Changes in Logic Apps: Schema Refresh 2

Flow Controls as First Class Citizens

One of the most useful changes in the designer is the creation of action cards for each of the following flow controls:

• Decision Trees (Condition)
• Iterating over a list (For Each)
• Iterate until condition met (Do Until)
• Grouping Activities (Scope)

Condition Improvements

Although the Condition action was present in the last designer refresh, nested conditions could not be created in the design view. This issue, coupled with the complexities of defining a condition in code view, made the creation of nested conditions quite complex.

Within the new designer, nesting conditions is as simple as adding an action in the right branch.

‍

‍

The condition action card has also had a design update, making it more compact and intuitive to use. Conditions that are simply derived from fields outputted by previous actions can be created in the default mode. Complex expressions can also be typed, by clicking the "Edit in advanced mode" link. This allows complex evaluation conditions, like combining values of multiple elements or applying functions to a value before evaluating. A list of the possible data manipulation and comparison functions can be found in the new Workflow Definition Language page.

‍

Iterating over Lists

Another activity that was quite complex to setup and could only be done in the code view – “Foreach” loops - can now be setup quite simply by adding the corresponding action. The action card recognizes arrays that have been outputted by previous actions, making it simpler to define the list of recurring elements.

‍

Unfortunately, the “Foreach” action currently only supports a single action. But a simple workaround overcomes this restriction, since the ability to invoke a logic app within a workflow has been available for some time. This way, a “Foreach” action can call a logic app, and make the response of that logic app available to the next actions in the flow.

‍

Iterating until a condition is met

The “Do until” action, which previously was as complex to define as “Foreach”, also receives its own action card. The action allows a user to define some exit criteria for the loop based on an action output and an evaluation criteria. But as a safeguard for infinite loops, the action also allows the user to define an upper limit for the iteration as either a maximum number of iterations or a timeout.

‍

‍

Similar to “Foreach”, the “Do until” action only allows one action to be executed within the loop. And the workaround in this case is the same as the “Foreach” action - use a nested workflow to overcome this limitation.

Compared to the “Foreach” loop, the design of this action still needs improvement. The current design is counterintuitive, as the action that will drive the condition settings are positioned after the condition area. This has been raised with the product team, so hopefully some improvements will follow.

Grouping Activities with Scopes

Scopes allow multiple actions to be executed as a single group.

‍

The final status of a “Scope” action will be based on the evaluation of all actions executed within. If all actions succeed, the “Scope” status is Succeeded. If any of the actions fail, the “Scope” status is Failed.

This allows a try/catch type pattern: an action can be triggered when any one action within the “Scope” fails. At this stage, it has to be setup from the code view, by setting up the correct status in the "Run After" element of an action:

Other Improvements

Although the control flows are arguably the main change in this designer update, there are also some other changes that improve the usability of the designer and code views.

Action Cards Rename

The new designer lets the users rename each action card directly from a drop down menu in the design view - a simple change that makes the whole workflow more readable.

‍

Changes in the designer are reflected in all references to the action card. The following rules apply for action names

• An action name is limited to 80 characters.
• Only letters, numbers and the following characters are allowed - "-", "_", ".", "(", ")"
• Any space added in the designer view will be replaced by the "_" space in code view.

It is important to remember the last rule when writing functions that reference action names.

Simplified Schema

The new schema is much cleaner and straightforward to read, with the following improvements:

• Sequencing and dependencies are presented now on a "RunAfter" element.
• Flow control actions now wrap the actions executing under them, replicating the designer view.
• If/else conditions are now represented as a part of the same structure.

These changes make it easier for developers to adjust the code to include parallel executions, catch or compensation patterns.

Writing workflow definition language functions within card parameters

The inability to write function as parameters in the code view was one of the bugs in the previous schema that upset users most. This, coupled with the complexity of the structure, and bugs in some actions which would reset changes in the code view, made non-trivial coding very time consuming.

This bug has been fixed, so functions can now be used within the parameters of an action card from the design view, making it much easier to derive action parameters by processing outputs from previous actions.

‍

Tracking Properties during action execution

A new element in the action definition, trackedProperties allows developers to include custom properties to be included in the diagnostics telemetry that is captured during logic apps execution.

‍

Notice that tracked properties are restricted to the following types of values:

• Literals
• inputs or outputs of the action being tracked.

In order to capture the tracked properties, the diagnostics telemetry must be turned on. To enable this feature, follow the steps below:

• In the monitoring area in the main blade, click in the display alert:

‍

- Turn on the Diagnostics feature and provide the required information:

• A storage account where the telemetry will be written to.
• The retention policy for workflow runtime, in days. This is where the tracked properties will be captured.
• The retention policy for the metrics, in days.

‍

At this stage, there is no way to explore the tracked properties directly from the Azure Portal, but the telemetry is stored in a blob container called insights-logs-workflowruntime, within the storage account defined in the diagnostics settings. This container can be used to extract the information when required.

Extending Logic Apps with external resources

Although not a change implemented in this schema refresh, the ability to access new resources in the same region is worth a mention, as it shows how extensible the platform can be. When creating a new action, on top of the existing Managed APIs, the following options can be selected:

‍

• "Show APIs for App Services in the same region” allows developers to extend the logic app with APIs that exist in the same Azure subscription. This is similar to HTTP + Swagger, but instead of having to provide the Swagger address, the APIs are discovered automatically.
• “Show Logic Apps in the same region” allows developers to nest workflows by executing Logic Apps that contain a manual trigger.
• “Show Azure Functions in the same region” allows developers to tap into Azure Function containers. Azure Function is one of the latest additions to Azure. It is described by Microsoft as “an event driven, compute-on-demand experience that extends the existing Azure application platform with capabilities to implement code triggered by events occurring in virtually any Azure or 3rd party service as well as on-premises systems”.

Migrating existing workflows

To upgrade existing Logic Apps to the new schema, an “Update Schema” command is offered in the main blade, just like the previous upgrade.

‍

The experience is much improved - where previously a manual process was required, the “Update Schema” now offers an option to save the updated workflow.

‍

Notice that the recommendation is to save the logic app as a new version, to guarantee that the logic app works as expected first. Also, in order to guarantee that all connections are preserved after the migration, the migration process does not allow a new resource group to be created during this migration.

Outstanding Issues

In my opinion, some items that still haven’t been addressed by this update could improve the final product.

Exception Handling

Exceptions are still not explicitly dealt with. The workaround right now is to execute actions when a specific action completes execution with status of failed. This has to be handled from the code view.

Ideally, the “Scope” action would allow developers to define two sets of actions:

• The actual scope actions
• The actions to be executed when the scope fails

This would make the definition of compensation or exception handling simpler.

Better integration with Application Insights

There are some good improvements in the telemetry capture for logic apps, including a way to store tracked properties. But the functionality is still a bit limited, especially when trying to capture custom events and integrate telemetry of a whole solution using Application Insights. A workaround would be to create Azure Functions or Custom APIs and roll out your own instrumentation, but that means adding a lot of extra actions just for instrumentation, which can make the actual workflow less readable.

The ideal situation would be to have the tracked properties better aligned to Application Insights, allowing for integration with an Application Insights repository – tracked properties in this case could work like custom events..

Execution of multiple actions in a Loop

Currently only one action can be included in a “Foreach” or “Do Until” loop. Ideally those items should work as a “Scope”, allowing for multiple actions to be executed within their boundaries.

Lack of Support for Session Variables or Recurrence

Right now, the workflows don’t support variables that can change value during the workflow execution. This makes some flow controls, in particular the “Do until” loop, less flexible. A way to setup and update session variables would make “Do until” more usable.

Summary

This Logic Apps schema refresh builds on the work initiated in the previous refresh, ironing out issues highlighted in the previous update and adding new functionality to improve the overall development experience. The technology is improving at a very fast pace to reach the GA stage before the end of Q2.

There are still some outstanding issues and potential improvements, but the Microsoft product team is working very closely with the community, actively seeking feedback, which can only improve the final product.