How to Expose and protect Logic App using Azure API Management (Part 3) – Exposing multiple Logic Apps in a single API

It has been a while since I wrote about this topic. I didn’t finish this blog series for several reasons, and now, one year later, it is the right time to continue this story. In the first part of this blog series, I have explained how you can expose a Logic App in API Management. It is a straightforward and simple process. Microsoft did a great job on this user experience. But the main questions I want to address in the post are:

• If we have one or more Logic Apps that we want to expose on APIM as an API, do we need to have several APIs with one operation? Or can we combine them in a unique API?
• What about implementing a proper REST naming convention on these APIs? Is it possible?

The quick answer to these questions is: Yes, we can combine multiple Logic Apps in a unique API. And yes, it is possible to change the default configurations and implement a proper REST naming convention.

The scenario

Let’s imagine we have the following Logic Apps:

And we want to expose them as a single API on Azure API Management called: BizTalk Alerts API with the following operations:

• POST bts-host-instance-alert
• POST bts-ports-alert
• POST bts-suspended-instances-alert

The problem

If I try to expose/import all the Logic Apps that we want using the default process described in the first part of this series:

• Access to your APIM on the Azure Portal.
• And on the left menu, under the APIs section, click the APIs option.
• Select the button + Add API just above the All APIs list available.
• On the Add a new API panel, you will find several different options to add a new API to your list:
  • Select the Logic App option.
• This will open a Create from Logic App form that will allow us with a few clicks to ingest our logic app configuration into APIM.
• To do that, we need:
  • On the Logic App attribute, click on Browse and select the Logic App we want to expose from the available Logic App list inside our subscription that can be triggered using an HTTP based trigger like the Request trigger.
  • This will fill all the required fields with default values except for the API URL suffix you need to provide.
  • To finish, click the Create button.
• After you have done that, the wizard will create one API exposing the Logic App under a POST operation called manual-invoke with the URL /manual/paths/invoke.

What happens is that by doing that, we will end up having three (3) different APIs with a single operation called manual-invoke with the same URL /manual/paths/invoke only having a distinct API URL suffix:

• https://saspapimanagement.azure-api.net/a/manual/paths/invoke
• https://saspapimanagement.azure-api.net/b/manual/paths/invoke
• https://saspapimanagement.azure-api.net/c/manual/paths/invoke

And if you think that, maybe if I give the same API URL suffix that we provide on the first exportation, the wizard will be smart enough to add a new operation to an existing API, that will not going to happen

You will also not have the importation wizard on the + Add operation option inside an existing API. You have to do it manually.

This behavior is not what we want to archive. Neither is according to REST best practices. So, how can we improve this? How can we do better?

Exposing several Logic Apps as different operations inside API using REST best practices

To expose our 3 Logic Apps as different operations inside API using REST best practices, we will be going to start by using the default importation process:

• Select the button + Add API just above the All APIs list available.
• On the Add a new API panel, you will find several different options to add a new API to your list:
  • Select the Logic App option.

• This will open a Create from Logic App form that will allow us with a few clicks to ingest our logic app configuration into APIM.

• To do that, we need:
  • On the Logic App attribute, click on Browse and select the Logic App we want to expose from the available Logic App list inside our subscription that can be triggered using an HTTP based trigger like the Request trigger.
    • Let’s choose the first one, POC–Monitor-BizTalk-Host-Instances, and click Select

• • • This will fill all the required fields with default values, but we don’t want this configuration.

• • • Instead, let’s change to these values:
      • Display name: BizTalk Alerts API
      • Name: biztalk-alerts-api
      • API URL suffix: biztalk-alert

• • • To finish, click the Create button.

We now have a new API with the proper name, BizTalk Alerts API, but we still have a manual-invoke POST operation with the URL /manual/paths/invoke. Now the next step is to fix this configuration to have a proper REST best practice naming convention. And we can do this by:

• Select the manual-invoke operation, and on the Frontend panel, select the Open form-based editor

• On the Frontend editor panel, modify the following values and then select Save.
  • Display name: change from manual-invoke to host-instances-notification
  • URL: keep it POST operation but change the value /manual/paths/invoke to /host-instances/notification

Now we have our first Logic App exposed in API Management with a proper naming convention. You can go ahead and try it.

To add the remaining Logic Apps, we will use a different process:

• Select the API you created in the previous step, BizTalk Alerts API.
• And just above the All operations list, click + Add Operation.

• On the Frontend editor panel, add the following values and then select Save.
  • For the Display name type ports-notification
  • You can leave the Name as it is ports-notification
  • In the URL, choose POST and enter /ports/notification

• On the operation that you created in the previous step, select Open Backend editor on the Backend panel

• On the Backend editor panel, modify the Target attribute to be Azure Logic App, and then on the Azure Resource, select Browse

• On the Select Logic App trigger to import panel, click Logic App and from the Select Logic App to import panel list, select the Logic App you want, in our case, POC-Monitor-BizTalk-Ports, and click Select.

• Back to the Select Logic App trigger to import panel, select the Name of the trigger, manual, and click Save.

• Back on the Backend editor panel, click Save.

Now we have two Logic App exposed in API Management with a proper naming convention. You can go ahead and try it again.

Finally, we need to do the same steps for the last Logic App, but in this case, on the Frontend editor panel, you need to add the following values

• For the Display name type suspended-instances-notification
• Leave the Name as it is suspended-instances-notification
• In the URL, select POST and enter /suspended/instances/notification

And on the Backend editor panel, we need to select our last Logic App: POC-Monitor-BizTalk-Suspended-Instances.

In the end, you will have a single API: BizTalk Alerts API composed of 3 operations with the following URLs:

• POST host-instances-notification: https://<apim-name>.azure-api.net/biztalk-alert/host-instances/notification
• POST ports-notification: https://<apim-name>.azure-api.net/biztalk-alert/ports/notification
• POST suspended-instances-notification: https://<apim-name>.azure-api.net/biztalk-alert/suspended/instances/notification

With this approach, you will have a better way of exposing and combining your Logic Apps in different APIs according to that API’s scope. And above all, doing it following and implementing REST best practices.