I have a question about the use of the Azure Management Api. The architecture of the single responssabilidade Api predicts domain to perform the functions of the business area. See image structure.
enter image description here
1. I wonder if the Azure Api Management operates as a management or I have the possibility of using it as a Geteway add results of many APIs in one (
orchestrating) and available to the client that made the request?
2. The responsability to gather this data is the Web Application?
3. Is there a pattern?
Azure API management can do both, it started as a management tool, but has received some updates so it can act as a gateway as well.
Read about the different API managment policies you can create here: https://azure.microsoft.com/en-us/documentation/articles/api-management-policy-reference/
Or take a look at the advanced policies, with the control flow and the send request
https://msdn.microsoft.com/library/azure/dn894085.aspx
For an example of sending requests to gather information from multiple sources see this:
https://azure.microsoft.com/nl-nl/documentation/articles/api-management-sample-send-request/
Related
I have been following the Azure Service Bus REST API documentation located at https://learn.microsoft.com/en-us/rest/api/servicebus/
I'm required to know the total number of messages in a queue before reading the first message. However, I cannot see a request/command to simply get the total/count number of messages in a given queue.
Is this not possible via the REST API and only available to SDK?
Thanks
You can certainly get this information through REST API. In fact, there are two different REST APIs using which you can get this information.
Using Azure Resource Manager REST API - It is newer and recommended way to work with Service Bus Namespaces. The operation you would want to perform is Queues - Get. The response body will contain the details about the messages count. This API would require you to get an Azure AD access token which is then used for authorization.
Using Old REST API - Though not recommended but you can use old Service Bus REST API to get the information. The operation you would to perform is Get Entity. This API would require you to use your Service Bus Namespace's shared access key for authorization.
Having said this, it is still recommended that you use the SDKs instead of consuming the REST API directly as SDKs are simply wrapper over REST APIs.
Yes you can you need to access it via the management API, more specifically this https://www.nuget.org/packages/Microsoft.Azure.Management.ServiceBus.Fluent/
Here is a great link explaining exactly how to use that package and get the counters you are after
https://www.florinciubotariu.com/retrieving-number-of-messages-in-service-bus-in-net-core/
I am looking for some design guidance in using Azure APIM as a forward proxy between backend services (such as function apps or logic apps) and external clients.
We have a function app that processes invoice requests (for an order previously placed) from a mainframe system, does some transformations and sends them to an external party via HTTP. I have two options with the sending process.
Store external HTTP endpoint as an app setting in function app and let function app send the
transformed message directly to external party.
Send the transformed message to Azure APIM with the external HTTP endpoint set as the backend service (using set-backend-service APIM policy) and let APIM forward it to external party.
Now, are there are any real benefits with the second approach if the requirement is only to forward requests to external party from a security or operational standpoint? There are no requirements to enrich the outgoing message (add or remove headers, modify message body etc).
Personally, all I see is an extra hop with the second approach. But some of my teammates seem to think the second approach can offer some benefits in the way of analytics. There are some metrics available under APIM --> Analytics tab that lets you see the number of successful, failed requests etc. But I think this information is also available to Application Insights tied to the function app.
Just interested to see some insights around this so we can make an informed decision.
I guess using Azure API Management would be an over-engineering in your case, assuming the Azure Function is only going to be the caller of the Azure API Management instance.
Even though Azure API management provides analytics, url-rewrites, transformations, analytics etc - it makes more sense when you use it to govern the API. Ask yourself a question on, how many of the Azure API management functionalities are going to be leveraged fully in your case.
Remember Azure API management by design is an API governance tool where you can perform throttling, monetizing your API by giving access to it to different 3rd party with segregated subscription keys. In my opinion, Azure API management comes into the scene where you need to distribute some API to 3rd party applications, which clearly not in your case.
So far, using Azure service bus, I have managed to get data from purchase orders, payment logs, invoices, etc.
But my API was waiting that one of these events to happen. But now we need to do an active search and show all providers registered in dynamics.
So far the ways we found to get some information from dynamics were: MS Flow, Azure Logic Apps and the Azure service bus. But it all depends on an event within Dynamics 369 FO so that we can receive some information.
Instead of using the tools in Azure (which are fantastic in some scenarios), have you considered interacting directly with the OData endpoints directly exposed by the D365FO application? You can create custom data entities using MorphX/x++ and expose them as an RESTful OData endpoints (JSON format returned). There are also hundreds of out of the box data entities that are exposed without needing custom ones created.
Learn more here: https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/data-entities/odata
and here: https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/data-entities/build-consuming-data-entities
and code samples here: https://github.com/microsoft/Dynamics-AX-Integration
I've been working on developing an API to serve a machine learning model using Azure Machine Learning (AML) webservice deployments on a Kubernetes target as outlined here: https://learn.microsoft.com/en-us/azure/machine-learning/service/how-to-deploy-and-where#prepare-to-deploy
My particular use case requires more than simple scoring of data through the model. The API needs to have multiple endpoints to perform different actions related to the model. For example, an endpoint to upload data, an endpoint to delete data, an endpoint to list existing data, an endpoint to score previously uploaded data, an endpoint to change preprocessing parameters, etc...
I can build all of this logic, but I am struggling with the fact that AML web services only provides one endpoint (The service URI ending in "/score"). Is there a way to add more endpoints to an AML service? For example, I would like to have a way for users to be able to POST, GET, DELETE, PUT "/data", GET "/predictions", and POST, GET, DELETE, PUT "/parameters", etc..
Is there a way to do this in AML or is this not the right tool for what I am trying to accomplish? Is there a better solution within Azure that is more suited for my needs?
Thank you!
Azure ML allows controlled rollout/traffic splitting, but doesn't directly support your API design.
I might need to know more about your use case to make a recommendation. Are you looking at implementing incremental learning? What is the motivation for separate endpoints?
-Andon
Your proposal seems like a stateful web server which is more than a REST API service. For example, you need to keep a piece of logic to maintain "ids" of data: if there are two POST /data calls with different data, and the DELETE /data need to operate on the proper one. This is much more than a single performance optimized machine learning service.
I would recommend you creating a separate server with all these logic pieces and only reach Azure Machine Learning service whenever you need it. You could also build a cache in your service to only call Azure ML service when a new data coming in or the local cache expired. It will save you additional money from Azure :-)
i have question regarding Azure API Management again : ).
i am using API management which is API Gateway doing HTTPS to Azure Storage REST API directly
and is there any way that i cant get email notification when there are massive requests or high latency at response ??
Thanx for reading : )
You can configure alert notifications either in the portal or via the REST API or .NET SDK to monitor for specific Azure Storage Metrics that you want.
See https://azure.microsoft.com/en-us/documentation/articles/insights-receive-alert-notifications/ for more details.
For massive requests, you might want to consider using "TotalRequests" or "TotalBillableRequests" in a specific time period.
For high response latency, you can track "AverageE2ELatency" or "AverageServerLatency" in a specific time period.
See https://azure.microsoft.com/en-us/documentation/articles/storage-monitoring-diagnosing-troubleshooting/#monitoring-performance for more details on these specific metrics and how they relate to performance monitoring.
Hope this helps.
Sriprasad's answer makes sense for configuration from the Storage side. From the API Management side, you cannot currently set a notification on any event other than the built-in ones (subscription requests, new subscriptions, application gallery requests, new issues/comments, approaching of user subscription quota limit).
You can use Log-To-Eventhub policy to log a message to event hub for every request and consume it in a custom or third party solution like AppInsights/Runscopee to fire an alert.
Refer
https://azure.microsoft.com/en-us/documentation/articles/api-management-log-to-eventhub-sample/
If your requirement is to get report/metrics from API Management you can use the management rest api's for APIM.
https://msdn.microsoft.com/en-us/library/dn781421.aspx
Specifically you might want to look at reportByAPI (which gives you useful metrics in response like callcounts, apiTimeAvg) based on which you can setup alerts/email notification.
https://msdn.microsoft.com/en-us/library/dn781421.aspx#ReportByAPI