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
| JavaScript/TypeScript | v4 programming model: define inputs/outputs in code using `@azure/functions`; v3: configure in a per-function *function.json*|
24
+
| Python | v2 programming model: define inputs/outputs with decorators; v1: configure in *function.json*|
25
+
| PowerShell | configure in *function.json*|
24
26
25
-
For languages that rely on *function.json*, the portal provides a UI for adding bindings in the **Integration** tab. You can also edit the file directly in the portal in the **Code + test** tab of your function.
27
+
> [!NOTE]
28
+
> In modern models (Node.js v4 and Python v2), you author trigger and binding configuration in code and the runtime generates the corresponding *function.json*. Older models (Node.js v3, Python v1, PowerShell) use *function.json* directly. You can't mix programming models within the same function app.
29
+
30
+
For languages that rely on *function.json* (for example, Node.js v3, Python v1, and PowerShell), the portal provides a UI for adding bindings in the **Integration** tab. You can also edit the file directly in the portal in the **Code + test** tab of your function. For code-first models like Node.js v4 and Python v2, configure bindings in code in your local project; the portal reflects configuration but might not support direct edits.
26
31
27
32
In .NET and Java, the parameter type defines the data type for input data. For instance, use `string` to bind to the text of a queue trigger, a byte array to read as binary, and a custom type to deserialize to an object. Since .NET class library functions and Java functions don't rely on *function.json* for binding definitions, they can't be created and edited in the portal. C# portal editing is based on C# script, which uses *function.json* instead of attributes.
28
33
29
-
For languages that are dynamically typed such as JavaScript, use the `dataType` property in the *function.json* file. For example, to read the content of an HTTP request in binary format, set `dataType` to `binary`:
34
+
For languages that are dynamically typed such as JavaScript (using the v3 model) or PowerShell, use the `dataType` property in the *function.json* file. For example, to read the content of an HTTP request in binary format, set `dataType` to `binary`:
30
35
31
36
```json
32
37
{
@@ -49,64 +54,112 @@ All triggers and bindings have a direction property in the *function.json* file:
49
54
50
55
When you use attributes in a class library to configure triggers and bindings, the direction is provided in an attribute constructor or inferred from the parameter type.
51
56
52
-
## Azure Functions trigger and binding example
57
+
## Azure Functions trigger and binding examples
53
58
54
-
Suppose you want to write a new row to Azure Table storage whenever a new message appears in Azure Queue storage. This scenario can be implemented using an Azure Queue storage trigger and an Azure Table storage output binding.
59
+
Suppose you want to write a message to Azure Queue storage whenever an HTTP request is received. You can implement this with an HTTP trigger and a Storage Queue output binding. The configuration approach depends on your language and programming model.
55
60
56
-
Here's a *function.json* file for this scenario.
61
+
Here's a legacy *function.json* file for this scenario (applicable to Node.js v3, Python v1, or PowerShell).
57
62
58
63
```json
59
64
{
60
-
"disabled": false,
65
+
"disabled": false,
61
66
"bindings": [
62
67
{
63
-
"type": "queueTrigger",
68
+
"type": "httpTrigger",
64
69
"direction": "in",
65
-
"name": "myQueueItem",
66
-
"queueName": "myqueue-items",
67
-
"connection":"MyStorageConnectionAppSetting"
70
+
"name": "req",
71
+
"authLevel": "function",
72
+
"methods": ["get","post"]
68
73
},
69
-
{
70
-
"tableName": "Person",
71
-
"connection": "MyStorageConnectionAppSetting",
72
-
"name": "tableBinding",
73
-
"type": "table",
74
-
"direction": "out"
75
-
}
74
+
{
75
+
"type": "queue",
76
+
"direction": "out",
77
+
"name": "outqueue",
78
+
"queueName": "outqueue",
79
+
"connection": "AzureWebJobsStorage"
80
+
}
76
81
]
77
82
}
78
83
```
79
84
80
-
The first element in the `bindings` array is the Queue storage trigger. The `type` and `direction` properties identify the trigger. The `name` property identifies the function parameter that receives the queue message content. The name of the queue to monitor is in `queueName`, and the connection string is in the app setting identified by `connection`.
85
+
The first element in the `bindings` array is the HTTP trigger. The `type` and `direction` properties identify the trigger. The `name` property identifies the function parameter that receives the HTTP request, and `methods` lists the supported HTTP verbs.
86
+
87
+
The second element in the `bindings` array is the Storage Queue output binding. The `type` and `direction` properties identify the binding. The `name` property specifies how the function provides the new queue message, the `queueName` identifies the queue, and `connection` refers to the app setting that holds the storage connection string.
81
88
82
-
The second element in the `bindings` array is the Azure Table Storage output binding. The `type` and `direction` properties identify the binding. The `name` property specifies how the function provides the new table row, in this case by using the function return value. The name of the table is in `tableName`, and the connection string is in the app setting identified by `connection`.
89
+
> [!NOTE]
90
+
> Disabling a function via the `disabled` property in *function.json* is legacy behavior. Prefer using the app setting `AzureWebJobs.<FunctionName>.Disabled=true`.
83
91
84
-
### C# function example
92
+
### C# (isolated worker) example
85
93
86
-
Following is the same example represented in a C# function. The same trigger and binding information, queue and table names, storage accounts, and function parameters for input and output are provided by attributes instead of a *function.json* file.
94
+
This example shows an HTTP-triggered function that writes a message to a Storage Queue using an output binding defined by attributes. For more information, see [C# isolated worker guide](/azure/azure-functions/dotnet-isolated-process-guide).
In the v4 Node.js programming model, you configure inputs and outputs in code using `@azure/functions`. For more information, see [Node.js developer guide (v4)](/azure/azure-functions/functions-reference-node?pivots=nodejs-model-v4#inputs-and-outputs).
126
+
127
+
```javascript
128
+
import { app, output } from"@azure/functions";
129
+
130
+
constqueueOutput=output.storageQueue({
131
+
queueName:"outqueue",
132
+
connection:"AzureWebJobsStorage"
133
+
});
134
+
135
+
app.http("HttpToQueue", {
136
+
methods: ["GET", "POST"],
137
+
authLevel:"function",
138
+
extraOutputs: [queueOutput],
139
+
handler:async (request, context) => {
140
+
constbody=awaitrequest.text();
141
+
context.extraOutputs.set(queueOutput, body ||"Processed request");
142
+
return { status:200, body:"Queued" };
143
+
}
144
+
});
145
+
```
146
+
147
+
### Python (v2 programming model) example
148
+
149
+
In the v2 Python programming model, you use decorators to define bindings. The runtime generates *function.json* for you. Visit the [Python developer guide](/azure/azure-functions/functions-reference-python) for more information.
> In Node.js v4 and Python v2, the runtime generates *function.json* from your code. Avoid editing *function.json* directly in the portal for these models; make changes in code and republish.
0 commit comments