This blog will brief on Azure Logic App Triggers. Let us see a short introduction of what a Logic App is and how does it work before getting deep into Logic App Triggers.
Azure Logic App
Azure Logic App is a cloud service that helps to schedule, automate, and orchestrate tasks when there is a need to integrate apps, data, systems, and services across enterprises or organizations. Logic Apps simplifies how to design and build scalable solutions for app integration, data integration, enterprise application integration, etc whether in the cloud, on-premises, or both.
How does Logic App work?
A Logic App’s workflow starts with a trigger, which fires when a specific event happens, or when newly available data meets a specific criterion. Various triggers provided by the connectors in Logic Apps include basic scheduling capabilities to regulate the workloads and for more complex scheduling or advanced recurrences, the recurrence trigger can be used as the first step in any workflow.
Each time the trigger fires, the Logic App engine creates a Logic App instance that runs the actions in the workflow. These actions can also include data conversions and flow controls, such as conditional statements, switch statements, loops, and branching.
As we have seen what a Logic App is and how it works. Let’s get deeper into the Logic App Triggers.
Triggers
Every workflow includes a trigger. Connectors provide triggers that fire events or new data when specified conditions are met. Triggers are generally of two types:
- Polling Trigger – It checks a service’s endpoint at regular intervals
- Push Trigger – It creates a subscription to an endpoint and provides a call-back URL so the endpoint can notify the trigger when the specified event happens, or data is available. Push trigger waits for the endpoint’s response to getting fired
The schema of the Azure Logic App Trigger looks like the one below:
"trigger-name": {
"type": "trigger-type",
"inputs": { "trigger-inputs" },
"recurrence": {
"frequency": "time-uni",
"interval": number-of-time-units
},
"conditions": [ "array-with-conditions" ],
"runtimeConfiguration": { "runtime-config-options" },
"splitOn": "splitOn-expression",
"operationOptions": "operation-option"
}
Note: Some of these tags are optional.
The required parameters for the trigger are:
- <trigger-name> – Name of the trigger
- <trigger-type> – Type of the trigger namely “Http” or “ApiConnection”
- <trigger-inputs> – It is a JSON object representing the inputs that define the trigger’s behavior
- <time-unit> – Unit of time which describes how often the trigger fires: Second, Minute, Hour, Day, Week, Month
- <number-of-time-units> – It is the value that specifies how often the trigger fires based on the set frequency. The minimum and maximum intervals to be set are
Month: 1-16 months
Day: 1-500 days
Hour: 1-12,000 hours
Minute: 1-72,000 minutes
Second: 1-9,999,999 seconds
Types of Triggers
Each trigger has its own interface and inputs which defines its behavior.
Built-In Triggers
HTTP
This trigger sends a request to the specified HTTP or HTTPS endpoint based on the specified recurrence schedule. This endpoint must conform to a specific trigger contract either by using a “202” asynchronous pattern or by returning an array. The trigger then checks the response to determine whether the workflow runs.
HTTPWebhook
This trigger makes a logic app callable by creating an endpoint that can register a subscription by calling the specified endpoint URL. When this trigger is created in a workflow, an outgoing request makes the call to register the subscription. This way, the trigger can start listening for events. When an operation makes this trigger invalid, an outgoing request automatically makes the call to cancel the subscription.
Recurrence
This trigger runs based on the specified recurrence schedule. Future date and time can be set for firing this trigger. Based on the frequency, you can also specify times and days for running your workflow.
Request
This trigger makes a logic app callable by creating an endpoint that can accept incoming requests. A JSON schema is provided for this trigger which describes and validates the payload or inputs that the trigger receives from the incoming request. The schema also makes trigger properties easier to reference from later actions in the workflow. listCallbackUrl is used to call this trigger. This trigger is also known as a “manual” trigger.
Managed API Triggers
ApiConnection
This trigger checks or polls an endpoint by using Microsoft-managed APIs. The parameters for this trigger differ based on the endpoint. Many sections in this trigger definition are optional. The trigger’s behavior depends on whether sections are included.
ApiConnectionWebhook
This trigger sends a subscription request to an endpoint by using a Microsoft-managed APIs. It provides a call-back URL to where the endpoint can send a response and waits for the endpoint to respond.
Trigger Conditions
Triggers can have an array that contains one or more expressions for conditions that determine whether the workflow should run. Conditions can be modified in the code view editor of the Logic App.
Consider the trigger given below which fires only after getting “200” as a response:
"Recurrence": {
"type": "Recurrence",
"recurrence": {
"frequency": "Hour",
"interval": 1
},
"conditions": [ {
"expression": "@equals(triggers().code, 200)"
} ]
}
This expression can be changed as below, to fire only when “500” is received as a response. When an expression references a trigger’s status code, the trigger’s default behavior is replaced.
"conditions": [ {
"expression": "@equals(triggers().code, 500)"
} ]
If the trigger needs to be fired for more than one status code, it should be specified as a comma-separated value as below.
"conditions": [ {
"expression": @or(equals(triggers().code, 200), equals(triggers().code, 201))"
} ]
SplitOn cannot be used with a synchronous response pattern. Workflows using SplitOn and a response action will run asynchronously and send a 202 response.
When trigger concurrency is enabled, the SplitOn limit is significantly reduced. If the number of items exceeds this limit, the SplitOn capability is disabled. When concurrency is enabled, a long-running Logic App instance might cause new Logic App instances to enter a waiting state. This state prevents Azure Logic Apps from creating new instances and happens even when the number of concurrent runs is less than the specified maximum number of concurrent runs.
Consider the API response below:
{
"OrderId": "Id_951357456",
"Items": [
{
"productId": “Pid_357159”,
"price": "250"
},
{
" productId ": “Pid_368745”,
" price": "500"
}
]
}
To get the array of items, trigger can be created as below:
"Debatch": {
"type": "Http",
"recurrence": {
"frequency": "Second",
"interval": 1
},
"splitOn": "@triggerBody()?.Items"
}
Note that the SplitOn property cannot be used to get the properties outside the array. In the above example, it will not be able to get the property ‘OrderId’. The SplitOn property has a limit of 100,000 without trigger concurrency and 100 with trigger concurrency.
Trigger Concurrency
Limit for Logic App trigger concurrency:
- Unlimited when the concurrency control is turned off
- 25 is the default limit when the concurrency control is turned on, which can’t be undone after you turn on the control. The default value can be changed between 1 and 50 inclusively
These limits are the maximum number of Logic App instances that can run in parallel. When concurrency is enabled, the SplitOn limit is reduced to 100 items for de–batching arrays.
Conclusion
In a nutshell, Azure Logic Apps service is a cloud service. All that needs to be done is to define the triggers and actions that the workflow performs. It is used in scenarios where there is a need to coordinate multiple actions across multiple systems. Each trigger serves its own purpose. Appropriate triggers must be used based on the requirement to yield desired performance and result.
Strengthen your Azure Logic Apps monitoring and get powerful toolsets, actionable insights to troubleshoot issues with the help of Turbo360.
