Azure Event Grid with ASB
Hi, we need to push Event Grid events for blob creation to an Azure Service Bis queue to deduplicate as the EG guarantee "At least one delivery" pattern, but the problem is that we need to deduplicate with blob name as "MessageId" on ASB side. The problem is that the blob name is not present in the event data. we have only "subject" with the full url that can exceed 128 characters, the limit of ASb Messageid. In some duplicate events I found that the filed "data/storageDiagnostics/batchId" is the same for duplicated events. I'm wonderring if this batchId will be always the same for duplicate events, I can use it as "MessagesId" in "Delivery properties"Orchestration vs Choreography: How to Pick the Right Integration Pattern in Azure
Introduction Microservices architecture has become a popular approach for building scalable and flexible applications. Instead of a monolithic architecture, where all components of an application are tightly coupled, microservices divide the application into more independent services that can be developed, deployed and maintained separately. This approach allows for more agility, easier maintenance, and greater scalability. However, with microservices come challenges in integration. Each service must be independent, communicating and exchanging data with other benefits. This is where integration patterns come in. Two popular integration patterns for microservices are orchestration and choreography. This article will explore the differences between these two patterns and guide how to choose the correct pattern for your microservices in Azure. We will also provide step-by-step instructions on implementing each design using Azure services and best practices for effective integration. Orchestration vs Choreography Imagine you’re building a ride-sharing app that needs to connect riders with drivers in real-time. The app is built as a set of microservices, with separate services for user authentication, location tracking, ride matching, and payment processing. As a developer, you must choose between orchestration and choreography to integrate these microservices in Azure. Orchestration Orchestration involves a central component, often called an orchestrator, that manages the flow of communication between services. The orchestrator is responsible for initiating and coordinating service interactions and controlling the order and flow of messages between services. In an orchestration pattern, each service communicates directly with the orchestrator, which acts as a mediator between services. Let’s take the example of a user requesting a ride: The ride service receives a request from the user, which includes the user’s location and destination. The ride service sends the ride request data to the orchestrator. The orchestrator queries the driver service for available drivers. The driver service responds with a list of available drivers. The orchestrator selects an available driver and sends the ride request data to the driver service. The driver service confirms the ride request with the selected driver and sends the driver’s details to the orchestrator. The orchestrator sends the ride details to the payment service to authorise payment. The payment service authorises payment and sends a confirmation to the orchestrator. The orchestrator sends the start ride command to the driver service. The driver service starts the ride and sends periodic updates to the orchestrator, which updates the user through the app’s API. In this scenario, the central controller service manages the flow of information between the microservices, ensuring that the ride request is handled in the correct order and all the necessary steps are completed. Choreography Conversely, choreography is a distributed approach where each service communicates with other services directly, without a central mediator. In a choreography pattern, services publish and subscribe to events or messages, and each service reacts to these events or announcements independently. This approach allows for greater autonomy and scalability of services, as each service can respond to events without relying on a central orchestrator. Let’s take the same example of a user requesting a ride: The ride service receives a request from the user, which includes the user’s location and destination. The ride service sends an event to the location service to find nearby drivers. The location service listens for the event and responds with a list of available drivers. The ride service listens for the response and selects the best driver. The ride service sends an event to the payment service to authorise the payment for the ride. The payment service listens to the event and confirms the payment. The driver service listens for the confirmation and assigns the ride to the selected driver. The location service listens for a request from the driver service to track the driver’s location and sends updates to the rider. In this scenario, each microservice communicates with the other microservices through events, with each microservice determining its order of execution based on the circumstances it receives. The microservices work together in a decentralised manner without a central controller service directing the flow of information. Considerations for Choosing the Right Integration Pattern Both patterns have their pros and cons. Orchestration provides centralised control over communication flow and a clear, linear order of execution, making it easier to manage complex workflows. However, it can also introduce a single point of failure and become a bottleneck as the system grows. Conversely, choreography provides greater autonomy and scalability but can be more challenging to manage, leading to more complex service coordination. Choosing the correct pattern for your microservices depends on your specific requirements and goals; there are several factors to consider: Complexity and Scale: The complexity and scale of your microservices system can influence your choice of integration pattern. Orchestration may better suit complex workflows with many services, while choreography may be better for more loosely-coupled, decentralised systems. Team Expertise and Resources: The skills and resources of your development team can also influence your choice. If your team has experience with centralised control and workflow management, orchestration may be a good choice. If your team is more experienced with event-driven architecture and decentralised communication, choreography may be a better fit. Integration Requirements and Goals: Your integration requirements and goals can also influence your choice. If you must enforce strict order and coordination between services, orchestration may be the best choice, and choreography may be a better fit for flexibility and scalability. Future Scalability and Flexibility Needs: Finally, it’s essential to consider future scalability and flexibility needs. If you anticipate significant growth in your system or need to add or remove services frequently, choreography may be a better choice. If you expect a more stable system with a fixed number of benefits, orchestration may be a better fit. By considering these factors, you can decide on the best integration pattern for your microservices system in Azure. The following sections will provide step-by-step guidance on implementing each design using Azure services. Implementing Orchestration in Azure Azure offers several services that can be used to implement orchestration, including Azure Logic Apps, Azure Functions, and Azure Durable Functions. For the ride-sharing app scenario, we’ll use Azure Logic Apps to orchestrate the communication between the microservices. To implement orchestration using Azure Logic Apps, you would create a workflow that defines the steps for handling a ride request. The workflow would be triggered by an HTTP request to the ride service, which would then execute the workflow steps in the correct order. Here’s what the ride request workflow might look like: When the ride service receives a request from the user, it triggers the Logic App workflow. The workflow sends a message to the location service to find nearby drivers using the HTTP action. The workflow waits for the location service to respond with a list of available drivers using the HTTP action with a polling action to wait for the response. Once the response is received, the workflow selects the best driver based on criteria such as proximity and driver rating using a conditional action. The workflow sends a message to the payment service to authorise the payment for the ride using the HTTP action. The workflow waits for the payment service to confirm the payment using the HTTP action with a polling action to wait for the response. Once the payment is confirmed, the workflow sends a message to the driver service to assign the ride to the selected driver using the HTTP action. The workflow sends a message to the location service to track the driver’s location in real-time and update the rider using the HTTP action. In this scenario, Azure Logic Apps acts as the central controller service, managing the flow of information between the microservices and ensuring that the ride request is handled in the correct order. Implementing Choreography in Azure Choreography in Azure involves each microservice responsible for its events and state changes. In the ride-sharing app scenario, each microservice would communicate with other microservices to perform their respective tasks. Azure provides several services for implementing choreography, including Azure Event Grid and Azure Service Bus. For the ride-sharing app scenario, we’ll use Azure Event Grid to facilitate communication between the microservices. In a choreographed system, each microservice subscribes to events from other microservices that it depends on. In the ride-sharing app example, the location service would publish an event when a driver becomes available. The ride service would subscribe to these events to find available drivers for a ride request. Similarly, the payment service would publish an event when a payment is authorised, and the driver service would subscribe to these events to start the ride. Here’s how the ride request process might look in a choreographed system using Azure Event Grid: When the user requests a ride, the ride service sends a message to the location service to find available drivers using the HTTP action. The location service publishes an event on Azure Event Grid when a driver becomes available. The ride service subscribes to the event and receives a message with information about the available driver. The ride service sends a message to the payment service to authorise the payment for the ride using the HTTP action. When the payment is authorised, the payment service publishes an event on Azure Event Grid. The driver service subscribes to the event and receives the message to start the ride. The driver service sends location updates to the location service, which publishes events on Azure Event Grid for the rider to see the driver’s location. In this scenario, each microservice communicates with other microservices through events published to Azure Event Grid, and there is no central controller to manage the flow of information. Conclusion In conclusion, choosing the correct integration pattern for your microservices system in Azure depends on your specific requirements and goals. Orchestration provides centralised control and a clear order of execution, while choreography offers greater autonomy and scalability. By considering factors such as complexity, team expertise, integration requirements, and future scalability needs, you can decide on the best pattern for your system. Azure provides several services for implementing orchestration and choreography patterns, such as Azure Service Bus and Azure Logic Apps for orchestration and Azure Event Grid and Azure Functions for choreography. By following the step-by-step guidance provided in this article, you can implement the integration pattern that best suits your microservices system in Azure.
calling web api in Sharepoint Framework with Aad client lib through Azure?
b but I'm facing this issue. Kindly If you know the any possible solution then guide me.I'm following this link https://docs.microsoft.com/en-us/sharepoint/dev/spfx/use-aadhttpclient. after receiving these errors mentioned above then got a few things but token acquisition failure still remains. Manifest file code: package-solution.json "webApiPermissionRequests": [ { "resource": "SaintGobain-Service-API", "scope": "Sites.FullControl.All" } ]
500 internal server error while invoking bulk Azure API calls.
Hi All, I am facing an issue like when i invoke multiple(more than 10) API calls with 300 msec time gap random API calls are throwing "500 Internal server error". But when i increase the time gap between the API call there is no issue. If any resolution for this issue please share with me. thank you in advance !!! Resources used: 1. Azure API Management 2. Azure Functionapps
