In the last tip, I explained some basics about the ABAP server: Let us now combine what I have explained about the three-layer architecture of the server and the fact that developers in general develop on a central ABAP server in real-world projects. As in the last tip I will provide a little example to illustrate what happens when you activate your program.
Active and inactive programs
As I have told you, there are many developers developing on the same server. Each developer has his own "instance" of the development environment on the server within his roll area.
You can compare this to many clients working with different instances of a class.
Technically the development environment comprises a set of programs such as the ABAP Editor, the ABAP Workbench or the Class Builder plus a lot of other tools to support the development process. An ABAP developer works on the client and has the classical SAP GUI that presents the user interface of the respective development tools. The program(s) under development are stored on the central database.
The program a developer writes within development client 1 is only visible to this developer as long as the program is not activated.
As soon as the developer activates a program, it is visible on the whole server. This means, of course, that other programs can access it.
Developing on a central server - the way to keep your sources in sync
One great advantage of this organization lies in the fact that incompatibilities will become visible very early. Let us refine our small sketch a bit to show you how this works in detail: Let us assume that program 1 uses class 3 (developed by development client 3). Remember: It is the active version of class 3 that is used. Inactive versions are not visible to other users (in fact they are not visible to any other development objects).
Meanwhile there is a new inactive version of class 3 under development.
As developer three is not very experienced, he changes the interface of the method that is called by program 1. Let us assume he renames the parameters of the method. Unaware of the consequences of this incompatible change, developer 3 activates his class. What happens? The old inactive version becomes the new active one and … there is an syntax error as soon as program 1 (the client of class 3) is recompiled:
If the new program 1 does not properly interact with other programs that call program 1 this problem arises as soon as a client program of program 1 is run. So, as I have already told, there is no need to maintain a dedicated test system if the developers belonging to a project develop on the same server.
So one typical problem of local development does not occur when you develop in ABAP: Instead of developing against proprietary source versions that you have on your PC and not updated for weeks, you will always use the latest sources as soon as they are activated. This way, incompatibilities will be realized in a very early state.
Thomas Weiss works in the SAP NetWeaver Product Management and has built elearning tutorials on ABAP topics.
This content is reposted from the SAP Developer Network.
Copyright 2007, SAP Developer Network
SAP Developer Network (SDN) is an active online community where ABAP, Java, .NET, and other cutting-edge technologies converge to form a resource and collaboration channel for SAP developers, consultants, integrators, and business analysts. SDN hosts a technical library, expert blogs, exclusive downloads and code samples, an extensive eLearning catalog, and active, moderated discussion forums. SDN membership is free.
Want to read more from this author? Click here to read Thomas Weiss' Weblog. Click here to read more about ABAP on the SDN.
