LESSON 3 ABAP WORK BENCH AND TOOLS

ABAP WORK BENCH CONCEPTS AND TOOLS

The R/3 System has a modular software architecture that follows software -oriented client/server principles.The R/3 System allocates presentation, applications, and data storage to different computers. This serves as the basis for the scalability of the R/3 system.

The lowest level is the database level. Here data is managed with the help of a relational database management system (RDBMS). In addition to master data and transaction data, programs and the metadata that describe the R/3 System are stored and managed here.

ABAP programs run at the application level, both the applications provided by SAP and the ones you develop yourself. ABAP programs work with data called up from the database level and store new data there as well.


 

The third level is the presentation level (SAPGUI). This level contains the user interface, in which an end user can access an application, enter new data and receive the results of a work process.

The technical distribution of software is independent of its physical location on the hardware.

Vertically, all levels can be installed on top of each other on one computer or each level on a separate computer. Horizontally, application and presentation level components can be divided among any number of computers. The horizontal distribution of database components, however, depends on the type of database installed.

ABAP programs are processed on the application server. The design of the user dialogs and the database dialogs is therefore of particular importance when writing application programs.

Bla Box

The user is primarily interested in how his or her business transaction flows and in how data can be input into and displayed from the transaction. Technical details, such as whether a single program is running or multiple programs are called implicitly, or the technical differences between the kind of screens being displayed, are usually less important to the user. The user does not need to know the precise flow of the ABAP program on the application server. Users see the R/3 System with application servers and database as a black box.

There are, however, three technically distinct screen types (screens, selection screens, and lists) that offer the user different services. It is the developer's job to determine which type of user dialog is most suitable to the user's needs.

When the user performs a user action (choosing Enter, a function key, a menu function or a pushbutton, for example), control is handed over from the presentation server to the application server and certain parts of the ABAP program are processed. If further user dialog is triggered within the ABAP program, the system sends a screen to the presentation server and control is once again handed over to the presentation server.

In this part of the unit, the user has chosen to start a program where an airline ID can be entered on the initial selection screen. The program subsequently uses this information to retrieve the 'Long name of airline' and the 'Local currency of airline' from the database and display them for the user in list form.

Whenever a user logs on to the system, a screen is displayed. From this screen, the user can start a program by using its menu path.

If the user has triggered a program with a user action, then the program context is loaded on the application server. The program context contains memory areas for variables and complex data objects, information on the screens for user dialogs and ABAP processing blocks. The runtime system gets the program information from the Repository, which is a special part of the database.

The sample program has a selection screen as the user dialog, a variable and a structure as data objects and one ABAP processing block. The list that is used to display the data is created dynamically at runtime.

The subsequent flow of the program is controlled by the ABAP runtime system.

Since the program contains a selection screen, the ABAP runtime system sends it to the presentation server at the beginning of program processing. The presentation server controls the program flow for as long as the user fills in the input fields.

Selection screens allow users to enter selection criteria required by the program.

As soon as the user has finished entering data on the selection screen, he or she can trigger further processing by choosing 'Execute'. All data input on the selection screen is the automatically placed in its corresponding data object in the program and the ABAP runtime system resumes control of processing. Our sample program contains only one ABAP processing block. The runtime system triggers sequential processing of this ABAP processing block.

If the entries made by the user do not have the correct type, then an error message is automatically triggered. The user must correct his/her entries.

The ABAP processing block contains a read access to the database that has been programmed into it.

The program also passes the database information about which database table to access and which line in the table to read.

The database returns the requested data record to the program and the runtime system ensures that this data is stored in the appropriate data objects. Normally a structure is the target field when a single record is accessed. The structure contains variables for all fields requested from the database.

The layout of the subsequent list display has also been programmed into the processing block. After all processing has ended, the runtime system sends the list screen to the presentation server.

When the user starts the program, the program context is loaded first. This time, however, our sample program contains three processing blocks, a selection screen, and a screen, and a variable and two structures as its data objects.

Since the program contains a selection screen, the ABAP runtime system sends it to the presentation server at the beginning of program processing.

As soon as the user has finished entering data on the selection screen, he or she can trigger further processing by choosing 'Execute'. All data input on the selection screen is then automatically placed in its corresponding data object in the program and the ABAP runtime system resumes control of processing. The runtime system then triggers sequential processing of the ABAP processing block that comes after the selection screen.

The ABAP processing block contains a read access to the database that has been programmed into it. The program also passes the database information about which database table to access and which line in the table to read.

The database returns the requested data record to the program and the runtime system ensures that this data is stored in the appropriate data objects. Normally a structure is the target field when a single record is accessed. The structure contains variables for all fields requested from the database.

The ABAP processing block now triggers screen processing. This is often expressed simply by saying 'The program calls the screen'. However, in reality, each screen possesses its own processing block that is sequentially processed before the runtime system sends the screen to the presentation server (Process Before Output). This allows screens to be used in a very flexible manner.

After the screen's processing block has been processed, the ABAP runtime system sends the screen to the presentation server. During this process, data is transported into the screen's fields from a structure that serves as an interface for the screen.

Once the user performs a user action (choosing Enter, a function key, a menu function or a pushbutton, for example), control is handed over to the runtime system on the application server again. The screen fields are transported into the structure that serves as the screen's interface and a special processing block belonging to the screen is triggered. This processing block is always processed immediately following a user action (Process After Input).

After the 'Process After Input' processing block has been processed, the sample program continues processing the ABAP processing block that called the screen in the first place.

The database contains, along with the Repository, application and customizing tables that are usuall client-specific.

The Repository contains all development objects, for example, programs, definitions of database tables and global types. Development objects are therefore also known as Repository objects.

Repository objects are not client-specific. They can therefore be viewed and used in all clients.

All development objects created with the development tools found in the ABAP Workbench are classified as Repository objects and are stored centrally in the R/3 Repository.

The R/3 Repository is a special part of the SAP system's central database.

The Repository is organized according to application. Each application is further divided into logical subdivisions called development classes.

Repository objects are often made up of sub-objects that are themselves Repository objects.

Each Repository object must be assigned to a development class when it is created.

You can use the Repository Information System to search for Repository objects according to various criteria.

You can view the Repository structure in the application hierarchy. You can navigate to the application hierarchy from the initial screen using Tools -> ABAP Workbench -> Overview -> Application Hierarchy. (Transaction SE81).

The application components are displayed in a tree structure in the application hierarchy. Expanding a component displays all the development classes that are assigned to that component.

You can select a sub-tree and navigate from the application hierarchy to the Repository Information System. The system then collects all development classes for the sub-tree selected and passes them to the Information System.

You can use the Repository Information System to search for specific Repository objects. Search criteria are available for the various kinds of Repository objects.

You can navigate to the Repository Information System using

The Information system pushbutton in the application hierarchy

The menu path Tools -> ABAP Workbench -> Overview -> Information System

Transaction SE84 in the command field.

The ABAP Workbench contains different tools for editing Repository objects. These tools provide you with a wide range of assistance that covers the entire software development cycle.

The most important tools for creating and editing Repository objects are:

ABAP Editor for writing and editing program code

ABAP Dictionary for processing database table definitions and retrieving global types

Menu Painter for designing the user interface (menu bar, standard toolbar, application toolbar, function key assignment)

Screen Painter for designing screens (dynamic programs) for user dialogs

Function Builder for displaying and processing function modules (routines with defined interfaces that are available throughout the system)

Class Builder for displaying and processing central classes

There are two different ways to go about using these tools:

Either you call each individual tool and edit the corresponding Repository objects.

You must then call the next tool for the next set of objects...

Or you work with the Object Navigator: This transaction provides you with a tree-like overview of all objects within a development class or program.

The Object Navigator screen is divided into two areas:

An area for displaying an object list as a hierarchy

The object window, in which objects can be displayed and edited.

You can hide the hierarchy area using the 'Close browser' pushbutton.

You can display the object list for the object currently displayed in the object window using the 'Object list' icon.

You can select functions from a context menu in both screen areas. You are only given a choice of those functions that are relevant to displaying or editing the object on which the cursor is positioned.

Right-click with the mouse to display the context menu. (Left-click if you have set up your mouse for left-handers).

Repository objects are organized in a hierarchy:

Each application component consists of multiple development classes

Each development class can contain several different kinds of Repository objects:

programs, function groups, ABAP Dictionary objects, ...

Each Repository object can consist of different object types:

Programs can contain: global data, types, fields, events, ...

Function groups can contain: global data, function modules, ...

You can enter the type of object list and the object name in the upper part of the hierarchy area. The object list is then displayed in the hierarchy area.

Double-clicking on a sub-object in an object list displays the object list for the selected object in the hierarchy area.

Double-clicking on an object that does not have an object list displays that object in the object window.

You can use the icons to navigate by history or hierarchy between the object lists.

You can add object lists that you edit frequently to your favorites.

You can use the context menu to display objects from an object list. The system then automatically selects the correct tool for processing the object selected.

If the object you require from the object list is not available in the system, you can create it by double-clicking. This is called forward navigation.

There are various ways of starting a program:

You can start a program from the Object Navigator object list using the context menu or using the 'Test' icon.

If the program has a transaction code, then this can be added to a menu. Then all you have to do is click on the menu option with the mouse.

You can add programs to the favorites list on the initial screen. Programs can also be made available using the activity groups on the initial screen. Then all you have to do is select the program in the hierarchy on the initial screen.

You can determine the functional scope by executing the program.

On any screen, you can access information about the program name and the screen number using System -> Status. A standard selection screen has the screen number 1000.

You can access information on the field name and field type for any field on the screen using F1 -> Technical Info.

You can display an overview of the program objects using the program object list in the Object Navigator.

The hierarchy only shows those object types for which objects exist.

You can display the objects in the Object Navigator details window by double -clicking or using the context menu.

If you start a program from the Object Navigator object list using the context menu, then you have two options.

Choose Execute -> Direct to execute the program directly.

Choose Execute -> Debugging to execute the program in the debugging mode.

Starting the program in the debugging mode allows you to execute the program line by line using the 'Single Step' icon. You can display up to eight variables. To trace the variable values, enter the field names in the left input field. You can also see this entry by double -clicking on the field name in the code displayed.

You can set a breakpoint by double -clicking in front of a line of source code in the debugging mode. If you then click on the 'Continue' icon, the program will be executed up to the point where the next breakpoint is defined.

You can find information on content-related breakpoints in the ABAP Statements and Data Declarations unit.

ABAP programs are made up of individual statements.

Each statement ends with a period.

The first word in a statement is called a keyword.

Words must always be separated by at least one space.

Statements can be indented.

Statements can take up more than one line.

You may have multiple statements in a single line.

Consecutive statements with identical initial keywords can be condensed into one chained statement.

In chained statements, the initial part of the statement containing the keyword must be followed by a colon.

Individual elements that come after the colon must always be separated by commas.

Blank spaces are allowed before and after all punctuation (colons, commas, periods).

Be aware that the system still considers the individual parts of a chained statement to be complete statements that are independent of one another.

There are two ways to insert comments into a program:

A star (*) in column 1 allows you to designate the whole line as a comment.

Quotation marks (") in the middle of a line designate the remainder of the line as a comment.

You can display detailed information on single objects in the Editor by double -clicking:

Double -clicking on the name of a database table displays the database table definition using the ABAP Dictionary in the object window of the Object Navigator.

Double -clicking on a field name displays the part of the program source code where the data object is defined.

Double -clicking on a screen number displays the screen using the Screen Painter in the object window of the Object Navigator.

Use the Back function to get back to the program source code display in the Editor.

You can also set a breakpoint in any line of source code in the Editor. Then start the program without selecting the debugging mode. The program will now be executed up to the point where the breakpoint is defined. At this point, the debugging mode is started.

There are various ways of navigating to keyword documentation for an ABAP statement:

F1 on a keyword displays the documentation for the statement on which the cursor is positioned.

The Information icon displays a dialog box offering you various views of the keyword

documentation.

If you need more precise information on parts of the source code, you can analyze the source code.

The following slides explain the most important statements in the sample program.

There are various statements that you can use to define data objects.

The TABLES statement always refers to the global type of a flat structure that is defined in the ABAP Dictionary. The structure type for the data object in the program is taken from the Dictionary. The data object name is identical to the name of the structure type. They are normally used as an interface to the screen.

The DATA statement is usually used to define local data objects. The data object type is specified using the TYPE addition.

The PARAMETERS statement defines not only an elementary data object, but also an input field on the standard selection screen that is processed at the start of the program.

When you activate a program, an internal load version is generated. A selection screen is generated from the PARAMETERS statement. When the program starts, memory areas are made available for the data objects.

You can find further information on data objects in the unit entitled ABAP Statements and Data Declarations, or in the keyword documentation.

The SELECT statement ensures that data is read from the database. In order to read a record from a database table, the following information must be passed to the database:

From which database table is the data read? (FROM clause)

How many lines are read? The SINGLE addition shows that only one line is read.

Which line is read? The WHERE clause shows which columns of the database table have which values. For a SELECT SINGLE, the condition must be formulated so that one line is specified unambiguously.

The data supplied by the database is put into local data objects. The INTO clause specifies the data objects into which you want to copy the data. In this example, the data is copied to the components of the same name in structure wa_sbc400.

The statement CALL SCREEN calls a screen.

A screen must be created using the Screen Painter tool.

A screen is an independent Repository object, but belongs to the program.

You can define input fields on a screen that refer to the ABAP Dictionary. Screens automatically perform consistency checks on all input and provide any error dialogs that may be needed. Thus, screens are more than just templates for entering data, they are, in fact, dynamic programs (dynpros).

The statement TABLES declares a structure object that serves as an interface for the screen. All data from this structure is automatically inserted into its corresponding screen fields when the screen is called by the CALL SCREEN statement. Data entered by the user on the screen is transferred to its corresponding fields in the program after each user action (after choosing Enter, for example).

ABAP contains statements (WRITE, SKIP, ULINE) that allow you to create a list.

WRITE statements display field contents, formatted according to their data type, as a list.

Consecutive WRITE statements display output in the same output line. Output continues in the next line when the present one is full.

You can place a position entry in front of any output value. This allows you to determine carriage feed (/), output length (l) and where a column begins (p). More detailed information about formatting options can be found in the keyword documentation under WRITE.

List output can be displayed in color.

The complete list appears automatically at the end of the processing block.

The first project is to extend an existing program. As no extensions are allowed in the program and modifications are to be avoided, the first step is to copy the program and then change it.

You must allocate changes to existing programs to a project in the system, just as you would for creating copies of programs or creating new programs. Therefore the following slides deal first with how a project is represented in the R/3 System.

Projects are always implemented in a development system and then transported to the next system. A decisive criterion for the combination of projects is therefore which Repository objects need to be transported together because of their dependencies. More detailed information on project organization is available in the unit entitled Software Logistics and Software Adjustment .

Repository objects are automatically linked to correction and transport systems when they are assigned to a transportable development class (not $TMP).

After development has ended, Repository objects are transported into the test systems or production systems by way of certain prescribed pathways.

The ABAP Workbench tool Workbench Organizer (WBO) organizes all development tasks pertaining to Repository objects.

Each project requires the following information:

Name of the Project Manager?

What functional scope is to be covered by the object? Which Repository objects are to be changed or created?

What is the timeframe for the project?

Names of the project participants?

The trainer is the Project Manager.

Programs need to be developed for each topic. (These are the trainer's sample programs and the exercise groups' exercises)

This project is to be completed by 3:00 p.m. on Friday.

The user names of the participants

At the beginning of a development project, the project manager must create a change request. The project manager assigns all project team members to the change request. The Workbench Organizer assigns a project number to the change request (K9. Example: C11K900001). is the system number.

Next, the Workbench Organizer (WBO) creates a task for each employee assigned to the change request. From now on whenever an employee allocates a Repository object to that change request, the Repository object will automatically be filed away in that employee's task. Thus all Repository objects that an employee works on during a development program are collected within his or her task folder.

When changing a Repository object, a developer assigns it to a change request. Unlike the logical functional divisions that separate different development classes, change requests are project-related.

Thus, although a program always belongs to only one development class, it can, at different times, belong to different change requests.

When development is finished, the developer carries out a final quality check and releases the task.

The objects and object locks are passed from the task to the change request. However, all employees assigned to the change request can still make changes to the object because the Workbench Organizer will automatically create a new task should the need arise.

When the project is complete, the Project Manager checks the consistency of the request and the Project Manager releases the change request. The locks on the objects in the request are released.

The Repository objects are then exported to the central transport directory.

The objects are not imported automatically into the target system. Instead, the system administrator uses the transport control program tp at the operating system level. Afterwards, the developers check the import log.

Program names beginning with Y or Z, or with SAPMZ or SAPMY, are reserved for customer developments. You can also have a namespace reserved for customer developments. Detailed information on customer namespaces for various Repository objects is available in the SAP Library under Basis Components -> Change and Transport System(BC-CTS) -> BC Namespaces and Naming Conventions.

You can copy a program from the object list of a development cla ss or program. To do so, simply place your cursor on the name of the program you want to copy and click with the right mouse button. Choose Copy. The system displays a dialog box where you can enter a new name for your copy. Confirming your entries using the appropriate pushbutton in the application toolbar causes the system to display a dialog box where you can select the sub-objects that you want to copy with the program. Thus, you should decide which sub-objects you want to copy with the program BEFORE you begin the copy procedure. After you confirm these entries, the system displays yet another dialog box where you can save Repository objects.

If you are copying a program that contains includes, another dialog box is displayed before this one, where you can choose which includes you want to copy and enter new names for them.

Assign the program to a development class, in order to be able to save it. Your name is automatically entered into the system as the person responsible for the new program copy. Check all entries to see if they are correct and then choose Save.

All Repository objects that are created or changed must be assigned to the change request for their corresponding project. For this training course, the trainer has created a change request for the project 'Exercises for Participants on Course BC400 as of May 8, 2000'. Each group has a task within this change request. Assign all of your Repository objects (development classes, programs, and so forth) to this change request.

You can display all change requests in which you have a task using the 'Own requests' pushbutton.

You can adjust the short text (= title) as follows:

Double click on program object types in the Object Navigator object list.

Choose attributes.

Click on the 'Change' icon.

If the original language of the source program is not identical to your logon language, a dialog box appears to ask you whether you want to change the title in the original language or if you want to change the original language.

Now you can adjust the title.

The altered title appears as short text next to the program name in the Object Navigator object list.

In order to adapt the source code, navigate to the Editor (context menu).

To adapt the list, supplement a ULINE statement and a WRITE statement. You can find further information on these statements in the keyword documentation.

You can carry out a syntax check after you have changed the source code.

You can change a screen using the Screen Painter. To change the layout, first use the context menu for the screen in the object list to navigate to the Screen Painter and then from there use the 'Layout' icon to navigate to the graphic Layout Editor.

This contains an icon for creating input/output fields with reference to global types. Enter a structure type that is defined in the ABAP Dictionary. All fields for this structure type are displayed for selection. You cannot select fields that are already contained on the screen. This is shown by a small padlock next to the field.

The tool for displaying and maintaining global types is called the ABAP Dictionary. You can find more detailed information on global types in the ABAP Statements and Data Declarations unit.

A syntax check started from the Editor always relates to the current contents of the Editor.

As soon as you have saved the program, this source code is visible throughout the system. You can use the context menu to carry out a syntax check that encompasses all program components. Starting the program from the object list context menu ensures that the active version is started.

n As soon as you have activated the program, the active version can be executed throughout the system.

You can run an extended program check for activated programs using the context menu or the menu option. These checks are considerably more extensive than the syntax check.