mirror of https://github.com/dapr/docs.git
Merge branch 'submodules_1.12' of https://github.com/hhunter-ms/docs into submodules_1.12
This commit is contained in:
Hannah Hunter
commit
24b9291bf6
|
|
@ -96,6 +96,10 @@ For more information on message routing, read [Dapr pub/sub API reference]({{< r
|
|||
|
||||
Sometimes, messages can't be processed because of a variety of possible issues, such as erroneous conditions within the producer or consumer application or an unexpected state change that causes an issue with your application code. Dapr allows developers to set dead letter topics to deal with messages that cannot be delivered to an application. This feature is available on all pub/sub components and prevents consumer applications from endlessly retrying a failed message. For more information, read about [dead letter topics]({{< ref "pubsub-deadletter.md">}})
|
||||
|
||||
### Enabling the outbox pattern
|
||||
|
||||
Dapr enables developers to use the outbox pattern for achieving a single transaction across a transactional state store and any message broker. For more information, read [How to enable transactional outbox messaging]({{< ref howto-outbox.md >}})
|
||||
|
||||
### Namespace consumer groups
|
||||
|
||||
Dapr solves multi-tenancy at-scale with [namespaces for consumer groups]({{< ref howto-namespace >}}). Simply include the `"{namespace}"` value in your component metadata for consumer groups to allow multiple namespaces with applications of the same `app-id` to publish and subscribe to the same message broker.
|
||||
|
|
|
|||
|
|
@ -79,6 +79,52 @@ localhost:3500/v1.0/invoke/<appID>/method/<my-method>
|
|||
curl http://localhost:3602/v1.0/invoke/orderprocessor/method/checkout
|
||||
```
|
||||
|
||||
## TLS authentication
|
||||
|
||||
Using the [HTTPEndpoint resource]({{< ref httpendpoints-schema.md >}}) allows you to use any combination of a root certificate, client certificate and private key according to the authentication requirements of the remote endpoint.
|
||||
|
||||
### Example using root certificate
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: HTTPEndpoint
|
||||
metadata:
|
||||
name: "external-http-endpoint-tls"
|
||||
spec:
|
||||
baseUrl: https://service-invocation-external:443
|
||||
headers:
|
||||
- name: "Accept-Language"
|
||||
value: "en-US"
|
||||
clientTLS:
|
||||
rootCA:
|
||||
secretKeyRef:
|
||||
name: dapr-tls-client
|
||||
key: ca.crt
|
||||
```
|
||||
|
||||
### Example using client certificate and private key
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: HTTPEndpoint
|
||||
metadata:
|
||||
name: "external-http-endpoint-tls"
|
||||
spec:
|
||||
baseUrl: https://service-invocation-external:443
|
||||
headers:
|
||||
- name: "Accept-Language"
|
||||
value: "en-US"
|
||||
clientTLS:
|
||||
certificate:
|
||||
secretKeyRef:
|
||||
name: dapr-tls-client
|
||||
key: tls.crt
|
||||
privateKey:
|
||||
secretKeyRef:
|
||||
name: dapr-tls-key
|
||||
key: tls.key
|
||||
```
|
||||
|
||||
## Related Links
|
||||
|
||||
- [HTTPEndpoint reference]({{< ref httpendpoints-schema.md >}})
|
||||
|
|
|
|||
|
|
@ -94,6 +94,21 @@ The diagram below shows an example of how this works. If you have 1 instance of
|
|||
|
||||
Dapr can run on a variety of [hosting platforms]({{< ref hosting >}}). To enable service discovery and service invocation, Dapr uses pluggable [name resolution components]({{< ref supported-name-resolution >}}). For example, the Kubernetes name resolution component uses the Kubernetes DNS service to resolve the location of other applications running in the cluster. Self-hosted machines can use the mDNS name resolution component. The Consul name resolution component can be used in any hosting environment, including Kubernetes or self-hosted.
|
||||
|
||||
### Streaming for HTTP service invocation
|
||||
|
||||
You can handle data as a stream in HTTP service invocation. This can offer improvements in performance and memory utilization when using Dapr to invoke another service using HTTP with large request or response bodies.
|
||||
|
||||
The diagram below demonstrates the six steps of data flow.
|
||||
|
||||
<img src="/images/service-invocation-simple.webp" width=600 alt="Diagram showing the steps of service invocation described in the table below" />
|
||||
|
||||
1. Request: "App A" to "Dapr sidecar A"
|
||||
1. Request: "Dapr sidecar A" to "Dapr sidecar B"
|
||||
1. Request: "Dapr sidecar B" to "App B"
|
||||
1. Response: "App B" to "Dapr sidecar B"
|
||||
1. Response: "Dapr sidecar B" to "Dapr sidecar A"
|
||||
1. Response: "Dapr sidecar A" to "App A"
|
||||
|
||||
## Example Architecture
|
||||
|
||||
Following the above call sequence, suppose you have the applications as described in the [Hello World tutorial](https://github.com/dapr/quickstarts/blob/master/tutorials/hello-world/README.md), where a python app invokes a node.js app. In such a scenario, the python app would be "Service A" , and a Node.js app would be "Service B".
|
||||
|
|
|
|||
|
|
@ -0,0 +1,112 @@
|
|||
---
|
||||
type: docs
|
||||
title: "How-To: Enable the transactional outbox pattern"
|
||||
linkTitle: "How-To: Enable the transactional outbox pattern"
|
||||
weight: 400
|
||||
description: "Commit a single transaction across a state store and pub/sub message broker"
|
||||
---
|
||||
|
||||
The transactional outbox pattern is a well known design pattern for sending notifications regarding changes in an application's state. The transactional outbox pattern uses a single transaction that spans across the database and the message broker delivering the notification.
|
||||
|
||||
Developers are faced with many difficult technical challenges when trying to implement this pattern on their own, which often involves writing error-prone central coordination managers that, at most, support a combination of one or two databases and message brokers.
|
||||
|
||||
For example, you can use the outbox pattern to:
|
||||
1. Write a new user record to an account database.
|
||||
1. Send a notification message that the account was successfully created.
|
||||
|
||||
With Dapr's outbox support, you can notify subscribers when an application's state is created or updated when calling Dapr's [transactions API]({{< ref "state_api.md#state-transactions" >}}).
|
||||
|
||||
The diagram below is an overview of how the outbox feature works:
|
||||
|
||||
1) Service A saves/updates state to the state store using a transaction.
|
||||
2) A message is written to the broker under the same transaction. When the message is successfully delivered to the message broker, the transaction completes, ensuring the state and message are transacted together.
|
||||
3) The message broker delivers the message topic to any subscribers - in this case, Service B.
|
||||
|
||||
<img src="/images/state-management-outbox.png" width=800 alt="Diagram showing the steps of the outbox pattern">
|
||||
|
||||
## Requirements
|
||||
|
||||
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.
|
||||
|
||||
{{% 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.
|
||||
{{% /alert %}}
|
||||
|
||||
## Usage
|
||||
|
||||
To enable the outbox feature, add the following required and optional fields on a state store component:
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Component
|
||||
metadata:
|
||||
name: mysql-outbox
|
||||
spec:
|
||||
type: state.mysql
|
||||
version: v1
|
||||
metadata:
|
||||
- name: connectionString
|
||||
value: "<CONNECTION STRING>"
|
||||
- name: outboxPublishPubsub # Required
|
||||
value: "mypubsub"
|
||||
- name: outboxPublishTopic # Required
|
||||
value: "newOrder"
|
||||
- name: outboxPubsub # Optional
|
||||
value: "myOutboxPubsub"
|
||||
- name: outboxDiscardWhenMissingState #Optional. Defaults to false
|
||||
value: false
|
||||
```
|
||||
|
||||
### Metadata fields
|
||||
|
||||
| Name | Required | Default Value | Description |
|
||||
| --------------------|-------------|---------------|------------------------------------------------------- |
|
||||
| outboxPublishPubsub | Yes | N/A | Sets the name of the pub/sub component to deliver the notifications when publishing state changes
|
||||
| outboxPublishTopic | Yes | N/A | Sets the topic that receives the state changes on the pub/sub configured with `outboxPublishPubsub`. The message body will be a state transaction item for an `insert` or `update` operation
|
||||
| outboxPubsub | No | `outboxPublishPubsub` | Sets the pub/sub component used by Dapr to coordinate the state and pub/sub transactions. If not set, the pub/sub component configured with `outboxPublishPubsub` is used. This is useful if you want to separate the pub/sub component used to send the notification state changes from the one used to coordinate the transaction
|
||||
| outboxDiscardWhenMissingState | No | `false` | By setting `outboxDiscardWhenMissingState` to `true`, Dapr discards the transaction if it cannot find the state in the database and does not retry. This setting can be useful if the state store data has been deleted for any reason before Dapr was able to deliver the message and you would like Dapr to drop the items from the pub/sub and stop retrying to fetch the state
|
||||
|
||||
### Combining outbox and non-outbox messages on the same state store
|
||||
|
||||
If you want to use the same state store for sending both outbox and non-outbox messages, simply define two state store components that connect to the same state store, where one has the outbox feature and the other does not.
|
||||
|
||||
#### MySQL state store without outbox
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Component
|
||||
metadata:
|
||||
name: mysql
|
||||
spec:
|
||||
type: state.mysql
|
||||
version: v1
|
||||
metadata:
|
||||
- name: connectionString
|
||||
value: "<CONNECTION STRING>"
|
||||
```
|
||||
|
||||
#### MySQL state store with outbox
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Component
|
||||
metadata:
|
||||
name: mysql-outbox
|
||||
spec:
|
||||
type: state.mysql
|
||||
version: v1
|
||||
metadata:
|
||||
- name: connectionString
|
||||
value: "<CONNECTION STRING>"
|
||||
- name: outboxPublishPubsub # Required
|
||||
value: "mypubsub"
|
||||
- name: outboxPublishTopic # Required
|
||||
value: "newOrder"
|
||||
```
|
||||
|
||||
## Demo
|
||||
|
||||
Watch [this video for an overview of the outbox pattern](https://youtu.be/rTovKpG0rhY?t=1338):
|
||||
|
||||
<div class="embed-responsive embed-responsive-16by9">
|
||||
<iframe width="360" height="315" src="https://youtu.be/rTovKpG0rhY?t=1338" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
|
|
@ -116,6 +116,10 @@ Dapr enables states to be:
|
|||
|
||||
For more details read [How-To: Share state between applications]({{< ref howto-share-state.md >}}),
|
||||
|
||||
### Enabling the outbox pattern
|
||||
|
||||
Dapr enables developers to use the outbox pattern for achieving a single transaction across a transactional state store and any message broker. For more information, read [How to enable transactional outbox messaging]({{< ref howto-outbox.md >}})
|
||||
|
||||
### Querying state
|
||||
|
||||
There are two ways to query the state:
|
||||
|
|
|
|||
|
|
@ -162,7 +162,7 @@ APIs that generate random numbers, random UUIDs, or the current date are _non-de
|
|||
|
||||
For example, instead of this:
|
||||
|
||||
{{< tabs ".NET" >}}
|
||||
{{< tabs ".NET" Java >}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
|
|
@ -175,11 +175,22 @@ string randomString = GetRandomString();
|
|||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
```java
|
||||
// DON'T DO THIS!
|
||||
Instant currentTime = Instant.now();
|
||||
UUID newIdentifier = UUID.randomUUID();
|
||||
string randomString = GetRandomString();
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{< /tabs >}}
|
||||
|
||||
Do this:
|
||||
|
||||
{{< tabs ".NET" >}}
|
||||
{{< tabs ".NET" Java >}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
|
|
@ -192,6 +203,17 @@ string randomString = await context.CallActivityAsync<string>("GetRandomString")
|
|||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
```java
|
||||
// Do this!!
|
||||
Instant currentTime = context.getCurrentInstant();
|
||||
Guid newIdentifier = context.NewGuid();
|
||||
String randomString = context.callActivity(GetRandomString.class.getName(), String.class).await();
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{< /tabs >}}
|
||||
|
||||
|
||||
|
|
@ -202,20 +224,58 @@ Instead, workflows should interact with external state _indirectly_ using workfl
|
|||
|
||||
For example, instead of this:
|
||||
|
||||
{{< tabs ".NET" Java >}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
```csharp
|
||||
// DON'T DO THIS!
|
||||
string configuration = Environment.GetEnvironmentVariable("MY_CONFIGURATION")!;
|
||||
string data = await new HttpClient().GetStringAsync("https://example.com/api/data");
|
||||
```
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
```java
|
||||
// DON'T DO THIS!
|
||||
String configuration = System.getenv("MY_CONFIGURATION");
|
||||
|
||||
HttpRequest request = HttpRequest.newBuilder().uri(new URI("https://postman-echo.com/post")).GET().build();
|
||||
HttpResponse<String> response = HttpClient.newBuilder().build().send(request, HttpResponse.BodyHandlers.ofString());
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{< /tabs >}}
|
||||
|
||||
Do this:
|
||||
|
||||
{{< tabs ".NET" Java >}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
```csharp
|
||||
// Do this!!
|
||||
string configuation = workflowInput.Configuration; // imaginary workflow input argument
|
||||
string data = await context.CallActivityAsync<string>("MakeHttpCall", "https://example.com/api/data");
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
```java
|
||||
// Do this!!
|
||||
String configuation = ctx.getInput(InputType.class).getConfiguration(); // imaginary workflow input argument
|
||||
String data = ctx.callActivity(MakeHttpCall.class, "https://example.com/api/data", String.class).await();
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{< /tabs >}}
|
||||
|
||||
|
||||
#### Workflow functions must execute only on the workflow dispatch thread.
|
||||
The implementation of each language SDK requires that all workflow function operations operate on the same thread (goroutine, etc.) that the function was scheduled on. Workflow functions must never:
|
||||
- Schedule background threads, or
|
||||
|
|
@ -225,20 +285,58 @@ Failure to follow this rule could result in undefined behavior. Any background p
|
|||
|
||||
For example, instead of this:
|
||||
|
||||
{{< tabs ".NET" Java >}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
```csharp
|
||||
// DON'T DO THIS!
|
||||
Task t = Task.Run(() => context.CallActivityAsync("DoSomething"));
|
||||
await context.CreateTimer(5000).ConfigureAwait(false);
|
||||
```
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
```java
|
||||
// DON'T DO THIS!
|
||||
new Thread(() -> {
|
||||
ctx.callActivity(DoSomethingActivity.class.getName()).await();
|
||||
}).start();
|
||||
ctx.createTimer(Duration.ofSeconds(5)).await();
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{< /tabs >}}
|
||||
|
||||
Do this:
|
||||
|
||||
{{< tabs ".NET" Java >}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
```csharp
|
||||
// Do this!!
|
||||
Task t = context.CallActivityAsync("DoSomething");
|
||||
await context.CreateTimer(5000).ConfigureAwait(true);
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
```java
|
||||
// Do this!!
|
||||
ctx.callActivity(DoSomethingActivity.class.getName()).await();
|
||||
ctx.createTimer(Duration.ofSeconds(5)).await();
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{< /tabs >}}
|
||||
|
||||
|
||||
### Updating workflow code
|
||||
|
||||
Make sure updates you make to the workflow code maintain its determinism. A couple examples of code updates that can break workflow determinism:
|
||||
|
|
|
|||
|
|
@ -464,7 +464,41 @@ public override async Task<object> RunAsync(WorkflowContext context, MyEntitySta
|
|||
<!--java-->
|
||||
|
||||
```java
|
||||
todo
|
||||
public class MonitorWorkflow extends Workflow {
|
||||
|
||||
@Override
|
||||
public WorkflowStub create() {
|
||||
return ctx -> {
|
||||
|
||||
Duration nextSleepInterval;
|
||||
|
||||
var status = ctx.callActivity(DemoWorkflowStatusActivity.class.getName(), DemoStatusActivityOutput.class).await();
|
||||
var isHealthy = status.getIsHealthy();
|
||||
|
||||
if (isHealthy) {
|
||||
// Check less frequently when in a healthy state
|
||||
nextSleepInterval = Duration.ofMinutes(60);
|
||||
} else {
|
||||
|
||||
ctx.callActivity(DemoWorkflowAlertActivity.class.getName()).await();
|
||||
|
||||
// Check more frequently when in an unhealthy state
|
||||
nextSleepInterval = Duration.ofMinutes(5);
|
||||
}
|
||||
|
||||
// Put the workflow to sleep until the determined time
|
||||
// Note: ctx.createTimer() method is not supported in the Java SDK yet
|
||||
try {
|
||||
TimeUnit.SECONDS.sleep(nextSleepInterval.getSeconds());
|
||||
} catch (InterruptedException e) {
|
||||
throw new RuntimeException(e);
|
||||
}
|
||||
|
||||
// Restart from the beginning with the updated state
|
||||
ctx.continueAsNew();
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ Let's take a look at Dapr's [Bindings building block]({{< ref bindings >}}). Usi
|
|||
- Trigger your app with events coming in from external systems.
|
||||
- Interface with external systems.
|
||||
|
||||
In this Quickstart, you will schedule a batch script to run every 10 seconds using an input [Cron]({{< ref cron.md >}}) binding. The script processes a JSON file and outputs data to a SQL database using the [PostgreSQL]({{< ref postgresql.md >}}) Dapr binding.
|
||||
In this Quickstart, you schedule a batch script to run every 10 seconds using an input [Cron]({{< ref cron.md >}}) binding. The script processes a JSON file and outputs data to a SQL database using the [PostgreSQL]({{< ref postgresql.md >}}) Dapr binding.
|
||||
|
||||
<img src="/images/bindings-quickstart/bindings-quickstart.png" width=800 style="padding-bottom:15px;">
|
||||
|
||||
|
|
|
|||
|
|
@ -14,6 +14,757 @@ Let's take a look at Dapr's [Publish and Subscribe (Pub/sub) building block]({{<
|
|||
|
||||
<img src="/images/pubsub-quickstart/pubsub-diagram.png" width=800 style="padding-bottom:15px;">
|
||||
|
||||
You can try out this pub/sub quickstart by either:
|
||||
|
||||
- [Running all applications in this sample simultaneously with the Multi-App Run template file]({{< ref "#run-using-multi-app-run" >}}), or
|
||||
- [Running one application at a time]({{< ref "#run-one-application-at-a-time" >}})
|
||||
|
||||
## Run using Multi-App Run
|
||||
|
||||
Select your preferred language-specific Dapr SDK before proceeding with the Quickstart.
|
||||
|
||||
{{< tabs "Python" "JavaScript" ".NET" "Java" "Go" >}}
|
||||
<!-- Python -->
|
||||
{{% codetab %}}
|
||||
|
||||
### Step 1: Pre-requisites
|
||||
|
||||
For this example, you will need:
|
||||
|
||||
- [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started).
|
||||
- [Python 3.7+ installed](https://www.python.org/downloads/).
|
||||
<!-- IGNORE_LINKS -->
|
||||
- [Docker Desktop](https://www.docker.com/products/docker-desktop)
|
||||
<!-- END_IGNORE -->
|
||||
|
||||
### Step 2: Set up the environment
|
||||
|
||||
Clone the [sample provided in the Quickstarts repo](https://github.com/dapr/quickstarts/tree/master/pub_sub).
|
||||
|
||||
```bash
|
||||
git clone https://github.com/dapr/quickstarts.git
|
||||
```
|
||||
|
||||
From the root of the Quickstarts directory, navigate into the pub/sub directory:
|
||||
|
||||
```bash
|
||||
cd pub_sub/python/sdk
|
||||
```
|
||||
|
||||
### Step 3: Run the publisher and subscriber
|
||||
|
||||
With the following command, simultaneously run the following services alongside their own Dapr sidecars:
|
||||
- The `order-processor` subscriber
|
||||
- The `checkout` publisher
|
||||
|
||||
```bash
|
||||
dapr run -f .
|
||||
```
|
||||
|
||||
**Expected output**
|
||||
|
||||
```
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 1 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 1 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 2 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 2 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 3 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 3 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 4 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 4 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 5 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 5 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 6 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 6 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 7 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 7 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 8 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 8 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 9 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 9 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 10 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 10 }
|
||||
Exited App successfully
|
||||
```
|
||||
|
||||
### What happened?
|
||||
|
||||
When you ran `dapr init` during Dapr install, the following YAML files were generated in the `.dapr/components` directory:
|
||||
- [`dapr.yaml` Multi-App Run template file]({{< ref "#dapryaml-multi-app-run-template-file" >}})
|
||||
- [`pubsub.yaml` component file]({{< ref "#pubsubyaml-component-file" >}})
|
||||
|
||||
Running `dapr run -f .` in this Quickstart started both the [subscriber]({{< ref "#order-processor-subscriber" >}}) and [publisher]({{< ref "#checkout-publisher" >}}) applications.
|
||||
|
||||
##### `dapr.yaml` Multi-App Run template file
|
||||
|
||||
Running the [Multi-App Run template file]({{< ref multi-app-dapr-run >}}) with `dapr run -f .` starts all applications in your project. In this Quickstart, the `dapr.yaml` file contains the following:
|
||||
|
||||
```yml
|
||||
version: 1
|
||||
common:
|
||||
resourcesPath: ../../components/
|
||||
apps:
|
||||
- appID: order-processor-sdk
|
||||
appDirPath: ./order-processor/
|
||||
appPort: 6001
|
||||
command: ["uvicorn", "app:app"]
|
||||
- appID: checkout-sdk
|
||||
appDirPath: ./checkout/
|
||||
command: ["python3", "app.py"]
|
||||
```
|
||||
|
||||
##### `pubsub.yaml` component file
|
||||
|
||||
With the `pubsub.yaml` component, you can easily swap out underlying components without application code changes.
|
||||
|
||||
The Redis `pubsub.yaml` file included for this Quickstart contains the following:
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Component
|
||||
metadata:
|
||||
name: orderpubsub
|
||||
spec:
|
||||
type: pubsub.redis
|
||||
version: v1
|
||||
metadata:
|
||||
- name: redisHost
|
||||
value: localhost:6379
|
||||
- name: redisPassword
|
||||
value: ""
|
||||
```
|
||||
|
||||
In the component YAML file:
|
||||
|
||||
- `metadata/name` is how your application talks to the component.
|
||||
- `spec/metadata` defines the connection to the instance of the component.
|
||||
- `scopes` specify which application can use the component.
|
||||
|
||||
##### `order-processor` subscriber
|
||||
|
||||
In the `order-processor` subscriber, you subscribe to the Redis instance called `orderpubsub` [(as defined in the `pubsub.yaml` component)]({{< ref "#pubsubyaml-component-file" >}}) and topic `orders`. This enables your app code to talk to the Redis component instance through the Dapr sidecar.
|
||||
|
||||
```py
|
||||
# Register Dapr pub/sub subscriptions
|
||||
@app.route('/dapr/subscribe', methods=['GET'])
|
||||
def subscribe():
|
||||
subscriptions = [{
|
||||
'pubsubname': 'orderpubsub',
|
||||
'topic': 'orders',
|
||||
'route': 'orders'
|
||||
}]
|
||||
print('Dapr pub/sub is subscribed to: ' + json.dumps(subscriptions))
|
||||
return jsonify(subscriptions)
|
||||
|
||||
|
||||
# Dapr subscription in /dapr/subscribe sets up this route
|
||||
@app.route('/orders', methods=['POST'])
|
||||
def orders_subscriber():
|
||||
event = from_http(request.headers, request.get_data())
|
||||
print('Subscriber received : ' + event.data['orderid'], flush=True)
|
||||
return json.dumps({'success': True}), 200, {
|
||||
'ContentType': 'application/json'}
|
||||
|
||||
|
||||
app.run(port=5001)
|
||||
```
|
||||
|
||||
##### `checkout` publisher
|
||||
|
||||
In the `checkout` publisher, you publish the orderId message to the Redis instance called `orderpubsub` [(as defined in the `pubsub.yaml` component)]({{< ref "#pubsubyaml-component-file" >}}) and topic `orders`. As soon as the service starts, it publishes in a loop:
|
||||
|
||||
```python
|
||||
with DaprClient() as client:
|
||||
# Publish an event/message using Dapr PubSub
|
||||
result = client.publish_event(
|
||||
pubsub_name='orderpubsub',
|
||||
topic_name='orders',
|
||||
data=json.dumps(order),
|
||||
data_content_type='application/json',
|
||||
)
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
<!-- JavaScript -->
|
||||
{{% codetab %}}
|
||||
|
||||
### Step 1: Pre-requisites
|
||||
|
||||
For this example, you will need:
|
||||
|
||||
- [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started).
|
||||
- [Latest Node.js installed](https://nodejs.org/download/).
|
||||
<!-- IGNORE_LINKS -->
|
||||
- [Docker Desktop](https://www.docker.com/products/docker-desktop)
|
||||
<!-- END_IGNORE -->
|
||||
|
||||
### Step 2: Set up the environment
|
||||
|
||||
Clone the [sample provided in the Quickstarts repo](https://github.com/dapr/quickstarts/tree/master/pub_sub).
|
||||
|
||||
```bash
|
||||
git clone https://github.com/dapr/quickstarts.git
|
||||
```
|
||||
|
||||
From the root of the Quickstarts directory, navigate into the pub/sub directory:
|
||||
|
||||
```bash
|
||||
cd pub_sub/javascript/sdk
|
||||
```
|
||||
|
||||
### Step 3: Run the publisher and subscriber
|
||||
|
||||
With the following command, simultaneously run the following services alongside their own Dapr sidecars:
|
||||
- The `order-processor` subscriber
|
||||
- The `checkout` publisher
|
||||
|
||||
```bash
|
||||
dapr run -f .
|
||||
```
|
||||
|
||||
**Expected output**
|
||||
|
||||
```
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 1 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 1 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 2 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 2 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 3 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 3 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 4 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 4 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 5 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 5 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 6 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 6 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 7 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 7 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 8 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 8 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 9 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 9 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 10 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 10 }
|
||||
Exited App successfully
|
||||
```
|
||||
|
||||
### What happened?
|
||||
|
||||
When you ran `dapr init` during Dapr install, the following YAML files were generated in the `.dapr/components` directory:
|
||||
- [`dapr.yaml` Multi-App Run template file]({{< ref "#dapryaml-multi-app-run-template-file" >}})
|
||||
- [`pubsub.yaml` component file]({{< ref "#pubsubyaml-component-file" >}})
|
||||
|
||||
Running `dapr run -f .` in this Quickstart started both the [subscriber]({{< ref "#order-processor-subscriber" >}}) and [publisher]({{< ref "#checkout-publisher" >}}) applications.
|
||||
|
||||
##### `dapr.yaml` Multi-App Run template file
|
||||
|
||||
Running the [Multi-App Run template file]({{< ref multi-app-dapr-run >}}) with `dapr run -f .` starts all applications in your project. In this Quickstart, the `dapr.yaml` file contains the following:
|
||||
|
||||
```yml
|
||||
version: 1
|
||||
common:
|
||||
resourcesPath: ../../components/
|
||||
apps:
|
||||
- appID: order-processor
|
||||
appDirPath: ./order-processor/
|
||||
appPort: 5002
|
||||
command: ["npm", "run", "start"]
|
||||
- appID: checkout-sdk
|
||||
appDirPath: ./checkout/
|
||||
command: ["npm", "run", "start"]
|
||||
```
|
||||
|
||||
##### `pubsub.yaml` component file
|
||||
|
||||
With the `pubsub.yaml` component, you can easily swap out underlying components without application code changes.
|
||||
|
||||
The Redis `pubsub.yaml` file included for this Quickstart contains the following:
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Component
|
||||
metadata:
|
||||
name: orderpubsub
|
||||
spec:
|
||||
type: pubsub.redis
|
||||
version: v1
|
||||
metadata:
|
||||
- name: redisHost
|
||||
value: localhost:6379
|
||||
- name: redisPassword
|
||||
value: ""
|
||||
```
|
||||
|
||||
In the component YAML file:
|
||||
|
||||
- `metadata/name` is how your application talks to the component.
|
||||
- `spec/metadata` defines the connection to the instance of the component.
|
||||
- `scopes` specify which application can use the component.
|
||||
|
||||
##### `order-processor` subscriber
|
||||
|
||||
In the `order-processor` subscriber, you subscribe to the Redis instance called `orderpubsub` [(as defined in the `pubsub.yaml` component)]({{< ref "#pubsubyaml-component-file" >}}) and topic `orders`. This enables your app code to talk to the Redis component instance through the Dapr sidecar.
|
||||
|
||||
```js
|
||||
server.pubsub.subscribe("orderpubsub", "orders", (data) => console.log("Subscriber received: " + JSON.stringify(data)));
|
||||
```
|
||||
|
||||
##### `checkout` publisher
|
||||
|
||||
In the `checkout` publisher service, you publish the orderId message to the Redis instance called `orderpubsub` [(as defined in the `pubsub.yaml` component)]({{< ref "#pubsubyaml-component-file" >}}) and topic `orders`. As soon as the service starts, it publishes in a loop:
|
||||
|
||||
```js
|
||||
const client = new DaprClient();
|
||||
|
||||
await client.pubsub.publish(PUBSUB_NAME, PUBSUB_TOPIC, order);
|
||||
console.log("Published data: " + JSON.stringify(order));
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
<!-- .NET -->
|
||||
{{% codetab %}}
|
||||
|
||||
### Step 1: Pre-requisites
|
||||
|
||||
For this example, you will need:
|
||||
|
||||
- [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started).
|
||||
- [.NET SDK or .NET 6 SDK installed](https://dotnet.microsoft.com/download).
|
||||
<!-- IGNORE_LINKS -->
|
||||
- [Docker Desktop](https://www.docker.com/products/docker-desktop)
|
||||
<!-- END_IGNORE -->
|
||||
|
||||
### Step 2: Set up the environment
|
||||
|
||||
Clone the [sample provided in the Quickstarts repo](https://github.com/dapr/quickstarts/tree/master/pub_sub).
|
||||
|
||||
```bash
|
||||
git clone https://github.com/dapr/quickstarts.git
|
||||
```
|
||||
|
||||
From the root of the Quickstarts directory, navigate into the pub/sub directory:
|
||||
|
||||
```bash
|
||||
cd pub_sub/csharp/sdk
|
||||
```
|
||||
|
||||
### Step 3: Run the publisher and subscriber
|
||||
|
||||
With the following command, simultaneously run the following services alongside their own Dapr sidecars:
|
||||
- The `order-processor` subscriber
|
||||
- The `checkout` publisher
|
||||
|
||||
```bash
|
||||
dapr run -f .
|
||||
```
|
||||
|
||||
**Expected output**
|
||||
|
||||
```
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 1 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 1 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 2 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 2 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 3 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 3 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 4 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 4 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 5 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 5 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 6 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 6 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 7 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 7 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 8 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 8 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 9 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 9 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 10 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 10 }
|
||||
Exited App successfully
|
||||
```
|
||||
|
||||
### What happened?
|
||||
|
||||
When you ran `dapr init` during Dapr install, the following YAML files were generated in the `.dapr/components` directory:
|
||||
- [`dapr.yaml` Multi-App Run template file]({{< ref "#dapryaml-multi-app-run-template-file" >}})
|
||||
- [`pubsub.yaml` component file]({{< ref "#pubsubyaml-component-file" >}})
|
||||
|
||||
Running `dapr run -f .` in this Quickstart started both the [subscriber]({{< ref "#order-processor-subscriber" >}}) and [publisher]({{< ref "#checkout-publisher" >}}) applications.
|
||||
|
||||
##### `dapr.yaml` Multi-App Run template file
|
||||
|
||||
Running the [Multi-App Run template file]({{< ref multi-app-dapr-run >}}) with `dapr run -f .` starts all applications in your project. In this Quickstart, the `dapr.yaml` file contains the following:
|
||||
|
||||
```yml
|
||||
version: 1
|
||||
common:
|
||||
resourcesPath: ../../components/
|
||||
apps:
|
||||
- appID: order-processor
|
||||
appDirPath: ./order-processor/
|
||||
appPort: 7006
|
||||
command: ["dotnet", "run"]
|
||||
- appID: checkout-sdk
|
||||
appDirPath: ./checkout/
|
||||
command: ["dotnet", "run"]
|
||||
```
|
||||
|
||||
##### `pubsub.yaml` component file
|
||||
|
||||
With the `pubsub.yaml` component, you can easily swap out underlying components without application code changes.
|
||||
|
||||
The Redis `pubsub.yaml` file included for this Quickstart contains the following:
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Component
|
||||
metadata:
|
||||
name: orderpubsub
|
||||
spec:
|
||||
type: pubsub.redis
|
||||
version: v1
|
||||
metadata:
|
||||
- name: redisHost
|
||||
value: localhost:6379
|
||||
- name: redisPassword
|
||||
value: ""
|
||||
```
|
||||
|
||||
In the component YAML file:
|
||||
|
||||
- `metadata/name` is how your application talks to the component.
|
||||
- `spec/metadata` defines the connection to the instance of the component.
|
||||
- `scopes` specify which application can use the component.
|
||||
|
||||
##### `order-processor` subscriber
|
||||
|
||||
In the `order-processor` subscriber, you subscribe to the Redis instance called `orderpubsub` [(as defined in the `pubsub.yaml` component)]({{< ref "#pubsubyaml-component-file" >}}) and topic `orders`. This enables your app code to talk to the Redis component instance through the Dapr sidecar.
|
||||
|
||||
```cs
|
||||
// Dapr subscription in [Topic] routes orders topic to this route
|
||||
app.MapPost("/orders", [Topic("orderpubsub", "orders")] (Order order) => {
|
||||
Console.WriteLine("Subscriber received : " + order);
|
||||
return Results.Ok(order);
|
||||
});
|
||||
|
||||
public record Order([property: JsonPropertyName("orderId")] int OrderId);
|
||||
```
|
||||
|
||||
##### `checkout` publisher
|
||||
|
||||
In the `checkout` publisher, you publish the orderId message to the Redis instance called `orderpubsub` [(as defined in the `pubsub.yaml` component)]({{< ref "#pubsubyaml-component-file" >}}) and topic `orders`. As soon as the service starts, it publishes in a loop:
|
||||
|
||||
```cs
|
||||
using var client = new DaprClientBuilder().Build();
|
||||
await client.PublishEventAsync("orderpubsub", "orders", order);
|
||||
Console.WriteLine("Published data: " + order);
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
<!-- Java -->
|
||||
{{% codetab %}}
|
||||
|
||||
### Step 1: Pre-requisites
|
||||
|
||||
For this example, you will need:
|
||||
|
||||
- [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started).
|
||||
- Java JDK 11 (or greater):
|
||||
- [Oracle JDK](https://www.oracle.com/java/technologies/downloads), or
|
||||
- OpenJDK
|
||||
- [Apache Maven](https://maven.apache.org/install.html), version 3.x.
|
||||
<!-- IGNORE_LINKS -->
|
||||
- [Docker Desktop](https://www.docker.com/products/docker-desktop)
|
||||
<!-- END_IGNORE -->
|
||||
|
||||
### Step 2: Set up the environment
|
||||
|
||||
Clone the [sample provided in the Quickstarts repo](https://github.com/dapr/quickstarts/tree/master/pub_sub).
|
||||
|
||||
```bash
|
||||
git clone https://github.com/dapr/quickstarts.git
|
||||
```
|
||||
|
||||
From the root of the Quickstarts directory, navigate into the pub/sub directory:
|
||||
|
||||
```bash
|
||||
cd pub_sub/java/sdk
|
||||
```
|
||||
|
||||
### Step 3: Run the publisher and subscriber
|
||||
|
||||
With the following command, simultaneously run the following services alongside their own Dapr sidecars:
|
||||
- The `order-processor` subscriber
|
||||
- The `checkout` publisher
|
||||
|
||||
```bash
|
||||
dapr run -f .
|
||||
```
|
||||
|
||||
**Expected output**
|
||||
|
||||
```
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 1 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 1 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 2 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 2 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 3 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 3 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 4 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 4 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 5 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 5 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 6 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 6 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 7 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 7 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 8 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 8 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 9 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 9 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 10 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 10 }
|
||||
Exited App successfully
|
||||
```
|
||||
|
||||
### What happened?
|
||||
|
||||
When you ran `dapr init` during Dapr install, the following YAML files were generated in the `.dapr/components` directory:
|
||||
- [`dapr.yaml` Multi-App Run template file]({{< ref "#dapryaml-multi-app-run-template-file" >}})
|
||||
- [`pubsub.yaml` component file]({{< ref "#pubsubyaml-component-file" >}})
|
||||
|
||||
Running `dapr run -f .` in this Quickstart started both the [subscriber]({{< ref "#order-processor-subscriber" >}}) and [publisher]({{< ref "#checkout-publisher" >}}) applications.
|
||||
|
||||
##### `dapr.yaml` Multi-App Run template file
|
||||
|
||||
Running the [Multi-App Run template file]({{< ref multi-app-dapr-run >}}) with `dapr run -f .` starts all applications in your project. In this Quickstart, the `dapr.yaml` file contains the following:
|
||||
|
||||
```yml
|
||||
version: 1
|
||||
common:
|
||||
resourcesPath: ../../components/
|
||||
apps:
|
||||
- appID: order-processor-sdk
|
||||
appDirPath: ./order-processor/target/
|
||||
appPort: 8080
|
||||
command: ["java", "-jar", "OrderProcessingService-0.0.1-SNAPSHOT.jar"]
|
||||
- appID: checkout-sdk
|
||||
appDirPath: ./checkout/target/
|
||||
command: ["java", "-jar", "CheckoutService-0.0.1-SNAPSHOT.jar"]
|
||||
```
|
||||
|
||||
##### `pubsub.yaml` component file
|
||||
|
||||
With the `pubsub.yaml` component, you can easily swap out underlying components without application code changes.
|
||||
|
||||
The Redis `pubsub.yaml` file included for this Quickstart contains the following:
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Component
|
||||
metadata:
|
||||
name: orderpubsub
|
||||
spec:
|
||||
type: pubsub.redis
|
||||
version: v1
|
||||
metadata:
|
||||
- name: redisHost
|
||||
value: localhost:6379
|
||||
- name: redisPassword
|
||||
value: ""
|
||||
```
|
||||
|
||||
In the component YAML file:
|
||||
|
||||
- `metadata/name` is how your application talks to the component.
|
||||
- `spec/metadata` defines the connection to the instance of the component.
|
||||
- `scopes` specify which application can use the component.
|
||||
|
||||
##### `order-processor` subscriber
|
||||
|
||||
In the `order-processor` subscriber, you subscribe to the Redis instance called `orderpubsub` [(as defined in the `pubsub.yaml` component)]({{< ref "#pubsubyaml-component-file" >}}) and topic `orders`. This enables your app code to talk to the Redis component instance through the Dapr sidecar.
|
||||
|
||||
```java
|
||||
@Topic(name = "orders", pubsubName = "orderpubsub")
|
||||
@PostMapping(path = "/orders", consumes = MediaType.ALL_VALUE)
|
||||
public Mono<ResponseEntity> getCheckout(@RequestBody(required = false) CloudEvent<Order> cloudEvent) {
|
||||
return Mono.fromSupplier(() -> {
|
||||
try {
|
||||
logger.info("Subscriber received: " + cloudEvent.getData().getOrderId());
|
||||
return ResponseEntity.ok("SUCCESS");
|
||||
} catch (Exception e) {
|
||||
throw new RuntimeException(e);
|
||||
}
|
||||
});
|
||||
}
|
||||
```
|
||||
|
||||
##### `checkout` publisher
|
||||
|
||||
In the `checkout` publisher, you publish the orderId message to the Redis instance called `orderpubsub` [(as defined in the `pubsub.yaml` component)]({{< ref "#pubsubyaml-component-file" >}}) and topic `orders`. As soon as the service starts, it publishes in a loop:
|
||||
|
||||
```java
|
||||
DaprClient client = new DaprClientBuilder().build();
|
||||
client.publishEvent(
|
||||
PUBSUB_NAME,
|
||||
TOPIC_NAME,
|
||||
order).block();
|
||||
logger.info("Published data: " + order.getOrderId());
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
<!-- Go -->
|
||||
{{% codetab %}}
|
||||
|
||||
### Step 1: Pre-requisites
|
||||
|
||||
For this example, you will need:
|
||||
|
||||
- [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started).
|
||||
- [Latest version of Go](https://go.dev/dl/).
|
||||
<!-- IGNORE_LINKS -->
|
||||
- [Docker Desktop](https://www.docker.com/products/docker-desktop)
|
||||
<!-- END_IGNORE -->
|
||||
|
||||
### Step 2: Set up the environment
|
||||
|
||||
Clone the [sample provided in the Quickstarts repo](https://github.com/dapr/quickstarts/tree/master/pub_sub).
|
||||
|
||||
```bash
|
||||
git clone https://github.com/dapr/quickstarts.git
|
||||
```
|
||||
|
||||
From the root of the Quickstarts directory, navigate into the pub/sub directory:
|
||||
|
||||
```bash
|
||||
cd pub_sub/go/sdk
|
||||
```
|
||||
|
||||
### Step 3: Run the publisher and subscriber
|
||||
|
||||
With the following command, simultaneously run the following services alongside their own Dapr sidecars:
|
||||
- The `order-processor` subscriber
|
||||
- The `checkout` publisher
|
||||
|
||||
```bash
|
||||
dapr run -f .
|
||||
```
|
||||
|
||||
**Expected output**
|
||||
|
||||
```
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 1 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 1 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 2 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 2 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 3 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 3 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 4 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 4 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 5 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 5 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 6 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 6 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 7 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 7 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 8 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 8 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 9 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 9 }
|
||||
== APP - checkout-sdk == Published data: Order { OrderId = 10 }
|
||||
== APP - order-processor == Subscriber received : Order { OrderId = 10 }
|
||||
Exited App successfully
|
||||
```
|
||||
|
||||
### What happened?
|
||||
|
||||
When you ran `dapr init` during Dapr install, the following YAML files were generated in the `.dapr/components` directory:
|
||||
- [`dapr.yaml` Multi-App Run template file]({{< ref "#dapryaml-multi-app-run-template-file" >}})
|
||||
- [`pubsub.yaml` component file]({{< ref "#pubsubyaml-component-file" >}})
|
||||
|
||||
Running `dapr run -f .` in this Quickstart started both the [subscriber]({{< ref "#order-processor-subscriber" >}}) and [publisher]({{< ref "#checkout-publisher" >}}) applications.
|
||||
|
||||
##### `dapr.yaml` Multi-App Run template file
|
||||
|
||||
Running the [Multi-App Run template file]({{< ref multi-app-dapr-run >}}) with `dapr run -f .` starts all applications in your project. In this Quickstart, the `dapr.yaml` file contains the following:
|
||||
|
||||
```yml
|
||||
version: 1
|
||||
common:
|
||||
resourcesPath: ../../components/
|
||||
apps:
|
||||
- appID: order-processor
|
||||
appDirPath: ./order-processor/
|
||||
appPort: 6005
|
||||
command: ["go", "run", "."]
|
||||
- appID: checkout-sdk
|
||||
appDirPath: ./checkout/
|
||||
command: ["go", "run", "."]
|
||||
```
|
||||
|
||||
##### `pubsub.yaml` component file
|
||||
|
||||
With the `pubsub.yaml` component, you can easily swap out underlying components without application code changes.
|
||||
|
||||
The Redis `pubsub.yaml` file included for this Quickstart contains the following:
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Component
|
||||
metadata:
|
||||
name: orderpubsub
|
||||
spec:
|
||||
type: pubsub.redis
|
||||
version: v1
|
||||
metadata:
|
||||
- name: redisHost
|
||||
value: localhost:6379
|
||||
- name: redisPassword
|
||||
value: ""
|
||||
```
|
||||
|
||||
In the component YAML file:
|
||||
|
||||
- `metadata/name` is how your application talks to the component.
|
||||
- `spec/metadata` defines the connection to the instance of the component.
|
||||
- `scopes` specify which application can use the component.
|
||||
|
||||
##### `order-processor` subscriber
|
||||
|
||||
In the `order-processor` subscriber, you subscribe to the Redis instance called `orderpubsub` [(as defined in the `pubsub.yaml` component)]({{< ref "#pubsubyaml-component-file" >}}) and topic `orders`. This enables your app code to talk to the Redis component instance through the Dapr sidecar.
|
||||
|
||||
```go
|
||||
func eventHandler(ctx context.Context, e *common.TopicEvent) (retry bool, err error) {
|
||||
fmt.Println("Subscriber received: ", e.Data)
|
||||
return false, nil
|
||||
}
|
||||
```
|
||||
|
||||
##### `checkout` publisher
|
||||
|
||||
In the `checkout` publisher, you publish the orderId message to the Redis instance called `orderpubsub` [(as defined in the `pubsub.yaml` component)]({{< ref "#pubsubyaml-component-file" >}}) and topic `orders`. As soon as the service starts, it publishes in a loop:
|
||||
|
||||
```go
|
||||
client, err := dapr.NewClient()
|
||||
|
||||
if err := client.PublishEvent(ctx, PUBSUB_NAME, PUBSUB_TOPIC, []byte(order)); err != nil {
|
||||
panic(err)
|
||||
}
|
||||
|
||||
fmt.Println("Published data: ", order)
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{< /tabs >}}
|
||||
|
||||
## Run one application at a time
|
||||
|
||||
Select your preferred language-specific Dapr SDK before proceeding with the Quickstart.
|
||||
|
||||
{{< tabs "Python" "JavaScript" ".NET" "Java" "Go" >}}
|
||||
|
|
@ -157,7 +908,7 @@ Subscriber output:
|
|||
== APP == INFO:root:Subscriber received: {"orderId": 10}
|
||||
```
|
||||
|
||||
#### `pubsub.yaml` component file
|
||||
##### `pubsub.yaml` component file
|
||||
|
||||
When you run `dapr init`, Dapr creates a default Redis `pubsub.yaml` and runs a Redis container on your local machine, located:
|
||||
|
||||
|
|
@ -315,7 +1066,7 @@ Subscriber output:
|
|||
|
||||
```
|
||||
|
||||
#### `pubsub.yaml` component file
|
||||
##### `pubsub.yaml` component file
|
||||
|
||||
When you run `dapr init`, Dapr creates a default Redis `pubsub.yaml` and runs a Redis container on your local machine, located:
|
||||
|
||||
|
|
@ -468,7 +1219,7 @@ Subscriber output:
|
|||
== APP == Subscriber received: Order { OrderId = 10 }
|
||||
```
|
||||
|
||||
#### `pubsub.yaml` component file
|
||||
##### `pubsub.yaml` component file
|
||||
|
||||
When you run `dapr init`, Dapr creates a default Redis `pubsub.yaml` and runs a Redis container on your local machine, located:
|
||||
|
||||
|
|
@ -630,7 +1381,7 @@ Subscriber output:
|
|||
== APP == 2022-03-07 13:31:37.919 INFO 43512 --- [nio-8080-exec-2] c.s.c.OrderProcessingServiceController : Subscriber received: 10
|
||||
```
|
||||
|
||||
#### `pubsub.yaml` component file
|
||||
##### `pubsub.yaml` component file
|
||||
|
||||
When you run `dapr init`, Dapr creates a default Redis `pubsub.yaml` and runs a Redis container on your local machine, located:
|
||||
|
||||
|
|
@ -788,7 +1539,7 @@ Subscriber output:
|
|||
|
||||
Note: the order in which they are received may vary.
|
||||
|
||||
#### `pubsub.yaml` component file
|
||||
##### `pubsub.yaml` component file
|
||||
|
||||
When you run `dapr init`, Dapr creates a default Redis `pubsub.yaml` and runs a Redis container on your local machine, located:
|
||||
|
||||
|
|
|
|||
|
|
@ -10,10 +10,678 @@ With [Dapr's Service Invocation building block](https://docs.dapr.io/developing-
|
|||
|
||||
<img src="/images/serviceinvocation-quickstart/service-invocation-overview.png" width=800 alt="Diagram showing the steps of service invocation" style="padding-bottom:25px;">
|
||||
|
||||
Dapr offers several methods for service invocation, which you can choose depending on your scenario. For this Quickstart, you'll enable the checkout service to invoke a method using HTTP proxy in the order-processor service.
|
||||
Dapr offers several methods for service invocation, which you can choose depending on your scenario. For this Quickstart, you'll enable the checkout service to invoke a method using HTTP proxy in the order-processor service and by either:
|
||||
- [Running all applications in this sample simultaneously with the Multi-App Run template file]({{< ref "#run-using-multi-app-run" >}}), or
|
||||
- [Running one application at a time]({{< ref "#run-one-application-at-a-time" >}})
|
||||
|
||||
Learn more about Dapr's methods for service invocation in the [overview article]({{< ref service-invocation-overview.md >}}).
|
||||
|
||||
## Run using Multi-App Run
|
||||
|
||||
Select your preferred language before proceeding with the Quickstart.
|
||||
|
||||
{{< tabs "Python" "JavaScript" ".NET" "Java" "Go" >}}
|
||||
<!-- Python -->
|
||||
{{% codetab %}}
|
||||
|
||||
### Step 1: Pre-requisites
|
||||
|
||||
For this example, you will need:
|
||||
|
||||
- [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started).
|
||||
- [Python 3.7+ installed](https://www.python.org/downloads/).
|
||||
<!-- IGNORE_LINKS -->
|
||||
- [Docker Desktop](https://www.docker.com/products/docker-desktop)
|
||||
<!-- END_IGNORE -->
|
||||
|
||||
### Step 2: Set up the environment
|
||||
|
||||
Clone the [sample provided in the Quickstarts repo](https://github.com/dapr/quickstarts/tree/master/service_invocation).
|
||||
|
||||
```bash
|
||||
git clone https://github.com/dapr/quickstarts.git
|
||||
```
|
||||
|
||||
From the root of the Quickstart clone directory, navigate to the quickstart directory.
|
||||
|
||||
```bash
|
||||
cd service_invocation/python/http
|
||||
```
|
||||
|
||||
### Step 3: Run the `order-processor` and `checkout` services
|
||||
|
||||
With the following command, simultaneously run the following services alongside their own Dapr sidecars:
|
||||
- The `order-processor` service
|
||||
- The `checkout` service
|
||||
|
||||
```bash
|
||||
dapr run -f .
|
||||
```
|
||||
|
||||
**Expected output**
|
||||
|
||||
```
|
||||
== APP - order-processor == Order received : Order { orderId = 1 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 1 }
|
||||
== APP - order-processor == Order received : Order { orderId = 2 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 2 }
|
||||
== APP - order-processor == Order received : Order { orderId = 3 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 3 }
|
||||
== APP - order-processor == Order received : Order { orderId = 4 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 4 }
|
||||
== APP - order-processor == Order received : Order { orderId = 5 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 5 }
|
||||
== APP - order-processor == Order received : Order { orderId = 6 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 6 }
|
||||
== APP - order-processor == Order received : Order { orderId = 7 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 7 }
|
||||
== APP - order-processor == Order received : Order { orderId = 8 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 8 }
|
||||
== APP - order-processor == Order received : Order { orderId = 9 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 9 }
|
||||
== APP - order-processor == Order received : Order { orderId = 10 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 10 }
|
||||
== APP - order-processor == Order received : Order { orderId = 11 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 11 }
|
||||
== APP - order-processor == Order received : Order { orderId = 12 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 12 }
|
||||
== APP - order-processor == Order received : Order { orderId = 13 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 13 }
|
||||
== APP - order-processor == Order received : Order { orderId = 14 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 14 }
|
||||
== APP - order-processor == Order received : Order { orderId = 15 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 15 }
|
||||
== APP - order-processor == Order received : Order { orderId = 16 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 16 }
|
||||
== APP - order-processor == Order received : Order { orderId = 17 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 17 }
|
||||
== APP - order-processor == Order received : Order { orderId = 18 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 18 }
|
||||
== APP - order-processor == Order received : Order { orderId = 19 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 19 }
|
||||
== APP - order-processor == Order received : Order { orderId = 20 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 20 }
|
||||
Exited App successfully
|
||||
```
|
||||
|
||||
### What happened?
|
||||
|
||||
Running `dapr run -f .` in this Quickstart started both the [subscriber]({{< ref "#order-processor-service" >}}) and [publisher]({{< ref "#checkout-service" >}}) applications using the `dapr.yaml` Multi-App Run template file.
|
||||
|
||||
##### `dapr.yaml` Multi-App Run template file
|
||||
|
||||
Running the [Multi-App Run template file]({{< ref multi-app-dapr-run >}}) with `dapr run -f .` starts all applications in your project. In this Quickstart, the `dapr.yaml` file contains the following:
|
||||
|
||||
```yml
|
||||
version: 1
|
||||
apps:
|
||||
- appDirPath: ./order-processor/
|
||||
appID: order-processor
|
||||
appPort: 8001
|
||||
command: ["python3", "app.py"]
|
||||
- appID: checkout
|
||||
appDirPath: ./checkout/
|
||||
command: ["python3", "app.py"]
|
||||
```
|
||||
|
||||
##### `order-processor` service
|
||||
|
||||
The `order-processor` service receives the call from the `checkout` service:
|
||||
|
||||
```py
|
||||
@app.route('/orders', methods=['POST'])
|
||||
def getOrder():
|
||||
data = request.json
|
||||
print('Order received : ' + json.dumps(data), flush=True)
|
||||
return json.dumps({'success': True}), 200, {
|
||||
'ContentType': 'application/json'}
|
||||
|
||||
|
||||
app.run(port=8001)
|
||||
```
|
||||
|
||||
#### `checkout` service
|
||||
|
||||
In the `checkout` service, you'll notice there's no need to rewrite your app code to use Dapr's service invocation. You can enable service invocation by simply adding the `dapr-app-id` header, which specifies the ID of the target service.
|
||||
|
||||
```python
|
||||
headers = {'dapr-app-id': 'order-processor'}
|
||||
|
||||
result = requests.post(
|
||||
url='%s/orders' % (base_url),
|
||||
data=json.dumps(order),
|
||||
headers=headers
|
||||
)
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
<!-- JavaScript -->
|
||||
{{% codetab %}}
|
||||
|
||||
### Step 1: Pre-requisites
|
||||
|
||||
For this example, you will need:
|
||||
|
||||
- [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started).
|
||||
- [Latest Node.js installed](https://nodejs.org/).
|
||||
<!-- IGNORE_LINKS -->
|
||||
- [Docker Desktop](https://www.docker.com/products/docker-desktop)
|
||||
<!-- END_IGNORE -->
|
||||
|
||||
### Step 2: Set up the environment
|
||||
|
||||
Clone the [sample provided in the Quickstarts repo](https://github.com/dapr/quickstarts/tree/master/service_invocation).
|
||||
|
||||
```bash
|
||||
git clone https://github.com/dapr/quickstarts.git
|
||||
```
|
||||
|
||||
From the root of the Quickstart clone directory, navigate to the quickstart directory.
|
||||
|
||||
```bash
|
||||
cd service_invocation/javascript/http
|
||||
```
|
||||
|
||||
### Step 3: Run the `order-processor` and `checkout` services
|
||||
|
||||
With the following command, simultaneously run the following services alongside their own Dapr sidecars:
|
||||
- The `order-processor` service
|
||||
- The `checkout` service
|
||||
|
||||
```bash
|
||||
dapr run -f .
|
||||
```
|
||||
|
||||
**Expected output**
|
||||
|
||||
```
|
||||
== APP - order-processor == Order received : Order { orderId = 1 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 1 }
|
||||
== APP - order-processor == Order received : Order { orderId = 2 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 2 }
|
||||
== APP - order-processor == Order received : Order { orderId = 3 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 3 }
|
||||
== APP - order-processor == Order received : Order { orderId = 4 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 4 }
|
||||
== APP - order-processor == Order received : Order { orderId = 5 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 5 }
|
||||
== APP - order-processor == Order received : Order { orderId = 6 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 6 }
|
||||
== APP - order-processor == Order received : Order { orderId = 7 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 7 }
|
||||
== APP - order-processor == Order received : Order { orderId = 8 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 8 }
|
||||
== APP - order-processor == Order received : Order { orderId = 9 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 9 }
|
||||
== APP - order-processor == Order received : Order { orderId = 10 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 10 }
|
||||
== APP - order-processor == Order received : Order { orderId = 11 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 11 }
|
||||
== APP - order-processor == Order received : Order { orderId = 12 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 12 }
|
||||
== APP - order-processor == Order received : Order { orderId = 13 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 13 }
|
||||
== APP - order-processor == Order received : Order { orderId = 14 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 14 }
|
||||
== APP - order-processor == Order received : Order { orderId = 15 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 15 }
|
||||
== APP - order-processor == Order received : Order { orderId = 16 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 16 }
|
||||
== APP - order-processor == Order received : Order { orderId = 17 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 17 }
|
||||
== APP - order-processor == Order received : Order { orderId = 18 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 18 }
|
||||
== APP - order-processor == Order received : Order { orderId = 19 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 19 }
|
||||
== APP - order-processor == Order received : Order { orderId = 20 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 20 }
|
||||
Exited App successfully
|
||||
```
|
||||
|
||||
### What happened?
|
||||
|
||||
Running `dapr run -f .` in this Quickstart started both the [subscriber]({{< ref "#order-processor-service" >}}) and [publisher]({{< ref "#checkout-service" >}}) applications using the `dapr.yaml` Multi-App Run template file.
|
||||
|
||||
##### `dapr.yaml` Multi-App Run template file
|
||||
|
||||
Running the [Multi-App Run template file]({{< ref multi-app-dapr-run >}}) with `dapr run -f .` starts all applications in your project. In this Quickstart, the `dapr.yaml` file contains the following:
|
||||
|
||||
```yml
|
||||
version: 1
|
||||
apps:
|
||||
- appDirPath: ./order-processor/
|
||||
appID: order-processor
|
||||
appPort: 5001
|
||||
command: ["npm", "start"]
|
||||
- appID: checkout
|
||||
appDirPath: ./checkout/
|
||||
command: ["npm", "start"]
|
||||
```
|
||||
|
||||
##### `order-processor` service
|
||||
|
||||
The `order-processor` service receives the call from the `checkout` service:
|
||||
|
||||
```javascript
|
||||
app.post('/orders', (req, res) => {
|
||||
console.log("Order received:", req.body);
|
||||
res.sendStatus(200);
|
||||
});
|
||||
```
|
||||
|
||||
##### `checkout` service
|
||||
|
||||
In the `checkout` service, you'll notice there's no need to rewrite your app code to use Dapr's service invocation. You can enable service invocation by simply adding the `dapr-app-id` header, which specifies the ID of the target service.
|
||||
|
||||
```javascript
|
||||
let axiosConfig = {
|
||||
headers: {
|
||||
"dapr-app-id": "order-processor"
|
||||
}
|
||||
};
|
||||
const res = await axios.post(`${DAPR_HOST}:${DAPR_HTTP_PORT}/orders`, order , axiosConfig);
|
||||
console.log("Order passed: " + res.config.data);
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
<!-- .NET -->
|
||||
{{% codetab %}}
|
||||
|
||||
### Step 1: Pre-requisites
|
||||
|
||||
For this example, you will need:
|
||||
|
||||
- [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started).
|
||||
- [.NET SDK or .NET 7 SDK installed](https://dotnet.microsoft.com/download).
|
||||
<!-- IGNORE_LINKS -->
|
||||
- [Docker Desktop](https://www.docker.com/products/docker-desktop)
|
||||
<!-- END_IGNORE -->
|
||||
|
||||
### Step 2: Set up the environment
|
||||
|
||||
Clone the [sample provided in the Quickstarts repo](https://github.com/dapr/quickstarts/tree/master/service_invocation).
|
||||
|
||||
```bash
|
||||
git clone https://github.com/dapr/quickstarts.git
|
||||
```
|
||||
|
||||
From the root of the Quickstart clone directory, navigate to the quickstart directory.
|
||||
|
||||
```bash
|
||||
cd service_invocation/csharp/http
|
||||
```
|
||||
|
||||
### Step 3: Run the `order-processor` and `checkout` services
|
||||
|
||||
With the following command, simultaneously run the following services alongside their own Dapr sidecars:
|
||||
- The `order-processor` service
|
||||
- The `checkout` service
|
||||
|
||||
```bash
|
||||
dapr run -f .
|
||||
```
|
||||
|
||||
**Expected output**
|
||||
|
||||
```
|
||||
== APP - order-processor == Order received : Order { orderId = 1 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 1 }
|
||||
== APP - order-processor == Order received : Order { orderId = 2 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 2 }
|
||||
== APP - order-processor == Order received : Order { orderId = 3 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 3 }
|
||||
== APP - order-processor == Order received : Order { orderId = 4 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 4 }
|
||||
== APP - order-processor == Order received : Order { orderId = 5 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 5 }
|
||||
== APP - order-processor == Order received : Order { orderId = 6 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 6 }
|
||||
== APP - order-processor == Order received : Order { orderId = 7 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 7 }
|
||||
== APP - order-processor == Order received : Order { orderId = 8 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 8 }
|
||||
== APP - order-processor == Order received : Order { orderId = 9 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 9 }
|
||||
== APP - order-processor == Order received : Order { orderId = 10 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 10 }
|
||||
== APP - order-processor == Order received : Order { orderId = 11 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 11 }
|
||||
== APP - order-processor == Order received : Order { orderId = 12 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 12 }
|
||||
== APP - order-processor == Order received : Order { orderId = 13 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 13 }
|
||||
== APP - order-processor == Order received : Order { orderId = 14 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 14 }
|
||||
== APP - order-processor == Order received : Order { orderId = 15 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 15 }
|
||||
== APP - order-processor == Order received : Order { orderId = 16 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 16 }
|
||||
== APP - order-processor == Order received : Order { orderId = 17 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 17 }
|
||||
== APP - order-processor == Order received : Order { orderId = 18 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 18 }
|
||||
== APP - order-processor == Order received : Order { orderId = 19 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 19 }
|
||||
== APP - order-processor == Order received : Order { orderId = 20 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 20 }
|
||||
Exited App successfully
|
||||
```
|
||||
|
||||
### What happened?
|
||||
|
||||
Running `dapr run -f .` in this Quickstart started both the [subscriber]({{< ref "#order-processor-service" >}}) and [publisher]({{< ref "#checkout-service" >}}) applications using the `dapr.yaml` Multi-App Run template file.
|
||||
|
||||
##### `dapr.yaml` Multi-App Run template file
|
||||
|
||||
Running the [Multi-App Run template file]({{< ref multi-app-dapr-run >}}) with `dapr run -f .` starts all applications in your project. In this Quickstart, the `dapr.yaml` file contains the following:
|
||||
|
||||
```yml
|
||||
version: 1
|
||||
apps:
|
||||
- appDirPath: ./order-processor/
|
||||
appID: order-processor
|
||||
appPort: 7001
|
||||
command: ["dotnet", "run"]
|
||||
- appID: checkout
|
||||
appDirPath: ./checkout/
|
||||
command: ["dotnet", "run"]
|
||||
```
|
||||
|
||||
##### `order-processor` service
|
||||
|
||||
The `order-processor` service receives the call from the `checkout` service:
|
||||
|
||||
```csharp
|
||||
app.MapPost("/orders", (Order order) =>
|
||||
{
|
||||
Console.WriteLine("Order received : " + order);
|
||||
return order.ToString();
|
||||
});
|
||||
```
|
||||
|
||||
##### `checkout` service
|
||||
|
||||
In the Program.cs file for the `checkout` service, you'll notice there's no need to rewrite your app code to use Dapr's service invocation. You can enable service invocation by simply adding the `dapr-app-id` header, which specifies the ID of the target service.
|
||||
|
||||
```csharp
|
||||
var client = new HttpClient();
|
||||
client.DefaultRequestHeaders.Accept.Add(new System.Net.Http.Headers.MediaTypeWithQualityHeaderValue("application/json"));
|
||||
|
||||
client.DefaultRequestHeaders.Add("dapr-app-id", "order-processor");
|
||||
|
||||
var response = await client.PostAsync($"{baseURL}/orders", content);
|
||||
Console.WriteLine("Order passed: " + order);
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
<!-- Java -->
|
||||
{{% codetab %}}
|
||||
|
||||
### Step 1: Pre-requisites
|
||||
|
||||
For this example, you will need:
|
||||
|
||||
- [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started).
|
||||
- Java JDK 11 (or greater):
|
||||
- [Oracle JDK](https://www.oracle.com/java/technologies/downloads), or
|
||||
- OpenJDK
|
||||
- [Apache Maven](https://maven.apache.org/install.html), version 3.x.
|
||||
<!-- IGNORE_LINKS -->
|
||||
- [Docker Desktop](https://www.docker.com/products/docker-desktop)
|
||||
<!-- END_IGNORE -->
|
||||
|
||||
### Step 2: Set up the environment
|
||||
|
||||
Clone the [sample provided in the Quickstarts repo](https://github.com/dapr/quickstarts/tree/master/service_invocation).
|
||||
|
||||
```bash
|
||||
git clone https://github.com/dapr/quickstarts.git
|
||||
```
|
||||
|
||||
From the root of the Quickstart clone directory, navigate to the quickstart directory.
|
||||
|
||||
```bash
|
||||
cd service_invocation/java/http
|
||||
```
|
||||
|
||||
### Step 3: Run the `order-processor` and `checkout` services
|
||||
|
||||
With the following command, simultaneously run the following services alongside their own Dapr sidecars:
|
||||
- The `order-processor` service
|
||||
- The `checkout` service
|
||||
|
||||
```bash
|
||||
dapr run -f .
|
||||
```
|
||||
|
||||
**Expected output**
|
||||
|
||||
```
|
||||
== APP - order-processor == Order received : Order { orderId = 1 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 1 }
|
||||
== APP - order-processor == Order received : Order { orderId = 2 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 2 }
|
||||
== APP - order-processor == Order received : Order { orderId = 3 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 3 }
|
||||
== APP - order-processor == Order received : Order { orderId = 4 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 4 }
|
||||
== APP - order-processor == Order received : Order { orderId = 5 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 5 }
|
||||
== APP - order-processor == Order received : Order { orderId = 6 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 6 }
|
||||
== APP - order-processor == Order received : Order { orderId = 7 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 7 }
|
||||
== APP - order-processor == Order received : Order { orderId = 8 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 8 }
|
||||
== APP - order-processor == Order received : Order { orderId = 9 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 9 }
|
||||
== APP - order-processor == Order received : Order { orderId = 10 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 10 }
|
||||
== APP - order-processor == Order received : Order { orderId = 11 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 11 }
|
||||
== APP - order-processor == Order received : Order { orderId = 12 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 12 }
|
||||
== APP - order-processor == Order received : Order { orderId = 13 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 13 }
|
||||
== APP - order-processor == Order received : Order { orderId = 14 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 14 }
|
||||
== APP - order-processor == Order received : Order { orderId = 15 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 15 }
|
||||
== APP - order-processor == Order received : Order { orderId = 16 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 16 }
|
||||
== APP - order-processor == Order received : Order { orderId = 17 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 17 }
|
||||
== APP - order-processor == Order received : Order { orderId = 18 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 18 }
|
||||
== APP - order-processor == Order received : Order { orderId = 19 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 19 }
|
||||
== APP - order-processor == Order received : Order { orderId = 20 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 20 }
|
||||
Exited App successfully
|
||||
```
|
||||
|
||||
### What happened?
|
||||
|
||||
Running `dapr run -f .` in this Quickstart started both the [subscriber]({{< ref "#order-processor-service" >}}) and [publisher]({{< ref "#checkout-service" >}}) applications using the `dapr.yaml` Multi-App Run template file.
|
||||
|
||||
##### `dapr.yaml` Multi-App Run template file
|
||||
|
||||
Running the [Multi-App Run template file]({{< ref multi-app-dapr-run >}}) with `dapr run -f .` starts all applications in your project. In this Quickstart, the `dapr.yaml` file contains the following:
|
||||
|
||||
```yml
|
||||
version: 1
|
||||
apps:
|
||||
- appDirPath: ./order-processor/
|
||||
appID: order-processor
|
||||
appPort: 9001
|
||||
command: ["java", "-jar", "target/OrderProcessingService-0.0.1-SNAPSHOT.jar"]
|
||||
- appID: checkout
|
||||
appDirPath: ./checkout/
|
||||
command: ["java", "-jar", "target/CheckoutService-0.0.1-SNAPSHOT.jar"]
|
||||
```
|
||||
|
||||
##### `order-processor` service
|
||||
|
||||
The `order-processor` service receives the call from the `checkout` service:
|
||||
|
||||
```java
|
||||
public String processOrders(@RequestBody Order body) {
|
||||
System.out.println("Order received: "+ body.getOrderId());
|
||||
return "CID" + body.getOrderId();
|
||||
}
|
||||
```
|
||||
|
||||
##### `checkout` service
|
||||
|
||||
In the `checkout` service, you'll notice there's no need to rewrite your app code to use Dapr's service invocation. You can enable service invocation by simply adding the `dapr-app-id` header, which specifies the ID of the target service.
|
||||
|
||||
```java
|
||||
.header("Content-Type", "application/json")
|
||||
.header("dapr-app-id", "order-processor")
|
||||
|
||||
HttpResponse<String> response = httpClient.send(request, HttpResponse.BodyHandlers.ofString());
|
||||
System.out.println("Order passed: "+ orderId)
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
<!-- Go -->
|
||||
{{% codetab %}}
|
||||
|
||||
### Step 1: Pre-requisites
|
||||
|
||||
For this example, you will need:
|
||||
|
||||
- [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started).
|
||||
- [Latest version of Go](https://go.dev/dl/).
|
||||
<!-- IGNORE_LINKS -->
|
||||
- [Docker Desktop](https://www.docker.com/products/docker-desktop)
|
||||
<!-- END_IGNORE -->
|
||||
|
||||
### Step 2: Set up the environment
|
||||
|
||||
Clone the [sample provided in the Quickstarts repo](https://github.com/dapr/quickstarts/tree/master/service_invocation).
|
||||
|
||||
|
||||
```bash
|
||||
git clone https://github.com/dapr/quickstarts.git
|
||||
```
|
||||
|
||||
From the root of the Quickstart clone directory, navigate to the quickstart directory.
|
||||
|
||||
```bash
|
||||
cd service_invocation/go/http
|
||||
```
|
||||
|
||||
### Step 3: Run the `order-processor` and `checkout` services
|
||||
|
||||
With the following command, simultaneously run the following services alongside their own Dapr sidecars:
|
||||
- The `order-processor` service
|
||||
- The `checkout` service
|
||||
|
||||
```bash
|
||||
dapr run -f .
|
||||
```
|
||||
|
||||
**Expected output**
|
||||
|
||||
```
|
||||
== APP - order-processor == Order received : Order { orderId = 1 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 1 }
|
||||
== APP - order-processor == Order received : Order { orderId = 2 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 2 }
|
||||
== APP - order-processor == Order received : Order { orderId = 3 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 3 }
|
||||
== APP - order-processor == Order received : Order { orderId = 4 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 4 }
|
||||
== APP - order-processor == Order received : Order { orderId = 5 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 5 }
|
||||
== APP - order-processor == Order received : Order { orderId = 6 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 6 }
|
||||
== APP - order-processor == Order received : Order { orderId = 7 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 7 }
|
||||
== APP - order-processor == Order received : Order { orderId = 8 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 8 }
|
||||
== APP - order-processor == Order received : Order { orderId = 9 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 9 }
|
||||
== APP - order-processor == Order received : Order { orderId = 10 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 10 }
|
||||
== APP - order-processor == Order received : Order { orderId = 11 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 11 }
|
||||
== APP - order-processor == Order received : Order { orderId = 12 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 12 }
|
||||
== APP - order-processor == Order received : Order { orderId = 13 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 13 }
|
||||
== APP - order-processor == Order received : Order { orderId = 14 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 14 }
|
||||
== APP - order-processor == Order received : Order { orderId = 15 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 15 }
|
||||
== APP - order-processor == Order received : Order { orderId = 16 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 16 }
|
||||
== APP - order-processor == Order received : Order { orderId = 17 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 17 }
|
||||
== APP - order-processor == Order received : Order { orderId = 18 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 18 }
|
||||
== APP - order-processor == Order received : Order { orderId = 19 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 19 }
|
||||
== APP - order-processor == Order received : Order { orderId = 20 }
|
||||
== APP - checkout == Order passed: Order { OrderId = 20 }
|
||||
Exited App successfully
|
||||
```
|
||||
|
||||
### What happened?
|
||||
|
||||
Running `dapr run -f .` in this Quickstart started both the [subscriber]({{< ref "#order-processor-service" >}}) and [publisher]({{< ref "#checkout-service" >}}) applications using the `dapr.yaml` Multi-App Run template file.
|
||||
|
||||
##### `dapr.yaml` Multi-App Run template file
|
||||
|
||||
Running the [Multi-App Run template file]({{< ref multi-app-dapr-run >}}) with `dapr run -f .` starts all applications in your project. In this Quickstart, the `dapr.yaml` file contains the following:
|
||||
|
||||
```yml
|
||||
version: 1
|
||||
apps:
|
||||
- appDirPath: ./order-processor/
|
||||
appID: order-processor
|
||||
appPort: 6006
|
||||
command: ["go", "run", "."]
|
||||
- appID: checkout
|
||||
appDirPath: ./checkout/
|
||||
command: ["go", "run", "."]
|
||||
```
|
||||
|
||||
##### `order-processor` service
|
||||
|
||||
In the `order-processor` service, each order is received via an HTTP POST request and processed by the `getOrder` function.
|
||||
|
||||
```go
|
||||
func getOrder(w http.ResponseWriter, r *http.Request) {
|
||||
data, err := ioutil.ReadAll(r.Body)
|
||||
if err != nil {
|
||||
log.Fatal(err)
|
||||
}
|
||||
log.Printf("Order received : %s", string(data))
|
||||
}
|
||||
```
|
||||
|
||||
##### `checkout` service
|
||||
|
||||
In the `checkout` service, you'll notice there's no need to rewrite your app code to use Dapr's service invocation. You can enable service invocation by simply adding the `dapr-app-id` header, which specifies the ID of the target service.
|
||||
|
||||
```go
|
||||
req.Header.Add("dapr-app-id", "order-processor")
|
||||
|
||||
response, err := client.Do(req)
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% /tabs %}}
|
||||
|
||||
## Run one application at a time
|
||||
|
||||
Select your preferred language before proceeding with the Quickstart.
|
||||
|
||||
{{< tabs "Python" "JavaScript" ".NET" "Java" "Go" >}}
|
||||
|
|
|
|||
|
|
@ -6,10 +6,652 @@ weight: 72
|
|||
description: "Get started with Dapr's State Management building block"
|
||||
---
|
||||
|
||||
Let's take a look at Dapr's [State Management building block]({{< ref state-management >}}). In this Quickstart, you will save, get, and delete state using a Redis state store, but you can swap this out for any one of the [supported state stores]({{< ref supported-state-stores.md >}}).
|
||||
Let's take a look at Dapr's [State Management building block]({{< ref state-management >}}). In this Quickstart, you will save, get, and delete state using a Redis state store by either:
|
||||
- [Running all applications simultaneously with the Multi-App Run template file]({{< ref "#run-using-multi-app-run" >}}), or
|
||||
- [Running a single application at a time]({{< ref "#run-one-application-at-a-time" >}})
|
||||
|
||||
<img src="/images/state-management-quickstart.png" width=1000 style="padding-bottom:15px;">
|
||||
|
||||
While this sample uses Redis, you can swap it out for any one of the [supported state stores]({{< ref supported-state-stores.md >}}).
|
||||
|
||||
## Run using Multi-App Run
|
||||
|
||||
Select your preferred language-specific Dapr SDK before proceeding with the Quickstart.
|
||||
|
||||
{{< tabs "Python" "JavaScript" ".NET" "Java" "Go" >}}
|
||||
<!-- Python -->
|
||||
{{% codetab %}}
|
||||
|
||||
### Pre-requisites
|
||||
|
||||
For this example, you will need:
|
||||
|
||||
- [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started).
|
||||
- [Python 3.7+ installed](https://www.python.org/downloads/).
|
||||
<!-- IGNORE_LINKS -->
|
||||
- [Docker Desktop](https://www.docker.com/products/docker-desktop)
|
||||
<!-- END_IGNORE -->
|
||||
|
||||
### Step 1: Set up the environment
|
||||
|
||||
Clone the [sample provided in the Quickstarts repo](https://github.com/dapr/quickstarts/tree/master/state_management).
|
||||
|
||||
```bash
|
||||
git clone https://github.com/dapr/quickstarts.git
|
||||
```
|
||||
|
||||
### Step 2: Manipulate service state
|
||||
|
||||
In a terminal window, navigate to the `order-processor` directory.
|
||||
|
||||
```bash
|
||||
cd state_management/python/sdk/order-processor
|
||||
```
|
||||
|
||||
Run the `order-processor` service alongside a Dapr sidecar using [Multi-App Run]({{< ref multi-app-dapr-run >}}).
|
||||
|
||||
```bash
|
||||
dapr run -f
|
||||
```
|
||||
|
||||
The `order-processor` service writes, reads, and deletes an `orderId` key/value pair to the `statestore` instance [defined in the `statestore.yaml` component]({{< ref "#statestoreyaml-component-file" >}}). As soon as the service starts, it performs a loop.
|
||||
|
||||
```python
|
||||
with DaprClient() as client:
|
||||
|
||||
# Save state into the state store
|
||||
client.save_state(DAPR_STORE_NAME, orderId, str(order))
|
||||
logging.info('Saving Order: %s', order)
|
||||
|
||||
# Get state from the state store
|
||||
result = client.get_state(DAPR_STORE_NAME, orderId)
|
||||
logging.info('Result after get: ' + str(result.data))
|
||||
|
||||
# Delete state from the state store
|
||||
client.delete_state(store_name=DAPR_STORE_NAME, key=orderId)
|
||||
logging.info('Deleting Order: %s', order)
|
||||
```
|
||||
|
||||
### Step 3: View the order-processor outputs
|
||||
|
||||
Notice, as specified in the code above, the code saves application state in the Dapr state store, reads it, then deletes it.
|
||||
|
||||
Order-processor output:
|
||||
```
|
||||
== APP == INFO:root:Saving Order: {'orderId': '1'}
|
||||
== APP == INFO:root:Result after get: b"{'orderId': '1'}"
|
||||
== APP == INFO:root:Deleting Order: {'orderId': '1'}
|
||||
== APP == INFO:root:Saving Order: {'orderId': '2'}
|
||||
== APP == INFO:root:Result after get: b"{'orderId': '2'}"
|
||||
== APP == INFO:root:Deleting Order: {'orderId': '2'}
|
||||
== APP == INFO:root:Saving Order: {'orderId': '3'}
|
||||
== APP == INFO:root:Result after get: b"{'orderId': '3'}"
|
||||
== APP == INFO:root:Deleting Order: {'orderId': '3'}
|
||||
== APP == INFO:root:Saving Order: {'orderId': '4'}
|
||||
== APP == INFO:root:Result after get: b"{'orderId': '4'}"
|
||||
== APP == INFO:root:Deleting Order: {'orderId': '4'}
|
||||
```
|
||||
|
||||
##### `dapr.yaml` Multi-App Run template file
|
||||
|
||||
When you run `dapr init`, Dapr creates a default [Multi-App Run template file]({{< ref multi-app-dapr-run >}}) named `dapr.yaml`. Running `dapr run -f` starts all applications in your project. In this sample, the `dapr.yaml` file contains the following:
|
||||
|
||||
```yml
|
||||
version: 1
|
||||
common:
|
||||
resourcesPath: ../../resources/
|
||||
apps:
|
||||
- appID: order-processor
|
||||
appDirPath: ./order-processor/
|
||||
command: ["python3" , "app.py"]
|
||||
```
|
||||
|
||||
##### `statestore.yaml` component file
|
||||
|
||||
When you run `dapr init`, Dapr also creates a default Redis `statestore.yaml` and runs a Redis container on your local machine, located:
|
||||
|
||||
- On Windows, under `%UserProfile%\.dapr\components\statestore.yaml`
|
||||
- On Linux/MacOS, under `~/.dapr/components/statestore.yaml`
|
||||
|
||||
With the `statestore.yaml` component, you can easily swap out the [state store](/reference/components-reference/supported-state-stores/) without making code changes.
|
||||
|
||||
The Redis `statestore.yaml` file included for this quickstart contains the following:
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Component
|
||||
metadata:
|
||||
name: statestore
|
||||
spec:
|
||||
type: state.redis
|
||||
version: v1
|
||||
metadata:
|
||||
- name: redisHost
|
||||
value: localhost:6379
|
||||
- name: redisPassword
|
||||
value: ""
|
||||
- name: actorStateStore
|
||||
value: "true"
|
||||
```
|
||||
|
||||
In the YAML file:
|
||||
|
||||
- `metadata/name` is how your application talks to the component (called `DAPR_STORE_NAME` in the code sample).
|
||||
- `spec/metadata` defines the connection to the Redis instance used by the component.
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
<!-- JavaScript -->
|
||||
{{% codetab %}}
|
||||
|
||||
### Pre-requisites
|
||||
|
||||
For this example, you will need:
|
||||
|
||||
- [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started).
|
||||
- [Latest Node.js installed](https://nodejs.org/download/).
|
||||
<!-- IGNORE_LINKS -->
|
||||
- [Docker Desktop](https://www.docker.com/products/docker-desktop)
|
||||
<!-- END_IGNORE -->
|
||||
|
||||
### Step 1: Set up the environment
|
||||
|
||||
Clone the [sample provided in the Quickstarts repo](https://github.com/dapr/quickstarts/tree/master/state_management).
|
||||
|
||||
```bash
|
||||
git clone https://github.com/dapr/quickstarts.git
|
||||
```
|
||||
|
||||
### Step 2: Manipulate service state
|
||||
|
||||
In a terminal window, navigate to the `order-processor` directory.
|
||||
|
||||
```bash
|
||||
cd state_management/javascript/sdk/order-processor
|
||||
```
|
||||
|
||||
Run the `order-processor` service alongside a Dapr sidecar.
|
||||
|
||||
```bash
|
||||
dapr run -f
|
||||
```
|
||||
|
||||
The `order-processor` service writes, reads, and deletes an `orderId` key/value pair to the `statestore` instance [defined in the `statestore.yaml` component]({{< ref "#statestoreyaml-component-file" >}}). As soon as the service starts, it performs a loop.
|
||||
|
||||
```js
|
||||
const client = new DaprClient()
|
||||
|
||||
// Save state into a state store
|
||||
await client.state.save(DAPR_STATE_STORE_NAME, order)
|
||||
console.log("Saving Order: ", order)
|
||||
|
||||
// Get state from a state store
|
||||
const savedOrder = await client.state.get(DAPR_STATE_STORE_NAME, order.orderId)
|
||||
console.log("Getting Order: ", savedOrder)
|
||||
|
||||
// Delete state from the state store
|
||||
await client.state.delete(DAPR_STATE_STORE_NAME, order.orderId)
|
||||
console.log("Deleting Order: ", order)
|
||||
```
|
||||
### Step 3: View the order-processor outputs
|
||||
|
||||
Notice, as specified in the code above, the code saves application state in the Dapr state store, reads it, then deletes it.
|
||||
|
||||
Order-processor output:
|
||||
```
|
||||
== APP == > order-processor@1.0.0 start
|
||||
== APP == > node index.js
|
||||
== APP == Saving Order: { orderId: 1 }
|
||||
== APP == Saving Order: { orderId: 2 }
|
||||
== APP == Saving Order: { orderId: 3 }
|
||||
== APP == Saving Order: { orderId: 4 }
|
||||
== APP == Saving Order: { orderId: 5 }
|
||||
== APP == Getting Order: { orderId: 1 }
|
||||
== APP == Deleting Order: { orderId: 1 }
|
||||
== APP == Getting Order: { orderId: 2 }
|
||||
== APP == Deleting Order: { orderId: 2 }
|
||||
== APP == Getting Order: { orderId: 3 }
|
||||
== APP == Deleting Order: { orderId: 3 }
|
||||
== APP == Getting Order: { orderId: 4 }
|
||||
== APP == Deleting Order: { orderId: 4 }
|
||||
== APP == Getting Order: { orderId: 5 }
|
||||
== APP == Deleting Order: { orderId: 5 }
|
||||
```
|
||||
|
||||
##### `dapr.yaml` Multi-App Run template file
|
||||
|
||||
When you run `dapr init`, Dapr creates a default Multi-App Run template file named `dapr.yaml`. Running `dapr run -f` starts all applications in your project. In this sample, the `dapr.yaml` file contains the following:
|
||||
|
||||
```yml
|
||||
version: 1
|
||||
common:
|
||||
resourcesPath: ../../resources/
|
||||
apps:
|
||||
- appID: order-processor
|
||||
appDirPath: ./order-processor/
|
||||
command: ["npm", "run", "start"]
|
||||
```
|
||||
|
||||
##### `statestore.yaml` component file
|
||||
|
||||
When you run `dapr init`, Dapr creates a default Redis `statestore.yaml` and runs a Redis container on your local machine, located:
|
||||
|
||||
- On Windows, under `%UserProfile%\.dapr\components\statestore.yaml`
|
||||
- On Linux/MacOS, under `~/.dapr/components/statestore.yaml`
|
||||
|
||||
With the `statestore.yaml` component, you can easily swap out the [state store](/reference/components-reference/supported-state-stores/) without making code changes.
|
||||
|
||||
The Redis `statestore.yaml` file included for this quickstart contains the following:
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Component
|
||||
metadata:
|
||||
name: statestore
|
||||
spec:
|
||||
type: state.redis
|
||||
version: v1
|
||||
metadata:
|
||||
- name: redisHost
|
||||
value: localhost:6379
|
||||
- name: redisPassword
|
||||
value: ""
|
||||
- name: actorStateStore
|
||||
value: "true"
|
||||
```
|
||||
|
||||
In the YAML file:
|
||||
|
||||
- `metadata/name` is how your application talks to the component (called `DAPR_STORE_NAME` in the code sample).
|
||||
- `spec/metadata` defines the connection to the Redis instance used by the component.
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
<!-- .NET -->
|
||||
{{% codetab %}}
|
||||
|
||||
### Pre-requisites
|
||||
|
||||
For this example, you will need:
|
||||
|
||||
- [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started).
|
||||
- [.NET SDK or .NET 6 SDK installed](https://dotnet.microsoft.com/download).
|
||||
<!-- IGNORE_LINKS -->
|
||||
- [Docker Desktop](https://www.docker.com/products/docker-desktop)
|
||||
<!-- END_IGNORE -->
|
||||
|
||||
### Step 1: Set up the environment
|
||||
|
||||
Clone the [sample provided in the Quickstarts repo](https://github.com/dapr/quickstarts/tree/master/state_management).
|
||||
|
||||
```bash
|
||||
git clone https://github.com/dapr/quickstarts.git
|
||||
```
|
||||
|
||||
### Step 2: Manipulate service state
|
||||
|
||||
In a terminal window, navigate to the `order-processor` directory.
|
||||
|
||||
```bash
|
||||
cd state_management/csharp/sdk/order-processor
|
||||
```
|
||||
|
||||
Run the `order-processor` service alongside a Dapr sidecar.
|
||||
|
||||
```bash
|
||||
dapr run -f
|
||||
```
|
||||
|
||||
The `order-processor` service writes, reads, and deletes an `orderId` key/value pair to the `statestore` instance [defined in the `statestore.yaml` component]({{< ref "#statestoreyaml-component-file" >}}). As soon as the service starts, it performs a loop.
|
||||
|
||||
```cs
|
||||
var client = new DaprClientBuilder().Build();
|
||||
|
||||
// Save state into the state store
|
||||
await client.SaveStateAsync(DAPR_STORE_NAME, orderId.ToString(), order.ToString());
|
||||
Console.WriteLine("Saving Order: " + order);
|
||||
|
||||
// Get state from the state store
|
||||
var result = await client.GetStateAsync<string>(DAPR_STORE_NAME, orderId.ToString());
|
||||
Console.WriteLine("Getting Order: " + result);
|
||||
|
||||
// Delete state from the state store
|
||||
await client.DeleteStateAsync(DAPR_STORE_NAME, orderId.ToString());
|
||||
Console.WriteLine("Deleting Order: " + order);
|
||||
```
|
||||
### Step 3: View the order-processor outputs
|
||||
|
||||
Notice, as specified in the code above, the code saves application state in the Dapr state store, reads it, then deletes it.
|
||||
|
||||
Order-processor output:
|
||||
```
|
||||
== APP == Saving Order: Order { orderId = 1 }
|
||||
== APP == Getting Order: Order { orderId = 1 }
|
||||
== APP == Deleting Order: Order { orderId = 1 }
|
||||
== APP == Saving Order: Order { orderId = 2 }
|
||||
== APP == Getting Order: Order { orderId = 2 }
|
||||
== APP == Deleting Order: Order { orderId = 2 }
|
||||
== APP == Saving Order: Order { orderId = 3 }
|
||||
== APP == Getting Order: Order { orderId = 3 }
|
||||
== APP == Deleting Order: Order { orderId = 3 }
|
||||
== APP == Saving Order: Order { orderId = 4 }
|
||||
== APP == Getting Order: Order { orderId = 4 }
|
||||
== APP == Deleting Order: Order { orderId = 4 }
|
||||
== APP == Saving Order: Order { orderId = 5 }
|
||||
== APP == Getting Order: Order { orderId = 5 }
|
||||
== APP == Deleting Order: Order { orderId = 5 }
|
||||
```
|
||||
|
||||
##### `dapr.yaml` Multi-App Run template file
|
||||
|
||||
When you run `dapr init`, Dapr creates a default Multi-App Run template file named `dapr.yaml`. Running `dapr run -f` starts all applications in your project. In this sample, the `dapr.yaml` file contains the following:
|
||||
|
||||
```yml
|
||||
version: 1
|
||||
common:
|
||||
resourcesPath: ../../../resources/
|
||||
apps:
|
||||
- appID: order-processor
|
||||
appDirPath: ./order-processor/
|
||||
command: ["dotnet", "run"]
|
||||
```
|
||||
|
||||
##### `statestore.yaml` component file
|
||||
|
||||
When you run `dapr init`, Dapr creates a default Redis `statestore.yaml` and runs a Redis container on your local machine, located:
|
||||
|
||||
- On Windows, under `%UserProfile%\.dapr\components\statestore.yaml`
|
||||
- On Linux/MacOS, under `~/.dapr/components/statestore.yaml`
|
||||
|
||||
With the `statestore.yaml` component, you can easily swap out the [state store](/reference/components-reference/supported-state-stores/) without making code changes.
|
||||
|
||||
The Redis `statestore.yaml` file included for this quickstart contains the following:
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Component
|
||||
metadata:
|
||||
name: statestore
|
||||
spec:
|
||||
type: state.redis
|
||||
version: v1
|
||||
metadata:
|
||||
- name: redisHost
|
||||
value: localhost:6379
|
||||
- name: redisPassword
|
||||
value: ""
|
||||
- name: actorStateStore
|
||||
value: "true"
|
||||
```
|
||||
|
||||
In the YAML file:
|
||||
|
||||
- `metadata/name` is how your application talks to the component (called `DAPR_STORE_NAME` in the code sample).
|
||||
- `spec/metadata` defines the connection to the Redis instance used by the component.
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
<!-- Java -->
|
||||
{{% codetab %}}
|
||||
|
||||
### Pre-requisites
|
||||
|
||||
For this example, you will need:
|
||||
|
||||
- [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started).
|
||||
- Java JDK 11 (or greater):
|
||||
- [Oracle JDK](https://www.oracle.com/java/technologies/downloads), or
|
||||
- OpenJDK
|
||||
- [Apache Maven](https://maven.apache.org/install.html), version 3.x.
|
||||
<!-- IGNORE_LINKS -->
|
||||
- [Docker Desktop](https://www.docker.com/products/docker-desktop)
|
||||
<!-- END_IGNORE -->
|
||||
|
||||
### Step 1: Set up the environment
|
||||
|
||||
Clone the [sample provided in the Quickstarts repo](https://github.com/dapr/quickstarts/tree/master/state_management).
|
||||
|
||||
```bash
|
||||
git clone https://github.com/dapr/quickstarts.git
|
||||
```
|
||||
|
||||
### Step 2: Manipulate service state
|
||||
|
||||
In a terminal window, navigate to the `order-processor` directory.
|
||||
|
||||
```bash
|
||||
cd state_management/java/sdk/order-processor
|
||||
```
|
||||
|
||||
Run the `order-processor` service alongside a Dapr sidecar.
|
||||
|
||||
```bash
|
||||
dapr run -f
|
||||
```
|
||||
|
||||
The `order-processor` service writes, reads, and deletes an `orderId` key/value pair to the `statestore` instance [defined in the `statestore.yaml` component]({{< ref "#statestoreyaml-component-file" >}}). As soon as the service starts, it performs a loop.
|
||||
|
||||
```java
|
||||
try (DaprClient client = new DaprClientBuilder().build()) {
|
||||
for (int i = 1; i <= 10; i++) {
|
||||
int orderId = i;
|
||||
Order order = new Order();
|
||||
order.setOrderId(orderId);
|
||||
|
||||
// Save state into the state store
|
||||
client.saveState(DAPR_STATE_STORE, String.valueOf(orderId), order).block();
|
||||
LOGGER.info("Saving Order: " + order.getOrderId());
|
||||
|
||||
// Get state from the state store
|
||||
State<Order> response = client.getState(DAPR_STATE_STORE, String.valueOf(orderId), Order.class).block();
|
||||
LOGGER.info("Getting Order: " + response.getValue().getOrderId());
|
||||
|
||||
// Delete state from the state store
|
||||
client.deleteState(DAPR_STATE_STORE, String.valueOf(orderId)).block();
|
||||
LOGGER.info("Deleting Order: " + orderId);
|
||||
TimeUnit.MILLISECONDS.sleep(1000);
|
||||
}
|
||||
```
|
||||
### Step 3: View the order-processor outputs
|
||||
|
||||
Notice, as specified in the code above, the code saves application state in the Dapr state store, reads it, then deletes it.
|
||||
|
||||
Order-processor output:
|
||||
```
|
||||
== APP == INFO:root:Saving Order: {'orderId': '1'}
|
||||
== APP == INFO:root:Result after get: b"{'orderId': '1'}"
|
||||
== APP == INFO:root:Deleting Order: {'orderId': '1'}
|
||||
== APP == INFO:root:Saving Order: {'orderId': '2'}
|
||||
== APP == INFO:root:Result after get: b"{'orderId': '2'}"
|
||||
== APP == INFO:root:Deleting Order: {'orderId': '2'}
|
||||
== APP == INFO:root:Saving Order: {'orderId': '3'}
|
||||
== APP == INFO:root:Result after get: b"{'orderId': '3'}"
|
||||
== APP == INFO:root:Deleting Order: {'orderId': '3'}
|
||||
== APP == INFO:root:Saving Order: {'orderId': '4'}
|
||||
== APP == INFO:root:Result after get: b"{'orderId': '4'}"
|
||||
== APP == INFO:root:Deleting Order: {'orderId': '4'}
|
||||
```
|
||||
|
||||
##### `dapr.yaml` Multi-App Run template file
|
||||
|
||||
When you run `dapr init`, Dapr creates a default Multi-App Run template file named `dapr.yaml`. Running `dapr run -f` starts all applications in your project. In this sample, the `dapr.yaml` file contains the following:
|
||||
|
||||
```yml
|
||||
version: 1
|
||||
common:
|
||||
resourcesPath: ../../resources/
|
||||
apps:
|
||||
- appID: order-processor
|
||||
appDirPath: ./order-processor/
|
||||
command: ["java", "-jar", "target/OrderProcessingService-0.0.1-SNAPSHOT.jar"]
|
||||
```
|
||||
|
||||
##### `statestore.yaml` component file
|
||||
|
||||
When you run `dapr init`, Dapr creates a default Redis `statestore.yaml` and runs a Redis container on your local machine, located:
|
||||
|
||||
- On Windows, under `%UserProfile%\.dapr\components\statestore.yaml`
|
||||
- On Linux/MacOS, under `~/.dapr/components/statestore.yaml`
|
||||
|
||||
With the `statestore.yaml` component, you can easily swap out the [state store](/reference/components-reference/supported-state-stores/) without making code changes.
|
||||
|
||||
The Redis `statestore.yaml` file included for this Quickstart contains the following:
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Component
|
||||
metadata:
|
||||
name: statestore
|
||||
spec:
|
||||
type: state.redis
|
||||
version: v1
|
||||
metadata:
|
||||
- name: redisHost
|
||||
value: localhost:6379
|
||||
- name: redisPassword
|
||||
value: ""
|
||||
- name: actorStateStore
|
||||
value: "true"
|
||||
```
|
||||
|
||||
In the YAML file:
|
||||
|
||||
- `metadata/name` is how your application talks to the component (called `DAPR_STORE_NAME` in the code sample).
|
||||
- `spec/metadata` defines the connection to the Redis instance used by the component.
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
<!-- Go -->
|
||||
{{% codetab %}}
|
||||
|
||||
### Pre-requisites
|
||||
|
||||
For this example, you will need:
|
||||
|
||||
- [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started).
|
||||
- [Latest version of Go](https://go.dev/dl/).
|
||||
<!-- IGNORE_LINKS -->
|
||||
- [Docker Desktop](https://www.docker.com/products/docker-desktop)
|
||||
<!-- END_IGNORE -->
|
||||
|
||||
### Step 1: Set up the environment
|
||||
|
||||
Clone the [sample provided in the Quickstarts repo](https://github.com/dapr/quickstarts/tree/master/state_management).
|
||||
|
||||
```bash
|
||||
git clone https://github.com/dapr/quickstarts.git
|
||||
```
|
||||
|
||||
### Step 2: Manipulate service state
|
||||
|
||||
In a terminal window, navigate to the `order-processor` directory.
|
||||
|
||||
```bash
|
||||
cd state_management/go/sdk/order-processor
|
||||
```
|
||||
|
||||
Run the `order-processor` service alongside a Dapr sidecar.
|
||||
|
||||
```bash
|
||||
dapr run -f
|
||||
```
|
||||
|
||||
The `order-processor` service writes, reads, and deletes an `orderId` key/value pair to the `statestore` instance [defined in the `statestore.yaml` component]({{< ref "#statestoreyaml-component-file" >}}). As soon as the service starts, it performs a loop.
|
||||
|
||||
```go
|
||||
client, err := dapr.NewClient()
|
||||
|
||||
// Save state into the state store
|
||||
_ = client.SaveState(ctx, STATE_STORE_NAME, strconv.Itoa(orderId), []byte(order))
|
||||
log.Print("Saving Order: " + string(order))
|
||||
|
||||
// Get state from the state store
|
||||
result, _ := client.GetState(ctx, STATE_STORE_NAME, strconv.Itoa(orderId))
|
||||
fmt.Println("Getting Order: " + string(result.Value))
|
||||
|
||||
// Delete state from the state store
|
||||
_ = client.DeleteState(ctx, STATE_STORE_NAME, strconv.Itoa(orderId))
|
||||
log.Print("Deleting Order: " + string(order))
|
||||
```
|
||||
|
||||
### Step 3: View the order-processor outputs
|
||||
|
||||
Notice, as specified in the code above, the code saves application state in the Dapr state store, reads it, then deletes it.
|
||||
|
||||
Order-processor output:
|
||||
```
|
||||
== APP == dapr client initializing for: 127.0.0.1:53689
|
||||
== APP == 2022/04/01 09:16:03 Saving Order: {"orderId":1}
|
||||
== APP == Getting Order: {"orderId":1}
|
||||
== APP == 2022/04/01 09:16:03 Deleting Order: {"orderId":1}
|
||||
== APP == 2022/04/01 09:16:03 Saving Order: {"orderId":2}
|
||||
== APP == Getting Order: {"orderId":2}
|
||||
== APP == 2022/04/01 09:16:03 Deleting Order: {"orderId":2}
|
||||
== APP == 2022/04/01 09:16:03 Saving Order: {"orderId":3}
|
||||
== APP == Getting Order: {"orderId":3}
|
||||
== APP == 2022/04/01 09:16:03 Deleting Order: {"orderId":3}
|
||||
== APP == 2022/04/01 09:16:03 Saving Order: {"orderId":4}
|
||||
== APP == Getting Order: {"orderId":4}
|
||||
== APP == 2022/04/01 09:16:03 Deleting Order: {"orderId":4}
|
||||
== APP == 2022/04/01 09:16:03 Saving Order: {"orderId":5}
|
||||
== APP == Getting Order: {"orderId":5}
|
||||
== APP == 2022/04/01 09:16:03 Deleting Order: {"orderId":5}
|
||||
```
|
||||
|
||||
##### `dapr.yaml` Multi-App Run template file
|
||||
|
||||
When you run `dapr init`, Dapr creates a default Multi-App Run template file named `dapr.yaml`. Running `dapr run -f` starts all applications in your project. In this sample, the `dapr.yaml` file contains the following:
|
||||
|
||||
```yml
|
||||
version: 1
|
||||
common:
|
||||
resourcesPath: ../../resources/
|
||||
apps:
|
||||
- appID: order-processor
|
||||
appDirPath: ./order-processor/
|
||||
command: ["go", "run", "."]
|
||||
```
|
||||
|
||||
##### `statestore.yaml` component file
|
||||
|
||||
When you run `dapr init`, Dapr creates a default Redis `statestore.yaml` and runs a Redis container on your local machine, located:
|
||||
|
||||
- On Windows, under `%UserProfile%\.dapr\components\statestore.yaml`
|
||||
- On Linux/MacOS, under `~/.dapr/components/statestore.yaml`
|
||||
|
||||
With the `statestore.yaml` component, you can easily swap out the [state store](/reference/components-reference/supported-state-stores/) without making code changes.
|
||||
|
||||
The Redis `statestore.yaml` file included for this Quickstart contains the following:
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Component
|
||||
metadata:
|
||||
name: statestore
|
||||
spec:
|
||||
type: state.redis
|
||||
version: v1
|
||||
metadata:
|
||||
- name: redisHost
|
||||
value: localhost:6379
|
||||
- name: redisPassword
|
||||
value: ""
|
||||
- name: actorStateStore
|
||||
value: "true"
|
||||
```
|
||||
|
||||
In the YAML file:
|
||||
|
||||
- `metadata/name` is how your application talks to the component (called `DAPR_STORE_NAME` in the code sample).
|
||||
- `spec/metadata` defines the connection to the Redis instance used by the component.
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{< /tabs >}}
|
||||
|
||||
|
||||
## Run one application at a time
|
||||
|
||||
Select your preferred language-specific Dapr SDK before proceeding with the Quickstart.
|
||||
|
||||
{{< tabs "Python" "JavaScript" ".NET" "Java" "Go" >}}
|
||||
|
|
@ -94,7 +736,7 @@ Order-processor output:
|
|||
== APP == INFO:root:Deleting Order: {'orderId': '4'}
|
||||
```
|
||||
|
||||
#### `statestore.yaml` component file
|
||||
##### `statestore.yaml` component file
|
||||
|
||||
When you run `dapr init`, Dapr creates a default Redis `statestore.yaml` and runs a Redis container on your local machine, located:
|
||||
|
||||
|
|
@ -216,7 +858,7 @@ Order-processor output:
|
|||
== APP == Deleting Order: { orderId: 5 }
|
||||
```
|
||||
|
||||
#### `statestore.yaml` component file
|
||||
##### `statestore.yaml` component file
|
||||
|
||||
When you run `dapr init`, Dapr creates a default Redis `statestore.yaml` and runs a Redis container on your local machine, located:
|
||||
|
||||
|
|
@ -333,7 +975,7 @@ Order-processor output:
|
|||
== APP == Deleting Order: Order { orderId = 5 }
|
||||
```
|
||||
|
||||
#### `statestore.yaml` component file
|
||||
##### `statestore.yaml` component file
|
||||
|
||||
When you run `dapr init`, Dapr creates a default Redis `statestore.yaml` and runs a Redis container on your local machine, located:
|
||||
|
||||
|
|
@ -455,7 +1097,7 @@ Order-processor output:
|
|||
== APP == INFO:root:Deleting Order: {'orderId': '4'}
|
||||
```
|
||||
|
||||
#### `statestore.yaml` component file
|
||||
##### `statestore.yaml` component file
|
||||
|
||||
When you run `dapr init`, Dapr creates a default Redis `statestore.yaml` and runs a Redis container on your local machine, located:
|
||||
|
||||
|
|
@ -573,7 +1215,7 @@ Order-processor output:
|
|||
== APP == 2022/04/01 09:16:03 Deleting Order: {"orderId":5}
|
||||
```
|
||||
|
||||
#### `statestore.yaml` component file
|
||||
##### `statestore.yaml` component file
|
||||
|
||||
When you run `dapr init`, Dapr creates a default Redis `statestore.yaml` and runs a Redis container on your local machine, located:
|
||||
|
||||
|
|
|
|||
|
|
@ -15,36 +15,11 @@ For CLI there is no explicit opt-in, just the version that this was first made a
|
|||
|
||||
| Feature | Description | Setting | Documentation | Version introduced |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| **Streaming for HTTP service invocation** | Enables (partial) support for using streams in HTTP service invocation; see below for more details. | `ServiceInvocationStreaming` | [Details]({{< ref "support-preview-features.md#streaming-for-http-service-invocation" >}}) | v1.10 |
|
||||
| **Pluggable components** | Allows creating self-hosted gRPC-based components written in any language that supports gRPC. The following component APIs are supported: State stores, Pub/sub, Bindings | N/A | [Pluggable components concept]({{<ref "components-concept#pluggable-components" >}})| v1.9 |
|
||||
| **Multi-App Run for Kubernetes** | Configure multiple Dapr applications from a single configuration file and run from a single command on Kubernetes | `dapr run -k -f` | [Multi-App Run]({{< ref multi-app-dapr-run.md >}}) | v1.10 |
|
||||
| **Workflows** | Author workflows as code to automate and orchestrate tasks within your application, like messaging, state management, and failure handling | N/A | [Workflows concept]({{< ref "components-concept#workflows" >}})| v1.10 |
|
||||
| **Cryptography** | Encrypt or decrypt data without having to manage secrets keys | N/A | [Cryptography concept]({{< ref "components-concept#cryptography" >}})| v1.11 |
|
||||
| **Service invocation for non-Dapr endpoints** | Allow the invocation of non-Dapr endpoints by Dapr using the [Service invocation API]({{< ref service_invocation_api.md >}}). Read ["How-To: Invoke Non-Dapr Endpoints using HTTP"]({{< ref howto-invoke-non-dapr-endpoints.md >}}) for more information. | N/A | [Service invocation API]({{< ref service_invocation_api.md >}}) | v1.11 |
|
||||
| **Actor State TTL** | Allow actors to save records to state stores with Time To Live (TTL) set to automatically clean up old data. In its current implementation, actor state with TTL may not be reflected correctly by clients, read [Actor State Transactions]({{< ref actors_api.md >}}) for more information. | `ActorStateTTL` | [Actor State Transactions]({{< ref actors_api.md >}}) | v1.11 |
|
||||
| **Transactional Outbox** | Allows state operations for inserts and updates to be published to a configured pub/sub topic using a single transaction across the state store and the pub/sub | N/A | [Transactional Outbox Feature]({{< ref howto-outbox.md >}}) | v1.12 |
|
||||
|
||||
### Streaming for HTTP service invocation
|
||||
|
||||
Running Dapr with the `ServiceInvocationStreaming` feature flag enables partial support for handling data as a stream in HTTP service invocation. This can offer improvements in performance and memory utilization when using Dapr to invoke another service using HTTP with large request or response bodies.
|
||||
|
||||
The table below summarizes the current state of support for streaming in HTTP service invocation in Dapr, including the impact of enabling `ServiceInvocationStreaming`, in the example where "app A" is invoking "app B" using Dapr. There are six steps in the data flow, with various levels of support for handling data as a stream:
|
||||
|
||||
<img src="/images/service-invocation-simple.webp" width=600 alt="Diagram showing the steps of service invocation described in the table below" />
|
||||
|
||||
| Step | Handles data as a stream | Dapr 1.11 | Dapr 1.11 with<br/>`ServiceInvocationStreaming` |
|
||||
|:---:|---|:---:|:---:|
|
||||
| 1 | Request: "App A" to "Dapr sidecar A | <span role="img" aria-label="No">❌</span> | <span role="img" aria-label="No">❌</span> |
|
||||
| 2 | Request: "Dapr sidecar A" to "Dapr sidecar B | <span role="img" aria-label="No">❌</span> | <span role="img" aria-label="Yes">✅</span> |
|
||||
| 3 | Request: "Dapr sidecar B" to "App B" | <span role="img" aria-label="Yes">✅</span> | <span role="img" aria-label="Yes">✅</span> |
|
||||
| 4 | Response: "App B" to "Dapr sidecar B" | <span role="img" aria-label="Yes">✅</span> | <span role="img" aria-label="Yes">✅</span> |
|
||||
| 5 | Response: "Dapr sidecar B" to "Dapr sidecar A | <span role="img" aria-label="No">❌</span> | <span role="img" aria-label="Yes">✅</span> |
|
||||
| 6 | Response: "Dapr sidecar A" to "App A | <span role="img" aria-label="No">❌</span> | <span role="img" aria-label="No">❌</span> |
|
||||
|
||||
Important notes:
|
||||
|
||||
- `ServiceInvocationStreaming` needs to be applied on caller sidecars only.
|
||||
In the example above, streams are used for HTTP service invocation if `ServiceInvocationStreaming` is applied to the configuration of "app A" and its Dapr sidecar, regardless of whether the feature flag is enabled for "app B" and its sidecar.
|
||||
- When `ServiceInvocationStreaming` is enabled, you should make sure that all services your app invokes using Dapr ("app B") are updated to Dapr 1.10 or higher, even if `ServiceInvocationStreaming` is not enabled for those sidecars.
|
||||
Invoking an app using Dapr 1.9 or older is still possible, but those calls may fail unless you have applied a Dapr Resiliency policy with retries enabled.
|
||||
|
||||
> Full support for streaming for HTTP service invocation will be completed in a future Dapr version.
|
||||
|
|
|
|||
|
|
@ -117,14 +117,60 @@ spec:
|
|||
value: "myeventhubstoragecontainer"
|
||||
```
|
||||
|
||||
## Sending multiple messages
|
||||
## Sending and receiving multiple messages
|
||||
|
||||
Azure Event Hubs supports sending multiple messages in a single operation. To set the metadata for bulk operations, set the query parameters on the HTTP request or the gRPC metadata as documented [here]({{< ref pubsub_api >}})
|
||||
Azure Eventhubs supports sending and receiving multiple messages in a single operation using the bulk pub/sub API.
|
||||
|
||||
### Configuring bulk publish
|
||||
|
||||
To set the metadata for bulk publish operation, set the query parameters on the HTTP request or the gRPC metadata, [as documented in the API reference]({{< ref pubsub_api >}}).
|
||||
|
||||
| Metadata | Default |
|
||||
|----------|---------|
|
||||
| `metadata.maxBulkPubBytes` | `1000000` |
|
||||
|
||||
### Configuring bulk subscribe
|
||||
|
||||
When subscribing to a topic, you can configure `bulkSubscribe` options. Refer to [Subscribing messages in bulk]({{< ref "pubsub-bulk#subscribing-messages-in-bulk" >}}) for more details and to learn more about [the bulk subscribe API]({{< ref pubsub-bulk.md >}}).
|
||||
|
||||
| Configuration | Default |
|
||||
|---------------|---------|
|
||||
| `maxMessagesCount` | `100` |
|
||||
| `maxAwaitDurationMs` | `10000` |
|
||||
|
||||
## Configuring checkpoint frequency
|
||||
|
||||
When subscribing to a topic, you can configure the checkpointing frequency in a partition by [setting the metadata in the HTTP or gRPC subscribe request ]({{< ref "pubsub_api.md#http-request-2" >}}). This metadata enables checkpointing after the configured number of events within a partition event sequence. Disable checkpointing by setting the frequency to `0`.
|
||||
|
||||
[Learn more about checkpointing](https://learn.microsoft.com/azure/event-hubs/event-hubs-features#checkpointing).
|
||||
|
||||
| Metadata | Default |
|
||||
| -------- | ------- |
|
||||
| `metadata.checkPointFrequencyPerPartition` | `1` |
|
||||
|
||||
Following example shows a sample subscription file for [Declarative subscription]({{< ref "subscription-methods.md#declarative-subscriptions" >}}) using `checkPointFrequencyPerPartition` metadata. Similarly, you can also pass the metadata in [Programmatic subscriptions]({{< ref "subscription-methods.md#programmatic-subscriptions" >}}) as well.
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v2alpha1
|
||||
kind: Subscription
|
||||
metadata:
|
||||
name: order-pub-sub
|
||||
spec:
|
||||
topic: orders
|
||||
routes:
|
||||
default: /checkout
|
||||
pubsubname: order-pub-sub
|
||||
metadata:
|
||||
checkPointFrequencyPerPartition: 1
|
||||
scopes:
|
||||
- orderprocessing
|
||||
- checkout
|
||||
```
|
||||
|
||||
{{% alert title="Note" color="primary" %}}
|
||||
When subscribing to a topic using `BulkSubscribe`, you configure the checkpointing to occur after the specified number of _batches,_ instead of events, where _batch_ means the collection of events received in a single request.
|
||||
{{% /alert %}}
|
||||
|
||||
## Create an Azure Event Hub
|
||||
|
||||
Follow the instructions on the [documentation](https://docs.microsoft.com/azure/event-hubs/event-hubs-create) to set up Azure Event Hubs.
|
||||
|
|
|
|||
|
|
@ -27,6 +27,19 @@ spec:
|
|||
secretKeyRef:
|
||||
name: <REPLACE-WITH-SECRET-NAME>
|
||||
key: <REPLACE-WITH-SECRET-KEY>
|
||||
clientTLS:
|
||||
rootCA:
|
||||
secretKeyRef:
|
||||
name: <REPLACE-WITH-SECRET-NAME>
|
||||
key: <REPLACE-WITH-SECRET-KEY>
|
||||
certificate:
|
||||
secretKeyRef:
|
||||
name: <REPLACE-WITH-SECRET-NAME>
|
||||
key: <REPLACE-WITH-SECRET-KEY>
|
||||
privateKey:
|
||||
secretKeyRef:
|
||||
name: <REPLACE-WITH-SECRET-NAME>
|
||||
key: <REPLACE-WITH-SECRET-KEY>
|
||||
scopes: # Optional
|
||||
- <REPLACE-WITH-SCOPED-APPIDS>
|
||||
auth: # Optional
|
||||
|
|
@ -39,6 +52,7 @@ auth: # Optional
|
|||
|--------------------|:--------:|---------|---------|
|
||||
| baseUrl | Y | Base URL of the non-Dapr endpoint | `"https://api.github.com"`, `"http://api.github.com"`
|
||||
| headers | N | HTTP request headers for service invocation | `name: "Accept-Language" value: "en-US"` <br/> `name: "Authorization" secretKeyRef.name: "my-secret" secretKeyRef.key: "myGithubToken" `
|
||||
| clientTLS | N | Enables TLS authentication to an endpoint with any standard combination of root certificate, client certificate and private key
|
||||
|
||||
## Related links
|
||||
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 367 KiB |
Loading…
Reference in New Issue