You are on page 1of 46

SAP ABAP

SAP System Application Products Abbreviations


1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. ERP Enterprise Resource Planning SAP System Application Products ABAP Advance Business Application Programming MM Material Management SD Sales & Distribution FI Finance, CO Controlling FI-CA Finance Casting BASIS BASIS BW Business Information Warehouse BI Business I CRM Customer Relationship Management 12. XI Exchange Infra Structure 13. NT Net Ware 14. QM Quality Management 15. PP Production Plant 16. WMS Ware House Management System 17. HR Human Resources 18. PM Plant Maintenance 19. PS Project System 20. ECM Enterprise Compensation Management 21. IM Inventory Management 22. PLM Project Life cycle Management 23. GTS Global Trade Service 24. SCM Supply Change Management 25. EP Enterprise Portal 26. BPP Business Process Produce 27. SEM Strategic Enterprise Management 28. APO - Advanced Planner Optimizer 29. SRM - Supplier Relationship Management 30. IS-Retail Industrial Service Retail 31. ISU Industrial Service Utilities 32. DM Delivery Management 33. *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*

ABAP Advance Business Application Programming - Abbreviations


ABAP Advance Business Application Programming ALV Abap List Viewer BDC Batch Data Communication LSMW Legacy System Migration Workbench ALE Application Link Enabling IDoc Intermediate Document BADI Business Add Ins BAPI Business Application Programming Interface RFC Remote Function Call EDI Electronic Data Interchange ITS Internet Transaction Server BOR Business Object Repository JCO Java Connectivity Object

CGI Common Gate way Internet NWAS Net wear Web Application Server BSP Business Server Page OOPs Object Oriented Programs SBWP SAP Business Work Place SDLC Software Development Life Cycle OLTP On Line Transaction Processing OLAP On Line Analysis and Processing AWB ABAP Work Bench ODC Offshore Development Centre ASAP Accelerate System Application Products *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*

Abbreviations
HTTP Hyper Text Transfer Protocol CSP Complementary Software Program LAN Local Area Network WAN World Area Network WWW World Wide Web CPU Central Process Unit HTML Hyper Text Mark up Language *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*

T Codes (Transaction Codes)


SE11 ABAP Dictionary SE12 ABAP Dictionary SE16 ABAP Dictionary SE18 Badi Builder Initial Screen for Definition SE19 Badi Builder: Initial Screen for Implementations SE20 - Enhancements Initial screen SE24 ABAP Class Builder SE37 Function Module SE38 ABAP Editor SMARTFORMS Smartforms LSMW LSMW SHDB BDC (Batch Data Communication) or SM35 -- batch input -- recording ME21 Purchase Order Create ME22 Purchase Order Change ME23 Purchase Order Display XK01 Vendor Create XK02 Vendor Change XK03 Vendor Display XD01 Customer Create XD02 Customer Change XD03 Customer Display VA01 Sales Order Create VA02 Sales Order Change VA03 Sales Order Display SE80 Object Navigator (Development Package) SE09 Transport Organizer SE36 Logical Database SQ01 Define Query & Execute Query SQ02 Define and Generate Infosets & Assign User Group to Infosets SQ03 Define User Group & Assign Users and Infosets to User Group SE84 ABAP Development Workbench

SE41 Menu Painter SE51 Screen Painter (Transaction) SE71 Script forms ST02 Buffering Changes ST03 System Performance ST04 Database Performance Analysis Oracle Database overview ST05 SQL Trace SE30 Run time Analysis SLIN Syntax Error ST22 Dump Analysis VF03 Billing Document (Export Invoice) CS01 Create a Material of BOM CA01 Create Routing SE91 Create a Messages SE93 Maintain Transaction (Create T.Code) AL21 To Analyze the Performance of ABAP SE72 Smart forms Style SE73 Bar codes SE74 Script format Conversion SE75 Standard text module script SE76 Script form Translation SE78 Graphics SO10 Standard Text SM01 Lock/Unlock Transaction Code SM12 Lock Entries SM21 System Log SM35 Batch Input (BDC), Session overview SM36 Define Background job SM37 Simple Job Selection SM50 Process overview SM51 SAP Servers SM66 Global work process overview RFC calls SALE Logical system Names SM59 Maintain RFC destinations SPRO Using for Function Consultant SP01 Spool Request SP02 Spool Request Output Controller BD64 Maintain Distribution Model BD82 Generate partner Profiles SA38 ABAP Execute Program direct SE03 Transport Organizer Tools SCC4 Display View Clients Overview DB13 DBA Planning Calendar for Oracle Database ERP: Maintain DB12 Backup logs: Overview for Database ERP OSS Notes ---- Online Service Systems for SAP.com web site.

Project Implementation Levels


Total 5 Phases. Phase 1 --- Development Customization (Project Preparation) Phase 2 --- Business Requirement of Process and Analysis (Blue Print) Phase 3 --- Realization Phase 4 --- Testing

Phase 5 --- Go Live *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*

Support Levels
Level 1: ----- Call Center / Help Desk. Level 2: ----- Team Ticket level issues Level 3: ----- Level 4: ----- 24/7 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* Level 1: End User / Client Level 2: Function Consultants Level 3: Techno Function Consultants Level 4: Technical Consultants *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*

System Fields
Its a structure -- SYST Sy-datum Sy-uzeit Sy-uname Sy-index Sy-tabix Sy-subrc Sy-linno Sy-lsind Sy-ucomm Sy-ldbpg Date Time User Name Maintains the loop index Row index Internal table Current line index Process status List creation, current line List processing, details list index Screen function code triggered by PAI ABAP program, logical database program

*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* MM Flow: ------MRP (Material Requirement Plan) (MDTB - MRP Table) (MDIP - Material: MRP Profiles (Field Contents)) ------ Procurement ------ Purchase Requisition (ME51N) (EBAN) ------ Request Quotation ----- Quotation (VA21) ( ------ Bill of Material (CS01) (MAST - Material to BOM Link, STKO BOM Header, STPO BOM Item) ------ Delivery ------ Invoice Purchase Order (ME21N) Material Description (MAKT) SD Flow: 1. Enquiry (VA11) ------ Quotation (VA21) ------ Sales Order (VA01) ------ Delivery (VL01N) ------ Invoice (VF01)

------ VBAK, VBAP ----LIKP, LIPS ----- VBRK, VBRP. 2. Delivery (Shipping) ------ Packing & Picking will do. Picking means: - From which plant the materials should be delivered for a particular sales order. 3. Invoice --------- Billing 4. Conditional Table ---- KONV ----- Contains currency, amount, unit of measure, as per these specifications Billing will be done. *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* ABAP Editor Attributes Total 7 types: 1 E Executable Program K Class Pool F Function Group M Module Pool I Include Program S Subroutine Pool J Interface Pool

*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* Tables Master Data Tables KNA1 Customer Master (General Data) MARA General Material Data T001W Plants/Branches LFA1 Vendor Master (General Data) SKB1 G/L Account Master (Company Code) T001 Company Codes

*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* FI-CO (Finance Costing) BSAD - Accounting: Secondary Index for Customers (Cleared Items) BSAS Accounting: Secondary Index for G/L Accounts (Cleared Items) BSEG Accounting Document Segment BSES Document Control Data BSIK Accounting: Secondary Index for Vendors BSIS Accounting: Secondary Index for G/L Accounts MM (Material Management) EKKO Purchase Document Header KNMT Customer-Material Info Record Data Table MARC Plant Data for Material MSEG Document Segment Material EKPO Purchase Document Item MAKT Material Description MAST Material to BOM Lint MKPF Header Material Document

SD (Sales & Distribution) KONV Conditions (Transaction Data) LIKP SD Document: Delivery Header Data LIPS SD document: Delivery: Item data VBAK Sales Document: Header Data VBAP Sales Document: Item Data VBBE Sales Requirements: Individual Records VBEH Schedule line history VBEP Sales Document: Schedule Line Data VBFA Sales Document Flow VBPA Sales Document: Partner VBRK Billing Document: Header Data VBRP Billing Document: Item Data VBUK Sales Document: Header Status and Administrative Data VBUP Sales Document: Item Status VEKP Handling Unit - Header Table KNA1 Customer Master KNB1 Customer Master (Company Code) KNVV Customer Master Sales Data LFA1 Vendor Master KNVP Customer Master Partner Functions

Tables & Fields LFA1 LIFNR, MARA MATNR, T001W WERKS, BSAD BUKRS, KUNNR BSEG BUKRS, BSIK BUKRS, LIFNR EKKO EBELN, BUKRS, LIFNR KNMT VKORG, KUNNR, MATNR MARC MATNR, WERKS MSEG MBLNR, MATNR, WERKS, KONV KNUMV LIPS VBELN, MATNR VBAP VBELN, MATNR, VBEH VBELN, POSNR VBFA VBELN, POSNR, MEINS, MATNR VBRK VBELN, VKORG, BELNR VBUK VBELN VEKP VENUM LFA1 LIFNR KNVP KUNNR, VKORG, LIFNR KNA1 KUNNR, SKB1 BUKRS T001 BUKRS, BSAS BUKRS, BELNR BSES BUKRS, BELNR BSIS BUKRS, BELNR EKPO EBELN, EBELP, MATNR, BUKRS, WERKS, MATKL MAKT MATNR, SPRAS, MAKTX MAST MATNR, WERKS MKPF MBLNR, LIKP VBELN, VKORG VBAK VBELN, VBBE VBELN, MATNR, WERKS VBEP VBELN, POSNR, MEINS VBPA VBELN, POSNR, KUNNR, LIFNR VBRP VBELN, POSNR, MEINS VBUP VBELN, POSNR KNA1 KUNNR KNB1 KUNNR, BUKRS KNVV KUNNR, VKORG

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* Data Dictionary T-Codes: SE11 Data Dictionary display, change, create SE12 Data Dictionary change SE16 Data Dictionary display for database tables Data Dictionary Objects: Database Tables View, Data type, Type group, Domain, Search help, Lock objects etc Table: Collection of rows and columns, and have associated database tables, primary key. Structure: Description of group of fields (without data), and have no associated database tables, no primary key. Data type - in the ABAP program to define data objects and types analogously to types that are predefined in the ABAP program (such as C or I) or types that are defined locally in ABAP programs. The following type categories can be defined in the ABAP Dictionary:

Data elements (elementary types) Elementary types have no structure. They describe the data type attributes (such as given Dictionary data type, number of places) and information that is relevant for the screen (such as title) of unstructured data objects (variables/fields). T.code SE11, choose Data type ---- and give ZDATAELEMENT name ---- click create button --- we get pop up window in that 3 choices i.e., 1. Data Element, 2. Structure, 3. Table type. We can choose of Data element radio button and click continue button ---- we can get Dictionary Maintain data element window --- give the short description --- give the domain name like

Structures (structured types) Structured types describe the structure and functions of any structured data objects, that is of data structures with components of any type. A component can be a field with an elementary type or can itself be a structure. A table can also be used as a component in a structure. A database table always has a structure and is therefore implicitly a structured type. However, the fields of a database table can only have an elementary type. Table types Table types describe the structure and functions of internal tables in the ABAP program. Their rows can have any row type. Table types with elementary row type therefore can be defined just the same as multi-dimensional table types (table types with a table type as row type) or table types using structures with table-like components.

View: - Collection of fields from different database tables. 4 types of views 1. Database view Tables ----- fields from more than one table Joins ------ inner join used Access ---- one table (read/write), one table (read) Usage ---- reports, to fill a table this view is used. 2. Projection View Tables ------ fields from one table Joins ------ no joins used Access ------ one table (read/write) Usage ----- reports 3. Maintenance view ----- (V_T438M_V) Tables ------ fields from more than one table Joins ------ no joins used Access ---- one table (read/write/delete/change) Usage ----- SM30 4. Help view Tables ---- one table Joins ---- no joins used Access -- one table (read) Usage ---- search help Data Element: A field in R/3 system is a data element. Properties and type for a table field. Domain: A domain describes the technical attributes of a field, such as the data type or the number of positions in a field. The domain defines primarily a value range describing the valid data values for the fields referring to this domain. Different technical fields of the same type can be combined in a domain. Fields referring to the same domain are changed at the same time when a domain is changed. This ensures the consistency of these fields. Data Class a. APPL0 Master Data, Transparent Tables b. APPL1 Transaction data, Transparent tables c. APPL2 Organization and Customizing d. USER Customer data class e. USER1 Customer data class f. USER6 Customer data class, generated by SAPDBA Size Category

0 1 2 3 4 5 6

0 720 2,800 11,000 46,000 180,000 370,000

to to to to to to to

720 2,800 11,000 46,000 180,000 370,000 14,000,000

Delivery Class

1. A Application table (Master & Transaction data) 2. C Customizing table, maintenance only by cust, not SAP import
3. L Table for storing temporary data, delivery empty 4. G Customizing table, protected against SAP upload, only INS all 5. E Control table, SAP and Customer have separate key areas 6. S System table, maintenance only by SAP, change = modification 7. W System table, contents transportable via separate TR objects Delivery & Maintenance: Data Browser / Table view maintenance:

1. Display / Maintenance Allowed with Restriction


2. Display / Maintenance Allowed 3. Display / Maintenance not Allowed. Field Symbols: Field symbols are place holders for existing fields. A field symbol does not physically reserve space for a field, but points to a field which is not known until runtime of the program. Field Groups: A field group combines several fields under one name. At runtime, the INSERT command is used to define which data fields are assigned to which field group. Search Helps: Search help is the input help for the field. A search help is an object of the ABAP Dictionary with which input helps (F4 helps) can be defined. There are the following types of search helps:

1. Elementary search helps: - Implement a search path for determining the possible entries. 2. Collective search helps: - contain several elementary search helps. A collective search help therefore provides
several alternative search paths for possible entries.

3. Append search helps: - can be used to enhance collective search helps delivered by SAP with customer-specific
search paths without requiring a modification. The three components of the input help process described by a search help are the outer interface, the online behavior and the method of data collection. The outer interface is defined by specifying the interface parameters. They define the context information to be used in the input help process and the attributes to be sent to the screen by the input help. The search help attachment defines the field contents for parametrizing an import parameter and the fields of the input template in which the contents of the export parameters should be returned. The dialog behavior and data collection are defined differently for elementary search helps and collective search helps. The behavior of a search help can be made more flexible than usual with search help exits. Lock Objects: A lock object is a virtual link of several SAP tables which is used to synchronize simultaneous access by two users
to the same set of data ( SAP lock concept).

Locks are requested and released in the programming of online transactions by calling certain function modules which are automatically generated from the definition of the lock objects. These lock objects must be explicitly created in the ABAP Dictionary. To set locks, you must perform the following steps: 1. You must define a lock object in the ABAP Dictionary. The name of the lock object should begin with E. 2. The function modules for requesting and releasing locks which are created automatically when the lock object is activated must be linked to the programming of the relevant online transactions.

T.code SE11, the name should begin with E Lock object name .. Short description . Attributes --- Last changed on/by, Package, Original language, Allow RFC (check box) Tables --- Primary table (Name, Lock mode Write lock, Read lock, exclusive, not cumulative), secondary tables (Name, Lock mode) Lock parameter --- lock parameter (ID), Table (table name), field (field name), Save & active. Buffering: 3 types of buffering

1. Full buffering: All the records of the table are loaded into the buffer when 1 record is accessed. 2. Generic buffering: When a record of the table is accessed, all the records having this record in generic
key fields are loaded into the buffer. 3. Single record buffering: Only the records of the table that are really accessed are loaded into the buffer. Table Maintains Data base Table Types: 4 types a. b. c. d. Transparent table Pool table Cluster table Internal table same data and fields. Both open Sql and Native Sql can be used.

1. Transparent table: Exists with the same structure both in dictionary as well as in database exactly with the 2. Pool table & Cluster table: These are logical tables that are arranged as records of transparent tables. One
cannot use native sql on these tables (only open sql). They are not manageable directly using database system tools. 3. Internal Table: 3 types and other tables types, totally 5 types Internal Table Types Total 5 types of internal tables
1. STANDARD TABLE 2. SORTED TABLE 3. HASHED TABLE 4. INDEX TABLE 5. ANY TABLE The table type - set in the DATA, TYPES, or CREATE DATA statement, specifies how the system accesses entries in the internal table in generic key operations. (READ TABLE itab, DELETE TABLE itab, INSERT TABLE itab, MODIFY TABLE itab, COLLECT itab). As a general

rule, the runtime required for key operations depends on the total length of the key. The various table types have the following hierarchy: ANY TABLE | -----------------------------| | INDEX TABLE HASHED TABLE | -------------------------------------| | STANDARD TABLE SORTED TABLE STANDARD TABLE: - Defines the table as a standard table. Key access to a standard table uses a linear search. This means that the time required for a search is in linear relation to the number of table entries. You should use index operations to access standard tables. For the sake of compatibility, you can use TABLE as a synonym of STANDARD TABLE. SORTED TABLE : - Defines the table as one that is always saved correctly sorted. Key access to a sorted table uses a binary key. If the key is not unique, the system takes the entry with the lowest index. The runtime required for key access is logarithmically related to the number of table entries. You can also access sorted tables by index operations. When you insert using an index, the system checks to ensure that the sort sequence has been correctly maintained. For this reason, it takes longer than inserting entries in a standard table. As a rule, you should only access sorted tables using their key. HASHED TABLE : - Defines the table as one that is managed with an internal hash procedure. You can imagine a hashed table as a set, whose elements you can address using their unique key. Unlike standard and sorted tables, you cannot access hash tables using an index. All entries in the table must have a unique key. Access time using the key is constant, regardless of the number of table entries. You can only access a hashed table using the generic key operations or other generic operations ( SORT, LOOP, and so on). Explicit or implicit index operations (such as LOOP ... FROM oe INSERT itab within a LOOP) are not allowed. INDEX TABLE: - Standard and sorted tables belong to the generic class index tables. An index table is one that we can access using an index. We can currently only use the table type INDEX TABLE to specify the type of generic parameters in a FORM or a FUNCTION. Hashed tables are not index tables, and cannot therefore be passed to parameters defined as INDEX TABLE. ANY TABLE: - Like INDEX TABLE, you use ANY TABLE to specify the type of any generic table parameter. The set of permitted operations for a table with type ANY TABLE consists of the intersection of all permitted operations for STANDARD, SORTED and HASHED TABLEs, and so is identical to the set of operations permitted for hashed tables. Note in particular that you cannot use index access for tables with this type.

Check Table: - A control element for a foreign key. If a foreign key links two tables by assigning fields of tables to
the primary key fields of table is known as the check table for the foreign key. Value Table: - The table is specified in the definition of a domain and it is to be checked against all fields pointing to the domain. If we try to define a foreign key for a field that points to this domain, the value table of the domain is proposed as the check table for the foreign key. Foreign Key Table: - A diagram that is checked against the check table is using the foreign key. Sum: It is an aggregate command Collect: It is a data manipulation command Secondary Index: It enables us can search quickly on columns other than those in the primary key. 15 secondary indexes per table are allowed. Commit Work: Closes the all database calls. Roll Back: Cancels all requests relevant to synchronized execution of tasks. (No changes in database)

Match Code: Contains fields from several tables. Index: Fields from only one table. LUW (Logical Unit of Work): A Logical Unit of Work (LUW or database transaction) is an inseparable sequence of database operations which must be executed either in its entirety or not at all. For the database system, it thus constitutes a unit. LUWs help to guarantee database integrity. When an LUW has been successfully concluded, the database is once again in a correct state. If, however, an error occurs within an LUW, all database changes made since the beginning of the LUW are canceled and the database is then in the same state as before the LUW started. An LUW begins o each time you start a transaction o when the database changes of the previous LUW have been confirmed (database commit) or o when the database changes of the previous LUW have been cancelled (database rollback) An LUW ends o when the database changes have been confirmed (database commit) or o when the database changes have been canceled (database rollback) Database commit and rollback Within an LUW, database changes are not made until after a database commit. Prior to this, any database change can be canceled by a database rollback. In the R/3 System, a database commit is triggered either automatically or by the ABAP/4 command COMMIT WORK or the appropriate Native SQL command for the database system. Similarly, a database rollback is triggered either automatically or by the ABAP/4 command ROLLBACK WORK or the appropriate Native SQL command for the database system. A database commit is triggered automatically by o each screen change, and especially after the ABAP/4 commands CALL SCREEN, CALL DIALOG, CALL TRANSACTION, MESSAGE or o a Remote Function Call A database rollback is triggered automatically by o errors which occur at runtime or o the ABAP/4 command MESSAGE with the message type 'A' After each database commit or rollback, the database locks set in the LUW are released (see Database Locking). *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* Reports: T-Codes: SE38, SE24 (Class) Classical Report Events: Initialization:
This event keyword defines an event block whose event is triggered by the ABAP runtime environment during the flow of an executable program, directly after LOAD-OF-PROGRAM and before the selection screen processing of any existing standard selection screen. This gives you the one-time opportunity to initialize the input fields of the selection screen, including those defined in the logical database linked with the program. When an executable program defines a standard selection screen, it is called again by the ABAP runtime environment after execution, which triggers the INITIALIZATION event again. In this case, initializing parameters or selection criteria of the selection screen has no effect, because they are automatically supplied with the preceding user inputs from the selection screen during the selection screen event AT SELECTION-SCREEN OUTPUT. To explicitly initialize the selection screen for each call, you must use the event AT SELECTION-SCREEN OUTPUT.

At-Selection-Screen on: In the PAI event of the selection screen, the event At Selection-Screen on is triggered when the contents of each individual input field one passed from the selection screen to the ABAP program

At-Selection-Screen: When the user enter the values in the fields of selection-screen and click on execute button, this event gets triggered. Start-of-selection: In an executable program, the corresponding event is processed after the selection screen has been displayed and before data is read using a logical database.
The REPORT statement always executes a START-OF-SELECTION implicitly. Consequently all processing logic between the REPORT statement and the next event keyword is automatically processed in the START-OF-SELECTION event. Immediately afterwards, the system processes the statements that belong to an explicit START-OF-SELECTION block

Top-of-Page: TOP-OF-PAGE is a list processing event which is executed before the first data is output on a new page. End-of-page: The END-OF-PAGE event is executed whenever processing reaches that area when formatting a list page or if the RESERVE statement detects that there is insufficient space remaining on the current page. End-of-Selection: Event: After processing of all records in a LDB Get Node: - Syntax
GET node [LATE] [FIELDS f1 f2 ...].

Alternatives:
1. GET node [FIELDS f1 f2 ...]. 2. GET node LATE [FIELDS f1 f2 ...].

Addition:
... FIELDS f1 f2 ... Effect Use GET to handle two types of events after submitting executable programs: Get events and events at the end of a hierarchy level of a logical database. If during a GET event a list is written, previously an automatic line feed is created. Note The event blocks after GET are implemented internally as procedures. Declarative statements in GET event blocks create local data.

Alternative 1
GET node [FIELDS f1 f2 ...]. Effect This statement defines an event block whose result is triggered by the ABAP runtime environment after submitting an executable program, if the logical database to which the program is linked, provides data in the work area node. The node work area must be declared with the NODES statement (or TABLES). The data can be processed in the event block. GET node also controls the behavior of the logical database. The logical database reads all data from all nodes that are not defined for field selection using SELECTIONSCREEN FIELD SELECTION in the logical database and are located on the access path of the logical database superior to node. This is independent of whether GET event blocks have been defined for these nodes or not. However, only the data of those nodes can be accessed for which a work area was declared using the NODES (or TABLES) statement. If for nodes on the access path of the logical database superior to node, for which no GET event blocks are defined, a field selection is defined in the logical database, then all data is read only for those nodes, for which a NODES (or TABLES) statement exists. For nodes without a NODES (or TABLES) statment, only the key fields are read, because the logical database needs the key fields to build the access path. At the end of a hierarchy level of the logical database, all fields of the work area node are set to hexadecimal null.

Alternative 2
GET node LATE [FIELDS f1 f2 ...]. Effect This statement defines an event block whose result is triggered by the ABAP runtime environment after submitting an executable program, when the logical database has read in all records of node node. For node and FIELDS, the same applies as for the previous variant. Use this event block for final processing actions concerning the hierarchy level of the node.

Addition
... FIELDS f1 f2 ... Effect Use addition FIELDS to read only the specified fields f1 f2 ... and the key fields for node node from the logical database. As a prerequisite, the node must be defined for field selection in the logical database using SELECTIONSCREEN FIELD SELECTION. The content of the other fields of the work area is set to hexadecimal null.

&*&*&&**&*&*&*&*&* Example for Reporting Events


This example shows a typical report where the logical database F1S is assigned to its properties. REPORT demo_get. NODES: spfli, sflight, sbook. DATA: weight TYPE p LENGTH 8 DECIMALS 4, total_weight TYPE p LENGTH 8 DECIMALS 4. INITIALIZATION. carrid-sign = 'I'. carrid-option = 'EQ'. carrid-low = 'AA'. carrid-high = 'LH'. APPEND carrid TO carrid. START-OF-SELECTION. WRITE 'Luggage weight of flights'. GET spfli FIELDS carrid connid cityfrom cityto. SKIP. ULINE. WRITE: / 'Carrid:', spfli-carrid, 'Connid:', spfli-connid, / 'From: ', spfli-cityfrom, 'To: ', spfli-cityto. ULINE. GET sflight FIELDS fldate. SKIP. WRITE: / 'Date:', sflight-fldate. GET sbook FIELDS luggweight. weight = weight + sbook-luggweight. GET sflight LATE FIELDS carrid . WRITE: / 'Luggage weight =', weight. total_weight = total_weight + weight. weight = 0. END-OF-SELECTION. ULINE. WRITE: / 'Sum of luggage weights =', total_weight.

&*&*&*&*&*&&*&*&*&*&*&*&*&*&*&*&&*&*&*&*&*&*&*&*&*& Interactive Report Events:


AT LINE-SELECTION: - This event is processed whenever the user chooses a valid line in the list (i.e. a line generated by statements such as WRITE, ULINE, or SKIP) with the cursor and presses the function key which has the function PICKS in the interface definition. This should normally be the function key F2, because it has the same effect as double-clicking the mouse, or

clicking once in the case of a hotspot. The processing for the event AT LINE-SELECTION usually generates further list output (the details list) which completely covers the current list display. If you want the current list display to remain visible (to aid user orientation), you can do this with the key word WINDOW. In most cases, the information from the selected line is used to retrieve more comprehensive information by direct reading. When displaying the original list, you store the key terms needed for this in the HIDE area of the output line. Note You can choose a line and start new processing even in the details lists. The following system fields are useful for orientation purposes, since their values change with each interactive event executed. SY-LSIND: - Index of list created by current event (basic list = 0, 1st details list = 1 ...) SY-PFKEY: - Status of displayed list (SET PF-STATUS) SY-LISEL: - Contents of selected line SY-LILLI: - Absolute number of this line in the displayed list SY-LISTI: - Index of this list - usually SY-LSIND - 1 (READ LINE) SY-CUROW: - Last cursor position: Line in window SY-CUCOL: - Last cursor position: Column in window (GET CURSOR) SY-CPAGE: - 1st displayed page of displayed list SY-STARO: - 1st displayed line of this page of displayed list SY-STACO: - 1st displayed column of displayed list (SCROLL LIST) The system field SY-LSIND defines the line selection level (basic list: SY-LSIND = 0). System field for interactive reporting are also contained in the System Fields for Lists documentation. Example DATA TEXT(20). START-OF-SELECTION. PERFORM WRITE_AND_HIDE USING SPACE SPACE. AT LINE-SELECTION. CASE TEXT. WHEN 'List index'. PERFORM WRITE_AND_HIDE USING 'X' SPACE. WHEN 'User command'. PERFORM WRITE_AND_HIDE USING SPACE 'X'. WHEN OTHERS. SUBTRACT 2 FROM SY-LSIND. PERFORM WRITE_AND_HIDE USING SPACE SPACE. ENDCASE. CLEAR TEXT. FORM WRITE_AND_HIDE USING P_FLAG_LSIND P_FLAG_UCOMM. WRITE / 'SY-LSIND:'. PERFORM WRITE_WITH_COLOR USING SY-LSIND P_FLAG_LSIND. TEXT = 'List index'. HIDE TEXT. WRITE / 'SY-UCOMM:'. PERFORM WRITE_WITH_COLOR USING SY-UCOMM P_FLAG_UCOMM. TEXT = 'User command'. HIDE TEXT. IF SY-LSIND > 0. WRITE / 'PICK here to go back one list level'. ENDIF. ENDFORM. FORM WRITE_WITH_COLOR USING P_VALUE P_FLAG_POSITIVE. IF P_FLAG_POSITIVE = SPACE. WRITE P_VALUE COLOR COL_NORMAL. ELSE.

WRITE P_VALUE COLOR COL_POSITIVE. ENDIF. ENDFORM. Depending on whether you choose the line at SY-LSIND or SY-UCOMM, the next details list contains the corresponding value with the color "positive". If the line is chosen without HIDE information, the list level is reduced.

AT USER-COMMAND. Effect: - Event in interactive reporting This event is executed whenever the user presses a function key in the list or makes an entry in the command field. Some functions are executed directly by the system and thus cannot be processed by programs. These include:
PICK: - See variant AT LINE-SELECTION PFn: - See variant AT PFn /...: - System command %...: - System command PRI: - Print BACK: - Back RW: - Cancel P...: - Scroll function (e.g.: P+ , P- , PP+3, PS-- etc.)

Instead of these functions, you can use the SCROLL statement in programs. Since many of these system functions begin with "P", you should avoid using this letter to start your own function codes. Otherwise, the effect is as for AT LINESELECTION; also, the current function code is stored in the system field SY-UCOMM. Example DATA: NUMBER1 TYPE I VALUE 20, NUMBER2 TYPE I VALUE 5, RESULT TYPE I. START-OF-SELECTION. WRITE: / NUMBER1, '?', NUMBER2. AT USER-COMMAND. CASE SY-UCOMM. WHEN 'ADD'. RESULT = NUMBER1 + NUMBER2. WHEN 'SUBT'. RESULT = NUMBER1 - NUMBER2. WHEN 'MULT'. RESULT = NUMBER1 * NUMBER2. WHEN 'DIVI'. RESULT = NUMBER1 / NUMBER2. WHEN OTHERS. WRITE 'Unknown function code'. EXIT. ENDCASE. WRITE: / 'Result:', RESULT. After entry of a function code, the appropriate processing is performed under the event AT USER-COMMAND and the result is displayed in the details list.

AT PFn: Effect: - Event in interactive reporting Here, n stands for a numeric value between 0 and 99. This event is executed whenever the user presses a

function key that contains the function code PFn in the interface definition. The default status for lists contains some of these functions. Otherwise, the effect is as for the variant AT LINE-SELECTION. The cursor can be on any line.
Notes

1. To ensure that the chosen function is executed only for valid lines, you can check the current HIDE information. 2. This variant should be used only for test or prototyping purposes, since the default status is not normally used. Instead, you
should set a program-specific status with SET PF-STATUS. This should not contain any function codes beginning with "PF". Example DATA NUMBER LIKE SY-INDEX. START-OF-SELECTION. DO 9 TIMES. WRITE: / 'Row', (2) SY-INDEX. NUMBER = SY-INDEX. HIDE NUMBER. ENDDO. AT PF8. CHECK NOT NUMBER IS INITIAL. WRITE: / 'Cursor was in row', (2) NUMBER. CLEAR NUMBER.

HIDE: - The contents of f related to the current output line are stored. If this line is selected, f is filled automatically
with the stored value. The selection can be made using:

1. 2. 3. 4.

AT LINE-SELECTION AT PFx AT USER-COMMAND READ LINE

You do not have to output the field with WRITE in order to be able to store its value. The HIDE statement does not support structures that contain tables (deep structures). System fields that are particularly useful in interactive reporting are listed in the system fields for lists documentation. Note You cannot save lines or components of lines of an internal table that is addressed using a field symbol to the HIDE area. (Compare the ASSIGNING addition to the READ and LOOP statements). Assign the contents of the line or component to a global variable and save this instead. Exceptions Non-Catchable Exceptions Cause: The field is too long for HIDE. Runtime Error: HIDE_FIELD_TOO_LARGE Cause: Cannot apply HIDE to a table line or component of a table line. Runtime Error: HIDE_ILLEGAL_ITAB_SYMBOL Cause: HIDE is not possible in a local field. Runtime Error: HIDE_NO_LOCAL: HIDE Cause: HIDE is not possible on an empty page. Runtime Error: HIDE_ON_EMPTY_PAGE Control Break Events:

Total 4 events a. b. c. d. At first : Main heading At new : Sub heading At end : Sub total At last : Grand total

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* ALV Report ALV provides function modules to avoid coding and logic. Why we go for ALV No programming code for ----- sorting, totals, subtotals, filtering and user friendly. List: Grid: Hierarchical ALV: - Classes -------- list view control with list view control multiple records can be display. Clgui_alv_tree_simple Clgui_custom_container Blocked ALV: - Multiple reports can be designed with in single execute program Reuse_alv_block_list_initialize Reuse_alv_block_list_display Reuse_alv_block_list_append ALV Function Modules: a. b. c. d. e. f. g. h. i. REUSE_ALV_LIST_DISPLAY REUSE_ALV_GRID_DISPLAY REUSE_ALV_FIELDCATALOG_MERGE REUSE_ALV_EVENTS_GET REUSE_ALV_COMMENTARY_WRITE REUSE_ALV_BLOCK_LIST_INIT REUSE_ALV_BLOCK_LIST_APPEND REUSE_ALV_BLOCK_LIST_DISPLAY REUSE_ALV_HIERSEQ_LIST_DISPLAY.

ALV Events: Total 18 events 1. Slis_ev_caller_exit_at_start 2. Slis_ev_item_data_expand 3. Slis_reprep_sel_modify 4. Slis_ev_user_command 5. Slis_ev_top_of_page 6. Slis_ev_data_changed 7. Slis_ev_top_of_coverpage 8. Slis_ev_end_of_coverpage 9. Slis_ev_foreign_top_of_page 10. Slis_ev_foreign_end_of_page 11. Slis_ev_pf_status_set 12. Slis_ev_list_modify 13. Slis_ev_top_of_list 14. Slis_ev_end_of_page

15. 16. 17. 18.

Slis_ev_end_of_list Slis_ev_after_line_output Slis_ev_before_line_output Slis_ev_subtotal_text

ALV main events: Total main events 6 1. 2. 3. 4. 5. 6. Slis_print_alv Slis_T_listheader Slis_T_event Slis_T_sortinfo_alv Slis_T_layout_alv Slis_T_fieldcat_alv

ALV header and footer display: 1. SLIS_EV_TOP_OF_PAGE -------------- Header 2. SLIS_EV_END_OF_PAGE ------------- Footer ALV field catalog: It is catalog which merges two tables. REUSE_ALV_FIELDCATALOG_MERGE. ALV logo display: REUSE_ALV_COMMENTARY_WRITE. We can display data in GRID and we can insert LOGO. *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* Function Modules T-Codes: SE37 Function Group

Function Modules
Function modules are cross-program, reusable procedures that are organized into function groups, and whose functions are implemented between the statements FUNCTION and ENDFUNCTION. Function modules and their interfaces are created in the Function Builder.

FUNCTION Syntax
FUNCTION func. *"--------------------------------------------------------*" Local Interface: *" parameter_interface *"--------------------------------------------------------... ENDFUNCTION. Effect Between the statements FUNCTION and ENDFUNCTION, the functions of a function module func are implemented in a function group. The function module and its interface are defined in the Function Builder tool. In the source code of the function module, the function module interface defined in the Function Builder is automatically displayed as parameter_interface in comment lines underneath the FUNCTION statement. Within the function module, local data types and data objects can be declared. There is also access to the formal parameters of the function module and to the global data types and data objects of the function group. A function module is called using the statement CALL FUNCTION. Note

The logical expression IS SUPPLIED can be used in the function module to determine whether an actual parameter has been specified for a formal parameter. Example Implementation of a function module that reads data in a table-type formal parameter flight_tab under the condition of an elementary formal parameter id. The parameter interface defined in the Function Builder is visible as a comment. FUNCTION read_spfli_into_table. *"--------------------------------------------------------*" Local Interface: *" IMPORTING *" VALUE(ID) LIKE SPFLI-CARRID DEFAULT 'LH ' *" EXPORTING *" FLIGHT_TAB TYPE SPFLI_TAB *"--------------------------------------------------------SELECT * FROM spfli INTO TABLE flight_tab WHERE carrid = id. ENDFUNCTION.

Function Module Interfaces


The parameter interface of a function module is defined in the Function Builder. It includes the definition of interface parameters and the specification of exceptions that can be triggered by a function module. The Function Builder automatically generates comment lines below the FUNCTION statement in the source code of the function module, which represent the interface of the function module with the following syntax:

Syntax
... [IMPORTING parameters] [EXPORTING parameters] [CHANGING parameters] [TABLES table_parameters] [{RAISING|EXCEPTIONS} exc1 exc2 ...] The syntax and semantics of IMPORTING, EXPORTING, CHANGING, RAISING, and EXCEPTIONS mainly correspond to the definition of method interfaces with [CLASS-]METHODS. The additional option of defining table parameters using TABLES is obsolete.

Interface parameters
The interface parameters are defined on the relevant tab pages in the Function Builder. IMPORTING parameters are input parameters. When the function module is called, a suitable actual parameter must be specified for every non-optional input parameter. The content of the actual parameter is passed to the input parameter when the call is made. The content of an input parameter for which 'pass by reference' is defined cannot be changed in the function module. EXPORTING parameters are output parameters. When the function module is called, a suitable actual parameter can be specified for every output parameter. The content of an output parameter that is defined for 'pass by value' is transferred to the actual parameter if the function module is completed without errors. An output parameter that is defined for pass by reference is not initialized when the function module is called. CHANGING parameters are input and output parameters. When the function module is called, a suitable actual parameter must be specified for every non-optional input or output parameter. When the function module is called, the content of the actual parameter is passed to the input/output parameter, and when the function module is completed, the content of the input/output parameter is passed to the actual parameter. TABLES parameters are table parameters. Table parameters are obsolete CHANGING parameters that are typed as standard tables with a header line. If an internal table without a header line or a table body is passed as an actual parameter to a formal parameter of this type, an empty local header line is generated in the function module. If an internal table with a header line is used as an actual parameter, both the table body and the header line are passed to the function module. Pass by value is not possible in formal parameters defined using TABLES. Formal parameters defined with TABLES can be replaced by formal parameters defined with CHANGING. A local work area can be created for the internal table in the function module by using the addition LIKE LINE OF itab of the DATA statement.

Exceptions
The exception of a function module are defined on the Exceptions tab page in the Function Builder. Here you can select exception classes to define whether class-based exceptions are declared or non-class-based exception are defined. Class-based exceptions are represented in the above syntax by RAISING, and non-class-based exceptions are represented by EXCEPTIONS.

The addition RAISING is used to declare class-based exceptions that can be propagated from the function module to the caller. Exceptions in the categories CX_STATIC_CHECK and CX_DYNAMIC_CHECK must be explicitly declared, otherwise a propagation can lead to an interface violation. A violation of the interface leads to the treatable exception CX_SY_NO_HANDLER. Exceptions of the category CX_NO_CHECK are implicitly always declared. The declaration of exceptions of the category CX_STATIC_CHECK is statically checked in the syntax check. For exceptions of the category CX_DYNAMIC_CHECK, the check is not performed until runtime. In a function module in which class-based exceptions are declared with the RAISING addition, the statement CATCH SYSTEM-EXCEPTIONS cannot be used. Instead, the relevant treatable exceptions should be handled in a TRY control structure. The addition EXCEPTIONS is used to define a list of non-class-based exceptions that can be triggered in the function module using the statements RAISE or MESSAGE RAISING. Exceptions defined in this way - as with formal parameters - are bound to the function module and cannot be propagated. If an exception of this type is triggered in a function module, and no return value has been assigned to it with the homonymous addition EXCEPTIONS of the CALL FUNCTION statement when the call was made, this leads to a runtime error.

Note For new developments after release 6.10, SAP recommends that you work with class-based exceptions that are independent of the function module.

Properties of interface parameters


When an interface parameter p1, p2... is defined in the Function Builder, properties are determined for the parameter, which are reflected in the syntax of parameters and table_parameters.

Syntax of parameters ... { VALUE(p1) | p1 } {TYPE [REF TO] type} | {LIKE struc-comp} | {STRUCTURE struc} [OPTIONAL|{DEFAULT def1}] { VALUE(p2) | p2 } {TYPE [REF TO] type} | {LIKE struc-comp} | {STRUCTURE struc} [OPTIONAL|{DEFAULT def2}] ...

Syntax of table_parameters
... p1 {TYPE itab_type} | {STRUCTURE struc} [OPTIONAL] p2 {TYPE itab_type} | {STRUCTURE struc} [OPTIONAL] ... The syntax and semantics of VALUE, TYPE, OPTIONAL, and DEFAULT are mainly the same as in the definition of method interfaces with [CLASS-]METHODS. The option of typing interface parameters with LIKE or STRUCTURE is obsolete.

Type of parameter passing


There are two ways in which parameters can be passed: pass by reference and pass by value. Pass by value is selected in the Function Builder by selecting pass by value, and in the above syntax, differs from pass by reference by the specification of VALUE( ). In pass by reference, the formal parameter points directly to the actual parameter, so that changes to the formal parameters have an immediate effect on the actual parameter. In pass by value, when the function module is called, the formal parameter is created as a copy of the actual parameter (in IMPORTING and CHANGING parameters), or initial (in EXPORTING parameters) in the stack. In CHANGING and EXPORTING parameters, the formal parameter is copied to the actual parameter when returning from the function module. Note the following for the different types of parameter: In IMPORTING, EXPORTING, and CHANGING parameters, pass by reference and pass by value are possible, in TABLES parameters, only pass by reference is possible. IMPORTING parameters passed by reference cannot be overwritten in the function module. EXPORTING parameters passed by reference are not initialized when the function module is called. For this reason, no read access to these parameters should be permitted before the first write access.

Typing of interface parameters


The parameter interface of a function module is public across the system. Interface parameters can therefore only be typed with reference to data types from the ABAP Dictionary or from the public visible section of global classes. In the Function Builder, interface parameters can be typed by the selection of either TYPE, TYPE REF TO or LIKE. While typing with TYPE is also displayed as TYPE in the above syntax, typing with LIKE is not only represented by LIKE, but also by STRUCTURE. Typing with TYPE [REF TO] is the recommended typing for interface parameters of function modules. It takes place when TYPE or TYPE REF TO is selected in the Function Builder. For IMPORTING, EXPORTING, and CHANGING parameters, any predefined ABAP type (complete or generic), or any data type from the ABAP

Dictionary or from the public visibility section of a global class can be specified after TYPE. After TYPE REF TO, the generic data type data, a non-generic data type, or an object type can be specified and the interface parameter is typed as a reference variable. In TABLES parameters, only one table type itab_type can be specified from the ABAP Dictionary of table type 'standard table' with a flat line type. The typing check is performed in the same way as for subprograms and methods. Typing with LIKE is obsolete. It takes place if an elementary component of a flat structure (or database table) struc-comp from the ABAP Dictionary is specified after LIKE in the Function Builder. The typing check is the same as for the specification of components after TYPE, with the exception that the fractional portion is not taken into account for packed numbers. Typing with STRUCTURE is obsolete. It takes place if a flat structure structure (or database table) struc from the ABAP Dictionary is specified after LIKE in the Function Builder. This structure is then forced on the formal parameter (casting), and it is possible to access the individual components. For a formal parameter typed with STRUCTURE, a connected actual parameter must be a structure. In non- Unicode programs, the actual parameter must be suitably aligned (in pass by reference) and its length must exactly match the length of the forced structure struc, with the exception of table parameters. For table parameters, the length of the actual parameter must be at least the length of the structure. In Unicode programs, the Unicode fragment view of a structured actual parameter must match that of struc. For an elementary actual parameter this must be character-type and flat.

Note If a component of a global program structure in the function group of a function module has exactly the same identity (structure name struc and component comp) as the component of a structure in the ABAP Dictionary specified after LIKE, LIKE refers to the component of the structure defined in the function group. This leads to a warning in a syntax check. In contrast, TYPE always refers to types in the ABAP Dictionary.

Optional parameters
IMPORTING, CHANGING, and TABLES parameters can be made optional by the selection of optional in the Function Builder. EXPORTING parameters are always optional. IMPORTING and CHANGING parameters can be assigned a replacement parameter (default value in the Function Builder). In the above syntax, this is expressed using the additions OPTIONAL or DEFAULT. For an optional parameter, no actual parameter must be entered when the function module is called. While a formal parameter with the addition OPTIONAL is then initialized according to its type, a formal parameter with the addition DEFAULT assumes the value and type of the replacement parameter def1 def2 .... If no actual parameter is specified for a generically typed formal parameter with the addition OPTIONAL when it is called, the type of the formal parameter is completed according to fixed rules. Note Within a function module, the logical expression IS SUPPLIED can be used to check if an optional formal parameter was assigned an actual parameter when it was called.

Global Parameters
The formal parameters of a function module can be made known globally in the Function Builder through the path Edit Interfaces Globalize parameters. Then the field Global is selected in the properties of the function module. The formal parameters of a global interface have the following properties: All parameters that are fully typed and are defined for being passed as a value are treated as if global data objects of the same name were declared in the Top Include. This means they are visible in the same function group and, when the function module is exited, they retain their value. When the function module is called, all the parameters of a global interface are initialized or they are assigned their default value. All the other parameters are handled in such a way as if global data objects with the same name were declared in the Top Include (for table parameters, these are two in each case: one for the table body and one for the header row). However, these can only be used during execution of the function module. In other words, they are visible in the entire function group, but they can only be accessed during execution of the function module. If one such parameter is accessed outside of function module execution, a runtime error GETWA_NOT_ASSIGNED is triggered since these parameters are implemented internally through field symbols to which a data object is assigned only during execution of the function module. In the function group, no global data objects with the same name must be created like a global parameter. If several function modules of a function group have global interfaces, parameters with the same name must be defined identically. Note The use of global interface parameters is obsolete and, in new function modules, interfaces should generally not be globalized.

Subroutines
Subroutines are mainly used for the local modularization of an ABAP program, but can also be called externally. Their functions are implemented between the FORM and ENDFORM statement.

FORM

Syntax
FORM subr [TABLES table_parameters] [USING parameters] [CHANGING parameters] [RAISING exc1 exc2 ... ]. ... ENDFORM.

Extras:
1. ... TABLES table_parameters 2. ... USING parameters 3. ... CHANGING parameters 4. ... RAISING exc1 exc2 ... Effect The FORM statement defines a subr subroutine and its interface. The naming conventions apply to the subr name. The subroutine's functionality is implemented between the statements FORM and ENDFORM. The additions define the formal parameters of the subroutine and the propagation of the class-based exceptions to the caller is declared. Local data types and data objects can be declared within the subroutine. Furthermore, the formal parameters of the subroutine and the global data types and data objects of the frame program can be accessed. You call a subroutine using the PERFORM statement.

Addition 1
... TABLES table_parameters Effect TABLES is used to declare table parameters table_parameters. Table parameters are obsolete formal parameters that are typed as internal standard tables with header lines. The addition TABLES can be listed only before USING or CHANGING. If an internal table without header line or a table body is transferred as an actual parameter to this type of formal parameter, then an empty local header line is generated in the subroutine. If an internal table with header line is used as the actual parameter, then both the table body and the header line are passed to the subroutine. For formal parameters defined with TABLES, no pass by value is possible. Notes Formal parameters defined with TABLES can be replaced by formal parameters defined with USING or CHANGING. A local work area can also be created in the subroutine using the addition LIKE LINE OF itab of statement DATA. Specifying TABLES after USING or CHANGING creates a formal parameter called "TABLES".

Addition 2
... USING parameters

Addition 3
... CHANGING parameters Effect These additions define formal parameters parameters. Formal parameters can be used in the subroutine as data objects at all operand positions that match their typing and their changeability defined by USING or CHANGING. When you define the formal parameters parameter, you have the option of defining either pass by reference or pass by value. The effect of this definition for formal parameters defined with USING and CHANGING is as follows: Pass by reference for USING parameters For the formal parameters p1 p2 ..., no local data object is created in the subroutine. Instead, when it is called, a reference is passed to the specified actual parameter. A change to the formal parameter in the subroutine also changes the value of the actual parameter. Pass by reference for CHANGING parameters The formal parameters p1 p2 ... are handled exactly like those parameters defined for pass by reference using USING. Pass by value for USING parameters For each formal parameter p1 p2 ..., a local object with the same data type as the corresponding actual

parameter is created in the subroutine and filled with its values. A change to the formal parameter in the subroutine does not change the value of the actual parameter. The actual parameter also retains its original value even after the subroutine has ended. Pass by value for CHANGING parameters For each formal parameter p1 p2 ..., a local data object with the same data type as the corresponding actual parameter is created in the subroutine and filled with its values. A change to the formal parameter in the subroutine does not directly change the value of the actual parameter. If the subroutine is ended using ENDFORM, RETURN, CHECK or EXIT however, the content of the formal parameter is assigned to the actual parameter. If the subroutine is ended by a message or an exception, the actual parameter remains unchanged.

Notes Formal parameters defined for pass by reference with USING should not be changed in the subroutine. In this case, CHANGING can be used instead. The addition CHANGING should be used for the formal parameter whose value is changed in the subroutine. The sequence of USING and CHANGING is not arbitrary. Specifying USING after CHANGING creates a formal parameter called "USING". Example In a subroutine, the formal parameter ptab can be used at an operand position that expects an index table, since it is typed accordingly. The formal parameter wa is completely generic and the system does not check until runtime whether it is suitable for the line type of the internal table. FORM fill_table USING wa TYPE any CHANGING ptab TYPE INDEX TABLE. APPEND wa TO ptab. ENDFORM.

Addition 4
... RAISING exc1 exc2 ... Effect With the addition RAISING, class-based exceptions exc1 exc2 ... can be passed, which are triggered in or propagated to the subroutine by the ABAP runtime environment or using the statement RAISE EXCEPTION, but are not handled in a TRY block. Subclasses of CX_STATIC_CHECK and CX_DYNAMIC_CHECK can be implicitly declared. Subclasses of CX_NO_CHECK are implicitly declared. For exc1 exc2 ..., all exception classes that are visible at this point that are subclasses of CX_STATIC_CHECK CX_DYNAMIC_CHECK can be specified here. The exception classes must be specified in ascending order with respect to their inheritance hierarchy. If an exception for this superclass occurs, which can be neither handled nor passed on, this leads to either a syntax error or an exception that must be handled by the caller CX_SY_NO_HANDLER. Notes Exceptions that are based on the subclasses of CX_STATIC_CHECK and CX_DYNAMIC_CHECK must be handled either in the subroutine or declared explicitly using the RAISING addition. For CX_STATIC_CHECK this is checked during the syntax check; for CX_DYNAMIC_CHECK the check is not performed until runtime. In a subroutine that propagates class-based exceptions with the RAISING addition, the CATCH SYSTEMEXCEPTIONS statement cannot be used. Instead, the corresponding treatable exceptions must be caught in a TRY block.

FORM - parameters

Syntax
... { VALUE(p1) | p1 } [typing|{STRUCTURE struc}] { VALUE(p2) | p2 } [typing|{STRUCTUREstruc}] ... . Effect: Definition of formal parameters p1 p2 ... for subroutines. The addition typing types a formal parameter p1 p2 ....The syntax of typing is described in Typing. Typing a formal parameter has the effect that when an actual parameter is passed, its type is checked against the typing. In addition, the typing determines at which operand positions the formal parameter can be used in the subroutine. Use VALUE to determine how to pass values for a formal parameter p1 p2 .... Without VALUE, values are passed by reference. Obsolete Typing

A formal parameter p1 p2 ... can be specified with the addition STRUCTURE instead of typing, where struc must be a program-local structure (data object, no data type) or a flat structure from the ABAP Dictionary. This stamps the structure on the formal parameter (Casting) and in the subroutine, the individual components can be accessed. When passing an actual parameter to a formal parameter typed with STRUCTURE, the only check executed in nonUnicode programs is whether the length of the actual parameter is equal to or greater than the length of the structure. In Unicode programs, there is a difference between structured and elementary actual parameters. With a structured actual parameter, its Unicode fragment view must match that of struc. With an elementary actual parameter, it must be character-type and flat. Notes Formal parameters typed with STRUCTURE can usually be replaced by formal parameters typed with TYPE or LIKE. If you really want to do a casting, you should use generic formal parameters and assign them to field symbols using the statement ASSIGN and the addition CASTING. Without an explicit typing, a formal parameter is typed with the fully generic type any.

FORM - table_parameters

Syntax
... t1 [{TYPE itab_type}|{LIKE itab}|{STRUCTURE struc}] t2 [{TYPE itab_type}|{LIKE itab}|{STRUCTURE struc}] ... . Effect Definition of table parameters t1 t2 ... for subroutines. After the additions TYPE and LIKE, you can specify a table type table_type or an internal table itab of type standard table. The additions TYPE and LIKE type the row type of the formal parameter with the row type of the specified internal table. The other obsolete addition STRUCTURE stamps the flat structure struc onto the row type. Note Defining table parameters is obsolete and can be replaced by general formal parameters defined with USING and CHANGING.

*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* Script T-Codes: SE71 - Script, NACE Output types, SE73 Bar codes SE74 Script format conversion SE76 Script form translation SE78 Logo Upload SE38 ABAP Editor, SE75 Standard text module script SO10 Standard text

Form Names: MEDRUCK, RVORDER01, RVINVOICE01, F110_PRENUM_CHCK Windows Types 1. Main window 2. Variable window 3. Constant window

a. Main window: Main window is used to print the output of line item of document b. Variable window: The content of variable window is regenerated on every page c. Constant window: The content of constant window is generated once in the beginning and it is printed on
every page. Script Function Modules a. b. c. d. e. open_form start_form write_form end_form close_form

1. Subroutines in Script. What is the Syntax? Calling ABAP subroutines. Yes we can write subroutines in SAP Script. Perform Form name in Program program name. Using&parameter& Changing&Parameter& Perform ZSSS in program ZSSS1 Using&matnr& Changing&matnr1& Endperform. Here using is input values. Changing is output values. 2. How to debug script? Goto se71. enter the form name from the menu bar ----- go to utilities ----- select Activate Debugger. 3. Which table is used to find the form name, program name? TNAPR --------- goto se11. enter TNAPR ---ctrl+shift12 ------ enter the output type. Then it gives the form Name, program name. 4. What is the purpose of TEXT ELEMENT? It is used to establish the link between driver program(se38) and layout set. 5. What is the parameters passed in Open_form, Write_form? In open_form: - Form name, page number, language. In write_form: - Window(Main Window), element. 6. Difference between Open_form Start_form Open_form: - activates the sap script processor, calls the form. Start_form: - calls the form 7. What is the purpose of Protect End Protect? In this we can determine that the paragraph can not be separated by page break. All the lines in the command are printed together on a single page. Protect End protect command is used to print complete text on same page. 8. Address End address: - To format the address. Symbols: Total 4 symbols. 1. System symbols, 2. Standard symbols, 3. Program symbols, 4. Text symbols.

1. 2. 3. 4.

System symbols: come from global system variables. Standard symbols: It is global available & maintained in the SAP Script table TTDTG. Program symbols: Values of the program symbol come from the table of programs. Text symbols: We define text symbols locally in our documents.

Script to Smartforms migrate types: 2 types 1. fb_migrate_module 2. goto ------ smartforms _______ --- Utilities --- Migrate option ---------- source form script ________ ----- enter. Script logo to store in the table STXH SP01 Spool request SP02 Output control

The page numbers display: In SP02 (output control) ----- spool request ---- goto ----- display requests ----- Settings ------ we can get pop up window, in that ------ display mode Graphical raw hexadecimal ------ display area From page _____ to ____ The last _______ pages ------ save settings. Script Client dependent and print program client independent Smartforms client independent and print program client dependent *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Smartforms T-Code: SMARTFORMS, SE38 ABAP Editor, SE72 Smartforms styles, Windows types: 1. 2. 3. 4. Main window Secondary window Copies window Final window

Function Module: SSF_FUNCTION_MODULE_NAME. Form interface: - Form Interface is where you declare what must be passed in and out of the smartforms (in form the print program to the smartform and out from the smartform to the print program Global definition: - Global definition is where you declare data to be used within the smarform on a global scope, i.e., anything you declare here can be used in any other node in the form. Difference between Table and Template Table: is a node used to print a table with dynamic layout and are used for displaying records in a tabular formats. Template: is a node used to print a table with fixed locations. Field list on/off Field name Import interface, export interface, Global data, System fields System fields SFSY Page Page number / Number of pages Form pages Total number of Form pages Job pages Total number of pages of print job Copy count Copy counter (1 = original, 2 = 1st copy) Copy count 0 - Copy counter (0 = original, 1 = 1st copy) Date Current date of application server Time Current time of application server SUBRC Return value of ABAP statement USERNAME username Page name page name + variant

Window name XSF XDF XDF2

window name + variant XSF Output active / inactive SAP Smart forms : XDF Output active - SAP Smart forms : XDF Output active

Script to Smartforms Difference Smartforms Multiple page formats are possible Main window is not necessary Routines can be written Generates a Function Module when activated i.e., only 2 modules call function module and pass the values. Performance increases, processing time is reduced and code itself in the layout print program is also reduced Script Multiple page formats are not possible Main window is compulsory Routines can not be written Function Module is not generated when activated The function modules open_form, Close_form, Write_form.

*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* BDC (Batch Data Communication) T-Codes: SHDB, SM35 BDC Types: 3 1. Session Method 2. Call Transaction Method 3. Direct Input Method Synchronous: The next transaction is called only when the update of previous transaction is completed. Asynchronous: The current transaction does not wait until the previous transaction completes. Local Updates: If the data is updated locally then the update of the database will not be processed in a separate process. It will process in calling program. How to error handling in CALL Transaction: We can handle incorrect transaction by using update mode S and checking the return code from CALL Transaction Using. The messages can be saved in an internal table <BDCMSGCOLL> that has the structure. How to error handling in SESSION Method: Errors will be automatically generated. Function Modules in Session Method BDC Standard Programs 1. 2. 3. 4. RMDATIND MM RCSBI010 BOM RCRAPDX2 Work Centre RCPTRA01 Routing

Before loop we can call the function modules and background session 1. BDC_Open_Group

2. 3. 4. 5.

BDC_Insert_Group BDC_Close_Group WS_UPLOAD WS_DOWNLOAD

a. bdc_open_group: exporting = client = sy-mandt group = IBM user = sy-uname before endloop we can call bdc_insert_group b. bdc_insert exporting = t code = MM01 tables dynprotab = bdc data after the endloop we can call bdc_close_group c. bdc_close_group no changes any things. We get the Queue id and to specify the data and time we go for bdc_open_group. Session Method Asynchronous Processing Transfers data from multiple transactions Synchronous database update A bath input processing log is generated for each session Time delay Call Transaction Synchronous Processing Transfers data from an individual transactions Updates the database both synchronous & asynchronously. No bath input processing log Data loading is immediately process

After BDC program (se38) we can execute the program we can get selection screen. In that 2 types of execute process. 1. Generate Session 2. Call Transaction 1. Generate Session: Session name _____ User _______ Keep Session _______ Lock date ________ No data indicator ___/___ Small log ____ Data set ________ 2. Call Transaction Procession Mode ___N___, A- Display all screens, E Display errors, N Background process, P Background processing, debugging possible Update mode ____L____, L Local, S Synchronous, A - Asynchronous Error Session ____ User ____SAPUSER____ Keep session _____ Lock date ______

BDCMSGCOLL: - contains T code -- Transaction code. Dyname -- Module pool program name Dynum -- Screen no Msg type -- message type Msg id -- message id Msg nr -- message number Fld name -- field name Msgspra -- language id of a msg Msgv1 -- variable part of a msg *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* LSMW (Legacy System Migration Workbench) T-Codes: LSMW Total Steps 14 or 21 steps 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Maintain object attributes Maintain source structures Maintain source fields Maintain structure relations Maintain field mapping and conversion rules Maintain fixed values, translations, user-defined routines Specify files Assign files Read data Display the read data Convert the data Display the converted data Create batch input session Run bath input session

I. In Maintain object attributes we can get 4 options

a. Attributes: - ---------- object


b. Object type and input method: 1. Standard batch / direct input Object -------Method -----Program name ---Program type ----2. Batch input recording Recording ------------3. Business object method (BAPI) Business object ----------Method -----------------Message type ---------Basic type --------------4. IDoc (Intermediate Document) Message type ----------Basic type --------------Enhancement -------------Allow structure Assignment for EDICDC 400

II. Maintain fixed values, translations, user-defined routines Ans: - We can not write in sub routines in 6 step of maintain fixed values, translations, user-defined routines. Components of LSMW: a. b. c. d. Batch Input Recording BAPI ALE

*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ SM37 Simple Job Selection Job name & User name execute Job status Scheduled, Released, Ready, Active, Finished, Canceled Job start condition from date & time to date & time Job step ABAP Program name --&*&*&*&*&*&*&**&*&*&*& SM36 Define Background job General data job name, job class-c, status, exec target, Job start ---Job frequency --Job steps ---&*&*&*&*&*&*&*&

Debugging Background Scheduled Jobs in SAP ABAPers some times find themselves struggling to get the background scheduled jobs in debugging mode specially in the case where the jobs have different Job Status.

Following steps helps you to debug background scheduled jobs with different statuses: 1. Background jobs with Scheduled or Released Status: After scheduling the program to run in background, select the job in SM37 and type jdbg in the command area. It will take you to debugging mode for the corresponding job.

2. Background jobs with Active Status: Goto SM50 to get the list of processes. Identify the process related to the program. Goto menu option Program/Mode->Program->Debugging.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ Screen Programming (Dialog Programming) Work bench tools: 1. Menu Painter SE41 2. Screen Painter SE51 3. ABAP Editor SE38

Events
PBO Process Before Output PAI Process After Input POH Process on Help-Request ----- F1 help POV Process on Value-Request ----- F4 help 1. A: 2. A: What are Screen types? Normal screen, Modal Dialog box, Subscreen, Selection screen. What is the flow logic? Screen flow logic consists of events PBO and PAI of each screen. It controls user interaction with the screen. Its a separate language..

3. What are screen tables? A: Table control, Step loop. 4. How do you do validations in transactions? A: In the transaction event PAI (Process After Input). *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* Version Management Functions: 1. ABAP/4 workbench & the organizer provide a version management for all the objects in the system. 2. With version management user can compare previous version & current version 3. Locate our object through the change request no of workbench organizer. Menu -- Utilities -- display version , --- it displays what has been modified and who did it. T-code 09 -- workbench organizer. Type of versions: -- Active or partially active / revised. -- temporary versions -- historical versions. Version management functions: Canceling changes -- reset revised version to active version Storing changes -- active version will be temporarily stored in version Switching changes -- switch between active & revised versions. *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*

LDB (Logical Database) T.Code SE36 In HR module are used in Logical Database. LDB (Logical Database):

Logical Database is a program that contains the data access logic.


Improving performance and LDB is part of the application server. The data structure in a logical database is hierarchical. Many tables in the R/3 system are linked to each other using foreign key relationship Some of these depend from tree like hierarchical structure. Logical database read data from database tables that are part of these structures.

Every logical database is 3 components. 1. Structure 2. Selections 3. Database program LDB Advantages Performance increase LDB Disadvantages LDB uses nested SELECT statements The number of tables increases, the performance of the report comes down, hence the usage is less.

*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ SAP Quires SAP Quires: SAP Quires are used to generate reports using some data source. Infoset: Infoset is a subset on data source. SAP Quires Procedure: a. Define user group b. Define and generate infoset c. Assign users & infosets to user group d. Assign user group to infoset e. Define Query f. Execute Query : : : : : : SQ03 SQ02 SQ03 SQ02 SQ01 SQ01

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= AUTHORITY-CHECK AUTHORITY-CHECK OBJECT object ID name1 FIELD f1 ID name2 FIELD f2 ... ID name10 FIELD f10.

Explanation of IDs: Object: - Field which contains the name of the object for which the authorization is to be checked. name1 ... : - Fields which contain the names of the name10: - authorization fields defined in the object. f1 ...: - Fields which contain the values for which the f10: - authorization is to be checked. AUTHORITY-CHECK: - Checks for one object whether the user has an authorization that contains all values of f. You must specify all authorizations for an object and a also a value for each ID (or DUMMY). The system checks the values for the IDs by AND-ing them together, i.e. all values must be part of an authorization assigned to the user. If a user has several authorizations for an object, the values are OR-ed together. This means that if the CHECK finds all the specified values in one authorization, the user can proceed. Only if none of the authorizations for a user contains all the required values is the user rejected. If the return code value in SY-SUBRC is 0, the user has the required authorization and may continue. The return code value changes according to the different error scenarios. The return code values have the following meaning: 4: - User has no authorization in the SAP System for such an action. If necessary, change the user master record. 8: - Too many parameters (fields, values). Maximum allowed is 10. 12: - Specified object not maintained in the user master record. 16: - No profile entered in the user master record. 24: - The field names of the check call do not match those of an authorization. Either the authorization or the call is incorrect. 28: - Incorrect structure for user master record. 32: - Incorrect structure for user master record. 36: - Incorrect structure for user master record. If the return code value is 8 or 24, inform the person responsible for the program. If the return code value is 4, 12, 16 or 24, consult your system administrator if you think you should have the relevant authorization. In the case of errors 28 to 36, contact SAP because authorizations have probably been destroyed. Individual authorizations are assigned to users in their respective user profiles, i.e. they are grouped together in profiles which are stored in the user master record. Note Instead of ID name FIELD f, you can also write ID name DUMMY. This means that no check is performed for the field concerned. The check can only be performed on CHAR fields. All other field types result in 'unauthorized'. Example Check whether the user is authorized for a particular plant. In this case, the following authorization object applies: Table OBJ: Definition of authorization object M_EINF_WRK ACTVT WERKS Here, M_EINF_WRK is the object name, whilst ACTVT and WERKS are authorization fields. For example, a user with the authorizations M_EINF_WRK_BERECH1 ACTVT 01-03 WERKS 0001-0003 . can display and change plants within the Purchasing and Materials Management areas. Such a user would thus pass the checks

AUTHORITY-CHECK OBJECT 'M_EINF_WRK' ID 'WERKS' FIELD '0002' ID 'ACTVT' FIELD '02'. AUTHORITY-CHECK OBJECT 'M_EINF_WRK' ID 'WERKS' DUMMY ID 'ACTVT' FIELD '01': but would fail the check AUTHORITY-CHECK OBJECT 'M_EINF_WRK' ID 'WERKS' FIELD '0005' ID 'ACTVT' FIELD '04'. To suppress unnecessary authorization checks or to carry out checks before the user has entered all the values, use DUMMY - as in this example. You can confirm the authorization later with another AUTHORITY-CHECK. *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ SET PARAMETER SET PARAMETER ID pid FIELD f.

Effect: - Writes the contents of the field f to the global user-specific SAP memory and the local transaction-specific
SAP memory under the ID pid. Any existing values under the same ID are overwritten. Parameter IDs can be up to 20 characters long. They cannot consist entirely of spaces. The SAP system description contains an overview of parameter IDs. You can also produce a list using the ABAP Workbench. Notes

The global, user-specific SAP memory is available to a user for the duration of a single terminal session. Values written to it are retained even when the user exits a program. Do not use SAP memory as a temporary storage area, since parallel sessions belonging to the same user all use the same memory area. Only store data of the types C, N, D, and T, as well as structures that consist of these types, in the SAP Memory. You can create new parameter IDs using the ABAP Workbench. Parameter IDs may have a namespace prefix. DATA REPID like sy-repid VALUE 'RSPFPAR'. SET PARAMETER ID 'RID' FIELD REPID.

Example

Sets the program name so it can be passed to other programs. Exceptions Non-Catchable Exceptions

Cause: Key consists entirely of spaces Runtime Error: SET_PARAMETER_ID_SPACE Cause: Key longer than 20 characters Runtime Error: SET_PARAMETER_ID_TOO_LONG Cause: Value exceeds 250 characters Runtime Error: SET_PARAMETER_VALUE_TOO_LONG

GET PARAMETER GET PARAMETER ID pid FIELD f.

Effect: - First, the value stored under the key pid is transferred from the local SAP memory into the field f. If this key
is not available in the local SAP memory, the value stored under the same key pid is transferred from the global user-related SAP memory to the field f. A parameter ID can have up to 20 characters. You can find an overview of the keys (parameters) used in the SAP system description or the appropriate function in the ABAP Workbench. The Return Code is set as follows: - SY-SUBRC = 0: A value was read from SAP memory. SY-SUBRC = 4: No value was found in SAP memory under the specified key. Notes

The global user-related SAP memory is available to each user for the entire duration of a terminal session. For this reason, set values are retained when you leave a program. You should not use SAP memory for temporary storage because a user's parallel sessions use the same global memory.

Example Read the program name from SAP memory: DATA: REPID LIKE SY-REPID. GET PARAMETER ID 'RID' FIELD REPID. *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+

Lock object name


A lock object is a virtual link of several SAP tables which is used to synchronize simultaneous access by two users to the same set of data ( SAP lock concept). Locks are requested and released in the programming of online transactions by calling certain function modules which are automatically generated from the definition of the lock objects. These lock objects must be explicitly created in the ABAP Dictionary. To set locks, you must perform the following steps: 1. You must define a lock object in the ABAP Dictionary. The name of the lock object should begin with E. 2. The function modules for requesting and releasing locks which are created automatically when the lock object is activated must be linked to the programming of the relevant online transactions.

Using the SAP Locking Facility Definition of an SAP lock


The description of an SAP lock to a table is made via the lock condition and the lock mode. The lock condition is a logical condition for the lines of the table to be locked. It describes the area of the table which the lock is to protect from competitive access. To avoid the administration of the lock becoming complicated, the lock condition can not be formulated as freely as the WHERE clauses: only fully qualified key fields related by AND may appear in the condition. Via the lock mode you define which operations on the table are to be protected by the lock. The lock modes available are: Read lock (shared lock) protects read access to an object. The read lock allows other transactions read access but not write access to the locked area of the table. Write lock (exclusive lock) protects write access to an object. The write lock allows other transactions neither read nor write access to the locked area of the table. Enhanced write lock (exclusive lock without cumulation) works like a write lock except that the enhanced write lock also protects from further accesses from the same transaction. In order to be able to define SAP locks for a table, you must first create a lock object for the table via Development->Dictionary. If the data for an application object is distributed among several database tables, it is often necessary to be able to lock these tables simultaneously. It is therefore possible to include several tables in a lock object, althought they must be related via appropriate foreign key relationships . The tables involved in a lock object are also known as its base tables. The following requirements must be satisfied by the foreign keys which are used for the definition of the join condition of a lock object: 1. The set of base tables forms a tree structure, the nodes of which are the base tables and the links of which are the corresponding join conditions. The root of this tree structure is the primary table of the lock object. 2. The foreign key relationship belonging to a link in the tree structure described in 1 always has the father of the link as check table and the son of the link as foreign key table. 3. A foreign key field of one of the foreign key relationships which is in a base table of the lock object is alway also the key field in this table. 4. No field from a base table is checked against more than one field via the foreign key relationships in question. (That is, it neither appears twice as foreign key field in a relationship, nor is checked against different fields in two separate relationships (as foreign key field).

5. If a base table contains a foreign key field from one of the foreign key relationships, it is in the subtree which has the check table of this foreign key relationship as root. Requirements 2-5 are always met if the son is always a key enhancement of the father in the tree described in 1. Constant and partial keys and foreign keys which are "adapted" for non-base tables are also unproblematic. However if one of the foreign keys involved is "adapted" to another base table, requirements 2-5 must be checked.

Requesting an SAP lock


When a lock object obj is activated, two function modules (see CALL FUNCTION) with the names ENQUEUE_obj and DEQUEUE_obj are generated. These lock modules are used to explicitly request or release SAP locks in an ABAP program. The SAP lock concept thus assumes a cooperative behavior by all the programs involved. This means that access from programs that do not call the specified modules are not protected. The lock conditions and lock modes for the requested locks are defined by the IMPORT parameters of the lock modules. The lock conditions are defined by the lock parameters of the lock object. If the lock object has only one base table, each primary key field of the table corresponds to exactly one lock parameter. Apart from this, a lock parameter corresponds to a group of primary key fields that are identified by the join conditions. For each lock parameter par , the lock modules have two IMPORT parameters with the names par and X_par. The lock condition is defined by these parameters. If a parameter par is not defined or if it is defined with the initial value, this means that the corresponding key fields should be locked generically. If you really want to lock the key field with the initial value, you must also define the parameter X_par with the value 'X'. Definition of the lock parameters of a lock object: The lock parameters of a lock object are used when the relevant lock modules are called to allocate the values to the lock arguments of the lock object. For each parameter field of the lock object (at most) one lock parameter can be defined. The name of the lock parameter generally corresponds to the name of the relevant parameter field. The name can however be freely chosen as long as it adheres to the name conventions for lock parameters. For each parameter <Par> of the lock objects the relevant lock modules receive IMPORT parameters <Par> and X_<Par>. The parameter <Par> possesses the relevant parameter field as reference field. If the IMPORT parameter <Par> is filled with a value in a call, all the lock fields equivalent to the parameter field in the corresponding lock arguments are filled with that value. If the parameter remains initial, generic locking takes place on these lock fields. If however the flag X_<Par> is set, initial <Par> also means that the corresponding lock field should be locked at initial value. To define the lock modes, the lock modules have an IMPORT parameter MODE_tab for each base table tab, with which the lock mode for this table can be defined. A default value must already be set for this parameter in the definition of the lock object. You cannot set an SAP lock by finding all the lines of the table which satisfy the lock condition and marking them as locked. Rather, the lock condition and lock mode for a table are entered in a special lock table.

Collision of SAP locks


Before a requested SAP lock is entered in the lock table, a check is made on whether it collides with a lock already entered in the lock table. Two locks on the same table collide if their lock conditions overlap and their lock modes are incompatible. The overlapping of two lock conditions on one table is a purely logical attribute. It occurs if a row of the table which meets both conditions could exist. It is therefore irrelevant for the overlap whether or not such a row really exists in the table. The following rules apply for the compatability of locks: An enhanced write lock is incompatible with all other locks, a write lock is incompatible with all locks requested by other transactions, and a read lock is compatible with all other read locks. If locks are requested with the help of a lock object that has several base tables, all locks requested are regarded as colliding as soon as a collision is recognized for just one of the base tables involved.

Behaviour in a collision
An SAP lock that collides with an existing lock cannot be granted and is therefore not entered in the lock table. With the help of the IMPORT parameter _WAIT, you can determine how the ENQUEUE module should behave if the lock it requests collides with an existing lock. If this parameter has the value ' ', the exception FOREIGN_LOCK is triggered. The system field SY-MSGV1 is supplied with the user set by the the colliding lock. If the parameter has the value 'X', the lock request is repeated at set intervals until either the lock can be granted or an internal system time limit is exceeded. In the second case the exception FOREIGN_LOCK is also triggered.

Duration of an SAP lock


At the end of a transaction, this automatically releases all the SAP locks it holds. Note, however, that if an update routine is called by the transaction, locks can be transferred from the ordering transaction to the update routine. In the same way, these locks are automatically released at the end of the update routine. Via the IMPORT parameter _SCOPE of the ENQUEUE module, you can determine whether a lock should be transferred to the update routine if one is called. If _SCOPE has the value '1', the lock remains with the the ordering transaction. If _SCOPE has the value '2', the lock can pass to the update routine. Finally, if the parameter has the value '3', two locks of the same kind will be generated, one of which passes to an update routine when one is called. By calling the DEQUEUE module, a transaction can explicitly release a lock which it holds. The lock parameter and lock mode must be supplied with the same value as for calling the ENQUEUE module. If the parameter _SCOPE has the value '1', only one lock is released which cannot pass to an update routine. If the parameter has the value '2', only one lock is released which can pass to the update program. Finally, if the parameter has the value '3', both locks can be released. Note however that a transaction can release neither a lock which has already been transferred to the update program, nor a lock which is held by another transaction. Via the IMPORT parameter _SYNCHRON you can control whether the release of the lock should be synchronous or asynchronous. If this parameter has the value 'X', the module waits until the lock has really been removed from the lock table. If the parameter has the value ' ', a requst for deletion of the lock from the lock table is sent to the application server which manages the lock table, and then the execution of the program is immediately continued.

Monitoring of SAP locks


The transaction Display and delete locks monitors the SAP locks.

SDLC 1. 2. 3. 4. 5. 6. Feasibility Study Requirement Analysis Business Blue Print Coding Testing Maintain

&*&*&*&*&**&*&*&*&**&*&*&*&*&***&*&*&*&*&*&*&***&*&*&*&**&*&**&*&*&*&*&*&*&*&

Indexes
You can search a table for data records that satisfy certain search criteria faster using an index. An index can be considered a copy of a database table that has been reduced to certain fields. This copy is always in sorted form. Sorting provides faster access to the data records of the table, for example using a binary search. The index also contains a pointer to the corresponding record of the actual table so that the fields not contained in the index can also be read. The primary index is distinguished from the secondary indexes of a table. The primary index contains the key fields of the table and a pointer to the non-key fields of the table. The primary index is created automatically when the table is created in the database. Table SCOUNTER in the flight model contains the assignment of the carrier counters to airports. The primary index on this table therefore consists of the key fields of the table and a pointer to the original data records.

You can also create further indexes on a table in the ABAP Dictionary. These are called secondary indexes. This is necessary if the table is frequently accessed in a way that does not take advantage of the sorting of the primary index for the access. Different indexes on the same table are distinguished with a three-place index identifier. All the counters of carriers at a certain airport are often searched for flight bookings. The airport ID is used to search for counters for such an access. Sorting the primary index is of no use in speeding up this access. Since table SCOUNTER has a large number of entries, a secondary index on the field AIRPORT (ID of the airport) must be created to support access using the airport ID.

The optimizer of the database system decides whether an index should be used for a concrete table access (see How to Check if an Index is Used?). This means that an index might only result in a gain in performance for certain database systems. You can therefore define the database systems on which an index should be created when you define the index in the ABAP Dictionary (see Creating Secondary Indexes.) All the indexes existing in the ABAP Dictionary for a table are normally created in the database when the table is created if this was not excluded in the index definition for this database system. If the index fields have key function, that is if they already uniquely identify each record of the table, an index can be defined as a unique index.

What to Keep in Mind for Secondary Indexes


How well an existing index supports data selection from a table largely depends on whether the data selected with the index represents the data that will ultimately be selected. This can best be shown using an example. An index is defined on fields FIELD1, FIELD2, FIELD3 and FIELD4 of table BSPTAB in this order. This table is accessed with the SELECT statement: SELECT * FROM BSPTAB WHERE FIELD1 = X1 AND FIELD2 = X2 AND FIELD4= X4. Since FIELD3 is not specified more exactly, only the index sorting up to FIELD2 is of any use. If the database system accesses the data using this index, it will quickly find all the records for which FIELD1 = X1 and FIELD2 = X2. You then have to select all the records for which FIELD4 = X4 from this set. The order of the fields in the index is very important for the accessing speed. The first fields should be those which have constant values for a large number of selections. During selection, an index is only of use up to the first unspecified field. Only those fields that significantly restrict the set of results in a selection make sense for an index. The following selection is frequently made on address file ADRTAB: SELECT * FROM ADRTAB WHERE TITEL = Prof. AND NAME = X AND VORNAME = Y.

The field TITLE would rarely restrict the records specified with NAME and FIRSTNAME in an index on NAME, FIRSTNAME and TITLE, since there are probably not many people with the same name and different titles. This would not make much sense in this index. An index on field TITLE alone would make sense for example if all professors are frequently selected. Additional indexes can also place a load on the system since they must be adjusted each time the table contents change. Each additional index therefore slows down the insertion of records in the table. For this reason, tables in which entries are very frequently written generally should only have a few indexes. The database system sometimes does not use a suitable index for a selection, even if there is one. The index used depends on the optimizer used for the database system. You should therefore check if the index you created is also used for the selection (see How to Check if an Index is Used).). Creating an additional index could also have side effects on the performance. This is because an index that was used successfully for selection might not be used any longer by the optimizer if the optimizer estimates (sometimes incorrectly) that the newly created index is more selective. The indexes on a table should therefore be as disjunct as possible, that is they should contain as few fields in common as possible. If two indexes on a table have a large number of common fields, this could make it more difficult for the optimizer to choose the most selective index.

&*&*&*&*&**&*&*&*&**&*&*&*&*&***&*&*&*&*&*&*&***&*&*&*&**&*&**&*&*&*&*&*&*&*& **&*&***&*&*&*&*&

Creating a secondary index


There are two types of indexes: Primary index and secondary index. Primary index is automatically created using the primary keys defined.

Secondary index could be created as per the user requirement. This article discusses about creating a secondary index. Go to transaction SE11.

For our demo purpose, we have considered the table ZAUTHOR.

To know if there are any secondary indexes available, click on Goto Indexes

Following popup appears:

From the above screenshot, it is evident that there are no secondary indexes already created. Click on Create Create Index

Enter the name of the index.

Fill in the details Short description and the fields in the index.

Save and activate. Now you can observe the index created above in the list now:

Maximum number of secondary indexes we can have are 9. How to make SELECT statement to make use of any particular secondary index? click

here

Secondary Indexes
Consider the following example: SELECT * FROM SPFLI %_HINTS ORACLE 'INDEX("SPFLI" "SPFLI~001")' ....... ENDSELECT. In the above example, 001 is the secondary index of the table SPFLI. It's a well-known fact that the efficient way of retrieving data from the database tables is by using secondary indexes. Many database vendors provide the optimizer hints for the same. From SAP v4.5, optimizer hints can be provided by the %_HINTS parameter. This is dependent on the database systems that support optimizer hints. The point to be noted here is these optimizer hints are not standardized by the SQL standards. Each database vendor is free to provide the optimizer hints. Now to know which index to use for our table: 1. Go to SE11 and there specify the table name 2. Now from the menu, goto --> indexes 3. select the required index. Now suppose that the identifier 001 represents a non-unique secondary index comprising of the columns CITYFROM and CITYTO. The index name should be defined as: <tablename>~<Index Identifier> like SPFLI~001 in the above example. The sequence of fields in the WHERE condition is of no relevance in using this optimizers index. If you specify hints incorrectly, ABAPTM ignores them but doesn't return a syntax error or runtime error. The code was written in R/3 4.6C. Code Consider the following example: REPORT Suresh_test. TABLES: spfli. DATA : t_spfli LIKE spfli OCCURS 0 WITH HEADER LINE. SELECT * FROM spfli INTO TABLE t_spfli

%_HINTS ORACLE 'INDEX("SPFLI" "SPFLI~001")'. LOOP AT t_spfli. WRITE :/ t_spfli. ENDLOOP.

&*&*&*&*&**&*&*&*&**&*&*&*&*&***&*&*&*&*&*&*&***&*&*&*&**&*&**&*&*&*&*&*&*&*&

BAPI
Return Parameters (Error Handling) - Use A BAPI should be able to record and classify all possible errors that may occur. You have to create a parameter named Return for every BAPI. This parameter returns exception messages or success messages to the calling program. BAPIs themselves must not trigger any messages (such as MESSAGE xnnn) in the coding. In particular they must not generate terminations or display dialog boxes. Instead, all messages must be intercepted internally and reported back to the calling program in the Return parameter. Otherwise the BAPI will not be processed correctly and control may not be given back to the calling program. All error messages or indeed any message that may be returned by the BAPI, must be defined in message table (Tools ABAP Workbench Development Programming environment Messages) and described in the documentation for the return parameter. This also applies to the most important or most likely error messages generated by other programs that can be indirectly passed via the BAPI to the application program. You must not use exceptions in BAPI interfaces. When a termination message (message type A) is triggered, a database rollback is executed in the standard programming model, that is, all tasks performed since the last COMMIT WORK are canceled. When you program BAPIs, we recommend that you also execute a database rollback in the return parameter for termination messages. You must describe this process in the documentation for the Return parameter. For messages of type E (error), the calling program performs the error handling. Application developers are provided with two service BAPIs to diagnose and process error messages from BAPI calls: BapiService.MessageGetDetail() displays the short and long texts of BAPI error messages. BapiService.ApplicationLogGetDetail(), with which information in application logs can be displayed.

Features
The export parameter Return can be implemented as follows: As a structure, whereby it must be defined in the function module as an export parameter, as well as in the method in the BOR. As a table, whereby it must be defined in the function module as a table parameter, as well as in the method in the BOR as an export parameter.

Before filling the Return parameter you should either initialize the structure with CLEAR or the table with REFRESH and CLEAR. If the return parameter is not set or is set to an initial value this means that no error has occurred. The Return parameter may be based on the following reference structures: BAPIRET2 - You must use this reference structure when developing new BAPIS. BAPIRET1, BAPIRETURN - These reference structures are still partly used in old BAPIs.

Both structures must be filled in the logon language.

Reference Structure BAPIRET2


The structure BAPIRET2 is filled via the function module BALW_BAPIRETURN_GET2. It contains the following fields: Field TYPE Type CHAR 1 Description S = success message E = error message W = warning message I = information message A = termination message (abort) Message ID The structure BAPIRET2 takes into account the name space extension for the message class as of Release 4.0. If you want messages to be compatible with earlier R/3 Releases, use the message classes before Release 4.0. Message number Full message text from the message table. All variables (in fields Message_V1 to Message_V4) have been replaced with text. Application log number This is empty if no log used. Note that for type A error messages (abort), an application log is not created, as in this case there is no COMMIT WORK. LOG_MSG_NO MESSAGE_V1 MESSAGE_V2 MESSAGE_V3 MESSAGE_V4 PARAMETER ROW FIELD SYSTEM NUMC 6 CHAR 50 Current message number in application log Fields for the variable texts of the message specified in fields ID and NUMBER.

ID

CHAR 20

NUMBER MESSAGE LOG_NO

NUMC 3 CHAR 220 CHAR 20

CHAR 32 INT 4 CHAR 30 CHAR 10

Parameter containing the invalid value. Line number of the data record containing the invalid value Field containing the invalid value. System (logical system) in which the message was generated.

Reference Structure BAPIRET1


This structure is filled via the function module BALW_BAPIRETURN_GET1. It consists of the fields in the BAPIRET2 structure excluding the fields PARAMETER, ROW and FIELD.

Return Parameters in the ALE Distributed Environment


Once the function module responsible for converting the IDoc into the appropriate BAPI in the receiving system has been called, IDoc status records are written which log the messages reported by the return parameter. If the value of the field Type is A (abort) in at least one of the return parameter entries, status 51 (error, application document has not been posted) is written to all the IDoc status records and a ROLLBACK executed. If the value of the field Type is E (error) in at least one of the return parameter entries, status 51 (error, application document has not been posted) is written to all the IDoc status records and a COMMIT WORK is executed anyway. Otherwise status 53 (application document posted) is written and a COMMIT WORK is executed.

Application Log and Application-Specific Error Tables


If the information provided in the Return parameter is not sufficient, you can log errors with the application log. The logging should be done by the BAPI itself so that function modules called directly by this BAPI do not have to be modified. The fields LOG_NO and LOG_MSG_NO of the Return parameter return the application log numbers and their messages. As of Release 4.6A you can already maintain the log number when you create the application log. Several instances of an application object can be maintained at the same time and can be updated together. The update task can be also used for application logs, that is, log entries are and no longer directly written to the database, they are written via the update task. If you plan to use application logs in your BAPI, you must write these using the update task. For further information on application logs see Applications. Creating Applications Logs in the document BC - Extended Function Library

If this still does not provide enough information, the calling application can define its own additional error tables. There are no set guidelines for these additional tables. The Return parameter in your BAPI could give details of the messages in the error tables, for example, if there are error messages (type E) in the table. The calling program then has immediate control over the contents of the error table and does not have to first search for error messages. The use of the application log and error tables enable error messages to be returned if they cannot be adequately returned in the return parameter. Note that for type A error messages (abort), an application log is not created, as in this case there is no COMMIT WORK. &*&*&*&**&*&*&*&*&***&*&*&**&*&*&*&*&*&*&*&*&**&*&*&*&*&*&*&*&*&***&*&*&*&*&**&
error handling in bapi A BAPI should be able to record and classify all possible errors that may occur a function Module BAPI_MESSAGE_GETDETAIL is used to Handle the Error Messages.. You have to create a parameter named Return for every BAPI. This parameter returns exception messages or success messages to the calling program. BAPIs themselves must not trigger any messages (such as MESSAGE xnnn) in the coding. In particular they must not generate terminations or display dialog boxes. Instead, all messages must be intercepted internally and reported back to the calling program in the Return parameter. Otherwise the BAPI will not be processed correctly and control may not be given back to the calling program. All error messages or indeed any message that may be returned by the BAPI, must be defined in message table (Tools ABAP Workbench Development Programming environment Messages) and described in the documentation for the return parameter. This also applies to the most important or most likely error messages generated by other programs that can be indirectly passed via the BAPI to the application program. You must not use exceptions in BAPI interfaces. When a termination message (message type A) is triggered, a database rollback is executed in the standard programming model, that is, all tasks performed since the last COMMIT WORK are canceled. When you program BAPIs, we recommend that you also execute a database rollback in the return parameter for termination messages. You must describe this process in the documentation for the Return parameter. For messages of type E (error), the calling program performs the error handling. Application developers are provided with two service BAPIs to diagnose and process error messages from BAPI calls: BapiService.MessageGetDetail() displays the short and long texts of BAPI error messages. BapiService.ApplicationLogGetDetail(), with which information in application logs can be displayed. Features The export parameter Return can be implemented as follows: As a structure, whereby it must be defined in the function module as an export parameter, as well as in the method in the BOR. As a table, whereby it must be defined in the function module as a table parameter, as well as in the method in the BOR as an export parameter. Before filling the Return parameter you should either initialize the structure with CLEAR or the table with REFRESH and CLEAR. If the return parameter is not set or is set to an initial value this means that no error has occurred.

The Return parameter may be based on the following reference structures: BAPIRET2 You must use this reference structure when developing new BAPIS. BAPIRET1, BAPIRETURN These reference structures are still partly used in old BAPIs. Both structures must be filled in the logon language.

&*&*&*&**&*&*&*&*&***&*&*&**&*&*&*&*&*&*&*&*&**&*&*&*&*&*&*&*&*&***&*&*&*&*&**&