-1

I'm facing an interesting problem where I manage to deploy a filesystem API connection using an on-premise data gateway via bicep, but when a workflow uses the filesystem step (which uses the API connection) it throws the following error message:

"The requested action could not be completed. Check your request parameters to make sure the path '\\folder\\Input' exists on your file system."

The interesting part here is that if I navigate to the API connection resource in the portal, click on "Edit API Connection" under the General section, input the username/password manually and hit Save, the api connection suddenly starts working.

The immediate reaction is of course that the username/password details set during the deploy is not complete in some way. So I decided to just verify that the secret fetched from the keyvault was indeed working by simply changing the secret name in the getSecret method:

resource keyVaultResource 'Microsoft.KeyVault/vaults@2019-09-01' existing = {
  name: keyVaultName
  scope: az.resourceGroup('rg-xxx-test')
}

// MODULES
module apiConnectionModule 'apiconnection.bicep' = {
  name: 'ApiConnection_Filesystem'
  dependsOn: []
  params:{
    location: location
    userName: keyVaultResource.getSecret('Filesystem-User')
    password: keyVaultResource.getSecret('Filesystem-Password')
  }
}

Indeed during deployment it complained that the secret was not present. So so far so good I guess. The username/pass is then passed to the module below which creates the filesystem API Connection:

param location string = resourceGroup().location
param logicAppName string = 'lapp-xxx-test'

@secure()
param userName string

@secure()
param password string

// RESOURCES
resource apiConnectionResource 'Microsoft.Web/connections@2016-06-01' = {
  name: 'apiconn-file-test'
  location: location
  kind: 'V2'
  tags: {}
  properties: {
    displayName: 'apiconn-file-test'
    parameterValues: {
      rootfolder: '\\\\NASFOLDER\\TEST'
      userName: userName
      password: password
      authType: 'windows'
      gateway: {
        id: '/subscriptions/xxx-xxx-xxx-xxx-xxx/resourceGroups/xxx/providers/Microsoft.Web/connectionGateways/xxx-On-Prem-Gateway'
      }
    }
    api: {
      id: '/subscriptions/${subscription().subscriptionId}/providers/Microsoft.Web/locations/westeurope/managedApis/filesystem'
    }
  }
}

resource accessPolicy 'Microsoft.Web/connections/accessPolicies@2016-06-01' = {
  name: '${apiConnectionResource.name}/${logicAppName}'
  location: location
  properties: {
    principal: {
      type: 'ActiveDirectory'
      identity: {
        tenantId: subscription().tenantId
        objectId: reference('/subscriptions/${subscription().subscriptionId}/resourceGroups/${resourceGroup().name}/providers/Microsoft.Web/sites/${logicAppName}','2021-02-01','full').identity.principalId
      }
    }
  }
}

Just to add, the logic app is VNET integrated, if that helps. Am I doing something out of whack here?

Big thanks for helping out.

Morty
  • 11
  • 3

1 Answers1

1

I think I found the underlying reason for this problem. It seems like it is an expected behavior. Even though the deployment of the API connection is successful, you still need to give your consent for it to be "finalized". This is a manual task where you indeed navigate to the created resource and enter the credentials again to enable it. I would prefer this to be handled in the deployment though if possible. I hope this helps others in some degree.

Morty
  • 11
  • 3
  • This is not expected for file connector, i know it is for some other (Outlook, salesforce etc.) can you share your connections.json? – viktorh Apr 27 '23 at 06:24