Announcing the General Availability of the RabbitMQ Connector
We are pleased to announce the general availability of the RabbitMQ Connector in Logic Apps (Standard) which allows you to both send and receive messages between Logic Apps and RabbitMQ. RabbitMQ is a robust, open-source message broker widely used for building reliable, scalable, and flexible messaging solutions. It is trusted across industries such as financial services, e-commerce, IoT, telecommunications, and cloud-native microservices. Our RabbitMQ connector allows messaging scenarios on-premises using Logic Apps hybrid. Benefits of Using RabbitMQ Reliability: RabbitMQ ensures message delivery with strong durability and acknowledgment mechanisms. Flexible Routing: Supports complex routing logic via exchanges (direct, topic, fanout, headers). Clustering & High Availability: Offers clustering and mirrored queues for fault tolerance. Management & Monitoring: Provides a user-friendly management UI and extensive monitoring capabilities. Extensibility: Supports plugins for authentication, federation, and more. Our current connector offering supports both triggers (receive) and sending (publish) within Logic Apps. Receiving Messages To enable a trigger, we need to search for the RabbitMQ connector within our designer. We will discover an operation called When the queue has messages from RabbitMQ show up as a built-in connector. We also have a peek lock operation for non-destructive reads. Search for Trigger and click on this operation to add the trigger to your design surface. Configure the trigger by providing the Queue Name. You can use the payload from your trigger in downstream actions. For example, you might place the payload within a Compose action for further processing. Publishing Messages To send a message, search for the RabbitMQ connector in your design experience. You’ll find an operation called Send a message. Add this operation to your design surface and Provide the following: Queue Name Message Body Exchange Name (if routing is required) Routing Key Once configured, you can run messages through your solution. To see this in action, refer to the demonstration video below. Completing Messages To Complete messages, in scenarios using peek-lock, search for the RabbitMQ connector within the Logic Apps designer. You’ll find an operation called Complete message as a built-in connector. Search for the action and click on this operation to add the action to your design surface. Provide: Delivery tag Consumer tag Acknowledgment (Complete or Reject) You can use the payload from your trigger in downstream actions. For example, you might place the payload within a Compose action for further processing. You can also create queues as well, with the Create a queue action. Please see the following video with further details on the configuration of this connector: Supported Regions We are rolling out this connector worldwide, with some regions receiving it before others.
Introducing native Service Bus message publishing from Azure API Management (Preview)
We’re excited to announce a preview capability in Azure API Management (APIM) — you can now send messages directly to Azure Service Bus from your APIs using a built-in policy. This enhancement, currently in public preview, simplifies how you connect your API layer with event-driven and asynchronous systems, helping you build more scalable, resilient, and loosely coupled architectures across your enterprise. Why this matters? Modern applications increasingly rely on asynchronous communication and event-driven designs. With this new integration: Any API hosted in API Management can publish to Service Bus — no SDKs, custom code, or middleware required. Partners, clients, and IoT devices can send data through standard HTTP calls, even if they don’t support AMQP natively. You stay in full control with authentication, throttling, and logging managed centrally in API Management. Your systems scale more smoothly by decoupling front-end requests from backend processing. How it works The new send-service-bus-message policy allows API Management to forward payloads from API calls directly into Service Bus queues or topics. High-level flow A client sends a standard HTTP request to your API endpoint in API Management. The policy executes and sends the payload as a message to Service Bus. Downstream consumers such as Logic Apps, Azure Functions, or microservices process those messages asynchronously. All configurations happen in API Management — no code changes or new infrastructure are required. Getting started You can try it out in minutes: Set up a Service Bus namespace and create a queue or topic. Enable a managed identity (system-assigned or user-assigned) on your API Management instance. Grant the identity the “Service Bus data sender” role in Azure RBAC, scoped to your queue/ topic. Add the policy to your API operation: <send-service-bus-message queue-name="orders"> <payload>@(context.Request.Body.As<string>())</payload> </send-service-bus-message> Once saved, each API call publishes its payload to the Service Bus queue or topic. 📖 Learn more. Common use cases This capability makes it easy to integrate your APIs into event-driven workflows: Order processing – Queue incoming orders for fulfillment or billing. Event notifications – Trigger internal workflows across multiple applications. Telemetry ingestion – Forward IoT or mobile app data to Service Bus for analytics. Partner integrations – Offer REST-based endpoints for external systems while maintaining policy-based control. Each of these scenarios benefits from simplified integration, centralized governance, and improved reliability. Secure and governed by design The integration uses managed identities for secure communication between API Management and Service Bus — no secrets required. You can further apply enterprise-grade controls: Enforce rate limits, quotas, and authorization through APIM policies. Gain API-level logging and tracing for each message sent. Use Service Bus metrics to monitor downstream processing. Together, these tools help you maintain a consistent security posture across your APIs and messaging layer. Build modern, event-driven architectures With this feature, API Management can serve as a bridge to your event-driven backbone. Start small by queuing a single API’s workload, or extend to enterprise-wide event distribution using topics and subscriptions. You’ll reduce architectural complexity while enabling more flexible, scalable, and decoupled application patterns. Learn more: Get the full walkthrough and examples in the documentation 👉 hereIntroducing the RabbitMQ Connector (Public Preview)
We are pleased to announce the introduction of the RabbitMQ Connector in Logic Apps (Standard) which allows you to both send and receive messages between Logic Apps and RabbitMQ. RabbitMQ is a robust, open-source message broker widely used for building reliable, scalable, and flexible messaging solutions. It is trusted across industries such as financial services, e-commerce, IoT, telecommunications, and cloud-native microservices. Our RabbitMQ connector allows messaging scenarios on-premises using Logic Apps hybrid. Benefits of Using RabbitMQ Reliability: RabbitMQ ensures message delivery with strong durability and acknowledgment mechanisms. Flexible Routing: Supports complex routing logic via exchanges (direct, topic, fanout, headers). Clustering & High Availability: Offers clustering and mirrored queues for fault tolerance. Management & Monitoring: Provides a user-friendly management UI and extensive monitoring capabilities. Extensibility: Supports plugins for authentication, federation, and more. Our current connector offering supports both triggers (receive) and sending (publish) within Logic Apps. Receiving Messages To enable a trigger, we need to search for the RabbitMQ connector within our designer. We will discover an operation called When the queue has messages from RabbitMQ show up as a built-in connector. We also have a peek lock operation for non-destructive reads. Search for Trigger and click on this operation to add the trigger to your design surface. Configure the trigger by providing the Queue Name. You can use the payload from your trigger in downstream actions. For example, you might place the payload within a Compose action for further processing. Publishing Messages To send a message, search for the RabbitMQ connector in your design experience. You’ll find an operation called Send a message. Add this operation to your design surface and Provide the following: Queue Name Message Body Exchange Name (if routing is required) Routing Key Once configured, you can run messages through your solution. To see this in action, refer to the demonstration video (No link found). Completing Messages To Complete messages, in scenarios using peek-lock, search for the RabbitMQ connector within the Logic Apps designer. You’ll find an operation called Complete message as a built-in connector. Search for the action and click on this operation to add the action to your design surface. Provide: Delivery tag Consumer tag Acknowledgment (Complete or Reject) You can use the payload from your trigger in downstream actions. For example, you might place the payload within a Compose action for further processing. You can also create queues as well, with the Create a queue action. Please see the following video with further details on the configuration of this connector: Supported Regions We are rolling out this connector worldwide, with some regions receiving it before others.IBM MQ Built-in (In-App) connector and Queue Handles: The math behind Queue Handles
In some scenarios, we found that it might be challenging to understand how IBM MQ server needs to be configured to be able to poll without experiencing the dreaded IBM MQ returned Reason Code: 2017 - MQRC_HANDLE_NOT_AVAILABLE.BizTalk Server Patterns – The Parallel Shape
This blog entry was originally post on October 16th, 2009 and can be found here: https://docs.microsoft.com/en-us/archive/blogs/quocbui/biztalk-patterns-the-parallel-shape This blog entry describes how to effectively benefit from parallel processing by using the BizTalk Server messaging engine.
Elasticsearch vs azure search
Hello all, i am developing a bot for teams that take a message and search for it in my database and return it if found or return the related messages to it. now i found the Elasticsearch and the azure search service,, which is better to use with my bot that developed using Microsoft bot framework?
