Bruno DEMEYERE
My feedback
-
1 voteBruno DEMEYERE
shared this idea
·
-
25 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 votesBruno DEMEYERE
supported this idea
·
-
34 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). -
113 votesBruno DEMEYERE
supported this idea
·
-
45 votesBruno 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
·
-
16 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
·
-
41 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.
-
294 votesBruno 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
·
-
253 votesBruno DEMEYERE
supported this idea
·
-
91 votesBruno 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
·
-
159 votesBruno 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. -
417 votesBruno DEMEYERE
supported this idea
·
-
1 voteBruno 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.