AZ-204 Microsoft Azure Developer Associate – Connect to and consume Azure and third-party services part 3

10. AZ-203/ 204 – API Management Instance – Introduction

Hi and welcome back. Now in this chapter, let’s have an introduction on to the API management instance. But before that, let’s have a quick review of application programming interface. Now, let’s say that you have an internal application or an internal system wherein you have data that’s maybe stored in a database or in a data store. So let’s say you have data for the orders of an ecommerce application. Let’s say you have the customer data for your ecommerce application. Now, let’s say that you have users which could be internal, or it could be external, or maybe you have an application. Again, it could be an internal application to your network or an external application that needs to have access to the data. Now, in today’s world, having direct access to the data is not recommended. Instead, you could have an interface in between.

That interface would fetch the data and then your users or your application could make calls to the interface to fetch that data. So this is known as an application programming interface. So just an example over here. So you could have one interface for your orders data, you could have another interface for your customers data. And again, you could have applications or users who are accessing this interface. So you give this interface or this API to your users. Until then, you can actually access these resources via these API calls. Even when working with Azure, we have seen so many times when we could actually make API calls using, remember the Postman tool on to Resources or Services in Azure? So again, these are all API calls, application programming interface calls.

So all of these interfaces are available. Remember, on the Azure side when you’re making EPA calls onto Azure and each epay call serves a purpose, it basically calls a service or does something with that service. So again, just the basics when it comes to API calls. And then one of the other advantage of having APIs in place is that you can issue normal requests via the web using normal protocols. So if you want to get some information, you could use the Get method. You could use the URL of the company. Let’s say you want to get the order information where the order ID is equal to ten. You can actually just submit this URL and get the information. So now we come to the concept of the API management interface. So this just provides a way in which your users can actually access your APIs via a single management instance.

So instead of your users and applications making a direct call to the interface, you have kind of a control layer in front of those APIs. Now, some of the advantages of having a control layer are so in the API management instance, you have something known, has a cachet. So responses frequently access responses can actually be sent to the user’s annual application directly without calling the API, without fetching the data. So this makes the retrieval faster. Another thing is security. So this is a highly secure infrastructure. Now, when it comes to API calls, it’s very, very important to secure your infrastructure. You could have malicious users making calls on to your data, and you don’t want that. You want to have a secure way of making the calls.

Some other aspects which are available. Yours are something known as a call rate limit. Basically to limit the number of calls to the API. So let’s say you have an attack from the Internet onto your APIs. So they’re trying to flood your APIs with network traffic. So in such a case, if you have a call limit rate, it will limit the amount of load on the APIs. So it’s a good way not to bring your entire system down. So there are some advantages of having a management interface in between. Right? So this is an introduction on the application programming interface management instance. Let’s go on to the labs to see how we can implement this.

11. AZ-203/ 204 – Lab – API Management

Hi and welcome back. Now in this chapter, let’s have an introduction on to the API management instance. But before that, let’s have a quick review of application programming interface. Now, let’s say that you have an internal application or an internal system wherein you have data that’s maybe stored in a database or in a data store. So let’s say you have data for the orders of an ecommerce application. Let’s say you have the customer data for your ecommerce application. Now, let’s say that you have users which could be internal, or it could be external, or maybe you have an application. Again, it could be an internal application to your network or an external application that needs to have access to the data. Now, in today’s world, having direct access to the data is not recommended. Instead, you could have an interface in between.

That interface would fetch the data and then your users or your application could make calls to the interface to fetch that data. So this is known as an application programming interface. So just an example over here. So you could have one interface for your orders data, you could have another interface for your customers data. And again, you could have applications or users who are accessing this interface. So you give this interface or this API to your users. Until then, you can actually access these resources via these API calls. Even when working with Azure, we have seen so many times when we could actually make API calls using, remember the Postman tool on to Resources or Services in Azure? So again, these are all API calls, application programming interface calls.

So all of these interfaces are available. Remember, on the Azure side when you’re making EPA calls onto Azure and each epay call serves a purpose, it basically calls a service or does something with that service. So again, just the basics when it comes to API calls. And then one of the other advantage of having APIs in place is that you can issue normal requests via the web using normal protocols. So if you want to get some information, you could use the Get method.You could use the URL of the company. Let’s say you want to get the order information where the order ID is equal to ten. You can actually just submit this URL and get the information. So now we come to the concept of the API management interface. So this just provides a way in which your users can actually access your APIs via a single management instance.

So instead of your users and applications making a direct call to the interface, you have kind of a control layer in front of those APIs. Now, some of the advantages of having a control layer are so in the API management instance, you have something known, has a cachet. So responses frequently access responses can actually be sent to the user’s annual application directly without calling the API, without fetching the data. So this makes the retrieval faster. Another thing is security. So this is a highly secure infrastructure. Now, when it comes to API calls, it’s very, very important to secure your infrastructure. You could have malicious users making calls on to your data, and you don’t want that.

You want to have a secure way of making the calls. Some other aspects which are available. Yours are something known as a call rate limit. Basically to limit the number of calls to the API. So let’s say you have an attack from the Internet onto your APIs. So they’re trying to flood your APIs with network traffic. So in such a case, if you have a call limit rate, it will limit the amount of load on the APIs. So it’s a good way not to bring your entire system down. So there are some advantages of having a management interface in between. Right? So this is an introduction on the application programming interface management instance. Let’s go on to the labs to see how we can implement this.

12. AZ-203/ 204 – Lab – API Management Policies

Hi and welcome back. Now in this lab let’s look at API management policies. So these are policies that allow you to change the behavior of the API via a configuration. Now let’s say for example, you want to ensure that when a request is made to an API it needs to include a particular STP header and a value. So this can be done via the help of a policy. Now, there are different types of policies that are available as part of API management. These policies are then divided into these policies can be added onto three sections. One is the inbound, the back end and the outbound. So if you want policies that need to be applied to the request being made to the API, you would add the policy to the inbound part. If you want policies to be applied before the request is forwarded on to the back end service, then you place it as part of the back end section.

And if you want a policy to be applied when a response is sent back from the API management instance, they can place it as part of the outbound section. Now, some important policy definitions so you have access definition policies. So an example is checking the STP header and value. This can be applied to both the inbound and the outbound section. You also have to known as a limit the call rate. Since sometimes APIs are kept open to the public, you might get or you might want to limit the number of calls being made. Sometimes you might have an attack on the APIs for malicious users who try to flood the APIs with numerous amount of calls. In such a case and in such a point, having a limit on the call rate is very important. So this can be applied onto the inbound section for your policy. You can have advanced policies. Here. An example is set variable.

So this helps you set a context variable. You can actually take a header value from the STP request and then assign it to a variable using this policy. You can apply this to the inbound, the outbound, the back end or the on error section. You don’t have setting the status code. This can be used to explicitly set the status code. This can be applied to the inbound and the on error section. Then you have authentication policies so you have Authenticate with Basic. This ensures that the authentication with the back end service is done via basic authentication. You then have Authenticate with a client certificate. Here the authentication is carried out with the back end service via client certificates. And then you have authentication with a managed identity. Here in the authentication is carried out with the back end service via a managed identity. All of these can be added to the inbound section.

You then have caching policies. So caching can be used to improve the performance of your responses. The API can return data from the cache instead of getting it back from the back end service. The API can return data from the cachet instead of getting it from the back end service. So an example is adding an outbound element has shown over here to enable the caching. We can also specify the duration. The response will stay in the cache. We can also look up a value from the cache which can be applied to the inbound, outbound, back in, or on error sections. Now let’s go on to our lab. Let’s see an example of a very simple policy that can be applied to our existing API. Here we are back in our API Management service. Now, if you go on to our sample API, we actually have a part over here wherein we can actually add policies to the inbound processing, the back end processing, and the outbound processing.

So these are the different sections. You can actually either add a policy by using this wizard over here, or if you discard this, you can actually click on this icon to open the Policy Code editor. So let me go ahead and add a simple policy. So what I’m doing over here is that to the inbound policy, I am adding an IP filter action which is going to forbid this IP address. So basically, this is the IP address of my workstation. Before I actually apply the policy, let me confirm that I can send a request and I’m getting the response. So that’s working. Now let me go ahead and save this policy. So I just made a mistake by not adding the closing tag for the IP filter. I’ve done that. Let me click on save. So now we have the policy in place. If I go ahead and click on Send again, you can now see I’m getting a forbidden error message. So this is how you can actually apply policies in the API management instance.

13. AZ-203/ 204 – Lab – Azure Event Grid

Hi and welcome back. Now in this lab, let’s look at the Azio Event Grid. So this is a service that allows you to respond to events that are emitted from Azure based resources or from custom events. When you want to use the Azure Event Grid, you normally first have to subscribe to an Azure Resource, and then you would specify the event handler that would receive the event. Now over here, I have a reference from the Microsoft documentation that gives you a really good picture on what you can do with the Event Grid service. So services in Azure, such as the Azure Blob Storage Resource Groups, or even Event Hubs, when any action is taken on any of the services, they basically emit an event. So for example, if you’re looking at Azure Blob Storage, when you place an object onto the Azure Blob Storage service, it can emit an event.

That event would have the details of the object that has been added onto the Blob service. That event would be sent onto the Event Grid service. Or maybe you want to look at the events from a resource group level. So let’s say that you want to be notified of any event that occurs on the resource group level. So let’s say someone creates a resource in that resource group. You want to be notified via an event. So that resource group will emit an event. Again, that event will go on to the Event Grid service. And then on the right hand side, you can have your event handlers. So you could take your event handlers, attach it to the Event Grid service so that your handler can receive those events. So your handlers can be Azure functions.

So Azure functions can actually take on the events from the Event Grid service. Please remember that you have to ensure that you subscribe to the event source. So apart from that, you could use logic apps, other consumers, or even other services and applications. So what we’re going to see in our first demo? Well, first we’re going to ensure that we register the provider for Azure Event Grid in our particular region. Then we will use an Azure Logogic App service to see how we can work with the Event Grid service. We will then add a specific condition to model the events for virtual machines to a resource group, and then we’ll add a condition to send an email if an event is fired.

So let’s go ahead with a lab and let’s see how we can use the Azure Event Grid service. Now, before we can start using the Event Grid service, we have to ensure that has been registered in our particular region so we can actually go on to our subscription, make sure we go on to the resource providers. Let’s search for Event Grid in Microsoft. Event Grid? Make sure that it is registered. If it is not, go ahead and click on the button. So there will be a register button over here. So please do this before you actually start working with the Azure Event Grid service. So here I am in logic apps. Now let me go ahead and add a blank logic app. Let me search for event grid. So let me choose the trigger. When a resource event occurs, I’ll sign in to my default directory so it will ask me to sign in with my user account.

So now it’s asking me to choose the account. So I’ll choose my normal root account. Once you’re logged in, we now have to choose what is the subscription, what is the resource type, what is the resource name to which we want to listen for events. So I’ll choose my subscription. So I’ll choose the resource type. At the moment has resource groups. I’ll listen for events in my ASIO Demo resource group. Now these are the different events that you can actually listen to. So I’ll listen to any resource action success, any delete success and any write success. So this step is basically going to return all the events which are emitted from the resource group known as Azure Demo.

So if you add any resource to this resource group, you will actually get an event which will come to this logic app service. So these are all the events we are going to listen to. Now we want to look for events which are pertinent to the Azure virtual machines which will be part of this resource group. So for that we are going to go ahead and add a condition. So let me go ahead and click on Save first and then we add a new step so we can search for condition. We can actually go on to control, choose the condition control. And now we have a condition in place and in the condition we have a path for if it’s true and a path for if it’s false. Now I’m going to go ahead and enter a value.

So for the value I’m going to choose expression and add this expression. So we’re going to be looking at the trigger body. So whatever is the body of the event which has been emitted and sent on to Azure Logic app service, we are going to look at the data part and the operation name. I’ll click on okay, I’ll say is it equal to and I’m going to enter the value of Microsoft Compute virtualmachines Write. So if there are any write changes onto virtual machines in this resource group, only then this condition will be met. Let me go ahead and again click on Save. Now if you switch between the code view and back onto the designer view, if you go on to the condition, you can now see it’s changed to data operation, right? So we have a condition in place, let’s go ahead and add an action.

So let me send an email, let me sign in. Once I’m signing, I’ll enter the details, I’ll again add the parameters of the subject and the body. So in the subject I could choose what is the subject of the event. So in the body, you can actually add these dynamic content. Now, depending upon the type of event, these will actually come in the body of the email. Now let me go ahead and click on Save, right? So the logic app is completed. So we have remember our resource event. So this will listen to all the events in the resource group. We have three conditions. The three events which are listening to, we then have our condition to only check for rights to virtual machines.

If the condition is true, then we’ll send an email. So let’s go ahead onto our app. So this is our logic app. Now over here, I have a virtual machine in place. Let’s go ahead and resize the virtual machine. So this should trigger an event which is a right onto the virtual machine. After some time you will actually get an email which has the details of the event itself. Again, these are just raw details about the event. Now, when you go back to your logic app, let’s say you want to debug what’s wrong with the logic app. There are two ways. The first is to go ahead and look at the run history. So if you can’t see the runs, just click on refresh. You will see all the runs which have been loaded over here.

Now, if you go on to any run, so in the designer itself, so you can see what is the expression result. If I go on to another result, you can see the expression is true. If you go on to the run details, you can see all the run details over here. If you go on to the output link, you will see what is the JSON part of the output itself when the logic app instance was fired. Now, apart from the run history, you can also go on to the trigger history and see when all the triggers have been fired. So when it’s been fired, again, you have the inputs link and the outputs link as well. So these are two ways that you can actually debug what’s happening in Azure logic apps, right? So this marks the end of this lab.