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: articles/azure-functions/durable/durable-functions-custom-orchestration-status.md
+25-11Lines changed: 25 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,7 +8,7 @@ ms.author: azfuncdf
8
8
9
9
# Custom orchestration status in Durable Functions (Azure Functions)
10
10
11
-
Custom orchestration status lets you set a custom status value for your orchestrator function. This status is provided via the HTTP GetStatus API or the `DurableOrchestrationClient.GetStatusAsync` API.
11
+
Custom orchestration status lets you set a custom status value for your orchestrator function. This status is provided via the [HTTP GetStatus API](durable-functions-http-api.md#get-instance-status) or the [`GetStatusAsync` API](durable-functions-instance-management.md#query-instances) on the orchestration client.
12
12
13
13
## Sample use cases
14
14
@@ -19,7 +19,7 @@ Custom orchestration status lets you set a custom status value for your orchestr
19
19
20
20
Clients can poll the status end point and display a progress UI that visualizes the current execution stage. The following sample demonstrates progress sharing:
21
21
22
-
#### C#
22
+
#[C#](#tab/csharp)
23
23
24
24
```csharp
25
25
[FunctionName("E1_HelloSequence")]
@@ -46,7 +46,9 @@ public static string SayHello([ActivityTrigger] string name)
> In JavaScript, the `customStatus` field will be set when the next `yield` or `return` action is scheduled.
141
147
148
+
---
149
+
142
150
### Output customization
143
151
144
152
Another interesting scenario is segmenting users by returning customized output based on unique characteristics or interactions. With the help of custom orchestration status, the client-side code will stay generic. All main modifications will happen on the server side as shown in the following sample:
The orchestrator can provide unique instructions to the clients via the custom state. The custom status instructions will be mapped to the steps in the orchestration code:
220
230
221
-
#### C#
231
+
#[C#](#tab/csharp)
222
232
223
233
```csharp
224
234
[FunctionName("ReserveTicket")]
@@ -246,7 +256,7 @@ public static async Task<bool> Run(
Copy file name to clipboardExpand all lines: articles/azure-functions/durable/durable-functions-entities.md
+38-8Lines changed: 38 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -45,11 +45,13 @@ An entity operation can also create, read, update, and delete the state of the e
45
45
46
46
## Define entities
47
47
48
-
Currently, the two distinct APIs for defining entities are a:
48
+
Currently, the two distinct APIs for defining entities are:
49
49
50
50
**Function-based syntax**, where entities are represented as functions and operations are explicitly dispatched by the application. This syntax works well for entities with simple state, few operations, or a dynamic set of operations like in application frameworks. This syntax can be tedious to maintain because it doesn't catch type errors at compile time.
51
51
52
-
**Class-based syntax**, where entities and operations are represented by classes and methods. This syntax produces more easily readable code and allows operations to be invoked in a type-safe way. The class-based syntax is a thin layer on top of the function-based syntax, so both variants can be used interchangeably in the same application.
52
+
**Class-based syntax (.NET only)**, where entities and operations are represented by classes and methods. This syntax produces more easily readable code and allows operations to be invoked in a type-safe way. The class-based syntax is a thin layer on top of the function-based syntax, so both variants can be used interchangeably in the same application.
53
+
54
+
# [C#](#tab/csharp)
53
55
54
56
### Example: Function-based syntax - C#
55
57
@@ -103,11 +105,13 @@ The state of this entity is an object of type `Counter`, which contains a field
103
105
104
106
For more information on the class-based syntax and how to use it, see [Defining entity classes](durable-functions-dotnet-entities.md#defining-entity-classes).
105
107
108
+
# [JavaScript](#tab/javascript)
109
+
106
110
### Example: JavaScript entity
107
111
108
112
Durable entities are available in JavaScript starting with version **1.3.0** of the `durable-functions` npm package. The following code is the `Counter` entity implemented as a durable function written in JavaScript.
109
113
110
-
**function.json**
114
+
**Counter/function.json**
111
115
```json
112
116
{
113
117
"bindings": [
@@ -121,7 +125,7 @@ Durable entities are available in JavaScript starting with version **1.3.0** of
Entities can be accessed using one-way or two-way communication. The following terminology distinguishes the two forms of communication:
@@ -157,13 +163,15 @@ Entities can be accessed from within client functions, from within orchestrator
157
163
158
164
The following examples illustrate these various ways of accessing entities.
159
165
160
-
> [!NOTE]
161
-
> For simplicity, the following examples show the loosely typed syntax for accessing entities. In general, we recommend that you [access entities through interfaces](durable-functions-dotnet-entities.md#accessing-entities-through-interfaces) because it provides more type checking.
162
-
163
166
### Example: Client signals an entity
164
167
165
168
To access entities from an ordinary Azure Function, which is also known as a client function, use the [entity client binding](durable-functions-bindings.md#entity-client). The following example shows a queue-triggered function signaling an entity using this binding.
166
169
170
+
# [C#](#tab/csharp)
171
+
172
+
> [!NOTE]
173
+
> For simplicity, the following examples show the loosely typed syntax for accessing entities. In general, we recommend that you [access entities through interfaces](durable-functions-dotnet-entities.md#accessing-entities-through-interfaces) because it provides more type checking.
174
+
167
175
```csharp
168
176
[FunctionName("AddFromQueue")]
169
177
publicstaticTaskRun(
@@ -177,6 +185,8 @@ public static Task Run(
177
185
}
178
186
```
179
187
188
+
# [JavaScript](#tab/javascript)
189
+
180
190
```javascript
181
191
constdf=require("durable-functions");
182
192
@@ -187,12 +197,16 @@ module.exports = async function (context) {
187
197
};
188
198
```
189
199
200
+
---
201
+
190
202
The term *signal* means that the entity API invocation is one-way and asynchronous. It's not possible for a client function to know when the entity has processed the operation. Also, the client function can't observe any result values or exceptions.
191
203
192
204
### Example: Client reads an entity state
193
205
194
206
Client functions can also query the state of an entity, as shown in the following example:
195
207
208
+
# [C#](#tab/csharp)
209
+
196
210
```csharp
197
211
[FunctionName("QueryCounter")]
198
212
publicstaticasyncTask<HttpResponseMessage>Run(
@@ -205,6 +219,8 @@ public static async Task<HttpResponseMessage> Run(
205
219
}
206
220
```
207
221
222
+
# [JavaScript](#tab/javascript)
223
+
208
224
```javascript
209
225
constdf=require("durable-functions");
210
226
@@ -216,12 +232,16 @@ module.exports = async function (context) {
216
232
};
217
233
```
218
234
235
+
---
236
+
219
237
Entity state queries are sent to the Durable tracking store and return the entity's most recently persisted state. This state is always a "committed" state, that is, it's never a temporary intermediate state assumed in the middle of executing an operation. However, it's possible that this state is stale compared to the entity's in-memory state. Only orchestrations can read an entity's in-memory state, as described in the following section.
220
238
221
239
### Example: Orchestration signals and calls an entity
222
240
223
241
Orchestrator functions can access entities by using APIs on the [orchestration trigger binding](durable-functions-bindings.md#orchestration-trigger). The following example code shows an orchestrator function calling and signaling a `Counter` entity.
> JavaScript does not currently support signaling an entity from an orchestrator. Use `callEntity` instead.
255
277
278
+
---
279
+
256
280
Only orchestrations are capable of calling entities and getting a response, which could be either a return value or an exception. Client functions that use the [client binding](durable-functions-bindings.md#entity-client) can only signal entities.
257
281
258
282
> [!NOTE]
@@ -263,6 +287,8 @@ Only orchestrations are capable of calling entities and getting a response, whic
263
287
An entity function can send signals to other entities, or even itself, while it executes an operation.
264
288
For example, we can modify the previous `Counter` entity example so that it sends a "milestone-reached" signal to some monitor entity when the counter reaches the value 100.
265
289
290
+
# [C#](#tab/csharp)
291
+
266
292
```csharp
267
293
case"add":
268
294
varcurrentValue=ctx.GetState<int>();
@@ -276,6 +302,8 @@ For example, we can modify the previous `Counter` entity example so that it send
276
302
break;
277
303
```
278
304
305
+
# [JavaScript](#tab/javascript)
306
+
279
307
```javascript
280
308
case "add":
281
309
constamount=context.df.getInput();
@@ -287,7 +315,9 @@ For example, we can modify the previous `Counter` entity example so that it send
There might be times when you need to coordinate operations across multiple entities. For example, in a banking application, you might have entities that represent individual bank accounts. When you transfer funds from one account to another, you must ensure that the source account has sufficient funds. You also must ensure that updates to both the source and destination accounts are done in a transactionally consistent way.
0 commit comments