Pass Mulesoft MCPA - Level 1 Exam in First Attempt Easily

Introduction

1. Topics and Sections

In this video, we will be going through the topics, different contents, and different sections of this course. What you are looking at is the MuleSoft Topic Sheet, which is also called a Data Sheet provided by MuleSoft. You can even download it from their website. But for convenience sake, I have uploaded the worksheet to the course resources. So you can download the sheet from the course resources section. So let's dive into the sheet. It will be very quick. It's a short one. So, going down, we can see the format of the exam here, which we have covered in the previous part. So it's the same thing: multiple choice, you have questions, 120 minutes, et cetera. We can see the preparation. So what MuleSoft suggests is that if you want to prepare it the right way, you can actually take their course, which is both instructor-led and online, called Any Point Platform Architecture Application Networks Course. So this is a highly rated course that covers very deep dive concepts of the Museum of Architecture and will make you an expert if practised properly. So they have outlined these topics in the sheet to make you aware. That is all you need to know to be prepared for the Platform Architecture exam or its contents in the course. In fact, they have a grid at the bottom that compares exam topics to modules. So this is the grid I'm talking about. So on the left, you can see the exam topics that you need to be aware of before taking the exam. And on the right, actually, it is more of their course contents to tally the particular topics with their modules. So it represents that, okay, for this particular exam, topics on the left are covered in their modules, and on the right module, module two in their course that they're offering or provisioning, the same goes down. So what confidence here that I want to giveyou is that the same level of knowledge thatyou are going to gain from the MuleSoft course,you are going to gain from this course too. It may not be a very deep dive because it's a pretty lengthy course, but I'm telling you, you will actually get the concepts that are a closure to what they have in their modules so that they'll be helpful for you both, for example, and your real projects. So what I'm going to do, and what I did in this course, is not name the sections exactly the same way. I don't want to just copy and paste it, but the contents of each section going forward after this particular section will be covering the topic similar to what you see. Again, I have not named the sections or the lectures exactly the same as what you see in this particular sheet. But like I'm telling you, we cover these topics to make sure that you are covered. The requirements of the topics are clear.

2. Course Type and Mindset

One thing I would like all of you to do before proceeding is to switch yourself from developer mode to architect mode. Your mindset should be queued in such a way. The reason I am asking this is because this course primarily focuses on the endpoint platform and is designed for architecting MuleSoft solutions on the endpoint platform. This is not a development course. Please keep this in mind. This is targeted at senior developers, architects, and leads who already have good news about development experience. Okay? You should know the basics about how to develop new apps using Anypoint Studio, at least how to write a small app in Anypoint Studio, how it gets bundled, et cetera. This is expected before you start this course. If by any chance you don't have that, then I strongly encourage you to visit this trainingmulesoft.com website, which is MuleSoft's proprietary training website, and complete the MuleSoft Free Self Study Course on MuleSoft Development Fundamentals. Okay? It's a very self-explanatory course provided by MuleSoft for free. I suggest you finish that if you don't already have experience in museum development, and then visit this course for your own benefit. Also, this course is designed in an incremental fashion. So, for those who are already familiar with any point platform, the lecture is still in Section 2. The first two sections might look a little boring as they are introductory and theoretical, okay? So please bear with me. Please do not leave a negative rating before Section 2, thinking this is a boring or theoretical course, as it will become more practical after Section 3. Okay? It will definitely get practical. Please believe me. I hope you understand this. And, once again, if you are bored until section two, please be patient as we progress through the course and leave your rating at a later stage, say when you are 20% to 25% done, rather than leaving it early. If you think you are convinced already, then you may leave your rating. It's fine. But if you think no, this is not it, then please be patient and wait till you complete some 5% of the course, and I request that you leave a rating at that point in time. Okay? I hope you understand. Thank you.

Hide

Application Network

1. API Terminology

Hi. In this video, we are going to learn about some of the terminologies that we will see across the course and that are also important for the platform market exam. If you are planning to take the platform market exam, you will come across some courses where the object of the answers is misleading or confusingly mixed up with these terms. So you will have to select the right option, for which you have to clearly understand the differences between these terms. So, as you can see, there is an API client, an API consumer, and an API implementation. Let's quickly understand this. An API is nothing but an interface between the client and the actual application. So the client is someone who uses the API and APact as an interface between the client and the application. Now, an APA client, as the name suggests, is actually the ultimate source that is calling the API. So, depending on where you're calling it, it could be a postman or some other advanced rest tool. Or it could be a Java programme or netprogram that you're writing to call the API.

That is an APA client. And an API consumer is a bit of a confusing term here because sometimes or most of the time we get mixed up with APA clients and EPA consumers because we think both are the same, but in new software or at least in the API, there is no point-to-flat-form terminology. API consumer is a non-problematic entity. There is no code being written to call the API here. It's a kind of role that represents when calling the API that a group of API clients play. So we will better understand it on the next slide so that you won't get confused. But for now, let's say in two ways. APA clients and API consumers go together. But an APA client is an actual piece of code that makes the call, and the consumer is a role on top of the APA client. Now, the last one is APA implementation. Again, this is a straightforward term. The APA implementation is the actual implementation, a piece of logic that is written to expose the functionality of the back-end service. Let's move on to the next slide to visually understand what these are. So, let's put it all together. Let's say we have an application server, which could be a back-end server or any back-end enterprise system or legacy system. Now, we want to make a call to this application server by exposing an API. So we are ready to implement an API for it. So we have written a piece of logic that exposes the functionality of the back-end server. That piece of logic could be in any programming language. It is agnostic to the application service logic. Now, this is the piece of logic sitting here. How would we expose this functionality to external systems or to external clients?

For that comes the interface, which is also an API. So an API or API interface, like we discussed in the previous section, is a specification to help the clients understand how they can invoke the functionality that we are exposing for the application server, which is back on the server. So you must be very well aware of this already. It could be a Ramble spec, a Swagger spec, or any other open API spec. So it's like a kind of agreement between the client and the APA implementation saying, Hey, I'll call you as per this AP interface, and you take my request and send me back the response. Now, API consumers sit in between the API client and the API. So what is this API consumer? I said I'd help you understand this on this visual representation slide, right? As a result, APA consumer is a group identity that represents these. All clients belong to me. It could be an LOB, or it could be a vertical in your organization. If it is an internal one, or if it is an externally exposed API, then there could be a group of users to whom you have given your API or exposed API. Say, for example, let me help you with a real-life scenario. If this is an internal API for your company, it could be called from many lobes or verticals. One could be finance; one could be HR; one could be sales. Right? Now, how do we know who is calling me from the mule soft world or the API provider side? Yes, there will be many ways—technically, the IP address and the other waste. But, logically, how would I know if this call is coming from the HR lobe? This is coming from finance. This is coming from the sales application. So, first and foremost, we will register the consumers, or clients. Our consumers have to come to the any point exchange and request for the API access and register themselves as consumers, saying, "Okay, this is for Lob." My name is Lob and my nameis Finance and my name is Sales.

Once they register as consumers, any API to which they gain access using their consumer credentials will be assigned a specific set of client credentials, the login, or whatever the mechanism is. And then, using those credentials or the access mechanism, they implement their API clients, which should again be a programme or a piece of logic, or even if they hit from Postman whenever they use the access mechanism they were granted with when they registered for their API consumer, the moment the request hits from that APA client. So this is the total view. So once again, we have an application server. The piece of logic that is implemented to expose the application server functionality is the AP implementation. This is the actual code, and it can be written in any language agnostic to the application server logic. Of course, if it is implemented in Mule, it is going to be Mule Flow. I understand, but I wanted to explain this with a generic definition. And now the API sits in front of the AP implementation. It is a specification or an interface, a kind of agreement between the API consumer or client and the AP implementation. The APA consumer has an impact. While it is shared between client and ape, it actually sits in between them. So they have to come and register themselves as consumers and gain access to the APS they want, and then have to implement the programmatic logic, which is the APA client. So the examples of API clients could be Postman, a Java program, or a DotNet programme written to call the APIs. Now, let's understand one more concept before concluding this particular part. APL connectivity. I am very sure you understand this concept well by this time, because you must have definitely cleared the Mule Soft Developer Certification, even if you're not into certifications.

If you're taking this platform architecture course, you're probably familiar with MuleSoft development, which means you're already familiar with Apollo. But let's not ignore it. Let's explain it one more time before we conclude this particular part. So this is the most popular layered architecture proposed by MuleSoft or made popular by MuleSoft in the API world by suggesting that this is the better approach in the APA implementation projects to keep it very loosely coupled, very less maintainable, and properly organised, so that you have a very clear picture of what APIs we are building in your organisation or in your project. So here it goes. MRSA suggests that we should have three layers of APIs. The API should be segregated into three separate layers. One being called Experience APIs, and thesecond layer is Process APIs and thethird layer is the System API's. So, how will we divide the APIs into layers? How will we know? Okay, which VP goes into which layer? So to understand that, let's say this. Let's have a scenario. Let's say we have two back-end applications. One could be an application server A, and one is an application server B. Say application server A could be an SRP systemand application server B could be a CRP system. One is ERP, and one is CRM. So now the definition of the systemAPI layer goes like this. There is no fixed definition, by the way. But I'm just trying to explain the way I understandwhat system API should have is the APIs that interactwith the back end application service directly should be thesystem APIs point number one and point number two. These APIs should not be written as composite APIs. Let me explain it better. What do I mean by composite APIs? When I say system API layer, it can have all the APIs that interact with the system. It does not imply that you can have a single large API that handles the implementation of multiple methods or something to the back end server. No, what they mean is it should be modularized. It should be very atomic in nature.

So that back-end server will also have different individual functionalities, right? For example, one could fight for the CRM system,one could be a create customer, one could bean update customer, one could be add address tothe customer, one could be retrieved address to thecustomer and the last could be retrieved customer. These are different functionalities. So we should be implementing The better way to do this is to implement each system API for one functionality of the back-end API. So that way, it is even more modularized. So, if you need to change any logic or functionality for any of these specific functionalities, we go and touch that piece of the API system. Only the other four or five functionalities will be left untouched. However, if you write a single bulky API with all of these embedded inside it and expect some process API or consumer to call accordingly, the concept of loose coupling and maintainability will be lost. When you touch something, even if you know you aren't touching another function, such as customer criteria, you are only touching create customer. Still, in the world of programming or project development lifecycles, the software development lifecycle is unacceptable to testers. Any piece of logic that is touched, even if it is only a small mapping, necessitates complete regression, which is a very expensive thing to do in the project lifecycle. As a result, you must implement atomic APIs that call specific back-end system functionality. Now, once we grouped or arranged already with allour system APIs, there comes the process APIs. Process APIs, as per my experience from the projects I have implemented, are where the complex orchestrations come in.

Because, like I said, SysAPI is a one-to-one kind of API. I don't want to use the word "one to one," but the smallest form of APIs is when we implement each functionality as a system API, then there will be many system APIs. That is the reason I wanted to represent. The way I understand it, I kept more system APIs, moderate plus APIs, and less experience APIs to say that, because you are writing individual modules, there will be lots of system APIs. There will be many of them. Now, coming to the process APIs, this is where the complexity comes from because we have to orchestrate the calls of the system APS. It could be a great customer if we have an API, as Isaid. However, a great customer may be one atomic from the backend systems, but from the project side or the business side who is leveraging that great customer from the backend systems, it may be much more complex, meaning the great customer may have to go and talk to the SAP as well as the CRM. Or it could be a number of finance systems. As a result, such orchestrations of calling X-Y-Z-CAPIs fall under the purview of the process. APIs? All such APIs are now classified as part of the process API layer. The experience API is more about the user experience or the client API. We provide client experience if you understand that by the time the Process API is developed from the business side, the entire API is ready. So they achieve the behaviour they want by using the Process API layer only. Then why do we experience APIs?

This layer is to satisfy the consumers of the APIs. That is, your APA could have mobile consumers, web consumers, various bots, artificial intelligence consumers, and a variety of other types of consumers. So we have to tune the API accordingly, right? As a result of accepting various protocols, one could be rest over HTTP, one could be so poor HTTP, and one could be JSON RPC. So, as I previously stated, we cannot write for all different implementations plus API. As a result, we implement such APIs to abstract it or perform diagnostics of business logic functionality in the experience layer. As a result, this should usually be a smaller piece of code or a section of a page focusing on how the end user experience is delivered. And then, once that is transformed, it will, at the end of the day, be the same process. There could be a process apps.There could be more than one experience API calling the same process API. Because one could be exposing a rest while the other is exposing as, right? Yeah. I hope you understand the terms and the Apollo activity better. Let's move on to the next part. Happy learning.

2. API Terminology Demo

Hi. Let us quickly have a short demo to map the new terms that we have learned in the previous part of the book into the real Anypoint platform. So I have just logged into the endpoint platform. If you don't have one, you can create the free trial one we had for 30 days. So let's take the first term, which is API and API interface. So, how I can compare this is that you can go to the Design Center. That's where we generally create new API interfaces. So I have already created one sample for you. Let's say I create an existing one. Let's open the existing one to make it faster with a small sample of Ramble. The add-in resource API interface specification includes the Just Math API. Okay? So if you just click on it, it shows what the expected input and output are, what type of APA method is being used, what the expected response format is, and all the other details of the particular API. So, this is the first term, which is "API interface." Now, moving on to the next part, which is the actual API specification or API, That's where we go into the API Manager.

And in the API manager, we can create the API from the interface in many ways. You can either import the RAM directly or you can choose the one that's published to the Exchange server for any point exchange. So this is the first term in API, the API interface, which is Any Point Designer, and the API, which is in the API Manager. Good enough. So now, the third part is the APA implementation. Let's have a look at that. This is my APA implementation, where I just created a Mule project using the same API Specification Interface, which is the RAML file. And it's a very simple implementation. I just have a data view where it takes in the inputs from the API and creates the response, just adding them up. That's it. So, let's deploy this to the runtime manager, followed by the runtime manager. I have it deployed. Now, it's a simple math API like you saw in Any Point Designer. So this is the API implementation, the actual piece of logic that is exposing the functionality. So, this is the AP implementation. Any Point Exchange and any Point Designer carry the APA interface, and the AP manager has the API. So, two terminals are left: APA Consumer and APA Client. Now, the API consumer is nothing but someone who actually goes to the Any Point exchange and accesses the API and registers himself as a consumer. like I showed last time. Let's say if I am an API consumer, I come here and choose the API. If it is for the first time, we have to go and actually request the API for the version in the sandbox. For example, I don't have an application. So I consider myself myself as a sales team. The sales team and I create the consumer of mine, and I request access. The moment I do that, my consumer is created, and I will be given the client credentials for me.

So if I go, I can always visit my clients here, and if I open that, these are the client credentials that are provided to me. So right now, I requested access for the math API. So I am seeing just this API say in futureI have many more APIs using the same consumer. I can go and request access for allthose APIs which will be listed here andthey all be sharing the same client credentials. Now, similarly, say tomorrow the HR team comes in and says yes, I also want access to the MathAPI, but I am from a different lobe. So what we can do is have them come here requesting the access and again select any point instance; this time, because they are from a different team, they will be registering themselves as "finance," they will create the consumer for themselves, and they will request the access. Now that TADA has its own consumer, don't worry about the privileges. I'm an admission, I'm able to see all. But generally, when the teams create the consumer central, they'll be able to see only the owners of their particular consuming applications. Same thing. So going forward, I will request access to multiple EPIS using the same client credentials. Now this is the API consumer's role, right? So one particular consumer can haveaccess to any number of APIs. Now that's an APA consumer. Now let's move on to the API client. APA client is nothing but any client who calls the API. Here we have Postman. So this is our client, to whom we will make the request. Let's say if I change it to a different number and send, we get the response back and it's working. So it could be a Java programme or anything else as well. Happy learning.

3. Operating Model

In this video, we are going to see about the effect to application networks and their operating models. So, what is an application network to explore it in short? So, we've seen the API connectivity in the previous part, right? three-layered architecture where we have experience, process, and system APIs. So that is all about implementing one experience API or one functionality in a proper way to make it model-driven, resilient, and maintainable. Now, one API does not serve the entire business purpose. There will be many such APIs to be written, forming a network of such APIs. For example, we have seen a three-layered architecture for a given API. So, in the last slide, we have seen that only one API is connected to different system APIs, right? But like I am saying now, there could be many such APIs. There could be API two API three andAPI four, all connected to various various applications. And such APIs or networks would differ greatly across the lobes. There could be one set of such APIs written in a different lobe for the purposes of different business implementations, just as there could be another vertical in your organization.

And at one point, they may not overlap across many functionalities, but in some places there would be a common integration between these as well. So it keeps on growing, right? So, this kind of network is called the application network. So that's the definition you are seeing in front of the slide. So, an application network is the state of an enterprise architecture. It's an architecture across the enterprise that emerges from the application of Apollo connectivity. So, when we do the Apollo connectivity and build the APIs and form a network of all the APIs by fostering meaning, imposing proper governance, making all these APIs discoverable, and enforcing the team or organisation to consume the API more and more, As a result of all of this, the application network and effect application network architectures have emerged. So, how to now ensure that the organizational,the governance of API is applied and howthe APIs are discoverable, are made discoverable todifferent lobs across them, and how to ensurethat they are consuming it correctly or makingsure that they're getting consumed and not left. That means achieving reusability, right? So, how do I do that? So, let's see it in the next part. What you're looking at now is the delivery gap and the capacity. Let me explain it to you better on the left. What you see is a standard IT operating model.

Meaning there is a project. There will be definitely teams to deliver theIt things to do the implementations, manage theprojects, test and then roll out. At the same time, there will be lots of demands from the business asking for various needs or from the sales and marketing teams to meet various requirements of the end users. So, in a typical project, till recent times It used to be that the demands kept coming, and the pressure was put on the guys to deliver on those specific requirements. So what is the only way to do it? Either they have to work hard to meet the achievements, or if that is not the case, then the organisation has to outsource the work to various numbers of people. So they have to keep growing. The teams like the new departments will be formedwithin the It saying Mobile Data Department, Big DataDepartment, cloud and SaaS team and all. So as the team grows, yes, it's fine, the database canbe met but what grows is the gap between the teams. Everyone will start using their own practise terminologies and ways of implementation, right? And it's not possible to have these teams sync up to them all the time. That gaps, lots of gaps. And if there are a lot of end systems, everyone will start writing their own logic or code to communicate with the systems they don't know about. It may be a code that is already implemented in adifferent team but nobody has time to know all those thingsand cover up and sync up and you reuse the code. So everyone, because of their pressure and timelines, will start duplicating the code. Is that enough? No, that causes even more problems in the testing effort. The same code has to be tested by many different test teams. No one knows rt. The saThey already tested the same code with a different team. They will be testing the same functionality.

So it may work. We have one way with one team and another way with another team. So this is all the problems with the current Itoperating model or the It operating model in recent times. But how is the trend moving on now? So on the right, what you see is the MuleSoft proposed operating model. So when I say it's a new soft proposal, I mean the model, which has again been made very popular by MuleSoft. And believe me, it works very well; in recent years, teams that have adopted this model have been successful and have delivered extremely quickly. What MuleSoft is proposing for the operating model should be such that you can have the same IT delivery capacity. There's no need to increase your team members or anything. Simultaneously, you can build your assets in a specific way according to a specific model so that your IT delivery can continue to provide things within the same capacity and you can also meet the demand of your business by adopting or consuming the IT delivery assets. So how is it possible? So, as we will see in the following slide, let us now look at how to meet the demands of it using this new operating model. So what this operating model says is that the central office needs to move away from trying to deliver all its projects themselves. So usually there will be just one IT team on the project. It could be one big item, but it's like a separate department, right? One is its department. So what this model says is that it should move away from trying to deliver all its projects by themselves and start building just the reusable assets to enable the business to deliver some of their own projects as well. But here you raise a doubt: how can business deliver the project? They may not have the technical knowledge at all. So they're not saying I completely ignored the business or lob. What? They say you should divide central IT into small departments, with one core IT team available. As a result, there will be one main it. I will tell you the name of it. You must have heard it's calledC four E or something, right? C-four-e-team Then, in each lobe, place a small number of itpeople or developers. As a result, a lob with a small it team will be formed. Each lobby will have an individual IT team, and there will be a central IT whose core job is to develop the reusable assets. That way, the IT developers in the Lobteams will be using those particular assets to meet the needs of the business. That way, the demand will be met by this operating model. So that the central It willbe focusing on the reusable assets. They do not bother about whatare the new demands on business. Only the developers will be taking care of that. So that way, it will be faster.

So what is the key thing here? So the key to this strategy is to emphasise consumption as much as production. So what I mean is that, as fast as they deliver the reasonable assets, the Lob team should also focus on consuming them that much faster. There cannot be huge delays in this process. Then there is no use of adoptingto this new operating model, right? So how to make sure thatthe consumption happens very fast? Again, the It team or central team cannot go toeach other and say, hey, I have a new API. Please go and consume it and give feedback, so it doesn't work well that way. If it's a big organization, even for small organisations, it cannot be a one-to-one promotion of the APIs they send out. So the key thing here is that the API should be self discoverable.Someone should be able to do self service.They can go to a particular place and find the apps that are available for them to use. so they have to be discoverable easily. So someone who can do self-service by easily finding the AP they want to use should be discoverable. In traditional IT approaches, the emphasis would be solely on project delivery from the IT side. They do not understand much of the business knowledge, right? Sometimes I heard in many projects, Isaw people cursed items, cursed business, man. What exactly are they asking? So there is a gap between IT and business. This way, the gap will be gone. There can be one core It who may have limitedidea, but still they will have business but limited ideaon the complete business but the ideal operation. The Lobster teams will have the most knowledge.

So they know how to use these APIs or the reusable assets. So this fills the complete gap. So in this new operating model, it changes its mindset to think about producing assets that will be consumed by others in the line of business. So the assets need to be discoverable, and developers need to be enabled to self-service them in projects. So the main important part of this cycle is to get active feedback, right? So yes, they're consuming it, but what is the point if we don't get the feedback faster? We are saying, "We need this, we need that. Please enhance the API." This way, it should meet the extra demands as well. So such kind of feedback has to come. Could be input spec or the functional behavior. So from that consumption model, if the active feedback comes back, then it makes the model more effective. And the use of metrics came from theproduction model where it's working better or not. As you can see, this is a cycle. So the IT team, the centralised team, keeps producing the assets. So the lobby teams will come and discover them and consume them. They provide the feedback and the usage metrics. They will improve and develop new APIs based on the feedback, and the assets will be reconsidered once the feedback is received. So it's like an iteration model. So this is how the new IT operating model works and makes delivery most effective and faster. I hope you understood it. If you have any questions, please post them on the question and answer form so that everyone can benefit. All the core subscribers know the doubts, and they also gain from the answers. It can become resistant. Thank you. Happy learning.

Hide