Develop the API App
Azure API Apps are pure Web API’s. To ensure smooth integration with Logic Apps, they should expose Swagger documentation. Therefore, you can use several libraries such as Swashbuckle or TRex.
When developing triggers, you can use the following patterns:
- Polling trigger: check for new data at regular time intervals. You can choose whether to continue polling when there is new data available. The TriggerState object is always passed on from the previous polling event to the next and can be used to identify new data compared with the previous run. You can find an example here.
- Push trigger: this trigger uses web hooks behind the scenes. When the trigger is saved, the Logic Apps registers its callback URL in the source system, for a specific event. When an event occurs, the source system API must push data to that callback URL, so a Logic Apps is triggered. When the triggers is deleted, the Logic App unsubscribes itself from the source system. You can find an example here.
When developing actions, you can use the following patterns:
- Request / Response: used for short running operations that can be executed in a request / response way, within an acceptable timeout limit. You can leverage the HTTP + Swagger to call these operations.
- Polling action: similar to the Polling Trigger pattern, you can use the polling mechanism to check whether a long running operation is completed or not.
- Webhook action: similar to the Push Trigger pattern, a specific Logic App instance will register a webhook in the target system API, to get notified when a specific event occurs. When a Logic App run is cancelled, the webhook gets unregistered. This pattern is optimized for long running operations.
Deploy the API App
The API app can be easily published from within Visual Studio when you are in development mode. There are multiple options to setup continuous deployment – using ARM templates is my personal favourite. You can find an example here.
Your Logic App will not discover the custom API App unless:
- You deploy the API App in the same subscription and region as your Logic App
- You set the API definition location to https://{name}.azurewebsites.net/swagger/docs/v1
- You allow CORS from the Logic Apps domains, or just allow all origins by using “*”
Debug the API App
Web APIs can run easily on your local development workstation, so local debugging is the most productive way to solve issues. However, in some particular cases, you want to debug the cloud instance of your API App. This is possible, if you configure it the right way!
- Enable remote debugging in the Application Settings of your API App
- Publish your API App in debug mode towards the cloud
- In Visual Studio open the Cloud Explorer and navigate to the API App. Choose Attach Debugger and within a few seconds, you can hit your breakpoints locally, but executed in the cloud.
Secure the API App
In many scenarios, you create custom API Apps to extend Logic Apps with functionality that should not be publicly available. It’s extremely important to know that, by default, Azure API Apps are exposed on the internet without any authentication / authorization applied. If you don’t take action, you can introduce a huge security breach!
Fortunately, there are authorization solutions available that require no coding at all! You can setup Service Principal authentication. Therefore the following steps are required, in depth documentation can be found here.
- Create an Active Directory app registration for the Logic App and the API App
- Enforce Active Directory authentication on the API App
- Provide the Service Principal credentials within the Logic App designer. It’s advised to retrieve client secrets directly from Azure KeyVault, as explained over here. The new Managed Service Identity feature can also be leveraged over here.
- When looking at the logs, it’s good to see that passwords and client secret are automatically sanitized:
Good luck with extending your Logic Apps through API Apps!
Subscribe to our RSS feed