Develop ABAP

How to Develop in ABAP
Applies to:
SAP NetWeaver 7.0.For more information, visit the ABAP homepage.
Summary
This is the PDF version of the development blog series on SDN published in 2007 that gave an introduction to ABAP newbies who want to learn how to develop simple programs in ABAP. This PDF file does not contain the few blogs of the original series that explained how to install and administrate the ABAP demo version and how to import and export programs. This PDF document solely focuses on the many blogs that focused on development in ABAP. This is why the PDF file starts with blog 3 and has some gaps in the numbering. The author of the relevant part is listed at the beginning of each blog. If there is no author listed, the blog is written by Thomas Weiss. If you are interested in the comments and answers to the comments on the blogs you should read the original blogs on SDN. Otherwise this PDF file gives you an easy opportunity to work your way through the whole series. Author: Thomas Weiss
Company: SAP AG Created on: 28 January 2010
Author Bio
Thomas Weiss has a Ph.D. in analytic philosophy. He worked as a professional writer before joining, in 2001, the SAP NetWeaver product management training team where his responsibilities included the e-Learning strategy for ABAP. After becoming more involved in writing ABAP material himself, he is now a member of the SAP NetWeaver Application Server Solution Management. One of his main interests lies in rolling out ABAP topics both for experts and for beginners by writing blogs in SDN.
SAP COMMUNITY NETWORK 2010 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 1
Table of Contents
Why and How the Server Matters to You as a Developer: Server Architecture and Work Processes .............. 4 ABAP Application Server for Newbies Why and How the Server Matters to You as a Developer .............. 4 Developing on the Server................................................................................................................................ 4 The Three-Layer Architecture ......................................................................................................................... 5 Work Processes in Some Detail ..................................................................................................................... 5 The Three Layer Architecture Continued ........................................................................................................ 7 Summary ......................................................................................................................................................... 8 Many Developers on one Central Server - How Does It Work? ......................................................................... 9 Many Developers on One Server How Does It Work? ................................................................................ 9 Developing on a Central Server The Way to Keep Your Sources in Sync ................................................ 10 Summary ....................................................................................................................................................... 11 Navigation in the Application Server ................................................................................................................. 12 A First Hello World Program ' .......................................................................................................................... 15 The Repository Browser The Central Place in the ABAP IDE ................................................................... 15 Packages ...................................................................................................................................................... 16 A Package for Local Objects ......................................................................................................................... 16 Hello World as a Local Program .................................................................................................................. 16 Summary ....................................................................................................................................................... 19 Creating a Program and a Package - An Introduction to the SAP Change and Transport System ................. 20 Some Words of Motivation: Why Your Programs Deserve Better than Package $tmp ................................ 20 Creating a Package - the Chance to Get in Touch With the CTS ................................................................ 21 Creating a Package - the Details .................................................................................................................. 21 The Concept of a Transport Layer ................................................................................................................ 22 Some More Basic Concepts of the SAP Change and Transport System ..................................................... 23 Package Building Continued ......................................................................................................................... 25 Creating a Program within a Package .......................................................................................................... 27 Outlook .......................................................................................................................................................... 28 A First Little Business Program ' ....................................................................................................................... 29 The Aim: Our first Little Business Program ................................................................................................... 29 How to Use the ABAP Documentation .......................................................................................................... 29 How to Get an Internal Table with the Line Type of a Database Table ........................................................ 30 Open SQL in ABAP ....................................................................................................................................... 30 Test Output of an Internal Table 1: A Loop and a Write-Statement ............................................................. 31 How to Get to Know the Properties of a Database Table ............................................................................. 31 What the List Output with the Write Statement Looks Like ........................................................................... 32 Test Output of an Internal Table 2: A Dynamic Way to Output Any Internal Table ...................................... 33 Test Output of an Internal Table 3: The Object Oriented Way ..................................................................... 33 The Whole Code of the Three Alternatives An Overview .......................................................................... 34 Summary ....................................................................................................................................................... 36 Getting More Familiar With the ABAP Dictionary ............................................................................................. 37 PARAMETERS and the Selection Screen .................................................................................................... 38
From the ABAP Dictionary to the Data Browser ........................................................................................... 39 Data Element, Domain, and the Way They Interact ..................................................................................... 41 At Last: The Source of Our Search Help ...................................................................................................... 43 Summary ....................................................................................................................................................... 43 Debugging in ABAP .......................................................................................................................................... 45 Defining a Custom Structure in a Program ................................................................................................... 45 A Useful Addition to the SELECT Statement ................................................................................................ 46 What Is Wrong With Our Program We Start to Debug .............................................................................. 47 The New ABAP Debugger A Short Overview ............................................................................................ 47 Debugging Our Program ............................................................................................................................... 48 Some Words on Efficient SQL Programming ............................................................................................... 49 How to Use the ABAP Language Documentation Efficiently ........................................................................ 50 Summary ....................................................................................................................................................... 52 Get Your Program up to Speed - Overview & Introduction .............................................................................. 53 The Programs to Be Analyzed ...................................................................................................................... 53 ABAP Runtime Analysis: Tool & Procedure ................................................................................................. 54 The Foundation of an Application - Creating the Database Tables ................................................................. 59 The Contents of this Blog in Some Detail ..................................................................................................... 59 The Concept of a Client: A Key-Player in the SAP World of Business Programming .................................. 60 Defining the Data Elements .......................................................................................................................... 61 Creating Database Table YACCOUNT ......................................................................................................... 62 Providing Some More Check Tables ............................................................................................................ 66 Summary ....................................................................................................................................................... 67 How to Dynamically Create Test Data for Our Database Table ....................................................................... 68 The Basic Principle of How to Create the Entries Randomly........................................................................ 68 How to Fill Database Tables in the Data Browser ........................................................................................ 69 Looking at the Program Itself ........................................................................................................................ 70 Running the Program .................................................................................................................................... 73 Summary ....................................................................................................................................................... 74 The Complete Program Code ....................................................................................................................... 74 Your First ABAP Objects .................................................................................................................................. 77 Starting with Web Dynpro for ABAP ................................................................................................................. 82 Create your First Web Dynpro Component ................................................................................................... 82 Model View Controller and the Context ........................................................................................................ 83 Data in the View ............................................................................................................................................ 85 Defining the View Layout .............................................................................................................................. 86 A First Test .................................................................................................................................................... 89 Bringing Life into the Component .................................................................................................................. 90 Conclusion .................................................................................................................................................... 93 Copyright........................................................................................................................................................... 94
Why and How the Server Matters to You as a Developer: Server Architecture and Work Processes
In general, you develop on a central server in ABAP. That is why the server matters to ABAP developers from the very outset. In this blog I explain the three layer architecture of the SAP NW Application Server ABAP and the basics of how users are distributed on work processes. The result of this architecture is a highly scalable and robust server. ABAP Application Server for Newbies Why and How the Server Matters to You as a Developer Usually as a developer in a language like C or C++ you need not care so much about the server. It might only matter to you if your program should run on a server in the end. When you are developing in ABAP things are different in this regard. In this blog I will explain why the server concerns you from the very outset and why, consequently, you need to have some knowledge about the SAP NetWeaver Application Server ABAP. And this is what I want to provide you with in this blog: some basic information on the SAP NW Application Server ABAP. Developing on the Server For those experienced with other programming languages like C, Java, or Visual Basic working with ABAP offers some features they might not be accustomed to. The structure of the development environment for ABAP is different from probably everything that you might have encountered so far: In ABAP, you program on the server from the outset. You do not develop the programs locally on your PC, nor do you store the sources in a versioning system or deploy the programs on the server at a later stage. In order to program with ABAP, you therefore require access to and developer authorization for the SAP NW Application Server ABAP. You write your programs using the ABAP Editor of the ABAP Workbench and the tools integrated there, which are also part of the server. However, the SAP NW Application Server ABAP not only contains the programming environment with its tools and utilities for supporting the software lifecycle. Developing with ABAP is closely connected to the server in another respect: Once you activate your source code, platform-independent byte code is generated, which the runtime environment interprets for the program execution. And this byte code generated from your ABAP program runs on the SAP NW AS ABAP. Usually many developers are working on the same server. This way, a problem known to all developers in large projects does not even arise: No quality manager needs to care about providing a system on which to deploy the programs from different developers and where to test the interaction of the programs from different developers in a project. Everything to accomplish this is already done, and you as a developer already have your programs in the right place: As soon as your source code is activated the respective development object is visible on the central system. So the principle in ABAP is: Development on a central server. You need also not care about checking in and out your sources in a content management system. The whole persistence and administration of different versions of your sources also happens transparently to the users. Pushing the Save-button in the ABAP Workbench stores your program in the database. You retrieve it by the program name: There is no fumbling with program files in ABAP. Again the server does it all for you. By the way, this is a typical experience when working with the SAP NW AS ABAP: Many things you need for business programming are provided by the system. The ABAP server does a lot of services for you in the background that developers or quality manager usually have to care about. The explanation for these conveniences is the fact that the organization and structure of and the technology behind the development process in ABAP is different. Some these features need getting used to, but after a while you will like them because thanks to them you can concentrate on what your job really is about: developing business logic. It is for this reason that you must take into account the architecture of the environment in which ABAP programs run when designing and developing these programs. For this purpose, you first require some information about this architecture.
The Three-Layer Architecture The SAP NW Application Server ABAP consists of three layers: presentation, application, and database. The database layer of a system is made up of a central database with a database management system and the database itself. It not only contains the user data, but also the entire program code of the SAP NW AS and application programs, all administrative data, and Customizing settings. That is, the programs you develop are stored in the database of the system. The application layer lies between the database layer and the presentation layer. It consists of one or more application servers (more than 100 servers possible) and a single message server, which is responsible for communication and load distribution within this layer. The programs that process the business logic of an application and all the development tools, such as the ABAP Workbench, run in this layer. Work Processes in Some Detail Technically, the actual processing takes place in work processes, which represent processes of the operating system. A fixed database connection is assigned to each work process. For you as a developer this means: You always have a database connection at hand. No need to get a database manager, to open, handle and close the database connection. The whole database handling is done for you in the background by the server. There is no fixed assignment of users to work processes. A lengthy user session can utilize different work processes sequentially, and one work process is used by different users consecutively. Still the state of your program is kept. The context of your work process is rolled in as soon as your program is processed and once the work process returns a result, your context is rolled out. It is this so-called roll area that contains all the data and programs that are currently processed by a user. This architecture makes for robustness and scalability. It is robust because every user has a work process of his own, for the time his program is processed. All that can happen in the worst case only concerns the work process your program currently occupies. There is no such thing like crashing the whole engine in ABAP by a severe syntax error in your program. The way user requests are distributed to work processes combines the advantages of stateful and stateless communication. On the one hand, a user does not occupy a process for a long period while he might not be doing anything. On the other hand, the Dispatcher (within the server) knows and remembers the identity of a user over time: This way each time a user session gets processed its context is known. To give you a better understanding of this mechanism I will present you an example of how a user of a particular application is assigned to different work processes at different points in time when performing different steps in a application. To avoid one possible misunderstanding from the outset: In general, one request is processed within a single work process though it is possible to write programs in ABAP that distribute different costly tasks on several work processes (such as, for example, several large selects on the database if they do not depend on each other). Let us suppose a loan officer, let us call him Jones works with an application in the office: First retrieves the table of debtors in a particular region. His request is processed by work process 1 (picture 1). But, of course, he might get any other work process that is currently free.
If the request is processed the result is sent back to the user. The roll area that keeps the state and data of user 1 is rolled out and the work process is freed for requests of other users (picture 2). As long as user Jones does not interact with the application he does not occupy any work process. By the way, the other users in our pictures are assigned to other free work processes in the same way as user Jones is. But this is not shown in the picture, as I want to keep the focus on the way user Jones is assigned to work processes. Next our loan officers want to get the details of a particular customer. He gets assigned to work process 3 and his roll area in the state he has left it is rolled into this work process (if there is not much traffic on a server, you will in general stay into the same work process, because the server tries to minimize the cost for rolling-in and out, but this are optimization details, and I am interested here in the general mechanism).
Again the work process is freed after the request is processed (picture 2). Next the loan officer sets a new credit limit for Smith and saves it. Again he gets another work process. His roll area is rolled in, the request is processed and the data is saved on the database.
This way a user does only occupy a work process when the application he uses actually sends a request. Due to this mechanism it is possible to have far more users than work processes on an AS ABAP. So a typical SAP ERP System running on an AS ABAP server might have 50 work processes and 500 users currently logged on (This is, of course, only an example to show the ratio, the actual number of work processes on a server depends on many technical details such as the CPU power of the servers, the RAM that is available, what kind of applications the users typically are running, how many users are logged on simultaneously etc.. The number of work processes for a system is determined in the profile by the system administrator).
The Three Layer Architecture Continued The kernel and the Basis services make up the part of the application layer that is specific to both the operating system and the database. They are responsible for user and process management, database access, communication with other systems, as well as system monitoring and administration. The software processes or virtual machines, that interpret the platform-independent byte code as operating systemspecific machine language commands, run in the kernel. The presentation layer represents the interface with the user and is responsible for the screen display. This layer receives user entries that is, mouse-clicks and keyboard input and passes them on to the application layer. Furthermore, it receives data from the application layer and displays it to the user. When writing a business application you should use Web Dynpro ABAP as a state-of-the-art user interface. A Web Dynpro ABAP component may run on the same server as the underlying business logic. A ABAP Web Dynpro application is displayed in the Browser or the Business Client. The ABAP workbench and all the other tools you need for developing use the Dynpro technology (Dynpros are the classical user interfaces of most ABAP-based SAP programs and run in the SAP GUI). In our demo programs in this series, we will sometimes use classical Dynpros to input and output data as a handy device just as you use the output to the console in Java Tutorial. It saves you time if you want to test a backend program and the real user interface written in Web Dynpro ABAP is not yet available or you want to test the business logic apart from the presentation logic. The real user interface of your programs should always be developed with Web Dynpro ABAP.
Presentation Layer: Client-Side Presentation

Browser SAP Browser GUI NW Business Client
Application Layer: Presentation Logic Business Logic:
Dispatcher Buffer
Work Proces s Work Proces s Work Proces s
Functions ABAP Programs BAPIS

Database Layer
Web Services
DB Processes
DB
The purpose of this division in three layers is high performance and scalability. The layer division is purely logical. It does not imply over how many machines the system is distributed. In fact, all three layers can actually run on a single computer. For demonstration purposes, such as you have just done it in the case of this demo system, it is possible to install all three layers on a single PC. However, in the case of large, production applications of customers, this is more of a theoretical possibility, since it would counteract the scalability of the three-level architecture.
Summary Now you should have understood that you always work on the server when developing in ABAP. It is for this reason that I have explained to you the basics of the three-level architecture of the server and the way users are assigned to work processes. In the next blog I will explain the impact of development on a central server on the developing process. Again I will focus on an example that is intended to illustrate a basic mechanism. This time you will lean some details about what happens when you activate your program.
Many Developers on one Central Server - How Does It Work?

In this blog I show you one big advantage of central development in an example: You will always use the latest sources as soon as they are activated instead of developing against proprietary source versions that you have on your PC and not updated for weeks. This is ensured by the technology underlying the development process in ABAP. An simple example illustrate how this works. Many Developers on One Server How Does It Work? In the last blog 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 always develop on the central ABAP server in real-world projects. As in the last blog I will provide a little example to illustrate what happens when you activate your program.
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:
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.
Navigation in the Application Server

This Blog was posted by Manfred Lutz on 5 April, 2007, on SDN at ABAP Application Server Beginner. In Part 2 of this blog series, you logged onto the Application Server as 'BCUSER'. From this starting point, this blog explains how to find the functionality you need.
Item No.1 is a Command field for the 'transaction code'. This is a shortcut to the transaction (functionality) you want to execute. Position the cursor in the field and press 'F1' to display the documentation. This is a general feature of the Application Server for online help on input fields. In Part 2 of this blog series you were asked to enter 'SE80' in this Command field, which takes you directly to the ABAP workbench. This works only in the logon screen, in all other screens you have to add '/' as the first character and a letter as described in the documentation. For example, if you add an 'o' (as in 'other') before the transaction code, a new window will be opened for that transaction. To the right of the Command field, there is an icon to display a history of commands used. Just click the icon and a pull down menu appears with all the transaction codes you entered so far. Item No.2 is two buttons in the toolbar. The left button opens a new window, which is the same as '/o' in the Command field. The right button is for creating a shortcut on your desktop that will start the transaction you are currently in. You also can create a shortcut to any other transaction. Item No. 3 is a folder for your favorite transactions. Since it is not easy to remember all the transaction codes you can collect the ones you'd like to use more often in that folder. To make it more convenient for you, the folder displays the title of the transaction instead of the transaction code. Click the folder icon to open the context menu. 'Insert transaction' adds a new item to your favorites. You can do the same thing by clicking 'Favorites' in the menu bar. If you are in a screen and you don't know the transaction code, just click the 'System' button in the menu bar and select 'Status'. A new dialog box will appear.
This dialog box shows all the system information for your session. The transaction code used in the favorites folder can be found under 'Transaction'. One useful hint: In the Favorites folder and in the SAP Menu you can display the transaction code in the beginning of each line (see screenshot below). For that, click on 'Extras' in the menu bar and select 'Settings' and check for 'Display technical names'. Item No. 4 is a navigation tree to the different transactions. Just open up the SAP menu, click 'Tools', open the 'ABAP Workbench' folder, open 'Overview' folder, and then you'll find the 'Object Navigator' item.
Double-click that item, and the 'SE80' transaction is started. Since the ABAP Trial Version is only the Application Server, there are no business-oriented transactions in the navigation tree.
There are three buttons in the middle of the toolbar, all for navigation purposes. They are highlighted when active. The green button is the 'Back' button, which goes back to the previous screen. The yellow button is the 'Exit' button that interrupts the transaction and takes you straight back to the entry screen. The red button is the 'Cancel' button that stops the transaction, but will not always return you to the entry screen. To close the session, just enter '/nex' in the Command field and press 'Enter' or the green 'OK' icon to the left of the toolbar. All open sessions will then be terminated without any dialog.
A First Hello World Program '

After you have learned how to get the ABAP Object Navigator (transaction SE80) in the last blog it is now time to do it. And we will do here and now in this blog, we will write a Hello World program. Again, you will recognize a principle that I have explained in my blogs on the server. The ABAP development environment offers you a lot of benefits for free that take quite some extra work when developing in other languages. When developing in ABAP, your program becomes part of a large mechanism that helps to manage and organize development objects in a system landscape from the very outset. Let my elucidate this by an analogy. Creating a development object with C or Java is in a way like writing a text with a word processor: You write it, save it where you want and that's it. In contrast, developing a program in ABAP is like writing a text with a content management system where you are forced to create a document as part of a larger context with a number of default attributes, which help to pigeonhole your document within this system. The main structure is pretty simple: Every development object in ABAP belongs to a package. In general, every package has a property that determines to which other systems the package plus its content is transported if the package plus its elements are assigned to a transport request. The only exception to this rule is the package $tmp which is made for local developments. The content of this package is not transported to any other systems. In this blog we will create a program in this package for local developments, while in a later blog we will create a package that we will use as a container for all elements we will create in other blogs. The Repository Browser The Central Place in the ABAP IDE First we navigate to the transaction SE80 and have a short look at what we see there:
The Object Navigator is the development environment for the central editing of all development objects. We call these objects repository objects. This includes all ABAP programs of AS ABAP and all their components. However, there are many other repository objects, such as global data definitions in the ABAP Dictionary, global classes, or XSLT programs. Together, these development objects in the ABAP Workbench form a socalled repository. This repository is a special part of central database, which, instead of customer data, comprises the programs of AS ABAP itself. The buttons in the upper part of the navigation area allow the selection of a browser. You can configure in Utilities - Settings which browsers are presented for selection with buttons. The browser we will generally be using is the Repository Browser (1). It is the default setting of the Object Navigator and also the most generic browser, which provides an overview of all important repository objects sorted by different criteria. You access the repository objects through the Repository Browser by using so-called object lists. You must select such an object list in the dropdown list box, which is displayed in the navigation area under the
buttons. In our screenshot you see the local objects (2) of user bcuser. As we have not created any local objects by now, the area that shows these local objects is still empty (4). By choosing another entry in the dropdown list you can see other objects such as package, programs, function groups etc. The whole list is shown in the screenshot (3). Packages As already mentioned above, every development object must belong to a package. Packages organize development objects and handle their connection to the AS ABAP software logistics. That is a package is like a folder in a way. As for the software logistics, in ABAP your objects have to be assigned to a specific "software transport track" and a particular transport request. As soon as you release the relevant transport request, your object will be transported to the next system on that track. I will explain in another blog more technical terms what these tracks and transport requests look like in detail. You can view a package plus all its elements also in the SE80. Just choose the entry Package in the object list of the Repository Browser, enter the name of the relevant package in the input field below and press "Enter". Then all the objects of that package are displayed. A Package for Local Objects We will make do with the default package for local development for our first program. In this case we do not need to create a package and need no transport request. As already told, every AS ABAP contains a predefined package named $TMP, in which you can create local practice and test programs, that need not be transported to other systems. Each user has a local package of his own in a system. If the SE80 does not already show the space for your local objects, select "Local Objects" in the Repository Browser, enter "BCUSER" in the input field under the dropdown list box, and press "Enter": As result the Repository Browser displays all the development objects in this special package, which were created under your user name. Hello World as a Local Program To create a local program we select "Program" in the Repository Browser and enter the name z_hello_word_local in the input field below and press "Enter" or select the glasses icon.
Here you see a very helpful feature of the ABAP development environment. If you want to edit an object that does not exist, in general the system asks you if you want to create the respective object. We confirm and get to the next dialogue window. By the way, you should note and always remember as from now that repository objects created for customers in customer systems have different naming conventions than those that apply to Sap's own programs: A customer must use "Y" or "Z" for the first letter, or the abbreviations reserved by SAP for the customers company. Our Trial Version is set up as a customer system in which the user BCUSER is registered as a customer. Therefore the names of the objects we create must start with an "y" or "z". In the next dialog window we deselect the item "With TOP INCL", confirm, and get to the next dialog window.
In here you can define the properties of the new program. This is important, since the program properties determine the execution of the program in the ABAP runtime environment. One of the most important program properties of an ABAP program is its type. From the list provided, we want to select the type "Executable program" for our simple Hello-World- program, and change or add no other properties. In particular, ensure that the properties "Unicode checks active" and "Fixed point arithmetic" should always be checked. In the next dialog window we select "Local Object" and, thus, do not need to input a package name. And there we are. Now we have done everything we need to input the code of our first program. Note that in our blogs we will be using the new frontend editor available as of SAP NetWeaver 2004s, which like all modern editors supports syntax highlighting and so on. To configure this editor, select Utilities Settings - Frontend Editor (new). To configure the editor for your own preferences, you can select the icon in the lower right-hand corner. Up to and including Release 6.40 (SAP NetWeaver 04), you will still need to use the old frontend, which provides a lot less support for programming. To go on, we double-click the program name in the object list of the SE80.
On the right the editor opens. In it you see the framework predefined by the ABAP Workbench. This syntax consists of a few lines of comments, and also contains an initial statement named Report.
*&----------------------------------------------------* *& Report Z_CREATE_EXAMPLE_DATA *& *& *& REPORT Z_CREATE_EXAMPLE_DATA. * * * *
*&----------------------------------------------------*
*&----------------------------------------------------*
The first seven lines are comment lines, and the eighth line is a statement.
Comment lines are introduced by an asterisk * in the first position. The rest of the line is arbitrary and is shown in a different color by the editor. To mark only the final portion of a line as a comment, you can use the character ". As we want to input some code, we have to change the program. In order to do this we have to go to the change mode by pressing the respective button: Below the report-statement we enter: REPORT
Z_HELLO_WORLD_LOCAL.
data
output_text type string.
output_text = 'Hello World'. output_text. "obsolete statement
write
Admittedly, this listing needs some beautifying. The tool to do this is the Pretty printer. We configure the Pretty Printer at Utilities-Settings-ABAP Editor-Pretty Printer and select Convert Uppercase/Lowercase and below Keyword Uppercase. Next we press the Button Pretty Printer and our program now looks a bit nicer as all the keywords are now in capitals. To run the program we press the icon: Now let us spend some words on the syntax of this little program. Though this program is as simple as could be, I still want to add some comments on the general way ABAP programs are structured. Every standalone ABAP program, that is, all types of programs except for so-called include programs, start with an introductory statement. In our first program, the introductory statement is REPORT. This designation is historical and expresses the fact that an executable program was once exclusively used for reporting. Here, however, it suffices to know that our first statement introduces the program z_hello_world_local. After the introductory statement, every ABAP program follows a fixed program structure that divides it into two parts: a global declaration part a procedural part
In the global declaration part, which directly follows the introductory statement, declarative statements can be used for definitions and declarations, which will be visible and applicable throughout the entire ABAP program. Examples of objects that can be declared or defined here are data types, classes, and data objects. For larger programs, these declarations are generally made in a special include program, the "top include," which is supported by the ABAP Workbench and inserted at this position. After the global declaration part comes the implementation part, in which the actual processing logic of the ABAP program is implemented. The keywords and statements used in this program do not need many explanations. We declare a field of type string, assign a value to, and output it. Note some important information on the write-statement. The write statement outputs a list and it is driven by the classic SAP Dynpro technology which should not be used to write to used to write applications with an state-of-the-art user interface. You should use Dynpro-based UIs only in test-programs if you want to output (or input) some values in a quick and dirty way. You can compare the write-statement to the output to the console in Java. Just the same way you should not use the write-statement to output something in an application proper. The right way to do this is to use a Web Dynpro ABAP application as a user interface and to encapsulate all the logic of your programs in function
modules or classes. Still, we will use the write-statement sometimes in our blog series in order to output some results or to input some values a program needs. And this is the way, you should use this classic, but by now obsolete UI technology yourself: Use it (only) to test your business logic separately from the presentation logic. In order to show you, how the syntax check works in ABAP, let us change the Keyword DATA to DTA and press the Check Icon .
At the bottom of the editor we get the information:
This check gives you precise information as to in which line the error is. In case of a slip of pen like this, the system can make a reasonable guess as to what you wanted to type in, and proposes an semi-automatic correction. By pressing the Correct Errors button (marked by the red-dotted frame) you can accept the proposal and your syntax error gets corrected. Next we save our program by pressing the Save button: The real storage of the program in the database is done by the system. You need not worry about it. All you need to retrieve the program is the name. So there is no fumbling with files on the Web AS ABAP. If you remember the blog about the activation of programs, you probably know that this program is still not visible to other users. Why? There is no active version of this program. A version of program that is not activated is only visible to the developer of this program. In order to make our program visible in the whole system, we activate the it by pressing the Activate button: Now our program is visible to every user in the system. Summary Now you have learned all you need to develop a simple program in ABAP. You know that you need a package for every development object. If your objects does not need to be transported to another system the package $tmp for local development will do. You have seen how to find your way in the Repository browser of the SE80 and how easy you can create a new program. Just input the name of a new object and the system asks you if you want to create it. You are able to save, activate, run, or check a program for syntactical correctness
In other words, now you know the basics, and we can go on with something more complex in the next blog. Special thanks to Horst Keller and the Galileo Press. By courtesy of the author and the publishing house I could reuse some explanations of ABAP concepts from the lately published book: ABAP Objects. ABAPProgramming in SAP NetWeaver in this blog. And I will also do this in the following blogs of this series, as it is faster sometimes to reuse an explanation of some ABAB basics to some extent if it fits in the structure of the blog. In case, you want to know anything about ABAP in more detail than we can present here in our blog series, just consult the book. On 950 pages it covers, I feel temped to say, almost every conceivable detail of the ABAP language
Creating a Program and a Package - An Introduction to the SAP Change and Transport System
This blog is about how to create a transportable package, how to create a program within this package, and how to get the connection to the integrated software logistics of the server, the SAP Change and Transport System (CTS) right from the beginning. Doing this you will get a grasp of what a multi layer system landscape for development is for and what the concepts of a transport layer and a transport requests mean in this context. This will provide you with a basic understanding of the complex world of software logistics in the ABAP world. Unfortunately, I must confess it, you need a lot of dialog windows to define the relevant properties of a package and a program. And clicking through these windows is a bit of a bore. No kidding. And the worst is: It will take so much time to show you what attributes the package and the program need and to explain why they need these attributes with which value that I have decided to postpone any program code to the next blog. But still I believe that you need the information I present in this blog. And I will try to make the long walk through many dialog windows more interesting by adding some more basic information to the CTS. But do not expect too much from it. The world of SAP CTS is complex, and I can only scratch its surface. But let me first spend some thoughts on why we are not content with our demo programs in the package $tmp for local developments. Some Words of Motivation: Why Your Programs Deserve Better than Package $tmp Development is not only about devising cool patterns, algorithms and coming up with a hip design. This is the bright side of developing. What I show in this blog is, in a way, the monotonous housekeeping of the developer. It is not cool, but it has to be done, if you will not end up in a mess with your cool programs. And you will get rewarded for it. By assigning your development objects to a package and a transport request with the right properties, you will keep your developments tidy, from the very outset. This proper structuring of development objects becomes particularly important if you work in a team on a development project. When just developing on your own at home, this assignment of your objects to the software logistics is not strictly necessary and means some overhead expense for you. Nevertheless, you might also profit from it when just working on your own. To return to our analogy of housekeeping: Avoiding producing a mess is more important if you share an apartment, but it is not wrong if you live on your own either. The same applies in analogy to developing on your own with our demo version at home. There is only one default package $tmp for local development for each user. And you need more packages to manage a lot of different developments. Just imagine you had all files on you PC in one folder. In the same way, it does no good to have all your development objects in your package $tmp. But there is an even more compelling reason to use a transportable package as a container for your programs right from the beginning: You cannot even export local objects to a file. (In fact this is unconditionally true only for objects in package $tmp. They can never be transported. Objects in a local package can be transported in a special type of transport request: a request for the transport of copies. But this type of request can only be created in the Transport Organizer, SE09 and not from the dialog windows provided by the ABAP Editor in the SE80. As I do not want to introduce the SE09 in this blog we have to make do with a normal transportable package). As ABAP development objects are stored in the database of the system you cannot just copy a program file if you need it elsewhere. You need to export it to transport files first, and then you can import these files into any other application server ABAP if you have access to the file system of the underlying physical server. This is the motivation and an explanation as to why even solitary developers at home should not be content with developing in package $tmp. Your programs deserve better. They should live in a transportable package.
Creating a Package - the Chance to Get in Touch With the CTS This walk through a lot of dialog windows, cumbersome as it is, might still be interesting to those who have some experience in handling these things. In a way, this cascade of dialog windows resembles a wizard driven activity. You may get along in these windows, and still not really know what you are doing. This is the way I got through some wizards. I was happy to be out of it, and hoped that I had fed the wizard the info it needs and that the wizard would not take revenge on me: Maybe due to my limited knowledge I had provided some syntactically correct data that nevertheless did not lead to a semantically meaningful outcome. Since the input in these dialog windows connects your development objects to the SAP Change and Transport System and this powerful system is really complex, the odds are good that you do not really know what you are doing there, though you get along quite successfully in these windows. In any case, if you are one of those you will probably profit from this blog. Creating a Package - the Details By creating a package we are laying a cornerstone for all subsequent developments in later blogs, as we will use it throughout all parts of our little demo application. Moreover you learn the little steps you have to take before you can start typing in the code, whenever you need a new development object. After this blog we will simply presuppose that you know how to perform these steps, and if we create other development objects such as a global class, a function group and a function module, a database table or a data element in the ABAP Dictionary, we will only explain what is different from the procedure explained in this blog. As packages themselves are also repository objects, which can be edited using the ABAP Workbench, we use this tool to create our package. To do this, we select the package object list in the Repository Browser, and enter the name y_abap_demo into the input field below.
Again you see this very helpful feature of the ABAP development environment: If you want to edit an object that does not exist, in general the system asks you if you want to create the respective object. We confirm and get a dialogue window:
In addition to a short description you must specify the Application Component, the Software Component, and the Transport Layer. In order to input the software component, we select suitable entries from the selection list, which is displayed after pressing the input help key (F4). As already mentioned, this value help is an important and extremely helpful feature, and you find it throughout the SAP AS ABAP and all ABAP-based applications if their developer has provided it. So let me show you in the next figure how this value help works. You select the field with the label Software Component, enter (F4) and you get the value help if it is provided:
In our case the values you see are created by the system administration when the system was set up: It is a list the software components that are available in the system. The software component HOME is meant by SAP for customer development and equipped with all the tools available for this. We select it and confirm by selecting the check mark (1). In case a list in a value help is very long, select the telescope icon (2) and start a search. The Concept of a Transport Layer The transport layer is an important concept. It refers to the transport path a package should take in a system landscape. The usual landscape has a least three layers:
The basic idea behind this layered system structure is simple: You develop an object in the development system and test it in the consolidation system. When all tests are successful you transport your tested development objects to the productive system. The SAP CTS enables you to define this path as an attribute of a package. Due to this feature there is no fiddling about with the destinations of development objects. You just define them in the properties of the respective package in the beginning. How useful the concept of a transport layer is, becomes in particular evident if you have, for example, one development system for different productive systems.
In the landscape shown in this figure it makes sense to define two transport layers, one that for a path from the development system over consolidation system 1 to productive system 1 and the other layer that leads from the same development system to consolidation system 2 and productive system 2. Due to this organizational structure development objects destined for productive System1 are from the very outset in a different pigeonhole than those for productive System 2. The arrows in these figures only show the direction and the destination of the relevant transports. The transport layer by itself does not transport anything. You need a transport request to get something transported. Maybe an analogy can help to expose the way the concepts of a package, a transport layer, its respective destination system, and the export from and import into a system are interrelated: The transport layer is like a subway line and the transport request is like the tram. Assigning some object to a transport line is like buying a ticket for this line, while assigning an object to a transport request is like actually putting it on the train. Exporting the transport request is like the train leaving the station, and the import is the reverse. Some More Basic Concepts of the SAP Change and Transport System Let me show you an example to help you understand how a program BB in a package z_my_package assigned to transport layer DeCoPro and transport request 1 is transported through a system landscape with three layers (the names of the transport request and the transport layer are simply chosen for didactic reasons and irrespective of existing conventions and technical constraints). The figures just concentrate on the entities mentioned: The program, its package, the transport request and the transport layer.
1. Our Program is assigned properly to the package, this in turn is assigned to a transport layer, both are assigned to the same transport request, that is a transport request that has the same destination as the first destination defined in the transport layer. So far nothing has been transported. The transport is not released and you can still change it, that is, you can, for example, assign other objects to it or change programs in the request.
2. The transport request has been released from the development system and been imported into the consolidation system. As you see, there are copies of program BB and its package in the relevant destination system after the transport. And this makes sense: If the transport moved the program, many transports would empty a system, and above all, you could no longer change a program after it has been
transported out of a system. The released transport request is in the consolidation system too, and it also still exists in the development system. In fact, this is only the logical perspective. Physically the objects in a released transport request are written to a file, and this file exists only once. When it is imported into another system, this system gets a reference to this file. 3. Next after the tests in the test system are completed successfully we import the transport request into the productive system.
Again, physically the productive system just gets a reference to the exported transport request in the file. So the arrow between the systems only expresses a temporal and logical sequence. I still decided to use these arrow as this is the typical way to sketch the structure of the transports through a SAP system landscape. The physical structure (see figure below) is like this: When importing the Transport Request 1 into the consolidation and the productive system these systems just get a reference to the export files of the relevant transport request:
At this stage of the explanation, you might ask yourself what happens if you have to change program BB for some reason. Well, let us suppose in the productive system a branch of your program is executed that has not been tested so far, and the program does not behave as expected. So we have to change it, and we do this in the development system. This is what the division in the three layers is for. As the name suggests, in general, you only develop in the development system. Of course, there are some situations when you better correct errors in the consolidation system (for example if this system gets programs from different development systems and the error does not appear in the development systems, but only when the sources from the relevant development systems are activated and run on one system), but then you should change
the relevant development objects in the consolidation and the development system. Otherwise you will easily get inconsistencies between these two systems. But in our example we can stick to the general rule to develop in the development system. In order to change the program, we need to assign it to a new unreleased transport request:
There we are. We have assigned the program to a new unreleased transport request, which can still be changed. A package is usually only transported once, except for the case that the package properties have changed. For this reason we only assign the program to a new transport request and not the package. But what happened to the previous assignment of the program to transport request 1? Nothing. The point is simple: A development object can be assigned to one unreleased changeable transport request only, but, in addition to many released transport
requests. But why is it that the assignments to the old, released requests do still exist, if they are not changeable? What are they good for? Probably you guess the answers: This is for matters of versioning. Whenever a transport request is released a actual version of the program state at this time is stored. You can both return to this old version in case you need to or simply use it to track when which version of a program was released. Before leaving this short introduction to the transport system, let me mention that, of course in our example we need to transport our bug fix to the productive system, before our problem is corrected there. But this should suffice by now to give you a basic understanding of the SAP Change and Transport System. As I told you before, the CTS offers a complex set of features, and in this intro blog I can do no more than give you a clue as to what you are doing when you fill out the relevant fields during the creation of package and a program. Package Building Continued So let us go on with our example. For our demo system you should use the transport layer znsp throughout (as already told, you also need a transport layer if want to export a development object to a file. In a later blog we show how you export and import development objects to or from a file). If you have input all values as shown on the last figure you press the Create button .
In the next dialog window you have to assign your package
to a transport request.
As we do not have a transport request of our own so far we create one by pressing the Create button in this dialog window and the next dialog window appears. We input some short description as shown:
Just note in this context: In a real-world development project you will always use a transport request that is created in the transaction SE09 and paste this into the window with the header Prompt for transportable Workbench Request, that is the window we have just shown, and not create the transport request by using the Create button in this window. By using the SE09, you have more control on the transport request you get. If you just need a transport request without any particular properties, you can do it the way we do it here. Pressing the Save button opens another dialog window:
There it comes: Our first transport request. We finish the creation of our package by pressing the Create button. And now we have done it. We have created a package of our own. The package we have just created is shown in the list below the input field of the Repository Browser where the $tmp package of our BCUSER was shown before. In case you feel a bit dizzy by now because of the bunch of dialog window, do not hesitate. Let us do something similar again and pass a similar cascade of dialog windows in order to create a program in our package.
Creating a Program within a Package So we create a program within this package, or to put it another way, create a program and assign it to this package. If you have completed this task you will see that these dialog windows always appear in a defined order, and once you have understood this order, you will feel no more confused by clicking your way through the dialog windows that by walking through a long floor with several doors. So let us start. We right-click on the package Y_ABAP_Demo and choose Create - Program.
Again we are lead to a dialogue window, where we input the name of the program we want to create y_select_f_flight. We deselect "Top Include" because we still do not need a top include, and we confirm. As in the case of our last program z_hello_word_local we get the dialog window that defines the program properties. We confirm again and in the dialog window we see that the system already proposes y_abap_demo as the package for our program. We press the Save button.
The next dialog window also offers little work for us. The transport request our package belongs to is already in the relevant field.
Again we confirm and we have done it: We have created a new program within a package. The procedures I have just described might look like a lot of work, but let me repeat it: After a short while it will cause no more trouble than getting the car key, opening the car, sitting down, fastening the seat belt, and turning the ignition key. In real life, you hardly pay any attention to these actions. In the same way you will create programs in ABAP. The steps are always the same: Give the program name, Define the properties of the programs (in general, you just accept the values proposed by the system), Assign your program first to a package, Assign your to a transport request.
Outlook Instead of a summary I want to finish this blog by giving an outlook on what we will do in the next blog. By now the ABAP Editor has opened in the change mode and below the usual comments at the beginning of a report you have the first line: report y_select_f_sflight. You know this already from the last blog From here we will start in one of the next blogs and write a program that performs the task of a typical business program: It selects some lines from a database table that fulfill a given condition, stores them in a container in the program, an internal table, and shows this internal table in a quick and dirty way on the screen. We will use a Dynpro-based list and an object-oriented alternative to do this. As already mentioned, you should use this technology for test purposes only: It facilitates a fast and easy output to the screen, but does not support the model-view-controller paradigm. In some later blog we will show you how to output a table like this in a real world program: You encapsulate your business logic that contains the SELECT statement in a global class or a function module and offer the relevant data in a getter method. The presentation in the UI is done in a Web Dynpro ABAP application that accesses the relevant modularization unit that offers the data.
A First Little Business Program '

Now it is time to write a program that does something more than just output "Hello World". In blog 7 of our series we have done the necessary preparatory work, that is, we have created a transportable package for all our programs and a program within this package. With some more experience you will handle this prepwork very fast with hardly paying any attention to it, though it might look time consuming at first sight. The other reason why I spent some more time on this is that it will pay if you know what your are doing when clicking your way through these dialog windows: The SAP CTS (Change and Transport System) does not exist for its own sake, but it has proven to be highly useful in large development projects and that is why SAP created the CTS. In any case, the result of the last blog will be the starting point at which be begin to write our program. You will only be able to reproduce what we are doing in this blog, if you have the results of this blog or are able to create an empty report, that is a program of the type report. If you have trouble doing this, just look in blog 7. The Aim: Our first Little Business Program These were the preliminaries. So let us resume the work we have begun in the last blog. Our aim is to write a typical business program: It selects some lines from a database table that fulfill a given condition, stores them in a container in the program, and shows this data in a quick and dirty way on the screen. As to the presentation of the result in the user interface I will show three alternatives that are easy to realize, straight forward to understand and require a minimum of coding effort. You will probably be surprised at how simple it is to output a result table on the screen in ABAP. All three alternatives are based on classic Dynpro technology. That means you should use them for test purposes only, if you need to output some result fast. Each alternative has an advantage of its own and contains new ABAP commands for you: The first one is straight forward in that you see all the different components that you output. You can use the second alternative to output any result table of a SELECT on the screen no matter what its components are. Understanding this you get to know two important means for dynamic programming: the field-symbol, which is a sort of a pointer and the dynamic assign. The third alternative is based on a service class that needs hardly more than the name of table you want to output. The code of this gives you an impression of how object orientation is realized in ABAP. Nevertheless, useful and fast-to-realize as these alternatives are, they are all more or less comfortable ways to output results for test purposes. In a real-world program you use Web Dynpro ABAP, encapsulate your business logic in a global class or a function module and hand over the data needed in the user interface as parameters. But I think it is perfectly legitimate to use this classic technology at this stage of our blog series. Just compare it to the output to console so widely used in Java tutorials though nobody would bother a real end user with such a user interface. How to Use the ABAP Documentation Our example is based on the SAP flight model: This model gives a simple description of seat bookings in passenger airplanes by flight customers and is realized in a set of database tables such as SCARR for air carriers, SPFLI for flight connections, SFLIGHT for flights and SBOOK for bookings. You find more information on this model in the SAP Help Portal under this link. The SAP Help Portal contains the SAP documentation in different tree structures. The key node of the ABAP documentation in this portal is here. The topics we touch in our blogs are mainly covered under these three subnodes
The documents under the node ABAP Programming and Runtime Environment describe language-related topics. Under the header ABAP Workbench you find documentation on the tools to edit objects like reports, function modules, and global classes, on the Transport Organizer, on test tools like the ABAP Debugger and the Performance Trace and all the other tools of the ABAP Workbench. The Web Dynpro ABAP documentation provides a description of the complete architecture of Web Dynpro ABAP and its main concepts. You should consult the Help Portal for ABAP topics when you have questions that are related to tools, the architecture or the relation of concepts. For information on the keywords and syntax of the language itself there is the system documentation. One way to access the system documentation is by marking the relevant command in the editor and pressing the F1 button. How to Get an Internal Table with the Line Type of a Database Table This was a short digression to the ABAP documentation and how to access it. Let us go on and select some flights from the database table sflight, in particular the flights that fulfill two conditions: The airline is Alitalia and the seat capacity of the airplane is smaller than 250 seats. We want to output the result set of this select condition on the screen. We begin our program by declaring the data we need: DATA: itab_flight TYPE STANDARD TABLE OF sflight, wa_flight TYPE sflight. In the first statement we define an internal table with the line type of the database table sflight. The way this works in general is simple: DATA: sometable TYPE STANDARD TABLE OF [any database table]. This declaration defines the internal table some_table with the line type of the database table given in the square brackets at the end. A internal table is the ABAP data type that is tailor made for business programming. It is a dynamic data field that can contain a practically infinite number of lines. You can use centrally defined line types or define a line type within your program.
The figure shows a linetype for contacts (1). It consists of forename, last name and city. The internal table itab_contacts (2) can contain a practically infinite number of lines, the technical size limit for an internal table is 2 GB. Open SQL in ABAP Next we select from the database table sflights all flights of the carrier Lufthansa with airplanes that have less than 250 seats: SELECT * FROM sflight INTO TABLE itab_flight WHERE carrid = 'LH' AND seatsmax < 250.
As you can see a subset of SQL is part of ABAP. This so-called Open SQL has a big advantage for you: It is a database independent subset an SQL, so that your SQL statements are valid for the database of every vendor that is supported by the SAP NetWeaver Application Server ABAP. As the application server always has a database connection at hand, you need not care about opening, administrating and closing such a connection. By using the keywords INTO TABLE you perform an array fetch, that is, the whole result set is transported into the internal table. The only precondition is that the database table and the internal table have the same line type. Next we want to see the content of the internal table. One way to see the content of this internal table at runtime is to switch to the debugger and to have at a look at the content of it. We will show in a later blog how easy this is in ABAP. You can just set a breakpoint at a particular statement and the debugger opens as soon as this statement is processed. Test Output of an Internal Table 1: A Loop and a Write-Statement Here we will output the content of the internal table on the screen by using a classical list. ABAP has a particular control statement to loop over all lines of an internal table. Let us use it: LOOP AT itab_flight INTO wa_flight. WRITE: wa_flight-mandt, wa_flight-carrid, wa_flight-connid, wa_flight-fldate, wa_flight-price, wa_flight-currency, wa_flight-planetype, wa_flight-seatsmax, wa_flight-seatsocc, wa_flight-paymentsum, wa_flight-seatsmax_b, wa_flight-seatsocc_b, wa_flight-seatsmax_f, wa_flight-seatsocc_f. SKIP. ENDLOOP. Every line of the internal table is put into the work area consecutively. Inside the loop the different components of the work area wa_flight are written to the list output. In ABAP the hyphen is the component selector for a structure. How to Get to Know the Properties of a Database Table You may ask how could I know the components of this structure. Answering this question is a good opportunity to show another useful feature of ABAP. Obviously, the work area is a structure of the line type of the database table sflight. So we double click the name of this database table in the declaration at the top
of our report. We are asked to save the program, and we confirm. There we are:
The system has led us to the location where the table is defined. This is the ABAP Dictionary (transaction SE11). By using the Back button we return to our program. So this is the way you get to know the components of the line type of a database table. What the List Output with the Write Statement Looks Like The way the output to a list works is simple: As soon as the whole list is filled it is output to the screen. So let us save and run our program, and the upper part of the result on the screen looks like this:
Obviously this way to write the lines of the internal table while looping over it presupposes the knowledge of what the components of this table are.
Test Output of an Internal Table 2: A Dynamic Way to Output Any Internal Table Next I will show you a way to write the lines of a table without knowing the different components of its line type. First of all you can reuse these lines of code to output any result of a SELECT that is stored in an internal table. And secondly, you encounter two important means to realize dynamic programming in ABAP: the field-symbol and the dynamic assign. First we have to declare such a field-symbol, this is a particular field type in ABAP. Without going into the details of it, you should know that a field symbol works like a pointer without pointer arithmetics, but has a value semantics. That is you can assign it to different data fields and when accessing their content there is no need for dereferentiation. FIELD-SYMBOLS: <wa_comp> TYPE ANY. The typing ANY is necessary because the field symbol should be able to refer to data of any type. And this is what our loop looks like now using a dynamic assignment to the different components of the work area: LOOP AT DO. ASSIGN COMPONENT IF
itab_flight INTO wa_flight. sy-index OF STRUCTURE wa_flight TO <wa_comp>.
sy-subrc <> 0.
SKIP. EXIT.
ENDIF. WRITE ENDDO. ENDLOOP. The most complex activity is contained in the third line. The rest is simple and straight forward: The system variable sy-index contains the loop counter that is counted up with every processing of the loop. The n-th component of the structure is assigned to the field symbol. If this is successful (if sy-subrc =0) the content of the field symbol is output to the list using the write-statement. If there is no more component to be assigned to the field symbol, the assign is not successful (sy-subrc <>0) and the we leave the DO-loop (the inner loop) and go on with the outer loop. To check if our new lines yield the same result we outcomment the original loop. You mark the relevant lines and press CRT and "<" simultaneously. We run the program and the result is almost the same. There is one difference: This table has some more columns because this time we output all columns, while in the first alternative we have not shown the columns SEATSMAX_B, SEATSOCC_B, SEATSMAX_F, SEATSOCC_F. If you doubt this just double click on sflight in the program and look in the declaration of the table in the ABAP Dictionary. Test Output of an Internal Table 3: The Object Oriented Way A more comfortable way to output the internal table is by using a service class that outputs the whole table plus the header information provided in the ABAP Dictionary. First, we need to declare a field that can keep a reference to the service class. DATA alv TYPE REF TO cl_salv_table. The whole output is contained in two statements: cl_salv_table=>factory( IMPORTING r_salv_table = alv CHANGING t_table = itab_flight ). alv->display( ).
<wa_comp>.
The class method factory of the class cl_salv_table needs the internal table it should show, creates an instance of this very class, and exports a reference to this instance. In the second statement the method display of this instance outputs the table to the screen. Before we run the program, we should, of course, outcomment, the dynamic assign plus the loop:
The Whole Code of the Three Alternatives An Overview Now let us have a look at the whole code of our program in one listing. I have outcommented alternative two and three to output the internal table on the screen. So if you use this code as it is, you run alternative one. To change this just outcomment other parts of the code (press Shift + CRT + ">" to uncomment and CRT + ">" to outcomment some lines):
REPORT read_table_flights. DATA: itab_flight TYPE STANDARD TABLE OF wa_flight TYPE sflight, alv TYPE REF TO cl_salv_table. FIELD-SYMBOLS: <wa_comp> TYPE any. SELECT * FROM sflight INTO TABLE WHERE carrid = 'LH' AND
sflight,
itab_flight connid = '402'.
* Alternative one: Loop at table and write the different components of work area LOOP AT itab_flight INTO wa_flight. WRITE: wa_flight-carrid,
wa_flight-connid, wa_flight-fldate, wa_flight-price, wa_flight-currency, wa_flight-planetype, wa_flight-seatsmax, wa_flight-seatsocc, wa_flight-paymentsum. skip.

endloop. **Alternative two: Loop at table with dynamic assign of component *LOOP AT itab_flight INTO wa_flight. * DO. * ASSIGN COMPONENT sy-index OF STRUCTURE wa_flight TO <wa_comp>. * IF sy-subrc <> 0. * SKIP. * EXIT. * ENDIF. * WRITE <wa_comp>. * ENDDO. *ENDLOOP. ** object oriented way *cl_salv_table=>factory( IMPORTING r_salv_table = alv * CHANGING t_table = itab_flight ). *alv->display( ).
Summary Now you have learned: What an internal table is good for and how easily you can declare an internal table of the same line type as a given database table How you write a SELECT statement in ABAP and put its result into an internal table. A simple way to output an internal table on the screen by looping over it and outputting each line component-wise. A dynamic way to output any internal table using a field symbol and a dynamic assign. An object oriented way to output the whole table without any looping.
Getting More Familiar With the ABAP Dictionary

In this blog of our series we will improve the program from the last blog and show you some other useful features of ABAP and the development environment provided by the NetWeaver Application Server ABAP. You find an overview of all the blogs in the series here. Quite obviously our program is not very flexible. In fact, what the program does appears more hard-wired than really program driven insofar as you always get the same result. In this blog we will adapt the program so that you can choose the carrier on a so-called selection screen. Using this selection screen you can very easily create a UI to input the relevant parameter, but you should use this also (just as the list output) for test purposes only, as it is based on old technology. Still, with this limitation, the selection is the perfect means to create a user interface for input of test data in a quick hack. So we will create one to input the carrier. Astonishingly enough, we will find that there is a value help for the input of the carrier, when we call this selection screen from the program. Apparently this is quite useful, as the user cannot be expected to know the carriers available, let alone the abbreviations of the carriers that are needed by the program. At this stage, we will take the existence of this value help for granted, but keep the question in mind: Where does the value help come from, if we have prepared nothing of this kind in the program code? Moreover there lurks the problem that we do not know in advance for which searches we will get a nonempty result set. We cannot be sure if there are any flights in the result set for a particular carrier. To make matters worse, we also will not know, why the program does not show any flights, if this happens. You might suppose that there might be something wrong with the program's presenting the values in the user interface if it does not show any flights. We will tackle all the questions addressed in the course of this blog: First we show you how to navigate from the definition of a database table in the ABAP Dictionary (transaction SE11) to the Data Browser (transaction SE16) that enables you to look at the records in the respective table. This way, you can check beforehand whether the data you input will produce a non-empty result set. Having a closer look at the ABAP Dictionary and the way data types are defined there we will get a better understanding of how and why technical and semantic properties of a data type can be defined separately from each other: Semantic properties are defined in the Data Elements, while syntactic properties can be defined in the Domain. It is the data element that contains a reference to a Search Help. The so-called Search Help is also defined in the ABAP Dictionary and provides the value help we use when inputting our carrier as a parameter. In some of the next blogs I will present you the standard solution to problems like this: Quite obviously, the standard approach to a problem like this, is to use the debugger. This is true for ABAP as for any other programming language. But with the SAP AS ABAP it is particularly easy start the debugger. You can diverge into the debugger from the normal state of the system. There is no need to start the system in a particular debugging mode in ABAP. Moreover you will find, that the ABAP debugger offers all the functionality you expect from a state-of-the-art debugger. But this is something that should only raise your interest in the blogs to come. Explaining the ABAP debugger will not be part of this blog.
PARAMETERS and the Selection Screen We start by copying the program from blog 10 to another program. To do this, we navigate to the program in the object tree of the SE80, right click it and choose Copy. A dialog window opens:
We enter the name of the target program as shown and press the Copy button. Next we switch to the Change mode (by selecting the respective button). So what do we want to achieve? We are not content with the SELECT statement as it is: SELECT FROM sflight INTO TABLE itab_flight WHERE carrid = 'LH' AND seatsmax < 250.
Instead of always choosing the carrier Lufthansa, we want to enable the user to input other carriers and look what flights they offer. In ABAP this is quite easy to achieve. We declare a variable of the relevant type as an input parameter of the program: parameters: p_carrid type s_carr_id. This simple line of code serves two purposes: First, it is the declaration of the variable as we need it. (Later in the blog you will understand why we use the data type s_carr_id ). Secondly the parameters-command in ABAP creates a so-called selection screen at run time, that is a screen to input the respective variable(s) declared in this command. In order to make our parameter do some work we adapt the select statement: SELECT FROM sflight INTO TABLE itab_flight WHERE carrid = p_carrid AND seatsmax < 250.
We save, activate and run the program. As I have told you, we get to a so-called selection-screen.
<img src="https://blogs.sdn.sap.com/blogs/images/266/18_selection_screen_1.png" width="306" height="95" border="0" alt="image" />

Since we are not familiar with the carriers in the database we need a value help and press the F4 Button. Surely, you remember: This is the button to trigger the value help in ABAP, if there is a value help supplied. Obviously, there is a value help though we have not done anything to provide one:
<img src="https://blogs.sdn.sap.com/blogs/images/266/19_value_help.png" width="241" height="395" border="0" alt="image" />

We choose BA for British Airways, confirm and press the Copy button (with the checkmark icon). Noting happens. And this is the situation I have mentioned at the beginning of this blog. Obviously, we do not really know, if there is something wrong with our program or if there are no flights of British Airways with the specified capacity. From the ABAP Dictionary to the Data Browser As a first approach to solve this problem we try to find some other way to check if there are any flights in the table that match our SELECT criteria: We double click the name of the database table sflight in the data declaration of the program. The ABAP Dictionary opens. The Fields tab shows the name of each column plus its data type, as we have already shown in blog 10. At the moment we use the ABAP Dictionary only to pass through to another transaction that provides us a view on the content of the database table. To get there, we choose the menu Utilities Table Contents Display. We reach the selection screen of the Data Browser (SE16):
First we enter BA in the field CARRID. A message in the status line tells us: "No table entry found for specified key". In order to get an overview of all the entries in the table, we delete the input BA, select the Execute button, and get a list with the entries:
A view at the relevant section of the table shows that there are no entries for BA at all. So we have one part of the answer to the question of why our program showed no result list. Still you might wonder why the program does not even show an empty list. Let me add a particular feature of the report-logic to answer the question completely: If there is no list output the program returns to the selection screen. (But be careful: In case you ever want to use this feature in test programs, you should know that the selection screen is opened in an new internal mode. That means the global variables of the program are reset to their initial values.) Now it is time to have a look at the question of where the value help came from. You surely remember that in blog 10 I told you that the flight model is part of all delivered SAP systems. This means the respective tables and the relevant data elements are available in the system. That was why we could use the table sflight with all its components though we have not stirred a finger to create it. The same is true for the value help as I will show in the next section.
Data Element, Domain, and the Way They Interact We navigate back to the ABAP Dictionary, where we see the definition of the database table sflight. We want to have a closer look at the type of the component CARRID since we have a value help for a parameter of this type. So we double click the data type S_CARR_ID We get to the data element S_CARR_ID:
Still we find that the syntactic properties of the type are not defined in here, but defined in a Domain. So we drill down to the domain by double clicking its name:
To make a long story short, the ABAP Dictionary provides two levels to define a data type: The data element determines the semantic properties of a type, while you can assign a domain to the data element, and it is this domain that defines the syntactic of technical properties. What is this two-level-structure good for? Apparently it is a good idea to reuse the technical properties of a data type. For instance, a character field of length three can be used for all kinds of IDs, not only for carriers. They all share the syntactic properties, but need, for example, different labels. Probably you remember the last blog: When we output the internal table with the display method of the class cl_salv_table all the columns had header information on the screen. You might have asked yourself: Where did this information about the header text come from? It is now that we are in the right position to answer this question: The text used for headers is defined in the data element under the tab Field Label:
On the level of the data elements (1) you define the semantic properties, and, the syntactic properties are defined in the domain (2).
Of course, this two-level-structure is optional: If you want you want you can define also the syntactic properties in the data element.
At Last: The Source of Our Search Help The data element is also the place where search help for a data element is defined. Under the tab Further Characteristics you see the name of a search help: S_CARRIER_ID:
By double clicking the name of the search help we could go into the details of the search help. I do not want to do this here, but it should suffice to state: A search help is a particular kind of object that is created and edited with the ABAP Dictionary. It provides a value help with the with the list of possible input data by drawing the data from a table that serves as the data source. The fact that the search help is a property of the data type has a big advantage: A a search help defined in the ABAP Dictionary, is also available in Web Dynpro ABAP applications if the fields on the screen are typed with the right Dictionary types that supply such a help. We navigate back to our program by using the Back button and take some breath and sum up what we have learned so far about the ABAP Dictionary and the Parameters command. Summary The ABAP Dictionary (SE11) defines the technical properties of a database table such as the name and the data type of each column. It is possible to define the syntactic and the semantic properties of a data type separately from each other, the semantic properties in the data element, the syntactic properties in the domain. Typical semantic properties are the field labels and the reference to a Search Help. So we know by now where the value help that seemed to appear by magic is defined: In the data element of S_CARR_ID. A Search Help defined there can also be used in a Web Dynpro ABAP application. The Data Browser (SE16) is the place where we can get an overview of all the entries of a database table. We can navigate there via the ABAP Dictionary as we have seen, but we might, of course, also open another session, input SE16 as an ok code and enter the name of the relevant database table there. The Parameters command is very simple to use and still a powerful means to create a UI for user input. But nowadays you should use it for test purposes only because it is based on classic technology.
With the knowledge we have acquired, we can now check if the WHERE-condition of our SELECT should lead to a list output. In order to make sure that nothing else goes wrong, you should be able to use the debugger. As I have already mentioned in the introduction of this blog, I will soon introduce this powerful tool. You will find it particularly useful, since you can just jump into the debugger without making any time consuming preparations.
Debugging in ABAP
In this blog (blog 12 of our blog series) you get to know one of the most important tools for an ABAP developer, the debugger, and an important source of information that every developer needs: the ABAP keyword documentation. I will give you a short overview on the ABAP debugger and use it to find a particular bug. You will probably be pleased to learn that in the SAP AS ABAP it is very easy to start the debugger. You can diverge into the debugger from the normal state of the system. There is no need to start the system in a particular debugging mode in ABAP. Moreover I will show you how to benefit from some really useful features of the ABAP keyword documentation. All these explanations are embedded in a practical example: We will change the program from blog 11 in order to present fewer columns in the UI, to order the entries and to minimize the result set. In the course of doing this, you will learn: How to define a structure How to narrow the result set of a SELECT by reading less fields from the database A particular addition the SELECT statement that enables you to restrict the number of fields transported into the target field of the SELECT. Defining a Custom Structure in a Program As a preliminary we copy the program from blog 11 to the program y_select_f_flight_ad_2. If you have any trouble doing this refer to blog 11 where I describe how to copy a program y_select_f_flight_ad_1. Let us start by defining a narrower structure than the one we had in our program. You remember that by defining wa_flight TYPE sflight we got a structure that was as broad as the table sflight with all of its fields. We assume, we need only some of its fields, namely: carrid, connid, fldate, price, currency, and planetype. So we add a new data definition:
DATA: itab_flight TYPE STANDARD TABLE OF sflight, wa_flight TYPE sflight, alv TYPE REF TO cl_salv_table, BEGIN OF str_flight_s, carrid TYPE sflight-carrid, connid TYPE sflight-connid, fldate TYPE sflight-fldate, price TYPE sflight-price, currency TYPE sflight-currency, planetype TYPE sflight-planetype, END OF str_flight_s. If you have read the blog in which I introduced the data element, you know what additional benefit we get by using those Dictionary data types: They all have defined field texts. Since I intend to use the object-oriented way to output an internal table (look at blog 10) we will profit from these texts by getting headers for all the table columns we output. You may think that by now we do not even have an internal table that has the same line type of our new structure. And you are right. So let us create one: itab_flight_s LIKE STANDARD TABLE OF str_flight_s. does the job for us. We use the keyword LIKE because we do not give a type for the table line, but a structure. Next we adapt the select statement: SELECT * FROM sflight INTO TABLE itab_flight_s WHERE carrid = p_carrid AND seatsmax < 250. Again we have an array fetch, because we select the whole result at once, and we have yes, we have a syntax error. Press CRT + F2, this is the keyboard short cut for the syntax check to see this. A Useful Addition to the SELECT Statement At second thought it is easy to understand what is wrong with our SELECT. By using the asterisk we read all columns of table sflight, and this does not completely match with structure str_flights_s. Of course, there is a partial match, because the structure str_flights_s contains only fields that are typed with the respective types of the columns of sflight, but it does not contain all the fields of this database table, only a subset. Wouldn't it be nice if we could tell the program: Move just the fields from the result set to the target structure that have a counterpart in this structure. And indeed, there are some keywords in ABAP that do this job. We adapt the SELECT statement again: SELECT * FROM sflight INTO CORRESPONDING FIELDS OF TABLE itab_flight_s WHERE carrid = p_carrid AND seatsmax < 250. But be careful with the keywords INTO CORRESPONDING FIELDS. They can do no magic, but use the identity of the names for the assignment: That is the value of the selected entries from database table column A are moved to the fields in column A of the internal table. And this is all. In our case, the fields with an identical name also are of the same type, but if this would not be case this is not checked by the system. Next we use the object-oriented way to output our internal table. In order to get some additional information in case the internal table itab_flight_s is empty we add a condition. So our code looks like this: IF itab_flight_s IS INITIAL. WRITE: 'nothing in table.'. ELSE. cl_salv_table=>factory( IMPORTING r_salv_table = alv CHANGING t_table = itab_flight ). alv->display( ). ENDIF. We outcomment the two alternative ways to output the table (mark the relevant code and press CRT + SHIFT + "<"), save, activate the program, and run it.
What Is Wrong With Our Program We Start to Debug We know from blog 11 that there is a result set with some entries in it if we choose Lufthansa in the selection screen as the value of the parameter p_carrid and so we provide the same value for this parameter. Unfortunately the result is not satisfying:
It might seem hard to understand why we do neither get the output "nothing in table" nor an output showing some table entries. So this is the time to resort to the debugger. To see what our SELECT statement does at runtime we set a breakpoint at this line. We do this by double clicking the leftmost column in the editor as shown and a small icon appears that stands for a
breakpoint: Before starting to debug we check if we have really chosen the new debugger. In fact your system should already be configured accordingly. If not we open the menu: Utilities Settings ABAP Editor DEBUGGER and select "New Debugger". And now let us go. We run the program, choose the input parameter Lufthansa and select Execute or press F8: A new external mode opens and we see the new debugger. Let me use this opportunity to give you some general information on the debugger before we go into the details of how to find our bug. The New ABAP Debugger A Short Overview You know, you live in good times, at least as far as the ABAP debugger is concerned. Since NetWeaver 2004 there is a completely new debugger that runs in another work process than the program that is debugged, the debuggee. This is why the new debugger always starts in a new external mode. To put it in a nutshell: This debugger is a state-of-the-art tool that offers the features you expect from any debugger, even some features more (for example a tool to compare the contents of any two internal tables). The navigation within the debugger is straight forward, and you can easily configure the different tools in it as you like. As for the general layout of the debugger, it is divided in different tabs. Each tab stands for a desktop of its own, that can contain different tools, which, for example, show the source code, the call stack, or the value of variables etc. You can customize each desktop by inserting the tools you like in the position you want. To give you a general impression of what such a desktop in the debugger looks like let me show you a screenshot of the standard desktop with its three tools:
Below the menus that are not shown in this screenshot (experienced bloggers on SDN know: the size of pictures in SDN blogs is limited ) there is are some buttons to control how to step through the debugged code (5). In the panes below you see the standard desktop (1) with the source code tool (2), the call stack (3) and the variables and their values(4). So much for the overview of the debugger. But to really show you how to work with it we go on searching our bug. Debugging Our Program As the debugger has opened with desktop 1 we first choose the standard desktop tab to see the tools as shown in the figure above. We double click the name of the internal table itab_flight_s in the code view. That has the effect that the debugger shows the value of this variable in the pane on the right (4 in the figure above):
If you were more experienced with the ABAP debugger, this display would already tell you that we have an internal table with six columns and no line. So you can just guess it or must believe me. To make sure that this is the right way to understand what we see we double click the name of the internal table in this pane: We get to the tab rider that shows the content of the internal table so that we can check, if there were any lines to be displayed:
There are none. We navigate back to the standard desktop by using the Back button. Next we want to execute the SELECT statement and then look again at the content of the internal table. So we need a single step, and quite obviously the icons to control the debugging steps look as in most other debuggers, and
anybody familiar with debugging will have no problems to choose the right debugging steps in the ABAP debugger:
We select the single step mode as shown, look again at the content of the internal table in the right pane below. Obviously our internal table is now populated with 33 entries.
So we can feel relieved: There was no mystic loss of data in the system since the blog 11 when we had quite a number of entries for the carrid of Lufthansa. We go on in the single step mode, and see that the first branch of the if-statement is not taken. This is because the internal table is not empty. While we are stepping forward we have an eye on the content of the internal table in the pane on the right. It does not change until we reach the display method. So how could it be that there are no lines output, if the value of the internal table it not empty and this table is output? Obviously we have so far explicitly verified only the first part of the condition. So do we really output the internal table, which has 33 lines as the debugger tells us. We have a closer look at the relevant statement: cl_salv_table=>factory( IMPORTING r_salv_table = alv CHANGING t_table = itab_flight ). alv->display( ). And there is the culprit. We have passed the wrong table to the factory method. We double click itab_flight to view it in the variables tool. The table is empty, and this takes little wonder. It is the table we used in the blog 11. Since we have not deleted its definition it does still exist in the program, but no line was added to it. Remember: We meant to replace its name by the name of the table itab_flight_s in all statements. But it seems, we have forgotten one statement, namely the one in which an internal table is passed to the factory method. So the table itab_flight is still empty, and it is this empty table that we pass to the factory method. This is also the explanation of why our output showed many more headers for columns than our new narrow table s_flight_s. We showed the old table s_flight with all columns of the database table sflight and no content, because the result of the SELECT statement was moved to the new internal table s_flight_s. So we correct the statement accordingly, activate, save the program, and by double-clicking our breakpoint we remove it: For the time being we do not need the debugger, we are fully confident that we have corrected the mistake, and we are right. Let me use the last sections of this blog to tell you a bit about good SQL programming style and something more about the ABAP language documentation as I have announced at the beginning of this blog. Some Words on Efficient SQL Programming First of all, you probably know already that it is bad programming style to select more data from the database that is needed or used. Why is this so? In general, in a real-life system accessing the database is expensive. You have the network latency and you have to access the hard disk if the table is not cached. In general, both activities are far more time consuming than the execution of simple statements on the application server that do only affect the memory of the work area of the process the program runs in. Selecting all fields from a dataset on the database if in fact you move only a few fields to the target structure is as efficient as carrying ten buckets of water to the tenth floor and then pour five of them away. Of course, it does not really matter in our little example, but if you have result sets with some hundred thousands of datasets, you are well-advised to select only the fields you really use: So we adapt our select statement to:
SELECT carrid fldate planetype currency price connid FROM sflight INTO CORRESPONDING FIELDS OF TABLE itab_flight_s WHERE carrid = p_carrid AND seatsmax < 250. I have chosen a sort of random order for the columns just to show you that this order does not matter because the fields of the result set are moved according to their name. The order is irrelevant. How to Use the ABAP Language Documentation Efficiently Being economical we want to order the flights in the result by the price and the date. Most probably we need an addition to the SELECT statement. If you are not sure what the relevant addition you need looks like in detail, just position the cursor on the keyword SELECT and double click. A dialog window opens:
We double click the first alternative and get to a window with a tree in the pane on the left
: It shows the nodes and leaves under the node SELECT. Each node and leave corresponds to a page that is shown in the pane on the right. You can navigate to the respective page by double clicking a node or leave in the tree. The navigation within in the tree is quite as you expect it. We see that the SELECT node is marked and the corresponding page is shown. The entry for the SELECT node starts with an overview of the syntax of this statement:
We click sort key and get to the page that informs us in more detail:
So this should suffice to give you an impression of how you can drill down on the topic you need in the ABAP language documentation. You can use the arrow heads on top of the page to navigate back and forth to pages you have already opened. The button bar offers some other useful functions you might need:
I guess the tool tips require no further explanation.
So much for the explanation of the ABAP keyword documentation. To learn more about the ABAP keyword documentation have a look at a blog in which this source of information is introduced by its author. Let us now go on with our example and enhance our SELECT statement by the keywords we have just found: SELECT * FROM sflight INTO CORRESPONDING FIELDS OF TABLE itab_flight_s WHERE carrid = p_carrid AND seatsmax < 250 ORDER BY price fldate. We save, activate and run the program. Fortunately, this time it behaves as we have expected. Summary By now you should be able to use the debugger and to find your way in the ABAP keyword documentation. In a sense, you can now stand on your own feet in ABAP: You know how and where to find information on the details of the ABAP semantic and syntax. And you are able to track down the source of misbehavior if your program seems to lead a live of its own and does not what it is expected to. So in the next blogs I will explain not every new keyword we use as extensively as I used to. But as there is far more to developing in a language than knowing the details of its keywords there still remains a lot of work to be done in this series. In particular we will show you in the next blogs how to create database tables in the ABAP Dictionary and relate them by a foreign key relationship. We will fill these tables with entries from a text file we put in a directory of the server. And this is only the beginning. Some blogs later we will encapsulate our program logic so that we can call it from a state-of-the-art UI: an ABAP Web Dynpro View. At this stage you will learn the basics of Web Dynpro ABAP and how it interacts with the backend logic. So we hope this short sketch of what else is going to come will heighten you interest in this series.
Get Your Program up to Speed - Overview & Introduction

This Blog was posted by Hans Tillinger on 3 June, 2007, on SDN at ABAP. The runtime analysis tool allows you to examine the performance of any ABAP programs, such as reports, subroutines, function modules or classes that you create in the ABAP Workbench. It saves its results in performance data files, which you can display as lists. You can use these results to identify runtime-intensive statements, to combine table accesses, and show the hierarchy of program calls. Normally you use the runtime analysis tool to measure the runtime of complex program segments or complete transactions (if you want to measure the runtime of smaller program segments or individual ABAP statements you can use the ABAP statement GET RUN TIME FIELD). However, we use only simple examples in this blog, in order to make the understanding easier. The Programs to Be Analyzed Let's assume I am a very newbie in ABAP and I have written a tiny little program which is doing the following: -reading data from a database table storing that data in an internal table display that data on a list (at the start of the program you have to specify certain key values; only matching data should be displayed later on).
So here it comes (and it seems to work as designed ...). REPORT y_wlog_atra_1. PARAMETERS: p_carrid TYPE sbook-carrid DEFAULT 'LH', p_connid TYPE sbook-connid DEFAULT '0400'. DATA: wa_sbook TYPE sbook, itab_sbook TYPE STANDARD TABLE OF sbook. SELECT * FROM sbook INTO wa_sbook. CHECK: wa_sbook-carrid = 'LH' AND wa_sbook-connid = '0400'. APPEND wa_sbook TO itab_sbook. ENDSELECT. LOOP AT itab_sbook INTO wa_sbook. WRITE: /, wa_sbook-carrid, wa_sbook-connid, wa_sbook-fldate, wa_sbook-bookid, wa_sbook-customid, wa_sbook-custtype. ENDLOOP.
A nice colleague has thrown a glance at my source code. He has given the hint to use a WHERE clause with the SELECT statement instead of the CHECK statement for reasons of better performance. So I have written another program ... REPORT y_wlog_atra_2. ...
SELECT * FROM sbook INTO wa_sbook WHERE carrid = 'LH' AND connid = '0400'. APPEND wa_sbook TO itab_sbook. ENDSELECT. ... I am curious about the performance now. Let's compare the 2 variants with the ABAP Runtime Analysis tool. ABAP Runtime Analysis: Tool & Procedure To start it, choose Test --> Runtime Analysis in the SAP Menu, or use transaction SE30 The runtime analysis procedure consists of two parts: Recording performance data (upper part of the screen) Analyzing the performance data (lower part of the screen; this part only appears if there are performance data files in place)
The procedure for the first part (Recording performance data): We go to the initial screen of the runtime analysis (transaction code SE30) and specify the name of the first program (Y_WLOG_ATRA_1)in the relevant input field. After that we press the button Execute
The selection-screen of the program Y_WLOG_ATRA_1(including the 2 input fields) is displayed. At the bottom of the screen we are informed that the measurement has been started. We continue by clicking the Execute button. Later on we will see that a file (containing performance data) has been created in parallel.
Now we repeat that procedure for our second program (Y_WLOG_ATRA_2). The second step is the analysis of the generated performance data. To do that we have to go to the initial screen of the Runtime Analysis tool again. On the bottom part of the screen you can specify those performance data files you want to analyze. You can see some information related to the last measurement run (in our case that was program (Y_WLOG_ATRA_2). By pressing the button Other File we are able to select those performance data files we like to analyze.
I want to see all the files I have created (user BCUSER).
I get the relevant list with 2 lines (related to the performance data files of the programs Y_WLOG_ATRA_1 and Y_WLOG_ATRA_2). Based on that list you can display the distinct performance data per line. You have to click in the column Object Type of the relevant line.
As a start the tool displays the evaluation overview (showing the cumulated execution times for the ABAP, database and system-level). Here comes the evaluation overview for program Y_WLOG_ATRA_1
We can do the same for the other program Y_WLOG_ATRA_2
By comparing the performance data of the 2 programs we clearly see that I have done well with listening to the advice of my colleague. The performance of the second program is dramatically better.
In the next step you can forward to a more detailed display of the performance data (hit lists). That listing shows the different granular execution steps (according to your filter adjustments ). Here you can easily identify the most time-consuming program units.
And it will also be a good idea to glance at the Tips & Tricks corner. You will find many valuable suggestions about good performance definitely.
The Foundation of an Application - Creating the Database Tables

This blog of our series (find the other blogs of the series here) is about building and managing the foundation of any business application: The database table(s). With the ABAP declarative approach of the Data Dictionary these things are so easy that you can concentrate on your data model and leave all database vendor specific details to the system. From a technical point of view what I will explain is easier to understand than the SAP Change and Transport Management. Still this blog is hard stuff because it contains a lot of details and it is has become longer than I planned. But I saw no good way to cut the material into different parts. In addition to the technical information I will explain the concept of a client in the SAP world to some degree since we will build a client-specific table. When creating a table on the Application Server ABAP all you have to do is to define the metadata of a table, including foreign key relationships and check tables, search helps and fixed values. Just activate the relevant object (s) in the Data Dictionary (transaction SE11) and the table is created on the underlying database of the system. No need for any code as far as the data definition on the database is concerned. No need either to care about vendor specific technical details. Your database tables will be created on any database that is supported by the Application Server ABAP if this is the database of your system. We will implement a simple data model almost from scratch in this blog. You will learn in some depth the basics of How to define a database table How to define a foreign key relationship and thereby How to provide a check table for the relevant column in the foreign key table. How to create data elements and domains How to create fixed values in the domain.
You perform all these things in different screens of the Data Dictionary. This way you will get to know how to manage database tables in a metadata-driven approach that is typical of developing on the Application Server ABAP. Our central table will be a table of accounts that is related to some other auxiliary or check tables. So I will give some substance to the claim of how easy database table handling is on the AS ABAP. Another blog will show you how to fill this account table with data very easily by inputting some data into auxiliary tables in the Data Browser (SE16) and then using these data in a program to create random entries for the account table. The Contents of this Blog in Some Detail We want to create a table YACCOUNT that contains accounts and we want to use this table plus its auxiliary tables for queries later in other blogs. The account table is related to a customer table by a n:1 relationship: One customer can have many accounts, but an account is uniquely assigned to a customer. As for the customer data we can profit from the fact that there is already a table with customer names and some relevant attributes: The table SCUSTOM is part of the flight model that is delivered with every ABAP system and this table should contain about 1500 customers in the Demo System you use. So we need not define a customer table of our own and fill it with data, but we can simply re-use the table SCUSTOM and relate our account table YACCOUNT to it by a foreign key relationship. In another blog we will fill the database table YACCOUNT with some test data. This step is very important for every business application. You have to test an application to see if it works. And you only can test it, when you have some test data: We will first manually provide a small set of test data for the check tables in the Data Browser (SE16). Using these entries in the check table a program of some 70 lines will create random entries for the table YACCOUNT. This way we will get the test data that enable us to run Web the Dynpro ABAP based applications we write in later blogs in the environment these applications need. Let us now consider the structure of our central table in some detail: The account table should provide columns for The client The account number,
The bank, The city of the bank, A customer ID that is related to the customer table, The balance The currency A category that specifies the height of the income that is transfer to the account every month.
Since the identity of an account is defined by client, account number, bank and the city of the bank, we define a composite key with these four columns. This means there cannot be an account with the same account number in the same client with the same bank in the same town. Further will assume that the number of banks, towns, currencies, and income categories is limited in our example. So we will provide check tables: For example the currencies permitted in our table, the foreign-key table, are controlled by a table for currencies, the check table. These tables have to be related by a foreign key relationship that is can also defined in the ABAP Dictionary. This way we will also create these check tables and the relevant foreign-key relationships when defining the table YACCOUNT. Though we can profit from the existence of the table SCUSTOM we still need some other tables: For the bank and the city of the bank we will provide check tables to delimit the banks and cities allowed, but we will keep these tables very lean indeed. As for the category, we do not need a check table, but can use so-called fixed values in the domain of the relevant data element to control the number of entries in the category column of the account table. Defining all these things plus the data elements required might seem a bit tiring if not intimidating at first, but you will soon realize that you do not need a lot of practice to create data elements and database tables really fast in the Data Dictionary. It will be the same experience as the one you had when defining a package LINK: When you have done it a few times with the relevant tools and have got accustomed to the procedure, you will find it as easy as pie. So do not let yourself be put off when having a look at the all the stuff we are defining in this blog. I will spend less time on explaining details than in the last blogs. Having worked your way through the blogs of our series you are sort of an advanced Newbie to ABAP. When I show you how to create data elements and domains, how to define tables and how to relate them by a foreign key relationship I presuppose that you are able to find your way in the ABAP Dictionary. In other words: I presuppose that you are familiar with the blog on the Data Dictionary in our series. In particular you should know what a data element is, what the respective definitions of field labels for data elements the definitions of fields for a table look like, not in great detail, but to the degree that I have explained this in the blog mentioned The Concept of a Client: A Key-Player in the SAP World of Business Programming When defining the fields of the table YACCOUNT you see that the first field is the client. Probably you do not know what a client is. At least to me "The Client" was no more than a suspense movie before I joined SAP. Within the context of SAP ERP systems the client is an important concept that deserves some words of explanation. Though the main focus of this blog series is on ABAP, its development environment and the way you develop with this powerful language for business programming, it is nevertheless for some of you also a first step into the SAP world. And within this world you simply should not only know the definition of what a client is, but have some basic understanding of this concept. Those of you who are more interested in ABAP development in a narrower sense or are already familiar with the client concept should simply skim or skip the rest of this section. A Client is in commercial, organizational, and technical terms, a self-contained unit in an SAP system with separate master records and its own set of tables. This definition of a client in the SAP Help Portal is, of course, comprehensive and true, but you may still as yourself how one concept can have a commercial, an organizational and a technical aspect at the same time. Let me start by sketching the commercial aspect of the client concept. Then I explain how this creates technical requirements and how they are fulfilled. From one point of view an ERP system holds A large bunch of business data and
the applications that work with this data. These applications represent the business processes of a company.
Obviously it is a good idea to organize these data according to organizational units and the business needs of a company. The same holds true for the technical fine tuning of the business applications: For example, the different international subsidiaries of a global company may need to implement the same business processes differently in their systems. What I have loosely called the technical fine tuning is done by means of customizing in an ERP system: You adapt an application to the specific structure of your business processes. And maybe you want to adapt it in different ways for different subsidiaries. In other words: The data need to be structured by organizational and business-related criteria, and the processes may require different customizing for different subsidiaries of a company. It is the concept of a client and the way it is implemented in a SAP ERP system that helps to fulfill all these requirements: The client is the highest organizational unit in an ERP system and a self-contained unit with its own master data. From a commercial point of view a client can represent a corporate group of legally independent companies. And you can customize the same process differently in different clients. How is this separation technically achieved with the client concept: The client is the first key field in most relevant tables of an SAP ERP system. A user in an ERP system is always logged on to a particular client of a system. A SELECT in a program always selects only the data from the client the programs runs (system field sy-mandt). There is no need to specify the client in the WHERE-condition. The client-specific data are automatically selected.
It is because of this structure that you can keep the data of different clients in one table and still keep them apart as if they were stored in different tables. And this is why our table is designed the way it is with the client as the first key field. By the way, the client-specific customizing is also, to a large degree, realized by tables that are designed the way I have just described. But now let us return from this abstract explanation of a key concept of the SAP ERP world to the mundane task of creating our table. Defining the Data Elements It is common practice to use data elements for all columns of a table and there are good reasons for this practice: 1. All foreign keys must be typed with a data element. 2. So check tables to control the values of columns require a data element. 3. The field labels defined in a data element will automatically provide translatable column headers and labels when the respective data element is shown in the User Interface. This applies for Dynprodriven test UIs and Web Dynpro based user interfaces. We need data elements for the account number, the bank, the city, the customer ID, the balance the currency, the date of the last entry, and the category of the account. The first column for tables in common business applications is the field MANDT which represents the client. We name the other columns ACC_NUM, BANK, CITY, CUSTOMER, BALANCE, CURRENCY, LAST_ENTRY, and CATEGORY. The Field CUSTOMER contains an ID that is related to the customer table SCUSTOM by a foreign key relationship. For the columns MANDT, CUSTOMER and CURRENCY we can reuse data elements that already exist. This re-use of existing data elements is also common programming style when developing in ABAP. Data Element for the Account Number: Y_ACC_ NUM First we create the data element Y_ACC_ NUM. We navigate to the transaction SE11, select Data Type and press the button Create. In the dialog window we choose Data Element and continue. We enter the short description Account Number, select the radio button Predefined Type on the tab rider Data Type, and input NUMC, a numerical character type and a length of 8. On the tab rider FIELD LABEL we have to input labels of different length for our field:
We input Acc.Num. as a short label and Account Number in the other lines. We need not provide enough space for some translation of the labels, and so we need not input the length for the Field Labels, but the system calculates it by the actual length of the field labels we have just input. When activating the data element we choose y_abap_demo as the package as in the other examples. The next dialog window proposes us the same transport request as in the last example programs. We continue and activate the data element (we will use this package and this transport request throughout this whole example without mentioning this fact any more in this blog). Data Element for the Bank: Y_BANK Next we create a data element for the name of the bank. The procedure will be the same: 1. Input the name in transaction SE11: Y_BANK 2. Enter a short description: Bank. 3. Input the appropriate format: CHAR of length 30. 4. Go to the tab rider Field Label and enter Bank for the labels of all lengths. 5. Activate and Save.
Data Element for the City: Y_CITY The data element Y_City has City as a short description and as the text for all field labels. Its format is CHAR and length 30. For the column CUSTOMER we can reuse an existing data element from the table SCUSTOM, as I have already told you. Data Element for the Balance: Y_BALANCE So we go on and create a data element for the column BALANCE: Y_BALANCE. We proceed in the same way, but this time we will use a domain instead of defining the data format by ourselves: We input the short description Balance, select Domain as Elementary Type, input the domain name S_PRICE, and press Enter: The data format of the domain is shown below: CURR 15, decimal places 2. To complete the definition of this data element Y_BALANCE we have to provide field labels in the way shown before: We input Balance for all lengths. We save and activate the data element. Since you need to save and activate all objects that you create this procedure will only be mentioned time and then. I just presuppose that you know by now when and how to do this. Data Element for the Last Entry: Y_LAST_ENTRY For the field LAST_ENTRY we create the data element Y_LAST_ENTRY with the domain S_BDATE and LastEntry as the text for all field labels and Last Entry as a short description. Data Element for the Category: Y_CAT Last we define the DATA Element Y_CAT with the short description: Account Category and the field labels: Category (short) and Account Category (all other labels). By forward navigation we define the domain: Y_CAT, format: NUMC and length 1. We switch to the tab rider Value Range and input the fixed values: 1 with the short description low income, 2 and medium income, 3 and high income. Creating Database Table YACCOUNT Now we have all the data elements we need at hand and we can create the database table YACCOUNT. By the way: It is also possible to create the data elements you need by forward navigation when defining a table, but I have decided to separate the definition of the data elements from the definition of the database table in this blog for didactic reasons.
We return to the start screen of the Data Dictionary, select Database Table, enter YACCOUNT, and press
the button Create. In the next window we input the short description: Account. Under the tab rider Delivery and Maintenance we input A as the Delivery Class and Display/Maintenance allowed with Restrictions. We change to the tab rider Fields and enter the name of the fields and their data elements as shown in the figure below:
Next we mark the line CUSTOMER and press the Key icon to define a check table for this line and a foreign key relationship. We refuse the proposal in the first dialog window as this suggests the check table from the domain and this table is not suitable for our purposes. In the next dialog window we input the short text: Check table for account ID and the check table SCUSTOM. Next we press the button Generate Proposal and get to the next dialog window. There is no magic, but the system draws the proposal from the identity of the data elements.
We enter 1: CN as the cardinality, and then we check the definition of the table for consistency by pressing the Syntax Check icon. If this check is successful we press the Copy button. As you need to define other check tables on your own later in this blog, let us repeat the steps necessary to define a foreign key relationship with a check table that determines which values can be input into a particular field: 1. Mark the line with the relevant field/column.
2. Press the button with the Key symbol. 3. Input some explaining text and the name of the check table. 4. Press the button Generate Proposal. (If the relevant data element has a value table defined in its domain this table is proposed by the system after step 2.) 5. If the proposal is ok, just enter the relevant cardinality and press Copy to close the dialog window and keep what you have input there. We need another check table for the currency. Again we mark the line and press the Key symbol. This time we confirm the proposal:
And we get rewarded by an almost complete proposal that is made by the system:
We only have to enter a suitable text and there we are. We select the Copy icon and have another check table. The tab rider Entry help/check shows us the check tables for the table YACCOUNT.
Next we define a reference field for the column of the type CURR as shown in the figure below:
A reference field is needed for all currency and quantity fields as the figures in this field need a currency or unit. If you have no reference field and table for fields of this kind you will get a syntax error. This syntactic constraint reflects a semantic fact: A figure in a field does not tell you a lot if you do not know to which quantities or currencies the figure is related: It does not suffice to know that you have, for example, five items, but you need to know if you have five meters, five Euros, five pound etc. And this information is provided the reference field and table. There still remains some work to be done. We select the menu Extras Enhancement Category. Here we determine if and if so to which degree the table can be enhanced: We choose Can be enhanced (charactertype or numeric) and press Copy.
After saving again we press the button Technical Settings and choose the data class APPL0 and the size category 0.
We save and activate, return to the view of the table we have been working with before. Next we save and activate the table. Let us pause for a second and reconsider the steps necessary to create a database table in the Data Dictionary: 1. Go to the start screen of the Data Dictionary. 2. Type in the name of the table and select the Create button. 3. Enter a Short Description 4. Choose the Delivery and Maintenance tab rider and input a delivery class and determine if and how the table can be maintained and displayed. 5. Change to the Fields tab; input the name of the fields and the respective data elements. 6. Select the Key checkbox for the key fields and select Initial Values for all fields. 7. Save and press the button Technical Settings.
8. Choose a data class and a Size Category by using the input help. 9. Save, go back and choose the menu item Extras Enhancement Category and input this category. 10. Provide check tables and Reference Fields plus Tables if you need to. 11. Save and activate the table. The table is now being created on the database. This is what is meant by "metadata-driven creation" of database tables: You define the metadata and once you activate this metadata, the table is created on the database.
Providing Some More Check Tables Now you can test to which degree you have already understood the steps you need to define a table. We still have to create the check tables for the columns BANK and CITY, and I will keep the description of how to do this really short. In case you have any problems when creating theses tables just return to the last section. For the field BANK in the table YACCOUNT we create the table YBANK with only one column BANK and the data element Y_BANK: Again we choose A as the delivery class, but this time we select Display/Maintenance Allowed. This is important, because we will input some banks into this table in the Data Browser (SE16), and this is only possible if the maintenance of the table in the SE16 is allowed that is with this value for the attribute Data Browser/Table View Maintenance. The technical settings and the enhancement category for the table YBANK are the same as for the table we have defined above. So should know how to handle this. We need another check table for the field CITY in the table YACCOUNT. We name this table YCITY. Apart from the columns this table has the same attributes as the table YBANK and the column CITY with the data element Y_CITY and another column CURRENCY with the data element S_CURR. After you have completed their definitions, we need to create the foreign key relationships with the relevant columns of the table YACCOUNT. You should also we able to do this on your own by now. Let me just give you some hints on how to do this: Mark the relevant line in the table YACCOUNT, press the Key icon, enter a short text plus the relevant check table, press the button Generate Proposal, and input the Cardinality 1:CN. You may ask what the second column CURRENCY in this table is for. We will use this table YCITY to generate test entries for the table YACCOUNT in another blog. For reasons of simplicity we suppose that the currency of an account is determined by the city of the respective account: For example, all accounts on banks in New York have Dollar as the currency. To uniquely assign each city to a currency we write the respective currency for each city in the same row as the city. Our data generator program will select the city and currency and one dataset from one row of the table YCITY. When looking at the code of the program that generates the test data for us, you will understand why and how this simple table will do the same job as a long CASE construction and keep the code far more readable. Of course, in a more complex example with a more complete data model we would also add the country, maybe as a column of the currency table or in a table of its own. But I have to decided to keep our example simple instead of defining as many tables and attributes as we would need in a more real-world example. Though we want to keep the model simple we will quickly establish another foreign-key-relationship for the table YCITY. With some experience in data modeling you probably know which relationship is still missing: We mark the line CURRENCY in the table YCITY, press the Key symbol, and we get the right proposal by the system: Check table SCURX. So we complete the definition of this check table in the same way as before when we defined the other check tables. So much for some short considerations on the design of our check tables Do not forget to save and activate the table YBANK and YACCOUNT, and there we are: We have defined a table with four check tables, which also provide an input help for the respective column of the table. You might ask yourself why there are more input helps than check tables. That there is input help for the column LAST_ENTRY results from the fact that every date field gets a calendar as a input help by the system for
free. The input help for the column CATEGORY is based on the fixed values we have input in its
Domain The table SCUSTOM and the table SCURX are already well filled with data, and the tables YBANK and YCITY will be filled by us in the DATA BROWSER (SE16). Summary By now you should be able To define database tables Including all the attributes To define the data elements and domains you need To reuse existing data types To establish the foreign key relationships with check tables.
From a more semantic point of view we created the tables we need in subsequent blogs. Moreover you should have understood the basics of the concept of a client in the SAP world, what it is good for, how it is technically realized, and which impact this concept has on the design of database tables. What is still missing is the content of these tables. And this is what we will provide in the next blog: We will write a little program of some 70 lines that enables you to create a number of random entries for these tables. Doing this you will understand once more what is so good about internal tables.
How to Dynamically Create Test Data for Our Database Table

Since you have to test an application to see if it works, and since you only can test it, when you have some test data, what we are doing here is an essential step: In this blog of our series (find the whole series here) we will fill the database table YACCOUNT we have created in the last blog with random entries. We will first manually provide a small set of test data for the check tables YBANK and YCITY in the Data Browser (SE16). Using these entries in the check table a program of some 70 lines will create random entries for the table YACCOUNT. It is these entries that will be the data for the SELECTs we will perform later to provide data for queries started in a Web Dynpro ABAP interface. You need quite some data in your database tables if a SELECT with a complex condition should return a reasonable result set. So it will be a good idea to create some thousand of datasets with the data generating program. In principle, you can choose any number of entries you want to apart from the fact that for numbers larger than a million the performance of the program will diminish. So let us better take account of the fact that we just work on a little demo system and be content with creating some thousands of test dataset. But this discussion already hints one advantage of the program we are going to write: You can create the number of data sets you want provided your system has the relevant resources. The Basic Principle of How to Create the Entries Randomly The basic principles of how we create the entries for the database table YACCOUNT is simple: We use a loop and create each dataset separately. We create a random value for each column of the table in a way that the value fulfills two conditions: 1. The random value meets the semantic and syntactic constraints for the respective column satisfied. 2. It is guaranteed that there is only one dataset with the same composite key: unique-key condition. Let us consider the different types of semantic conditions for the different columns. First of all we have to fill the check tables that have no data so fare: A. Fill the tables YBANK and YCITY with some data. As described in the last blog a line of the table YCITY contains both the city and the currency assigned to the city. The customers table needs not be filled as it already contains some hundreds of datasets. The data in these check tables plus the fixed values we have defined for the column CAT define the constraints that the random values we create for the respective columns have to meet: The random value for each column has to be a member of the set defined by the entries in the check table. For example, a valid city has to be part of the table YCITY etc. B. How do we create one dataset: For columns with a check table we have to make sure that the random value is an element of the set defined in the check table. How is this done: 1. Load the relevant check table into an internal table. 2. Get the number of entries (NmbEn) of this internal table. 3. Create a random z integer between 1 and NmbEn of the relevant table. 4. Select a line from the internal table randomly by index access with index z. C. As for the account number we have to create a number that is between 10000000 and 99999999 and to assure the uniqueness of the composite key. This is achieved by creating the values for BANK and CITY for a dataset first. Then a random account number is created and only accepted if there is no other dataset in the internal table with the same composite key. If there is already a dataset with that key, another random number is created and so on, until a unique key is created. D. The structure of the table YCITY assures that every account has the currency that is assigned to its city: The table YCITY provides a unique currency for every city. Once a line is chosen from this table randomly the city and the currency of the respective dataset are determined at the same time. E. The balance is simply calculated by creating a random integer between 0 and an upper limit. F. The entry date is the system date. G. The values for the category are just random integers between 1 and 3.
So each column of the dataset will contain random data that meet the semantic and syntactic constraints by the mechanisms described. After a dataset is created it is added to an internal table of the same line type as the database table YACCOUNT, and the next dataset is created. Once the number of datasets that the user has provided as a parameter to the program is created the whole internal table is stored in the database. How to Fill Database Tables in the Data Browser Let us now look in some more detail at how we fill the tables YBANK and YCITY with values: The steps to fill a table with values in the Data Browser are simple: 1. Go to the Data Browser (SE16). 2. Select the Create Entries Icon. (second from the left) 3. Type in the values and press the Save button. 4. Press the Reset button. 5. Repeat this step for all values you want to input. This the button you press at the start screen of the SE16
And this is what the screen looks like where you input the data:
Input these values in table YBANK: DEUTSCHE BANK, JP MORGAN, CITIBANK, WASHINGTON MUTUAL, COMMERZBANK, UBS, UNICREDITO ITALIANO, CITYGROUP, CREDIT SUISSE, BANK OF SCOTTLAND, HYPOVEREINSBANK, and DIREKTBANK. Input these pairs of values into the table YCITY: BASEL, CHF BOSTON, USD FRANKFURT, EUR MILANO, EUR MUNIC, EUR NEW YORK, USD, PARIS, EUR LONDON, GBP The program that generates the test data works fine with any other set of banks and cities/currencies. So if you prefer other banks and towns just type them in. It is understood that the more banks and cities you have the more diverse will be the generated test data.
As I have told you in the last blog the design of the tables YBANK and SCURX is not as elaborate as it should be. So a field for a country is missing in both tables. Still we can take advantage of the fact that we have defined SCURX as a check table for the table YBANK. When inputting the data in this field, we will get a value help so that we can input only currencies that are defined in table SCURX. Looking at the Program Itself Now it is time to have a look at the program that generates the data. I will present the listing of this program twice. First, I will use a listing with line numbers that make it easy to refer to each line in some explanation. At the end of the blog I will present a complete listing without line numbers so that you can easily paste it in your editor. Let us start by having a look at the relevant data definitions we need:
1 2 3 4 5 6 7 8 9 10 11 12 13 t 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
REPORT y_fill_account_table. * internal tables and work areas for database tables. DATA: wa_acc TYPE yaccount, itab_acc LIKE HASHED TABLE OF yaccount WITH UNIQUE KEY mandt acc_num bank city, wa_bank TYPE ybank, itab_bank LIKE STANDARD TABLE OF ybank, wa_city TYPE ycity, itab_city LIKE STANDARD TABLE OF ycity, wa_scustom TYPE scustom, itab_scustom LIKE STANDARD TABLE OF scustom, z TYPE i. * References to different objects of class cl_abap_random_in * and counter for the number of lines of the itabs. DATA: rnd_bank TYPE REF TO cl_abap_random_int, rnd_city LIKE rnd_bank, rnd_scust LIKE rnd_bank, rnd_cat LIKE rnd_bank, rnd_account LIKE rnd_bank, rnd_balance LIKE rnd_bank, bank_count TYPE i, city_count TYPE i, scust_count TYPE i, cat_count TYPE i VALUE 3, max_start_balance type i value 45000, cat_high type i value 3. * How many datasets to create PARAMETERS: numb_acc TYPE i DEFAULT 10.
First of all, there is the definition of an internal table that should hold the data for the database table YACCOUNT in line 4 and 5 plus the work area of the relevant line type in line 3. A hashed table is a table that is by a hash algorithm. There is no table index. The position of a row in the memory is calculated by specifying a key using a hash function that provides a unique value for each table row. If you want to read a dataset from a large hashed table this is faster by degrees than a search in a standard or a sorted table. In fact the time you need for a search in a hashed table increases logarithmically with the number of entries in the internal table. It is because of this advantage that we choose this type of internal table for our program. Later we have to check if the key of a new dataset we have created randomly is unique. To do this we have to search if the key of this dataset does already exist in the internal table itab_acc. We need internal tables and work areas for all check tables of the table YACCOUNT as the random values should be take from these tables (lines 6 to 11). As these tables are not very large and only accessed by
index, a standard table suffices. Again you see how easy it is in ABAP to define an internal table that has the same type as a database table. The references in the lines 15 to 20 are used for objects created by a factory method of the class cl_abap_random_int. The PARAMETERS statement enables
the user to choose how many datasets should be created. I do not think I need to explain the definition of the integers. The next lines do some more preparatory work: 29 DELETE FROM yaccount. "delete all lines from the db table yaccount
30 31 32 * Fill internal table from relevant db table * and get the number of lines. SELECT * FROM ybank INTO TABLE itab_bank. bank_count = LINES( itab_bank ). SELECT * FROM ycity INTO TABLE itab_city. city_count = LINES( itab_city ). SELECT * FROM scustom INTO TABLE itab_scustom. scust_count = LINES( itab_scustom ). * Get objects that have a method to create a * random number between min and max. *for account categories rnd_cat = cl_abap_random_int=>create( min = 1 max * for number of banks
33
34
35
36
37
38 39 40
41 . "
42
= cat_high )
43 t ).
44
rnd_bank = cl_abap_random_int=>create( min = 1 max = bank_coun

* for number of customers
45 rnd_scust = cl_abap_random_int=>create( min = 1 max = scust_co unt ).

46 * for number of cities
47 t ).
48
rnd_city = cl_abap_random_int=>create( min = 1 max = city_coun

* for account number which has 8 digits
49
50 51
rnd_account = cl_abap_random_int=>create( min = 10000000 max = 99999999 ).

* for initial balance max
52
53
rnd_balance = cl_abap_random_int=>create( min = 0 = max_start_balance ).
In line 29 we delete all lines from the database table YACCOUNT and from line 32 to 37 we load the content of the database tables YBANK, YCITY and SCUSTOM in the relevant internal tables and get the respective number of entries in each internal table. In line 41 we create an object that produces random number between one and the number of categories. This is done by a public static factory method of the global class cl_abap_random: Public components of global classes are available in the whole system. In ABAP it is quite common to provide services as methods of global classes. Surely you remember the object oriented way to output a table also uses a method of a global class (cf. blog 10 of our series). In the same way we create random-integer-producer-objects for the three check tables (lines 43 to 47), the account number and the initial balance of each account.
Next we create the random entries in a way that assures that the syntactic and semantic constraints are met: 54 DO numb_acc TIMES. 55 z = rnd_bank->get_next( ). " Get random number 56 READ TABLE itab_bank INDEX z INTO wa_accbank. "Get a bank randomly 57 z = rnd_city->get_next( ). 58 READ TABLE itab_city INDEX z INTO wa_city. "Get dataset from ycit
y
59 60
currency.
wa_acc-city = wa_city-city. wa_acc-currency = wa_city-
"randomly
61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76
77 78 79
"Currency depends on the city DO. "get an account number that is unique for bank and city z = rnd_account->get_next( ). wa_acc-acc_num = z. READ TABLE itab_acc FROM wa_acc TRANSPORTING NO FIELDS. IF sy-subrc <> 0. "Check if there is already a dataset EXIT. "with the same key in itab_acc ENDIF. ENDDO. z = rnd_scust->get_next( ). READ TABLE itab_scustom INDEX z INTO wa_acc-customer = wa_scustom-id.
wa_scustom.
80
wa_acc-balance = rnd_balance->get_next( ). wa_acc-category = rnd_cat->get_next( ). wa_acc-last_entry = sy-datum. INSERT wa_acc INTO TABLE itab_acc. ENDDO. INSERT yaccount FROM TABLE itab_acc. WRITE: 'Database Table yaccount successfully filled with ', numb_acc,' datasets' .
By looping numb_acc times it is made sure that we create the number of datasets chosen by the user. It is within this loop that the dataset is built: We create a random number between 1 and the number of banks in the check table in line 55. By using this number for an index read from the relevant internal table we get a bank randomly and move this value to the relevant component of our structure wa_acc. The mechanism works in an analogous way for each random value from a check table. Just note the advantage resulting from the fact that each row in database table YCITY contain a city and the respective currency for the city: When reading from the table YCITY we get a structure with the components city and currency, and not just any currency, but the currency assigned to the city. This way it is assured that each account has a currency that is determined by the city. Let us now have a closer look at the inner loop from line 61 to line 68. What is this loop for? This loop is to assure that all lines of the internal table itab_acc will have a unique index. In
line 63 the work area wa_acc contains all the key fields we have filled with random values. The statement READ TABLE itab FROM wa reads the dataset with the same key as the work area wa from the internal table itab. So we are looking in the internal table itab_acc if it already contains a dataset with the same key as the work area. If the account number we have created has produced a composite key that already exists another random account number should be created. If the account number is part of a unique key that is a key does not exist so far in the internal table itab_acc the sy-subrc after reading the table in line 64 is different than zero and the loop is left. From line 70 to 74 other random values are created and the entry column is filled with the system date.
Lines 78 to 80 are almost self-explanatory: The whole internal table is inserted into the database table and we output some information as to how many datasets we have created. And that is it. To use this program yourself create an empty report y_fill_account_table in the package y_abap_demo and insert the program code provided at the end of this blog by copy and paste. Running the Program To check if the program works, run it, insert a number such as for example 1500, and see if you get the output:
Next we open the Data Browser (SE16), input YACCOUNT and press the leftmost button Content. In the next window we press the button Number of Entries, and there we are:
The dialog window shows us that our program has done what it is made for. We can close the dialog window and press the leftmost button Execute to look at the rows in detail:
Summary What we done in this blog amount to three different things described from different points of view: 1. We have implemented a program that creates the test data we need for the subsequent Web Dynpro blogs. 2. You have seen a mechanism that you can adapt easily to create test data for your own programs. 3. When explaining the details of the program you have learned some more details about ABAP such as how to define references to instances of a global class, how services are provides as method of global classes, how to read lines from internal tables in different ways, and some more details. The Complete Program Code REPORT y_fill_account_table. * internal tables and work areas for database tables. DATA: wa_acc TYPE yaccount, itab_acc LIKE HASHED TABLE OF yaccount WITH UNIQUE KEY mandt acc_num bank city, wa_bank TYPE ybank, itab_bank LIKE STANDARD TABLE OF ybank, wa_city TYPE ycity, itab_city LIKE STANDARD TABLE OF ycity, wa_scustom TYPE scustom, itab_scustom LIKE STANDARD TABLE OF scustom, z TYPE i. * References to different objects of class cl_abap_random_int * and counter for the number of lines of the itabs. DATA: rnd_bank TYPE REF TO cl_abap_random_int, rnd_city LIKE rnd_bank, rnd_scust LIKE rnd_bank,
rnd_cat LIKE rnd_bank, rnd_account LIKE rnd_bank, rnd_balance LIKE rnd_bank, bank_count TYPE i, city_count TYPE i, scust_count TYPE i, cat_count TYPE i VALUE 3, max_start_balance type i value 45000, cat_high type i value 3.
* How many datasets to create PARAMETERS: numb_acc TYPE i DEFAULT 10. DELETE FROM yaccount. "delete all lines from the db table yaccount * Fill internal table from relevant db table * and get the number of lines. SELECT * FROM ybank INTO TABLE itab_bank. bank_count = LINES( itab_bank ). SELECT * FROM ycity INTO TABLE itab_city. city_count = LINES( itab_city ). SELECT * FROM scustom INTO TABLE itab_scustom. scust_count = LINES( itab_scustom ). * Get objects that have a method to create a * random number between min and max. *for account categories rnd_cat = cl_abap_random_int=>create( min = 1 max = cat_high ). " * for number of banks rnd_bank = cl_abap_random_int=>create( min = 1 max = bank_count ). * for number of customers rnd_scust = cl_abap_random_int=>create( min = 1 max = scust_count ). * for number of cities rnd_city = cl_abap_random_int=>create( min = 1 max = city_count ). * for account number which has 8 digits rnd_account = cl_abap_random_int=>create( min = 10000000 max = 99999999 ). * for initial balance rnd_balance = cl_abap_random_int=>create( min = 0 max = max_start_balance ). DO numb_acc TIMES. z = rnd_bank->get_next( ). " Get random number READ TABLE itab_bank INDEX z INTO wa_acc-bank. "Get a bank randomly z = rnd_city->get_next( ). READ TABLE itab_city INDEX z INTO wa_city. "Get dataset from ycity wa_acc-city = wa_city-city. "randomly wa_acc-currency = wa_city-currency. "Currency depends on the city DO. "get an account number that is unique for bank and city z = rnd_account->get_next( ). wa_acc-acc_num = z. READ TABLE itab_acc FROM wa_acc TRANSPORTING NO FIELDS. IF sy-subrc <> 0. "Check if there is already a dataset EXIT. "with the same key in itab_acc ENDIF. ENDDO.
z = rnd_scust->get_next( ). READ TABLE itab_scustom INDEX z INTO wa_acc-customer = wa_scustom-id.
wa_scustom.
wa_acc-balance = rnd_balance->get_next( ). wa_acc-category = rnd_cat->get_next( ). wa_acc-last_entry = sy-datum. INSERT wa_acc INTO TABLE itab_acc. ENDDO. INSERT yaccount FROM TABLE itab_acc. WRITE: 'Database Table yaccount successfully filled with ', numb_acc,' datasets' .
Your First ABAP Objects

This Blog was posted by Dirk Feeken on 6 July, 2007, on SDN at ABAP as part of the ABAP Trial Version for Newbies series. Our first goal is an application which allows to display and change the data of a selected customer. In this blog we will create the necessary ABAP object and in the next one we will create the user interface with Web Dynpro. The intention is of course not to demonstrate a well thought out, realistic example of object orientated modelling of a real business problem, which is a science in itself, and would go beyond the scope of this blog. Here we want to demonstrate how classes can be implemented in ABAP Objects in the form of a tiny example. The customer class will have a constructor, a set of public attributes and a save method which stores changed attributes to the database. To create an ABAP class go to the ABAP workbench SE80, select "Class/Interface and enter the name YCL_CUSTOMER in the input field and hit enter. Confirm the pop up and enter a description in the next window while leaving the other settings as they are.
Double click the YCL_CUSTOMER class on the left hand side (below "Object Name) and select the Attribute tab on the right hand side, to create the attributes of the class. We choose a subset of the SCUSTOM database columns as attributes of our class. Select the Attributes tab and add the attributes based on the ABAP dictionary types used for the corresponding database table column: ID TYPE S_CUSTOMER NAME TYPE S_CUSTNAME STREET TYPE S_STREET POSTCODE TYPE POSTCODE CITY TYPE CITY COUNTRY TYPE S_COUNTRY TELEPHONE TYPE S_PHONENO EMAIL TYPE S_EMAIL All attributes should be public Instance attributes, set by the Level and Visibility column. The result looks like this:
Of course we could also declare the attributes as private and offer setter and getter methods, which might be better style but lets keep our example as simple as possible for the moment. Lets assume an application which wants to instantiate a customer object knows in most cases already the ID of the customer (by a query method of a customer manager class for example). Therefore we create a constructor for the class with the customer ID as an optional parameter. The constructor then gets the data of the customer and fills the objects attributes with the values from the database. To create a constructor click on the Constructor button on the upper right hand corner and the editor for the already existing but empty constructor method opens.
Click on "Parameters to add the customer ID as optional (check checkbox in third column!) parameter of the dictionary type S_CUSTOMER.
Clicking on "Methods will bring you back to the former view and a double click on the CONSTRUCTOR method opens the ABAP editor.
In the constructor we will first check if the customer ID has been provided or not, since it was declared as an optional parameter. If the ID is available we select the data of the customer with this ID from the database into a structure. The structure type is available in the ABAP dictionary because the database table SCUSTOM is based on it. Sometimes people are confused that a table in the database (table=many lines) is represented as structure (=single line) in the ABAP dictionary, but for the moment lets simply accept this as a fact. The structure is declared at the top of the method with the data: statement and filled with the Open SQL statement SELECTFROMINTO. The important point is that SQL is directly integrated into ABAP. You just type in the SQL statements into your ABAP code. The application server automatically gives you the connection to the database and hides completely the differences between the SQL dialects of different database which can drive programmers crazy. This is done via the "Open SQL called layer in the application server, offering a unified SQL which is translated into the specific SQL dialect of the currently used database, making ABAP programming independent of the database vendors. Then the attributes of the object instance are filled with the result we got from the database. A column, the so called component of a structure can be directly accessed with the "-" separator, for example the name of the customer is available as S_CUSTOMER-NAME. The whole listing of the constructor method looks like METHOD constructor. * declaration of a structure matching the database table DATA: s_customer TYPE scustom. * check if ID parameter has been supplied IF id IS SUPPLIED. * get the data of the customer from the database SELECT SINGLE * FROM scustom INTO s_customer WHERE id = id. * fill the object's attributes with the data me->id = id. me->name = s_customer-name. me->street = s_customer-street. me->postcode = s_customer-postcode. me->city = s_customer-city. me->country = s_customer-country. me->telephone = s_customer-telephone. me->email = s_customer-email. ENDIF. ENDMETHOD. Type in the coding (and I recommend to type it rather than cut and paste), save and check the syntax of the method with the check button. If no errors occur you can activate the class with the button next to the check button.
A special feature of the ABAP workbench is that it contains a test environment which you can use out of the box to test and execute your ABAP coding directly without the need of writing a test program. After you have successfully activated your class click on the test button and the workbench will display the following:
This screen is a built in test feature of the ABAP workbench. It generates automatically a test UI for an ABAP class based on its methods and attributes. The first screen offers all static public methods of a class, in our case only the constructor with its single parameter. Choose for example 00000001 as customer ID (1.) and click the instantiate button (2.). An object instance is created and its attributes are displayed:
We see the first customer in our dataset is a company named SAP AG, located in Walldorf, Germany. Unfortunately the data is already outdated. Last year the city of Walldorf renamed the Neurottstrasse to Dietmar-Hopp-Allee in honor of the founder and former CEO of SAP. Although we can change the street name due to the public attributes we still need a method which allows us to save the changed data to the database. To create this new method go back to the class builder with the green back button click the Methods tab and go into change mode. Create a new method SAVE as public instance method. A double click on SAVE leads you to the editor. The code to save the current attribute values to the database is pretty simple: METHOD save. * declaration of structure DATA: s_customer TYPE scustom. * fill structure with current attribute values s_customer-id = me->id. s_customer-name = me->name. s_customer-street = me->street. s_customer-postcode = me->postcode. s_customer-city = me->city. s_customer-country = me->country.
s_customer-telephone = me->telephone. s_customer-email = me->email. * update the data in the DB MODIFY scustom FROM s_customer. ENDMETHOD. It is necessary to put the current attribute values into a structure first, because the SQL statements for updating or modifying database tables need the values in a structure matching the database table structure. The MODIFY keyword is the Open SQL statement for either updating an existing dataset or creating a new one. (We could have choosen here also the UPDATE statement, but we want to enhance the class later also with the capability to create and save new entries into the database, therefore we chose the MODIFY.) Enter the code into the method and activate the class. If you now click the Test button and instantiate the customer 00000001, the test environment will display also the new SAVE method.
Now we can correct the address to Dietmar Hopp Allee 16 (2.). Check the Upper/lower case active checkbox (1.), otherwise the data will be converted to uppercase and click on the clock/run icon (3.) right to the SAVE method. Now the data is updated and if you call the test again or look into the database table with the transaction SE16 it will display the new address. Although the integrated test capabilities of the ABAP workbench are quite useful for test purposes, we want to have a "real application example in the end, of course. With our first ABAP class, we can start with creating a user interface in Web Dynpro, which allows displaying change and save customer addresses in the next blog.
Starting with Web Dynpro for ABAP

This Blog was posted by Dirk Feeken on 20 July, 2007, on SDN at ABAP. This blog of our ABAP Trial Version for Newbies series should be of interest to everybody who is working in the ABAP environment since Web Dynpro is SAP's main UI technology for currently developed and future applications. With Web Dynpro for ABAP SAP offers this mighty UI framework also for the large community of ABAP developers and it's probably a good advice for every ABAP developer to start exploring the Web Dynpro development model as soon as possible. With the SAP NetWeaver 7.0 ABAP Trial Version we have the perfect environment at hand to do this. The best way to learn is by doing, so we will create a small Web Dynpro application which illustrates the basic idea behind the Web Dynpro programming model. In our first small Web Dynpro example we use the YCL_CUSTOMER ABAP objects class we created in the last blog of the series. The Web Dynpro application should display, change and save the data of a given customer. This small example will already demonstrate the separation of the UI layer from the core logic. The Web Dynpro layer uses the ABAP class but does not now anything about the way the class retrieves and stores the data while the customer class does not care if it is used by an application with a web user interface or called by other backend services. Create your First Web Dynpro Component The core of a Web Dynpro project is the Web Dynpro component. The component contains the visible parts of the UI and the logic which steers its behavior. We start in the ABAP Workbench (SE80) with creating a new Web Dynpro component. Select "Web Dynpro Comp./Intf." from the drop down list and enter the name for the new component for example "YWD_CUSTOMER".
Hit enter and confirm the pop up. You can enter a description in the next window while leaving the other options untouched. Also the "Object Directory Entry" popup of the transport system should already be familiar to you. It's up to you if you want to create the component simply as local object or to put it into a transportable package. The workbench has now created the Web Dynpro component with a component controller, which is the backbone of our WD component, a component interface (which will be explained later) and a window, which is the place where the visible parts of a Web Dynpro component - the views - will later be arranged and where it can be defined how they will be displayed.
Model View Controller and the Context The Web Dynpro model is based on the famous Model-View-Controller paradigm, used in almost all modern UI frameworks. The visible layout is defined by views, which contain the arrangement of UI elements (buttons, tables, input fields, etc...). The invisible parts, which steer the behavior of the UI, handle the data, contain event handlers etc.... are the so called controllers with the component controller being the core controller of the component. Its role is to handle and retrieve the data from the business logic or model which is in our case the YCL_CUSTOMER class. We define the kind of data the WD component should handle in the component controller's context. Each Web Dynpro controller contains a hierarchical structure called context to store data. The hierarchy contains nodes as structuring elements and attributes for the data. Select the component controller and go to the "Context" tab.
The context is still empty, just the root node named "CONTEXT" is visible. We want our Web Dynpro component to display the data of a customer. Therefore we define a context structure which contains the attributes of our customer class YCL_CUSTOMER. Right click on the "CONTEXT" root node and select "Create - Node" ( Be sure to be in change mode).
The upcoming popup allows us to create a context structure based on ABAP dictionary data types. This comes in handy since the attributes of our customer class are based on data types already defined in the ABAP dictionary as columns of the SCUSTOM structure. Therefore we choose "SCUSTOM" as "Dictionary structure" for the new node named "CUSTOMER". Before confirming click the "Add Attribute from Structure" button!
In the next pop up select ID NAME STREET POSTCODE CITY COUNTRY TELEPHONE EMAIL and confirm. The context of the component controller now contains a context node named "CUSTOMER" with attributes corresponding to the attributes of the SCUSTOM structure. The context is now able to store the data of one customer and should look like this:
Data in the View Before we continue with the implementation of the necessary code to retrieve the data of a customer into the context, lets first create a view with the UI elements so we can test out the Web Dynpro component in an early stage and see how it works in general. Right click the WD component name YWD_CUSTOMER at the left hand side and select "Create - View":
Enter "CUSTOMER_VIEW" as name and confirm. The workbench shows the layout tab of the newly created view. Because the layout preview tab displays the preview via HTTP a browser user/password popup might turn up. Use your system user (user: bcuser pwd: minisap) to start the preview (which is still empty). A real world application contains usually several views, each for a specific task with its specific data and interactive UI elements and event handlers. Therefore Web Dynpro creates in addition to the component controller for each view another controller, the view controller. The task of the view controller is to handle only the data and user actions of its view, while the component controller is responsible for the whole data of the Web Dynpro component and the communication with the business logic. In our simple case we have only one view and therefore the view controller needs the same data as the component controller. To display the data the view needs it in its own context. The data transfer is done via context mapping between the two controller contexts. Nodes of different contexts can be mapped if they have the same structure. The framework ensures that mapped context nodes contain at runtime always the same values.
To define the mapping between the component controller and the view controller go to the context tab of the view. The tab displays the context of the view controller on the left hand side and the context of the component controller at the right hand side. Now drag and drop the CUSTOMER node from the component controller context to the view controller context. This will create a new context node of the same structure in the view controller which is already mapped.
You will be asked if you really want to copy the node to the view controller and map it. Confirm this with and you should end up with a CUSTOMER context node in the view controller context which is mapped to the component controller context. Defining the View Layout Now we want to create the layout of the view which should display the customer data out of the context. A view displays data and offers user interaction with UI elements. These UI elements are bound to the nodes and attributes of the view controller's context. Switch back to the layout tab. You see the empty view area and the available UI elements. Select the "Standard Container" UI element library from the bottom of the list. First we need a group UI element as container for several input fields, labels, and buttons. The Group UI element is the left one in the first row of the Standard Container elements. Drag and drop it onto the layout area (1) and the group element will also appear in a hierarchical view at the right hand side with a caption as sub element (2). This tree displays all UI
elements of a view under the main container called the ROOTUIELEMENTCONTAINER. Since some UI elements can contain other UI elements this can become a pretty complex tree structure. For example the Group UI element is such an container element which contains already a caption element.
New UI elements can either be added to the view by drag and drop or in the tree at the right hand side with a right mouse click. We want to display all attributes of the customer in text input fields. Instead of adding each input field individually we use a wizard which creates the input fields with correct labels and binds them to the customer context node of the view controller. Right click onto the GROUP in the tree and choose "Create Container Form" from the menu. In the upcoming "Create Context Binding" popup click on "Context" (1) and select the CUSTOMER node (2) in the "Choose Context" popup and confirm.
Confirm again the selection in the "Create Context Binding" pop up. The wizard has created a label and an input field for each attribute of the CUSTOMER node and it has also created the binding between the context node attributes and the input fields. This means that any data which
is stored in the context is automatically displayed in the input fields and any user input in the fields will be automatically stored in the context. You see the labels and input fields in the layout preview. If you select a UI element in the tree structure the properties of the selected UI element are displayed below in a table and can be changed. Lets use this to clean up the layout. First select the "CAPTION [Header]" element below the group element and set its text property to "Customer Data". Next select the GROUP element itself and change the "Layout" property from "FlowLayout" to "GridLayout". Change further down in the property list the "ColCount" property to 2 and save the view. The layout should now look more tidy with the labels in the first column of each row.
Let us have a look how our almost finished Web Dynpro component looks like in this state. We haven't implemented the data retrieval yet, therefore it will not display any data but the general layout is already fixed and I assume you are curious by now how the whole thing looks in a browser. To be visible we have to put the view into the window of the component. The window is a container for views. Real applications contain several views and sometimes also several windows. Therefore it is necessary to declare which view belongs to which window. Double click on the Window YWD_CUSTOMER (1) . (By default the window of a WD component has the same name as the component itself but it is another kind of object). The still empty window structure is now displayed on the right hand side. Now drag and drop the view CUSTOMER_VIEW from the left hand side to the YWD_CUSTOMER window in the window structure (2). You can check if the view has been included by clicking the triangle left from the window to display its structure.
A First Test Now activate the whole project by selecting the YWD_CUSTOMER component in the object tree with a double click and clicking on the activation button (sevenths icon in icon row on top of the workbench). A popup appears with all inactive objects you have created in the component. All should be selected. Confirm the popup. The last thing we need to see our example in a browser is a new entity called Web Dynpro application. So far we have created a Web Dynpro Component, which contains the core Web Dynpro entities and defines our UI. The Web Dynpro Application is the handle which allows to start the component. Right click on the YWD_CUSTOMER component and select "Create - Web Dynpro Application". You can add a description to the WD Application. Save the WD Application with the save button on top of the workbench. Since a WD Application is also a transportable object select a package or save it as local object. Now a new node "Web Dynpro Applications" has appeared in the object tree with the YWD_CUSTOMER application beneath it. You can test the WD Application with the WD component by right mouse click on the application object (1) and selecting "Test" (2).
The browser will be started and tries to call the Web Dynpro application which itself instantiates the YWD_CUSTOMER Web Dynpro component and displays its window with the view. Since the application is
running on the server you have to log on with your user credentials (user: bcuser pwd: minisap). The browser will display the following (Don't worry if a time out error occurs. This just means that the default 60sec limit for a HTTP request are not sufficient to compile the Web Dynpro framework on the server, which might be necessary if it is the first time you try to run a Web Dynpro application. Just try again until the view appears. Later request will be much faster.). The browser should display the view:
OK, this probably doesn't knock your socks off but shows already some important features. For example the label texts are the correct ones retrieved from the ABAP dictionary data types. This works directly out of the box without any development effort. The texts are also language dependent. If you change the last two characters in the URL from "EN" to "DE" the view will be displayed with German texts for the labels (the Trial version contains only English and German texts, but real systems contain all kinds of languages). There's also a value help available for the Customer Number, although we have nothing implemented for that. The Web Dynpro framework displays automatically a value help if one is defined in the ABAP dictionary for the data type which is used for the context attribute that is bound to the input field. In the case of the Customer Number there is a rather complex value help defined for the data type SCUSTOM-ID as part of the data types used in standard SAP training workshops. Experienced ABAP developers will be glad to hear that their existing value help defined for GUI based transaction is fully usable in Web Dynpro. Bringing Life into the Component Let's continue with the implementation of the code that displays and allows to change customer data. We want to add a button and if a user has entered or selected a customer ID the view should display the address data of the customer. As mentioned, retrieving data from the business logic or model is the task of the component controller. Select the component controller in the workbench. First we add a reference variable of our YCL_CUSTOMER class as attribute to the component controller. Select the "Attributes" tab and enter the attribute CUSTOMER of the type (reference) YCL_CUSTOMER:
The component controller has to offer a method which creates a customer object for a given customer ID and fills its context structure with the attributes of the customer.
Switch to the Methods tab of the component controller and create a new method READ_CUSTOMER. A double click on the method names opens the ABAP editor. Implement the following code into the method:
METHOD read_customer . DATA: cnode TYPE REF TO if_wd_context_node, custom_id type scustom-id. * get reference of CUSTOMER context node cnode = wd_context->get_child_node( 'CUSTOMER' ). * get current value of the ID attribute cnode->get_attribute( EXPORTING name = 'ID' IMPORTING value = custom_id ). * instantiate the customer object for the ID CREATE OBJECT wd_this->customer EXPORTING id = custom_id. cnode->set_attribute( cnode->set_attribute( cnode->set_attribute( cnode->set_attribute( cnode->set_attribute( cnode->set_attribute( cnode->set_attribute( cnode->set_attribute( ENDMETHOD. name name name name name name name name = = = = = = = = 'ID' 'NAME' 'STREET' 'POSTCODE' 'CITY' 'COUNTRY' 'TELEPHONE' 'EMAIL' value value value value value value value value = = = = = = = = wd_this->customer->id ). wd_this->customer->name ). wd_this->customer->street ). wd_this->customer->postcode ). wd_this->customer->city ). wd_this->customer->country ). wd_this->customer->telephone ). wd_this->customer->email ).
First we declare the variables for a reference to a context node and for the ID of a customer. Next we retrieve the reference of the CUSTOMER node from the controller's context. We use the node's "get_attribute" method to get the current value of the "ID" context attribute. With the ID we instantiate the CUSTOMER object with the CREATE statement. WD_THIS is the self reference of the component controller. Therefore the customer object reference we have added as class attribute to the component controller can be accessed as WD_THIS->CUSTOMER. Finally we set the context's attributes with the values of the current customer object. This method should be called if the user clicks a button. To add the button to the view select the CUSTOMER_VIEW and go to the layout tab. The button is the first element in the "Standard Simple" library of UI elements. Drag and drop the button to the view. Select it in the tree hierarchy and set its text property to "Get Customer" (1). The button has to trigger an action. To create such an action click on the create button next to the "onAction" property(2):
In the upcoming pop up name the new action GET_CUSTOMER and confirm. A double click on the newly created action name in the Property table (3) will open the ABAP editor for the action's method handler ONACTIONGET_CUSTOMER. This event handler is a method of the view controller because the button belongs to the view. Remember that the view controller and the component controller are two different objects. It is not possible to link an action of a button directly to a component controller. Handling the events of UI elements of a view is always the task of the view controller. What we have to do now is simply calling the component controller's READ_CUSTOMER method from the event handler in the view controller. This is quite straightforward since every view controller has access to the reference of the component controller. Therefore our event handler consists of a single line of code: METHOD ONACTIONGET_CUSTOMER . * call the component controllers read_customer method wd_comp_controller->read_customer( ). ENDMETHOD.
Save and activate everything and test the WD application again. If you type in a customer number, for example 00000003 the data of the corresponding customer will be displayed:
Because this blog got longer than expected, I leave the last part, adding the functionality to save changed address data for you as homework. But you have everything you need to know at hand. Create a new SAVE_CUSTOMER method in the component controller in which you take the current context attribute values, put them in the customer object's attributes and call the save method of the customer object. Add a button to the view, which triggers an action that calls the SAVE_CUSTOMER method of the component controller and you are done. Conclusion If this was your first encounter with Web Dynpro you probably think by now that the Web Dynpro framework is quite complex. A lot of new entities appeared and most of the concepts are new and it takes some time to get used to everything. The learning curve might be steeper than in other more low level UI environments, where you get first results faster. But you might have noticed something during this example: You never cared about any HTML, JavaScript, HTTP or browser issues. It was never necessary to think what kind of HTML data or script has to be sent to the browser to create a specific effect. All you thought about was really the user interface of your application. Where should a button be placed, which part of the business data should be displayed, which action should be triggered by a button and so on. These kinds of questions can be complex and sometimes hard to solve. Creating good user interfaces is still an art. But when you deal with this art, you should concentrate on what your UI should look like and what it should do and not what happens during an HTTP request or what kind of effect a browser cache can have or if a specific JavaScript statement is supported by all browsers. This is the fundamental feature of the Web Dynpro framework. Concentrate on the user interface and not on the underlying rendering technologies.
Copyright
Copyright 2010 SAP AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z, System z10, System z9, z10, z9, iSeries, pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS, S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise Server, PowerVM, Power Architecture, POWER6+, POWER6, POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes, BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX, Intelligent Miner, WebSphere, Netfinity, Tivoli and Informix are trademarks or registered trademarks of IBM Corporation. Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries. Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Business Objects S.A. in the United States and in other countries. Business Objects is an SAP company. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

Develop ABAP

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Develop ABAP

Uploaded by

Copyright:

Available Formats

How to Develop in ABAP

Company: SAP AG Created on: 28 January 2010

SAP COMMUNITY NETWORK 2010 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 1

How to Develop in ABAP

SAP COMMUNITY NETWORK 2010 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 2

How to Develop in ABAP

SAP COMMUNITY NETWORK 2010 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 3

How to Develop in ABAP

SAP COMMUNITY NETWORK 2010 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 4

How to Develop in ABAP

SAP COMMUNITY NETWORK 2010 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 5

How to Develop in ABAP

SAP COMMUNITY NETWORK 2010 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 6

How to Develop in ABAP

Presentation Layer: Client-Side Presentation

Application Layer: Presentation Logic Business Logic:

Functions ABAP Programs BAPIS

SAP COMMUNITY NETWORK 2010 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 7

How to Develop in ABAP

SAP COMMUNITY NETWORK 2010 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 8

How to Develop in ABAP

Many Developers on one Central Server - How Does It Work?

SAP COMMUNITY NETWORK 2010 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 9

How to Develop in ABAP

SAP COMMUNITY NETWORK 2010 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 10

How to Develop in ABAP

SAP COMMUNITY NETWORK 2010 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 11

How to Develop in ABAP

Navigation in the Application Server

SAP COMMUNITY NETWORK 2010 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 12

How to Develop in ABAP

SAP COMMUNITY NETWORK 2010 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 13

How to Develop in ABAP

SAP COMMUNITY NETWORK 2010 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 14

How to Develop in ABAP

A First Hello World Program '

SAP COMMUNITY NETWORK 2010 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 15

How to Develop in ABAP

SAP COMMUNITY NETWORK 2010 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 16

How to Develop in ABAP

SAP COMMUNITY NETWORK 2010 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 17

How to Develop in ABAP

output_text type string.

output_text = 'Hello World'. output_text. "obsolete statement

SAP COMMUNITY NETWORK 2010 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com 18