MCPA MuleSoft Certified Platform Architect Level 1 – Getting Production Ready Part 2

3. Promoting APIs to Higher Environments

Let us now see how to promote APIs and APA implementations to higher environments. We have already seen in the previous lecture using DevOps how we can deploy the APA implementations and API instances, policies, etc. Right? For AP implementations, we have the Mule Maven plugin support and any other third party tool support. Same way for the Mule API instances, APA policies or any other APA manager stuff. We can use the Any Point Platform API.

So apart from the DevOps style, any Point Platform also supports the promotion of the API Manager and APA runtime Manager assets from one environment to another manually as well. Okay, so promoting all the supported parts of the APA Manager, for example, policies, instances and the other SLS and all these, all can actually be promoted from one environment to other environment except the contracts. Okay, so what are contracts? You already know. Their API clients are consumers who request access on a particular API instance, correct? They won’t be promoted, reason being they are only per environment basis.

Okay? So once a API consumer comes and requests an access that is granted only per environment, please remember this this particular request access is per environment per AP instance only. Say the same API. If it is deployed to the other environment, then the APA consumer is required to go and again request the access. Okay? The same access will not be automatically promoted. So this means that the APA consumers must separately request access for their APA clients to APA instances in all and every individual environment.

Even if the same APA client credentials are there, it doesn’t matter. It should be separate one. So the client ID and secret a given APA client uses for accessing an API is however, independent of this environment. Meaning, say, if the same client decided, okay, I want access in a UAT environment again after promotion of the APA, and if the same client goes and requests the access in the UAT environment, then the client credentials won’t change, okay? They stay same. So using the same client credentials, the access will be granted and the API client can make the API invocations to both API endpoints, meaning Sandbox, for example, and UAT.

Okay? Generally this is not a typical usage. People don’t use like that because of the security reasons. So it would be typical for an API client in the Sandbox environment to access an API instance from the Sandbox environment and a separate API client in the production environment or any higher environment, even if the client is same. For example, if it is a HR lob, even if it is HR lobby only, it is better to have a consumer like HR underscore Sandbox and HR underscore UAT or HR for prod to just keep it safer to not share the client credentials.

In this case, there will be separate set of API client credentials that are generated for each consumer that is created. And it would use distant client ID secret pairs. Okay? So this is preferable for governance reasons so that you don’t confuse people, okay? Because same client ID where the request is being reserved from, is it from Sandbox? Is it for production? So for governance and security purposes, better to use a separate consumer in each environment.

So after the promotion of an API instance in the Any point APA Manager, this newly created or promoted APA instance shares the implementation URL and consumer endpoint with the original AP instance only. So for example, if this is promoted from Sandbox to UAT, whatever are the implementation URL and consumer endpoint that were on the Sandbox APA Manager instance, the same will be promoted, okay? They’ll be taken while promoting to the Uate environment, as this is not generally realistic. So typically what should be done is they have to be changed after the promotion. For example, those implementation URL and consumer endpoints should be changed to the one that belong to the UAT. So what you are seeing in front of you is just a small screenshot of how the web UI looks for the promotion of the APIs between environments.

So you can basically choose the environment where you want to deploy and the source environments and what all you wanted to include during the promotion. If you want to include policies, SLS alerting as well as configuration, or if you want only some of them, you can cherry pick. You can pick the version and say Promote to whatever environment. Okay? And which version? So this way once you are done, when you click Promote, it will take that to the higher environment. For example, if we are doing this production in the production environment and if you’re choosing staging like you are seeing in front of you in the screenshot, then from staging that particular for example aggregator code API of that version and instance will be promoting all policies, SLS alerting and API configuration to the production environment. Not only in the API manager. Any point runtime Manager also supports similar promotion of mule applications such as APA implementations between the environments. Okay? So again, like we had to change the implementation URL and consumer endpoint for APIs after promotion.

Same way here the DNS names of the mule applications must differ between the environments. Once again, please remember that promotion of Any Point API Manager definitions and matching API implementations can be automated by any point platform APIs. Okay? We are not discussing this as the only way. This is just another way possible through the web UI. So we are discussing this, there is no encouragement that we have to do this in the right way or anything like that. The automation is always possible to the Any point platform APS or the Any Point CLI, okay? It can be integrated to any DevOps approach. You can choose and automate this. This is just one more approach we can do manually as well. In the instances, for example, the reason could be because there is a Mule Maven plugin for the APA implementations, so the runtime manager deployments can be quickly enabled for the DevOps.

But because the APA manager assets like the policies SLAs and all, require the platform APA knowledge or the CLA expertise, say, because of XYZ reasons, your organization doesn’t have time to invest in getting these learned or bringing an expert in the platform API and CLI, and you don’t want that much high level maturity of the DevOps. Then, to save time, you can restrict the APA managers to be promoted from the APA manager based promotion like we discussed in this lecture, and still have the runtime manager deployments via the Mule Maven plugin using the DevOps way. Automated deployment. All right, let us move on to the next lecture in this section. Happy learning.

4. Demo: Promoting APIs in API Manager

Let us see how to promote APIs from one environment to another environment. I will quickly show you what APIs I have currently got in the API Manager and what policies, contracts and alerts that are currently set on them. And also the any point exchange. What API consumer has got the access to these APIs in Sandbox? Okay, so I’m navigating to the API manager. Now you can see there are three APIs currently. The Sales order, Experience API, process API and System API. And for all these three APIs currently, I have set the policy as a client ID enforcement policy. And I have set up a few alerts as well as there is one API consumer who got access on all these three APIs. If I just open each of them quickly, I can show you that the alerts that this API currently got are two alerts, which is one for the request count breach and one for the policy violation, which is nothing but on the client ID enforcement. And if you see the policies, it is the client ID enforcement policy.

Same time, if you go to contract, you can see that there is an API consumer with application name called Pokola Play Pen, who has currently got the access on this particular API instance, right? And currently I don’t have any SLI same way, I’ll quickly show you other two as well. I will go to the process API and on the process API you can see the same API consumer has got access on this. And even there is one alert called policy violation alert. And also the policy is Client ID enforcement. Also, same with the system API, you can go to the alerts, there is a policy violation alert and the popular pulp and is the API consumer and Client ID enforcement is the policy. Now I’ll show you in the any point exchange. Once you land on to Any Point Exchange, you can see your APA assets listed in the Exchange. And if you open your Assets, you can see that currently on the right side of your Exchange, once you open it, you can see the asset versions and the instances against those versions.

Okay? So currently you can clearly see that for version 10 of this API, we have one Mocking service instance, which you already know because during the design of the API we enable Mocking, which is nothing but instance that runs in background by MuleSoft just to mock the behavior, right? So that mocking service is also listed as one of the instances. And same way currently you can see one instance called Sandbox with a version 1637-7212. This is nothing but the API instance that we currently have listed in the Sandbox environment. Okay, say for example, if you create another API instance of the same API in Sandbox, again, then you would see another Sandbox entry here with whatever is the version name or the instance version name that is generated by the mule software. All right, so there are no other environments for now, only sandbox and walking service. The same with the other API as well. I’m just going to open process API and you can see the same thing here.

Now let’s go to the API manager again and see how we can promote the APIs generally in use of API Manager. This promotion of the assets from one environment to another environment works basically by navigating to the environment where we want to promote the APIs, okay? The reason being the feature currently we have is to promote from environment. This is the option basically, where we have to come and make use of it to promote the assets from a different environment to the environment where we are currently on. So if you see we are currently in sandbox environment, and if you click on this Promote From Environment button in this environment, basically it will try to ask you to choose a source environment, okay, from where you want to promote the APIs. As we already have the APIs in the sandbox environment, our target environment is some higher environment. So I’m going to switch to the test environment first. As you can see, currently there are no API instances listed in the test environment. I’m going to click on this Promote From Environment this particular button. And once I do that, it basically asks me to choose the source environment. All right? So we have to choose the source environment first. I’ll choose the source environment as sandbox. Once I am done, then it will ask me to choose an APA version. What I will do is I’ll choose the API.

It is first experience API and then currently there is only one version of that APA in sandbox. I’m going to choose that and the APA instance. Once that’s done. This is the important piece where you need to choose what all things to be promoted from the sandbox along with this API instance. For example, it currently asks you to choose, okay, do you want all the policies that are currently on the APA instance in sandbox also to be brought into this test environment or not? Similarly SLS alerts. Okay? But if you notice one thing, like I explained you in the previous lecture, there is nothing to choose for the contracts, okay? This is because the API contracts, which means the access granted on an API instance in an environment, right, that is the one that represents the contract. The contracts cannot be promoted from one environment to another environment. You have to please remember this. The contracts cannot be promoted from one environment to another environment. Reason being, it’s an agreement for an environment on an APA instance between the API consumer and the AP instance.

Okay? So if an APA consumer goes and requests access on a particular API instance in a particular environment, then that contract is only for that set of combination. It is not applicable to the APA instances that are generated on the same API in different environment. Okay? It is not applicable like that. If someone wants to get access on the APA instance in a different environment, then they need to again go to the exchange and request the access just like how they did previously. So what I’m going to do now is I’ll choose all the three options for the experience.

Then for the process, I’ll show you only by choosing some two of them and leaving the alerts. And for the system API, I won’t choose any of them, okay? Just for demonstration purpose, to show you how they will come. So I’m going to choose all click on Promote and the API is now promoted to the test environment. And if I go and click on the individual options like say alert, you can see that the same two alerts I had in the sandbox environment are promoted even to the Pet environment. Same way I can see the client ID enforcement policy too. And when I go to contracts, you can see that the contracts has not come here.

Like I said, they are not applicable in the promotions. Someone has to go and again request access for this particular AP instance in the test environment. As they don’t have SLS, it doesn’t matter. Nothing has come here. Now, one more time, I’ll do the process and system APS quickly. I’m going to choose Sandbox and the API is process API version. And the instance in the sandbox this time, what I will do is I will not choose my alerts and I will only choose policies and SLS. Anyway, I don’t have SLS. So I’ll just choose policies and I’ll say promote. Now this time if I again go back and see the alerts, you see that no alerts have come here because they have not opted it during the promotion. Similarly, no contracts, obviously. Because this is going to be always the same. No confusion. Contracts cannot be promoted from one environment to another environment. Separate request seems to be accessed. And then policies, yes, I did select them. That’s why I see client ID enforcement.

No. I select errors. Right. And the last one is the System API. Let’s go do that. And then I will not choose any of these. And I will say promote. So as usual, this got created in the test environment. You should not be seeing all the options. No alerts, no contracts, no policies, no SLR tears. So you understood this thing, right? So that’s how we promote the APIs. Now, one last thing I want to show is now that we have got the API instances promoted to test environment, if we go back again to the exchange and visit the APIs one more time, then you should now see the test instance also registered here. Okay? If you remember last time when we visited this page before the promotion, we were seeing only Mocking service and Sandbox. But now we can see the test as well. That’s because the test APA instances are now promoted to the test environment. Correct? So if someone wants to get access on these APIs now they have to visit the API just like how they usually do.

Go and request the access. Select the API instance. Okay? This time you can see that it is prompting to select any one of these because there are two instances. One is Sandbox and one is test. So we can choose the test environment. And this is where I was telling in the previous lecture that say if the same APA consumer who has got access on the APA instances in one environment also request for the access for APA instance in different environment, it still works. Not wrong. And the same client ID credentials that this APA consumer currently have can be used to access both the APIs in both environments. Okay? So the client ID credentials are not going to change. For example, if I PROCEED with this option now, I selected the API consumer who also has access on the Sales Order Experience API in Sandbox. Now, I have chosen the test environment instance and the same API consumer. I will request the access. And once I do that, you can see that, okay, the request has been received and approved, right? And I was given with the client ID and client secret.

And these client ID and client secret will be same as the one the APA consumer currently have for the Sandbox as well. Okay, if you want to confirm that, what you can do is you can visit back to the Homepage of Exchange, go to my applications, click on the APA consumer, and here you can always see the list of all the APIs that this particular API consumer has got access to. Okay? So this API consumer has already requested access on all these APIs in Sandbox in the past. And now, like a moment back, we have requested access for the Experience API in the test environment. And like you can see for all these set of APIs, the clientele and client secret are the same combination. So they’re not going to change. But what I was trying to explain in the previous lecture is, although this is technically possible, the same consumer can have access on all the APIs.

It is not recommended to keep the things clean, to separate the concerns out. The best or good approach is to have a separate API consumer per environment. Okay? You may think why it is required, but trust me, it really helps as a best practice, okay? It keeps the concerns separate. It keeps things clean. There won’t be any confusion. That okay, by mistake, if you are trying to access an environment API in Sandbox and trying to use client ID credentials when you’re supposed to trust it on the test environment, it will still go through. If you have the same API consumer, because the client ID secret are same and it may result in behavior. Correct? But if you, say, have separate client ready credentials for each environment, then even though by mistake, if the endpoint is configured wrong, and if you try to hit with the Sandbox credentials to a test environment and point, it would fail, saying the client ID secret combination is wrong. So I hope you’re getting this right.

So for good practice, it is always better to maintain separate API consumers for each environment so that the things will be clean. So, as you know, it’s not a difficult task. What you can do is just go to the API and request for access, select the AP instance, and instead of choosing the same Pocala Play Pen, an existing Sandbox API consumer, you would select Pocala Play Pen test, for example. And I’ll just say, okay, test environment, consumer. Okay, create it, and I’ll say Request access. So once I do that, it’s the same way the request is granted and a new set of client trading credentials will be provisioned for this new Pocal applied and test consumer.

If I go back now and go to my applications, you can see that I have this consumer listed here. And if I open, I should see one API, which is Sales Order PRC API currently having access for this API consumer with this set of client ready credentials. And if I go and now request access for EXP and Cslayer Two, then they will be also granted access. And I can use this set of client ready credentials to access, experience, system and process APIs for test environment here and this set of client ready credentials for the Pocalo Blip and consumer for Sandbox environment. Okay? So this way, it is clean and it’s a good practice to do. All right, hope you understood. If you have any questions, please do post on the Q and A forum. Happy learning.