Sap ABAP Faqs,Interview Questions
What is an ABAP data dictionary?-
ABAP 4 data dictionary describes the logical structures of the objects used in application development and shows how they are mapped to the underlying relational database in tables/views.
What are domains and data element?-
Domains:Domain is the central object for describing the technical characteristics of an attribute of an business objects. It describes the value range of the field. Data Element: It is used to describe the semantic definition of the table fields like description the field. Data element describes how a field can be displayed to end-user.
What is foreign key relationship?
- A relationship which can be defined between tables and must be explicitly defined at field level. Foreign keys are used to ensure the consistency of data. Data entered should be checked against existing data to ensure that there are now contradiction. While defining foreign key relationship cardinality has to be specified. Cardinality mentions how many dependent records or how referenced records are possible.
Describe data classes.- Master data: It is the data which is seldomly changed. Transaction data: It is the data which is often changed. Organization data: It is a customizing data which is entered in the system when the system is configured and is then rarely changed. System data:It is the data which R/3 system needs for itself.
What are indexes?-
Indexes are described as a copy of a database table reduced to specific fields. This data exists in sorted form. This sorting form ease fast access to the field of the tables. In order that other fields are also read, a pointer to the associated record of the actual table are included in the index. Yhe indexes are activated along with the table and are created automatically with it in the database.
Difference between transparent tables and pooled tables.- Transparent tables: Transparent tables in the dictionary has a one-to-one relation with the table in database. Its structure corresponds to single database field. Table in the database has the same name as in the dictionary. Transparent table holds application data. Pooled tables. Pooled tables in the dictionary has a many-to-one relation with the table in database. Table in the database has the different name as in the dictionary. Pooled table are stored in table pool at the database level.
What is an ABAP/4 Query?- ABAP/4 Query is a powerful tool to generate simple reports without any coding. ABAP/4 Query can generate the following 3 simple reports: Basic List: It is the simple reports. Statistics: Reports with statistical functions like Average, Percentages. Ranked Lists: For analytical reports. - For creating a ABAP/4 Query, programmer has to create user group and a functional group. Functional group can be created using with or without logical database table. Finally, assign user group to functional group. Finally, create a query on the functional group generated.
What is BDC programming?- Transferring of large/external/legacy data into SAP system using Batch Input programming. Batch input is a automatic procedure referred to as BDC(Batch Data Communications).The central component of the transfer is a queue file which receives the data vie a batch input programs and groups associated data into “sessions”.
What are the functional modules used in sequence in BDC?- These are the 3 functional modules which are used in a sequence to perform a data transfer successfully using BDC programming: BDC_OPEN_GROUP - Parameters like Name of the client, sessions and user name are specified in this functional modules. BDC_INSERT - It is used to insert the data for one transaction into a session. BDC_CLOSE_GROUP - This is used to close the batch input session.
What are internal tables?- Internal tables are a standard data type object which exists only during the runtime of the program. They are used to perform table calculations on subsets of database tables and for re-organising the contents of database tables according to users need.
What is ITS? What are the merits of ITS?- ITS is a Internet Transaction Server. ITS forms an interface between HTTP server and R/3 system, which converts screen provided data by the R/3 system into HTML documents and vice-versa. Merits of ITS: A complete web transaction can be developed and tested in R/3 system. All transaction components, including those used by the ITS outside the R/3 system at runtime, can be stored in the R/3 system. The advantage of automatic language processing in the R/3 system can be utilized to language-dependent HTML documents at runtime.
What is DynPro?- DynPro is a Dynamic Programming which is a combination of screen and the associated flow logic Screen is also called as DynPro.
What are screen painter and menu painter?- Screen painter: Screen painter is a tool to design and maintain screen and its elements. It allows user to create GUI screens for the transactions. Attributes, layout, filed attributes and flow logic are the elements of Screen painter. Menu painter: Menu painter is a tool to design the interface components. Status, menu bars, menu lists, F-key settings, functions and titles are the components of Menu painters. Screen painter and menu painter both are the graphical interface of an ABAP/4 applications.
What are the components of SAP scripts?- SAP scripts is a word processing tool of SAP which has the following components: Standard text. It is like a standard normal documents. Layout sets. - Layout set consists of the following components: Windows and pages, Paragraph formats, Character formats. Creating forms in the R/3 system. Every layout set consists of Header, paragraph, and character string. ABAP/4 program.
What is ALV programming in ABAP? When is this grid used in ABAP?- ALV is Application List viewer. Sap provides a set of ALV (ABAP LIST VIEWER) function modules which can be put into use to embellish the output of a report. This set of ALV functions is used to enhance the readability and functionality of any report output. Cases arise in sap when the output of a report contains columns extending more than 255 characters in length. In such cases, this set of ALV functions can help choose selected columns and arrange the different columns from a report output and also save different variants for report display. This is a very efficient tool for dynamically sorting and arranging the columns from a report output. The report output can contain up to 90 columns in the display with the wide array of display options.
What are the events in ABAP/4 language?- Initialization, At selection-screen, Start-of-selection, end-of-selection, top-of-page, end-of-page, At line-selection, At user-command, At PF, Get, At New, At LAST, AT END, AT FIRST.
What is CTS and what do you know about it?- The Change and Transport System (CTS) is a tool that helps you to organize development projects in the ABAP Workbench and in Customizing, and then transport the changes between the SAP Systems and clients in your system landscape. This documentation provides you with an overview of how to manage changes with the CTS and essential information on setting up your system and client landscape and deciding on a transport strategy. Read and follow this documentation when planning your development project.
What are logical databases? What are the advantages/ dis-advantages of logical databases?- To read data from a database tables we use logical database. A logical database provides read-only access to a group of related tables to an ABAP/4 program. Advantages: i)check functions which check that user input is complete, correct,and plausible. ii)Meaningful data selection. iii)central authorization checks for database accesses. iv)good read access performance while retaining the hierarchical data view determined by the application logic. dis advantages: i)If you donot specify a logical database in the program attributes,the GET events never occur. ii)There is no ENDGET command,so the code block associated with an event ends with the next event statement (such as another GET or an END-OF-SELECTION).
What is a batch input session?- BATCH INPUT SESSION is an intermediate step between internal table and database table. Data along with the action is stored in session ie data for screen fields, to which screen it is passed, program name behind it, and how next screen is processed.
How to upload data using CATT ?- These are the steps to be followed to Upload data through CATT: Creation of the CATT test case & recording the sample data input. Download of the source file template. Modification of the source file. Upload of the data from the source file.
What is Smart Forms?- Smart Forms allows you to create forms using a graphical design tool with robust functionality, color, and more. Additionally, all new forms developed at SAP will be created with the new Smart Form solution.
How can I make a differentiation between dependent and independent data?- Client dependent or independent transfer requirements include client specific or cross client objects in the change requests. Workbench objects like SAPscripts are client specific, some entries in customizing are client independent. If you display the object list for one change request, and then for each object the object attributes, you will find the flag client specific. If one object in the task list has this flag on, then that transport will be client dependent.
What is the difference between macro and subroutine?- Macros can only be used in the program the are defined in and only after the definition are expanded at compilation / generation. Subroutines (FORM) can be called from both the program the are defined in and other programs . A MACRO is more or less an abbreviation for some lines of code that are used more than once or twice. A FORM is a local subroutine (which can be called external). A FUNCTION is (more or less) a subroutine that is called external. Since debugging a MACRO is not really possible, prevent the use of them (I’ve never used them, but seen them in action). If the subroutine is used only local (called internal) use a FORM. If the subroutine is called external (used by more than one program) use a FUNCTION.
Showing posts with label abap. Show all posts
Showing posts with label abap. Show all posts
SAP ABAP Dictionary interview Questions
What types of objects can be created in the ABAP Dictionary?
Tables
Views
Data Elements
Structures
Table Types
Type Groups
Domains
Search Helps
Lock Objects
What types of tables can be created in the ABAP Dictionary?
Transparent Tables
Pooled and Clustered Tables
Which field differentiates a table from client-dependent and client-independent?
The MANDT field of the table specifies whether the table is client independent or not. Client-dependent tables contains MANDT column and are client specific. Client Independent tables do not have MANDT columan and can be accessed from any client.
Full Size
What is the difference between Pooled tables and Cluster tables?
Cluster tables and Pooled tables have many to one relationship with the underlying database.
A table pool corresponds to a table in the database in which all records from the pooled tables assigned to it are stored.
Several logical data records from different cluster tables can be stored together in one physical record in a table cluster.
* A pooled table cannot have the name having more than 10 characters.
* All the key fields of the pooled table must be of character data type.
* In pooled tables, the maximum length of the key field/data fields should not exceed the length of varkey/vardata of the pool respectively.
* In cluster table the records having the same key are stored in a single key in the cluster.
* If there is an overflow of the data records a continuation record is created with the same table key.
What is the difference between Database tables and Views?
The Table has a physical storage of data whereas views do not have physical storage of data.
The view is derived from one or more tables which is created only with the required fields from the database table(s). It can also be created with table inner joins and specifying conditions for data retrieval.
What are the different types of Views?
* Projection view - Just retrieves some fields from a single table.
* Help View - This is used for search help.
* Database View - This is inner join view of one or more tables
* Maintenance View - Helps in creating maintaining data of the application object. The data can be distributed among several tables.
Can I use all the views in the ABAP program ?
No. You can use only projection view or database view in your ABAP program.
What is Table Maintenance Generator?
The Table Maintenance Generator is used to create table maintenance program to add, modify or delete records in the database table. This can be accessed using transaction SE54 or in SE11 using the menu Utilities->Table Maintenance Generator.
What is One step, two step in Table Maintenance Generator?
This specifies the screens to be created in the Table Maintenance Program.
Single step: Only overview screen is created i.e. the Table Maintenance Program will have only one screen where you can add, delete or edit records.
Two step: Two screens namely the overview screen and Single screen are created. The user can see the key fields in the first screen and can further go on to edit further details.
How do you activate the database table after making changes to it?
After making changes to the table, inorder to reflect the changes go to transaction SE14 and Choose Edit and then choose Activate and Adjust Database.
In which table are the programs stored in?
The programs are stored in the table TADIR and the development class packages in TDEVC.
I have recently added a few fields to a custom table. But I don't get these fields in the table maintenance program?
You have to delete and recreate your own existing table maintenance program to see your new fields.
What is the difference between INSERT and MODIFY?
Whenever you need to create new records in the database table use INSERT. Whenever using INSERT be sure that a duplicate entry having the same values for the primary key fields are not present. Else it may throw a dump.
When you use MODIFY it makes a check for the matching key field values. If present it modifies the matching record, else it creates a new record in the database table.
How do I create index on a database table?
Go to transaction SE11, open your database table. Choose the menu, Goto->Indexes to create index. Give your index name and choose the fields of the table. Be careful, an additional index may vanish with the next upgrade or hotpackage.
What is the difference between Check Table and Value Table?
The Check Table is the dependent table to which the relationship is defined using foreign keys. The contents of the check table field are shown in the input help for the referenced field.
The Value table is the table attached to a field at the domain level, where the entry to the field can be only from the value table. They are not used in the Input Help.
When Value table becomes check table?
While establishing foriegn key relation between check table and foriegn key table if at the domain level value table is provided then the system will prapose that value table as check table if you accept this prposal then value table will becomes check table.
What is the difference between Domain and Data Elements?
The Domain specifies the Technical attributes of the field such as the data type, length and the value range.
The data element is an elementary type defining the description/text for the field when displaying on the screen and Parameter ID.
When I create new entries in the table the field values are always in Uppercase. How do I get the data with mixed case?
The reason for this is that the Domain for the field in the table might have Lowercase checkbox unchecked. Check the Lowercase checkbox to preserve the case of your data.
What is the need of reference table and reference field in Currency/Quantity fields?
The reference table and reference field are the fields which specify the currency key or Unit of Measure. Suppose if the user specifies a currency amount say 1000$, the currency amount field would indicate the amount 1000 and the currency key indicates that the currency specified is in Dollars.
Where to find the table of tables?
How to add new fields in standard table ?
Create Z-Structure with the fields needed and append the structure to the standard table by using the option append structure within table display
we can enhance the standard tables by using Append structures and customizing includes.
Append structures allow you to attach fields to a table without actually having to modify the table itself. Table enhancements using append structures therefore do not have to be planned by SAP developers. An append structure can only belong to exactly one table.
Tables
Views
Data Elements
Structures
Table Types
Type Groups
Domains
Search Helps
Lock Objects
What types of tables can be created in the ABAP Dictionary?
Transparent Tables
Pooled and Clustered Tables
Which field differentiates a table from client-dependent and client-independent?
The MANDT field of the table specifies whether the table is client independent or not. Client-dependent tables contains MANDT column and are client specific. Client Independent tables do not have MANDT columan and can be accessed from any client.
Full Size
What is the difference between Pooled tables and Cluster tables?
Cluster tables and Pooled tables have many to one relationship with the underlying database.
A table pool corresponds to a table in the database in which all records from the pooled tables assigned to it are stored.
Several logical data records from different cluster tables can be stored together in one physical record in a table cluster.
* A pooled table cannot have the name having more than 10 characters.
* All the key fields of the pooled table must be of character data type.
* In pooled tables, the maximum length of the key field/data fields should not exceed the length of varkey/vardata of the pool respectively.
* In cluster table the records having the same key are stored in a single key in the cluster.
* If there is an overflow of the data records a continuation record is created with the same table key.
What is the difference between Database tables and Views?
The Table has a physical storage of data whereas views do not have physical storage of data.
The view is derived from one or more tables which is created only with the required fields from the database table(s). It can also be created with table inner joins and specifying conditions for data retrieval.
What are the different types of Views?
* Projection view - Just retrieves some fields from a single table.
* Help View - This is used for search help.
* Database View - This is inner join view of one or more tables
* Maintenance View - Helps in creating maintaining data of the application object. The data can be distributed among several tables.
Can I use all the views in the ABAP program ?
No. You can use only projection view or database view in your ABAP program.
What is Table Maintenance Generator?
The Table Maintenance Generator is used to create table maintenance program to add, modify or delete records in the database table. This can be accessed using transaction SE54 or in SE11 using the menu Utilities->Table Maintenance Generator.
What is One step, two step in Table Maintenance Generator?
This specifies the screens to be created in the Table Maintenance Program.
Single step: Only overview screen is created i.e. the Table Maintenance Program will have only one screen where you can add, delete or edit records.
Two step: Two screens namely the overview screen and Single screen are created. The user can see the key fields in the first screen and can further go on to edit further details.
How do you activate the database table after making changes to it?
After making changes to the table, inorder to reflect the changes go to transaction SE14 and Choose Edit and then choose Activate and Adjust Database.
In which table are the programs stored in?
The programs are stored in the table TADIR and the development class packages in TDEVC.
I have recently added a few fields to a custom table. But I don't get these fields in the table maintenance program?
You have to delete and recreate your own existing table maintenance program to see your new fields.
What is the difference between INSERT and MODIFY?
Whenever you need to create new records in the database table use INSERT. Whenever using INSERT be sure that a duplicate entry having the same values for the primary key fields are not present. Else it may throw a dump.
When you use MODIFY it makes a check for the matching key field values. If present it modifies the matching record, else it creates a new record in the database table.
How do I create index on a database table?
Go to transaction SE11, open your database table. Choose the menu, Goto->Indexes to create index. Give your index name and choose the fields of the table. Be careful, an additional index may vanish with the next upgrade or hotpackage.
What is the difference between Check Table and Value Table?
The Check Table is the dependent table to which the relationship is defined using foreign keys. The contents of the check table field are shown in the input help for the referenced field.
The Value table is the table attached to a field at the domain level, where the entry to the field can be only from the value table. They are not used in the Input Help.
When Value table becomes check table?
While establishing foriegn key relation between check table and foriegn key table if at the domain level value table is provided then the system will prapose that value table as check table if you accept this prposal then value table will becomes check table.
What is the difference between Domain and Data Elements?
The Domain specifies the Technical attributes of the field such as the data type, length and the value range.
The data element is an elementary type defining the description/text for the field when displaying on the screen and Parameter ID.
When I create new entries in the table the field values are always in Uppercase. How do I get the data with mixed case?
The reason for this is that the Domain for the field in the table might have Lowercase checkbox unchecked. Check the Lowercase checkbox to preserve the case of your data.
What is the need of reference table and reference field in Currency/Quantity fields?
The reference table and reference field are the fields which specify the currency key or Unit of Measure. Suppose if the user specifies a currency amount say 1000$, the currency amount field would indicate the amount 1000 and the currency key indicates that the currency specified is in Dollars.
Where to find the table of tables?
How to add new fields in standard table ?
Create Z-Structure with the fields needed and append the structure to the standard table by using the option append structure within table display
we can enhance the standard tables by using Append structures and customizing includes.
Append structures allow you to attach fields to a table without actually having to modify the table itself. Table enhancements using append structures therefore do not have to be planned by SAP developers. An append structure can only belong to exactly one table.
Sap ABAP Tutorials WorkBench and tools
Sap Tutorials WorkBench 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 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.
And 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.
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 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.
And 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.
SAP ABAP Tutorials :Architecture and Design
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).
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.
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 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.
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).
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).
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).
Subscribe to:
Posts (Atom)
