Using File system connector in Logic Apps Standard

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.
   
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

To create a new connection make sure you use the generally available designer. 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.

How it works

The File System connector uses the App Service BYOS feature to mount the file share to a specific path. So, when a new connection is created, designer updates the config 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.

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 the SMB ports (139, 445) are exposed on the VM firewall and in the NSGs.
  
• Check if the FQDN /IP 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 or IP address>
  

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: The file share configuration does not support configurations with duplicate root folder path. So when a customer tries to create a new connection with root folder path of an existing connection, the logic would fail to restart for them. In this case customers must manually delete the config using REST API like shown below

To fetch the existing config, use the following HTTP request:

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

An example 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-2": {

"type": "FileShare",

"accountName": "testuser2",

"shareName": "Myshare2",

"accessKey": "<password>",

"mountPath": "\\mounts\\FileSystem-2",

"state": "NotValidated",

"endpoint": "10.0.0.4"

}

}

}

Remove the duplicate config from the response body and update the existing config using the HTTP request:

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

VS Code development/deployment

The File system connector also works locally in VS code. However the existing connections will not work once deplyed to Azure. Customers are currently expected to recreate their connections (via designer) once the deployment is complete.

Continue reading...