Quo Vadis ABAP? I am worried.
ABAP is getting more and more database-specific features – and this make me worry. Please don’t understand me wrong – I have no problem with SAP’s technological strategy but with SAP’s communication und documentation. And I’m convinced that this will lead to severe problems unless SAP decides to deliver better documentation.
SAP said it loud and clear: not every feature of ABAP language is supported on every database platform – typical examples are ADMP and CDS with parameters. With parameterized CDS you can do amazing things: operational reporting, fast queries, and it is a very powerful tool for code pushdown to the database.
Before reading the next section I would like you to answer following questions about NW 7.40:
- Do you know which DBMS of the PAM support parameterized CDS?
- Supposed you have a complex SAP landscape with different DBMS: How do you find out whether parameterized CDS is supported in your landscape?
- Supposed you are an SAP Partner and your solution uses parameterized CDS – do you know on which DBMS your solution runs?
The answer is difficult since in NW 7.40 parameterized CDS is not supported on every DBMS of the PAM. SAP doesn’t provide any official information which database platforms are supported. This restriction is documented in ABAP Help with two sentences: if you use parameterized CDS on DBMS that doesn’t support this feature you get an exception. There is also a class that provides the information whether the system database supports the feature.
Where’s the Problem?
The answer is simple: how can we make technological decisions when SAP doesn’t give precise information which feature of ABAP (and of course AS ABAP, too) works on which database? How can we be sure that our software is running a system landscape with different DBMS? This is common in larger development systems and the general case for SAP partners.
We have the following possibilities:
- We can develop a solution that supports anyDB. This can be difficult and expensive since we have to develop two variants, say one with parameterized and one without. Dual development has its costs and if I have the choice I would like to avoid it. In the end I think I have to avoid it because of economic reasons.
- We don’t know or I don’t care about the restrictions. But then the solution crashes when it runs on a DBMS which doesn’t support the feature. In the worst case this could lead to a production downtime, which is or course no option. Unfortunately parameterized CDS has some unique features and when there are in the core of your application a change could be problematic and expensive.
- We know about a restriction and I will change the DBMS. Of course this is expensive.
- We decide not to use the new techniques at all. This is annoying since I paying for the platform. Without using new features the platform loses value.
This is the dilemma. Without knowing the facts we could get into trouble if our systems landscapes are running on multiple DBMS. Without this information SAP partners can’t neither answer the question whether their solution runs on a special DBMS nor make reasonable decision.
What do we need?
The answer is simple: whenever there is a restriction, SAP customers and partners should be informed about it. Here we need a list of supported databases. As I explained above it does not suffice that there is a solution only at runtime. I need this information in a release note so that it is an eye-catcher no one can miss by chance.
Why I am worried?
At the moment there are only a few restrictions, but as I explained above the times are over when AS ABAP was database agnostic and the whole PAM was supported. Of course it was possible to create database specific solutions using native SQL/ADBC, but the Code Inspector / ABAP Test Cockpit contains checks so that we ensure at development time that our solutions are platform independent, but I know no automated checks for parameterized CDS so far.
I think it is very likely that SAP will continue to develop ABAP features that are no more database agnostic. As I said above I have no problem with this but I need explicit information about restrictions. Everyone with complex system landscapes needs this information especially partners. If SAP continues adding database proprietary features to NetWeaver platform without precise information about supported DBMS, we will start developing solution where no one can tell on which DBMS they can run.
Tobias, Thank you for your comment.
Absolutely agree! ABAP CDS view with parameters is a very good example for not so optimal documentation.
From my point of view, the overall quality of documentation not only for ABAP leaves a lot of room for improvement not to say essential homework that has to be done. Very good other examples is the HANA Developer guide (nearly every code example contains one to several errors), the PAL reference guide (parameters of algorithms not documented but used within the examples) and the UI5 developer guide (step one of Navigation and routing -> link for initial setup leads into nirvana).
Hi Christian,
I really like to hear that I'm not the only one who has problems with the HANA developer guide. I already doubted my mental sanity because I stumbled from problem to problem.
Cheers,
Tobias
Hmm... going through the current documentation I cannot second this at all.
Not sure if this notion is based on an older release or just a gut feeling.
Personally I am very happy about the improvements in our documentation and the coverage of topics.
When I find errors in them, I typically report them as bugs (just for like any other part of the software) as this is the only way to have them fixed.
my 2ct
I did no track them accurately. Nevertheless, a short check allowed some findings:
Page 586: Importing CDS entities - the EPM. in front of SO. is imho not correct
Page 665: Lower part - binding the rows PARTNERID.PARTNERID has to be PARTNER.PARTNER.ID
Page 667 (optional part): the select in the data binding as given in the example (specified columns) would lead to a nearly empty UI. Imho it should be a select: "*" here
Nevertheless, I agree that opening OSS for that is the right way to further improve the documentation.
I hesitated long, whether I should remark something here but well then ...
Even if you are not pleased with the quality of the ABAP Documentation, at least you shouldn't find too much errors in the example codings of the ABAP Keyword Documentation. The reason is that all the example code for which it is feasable is extracted from the text and syntax checked by an automated test tool. Many examples are delivered as executables anyway. If you find other bugs or are dissatisfied with the overall quality feel free to report it (here or via a ticket). Your voice will be heard for sure. (Just to mention it, in SAP's own systems the ABAP Keyword Documentation has a built-in "Feedback button", where errors can be reported easily and early). Unfortunately, the original language of that documentation is still German and some quality is necessarily lost in translation to English (although those guys do a terrific job). But also translation errors can be reported and will be corrected.
Hi Horst,
the ABAP Keyword Documentation is very good. But in this case I would have expected a big exclamation mark together with a list of limitations: which databases are supported.
But IMHO this is not enough: I consider those restructions as so severe that it should be mentioned also on another place (Release Note) so that it can't be missed. The same holds for any other DBMS limitation. But I am repeating myself.
Best Regards,
Tobias
And it would also be great if we could click on a DBMS in the PAM and see a list of all limitiations for that platform, including features of the ABAP language that are not fully supported or bear restrictions.
Lastly, it should be possible to run Code Inspector/ATT tests to check for any DBMS compatibility issues.
Exact what is in my mind. A specific ATC-Plugin which allows me to check if my code is compatible to other DBMS and further more a documentation how to handle it. I'm pretty sure, there must be a way how to handle it at SAP. Why reinvent the process at each single customer again.
Hi Tobias,
I won't go that far. Yes, there is a gap delivering information what is possible and what not. I would love to have an build in option, which fetch the landscape information and let me check my code on all landscape with one click.
Can you imagine, what I have in my mind? Something like I click on all databases I want to use and have an enhanced ATC which guide me to build a all over solution, however this looks like. I think you have something similar in your mind.
Of course it influence decisions or better, it does affect the future decisions if you are going to host an system for example on a non-supported db next year, but is this not the normal way things are going today also?
I don't think this is a bad thing, for me the pain is just the wide spread documentation. You need to have a look at different places to find it, that really hurts me.
One place for all relevant information... and what is better than the build in tools I use every day.
~Florian
BTW: I also delivered some CDS and recognized afterwards, that my customer won't be able to use it because of non-supported parameters 🙁
Hi Florian,
you complained about the wide spread documentation? Do you have a suggestion how to improve it?
IMHO the ABAP documentation is really good. The main problem is that every new SAP technology has restrictions. IMHO a central document that points to limitations and severe errors (especially if they can solved only with the next SP). There should be a part in the release note pointing them.
Best Regards,
Tobias
Hi Tobias,
I'm pretty sure we find some time next week to talk about. I got something in my mind which might work. Something like a single point of contact to find everything regarding to "ABAP"...
~Florian
Hi Tobias,
great blog.
I personally think that extending ABAP with features that are not database agnostic is no good idea. IMHO this will only lead to unnecessary complexity in code. For example, all add on vendors will either start to develop 2 versions of their product of start mixing two variants in the code. I would expect patterns like
IF <HANA_DB>.
use shine new feature
ELSE.
complicated legacy code
END.
start popping up. This is what one already starts to see in some SAP standard code. My nightmare scenario would be that the database dependent features lead to some kind of preprocessor tool for ABAP code (similar to C). Therefore, I really hope SAP keeps the number of features not available on any DB very small (at least until in some distant future all customers are on HANA).
Christian
Hi Tobias,
great blog!
I want to comment on the fear Christian has:
I agree with you that non DB agnostic ABAP features are not a good idea. But for me it's clear that the ABAP AS will not be DB agnostic anymore in the (very) longrun. Sad but true.
Cheers,
Martin
Hi Christian,
you are absolutely right: when AS ABAP isn't database agnostic any more, this will lead to more complexity. And yes, we need best practices to manage it. And I agree with you: coding those features using IF .. THEN.. ELSE is awful. Sometimes I'm thinking about possible solutions perhaps using the switch- and enhancement framework but I'm not sure whether a new abstraction layer is good or not. Maybe we should be able to annotate ABAP classes or methods to indicate that they are limited to certain database restrictions – perhaps using the classification API. Those classifications can be static or dynamic (like the package checks) and could be calculated on thy fly. So we could analyze in batch and on-the-fly which DBMS are supported and which not.
But nevertheless will still need precise information to develop the architecture of an application, especially when you are doing operational reporting. The reason is that once you decided to use database specific features in an operational data model then it will become a property of the whole data model. So this is a decision you should make carefully. And we should know about the consequences of our decisions but therefore we need a precise documentation.
Best Regards,
Tobias
Hmm, not at all the blog I expected based on the title 🙂 , but still a valid point. It's not just ABAP - pretty much in any SAP area we see lack of clear and concise information, preferably from a single source.
As correctly pointed out, if people do not understand how/when to use something they may opt out of using it altogether - "better safe than sorry". It's not enough just to come up with new technology, it needs to be adopted as well.
Hi Jelena,
I fully agree with you. The lack of documentations applies e.g. for BOPF. Great framework which can save a lot of time and money while developing applications in ABAP. But there are only few blogs on SCN. On the SAP help portal there is almost nothing about it. SAP education is offering a two days training. That's way to short to understand such a powerful but also complex framework.
Cheers,
Martin
Just to clarify my point: I really appreciate the creat job the BOPF team does on the BOPF Application Framework space. My point is, that there is not much information and documentation available outside the BOPF space. Even on TechEd you have to know in which sessions BOPF will be a topic. Maybe the framework is just not as cool as HANA and therefore there is almost no promotion. But I want to stop the discussion on that know as it is off Tobias' topic.
Alfred Barzewski, who is active in that field, just pointed out to me, that a new BOPF Developer's Guide is available. Did you know that?
Thanks Horst, good news! No, I didn't know that. I actually searched help.sap.com before I posted my comment but didn't find it.
Ah, search on help.sap.com ...
Reminds me that I have to make my files crawlable 😐
is that guide part of "your" files? It still does not appear in the search results.
Nope
Hi Jelena,
I made the experience that every new SAP technology has its limitations. In fact I am not surprised because SAP diversified its technology portfolio, developed new feature, supports more and more clients (NWBC, browsers…) It’s getting so complex that some scenarios are not supported. The information about restriction is most important for early adopters from my experience.
For me the title of this blog is appropriate since I never thought that this lack of precise information concerning ABAP language or ABAP application server would be possible. If the same kind of restrictions and the sloppy resp. late communication becomes habitual also in AS ABAP I worry about reliability of core processes in customer and partner solutions.
Cheers,
Tobias
Hi Tobias, it's not that title was inappropriate, I just expected to see a blog about general strategy, something along "SAP is trying to kill ABAP" lines. 🙂
Hi,
actually it is very simple. CDS views with parameters are working on every database platform from 750 on. So there is much reason to upgrade from 740 to 750 ;-). If I remember correctly, in 740 they also run on all databases except Sybase, MaxDB and DB4.
AMDPs and table functions (and, of course, database procedures and external views) are therefore the the only features not working on every database. But it is very simple, too: they work only on SAP HANA. And if you ever wrote an AMDP: HDB and SQLSCRIPT are keywords in the ABAP language you have to write when you create an AMDP method. So not much confusion here, too.
And actually you never should write code like this:
IF HANA.
...
ELSE.
...
ENDIF.
There are many concepts which have been incorporated to prevent this. The most prominent are:
(1) BAdIs
(2) The class CL_ABAP_DBFEATURES
And we are trying hard to prevent any DB features not absolutely necessary. Also one could argue, that AMDPs are not really an ABAP feature but a HANA feature. You can call database procedures on every database from the ABAP by using native SQL. And native SQL (and AMDP is nothing more than that) has been in the ABAP since 20 years.
So actually, the problem described here does not exist (regarding DB features in Open SQL and CDS) or exists since 20 years (regarding native SQL).
Best regards,
Kilian.
Hi Kilian,
sounds good, but reality looks a bit different. It is not that easy to upgrade a system if you have done that some time before. This is an invest and so as a techie I would love it, but my business is somehow addicted to money (which I can understand).
Anyway, what is your plan for let me suggest a situation:
I want to deliver a Monitor as a partner solution and I got different dbs.
How to get rid of the never should use statement:
IF HANA.
...
ELSE.
...
ENDIF.
I'm looking forward to your solution. Maybe there is a best practise I do not know.
Having a look a at some "optimized" programs I see exact that construct and in my opinion IF cl_abap_dbfeatures is the same.
Just not calling it IF HANA doesn't say you don't mean that...
~Florian
Hi Florian,
there are many aspects here:
1. SAP is trying to make upgrades more painless than ever before. Zero Downtime, concurrent load formats, downward compatible kernels, ABAP in the cloud, and so on. But I am no expert on this matter for sure.
2. Regarding all this "switches", I find the BAdI Approach quite nice, because you could always plug multiple BAdI implementations to one BAdI and it is, in fact, quite common in Business Suite and customer coding to have it like that. No if's needed in the coding, just some customizing.
3. The difference between CL_ABAP_DBFEATURES and "IF HANA" is clear: in the moment a feature (or better, a feature set) becomes available on one database, your code gets called on that database. And as you can see, we _really_ are trying to make it work on all databases.
It is much better than in the "good old days" though. There are customer and SAP solutions which are written to 90% in native SQL. They will never be "ported", the MaxDB code will never be executable on Sybase and you will never get rid of them. With CL_ABAP_DBFEATURES it is totally different. In the moment, a DB Feature works on all databases (like views with parameters) you get notified via SLIN that some coding of yours is superfluous and you may remove it.
So you shouldn't understand the new features as a way to make Open SQL less portable, but to make native SQL better portable. In such a light, we made a giant step forward. And if you don't want that: stay with ABAP (or Native SQL still). The missing pieces are only a needle in the haystack ...
Best regards,
Kilian.
Hi Kilian,
I don't mean a specific db-feature, it is more the in-memory optimized parts. You know, there might be some select-statements which are valid for all databases, but will end in a mess when used without HANA.
So it is more about how to handle db-non-specific functions.
Maybe it is a bit too much off-topic here, if there is a best-practise guide please point me to, I haven't found one at the documention.
~Florian
Hi Florian,
this was always a problem. If you have many and complex joins, some databases may be better handling that than others. But that is really outside of our influence at all :-(.
In programming, you always have to balance portability vs. speed. If you want portability, you write in Java and are slow. If you want speed, you write in C++ and are not portable anymore.
But the point really is that some ABAP coding is so bad (with regarding to the database) that rewriting it and pushing as much as possible to the DB will give you profit on any DB.
Best regards,
Kilian.
Just to mention it, the class CL_ABAP_DBFEATURES is new with ABAP 750 and can be used to check the features of databases that can be used in ABAP programs but which are not supported by all database systems. The example programs of the ABAP documentation that use DB features like AMDP were (of course) all switched from
IF cl_db_sys=>is_in_memory_db = ....
to
IF cl_abap_dbfeatures=>use_features( ... ).
Oops, still an IF, but not HANA- but feature-specific.
Cheers!
Horst
Hi Horst,
like that explaination. Thank you 😆
~Florian