Bruno DEMEYERE
My feedback
-
9 votesunder review · 3 comments · API Management » API management experience · Flag idea as inappropriate… · Admin →
Bruno DEMEYERE supported this idea ·
An error occurred while saving the comment -
5 votes
Bruno DEMEYERE supported this idea ·
-
27 votes
Thanks for the feedback!
Bruno DEMEYERE supported this idea ·
An error occurred while saving the comment Bruno DEMEYERE commented
The memory consumtion of the cache instance would be useful too.
And in documentation, the precision of the behavior of APIM when total memory cache is reached whould be usefull and comfortable (I suppose in this case you get a cache "miss" rather than an error, but I not totaly sure either). -
100 votes
Bruno DEMEYERE supported this idea ·
-
45 votes
Bruno DEMEYERE supported this idea ·
An error occurred while saving the comment Bruno DEMEYERE commented
In a general way, a way to access (in gateway logs for example) to client side transport security protocol (TLS 1.0 , 1.1 ...) would be great to be able to better plan our TLS security updates.
-
1 vote
Thank you for the suggestion, Bruno! Backend URL and status code are already available via context’s Request and Response members. It would help if you can share what sort of analyses you would like to perform in outbound policies.
An error occurred while saving the comment Bruno DEMEYERE commented
Hi I made further tests and in fact I ws wrong about URL and return code. If you get Request.URL just after backend call you get the info even if backend url was changed before the call. I don't know why I figured it was a static info (the service url configured).
The same for response.ReturnCode I can get it before it is changed by a policy.
So the improve could be limited to have only backend call duration (but I could calculate it via policy too).
So I suggest you archive this request. Thanks again for your interest.An error occurred while saving the comment Bruno DEMEYERE commented
Hi, thanks for your interest. In APIM native gateway logs you have a lot of interesting informations about backend call like backendMethod, backendUrl, backendResponseCode, backendTime, backendProtocol. You're right there is some information in Request or Response, like service URL or responce code. But the response code or backend url can be manipulated by process (by example a policy can change backend url, a backend response call can be reinterpreted ...). In this case I'm not sure that the context will provide the right information. The return code seems to be the final one (the one finally returned by APIM). In gateway logs, the informations are clearly distinctive and richer. I would be very interested to have this clear level of information in policies (for my custom logging for example).
Bruno DEMEYERE shared this idea ·
-
13 votes
Thank you for the feedback! We added this suggestion to the backlog and will update the item when we prioritize it for implementation.
Bruno DEMEYERE shared this idea ·
-
49 votes
Please see this FAQ – https://docs.microsoft.com/en-us/azure/api-management/api-management-faq#is-the-api-management-gateway-ip-address-constant-can-i-use-it-in-firewall-rules. If you don’t re-create API Management instance on every deployment the IP address will remain the same (and deployments will take significantly less time too). Does this address your concern?
An error occurred while saving the comment Bruno DEMEYERE commented
For my case we never recreate the overall instance when deploying an API or other operaiton on APIM. But in case of a need to restore an overall APIM (serious outage, return back to a previous version, need to duplicate on another region ...) we would need to be able to keep the same adress.
Bruno DEMEYERE supported this idea ·
An error occurred while saving the comment Bruno DEMEYERE commented
It would be great to be able to re provisioning an overall APIM instance (for exemple with Terraform) and be able to assign the public IP (usefull for reset of dev environments for example).
Even in production env, according to documentation, you are not sure your public IP will not change in case of major outage.
-
10 votesunder review · 0 comments · API Management » API management experience · Flag idea as inappropriate… · Admin →
Bruno DEMEYERE supported this idea ·
-
38 votes
Thanks for the feedback, keep votes coming!
An error occurred while saving the comment Bruno DEMEYERE commented
The problem is that JSON don't support comments where XML does.
-
274 votes
Bruno DEMEYERE supported this idea ·
-
1 vote
Thank you for the feedback! We added this suggestion to the backlog and will update the item when we prioritize it for implementation.
Bruno DEMEYERE shared this idea ·
-
221 votes
Bruno DEMEYERE supported this idea ·
-
87 votes
Bruno DEMEYERE supported this idea ·
-
10 votes
An error occurred while saving the comment Bruno DEMEYERE commented
A more flexible behavior would be to be able to choose any property of API context to be added to Log analytics by configuration, for example "context.Operation.Name" (via "overide menu" of Azure Monitor in API settings).
Bruno DEMEYERE shared this idea ·
-
153 votes
Bruno DEMEYERE supported this idea ·
-
103 votesunder review · 1 comment · API Management » Developer portal · Flag idea as inappropriate… · Admin →
An error occurred while saving the comment Bruno DEMEYERE commented
As a workaround you can assign your "API products" to users groups by using "Access control" on "API products".
Users can still "sign up" but they don't see any API or product on the portal until you move them user to the correct user(s) group(s). Even better, users don't see all APIs but only those authorized for their group. -
398 votes
Bruno DEMEYERE supported this idea ·
-
1 vote
Bruno DEMEYERE shared this idea ·
On a regular basis we have errors of type "BackendConnectionFailure/The underlying connection was closed: A connection that was expected to be kept alive was closed by the server".
It happens only on specific hosts (and some are not under our control).
I search for a way to avoid persistent connection with those host (or to be able to deal with keep-alive parameter at APIM side). Settting header "Connection" or "Keep-alive" are not allowed in APIM policies (it results an error when trying to save policy).
I think being able to set specifics connections settings on a per backend basis could be helpful to deal with those kind of errors.