Azure Service Bus, paired with Logic Apps, offers a powerful combination for sending, receiving, and managing messages between different applications and services. In this blog, we’ll walk through the process of sending and receiving messages using Azure Service Bus and Logic Apps. Steps to send and receive messages from service bus using logic app Step 1: Create an Azure Service Bus Namespace Navigate to the Azure Portal: – Go to portal.azure.com and log in with your credentials. Create a Service Bus Namespace: – In the search bar at the top, type “Service Bus” and select Service Bus from the results. – Click + Create to start the creation process. – Fill in the required details: Click Review + Create, and then Create to deploy the namespace. Step 2: Create a Queue or Topic in the Service Bus Namespace Access the Service Bus Namespace: – After the namespace is deployed, navigate to it by clicking on the resource in the portal. Create a Queue or Topic depending on your use case I am going to use: – Creating a Queue: Step 3: Create a Logic App to Send Messages to the Service Bus Navigate to Logic Apps: – In the Azure portal, use the search bar to find and select Logic Apps. – Click + Create to start a new Logic App. Configure Your Logic App: – In the Basics tab, provide the following details: – Click Review + Create, and then Create. Design the Logic App: – Once the Logic App is created, open the Logic Apps Designer and a trigger “When a HTTP request is received” along with POST request. – Add a compose action and pass the input parameters. – Go to Service bus –> Shared access policies –> Copy the Connection String Endpoint url – Add action Service Send Message and paste the copied end point in Connection String. – Pass the Output of compose in content. – Add a response action and the logic app workflow. – Now Copy the Url from trigger and paste it in postman hit the url. – As soon as you hit the url you will get customer Id as response in postman body. – Now Go to azure portal and check the run history I will see the Date and Status has been added for that particular customer id. – Now, Let’s verify this particular message whether it has been sent at the logic level or not. – Go to queue in my case Queue name Is “receivingqueue” –> Go to Service bus Explorer –> Click on Peek form Start. – Now in order see the content/ Message select the sequence number Step 4: Create a Logic App to Receive Messages from the Service Bus – Create a New Logic App: Repeat the steps to create a new Logic App. – Go to Logic app designer. – Add the Trigger “When a message is received in a queue”. – Add a compose action – Add a Terminate action on Succeeded. – Now to verify you check the run history of logic app you can we are getting the content in base64 Format – You can decode it and check it’s the same data that we were sending. Conclusion We’ve successfully set up a messaging system with Logic Apps and Azure Service Bus by following these steps. This configuration makes it possible to automate workflows, integrate apps seamlessly, and create reliable cloud solutions. Whether you’re working with batch processing or real-time data, Azure’s tools give you the strength and flexibility you need to scale your business effectively.

If you’re finding it challenging to decide when to use Azure Service Bus Queues or Topics, this blog is for you! In our previous blog, we explored Azure Service Bus Queues, Topics, and Subscriptions. To recap, Azure Service Bus is a fully managed messaging service provided by Microsoft Azure. It helps decouple and scale applications by allowing different components to communicate with each other through messages. In this blog, we will delve deeper into Azure Service Bus Queues vs. Topics, examining their differences, use cases, and how to choose between them based on your application needs. By understanding these core concepts, we’ll be better equipped to design scalable and efficient messaging solutions using Azure Service Bus. Azure Service Bus Queues vs. Topics Service Bus Queues Queues work on a First In, First Out (FIFO) basis. This means that clients that receive messages from the queue and then process that message in the order in which they were added to the queue, and they will be the only consumer that processes this message. The queue will store this message until our client is able to process them. To process the message, the client will pull the message off the queue. Purpose: Queues are designed for point-to-point communication. They are ideal when a single consumer needs to process messages from a single sender. Message Handling: Messages are stored in a queue and processed by a single consumer in a first-in, first-out (FIFO) manner. Use Case: Best suited for scenarios where a specific task needs to be handled one at a time. For example, in an order processing system where each order needs to be managed sequentially. Fig – Message Queue with Messages One of the benefits of using queues is that producers and consumers do not need to exchange messages simultaneously. Messages are stored in the queue and are processed only when the consumer retrieves them. This setup enables producers to continue sending messages to the queue independently. Consequently, components within our architecture can be decoupled, as producers and consumers are not required to synchronize their actions. If there is a high volume of messages entering the queue, we can scale up the consumers without needing to scale the producers. Service Bus Topics Topics are different to Queues since instead of working with a single consumer, we can have multiple subscribers to our topic, who will receive their own copy of the message from the topic. This works in a pub/sub pattern, where we will have messages being published to the topic and have multiple clients subscribe to that topic. Purpose: Topics are designed for publish-subscribe communication. They allow messages to be sent to a topic and processed by multiple consumers. Message Handling: Messages sent to a topic are delivered to multiple subscriptions. Each subscription can have its own filter and process messages independently. Use Case: Ideal for broadcasting messages to multiple systems. For instance, a CRM system might need to notify various departments (e.g., sales, marketing) about a new customer record. Fig – Topic with three Subscription with Messages In Topics, our consumers don’t directly consume the message from our Topic. Instead, we create subscriptions that subscribe to the topic and our consumers receive a copy of a message from the topic. In Azure Service Bus, we can define filters on these subscriptions that determine conditions for messages to be published to a subscription and actions that modifies the message metadata. Conclusion In this post, we discussed the differences between Queues and Topics in Azure Service Bus. To summarize, Azure Service Bus Queues are ideal for point-to-point communication in which messages must be handled sequentially by a single consumer. Topics, on the other hand, are suitable for scenarios that need publish-subscribe patterns, as they enable several consumers to process the same message independently. Choosing the proper solution is determined by your application’s, individual requirements, ensuring that your message system is both scalable and efficient. If your system requires sequential processing and single customers, queues are the best option. However, if your system wants to broadcast messages to several users, Topics will give the necessary flexibility and scalability. We hope you found this article useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com

Introduction In Dynamics 365 CRM, integrating with external systems, running automated processes, and developing custom applications often requires non-interactive access to CRM data. One of the most secure and efficient ways to achieve this is by creating an Application User via the Azure Portal. In this blog, we’ll guide you through the step-by-step process of setting up an Application User and explain when and why you should use it in your CRM environment. Steps to Create an Application User: – Navigate to the Azure Portal and log in with your Azure account. – Search for Azure Active Directory or select from the left-hand menu. – Click on “App registrations” in the Azure Active Directory blade and click on “New registration”. – Enter the following details: – Click “Register”. – Select the newly created application from the App registrations list and click on “API permissions” in the left-hand menu. – Click on “Add a permission”. – Select “Dynamics CRM”. – Select “Delegated permissions” and check the necessary permissions such as user_impersonation. – Click “Add permissions”. – Click on “Grant admin consent for [your organization]” and confirm. – Go to “Certificates & secrets” in the application settings. – Click on “New client secret”. – Add a description (e.g., “CRM App Secret”) and set an expiry period. – Click “Add”. – Copy the value of the client secret and store it securely. You will need it later. – Add Application User in Dynamics 365 CRM – Log on to the Microsoft Power Platform Admin (D365 Admin) centre as a system administrator. – In the navigation pane, go to Environments, and then select an environment form the list. – On the Settings tab, go to Users + permissions, and then select Application users. – The application users page appears. – Click + New app user. – After clicking on + New app user. A side menu slider will appear. Here you will have to: When to Use an Application User Conclusion Creating an application user in Dynamics 365 CRM via the Azure Portal is a straightforward process that enhances the integration capabilities and automation potential of your CRM environment. By following the steps outlined above, you can set up an application user and leverage it for various integration and automation scenarios. We hope you found this article useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com

Introduction Azure Service Bus is a fully managed, multi-tenant cloud messaging service functioning as a brokered messaging system. In a software-oriented architecture (SOA), application components interact through communication protocols over a network, facilitated by the Service Bus. This article provides an overview of Azure Service Bus, highlighting its role in integrating systems like Microsoft Dynamics 365 CRM with third-party e-commerce platforms. Real-World Scenario: Integrating Dynamics 365 CRM with an E-commerce Platform Azure Service Bus is instrumental in enabling seamless interaction between Dynamics 365 CRM and external e-commerce applications, enhancing data management and operational efficiency. – Customer Data Synchronization: Customer data from the e-commerce platform is transferred to Dynamics 365 CRM using Service Bus queues, ensuring the CRM system reflects the latest information. – Order Processing: When an order is placed, it triggers a message to Dynamics 365 CRM, streamlining order fulfilment and tracking through Service Bus topics and subscriptions. – Inventory Management: Inventory levels are updated in real-time across both systems. Messages sent through Service Bus ensure accurate stock levels, preventing overselling. – Customer Support Integration: Customer support tickets from the e-commerce platform are channelled to Dynamics 365 CRM, providing a comprehensive view of customer interactions and improving support quality. Use Case Real-Time Data Synchronization Between Dynamics 365 CRM and Finance & Operations Scenario: Imagine a company that uses Microsoft Dynamics 365 CRM for customer relationship management and Dynamics 365 Finance & Operations (F&O) for financial and inventory management. To ensure consistent and accurate data across these systems, especially regarding inventory levels, real-time data synchronization is essential. Solution: In this integration scenario, the goal is to synchronize inventory levels between Microsoft Dynamics 365 CRM and Finance and Operations (F&O) systems to ensure real-time accuracy. The process starts with Dynamics 365 CRM, where changes in inventory, such as sales or restocking, trigger an event. This event generates a message containing the updated inventory details, which is then sent via Azure Service Bus. Azure Service Bus serves as a reliable messaging service that decouples the CRM and F&O systems, facilitating smooth communication between them. Once the message reaches Azure Service Bus, it is picked up by an Azure Logic App. The Logic App orchestrates the integration process, potentially using Azure Functions for tasks such as data transformation, validation, or enrichment. For instance, it may convert the message into a format compatible with the F&O system, such as OData, a standard protocol for data exchange. After processing, the transformed data is sent to the F&O system, where the inventory levels are updated accordingly. This setup ensures that inventory records are synchronized in real time across both systems, preventing issues like overselling by maintaining up-to-date stock levels. The use of Azure Service Bus and Logic Apps not only supports real-time communication but also offers a scalable and flexible integration solution that can adapt to evolving business needs. Key benefits of this approach include real-time updates, fault tolerance through message persistence and retry logic, and the flexibility to scale and integrate systems without tight coupling. Azure Service Bus Queues and Topics and Subscriptions Azure Service Bus offers Queues and Topics and Subscriptions as core features, enabling different messaging patterns to suit various use cases. Queues facilitate point-to-point communication, while Topics and Subscriptions support a publish-subscribe model. This flexibility allows for efficient data transfer and processing across applications. Stay tuned for my next post, where we’ll explore the specific scenarios in which to use queues versus topics and subscriptions. Conclusion Azure Service Bus provides a versatile and reliable messaging solution for building scalable, decoupled distributed applications. By integrating seamlessly with the broader Azure ecosystem, Service Bus empowers developers to create efficient communication channels, enhancing the performance and reliability of their applications. Whether you’re modernizing existing systems or developing new cloud-native applications, Azure Service Bus is an essential tool for delivering an excellent user experience. We hope you found this article useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com