Merge branch 'v1.15' into modernize-state-docs-examples-dotnet

This commit is contained in:
Mark Fussell 2025-05-15 15:15:29 -07:00 committed by GitHub
commit 6255089577
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
7 changed files with 52 additions and 59 deletions

View File

@ -199,7 +199,6 @@ Below are code examples that leverage Dapr SDKs to subscribe to the topic you de
{{% codetab %}}
```csharp
//dependencies
using System.Collections.Generic;
using System.Threading.Tasks;
using System;
@ -207,21 +206,19 @@ using Microsoft.AspNetCore.Mvc;
using Dapr;
using Dapr.Client;
//code
namespace CheckoutService.controller
{
namespace CheckoutService.Controllers;
[ApiController]
public class CheckoutServiceController : Controller
public sealed class CheckoutServiceController : ControllerBase
{
//Subscribe to a topic
//Subscribe to a topic called "orders" from the "order-pub-sub" compoennt
[Topic("order-pub-sub", "orders")]
[HttpPost("checkout")]
public void getCheckout([FromBody] int orderId)
public void GetCheckout([FromBody] int orderId)
{
Console.WriteLine("Subscriber received : " + orderId);
}
}
}
```
Navigate to the directory containing the above code, then run the following command to launch both a Dapr sidecar and the subscriber application:
@ -435,39 +432,35 @@ Below are code examples that leverage Dapr SDKs to publish a topic.
{{% codetab %}}
```csharp
//dependencies
using System;
using System.Collections.Generic;
using System.Net.Http;
using System.Net.Http.Headers;
using System.Threading.Tasks;
using Dapr.Client;
using Microsoft.AspNetCore.Mvc;
using System.Threading;
//code
namespace EventService
{
class Program
{
static async Task Main(string[] args)
{
string PUBSUB_NAME = "order-pub-sub";
string TOPIC_NAME = "orders";
const string PUBSUB_NAME = "order-pub-sub";
const string TOPIC_NAME = "orders";
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddDaprClient();
var app = builder.Build();
var random = new Random();
var client = app.Services.GetRequiredService<DaprClient>();
while(true) {
System.Threading.Thread.Sleep(5000);
Random random = new Random();
int orderId = random.Next(1,1000);
CancellationTokenSource source = new CancellationTokenSource();
CancellationToken cancellationToken = source.Token;
using var client = new DaprClientBuilder().Build();
await Task.Delay(TimeSpan.FromSeconds(5));
var orderId = random.Next(1,1000);
var source = new CancellationTokenSource();
var cancellationToken = source.Token;
//Using Dapr SDK to publish a topic
await client.PublishEventAsync(PUBSUB_NAME, TOPIC_NAME, orderId, cancellationToken);
Console.WriteLine("Published data: " + orderId);
}
}
}
}
```
Navigate to the directory containing the above code, then run the following command to launch both a Dapr sidecar and the publisher application:

View File

@ -413,7 +413,7 @@ dapr invoke --app-id checkout --method checkout/100
You can also append a query string or a fragment to the end of the URL and Dapr will pass it through unchanged. This means that if you need to pass some additional arguments in your service invocation that aren't part of a payload or the path, you can do so by appending a `?` to the end of the URL, followed by the key/value pairs separated by `=` signs and delimited by `&`. For example:
```bash
curl 'http://dapr-app-id:checkout@localhost:3602/checkout/100?basket=1234&key=abc` -X POST
curl 'http://dapr-app-id:checkout@localhost:3602/checkout/100?basket=1234&key=abc' -X POST
```
### Namespaces

View File

@ -318,8 +318,8 @@ Manage your workflow using HTTP calls. The example below plugs in the properties
To start your workflow with an ID `12345678`, run:
```http
POST http://localhost:3500/v1.0/workflows/dapr/OrderProcessingWorkflow/start?instanceID=12345678
```shell
curl -X POST "http://localhost:3500/v1.0/workflows/dapr/OrderProcessingWorkflow/start?instanceID=12345678"
```
Note that workflow instance IDs can only contain alphanumeric characters, underscores, and dashes.
@ -328,16 +328,16 @@ Note that workflow instance IDs can only contain alphanumeric characters, unders
To terminate your workflow with an ID `12345678`, run:
```http
POST http://localhost:3500/v1.0/workflows/dapr/12345678/terminate
```shell
curl -X POST "http://localhost:3500/v1.0/workflows/dapr/12345678/terminate"
```
### Raise an event
For workflow components that support subscribing to external events, such as the Dapr Workflow engine, you can use the following "raise event" API to deliver a named event to a specific workflow instance.
```http
POST http://localhost:3500/v1.0/workflows/<workflowComponentName>/<instanceID>/raiseEvent/<eventName>
```shell
curl -X POST "http://localhost:3500/v1.0/workflows/<workflowComponentName>/<instanceID>/raiseEvent/<eventName>"
```
> An `eventName` can be any function.
@ -346,14 +346,14 @@ POST http://localhost:3500/v1.0/workflows/<workflowComponentName>/<instanceID>/r
To plan for down-time, wait for inputs, and more, you can pause and then resume a workflow. To pause a workflow with an ID `12345678` until triggered to resume, run:
```http
POST http://localhost:3500/v1.0/workflows/dapr/12345678/pause
```shell
curl -X POST "http://localhost:3500/v1.0/workflows/dapr/12345678/pause"
```
To resume a workflow with an ID `12345678`, run:
```http
POST http://localhost:3500/v1.0/workflows/dapr/12345678/resume
```shell
curl -X POST "http://localhost:3500/v1.0/workflows/dapr/12345678/resume"
```
### Purge a workflow
@ -362,16 +362,16 @@ The purge API can be used to permanently delete workflow metadata from the under
Only workflow instances in the COMPLETED, FAILED, or TERMINATED state can be purged. If the workflow is in any other state, calling purge returns an error.
```http
POST http://localhost:3500/v1.0/workflows/dapr/12345678/purge
```shell
curl -X POST "http://localhost:3500/v1.0/workflows/dapr/12345678/purge"
```
### Get information about a workflow
To fetch workflow information (outputs and inputs) with an ID `12345678`, run:
```http
GET http://localhost:3500/v1.0/workflows/dapr/12345678
```shell
curl -X GET "http://localhost:3500/v1.0/workflows/dapr/12345678"
```
Learn more about these HTTP calls in the [workflow API reference guide]({{< ref workflow_api.md >}}).

View File

@ -23,7 +23,7 @@ The Dapr Workflow engine is internally powered by Dapr's actor runtime. The foll
To use the Dapr Workflow building block, you write workflow code in your application using the Dapr Workflow SDK, which internally connects to the sidecar using a gRPC stream. This registers the workflow and any workflow activities, or tasks that workflows can schedule.
The engine is embedded directly into the sidecar and implemented using the [`durabletask-go`](https://github.com/microsoft/durabletask-go) framework library. This framework allows you to swap out different storage providers, including a storage provider created for Dapr that leverages internal actors behind the scenes. Since Dapr Workflows use actors, you can store workflow state in state stores.
The engine is embedded directly into the sidecar and implemented using the [`durabletask-go`](https://github.com/dapr/durabletask-go) framework library. This framework allows you to swap out different storage providers, including a storage provider created for Dapr that leverages internal actors behind the scenes. Since Dapr Workflows use actors, you can store workflow state in state stores.
## Sidecar interactions

View File

@ -147,9 +147,9 @@ Learn more about [external system interaction.]({{< ref "workflow-patterns.md#ex
## Workflow backend
Dapr Workflow relies on the Durable Task Framework for Go (a.k.a. [durabletask-go](https://github.com/microsoft/durabletask-go)) as the core engine for executing workflows. This engine is designed to support multiple backend implementations. For example, the [durabletask-go](https://github.com/microsoft/durabletask-go) repo includes a SQLite implementation and the Dapr repo includes an Actors implementation.
Dapr Workflow relies on the Durable Task Framework for Go (a.k.a. [durabletask-go](https://github.com/dapr/durabletask-go)) as the core engine for executing workflows. This engine is designed to support multiple backend implementations. For example, the [durabletask-go](https://github.com/dapr/durabletask-go) repo includes a SQLite implementation and the Dapr repo includes an Actors implementation.
By default, Dapr Workflow supports the Actors backend, which is stable and scalable. However, you can choose a different backend supported in Dapr Workflow. For example, [SQLite](https://github.com/microsoft/durabletask-go/tree/main/backend/sqlite)(TBD future release) could be an option for backend for local development and testing.
By default, Dapr Workflow supports the Actors backend, which is stable and scalable. However, you can choose a different backend supported in Dapr Workflow. For example, [SQLite](https://github.com/dapr/durabletask-go/tree/main/backend/sqlite)(TBD future release) could be an option for backend for local development and testing.
The backend implementation is largely decoupled from the workflow core engine or the programming model that you see. The backend primarily impacts:
- How workflow state is stored
@ -232,7 +232,7 @@ Do this:
// Do this!!
DateTime currentTime = context.CurrentUtcDateTime;
Guid newIdentifier = context.NewGuid();
string randomString = await context.CallActivityAsync<string>("GetRandomString");
string randomString = await context.CallActivityAsync<string>(nameof("GetRandomString")); //Use "nameof" to prevent specifying an activity name that does not exist in your application
```
{{% /codetab %}}
@ -339,7 +339,7 @@ Do this:
```csharp
// Do this!!
string configuration = workflowInput.Configuration; // imaginary workflow input argument
string data = await context.CallActivityAsync<string>("MakeHttpCall", "https://example.com/api/data");
string data = await context.CallActivityAsync<string>(nameof("MakeHttpCall"), "https://example.com/api/data");
```
{{% /codetab %}}
@ -439,7 +439,7 @@ Do this:
```csharp
// Do this!!
Task t = context.CallActivityAsync("DoSomething");
Task t = context.CallActivityAsync(nameof("DoSomething"));
await context.CreateTimer(5000).ConfigureAwait(true);
```

View File

@ -305,7 +305,7 @@ The properties for the Multi-App Run template align with the `dapr run -k` CLI f
| `appMaxConcurrency` | N | The concurrency level of the application; default is unlimited | |
| `placementHostAddress` | N | Comma separated list of addresses for Dapr placement servers | `127.0.0.1:50057,127.0.0.1:50058` |
| `schedulerHostAddress` | N | Dapr Scheduler Service host address | `127.0.0.1:50006` |
| `appSSL` | N | Enable https when Dapr invokes the application | |
| `appSSL` | N | Enable HTTPS when Dapr invokes the application | |
| `maxBodySize` | N | Max size of the request body in MB. Set the value using size units (e.g., `16Mi` for 16MB). The default is `4Mi` | `16Mi` |
| `readBufferSize` | N | Max size of the HTTP read buffer in KB. This also limits the maximum size of HTTP headers. Set the value using size units, for example `32Ki` will support headers up to 32KB . Default is `4Ki` for 4KB | `32Ki` |
| `enableAppHealthCheck` | N | Enable the app health check on the application | `true`, `false` |

View File

@ -36,7 +36,7 @@ No matter which deployment approach you choose, it is important to understand th
{{% /alert %}}
### `DeamonSet`(Per-node)
### `DaemonSet`(Per-node)
With Kubernetes `DaemonSet`, you can define applications that need to be deployed once per node in the cluster. This enables applications that are running on the same node to communicate with local Dapr APIs, no matter where the Kubernetes `Scheduler` schedules your workload.