Why I enjoy ABAP development

It was another one of these déja-vu experiences. At the Eclipse Modeling Stammtisch yesterday, I mentioned that Eclipse is more or less a hobby of mine. I did (and still do, if I can spare the time) SAP R/3 development for a living. Yep, that's right: ABAP. And I actually enjoy it. Now you can imagine the expressions of the average IT guy - varying from astonishment to disbelief or even disgust. ABAP - how could you come to like that?

Funny though - almost no-one I talked to recently who showed that attitude had any real-life experience with ABAP development. The story I get to hear most of the time is "There was this class at university, and a guy with some 'Master of Business Admiration' resume who told us how to assemble a packing list for a motorcycle dealer in materials management - and something about postings and general ledger, but I didn't understand that." Sorry to say, but this is like trying to teach someone to drive a car by making him learn the spare part numbers of a single model by heart. When you're a techie, you need a different picture: What's in this box that might make me want to open it? Are there problems I could solve faster or more elegant if I knew how this system works? Why should I give ABAP development a try? While I can't really answer these questions for you, I'll try to give you a different view on the SAP R/3 system - from techie to techie. If you're not a techie, you're still invited to stay along for the pictures.

Sunflowers on the roof of Changi Airport
Sunflowers on the roof of Changi Airport

Just a quick note for the experts among you - I deliberately avoid mentioning the name NetWeaver. In my opinion, this name has been used far too extensively and now covers a gazillion of systems, applications and techniques that are more or less connected to each other. You can waste an awful lot of time trying to find out what NetWeaver really is if you're looking at it from a technical perspective because it really isn't a technical term. It's a brand name optimized for marketing. If you need some name to google for, at least use "SAP Web Application Server for ABAP" - I believe that's what the "good old R/3 system" is called nowadays. And please don't ask me about the Java part - I don't have the slightest idea what SAP did to Java and why you can't even change your host name without reinstalling the entire NetWeaver Development Infrastructure...

One thing I like to know about any tool I use is what its limitations are. It can be really frustrating to have spent a lot of time getting your head around some kind of framework only to find out that it's not suited for whatever you had in mind. So, if you're into writing the next great first-person shooter, forget about R/3. (You already knew that, didn't you?). If you need realtime processing, want to get into some of the more fancy numeric algorithms, need your software to run on mobile phones or render some impressive 3D images, R/3 isn't for you either. It's a system designed for business data management - and while it doesn't really care about the contents of business data, it makes a few basic assumptions: The data can be stored in a relational database - the classic variety, the one that's installed in a central location, not this fascinating 'we'll-replace-your-filesystem-with-a-database' approach. You'll want some kind of dialog screens to keep the users happy and perhaps some kind of reporting. Printing would be nice, too, and some connections to the rest of the world. If that's what you're after, and if you can bear the pain of looking into a proprietary system, come along.

café sign in Christchurch, NZ
Café sign in Christchurch, NZ

ABAP as a programming language is more or less meaningless without the basic components to back it up. Think of some simple database-powered application in your favorite programming language for a minute: Depending on which approach you use, you'll probably either write some DDL statements, create the database and then write the the code to connect to the database and manipulate the data, or you'll use some OR mapper to have the database structures generated automatically. If you're into modeling, there's a good chance that you'll want to generate both the DDL statements and the code to access the data. In ABAP development, you don't really have these choices - you'll have to create the database structure for yourself. But that's about all there is to do - once you have defined the structure in the central data dictionary, you can use it like any other built-in data type. DATA foo TYPE i declares an integer variable using one of the built-in data types, and DATA bar TYPE npat declares a structured variable (think of a Pascal record or a C struct) with exactly the same structure as the database table NPAT (which holds the patient data in the hospital management application). Declaring a variable to store the data of multiple patients (think of an array or a Java List<...>) is equally simple: DATA baz TYPE TABLE OF npat. This kind of transient variable is called an internal table to distinguish it from the persistent data storage in a database table. You can see how the ABAP language makes heavy use of the data dictionary - and without the dictionary, virtually no ABAP program makes sense. The same pattern occurs on numerous other occasions. IMHO this is one of the main reasons why there's no "Open Source ABAP Implementation" - you'd have to duplicate the entire system around the language as well.

Accessing the database is about as easy - there's a standard database connection that's always present, so you can just SELECT whatever FROM NPAT INTO TABLE baz. There's no need to load a driver, get the database location, assemble a connection string, pass some credentials, prepare a query, execute it and map the result set - it's all built into the system. You can even use SELECT as a loop command: SELECT whatever INTO bar, then do something with the contents of bar, ENDSELECT. It's not a great idea from a performance perspective, but it might give you an impression of how easy it can be to write database-driven applications. This might also be a good occasion to point out that the SAP R/3 system contains a database abstraction layer. ABAP contains a sub-set of the various SQL dialects that's called Open SQL, and the ABAP runtime environment takes care of translating the Open SQL commands into the database-specific syntax. It's possible to bypass this abstraction layer, but that's hardly ever necessary. The bottom line is - as long as you stick to Open SQL statements, you don't ever have to worry about the database itself. You don't even have to worry about the database your customers might use - it's perfectly possible to develop software on an Oracle-based installation and then deliver the very same program to a customer that uses a DB2, MaxDB or any other supported database - it'll work without any adaption.

Saddleback (Orana Wildlife Park, NZ)
Saddleback (Orana Wildlife Park, NZ)

Speaking of which - how do you get "a program" to the customer? As we all know, the deliverable is far more than the program itself. Database tables you already know of - and there are other artifacts that need to be moved along, too. And we don't even have to think in terms of producer-customer relationships - every decent SAP R/3 installation consists of at least two systems. The standard setup is a three-system landscape with a development system, a QA and training system and a production system (with the QA system usually being a copy of the production system to keep it up to date and thus facilitate testing). So once you have assembled some nice application in the development system, you'll want it copied over to the QA system to check it out and then on to the production environment. Enter CTS - the Change and Transport System. The CTS is a part of the development environment that keeps track of the artifacts you create, modify or delete. It records the changes in a so-called transport order. Once you're done, you release that order, telling the CTS to bundle up the new version of everything you adapted and assigned to that transport order. These objects are then exported from the development system and imported into the subsequent systems. Depending on the configuration and complexity of the system landscape this might happen manually or automatically, with or without QA approval - you get the idea. The CTS also keeps track of who touched which object and prevents you from interfering into somebody else's ongoing development tasks without at least noticing it. For many kinds of artifacts it also keeps a history of the versions that were exported, so it's easy to track changes and revert to previous versions. What's more, the CTS can also keep track of configuration changes and thus ensure that your multi-system landscape is kept in a reasonably consistent state. And most of the time, you don't even think of it - just select the transport order and there you go.

To be continued...

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer