This is the third blog in a sequence of several about the Composite Application Framework (CAF). Please also take a look into the first What is the Composite Application Framework? and second blog CAF II - Which Tools Does SAP Provide?.
Our guest, that we have the honor of serving today, ordered a filet mignon, cooked medium rare, with red wine sauce. As side dishes we will prepare rice, vegetables and French fries, topped by some eggs sunny-side-up. And as our guest loves good dining, a bottle of good French wine rounds out the order.
What does the chef have to do? 'Filet mignon' means that he has to go to the refrigerator, open it, and take out the meat. In the same storage area there are the eggs, and the vegetables are in the corresponding drawer, also in the refrigerator. Rice comes in a bag and is stored in a dry location on the other side of the kitchen. The same is true for potatoes, with the only difference that potatoes should be stored in a darker location. Flour, salt, oil, spices etc. are stored in bottles, cans, glasses and other storage devices on the shelves of the kitchen. Red wine for the sauce is in the wine cellar, which is normally downstairs for proper climate control of such precious things as wine.
The meat must now be unwrapped, the eggshells broken, the rice taken out of the bag and put into a rice cooker, vegetables washed, potatoes peeled and the bottle of red wine opened and poured into the pot for preparing the sauce.
Our user, that we have the honor of serving data to today, wants data about all sales, which are in status "pending", from sales region France. Additional infomation needed is the customer information, product documentation and which sales rep closed the deal, accompanied by the profit margin of each deal and topped by comments from colleagues about the specific deals. And as our user loves good data, the sales forecast for this period in this region rounds out his request.
You can see from this request that data in different forms and from distributed storage areas is needed and prepared. Sales and customer data is most likely coming from a CRM-system. Product information, as long as it is structured, comes probably from an R/3-system, except the product documentation in the form of PDFs and image files, which resides in a Content Management system. Profitability and comments represent an extension to existing functionality and therefore are retrieved and calculated from xApp's own persistency. The sales forecast comes from the data warehouse.
This "simple" example already shows the challenges for the architecture and tools. Existing storages and applications have to be used, new ones created and formed into new menus - read: applications.
What does it mean for our chef, the developer? Once again "xApp-fish" helps to translate:
Now imagine the developer working on a new application: finding out where the data is stored, what APIs have to be called to retrieve the data and how to transform them is difficult. Especially as our developer works for a customer who thinks right at the beginning they could use the default settings but then starts to customize heavily. Now imagine the developer doesn't have to learn how to call an R/3-BAPI, a Content Management API, a database, etc. to retrieve the needed data, doing all that with different programming languages and mapping tools and metadata storages. Wouldn't it be nice just to tell the Content Management to bring back all documents related to this product-ID and do that in the same tool which brings back the customer's data? And the only thing we have to know to speak to all of the "servants" is the same language in the same structure, known as an interface?
Finally, coming to the point, here we are:
this tool, which helps us to use the tools and build the basis of the applications, we call the Business Object Modeler.
The CAF object layer offers the Business Object Modeler to model the structure of objects, the relations, the mapping to XI proxies and other technical and semantic properties of Business Objects and ValueSets. It provides an object metamodel (as part of the service metamodel), a generation framework to generate runtime implementations of Business Objects and runtime extensions for these objects like a data access framework.
With the Business Object Modeler, Business Objects, ValueSets and methods can be created. A Business Object consists of tables and methods. The task of a Business Object is mainly to store and access data. Business Objects only contain life-cycle methods. Methods which have the characteristic of business logic or which access data from other Business Objects will be created with the Service Modeller.
Technically
From a technical point of view the Business Object Modeler is a plugin for Eclipse, and will be included in the SAP NetWeaver Developer Studio. The Eclipse perspective is called Composite Application Modeler and consists of the Business Object Modeler and the Service Modeler and offers connections to the Guided Procedures tools and Web Dynpro (which itself is a separate perspective in Eclipse).
Screenshot
Now that we know a little bit about the meaning of the Business Object Modeler, let's take a look at the tool itself (see also the attached screenshot):
Figure 1: Attribute tabstrip in the Business Object Modeler
On the left-hand side all CAF projects can be seen with all their Business Objects, ValueSets, Services, etc. By creating a new or editing an existing Business Object, the Business Object Editor with several tabstrips is launched. On those tabstrips general parameters (name of Business Object, owner, change date, etc.), attribute and data-dictionary information (attributes and relations to other Business Objects and ValueSets), methods (additional methods, search-by-methods,...), proxy-information (how the objects are mapped to methods and fields of APIs from backends), authorizations,... can be maintained. Finally, the last tabstrip contains what we have been waiting for so long, namely the coding generated out of the definitions maintained at the former tabstrips.
The CAF project uses several other projects in the background. They include a Java project, a DDIC project and an EJB project. In those projects the information is stored in the form of XMLs for the metadata, EJBs, DDIC-objects and also, on the XI for the mapping information to backends like R/3, BW or third-party systems.
Take a closer look at the screenshot, it shows the attribute tabstrip: here we see on the left tree of the editor Business Objects and ValueSets which are available in the current project and the so called CORE project. The latter one is something like a shared library, which comes with Business Objects, ValueSets, Patterns, Services,... used by all projects (e.g. Customer, Product, Country, Document, Searchpattern, Currency-Conversion,...). On the right tree we see our currently edited Business Object and its attibutes. By simply dragging and dropping a Business Object from the left to the right tree, we create an attribute - a reference to another Business Object. By editing the property-pane in the bottom we can change the settings and select, e.g. 1..1- or 1..n-relations, set time and language dependencies of the Business Object, add simple attributes, set keys, change the datatype, etc... By simply dragging and dropping we create a whole new universe of coding and metadata. Which brings us to the point: all parameters that are changed and defined are stored in a number of XML-metadata files. Out of those metadata files, coding can be generated. Currently the CAF allows you to create EJBs, but in the future the creation of ABAP, .NET, etc. coding would be possible as well since every piece of information is stored in those metadata files.
This fact also allows us to easily change and customize existing and delivered applications by simply using the Modelers included in the Composite Application Modeler. And upgrades are easier to be done as it requires "only" to merge metadata and regenerate the coding.
When all objects for your application are ready, then you deploy the whole project. During deployment, tables in the database are generated and the coding put in the right engine locations. There are also the runtime parts of the object layer waiting to be used by your project. The application (at least the persistency) is ready.
What you did here with a few mouse clicks generates dozens of tables and methods. Imagine how much time it would take you, if you had to define and create them all manually? The time you can save is tremendous.
Take your breath, lean back, sip on your cup of coffee or tea and sort your thoughts. Your questions might be:
Q: Where do I write my SQLs?
Q: Can I add coding?
Q: Is there really no need to code? Does it mean I as a developer or consultant will become superfluous?
Q: Sounds too good to be true?
Q: Does that sound similar to UML or other modeling tools?
And the developers, who know how to cook with the programming platforms but are not as firm in business processes, can focus now on the "real-developer" stuff and don't have to deal with those always-foggy business scenarios.
Let's face it: the ratio of misunderstanding between those team members due to their background and use of terminology can have a significant impact on the outcome, to no one's satisfaction. This is going to change for the benefit of all sides involved.
No need to throw cakes into each other's faces, but only in the movies...
Introduction
The object layer is the fundamental tool of every application. In this layer the definition of the persistency and the life-cycle methods are created and stored. How data is stored and accessed depends on the type of data, the data history and the business need.The Menu - from a Chef's Perspective
Let's compare our object layer with the situation a chef of a fancy restaurant faces in his kitchen:Our guest, that we have the honor of serving today, ordered a filet mignon, cooked medium rare, with red wine sauce. As side dishes we will prepare rice, vegetables and French fries, topped by some eggs sunny-side-up. And as our guest loves good dining, a bottle of good French wine rounds out the order.
What does the chef have to do? 'Filet mignon' means that he has to go to the refrigerator, open it, and take out the meat. In the same storage area there are the eggs, and the vegetables are in the corresponding drawer, also in the refrigerator. Rice comes in a bag and is stored in a dry location on the other side of the kitchen. The same is true for potatoes, with the only difference that potatoes should be stored in a darker location. Flour, salt, oil, spices etc. are stored in bottles, cans, glasses and other storage devices on the shelves of the kitchen. Red wine for the sauce is in the wine cellar, which is normally downstairs for proper climate control of such precious things as wine.
The meat must now be unwrapped, the eggshells broken, the rice taken out of the bag and put into a rice cooker, vegetables washed, potatoes peeled and the bottle of red wine opened and poured into the pot for preparing the sauce.
The Menu - from a Developer's Perspective
Hungry now? Let's go data-crunching then and translate the example above with our translation tool "xApp-fish" from kitchen-speak to object-layer-speak:Our user, that we have the honor of serving data to today, wants data about all sales, which are in status "pending", from sales region France. Additional infomation needed is the customer information, product documentation and which sales rep closed the deal, accompanied by the profit margin of each deal and topped by comments from colleagues about the specific deals. And as our user loves good data, the sales forecast for this period in this region rounds out his request.
You can see from this request that data in different forms and from distributed storage areas is needed and prepared. Sales and customer data is most likely coming from a CRM-system. Product information, as long as it is structured, comes probably from an R/3-system, except the product documentation in the form of PDFs and image files, which resides in a Content Management system. Profitability and comments represent an extension to existing functionality and therefore are retrieved and calculated from xApp's own persistency. The sales forecast comes from the data warehouse.
This "simple" example already shows the challenges for the architecture and tools. Existing storages and applications have to be used, new ones created and formed into new menus - read: applications.
Business Object Modeler
Now imagine a chef working on new menus and new ingredients: finding the storage place for those ingredients, how to open the storage, and how to bring them together is difficult. Especially as our chef is working in one of those restaurants where every customer makes his own menu. Now imagine that the chef doesn't have to run between all those storage locations and doesn't have to know for each one of them how to open and retrieve the needed ingredient (how to open the door of the fridge, how to open the can, how to uncork the wine bottle, how to break the eggshells, how to untie the rice bag, cut the plastic bag,...), doing all that with different tools and devices. Instead specialized servants bring the ingredients to him in the state and quantity he requested. And the only thing the chef has to learn is to speak to the servant. And the language and syntax for each of them is the same: "2 egg yolks, please", "5 cups of water", "1 slice of meat", but not "break the 2 eggshells and separate the egg yolks from the egg whites and give me the yolks only" or "turn on the water by turning the faucet on and measuring 5 cups of water" etc.What does it mean for our chef, the developer? Once again "xApp-fish" helps to translate:
Now imagine the developer working on a new application: finding out where the data is stored, what APIs have to be called to retrieve the data and how to transform them is difficult. Especially as our developer works for a customer who thinks right at the beginning they could use the default settings but then starts to customize heavily. Now imagine the developer doesn't have to learn how to call an R/3-BAPI, a Content Management API, a database, etc. to retrieve the needed data, doing all that with different programming languages and mapping tools and metadata storages. Wouldn't it be nice just to tell the Content Management to bring back all documents related to this product-ID and do that in the same tool which brings back the customer's data? And the only thing we have to know to speak to all of the "servants" is the same language in the same structure, known as an interface?
Finally, coming to the point, here we are:
this tool, which helps us to use the tools and build the basis of the applications, we call the Business Object Modeler.
The CAF object layer offers the Business Object Modeler to model the structure of objects, the relations, the mapping to XI proxies and other technical and semantic properties of Business Objects and ValueSets. It provides an object metamodel (as part of the service metamodel), a generation framework to generate runtime implementations of Business Objects and runtime extensions for these objects like a data access framework.
With the Business Object Modeler, Business Objects, ValueSets and methods can be created. A Business Object consists of tables and methods. The task of a Business Object is mainly to store and access data. Business Objects only contain life-cycle methods. Methods which have the characteristic of business logic or which access data from other Business Objects will be created with the Service Modeller.
Technically
From a technical point of view the Business Object Modeler is a plugin for Eclipse, and will be included in the SAP NetWeaver Developer Studio. The Eclipse perspective is called Composite Application Modeler and consists of the Business Object Modeler and the Service Modeler and offers connections to the Guided Procedures tools and Web Dynpro (which itself is a separate perspective in Eclipse).
Screenshot
Now that we know a little bit about the meaning of the Business Object Modeler, let's take a look at the tool itself (see also the attached screenshot):
Figure 1: Attribute tabstrip in the Business Object Modeler
On the left-hand side all CAF projects can be seen with all their Business Objects, ValueSets, Services, etc. By creating a new or editing an existing Business Object, the Business Object Editor with several tabstrips is launched. On those tabstrips general parameters (name of Business Object, owner, change date, etc.), attribute and data-dictionary information (attributes and relations to other Business Objects and ValueSets), methods (additional methods, search-by-methods,...), proxy-information (how the objects are mapped to methods and fields of APIs from backends), authorizations,... can be maintained. Finally, the last tabstrip contains what we have been waiting for so long, namely the coding generated out of the definitions maintained at the former tabstrips.
The CAF project uses several other projects in the background. They include a Java project, a DDIC project and an EJB project. In those projects the information is stored in the form of XMLs for the metadata, EJBs, DDIC-objects and also, on the XI for the mapping information to backends like R/3, BW or third-party systems.
Take a closer look at the screenshot, it shows the attribute tabstrip: here we see on the left tree of the editor Business Objects and ValueSets which are available in the current project and the so called CORE project. The latter one is something like a shared library, which comes with Business Objects, ValueSets, Patterns, Services,... used by all projects (e.g. Customer, Product, Country, Document, Searchpattern, Currency-Conversion,...). On the right tree we see our currently edited Business Object and its attibutes. By simply dragging and dropping a Business Object from the left to the right tree, we create an attribute - a reference to another Business Object. By editing the property-pane in the bottom we can change the settings and select, e.g. 1..1- or 1..n-relations, set time and language dependencies of the Business Object, add simple attributes, set keys, change the datatype, etc... By simply dragging and dropping we create a whole new universe of coding and metadata. Which brings us to the point: all parameters that are changed and defined are stored in a number of XML-metadata files. Out of those metadata files, coding can be generated. Currently the CAF allows you to create EJBs, but in the future the creation of ABAP, .NET, etc. coding would be possible as well since every piece of information is stored in those metadata files.
This fact also allows us to easily change and customize existing and delivered applications by simply using the Modelers included in the Composite Application Modeler. And upgrades are easier to be done as it requires "only" to merge metadata and regenerate the coding.
When all objects for your application are ready, then you deploy the whole project. During deployment, tables in the database are generated and the coding put in the right engine locations. There are also the runtime parts of the object layer waiting to be used by your project. The application (at least the persistency) is ready.
What you did here with a few mouse clicks generates dozens of tables and methods. Imagine how much time it would take you, if you had to define and create them all manually? The time you can save is tremendous.
Take your breath, lean back, sip on your cup of coffee or tea and sort your thoughts. Your questions might be:
Q: Where do I write my SQLs?
A: Nowhere. That's done for you by the framework. You just define the structure and everything else, from methods to add, delete, change and search data and the database structures will be generated for you.
Q: Can I add coding?
A: Sure you can, by specifying additional methods. But the less need for it, the less programming-platform-dependent your application is.
Q: Is there really no need to code? Does it mean I as a developer or consultant will become superfluous?
A: There is not much need to code, especially not for those stupid and default life-cycle methods. You will be able to focus much more on the more interesting parts like business logic or integration of other systems.
Q: Sounds too good to be true?
A: Sounds good, yes. But is it true and a sustainable concept? SAP is successful with its Business Information Warehouse, which is using a very similar concept and metadata approach for the analytical area. Now we take that concept and implement it on the transactional area. And you can be sure it works and will be gradually enhanced in its functionality.
Q: Does that sound similar to UML or other modeling tools?
A: That is only true from a first glance, but you will see that it's in fact very different. The CAF does not talk about class models, but of business objects and their relations. That classes, beans and tables are generated in the background is important for you, but not relevant for your modeling work. And the CAF is something for mainly building business applications, but not any kind of application. For the business applications that means you can focus on your object relations, processes and business logic.Actually the last question leads me to another interesting topic: the CAF enables people who know and define the business process, but don't know how to program, to also develop parts of the business application on their own. There is no need for them to type in code. This not only helps them to contribute in a new way to application development, but also gives them the chance to adapt their models much faster.
And the developers, who know how to cook with the programming platforms but are not as firm in business processes, can focus now on the "real-developer" stuff and don't have to deal with those always-foggy business scenarios.
Let's face it: the ratio of misunderstanding between those team members due to their background and use of terminology can have a significant impact on the outcome, to no one's satisfaction. This is going to change for the benefit of all sides involved.
No need to throw cakes into each other's faces, but only in the movies...
Coming to This Restaurant
Next week we will talk about how to serve the menu - pardon - the User Interface, of course. Recipes and cookbooks (i.e. service-layer) are only discussed during the meal, that means after we speak about the UI. That's where we are leaving the CAF for today. Surely you can guess that it's now lunch time, so I have to end this blog, as it made me somehow quite hungry...
18 Comments