In the last weblog I have 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 weblog 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 you see: As I have already explained, 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.
Summary
I hope, by now you have understood what is so good about many developers working on one central system. Once you activate your program it is visible to everybody else on the system, and possible conflicts are detected in a very early state.
Comments