Why I enjoy ABAP development (2)

In the first article, I already mentioned some of the aspects that make ABAP one of my favorite development environments: the central data dictionary and its connections with the language and runtime system, database access and the change and transport system. In this article, I'll tell you a bit about what you may or may not have to consider when developing ABAP programs.

First of all, the SAP R/3 system is a multi-user environment - but it doesn't feel like one. As a developer, you don't have to worry about separating users and sessions, because the system takes care of that for you. Most of the time, you can simply write a program like you did during the good old days of DOS because you simply can't access the other sessions runtime data and wreak havoc there. You'll even have to take some extra measures to create a shared memory area - but if you do, the system takes care of the consistency of the shared memory not only between sessions on a single server, but also across several physical application servers.

Speaking of application servers - a R/3 system can have any number of application servers. This is a common method to allow the system to scale up to the requirements: just add some application servers. As an average user, you don't have any influence on which server you'll logon to next - the system just assigns you to the server with the most time to spare. Of course, some parts of the R/3 system cannot be spread across several physical servers, most notably the parts that deal with locking and the creation of sequential numbers (like material numbers). For other parts (like the database), it's often not worth the effort spreading the load across different servers - you'll just use one "big and expensive" machine as the so-called central instance and let your users only logon to a farm of dedicated and rather cheap application servers. If one of these boxes go down unexpectedly, you'll only lose the unsaved work of the users that were currently working on this machine.

ABAP does not support concurrency at the language level. While this is a drawback for some GUI-intensive applications, it eliminates a very common source for programming errors that are very hard to track down. If you leave the GUI part out - and you'll have to when writing R/3 applications, because the GUI itself is mostly out of your control - you hardly need concurrency in business applications. What you - or rather your users - need is a reliable and flexible batch job engine to schedule background jobs and retrieve the output. You might have guessed it - the R/3 system comes with a background processing engine - and for the developer, this engine comes with no extra price tag attached. (Almost) every program can be started as a background job, you'll just have to take care that you don't try to access anything on the front-end system because a background job does not have a front-end connection. The background processing system also comes with a facility to schedule jobs for later or repeated execution, including fancy thinks like a factory calendar. As a developer, you can also use the background processing engine to enable parallel processing in your application, although you'll have to alter you program significantly to make use of this feature. Note that this is not concurrency (parallel execution threads within a program), but rather inter-process communication (multiple single-threaded applications running in a coordinated fashion).

Let's take a look at user and security management next. Most of the time, you're not concerned with user management when writing ABAP applications. User management exists and is already in place, because to run your program, the user obviously has to log on to the R/3 system. You can obtain information about the user that is currently logged on, but that's hardly ever needed for other purposes than logging or printing the correct phone number on an invoice. As a developer, you're more concerned with whether the user is allowed to run a certain program, view or change certain data or execute a certain function. This is rather easy to achieve with the help of so-called authority objects - you'll either use one that comes pre-defined with the system or create a new one. Authority objects carry information about up to ten parameters that can either be specified at run-time or skipped (think of a "don't care"-value). As a developer, you just tell the system to check whether the current user has the authority for object N_EINR_TCO with some values matching EINRI = '0001' and TCODE = 'NP10' . The structures that actually assign authorities ("instances of authority objects") to users are quite sophisticated, but something you don't really have to worry about. It's there, it works.

One last aspect for today - internationalization. It's not uncommon to have a central R/3 system serve users in different countries speaking different languages. No big deal - the system was thoroughly designed to keep language-dependent data separated from language-independent data. If you're into databases: think about a secondary table holding the language-dependent information with an additional primary key field or the language for every table that contains language-dependent data. That's exactly how it's implemented, by the way - with some very handy tools to keep this "duplication of tables" from getting out of hand. This mechanism applies both to the data and the system itself - for every text you see on the screen, there's a database entry for the language you've specified when logging on to the system. Choose another language, and the screen elements will change accordingly. Add to this a set of translation tools that can automatically identify the translatable objects and identify what needs to be translated, and you're ready to ship your application to every country in the world.

Probably to be continued...