Automating APIM Updates with Swagger via DevOps

Until recently, I did not have too much experience with Azure API Management (APIM). However, using a Swagger doc to import endpoint data under the Open API option clears the public URL. There are two problems there. First, I had to manually import the Swagger doc for each environment after each deploy. That’s a huge waste of time. Second, the import was clearing values that it shouldn’t.

Because of this I set out to try to automate this process. There are Powershell modules programmatically change APIM from Microsoft. I was able to get most of the way using Powershell on my local machine, but needed to run it in the pipeline in order to have full access to what the process needed. I ran into a bunch of issues there such as the commands could not be found. That’s when I found another link in Azure DevOps that pointed to a different set of documents that did pretty much the same thing…

It looks like Azure uses a different set of Az commands to perform this sort of functionality within a build/release pipeline. This documentation was rather vague. It didn’t state where the parameter values should come from and there were no examples. Being unfamiliar with APIM I, teamed up with a coworker to figure out what values each parameter should have with some trial and error. Below was what worked for me.

Azure CLI Task Configuration

- task: AzureCLI@2
 inputs:
 azureSubscription: ‘[service connection here]’
 scriptType: ‘pscore’,
 scriptLocation: ‘inlineScript’
 inlineScript: ‘[az afim api import script detailed below]’
Az aim api import script

az apim api import — specification-format OpenApi — specification-url [url to spec file] — service-url [URL the service is exposed on] — resource-group [name of resource group the APIM instance is in] -n [name of APIM] — api-id [name value in API settings tab] — path [URL suffix (“/” if empty)]

Small side note. If you run into a Service Unavailable error when running the import add a Powershell task with `Start-sleep -Seconds 60′ between the deploy and the import. The service is still spinning itself back up and is unavailable for import during that time.

Once we figured out what went where in the command it was smooth sailing. I hope this can help to make this process easier for the next developer. Until next time!