Logic Apps Test

Azure Logic Apps is a cloud-based platform for creating and running automated workflows that integrate your apps, data, services, and systems. With this platform, you can quickly develop highly scalable integration solutions for your enterprise and business-to-business (B2B) scenarios.

In a logic app, each workflow always starts with a single trigger. A trigger fires when a condition is met, for example, when a specific event happens or when data meets specific criteria. Many triggers include scheduling capabilities that control how often your workflow runs. Following the trigger, one or more actions run operations that, for example, process, handle, or convert data that travels through the workflow, or that advance the workflow to the next step.

The failure of or slowness in a workflow run can disrupt key business processes, and may sometimes result in significant losses. For instance, say that the workflow that routes and processes customer orders across on-premises systems and cloud services, fails. Such a failure will result in many dissatisfied customers and monetary losses in terms of revenues and penalties. To avoid such an outcome, an administrator should be able to rapidly capture failures/latencies in any logic app's workflow run, determine whether any failed or slow-running trigger/action caused these abnormalities, and initiate appropriate remedial action. Besides the status and speed of triggers and actions, the throughput limits defined for the same can also impact logic app performance. To avoid the throttling of a logic app, these limits need to be constantly compared with real-time usage and recalibrated if required.

The Logic Apps test helps with all of the above!

This test monitors the workflow runs for every logic app configured on Azure. For each app, the test then reports the count of failed runs for that app, thus promptly alerting you to workflow failures. The number of triggers and actions that failed (if any) are also revealed for each app, thereby pointing you to the probable reasons for the run failures. Similarly, the test also notifies you if the workflow runs of any logic app are unusually slow. If this slowness is a result of one/more slow triggers/actions, the test reveals the same. This way, the test warns administrators of real and potential issues in their logic apps, and enables them to ensure that nothing interrupts the smooth flow of business. Also, the test promptly captures and reports throttled events, so that administrators can instantly detect throughput limit violations, and see how these limits can be redefined to curb throttling of logic apps.

Target of the Test: A Microsoft Azure Subscription

Agent deploying the test: A remote agent

Output of the test: One set of results for each Azure logic app configured for every resource group in the target Azure Subscription

Configurable parameters for the test
Parameters	Description
Test Period	How often should the test be executed.
Host	The host for which the test is to be configured.
Subscription ID	Specify the GUID which uniquely identifies the Microsoft Azure Subscription to be monitored. To know the ID that maps to the target subscription, do the following: Login to the Microsoft Azure Portal. When the portal opens, click on the Subscriptions option (as indicated by Figure 1). Figure 1 : Clicking on the Subscriptions option Figure 2 that appears next will list all the subscriptions that have been configured for the target Azure AD tenant. Locate the subscription that is being monitored in the list, and check the value displayed for that subscription in the Subscription ID column. Figure 2 : Determining the Subscription ID Copy the Subscriptiion ID in Figure 2 to the text box corresponding to the SUBSCRIPTION ID parameter in the test configuration page.
Tenant ID	Specify the Directory ID of the Azure AD tenant to which the target subscription belongs. To know how to determine the Directory ID, refer to Configuring the eG Agent to Monitor a Microsoft Azure Subscription Using Azure ARM REST API.
Client ID, Client Password, and Confirm Password	To connect to the target subscription, the eG agent requires an Access token in the form of an Application ID and the client secret value. For this purpose, you should register a new application with the Azure AD tenant. To know how to create such an application and determine its Application ID and client secret, refer to Configuring the eG Agent to Monitor a Microsoft Azure Subscription Using Azure ARM REST API. Specify the Application ID of the created Application in the Client ID text box and the client secret value in the Client Password text box. Confirm the Client Password by retyping it in the Confirm Password text box.
Proxy Host and Proxy Port	In some environments, all communication with the Azure cloud be routed through a proxy server. In such environments, you should make sure that the eG agent connects to the cloud via the proxy server and collects metrics. To enable metrics collection via a proxy, specify the IP address of the proxy server and the port at which the server listens against the Proxy Host and Proxy Port parameters. By default, these parameters are set to none, indicating that the eG agent is not configured to communicate via a proxy, by default.
Proxy Username, Proxy Password and Confirm Password	If the proxy server requires authentication, then, specify a valid proxy user name and password in the Proxy Username and Proxy Password parameters, respectively. Then, confirm the password by retyping it in the Confirm Password text box.
Detailed Diagnosis	To make diagnosis more efficient and accurate, the eG Enterprise embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option. The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled: The eG manager license should allow the detailed diagnosis capability Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.

Measures made by the test:

Measurement

Description

Measurement Unit

Interpretation

Status

Indicates the current status of this logic app.

The values reported by this measure and its numeric equivalents are mentioned in the table below:

Measure Value	Numeric Value
Enabled	1
Completed	2
Disabled	3
Deleted	4
Suspended	5
NotSpecified	6

Note:

By default, this measure reports the Measure Values listed in the table above to indicate the current status of a logic app. In the graph of this measure however, the same is represented using the numeric equivalents only.

Use the detailed diagnosis of this measure to know the location, version, access endpoint, outgoing IP addresses, and endpoint IP addresses of the logic app.

Provisioning status

Indicates the current provisioning status of this logic app.

The values reported by this measure and its numeric equivalents are mentioned in the table below:

Measure Value	Numeric Value
Succeeded	1
Updating	2
Error	3
Unknown	0

Note:

By default, this measure reports the Measure Values listed in the table above to indicate the provisioning status of a logic app. In the graph of this measure however, the same is represented using the numeric equivalents only.

Runs started

Indicates the number of runs started for this logic app.

Number

Runs completed

Indicates the number of runs that have been completed for this logic app.

Number

Runs succeeded

Indicates the number of runs for this logic app that have been successful.

Number

Runs failed

Indicates the number of workflow runs for this logic app that failed.

Number

Ideally, the value of this measure should be 0. If it is not, then look up the values of the Actions failed and Triggers failed measures to understand if any actions/triggers failed at around the same time as the run failure. If so, you can attribute the run failure to the action/trigger failure.

Runs cancelled

Indicates the number of runs of this app that were cancelled.

Number

Run latency

Indicates the time interval between stimulation and response of this logic app.

Secs

A high value for this measure implies that the workflow run is slow. In this case, check the value of the Action latency and Trigger latency measures to determine whether one/more latent actions/triggers contributed to the workflow's slowness.

Run success latency

Indicates the average time taken by the successful workflow runs of this logic app.

Secs

Ideally, the value of this measure should be low.

Run throttled events

Indicates the number of throttling events for this logic app.

Number

The Azure Logic Apps service has its own throughput limits. So, if your logic app exceeds these limits, your logic app resource gets throttled, not just a specific instance or run.

Ideally therefore, the value of this measure should be 0. If it is not, then you may want to consider these options to eliminate throttling:

Limit the number of logic app instances that can run at the same time: By default, if your logic app's trigger condition is met more than once at the same time, multiple trigger instances for your logic app run concurrently or in parallel. This behavior means that each trigger instance fires before the preceding workflow instance finishes running.

Although the default number of trigger instances that can concurrently run is unlimited, you can limit this number by turning on the trigger's concurrency setting, and if necessary, select a limit other than the default value.
Enable high throughput mode: A logic app has a default limit for the number of actions that can run over a 5-minute rolling interval. To raise this limit to the maximum number of actions, turn on high throughput mode on your logic app.
Disable array debatching ("split on") behavior in triggers: If a trigger returns an array for the remaining workflow actions to process, the trigger's Split On setting splits up the array items and starts a workflow instance for each array item, effectively triggering multiple concurrent runs up to the Split On limit. To control throttling, turn off the Split On behavior and have your logic app process the entire array with a single call, rather than handle a single item per call.
Refactor actions into smaller logic apps: As mentioned earlier, a logic app is limited to a default number of actions that can run over a 5-minute period. Although you can increase this limit by enabling high throughput mode, you might also consider whether you want to break down your logic app's actions into smaller logic apps so that the number of actions that run in each logic app remains under the limit. That way, you reduce the burden on a single logic app resource and distribute the load across multiple logic apps. This solution works better for actions that handle large data sets or spin up so many concurrently running actions, loop iterations, or actions inside each loop iteration that they exceed action execution limit.

Run failure percentage

Indicates the percentage of runs for this logic app that failed.

Percent

A value close to 100% is a cause for concern as it implies that almost all the runs for the app failed.

Actions started

Indicates the number of actions started by this logic app.

Number

Actions completed

Indicates the number of actions completed by this logic app.

Number

Actions succeeded

Indicates the number of actions of this logic app that were successful.

Number

Actions failed

Indicates the number of actions of this logic app that failed.

Number

The value 0 is desired for this measure.

Actions skipped

Indicates the number of actions that were skipped by this logic app.

Number

Action latency

Indicates the time interval between the stimulation of actions by this logic app and the response.

Secs

Latent actions can slowdown workflow runs. Ideally therefore, the value of this measure should be very low.

Action success latency

Indicates the time interval between the stimulation of successful actions by this logic app and the response.

Secs

Actions, though successful, should not take too long to complete. This is why, a high value of this measure is often a cause for concern.

Action throttled events

Indicates the number of throttled events for the actions of this logic app.

Number

A high value for this measure means that actions exceed their throughput limit often. In this case, consider the following:

Enable high throughput mode: A logic app has a default limit for the number of actions that can run over a 5-minute rolling interval. To raise this limit to the maximum number of actions, turn on high throughput mode on your logic app.
Reduce the number of concurrent outbound calls: You can reduce the number of concurrent requests or reduce the duration as necessary.

Triggers started

Indicates the number of triggers started by this logic app.

Number

Triggers completed

Indicates the number of triggers completed by this logic app.

Number

Triggers succeeded

Indicates the number of triggers that succeeded for this logic app.

Number

Triggers failed

Indicates the number of triggers that this logic app failed to execute.

Number

The value 0 is desired for this measure.

Triggers skipped

Indicates the number of triggers skipped by this logic app.

Number

If a logic app skips a trigger, then it means that it is unable to find any items that met the condition specified in the trigger.

Triggers fired

Indicates the number of triggers fired by this logic app.

Number

Trigger latency

Indicates the time that elapsed between when this logic app started and ended triggers.

Secs

A low value is desired for this measure. A consistent increase in this value is a sign of bottlenecks in trigger execution. This in turn will adversely impact the pace of workflow runs.

When this measure reports abnormally high values for any logic app, you may want to compare the value of the Trigger fire latency measure with that of the Trigger success latency measure for that app. This will reveal where the delay originated - when firing triggers? or when executing them?

Trigger fire latency

Indicates the time taken by this logic app to fire triggers.

Secs

A consistently high value for this measure could indicate undue delays in firing triggers.

Trigger success latency

Indicates the latency workflow triggers that this logic app successfully executed.

Secs

A consistently high value for this measure could indicate significant delays in execution and successful completion of triggers.

Trigger throttled events

Indicates the number of throttled events for the triggers fired by this logic app.

Number

A high value for this measure means that triggers often exceeded their throughput limit. In such a situation, you may want to consider altering the defualt throughput limits.

Billable action executions

Indicates the number of actions of this app that are billable.

Number

In multi-tenant Azure Logic Apps, a logic app and its workflow follow the Consumption plan for pricing and billing. The Consumption model includes an initial number of free built-in triggers and operations, per Azure subscription, that a workflow can run. Above this number, metering applies to each execution, and billing follows the Actions pricing for the Consumption plan.

In single-tenant Azure Logic Apps, a logic app and its workflows follow the Standard plan for pricing and billing. The Standard model includes an unlimited number of free built-in operations (triggers and actions) that your workflow can run. Beyond that limit, the Standard model meters and bills an operation based on each call, whether or not the overall workflow successfully runs, finishes, or is even instantiated.

Billable trigger executions

Indicates the number of triggers of this app that are billable.

Number

Total billable executions

Indicates the total number of billable executions for this logic app.

Number