Hi,

When updating the API Management instance virtual network configuration through REST API/Azure Portal and then applying the virtual network configuration through REST API/Azure Portal, even after the service takes 15-45 minutes to update and then again 15-45 minutes for applying VNET configuration, when navigating to the Azure Portal i can still see pending VNET configuration as the "Apply VNET Configuration" button is not disabled. Even though when checking the Activity log the service was updated successfully and apply configuration was also successfully completed.

If possible can we add a feature to check when the last Network configuration update was applied or maybe a history tab.

This bug still is there as per my observation.

Thanks and Regards,
Sudeep Yadav

When setting up an APIM API and a backend in the portal, we are able to select a Logic App using an experience to find the logic app and the sub-resource. Then a radio button for Azure Logic App resource is selected with the name of the logic app and sub-resource. However, in an ARM template, this is impossible. Setting up the backend to point to the resourceId of the logic and deploying defaults this backend policy to HTTP and does not work unless fixed manually in the portal. Here is the snippet of the ARM template:

    {

        "type": "Microsoft.ApiManagement/service/backends",

        "apiVersion": "2019-12-01-preview",

        "name": "[concat(parameters('apiManagementServiceName'), '/', parameters('statusLogicAppProducerName'))]",

        "dependsOn": [

            "[resourceId('Microsoft.ApiManagement/service', parameters('apiManagementServiceName'))]"

        ],

        "properties": {

            "description": "[parameters('statusLogicAppProducerName')]",

            "url": "[parameters('statusLogicAppProducerUrl')]",

            "protocol": "http",

            "resourceId": "[parameters('statusLogicAppProducerId')]"

        }

    }

"protocol" enum only allows for http or soap, and this results in an non-working backend policy, so you must go to the portal and fix it. Not a great solution for a CI/CD pipeline without manual touches and RBAC in place for a production deployment.

Suggestion: Allow for selecting an azure resource in ARM Templates and match the experience in the Portal.

We have decided to go all in when it comes to ARM Templating, and our goal is to depend on as few parameters as possible and instead retrieve as may information from the system settings as possible.

While creating ARM Templates for Api Management I discovered that what i did see on my Azure Portal in Api Management Service in the Gateway Url property was not the value to be found when retrieving it using my ARM Template. Trying to figure out what happens i did a REST Api lookup and to my big surprise GatewayUrl via REST Api and Azure portal UI differ.

Of course i found the expected hostname in the hostnameConfigurations array in my case it was index 3, but if i have to retrieve my wanted informations from the array i have to add additional logic to figure out the correct index. And i would consider this a bad workaround.

If have to admit, that i do not understand why the Azure Portal UI and the REST Api differ, to me it means that microsoft has performed a workaround in the Azure Portal UI instead of correcting the data stored in the GatewayUrl property. As I see it the GatewayUrl should always reflect the entry in the array hostnameConfigurations where the property defaultSslBinding is set to true.

Maybe too few are using their own domains in ApiM so this has not been seen as a topic yet, but i still hope you will consider correcting this.

To me it looks like a minor change, that will make life easier and less confusing.

Right now, the "Subscription count limit" under Product -> Settings applies to the number of subscriptions without a user too. This should not be the case, the number of subscriptions you can create from the Azure Portal, without being assigned to a user, should not be limited to the "Subscription count limit". I understand that this limitation is by design and that currently, this limit applies to a user/product combination. However, subscriptions that have a "null" username should be exempt from this limit. I would suggest having a separate configurable limit here for non-user subscriptions or configuring this number to be unlimited.