Using Integration Manager with Azure App Services / Logic Apps

This blog contains a list of our blog posts with our findings for bugs and feature requests about the new Azure API App Services / Logic Apps.


We are commited to bring the same user experience with all functionality, support and capabilites for your cloud enabled system integrations as we today offer for on-prem BizTalk Server enabled system integrations.

Integration Manager is a productivity tool that helps you save time and get in control. We alse provide insights for your organization to intimate details about all the data also including artifacts, messagetypes, SLA levels, servers… all information about your valuable resources, all in one tool.

  • Logging
  • Monitoring
  • Reports
  • Repository  / CMDB

Current status and findings

We have already successfully built logic apps that logs events and body data to Integration Manager. We also provide monitoring capabilites of Logic Apps from within Integration Manager. All resources part of a distributed system can be monitored (Windows Services, queues, databases, BizTalk resources, API endpoints…)

The following blog posts pinpoints individual findings we encountered while developing, testing, deploying functionality to enable monitor and logging functionality for use with Integration Manager.

# IM Type Description Blog Workaround / Solution / Comment Resolved?
0 Feature Request Re-configuration of API Apps Link See blog post false
1 Log Feature Request Problems using Workflow Definition Language in Logic Apps Link false
2 Monitor Bug Logic App Workflow API documentation is incomplete Link false
3 Log Feature Request BizTalk transformer API service still requires Visual Studio 2012 Link See blog post false
4 Monitor Bug Hybrid Connections – Could not load file or assembly Newtonsoft.Json Link See blog post false
5 Monitor Feature Request Changing the order of connectors in your Logic APP not possible in designer view Link See blog post false

Column IM shows to which IM capability this post is related to.

Azure App Services Series – Finding #0: Re-configuration of API Apps

This blog post is the first blog of a series we have about Microsoft Azure App Services. See a list of all our findings here.


Re-configuring API apps added to your subscription is a task that will be a common task for everybody working with API & Logic Apps. Let us say we have an FTP connector used in our Logic Apps and the user’s password used in the FTP connector has changed.

The Solution

Doing that or finding the way of doing that is not the most intuitive way – you first need to select the API app itself, click on the API app host, select settings, application settings and scroll down in the blade to find the settings (see screenshot 1).

Change connector settings.

Change connector settings.

Our Wish

We would like a direct link to the settings in the API app/connector blade of Azure’s new portal instead of needing to open and wait for two other blades to load.


Link to feedback forum:

[UPDATE] Problem when using connectors of same kind in same logic app

UPDATE 2015-04-15

Microsoft has released an update to this issue now showing you the name of the connectors in your resource group.

Updated Workflow showing name of connector instance

Updated Workflow showing name of connector instance


Microsoft recently released Microsoft Azure App Service in preview – which enables you to build Logic Apps.

We came across a minor problem while creating and working with logic apps – which connector has which name when having the same type of connector in the current resource group.

Demo Scenario

Let us say you have a logic app that reads from one FTP Server (your internal ftp) and you need to upload the file to another FTP Server.

For this scenario we need to have two FTP Connectors in our resource group of the Logic App – in my example I have called them “FTPSourceServer” and “FTPTargetServer”.

Let’s take a look at the Logic APP triggers and action interface and see how it looks like (see screenshot 1 below).

Azure Blog april 13th - triggers and actions

Screenshot 1 – Triggers and actions interface


The Problem

How do we know which of the FTP connectors we see is either “FTPSourceServer” or “FTPTargetServer”, by just looking at the screen shown in Screenshot 1 above?

Short answer: In the current version, by 2015-04-13, we can’t by just looking at the designer view (the one on Screenshot 1).

Long answer: There is a work around! See “The Solution”.

The Solution

What you can do is to simply add the first in the list to the logic and simply choose the “File Available (Read then Delete)” trigger, save the changes and then switch to “Code View” (see screenshot 2).

Screenshot 2 - Add FTP Connector

Screenshot 2 – Add FTP Connector

You have now switched from the “Designer” to the “Code View” showing you the JSON data the logic app needs and uses in order for your logic app to work correctly. In order to find out which of the FTP connector you just added, simply search for the “triggers” section of the JSON file and see the name of the trigger – see screenshot 3.

Screenshot 3 - Name of trigger

Screenshot 3 – Name of trigger

As you can see, the name of the trigger is “ftpsourceserver”, which lets me know that the first FTP connector in the list of available API apps is the one FTP connector I called “FTPSourceServer” and of course the second in the list must therefore be the one I called “FTPTargetServer”. (Could be good to know that the JSON data is case insensitive when it comes to the object names – in case you would like to create the logic app’s code by your own.)

This is of course not the best way and I am sure Microsoft’s Azure team is aware of this issue and gets fixed soon – keep in my mind that the new interface of Microsoft Azure is still in preview as well as API and logic apps!