The Ultimate Azure API Management Course

hello and welcome to my course the ultimate azure api management course my name is hussein awad i am a cloud application architect and i have more than 20 years of experience in the field i am a two gaff enterprise architect have thin aws certifications and many microsoft certifications as well and through my career i have worked for top technology companies big4 consulting firms and many multinational organizations around the world so in this course we are going to cover everything you need to know in azure api management starting from creating the api management to hosting your first api in the api management then we will get to discuss the policies and we will see how you can use different kind of policies to empower your apis in an api management then we will be talking about the subscription keys and we will see how we can use those keys to secure the access to your apis in an api management and also how we can use different products to organize our apis to different consumers based on our needs then talking about the developer portal we are going to see how we can publish our apis to the developer portal and allow other users to interact with the developer portal to test our apis and receive a genuine responses then we will come into the monitoring and we will see how we can use different monitoring tools to empower us with the information to enhance the performance of our api management we are going to see how application insights can help us to understand or diagnose their performance bottlenecks in our api management and what are the key metrics we need to understand and how we create alerts to nitify us if something went wrong in our api management then talking about the infrastructure we are going to see what are the different pricing tiers for the azure api management and how we can deploy multiple instances for our azure api management then we will talk about the different virtual network configurations that works for api management and in here we are going to see how we can use application gateway that works in conjunction with api management to have both internal and external apis hosted in the same api management which is going to be the most cost efficient deployment for your api management then you are going to see how we can store the configuration of our api management in the code repository and then we are going to extract an arm template so we are going to use it to create a ci cd pipeline in azure devops then we are going to cover the managed identities and how we can use azure active directory for authentication between the azure api management and the backend azure functions as i said before we are aiming to cover everything in azure api management during this course now that's enough talking about api management now let's get started and let's create our first api management now let's see how we will create our first api management service and here i am in the home page of my azure portal and i can go to the api management service by either clicking on this link here or i can search for api management in the search box here so let's go ahead and click on this before we go ahead and create our first api management service let's go ahead and create a resource group for our resources in this subscription let's add a new resource group and let's call it dev resource group and i'm going to host it in australia east region let's create this resource group and now the resource group is ready for me now let's go back to the api management service and let's create one now let's call it my company api management and using courses subscription dev resource group that we just created and let's host it let's host it in australia's region and the organization name is going to be my company and this is the administrator email address that's going to receive notifications about the api management service now let's have a look at the pricing tiers api management service provides many tiers and as you go to the higher tier you are going to pay more for this course we are going to stick with the developer tier and it going to cost you 66 australian dollars per month let's go ahead and enable application in sites and as you can see i don't have any application inside instance in this subscription so let's go ahead and create one application insights let's go ahead and add an application insights instance and let's select dev resource group let's call it my company application insights and let's host it in australia east region as well and let's select the resource mode to be workspace based and we need to select a log analytics workspace and as you can see here i don't have a log analytics workspace so let's go ahead and create one now let's create a log analytics workspace dev resource group for our resource group and let's call it my company log analytics and it's hosted in australia east let's go ahead and create the log analytics workspace now the log analytics workspace has been created so let's go back to the application insights and probably we need to refresh this page again let's select the resource group and call it my company application insights again in australia east region workspace based and select my company log analytics and let's go ahead and create this application in sites instance the application insights is ready now for me so let's go back to the application api management service and let's refresh this page now let's go ahead and add my company api management for the name and then adding dev resource group australia east region my company for the organization name and again developer tier that has no sla and now let's select my company application insights instance and let's go ahead and create our api management service so it's going to take around 30 to 40 minutes for the api management service to be ready so to wrap up we have created now an api management service and an application insight instance and log analytics workspace and those are going to be the fundamentals for this course that's it for this lecture i hope you enjoyed it and please feel free to join me in the next lecture now let's go ahead and create our first api and let's head to the api management that we have created then let's browse to apis and as you can see here we have an echo api has been created for me and it has a bunch of different http operations get post delete etc let's go ahead and create our own api and let's say you are trying to create an api gateway or api management for linkedin where we want to allow our users to go ahead and create profile or update or delete and also want to allow them to save a job or apply for a certain job so let's go ahead and do this when i create a new api i can choose from all of those azure components to be the backend service for my api and for this course we are going to stick with the azure function app as you can see here i need to choose a function app to link it to my api and i don't have any yet so let's go ahead and create a new function app now let's go ahead and create our azure function app and let's assign it to dev resource group and let's put linkedin profile at the name of our function app let's publish it as a code using dot net core runtime stack version 3.1 and let's host it in australia east now let's go to the next page hosting it's going to create a new storage account for me because i don't have any storage account in my subscription yet and let's select the windows operating system and consumption plan now let's go to the next page monitoring now i get to choose either to create a new application inside instance for this function app or i could choose the previous application inside instance that i've created while i was provisioning the api management and let's do this let's go to the next page tags i'm not going to specify any tags then let's go ahead and create our function app now let's go to our function app and create our first function let's go to functions and add a new function and let's select http trigger and then let's put profile in the function name and let's make the authorization level anonymous however you should never do this in production now let's create our function now the function has been created for me and let's get inside now let's go to the code and test and to keep it simple let's get rid of all of this code and just return a message that says your linkedin profile has been created now let's save our changes and let's test it great 200 response code my function is working well now let's head back to my api management now let's go ahead and select the function app from here we will select linkedin profile function app and then we are going to select profile function and let's keep everything as a default let's go ahead and create this api now the linkedin profile api has been created with two operations get and post if we look at the get operation we will see that it's linked to the azure function app that we've just created linkedin profile now let's go ahead and see how we are going to test this function or this api we have tested the function app already before and we make sure it's working perfectly now we want to test it through the api gateway or api management and in order to do so let's go to the test tab and then let's send a request as you can see we have got 200 response code that says our api is working well as expected now i'm going to show you another way to test your api so let's go to the developer portal and let's go ahead and publish your developer portal then let's head to developer portal legacy then let's browse to apis link it in profile then let's go to get profile operation then let's go ahead and try this api and send a request and as you can see here we have got 401 access denied error and the error message says that the request is missing the subscription key it's interesting that we didn't get the same error message when we tested this api from the api management so let's go back to the api management to try to understand why this happened so let's go to apis go to linkedin profile api get profile and then let's go to the test tab and as you can see here in the http request that's been sent from the api management it's already including a subscription key this is why when we send the request it passes successfully and returned the 200 response code so from where this subscription key come from so let's go to the subscriptions to understand this more and as you can see here there are different subscription keys already created in the api management and one of them is assigned for all built-in access subscriptions and if we show this key you will see that this is the exact key that's been sent from the test tab in the api management that's why when we test and send the request from the api management it returns a 200 response code now let's go back to the apis lick it in profile get profile again test tab and as you can see here this is the subscription key that's been used in all built-in api management operations however when we send the request from the developer portal it doesn't include the subscription key this is why we have received 401 access denied error and to fix this we can add a header that includes the subscription key and adding the header name as well and then let's try to send the request one more time and here we go we have got 200 response code now i'm going to show you a different way to get it work without specifying a subscription key so let's remove the subscription key we just added and let's send another request again we are getting 401 access denied error now let's head back to the api management and let's go to the settings of our linkedin profile api scrolling down you will see a checkbox next to subscription required and this is why the api requires a subscription key to be passed on in the http request in order to work well so i'm going to go ahead and remove this checkbox and let's save our changes so let's go and test it in the test tab and select git operation and send a request again it returns a 200 response code now let's go to the developer portal and send a request as well and as you can see it sends 200 response code even though we haven't specified the subscription key that's because we have disabled the subscription key to be passed in the http request for this api however you should never do this in production now let's go ahead and check the subscription required the checkbox back again and let's save our changes now i want you to notice that we have two http operations for this api we have get and post now let's go back to our azure function to understand why this happen and if we look at the tested app in here we can see that we have two http methods we can use to test our azure function app we could use get or post http verbs and what we want to do is to restrict this function app to be able to take only one http verb given that we are going to use this function to create a new linkedin profile for example then we need to restrict this function to accept only a put http verb so to do so let's go to the integration here and let's click on http request and select put verb instead of get and post now let's go ahead and save our changes now going back to the code and test section and let's go to the test our function we can see here that we have only put verb is available for us to use and if we run it it will return 200 response code now what we need to do is to change our function name instead of profile to make it like create profile or something but unfortunately there is no feature to rename a function app from the azure portal and to be able to do so we need to go to the console and what we need to type in here is rin for rename and then type in the current function name and then type in the new function name that we want to have let's call it createprofile now let's go ahead and refresh this page and let's go back to our functions you will see here that our function name has been changed to get profile now let's go back to our api management and see how we are going to reflect these changes and as you can see here we still got two http verbs get and post so let's go ahead and test one of them and as you can see here we have got 404 error this is because our function app is not supporting these two http verbs anymore it supports only put verb now let's go ahead and update this api by importing a new function app and let's select our function app link it in profile and then let's select create profile function then let's import this function app and as you can see here we have got a put operation has been created with the create profile and if we go ahead and test it it's going to return 200 response code and if we test post or get one more time we are going to get 404 because these verbs are not supported anymore in the function app so we can go ahead and delete these two operations from our api that's it for this lecture i hope you enjoyed it and please feel free to join me in the next lecture now let's go ahead and create a new product let's go to products and then add a new product let's call it basic and put basic products in the description and i'm going to leave the state to be not published and i'm going to deselect requires subscription and here i can go ahead and select which apis i would like to have in this product and i'm going to select linkedin profile and let's go ahead and create this product now let's go to the developer portal and let's click on developer portal legacy let's go to products as you can see here i can see the basic products even though i haven't published the product yet and the reason for this because i'm logged in as an administrator and being an administrator will allow me to see all the published and unpublished products in my api management and to prove this let's sign out from the administrator account and let's go back again to products and as you can see i'm not able to see the basic product anymore now let's go to the basic product and go to settings and then publish our product so we assume that we will be able to see it as a guest user right now let's go back to the developer portal and refresh this page and still i'm not able to see the basic products and the reason for this because of the access controlled as you can see here only administrators group is allowed to have an access to the basic products and what we need to do is to add another group which is the guest group now let's go back to the developer portal and see how it look like and again it will not work as you can see here we're still missing the basic product so let's go back to our product and let's go to settings and this time let's go ahead and check on the checkbox requires subscription and let's go ahead and save our changes and then go back to the developer portal and let's refresh this page and as you can see here we are able to see the basic products as a guest user in the developer portal now let's get into the basic products and let's go to linkedin profile and let's try this api one more time as you can see here there is a 401 axis denied error and the reason for this because we have specified that this product will require subscription and being a guest user we haven't subscribed to this product yet so to fix this let's go ahead and open the developer portal one more time but as an administrator and let's go back to products let's go to basic products linkedin profile and let's try this api and as you can see here a subscription key has been already provided and let's go ahead and send the request and we got 200 response code do you remember last time when we tested this api we needed to provide the subscription key ourselves but now it's already provided for us and the reason for this because we set this api in a product and this is one of the benefits to make your apis or organize your apis and products the developer portal will implicitly include the subscription key that's been created for this product so let's go back to the api management and go to apis in our product and let's remove this api from the basic products let's go back to the developer portal and refresh this page now as you can see the subscription key is no longer available in the developer portal for this api and if i send the request i'm going to get 401 access denied error now let's go ahead and add this api again get back to the developer portal and here is a subscription key being provided and i can send requests successfully now let's look at the subscription keys and why they have been provided to the api so when i created the basic products a new subscription key has been created for the basic product and it's been assigned to the administrator because i am the administrator of the api management and i can do whatever i like to these keys i can see or hide the content of this keys as you can notice here this is the key it's been used in the developer portal ending by 144 and this is a subscription key being used when i tested this api in the developer portal now i also can suspend a certain subscription or cancel it or delete and i have an option to regenerate primary or secondary keys in case of the keys got compromised or something now let's have a look how this is going to look like for another user as an administrator to the api management i have the complete privilege to do whatever i like to the api management and have access to do everything but what about other users so let's go ahead and create a new user let's call it user1 now now this user has been added to our list of users for the developer portal now let's go to the developer portal and sign out as an administrator and log back in as a user one and let's go to products and as you can see here i cannot see the basic product anymore so let's go back to the api management and try to figure it out the reason for this because user one has been assigned in the developers group and the basic products has been assigned access control for only two groups administrators and guests and being a user in the developers group will not allow me to see this product to fix this let's add developers group to this product as well now going back to the developer portal we are going to see this product in here so let's get inside and let's go to linkedin profile and let's try this api and as you can see here we have got 401 axis denied error and the reason for this because we don't have a subscription key created for this user and to fix this let's go back to products basic and let's go ahead and click on subscribe button in here and what this does it's going to create a new subscription key for user one and assign it for the product basic product as you can see here user one now has its own subscription key to use basic products now if we go to the developer portal we will be able to see the subscription key for this api now let's go to this api and test it one more time link it in profile try it and now we are able to see that the subscription key has been provided in the developer portal and now we can send a request and get 200 response code now let's go back to the api management and change the settings of the basic product to requires approval and let's go ahead and save those changes then let's go to our subscription keys and let's go ahead and cancel the subscription for user one now let's go to the developer portal and refresh this page and as you can see here user one is no longer subscribed to the basic products because we just cancelled his subscription so let's go back to products basic products and then let's subscribe one more time and as you can see here the subscription request has been submitted and if we go back to the api management or go back to the subscription keys we will be able to see the new subscription request has been submitted by user 1 and also you can filter it out by seeing pending approval requests and in here you can do whatever you like whether to activate the subscription or suspend or reject or cancel or delete the subscription so let's go ahead and activate this subscription going back to the developer portal here the subscription key has been provided again for user one and we will be able to test our linkedin profile api as normal now let's go back to products page let's go to basic product again and as you can see here we can add multiple subscriptions uh to the same product and as you can see here the subscription has been requested and let's go to our api management and approve it and there is no limit for us to add as many subscription keys for the same products as much as we like and this is not a good approach to have multiple subscriptions for the same user and to fix this let's go back to our api management and let's put subscription count limit to one and let's deselect requires approval to make it easier for us and let's go ahead and save our changes now let's go ahead and cancel both of these subscriptions for the user one now let's go back to products page and select a basic product and let's subscribe to this product and this subscription is active already now let's go one more time to products page and try to add a new subscription as you can see here we don't have this option anymore because we have already subscribed to this product and as soon as we cancel this subscription we will be able to add a new subscription to this user this is a good way to not flooding our api management with many subscriptions for the same user now let's have a look at apis and here you can add more apis to your product or remove apis from your products and also let's have a look at policies and it's one of the interesting features in the products in api management and to understand it well let's have a look at these two products that's been provided in the api management we have a starter product and it has echo api in it and also we have unlimited products and it's also assigned to echo api so we have two products assigned to the same api now let's have a look at the policies for the starter products and as you can see here there is a limit to call this api or this product five times each minute so if someone is subscribed to the starter products they will be able to call echo apis five times each minutes however when they are subscribed to the unlimited products they will be able to call the same api which is echo api unlimited times this is how you can use products to provide the different usage limits for your apis in the api management now let's go to access control and this is where you specify which groups has access to a certain product in your api management and here are the different subscription keys that are subscribed to a certain products now let's look at the subscription keys and we can add a new subscription from here so let's put a name here trial subscription and let's allow tracing and for the scope of the subscription we can have it for the all apis in our api management which is pretty scary or you can assign it for a certain product which is pretty much what we have done or you can become very specific and assign this subscription to a particular api and in this case you need to specify which api you want to create this subscription for and also you need to select which user is going to be assigned to this subscription so let's go ahead and create this subscription as you can see here we have created the subscription for the echo api for user one now let's go ahead and clean up all of those cancelled subscriptions for user one and also let's say delete the echo api access and then let's go back to the developer portal and now as you can see here user one is assigned to the basic products in this lecture we have covered everything you need to know about products and subscriptions in the api management that's it for this lecture i hope you enjoyed it and please feel free to join me in the next lecture now let's see how can we create an api mock response let's say that we want to create a git profile operation in the linkedin profile api and this operation doesn't have a backend function yet and we want to allow the consumers of get profile operation to start to do their code changes and interact with git profile operation as soon as possible and without much dependency on the progress of the backend function of the get profile operation this is where the mock responses becomes really helpful and it's one of the powerful features about the api management so let's go ahead and see how can we do this let's add a new operation let's call it get profile and the url which is not ready yet let's call it get profile 2 and let's save this operation now let's go ahead and test it and as you can see here we have got 500 internal server error because there is no backend function linked to this operation yet and what we are going to do now is to go ahead and create a response let's call it 200 okay and then let's add a content type to be application json for example and then let's add a sample here to be linkedin profile and then username to be user1 and then email to be user1 at outlook.com for example and let's go ahead and save this now let's go back and test get profile operation one more time and again we're still getting 500 internal server error and what we need to do here is to add mock response and add a policy so let's add a new policy and add mock response and for this one we are going to stick with the 200 application json response and let's save this mock response and you can view it from here as well and now let's go and test get profile operation as you can see we get 200 response code with the same json structure that we've specified in the mock response now let's test create profile operation again we are getting 200 response code which is great but we don't get the line that says your profile has been created successfully right so let's go back and see why this happened when it comes to policies there are four scopes we can define our policies in the api management we can have a global policy where we create a policy that's going to affect all apis in our api management or we can have a product policy where we can create a policy that's going to affect all apis in a certain product pretty much like this policy that's been applied for the starter product if you remember also we can have an api scope this is where are going to have a policy that's going to be applied to all operations in a particular api and this is what we have done which is not right and also we can have an operation level or operation scope where we are going to create a policy that's going to affect only a particular operation in a certain api and what we have done wrong in here we applied the mock response on the linkedin profile api and it's going to apply to all operations in this api that's why it affects the response of the create profile operation so let's go ahead and fix this firstly let's go ahead and delete this mock response from the api scope and let's save this change and let's go and test create profile function to just to prove my point and as you can see here we have got our text back your profile has been created right now let's go to get profile operation and now let's add the mock response to be specific to this operation and i want you to note the scope of this policy and it's again it's all operations in this api which is not right you need to make sure that you select the specific operation you want to apply that policy for so let's select get profile operation and let's add a policy let's mock response making sure it's applied to a specific operation and then let's go ahead and save this now let's go and test get profile function again getting 200 response code with that json structure and let's go and test create profile operation and again we are getting 200 response codes and the text that says your profile has been created now let's see how can we enable throttling on our api and throttling is a protection mechanism where you get to specify how many calls your api or operation or product can handle during a certain period of time so let's go ahead and see how can we do this so we are going to add the throttling for all operations for linkedin profile api so let's go ahead and add policy and let's select limit call rate and let's specify it for one call every 60 seconds and counter key to be api subscription and let's go ahead and save this and this is going to affect all operations in this api so let's go ahead and test this now testing create profile operation as you can see the first call pass through we have got 200 response code and everything is fine however the second request is going to fail with four to nine too many requests status code and the reason for this because we've specified our throttling to only limit and allow one api call per minute and this applies for all operations in this api so if we go ahead and try to make a request for get profile operation we are going to receive the same throttling limit because we have specified only one call for all operations in this api per minute throttling is very very important mechanism to secure and protect your apis and operations from getting too many requests from a particular user and you should never ignore this now let's go back and remove the throttling limit and let's save our changes that's it for this lecture i hope you enjoyed it and please feel free to join me in the next lecture now let's talk about revisions and it's one of the interesting features in the api management revisions allow you to update your api definition and settings and put it in a separate revision separate from the current working revision of the api because you might have a situation where there are some developers already consuming the current revision of your api and you want to do some changes to those api definition and to avoid making any disturbance to those developers the best is to put your changes in a separate revision until you test it and make sure it works as expected and then you shift the traffic or move the traffic to the new revision now let's go ahead and see how can we do this let's go to revisions and let's add a new revision let's put update mock response in the description let's create a new revision now we have two revisions for our linkedin profile api the current one is linkedin profile and the new one in the comp with revision2 however this one is online but not current like other developers cannot use this revision yet now let's go back to settings to design and let's change the mock response for get profile operation let's go to responses 200 okay and let's expand this mock response to include full name and let's call it user one now let's go ahead and save our changes now you may notice here that we have two revisions for this api revision one which is the current one and then revision two this is where we have done our recent change and added the full name to the mock response now let's go ahead and test it as you can see here we are testing revision 2 of our api and you can see the full name has been added to the mock response however if we switch back to revision one and then select the get profile api and test it one more time you will see that we are still getting the old mock response that we have specified earlier so this is how revisions becomes really helpful to allow you to do changes to your api definitions and settings without breaking the current working versions that other developers might be using when you are done your changes and you are happy with the result you can go ahead and make this revision a current revision but before doing so let's go to the developer portal and let's open it let's go to apis link it in profile get profile and let's try this operation as you can see here we're still getting the old mock response which include only the username and email address the new revision is not available yet in the developer portal it's only available to test within the api management itself if i'm going to select revision 2 and select get profile operation and test it you will be able to see that the full name is included in here and as soon as we make the new revision the current revision we will be able to see the new update in the developer portal so here i'm going to put some description update mock response let's go ahead and save this if you go to change log here you will be able to see the current change that we have just done and changing the revision2 to be the current revision now let's go to the developer portal and send the request one more time as you can see here now we are receiving the new revision response which includes the full name in the response this is how revisions becomes really helpful for you to organize and make your changes without breaking the current working versions without breaking the current working revisions because as we are gonna see in the next lecture revisions are different than versions and we are going to cover this in more details in the next lecture and as you can see here we are still have two online revisions of this api and if we go back to test tab and select revision one get profile operation and let's copy request url let's test it in the browser definitely it's not going to work because i need to provide the subscription key in the header of the request and you can achieve so by using some tools like postman or something however we are not going to do this in here so in here we are getting 401 error that access denied because it's missing the subscription key and if we go back to the revisions and take revision1 offline and let's go and see how it look like now we are getting 404 error and resource is not found because you have taken that revision offline and that's something you need to consider for the old revisions of your api this is to avoid you having multiple online revisions for the same api at the same time because it might cause some confusion for other developers and as well if you go to the test tab in here and try to test revision one you will not be able to send any test request for revision one because it's not online anymore that's it for this lecture i hope you enjoyed it and please feel free to join me in the next lecture now let's talk about versions and the main difference between versions and revisions is that you can have multiple online revisions at the same time but you can only have one current revision for your api at a certain point of time however with versions you can have multiple versions up and running at the same time for your consumers to use and we are going to see this in a minute so let's go ahead and add an api and let's select function app and let's select our linkedin profile and create profile function let's call this api version and let's put the url as well version and let's go ahead and create this api now as you can see here we have got version api with get profile operation and let's go ahead and test it again we are getting 200 response code with your profile has been created text now let's go ahead and add version and let's put the name in here version version one and in versioning schema you can choose from path or header or query string however let's just stick with path and let's add version one in here and let's go ahead and create this version now we have two versions of this api the original version and version 1. now let's go to version 1 and do some changes select git profile and let's add 200 response for the application json content and the sample here we are going to put version one let's go ahead and save this and also let's go to the policies and add mock response policy for application json 200 okay now let's go and test version one of our api as you can see here we are getting the mock response that says version 1 for our api and if we go back to the original version of our api we're still getting the original text that says your profile has been created all of this is great now let's go to the developer portal and open the legacy one let's go to products basic and we cannot see our api anymore and the reason for this because we didn't put our version api in a product yet so let's go to apis and we will be able to see the version api and the two versions that we have original and v1 let's go ahead and try to test it and it will not work because we will need to provide the subscription key for this api so let's go back and put version api in a product and we can do this by going to products and select basic products select the apis and then add version we can either have both versions in the same product or we can have each version in separate products based on your structure and how you organized your apis in your api management so for now let's choose both versions now let's go back to the developer portal and let's go to apis open original and try create profile operation and it still provide the original text and let's test version 1 and it provides the mock response that we've specified before this is how versioning can be very important and useful for api management and big api providers always have multiple versions of their apis running at the same time and when they make a new deployment they always deploy their api and publish their apis as a new version and keeping the old versions as it is this is to make sure that other consumers and systems that might be using the old apis are still able to use the apis without any problems and also allow other developers and systems to start to migrate to their more recent version of the api at their own pace now let's go back to the api management and clean up those apis that's it for this lecture i hope you enjoyed it and please feel free to join me in the next lecture now let's talk about policies and we have touched on policies in the previous lectures when we talked about mock responses and throttling and policies simply are xml documents that has a sequence of inbound and outbound statements that's going to control your api and every time you talk about policies you need to mention what's the scope of the policy and if you remember we've talked before that there are four scopes in your api management where you can apply your policies either you can make your policy global by applying it to all apis in your api management or you can apply your policy at the product level and it's going to affect all apis hosted or assigned in this product like starter product that has a limit to 5 calls per minute or you can have your policy at the api level which is going to affect all operations in this api or you can have your policy at the operation level like what we have done in the mock response here and it's going to affect a certain operation only also it's important to mention that that inbound processing policies and outbound processing policies ending up to the same policy file so if you go to the outbound processing you are able to see the inbound policy that we've specified for the mock response which is exactly the same in here however when we go to a different scope we are not going to see these changes anymore because we are in a different scope and you can add policy by clicking on add policy button and these are the commonly used policies and you can have access to the whole list of policies by clicking on here and in this section we are going to cover most of these policies that's it for this lecture i hope you enjoyed it and please feel free to join me in the next lecture now let's talk about authentication policies and there are three ways we can use to authenticate in the api management either we can use basic authentication this is where we are going to provide the username and password for the backend service and this can only work when we have a custom https web service and we want to authenticate with it however basic authentication is not a good way to go let's go ahead and see how can we do this let's go ahead and add policy and click on authenticate with basic and let's say you are going to provide a username here and password let's go ahead and save our changes as you can see here we are getting error because we have put this policy in the wrong place so where we should put this policy if we get back to the document it's again assess inbound section and it can be applied at all scopes so let's go ahead and put this in the inbound section and then let's save our changes and same thing for authentication with client certificate let's go ahead and add it and then you need to supply your thumbprint and of course you need to place it in the inbound section both of these authentication methods will not work with azure function because azure function using function keys for authorization and managed identities for authentication and these two ways of authentication will only work with custom https web service so i'm going to remove these two lines and add an authentication with managed identity let's save our changes now let's see how we authenticate using managed identities so let's go to manage the identities and there are two ways either using system or user let's choose system assigned and let's turn it on and save our changes and same thing we need to do with the function apps so let's go to the function app and click on linkedin profile and select authentication and authorization and turn it on app service authentication and make the authentication using azure active directory let's configure it let's choose express configuration and create a new active directory app called linkedin profile and let's create it and let's save our changes let's go back to the api management and test it let's go to api's linkedin profile api create profile operation and let's send a test request as you can see you are getting unauthorized error and if we look at the trace and try to search for managed identity we will not find anything in the trace line here for authentication or let's look for authentication [Music] it doesn't use managed identity that we have specified and to fix this let's go to the policies of the create profile operation and let's add a policy and let's copy this managed identity policy and put it in the inbound policies for create profile operation we still need to replace this url with our function app url let's save our changes and let's test create profile operation one more time as you can see you are getting 200 response with our text and if we look at the trace and search for managed identity we will find that our managed identity took place for authentication between the api management and the function app so in this lecture we have seen how we can authenticate between the api management and the backend function using basic authentication or client certificate or managed identity that's it for this lecture i hope you enjoyed it and please feel free to join me in the next lecture now let's talk about access restriction policies so let's go to create profile operation and open policies and let's go ahead and add check http header and let's add a header name for example header and if this header is missing or has a wrong value it's going to return treble 4 response code with a message that says wrong header and this flag is for case sensitive for the value so let's put a p i with a capital a and let's go ahead and save our changes and it didn't work because we need to put this policy in the inbound section in here let's go ahead and save our changes and let's test create profile operation as you rc we are getting triple for unknown error because we haven't specified the header name so let's put the header name as it is and put api in the value and let's send another request we are getting 200 response codes now let's go ahead and change the value to be api all small letters and let's send the request one more time and still it gets to 100 response code because we have specified in our policy to ignore the case of the value and if we want to restrict this we can go to the check header and make ignore case as false so in this case if we have provided api with all small letters at the header value it's going to be rejected and return triple for response code as well now let's go ahead and test create profile operation and let's provide header with value api all small letters as you can see you are getting triple for unknown error because it has to be with capital a now let's go back to policies and clean this up go to create profile and we can delete a check header policy from here and let's save our changes and let's go ahead and add restrict caller ips and here you can allow certain ip address ranges to access your api or either you can block certain ip address ranges from accessing your api as well so let's go to the documentation and see what it says as you can see here either you can allow or forbid either one ip address or range of ip addresses to interact with your api and the purpose of this policy is to reduce the attack surface for your api and here is an example as well so let's go back to the api management and discard this change now let's go ahead and add another policy and let's look for sit codes by key and for this one we are not going to limit it by number of calls but by the bandwidth and i'm going to specify the bandwidth with 1k and is going to be renewed every 60 seconds and the counter key is assigned to the subscription and let's go ahead and save this as it says here the minimum number can be here at 300 seconds so let's go ahead and save this now let's go and test create profile api and as you can see the second run didn't pass through because it exceeds the code we have specified for the subscription key now let's go back to the create profile and remove this policy and save our changes then let's go ahead and add another policy limit code rates by key and then let's add two calls renewed every 60 seconds for api subscription key and let's save this changes and let's go ahead and carry and test create profile operation this is our first run this is our second one this is our third one it exceeds the throttling limit that we have specified per subscription key for this operation now let's go back and remove this limit now let's save our changes as well now let's go ahead and have a look at limit code rate by subscription and if you look at here you specify that limit number of calls and let's specify them by 2 and renewal period 60 seconds and let's remove this piece for now and now let's go ahead and put this limit in the inbound section let's save our changes now let's test create profile operation this is our first run second run this is the third run again getting the throttling error now what if we want to have a more specific limit to this policy so let's take this one off and let's add limit call per subscription what if we want to limited two calls and renewed every 60 seconds and the api name is linkedin profile and the number of calls allowed for this api is 2. and for the operations let's say for create profile it's going to be limited by only one call and for get profile operation limited by another call and let's go ahead and put this in the inbound section and as you can see i cannot save these changes because the scope is different here i am at the operation level and i'm trying to set some policy which is going to act at the api level so it will not get through and to fix this let's take this policy and put it in and save our changes and put this policy in the product for basic product which has get profile api and let's put it in the inbound policy and let's save our changes now let's go to the developer portal go to products basic linkedin profile create profile let's try this function yup this one works 200 response if we tried it one more time it will not work it will hit the limit that we've specified for this operation and if we go to get profile operation we will still able to hit it one time only before we get the four to nine throttling error this is the first one and in the second one we are getting too many requests now let's go back to our product policy and remove this policy and then let's save our changes so far we have seen what are the different ways we can use to restrict access to your apis and i'm going to put this link in the resources for this lecture that's it for this lecture i hope you enjoyed it and please feel free to join me in the next lecture now let's talk about caching policies and let's go to create profile api and let's add a policy let's choose cash response let's open the full one and let's put some number in here the number here in seconds and leave all the values to the default and let's save all changes now let's go to test create profile operation to see how the caching will work in this function let's go to trace and search for cache probably we need to send another request for the case to take place and then searching for cache as well and as you can see here the request has none cacheable http method because we are trying to cache a put operation which doesn't make sense and it will not happen so let's go back to create profile operation and remove the cache lookout policy now let's try to put cage to the git profile operation it has a good verb so it should work right so let's add the policy the cache response same as before putting some numbers in here and delete the values to the default now let's go and test the get profile operation and send the test request let's go to trace try to search for cache and as you can see probably we need to send another request search for cache one more time as you can see we don't have any record for the cache and if you scroll down you will see the last thing that we get is the mock response so probably because the mock response policy took place it override the cash policy so let's go ahead and move the cash lookout policy to be on top of mock response so it should be activated before the mock response is going to be called now let's go back and test the get profile operation one more time and let's go to trace and search for cache still probably we need to send another request search for cache as well as you can see here cache lookout took place but it didn't find anything in the cache and the reason for this because the mock responses are not caged if we get back to the policy you will see that the caching occurs in the outbound connection and during the mock response we don't even have an outbound connection we return the mock response in the inbound request that comes in so as the request comes in in here it's going to be processed in the inbound processing and return the mock straight away it doesn't get through the outbound processing to give it a chance to cage the response now let's go ahead and remove the cash lookout from here as well and let's save our changes probably we need to remove this line manually and then let's save our changes now let's go to function apps and let's create a new function that has a get http verb let's get into a linkedin profile go to functions and let's add a new function let's select http trigger call this function get jobs for example and let's create a function let's refresh this page and go to get jobs function now let's go to the integration section and select http request and only choose get verb to be supported for this function and let's save our changes and i'm going to leave the code that's in here as a default code i don't need to do any changes to it now let's get back to the api management and let's go ahead and import an api let's select function app and let's select linkedin profile api and select get jobs function and let's import this function as you can see here we have got get jobs operation in our api management and let's go ahead and test it and it will not work we are getting 401 unauthorized error that's because we didn't add the managed identity policy line in the get drops function so let's go ahead and do this let's go to git jobs function and add the managed identity policy line let's save our changes and now test to get jobs function one more time now it's working now let's go back and add cache for get jobs function and let's go ahead and add cache response and let's open the full configuration put some numbers in here this time i want you to enable allow private response caching and keep the downstream caching to private cache type to be internal and let's save our changes now let's go ahead and test to get jobs function and let's send another request and let's go to trace and check what happened to the quiche as you can see here it resulted in a hit it returned this response from the cache this time now let's go back to the policy and disable allow private response caching flag that we have specified before make it as false and let's save our changes and test the get jobs function one more time let's send another request for the cache to take place and let's see the trace let's search for cache and as you can see here the request contains authorization header and the cache lookout policy will not take place this is important to keep in mind when you configure the cache policy for your apis if your apis contains authorization header you have to enable allow private response caching otherwise it will not work now let's get back to the get jobs function and when we created the cash response policy you may notice that we had this policy been added to the outbound policies of the api management and this policy specifies how long we want to keep the data caged in the internal case of our api and these two policies has to go along together so if we try to remove this policy we will not be able to save our changes in the policy in here because to be able to read data from cache you have to store data in case as well now let's go back to the policies and see the other types of policies we also are able to get a certain value from cash and store value to the cash so let's go ahead and see how we can do this let's go ahead with the store value in case first and yeah this is not the right policy syntax so probably i need to go back to the documentation and copy it from me so let's go to store value in case and let's copy this line and let's put it in the outbound policies and in here i need to specify the key that i need to look for in the case and let's call it key and the value let's call it value as well and leave the duration as it is and let's go ahead and save our changes now let's go back to the policies and add a policy to be able to read from the cache read values from the cache and again let's go back to the documentation and go to the git value from cache and copy this policy and put it in here now we will get to see how we can use policy expressions with an access to different request headers or query string parameters and to do so let's go ahead and add context for example for request dot headers get value or default and the header that we are going to be looking for has a name header and the default value is going to be none and in the variable name here let's specify context dot request for example now let's go ahead and save this change now let's go to test to get jobs operation and let's have a look at the trace and let's search for cache and as you can see here cache lookup for value has been evaluated successfully however it didn't find any value in the case this happened for two reasons because this is our first run to run this operation and this is the first time to be able to cache the key value and the second reason that we haven't specified any header in our request yet so let's go ahead and add a header with the name header and the value of the header is the key which is that we have used to store the value in the cache and let's send another request now let's search for cache and in the request here you can see that lookup for value has found the result in the cache and if we go along and change the value to something that it's not in the cage keto for example and let's search for cache and as you can see here it didn't find any data in the cache and if we go to the outbound section you will be able to see how the data is going to be stored in the cache and for how long now let's go back to the get jobs operation and let's go to policies and the last policy i want to show you is the remove value from cache and again it's the wrong syntax i need to go back to the documentation and copy it from it let's search for remove value from cache and copy this line and let's put it in here and we need to specify the key that we want to remove from the cache let's specify key and what's going to happen here is we're going to remove the key from the cache straight after we create it which is pretty much if the key doesn't exist at all in the cache and of course you don't want to do this in production i'm just trying to show you how you can use different policies in the api management so let's go ahead and save this change and let's test get jobs operation let's search for cache as you can see here internal cache didn't find any value because we haven't specified a header yet so let's go ahead and put header in the name and key in the value and let's send another request and let's search for cache and you will see that still didn't find any value in the cache and the reason for this because we've specified in our policy to remove the value from the cache straight after we create it so it's a pretty much if it doesn't exist at all now let's go back to our policy and clean this up let's go to get jobs and let's go to policies and clean these policies up let's save our changes that's it for this lecture i hope you enjoyed it and please feel free to join me in the next lecture now let's talk about cross domain policies and the third thing i want you to do is to go ahead and check the global policy at all api level and as you can see here it's pretty simple right now let's go to the developer portal and let's go ahead and enable cors for our api management now let's go back to our apis and have a look at the global policy as you can see here by enabling cors from the developer portal it adds all of this tags to our global policy that's going to affect all apis in our api management and through this we can allow access to other domains to our api management in this domain so let's go back to the developer portal and here we can add or remove other domains to our api management so let's go to domains in the api management and this is the current domain that we have and we can add new domains however we will need to provide the certificate for the new domains that we are going to be add in the api management now let's go back to apis so go to linkedin profile and open the policy and from here you can add either cors or jsonp to control cross domain policies for your api management and i'm going to put a link for this page in the resources of this lecture so you can see some examples of cors if we go back to the api management and have a look at the global policy that we have defined you will see that we are enabled uh all methods and all headers for our apis however you can be very specific and specify what methods exactly you want to allow and what headers you want to allow as well that's it for this lecture i hope you enjoyed it and please feel free to join me in the next lecture now let's talk about transformation policies and in this lecture we are going to go ahead and add a sample api from microsoft to help us to go ahead in this lecture and i'm going to put a link to the sample api in the resources of this lecture now let's go ahead and add an api select open api and let's put conference api url that you will find in the resources of this lecture and let's go ahead and create this api as you can see the api has been created and it has different operations in it now let's see one of these operations let's say git sessions and let's go ahead and test it as you can see here 200 okay the request has been successful now i want you to pay attention to these two lines because they are really dangerous so these two headers tells what platform we are using for the backend service and what's the version of that platform and it's not a good idea to have this confidential information in the http response of our apis basically we are telling everybody what systems you are using on what the version of it and if they want to attack our system or bring it down they will have a good baseline to start their attack against us now let's see how can we use transformation policy to make this more secure so let's go to get sessions add policy and select set headers now i'm going to open a new tab so we can copy over the header names from the response let's select conference api get sessions and send a test request now let's go ahead and copy xasp.net version and put it in the header name here and leave the value empty and make the action delete and let's go ahead and add another header for x powered by and again putting the action delete as well now let's go ahead and save our changes as you can see here we cannot have a value specified for delete action and if you check here probably we have got an empty string in here so let's save our changes okay now let's test get sessions operation one more time and as you can see we are still able to see these two headers so let's go back and see what might be wrong and probably you have noticed it already we have put these headers in the inbound processing and of course it's not going to be applied for the http response and to fix this we need to put these two policies in the outbound policies of our operation let's go ahead and save this change now let's test our operation one more time and as you can see here we are not able to see these headers anymore so it's really important that you are putting your policy in the right place from the get-go to make sure that they are applied in the direction you wanted them to be applied now let's go to have one more look at our http response and you may have noticed that the orl for conference api is already included in our response and we don't want to have this url in our responsive course now let's get back to policy and see what we can do to protect this let's go ahead and add mask url in content this is the wrong format so probably i need to get back to the documentation and i'm going to put a link for this page in the resources of this lecture let's select mask urls and content and let's copy this line and make sure you are putting it in the outbound policies and let's go ahead and save our changes now let's test to get sessions operation one more time and i want you to notice here the url difference this one starts with conference api and the new one should be starting with our api name and mask the real url for the backend function that we are using as you can see here what's included in the response is the url through our api management not the url of the backend service that we are using this is to make sure that the backend services are well protected now let's go back and clean this up and see what other transformation policies that we might have let's clean this up and save our changes now and these are the other transformation policies that we can use we have already seen set http header and all of the other setters are exactly the same logic however the syntax might be different a little bit where you get to set either the backend service or a status code or a request method also you can convert json http request to response to xml and the other way around also you can replace a substring in the body of your request or response and you can rewrite the url in different formats and i'm going to put a link for this page in the resources of this lecture so you can follow along and find some examples of the different kind of policies however we have gone through the hard ones and you now should be familiar how you can write policies for your api managements that's it for this lecture i hope you enjoyed it and please feel free to join me in the next lecture now let's talk about advanced policies and i'm going to put a link for this page of the resources of this lecture and let's talk about control flow and as you can see here it's more like if else or switch condition in normal programming language where you specify different boolean expressions and based on the evaluation of those expressions it's going to control the execution flow of our policy let's go ahead and have a look at the example here assume we have a variable here called is mobile and it gets the value from request headers and based on the value of osmobile if it's true we are going to set a query parameter to be true and if the value of is mobile is false we are going to set query string parameter mobile to false now let's talk about forward request when we receive a request it's being forwarded to the backend service for processing and what this policy does it's going to specify a timeout in seconds for the backend service to be able to process and respond back to our request so let's have a look at example here assume that we have specified this policy at the global level right we specify the timeout for 60 seconds notes here that it needs to specify in the back in the tag not in inbound or outbound because it's something that affects the backend services now if we look at the operation level you'll see that we will not have to specify the same timeout here and the reason for this because policy is using inheritance and the lower level policies are going to inherit the specifications we defined for the higher level policies so for this policy we specified it for all apis and this policy is scoped for the operational level however it's going to use the 60 seconds timeout that we specified in the higher scope even though the timeout is not specified at the operation level explicitly now let's talk about limit concurrency and it's a way to specify the maximum requests we can get at any time and if we are getting more requested than that we are going to respond with four to nine too many requests is tedious code now let's talk about log to event hub and it's a policy that allows us to send the http requests or responses to the event hub for processing and we get to specify what data exactly we want to send there for processing we can specify the date and time and the service and ip address of the request and we are going to cover this in more detail in the monitoring section now let's talk about mock response and we've already talked about it in the previous lectures where you get to specify the status code that you want to mock in addition to the content type now let's talk about retry policy which is taking a boolean expression for evaluation and as long as the expression is true and the number of retro attempts didn't hit it's going to retry the execution now as you can see here the boolean expression is the status code equal 500 and the count of retrials is less than 10. now let's talk about return response and what does it break the pipeline execution and return either a default or a custom response the default one is 200 with nobody however you can specify a custom response code as well now let's have a look at send one way request and as it says it's ascending a request without expecting any response back and let's have a look at this example and it will make more sense as long as we are receiving a cts code more than 500 we want to send a one-way message to slack so we can get to notify the team members that are responsible for this api now let's talk about send request this is where you specify the url that you want to send and forward the request to it and it needs to be fulfilled within the specified timeout as you see in this example here the timeout is 20 seconds and this is the url that we want to send the request to now going to set http proxy this is where we specify proxy to forward requests via http proxy https are not supported and you need to specify the username and password in this policy and look at these three setters you get to set the request method as we see in here you can specify what method you want your request to apply and also you can set the status code of your request for example this one setting 401 for certain condition and also you can set a variable for your policy to be used for example here we created a variable called is mobile and it's going to take the value from request header then we have trace policy here which helps you to inspect what might be happening in your api and add more information to the trace tab and we are going to see this in a minute and finally we have the wait policy whether you specify either waiting for all of these conditions to be met or just anyone to be met now let's go back to the api management and go to the get jobs operation and let's see how we can add the trace for this operation so let's go ahead and add output trace information this is not the right syntax so let's paste this line and i'm going to leave everything to the default except these uh context variables here i'm going to say this is my trace for example and let's go ahead and save this now let's test get jobs operation and let's go to trace let's search for trace as you can see here we have added this line in the trace to help us getting more information about either the request or response that's it for this lecture i hope you enjoyed it and please feel free to join me in the next lecture now let's talk about how we can debug api management policies as we have already seen from the previous lectures that while you are using policies in your api management that chance that your policy file is going to get bigger and bigger a really high and it's going to be difficult for you to debug and diagnose what might be wrong in your policy file so in this lecture we are going to see how we can use visual studio code along with api management extension to help you to debug your policies of the api management and i'm going to put a link for this page in the resources of this lecture so let's go ahead and install visual studio code if you don't have it and also install azure api management extension it's really easy and straightforward in installation process here i am in visual studio code and i have installed api management extension and the first step you want to do is to go ahead and sign into your azure account and you can do so by going here and click on sign into azure or you can click on control shift p and search for sign in command and go for it now i have signed into azure account and here are the different subscriptions that i have and different api managements in my account and let's have a look at the apis here and as you can see here we have linkedin profile api twice and the reason for this is because we have created a secondary version of linkedin profile api in the previous lectures if you remember as you can see here this is the revision one of the linkedin profile api and this is the revision2 now let's go ahead and open the 2 operations and let's go ahead and test the get jobs operation let's go for start policy debugging then we need to go ahead and click on send request and then we are getting to our policy here and we can debug it step by step to see how are the different policies are being executed and how we are changing the behavior of our apis and these are the normal debug buttons that you're already familiar with you can go step by step or you can step out from the execution of this policy altogether and here in the debug console you are able to see different information that's going to help you to debug your policy and your api and at the end of this debugging process you are going to get the normal responses that you are expected to get from the get jobs operation that's it for this lecture i hope you enjoyed it and please feel free to join me in the next lecture now let's talk about the api management infrastructure and let's go to the pricing tier one more time and as you can see here developer tier provide no scaling for extra units for the api management however when you go to the other tiers you can scale your api management to multiple instances according to your tier so when you go back to the locations you can see here that my api management is only hosted in australia east and i have only one unit and i cannot scale this up anymore because this is the maximum limit of the developer tier and of course when you are in other tiers you will be able to scale your api management to multiple units according to your tier now i want you to note the virtual network availability in the frontiers it's available only in developer and premium tier and of course you cannot use a developer tier in production workload because there is no sla for the developer tier and this is one of the things that makes the premium tier pretty expensive in addition to the unlimited scaling and how many requests it can handle per each unit sometimes you might need to provide a public accessibility to your apis like the big api providers in the world however in some situations you might need to restrict the accessibility to your apis to your organization only and this is when you should consider putting your api management in an internal v-net and let's go ahead and see how can we do this before we go ahead i want you to notice something in the overview tab here you may notice that we have only one public ip address is associated with our api management and when we go and place our api management in an internal v-net we are going to have two ip addresses assigned to our api management public ip address and a private ip address let's go ahead and see how can we do this let's go to virtual networks let's click on internal let's select a v-net probably it's better to go ahead and create a new virtual network now let's go ahead and add a new virtual network and let's put it in the resource group and call it api internal v-net and put it in australia east region and leave everything else to the default values now let's go ahead and create this v-net now let's go to our virtual network and go to subnets and let's add one more subnet let's call it api management subnet let's leave everything to the default values now let's go back to our api management and probably we need to refresh this page one more time let's select internal and select the v-net and let's select api internal v-net that we've just created and select api management subnet and now let's go ahead and save our changes and it's going to take between 15 to 45 minutes for our changes to take place so i'm going to pause the recording and get back to you when it's done after 30 minutes or so our changes has been applied and now our api management is hosted in an internal v-net and in the subnet that we have specified before now let's go back to the overview and note something and as you can see here now we have two ip addresses associated with our api management public ip address and a private ip address and this will only happen when you put your api management in an internal vnet if you are going to put your api management in an external v-net you are only going to get one public ip address only now let's go back to our apis and see how this is change is going to affect our apis let's go to linkedin profile and let's go ahead and test one of the operations let's say get jobs and let's send a request as you can see here we are getting 400 bad requests because the api management is not reachable now let's try to go ahead and open the developer portal and again the developer portal is not accessible anymore all of this because we have put our api management in an internal v-net it will not be publicly accessible anymore now let's go ahead and create a virtual machine and we are going to put it in the same virtual network so it will have access to our api management now let's go ahead and create a virtual machine and let's put it in their resource group and let's call it api virtual machine australia east no infrastructure redundancy required and let's select windows server 2019 and let's select username and password then let's go to the network tab and in here we are going to put this vm in default subnet and then let's go ahead to the review and create and then let's go ahead and create our virtual machine now let's go to our virtual machine and let's connect to it using azure bastion and then let's go ahead and click on use bastion and for this one we need to have a subnet with the name of azure bastion subnet so let's go ahead and copy this and click on manage subnet configuration and we are going to create a new subnet in our v-net with the name of azure bastion subnet and let's go ahead and create this subnet now let's go back to the azure bastion and now let's go ahead and create it now my azure bastion has been created so let's go ahead and connect to click on use bastion and then let's provide the username and password that we have specified for our vm let's click on connect now let's go ahead and open internet explorer and try to access the api management because both of these virtual machine and the api management are hosted in the same virtual network but we are in a different subnets but they should be able to access each other right now let's go back to the api management and open the developer portal and let's copy the url that's in here and as you can see we are still not able to access the api management or the developer portal of our api management even though being hosted in the same v-net and to fix this we need to go to the virtual network then go to subnets and then select the subnet where the api management is hosted and then let's delegate subnet to api management service let's go ahead and save our changes now let's go back to our virtual machine and try to test the url one more time and as you can see it's not working because we need to do some updates in the host file so let's go to c windows system32 drivers atc and open the host file and in here we need to put the private ip address of the api management in this case 10.1.1.5 and then follow it by the url of the developer portal and also need to add one more line for the api management itself which we can get from properties gateway url and let's put it in here as well and let's take out the prefix now let's go ahead and save the host file now let's go back to the internet explorer and test the developer portal one more time and as you can see here we are able to access the developer portal from the vm now let's go ahead and sign in to the developer portal and as you can see we cannot sign into the developer portal and the reason for this is internet explorer has enhanced security for windows servers and what we need to do is to close internet explorer and go to the windows or server manager let's click on configure this local server and then going to ie enhanced security configuration and turn it off then let's go back and open internet explorer and try to put the developer portal url one more time let's go to sign in and let's put the email address of the user we have created before username one at outlook.com i'm putting the password as well here we go and then going to products basic products linkedin profile get profile operation and let's try this operation and send the request here we go 200 response code and the operation has been succeeded now let's go back to the api management and go to the overview and as you can see here the repository is disabled for the api management so let's go ahead and save our api management configuration and settings to a code repository it's going to make it easier for us when we try to build the ci cd for the api management later on and we are going to cover this in more detail later on through the course as you can see here our api management has been committed successfully to the master branch which is great now let's go and have a look at the other components of the infrastructure which is external cache we have already seen the internal cache previously when we have worked with the caching policies but the external cache is different this is where you are going to provide a connection string for an external cache for your api management to be able to use however it's a good rule of thumb to try to use the internal cache that's already provided in the api management first before consider to have an external cache because it's going to add more money to your monthly bill now let's go ahead and see custom domains and as you can see here you can create a custom domain or host name for different api management components however you would need to provide a certificate for this one and the easiest way you can create a certificate by using key vault now let's talk about gateways and sometimes they call it self-hosted gateways and it supports hybrid a multi-cloud environment where it allows an organization to manage all of their apis either on-prem or azure or aws or any cloud environment managing all of that from only one single api management instance and to do so let's go ahead and add a gateway let's call it self hosted or self hosted yep location here is australia east and then you need to select the apis that you want to have in the self-hosted gateway now when we go into the gateway in here go to the deployment tab you will able to see the commands that you will need to run either on docker or copernitos to be able to install or have or provision the self-hosted api management in your docker or copanito's instance and also you are able to see the different apis that you have in your gateway and also you can add more apis if you would like and also you are able to define hostnames and the keys for your self-managed or self-hosted api and by doing so you are going to lose some of the out-of-the-box features that's already provided in the api management in the azure portal now let's go ahead and clean this up that's it for this lecture i hope you enjoyed it and please feel free to join me in the next lecture now let's talk about application gateway and how can it be really helpful when it work together with api management assume you have a scenario where you have set of internal apis that are restricted for internal use at the same time you have set of external apis that you want to share with external customers of course it's going to be really difficult to build maintain and also very expensive if you are going to have two api managements one for the internal apis and one for the external apis and what microsoft recommends in here is to have only one api management unhosted in internal v-net and then we are going to have our internal apis and external apis hosted in this api management and we already know from the previous lectures as soon as we put our api management in an internal v-net our api management will not be publicly accessible anymore to the external customers and it will only be accessible to the internal customers that are connected to the internal v-net so the internal customers or internal systems will be able to access the internal apis that are hosted in the internal v-net but the external customers will not be able to reach the external apis at the moment this is why we need to bring in the application gateway and put it in between so the application gateway here will work as wef or web application firewall and it's going to use url based routing to direct external customers traffic to the external apis that are hosted in an internal v-net at the same time it's going to block any external traffic that will be directed to the internal apis because they should be protected from external traffic now let's go ahead and see how can we provision application gateway to make this architecture work now let's go to our azure portal and let's open our api management instance scrolling all the way down to custom domains and let's add a new one selecting gateway type and let's put api.mycompany.com in the hostname however it's important to mention from the get go that this scenario will not work because i don't have a dns record for mycompany.com however i am going to show you all the steps that you have to do in the api management and in the application gateway and also will guide you how to create a self-signed certificate in the key vault and what you will have to do is to create a cname record to direct the traffic from the api management to your application gateway now let's go ahead and open key vault and let's go ahead and add a new key vault let's put it in our dev resource group and let's call it my company api key vault and let's put it in australia east region and leave everything else to the default values and let's go straight to create our key vault and let's go ahead and create it now let's go to our key vault and let's go to certificates and let's generate a new certificate let's call it gateway certificates let's select self-signed certificate and let's put in the subject here api.mycompany.com and let's go ahead and create this certificate now let's go back to our api management and select this certificate from our key vault let's select our key vault and let's select the gateway certificate and now let's go ahead and add this custom domain and as you can see here api management doesn't have an access to the key vault and let's go ahead and click yes to provide the application gateway the api management with the proper access to the key vault and now let's go ahead and save our changes and it's going to take few minutes for the changes to be applied so i'm going to pause my recording until it's finished as you can see our custom domain name has been created now let's go ahead to the application gateways and let's add a new one let's put it in the resource group and let's call it application gateway put it in australia east region and select the tier to be waf version 2 waf stands for web application firewall auto scaling off and let's put it in our internal v-net and as you can see here the application gateway has to be in a subnet by itself so let's go ahead and do this and let's add a new subnet and let's call it application gateway subnet now let's go back to the application gateway and let's refresh this page and again we are going to put it in the resource group we are going to call it application gateway australia east west version 2 auto scaling off and we are going to put it in our internal v-net and in the application gateway subnet that we have just created now let's go to next steps here we need to specify a public ip address or a private ip address for our application gateway so let's go ahead and create a new one let's call it application gateway ip and let's go to the next step now we need to add two backend pools one back in the pool that's going to be directed to our api management and the other pool that's going to be terminate the traffic and doesn't redirect the traffic anywhere else so the first pool it's going to call it api and in here i'm going to put the private ip address of my api management and let's go ahead and add this and then let's add another pool let's call it sink pool and we are not going to assign any target with this pool let's go ahead and add this and let's go to the next step here we need to define the routing rules for our application gateway so let's go ahead and define rule one and let's call this listener one however you should use a proper names for your listener and roles because you will not be able to change them once you create your listener and rules and front-end ip let's select public http port 80 leave everything to the default values however in production you should consider using https and certifications now let's go to the backend targets and let's select api and for http settings let's go ahead and create new settings let's call it http settings 01 http all default values and then let's go ahead and add this and again in production you should consider using https in this settings let's go ahead and add this now let's add a path based routing here so for the internal routes in the url it's going to be targeted to the sync pool internal target and here we are going to use http settings one and it's going to be directed to the sync pool which is not going to pass this request anywhere however if we have an external in the url then we are going to pass this one external target then we are going to pass this request using http settings so on to the api backend target let's go ahead and add this one and then let's add this rule now let's go to the next step and let's go ahead and create our application gateway and again it might take few minutes for the application gateway to be ready so i'm going to pause my recording until it's done now the application gateway is ready for me so let's go to application gateways and app gateway and as you may notice here we have got a notification that says one or more of the backend pools are not healthy and the reason for this is that we need to create a specific props for the api management so let's go ahead and add one let's call it api management health check let's make it http and for the host name let's go ahead and copy the gateway hostname and for the path here we need to get back to the documentation and add a specific path to be able to get the healthy check of the api management so let's scroll all the way down here and we need to have this path in the healthy check for the api management to be able to return a proper response now let's check the http settings and let's go ahead and test this health prop before we add it as you can see here it succeeded so let's add this health prop and now let's go and check the backend health and as you can see it's healthy and now let's go to connection troubleshoot now let's specify our ipu manually and let's put the private ip address of our api management 10.1.1.7 and let's specify port 80 and let's check the connection and as you can see here it's been succeeded and the first hop has been to the application gateway and then destination to the api management and as i said before i will not be able to demonstrate this scenario for you because i don't have a custom domain name for my api management however in the production you should consider using https along with an ssl certificates to secure the connections between the client and the application gateway and between the application gateway and the api management now let's go ahead and clean this up let's go to overview and delete the application gateway and then let's go to the key vault and delete our key vault as well however we should go to the api management and delete the custom [Music] gateway that we have created before because it uses this key vault let's go ahead and delete this one and then let's save our changes now let's go and delete our key vault let's go ahead and delete it then let's get back to the api management and turn off the virtual network that we have created before so we'll be able to use the api management as we used to let's go ahead and save our changes it's going to take some time like 30 minutes or so now we have everything cleaned up now let's go to all resources we have one more thing we need to do manually scroll down to the public ip address that we have created it doesn't delete automatically one we delete the application gateway so we have to delete it manually in here so let's go ahead and delete it as well and then let's go ahead and delete the virtual machine that we have created api vm and its public ip address network security group and anything might be associated to it so let's go ahead and delete this as well that's it for this lecture i hope you enjoyed it and please feel free to join me in the next lecture now let's talk about the cicd pipeline for the api management and i'm going to put a link for this page in the resources of this lecture most of the time in your organization you will have more than one api management instance as you can see in this example here we have two api management instances a development instance and a production instance an api developers want to do their changes in the development instance and once they have done their changes and we test it and they are happy with it they want to automate the deployment to the production instance and they want to make it as easy as possible and as sustainable as possible so when the api developers finish the development of the backend functions and creating their api definitions we are going to go ahead and generate templates and we call it arm templates and this is the key thing here for the devops for the api management it uses arm templates to migrate the changes between different instances between development instance and production instance in this example here now let's have a closer look at these arm templates and as you can see here we have four are templates for the api management first one is the service template this is where it gets defined the pricing tier virtual network custom domains and anything will be related to the api management itself then we have api templates and it could be one or multiple templates based on how many apis we have created in our api management then we have shared templates this is where it's going to have the shared resources such as products subscription key etc and then we have a master template that putting together all of these templates in case we want to deploy everything in our api management to the production instance and all of these arm templates will be stored in the same code repo that we have created for our api management if you remember and then once we finished our development and we are happy with the testing result we can create a pull request to deploy a certain template to the production instance for example we can choose to deploy linkedin api template only to the production instance and leave everything else as it is and also it's important to make sure that you are doing your changes to the very latest version of your api management so it's important to fork the arm templates from production instance to the development instance before you go ahead and do some changes to your api definitions or back in the functions and then you go ahead and generate these templates and then keep going with the pull request and publish to the production instance this part is very basic part in the azure devops where you are going to fork between different instances or create a pull request to deploy to a different api management instance however in this course i am going to show you how can we generate these arm templates from the api definition that we have created in our api management and i'm going to use visual studio code to show you how can we do this here we are in visual studio code and let's go to the azure tab and we can extract the api management either from the api management extract service here however i am going to go to the demo conference api and extract this api and as you can see here we have done azure login and then trying to get the different operations in the conference api get session get sessions all of these different operations we're extracting these definitions in the arm template now if we go back to our project explorer you will see the different templates have been generated we have here the master template as you can see where it contains the definitions for all templates in our api management and we have a template here for the demo conference api which is the api item template which is what we are going to use if we want to deploy conference api template only and then we have named values template as well so this is how we can use the visual studio code to extract the definitions of the apis and generate arm templates to be used in ci cd and to make it even easier for you in this page you'll find some commands where you can use create or extractor to use command lines to extract the definition of your api management to make it easier for you to automate it using azure dev ops because of course you don't want to go ahead in visual studio code to generate the definitions for your api every single time that's it for this lecture i hope you enjoyed it and please feel free to join me in the next lecture now let's talk about analytics and it's very important to keep an eye on the analytics of your api management in the production instance so you can understand what's going on in your api management now let's go ahead and increase the time range for these graphs and as you can see here the first graph shows the number of requests our api management had received over this time range total number of requests successful ones failed ones unauthorized requests which is very very important and you need to keep an eye on it unauthorized requests are simply requests that are not authorized to call our apis maybe because the consumer is using the wrong subscription key or maybe because someone is trying to attack our apis that's why it's really important to set up the right alerts to notify you if the number of unauthorized requests succeed a certain limit so then you can go ahead and check if they are really a genuine requests or it's someone that's trying to break your apis and then you can react on that notify your security team and networking team to protect your apis or block these danger from your api management moving to the next chart here shows the amount of data transferred through our api management and now the response time chart and this chart shows the average response time and average service response time for the api management and to understand the difference between both let's go back to our apis now let's go to linkedin profile api and let's go to get jobs so the response time is the overall time is going to be required from the api management to fulfill requests starting from receiving requests applying the inbound policies and then passing the request to the backend function to process it and get the results passing it through the outbound processing policies and then return the result to the consumer all of this is the response time however the service response time is the time that's required from the backend service to respond to a certain request so having these two times split up this way it will help you to understand where the performance bottleneck is coming from is it because the backend service is taking too long to execute a certain request or is it because you are applying too many inbound and outbound policies to your api that make the overall response time for your api slower and this will give you some pointers so you can go ahead and improve the performance of your api and finally here we have the case chart and that shows us how many times you have got cash hit and cash missed and always you want to aim to have as many cash hits as possible because this is going to improve the overall performance of your api now moving to the geography and what i want you to notice here is the total number of requests we are getting per country and as you can see here we are receiving more than 500 requests coming from the united states which is far more than any other requests coming from other countries and what this tell us is that when we go ahead and provision our api management it might make sense to provision our api management in an american region because this is where most of our traffic is coming from however if we have an even number and getting too many requests from all countries around the world it will make more sense to go ahead and provision an additional instance of our api management as you can see here i have only one primary instance for my api management hosted in australian east region and i can based on my pricing tier i can go ahead and provision another instance of my api management in the american region to make the experience and performance much better for the american customers and also what you can take away from this view the number of countries that are accessing your apis and if for example you don't have any customer base in turkey and you are getting requests from turkey it might be a red flag for you to investigate and see where this traffic is coming from is it genuine or not based on the fact that there is no customers for you in turkey now let's go to apis and this is where you are able to see this information grouped by apis also grouped by operations so you get a more detailed view of how many requests and the average response time per operation in your api management same information grouped by product subscription users and at the end you're able to see the different requests and response code that's been called to your api management that's it for this lecture i hope you enjoyed it and please feel free to join me in the next lecture now let's talk about application insights and this is the application insights instance that we have created for our api management now let's go ahead and open application insights and this is the application insight instance that we have created and of course we cannot cover everything in the application insights in here it's not the core of our course but i'm going to walk you through the most important things that you need to focus on first of all application map and there is no data available in here so let's go ahead and increase the time range to be the last 30 days and as you can see here it's a representation of our api management instance and the different apis we have in our api and number of calls and the average response time so it is the same data we have been able to see before but it's a different representation and you can turn on and off the 400s code in the view in addition to changing the layout as well now let's go ahead and click on the api management instance itself and as you can see here we are able to see the top failing requests at the api management level and as you can see here 81 failures coming from create profile operation and if you focus on a linkedin profile api you will be able to see the same data but zoomed in for the linkedin profile api only also you will be able to see the slowest requests by name for example for linkedin profile api these are the slowest requests are going to be processed at the api level and if you focus on the api management level you are going to see the same data across the whole api management and then we are going to focus on more how we can investigate different failures and performance issues now let's go ahead and see the failures and as you can see here there are no data available so let's go ahead and increase the time range to cover the last 30 days and as you can see here we can see the top three response codes top three exception types in our api management so for the response codes in here you are able to see how many failures you are getting per certain operation in respect to the total number of calls for example create profile operation receives 61 failures out of 136 codes and this will help you to understand how different philly how different apis or operations are responding and how many failures they are posing and then you can go ahead and resolve these failures one by one and also you are able to see the top three exception types for your api for example you can filter on the gateway error here for example and you will be able to see which operations are causing this particular exception and also you can go ahead and see the full list of exceptions in here and if you can relate to the rate limit exceeded exception this is where the throttling limit has been triggered for our apis and in this case you might need to increase the throttling limit for your operation or your api management and as well header not found exception in addition to other exceptions as well now let's go ahead and have a look at the performance and again we need to increase the time range to cover the last 30 days and as you can see here you are able to see how each operation responds and how many hits each of the operation gets and you can sort it out to see the longest duration and let's look at the first two operations here get sessions and get jobs both of them gets around 170 seconds execution time average execution time however get jobs operation gets more hits than get session operation so what this tells you that you would need to prioritize improve the performance of get jobs operation to make it perform more quicker because at the end get sessions has been only called once over the last 30 days compared to get jobs operation which gets far more hit than that and finally we have live metrics here this is where you can see the live metrics about your api management and how many requests per second your api management instance is able to handle and cpu utilization and memory as well in addition to the failure rate that's it for this lecture i hope you enjoyed it and please feel free to join me in the next lecture now let's talk about api management metrics and metrics is a really nice way to help you to understand the health of your apis in the api management and in this lecture we are going to focus primarily on two key metrics capacity metric and requests metric so let's start with the capacity metric and capacity metric helps you to determine whether you need to upgrade or downgrade the tier of your api management for example you might be on a high tier api management instance but in reality you are receiving a little number of requests every second and in this case it will make more sense if you downgrade the tier of your api management to make it more cost effective on the other side you might have a really low tier api management instance and you're receiving an overwhelming number of requests and in this case it will make more sense if you upgrade the tier of your api management to accommodate to the number of requests you are receiving so capacity metric is the one metric to go to know whether your api management is on the right tier or not and whether you have the sufficient number of instances deployed for your api management and then you can take it to the next step and either increase the number of instances or reduce the number of api management instances and if you are into div ops you can watch the capacity metric and see how it goes and then you can automate the allocation and the allocation of extra instances for your api management now let's have a look at this graph here and as you can see here the maximum capacity usage for this api management is 5.5 which is quite low isn't it but don't make this tricky because this view only covers the last 24 hours and if we expand it to cover the last 30 days we will see that the capacity has reached up to 40 percent at a certain points when you have been using too many requests for our api management so before you go ahead and measure the capacity of your api metric it's very important that you select the right time range for your api management one day you want to be realistic to measure the capacity of your api because the usage can be different over the week and the weekend day and night and different criterias and it's important to put all of these into consideration when you measure the capacity of your api management now that's enough for the capacity metric now let's go to the requests metric and the request this metric shows you the number of requests that your api management has received whether those requests are successful or not successful all of these requests are captured under the requests metric now let's go ahead and add a filter and let's add the backend response code this is the response code of the backend azure function and let's filter the value probably let's go ahead and increase the time range a little bit to have more uh response codes and then let's select 500 and it's going to update the chart to get the 500 response code from the backend azure function and you're also able to get the backend response code category instead of being very specific about which response code you want to receive you are able to get the category of the response code whether it's a client-side error or server-side error or whatever it is so for example if you are going to select 5xx it's going to return all 5 hundreds response code that's been returned from the back-end azure functions and also you are able to do the same for the gateway response code either to get it very specific response code for the gateway or to get the category of the gateway response code as well also are able to filter out by the host name of your api management in addition to the last error scene for your api management whether it's operation not found or any different kind of error that might get raised in your api management you are able to filter out by selecting these values and also finally the location of your api management in case you have deployed multiple instances for your api management you are able to see the metric for as specific instance but in our case we have only one instance because we have a dev tier so we can only select australia east region and to get the most use of the metrics you need to combine it with alerts and this is what we are gonna do in the next lecture we are going to see how we can create alerts that it's going to notify certain team members when a certain metric has been triggered that's it for this lecture i hope you enjoyed it and please feel free to join me in the next lecture now let's talk about alerts and it's okay if your view is a little bit different than my view because i have already created an alert and triggered it before i record this lecture now let's go ahead and create a new alert rule and as you can see here it's assigned for our api management instance in the course subscription and dev resource group now let's go ahead and create the condition and those are the matrix that we have talked about before and i'm going to go ahead and select the capacity metric and the dimension name and gonna be australia east because i have only one instance for my api management instance and i'm gonna select the static threshold if the value is gonna be greater than one percent and the aggregation granularity is five minutes and the evaluation runs every one minutes so what this means that every one minute we are going to evaluate the last five minutes of the capacity metric to see if the average capacity metric is more than one percent of utilization then it's going to trigger the alert now let's go ahead and add the condition and let's select the action group to be application inside smart detection and let's name this alert role to be capacity alert dev resource group severity level zero and let's go ahead and create the alert now it's going to take a minute or so for the alert to be evaluated because that's how or what we have specified in the alert configuration so i'm gonna pause my recording until the alert been triggered and then we'll get back to you now the alert has been triggered as you can see here the severity zero has got one alert and if we click on it we will see that our alert has been triggered the capacity alert has been fired for the api management instance and we can get into it to see what actually was the configuration we have created for this alert that's it for this lecture i hope you enjoyed it and please feel free to join me in the next lecture now let's talk about logs if you remember when we created the api management instance we have created a log analytics workspace with it and as you can see here there are predefined set of queries you can use straight away to get some result from your log analytics so let's go ahead and use the number of requests query and as you can see here no data has been returned although going to the analytics section we are able to confirm that our api management has received 13 requests over the last 24 hours so why those requests are not shown here in the log analytics and the reason for this is we haven't set up the api management to send the logs to a log analytics workspace so let's go ahead to the diagnostic settings to see how can we fix this then let's go ahead and add diagnostic settings and let's select the gateway logs and all the metrics and when it comes to the destination we can select to send our logs to either log analytics workspace or a storage account or to an event hub and for this case i'm going to select log analytics workspace and this is the workspace that we have created before and then i'm gonna select the name for my diagnostic settings to be diagnostic 1 and let's go ahead and save our changes now let's go ahead and open our developer portal to get some traffic through the api management so we can capture and see it in vlog analytics now let's go to apis echo api let's select retrieve resource api and let's send some requests now let's get back to the log analytics now let's go ahead and run some queries as we said before those are predefined queries that will help you to get some analytics about your api management now let's go ahead and run number of requests query and as you can see here we had 17 calls to our api management during one day also you can use all of these queries to get some information and analytics about your api management like number of calls per api if we run this query you will be able to see that all of these calls targeted echo api and also if you go to tables here you are able to see api management gateway logs and it includes different kinds of attributes and columns that you can use to create your own query to get more data about your api management now let's go ahead and expand the time range to be the last seven days and let's run the query one more time as you can see here only 17 calls for echo api and the reason for this api management starts to export the logs and metrics to the log analytics workspace from the time we configured the diagnostic settings and instructed the api management to export its logs and metric to the log analytics workspace anything any logs or metrics prior to that point will not be exported to the log analytics workspace that's why it's very important to make sure you configure your api management to export its logs and metrics to log analytics workspace from the get go especially for the production instances that's it for this lecture i hope you enjoyed it and please feel free to join me in the next lecture

Channel: Hussein Awad

Views: 59,666

Keywords:

Id: K-tYU8GOUt0

Length: 159min 16sec (9556 seconds)

Published: Tue May 25 2021