how to develop in abap

SAP COMMUNITY NETWORK SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com

2010 SAP AG 1

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.



2010 SAP AG 2

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



2010 SAP AG 3

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



2010 SAP AG 4

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.



2010 SAP AG 5

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.



2010 SAP AG 6

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).



2010 SAP AG 7

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 system-specific 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.

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.

Browser

Database Layer

DB Processes

Work

Process

Work

Process

Work

Process

Dispatcher

Application Layer:

Presentation Logic

Business Logic:

Functions

ABAP Programs

BAPIS

Web Services

DB

Buffer

Browser NW Business Client

Presentation Layer: Client-Side Presentation

SAP GUI



2010 SAP AG 8

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.



2010 SAP AG 9

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.



2010 SAP AG 10

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:



2010 SAP AG 11

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.



2010 SAP AG 12

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.



2010 SAP AG 13

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.



2010 SAP AG 14

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.



2010 SAP AG 15

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 so-called 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



2010 SAP AG 16

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.



2010 SAP AG 17

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.



2010 SAP AG 18

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'.

write output_text. "obsolete statement

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



2010 SAP AG 19

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. ABAP-Programming 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



2010 SAP AG 20

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.



2010 SAP AG 21

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:



2010 SAP AG 22

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.



2010 SAP AG 23

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



2010 SAP AG 24

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



2010 SAP AG 25

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 .



2010 SAP AG 26

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.



2010 SAP AG 27

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.



2010 SAP AG 28

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.



2010 SAP AG 29

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 prep-work 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



2010 SAP AG 30

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.



2010 SAP AG 31

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



2010 SAP AG 32

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.



2010 SAP AG 33

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: 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:


DO.

ASSIGN COMPONENT sy-index OF STRUCTURE wa_flight TO .

IF 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 "



2010 SAP AG 34

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):



2010 SAP AG 35

REPORT read_table_flights.

DATA: itab_flight TYPE STANDARD TABLE OF sflight,

wa_flight TYPE sflight,

alv TYPE REF TO cl_salv_table.

FIELD-SYMBOLS: TYPE any.

SELECT *

FROM sflight INTO TABLE itab_flight

WHERE carrid = 'LH' AND connid = '402'.

* Alternative one: Loop at table and write the different components of work area


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 . * IF sy-subrc 0. * SKIP. * EXIT. * ENDIF. * WRITE . * ENDDO. *ENDLOOP.

** object oriented way *cl_salv_table=>factory( IM

how to develop in abap

Documents