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: learn-pr/azure/create-serverless-logic-with-azure-functions/includes/3-create-an-azure-functions-app-in-the-azure-portal.md
+6-6Lines changed: 6 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,22 +1,22 @@
1
-
You're now ready to start implementing the temperature service. In the previous unit, you determined that a serverless solution would best fit your needs. Let's start by creating a function app to hold our Azure Function.
1
+
You're now ready to start implementing the temperature service. In the previous unit, you determined that a serverless solution would best fit your needs. Let's start by creating a function app that can hold our Azure Function.
2
2
3
3
## What is a function app?
4
4
5
5
Functions are hosted in an execution context called a **function app**. You define function apps to logically group and structure your functions and a compute resource in Azure. In our escalator example, you would create a function app to host the escalator drive gear temperature service. There are a few decisions that need to be made to create the function app; you need to choose a service plan and select a compatible storage account.
6
6
7
7
### Choose a service plan
8
8
9
-
Function apps may use one of the following hosting plans:
9
+
Function apps can use one of the following hosting plans:
10
10
11
11
- Consumption plan
12
12
- Premium plan
13
13
- Dedicated (App service) plan
14
14
15
-
When using the Azure serverless application platform, choose the **Consumption plan**. This plan provides automatic scaling and bills you only when your functions are running. The Consumption plan comes with a configurable timeout period for executing a function. By default, it's five (5) minutes, but may be configured to have a timeout as long as 10 minutes.
15
+
When using the Azure serverless application platform, choose the **Consumption plan**. This plan provides automatic scaling and bills you only when your functions are running. The Consumption plan comes with a configurable timeout period for executing a function. By default, it's five (5) minutes, but can be configured to have a timeout as long as 10 minutes.
16
16
17
-
The **Premium plan** also dynamically scales your resources to meet demand, but you can specify a minimum number of VM instances to keep warm and reduce so called "cold starts." The Premium plan also lets your functions connect to and run inside virtual networks. Like the Dedicated plan, the default timeout for apps in a Premium plan is 30 minutes, but they can essentially run for an unlimited time (depending on server availability).
17
+
The **Premium plan** also dynamically scales your resources to meet demand, but you can specify a minimum number of virtual machine (VM) instances to keep warm and reduce so called "cold starts." The Premium plan also lets your functions connect to and run inside virtual networks. Like the Dedicated plan, the default timeout for apps in a Premium plan is 30 minutes, but they can essentially run for an unlimited time (depending on server availability).
18
18
19
-
The **Dedicated (App service) plan** enables you to avoid timeout periods by having your function run continuously on a VM that you define. An App service plan is technically not a serverless plan, because you're responsible for managing the app resources the function runs on. However, it may be a better choice when you already have excess App Service resources available on which to also run your functions.
19
+
The **Dedicated (App service) plan** enables you to avoid timeout periods by having your function run continuously on a VM that you define. An App service plan is technically not a serverless plan, because you're responsible for managing the app resources the function runs on. However, it might be a better choice when you already have excess App Service resources available on which to also run your functions.
20
20
21
21
### Storage account requirements
22
22
@@ -115,4 +115,4 @@ Let's create a function app in the Azure portal. Completing this module incurs a
115
115
116
116
1. When deployment completes, select **Go to resource**. The Function App pane for your escalator function appears.
117
117
118
-
1. In the **Essentials** section, select the **URL** link to open it in a browser. A default Azure web page appears with a message that your Functions app is up and running.
118
+
1. In the **Essentials** section, select the **Default domain** link to open it in a browser. A default Azure web page appears with a message that your Functions app is up and running.
Copy file name to clipboardExpand all lines: learn-pr/azure/create-serverless-logic-with-azure-functions/includes/5-add-logic-to-the-function-app.md
+39-9Lines changed: 39 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,13 +16,13 @@ As we described in the preceding unit, Azure provides templates that help you bu
16
16
17
17
1. On the Function App screen under the **Functions** tab, select **Create in Azure portal**. The **Create function** pane appears.
18
18
19
-
1. Under **Select a template**, select *HTTP trigger*.
19
+
1. Under **Select a template**, select *HTTP trigger* and select **Next**.
20
20
21
21
::: zone pivot="javascript"
22
22
23
-
4.Select **Create**. The **HttpTrigger1** is created and displays in the **HttpTrigger1** Function pane.
23
+
4.Leave the **Function name** as *HttpTrigger1* and the **Authorization Level** as *Function*, and select **Create**. The function**HttpTrigger1** is created and displays in the **HttpTrigger1** Function pane.
24
24
25
-
5.In the Developer menu on the left, select **Code + Test**. The code editor opens, displaying the contents of the *index.js* code file for your function. The default code that the HTTP template generated appears in the following snippet.
25
+
5.Select the **Code + Test** tab. The code editor opens, displaying the contents of the *index.js* code file for your function. The default code that the HTTP template generated appears in the following snippet.
26
26
27
27
```javascript
28
28
module.exports=asyncfunction (context, req) {
@@ -186,7 +186,7 @@ HTTP triggers let you use API keys to block unknown callers by requiring a key a
186
186
187
187
Because you specified *Function* when you created this function, you need to supply the key when you send the HTTP request. You can send it as a query string parameter named `code`. Or, use the preferred method and pass it as an HTTP header named `x-functions-key`.
188
188
189
-
1. To find the functionand master keys, in the Function App menu, under **Developer**, select **Function Keys**. The Function Keys pane for your function opens.
189
+
1. To find the function keys, open the **Code + Test** menu by selecting the name of your function (forexample, *HttpTriger1*) under the **Functions** tab on the **Overview** menu. Then, select the **Function Keys** tab.
190
190
191
191
1. By default the function key value is hidden. Show the default function key value by selecting **Show value**. Copy the contents of the **Value** field to the clipboard, and then store this key in Notepad or a similar app for later use.
192
192
@@ -208,6 +208,7 @@ Because you specified *Function* when you created this function, you need to sup
208
208
1. Check the logs.
209
209
210
210
The **Code + Test** pane should open a session displaying log file output (ensure **Filesystem Logs** is selected in the drop-down at the top of the **Logs** pane). The log file updates with the status of your request, which should look something like this:
211
+
211
212
::: zone pivot="javascript"
212
213
213
214
```output
@@ -217,6 +218,7 @@ Because you specified *Function* when you created this function, you need to sup
217
218
```
218
219
219
220
::: zone-end
221
+
220
222
::: zone pivot="powershell"
221
223
222
224
```output
@@ -230,7 +232,7 @@ Because you specified *Function* when you created this function, you need to sup
230
232
231
233
Let's add the logic to the function, to check temperature readings that it receives, and set a status for each temperature reading.
232
234
233
-
Our function is expecting an array of temperature readings. The following JSON snippet is an example of the request body that we send to our function. Each `Reading` entry has an ID, timestamp, and temperature.
235
+
Our function is expecting an array of temperature readings. The following JSON snippet is an example of the request body that we send to our function. The name of the array might be slightly different for JavaScript or PowerShell, but each entry in the array has an ID, timestamp, and temperature.
234
236
235
237
```json
236
238
{
@@ -297,6 +299,34 @@ The logic we added is straightforward. We iterate through the array and set the
297
299
298
300
Notice the `Log` statements when you expand **Logs** at the bottom of the pane. When the function runs, these statements add messages in the Logs window.
299
301
302
+
## Test our business logic
303
+
304
+
We're going to use the **Test/Run** feature in *Developer* > *Code + Test* to test our function.
305
+
306
+
1. On the **Code + Test** tab, select **Test/Run**. In the **Input** tab, replace the contents of the **Body** text box with the following code to create our sample request.
307
+
308
+
```json
309
+
{
310
+
"readings": [
311
+
{
312
+
"driveGearId":1,
313
+
"timestamp":1534263995,
314
+
"temperature":23
315
+
},
316
+
{
317
+
"driveGearId":3,
318
+
"timestamp":1534264048,
319
+
"temperature":45
320
+
},
321
+
{
322
+
"driveGearId":18,
323
+
"timestamp":1534264050,
324
+
"temperature":55
325
+
}
326
+
]
327
+
}
328
+
```
329
+
300
330
::: zone-end
301
331
302
332
::: zone pivot="powershell"
@@ -344,13 +374,11 @@ The logic we added is straightforward. We iterate through the array and set the
344
374
345
375
Note the calls to the `Write-Host` cmdlet. When the function runs, these statements add messages in the Logs window.
346
376
347
-
::: zone-end
348
-
349
-
## Test our business logic
377
+
## Test the business logic
350
378
351
379
We're going to use the **Test/Run** feature in *Developer* > *Code + Test* to test our function.
352
380
353
-
1. In the **Input** tab, replace the contents of the **Body** text box with the following code to create our sample request.
381
+
1. On the **Code + Test** tab, select **Test/Run**. In the **Input** tab, replace the contents of the **Body** text box with the following code to create our sample request.
354
382
355
383
```json
356
384
{
@@ -374,6 +402,8 @@ We're going to use the **Test/Run** feature in *Developer* > *Code + Test* to te
374
402
}
375
403
```
376
404
405
+
::: zone-end
406
+
377
407
1. Select **Run**. The **Output** tab displays the HTTP response code and content. To see log messages, open the **Logs** tab in the bottom flyout of the pane (if it isn't already open). The following image shows an example response in the output pane and messages in the **Logs** pane.
378
408
379
409
:::image type="content" source="../media/5-portal-testing.png" alt-text="Screenshot of the Azure function editor, with the Test and Logs tabs showing." lightbox="../media/5-portal-testing.png":::
0 commit comments