Solidsoft Reply are experiencing a growing number of customers who are interested in understanding Logic Apps and API Apps and as a result of the increasing requirement, I decided to spend time dedicated to this topic.
There are many articles and blog posts about this topic, in this article I would like to present my first impression and feedback.
I would like to do a quick introduction about that but before to read this article I recommend to see this video of Josh Twist.
The difference between the API Apps and Logic Apps is, the API Apps are single atomics applications we are be able to develop and deploy in the Microsoft Cloud, they provide us the possibility to write and deploy .Net code.
The Logic Apps is the possibility to orchestrate our API Apps in a logical flow and creating and centralizing our logical processes.
The first time I saw the Logic Apps I tried to compare them with BizTalk and I think is quite normal for a person as me but this is a mistake, they are two different things, different architecture, different pattern, different approach used, but both of them are able to cover the same scope.
Compare Logic and API Apps with BizTalk is quite complicate because they uses two different approaches and patterns, BizTalk provides different components layers and levels, API Apps is a unique containers of micro application blocks and we use Logic Apps to organize them.
We can’t create a new BizTalk orchestration shape but we can do that with API App creating a new API App, in the Logic Apps we can’t have the same concept of BizTalk pipeline file but we are free to organize our pipeline, formed by API app components, inside the Logic App, as we prefer.
The API Apps are application containers which executing actions, we can have two different types of Apps, simple applications containers which formed by our .Net code, or Triggers.
To start a Logic App we need to use a trigger, a trigger could start in different ways, because called, because a polling rule is verified or manually.
Essentially the API App is a different representation of a Web API, to create an API App we need to use Visual Studio 2013, Microsoft provides the Microsoft Azure SDK which provides a new project template, the API App project template.
To create a new API App we select new project -> Cloud -> APS.NET Web Application -> OK.
Visual Studio proposes a new template, the Azure API App (Preview).
Logically the Web API checkbox is selected.
After the NuGet package installation we have all we need to develop the API App, but I don’t want to enter in details in this first article, I want to discuss about the concepts.
The directory organization is the quite similar to a Web API.
This is a good idea because the developers don’t need to upgrade their knowledge, we can see a Web API on the left and a API App on the right, they are using the same ApiController abstract class inside the assembly, System.Web.Http.dll, so what is the real difference.
API App uses a metadata description controller completely based on Json, also the Swashbuckle NuGet package provides an automatic Swagger metadata generation.
For more information about Swagger you can go in the official site http://swagger.io/
The provisioning is different, the API App template provide a deploy completely focused on that.
Right click on project file, select publish and click on Microsoft Azure API Apps.
After selected the subscription we are able to define how to deploy the API App, what I like here is the idea to keep separated the concept of project name from the API App name, we can define a different and multiple API App name.
Now select the canonical information and deploy the API App.
There are aspects that I really like about the internal architecture.
One is the swagger integration inside the API App, we can activate this feature simply uncommenting these lines of code inside the SwaggerConfig.cs file.
We can test our swagger documentation running our project, press F5.
Adding /swagger in the link url and select List Operations we are able to see the documentation.
The difference between a simple and general API App operation and a Trigger operation is because a naming convention.
In this week I’m developing an API App trigger which able to integrate my RFID reader, to define a trigger I just need to specify the “Trigger” word at the end of our methods.
My first question was … why not using a System.Attribute approach and enrich the class? but exist a good reason behind that.
This is a simple and common way for all the programming languages the API App supports and now API App supports .NET, Java, Node.js, Python and PHP.
The Azure platform recognize triggers from the Swagger API definition rather than the API app code itself, this is really cross-platform approach.
To define the Trigger mechanism we just only need to define the push or poll in the Route Sytem.Attribute
After the deployment we are able to see and use it inside the Logic App, open the browser and navigate in the https://portal.azure.com and select Browse and API Apps.
About Logic Apps and API Apps distribution, we have to consider two different sides, Admin and Developer, one is on premise the second is on the cloud.
Logic App uses triggers to integrate on premise and, of course, on Cloud technologies as SQL Server, File System and other more, in the first case.
Logically the trigger needs to interact with the on premise environment, this mechanism is provided by a service host application running in our on premise environment and using a relay binding on the cloud.
In the next articles I would like to explain more in detail about settings on on-premise side and on cloud side environments.
We have two different sides of settings, one is one the cloud and the other is on the developer side in Visual Studio and no many resources mention about that but I think is important.
Open the Azure node, in the Visual Studio Server Explorer and logging in to the subscription, now we are able to see many information about our API App as logging and tracing.
We have two different settings sides, one is on premise side inside Visual Studio.
the other one is in the cloud side.
We can also to debug our code remotely.
Another interesting area to consider is the on-premise integration layer, when we are going to use a trigger as SQL Connector, to communicate between the cloud and our on-premise environment, the Azure Platform creates a relay binding endpoint into the namespace.
This is the reason because we need to specify a namespace string during the API App trigger creation inside the Logic App.
In on premise side a host process is going to create the service layer interface to communicate with the trigger in the cloud.
There are a lot of things to discuss about the Logic Apps and API Apps architecture and there are a lot of things which running “under the hood, in this article I tried to collect the most important.
My feedback is, I like the approach and the idea, I think we missed a so powerful platform inside Azure.
I hope that with this article, other passionate developers as me, will be able to understand more about Logic and API Apps, I will write more in detail about any particular aspect in the next articles and videos.