Microsoft recently announced a preview feature for its API Management (APIM) service that allows developers to send messages directly to Azure Service Bus using a built-in policy. The company states that the feature simplifies how organizations connect their API layer to event-driven, asynchronous systems.
Earlier, developers could create a custom solution in API Management to send messages to the Azure Service Bus. Yet with the new send-service-bus-message policy, they can forward payloads from API calls directly into Service Bus queues or topics. Brandon Verzuu, a business architect at ApplyThing, wrote in a Medium blog post:
Previously, if you wanted an HTTP-based API call in APIM to trigger an asynchronous backend process, you typically used a Logic App or an Azure Function as a channel adapter. This component’s sole job was to take the message, perhaps apply some transformation, and publish it to a Service Bus.
Now, under the new policy, when a client sends a standard HTTP request to an API endpoint in API Management, the policy sends the request as a message to Service Bus. Subsequently, downstream consumers such as Logic Apps, Azure Functions, or microservices process those messages asynchronously.
(Source: Microsoft Learn)
Luke Murray, a Microsoft MVP, describes in a blog post how a send-service-bus-message policy could look:
<policies>
<!-- Throttle, authorize, validate, cache, or transform the requests -->
<inbound>
<send-service-bus-message queue-name="your-queue" namespace="your-namespace.servicebus.windows.net">
<message-properties>
<message-property name="ApiName">@(context.Api?.Name)</message-property>
<message-property name="Operation">@(context.Operation?.Name)</message-property>
<message-property name="CallerIp">@(context.Request.IpAddress)</message-property>
<message-property name="ContentType">@(context.Request.Headers.GetValueOrDefault("Content-Type","application/json"))</message-property>
<message-property name="TimestampUtc">@(DateTime.UtcNow.ToString("o"))</message-property>
</message-properties>
<payload>@(context.Request.Body.As<string>(preserveContent: true))</payload>
</send-service-bus-message>
<return-response>
<set-status code="201" reason="Message Created" />
</return-response>
</inbound>
<!-- Control if and how the requests are forwarded to services -->
<backend />
<!-- Customize the responses -->
<outbound />
<!-- Handle exceptions and customize error responses -->
<on-error>
<base />
</on-error>
</policies>
In a Techcommunity blog post, the company outlines several use cases when leveraging the new policy, ranging from event notification by triggering internal workflows across multiple applications to partner integrations by offering REST-based endpoints for external systems while maintaining policy-based control.
Furthermore, the feature in APIM leverages managed identities for secure communication between API Management and Service Bus. Additionally, developers can apply enterprise-grade controls, such as rate limits, quotas, and authorization, through APIM policies and gain API-level logging and tracing for each message sent.
Stefan van der Loop, a Cloud Solutions Architect, commented in a LinkedIn post:
Oh wauw! I’d almost say Finally! this makes integration/decoupling so much easier and more robust. Now what’s left is moving towards a 99,99% SLA for both services 😉 Currently At 99,8% compound SLA uptime it still feels a bit light for production scenario’s. Then again, queues are cheap alternatives as fail-overs..
More details on Azure API Management is available on the documentation pages.
