mirror of https://github.com/dapr/docs.git
Merge branch 'issue_3423' of https://github.com/hhunter-ms/docs into issue_3423
This commit is contained in:
commit
adbe546df8
|
@ -16,9 +16,15 @@ When state TTL has native support in the state store component, Dapr forwards th
|
||||||
|
|
||||||
When a TTL is not specified, the default behavior of the state store is retained.
|
When a TTL is not specified, the default behavior of the state store is retained.
|
||||||
|
|
||||||
## Persisting state (ignoring an existing TTL)
|
## Explicit persistence bypassing globally defined TTL
|
||||||
|
|
||||||
To explicitly persist a state (ignoring any TTLs set for the key), specify a `ttlInSeconds` value of `-1`.
|
Persisting state applies to all state stores that let you specify a default TTL used for all data, either:
|
||||||
|
- Setting a global TTL value via a Dapr component, or
|
||||||
|
- When creating the state store outside of Dapr and setting a global TTL value.
|
||||||
|
|
||||||
|
When no specific TTL is specified, the data expires after that global TTL period of time. This is not facilitated by Dapr.
|
||||||
|
|
||||||
|
In addition, all state stores also support the option to _explicitly_ persist data. This means you can ignore the default database policy (which may have been set outside of Dapr or via a Dapr Component) to indefinitely retain a given database record. You can do this by setting `ttlInSeconds` to the value of `-1`. This value indicates to ignore any TTL value set.
|
||||||
|
|
||||||
## Supported components
|
## Supported components
|
||||||
|
|
||||||
|
|
|
@ -12,12 +12,6 @@ The workflow building block is currently in **alpha**.
|
||||||
|
|
||||||
Let's take a look at the Dapr [Workflow building block]({{< ref workflow >}}). In this Quickstart, you'll create a simple console application to demonstrate Dapr's workflow programming model and the workflow management APIs.
|
Let's take a look at the Dapr [Workflow building block]({{< ref workflow >}}). In this Quickstart, you'll create a simple console application to demonstrate Dapr's workflow programming model and the workflow management APIs.
|
||||||
|
|
||||||
The `order-processor` console app starts and manages the lifecycle of the `OrderProcessingWorkflow` workflow that stores and retrieves data in a state store. The workflow consists of four workflow activities, or tasks:
|
|
||||||
- `NotifyActivity`: Utilizes a logger to print out messages throughout the workflow
|
|
||||||
- `ReserveInventoryActivity`: Checks the state store to ensure that there is enough inventory for the purchase
|
|
||||||
- `ProcessPaymentActivity`: Processes and authorizes the payment
|
|
||||||
- `UpdateInventoryActivity`: Removes the requested items from the state store and updates the store with the new remaining inventory value
|
|
||||||
|
|
||||||
In this guide, you'll:
|
In this guide, you'll:
|
||||||
|
|
||||||
- Run the `order-processor` application.
|
- Run the `order-processor` application.
|
||||||
|
@ -26,13 +20,19 @@ In this guide, you'll:
|
||||||
|
|
||||||
<img src="/images/workflow-quickstart-overview.png" width=800 style="padding-bottom:15px;">
|
<img src="/images/workflow-quickstart-overview.png" width=800 style="padding-bottom:15px;">
|
||||||
|
|
||||||
Currently, you can experience the Dapr Workflow using the .NET SDK.
|
|
||||||
|
|
||||||
{{< tabs ".NET" "Python" >}}
|
{{< tabs ".NET" "Python" >}}
|
||||||
|
|
||||||
<!-- .NET -->
|
<!-- .NET -->
|
||||||
{{% codetab %}}
|
{{% codetab %}}
|
||||||
|
|
||||||
|
The `order-processor` console app starts and manages the lifecycle of an order processing workflow that stores and retrieves data in a state store. The workflow consists of four workflow activities, or tasks:
|
||||||
|
- `NotifyActivity`: Utilizes a logger to print out messages throughout the workflow
|
||||||
|
- `ReserveInventoryActivity`: Checks the state store to ensure that there is enough inventory for the purchase
|
||||||
|
- `ProcessPaymentActivity`: Processes and authorizes the payment
|
||||||
|
- `UpdateInventoryActivity`: Removes the requested items from the state store and updates the store with the new remaining inventory value
|
||||||
|
|
||||||
|
|
||||||
### Step 1: Pre-requisites
|
### Step 1: Pre-requisites
|
||||||
|
|
||||||
For this example, you will need:
|
For this example, you will need:
|
||||||
|
@ -259,6 +259,16 @@ The `Activities` directory holds the four workflow activities used by the workfl
|
||||||
<!-- Python -->
|
<!-- Python -->
|
||||||
{{% codetab %}}
|
{{% codetab %}}
|
||||||
|
|
||||||
|
The `order-processor` console app starts and manages the `order_processing_workflow`, which simulates purchasing items from a store. The workflow consists of five unique workflow activities, or tasks:
|
||||||
|
|
||||||
|
- `notify_activity`: Utilizes a logger to print out messages throughout the workflow. These messages notify you when:
|
||||||
|
- You have insufficient inventory
|
||||||
|
- Your payment couldn't be processed, etc.
|
||||||
|
- `process_payment_activity`: Processes and authorizes the payment.
|
||||||
|
- `verify_inventory_activity`: Checks the state store to ensure there is enough inventory present for purchase.
|
||||||
|
- `update_inventory_activity`: Removes the requested items from the state store and updates the store with the new remaining inventory value.
|
||||||
|
- `request_approval_activity`: Seeks approval from the manager if payment is greater than 50,000 USD.
|
||||||
|
|
||||||
### Step 1: Pre-requisites
|
### Step 1: Pre-requisites
|
||||||
|
|
||||||
For this example, you will need:
|
For this example, you will need:
|
||||||
|
|
Binary file not shown.
Before Width: | Height: | Size: 56 KiB After Width: | Height: | Size: 31 KiB |
Loading…
Reference in New Issue