I’d call myself an ABAP guy. Though I’ve done some Java time back and occasional web development as a hobby, the only serious programming language which I’d claim myself to have mastered is ABAP. Every year, this brings me into an uncomfortable situation when going to TechEd. Hardly anyone at SAP seems to actually care about me being able to earn money with the thing(s) I know. It’s been like this for the past years in Madrid and Amsterdam and looking at the agenda, I was sure it would be no different this year. Luckily at second sight, I was wrong.
For those who could not attend, I’d like to sketch where I have encountered news from the ABAP side. Of course, I was not able to join all the sessions I’d like to have joined, so I’d appreciate reading about your personal highlights as well!
Developer’s garage – get your own ABAP System now!
On the evening before day 1, developer’s garage was opened for the first time at . Idea was that developers could inform themselves about how to provide cool software on the technology stacks SAP is offering: HANA Cloud Platform, . River RDE and last but not least AS ABAP. I was brave enough to approach the SAP-crew waiting there despite the non- negative marketing for the AS ABAP. And I felt rewarded: Christopher Kaestner gave me an insight into what it takes to actually provide a stack upon which cloud systems can be deployed. Something I never cared about, but which was really interesting. And more important from a practical side, he instructed me how to use the SAP Cloud Appliance Library and how to set-up my ABAP on HANA-system using it.
While this is easy, it’s still a comparatively risky thing if you’re having your large HANA-instance run for a long time, particularly if you don’t have a real business case you’re working on but if you’re doing this merely for personal education (about 1€/h). However, there are cheaper alternatives: There’s also a virtualized version of the AS ABAP on which has much lower hardware-requirements (currently <25€/month). Why not develop the core of your application on another DB and start the HANA-based instance only if you’re doing the actual HANA-specific part? Anyway, it’s good style to use interfaces and alternative implementations on other databases and I believe that the actual HANA-power will only be required for few operations (just speaking of the ABAP on Hana-, not of the HANA XS-developer, of course). This is how I’ll most probably try it. Once the “on MaxDB-System” is on the same SP-level (currently, it’s quite old, SP02).
The cheapest variant would of course be if it was possible to get an AS ABAP trial run on a local machine and what was said in the garage leaves me in an optimistic mood that we’ll not have to wait for this another two years (I promised Christopher not to post how quickly they plan to provide this, as everything which is said at TechEd anyway is subject to change).
Key note – an ABAP container in HCP?
Many posts have already spoken about the keynote. Also I found it very refreshing but at the same time had the impression, that SAP has not forgotten its roots. Even BSEG had a short but important appearance. With respect to ABAP, there was nothing explicitly said, but promising enough, there was a slide picturing the future layering of the SAP development structure. With HANA in its core, the HCP is the -environment into which applications are being deployed: , HANAXS, HTML5 well, and ABAP. At least according to the slide shown.
after TechEd, Bjoern Goerke unfortunately disclaimed. We might have to wait some time longer until we can actually deploy our artifacts to the HCP. I guess that enabling the TMS for multi-tenancy (multiple isolated spaces in which the workbench-objects live on the same server) might be a bit tricky.
Lectures on ABAP on HANA and Core Data Services (CDS)
Also during day 1, I attended two sessions hosted about enhancements on ABAP. Carine Tchoutouo Djomo presented very nicely various aspects of the code-to-data paradigm (aka. Code pushdown). And largely, this has nothing to do with HANA, but with the general avoidance of transport of data between the database and the application server. Majorly, this was about
- The vast enhancements to
- Tools which help analyzing performance of database access dynamically (SQLM) and to combine this is information into a check-cockpit (SWLT)
- The new ALV for and with database-based paging
Only ABAP managed database procedures, which allow to code a stored procedure inside the ABAP are specific to HANA. Currently. From a -perspective, there is no limitation to HANA as DB, but the database vendor has to implement a set of libraries in order to enable coding in its stored procedure language. And I guess SAP has to be kind enough to accept his contribution and enable a keyword for it. Whether will see the statement LANGUAGE PL_SQL in the next years might be subject to the result of the next America’s cup race. I don’t have to go more into detail here as was so kind to record all the demos and make them available here on SCN.
I wish this was a common best practice for other topics as well. Briefly addressed in this session were also the mighty Core Data Services. This new artefact which can be modeled in eclipse replaces DDIC views. Of course, you’ll still be able to use se11-based DB views also after 7.40, but CDS-views are so much more powerful. Basically you can model the FROM-clause of your statically. Without limitations to inner-joins, join-on-join etc. But , a CDS-view is much more powerful as it also allows to define structured data-relations: A view always has a “flattened” result-structure. Within a CDS-view, also associations can be defined so that to me a CDS-view seems to be the ideal artifact for providing an OData service. To me, this CDS-core is the most powerful change in ABAP during the past years and a major reason to upgrade to 7.40. However, with respect to its extended capabilities, I’m a bit :
- CDS supports annotations which can be interpreted by a CDS-consumer, e. g. whether an attribute can be used as in some analytical artifact. Honestly, I don’t like this with respect to layering: The consumer should be attributing characteristics to CDS-entities, not the other way round.
- CDS is being positioned as the access layer for any kind of consumer who wants to get data out of the system. However, there are other technologies at “higher” architectural layers which serve a similar purpose. Most important to me: SADL, the service adaptation definition language. It can also build views on top of various artifacts including DB tables, but also more rich entities such as BOPF business objects. This is also necessary from my point of view as particularly for write-accesses further data transformation or validation might be necessary which CDS by its nature cannot provide. In addition, not all data is persisted. For this case, CDS support various expression types (aggregations, case-statements). But not every transient information can be determined using them – or the resulting code would be not maintainable.
My conclusion on CDS is that I highly appreciate it for its extended capabilities, but I’ll not use the annotations unless required by a runtime engine.
Now, last but not least, this is not an ABAP-topic, is it? No, it definitely isn’t (at least not until Björn Görke announces the ABAP-container in HCP). But it impacts the way backend applications in ABAP need to be implemented (shameless cross-link). Also, I feel that despite this beautiful new UI technology has matured, there is still a need for business applications to be developed in ABAP. I simply cannot imagine a productive way of building for business applications with integration to SAP products (e. g. the business suite) with the same efficiency as in ABAP. And this is not only about the actual laguage and ABAP runtime: The toolsets around business needs (roles and authorization, software logistics, integrated testing, output management, customizing, business rules, …) are very well established and even if not technologically brilliant in some places, they are known to SAP operations teams. What I’m particularly missing in this new technological layer is some application level framework like BOPF which helps to modularize semantically and which reduces the tasks of the developer on developing “business logic” – since this still is what most SAP-projects are being instantiated for.
ABAP is not dead at all. In fact, it’s currently being renovated not only with respect to syntax (If you have not yet read Horst Keller’s blogs about SP08-Language enhancements, do that right now), but it’s also getting enhanced with artifacts which allow a good integration into the other state-of-the-art-technologies by SAP (HANA, OData). For me, this means that I need to do the following:
- Understand SAPs current technologies and its impacts on application architecture
- Learn to master the interface-technologies from the ABAP-side (hoping that BOPF and SADL help me out on implementing lots of the OData-contract on my own)
- Understand the common architectural principles and further improve on my custom application’s architecture. The patterns apply for other platforms as well – and knowing them well simplifies switching to other platforms if necessary.