Miao Jiang talks about the importance of API’s as a core of Enterprise IT, and explains both the Publish and Consumption side of API’s. He also makes few announcements around improved Application Insights integration and KeyVault integration.
Integrate 2018, June 4-6, etc.venues, London
Kajal: And I’m Kajal Shetty. And I’m part of the licensing and customer relationship team at BizTalk 360. Our next speaker is Miao Jiang who is a senior program manager at Microsoft. And this is his first Integrate event in Europe. However, he had previously presented in 2017 Integrate in the USA. So and he will be speaking on the overview of API Management. So let’s please give him a warm welcome, Miao Jiang.
Miao: Thank you. Hi, everybody. My name is Miao. I work on API Management at Microsoft. So today I’m going to talk to you a little bit about APIs and API Management. So before that, just a quick survey. How many of you have heard of our product? Good, good number. So how many of you are actually using the product? Good. So, who thinks APIs are valuable and important? Okay, great. So I don’t have to work very hard to convince you on that part, right?
So first of all, let’s talk a little bit about the rise of APIs. So if you have been in the industry for the past decade or so, you have witnessed the fact that the technology landscape is getting more and more distributed than ever, right? Ten years ago, there was no cloud, right? There were very few stats systems, devices were kind of dumb, right, things like smart home and connected cars were only seen in science fictions. But today, 10 years later, all of these things are growing tremendously, right? And in fact, APIs has become the default standard for people to connect and exchange things, right?
They kind of started there outside of the…on the peripheral, outside of the enterprise firewalls, right? But then, as organizations and developers gain expertise in building APIs, and as technologists mature, they kind of trickled into the core of enterprise IT. And today, we are actually at a point where if you need to expose a piece of functionality, or if you need to enable some data exchange, right, APIs is the default way to do it. This is not even a discussion, right?
And technically, if you’re building an API, there are some things involved, right? There is HTTP and JSON for communication and the payload, right? There is OAuth for security and there is OpenAPI for describing your APIs. Also, formally now a Swagger file, right? So it’s a very limited technology stack. And anybody can build an API today, I mean, any developer can build an API today, right? And every language we use today has at least a handful of frameworks to help people build and consume APIs. So the technical challenges are somewhat trivial, right? Yes, there are still, you know, finer points and the distinctions between good, bad and, you know, great APIs. But in general, if you are a developer and you need to fulfill some requirements, getting an API out is not something that’s so difficult, right?
And one very interesting aspect of APIs is that they have become a key business driver. Basically, if you search for the value of APIs online, you’ll find a lot of articles and this is something that Gartner talks a lot about. There’s even a term about it called API economy. Basically, APIs have become transformational for organizations, right? We see a lot of stories where organizations derive tremendous value, you know, top 10 top line revenue and efficiencies from APIs, right? For example, organizations today use APIs to build mobile apps to ensure customer satisfaction and loyalty, right? And they also use APIs to build ecosystems to be able to get new customers through partners and affiliate networks, right? And APIs are also used internally to achieve agility and to empower employees to build solutions faster and to respond to market forces faster, right?
And another very interesting about APIs is that they are very well suited for building ad-hoc integrations, right? Due to the standards, common patterns, and all the tools we have today. Nowadays, any developers can write a piece of code which caused an API to gather some data and then cause another API to do something about data, right? This is all great but here is where it gets really interesting when platforms like Logic Apps emerge, right? So these platforms, they are API aware, they know how to connect and orchestrate different things and can fulfill all the necessary logic and the transformation in between, right? So these platforms, they’re really complimentary of APIs because they enable you to get the value of the investments you put into those APIs much faster and easier.
And finally, APIs are also subject to the network effect, right? Just like social networks, every new API you build adds some value to your other APIs because it gives you another way to connect and orchestrate things a little bit differently. So, all of these things, right, the change in the industry, the simplicity of building and consuming APIs today, and the business value that APIs create today are responsible for the exponential growth of APIs in the past five years.
And in fact APIs are the basis of every digital strategy today, right? So, with its importance and the strategic value of API today, right, they need to be carefully managed. This is where API Management comes into play. So in every API value chain, there are two very important groups of players. There is the API managers and developers, sometimes also called the publishers, and then there is the app developers. So essentially, the API managers and developers, they are responsible for designing, developing, and deploying the APIs, right? And after that, they will publish their APIs to app developers, no matter if internal or external developers. And then those app developers, they will take advantage of these APIs and build their apps on top of these APIs.
And so this is very easy to understand. There is a publishing side and there’s a consumption side but there are some needs that needs to be addressed on the both side, right? For example, on the publishing side, as soon as you start publishing an API, there are a bunch of concerns that you need to consider immediately, such as obstructing your APIs, right? This is about de-couple the frontend apps from your backend API so that the apps does not call your API directly. Otherwise, that will be super hard for you to make changes on the back end, or move things around on the back end, right?
And also, how do you secure and protect your APIs? This is also very important because APIs are crucial now to all the apps we have today, right? And also, managing the lifecycle of APIs is also very important. This is about how to make changes to our APIs in a safe way, and also roll out those changes without impacting the consumers, right? And how do you monitor and measure your API? This is about how do you know if your APIs are healthy or not? How do you find out who’s calling APIs and how many calls they are making, right? And how do you get interesting insights of your APIs and make them better, right? And then we all know that the value of APIs are realized when those APIs are used, right? So, you need to somehow provide a way for people to discover your APIs and onboard those developers, right? And finally, if you need to monetize your APIs, you also need to get detailed reports on, you know, detailed usage reports on your API, so you can charge your customers.
So on the other side, for the app developers, they are concerned about, how can they quickly discover the APIs that are relevant to their apps, right? And after that, how can they quickly and easily learn how to use those APIs and get access to the APIs and also, we all know that the time to the first successful call, is very important to every single API, right? So it will be ideal if developers can try your APIs without writing a single line of code, right? And if they have issues, if they’re faced with issues when using your APIs, where do they get help? Where can they raise support ticket and things like that, right? And finally, where can they get artifacts such as SDKs to use APIs or sample codes showing how to use APIs?
So there are concerns on the both sides. And this is where API Management comes into the picture, right? Basically, API Management connects both sides and while addressing all these concerns. So out of the box from API Management, there were three key components, on the right-hand side here. The blue box is the Admin experience, both interactive and problematic for the API publishers to manage and to publish their APIs. And then on the other side, we have a self-service developer portal which can help developers to discover, learn, on-board, and try your APIs, right?
And then in the heart of the product is a highly scalable API gateway, which provides you a layer of abstractions between apps and the backend APIs. And also you can do all sorts of things that we just mentioned in API gateways, such as no throttling, authentication, caching, transformation, and so forth. And the gateway can connect to any APIs as long as it’s an HTTP Web API. And as long as the URL of the API is resolvable, right? So it means your APIs can be hosted on Azure, right? It can be hosted on another cloud or we can also connect to on-premise APIs using virtual network technologies or express route, right? So tomorrow in our deep dive session, we will talk more about the virtual network topic.
So, a lot of the things you do in the API gateway results in application of what we call policies, right? So, basically policies in API Management, they encapsulate common API Management functionalities such as access control, protection, transformation, and caching, right? Policies can be changed together into a pipeline to mutate request contexts, or change your API behavior. They can also be set both in an inbound and outbound directions.
Policies can also be used to handle erroneous conditions. For example, if the call to the backend times out, right, you can route the request to another backend, right, using policies. And policies can also be applied at a variety of scopes. For example, you can have one set of policies which apply to all your APIs, right? And then another set of policies which only apply to individual API, okay? And on the right-hand side here is a quick list of all of our 40 policies. So we have policies for transformation such as XML to JSON, JSON to XML, you know, manipulating the headers or the HTTP bodies, right? We also have policies for authentication with OAuth, or, you know, rate limiting setting quota for each apps or developers and things like caching request, fan out, and so forth.
So policies are very useful, but they become more powerful and flexible when used together with what we call expressions and named values. Basically, policy expressions are C sharp snippets that you can embed into your policies to dynamically configure and conditionally execute policies. And named values, they’re properties of key-value pairs which are shared across an entire API Management instance. You can use them to keep secrets and the magic strings out of your policies. And if named properly they can also add semantics to your policies, right?
And if you use the named value in multiple places, it enables a single point of change. And you can also use them to provide environment specific values. So, for example, I have a very simple policy document here to show how to use policies with expressions and named values. So here in the first step, I’m using the set variable policy. And I’m reading the HTTP header content length from the incoming request and save it in a variable called body size. And here you can see that I am using a C sharp snippet to access the request context to read that header value, right?
And then in the next step, I am using the conditional policy with C sharp snippets to check the value of that variable. If the body size is less than 256 K then I don’t do anything, right? But if it’s more than 256 K, then what I’ll do is I will change the URL of the backend. Basically, I will route to this request to a different backend. Let’s say, my scenario here is that I have a dedicated host to handle large requests, right? And as you can see here, that instead of providing the actual value of the backend URL, where I’m using a couple named values here, which makes the policy much cleaner, and if I use this value in multiple places, I only have one place to change if I need to change the value, right?
So this is policies with expressions and named values. So, our product started became generally available in September 2014. So we are in the market for a little under four years now, and we have seen tremendous growth in the past four years. So today, we have a little over 10,000 customers, including 25 of the Fortune 100. And in total, our customers have a little over 17,000 API Management instances because some of them use multiple instances for different environments. And on a monthly basis, we are serving a little over 77 billion API calls. And in total, there are a little over 112,000 APIs that are managed and published through API Management.
So over the years, we have seen lots of very interesting use cases of APIs and API Management. Here are some of the most common ones. The first one is enterprise API catalog. So this is about using API management to expose all your APIs to internal and external developers and provide them with a centric place to discover, learn, and onboard and consume your APIs, right? We love the example here is Alaska Airlines. So Alaska they have grown from a regional airline to one of the largest airlines in the United States. And just like any other enterprises, Alaska has been building monolithic systems for decades, right? And we all know that those systems are slow moving and slowly evolving.
But today, you know, the airline industry is highly competitive, right? And in fact, your competition is just one click away, right? So to be able to innovate faster and deliver value to their business faster, Alaska has made an architectural decision and adopted an API driven strategy, basically. And also, they have been gradually splitting their monolithic systems into individual API services, which are highly shareable and highly reusable, right? And also enables them to scale individual APIs independently, right? And they use API management to provide a single point of discovering, onboarding and consuming all the APIs. And today, all of Alaska mobile apps, web apps, and the kiosk apps run on top of this API layer. And because of this API layer, they’re also able to expose some of the APIs to their partners to generate additional sales, right? Which brings us to the second use case, which is customer and partner integration.
So, this is about securely expose your APIs to your partners and customers directly to build a digital ecosystem that benefits your business. So, this benefit can be either direct, increased direct sales, or it can also be improved quality of service, right? So, one of my favorite examples here is Met Office. And obviously, my favorite example changes all the time based on where I’m presenting. So, Met Office, they have built and exposed a set of APIs to citizens. And this citizens includes, people like, you know, weather enthusiasts, scientists, academics, right? So, basically citizens can use these APIs to upload their weather observations, such as temperature, humidity, wind direction, rainfall, and so forth, right? And with this API, Met Office was able to collect more than 800 million observations since the inception of this platform. And this, you know, this weather observations from citizens are now very important to the accuracy of their weather forecasts.
And next, mobile enablement in IoT is another very popular use case. Basically, as I mentioned before, APIs are used today to enable all the apps running on mobile apps or apps on their mobile devices and IoT devices. And when you expose APIs to thousands or millions of devices, you want to make sure that your APIs are secured. They are protected from misused and abuse, right? And, one of the examples here is DNB Bank in Norway. They are using API management to expose their microservice based APIs to a new mobile payment app they built called Vipps, which is currently used by 2.7 million Norwegians today.
And the next one is a very interesting use case, which is APIs as business. So for many…for some organizations today APIs is the only product that they sell, right? And for these organizations, they care a lot about things like discoverabilities of their APIs, right? And usage analytics of their APIs. And one of the example here is Fantasy Data, which is a start-up in the U.S. and also a leading provider of real-time sports data. So basically, they provide data such as real-time scores, stats of players and teams, right? And they sell their data through APIs to their customers, such as casinos, you know, fantasy apps, and news websites. And with the out of the box functionalities from API Management, such as developer portal, API productizations, throttling policies and API Analytics reports, Fantasy Data was able to launch their platform quickly within just a few weeks just before another NFL season started.
And finally, gateway for microservices is another emerging use case. Basically, as you know, just like Alaska, a lot of organizations today are breaking their monolithic systems into microservices, right? And as soon as you do that, you will need a gateway to help you decouple the frontend apps from your microservices and do things like SSL offloading, request orchestration, authentication, and so forth, right? So, for example, Quest Software, they use API management to handle all the authentication for their microservices and the also call the API management the glue that ties everything together because they have microservices running everywhere. Some of them are in Azure, some of them are in other clouds. So they use API management to create a layer of abstraction and hide that complexity away from their clients.
So, our team has been working diligently to deliver features that our customers asked for. So, here is a quick list of the recent features and announcements. So, first of all, we are now generally available in the two regions in China, which make us the first global API Management provider to be able to be available in the country. And we’re also now GA’d in the U.S. government cloud. We also started previewing the integration with Azure App Insights, which is a very useful feature because if you currently use App Insights for your front end apps and our backend APIs now you can go to App Insights and do end-to-end request response tracing App Insights.
Not to mention that App Insights also give you a very rich surface to dig into the data and the telemetry, right? And it also comes with a real-time dashboard. So, this integration is very helpful and useful for monitoring and troubleshooting your APIs. And we also start to the previewing entity texts, which is a new feature that allows you to apply texts to APIs and operations so that you can better organized and present your APIs on the dev portal and it also improves searchability of your APIs both in the admin and the developer portal.
And versions and the revisions is another big rock feature that we delivered. Basically, it helps you to properly manage the lifecycle of your APIs. So, revisions is used if you when you want to make changes to APIs in a private way, in private and a safe way, right, and only publish the changes when you’re ready, right? And versions are used when you want to make a breaking change to your API, right? So, you can just create a new version and it’s up to the app developers to decide when they’re ready to switch to the new version. And we also GA’d the capacity metric. So, now you can use Azure monitor auto scale to monitor to capacity of your API Management instance, and automatically scale your instance based on the value of that metric. And finally, Azure Key Vault integration is also GA’d now, so you can use that to pull certificates from Azure Key Vault instead of uploading your certificates manually into API management.
All right. So with that, I think I’ve spoke a lot, I’ve talked a lot. So, I think it’s time to see some demos. Okay, so I’m here within the Azure portal. This is the admin UI of my API Management instance. And as you can see, the capacity of my instance looks healthy. It’s just under 10% and there are constant traffic coming into my APIs. So, the first thing I want to do here is that I want to add another API to be published by this API Management instance, right? So to do that, I will go to the API view, if I go to the APIs here, so this is the interface where you can manage, create, and delete all your API facades.
So as you can see, already have some APIs added here. So, to add a new API, I have many options. I can either start from scratch, basically manually provide all the metadata of this API such as the backend and URL, all the operations path [inaudible 00:24:38] parameters and so forth or I can import an open API specification also known as Swagger file which already contains all the metadata. We also support WADL and WSDL if it’s a soap API and for your apps that’s currently hosted on Azure, we have an experience to enable you to import those apps just within a few clicks, like Logic Apps, API apps, or function apps.
So the API I want to add here is called the conference API. It’s a very simple API that returns some data about the conference such as integrated, right? And for this API, I already have a Swagger file, which already contains all the metadata for it, right, such as the backend URL, all the operations and so forth. So let me just copy the link of this file and come back to my API view. So let me import this Open API spec by clicking this button and paste in the value here. So, to our post for that file, and it reads all the metadata of this API. And let’s give it an API URL suffix, which will be used as part of the public URL once it’s exposed through our API gateway. Let’s change the name from demo conference API to the Integrate conference API that’s added to a product so we can use it. Okay, great.
I hope Wi-Fi is working. Okay, great. So, now my API has been imported, right? As you can see, I have many operations under this API, such as get sessions, topics, speakers, and so forth. So, now let me change my hat. Let’s say I am a mobile app developer who needs to build a mobile app for this integrated conference, right? So as a mobile developer who wants to use this API, I will go to the developer portal to learn and onboard to this API, right? So, this is our default developer portal for this API Management instance. It is based on a content management system. So, you can fully customize the look and view of the developer portal.
So just to prove that here is an example of one of our customer’s developer portal. As you can see, they have really done a good job to customize it. And if we go to the API documents, just to prove this is our portal, right? As you can see the also…there’s some customization here as well. So let’s switch back to our developer portal. So as a developer, once I come here I can register. In this case, I’ve already registered, right? And after that, I can go to the APIs view to see all the APIs published by this API publisher, right?
And here, you can see that the Integrate conference API is already added here. So, if I click on that, this will bring me to the documentation of this API. And as you can see for each operation that has an individual documentation, it is fully automatically generated based on the metadata we have for this API. And as you can see, it has backend URL request parameters required, required headers, body sample, and so forth. And in the bottom, we also have code samples in eight different languages. So, developers can just copy and paste and start using our API right?
And if a developer wants to try our API, we also have a “Try It” function here. So let’s say I want to try the KF sessions operation. So if I click on the try it button here, it will bring me to the, you know, the developer console where I can make API calls directly from this page without writing any code, right? So let’s say, I’ll just use all the default values and make a call to this operation. Here I immediately get a response from this operation, right? It’s all great.
But if you have noticed, if you look at here in the response, there is a header called X-AspNet-Version, right? So this is a header that’s returned from my backend, right? So let’s say I don’t want to, you know, include this header in the response because I don’t want to disclose my backend, you know, stack to this app developers because this is irrelevant, right? So let’s say I want to remove this header. So I have two options. I can either go back to the codebase off my backend, change the code and redeploy right? Or I can do it API Management with a policy within a few seconds, right? Obviously, I’m going to go with the second option.
So let me show you how to do that. So I’m going to switch back to the admin portal to add a policy. So on the right-hand side of here, what you see is the request response processing flow. Basically, a request comes in to API Management gateway, right? And then in the inbound section, you can apply policies to change this request before we send it to the backend. And then once we receive the response from the backend, we can add and apply more policies in the outbound section to change the response before we forwarded it back to the original caller right?
So, in this case, we are changing the response, so we’ll be adding a policy in the outbound section. So let me click on the pencil here, so let me do set header, okay. Actually, I haven’t copied the header name yet, so let me copy the header name. Okay, and let’s say I want to delete it. Sorry, I think…Okay, let me delete it. Okay. So now this policy has to be added. So let’s actually go to the policy editor. This is the code view of our policy documents. So let’s just show you what actually happened after I…you know, after I saved the change from a UI. So basically, as you can see, in the policy document, we have inbound backend and outbound sections. And inbound at in the inbound section, basically, has chopped in a policy called set header, right? It basically says, “Okay. Please delete the header with this name.” Right? Okay, now it’s save it. And if I switch back to the developer portal, let me try to make another call, to make another call to this operation.
And now you can see that header has been removed, right? Just within a few seconds using a policy API gateway, I can do that without changing anything on the backend, okay? So next, what I want to do is I want to add some protection to my API. Let’s say my backend is not very scalable, right? If you know, someone has a bug in their application, it might call my API, you know, thousands of times a second, and might potentially bring down my backend and impact all my users, right? So I want to add a throttling policy in my API gateway.
So let’s switch back to the admin portal. So, in this case, we will add a policy in the inbound section. Let’s just use the code editor in the inbound section. What I’m doing here, let me go…and…let me add a policy called limit, rate limit by key. I’ll explain it in a minute. Okay, so what I’m doing here is that, I’m saying okay, for every subscription ID, so basically for anyone, everyone who subscribed to this API, I only want to allow 3 calls every 20 seconds, right? And anything more than that will be rejected. So let’s save this policy. Okay, let me switch back to my developer portal. So now if I try to make some more calls, right, so the first call, should be throttled. Let’s see if that works. That’s one, two, three, and four. So the fourth call is throttled and it says, okay, response code is 429, too many requests. And it also tells me that rate limit is exceeded, please try again in 16 seconds, right? This is how easy you can add throttling to APIs using policies in API Management.
So next, what I want to do is that I want to enable caching for my APIs because the conference API is a perfect example for caching, right, because most of the operations here are get operations and the content that the responses rarely change right? So to enable cache, it’s also super easy. Let’s just switch back to the admin portal here. And we go to the inbound section, we have a tab here called caching. And all I need to do is click enable caching. And we have some options here. But let’s just keep it simple and click Save.
So now the cache policy has been enabled as well. Let’s try it out. So in fact, we also have a test console here embedded in the admin console. It’s just like the test console on the developer portal. So let’s try it from here in the admin portal. So get sessions using all the default values. And let me try to call it. So we’ve got the response, right, but how do I know if cache is applied or not? Right? So which brings us to the next feature, which is the trace feature. So basically, this tab it gives you a detailed trace of what happened to this request. Basically, it includes all the details such as, what’s the original requests we received from the client? And what policies are applied to this requires or response and the elapsed time at every single step, right?
So if we searched for cache here, okay, not here. So, in the trace we see, okay, cache lookup policy has been applied and cache lookup resulted in a miss right? This is totally expected because this is the first call after we enabled the cache. But if we make another call, right, then the cache flow capture the result in a hit, right? Let’s make another call. Okay, so this is the second call which should read the value from the cache instead of forwarding a call to the backend. So if we go to the trace view again and if I search for cache, as you can see this time it says cache lookup resulted in a hit, right, because this is the second call, so it just retrieved the value from the cache instead of calling the backend.
Okay, cool. So the next thing I want to do is that I want to add a new operation to this API, right? And we all know that adding a new operation is not a breaking change. So I don’t have to create a new version to this API. But if you have been using our product, you probably know that previously, when you are making a change to an API, as soon as you click Save, right, this change will be published to the developers. But let’s say, I want to make this change, you know, in a safe way, I only want to publish it when everything looks good, when everything is tested out, right?
So to do that, I can create a new revision for my API. It’s super easy to create a new revision. I can either click on the three dots here and say add revision or I can just go to the revisions tab here. And as you can see, currently, I only have one revision and there is API and it is the current revision, right? Let me add another revision, add a new operation, create. Okay, so now I have two revisions for this API, revision one and a two. And the revision one is the current revision that the developers see. And the revision two is only private to me as the admin for this API Management instance, right?
So let’s go back to the design view, and I’m going to add a new operation. And let’s say the new operation is called get top speakers, let’s say this new operation will return the top speakers based on the ratings of this conference, right? Okay, the URL will be get top speaker. Okay. And I’m also going to provide a sample response for this operation, which will be useful later. So as part of this demo, I’m also going to show you another new feature called response marking.
So basically, we all know that the life cycle of the API is that the backend developer needs to finish coding the API first before the front end developer can start using this API, right? But with this feature, with the response marking feature, you can quickly…we can quickly create and mark an API on operation that returns marked responses to immediately unblock the frontend developers and allow the frontend and backend developers to work simultaneously, right?
So I’m going to provide a sample response for this operation, it will be 200, okay, and the content type will be application slash JSON and I’m just zoomed that and see. Okay, so here’s a sample of the response to say, the name of the top speaker is Miao Jiang shamelessly. Okay, great. All right, so now this operation is created, the next step we need to do is to enable marking, right? Let’s go to the operation and go to the inbound section. There is a marking tab here and let’s say I want to enable static response and I want to use the sample response that I just created safe, right?
So, now marking is enabled. I also have a banner here to inform me that this operation uses marking. So if I go to test here, make a call, and I got the response, right, which is the response I provided. So now I can immediately unblock the mobile developers, the app frontend developers who wants…who need to use this operation, right? Okay, so next, let’s say I want to…for some reason, I want to create a new version for this API. Let’s say because I want to, you know, delete an operation, right? So delete an operation is a breaking change to this API, because you know, whoever is whoever’s already using this operation will be impacted, right?
So creating a new version is very similar to creating a new revision. So, let’s just click on the add version here and we support three different version schemes. You can have the version number either in the path, in the header, or in the query string. And, let’s just keep it simple. Let’s keep it in the path. And let’s say the new version is called v2. Actually, before we do that, there’s one thing we need to do. So we have added this new operation and everything tested out, right? But we haven’t published it, right?
Just to prove that if we go back here and refresh the page, the new operation is not there, because revision two has not been published yet. So let’s come back here, go to revisions and make this current. I can also provide a change log to, to inform the developers of the change, did a new operation, save. Okay, so now if I switch back and refresh it, the new operation is there, right? So this is how you can, you know, publish changes to your APIs, you know, only when you’re ready. Okay, so now let’s go back to add a version for this API because we need to, you know, delete an operation right? So add a version and the newer version is called v2.
And let’s add it the product, create. Okay, so now under the Integrate conference API, you can see there are two versions. There’s the original version and the v2, right? So currently, they are exactly the same, because v2 is just a replica of the original version, right? Let’s just make sure we go to v2. So, in original version, the operation is still there. So if you go to v2, let’s say I want to delete this operation. Let’s say I want to delete this operation we just added right, because people get jealous that Miao is the best speaker, right? So we’ll delete it, okay.
So, now if we go back to original version, you can see the operation is still there. But in the v2, the operation is gone. So just to make sure that’s the case, if we go back to the API page, you can see that on the developer portal under the Integrate conference API, it also says it has two versions, right? So, if we go to the original version, that operation is still there, right? So for the existing apps, they will not be impacted. And if we go to v2, that operation is gone, right? So, it’s up to the mobile app developer to decide when they are ready to switch to the new version. All right, so I have a few minutes left.
So the next thing I want to show you is the integration with Application Insights. As I mentioned, it’s very useful for debugging and monitoring your APIs, right? So let me quickly switch to the my Application Insights instance. So this is my AI instance, which is already connected with my API Management instance. So my API Management instance has been sending telemetry data to this AI instance. So there are a few things that I think are really useful in App Insights. The first thing is that there is an application map here, which gives you a quick overview and a quick understanding of, you know, if your APIs are healthy or not, right?
So you can see that currently there were 29.6% of the incoming API calls are failing, right, in my API Management instance. If I click on that, I can get more details about actually which operations are failing, right? Like my conference API session is failing for some reason. And then if I go to the failures menu, I can get more details about those exceptions. I can zoom in to a different time and see, you know, what’s operations are failing at this time window and so forth. And another very, very useful feature here is they have a live metric stream, which always takes 10 seconds to start up.
Okay, so if I go back to the developer portal, so let’s say we make more calls to this operation and go back to the App Insights. You can see that it shows API calls coming in real in real time, including the request rates, durations, and failure rates, right? It’s very useful. And another very useful thing is the metrics explorer, which allows you to explore the metrics that we have in App Insights. For example, you see that I currently have two charts that’s created based on some of the telemetry. I’m just basically looking at the number of requests versus the number of failed requests, right? I can also future these charts. For example, I can see, I can choose to only see one API, right, and things like that. So this is very useful for you to play with your metrics.
And the last thing I want to show you is that App Insights, they also have a very powerful query engine, right, for you to query the telemetry in the logs that was sent to App Insights. So let’s say you know, in the middle of the day, you get a call from a customer saying, “Hey, you know, I’m getting…I’ve been getting errors from this API. What’s going on,” right? So, you can come to App Insights to troubleshoot your API. So let’s go to the overview page. And let’s go to the analytics. Okay, so this brings me to the query interface for App Insights. So let’s say we want to query all the requests in the past 24 hours with a result code not equal to 200. Basically filled request, right? Run.
Okay, it gives me a bunch of things, right? And let’s say okay, so the first one is actually the one my customer has been complaining about, right? So let me see. Okay, what’s going on? Okay, so I see it gets 4-1, but I don’t really know what’s the exception, right? But so what I can do is let me copy the operation ID of this request and then let me search for the exception telemetry. So I’m going to search for all the exceptions where operation ID equals to the one I just copied. Okay, so I see one exception for this request, right? Let’s see what’s going on here. Okay. Okay, so if there’s an exception and said, oh, access denied due to invalid subscription key, right? So now I immediately know what’s going on. And I can call my customers. Hey, it’s not my issue. It’s your problem, right? Cool, so, that wraps up my demo.
You’ve seen some things that we shipped recently. But we just scratched the surface today. There are a lot more in the products that I haven’t had a chance to show you. For example, I said, I mentioned that we have 40 policies for different things, right? We also support Soap API, now. We can also help you to Soap, to…I’m sorry to convert your soap APIs to a RESTful API to give kind of…to give new life to existing API, right? And we also have sophisticated [inaudible 00:45:58] support for external and internal use cases. Like I mentioned tomorrow, we will talk more about it at the last session. And also, if you need to create a custom dashboard for your APIs, right, we also have a Power BI template to get you started, right, which is fully customizable to build your own dashboard. And tomorrow, we’ll also talk more about our integration with Azure AD and Azure AD B2C for different scenarios.
And with that, I want to close my, end my talk with this slide with a bunch of useful links. So if you have any questions, please go to aka.ms/apimso, which stands for Stack Overflow. And we also have a blog which we actively post to, post our service updates and among other things. And if you’re looking for examples of, you know, policies, we have a GitHub repo with a bunch of sample policies for common scenarios. And if you have a feature request, please go to aka.ms/apiwish to submit your feature requests. We also have a public roadmap. And if you’re looking for customer stories, we have them at API and customers here, right? Thank you.
Fill the form below to get all the presentations delivered as a single zip file in your mailbox.
byJon Fancey & Matt Farmer
byMicrosoft Integration Team
Back to Top