In my [previous blog post | Caffeine - ABAP to Go - The Motivation] I described the motivation and scope of the Caffeine project. This time I will get into a little more detail and explain some inner workings at concrete examples. As mentioned in the previous blog post, Caffeine is about implementing libraries in ABAP that can then be executed on multiple platforms. Since we are talking about libraries only and are expecting the actual application to be written in the native language on the target platform, the integration and usability of the generated libraries are very important factors to the success of the approach.* * I'd like to point out that Caffeine is currently a prototype project "fresh from the labs" and is not related to any current or future SAP product. h2. The Language Caffeine supports a subset of ABAP, but also added some extensions that come in handy for the new tasks it handles. I’d like to point out that the definition of the subset is still evolving and that I intentionally started with a rather small subset, which can be extended in case important use cases would require it. ABAP OO, for instance, is not part of it. One of the few new keywords introduced in “Caffeine ABAP” is the “service”. In the Caffeine world, everything is a service. In ABAP terms, a service is pretty much the same thing like a “function module”, but we decided to give it a different name to point out that it is not 100% the same. The remaining “ABAP subset” is corresponding 100% to the exact ABAP semantics as the section “Runtime” will elaborate on further down in this text. The currently supported ABAP subset goes back to ABAP’s roots and is based on functional programming paradigm and internal tables. This seems appropriate for the current focus of client side validation and business logic as well as for backend adaptation logic. The idea is to use ABAP as it was designed initially: A “business DSL” to read, manipulate and compose table oriented data. Let’s explain some aspects of the language at the example of some simple code snipplets. I assume the average reader of this blog to be somewhat ABAP savvy and will thus not explain the ABAP code semantics in detail but will focus on the additions. 
A service is defined using the "define service" keywords and follows the well-known ABAP syntax for method definitions. A service can have any number of importing and exporting parameters but does not know the concept of “changing” parameters. There is also a possibility to call services of course:
As you can see, calling a service works the EXACT same way as calling methods or functions in ABAP. Only the keyword is different. The following code snipplet is obviously not the most effective way of implementing the factorial operation, but is supposed to demonstrate some simple internal table operations at work: 
These are only a few example code snipplets; Caffeine supports more than the ABAP keywords you have seen so far. If you are curious about the details or just want to get your hands on and try it out, then you can download and test it yourself. You will find the instructions and a link further down in this text. h2. The Type System Caffeine currently supports a small set of primitive ABAP data types such as i (64 bit integer), f (double precision float), string and date. It also supports structure definitions ( “types:”) and internal tables which can each contain nested structures and tables. The question of the type system as a whole is not yet fully answered by Caffeine. ABAP invented the Data Dictionary for persistent and reusable type definitions and currently Caffeine does not provide such a concept. Instead, it reuses and maps existing backend type systems to local internal tables and structures. It thus creates a common type system in which a developer can use, combine and modify data from different sources in a uniform way. I implemented a demo integration using this approach for the last TechEd in Las Vegas using the River platform as backend. The following example demonstrates the implications on the syntax: 
A service is defined using the "define service" keywords and follows the well-known ABAP syntax for method definitions. A service can have any number of importing and exporting parameters but does not know the concept of “changing” parameters. There is also a possibility to call services of course:As you can see, calling a service works the EXACT same way as calling methods or functions in ABAP. Only the keyword is different. The following code snipplet is obviously not the most effective way of implementing the factorial operation, but is supposed to demonstrate some simple internal table operations at work: These are only a few example code snipplets; Caffeine supports more than the ABAP keywords you have seen so far. If you are curious about the details or just want to get your hands on and try it out, then you can download and test it yourself. You will find the instructions and a link further down in this text. h2. The Type System Caffeine currently supports a small set of primitive ABAP data types such as i (64 bit integer), f (double precision float), string and date. It also supports structure definitions ( “types:”) and internal tables which can each contain nested structures and tables. The question of the type system as a whole is not yet fully answered by Caffeine. ABAP invented the Data Dictionary for persistent and reusable type definitions and currently Caffeine does not provide such a concept. Instead, it reuses and maps existing backend type systems to local internal tables and structures. It thus creates a common type system in which a developer can use, combine and modify data from different sources in a uniform way. I implemented a demo integration using this approach for the last TechEd in Las Vegas using the River platform as backend. The following example demonstrates the implications on the syntax:
7 Comments
