Merge pull request #47836 from v-thpra/azure-triage-fix-1011529

Fix for Customer Feedback 1011529: readings json

Author: prmerger-automator[bot]

learn-pr/azure/create-serverless-logic-with-azure-functions/includes/3-create-an-azure-functions-app-in-the-azure-portal.md

@@ -1,22 +1,22 @@
-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.
+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.
 
 ## What is a function app?
 
 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.
 
 ### Choose a service plan
 
-Function apps may use one of the following hosting plans:
+Function apps can use one of the following hosting plans:
 
 - Consumption plan
 - Premium plan
 - Dedicated (App service) plan
 
-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.
+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.
 
-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). 
+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). 
 
-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.
+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.
 
 ### Storage account requirements
 
@@ -115,4 +115,4 @@ Let's create a function app in the Azure portal. Completing this module incurs a
 
 1. When deployment completes, select **Go to resource**. The Function App pane for your escalator function appears.
 
-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.
+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.

learn-pr/azure/create-serverless-logic-with-azure-functions/includes/5-add-logic-to-the-function-app.md

@@ -16,13 +16,13 @@ As we described in the preceding unit, Azure provides templates that help you bu
 
 1. On the Function App screen under the **Functions** tab, select **Create in Azure portal**. The **Create function** pane appears.
 
-1. Under **Select a template**, select *HTTP trigger*.
+1. Under **Select a template**, select *HTTP trigger* and select **Next**.
 
 ::: zone pivot="javascript"
 
-4. Select **Create**. The **HttpTrigger1** is created and displays in the **HttpTrigger1** Function pane.
+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.
 
-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.
+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.
 
     ```javascript
     module.exports = async function (context, req) {
@@ -186,7 +186,7 @@ HTTP triggers let you use API keys to block unknown callers by requiring a key a
 
 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`.
 
-1. To find the function and master keys, in the Function App menu, under **Developer**, select **Function Keys**. The Function Keys pane for your function opens.
+1. To find the function keys, open the **Code + Test** menu by selecting the name of your function (for example, *HttpTriger1*) under the **Functions** tab on the **Overview** menu. Then, select the **Function Keys** tab.
 
 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.
 
@@ -208,6 +208,7 @@ Because you specified *Function* when you created this function, you need to sup
 1. Check the logs.
 
     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:
+
 ::: zone pivot="javascript"
 
     ```output
@@ -217,6 +218,7 @@ Because you specified *Function* when you created this function, you need to sup
     ```
 
 ::: zone-end
+
 ::: zone pivot="powershell"
 
     ```output
@@ -230,7 +232,7 @@ Because you specified *Function* when you created this function, you need to sup
 
 Let's add the logic to the function, to check temperature readings that it receives, and set a status for each temperature reading.
 
-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.
+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.
 
 ```json
 {
@@ -297,6 +299,34 @@ The logic we added is straightforward. We iterate through the array and set the
 
 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.
 
+## Test our business logic
+
+We're going to use the **Test/Run** feature in *Developer* > *Code + Test* to test our function.
+
+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.
+
+    ```json
+    {
+        "readings": [
+            {
+                "driveGearId": 1,
+                "timestamp": 1534263995,
+                "temperature": 23
+            },
+            {
+                "driveGearId": 3,
+                "timestamp": 1534264048,
+                "temperature": 45
+            },
+            {
+                "driveGearId": 18,
+                "timestamp": 1534264050,
+                "temperature": 55
+            }
+        ]
+    }
+    ```
+
 ::: zone-end
 
 ::: zone pivot="powershell"
@@ -344,13 +374,11 @@ The logic we added is straightforward. We iterate through the array and set the
 
 Note the calls to the `Write-Host` cmdlet. When the function runs, these statements add messages in the Logs window.
 
-::: zone-end
-
-## Test our business logic
+## Test the business logic
 
 We're going to use the **Test/Run** feature in *Developer* > *Code + Test* to test our function.
 
-1. In the **Input** tab, replace the contents of the **Body** text box with the following code to create our sample request.
+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.
 
     ```json
     {
@@ -374,12 +402,14 @@ We're going to use the **Test/Run** feature in *Developer* > *Code + Test* to te
     }
     ```
 
-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.
+::: zone-end
+
+2. 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.
 
    :::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":::  
 
     The **Output** tab shows that a status field was correctly added to each of the readings.
 
-1. In the Developer menu on the left, select **Monitor** to see that the request was logged to Application Insights. The **Monitor** pane appears for your function.
+3. In the Developer menu on the left, select **Monitor** to see that the request was logged to Application Insights. The **Monitor** pane appears for your function.
 
    The **Invocations Tab** of the pane displays **Invocation Traces** for each of your function invocations. Select the **Date(UTC)** value for one of the invocations and view the detail about the execution of your function.