Build governed asynchronous APIs with Azure API Management and Azure Service Bus
Many applications use Azure Service Bus to decouple services, handle traffic spikes, and process workloads asynchronously. However, securely exposing messaging capabilities to applications, partners, and internal teams can require custom middleware or messaging-specific client implementations. Today, we’re announcing the general availability of native Azure Service Bus integration in Azure API Management. With the send-service-bus-message policy, developers can publish messages directly from an Azure API Management gateway to an Azure Service Bus queue or topic. This provides a secure and governed HTTP interface for Service Bus workloads—without requiring teams to build and operate a separate adapter service. Connect APIs directly to Azure Service Bus Azure API Management can act as the governed entry point for applications that submit work to Azure Service Bus. A client sends a standard HTTP request to API Management. The gateway can authenticate and authorize the caller, validate or transform the request, and apply policies such as rate limits and quotas before publishing the message to a Service Bus queue or topic. Once the message is accepted, API Management can immediately respond to the caller while downstream services process the message asynchronously. Alternatively, message publication can be added to an existing API flow while the request continues to its primary backend. This integration brings together API governance in Azure API Management and reliable asynchronous messaging in Azure Service Bus—without adding another intermediary service. Greater control over Service Bus messages As part of general availability, we’re introducing additional controls for building production messaging workflows. 1. Control how messages are processed Developers can configure the following Service Bus message properties directly in the policy: Message IDs to correlate messages and support duplicate-detection or idempotent processing patterns. Session IDs to group related messages for ordered or stateful processing. Time-to-live to prevent messages from being processed after they are no longer relevant. These values can be generated dynamically using API Management policy expressions, allowing them to reflect request IDs, customer identifiers, transactions, or other application context. 2. Capture the send result The response-variable-name attribute captures information about the Service Bus send operation in an API Management context variable. Subsequent policies can use the result to add correlation information to an API response, emit telemetry, record an operational event, or apply conditional logic when a message cannot be sent. 3. Choose how failures affect the API Different messaging scenarios require different failure behavior. When publishing the message is the primary purpose of an API, a send failure can stop policy execution and invoke the API Management error-handling path. When publishing is secondary—such as sending an audit event or initiating optional downstream processing—the ignore-error option can allow the primary API request to continue. Information about the send operation remains available through the response variable for logging or subsequent policy logic. 4. Secure access with managed identity API Management authenticates to Azure Service Bus using a Microsoft Entra managed identity. Customers can use the system-assigned identity of the API Management service or specify a user-assigned managed identity. The selected identity is granted the Azure Service Bus Data Sender role for the appropriate namespace, queue, or topic. This removes the need to store Service Bus connection strings or shared access keys in API policies and makes it easier to apply least-privilege access using Azure role-based access control. Send a message with an API Management policy The following example sends the incoming request body to an orders queue. It assigns a message ID and expiration time, captures the result of the send operation, and treats successful publication as a required part of the API request. <send-service-bus-message queue-name="orders" namespace="contoso-messaging.servicebus.windows.net" message-id="@(context.RequestId.ToString())" time-to-live="00:10:00" response-variable-name="serviceBusResult" ignore-error="false"> <payload> @(context.Request.Body.As<string>(preserveContent: true)) </payload> </send-service-bus-message> A session ID can also be added when related messages need to be grouped for ordered or stateful processing. For a fully asynchronous API, the policy can be followed by return-response so that API Management acknowledges the request immediately after sending the message. For an existing API, the request can continue to its configured backend after the message is published. Common integration scenarios Create asynchronous APIs: Accept an order, document, or processing request through an HTTP API, publish it to a queue, and return immediately while downstream services complete the work. Govern partner integrations: Provide partners with a managed API contract instead of exposing the underlying Service Bus namespace. API Management can authenticate callers, validate requests, and apply quotas before publishing messages. Publish business events: Publish events to a Service Bus topic so multiple subscriptions and downstream services can process them independently. Handle bursts of incoming traffic: Use Service Bus to buffer messages when incoming API traffic temporarily exceeds the rate at which downstream services can process requests. Add events to existing API operations: Publish audit, notification, analytics, or workflow events while allowing the primary API request to continue to its configured backend. Preserve workflow affinity: Use Service Bus sessions to group related messages for ordered or stateful processing based on a customer, transaction, order, or workflow identifier. Get started To send messages from Azure API Management to Azure Service Bus: Create or select an Azure Service Bus queue or topic. Enable a system-assigned or user-assigned managed identity on the API Management service. Assign the identity the Azure Service Bus Data Sender role. Add the send-service-bus-message policy to an API operation. Configure the message payload, processing properties, output variable, and failure behavior. With native Azure Service Bus integration, Azure API Management provides a secure and governed way to connect HTTP APIs with asynchronous messaging workloads—without requiring additional middleware. Learn more Send Service Bus message policy reference Send messages to Azure Service Bus from Azure API Management Azure API Management June 2026 release notes Azure Service Bus documentation
Dynamic Connection Properties in Azure Logic Apps Standard
Switching Built-in Connections at Runtime The Problem Imagine your organization has a single Logic App workflow used by multiple teams. Each team has its own SFTP server, database, or service bus namespace. Traditionally, you'd need separate workflows or hardcode a single connection — neither scales well. The Solution Logic Apps Standard supports dynamic connection names for built-in (service provider) connectors. Instead of hardcoding a connection name, you can use any workflow expression — trigger inputs, previous action outputs, parameters, or conditional logic — to determine which connection to use at runtime. No designer support is available at this time — this works today via Code View. How It Works Define multiple connections in connections.json — one per team/environment/tenant Resolve the connection name dynamically using any expression Reference that expression in the connectionName field of your service provider action The runtime evaluates the expression and resolves the connection from connections.json at execution time. The Key Pattern "serviceProviderConfiguration": { "connectionName": "@<expression-that-resolves-to-connection-name>", "operationId": "listFolder", "serviceProviderId": "/serviceProviders/Sftp" } Instead of hardcoding "connectionName": "sftp", you provide an expression that evaluates to a connection key defined in connections.json. What You Can Use as the Dynamic Value Source Example Trigger body @triggerBody()?['connectionName'] Trigger header @triggerOutputs()['headers']['X-Connection-Name'] Conditional expression if(equals(triggerBody()?['team'], 'teamA'), 'sftpTeamA', 'sftpTeamB') Previous action output @outputs('Resolve_Connection') Workflow parameter @parameters('defaultConnection') Step-by-Step Example: Dynamic SFTP Connection 1. Define Connections in connections.json { "serviceProviderConnections": { "sftpTeamA": { "parameterValues": { "sshHostAddress": "@appsetting('SftpTeamA_HostAddress')", "username": "@appsetting('SftpTeamA_Username')", "password": "@appsetting('SftpTeamA_Password')", "portNumber": "@appsetting('SftpTeamA_PortNumber')", "rootDirectory": "@appsetting('SftpTeamA_RootDirectory')" }, "serviceProvider": { "id": "/serviceProviders/Sftp" }, "displayName": "SFTP - Team A" }, "sftpTeamB": { "parameterValues": { "sshHostAddress": "@appsetting('SftpTeamB_HostAddress')", "username": "@appsetting('SftpTeamB_Username')", "password": "@appsetting('SftpTeamB_Password')", "portNumber": "@appsetting('SftpTeamB_PortNumber')", "rootDirectory": "@appsetting('SftpTeamB_RootDirectory')" }, "serviceProvider": { "id": "/serviceProviders/Sftp" }, "displayName": "SFTP - Team B" } } } 2. Add App Settings In your Logic App's Configuration → Application settings, add values for each connection: Setting Example Value SftpTeamA_HostAddress storageacctA.blob.core.windows.net SftpTeamA_Username storageacctA.localuserA SftpTeamA_Password (generated password) SftpTeamA_PortNumber 22 SftpTeamA_RootDirectory /uploads SftpTeamB_HostAddress storageacctB.blob.core.windows.net SftpTeamB_Username storageacctB.localuserB SftpTeamB_Password (generated password) SftpTeamB_PortNumber 22 SftpTeamB_RootDirectory /uploads 3. Create the Workflow (Code View) { "definition": { "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#", "actions": { "List_files_in_folder": { "type": "ServiceProvider", "inputs": { "serviceProviderConfiguration": { "connectionName": "@if(equals(triggerBody()?['team'], 'teamA'), 'sftpTeamA', 'sftpTeamB')", "operationId": "listFolder", "serviceProviderId": "/serviceProviders/Sftp" }, "parameters": { "path": "@triggerBody()?['folderPath']" } }, "runAfter": {} }, "Response": { "type": "Response", "kind": "Http", "inputs": { "statusCode": 200, "body": "@body('List_files_in_folder')" }, "runAfter": { "List_files_in_folder": ["Succeeded"] } } }, "triggers": { "When_a_HTTP_request_is_received": { "type": "Request", "kind": "Http", "inputs": { "schema": { "type": "object", "properties": { "team": { "type": "string" }, "folderPath": { "type": "string" } } } } } }, "contentVersion": "1.0.0.0" }, "kind": "Stateful" } 4. Test It Send a POST request to the workflow trigger URL: { "team": "teamA", "folderPath": "/uploads" } Change "team": "teamB" to route to the other SFTP server at runtime. Multi-Step Resolution Example For more complex logic — lookups, mappings, or multi-condition routing — resolve the connection in a prior action and reference its output: { "Resolve_Connection": { "type": "Compose", "inputs": "@if(contains(triggerBody()?['region'], 'eu'), 'sftpEurope', if(contains(triggerBody()?['region'], 'us'), 'sftpAmerica', 'sftpDefault'))", "runAfter": {} }, "Upload_File": { "type": "ServiceProvider", "inputs": { "serviceProviderConfiguration": { "connectionName": "@outputs('Resolve_Connection')", "operationId": "createFile", "serviceProviderId": "/serviceProviders/Sftp" }, "parameters": { "path": "/incoming/data.csv", "content": "@triggerBody()?['fileContent']" } }, "runAfter": { "Resolve_Connection": ["Succeeded"] } } } Applicable Connectors This pattern works with all built-in service provider connectors (type: "ServiceProvider"), including: SFTP SQL Service Bus Event Hubs Azure Blob Storage (built-in) SMTP Azure Automation And any other built-in connector Limitations Code View only — The designer does not render or edit dynamic connection names visually. Built-in connectors only — Managed API connections (type: "ApiConnection") do not support this pattern. Connection must exist — The resolved name must match a key already defined in connections.json. Connections cannot be created on-the-fly. Case-sensitive — The expression output must exactly match the connection key in connections.json. Tips Use @appsetting() references in connections.json to keep credentials out of source control Store passwords in Azure Key Vault referenced via app settings Use meaningful connection names (e.g., sftpTeamA, sqlProd, serviceBusDev) You can scale to any number of connections — just add entries to connections.json and corresponding app settings Inline expressions like @if(...) work directly in connectionName — you don't always need a separate actionLogic App Standard - When High Memory / CPU usage strikes and what to do
Introduction Monitoring your applications is essential, as it ensures that you know what's happening and you are not caught by surprise when something happens. One possible event is the performance of your application starting to decrease and processing becomes slower than usual. This may happen due to various reasons, and in this blog post, we will be discussing the High Memory and CPU usage and why it affects your Logic App. We will also observe some possibilities that we've seen that have been deemed as the root cause for some customers. How High Memory and high CPU affects the processing When the instructions and information are loaded into Memory, they will occupy a space that cannot be used for other sets of instructions. The more memory is occupied, the more the Operative System will need to "think" to find the correct set of instructions and retrieve/write the information. So if the OS needs more time to find or write your instructions, the less time it will spend actually doing the processing. Same thing for the CPU. If the CPU load is higher, it will slow down everything, because the available workers are not able to "think" multiple items at the same time. This translates into the Logic App processing, by the overall slowness of performance. When the CPU or Memory reach a certain threshold, we start to see the run durations going up and internal retries increasing as well. This is because the runtime workers are busy and the tasks have timeout limits. For example, let's think of a simple run with a Read Blob built-in connector action, where the Blob is very large (let's say 400MB). The flow goes: Request Trigger -> Read blob -> send email The trigger has a very short duration and doesn't carry much overhead, because we're not loading much data on it. The Read Blob though, will try to read the payload into Memory (because we're using a Built-in Connector, and these load all the information into Memory). Built-in connector overview - Azure Logic Apps | Microsoft Learn So, not considering background processes, Kudu and maintenance jobs, we've loaded 400MB into memory. Using a WS1 plan, we have 3.5GB available. By just having a blank Logic App, you will see some memory occupied, although it may vary. So, if we think it takes 500MB for the base runtime and some processes, it leaves us with 3GB available. If we load 4 files at the same time, we will be using ~1.8GB (files + base usage). Already using about 50% of the memory. And this is just for one workflow and 4 runs. Of course the memory is released after the run completes, but if you think on a broader scale, with multiple runs and multiple actions at the same time, you see how easy it is to reach the thresholds. When we see memory over ~70%, the background tasks may behave in unexpected ways, so it's essential to have a clear idea on how your Logic App is working and what data you're loading into it. Same thing for CPU. The more you load into it, the slower it gets. You may have low memory usage, but if you're doing highly complex tasks such as XML transformations or some other built-in data transforms, your CPU will be heavily used. And the bigger the file and the more complex the transformation, the more CPU will be used. How to check memory/CPU Correctly monitoring your resources usage is vital and can avoid serious impact. To help your Standard logic app workflows run with high availability and performance, the Logic App Product Group has created the Health Check feature. This feature is still in Preview, but it's already a very big assistance in monitoring. You can read more about it, in the following article, written by our PG members, Rohitha Hewawasam and Kent Weare: Monitoring Azure Logic Apps (Standard) Health using Metrics And also the official documentation for this feature: Monitor Standard workflows with Health Check - Azure Logic Apps | Microsoft Learn The Metrics can also assist in providing a better view on the current usage. Logic App Metrics don't drill down on CPU usage, because those metrics are not available at App level, but rather at App Service Plan level. You will be able to see the working memory set and Workflow related metrics. Example metric: Private Bytes (AVG) - Logic App metrics On the AppService Plan overview, you will be able to see some charts with these metrics. It's an entry point to understand what is currently going on with your ASP and the current health status. Example: ASP Dashboard In the Metrics tab, you are able to create your own charts with a much greater granularity and also save as Dashboards. You're also able to create Alerts on these metrics, which greatly increases your ability to effectively monitor and act on abnormal situations, such as High Memory usage for prolonged periods of time. Example: Memory Percentage (Max) - ASP Metrics Currently there are multiple solutions provided to analyze your Logic App behavior and metrics, such as Dashboards and Azure Monitor Logs. I highly recommend reading these two articles from our PG that discuss these topics and explain and exemplify this: Logic Apps Standard Monitoring Dashboards | Microsoft Community Hub Monitoring Azure Logic Apps (Standard) with Azure Monitor Logs How to mitigate - a few possibilities Platform settings on 32 bits If your Logic App was created long back, it may be running on an old setting. Early Logic Apps were created with 32 bits, which severely limited the Memory usage scalability, as this architecture only allows a maximum of 3GB of usage. This comes from the Operative System limitations and memory allocation architecture. After some time, the standard was to create Logic Apps in 64 bits, which allowed the Logic App to scale and fully use the maximum allowed memory in all ASP tiers (up to 14GB in WS3). This can be checked and updated in the Configuration tab, under Platform settings. Orphaned runs It is possible that some runs do not finish due to various possibilities. Either they are long running or have failed due to unexpected exceptions, runs that linger in the system will cause an increase in memory usage, because the information will not be unloaded from Memory. When the runs become orphaned, they may not be spotted but they will remain "eating up" resources. The easiest way to find these runs, is to check the workflows and under the "Running" status, check which ones are still running well after the expected termination. You can filter the Run History by Status and use this to find all the runs that are still in "Running". In my example, I had multiple runs that had started hours before, but were not yet finished. Although this is a good example, it requires you to check each workflow manually. You can also do this by using Log Analytics and execute a query to return all the Runs that are not yet finished. You need to activate the Diagnostic Settings, as mentioned in this blog post: Monitoring Azure Logic Apps (Standard) with Azure Monitor Logs To make your troubleshooting easier, I've created a query that does this for you. It will check only for the Runs and return those that do not have a matching Completed status. The OperationName field will register the Start, Dispatch and Completed status. By eliminating the Dispatched status, we're left with Start and Completed. Therefore, this query should return all the RunIDs that have a Start but not a matching Completed status, as it groups them by counting the RunIDs. LogicAppWorkflowRuntime | where OperationName contains "WorkflowRun" and OperationName != 'WorkflowRunDispatched' | project RunId, WorkflowName, TimeGenerated,OperationName, Status, StartTime,EndTime | summarize Runs = count() by RunId, WorkflowName, StartTime | where Runs == 1 | project RunId, WorkflowName, StartTime Large payloads As previously discussed, large payloads can create a big overload and increase greatly the memory usage. This applies not only to the Built-in Connectors, but also to the Managed connectors, as the information stills needs to be processed. Although the data is not loaded into the ASP memory when it comes to Managed connectors, there is a lot of data flowing and being processed in CPU time. A Logic App is capable of processing a big amount of data, but when you combine large payloads, a very large number of concurrent runs, along with large number of actions and Incoming/Outgoing requests, you get a mixture that if left unattended and continues to scale up, will cause performance issues over time. Usage of built-in connectors The Built-in Connectors (or In App) are natively run in the Azure Logic Apps runtime. Due to this, the performance, capabilities and pricing are better, in most cases. Because they are running under the Logic App Runtime, all the data will be loaded in-memory. This requires you to do a good planning of your architecture and forecast for high levels of usage and heavy payload. As previously shown, using Built-in connectors that handle very large payloads, can cause unexpected errors such as Out of Memory exceptions. The connector will try to load the payload into memory, but if starts to load and the memory is no longer available, it can crash the worker and return an Out Of Memory exception. This will be visible in the Runtime logs and it may also lead to the run becoming orphaned, as it get stuck in a state that is not recoverable. Internally, the Runtime will attempt to gracefully retry these failed tasks, and it will retry multiple times. But there is always the possibility that the state is not recoverable and thus the worker crashes. This makes it also necessary to closely monitor and plan for high usage scenarios, in order to properly scale Up and Out your App Service Plans. Learnings Monitoring can be achieved as well through the Log Stream, which requires you to configure a Log Analytics connection, but can provide a great deal of insight of what the Runtime is doing. It can give you Verbose level or simply Warning/Error levels. It does provide a lot of information and can be a bit tricky to read, but the level of detail it provides, can be a huge assistance in troubleshooting from your side and from the Support side. For this, you can navigate to your Log Stream tab, enable it, change to "Filesystem Logs" and enjoy the show. If an Out of Memory exception is caught, it will show up in red letters (as other exceptions show), and will be something similar to this: Job dispatching error: operationName='JobDispatchingWorker.Run', jobPartition='', jobId='', message='The job dispatching worker finished with unexpected exception.', exception='System.OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown. at System.Threading.Thread.StartCore() at System.Threading.Thread.Start(Boolean captureContext) at System.Threading.Thread.Start() No PROD Logic App should be left without monitoring and alerting. Being a critical system or not, you should always plan not only for disaster scenarios but also for higher than usual volumes, because nothing is static and there's always the possibility that the system that today has a low usage, will be scaled and will be used in some way that it was not intended to. For this, implementing the monitoring on the resources metrics is very valuable and can detect issues before they get overwhelming and cause a show stopper scenario. You can use the Metrics from the Logic App that are provided out of the box, or the metrics in the ASP. These last metrics will cover a wider range of signals, as it's not as specific as the ones from the Logic App. You can also create custom Alerts from the Metrics and thus increasing your coverage on distress signals from the Logic App processing. Leaving your Logic App without proper monitoring will likely catch you, your system administrators and your business by surprise when the processing falls out of the standard parameters and chaos starts to arise. There is one key insight that must be applied whenever possible: expect the best, prepare for the worst. Always plan ahead, monitor the current status and think proactively and not just reactively. Disclaimer: The base memory and CPU values are specific for your app, and it can vary based on number of apps in App Service Plan, the number of instances you have as Always Running, etc, and number of workflows in the app, and how complex these workflows are and what internal jobs needs to be provisioned.
