MCPA - Level 1: MuleSoft Certified Platform Architect - Level 1 Certification Video Training Course

MCPA - Level 1: MuleSoft Certified Platform Architect - Level 1 certification video training course by prepaway along with practice test questions and answers, study guide and exam dumps provides the ultimate training package to help you pass.

Non-Functional Requirements of APIs

5. Managing APIs

Hi. In this lecture, let us discuss any point API manager, what features it provides, and how we can manage our APIs using it. Any point API Manager is a platform component that offers the following features: The first one is that it helps us manage all the APIs that are hosted on the endpoint platform. What kinds of APIs can we manage? So these APIs can be Mule Soft-implemented logic that is deployed and hosted on the Mules of Runtime Manager. Okay, those AP implementations can be managed in the AP Manager. Or these AP implementations can be completely external as well. meaning those are non-must-related AP implementations, okay? Say, for example, some net API or some Java API. Still, if it is meeting the Ramble specification, some Swagger, or any open API spec, even those kinds of external API implementations can be managed in the API Manager.

So if you have gone through the previous exercise assignment and have gone through the solution, we have even provided this as one of the reasons why we would go with the APA proxy where we want to enforce the policies instead of the embedded mules up front time. Right? So we would go with the APA proxy in these scenarios where there are external API implementations that we need to manage. Okay, so the management API is any type of API provided by the input API manager. Then what else can we do? So, we can also configure these particular APIs once we host them. So what do we mean by "host�? So either it is implemented via API or it is an external one.

We can actually create some API instances on the API Manager to go and do some work on them or to configure Tweak. Whatever we need to do in order to manage it, it has to be physically created as an asset, right? I'm not talking about any point-exchange asset, but an instance of an API in the API Manager. So we can create them by configuring the API Manager. And then we can do various things, like apply policies to those particular APIs, set various security levels or rate limits, etc. like we have discussed so far. As a result, AP Manager also enables us to configure these AP instances by applying policies and so on. It also allows us to create custom policies in addition to using the out-of-the-box policies that come with the platform.

Check to see if we have any organization-level policies that aren't coming out of the Museum platform. The reason for this is that they may not be general; they may be specific to our organisation or a more complex policy. Then we can very well go and create it as a custom policy, and we can implement or enforce it on our API instance in the API Manager. Okay, so this is also one way the AP Manager helps. Then, as we discussed in the previous video, one more thing: APA Manager also acts as the repository for the APA definitions.

Okay? So we know that, of course, APA templates are hosted on the APA Manager. That is where users will have to select the particular APA template and enforce it on an APA card. But once we enforce, what do we mean? We fill in the parameters, saying, "Okay, for this API policy template, I want to configure it as, say, 100 requests per second." Then it becomes an API definition.

So those API definitions for that particular API instance, on which we have enforced the policy, are also stored on the API Manager only. So, as we discussed in the previous lecture, it acts as a source of repois. If you recall, when a request hits from the API client to the API endpoint, the runtime will actually first go and try to download all those API definitions, correct? So it actually downloads only from the APA Manager only.

So it downloads those API definitions and then enforces them at runtime. Okay, so it acts as the repo for the APA definitions. Then there's AP manager. One more way it helps is to set some alerts on the APS. There can be various types of alerts. We can say that the response count is more than enough. The API count, not the response count If the API count is greater than, say, 100 within five minutes or within an hour, okay, then alert these people. Or if the response times are greater than 500, then alert these people.

So, for API, we can configure a variety of alerts in the API Manager at the APA instance level. Okay, then what else? So, another administration feature that any point APA Manager supports is managing all API clients. So remember, we discussed APA consumers. So for each APA consumer, when they register, they get client credentials. And going forward, using those API consumer-client credentials, they can request access to any number of APIs, right? So for all such APA consumers, they will be stored as contracts for each of the AP incidents. So we can manage those contracts as well, meaning we can revoke the access or we can refresh the client credentials for a particular consumer.

So all the administration for the consumers can also be done by the APA Manager. Okay? So these are all different features that are supported by API Manager in order to ensure that all things related to the life cycle of an API can be monitored and configured from a single place. So a few more features are also supported in the AP manager, but for Ramble based on the Rest APIs. Not applicable to SOAP or other types of APIs is the fact that API Manager supports applying these policies not only at the API instance level but also at the resource level. Rest APIs can have multiple resources, right? If you take our Create Sales order example, in Create Sales order, initially we created a resource called Create, which is supposed to create an order in ERP, but later, for demonstration sake, we said we could have retrieved it, we could have updated it, and we could have deleted it as well.

So let's say we have four such resources and we want to enforce the policies only on create and retrieve but not on update and delete. Okay? Then, for these Rest APIs, EPA Manager allows the policies and resource level to be applied. So these are the different features. We will be seeing a short demo as well to see where all these features can be implemented in the API manager. We won't go into detail on each of these because there will be more in-depth lectures coming up where we will focus on each of these features and do a separate demonstration for each of the specific functionality. So in the next demo, we will just set the level to high. Okay? We won't deep dive into all these features in a single lengthy video. OK, happy learning.

6. Demo: API Manager

Hi. Let us see a short demo on the API manager capabilities that we have discussed in the previous lecture. So again, we are on the landing page of the Any Point platform. And we can go to the API Manager like any other component, right from the landing page. Or we can go to the API Manager from the left-side navigation bar.

So let's go to the API API manager. So what you can see here is the API Manager page. And let us start discussing each of the capabilities we discussed in the previous lecture. The first is that we can manage APIs, whether they are MuleSoft-implemented or externally implemented. So how can we do that? So already, you may have a little idea. as we have seen a short demonstration in one of the demos before in the course. But I'm going to show you again. So once we are on the API Manager, we can go to Manage API and choose one of the options to import the API to create an API instance. So, what are the options? One way is to choose from the Any Point Exchange. Okay? So if the API is designed in the Design Center and published to the Exchange, we can choose it from the Exchange itself.

So, one thing I'd like you to understand is that we don't need to develop the Ramels and everything else in the Design Center for Mule Soft-implemented applications, okay? Even for an external application that is not NewLesoft API, even if it is implemented, say, in Java or Net and meets the RAML specification, we can still bring that RAML and import it into the Design Center or create it in the Design Center, and we can publish to the Exchange from there. So, in our Design Center database, we have a kind of registry of these rambles and specs, right? So we can still do that for an external API as well, not just for the mule-implemented API, and export and publish to Exchange, okay? So now we can go to Manage APA from Exchange and click, and then select the AP. For example, if I selected the same math, it would start showing the math APA.

So similarly, if we select the sales order, it should also bring up the sales order APA that we have published, all right? And then it will automatically bring in the details, saying, "Okay, what type of asset is it, what version was the most recent, and all that." So this is the way we can create the AP instances for Exchange. The second is that we can build an API from scratch. meaning we can click on "create a new API." We can give in an API name and select the type of API: is it a Soap, Open-air spec, or RAML-based? And we will allow us to choose the RAML file. Okay? If it is not on the Design Center but already exists as a RAML file or RAML project, then we can choose it. As you know, we can have a RAML definition, a bulkier version, everything embedded in a single RAML file, schemas, examples, trials, everything that is in a bulky big RAML file, a single file that can be chosen.

Or it could be an API spec project where the actual grammar of the API is a smaller one, as we did with the Create sales order. And there might be multiple other small RAML files. One for the request response, some for the examples, and some for traits. So this all together makes the API project a full RAML file. Correct. So we must decide whether to use the zip with multiple RAM files or a single RAML file. If we select a zip file having multiple RAML files with smaller schemas, for example, Rambles and write Rammers, then we have to mention which is the main file, meaning the top file, which is like a root, right? So we have to select that and continue. This will also create the API, and the third one is importing it. Okay? So if you think that your API project is as per the MuleSoft spec, then you can very well go straight ahead and import that project into the APA Manager right from the import section. Okay, just ask us to choose the zip code project, which is a Ramel project. And you can just say "select it" and it will import it.

So if you're unaware or if you want to know what kind of project that is, then you can do a small experiment yourself. You can go to the Design Center and open one of the Ramble specs that we have created, either the Major or the Salesforce one, because we have recently done this. Once we open this, then we can go to the options here and say "download project." Okay? Then what happens is that this will download the zip file with all the dependencies included, meaning the root RAML file, including all the dependent RAML files that are required to finish this RAML. This whole thing is downloaded as a zip file. So that is the zip file from which APIManager is expected to be imported at some point in the third option. All from which Now you know how to manage the APS by importing the API or creating the APA instances in the API Manager, both for mules and non mule. Because while creating here, there is no difference.

Even the AP manager doesn't care whether it's a mule or not, right? So we can just do that. There is an option to say whether it's amule or nonule, but we'll see that in the next demonstration, which is the enforcement of APA policies. Now, remember that the second capability we discussed was the configuration of APA policies on APA instances? So how can we do that? Let's take the existing API instance, which is the math s on the So what we can do is choose an API instance, and once we open the particular API instance after creating it for the first time, we will be given multiple options. Okay? So this is the navigation place where we can go and implement or configure the APIs. So how do you do that? So we can click on, say, "apply new policy." Then it will bring up a lot of API policy templates.

Okay? I'm hoping you understood the terminology before. That's why I'm stressing and mentioning APA policy es. Okay? I'm hoSo these are all the templates that are provided by the platform and the API Manager. As a result, it will provide us with the templates. So let's say I want to use the same example we have been using. Let's call it rate limiting. I want to implement rate-limiting on this particular policy. I selected the template. Now I say "configure the policy" the moment I do that. Remember the parameters and everything we talked about? The template will be created with parameterization. So these are the three parameters that are now being asked to fill in.So I will give the same example: 100 requests per second.

So in a second, I want to limit APA calls to 100 requests only. And I can give you this information. And one more capability, APA Manager LLC, is that we can choose whether we want to apply this whole policy, an entire API instance, depending on the number of resources that are inside the API. Alternatively, we can cherry-pick and say, "I only want to implement this on specific resources." Okay? That can mean I want to apply all the get, all the get and post, or any combination of the two. You can also say "get." Also, I want to match the Trust resource URL to something like a Flash order start, meaning any resource starting with the order. Okay? If you want to return only one resource, then you can give the full path without any regular exception like a star, a dot, or anything. Then it will only apply to that one. Yeah.

So this is how we apply the policy to the API. So you can add any number. So let me apply it to the full API now; let's do that. Once it is done, I can go and say, "Aside from this, I also want to implement, say, IP whitelisting." This is the template I chose. I say "configure policy." It asks me to give the IP expressions, okay? So when I say expression, it's because the code has to know where to refer for the IP address to come in, right? So it may come in the HTTP header or somewhere. So we have to give that inbound property. The property is the same as it was in the mule implementation. The payload expression can be referred to using the same pattern. So message domain properties of whatever IP address or hard IP address or something And then the list of comma-separated IP addresses or ranges that we want to whitelist All right? So we can continue to provide such policies and configure them via the API.

Okay? Now, the third one is the configurationof the custom policies as well. Okay, so what are the custom policies? The customer policies are the ones that are not in the given list of API templates. But we want to enforce some additional rules, which may be organization-specific. For that purpose, we can first create some custom policies from the main API manager navigation, where we can go and configure the custom policies. This will be covered in greater detail in a separate lecture on customs policies.

We have a lecture coming up, and we will talk about it in that lecture. Okay, but this is the place we can add custom policies. Once we add them, we can then start applying them to the individual API instances, just like we did with the other templates. All right, the next one is the downloading of the API policies at runtime. Remember that the API manager also serves as an arbiter of API definitions, so that when the API client reaches the actual endpoint of the API implementation, these policy definitions are downloaded and enforced. At that point in time, we said that the AP implementation itself does not store the policy data. It will just use the metadata, and it will download untimed.

So, where does it originate? Remember, once we chose the policy template and filled in the parameters and applied it, this has become the definition, because if you see the details now, it says, "Okay, this policy definition is having 100 requests per 1 second." Now, this has become a definition. So this definition is stored against this API, the API manager. So in the runtime, when the request comes to the end point, this definition is downloaded from here and then enforced on the API implementation before hitting the code. Implementation code.

Alerts are the next feature capability. Okay? We can actually go to the individual APIs and set some alerts, like, say, if I want to add an alert for a request count breach. Okay, so what I can say is that this is just an informational or warning message. I'd like to issue a cautionary note. And whenever the request count is greater than $100 for at least two consecutive periods of, say, 3 hours, Okay, so 3 hours. Then. What happens is that whenever the count reaches 102 in 3 hours, the alert is sent to, say, specific recipients I can specify. And these users are from the access management of the platform, which we have seen before. Right? So I can choose any number of users saying, "Okay," "Finance," or whoever belongs to the user. and I can see great alert.

The moment we create an alert, it will create the alert, and whenever these conditions meet, alerts will start coming. Similarly, we can add more, including a critical one that says whenever policies are violated, some of which we enforced, or response times exceed 500 milliseconds and the occurrences exceed five for at least one consecutive period. We can also call it a policy violation because we have only one policy to enforce, namely rate limiting. It is displaying that otherwise it will display multiple. Okay, we can choose that and say the same thing:

how many items were violated, if you got a 500 response code, a 400 response code, anything. Okay? Anything. With the AP, we can set alert funds and receive alerts to the email addresses in the esponse code, a 40The following capability is about client administration. So, as we discussed in previous terminology, API, consumer, and so on, in order to hit the API or access the API, one must first request access to that API. And then, after requesting access, they will be presented with the current credentials for that consumer. And using those current credentials, one has to hit the API. So, as you can see, we currently have two consumers, finance and sales, who have some client credentials and have registered to access this specific API.

Okay? So what we can do in this case is administer the APA to all such consumers who are registered for this APA."Okay, we can revoke the access for the specific consumer," or "we can actually refresh their tokens," if they are notable to work with the particular concurrence they already have. So all these kinds of things can be administered. So, for example, the one we saw before is the API level contract, meaning that for this math API, who are all the consumers who have requested access currently? So this is the latest version, revision, or version I created. So it doesn't have consumers. This is the old one from the last time you requested access. So currently, these two are the consumers. These two lobes are the consumers who requested access to this math API. Okay, so I can now suddenly decide, "No, I want to revoke access for this finance, or I want to rework access for this sale, and I'll be your consumer." So this is what we can do at the APA level for this particular API.

But in general, if you want to manage or administer the clients as an organizational platform administrator, it will just appear agnostic to the APS. To the APS, I am agnostic. It displays all consumers who have registered for any EPS and number of APS. Okay, for the time being, because they only registered for one AP, it shows math APA, but the same finance tomorrow registered for math, app to sales orders, and so on. to show all of them.

So all we can say now is that we can open this specific consumer and, as an administrator, share these credentials and everything within and see how we can add more owners to this today. Say only one person is the owner of this. So tomorrow there are multiple members in the lobby who want to go on honor. We can add all those honors, and this kind of administration can be done for APA consumers under contracts.

Then the last one is the analytics part. Okay, even here, the platform APA Manager provides analytics at an APA level, where if we go to an individual APA instance, we will have the analytics section here for that particular API, which opens a dashboard customized for that particular API to see what the requests are and all.

Like I said before, because this is a trial version, I'm able to show the analytics, but, you know, the dashboard and all would come out like the same thing: a number of requests are coming in a given time frame. If you include policy violations, the response codes we received show how many policy violations occurred in a given time range, and so on. Okay, this is the APS level; the same feature is available in general for all APS at the homepage level, where clicking on analytics will take you to a similar page but for all APS. So if you see the previous one, it's also on the same page, which looks like this.

All APS or Math Applications You can choose from this list. All right, so these are the various features of the API Manager in order to create AI instances and then configure policies on them, and then add even custom policies, and also define alerts, all on a particular API or multiple APIs. Then there's client or consumer administration, and then there's visual analytics to see how your APIs are performing or working. All right, so let us now move onto the next demonstration, where we will see API enforcement in detail, proxy-based enforcement of API policies, and the embedded basic endpoint-based enforcement of the API policies. All right, see you in the next demo. Happy learning.

7. Demo: Enforcement of API Policies

Hi. From now on, you need to roll up your sleeves because the next couple of demonstrations are going to be a bit lengthy, okay? But don't worry, they're lengthy because they are going to be more elaborative, and we'll deep dive into much more details to understand Any Point API Manager and the enforcement of the policies a bit better. Okay? So without wasting any time, let's move on to this current demonstration, which is about the enforcement of the API policies on our Create Sales order. Okay? So before we go into the APA Manager, in order to enforce the API policies or even to manage the APIs, we need to have the API implementation first, which we do not have as of now for our Create Sales order.

So what I'm going to quickly demonstrate now is how to create a simple AP implementation for our Create Sales order, okay? Then, once we have the implementation, we will deploy it to our Any Point Runtime Manager on the cloud hub so that it is deployed onto the cloud hub. Okay? Manager will then host API implementation at any point in time. We will try to add it as an API to the API Manager. Just to clarify one thing here, it is not necessary that the APA implementation must be deployed before the creation of the API instance on the API Manager, okay? You can right away go to the APA Manager and create the APA instance. like you saw in the previous lecture. In the API Manager, we can choose to import from the AnyPoint Exchange and create an APE instance. But the only thing is, once we create it, we cannot move further in the demonstration to show some concepts like the enforcement of the policies that are working or to show that the APA is active or not.

Okay? Because without AP implementation, we can create the APA instance, but it will be in an unregistered state. So it's like an inactive state. But what I wanted to demonstrate were live ones, so that it would be a more real-time scenario or closer to the real-time scenario. Okay? So let's go into the implementation part. It will be very quick. Okay, so what you're seeing is an Eppoint studio. By the way, I'm using the Mule 3-9x version throughout this course. So this is an Any Point Studio, which is a six-x rsion. So thiNot seven or mule four, but six six. Okay? Because the platform architecture concepts are independent of the Mule Run Time version, I haven't mentioned what version of Anybound Studio or Mule Run Time I'm using so far in the course. However, all concepts are recognised for the runtime. Okay, I am going to create a new project now, a new Mule project, and I'm going to name it EXP Sales Order API, so that this naming convention clearly depicts that it is an experience layer API and my API sales order. And it's an API type, obviously. And I'm going to select "add API components," and I will choose the Ramel project, which I downloaded from the Design Center.

So, like I have shown in the previous lecture, we can go to the Design Center, and from the top right, we can click on the gearicon and download our entire Design Center project. So I'm going to choose that project, and I'll proceed with the creation of the project and click on Finish. So this will create the template for the My Experience API Mule project template.Okay, so if you see the MuleSoft, any point studio has already made my project with the API kick router and all the resources that are in the RAML, which are obviously the retrieve and the create, ready to go. Okay? And if you look at the RAML specification assets, you'll notice that this is an exact replica of what we have on the Any Point Design Center because we imported it from there, which was created exactly the same way. Okay, so I'm not going to make this any more difficult than it needs to be. I will just simply show you what is currently set as a payload, which is our sample response. Right. This is the response that we have given as an example in our Design Center card. So already, the API kit has created a me resource with a set payload as this response.

So I'm going to leave it the same so that when I hit this API after deploying, I'll get the response back, which is the same one every time. But I'm happy with it and will proceed with the demonstration. Okay, so I have a project ready now that can be deployed and even tested. But the only thing is, whenever I test, I will get back the same API response for the create resource. Okay, so let me export this particular Yeah, so one more thing I wanted to do before exporting this is to make it discoverable from the APA Manager. That is, when I say discoverable, I mean that we need to add an auto discovery to make this on time or an APA implementation discoverable or manageable by the APA manager. This means that there is an option in the global Mule configuration elements where if you create a new configuration and select API auto discovery, it will ask us to provide the API name and version.

So you will soon see. What are these API name inversions? Basically, these are things that we get from the API instance that is created on the API Manager. And we can just give in a substitution or parameters here and temporarily save it and get it deployed. Then you can substitute those parameters at runtime through runtime properties. Okay, so this is required in order to make this API managed by the API Manager. Even if you don't have this, it doesn't mean the application cannot run. It can still run. It can still be hit by the postman. It will work, but it directly goes to the API runtime manager. By skipping the API manager, it can't go through via the API manager. which means indirectly that it cannot be managed via the API manager.

Okay. It is like a direct hit to the runtime manager. So what we are going to do is have variable substitutions here by saying APA dollar name dollar API version. And we will choose the flow name as the main. Okay? So I've got my auto-discovery, which I'm going to call the main flow. And I will also have these temporary substitutions here so that we don't have time errors during deployment. So, for the time being, I'll say that API name equals API name and API version. the same as the API version There is a small version of yeah. So I have also given these temporary substitutions so that for my API discovery during deployment time, I won't get any unexpected errors. Okay? Okay, AP name, APD version. Now this project is good enough to export and get deployed on the runtime manager. Let me export this now. So I'll export it as a deployable archive. I will export it to my desktop for my convenience. SEC done. That finish. Okay, so we have the deployable artifact. Let us now proceed to the any point platform to finish the rest of the part. Let's go to the runtime manager to deploy our EXP Sales Order API. Okay, here we are.

So I'll be in the sandbox environment, and I'm only going to say "deploy application." I'll give the name of the application as well as the name of my project, which is EXP Sales Order API. It met all the requirements. Then I will just upload my application file, which is on my desktop. ame of theEXP sales order API And do I have to give any runtime properties? Yes. Obviously, I would have to give some runtime properties, which are the API name and API version. I do not have them at the moment. So what I'll try is to just go ahead and deploy. Okay. Let's see what happens. Okay. Deploy the application. Let's monitor the logs and see what is going to happen without the variable substitutions for the API name and API version. Okay, so as you can see now, the application is up and running. Okay. So there is no impact of the API name and the API dot version on the runtime properties. Still, the application is up and running. Like I said before, the auto discovery does not impact the actual API implementation logic. Okay? C is still loading. All of our resources are treated and posted, and they are all up and running.

Okay, it can still work. Now let us go to the API manager. Okay, now that we have our API implementation happily running on the runtime manager, let's go to the API manager to start managing this particular API. Okay, here we are. So now, as I told you before, there are many ways to do this. We can either import the API from the exchange because we already published that API definition as an asset to the API Exchange, or we can create it from scratch, which we are not going to do now because we already did some homework and there is a design centre that is already published, so there is no point in importing. It here. And that we will not select the third option because, yes, we do have the Ramel project that we downloaded from the Design Center to import into Neon Studio. But this is pointless, and we do not need to use this option. Okay? So let's go with the first option. And I'm going to look through our sales order API.

Okay? So here it is. I'm going to select it. The moment I select it, it will auto-populate all the details, including the API version and the set version, and all. So this is the interesting one, or the important one, if you are the managing type, right? So this is where you get a choice or an option to specify where the API policies will be enforced. Okay? So if you choose the Basic Endpoint, which means you want to enforce your API policies at the API endpoint, which is the embedded API implementation enforcement, Okay? So when you choose Basic Endpoint, basically, you are going to use the same Ul runtime on which your current API implementation is running to enforce your ans you want tSo this is the option that you select, and you go ahead and use the same runtime. If you use the endpoint with a proxy, then what happens is the second concept we discussed in the previous lectures, where a dedicated mule runtime will be created in front of the API implementation runtime.

The API implementation and its policies are proxied by a second runtime, dedicated runtime H. And first on this proxy during the second mule runtime. Okay, so we will see both of them. Let's first go with the simple one, which is BasicEndpoint, and we select it as a mule application, which is our hybrid cloud hub. So fine. Our application is not suitable for A. So I'm not going to select this. And I'll say "click save." Okay? So the moment I click Save, it will create the API instance for my API. All right? But if you see, it is currently unregistered, like I told you before. Okay? So you may think, but as I told you, it will be unreserted if there is no API implementation l say "click savBut now we have it running. So why is it still under registered? It should have been active, right? So there are some steps we need to take to ensure that that API implementation is running at runtime. Manager can determine that this is the API instance associated with that specific runtime. Okay, so how do I link it? This is the place where the API name and API version come into play.

Okay, so we have to give these API name and version details in the auto discovery, which we parameterize anyway, so that an application running at runtime can identify and discover that this is the AP instance that it has to use in order to get itself managed. Okay, so I'm going to copy this and have it on my notepad so that I can use it later in the same version as well. Okay, so now I'll go to the runtime again. Okay, so it is unregistered. Now I'll go to the mules' runtime. Here we are. So I'll launch this specific runtime project. I'll go manage the application. I'll say the properties and API name are the names of the APIs we copied from the API instance in the API manager, and the API version is the one we copied from there again. Okay, this one. So along with these two, there are a couple of other properties that we need to provide to properly make the auto-discovery work. Okay? Yes, these two are the main ones for the auto-discovery to work, but they are not sufficient. Okay, so for these two to again get associated, two more parameters are required, which are the any point platform client ID and any point platform client secret.

Okay? This is a way of authenticating where the runtime application authenticates itself to the AP manager, saying, "Hey, I am a genuine API implementation running on the runtime manager, so please allow me to manage myself." Okay, so where can we get it from the access management? We can get the Any Point Platform Client ID from the access management. Moreover, if any Platform Client Secret Okay, but for now, what I'm going to do is assume that I already have those in the Math API project because I've given them. I'll take the Any Point Platform client ID and the Any Point Platform client secret. So my Point Platform client ID is going to take that from here. In addition to my point about platform client secrets. Okay, so these two are already known to you. Don't be concerned about the analytics agent enabled trueand header or disabled defaults, as these two are used to enable APA analytics on the AP instance. So, even if it's true, as we discovered due to the tile version or something, it's not populated in the analytics. But let us still go ahead and add these two as well.

Okay, so let's see if the analytics start working. So we have all the properties ready. So let's go to our EXP sales order API and go to the runtime properties from there, and let's put all these details in: API name, API version, client ID, any Point Platform client secret, analytics agent enabled, and all. And I'm going to say, "Apply these changes so the Mule application will again try to restart." Let's go to the logs and monitor them one more time to see what will happen this time. Okay, as you can see, the application is now deployed, and you can also see that the API with this API name and version is now unblocked and available, implying that the API instance should be active now ideally, according to this log statement. Okay, so if you see this log saying it is now unblocked and is available, that means your API instance on the API Manager should be active. Okay, so your application has been started successfully, and your workers are up and running. Okay, it's green now. So let us go to the API manager. Here we are.

So, if you see that the sales order exec is currently active, Okay, so if I click on the version, it will take us inside. So it is active, which means it is ready to use. And if you see it, it is a basic endpoint, and the implementation URL is currently the marketing URL, which will later change to the actual runtime manager URL. Once we have DLB configured and any point VPC configured, that will always be a DLB URL. And if you see some things like the configuration details, this particular configuration detail represents that this is a direct client to your API implementation. Okay, so the terminology will be different, but don't get confused. This is identical to what we discussed in the previous lecture, where if it is a basic endpoint, i.e. embedded API implementation and policy enforcement, the client request is routed directly to the gateway, which is the API implementation, and the policies are enforced at the same run time. Okay, so this is the representation of how they're showing here your APS currently running on the API gateway, which will implement the policies configured in any.5 for APS. Okay, that means your same AP implementation will also implement the policies in the same runtime. Okay, so this is one way to go. Now let us do one more thing, okay? Let us go and create one more API instance for the exact same API, and this time select it as an end point with a proxy. OK, so let us do that.

Let us return to administration and select the import from Exchange. Okay? And I'm going to choose the same API again, because the API manager does not restrict us from selecting the same API multiple times. There is no rule that says we can manage only one instance of a particular API. We can have any number of instances. Okay, so I'll select end uponwith proxy, and I know it's another Cloudhouse application, not a hybrid or anything. It's not a mule for application or clicking on "Save." Okay, so here we are. So this is the second version of the same AP instance. So if you go back, Now, under this particular sales order experience AP, you can see that it says there are two instances, okay? If I expand, there is one instance that is active and running, which is an older one, and there is another instance, okay? But you can notice that the version and the API name may change. Okay? Maybe the name will be different, but the version will change, or both may change. It depends. So this is still an unregistered state because no application is running, right?

So that's where it's not registered. So, instead of the basic and point instance, we'll copy this new API name and version and point our runtime application to this proxy instance. Okay? So I would like to give some extra knowledge here, like how we have two instances of an API in the API manager for the same API. Actually, in the same way, we can have the same API implementation deployed twice on the runtime manager. So it is not necessary that we go to the existing API implementation that we have running on the runtime manager and repoint that implementation to this new endpoint with a proxy.

Okay? If you want, or if you want to not touch the existing AP implementations, if you want that, you can leave that as it is. Don't touch it. Let that particular application run and point to the old basic endpoint. We can deploy one more runtime application with a different project name. Okay? So we called it ASP Hyphen Sales Order Hyphenapa, didn't we? In the runtime manager, we can name it as expensive to the Hyphen API, for example, okay? And we can point this one to the CenterPoint proxy. Isn't it all about the requirement situation and what we have to do? So it's up to us; it all depends on the circumstances, when, and why we want to do what we want to do. So right now, I don't want to create a new application to point that one to this proxy and the other one to the basic end point.

I'll just go ahead and point the existing one to this particular one. Okay. So I can cover one more concept in a single demonstration. So I'm going to the runtime manager now. Here we are. So I'll just do what I always do and go to this project-management application, Settings, and Properties. So instead of this 1150 thing, I will replace it with the new one, which is 1176. Okay? The restaurant's name and version will change, but the client, Adicant Secret Novel, will remain the same. I'm going to apply the changes now, okay? And we will monitor the logs again. As you can see now, the project is deployed. It is green, and the worker is running in green now. And as you can see, our 1176 version has been unblocked and is now available. which means now this particular instance of the API should be green and active.

OK, so for 1176, let us go back and see that particular one in the API manager. So we've arrived at the API manager. And, as I can see, our 1176 is now operational. Okay? So don't be confused about why this 1150 is active. I believe the AP manager has implemented some caching. Because, for the next five or ten minutes, even if we repoint to another instance, say from 155-02-1176, this particular instance will be shown as active. Okay? I'm not sure if the newsoft platform uses UIpage level caching or background caching, but it will still show as active. But soon, in the next five or 10 minutes, you will see this become unregistered, okay? to take some time, like five to 10 minutes, and this will be the only one left active.

Okay? But if you go into this new instance right now, everything will be the same, except for the end point with a proxy, right? And yeah, if you go again to these view configuration details for this new instance, you will see that this time it is depicting the picture a bit differently. It is saying that, okay, when your request comes from the API client, it will hit the API gateway, where your proxy layer is. Okay? So there is another runtime running here as a proxy. From there, it will go to the APA implementation, which is your final endpoint. Okay? So your proxy is currently running on the APA gateway, not your direct implementation, which will implement the policies. So proxy is implemented in the APA policies here, and then, after enforcement of policies and all, it will go and hit the AP implementation.

It is a three-layer one; I mean, three hops. Okay, so layer one is only directly from the client to the implementation, and your policies are applied directly there? Yeah. So this is the difference between them. So now let's see if it is unregistered or not. Let me refresh it, maybe freshly, and see if it is final endpoint. OkIt will take some time, like I told you. Okay. So, before we wrap up this lecture, I wanted to point out that, as you may recall, I frequently tried to explain that this Mule proxy is also a separate component that runs on Mule runtime. So you have to do a pro-and-con analysis to decide when you'd like to go with this proxy. It will only work for non-Muel applications because they do not have their own runtimes.

Prepaway's MCPA - Level 1: MuleSoft Certified Platform Architect - Level 1 video training course for passing certification exams is the only solution which you need.