SAP ABAP

SAP – System Application Products Abbreviations

1. ERP – Enterprise Resource Planning2. SAP – System Application Products3. ABAP – Advance Business Application Programming4. MM – Material Management5. SD – Sales & Distribution6. FI – Finance, CO – Controlling7. FI-CA – Finance Casting8. BASIS – BASIS9. BW – Business Information Warehouse10. BI – Business I11. CRM – Customer Relationship Management12. XI – Exchange Infra Structure13. NT – Net Ware14. QM – Quality Management15. PP – Production Plant16. WMS – Ware House Management System17. HR – Human Resources18. PM – Plant Maintenance19. PS – Project System20. ECM – Enterprise Compensation Management21. IM – Inventory Management22. PLM – Project Life cycle Management 23. GTS – Global Trade Service24. SCM – Supply Change Management25. EP – Enterprise Portal26. BPP – Business Process Produce27. SEM – Strategic Enterprise Management 28. APO - Advanced Planner Optimizer29. SRM - Supplier Relationship Management30. IS-Retail – Industrial Service – Retail31. ISU – Industrial Service Utilities32. DM – Delivery Management33.

*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*

ABAP – Advance Business Application Programming - Abbreviations

ABAP – Advance Business Application ProgrammingALV – Abap List ViewerBDC – Batch Data Communication LSMW – Legacy System Migration WorkbenchALE – Application Link EnablingIDoc – Intermediate DocumentBADI – Business Add InsBAPI – Business Application Programming InterfaceRFC – Remote Function CallEDI – Electronic Data InterchangeITS – Internet Transaction ServerBOR – Business Object RepositoryJCO – Java Connectivity ObjectCGI – Common Gate way Internet

NWAS – Net wear Web Application Server BSP – Business Server PageOOPs – Object Oriented Programs SBWP – SAP Business Work PlaceSDLC – Software Development Life CycleOLTP – On Line Transaction ProcessingOLAP – On Line Analysis and ProcessingAWB – ABAP Work BenchODC – Offshore Development CentreASAP – Accelerate System Application Products

*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*Abbreviations

HTTP – Hyper Text Transfer ProtocolCSP – Complementary Software ProgramLAN – Local Area NetworkWAN – World Area NetworkWWW – World Wide WebCPU – Central Process UnitHTML – Hyper Text Mark up Language

*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*T – Codes (Transaction Codes)

SE11 – ABAP DictionarySE12 – ABAP DictionarySE16 – ABAP DictionarySE18 – Badi Builder Initial Screen for DefinitionSE19 – Badi Builder: Initial Screen for ImplementationsSE20 - Enhancements Initial screenSE24 – ABAP Class BuilderSE37 – Function ModuleSE38 – ABAP EditorSMARTFORMS – SmartformsLSMW – LSMWSHDB – BDC (Batch Data Communication) or SM35 -- batch input -- recordingME21 – Purchase Order CreateME22 – Purchase Order ChangeME23 – Purchase Order DisplayXK01 – Vendor CreateXK02 – Vendor ChangeXK03 – Vendor DisplayXD01 – Customer CreateXD02 – Customer ChangeXD03 – Customer DisplayVA01 – Sales Order CreateVA02 – Sales Order ChangeVA03 – Sales Order DisplaySE80 – Object Navigator (Development Package)SE09 – Transport OrganizerSE36 – Logical DatabaseSQ01 – Define Query & Execute QuerySQ02 – Define and Generate Infosets & Assign User Group to InfosetsSQ03 – Define User Group & Assign Users and Infosets to User GroupSE84 – ABAP Development WorkbenchSE41 – Menu Painter

SE51 – Screen Painter (Transaction)SE71 – Script formsST02 – Buffering ChangesST03 – System PerformanceST04 – Database Performance Analysis – Oracle Database overview ST05 – SQL TraceSE30 – Run time AnalysisSLIN – Syntax ErrorST22 – Dump Analysis

VF03 – Billing Document (Export Invoice)CS01 – Create a Material of BOMCA01 – Create RoutingSE91 – Create a MessagesSE93 – Maintain Transaction (Create T.Code)AL21 – To Analyze the Performance of ABAPSE72 – Smart forms StyleSE73 – Bar codesSE74 – Script format ConversionSE75 – Standard text module scriptSE76 – Script form TranslationSE78 – GraphicsSO10 – Standard Text

SM01 – Lock/Unlock Transaction CodeSM12 – Lock EntriesSM21 – System LogSM35 – Batch Input (BDC), Session overviewSM36 – Define Background jobSM37 – Simple Job Selection SM50 – Process overviewSM51 – SAP Servers

SM66 – Global work process overview RFC callsSALE – Logical system NamesSM59 – Maintain RFC destinations

SPRO – Using for Function ConsultantSP01 – Spool RequestSP02 – Spool Request Output ControllerBD64 – Maintain Distribution ModelBD82 – Generate partner ProfilesSA38 – ABAP Execute Program directSE03 – Transport Organizer ToolsSCC4 – Display View Clients OverviewDB13 – DBA Planning Calendar for Oracle Database ERP: MaintainDB12 – Backup logs: Overview for Database ERPOSS Notes ---- Online Service Systems for SAP.com web site.

Project Implementation LevelsTotal 5 Phases.

Phase – 1 --- Development Customization (Project Preparation) Phase – 2 --- Business Requirement of Process and Analysis (Blue Print)Phase – 3 --- RealizationPhase – 4 --- TestingPhase – 5 --- Go Live

*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*Support Levels

Level – 1: ----- Call Center / Help Desk.Level – 2: ----- Team Ticket level issuesLevel – 3: ----- Level – 4: ----- 24/7

*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*

Level – 1: End User / ClientLevel – 2: Function ConsultantsLevel – 3: Techno Function ConsultantsLevel – 4: Technical Consultants

*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*System Fields

It’s a structure -- SYST

Sy-datum - DateSy-uzeit - TimeSy-uname - User NameSy-index - Maintains the loop indexSy-tabix - Row index – Internal table Current line indexSy-subrc - Process statusSy-linno - List creation, current lineSy-lsind - List processing, details list indexSy-ucomm - Screen function code triggered by PAISy-ldbpg - 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

--------- Billing4. 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 F – Function Group I – Include Program J – Interface PoolK – Class Pool M – Module Pool S – Subroutine Pool

*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*

Tables

Master Data Tables

KNA1 – Customer Master (General Data) LFA1 – Vendor Master (General Data)MARA – General Material Data SKB1 – G/L Account Master (Company Code)T001W – Plants/Branches 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 DataBSIK – Accounting: Secondary Index for Vendors BSIS – Accounting: Secondary Index for G/L Accounts

MM – (Material Management)EKKO – Purchase Document Header EKPO – Purchase Document ItemKNMT – Customer-Material Info Record Data Table MAKT – Material DescriptionMARC – Plant Data for Material MAST – Material to BOM LintMSEG – Document Segment – Material MKPF – Header – Material Document

SD – (Sales & Distribution) KONV – Conditions (Transaction Data) LIKP – SD Document: Delivery Header DataLIPS – SD document: Delivery: Item data VBAK – Sales Document: Header DataVBAP – Sales Document: Item Data VBBE – Sales Requirements: Individual RecordsVBEH – Schedule line history VBEP – Sales Document: Schedule Line DataVBFA – Sales Document Flow VBPA – Sales Document: PartnerVBRK – Billing Document: Header Data VBRP – Billing Document: Item DataVBUK – Sales Document: Header Status and Administrative DataVBUP –Sales Document: Item Status VEKP – Handling Unit - Header Table

KNA1 – Customer Master LFA1 – Vendor MasterKNB1 – Customer Master (Company Code) KNVP – Customer Master Partner FunctionsKNVV – Customer Master Sales Data

Tables & Fields

LFA1 – LIFNR, KNA1 – KUNNR, MARA – MATNR, SKB1 – BUKRST001W – WERKS, T001 – BUKRS,BSAD – BUKRS, KUNNR BSAS – BUKRS, BELNRBSEG – BUKRS, BSES – BUKRS, BELNRBSIK – BUKRS, LIFNR BSIS – BUKRS, BELNREKKO – EBELN, BUKRS, LIFNR EKPO – EBELN, EBELP, MATNR, BUKRS, WERKS, MATKLKNMT – VKORG, KUNNR, MATNR MAKT – MATNR, SPRAS, MAKTXMARC – MATNR, WERKS MAST – MATNR, WERKSMSEG – MBLNR, MATNR, WERKS, MKPF – MBLNR,KONV – KNUMV LIKP – VBELN, VKORGLIPS – VBELN, MATNR VBAK – VBELN, VBAP – VBELN, MATNR, VBBE – VBELN, MATNR, WERKSVBEH – VBELN, POSNR VBEP – VBELN, POSNR, MEINSVBFA – VBELN, POSNR, MEINS, MATNR VBPA – VBELN, POSNR, KUNNR, LIFNRVBRK – VBELN, VKORG, BELNR VBRP – VBELN, POSNR, MEINSVBUK – VBELN VBUP – VBELN, POSNRVEKP – VENUM KNA1 – KUNNRLFA1 – LIFNR KNB1 – KUNNR, BUKRSKNVP – KUNNR, VKORG, LIFNR KNVV – KUNNR, VKORG

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*

Data Dictionary

T-Codes:

SE11 – Data Dictionary display, change, createSE12 – Data Dictionary changeSE16 – 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 viewTables ----- fields from more than one tableJoins ------ inner join usedAccess ---- one table (read/write), one table (read)Usage ---- reports, to fill a table this view is used.

2. Projection ViewTables ------ fields from one tableJoins ------ no joins usedAccess ------ one table (read/write)Usage ----- reports

3. Maintenance view ----- (V_T438M_V)Tables ------ fields from more than one tableJoins ------ no joins usedAccess ---- one table (read/write/delete/change)Usage ----- SM30

4. Help viewTables ---- one tableJoins ---- no joins usedAccess -- 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 Tablesb. APPL1 – Transaction data, Transparent tablesc. APPL2 – Organization and Customizingd. USER – Customer data classe. USER1 – Customer data classf. USER6 – Customer data class, generated by SAPDBA

Size Category

0 - 0 to 7201 - 720 to 2,8002 - 2,800 to 11,0003 - 11,000 to 46,0004 - 46,000 to 180,0005 - 180,000 to 370,0006 - 370,000 to 14,000,000

Delivery Class

1. A – Application table (Master & Transaction data)2. C – Customizing table, maintenance only by cust, not SAP import3. L – Table for storing temporary data, delivery empty4. G – Customizing table, protected against SAP upload, only INS all5. E – Control table, SAP and Customer have separate key areas6. S – System table, maintenance only by SAP, change = modification7. 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 Allowed3. 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 ELock 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. Transparent tableb. Pool tablec. Cluster tabled. Internal table

1. Transparent table: Exists with the same structure both in dictionary as well as in database exactly with the same data and fields. Both open Sql and Native Sql can be used.

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. LUW’s 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 SELECTION-SCREEN 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 SELECTION-SCREEN 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 LINE-SELECTION; 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".

ExampleDATA 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. AT LINE-SELECTION 2. AT PFx 3. AT USER-COMMAND 4. 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. At first : Main headingb. At new : Sub headingc. At end : Sub totald. At last : Grand total

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*

ALV Report

ALV provides function modules to avoid coding and logic.

Why we go for ALVNo 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_simpleClgui_custom_container

Blocked ALV: - Multiple reports can be designed with in single execute programReuse_alv_block_list_initializeReuse_alv_block_list_displayReuse_alv_block_list_append

ALV Function Modules:

a. REUSE_ALV_LIST_DISPLAYb. REUSE_ALV_GRID_DISPLAYc. REUSE_ALV_FIELDCATALOG_MERGEd. REUSE_ALV_EVENTS_GETe. REUSE_ALV_COMMENTARY_WRITEf. REUSE_ALV_BLOCK_LIST_INITg. REUSE_ALV_BLOCK_LIST_APPENDh. REUSE_ALV_BLOCK_LIST_DISPLAYi. REUSE_ALV_HIERSEQ_LIST_DISPLAY.

ALV Events: Total 18 events

1. Slis_ev_caller_exit_at_start2. Slis_ev_item_data_expand3. Slis_reprep_sel_modify4. Slis_ev_user_command5. Slis_ev_top_of_page6. Slis_ev_data_changed7. Slis_ev_top_of_coverpage8. Slis_ev_end_of_coverpage9. Slis_ev_foreign_top_of_page10. Slis_ev_foreign_end_of_page11. Slis_ev_pf_status_set12. Slis_ev_list_modify13. Slis_ev_top_of_list14. Slis_ev_end_of_page15. Slis_ev_end_of_list16. Slis_ev_after_line_output17. Slis_ev_before_line_output18. Slis_ev_subtotal_text

ALV main events: Total main events 6

1. Slis_print_alv2. Slis_T_listheader3. Slis_T_event4. Slis_T_sortinfo_alv5. Slis_T_layout_alv6. Slis_T_fieldcat_alv

ALV header and footer display:

1. SLIS_EV_TOP_OF_PAGE -------------- Header2. 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 SYSTEM-EXCEPTIONS 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 non- Unicode 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, SE38 – ABAP Editor, SE73 – Bar codes SE74 – Script format conversion SE75 – Standard text module scriptSE76 – Script form translation SE78 – Logo Upload SO10 – Standard text

Form Names: MEDRUCK, RVORDER01, RVINVOICE01, F110_PRENUM_CHCK

Windows Types

1. Main window2. Variable window3. Constant window

a. Main window: Main window is used to print the output of line item of documentb. Variable window: The content of variable window is regenerated on every pagec. Constant window: The content of constant window is generated once in the beginning and it is printed on

every page.

Script Function Modules

a. open_formb. start_formc. write_formd. end_forme. 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 ZSSS1Using&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_formOpen_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. System symbols: come from global system variables.2. Standard symbols: It is global available & maintained in the SAP Script table TTDTG.3. Program symbols: Values of the program symbol come from the table of programs.4. Text symbols: We define text symbols locally in our documents.

Script to Smartforms migrate types: 2 types

1. fb_migrate_module2. goto ------ smartforms _______ --- Utilities --- Migrate option

---------- source form script ________ ----- enter.

Script logo to store in the table – STXH

SP01 – Spool requestSP02 – 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 independentSmartforms client independent and print program client dependent

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

Smartforms

T-Code: SMARTFORMS, SE38 – ABAP Editor, SE72 – Smartforms styles,

Windows types:

1. Main window2. Secondary window3. Copies window4. 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 pagesForm pages – Total number of Form pagesJob pages – Total number of pages of print jobCopy count – Copy counter (1 = original, 2 = 1st copy……)Copy count 0 - Copy counter (0 = original, 1 = 1st copy……)Date – Current date of application serverTime – Current time of application serverSUBRC – Return value of ABAP statementUSERNAME – usernamePage name – page name + variantWindow name – window name + variantXSF – XSF Output active / inactiveXDF – SAP Smart forms : XDF Output activeXDF2 - SAP Smart forms : XDF Output active

Script to Smartforms Difference

Smartforms ScriptMultiple page formats are possible Multiple page formats are not possibleMain window is not necessary Main window is compulsoryRoutines can be written Routines can not be writtenGenerates a Function Module when activated i.e., only 2 modules call function module and pass the values.

Function Module is not generated when activated

Performance increases, processing time is reduced and code itself in the layout print

The function modules open_form, Close_form, Write_form.

program is also reduced

*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*

BDC (Batch Data Communication)

T-Codes: SHDB, SM35

BDC Types: 3

1. Session Method2. Call Transaction Method3. 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. RMDATIND – MM2. RCSBI010 – BOM3. RCRAPDX2 – Work Centre4. RCPTRA01 – Routing

Before loop we can call the function modules and background session

1. BDC_Open_Group2. BDC_Insert_Group3. BDC_Close_Group4. WS_UPLOAD5. WS_DOWNLOAD

a. bdc_open_group:exporting =client = sy-mandtgroup = ‘IBM’user = sy-uname

before endloop we can call bdc_insert_group

b. bdc_insertexporting = t code = MM01

tables dynprotab = bdc data

after the endloop we can call bdc_close_group

c. bdc_close_groupno changes any things.

We get the Queue id and to specify the data and time we go for bdc_open_group.

Session Method Call TransactionAsynchronous Processing Synchronous ProcessingTransfers data from multiple transactions Transfers data from an individual transactionsSynchronous database update Updates the database both synchronous & asynchronously.A bath input processing log is generated for each session No bath input processing logTime delay 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 Session2. Call Transaction

1. Generate Session: Session name _____User _______Keep Session _______Lock date ________No data indicator ___/___Small log ____Data set ________

2. Call TransactionProcession Mode ___N___, A- Display all screens, E – Display errors, N – Background process,

P – Background processing, debugging possibleUpdate mode ____L____, L – Local, S – Synchronous, A - AsynchronousError Session ____

User ____SAPUSER____Keep session _____Lock date ______

BDCMSGCOLL: - containsT code -- Transaction code.Dyname -- Module pool program nameDynum -- Screen noMsg type -- message typeMsg id -- message idMsg nr -- message numberFld name -- field nameMsgspra -- language id of a msgMsgv1 -- variable part of a msg

*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*

LSMW (Legacy System Migration Workbench)

T-Codes: LSMW

Total Steps 14 or 21 steps

1. Maintain object attributes2. Maintain source structures3. Maintain source fields4. Maintain structure relations5. Maintain field mapping and conversion rules6. Maintain fixed values, translations, user-defined routines7. Specify files8. Assign files9. Read data10. Display the read data11. Convert the data12. Display the converted data13. Create batch input session14. Run bath input session

I. In Maintain object attributes we can get 4 options

a. Attributes: - ---------- objectb. Object type and input method: -

1. Standard batch / direct inputObject --------Method ------Program name ----Program type -----

2. Batch input recordingRecording -------------

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 routinesAns: - We can not write in sub routines in 6 step of maintain fixed values, translations, user-defined routines.

Components of LSMW:

a. Batch Inputb. Recordingc. BAPId. 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 & timeJob 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 – SE412. Screen Painter – SE513. ABAP Editor – SE38

Events

PBO – Process Before OutputPAI – Process After InputPOH – Process on Help-Request ----- F1 helpPOV – Process on Value-Request ----- F4 help

1. What are Screen types?A: Normal screen, Modal Dialog box, Subscreen, Selection screen.2. What is the flow logic?A: Screen flow logic consists of events PBO and PAI of each screen. It controls user interaction with the screen.

It’s 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 version3. 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 versionStoring changes -- active version will be temporarily stored in versionSwitching 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. Structure2. Selections3. Database program

LDB Advantages LDB DisadvantagesPerformance increase 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 : SQ03b. Define and generate infoset : SQ02c. Assign users & infosets to user group : SQ03d. Assign user group to infoset : SQ02e. Define Query : SQ01f. Execute Query : 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.

ExampleDATA REPID like sy-repid VALUE 'RSPFPAR'. SET PARAMETER ID 'RID' FIELD REPID.

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 nameA 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 lockWhen 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 locksBefore 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 collisionAn 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 lockAt 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 locksThe transaction Display and delete locks monitors the SAP locks.

SDLC

1. Feasibility Study2. Requirement Analysis3. Business Blue Print4. Coding5. Testing6. 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 name2. Now from the menu, goto --> indexes3. 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 Description

TYPE CHAR 1 S = success message E = error message W = warning message I = information messageA = termination message (abort)

ID CHAR 20 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.

NUMBER NUMC 3 Message number

MESSAGE CHAR 220 Full message text from the message table. All variables (in fields Message_V1 to Message_V4) have been replaced with text.

LOG_NO CHAR 20

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 NUMC 6 Current message number in application log

MESSAGE_V1 MESSAGE_V2 MESSAGE_V3 MESSAGE_V4

CHAR 50 Fields for the variable texts of the message specified in fields ID and NUMBER.

PARAMETER CHAR 32 Parameter containing the invalid value.

ROW INT 4

Line number of the data record containing the invalid value

FIELD CHAR 30 Field containing the invalid value.

SYSTEM CHAR 10 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    Creating Applications Logs  in the document    BC - Extended Function Library Applications.

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:

BAPIRET2You must use this reference structure when developing new BAPIS.

BAPIRET1, BAPIRETURNThese reference structures are still partly used in old BAPIs. 

Both structures must be filled in the logon language. 

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