[0:00]Hello everyone, welcome back to SAP Technomaniac. This is the second part of our SAP Clean Core playlist.
[0:09]In this part, we will discuss about what is SAP extensibility model, what is on stack extension, what is side-by-side extension. In the second part of this video, we will see how we can divide our custom object in Tier 1, Tier 2, and Tier 3. That got obsolete. Now we have newer model to divide our custom object at the level A, level B, level C and level D based on the clean code, how much they are clean. So let get started. There are two approaches for the extensibility. First, what is extensibility means? I want to enhance the SAP standard code without modifying the core system. There is a two way, I can do on stack extensions, second is the side-by-side extensions. I can create another video to explain these entire things, but I just want to give little bit of you here. On stack on stack extensions means we are doing the extension within the SAP S4 Hana system. It can be on premise or cloud and side-by-side extensions means instead of doing those extension within the system, I am getting the data from this system and doing the enhancement in BTP. So that is called the side-by-side extensions. Both the approaches are completely clean code. Let's talk little bit more about the these both the extensions. The on stack on stack extension is I told you, it is it will be within the SAP S4 Hana system. It can be the on premise system, public cloud or private cloud, anything can be there, but it will be within the SAP S4 Hana system. Some of the example I can see the advantage of there, it is a tightly coupled because we have directly data access. Just we can go and do the enhancement wherever the SAP given us options. Some of the example, you can, if you want to create the new wrap application, that is also part of the, obviously we are extending the functionality. We are if we are utilizing the released API within our wrap application and we are building that particular wrap application, it will come under the clean code only. But we have to make sure we are only using the release API. If you are not using release APIs, then it will not come under the clean code. Second thing, if you want to enhance the SAP standard provided apps using the CFL, custom field and logic app, you can go directly in the additional field, you activate those fields in the different, different application or even you are working in the legacy system. Not legacy, I can say, if you're working with the GUI system, there also you can create the screens from the CFL app along with the fury app. So that is a part of clean code again. Third thing, uh, if you are doing any kind of app cloud development, you are building new tables, you are building the release CDS view, but make sure whenever you are doing anything new, you have to use only the release objects. Based on the what you are using, it will decide your objects are clean code or not. Let's me move on to the side-by-side extensibility. It is little bit different. Instead of modifying those code within the SAP S4 Hana system, what we are doing, whatever we need from this system, we are exposing that is a API to the BTP. And there we are building the new application using this particular data as per our requirement. There are different scenarios are there, if I want to build an application, which should not be the strongly coupled to the my SAP S4 Hana system and I am utilizing not only the SAP S4 Hana system, I am utilizing the data from the other system, which is not part of SAP S4 Hana, and then I want to build some application, then I can go with the side-by-side accession. This is one of the example. Second, I want to build my product, that product I want to give the different, different companies at the BTP platform, that kind of application I want to build, again, I can go with the side-by-side accession. The technology wise, it will be little bit different. You can use the, uh, Cap M. You can use wrap as well. But if you are doing the side-by-side extension, better to go with Cap M because there is a lot of other things are there, multi-tenancy and a lot of other things, you can utilize that. But if you're building on the on stack, because there is no Cap M, no JavaScript in the SAP S4 Hana system, we have to go with the wrap only. So if you are doing the side-by-side extension, again, if you can do with the wrap also, there is not, if you know app, you are confident, then you can go ahead with the wrap as well. Then there is a if you are working in the BTP, there is a SAP builds app, integration services, everything's available there. If you need small amount of data and you need some other data, or you want to build some product for the companies, or you want to build some application, which will be not used by the SAP internal users, instead of it will be used by the your customers and partner. And you don't want to give the access directly to your system to the end user. Just you want to expose those application through the BTP platform, then you can go with the side-by-side extensibility. I have given the lemon term, small, small example. We can go in depth if I get a chance, I can create a stain alone video on that as well. Clean core extensibility level, you might have heard about the clean core flag classification, like Tier 1, Tier 2, and Tier 3. Now that is upgraded to Level A, Level B, Level C and Level D. The previous one, how it was, if SAP gives some released object, then all those released object will fall under Level A. Means it should be released for the cloud development. What I mean by release? It release for the cloud development or key user extensibility or it is released for the outside SAP interface users API. That is a different context C0, C1, C2. Depends on that, it giving the, the these are the released object, you can use as part of your objects because it will be working if you upgrade it to cloud. These were fall under Tier 1. But there are not most of the objects are, what we need, those not fall under under Tier 1, especially you are working in the lower version. Then Tier 2, how it was working? If something is not available, and your classical API is available some BAPI, then create the wrapper around it and use that, that will come under Tier 2. And then again, there is another category was there, Tier 3, where is the purely classical classical things were there, which is not released at all, and SAP just using it's part of the SAP standard software that fall under Tier 3. In this concept, the issue was there, creating the wrapper and using them, once the release APIs are available, removing them instead of them using the release API. It takes lot of effort. Why we need to create the wrappers and release them and use in the cloud development? Then this is the little bit confusing and code, which object, what kind of wrapper I need to create for function module, what is the way for tables, what is the way, or if I am using class, how to create the wrapper for those class, standard classes. So there was lot of confusion around that. Then SAP come up with this new model. I think this will look little bit different and it, I feel that it is very good way. If we have lot of legacy code, then we can easily classify that our code is fall under Level A, Level B, Level C and Level D. No need to put extra effort to create wrapper and all the things. SAP simply saying if we have released some object for the cloud development, they fall, they fall under Level A. How to check those one? I will show you after this slide, no need to worry. And if something is a classical APIs, means we are using lot of classical things. Like released BAPIs are there, lot of standard iDocs are there, which is working flawlessly, we no need to worry. It's working from the years and it's are stable one. Apart from that, we have, uh, function module, we have the customer exit, classical BADI are there, even user exits are there.
[9:07]Those all fell under the Level B. Even if I take simple example MV45A, FZZ, there are lot of, most of the guys, I know, aware about this. That is the reason I am taking this example, that also fall under the Level B. The one catch is there here. If something is available in Level A, then we should not use Level B. Suppose I'm giving one example. Again, same MV45A FZZ, when we are doing, previously if we have to edit the one custom field in the sales order for the our business requirement, we used to append the VB A K, VB A P structure. Then create the screen enhancement in additional tape, customer additional tape, and then we used to write the code in the that MV45 A B Z Z, wherever the exits are available. That was the way, that was the Level B. But SAP already given the new app application, sales order, many sales order app with latest version V2 version, you see. Not the older one, older one open VA01, VA02 directly even you are opening in the application, but the next version V2, those you have to custom app, you have to add the custom app, then you have to use the CFL. I'm giving little bit of view. We'll talk when we go in depth extensibility, but just we have to use custom field logic app, add those custom fields, and SAP provided already now SD BAPIs, those sales order related BAPI where you, you can modify the standard fields. Then this is available part A, as part of the cloud development. So it fall under Level A. So something is available in Level A, you should use Level A only.
[11:29]Because that is the cloud stable. If future your clients want to move to cloud, public cloud, they can easily move. Private cloud, anyway, we can use the SAP GUI also, rise with SAP, that also we can use. If you're going for public cloud in future, if you have plan, or if you not only the if you have plan for the future, if you want that your system is stable during the upgrade, go upper level always. Then Level B is a classical API as I told you. One of the example MV45 A B Z Z. Apart from that, a lot of things are there. BAPIs are there, exits, customer exit, classical BAPIs are there. I will create a list PDF and give you what falls under the Level B and what falls under the Level A. Again, if you're talking about the framework, if you use the latest and greatest wrap framework for your development, wrap application, you will create that fall under Level A. If you are still using SC GW, that fall under Level B, to creating the APIs or applications that fall under Level B. So we have the framework. If you are doing some custom development, obviously you have to create using the wrap framework only. Again, there, whenever you are utilizing, try to utilize all the release objects only, wherever possible. Then we have the Level C. Level C is the something like that. We have the SAP internal objects, uh, like uh, lot of the NAS protocol update function module, some of the example I'm giving. Some of the tables, uh, which is NST table is there, SYST table is there. Those are not released yet, if you see for the cloud development. As of now, it is not released, but in future it might released or it might not released.
[13:24]We are not sure yet. Again, some function module will be released for the customer development, that fall into Level B, but not if there is no release status in the function module, then it fall under Level C. It might release or not release, we are not sure yet. So those these kind of object, which we are using and not come under Level A and Level B, either it is a classical API, which is given by SAP, you can use, or no, it is in Level A, that is the cloud development APIs. Um, then it will fall under Level C. In this Level C, what is the problem with the Level C is that most of the, this Level C, we are not sure it will go to Level B, Level B, or it will go to the Level D. And the Level D is the very dangerous zone. Uh, I mean the dangerous zones means, if you are doing some modification, you are using the implicit enhancement, which is available at the beginning and end of the includes and class. You're using the class exit or writing class. Those kind of things if you are doing, then those fall into Level D. You should not use the implicit enhancement at all. Uh, that is the SAP recommendation because those will modify the SAP standard code, and it will be not supported neither in normally SAP SAP, if you are working in ACC also, you should avoid. Even S4 Hana, in future, it will not supported. So those are the high level of classification. I have given the some example over here, again, I can iterate, uh, these all classical things. BAPIs, iDocs, classical BAPIs will fall under Level B, and rap applications, release CDS view. Release CDS view also can be released and normal CDS. If you are using the unreleased CDS view, that fall under Level C. That is, it's not like that, you're using latest technology, it's not always there. If you're using unreleased CDS, unreleased business object, that fall under Level C. That might come to the Level A or not come. We are not sure. And ABAP cloud development you have to use, so in the property section, I will show you, each object, you when you go to the property sections, we have the standard ABAP or ABAP, ABAP for cloud development. So those again we can identify. I will show you after this slide, those all the things in the system as well. And I will show you the cloudification repository, that, that is very good repository created by SAP. It is available for all the, it's over the internet. We can easily search it available on GitHub. I will show you how to use that one also. And something, uh, these are the direct access to SAP table, obviously it is not required. You have to use released CDS view. If you're creating custom table, for that also you have to create the released CDS view, on top of that, released custom CDS view, then you have to use. You should not use implicit enhancement, internal SAP classes, those fall under Level C, as I told you. Level D, something, uh, already obsolete. I would say, if you're developing some new objects, avoid SC GW, that is gone. Completely, you have to use, come to the rap. Some, uh, you should not use web Intro, obviously, that is not no more supported. Means it's backward compatibility wise, might be supported, but it is not supported in the, if you're creating something new, you should what is the purpose of going to web Intro? Those kind of things already obsolete. So if you are doing new development and doing this thing, you are harming your customers, which you are supporting, you should not do. You should avoid the, if you, if you want to do some enhancement also, and the application is simpler, means switch to rap now, directly. So it will support your customer just suggest them it is not good way to go. In future, it will gonna go. In cloud, we don't have web Intro or GUIs, those two things are not, slowly, slowly everything's moving to Fury. Uh, this is all about the suggestions. This is the one of the picture recently I have uploaded on the LinkedIn. Uh, if you're not following me on the LinkedIn, you can check it out the link in my channel and go and follow. Most of the time, I didn't get to time to reply lot of messages nowadays I'm getting, but I try to reply as much as possible. If you guys are asking your project decision, definitely I'm not having that much time. So in the Level A, means released API, you are very green. When, whenever you want to move, you want to move to the cloud. Level B, if you are using still classical API, it will be the upgrade safe. If you're doing the on premise, you are using, you're going for one version to another version, it will be upgrade safe. Level C means, this is dangerous zone, I can say. It might fall into Level B or Level A in future or it might go to the Level D. If it go to Level D, Level D is not recommended at all. You are using obsolete, deprecated API. How to search those also, I will show you right away. Let me open my browser and show you this all the things, how to find Level A, Level B, Level C and Level D. In this video, we learn about the extensibility model and how we can classify SAP standard or custom object in the Level A, B, C and D category. In my next video, we will see how to find out one SAP object is fall under which category. There, cloudification repository, which is available online will rescue us. How to use this one? We will learn. Not only that, if you want to utilize the Eclipse ABAP repository tree to identify your objects are released or deprecated. That also we will learn how we can use Eclipse to find out the objects are released, not released or deprecated or we have some successor object for these unreleased objects or not. That we will do, obviously, in the next video. Before going to next video, subscribe this channel, like this video, comment it down, whatever you are feeling, share this videos with others as well. With that, thank you and happy learning.
