Merge pull request #296475 from ecfan/workspaces

[Standard] Visual Studio Code - Updates for workspace requirement, refresh, and new management doc

Author: denrea

articles/logic-apps/.openpublishing.redirection.logic-apps.json

@@ -1,5 +1,10 @@
 {
     "redirections": [
+        {
+            "source_path_from_root": "/articles/logic-apps/create-single-tenant-workflows-visual-studio-code.md",
+            "redirect_url": "/azure/logic-apps/create-standard-workflows-visual-studio-code",
+            "redirect_document_id": true
+        },
         {
             "source_path_from_root": "/articles/logic-apps/monitor-b2b-messages-log-analytics.md",
             "redirect_url": "/azure/logic-apps/monitor-track-b2b-messages-consumption",

articles/logic-apps/create-single-tenant-workflows-visual-studio-code.md

@@ -5,7 +5,7 @@ services: logic-apps
 ms.suite: integration
 ms.reviewer: estfan, azla
 ms.topic: how-to
-ms.date: 01/14/2024
+ms.date: 03/14/2025
 ms.custom: fasttrack-edit
 ---
 
@@ -27,20 +27,21 @@ In multitenant Azure Logic Apps, deployment depends on Azure Resource Manager te
 
 In *single-tenant* Azure Logic Apps, deployment becomes easier because you can separate resource provisioning between apps and infrastructure. You can use *parameters* to abstract values that might change between environments. By defining parameters to use in your workflows, you can first focus on designing your workflows, and then insert your environment-specific variables later. You can call and reference your environment variables at runtime by using app settings and parameters. That way, you don't have to redeploy as often.
 
-App settings integrate with Azure Key Vault. You can [directly reference secure strings](../app-service/app-service-key-vault-references.md), such as connection strings and keys. Similar to Azure Resource Manager templates (ARM templates), where you can define environment variables at deployment time, you can define app settings within your [logic app workflow definition](/azure/templates/microsoft.logic/workflows). You can then capture dynamically generated infrastructure values, such as connection endpoints, storage strings, and more. However, app settings have size limitations and can't be referenced from certain areas in Azure Logic Apps.
+App settings integrate with Azure Key Vault. You can [directly reference secure strings](/azure/app-service/app-service-key-vault-references), such as connection strings and keys. Similar to Azure Resource Manager templates (ARM templates), where you can define environment variables at deployment time, you can define app settings within your [logic app workflow definition](/azure/templates/microsoft.logic/workflows). You can then capture dynamically generated infrastructure values, such as connection endpoints, storage strings, and more. However, app settings have size limitations and can't be referenced from certain areas in Azure Logic Apps.
 
 > [!NOTE]
 >
-> If you use Key Vault, make sure that you store only secrets, such as passwords, credentials, and certificates. 
-> In a logic app workflow, don't use Key Vault to store non-secret values, such as URL paths, that the workflow designer needs to make calls. 
-> The designer can't dereference an app setting that references a Key Vault resource type, which results in an 
-> error and a failed call. For non-secret values, store them directly in app settings.
+> If you use Azure Key Vault, make sure to store only secrets, such as passwords, credentials, 
+> and certificates. Don't use a key vault in a logic app workflow to store non-secret values, 
+> such as URL paths, that the workflow designer needs to make calls. The designer can't 
+> dereference an app setting that references an Azure Key Vault resource, which results 
+> in an error and a failed call. For non-secret values, store them directly in app settings.
 
 For more information about setting up your logic apps for deployment, see the following documentation:
 
 - [Create parameters for values that change in workflows between environments for single-tenant Azure Logic Apps](parameterize-workflow-app.md)
-- [DevOps deployment overview for single-tenant based logic apps](devops-deployment-single-tenant-azure-logic-apps.md)
-- [Set up DevOps deployment for single-tenant based logic apps](set-up-devops-deployment-single-tenant-azure-logic-apps.md)
+- [DevOps deployment overview for single-tenant based logic apps](/azure/logic-apps/devops-deployment-single-tenant-azure-logic-apps)
+- [Set up DevOps deployment for single-tenant based logic apps](/azure/logic-apps/set-up-devops-deployment-single-tenant-azure-logic-apps)
 
 ## Visual Studio Code project structure
 
@@ -54,15 +55,15 @@ In Visual Studio Code, at your logic app project's root level, the **local.setti
 
 App settings in Azure Logic Apps work similarly to app settings in Azure Functions or Azure Web Apps. If you've used these other services before, you might already be familiar with app settings. For more information, review [App settings reference for Azure Functions](../azure-functions/functions-app-settings.md) and [Work with Azure Functions Core Tools - Local settings file](../azure-functions/functions-develop-local.md#local-settings-file).
 
-For your workflow to run properly, some app settings are required.
+The following table describes the app settings that your logic app uses. Some settings are required for your logic app to work correctly:
 
 | Setting | Required | Value | Description |
 |---------|----------|-------|-------------|
 | `APP_KIND` | Yes | `workflowApp` | Required to set the app type for the Standard logic app resource. The value must be set to **`workflowApp`**. <br><br>**Note**: In some scenarios, this app setting might be missing, for example, due to automation using Azure Resource Manager templates or other scenarios where the setting isn't included. If certain actions don't work, such as the **Execute JavaScript Code** action, or if the workflow stops working, check that the **APP_KIND** app setting exists and is set to **`workflowApp`**. |
 | `AZURE_AUTHORITY_HOST` | No | None | Sets the Standard logic app's default authority to use for OAuth authentication. |
 | `AzureWebJobsStorage` | Yes | None | Required to set the connection string for an Azure storage account. For more information, see [AzureWebJobsStorage](../azure-functions/functions-app-settings.md#azurewebjobsstorage). |
 | `FUNCTIONS_EXTENSION_VERSION` | Yes | `~4` | Required to set the Azure Functions version. For more information, see [FUNCTIONS_EXTENSION_VERSION](/azure/azure-functions/functions-app-settings#functions_extension_version). |
-| `FUNCTIONS_WORKER_RUNTIME` | Yes | `dotnet` | Required to set the language worker runtime for your logic app resource and workflows. <br><br>**Note**: This setting's value was previously set to **`node`**, but now the required value is **`dotnet`** for all new and existing deployed Standard logic apps. This change shouldn't affect your workflow's runtime, so everything should work the same way as before. <br><br>For more information, see [FUNCTIONS_WORKER_RUNTIME](../azure-functions/functions-app-settings.md#functions_worker_runtime). |
+| `FUNCTIONS_WORKER_RUNTIME` | Yes | `dotnet` | Required to set the language worker runtime for your logic app resource and workflows. <br><br>**Note**: This setting's value was previously set to **`node`**, but now the required value is **`dotnet`** for all new and existing deployed Standard logic apps. This change shouldn't affect your workflow's runtime, so everything should work the same way as before. <br><br>For more information, see [FUNCTIONS_WORKER_RUNTIME](/azure/azure-functions/functions-app-settings#functions_worker_runtime). |
 | `ServiceProviders.Sftp.FileUploadBufferTimeForTrigger` | No | `00:00:20` <br>(20 seconds) | Sets the buffer time to ignore files that have a last modified timestamp that's greater than the current time. This setting is useful when large file writes take a long time and avoids fetching data for a partially written file. |
 | `ServiceProviders.Sftp.OperationTimeout` | No | `00:02:00` <br>(2 min) | Sets the time to wait before timing out on any operation. |
 | `ServiceProviders.Sftp.ServerAliveInterval` | No | `00:30:00` <br>(30 min) | Sends a "keep alive" message to keep the SSH connection active if no data exchange with the server happens during the specified period. |

articles/logic-apps/create-standard-workflows-visual-studio-code.md

@@ -3,50 +3,62 @@ ms.service: azure-logic-apps
 ms.topic: include
 author: ecfan
 ms.author: estfan
-ms.date: 10/23/2024
+ms.date: 03/14/2025
 ---
 
 In Visual Studio Code, your logic app project has either of the following types:
 
 * Extension bundle-based (Node.js), which is the default type
 * NuGet package-based (.NET), which you can convert from the default type
 
-Based on these types, your project includes slightly different folders and files. A NuGet-based project includes a .bin folder that contains packages and other library files. A bundle-based project doesn't include the .bin folder and other files. Some scenarios require a NuGet-based project for your app to run, for example, when you want to develop and run custom built-in operations. For more information about converting your project to use NuGet, review [Enable built-connector authoring](../create-single-tenant-workflows-visual-studio-code.md#enable-built-in-connector-authoring).
+Based on these types, your project might include slightly different folders or files. For example, a Nuget package-based project has a **.bin** folder that contains packages and other library files. An extension bundle-based project doesn't include this **.bin** folder.
 
-For the default bundle-based project, your project has a folder and file structure that is similar to the following example:
+Some scenarios require a NuGet package-based project for your app to run, for example, when you want to develop and run custom built-in operations. For more information about converting your project to use NuGet, review [Enable built-connector authoring](/azure/logic-apps/create-single-tenant-workflows-visual-studio-code#enable-built-in-connector-authoring).
+
+The default extension bundle-based project has a folder and file structure that is similar to the following example:
 
 ```text
-MyBundleBasedLogicAppProjectName
-| .vscode
-| Artifacts
-  || Maps 
-     ||| MapName1
+MyWorkspaceName
+| MyBundleBasedLogicAppProjectName
+  || .vscode
+  || Artifacts
+     ||| Maps 
+         |||| MapName1
+         |||| ...
+     ||| Rules
+     ||| Schemas
+         |||| SchemaName1
+         |||| ...
+  || lib
+     ||| builtinOperationSdks
+         |||| JAR
+         |||| net472
+     ||| custom
+  || WorkflowName1
+     ||| workflow.json
      ||| ...
-  || Schemas
-     ||| SchemaName1
+  || WorkflowName2
+     ||| workflow.json
      ||| ...
-| WorkflowName1
-  || workflow.json
-  || ...
-| WorkflowName2
-  || workflow.json
-  || ...
-| workflow-designtime
-| .funcignore
-| connections.json
-| host.json
-| local.settings.json
+  || workflow-designtime
+     ||| host.json
+     ||| local.settings.json
+  || .funcignore
+  || connections.json
+  || host.json
+  || local.settings.json
 ```
 
-At your project's root level, you can find the following files and folders with other items:
+At your project's root level, you can find the following folders and files along with other items:
 
 | Name | Folder or file | Description |
 |------|----------------|-------------|
 | **.vscode** | Folder | Contains Visual Studio Code-related settings files, such as **extensions.json**, **launch.json**, **settings.json**, and **tasks.json** files. |
-| **Artifacts** | Folder | Contains integration account artifacts that you define and use in workflows that support business-to-business (B2B) scenarios. For example, the example structure includes maps and schemas for XML transform and validation operations. |
+| **Artifacts** | Folder | Contains integration account artifacts that you define and use in workflows that support business-to-business (B2B) scenarios. <br><br>For example, the sample structure includes the following folders: <br><br>- **Maps**: Contains [maps](/azure/logic-apps/logic-apps-enterprise-integration-maps) to use for XML transformation operations. <br><br>- **Schemas**: Contains [schemas](/azure/logic-apps/logic-apps-enterprise-integration-schemas) to use for XML validation operations. <br><br>- **Rules**: Artifacts for [business rules in rules-based engine projects](/azure/logic-apps/rules-engine/rules-engine-overview). |
+| **lib** | Folder | Contains supported assemblies that your logic app can use or reference. You can upload these assemblies to your project in Visual Studio Code, but you must add them to specific folders in your project. <br><br>For example, this folder includes the following folders: <br><br>- **builtinOperationSdks**: Contains the **JAR** and **net472** folders for Java and .NET Framework assemblies, respectively. <br><br>- **custom**: Contains .NET Framework custom assemblies. <br><br>For more information about supported assembly types and where to put them in your project, see [Add assemblies to your project](/azure/logic-apps/create-single-tenant-workflows-visual-studio-code#add-assembly). |
 | **<*WorkflowName*>** | Folder | For each workflow, the <*WorkflowName*> folder includes a **workflow.json** file, which contains that workflow's underlying JSON definition. |
 | **workflow-designtime** | Folder | Contains development environment-related settings files. |
-| **.funcignore** | File | Contains information related to your installed [Azure Functions Core Tools](../../azure-functions/functions-run-local.md). |
+| **.funcignore** | File | Contains information related to your installed [Azure Functions Core Tools](/azure/azure-functions/functions-run-local). |
 | **connections.json** | File | Contains the metadata, endpoints, and keys for any managed connections and Azure functions that your workflows use. <br><br>**Important**: To use different connections and functions for each environment, make sure that you parameterize this **connections.json** file and update the endpoints. |
-| **host.json** | File | Contains runtime-specific configuration settings and values, for example, the default limits for the single-tenant Azure Logic Apps platform, logic apps, workflows, triggers, and actions. At your logic app project's root level, the **host.json** metadata file contains the configuration settings and default values that *all workflows* in the same logic app use while running, whether locally or in Azure. <br><br>**Note**: When you create your logic app, Visual Studio Code creates a backup **host.snapshot.*.json** file in your storage container. If you delete your logic app, this backup file isn't deleted. If you create another logic app with the same name, another snapshot file is created. You can have only up to 10 snapshots for the same logic app. If you exceed this limit, you get the following error: <br><br>`Microsoft.Azure.WebJobs.Script.WebHost: Repository has more than 10 non-decryptable secrets backups (host))` <br><br>To resolve this error, delete the extra snapshot files from your storage container. |
-| **local.settings.json** | File | Contains app settings, connection strings, and other settings that your workflows use while running locally. In other words, these settings and values apply *only* when you run your projects in your local development environment. During deployment to Azure, the file and settings are ignored and aren't included with your deployment. <br><br>This file stores settings and values as *local environment variables* that are used by your local development tools as the `appSettings` values. You can call and reference these environment variables both at runtime and deployment time by using *app settings* and *parameters*. <br><br>**Important**: The **local.settings.json** file can contain secrets, so make sure that you also exclude this file from your project source control. |
+| **host.json** | File | Contains runtime-specific configuration settings and values, for example, the default limits for the single-tenant Azure Logic Apps platform, logic apps, workflows, triggers, and actions. At your logic app project's root level, the **host.json** metadata file contains the configuration settings and default values that *all workflows* in the same logic app use while running, whether locally or in Azure. For reference information, see [Edit app settings and host settings](/azure/logic-apps/edit-app-settings-host-settings#reference-host-json). <br><br>**Note**: When you create your logic app, Visual Studio Code creates a backup **host.snapshot.*.json** file in your storage container. If you delete your logic app, this backup file isn't deleted. If you create another logic app with the same name, another snapshot file is created. You can have only up to 10 snapshots for the same logic app. If you exceed this limit, you get the following error: <br><br>**`Microsoft.Azure.WebJobs.Script.WebHost: Repository has more than 10 non-decryptable secrets backups (host))`** <br><br>To resolve this error, delete the extra snapshot files from your storage container. |
+| **local.settings.json** | File | Contains app settings, connection strings, and other settings that your workflows use while running locally. These settings and values apply *only* when you run your projects in your local development environment. During deployment to Azure, the file and settings are ignored and aren't included with your deployment. <br><br>This file stores settings and values as *local environment variables* that your local development tools use for the **`appSettings`** values. You can call and reference these environment variables both at runtime and deployment time by using *app settings* and *parameters*. <br><br>**Important**: The **local.settings.json** file can contain secrets, so make sure that you also exclude this file from your project source control. This file also contains app settings that your logic app needs to work correctly. For reference information, see [Edit app settings and host settings](/azure/logic-apps/edit-app-settings-host-settings#reference-local-settings-json). |

articles/logic-apps/edit-app-settings-host-settings.md

@@ -0,0 +1,12 @@
+---
+ms.suite: integration
+ms.service: azure-logic-apps
+services: logic-apps
+author: ecfan
+ms.author: estfan
+ms.reviewer: azla
+ms.date: 03/18/2025
+ms.topic: include
+---
+
+  So, if you have another workflow that calls the deleted workflow, you must resave the caller workflow to refresh the metadata for the recreated workflow. That way, the caller gets the correct information for the recreated workflow. Otherwise, calls to the recreated workflow fail with an **`Unauthorized`** error. This behavior also applies to workflows that use artifacts in integration accounts and workflows that call Azure functions.