I had to troubleshoot an Azure App Services solution that I didn’t develop myself. In the solution a message was sent by a web app to a servicebus queue named From4PS_queue. This action activated a logic app with a servicebus queue trigger. The question was: which servicebus queue is used?
In the Azure Portal I found a service bus named SupportCalls for development, test and production. At the servicebus level I found an ACS policy named SharedAccessKey. After doubleclicking this ACS policy I found the primary connection string for the servicebus. I also found four queues at the servicebus level. Among these queues was the queue I was looking for. This queue had two shared access key policies: api for sending messages to the queue and logicapp for reading messages from the queue. Both access key policies also held a primary connection string.
In the app settings of the api app the primary connection string of the queue (policy: api) was used. I could see this right away from the appsettings of the api app. The settings for the logic app were harder to find. In the logic app’s parameters file I found the servicebus connection string TstSupportCalls (not the queue connection string, not the Dev version). This was confusing, because the setting from the pameters file is actually not used. When I turned to the json file, I saw the queue trigger with a connection named DevSupportCalls. From the resource group of the API connection I could reassure myself that the servicebus connection string DevSupportCalls was used. The name of the queue was entered in another property of the API App.
Think * Share * Integrate 