Using File system connector in Logic Apps Standard
Published Jan 23 2023 10:58 PM 10.9K Views
Microsoft

Logic Apps Standard now supports File System connector in App Service Environment. This enables customers to connect to any on-premise file shares with in the VNET from their workflows.

 

How to use it 

  1. File System connector only works on Logic Apps (Standard) hosted on App Service Environment.
  2. Create a new logic app in the App Service Environment and add a new workflow.
  3. To use the File System actions/triggers select the File System connector from the Built-in tab.Screenshot 2023-01-05 122933.png
  4. Create a new connection to use the connector triggers/actions. Once connection is created, all actions/triggers can be used like any other connector.

Creating a new connection

 The following parameters are needed to create a new connection. 

  • Connection name: The name of the connection
  • Root folder: The root folder for the network share. This should be in the format \\<FQDN or IP address of the Machine>\<folder name>. For example, \\test-file-serv.internal.cloudapp.net\Myshare. Note that the root folder cannot have nested folder path like \\test-file-serv.internal.cloudapp.net\Myshare\folder1.
  • Username: The username for the file share.  It can be a simple workstation username, or with a domain name in the format DOMAIN\user.
  • Password: The password for the file share.

Once the connection is created, there is config update which happens behind the scenes and hence the logic app would be restarted. Customers must wait till the app is restarted (less than a minute usually) to save the workflow or add more actions. The following error is expected when the workflow is tried to save during the restart.

Screenshot 2023-01-06 125207.png

 

Note: Users can only have upto a maximum of 20 File System connections per logic app. 

 

How it works?

The File System connector uses the App Service BYOS feature in the App Service Enviroments to mount the file share to a specific path. So, when a new connection is created, designer updates the configuration to mount the file share to C:\mounts\<connection-id> and the mount path is then written to connections.json. The Logic Apps runtime only uses this mount path for any of the action/trigger executions. However please note that a connection created successfully still doesn’t guarantee that the mount was successful. Due to networking constraints of the file share/logic apps, the file share might still not be accessible from Logic Apps. Customers may have to check if the mount path exists from the file system through the Kudu console to ensure that the connection properly works.

 

Screenshot 2023-01-09 122603.png

 

 

 

 

How to update/delete existing connections?

Unlike other built-in connectors, File System connectors cannot be updated by just updating the connections.json. This is becasue of the App Service configuration dependency mentioned above. Customers must update the underlying App service configuration inorder to update any connection.

 

How to see existing file share configuration?

The existing file share configuration can be read using the Microsoft.Web/azurestorageaccounts/list API. See the HTTP request below

 

 

 

 

POST https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<rg-name>/providers/Microsoft.Web/sites/<logic-app-name>/config/azurestorageaccounts/list?api-version=2018-11-01 

 

 

 

 

A sample response would look like this:

 

 

 

 

{
  "id": "/subscriptions/{subscription-id}/resourceGroups/{resource-group-name}/providers/Microsoft.Web/sites/{app-name}/config/appsettings",
  "name": "azurestorageaccounts",
  "type": "Microsoft.Web/sites/config",
  "location": "West Europe",
  "properties": {
    "FileSystem": {
      "type": "FileShare",
      "accountName": "testuser",
      "shareName": "Myshare",
      "accessKey": "<password>",
      "mountPath": "\\mounts\\FileSystem",
      "state": "NotValidated",
      "endpoint": "test-file-serv.internal.cloudapp.net"
    },
    "FileSystem-1": {
      "type": "FileShare",
      "accountName": "testuser2",
      "shareName": "Myshare2",
      "accessKey": "<password>",
      "mountPath": "\\mounts\\FileSystem-1",
      "state": "NotValidated",
      "endpoint": "10.0.0.4"
    }
  }
}

 

 

 

 

For each connection setup from the designer there would be a corresponding entry in the configurations with the connection id as the key and the following properties:

  •  "type": “FileShare” just specifies that this is a non-Azure file share.
  • “accountName”: user name specified during the connection.
  • "shareName": name of the file share specified in the root folder parameter of the connection.
  • "accessKey": password specified in the connection.
  • "endpoint": The IP or FQDN of the server, specified in the root folder. 
  • "mountPath": location to mount the share at runtime, minus the drive letter which will be automatically assigned.

Update existing file share configuration

The fileshare configuration can be updated by making a PUT call to Microsoft.Web/azurestorageaccounts API. Couple of things to note here.

  •  The API overwrites the exisiting configuration. So even if only one connection configuration needs to be updated make sure the entire configuration is provided as well.
  • In most cases users won't have to change the mount path. In cases where they have to update (like in case of ARM deplyoments) make sure the connections.json have the updated mount path as well. 

A sample request looks like this:

 

 

 

 

PUT https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<rg-name>/providers/Microsoft.Web/sites/<logic-app-name>/config/azurestorageaccounts?api-version=2018-11-01 

{
  "properties": {
    "FileSystem": {
      "type": "FileShare",
      "accountName": "testuser",
      "shareName": "Myshare",
      "accessKey": "<password>",
      "mountPath": "\\mounts\\FileSystem",
      "endpoint": "test-file-serv.internal.cloudapp.net"
    },
    "FileSystem-1": {
      "type": "FileShare",
      "accountName": "testuser2",
      "shareName": "Myshare2",
      "accessKey": "<password>",
      "mountPath": "\\mounts\\FileSystem-1",
      "endpoint": "10.0.0.4"
    }
  }
}

 

 

 

 

 

Common issues and troubleshooting

1.  One of the most common issues is that the file share is not reachable from the Logic app. Customers might get an error like:

The service provider action failed with error code 'InvalidServiceProviderConnection' and error message 'The mountpath `C:\\mounts\\FileSystem` does not exist as the provided connection is invalid.”

This could be because of multiple reasons. Customers may check the following in this case:

  • Make sure the file share is configured correctly.  Make sure that VNET/Logic App network security groups aren’t blocking SMB traffic to the destination server (port 445).
  • Check if the FQDN provided in the root path of the connection can be resolved/reached from the logic app. This can be done through the kudu console using nslookup <FQDN>
  • If traffic needs to be routed through the site VNET using custom DNS servers, the appsetting WEBSITE_CONTENTOVERVNET needs to be set, even on ASEs

Also note that incase only the machine name is given rather than the FQDN or IP address in the root path (like \\test-file-serv\Myshare instead of \\test-file-serv.internal.cloudapp.net\Myshare), the connection may not always work even though the nslookup of the machine name was successful.

 

2. Duplicate connections (connections with same root folder path) with different credentials are currently not supported. The connection creation succeeds, however the new connections will still continue to use the credentials from the previous connection.

 

VS Code development

The File system connector also works locally in VS code. However the existing connections will not work once deplyed to Azure. However after publishing from VS Code, users are currently expected to recreate their connections (via designer).

 

Deployment

For deployment, users can add this to their ARM template additionally to setup the file share configuration.

 

 

 

 

{...
    "resources": [
       ...
        {
            "type": "Microsoft.Web/sites/config",
            "name": "[concat(parameters('logicAppName'),'/azureStorageAccounts')]",
            "apiVersion": "2021-01-15",
            "location": "[parameters('location')]",
            "dependsOn": [ 
                           "[resourceId('Microsoft.Web/sites', parameters('logicAppName'))]"
                         ],
            "properties": {
                "mount1": {
                    "type": "FileShare",
                    "accountName": "[parameters('filesystem_username')]",
                    "endpoint": "[parameters('filesystem_hostName')]",
                    "shareName": "[parameters('filesystem_folder')]",
                    "accessKey": "[parameters('filesystem_password')]",
                    "mountPath": "[parameters('filesystem_mountPath')]"
                }
            }
        }
    ]
}

 

 

 

 

 

Users can also have the password referenced as app setting as shown in the template below. The same is also possible via the REST API mentioned above in the blog post. Make sure the app settings reference used is added (in this case FileSystem_password) for the connection to work.

 

 

 

 

{...
    "resources": [
       ...
        {
            "type": "Microsoft.Web/sites/config",
            "name": "[concat(parameters('logicAppName'),'/azureStorageAccounts')]",
            "apiVersion": "2021-01-15",
            "location": "[parameters('location')]",
            "dependsOn": [ 
                           "[resourceId('Microsoft.Web/sites', parameters('logicAppName'))]"
                         ],
            "properties": {
                "FileSystem": {
                    "type": "FileShare",
                    "accountName": "testuser",
                    "endpoint": "test-file-serv.internal.cloudapp.net",
                    "shareName": "Myshare",
                    "accessKey": "@AppSettingRef(FileSystem_password)",
                    "mountPath": "\\mounts\\FileSystem"
                }
            }
        }
    ]
}

 

 

 

 

 

 

 

16 Comments
Co-Authors
Version history
Last update:
‎Apr 03 2024 12:49 PM
Updated by: