Tuesday, July 6, 2010

Lesson 1 SAP Navigation

hearty welcome you to this SAP ABAP Programming learning portal.Here we are going to learn entire SAP ABAP course which is divided into Fifty Seven Lessons for convenience. You can go through day wise if you are new to ABAP and if you are all ready familiar with the subject you can just go to the required topic using the Complete course navigaiton.

Here the programme starts with lession one .

The SAP R/3 System is a client system. The client concept enables the joint operation, in one system, of several enterprises that are independent of each other in business terms. During each user session you can only access the data of the client selected during the logon.

A client is, in organizational terms, an independent unit in the R/3 System. Each client has its own data environment and therefore its own master data and transaction data, assigned user master records and charts of accounts, and specific customizing parameters.

A user master record linked to the relevant client must be created for users to be able to log on to the system.To protect access, a password is required for logon.The password is hidden as you type (you only see asterisks).SAP systems are available in several languages. Use the Language input field to select the logon language for each session.

Multiple logons are always logged in the system beginning with Release 4.6. This is for security as well as licensing reasons. A warning message appears if the same user attempts to log on twice or more. This message offers three options:

Continue with current logon and end any other logons in the system

Continue with current logon without ending any other logons in the system (logged in system)

Terminate current logon and the screen shot is as shown .

The standard SAP screen consists of following elements .

Command field: You can use the command field to go to applications directly by entering the transaction code. You can find the transaction code either in the SAP Easy Access menu tree (see next slide) or in the relevant application under System® Status.

Menu bar: The menus shown here depend on which application you are working in. These menus contain cascading menu options.

Standard toolbar: The icons in the system function bar are available on all R/3 screens. Any icons that you cannot use on a particular screen are dimmed. If you leave the cursor on an icon for a moment, a small flag will appear with the name (or function) of that icon. You will also see the corresponding function key. The application toolbar shows you which functions are available in the current application.

Title bar: The title bar displays your current position and activity in the system.

Check boxes: Checkboxes allow you to select several options simultaneously within a group.

Radio buttons: Radio buttons allow you to select one option only.

Status bar: The status bar displays information on the current system status, for example, warning and error messages.

A tab provides a clearer overview of several information screens.

Options: You can set your font size, list colors, and so on here.

SAP Easy Access is the standard entry screen displayed after logon. Using the menu path Extras® Set start transaction you can select a transaction of your choice to be the default entry screen after logon.

You navigate through the system using a compact tree structure that you can adapt to your own specific requirements. Use the menu path Extras® Settings to change your view of the tree structure. You can use this to display technical names (transaction codes).

Enter a transaction code in the command field:

A transaction code (T-Code) is assigned to each function in R/3 (not each screen).

You can access the assigned transaction code from any screen in the R/3 System.

You can find the transaction code for the function you are working in under the Status option of the System menu.

For example, to display Accounts receivable master data, enter “/n” and the appropriate

transaction code (in this case “/nfd03”).

combination to make the cursor move from one (input) field group to the next. Use TAB to move between fields within a group.


Use F1 for help on fields, menus, functions and messages.

F1 help also provides technical information on the relevant field. This includes, for example, the parameter ID, which you can use to assign values to the field for your user.

Use F4 for information on what values you can enter. You can also access F4 help for a selected field using the button immediately to the right of that field.

If input fields are marked with a small icon with a checkmark, then you can only continue in that application by entering a permitted value.

You can flag many fields in an application to make them either required entry fields or optional entry fields. You can also hide fields using transaction or screen variants or Customizing.

The R/3 System provides comprehensive online help. You can display the help from any screen in the system. You can always request help using the Help menu or using the relevant icon.


LESSON 2 SAP ARCHETECHERE AND DESIGN

Previously we have discussed regarding SAP Navigation in the first lesson.Here we are going to discuss regarding system architecture an design.

SAP SYSTEM KERNAL :

In SAP terminology, a service means a service provided by a software component and this component can consist of a process or a group of processes and is then called a server for that service.

Software components that use this service are called clients. At the same time, clients can also be servers for specific services.

A server often also means a computer (host) on which software components that provide specific software.

The fundamental services in a business application system are presentation services, application services, and database services.

In a one-tier R/3 System configuration, all processing tasks are performed on one server, as in classic mainframe processing.

Two-tier R/3 System configurations are usually implemented using special presentation servers that are responsible solely for formatting the graphical user interface. Many R/3 System users use Windows PCs for example as presentation servers. An alternative two-tier configuration (not shown) is to install powerful desktop systems and to use these for presentation and applications also (two-tier client/server).

This type of configuration is particularly useful for processing-intensive applications (such as simulations) or for software developers, but due to the additional administration requirements is usually used for test purposes only.

In a three-tier configuration, separate servers are used for each tier. Using data from the database server, several different application servers can operate at the same time. To ensure that the load on individual servers is as even as possible and to achieve optimal performance, you can use special application servers for individual application areas such as distribution or financial accounting (logon and load balancing).

The central process in the R/3 application layer is the dispatcher. Together with the operating system, the dispatcher controls the resources for the R/3 applications. The main tasks of the dispatcher include distributing transaction load to the work processes, connecting to the presentation layer, and organizing communication.

User screen input is received by the SAP presentation program SAP GUI, converted into its own format, and then sent to the dispatcher. The processing requests are then saved by the dispatcher in request queues and processed according to “first in / first out”.

The dispatcher distributes (dispatches) the requests one after the other to the available work processes. Data is actually processed in the work process. The user that sent the request through the SAP GUI is usually not assigned the same work process, because there is no fixed assignment of work processes to users.

Once the data has been processed, the processing result from the work process is sent through the dispatcher back to the SAP GUI. The SAP GUI interprets this data and generates the output screen for the user with the help of the operating system on the frontend computer.

During initialization of the R/3 System, the dispatcher executes the following actions, among others:

it reads the system profile parameters, starts work processes, and logs onto the message server (this service will be explained later).


Within ABAP, SAP OPEN SQL is used to access application data in the database, independent of the corresponding RDBMS. The R/3 database interface converts the open SQL statements from the ABAP statements into the corresponding database statements. This means that application programs written in ABAP are database-independent. Native SQL commands can be used in ABAP.

When interpreting open SQL statements, the R/3 database interface checks the syntax of these statements and automatically ensures the local SAP buffers in the shared memory of the application server are utilized optimally. Data frequently required by the applications is stored in these buffers so that the system does not have to access the database server to read this data.

In particular, all technical data such as ABAP programs, screens, and ABAP Dictionary information, as well as some business process parameters usually remain unchanged in a running system, making them ideal buffering candidates. The same applies to certain business application data, which is accessed as read-only.

The operating system views the R/3 runtime system as a group of parallel, cooperating processes. On each application server these processes include the dispatcher as well as work processes; the number of work processes depends on the available resources. Work processes may be installed for dialog processing, update, dialog free background processing and spooling.

The lock mechanisms in today’s relational database systems are usually not able to handle business data objects (such as customer orders) that affect several database tables. To coordinate several applications simultaneously accessing the same business object, the SAP System provides its own lock management, controlled by the enqueue work process.

In order for the system to execute lock requests, you must first define a lock object in the ABAP Dictionary. The lock object contains tables whose entries are to be locked. A lock object consists of a primary table. You can also define additional secondary tables using foreign key relationships (the name of a user-defined lock object must begin with "EY" or "EZ").

You can specify the lock mode ("S”: shared lock or "E”: exclusive lock) for a lock object. An exclusive lock (mode "E") can only be set if no other user has set a lock (“E” or “S”) on the data record. The same user can request additional "E" or "S" locks within a program call sequence (call chain).

If a lock object is activated, the system generates an ENQUEUE and a DEQUEUE function module.These function modules are called ENQUEUE_ and DEQUEUE_ and are used in ABAP code to lock and unlock data.


The start of an SAP transaction is also the start of an SAP - LUW. SAP - LUWs are completed either by a "COMMIT WORK" in the ABAP code, or by the completion of the corresponding asynchronous update (second part of the SAP - LUW). As explained previously, each dialog step in an SAP - LUW is processed by one work process, as is the case for the DB - LUW. Each database change is executed in its own DB-LUW.

The asynchronous updating usually used in an SAP - LUW allows the system to temporarily collect changes made by users and then, at the end of the dialog phase (in the second part of the SAP - LUW), make the necessary changes to the database in a separate update work process. To ensure data consistency, the resulting database change (which includes every “dialog step change”) is executed in only one final DB - LUW.

Background work processes are designed for periodic tasks such as reorganization or the automatic transfer of data from an external system to the R/3 System.

Background processing is scheduled in the form of jobs. Each job consists of one or more steps (ABAP reports, external programs, or other operating system calls), that are processed sequentially.

You can also set priorities (from "C" to "A") so that certain jobs are prioritized.

Job processing is not generally triggered immediately (immediate start). Instead you specify a start date and time when you schedule the job. It may also be necessary to start jobs periodically, for example, system control jobs repeated on a fixed cycle. Using the program SAPEVT, you can trigger a job start at the operating system level.

The background scheduler is responsible for automatically triggering the job at the specified time.

The background scheduler is an ABAP program that regularly looks in the scheduling table for jobs to be executed and then ensures that they are executed (RDISP/BTCTIME, default 60 s).

Spooling refers to the buffered transfer of data to output devices such as printers, fax devices, and so on. In distributed systems, networked administration is necessary for this output.

The R/3 System spool mechanism can supply print requests to printers and external spoolers both within a local network as well as across wide-area networks (WANs). The spool mechanism works with the local spool system on each server.

Spool requests are generated in dialog mode or during background processing and are then set in the spool database with details about the printer and the print format. The data itself is stored in the TemSe (TEMporary SEquential object) database.

When data is to be printed, a print request is generated for a spool request. This print request is processed by a spool work process.

Once the spool work process has formatted the data for output, it returns the print request to the operating system spool system.

The operating system spool takes over queue management and ensures that the required data is passed to the output device.

An instance is an administrative unit that combines R/3 System components providing one or more services. The services provided by an instance are started or stopped together. You use a common instance profile to set parameters for all the components of an instance.

A central R/3 System consists of a single instance providing all the necessary R/3 System services.

Each instance has its own SAP buffer areas.

The message server provides the application servers with a central message service for internal communication (for example, trigger update, request and remove locks, trigger background requests).

The dispatchers for the individual application servers communicate through the message server, which is installed once in each R/3 System (it is configured in the R/3 System profile files).

Presentation servers can also log on to an application server through the message server. This means that you can use the message server performance database for automatic load distribution (logon load balancing).


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.


LESSON 4 ABAP DATA OBJECTS AND STATEMENTS

n Types describe the attributes of

. Input and output fields on screens,

. Data objects and

. Interface parameters: Type checks are performed each time a function or subroutine is called according to how the interface parameter is typed. Type conflicts are already identified during the editing process and appropriate syntax errors displayed.

n Local types are used in programs

. If only technical attributes are needed and no semantic attributes are required, and

. If the types are only used locally within a program.

n Global types ( = ABAP Dictionary types) are used

. If you intend to use the types externally

(for example, for typing the interface parameters of global functions or with those data objects in the program that serve as the interface to the database or the presentation server),

. If you need semantic information as well (for example, on screens with input and output fields).

n More information on storing semantic information centrally can be found in this unit.

n Elementary Dictionary types are called Data Elements. They contain semantic as well as technical information (technical type, length, number of decimal places).

n A data element can contain the following semantic information:

. Field Label: This text appears on screens and selection screens to the left next to the input or output fields. A field label can have one of three possible lengths. You must select one of the different field labels when you create a screen.

. Field Documentation: The field documentation tells the user what information should be entered in the field. The user gets the field documentation for an input or output field where the cursor is positioned by pressing function key F1.

. Search Help: A data element can be linked to a search help. This search help defines the value help provided by function key F4 or the corresponding icon.

n You can find more information on elementary ABAP Dictionary types

. for screen fields : Using F1 -> Technical info. or by double-clicking on the output field next to the data element label

. for local types in programs or data objects : By double-clicking on the type

n Technical types and technical domains may be directly assigned to data elements. If you want more information on other data elements referencing the same domain, you can navigate to the domain from the data element by double -clicking on its name and then executing the function Where-used list.

n You can search for data elements by using the application hierarchy and the Repository Information System.

. In the application hierarchy, select the components to be scanned.

. Go to the Information System.

. Choose ABAP Dictionary --> Basic objects --> Data elements and restrict the search.

n If you go to the Information System from the application hierarchy, the development classes of the selected application components are automatically entered.

n You can also go directly to the Information System. If you do not select a development class, the entire Repository is scanned.

n When defining simple types or variables, you can refer to a pre-defined type. For more information refer to the keyword documentation on TYPES or DATA.

. C Character

. N Numeric Text

. D Date (YYYYMMDD)

. T Time (HHMMSS)

. X Byte (heXadecimal)

. I Integer

. P Packed Number

. F Floating Point Number

. STRING Character String

. XSTRING String of Bytes (X String)

n Assign data object types by referring your object to either a built-in ABAP type, a user defined type .

or an ABAP Dictionary object.

n If a variable v2 refers to variable v1 using the addition LIKE ( DATA v2 LIKE v1. ), then v2 inherits its type from v1.

n Up to Release 4.0B, you could only refer to Dictionary types using LIKE. Only structure fields could be used as elementary types up to that point. Only flat structures were provided as structure types.

n Elementary data objects appear in the program object list under the 'Fields' node.

n From the object list, you can use the right mouse button to navigate to the part of the source code where the data object is defined.

n You can use the Where-used list function to display all lines of source code where the data object is used.

n Rules for naming data objects:

A name can consist of 30 characters maximum (letters, numbers, or symbols).

The following symbols ARE NOT allowed: ( ) + . , :

SPACE is a predefined field.

n For compatibility reasons, it is still possible to construct data objects in the DATA statement without first having to define the type locally in the program with a TYPES statement. Default values are also defined in addition to the type information for the following generic types:

. With data types P,N,C, and X you may enter a length (in bytes) in parentheses after the type name.

If no length is entered, the default length for this data type is used. You can find the standard

lengths in the keyword documentation for TYPES and DATA.

. With data type P you can use the DECIMALS addition to determine the number of decimal places that should be used (up to a maximum of 14). If this addition is missing, the number of decimal places is set to zero.

. If no type is entered, then the field is automatically a type C field.

n You define constants using the ABAP keyword CONSTANTS. The VALUE addition is required for constants. It defines their value.

n ABAP recognizes two types of literals: number literals and text literals. The latter is always enclosed in inverted commas (').

n Whole numbers (with preceding minus sign if they are negative) are stored as number literals with either type I (up to and including nine digits) or type P (ten or more digits).

n All other literals (character, numbers with decimal places, floating point numbers) are stored as text literals wit h data type C. If a literal is assigned to a variable that does not have type C, then a type conversion is carried out. The conversion rules are described in the keyword documentation about MOVE.

n If you want to include an inverted comma (') in a text literal, you must enter it twice.

n You can create translatable text literals, or text symbols, for all ABAP programs. Use the Program object types dialog box to get to the maintenance screen for the text symbols.

n When a program is started, the program context is loaded into a storage area of the application server and made available for all the data objects.

n Each elementary field comes as standard with an initial value appropriate to its type. You can set a start value for an elementary field yourself using the VALUE addition. After VALUE you may only specify a fixed data object.

n You can copy the field contents of a data object to another data object with the MOVE statement. If the two data objects have different types, the type is automatically converted if there is a conversion rule. If you want to copy the field contents of variable var1 to a second variable var2, you can choose one of two syntax variants:

. MOVE var1 TO var2.

. var2 = var1.

n You can find detailed information about copying and about the conversion rules in the keyword documentation for MOVE or in the BC402 training course.

n The CLEAR statement resets the field contents of a variable to the initial value for the particular type.

You can find detailed information about the initial values for a particular type in the keyword

documentation about CLEAR.

n You can precede calculations with the COMPUTE stateme nt. This statement is optional. You can use either of the following two syntax variants to calculate percentage occupancy using the variable v_occupancy for 'current occupancy'‚ v_maximum for 'maximum occupancy'‚ and v_percentage for 'percentage occupancy':

. COMPUTE v_percentage = v_occupancy * 100 / v_maximum.

. v_percentage = v_occupancy * 100 / v_maximum.

n You can find detailed information on the operations and functions available in the keyword documentation on COMPUTE.

n IF and CASE statements allow you to make case distinctions:

n CASE ... ENDCASE:

. Only one of the sequences of statements is executed.

. The WHEN OTHERS statement is optional.

n IF ... ENDIF:

. The logical expressions that are supported are described in the keyword documentation about IF.

. The ELSE and ELSEIF statements are optional.

. If the logical expression is fulfilled, the following sequence of statements is executed.

. If the logical expression is not fulfilled, the ELSE or ELSEIF section is processed. If there is no ELSE or no further ELSEIF statement, the program continues after the ENDIF statement.

. You can include any number of ELSEIF statements between IF and ENDIF. A maximum of one of the sequences of statements will be executed.

n You can trace the field contents of up to eight data objects in debugging mode by entering the field names on the left side or by creating the entry by double -clicking on a field name.

n You can change field values at runtime by overwriting the current value and choosing the 'Change' icon.

n From Release 4.6, you are allowed to set up to 10 watchpoints and link them using the logical operators AND and OR. Watchpoints are breakpoints that are field-dependent. You can create the following types of watchpoints:

. Variable value: The system stops processing once the logical condition is fulfilled. The 'Comparison field' flag is not selected and the value is inserted at 'Comp. field/value'.

. Variable1 variable2: The system stops processing once the logical condition is fulfilled. The 'Comparison field' flag is selected and variable2 is inserted at 'Comp. field/value'.

. Variable: The system stops processing each time the variable's value changes.

n You can define structured data objects (also called structures) in ABAP. This allows you to combine variables that belong together into one object. Structures can be nested. This means that other structures or even tables can be sub-objects of your original structure.

n There are two different kinds of structures in ABAP programs:

. Structures defined using DATA TYPE .

These kinds of structures serve as the target fields for database accesses or for calculations

performed locally within the program. You can declare these types of structures either in the

ABAP Dictionary or locally within your program. For more information on how to declare local structures, refer to the keyword documentation on TYPES.

. Structures defined using

TABLES .

These types of structures are technically administered in their own area. From Release 4.0,

TABLES structures only need to be used as interface structures for screens.

n Fields of a structure are always addressed with -.

n The MOVE-CORRESPONDING TO statements transports values field by field between structures and . This only works if the components have identical names.

n The system looks for all fields in whose names also occur in and transports field - to - in all cases where it finds a match.

All other fields remain unchanged.

n You can trace the field contents of a structure by entering the name of the structure in the left column. The field view of the structure is displayed if you double -click on this entry.

n You must define the following information in order to fully specify a table type:

. Line Type: You can store the information about the required columns, their names and types, by defining a structure type as line type.

. Key: A fully specified key must define: Which columns should be key columns? In what order?

Should the key uniquely specify a record of the internal table (unique key)? Unique keys cannot be defined for all the table types.

. Table Kind: There are three table kinds: standard tables, sorted tables and hashed tables. The estimated access type is mainly used to choose the table type.

n Access type defines how ABAP accesses individual table entries. There are two different types of data access in ABAP, access using the index and access using a key.

n Access using the index involves using the data record index that the system maintains to access data.

. Example : Read access to a data record with index 5 delivers the fifth data record of your internal table (Access quantity: one single data record).

n Access using a key involves using a search term, usually either the table key or the generic table key, to access data.

n Another internal table attribute is the table type. Internal tables can be divided into three table types according to the way they access data:

Standard tables maintain a linear index internally. This kind of table can be accessed using

either the table index or keys.

Sorted tables are sorted according to key and saved. Here too, a linear index is maintained

internally. This kind of table can also be accessed using either the table index or keys.

Hashed tables do not maintain a linear index internally. Hashed tables can only be accessed

using keys.

n Which table type you use depends on how that table's entries are normally going to be accessed. Use standard tables when entries will normally be accessed using the index, use a sorted table when entries will normally be made using keys, and use hashed tables when entries will exclusively be made with keys.

n In this course, we will discuss the syntax of standard tables only.

n Table types can be defined locally in a program or centrally in the ABAP Dictionary

n To define a table -type data object or an internal table, specify the type as a global table type or a local table type.

n You can perform the following operations on single records in internal tables:

. APPEND appends the contents of a structure having the same type as the line to an internal table.

This operation can only be used with standard tables.

. INSERT inserts the contents of a structure having the same type as the line in an internal table.

This causes a standard table to be appended and a sorted table to be inserted in the right place; a hashed table is inserted according to the hashing algorithm.

. READ copies the contents of a line of the internal table to a structure having the same type as the line.

. MODIFY overwrites a line of the internal table with the contents of a structure having the same type as the line.

. DELETE deletes a line of the internal table.

. COLLECT inserts the contents of a structure having the same type as the line in an internal table into an internal table in compressed form.. This statement may only be used for tables whose non key fields are all numeric. The numeric values are added for identical keys.

n You can find detailed information about the ABAP statements described here in the keyword documentation for the relevant ABAP keywords.

n You can perform the following operations on sets of records in internal tables:

. LOOP ... ENDLOOP The LOOP places the lines of the internal table in the structure

specified in the INTO clause one-by-one. The structure must have the same type as the line of the internal table. All single -record operations can be executed within the loop. In this case the system provides the information about the line to be edited in the single -record operation.

. DELETE deletes the lines of the internal table that satisfy the condition .

. INSERT copies the contents of several lines of an internal table to another internal table.

. APPEND appends the contents of several lines of an internal table to another standard

table.

n You can find detailed information about the ABAP statements described here in the keyword documentation for the relevant ABAP keywords.

n You can perform the following operations on internal tables:

. SORT You can sort tables by any column or columns in ascending or descending order

Sorted tables cannot be resorted.

. CLEAR Sets the contents of the internal table to the right initial value for the column type.

. REFRESH works like CLEAR.

. FREE Deletes the internal table and releases the memory allocated to the table.

n You can add lines to a standard ta ble by first filling a structure with the required values and then appending it to the internal table with the APPEND statement. This statement is only meaningful with standard tables.

n Use the INSERT statement to insert lines in sorted and hashed tables.

n INSERT works like an APPEND in standard tables.

n You can read and edit the contents of an internal table with a LOOP statement. In this example, one line is copied each time from internal table it_flightinfo to structure wa_flightinfo. The fields of the structure can then be edited. A list is built here from the fields with a WRITE statement.

n If you want to change the contents of the internal table, first change the value of the structure fields within the loop and then overwrite the line of the internal table with the MODIFY statement.

n With the INDEX addition you can restric t access to certain line numbers. You may only perform index operations on index tables. Both standard and sorted tables are supported here.

n The above example shows the syntax for loop editing that only scans the first five lines of the internal table.

n The example below shows the syntax for reading the third line of the internal table.

n With the WHERE addition you can restrict access to lines with certain values in key fie lds. Key operations are supported for all table types. Key access to sorted or hashed tables is more efficient than key access to standard tables.

n The above example shows the syntax for loop editing that only scans the lines of the internal table whose 'carrid' field has the value 'LH'. The sorted table is most suitable for this type of editing. Loop editing with the WHERE addition is supported for sorted and standard tables.

n The example below shows the syntax for reading a line of the internal table with a fully specified key. The return code sy-subrc is set to zero if the internal table contains this line. The hashed table is most suitable for single -record access by key. This type of access is supported for all table types.

Note that all the key fields must be defined in key accesses with the WITH TABLE KEY addition. It is easy to confuse this addition with the WITH KEY addition, which already permitted key access to standard tables prior to Release 4.0, when it was not yet possible to define key columns explicitly.

n You can trace the contents of an internal table in debugging mode by choosing 'Table' and entering the name of the internal table.

n Internal tables can be defined with or without a header line. An internal table with header line consists of a work area (the header line) and the actual body of table, both of which are addressed with the same name. How this name is interpreted depends on the context in which it is used. For example: at MOVE the name is interpreted to mean the header line, while at SORT it is interpreted as the table body.

n You can declare an internal table with a header line using the addition WITH HEADER LINE.

n In order to avoid confusion, it is recommended that you create internal tables without header lines.

However, in internal tables with header lines you can often use a shortened syntax for certain

operations.

n A number of ABAP statements support a return code. Various exceptions are detected, depending on the statement. If such an exception occurs, a value is stored in field sy-subrc and the function for the statement is terminated. The keyword documentation for the particular statement describes the exceptions that are supported and their values. When you start a program, a structure named sy is automatically provided as data object. This structure contains various fields that are filled by the system.. You can access these fields from the program. One of the fields of this structure is field subrc. You therefore do not have to create a data object for the return code.

n In this example a line should be read from internal table itab with key access. There is no line with the required key at runtime. The Basis function for the READ statement is therefore terminated and the value 4 is placed in field sy-subrc. Field sy-subrc is queried in the program immediately after the READ statement.

n There is a special dialog type called the user message for error situations. Messages are triggered with the MESSAGE statement.

n Messages can be found in table T100. They are organized according to language, a two-digit ID, and a three-digit number.

n Messages can contain up to 4 variables, identified as &1, &2, &3, and &4. If you want to output the character & and do not want to use it as a variable, double it, for example: 'This is a message with an &&'.

n In message long texts use &v1&, &v2&, &v3&, and &v4& for their corresponding variable.

n You can create your own messages using ID numbers that begin with Y (for the head office) or Z (for branch offices).

n Send messages with the MESSAGE statement. The language for messages in table T100 is automatically set to the user's logon language. You can define the message ID following the parameter MESSAGE-ID in the REPORT statement. The message ID is now set for the entire report.

Enter the message number at the MESSAGE statement.

n Enter the message type directly in front of the three-digit message number; this letter determines how the report user reacts to dialog messages (see next slide).

n Set values for variables (up to a maximum of four) following the parameter WITH. Fields and literals are also allowed. The field at level i thus replaces message variable &i. If the variables in the message are identified with & or $, these placeholders are supplied with values independent of the position of the fields of the message statement.

n In addition to using message ID with the REPORT statement, you can also add a different message ID to the command MESSAGE by entering the ID in parenthesis directly after the message number.

This deviant message ID is only valid for a single message, however. Example: MESSAGE

E004(UD).

n Use the following syntax, whenever you want to send a dynamic message: MESSAGE ID

TYPE NUMBER WITH .

n System fields SY-MSGID, SY-MSGTY and SY-MSGNO are supplied with the message ID, message type, and message number respectively and system fields SY-MSGV1 to SY-MSGV4 with the fields for the placeholders.

n There are six different types of message: A, X, E, I, S or W. The runtime behavior of the messages depends on the context. The letters have the following meaning:

A Termination Processing is terminated, the user must restart the transaction

X Exit Like a termination message, but with short dump

MESSAGE_TYPE_X E Error Runtime behavior depends on context

W Warning Runtime behavior depends on context

I Information Processing is interrupted, the message is displayed in a dialog

box and the program is continued when the message has been confirmed

with ENTER.

S Set The message appears in the status bar on the next screen.

n You can find a program for testing the runtime behavior in the sample programs of the

documentation. You can find the sample programs with transaction code ABAPDOCU or in the Editor with the ‘Information’ icon and radio button ABAP Docu and Examples.


Tutorials on SAP-ABAP

Adobe Interactive Forms Tutorials

Business Server Pages (BSP)

Userexits/BADIs

Web Dynpro for ABAP (Step by step procedure for web dynpro,Tutorials on Web Dynpro,)

ALV Tutorials

Blog Archive

goodsites