Merge pull request #11837 from MicrosoftDocs/revert-11801-ferantivero…

…/feature/205097_choreography-example

Revert "[MAINT] Update Choreography cloud design pattern - Part I: The Example"

docs/patterns/choreography-content.md

@@ -38,9 +38,9 @@ Decentralizing the orchestrator can cause issues while managing the workflow.
 
 If a service fails to complete a business operation, it can be difficult to recover from that failure. One way is to have the service indicate failure by firing an event. Another service subscribes to those failed events takes necessary actions such as applying [compensating transactions](./compensating-transaction.yml) to undo successful operations in a request. The failed service might also fail to fire an event for the failure. In that case, consider using a retry and, or time out mechanism to recognize that operation as a failure. For an example, see the [Example](#example) section.
 
-It's simple to implement a workflow when you want to process independent business operations in parallel. You can use a single message bus. However, the workflow can become complicated when choreography needs to occur in a sequence. For instance, Service C can start its operation only after Service A and Service B have completed their operations with success. One approach is to have multiple message buses or queues that get messages in the required order. For more information, see the [Example](#example) section.
+It's simple to implement a workflow when you want to process independent business operations in parallel. You can use a single message bus. However, the workflow can become complicated when choreography needs to occur in a sequence. For instance, Service C can start its operation only after Service A and Service B have completed their operations with success. One approach is to have multiple message buses that get messages in the required order. For more information, see the [Example](#example) section.
 
-T he choreography pattern becomes a challenge if the number of services grow rapidly. Given the high number of independent moving parts, the workflow between services tends to get complex. Also, distributed tracing becomes difficult.
+The choreography pattern becomes a challenge if the number of services grow rapidly. Given the high number of independent moving parts, the workflow between services tends to get complex. Also, distributed tracing becomes difficult.
 
 The orchestrator centrally manages the resiliency of the workflow and it can become a single point of failure. On the other hand, for choreography, the role is distributed between all services and resiliency becomes less robust.
 
@@ -59,36 +59,94 @@ As with any design decision, consider any tradeoffs against the goals of the oth
 
 ## Example
 
-This example shows the choreography pattern by creating an event driven, cloud native workload running functions along with microservices. When a client requests a package to be shipped, the workload assigns a drone. Once the package is ready to pick up by the scheduled drone, the delivery process gets started. While in-transit the workload handles the delivery until it gains the shipped status.
+This example shows the choreography pattern with the [Drone Delivery app](https://github.com/mspnp/microservices-reference-implementation). When a client requests a pickup, the app assigns a drone and notifies the client.
 
-![GitHub logo](../_images/github.png) The code example of this pattern is available on [GitHub](https://github.com/mspnp/cloud-design-patterns/tree/master/choreography).
+![GitHub logo](../_images/github.png) An example of this pattern is available on [GitHub](https://github.com/mspnp/cloud-design-patterns/tree/master/choreography).
 
-This example is a refactoring of the [Drone Delivery implementation](https://github.com/mspnp/microservices-reference-implementation) that replaces the Orchestrator pattern with the Choreography pattern.
+![A close up of a map Description automatically generated](./_images/choreography-example.png)
 
-![An event driven cloud native example workload implementing choreography pattern](./_images/choreography-example.png)
-
-The Ingestion service handles the client requests and convert them into messages including the delivery details. Business transaction are initiated after consuming those new messages.
-
-A single client business transaction requires three distinct business operations: creating or updating a package, assigning a drone to deliver the package, and the proper handling of the delivery that consists of checking and eventually raising awareness when shipped. Three microservices perform the business processing: Package, Drone Scheduler, and Delivery services. Instead of a central orchestrator, the services use messaging to communicate among themselves. Each service would be responsible to implement a protocol in advance that coordinates in a decentralized way the business workflow.
+A single client business transaction requires three distinct business operations: creating or updating a package, assigning a drone to deliver the package, and checking the delivery status. Those operations are performed by three microservices: Package, Drone Scheduler, and Delivery services. Instead of a central orchestrator, the services use messaging to collaborate and coordinate the request among themselves.
 
 ### Design
 
-The business transaction is processed in a sequence through multiple hops. Each hop is sharing a single message bus among all the business services.
-
-When a client sends a delivery request through an HTTP endpoint, the Ingestion service receives it, converts such request into a message, and then publishes the message to the shared message bus. The subscribed business services are going to be consuming new messages added to the bus. On receiving the message, the business services can complete the operation with success, failure, or the request can time out. If successful, the services respond to the bus with the Ok status code, raises a new operation message, and sends it to the message bus. If there's a failure or time-out, the service reports failure by sending the reason code to the message bus. Additionally, the message is going to be dead lettered for later handling. Messages that couldn't be received or processed within a reasonable and appropriate amount of time are moved the DLQ as well.
+The business transaction is processed in a sequence through multiple hops. Each hop has a message bus and the respective business service.
 
-The design uses multiple message buses to process the entire business transaction. [Microsoft Azure Service Bus](/azure/service-bus-messaging) and [Microsoft Azure Event Grid](/azure/event-grid/) are composed to provide with the messaging service platform for this design. The workload is deployed on [Azure Container Apps](/azure/container-apps/) hosting [Azure Functions](/azure/azure-functions/functions-container-apps-hosting/) for ingestion, and apps handling [event-driven processing](/azure/container-apps/scale-app?pivots=azure-cli#custom) that executes the business logic.
+When a client sends a delivery request through an HTTP endpoint, the Ingestion service receives it, raises an operation event, and sends it to a message bus. The bus invokes the subscribed business service and sends the event in a POST request. On receiving the event, the business service can complete the operation with success, failure, or the request can time out. If successful, the service responds to the bus with the Ok status code, raises a new operation event, and sends it to the message bus of the next hop. In case of a failure or time-out, the service reports failure by sending the BadRequest code to the message bus that sent the original POST request. The message bus retries the operation based on a retry policy. After that period expires, message bus flags the failed operation and further processing of the entire request stops.
 
-The design ensures the choreography to occur in a sequence. A single Azure Service Bus namespace contains a topic with two subscriptions and a session-aware queue. The Ingestion service publishes messages to the topic. The Package service and Drone Scheduler service subscribe to the topic and publish messages communicating the success to the queue. Including a common session idendtifier which a GUID associated to the delivery identifier, enables the ordered handling of unbounded sequences of related messages. The Delivery service awaits two related messages per transaction. The first message indicates the package is ready to be shipped, and the second signals that a drone is scheduled.
+This workflow continues until the entire request has been processed.
 
-This design uses Azure Service Bus to handle high-value messages that can't be lost or duplicated during the entire delivery process. When the package is shipped, it's also published a change of state to Azure Event Grid. In this design, the event sender has no expectation about how the change of state is handled. Downstream organization services that arenot included as part of this design could be listening to this event type, and react executing specific business purpose logic (that is, email the shipped order status to the user).
+The design uses multiple message buses to process the entire business transaction. [Microsoft Azure Event Grid](/azure/event-grid/) provides the messaging service. The app is deployed in an [Azure Kubernetes Service (AKS)](/azure/aks/) cluster with [two containers in the same pod](https://kubernetes.io/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/#creating-a-pod-that-runs-two-containers). One container runs the [ambassador](./ambassador.yml) that interacts with Event Grid while the other runs a business service. The approach with two containers in the same pod improves performance and scalability. The ambassador and the business service share the same network allowing for low latency and high throughput.
 
-> If you are planning to deploy this into another compute service such as [AKS](/azure/aks/) pub-sub pattern application boilplate could be implemented with [two containers in the same pod](https://kubernetes.io/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/#creating-a-pod-that-runs-two-containers). One container runs the [ambassador](./ambassador.yml) that interacts with your message bus of preference while the another executes the business logic. The approach with two containers in the same pod improves performance and scalability. The ambassador and the business service share the same network allowing for low latency and high throughput.
-
-To avoid cascading retry operations that might lead to multiple efforts, business services should immediately flag unacceptable messages. It's possible to enrich such messages using well-known reason codes or a defined application code, so it can be moved to a [dead letter queue (DLQ)](/azure/service-bus-messaging/service-bus-dead-letter-queues). Consider managing consistency issues implementing [Saga](/azure/architecture/reference-architectures/saga/saga) from downstream services. For example, another service could handle dead lettered messages for remediation purposes only by executing a compensation, rety or pivot transaction.
+To avoid cascading retry operations that might lead to multiple efforts, only Event Grid retries an operation instead of the business service. It flags a failed request by sending a messaging to a [dead letter queue (DLQ)](/azure/service-bus-messaging/service-bus-dead-letter-queues).
 
 The business services are idempotent to make sure retry operations don't result in duplicate resources. For example, the Package service uses upsert operations to add data to the data store.
 
+The example implements a custom solution to correlate calls across all services and Event Grid hops.
+
+Here's a code example that shows the choreography pattern between all business services. It shows the workflow of the Drone Delivery app transactions. Code for exception handling and logging have been removed for brevity.
+
+```csharp
+[HttpPost]
+[Route("/api/[controller]/operation")]
+[ProducesResponseType(typeof(void), 200)]
+[ProducesResponseType(typeof(void), 400)]
+[ProducesResponseType(typeof(void), 500)]
+
+public async Task<IActionResult> Post([FromBody] EventGridEvent[] events)
+{
+
+   if (events == null)
+   {
+       return BadRequest("No Event for Choreography");
+   }
+
+   foreach(var e in events)
+   {
+
+        List<EventGridEvent> listEvents = new List<EventGridEvent>();
+        e.Topic = eventRepository.GetTopic();
+        e.EventTime = DateTime.Now;
+        switch (e.EventType)
+        {
+            case Operations.ChoreographyOperation.ScheduleDelivery:
+            {
+                var packageGen = await packageServiceCaller.UpsertPackageAsync(delivery.PackageInfo).ConfigureAwait(false);
+                if (packageGen is null)
+                {
+                    //BadRequest allows the event to be reprocessed by Event Grid
+                    return BadRequest("Package creation failed.");
+                }
+
+                //we set the event type to the next choreography step
+                e.EventType = Operations.ChoreographyOperation.CreatePackage;
+                listEvents.Add(e);
+                await eventRepository.SendEventAsync(listEvents);
+                return Ok("Created Package Completed");
+            }
+            case Operations.ChoreographyOperation.CreatePackage:
+            {
+                var droneId = await droneSchedulerServiceCaller.GetDroneIdAsync(delivery).ConfigureAwait(false);
+                if (droneId is null)
+                {
+                    //BadRequest allows the event to be reprocessed by Event Grid
+                    return BadRequest("could not get a drone id");
+                }
+                e.Subject = droneId;
+                e.EventType = Operations.ChoreographyOperation.GetDrone;
+                listEvents.Add(e);
+                await eventRepository.SendEventAsync(listEvents);
+                return Ok("Drone Completed");
+            }
+            case Operations.ChoreographyOperation.GetDrone:
+            {
+                var deliverySchedule = await deliveryServiceCaller.ScheduleDeliveryAsync(delivery, e.Subject);
+                return Ok("Delivery Completed");
+            }
+            return BadRequest();
+    }
+}
+```
+
 ## Related resources
 
 Consider these patterns in your design for choreography.
@@ -99,8 +157,6 @@ Consider these patterns in your design for choreography.
 
 - Use asynchronous distributed messaging through the [publisher-subscriber pattern](./publisher-subscriber.yml).
 
-- Use [compensating transactions](./compensating-transaction.yml) to undo a series of successful operations in case one or more related operations fail.
+- Use [compensating transactions](./compensating-transaction.yml) to undo a series of successful operations in case one or more related operation fails.
 
 - For information about using a message broker in a messaging infrastructure, see [Asynchronous messaging options in Azure](../guide/technology-choices/messaging.yml).
-
-- [Choose between Azure messaging services](/azure/service-bus-messaging/compare-messaging-services)