Use case — I want to import a Logic App as an API within my APIM instance.

There is no direct way to get the swagger file of a logic app using CLI (at least, I could not figure out). So, detailing the steps to extract the swagger definition of a logic app. I use the generated swagger file to import a Logic App as an API within APIM using Azure CLI

1. Provide the service principal contributor role to the logic app

• Get the resource id of the logic app —

$logicAppResourceId = (az logic workflow show –resource-group “{resourcegroup-name}” –name “{logicAppName}” –query id –output tsv)

• Provide contributor role for the service principal —

az role assignment create --assignee {sp-id} - role Contributor –scope $logicAppResourceId

2. Get the swagger file from the Logic App

• generate a JW token from https://login.microsoftonline.com/{tenantId}/oauth2/token for the service principle with resource as “https://management.core.windows.net/”

$tenantId = “11111111-1111-1111-1111-111111111111”
$clientId = “00000000-0000-0000-0000-000000000000”
$clientSecret = “your-client-secret”
$resource = “https://management.core.azure.com/"

$body = @{
grant_type = “client_credentials”
client_id = $clientId
client_secret = $clientSecret
resource = $resource
}

$response = Invoke-RestMethod -Method Post -Uri “https://login.microsoftonline.com/$tenantId/oauth2/token" -ContentType “application/x-www-form-urlencoded” -Body $body

$accessToken = $response.access_token
$accessToken

• construct the swagger URL for the logic app —

$swaggerUrl = “https://management.azure.com” + (az logic workflow show –resource-group “{resourcegroup-name}” –name “{logicapp-name}” –query id –output tsv) + “/listSwagger?api-version=2016–06–01”

• Issue a POST request to $swaggerUrl to get the swagger definition of the LogicApp using Postman (or any other option you prefer)

3. Import into APIM

• Run the below command to import the above swagger file to APIM

az apim api import –resource-group “{resourcegroup-name}” –service-name “{apim-instance-name}” –path “/v1” –api-id myapi –specification-path “.\logicapp.backend.swagger.json” –specification-format Swagger

4. Remove the contributor role for the service principal

az role assignment delete –assignee 00000000–0000–0000–0000–000000000000 –role “Contributor” –scope $logicAppResourceId

There are couple of ways to integrate an APIM with Logic App. The most common use case as far as I know is exposing the Logic App as an API on the APIM. The other scenario is calling a Logic App from APIM.

I will provide the APIM policy snippet to call a Logic App. If you are using Managed Identity to authenticate to Logic App (will cover in a separate article), you can skip sending the bearer token.

Few steps to be done in the Logic App

1. enable Authentication at the Logic App end

2. the Logic App URL should not contain the SAS token

3. make sure that the Logic App has the below in trigger section. Basically, this is the ensure that the Logic App expects the Bearer token and “IncludeAuthorizationHeadersInOutputs” ensures that the Auth token is available for further processing within the Logic App

   “triggers”: {
   “manual”: {
   “conditions”: [
   {
   “expression”: “@startsWith(triggerOutputs()?[‘headers’]?[‘Authorization’], ‘Bearer’)”
   }
   ],
   “inputs”: {
   “schema”: {}
   },
   “kind”: “Http”,
   “operationOptions”: “IncludeAuthorizationHeadersInOutputs”,
   “type”: “Request”
   }
   }

APIM Policy to call the Logic App

We issue a call to the Logic App from with the . The response from the Logic App is captured in response-variable-name=”responsela”.

<policies>
<inbound>

    <send-request mode\="new" response-variable-name\="responsela" timeout\="20" ignore-error\="false"\>  
        <set-url\>https://xxxxxxx.com:443/workflows/xxxxxxxxxxxx/triggers/manual/paths/invoke?api-version=2016-10-01</set-url\>  
        <set-method\>POST</set-method\>  
        <set-header name\="Content-Type" exists-action\="override"\>  
            <value\>application/json</value\>  
        </set-header\>  
        <set-header name\="Authorization" exists-action\="override"\>  
            <value\>Bearer \*\*\*\*</value\>  
        </set-header\>  
    </send-request\>  

    <return-response\>  
        <set-status code\="200" reason\="OK" />  
        <set-body\>@(((IResponse)context.Variables\["responsela"\]).Body.As<JObject\>(preserveContent: true).ToString())</set-body\>  
    </return-response\>  

</inbound\>  
<outbound\>  
    <base />  
</outbound\>  
<on-error\>  
    <base />  
</on-error\>  
<backend\>  
    <base />  
</backend\>  

</policies>

All the tags are quite self-explanatory and there a loads of documentation available about them. is very useful policy, it suspends further policy pipeline execution and returns to the caller.

Hope this helps.

Cheers!

If you have been using Azure App Services for a while to host your API, there is a small chance that you would have encountered the issue with a faulty instance. Your API just doesn’t respond or keeps crashing in a particular instance. And, if your ARR Affinity was enabled, your problems will just be exacerbated. Some users will always be routed to the faulty instance.

AFAIK, there are no straight forward way to release an instance that is allotted to you by Azure for the given App Service Plan. Adding more instances and removing instances (scale out / in) will not guarantee that the rogue instance will be released. I will share the approach I took to get rid of the rogue instance. Note that, the approach below needs your app service to be out of rotation and should not be serving incoming requests.

Assume that you suspect that a given instance in your App Service Plan has issues and is crashing frequently and you wish to remove this instance. As of today, there is no way to select an instance and remove it via the Azure Portal (yes, you can stop an instance from Process Explorer, but it would still not get rid of the instance). One way to achieve this would be to use vertical scaling (up/down). When you scale up/down Azure allocates necessary hardware based on the target pricing tier you have chosen. The infrastructure differs significantly across tiers and moving across tiers will almost always guarantee different infrastructure allocation. We will use this to get rid of the rogue instance.

Start by scaling down to a lesser tier (moving laterally within the same tier may not help) For instance, if you are operating on a Premium tier, move to Standard. This action will make Azure allocate new instances in the lesser tier that you have chosen. Now, after scaling down, scale up again to your target pricing tier. When you do this, you are going to be allocated fresh (at least not the old rogue) instances. This is how I got rid of one of the instances that was bothering me.

Hope this helps.

There are many options available when it comes to mocking API response, like, JSON server or even having a response JSON file added to your solutions, to cite a few. In this article we will see how Azure function proxies can be used to mock API responses.

Azure function provides an elegant option to mock API response using proxies. Using a Azure function proxy, you can provide a mock endpoint which can be used by your team to continue their work till your actual API is ready for integration.

Let us go ahead, create a simple proxy and see how the mock response is served.

We will be creating a proxy end point which will service a GET call, say, getCustomer. Our getCustomer API method is expected to provide a response in the below format. So, till getCustomer is up and ready for consumption, our proxy can be used to get the below JSON as mock response.

Below are the steps for create a Function proxy.

Step 1: We will create an Azure function app which will host the proxy. (If there is already a general purpose / maintenance Function App present we can use that.)

Step 2: Now that we have created the function app to host our proxy, let us create our proxy. Choose the “Proxies” item in the Azure function blade as shown below. Click on “Add” to create a new proxy. We will call this MockCustomerAPI

And we will provide a route /api/getcustomer. In the HTTP Method section, we select “GET”. Please note that we can choose to mock other HTTP methods like POST as well.

Step 3: This is the step where we will provide the response we want the proxy to send us back. We will override the response as shown below by expanding the “Response override” link and paste our mock response in the space provide in Body section.

We can provide the status code and status message as per our use case and click on “Create”. Once the proxy gets created successfully we will be provided with a link to access the proxy as shown below

Step 4: Now that we are done with creating the proxy, let us test. To test our proxy, copy the generated proxy URL and open in the browser. We will see the response as below

Thus, we have created a proxy for the getCustomer API which can be used by the UX team or other API teams to integrate during the early development cycles when our API is not ready yet. Please do note that mocks are not just for GET method, you could do other HTTP methods as well

Some of the advantages of this approach are

1. Mock API responses unblocks the collaborating team like UX team as they can work against the mock endpoint till the actual API is ready
2. Testing is easier and thorough if your API relies on a partner API. Creating a mock endpoint gives you the flexibility to change the response and test your code for all possible, allowed parameter values from the partner API
3. If there is a dependency on partner API which is not available in your lower environments, you can resort to creating a proxy in lower environment.
4. As it is hosted in a common URL, same contract will be used across all crews consistently. Any change done to the contract will be immediately visible to all the consuming developers.
5. Eliminates the need of having a separate JSON response file or JSON server on local dev box and thus ensure you are developing against the latest contract

Before we conclude, a note about CORS: If you are hitting the proxy from your front-end web application, please ensure you tweak the CORS setting for the mock function app accordingly as show below

Conclusion

There are many useful feature of Azure function Proxies like redirection and route template parameters. You can read more about Azure Function proxies in official Microsoft documentation.

Scaling cloud resources dynamically is a fascinating topic. Microsoft Azure provide quite a few ways to dynamically scale resources. This article focuses on creating a scheduled vertical scaling (scaled up/down) of App Services. The approach outlined here can be used for other Azure resource like SQL Databases, Redis Cache or in fact pretty much most of the Azure resources that support scaling. Just to clarify right at the outset, we are talking about vertical scaling (between pricing tiers) and not horizontal scaling (scale in/out) wherein we deal with the number of instances at our disposal.

It is a common knowledge that Azure provides out-of-the-box options to scale out/ scale in based on the scaling rules for App Service plan but there is no way to scale up / scale down as per some schedule.

For instance, there is no direct way to say that between 10 AM and 12 Noon, let my App Service plan run on P2V2 and come back to P1V2 there after or have my SQL Server move up to P6 for a few hours before coming back to S2. In other words, no option to scale up/scale down based on schedule

Note on Serverless Azure SQL Database :- We have Serverless Azure SQL Databases with two key capabilities which make them attractive in terms of cost. 1. The option to auto scale up / down between the minimum and maximum threshold 2. Auto-pause — wherein the SQL Server is stopped after a predefined period of inactivity till some activity is detected again. You don’t get charged for the period of inactivity. The downside is that it will take some time of the SQL Server to warm up and be available for the next use after the period of inactivity. Serverless is best suited for test / dev environments where you have tolerance to the brief period of connection unavailability during the warm-up. There could also be slight performance degradation for sometime as the cache memory are gradually reclaimed. Serverless is not for your use case if these limitations are not acceptable. Furthermore, there are cases when although your usage will be limited for an interval you cannot afford to shut down the server using auto pause. Without auto pause you will be charged for the minimum number of vCores and minimum memory configured. For more details, refer to Microsoft documentation on Azure Serverless SQL Database

So, if your case is such that you will want to use DTU based provisioning and still want scaling based on a schedule as you have predictable utilisation, you can use the approach outlined in this article. One example that comes to my mind is bumping up your DTU for a few hours when you are doing a performance test or scaling down during a seasonal / weekend low utilisation to save costs.

Alright, now that we have context set, let us move on to see how we can achieve this scheduled vertical scaling for Azure resource in the following section

To start with, create an automation account. Details on how to create automation account can be found here. Azure Automation allows us to invoke runbooks as per a schedule. We will leverage this capability for our purpose. Please remember to select the option to create a RunAs account while creating the Automation account as shown below. This is the principle under with the runbooks can execute.

After the automation account is created, create two Runbooks which will be invoked by a scheduler to perform the scaling operation automatically without our intervention. These runbooks will contain PowerShell scripts to perform the scaling operation based on your need. (one for Scale up and another for Scale down) The fact that we use PowerShell to perform the scaling gives us the option to scale pretty much all resource for which you can get hold of PowerShell scripts to scale; and the best source for PowerShell reference is Microsoft’s official documentation.

Now that you have the automation account and the runbooks that you need, create a schedule and link these runbooks as per your need. (I won’t go into details on creating a schedule as it is very well documented and simple. Refer to Microsoft’s documentation on how to create a Schedule )

So, for instance, the below schedule will automatically call the “ScaleDown” runbook at 5:10 AM on 7th Feb

The below PowerShell script can be used to scale up / down an App Service Plan

Write-Output “API Scale”

$connectionName = “AzureRunAsConnection”
try {
$servicePrincipalConnection=Get-AutomationConnection -Name $connectionName

Add-AzureRmAccount -ServicePrincipal -TenantId $servicePrincipalConnection.TenantId -ApplicationId $servicePrincipalConnection.ApplicationId -CertificateThumbprint $servicePrincipalConnection.CertificateThumbprint

Set-AzureRmAppServicePlan -ResourceGroupName “«yourresourcegroup” -Name “«yourappserviceplanname” -Tier PremiumV2 -NumberofWorkers 2 -WorkerSize “Medium”}

catch {
if (!$servicePrincipalConnection){
$ErrorMessage = “Connection $connectionName not found.”
throw $ErrorMessage } else{
Write-Error -Message $_.Exception
throw $_.Exception
}}

In case you receive an error as below, go and update the PowerShell modules in your automation account. That should fix the issue

The term ‘Set-AzureRmAppServicePlan’ is not recognized as the name of a cmdlet, function, script file, or operable program.

Below, I have provided a sample PowerShell to scale a SQL database; it scales to database to P1 tier. This script uses a credential to perform the DB scaling as opposed to the AzureRunAsAccount in the previous PowerShell.

To create a new credential, navigate to your automation account and select the “Credentials” option in the “Shared Resources” section. Refer to the below screen shot showing the credential creation

param([parameter(Mandatory=$true)] [PSCredential] $Credential )

# Name of the Azure SQL Database server
[string] $SqlServerName = “yourserver.database.windows.net”

$Servercredential = New-Object System.Management.Automation.PSCredential($Credential.UserName, (($Credential).GetNetworkCredential().Password | ConvertTo-SecureString -asPlainText -Force))

$CTX = New-AzureSqlDatabaseServerContext -ServerName $SqlServerName -Credential $ServerCredential

[string] $DatabaseName = “yourdb”
[string] $Edition = “Premium”
[string] $PerfLevel = “P1”
$Db = Get-AzureSqlDatabase $CTX –DatabaseName $DatabaseName

Write-Output “Database Scale state " - $Db.ServiceObjectiveAssignementStateDescription

if($Db.ServiceObjectiveName -ne $PerfLevel -and $Db.ServiceObjectiveAssignementStateDescription -ne “Pending”){
$ServiceObjective = Get-AzureSqlDatabaseServiceObjective $CTX -ServiceObjectiveName $PerfLevel

# Set the new edition/performance level
#None, Business, Web, Premium, Basic, Standard”

Write-Output “Trigger the scale operation”
Set-AzureSqlDatabase $CTX –Database $Db –ServiceObjective $ServiceObjective –Edition $Edition -Force

Write-Output “Completed vertical scale”
}else{
Write-Output “The DB is already in the target pricing tier Or DB is currenlty being scale up / down”}

This same approach can be applied for other Azure resources also. Go on and try it out!

Happy Scaling!