API Modeling

1. Introduction (Section 4)

Hey, Welcome to the next section. In this course, in this section, we will move on to the next phase of the project. So, in this phase, we will identify the APIs that are needed to build for the organisation in the project. And once identified, we will have to split the API implementations into three layers by deciding which API fits into one layer. Right. So that means we will assign each of the identified APIs to one of the three layers of Apollo connectivity. Once that is completed, then we will mark the APIs that are reusable, which can be usable either within the lob or across the lob. So we have to mark them so that we can use the same one in different kinds of AP implementations. And last, we will publish the APIs and related assets for reuse. Okay, As this is a critical exercise, as a platform architect, you will have to spend most of your time on this phase of the project. Previously, in the last section, which is also a previous phase of the project, or at least a phase of the project, where we will have to play a role or help the organisational staff or teams to align the IT operations and then establish the C & E and then decide what the deploymentmodels are and also the other stuff, right? The platform architecture, organisation structure,access, control, et cetera. So that is the first phase where the foundations were established. So in the next phase, you will have to again play a very key role in the previous section. It's a key role, but this is an even more critical area where you have to focus most of your time. because the reason is that identifying and assigning APS to relevant layers is a very important part of the project. When I say it's a very important part of the organisation or project, what I mean is this particular piece will become a very basic foundation. Okay, Because the success of a platform architect will depend on how well and deeply he or she can analyse and identify the APIs and assign them to the right layers. Okay, so this is kind of a one-time job, right? Yeah, it is a revised one. The revision is definitely but from a bird's view. This is a one-time thing at a very high level. You cannot return and cause too much disruption. When we deeply go into the middle of the project phase, the early phase is that we can realign in the middle of the project stage. And small alterations are possible, like deprecating one system API, removing one system API, replacing it with another, making small alterations, small orchestration changes, but you cannot go and disturb the whole thing. Right. So this is a very important portion of this phase. So in this process, the primary focus of yours should be on the functional architecture. OK, so while identifying and assigning the IPS to the layers, the first focus of primary focus should be the functional architecture. You have to understand the business knowledge of your organisation and project. Once you understand the business knowledge functionally,you have to segregate them into APIs. In other words, the better way to count how many APIs will be there? Whether the APIs are of an atomic nature or not, modernised or not, they are all these things in a functional aspect. Once that is done, then the next immediate focus of yours will be on the non-functional requirements, the NFRS. So to make sure that OK, with this identified APS, how do we meet the non-functional requirements like performance and the SLA, etc.? So what we are going to do in this section is because this is more of a theoretical thing, right? Not like a demo thing, okay? So, because the theoretical thing to make it easier for us to compare and understand, what we are going to do is take one use case scenario and then try to do the process we highlighted, which is likeidentifying the APIs, assigning each of them to the different layers, and then publishing them. What I have chosen, hopefully thinking that you will understand easily, is a sales order process for a particular logistics company, let's say. Okay? So in the sales order process, I am taking the use case, which is the creation of a sales order. So what you're seeing in front of you now is a very high-level current business process that the organisation has where they are exposed to creating sales orders as a soap orVisual and as a restaurant, as an API. They also have a file-based interface, so they can receive orders in any of this manner.Some of the customers of the logistics company place sales orders via SOAP web service, some of them via Rest, JSON API, and some of them via the File Page Interface. Then what happens in their business process today is that once they receive the order in any of these particular files, soap or rest, the key contents are that the customer will place his customer ID, their customer ID, and OK,which is the customer-side ID. So they represent themselves as "yes, this is my order." They put in one customer ID and then they put in the shipping location where the order should be shipped to, because the customer may have multiple branches, locations, or stores. So they have to put the shipping location on idle where they have to ship the order. The logistics company should then ship the order. And the last ones are the items that they want to order. They want to order what items could be phones, laptops, or any other additional aspect. Okay? So the item numbers should be placed. So the thing here is that when customers place their orders, they always use the IDs of these, which are from their side, meaning they are external to the loyalist company. Okay? So they maintain that every customer maintains their own customer ID, item numbers, and then the location ideas. So they place the orders using their customer ID, location ID, and item IDs. So what does the logistics company have to do as part of their business processes to first convert those particular external ideas into their systemIDs, which are their ERP IDs? So they have an existing Xray system which is a legacy system where they maintain the Xray external IDs and the ERP IDs. Okay? So they have to first validate that customer ID that is in the request to see whether it's present in the texture format. If it's not there, it means it's like an invalid customer or an unknown customer. So they can reject the order or customer in the response, saying sorry, customerID not found or something like that. If it is present, they will convert it into the system ID there and then in the canonical transformation. Similarly, they validate the iTEMiD shipping locations again as the extra system. If all three are good, then they proceed to the next step, which is the creation of an order in the ERP. Once the order is scaled in ERP, the ERP gives them back the sales order number, which is then again shared as part of the response to the customers. All right, so we will take this scenario and we will walk through this scenario to do the steps we discussed across this section. Okay? Thank you.

2. Fine grained vs Coarse grained APIs

Hi, I hope you have done a good job of finding the solution in the previous exercise. I hope you have identified the right API's and their closure to what the solution is shown in the previous assignment. So if you see, you must have noticed how the business process now looks if you draw into a three-layer architecture and how each component in the business process maps to each API in the three-layered architecture. Now, let's dig a little deeper into the APIs and how granular they are. Okay? So basically, the APIs can be defined as their coarse-grained APIs as well as their fine-grained APIs. And this terminology, of course, grained or fine, is actually a soil terminology. Or it could be soil technology, which is truly where it came from. Or is it also the technology? You must have seen the floors when your wife, or if you are a woman, goes to the grocery store and you buy some floors to bake something or to cook something. Typically, some floors have coarse grain while others have fine grain. You must be able to distinguish between soil and floor. Coarse grains are a little bit rough in nature and a little bit large in particles and all. So if it is for food, then there will be some crispy nature that comes on the food. And fine grain is like very smooth or very soft in nature. right? So that's the food technology and the sand technology. The coast grains are a bit rough and a bit large, and each grain is of a different size and shape. Whereas if it's a fine-grained soil,usually it's like almost similar grain. like, for example, sand, beach sand. Right. It's kind of fine-grained or can be further down fine grand.But I'm just comparing between uncertainsoil and beach soil, right? Yeah, beach sand. So now, how does that map to the API here? Okay, so let us take the same example from the exercise we have done before, how we came up with the three-layered architecture and solution for the business process and see whether it's a fine grain or a COVID grant. Okay, I'll tell you the answer up front. It is fine-grained as per my perspective. If your solution or approach to the API, how you identify the EPA and assign the threelayer, and if yours is also somewhere along the map are similar to the one I provided in the solution, you can call yourself a fine-grained. Okay, so what is this about? So let's have a look at the system layer now. Okay, from the previous exercise. If you see the system layer, we have three separate dedicated API system APIs for validating the item number, validating customer IDs, and validating the ship locations. right? Is it really necessary for some of your friends or colleagues to say "no, this is unnecessarily duplicating the APIs" while you're designing it or brainstorming it with them? This is not necessary for access systems to be a single system. And if you have a look at excesssystem, all of them have the same pattern. They're just three columns. Type, external ID, and SystemId. right? So why not have just one API? You pass the type of System ID or the external ID and it gives you back the other system ID if you pass the excess ID or the external ID if you pass System ID. So why complicate this? Why not write three distinct items: ship, location, and customer? So this is where the fine line comes into the picture. This is where you can draw a small line between how your architecture will be or whether your granularity will fall under fine grain or coarse grain. Okay? If you are thinking with a coarse grain mindset, then you will agree with your colleague and have only one API. It is not wrong. It's not wrong, but it's just how granular your architecture is. Okay? So yes, it still works. Correct. You can pass the type as an item and pass the external ID. We give you the system ID of the item. You pass the type as customer and the external ID of the customer, which gives you back the system ID of the customer. It works. It's not like it doesn't work, but say tomorrow's requirement has come, OK, wherein you are told by the organisation that guys, we are slowly moving away from this. As a starter, we have to use the item excess from the new WMS which you are going to adopt. It's a WMS (warehouse management system) system where every item is managed in that and up to date.And it has the capability to actually maintain the external ideas as well. So we need to rely on this legacy-old custom-built Excel system. So we want to move out or move our checks to that. Okay, then what would happen? You would have to now implement a new way because your current call doesn't work. There are not going to be any items in that excrement. You'll be left with the system and the customer and the shipment location. Except right, your item will be moving out. So you have to build a new one. Correct. So the same thing happens for customers. For example, tomorrow someone says we have a customer management system CRM where we have to look for the Xref. We should not be looking into custom built systems. We are completely moving away from home grown or homebuilt systems. Let's say it's a decision on the roadmap of your organization. Again, you would have to build a new API, right? So if you see the one where we design,we already have three. Even in the very first video where I explained AP terminology and where the API connectivity is discussed, I also mentioned system layer APS. How we decide is not just one API in front of the system. If it's an ERP system, it's not about one earp API in front of it. In the case of all of them, No, remember examples like we should have just one API called Customer. And within that, I recommend we have a separate API for creating customers. Similarly, for Update Customer itself, instead of having one API call to Customer and thenwithin the different operation services. In fact, I gave in on this question as well, right? So, if you have it separately, you have that fine grain granularity, okay? You can very seamlessly go and change the behaviour of the system integration in the back end or behind the scenes without actually touching your main layer, orchestration layer, processor API layer, and DXP layer, right? So, again, even here you may have a discussion: why such a big foresight? Why do that? Let us now do this list with a cost grain and one validated API. And then when the organisation says "Let us go" and build a new one. But that's the thing, right? So, the organisation needs minimal changes. If they're okay with change, they accept the change. It's inevitable. We cannot have an unchanged system,but they expect a minimal one. Okay? Imagine if you had to make this change at that time. It is not just the system API you are touching. Yes, you will split this into two system APIs here. Now, what happens to the process API now that we have changed the code in the process API layer? Because you're calling this validated. So all these things will change, right? So, instead, if it is a fine grain right now, then your processor layer orchestration is established. You don't even touch it, okay? And then it's the suspect that is important. Whenever there is a spec change, it would have to be made in the process layer. As long as the spec is the same,the interface is the same, it doesn't matter. Bandwagon, you may point to a different system. So this is where the fine grain versus the coarse grain comes into the picture. That is just one example; it is not the only difference. There are many such things. For example, right? So, let us see. So you might think, okay, this guy explained the sand compared with sand terminology or soil terminology and the flood terminology. But how do we map this to the APIs? How do we decide whether APIs are fully fine-grained or not? Whether it's fine-grained or not So, there are a few things which you will see. Now, if these aspects are met, you can think of it as a fine-grained Okay? And what are the pros and cons as well? We'll see if finegrain ever has a good or bad time. What are the pros and cons? So the first thing is maintainability. Okay? The Coast Grant APIs are difficult to maintain because they combine many things into one. So, like we discussed before, whenever there's a change, there's a change that can be implemented, but they're difficult to maintain. Whenever the changes keep coming, you have to touch more things. Okay? Similarly, one more thing is, if you take the experience layer as an example, we have dedicatedly created three APIs: one for Soap,one for Rest, and one for a file loan. The file and I don't want to call it an API, but it's an application like ASBA adapted application running this file volume. Instead, you might think, why not have one API experience? Because it's just a protocol change, right? So let's have one. And we support different content types. Let's say the content type is coming as HTTP based with HTTP verbs. We will divert it using a content handler before the actual application code to the Rest behaviour to convert the incoming request from JSON to canonical format. Say if it is a soap opera HTTP protocol,the request is coming, then let's convert it using contenthandler from the soap envelope to a canonical model and give it to the Plc layer. So you might think that. So that's where when the requirements keep coming up for each consumer, you'd have to necessarily fit all those consumer requests or individual customer requests into the same API and make them bulky. So, maintaining a bit will be difficult. That change may unnecessarily impact other customers, and what's working for that other customer might stop working because of some change you made for another customer. So all of these concerns will be separated and easy to maintain if you have one separate, separate experience layer APIs for each customer or a protocol or whatever it is, application, web, mobile, and all of these concerns will become agnostic. Okay? And the second aspect of the fine architecture is the fine grand APS management. Okay, We are very lucky to have APA, Manager of Neilsoft. In fact, many API gateway tools are coming with APA Manager concept API gateway concepts where you can apply the policies, whereas policies like IP whitelist, IP blacklist, rate limits, and throttle the request from Jason's third production, you can apply so many things are possible.So the management is easy. So you can find grain and select Okay, I want this set of policies on this API, this setup process on this API. If they are merged and have one bulky one, you cannot control which one should have what policies. Either you have to compromise and apply all of them to all functionalities, or you have to compromise and remove some of the policies. The more split or fine glare you have, the more broad you have, the more controls you have on what policies or how you manage the APS, and what policies you can apply. Okay? Then there's deployability: obviously, the more APS you have, the smaller the APS will be because you're splitting your functionality into extremely small pieces, right? As a result, the smaller or much smaller your APIs are, the faster they are deployed. Okay? So the downtime there won't be downtime. This is everything that is a zero downtime deployment. However, the rate at which your changes will be implemented will be much faster. So the deployment will be easy. And the second thing is scalability. Okay? So again, the much broader your apps are, you'll easily identify where the bottlenecks are, or during the huge loador sudden heat of hammer testing or sudden bombarding of requests from the customer for whatever reason, you know where all the load is getting impacted. So you may have 100 APS when there is a huge load or if for a particular feature you have promoted or your marketing team promoted and there is a huge demand and the requests are coming in, you will know from your pay manager or your analytics. Easily said. Okay, this Y-Z-A-C These four APS systems are under a tremendous load. So you can cherry pick those four and reduce the number of workers to two or three, or scale up or scale out whatever you want, and your costs will be lower because it will be cherry picked. So they merged all of the system bits into one system API, right? If there is a demand in the creditcustomers but no update of the deleted customer, you would have to scale up all four of them unnecessarily, right? So this is where scalable finegrain pace will come in handy. Similarly, as I previously stated, the smaller your apps are, the finer-grained they are. Obviously, the code complexity is also reduced, right? But there are two parts here. Let me first say that the implementation capacity will be reduced because you will be concentrating only on the lowest part. For example, creating a sales order means you will concentrate on creating sales orders only. All the prerequisites, all things are not. You do not mind because your validations and all are being taken care of in the process orchestration layer itself, right? So there is a valid item API, clientAPI, customer API, and ship location API. So you do not need to do all the bulky things. It is all taken. So you concentrate on doing that. So, that way, the functionalimplementation complexity will be reduced. But however, a little bit of a con on this side is that your processorchettion will have a little bit of a complex nature. But it is not technically complex. Meaning it's not technically like okay,it's very messy correspondence, but it's functionally bitcoin, meaning process layer. It should depict the observed nearest process,calling the validated items validated items, and then validating customers' validating locations. All this business should be reflected correctly, so that's a little bit of complexity comes in. But it is readable correctly. Everybody who wants to know the business process just goes to the process layer and they know exactly what is happening. What is the business process? Unlike in the golden days, they need to know and read the code level. They can just see the APorchestration and understand what the business logic is. Okay, but another thing is latency. This is the con side of the fine grand and the pro side of the coarse grand bi latency. Because, yes, we are saying that the more APIs it has, the smaller it becomes. It is very good. Right. But there will be different latencies. Every API is an extra HTTP call, okay? Even though they might be in the same VPC or they might be hosted on the same cloud setup and all, it's still HTTP. It's an external call out and there is definitely going to be latency. And every integration point introduces a failure mode. Every integration point has a failure. This is a good thumb rule and the integrationarchitect will keep in his mind that any integration point you introduce leads to a failure. It is not certain to fail, but there is enough probability to have failures. You're introducing a failure mode at the moment you have an integration point. To avoid a single point of failure, you should have slightly improved error handling, failure mode handling, and backup mechanisms. So this is another failure mode. But when you weigh the pros and cons, yeah, the cons are less. But if you actively implement those things, you can overcome the cons through proper implementation. So these are the important aspects of fine grain versus Coast Grant.And if you see our exercise solution for previous access solutions, we have tried to implement the solution as a fine grained APIs.Okay, let us move on to the next parts of this particular section. Happy learning.

3. Layered Walk-through of the Solution

Hi, In this video, let us quickly go through the solution one more time to understand it deeper in its technical aspects. Okay, so what we discussed in the solution page is a high-level diagram and a few points. I hope that is self-explanatory, but still thought I'll just walk you through a bit deeper so that it will help in the next videos for the improvement in order to make the proper reuse of APIs and also the addressing of the underpass. Okay, so what you're looking at in front of you is again the same solution with the three-layered APA alignment in the Experiencelayer process layer in the system layer. So if you remember our business process, the very first diagram or small horizontal diagram we showed, it just addresses or shows that the business process today has exposed its CreateSales order via three mechanisms. One is via web service, one is via restservice and one is via the file-based interface. right? So that is why what we have done is we have taken that knowledge and thought, okay, these three are customer-side or consumer-side requests or requirements. As a result, we have placed two APIs, one of which is a great sales order web service based in the Experience layer, and another API, which is again a great sales order for theRest purposes, which is a Rest based API. Okay? And the third one is the file-based one, although it's not an API, it still has a customer base. That's why we have players in the topless but not inside the block of the experience layer, just to say that it is also a customer-oriented or customer-side layer. Okay, so for all these three, the technical aspect of how they differ is the first one, which is the Create Sales Order web Service. SOAP (or HTTP) is its technology interface. So all requests that are coming inside or that hit this great sales order of service, have to be submitted as a soap opera HTTP request. So when we say technology interface, it means the particular API is exposing its requestor functionality to other consumers. So they have to use the Opera HTTP technology interface. Okay? Then, for the remainder, which is to generate a sale, order the remainder of the service. The technology interface is JSON. The request has to come in JSON format. And whereas for the last one, which is file-based Create Sales Order, the technology interface is very self explanatory.It is a file-based system where in the file it could be a CSV or XML file. Let's say CSV for flat file where in each row we get one particular order, having columns like a customer number, customer siteorder number, item numbers, and locations. Okay? shipment locations Now, what happens today, as per the diagram you are seeing in front of you, is that each of these APIs is further divided into two process APIs,the web service or the Rest service. After getting the data, they both read the SOAP opera at the request of the JSON request and then call the process APIs which validate the external IDs and then, on successful validation, call the Create Sales Order API process API. Okay, so these two process APIs that they have expose the technology interface as JSON. So this is like having a conventional model. So apart from the experience layer, all the other layers in this organisation have decided that OK, we will expose or fix our technology interface for the process layer APIs and the system layer APIs as the JSON technology interface to keep things consistent and easy. So that across the organization, across the Llobbies, all the teams have an easy way to invoke the APIs and understand the requests and responses. Okay, then they can focus on the experience layer, where the experience layer's sole purpose is to meet the needs of the consumer. That is the layer where the technology interface might change. because some consumers may request a different protocol or way of consumption. And some of them who are also adopting JSON, it's easy for them to expose JSON. So that is the layer where we control the various technology interfaces or experiences. Okay, so these two are again exposing a JSON technology interface, and this experiencelayers will call this synchronously. First, this API is called the validated external ID. by passing the customer information, item information, and shipment location information. Following successful validation, they proceed to the next step, which is the creation of a Sales order Process API. The same is true for Rest-based and file-based APIs, and each of these process APIs, in turn, calls these various system layer APIs. For example, the validate external ID process API over the JSON technology interface again calls three different system layer APIs, which are validate item,validate customer ID, and validate shipment location ID. Those two are again called synchronously. The first sheet validates the item and the second sheet goes to the customer and the third sheet goes to the shipment location validation in a synchronous serial manner. Okay? Similarly, there is only one systemlayer API call over the JSON technology interface in the Create. This creates a sales order API. So these three system layer APIs are validated by validation EPS in turn calls for the texture of the system via some old adapter technology. Let's say Okay, because it's not a modern system. Let us, for this example's sake, assume that it is notJSON because it could be a DB adapter if it's aDB or if it's some old kind of DB. Not JDB. There is a different custom protocol. So it might be calling through some old technological interface. Similarly, if the ERP is not modern or is not compatible with modern connectivity, it may use an old interface. So that's two systems I'm just using an example to demonstrate that this old legacy stuff is only abstracted at the system layer. So, based on my experience, the system layer is entirely based on JSON technology. The system layer abstracts all legacy ones, while the experience layer addresses all consumer needs. OK, so this is the solution we have put forward for now, which meets the functional requirements of the business process. Now, like we gave a heads up or we saw that there was a heads up in the first introduction video, after functional requirements, many things come into play. Okay, first Nana comes into the picture, then the proper reason comes into picture. So in the next section, the next video, what we will be seeing is how we can improvise this particular solution to realign the APIs to maximise the reusability of this. Okay? And then after that, in the next video, we will see how we can address some of the NFRS with respect to performance and all right, happy learning.

4. Establishing Routines

Hi, We have made very good progress so far, right? Starting from the very basic scratch of the project in your organization, all the way till the point where we are about to implement the episode, we have seen alignment of the IT organizations, structures, and deploymentmodels. We have sorted a lot of stuff. And now we are ready to deep dive and jump into the implementation, which is also called the development phase, right? So that's really good progress. I hope you all got a lot of concepts and prerequisites in the first few videos and the first few sections. So now let us move on and understand some of the things that we need to adopt in this API world, which are important during the design or the implementation phase. So, while working on the last two assignments, you have identified and designed APIs,for example, business processes, right? The sales order business process in your organization So, the approach we took was to convert the business process knowledge we have into Apolloactivity, as this is from scratch and the very first process that is being adopted. There are no issues here. However, as we continue to expand our application architecture by implementing more business processes in the organisation across different lobs, you will need to ensure for some routines, you will need to adopt some routine habits in the designing of the APS and implementing the APS. You have to practise them and make them a habit in this API world. Okay? So what is that? For example, the first thing is always before implementing any API, you can design it, but before implementing any API, check first for the possibility of reusing an existing API. So, how do you do that? You do it by going to an anypoint exchange and searching for that API. You do need to know the exact name, right? Because if the API is published properly with documentation, any words or keywords that match will bring the API onto any point exchange. So try to search for that functionality if it has already existed as a published API. Okay? So you may have some doubt here. At an early stage or at the very early stage of adoption, exchange will not have any APS, right? Because at scratch, we have to start with square zero. Start right from scratch. So there will be nothing on the exchange. So, say at this stage, if more than one team started, luckily, in our example, only one business process was taken and started with that. So, you know, that is, you are the only one doing so. You published with the exchange. But because it's a very big IT project, two or more teams started working on this. Okay? And for all of them, it's zero APIs in the exchange. So then how do the teams know at this stage that there are some reusable APIs that are being built? So, how do they know that? So, in order to announce that you are already working on some APIs What you need to do is the second habit. You immediately need to create and publish thoseAPI details to the Any Point exchange. Okay, so what do we mean by publish what should be published there? Okay, when we say publish the API metadata, we mean publish the details spec. You do need to have a full implementation of the API yet,but if you publish the metadata and the details relevant to the API, that is enough for others to know. OK, this team is building the API so we can reuse this. Okay, so let's see in detail what we need to publish. So what should be going into the API published is the basic API specification. Technically speaking, a RAML specification for each of the APIs And this RAML should be created at any design centre for the best or simplest implementation. Because you have seen the point. design center, right? We will see you soon at the demonstration as well. So it helps you to easily create auto-suggestions and the best way to align your ramble and all. So, once created, this can be published to anypoint exchange from any point design centre only. Okay, so how do you indicate that these APIs are not ready yet? right? So, okay, you are publishing, but the other teams, how will they know whether this is already implemented as well as running? Or is it just like working progress? So to convey this, you have to use the versions. You can put the ramp version while creating the RAML assome V zero, so that they know it's a draft. Just as we put a draught version and all in the documentation in the world and allworld documents. Similarly, we can't put a draught here. We say V zero. Similarly, when publishing the set to the exchange,you can put the version number as 1,something like that, so that they know. OK, it's not yet 10, not at Vone, which means it's a work in progress, but it's going to be published or implemented soon. So during all this, the C for E is the one who helps you to design this rambleand publish it and do it in the right way. C-four is the team, the centre for enablement, right? They are the team in charge of guiding and assisting with all of these activities. They define the naming conventions, best practises for versioning and all. So they should be assisting the Lob teams and other teams in correctly defining and publishing to the Any Point Exchange. So let us now go into the demonstration and take our same existing use case of sales order and do these steps as if we are really implementing them. Alright, let's see you at the demonstration. Happy learning.

ExamSnap's Mulesoft MCPA - Level 1 Practice Test Questions and Exam Dumps, study guide, and video training course are complicated in premium bundle. The Exam Updated are monitored by Industry Leading IT Trainers with over 15 years of experience, Mulesoft MCPA - Level 1 Exam Dumps and Practice Test Questions cover all the Exam Objectives to make sure you pass your exam easily.