You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+32-9Lines changed: 32 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,15 +9,6 @@ This repo contains a Python client SDK for use with the [Durable Task Framework
9
9
10
10
> Note that this project is **not** currently affiliated with the [Durable Functions](https://docs.microsoft.com/azure/azure-functions/durable/durable-functions-overview) project for Azure Functions. If you are looking for a Python SDK for Durable Functions, please see [this repo](https://github.com/Azure/azure-functions-durable-python).
11
11
12
-
## Features
13
-
14
-
-[x] Orchestrations
15
-
-[x] Activities
16
-
-[x] Durable timers
17
-
-[x] Sub-orchestrations
18
-
-[ ] External events
19
-
-[ ] Suspend and resume
20
-
-[ ] Retry policies
21
12
22
13
## Supported patterns
23
14
@@ -102,6 +93,38 @@ As an aside, you'll also notice that the example orchestration above works with
102
93
103
94
You can find the full sample [here](./examples/human_interaction.py).
104
95
96
+
## Feature overview
97
+
98
+
The following features are currently supported:
99
+
100
+
### Orchestrations
101
+
102
+
Orchestrations are implemented using ordinary Python functions that take an `OrchestrationContext` as their first parameter. The `OrchestrationContext` provides APIs for starting child orchestrations, scheduling activities, and waiting for external events, among other things. Orchestrations are fault-tolerant and durable, meaning that they can automatically recover from failures and rebuild their local execution state. Orchestrator functions must be deterministic, meaning that they must always produce the same output given the same input.
103
+
104
+
### Activities
105
+
106
+
Activities are implemented using ordinary Python functions that take an `ActivityContext` as their first parameter. Activity functions are scheduled by orchestrations and have at-least-once execution guarantees, meaning that they will be executed at least once but may be executed multiple times in the event of a transient failure. Activity functions are where the real "work" of any orchestration is done.
107
+
108
+
### Durable timers
109
+
110
+
Orchestrations can schedule durable timers using the `create_timer` API. These timers are durable, meaning that they will survive orchestrator restarts and will fire even if the orchestrator is not actively in memory. Durable timers can be of any duration, from milliseconds to months.
111
+
112
+
### Sub-orchestrations
113
+
114
+
Orchestrations can start child orchestrations using the `call_sub_orchestrator` API. Child orchestrations are useful for encapsulating complex logic and for breaking up large orchestrations into smaller, more manageable pieces.
115
+
116
+
### External events
117
+
118
+
Orchestrations can wait for external events using the `wait_for_external_event` API. External events are useful for implementing human interaction patterns, such as waiting for a user to approve an order before continuing.
119
+
120
+
### Suspend and resume
121
+
122
+
Orchestrations can be suspended using the `suspend_orchestration` client API and will remain suspended until resumed using the `resume_orchestration` client API. A suspended orchestration will stop processing new events, but will continue to buffer any that happen to arrive until resumed, ensuring that no data is lost.
123
+
124
+
### Retry policies (TODO)
125
+
126
+
Orchestrations can specify retry policies for activities and sub-orchestrations. These policies control how many times and how frequently an activity or sub-orchestration will be retried in the event of a transient error.
0 commit comments