Merge branch 'v1.13' into issue_4103

daprdocs/content/en/developing-applications/building-blocks/state-management/howto-outbox.md

@@ -28,8 +28,10 @@ The diagram below is an overview of how the outbox feature works:
 
 The outbox feature can be used with using any [transactional state store]({{< ref supported-state-stores >}}) supported by Dapr. All [pub/sub brokers]({{< ref supported-pubsub >}}) are supported with the outbox feature.
 
+[Learn more about the transactional methods you can use.]({{< ref "howto-get-save-state.md#perform-state-transactions" >}})
+
 {{% alert title="Note" color="primary" %}} 
-Message brokers that work with the competing consumer pattern (for example, [Apache Kafka]({{< ref setup-apache-kafka>}}) are encouraged to reduce the chances of duplicate events.
+Message brokers that work with the competing consumer pattern (for example, [Apache Kafka]({{< ref setup-apache-kafka>}})) are encouraged to reduce the chances of duplicate events.
 {{% /alert %}}
 
 ## Usage

daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-patterns.md

@@ -586,7 +586,45 @@ The key takeaways from this example are:
 - The number of parallel tasks can be static or dynamic
 - The workflow itself is capable of aggregating the results of parallel executions
 
-While not shown in the example, it's possible to go further and limit the degree of concurrency using simple, language-specific constructs. Furthermore, the execution of the workflow is durable. If a workflow starts 100 parallel task executions and only 40 complete before the process crashes, the workflow restarts itself automatically and only schedules the remaining 60 tasks.
+Furthermore, the execution of the workflow is durable. If a workflow starts 100 parallel task executions and only 40 complete before the process crashes, the workflow restarts itself automatically and only schedules the remaining 60 tasks.
+
+It's possible to go further and limit the degree of concurrency using simple, language-specific constructs. The sample code below illustrates how to restrict the degree of fan-out to just 5 concurrent activity executions:
+
+{{< tabs ".NET" >}}
+
+{{% codetab %}}
+<!-- .NET -->
+```csharp
+
+//Revisiting the earlier example...
+// Get a list of N work items to process in parallel.
+object[] workBatch = await context.CallActivityAsync<object[]>("GetWorkBatch", null);
+
+const int MaxParallelism = 5;
+var results = new List<int>();
+var inFlightTasks = new HashSet<Task<int>>();
+foreach(var workItem in workBatch)
+{
+  if (inFlightTasks.Count >= MaxParallelism)
+  {
+    var finishedTask = await Task.WhenAny(inFlightTasks);
+    results.Add(finishedTask.Result);
+    inFlightTasks.Remove(finishedTask);
+  }
+
+  inFlightTasks.Add(context.CallActivityAsync<int>("ProcessWorkItem", workItem));
+}
+results.AddRange(await Task.WhenAll(inFlightTasks));
+
+var sum = results.Sum(t => t);
+await context.CallActivityAsync("PostResults", sum);
+```
+
+{{% /codetab %}}
+
+{{< /tabs >}}
+
+Limiting the degree of concurrency in this way can be useful for limiting contention against shared resources. For example, if the activities need to call into external resources that have their own concurrency limits, like a databases or external APIs, it can be useful to ensure that no more than a specified number of activities call that resource concurrently.
 
 ## Async HTTP APIs