Orientation of ABAP printout

Hi,
i'd like to change the orientation of the print output of an ABAP report (Report print output on the screen using write). Currently the output is landscape, but i need it in portrait. Is there any way in doing this?
I tried changing the format type in SPAD. But for ABAP lists this is not possible.
Any hint on how to achieve this?
Thanks & best regards,
Daniel

hi,
One more thimg ur orientation also depends upon device type.
Just check in SPAD for ur output device wat is the device type.
If it is SWIN then it will consider windows orientation which is set by u through control panel. If it is swin then change it as per ur printer. u can select it from drop down list.
Also check if u have z page format add that to particular device type then only it will work.
Also u check wat width & height u have given in report heading. It has to match with ur page format
eg.
REPORT  zptp_reservation_printing LINE-SIZE 80 MESSAGE-ID zm.
I hope it wil fulfil ur need.
Reply if any concerns.

Similar Messages

  • Documents of Object Oriented of ABAP,  I  need.

    Hi people,
    I need urgent a documentation of Object Oriented of ABAP, if some body have one send to me please.
    [email protected]
    Thanks...

    Hi carlos,
    check this link....
    http://help.sap.com/saphelp_erp2004/helpdata/en/ce/b518b6513611d194a50000e8353423/frameset.htm
    http://www.henrikfrank.dk/
    reward points for helpfull answers and close the thread if your question is solved.
    regards,
    venu.

  • Undesratsnding abap objects

    hi
    can any one provide basic material for underatanding object oriented in abap...with many sample programs(preferably)....u can also provide me links....
    thank you,
    Ginni

    Methods in ABAP Objects - Example
    The following example shows how to declare, implement, and use methods in ABAP Objects.
    Overview
    This example uses three classes called C_TEAM, C_BIKER, and C_BICYCLE. A user (a program) can create objects of the class C_TEAM. On a selection screen, the class C_TEAM asks for the number of members of each team.
    Each object in the class C_TEAM can create as many instances of the class C_BIKER as there are members in the team. Each instance of the class C_BIKER creates an instances of the class C_BICYCLE.
    Each instance of the class C_TEAM can communicate with the program user through an interactive list. The program user can choose individual team members for actions. The instances of the class C_BIKER allow the program user to choose the action on a further selection screen.
    Constraints
    The ABAP statements used for list processing are not yet fully available in ABAP Objects. However, to produce a simple test output, you can use the following statements:
    WRITE [AT] /<offset>(<length>) <f>
    ULINE
    SKIP
    NEW-LINE
    Note: The behavior of formatting and interactive list functions in their current state are not guaranteed. Incompatible changes could occur in a future release.
    Declarations
    This example is implemented using local classes, since selection screens belong to an ABAP program, and cannot be defined or called in global classes. Below are the definitions of the two selection screens and three classes:
    Global Selection Screens
    SELECTION-SCREEN BEGIN OF: SCREEN 100 TITLE TIT1, LINE.
      PARAMETERS MEMBERS TYPE I DEFAULT 10.
    SELECTION-SCREEN END OF: LINE, SCREEN 100.
    SELECTION-SCREEN BEGIN OF SCREEN 200 TITLE TIT2.
      PARAMETERS: DRIVE    RADIOBUTTON GROUP ACTN,
                  STOP     RADIOBUTTON GROUP ACTN,
                  GEARUP   RADIOBUTTON GROUP ACTN,
                  GEARDOWN RADIOBUTTON GROUP ACTN.
    SELECTION-SCREEN END OF SCREEN 200.
    Class Definitions
    CLASS: C_BIKER DEFINITION DEFERRED,
           C_BICYCLE DEFINITION DEFERRED.
    CLASS C_TEAM DEFINITION.
      PUBLIC SECTION.
      TYPES: BIKER_REF TYPE REF TO C_BIKER,
             BIKER_REF_TAB TYPE STANDARD TABLE OF BIKER_REF
                                               WITH DEFAULT KEY,
             BEGIN OF STATUS_LINE_TYPE,
               FLAG(1)  TYPE C,
               TEXT1(5) TYPE C,
               ID       TYPE I,
               TEXT2(7) TYPE C,
               TEXT3(6) TYPE C,
               GEAR     TYPE I,
               TEXT4(7) TYPE C,
               SPEED    TYPE I,
             END OF STATUS_LINE_TYPE.
      CLASS-METHODS: CLASS_CONSTRUCTOR.
      METHODS: CONSTRUCTOR,
               CREATE_TEAM,
               SELECTION,
               EXECUTION.
      PRIVATE SECTION.
      CLASS-DATA: TEAM_MEMBERS TYPE I,
                  COUNTER TYPE I.
      DATA: ID TYPE I,
            STATUS_LINE TYPE STATUS_LINE_TYPE,
            STATUS_LIST TYPE SORTED TABLE OF STATUS_LINE_TYPE
                                          WITH UNIQUE KEY ID,
            BIKER_TAB TYPE BIKER_REF_TAB,
            BIKER_SELECTION LIKE BIKER_TAB,
            BIKER LIKE LINE OF BIKER_TAB.
      METHODS: WRITE_LIST.
    ENDCLASS.
    CLASS C_BIKER DEFINITION.
      PUBLIC SECTION.
      METHODS: CONSTRUCTOR IMPORTING TEAM_ID TYPE I MEMBERS TYPE I,
               SELECT_ACTION,
               STATUS_LINE EXPORTING LINE
                           TYPE C_TEAM=>STATUS_LINE_TYPE.
      PRIVATE SECTION.
      CLASS-DATA COUNTER TYPE I.
      DATA: ID TYPE I,
            BIKE TYPE REF TO C_BICYCLE,
            GEAR_STATUS  TYPE I VALUE 1,
            SPEED_STATUS TYPE I VALUE 0.
      METHODS BIKER_ACTION IMPORTING ACTION TYPE I.
    ENDCLASS.
    CLASS C_BICYCLE DEFINITION.
      PUBLIC SECTION.
      METHODS: DRIVE EXPORTING VELOCITY TYPE I,
               STOP  EXPORTING VELOCITY TYPE I,
               CHANGE_GEAR IMPORTING CHANGE TYPE I
                           RETURNING VALUE(GEAR) TYPE I
                           EXCEPTIONS GEAR_MIN GEAR_MAX.
      PRIVATE SECTION.
      DATA: SPEED TYPE I,
            GEAR  TYPE I VALUE 1.
      CONSTANTS: MAX_GEAR TYPE I VALUE 18,
                 MIN_GEAR TYPE I VALUE 1.
    ENDCLASS.
    Note that none of the three classes has any public attributes. The states of the classes can only be changed by their methods. The class C_TEAM contains a static constructor CLASS_CONSTRUCTOR. C_TEAM and C_BIKER both contain instance constructors.
    Implementations
    The implementation parts of the classes contain the implementations of all of the methods declared in the corresponding declaration parts. The interfaces of the methods have already been defined in the declarations. In the implementations, the interface parameters behave like local data.
    Methods of Class C_TEAM
    The following methods are implemented in the section
    CLASS C_TEAM IMPLEMENTATION.
    ENDCLASS.
    CLASS_CONSTRUCTOR
      METHOD CLASS_CONSTRUCTOR.
        TIT1 = 'Team members ?'.
        CALL SELECTION-SCREEN 100 STARTING AT 5 3.
        IF SY-SUBRC NE 0.
          LEAVE PROGRAM.
        ELSE.
          TEAM_MEMBERS = MEMBERS.
        ENDIF.
      ENDMETHOD.
    The static constructor is executed before the class C_TEAM is used for the first time in a program. It calls the selection screen 100 and sets the static attribute TEAM_MEMBERS to the value entered by the program user. This attribute has the same value for all instances of the class C_TEAM.
    CONSTRUCTOR
      METHOD CONSTRUCTOR.
        COUNTER = COUNTER + 1.
        ID = COUNTER.
      ENDMETHOD.
    The instance constructor is executed directly after each instance of the class C_TEAM is created. It is used to count the number of instance of C_TEAM in the static attribute COUNTER, and assigns the corresponding number to the instance attribute ID of each instance of the class.
    CREATE_TEAM
      METHOD CREATE_TEAM.
        DO TEAM_MEMBERS TIMES.
          CREATE OBJECT BIKER EXPORTING TEAM_ID = ID
                                        MEMBERS = TEAM_MEMBERS.
          APPEND BIKER TO BIKER_TAB.
          CALL METHOD BIKER->STATUS_LINE IMPORTING LINE = STATUS_LINE.
          APPEND STATUS_LINE TO STATUS_LIST.
        ENDDO.
      ENDMETHOD.
    The public instance method CREATE_TEAM can be called by any user of the class containing a reference variable with a reference to an instance of the class. It is used to create instances of the class C_BIKER, using the private reference variable BIKER in the class C_TEAM. You must pass both input parameters for the instance constructor of class C_BIKER in the CREATE OBJECT statement. The references to the newly-created instances are inserted into the private internal table BIKER_TAB. After the method has been executed, each line of the internal table contains a reference to an instance of the class C_BIKER. These references are only visible within the class C_TEAM. External users cannot address the objects of class C_BIKER.
    CREATE_TEAM also calls the method STATUS_LINE for each newly-created object, and uses the work area STATUS_LINE to append its output parameter LINE to the private internal table STATUS_LIST.
    SELECTION
      METHOD SELECTION.
        CLEAR BIKER_SELECTION.
        DO.
          READ LINE SY-INDEX.
          IF SY-SUBRC <> 0. EXIT. ENDIF.
          IF SY-LISEL+0(1) = 'X'.
            READ TABLE BIKER_TAB INTO BIKER INDEX SY-INDEX.
            APPEND BIKER TO BIKER_SELECTION.
          ENDIF.
        ENDDO.
        CALL METHOD WRITE_LIST.
      ENDMETHOD.
    The public instance method SELECTION can be called by any user of the class containing a reference variable with a reference to an instance of the class. It selects all of the lines in the current list in which the checkbox in the first column is selected. For these lines, the system copies the corresponding reference variables from the table BIKER_TAB into an additional private internal table BIKER_SELECTION. SELECTION then calls the private method WRITE_LIST, which displays the list.
    EXECUTION
      METHOD EXECUTION.
        CHECK NOT BIKER_SELECTION IS INITIAL.
        LOOP AT BIKER_SELECTION INTO BIKER.
          CALL METHOD BIKER->SELECT_ACTION.
          CALL METHOD BIKER->STATUS_LINE IMPORTING LINE = STATUS_LINE.
          MODIFY TABLE STATUS_LIST FROM STATUS_LINE.
        ENDLOOP.
        CALL METHOD WRITE_LIST.
      ENDMETHOD.
    The public instance method EXECUTION can be called by any user of the class containing a reference variable with a reference to an instance of the class. The method calls the two methods SELECT_ACTION and STATUS_LINE for each instance of the class C_BIKER for which there is a reference in the table BIKER_SELECTION. The line of the table STATUS_LIST with the same key as the component ID in the work area STATUS_LINE is overwritten and displayed by the private method WRITE_LIST.
    WRITE_LIST
      METHOD WRITE_LIST.
        SET TITLEBAR 'TIT'.
        SY-LSIND = 0.
        SKIP TO LINE 1.
        POSITION 1.
        LOOP AT STATUS_LIST INTO STATUS_LINE.
          WRITE: / STATUS_LINE-FLAG AS CHECKBOX,
                   STATUS_LINE-TEXT1,
                   STATUS_LINE-ID,
                   STATUS_LINE-TEXT2,
                   STATUS_LINE-TEXT3,
                   STATUS_LINE-GEAR,
                   STATUS_LINE-TEXT4,
                   STATUS_LINE-SPEED.
        ENDLOOP.
      ENDMETHOD.
    The private instance method WRITE_LIST can only be called from the methods of the class C_TEAM. It is used to display the private internal table STATUS_LIST on the basic list (SY-LSIND = 0) of the program.
    Methods of Class C_BIKER
    The following methods are implemented in the section
    CLASS C_BIKER IMPLEMENTATION.
    ENDCLASS.
    CONSTRUCTOR
      METHOD CONSTRUCTOR.
        COUNTER = COUNTER + 1.
        ID = COUNTER - MEMBERS * ( TEAM_ID - 1).
        CREATE OBJECT BIKE.
      ENDMETHOD.
    The instance constructor is executed directly after each instance of the class C_BIKER is created. It is used to count the number of instance of C_BIKER in the static attribute COUNTER, and assigns the corresponding number to the instance attribute ID of each instance of the class. The constructor has two input parameters - TEAM_ID and MEMBERS - which you must pass in the CREATE OBJECT statement when you create an instance of C_BIKER.
    The instance constructor also creates an instance of the class C_BICYCLE for each new instance of the class C_BIKER. The reference in the private reference variable BIKE of each instance of C_BIKER points to a corresponding instance of the class C_BICYCLE. No external user can address these instances of the class C_BICYCLE.
    SELECT_ACTION
      METHOD SELECT_ACTION.
        DATA ACTIVITY TYPE I.
        TIT2 = 'Select action for BIKE'.
        TIT2+24(3) = ID.
        CALL SELECTION-SCREEN 200 STARTING AT 5 15.
        CHECK NOT SY-SUBRC GT 0.
        IF GEARUP = 'X' OR GEARDOWN = 'X'.
          IF GEARUP = 'X'.
            ACTIVITY = 1.
          ELSEIF GEARDOWN = 'X'.
            ACTIVITY = -1.
          ENDIF.
        ELSEIF DRIVE = 'X'.
          ACTIVITY = 2.
        ELSEIF STOP = 'X'.
          ACTIVITY = 3.
        ENDIF.
        CALL METHOD BIKER_ACTION( ACTIVITY).
      ENDMETHOD.
    The public instance method SELECT_ACTION can be called by any user of the class containing a reference variable with a reference to an instance of the class. The method calls the selection screen 200 and analyzes the user input. After this, it calls the private method BIKER_ACTION of the same class. The method call uses the shortened form to pass the actual parameter ACTIVITY to the formal parameter ACTION.
    BIKER_ACTION
      METHOD BIKER_ACTION.
        CASE ACTION.
          WHEN -1 OR 1.
            CALL METHOD BIKE->CHANGE_GEAR
                              EXPORTING CHANGE = ACTION
                              RECEIVING GEAR = GEAR_STATUS
                              EXCEPTIONS GEAR_MAX = 1
                                         GEAR_MIN = 2.
            CASE SY-SUBRC.
              WHEN 1.
                MESSAGE I315(AT) WITH 'BIKE' ID
                                      ' is already at maximal gear!'.
              WHEN 2.
                MESSAGE I315(AT) WITH 'BIKE' ID
                                      ' is already at minimal gear!'.
            ENDCASE.
          WHEN 2.
            CALL METHOD BIKE->DRIVE IMPORTING VELOCITY = SPEED_STATUS.
          WHEN 3.
            CALL METHOD BIKE->STOP IMPORTING VELOCITY = SPEED_STATUS.
        ENDCASE.
      ENDMETHOD.
    The private instance method BIKER_ACTION can only be called from the methods of the class C_BIKER. The method calls other methods in the instance of the class C_BICYCLE to which the reference in the reference variable BIKE is pointing, depending on the value in the input parameter ACTION.
    STATUS_LINE
      METHOD STATUS_LINE.
        LINE-FLAG = SPACE.
        LINE-TEXT1 = 'Biker'.
        LINE-ID = ID.
        LINE-TEXT2 = 'Status:'.
        LINE-TEXT3 = 'Gear = '.
        LINE-GEAR  = GEAR_STATUS.
        LINE-TEXT4 = 'Speed = '.
        LINE-SPEED = SPEED_STATUS.
      ENDMETHOD.
    The public instance method STATUS_LINE can be called by any user of the class containing a reference variable with a reference to an instance of the class. It fills the structured output parameter LINE with the current attribute values of the corresponding instance.
    Methods of Class C_BICYCLE
    The following methods are implemented in the section
    CLASS C_BICYCLE IMPLEMENTATION.
    ENDCLASS.
    DRIVE
      METHOD DRIVE.
        SPEED = SPEED  + GEAR * 10.
        VELOCITY = SPEED.
      ENDMETHOD.
    The public instance method DRIVE can be called by any user of the class containing a reference variable with a reference to an instance of the class. The method changes the value of the private attribute SPEED and passes it to the caller using the output parameter VELOCITY.
    STOP
      METHOD STOP.
        SPEED = 0.
        VELOCITY = SPEED.
      ENDMETHOD.
    The public instance method STOP can be called by any user of the class containing a reference variable with a reference to an instance of the class. The method changes the value of the private attribute SPEED and passes it to the caller using the output parameter VELOCITY.
    CHANGE_GEAR
      METHOD CHANGE_GEAR.
        GEAR = ME->GEAR.
        GEAR = GEAR + CHANGE.
        IF GEAR GT MAX_GEAR.
          GEAR = MAX_GEAR.
          RAISE GEAR_MAX.
        ELSEIF GEAR LT MIN_GEAR.
          GEAR = MIN_GEAR.
          RAISE GEAR_MIN.
        ENDIF.
        ME->GEAR = GEAR.
      ENDMETHOD.
    The public instance method CHANGE_GEAR can be called by any user of the class containing a reference variable with a reference to an instance of the class. The method changes the value of the private attribute GEAR. Since the formal parameter with the same name obscures the attribute in the method, the attribute has to be addressed using the self-reference ME->GEAR.
    Using the Classes in a Program
    The following program shows how the above classes can be used in a program. The declarations of the selection screens and local classes, and the implementations of the methods must also be a part of the program.
    REPORT OO_METHODS_DEMO NO STANDARD PAGE HEADING.
    Declarations and Implementations
    Global Program Data
    TYPES TEAM TYPE REF TO C_TEAM.
    DATA: TEAM_BLUE  TYPE TEAM,
          TEAM_GREEN TYPE TEAM,
          TEAM_RED   TYPE TEAM.
    DATA  COLOR(5).
    Program events
    START-OF-SELECTION.
      CREATE OBJECT: TEAM_BLUE,
                     TEAM_GREEN,
                     TEAM_RED.
       CALL METHOD: TEAM_BLUE->CREATE_TEAM,
                   TEAM_GREEN->CREATE_TEAM,
                   TEAM_RED->CREATE_TEAM.
      SET PF-STATUS 'TEAMLIST'.
      WRITE '                   Select a team!             ' COLOR = 2.
    AT USER-COMMAND.
      CASE SY-UCOMM.
        WHEN 'TEAM_BLUE'.
          COLOR = 'BLUE '.
          FORMAT COLOR = 1 INTENSIFIED ON INVERSE ON.
           CALL METHOD TEAM_BLUE->SELECTION.
        WHEN 'TEAM_GREEN'.
          COLOR = 'GREEN'.
          FORMAT COLOR = 5 INTENSIFIED ON INVERSE ON.
           CALL METHOD TEAM_GREEN->SELECTION.
        WHEN 'TEAM_RED'.
          COLOR = 'RED '.
          FORMAT COLOR = 6 INTENSIFIED ON INVERSE ON.
           CALL METHOD TEAM_RED->SELECTION.
        WHEN 'EXECUTION'.
          CASE COLOR.
            WHEN 'BLUE '.
              FORMAT COLOR = 1 INTENSIFIED ON INVERSE ON.
               CALL METHOD TEAM_BLUE->SELECTION.
              CALL METHOD TEAM_BLUE->EXECUTION.
            WHEN 'GREEN'.
              FORMAT COLOR = 5 INTENSIFIED ON INVERSE ON.
               CALL METHOD TEAM_GREEN->SELECTION.
              CALL METHOD TEAM_GREEN->EXECUTION.
            WHEN 'RED '.
              FORMAT COLOR = 6 INTENSIFIED ON INVERSE ON.
               CALL METHOD TEAM_RED->SELECTION.
              CALL METHOD TEAM_RED->EXECUTION.
          ENDCASE.
      ENDCASE.
    The program contains three class reference variables that refer to the class C_TEAM. It creates three objects from the class, to which the references in the reference variables then point. In each object, it calls the method CREATE_TEAM. The method CLASS_CONSTRUCTOR of class C_TEAM is executed before the first of the objects is created. The status TEAMLIST for the basic list allows the user to choose one of four functions:
    When the user chooses a function, the event AT USER-COMMAND is triggered and public methods are called in one of the three instances of C_TEAM, depending on the user’s choice. The user can change the state of an object by selecting the corresponding line in the status list.

  • File orientation on the designjet 800ps, using mac os x and photoshop

    Hi everyone
    We're having a problem with the orientation of the printout we're getting from a designjet 800PS...... The printer is working fine (except for some slight banding), but we are trying to work out the orientation first.
    Essentially when we are printing A1 sheets from the roll of paper it is printing the long side of the poster along the continuous side of the paper. This means that we then have to chop half of the width of paper off, which is a complete waste. What we want to be able to do is rotate the image being printed by 90 degrees so we can print the long side of the poster across the width of the roll, thus saving us paper and making our rolls last longer.
    We are using mac os x leopard (which has the HP drivers for this printer still installed), and printing from photoshop. I assume there should be an option somewhere in the system printer settings when we print, but i cannot for the life of me find them.
    Cheers in advance.
    This question was solved.
    View Solution.

    Need more info!!
    Are you selecting landscape or portrait orientation in page set up and the paper/quality tab of the printer driver when you select print?  Both those settings much match.  Are you using the autorotate feature?  Have you read through your user guide?  Found here:
    http://h20000.www2.hp.com/bizsupport/TechSupport/DocumentIndex.jsp?lang=en&cc=us&contentType=Support...
    Also, is this the 24 or 42 inch designjet?  What size paper?  Roll or Sheet? 
    Just so you know there are some quirks to getting portrait docs to print landscape - 2 fixes if you are doing everything correctly and it's still spinning your doc around:
    1 - if you are printing to a roll that is smaller than the max size, you can lie to the printer and tell it you have a larger size roll installed.
    2 - reduce the overall size of the original document by 1/2 inch.
    There is an issue where when we use autorotate and then chose to print a portrait doc landscape, the spooling software actually makes the document 1 pixel too wide so the printer automatically turns the document back around.  However let's make sure you are setting things up correctly first.
    insert signature here

  • Abap basics material documents

    Hi Gurus,
    i am intrested to learn basic in Abap i want to make my carrrier in  it so i kindky request you to plz send material  my [email protected]
    Thanks in Advance,
    Edited by: Krishna on Apr 23, 2008 2:16 PM
    Edited by: Krishna on Apr 23, 2008 2:17 PM

    Hi....
    Go for Siemens material. Check the following link:
    http://www.sapbrainsonline.com/TUTORIALS/TECHNICAL/ABAP_tutorial.html
    additional info
    ABAP is one of many application-specific fourth-generation languages (4GLs) first developed in the 1980s. It was originally the report language for SAP R/2, a platform that enabled large corporations to build mainframe business applications for materials management and financial and management accounting. ABAP used to be an abbreviation of Allgemeiner Berichtsaufbereitungsprozessor, the German meaning of "generic report preparation processor", but was later renamed to Advanced Business Application Programming. ABAP was one of the first languages to include the concept of Logical Databases (LDBs), which provides a high level of abstraction from the basic database level.
    The ABAP programming language was originally used by SAP developers to develop the SAP R/3 platform. It was also intended to be used by SAP customers to enhance SAP applications – customers can develop custom reports and interfaces with ABAP programming. The language is fairly easy to learn for programmers but it is not a tool for direct use by non-programmers. Good programming skills, including knowledge of relational database design and preferably also of object-oriented concepts, are required to create ABAP programs.
    ABAP remains the language for creating programs for the client-server R/3 system, which SAP first released in 1992. As computer hardware evolved through the 1990s, more and more of SAP's applications and systems were written in ABAP. By 2001, all but the most basic functions were written in ABAP. In 1999, SAP released an object-oriented extension to ABAP called ABAP Objects, along with R/3 release 4.6.
    SAP's most recent development platform, NetWeaver, supports both ABAP and Java.
    edit Implementation
    edit Where does the ABAP Program Run?
    All ABAP programs reside inside the SAP database. They are not stored in separate external files like Java or C++ programs. In the database all ABAP code exists in two forms: source code, which can be viewed and edited with the ABAP workbench, and "compiled" code ("generated" code is the more correct technical term), which is loaded and interpreted by the ABAP runtime system. Code generation happens implicitly when a unit of ABAP code is first invoked. If the source code is changed later or if one of the data objects accessed by the program has changed (e.g. fields were added to a database table), then the code is automatically regenerated.
    ABAP programs run in the SAP application server, under control of the runtime system, which is part of the SAP kernel. The runtime system is responsible for processing ABAP statements, controlling the flow logic of screens and responding to events (such as a user clicking on a screen button). A key component of the ABAP runtime system is the Database Interface, which turns database-independent ABAP statements ("Open SQL") into statements understood by the underlying DBMS ("Native SQL"). The database interface handles all the communication with the relational database on behalf of ABAP programs; it also contains extra features such as buffering of frequently accessed data in the local memory of the application server.
    Basis
    Basis sits between ABAP/4 and Operating system.Basis is like an operating system for R/3. It sits between the ABAP/4 code and the computer's operating system. SAP likes to call it middleware because it sits in the middle, between ABAP/4 and the operating system. Basis sits between ABAP/4 and the operating system. ABAP/4 cannot run directly on an operating system. It requires a set of programs (collectively called Basis) to load, interpret, and buffer its input and output. Basis, in some respects, is like the Windows environment. Windows starts up, and while running it provides an environment in which Windows programs can run. Without Windows, programs written for the Windows environment cannot run. Basis is to ABAP/4 programs as Windows is to Windows programs. Basis provides the runtime environment for ABAP/4 programs. Without Basis, ABAP/4 programs cannot run. When the operator starts up R/3, you can think of him as starting up Basis. Basis is a collection of R/3 system programs that present you with an interface. Using this interface the user can start ABAP/4 programs. To install Basis, an installer runs the program r3inst at the command-prompt level of the operating system. Like most installs, this creates a directory structure and copies a set of executables into it. These executables taken together as a unit form Basis.
    To start up the R/3 system, the operator enters the startsap command. The Basis executables start up and stay running, accepting requests from the user to run ABAP/4 programs.
    ABAP/4 programs run within the protective Basis environment; they are not executables that run on the operating system. Instead, Basis reads ABAP/4 code and interprets it into operating system instructions. ABAP/4 programs do not access operating system functions directly. Instead, they use Basis functions to perform file I/O and display data in windows. This level of isolation from the operating system enables ABAP/4 programs to be ported without modification to any system that supports R/3. This buffering is built right into the ABAP/4 language itself and is actually totally transparent to the programmer.
    Basis makes ABAP/4 programs portable. The platforms that R/3 can run on are shown in Table. For example, if you write an ABAP/4 program on Digital UNIX with an Informix database and an OSF/Motif interface, that same program should run without modification on a Windows NT machine with an Oracle database and a Windows 95 interface. Or, it could run on an AS/400 with a DB2 database using OS/2 as the front-end.
    SAP also provides a suite of tools for administering the Basis system. These tools perform tasks such as system performance monitoring, configuration, and system maintenance. To access the Basis administration tools from the main menu, choose the path Tools->Administration.
    Platforms and Databases Supported by R/3
    Operating Systems Supported Hardware Supported Front-Ends Supported Databases
    AIX SINIX IBM SNI SUN Win 3.1/95/NT DB2 for AIX
    SOLARIS HP-UX Digital HP OSF/Motif Informix-Online
    Digital-UNIX Bull OS/2 Oracle 7.1
    Windows NT AT&T Compaq Win 3.1/95/NT Oracle 7.1
    Bull/Zenith OSF/Motif SQL Server 6.0
    HP (Intel) SNI OS/2 ADABAS D
    OS/400 AS/400 Win95 OS/2 DB2/400
    edit SAP Systems and Landscapes
    All SAP data exists and all SAP software runs in the context of an SAP system. A system consists of a central relational database and one or more application servers ("instances") accessing the data and programs in this database. A SAP system contains at least one instance but may contain more, mostly for reasons of sizing and performance. In a system with multiple instances, load balancing mechanisms ensure that the load is spread evenly over the available application servers.
    Installations of the Web Application Server (landscapes) typically consist of three systems: one for development, one for testing and quality assurance, and one for production. The landscape may contain more systems, e.g. separate systems for unit testing and pre-production testing, or it may contain fewer, e.g. only development and production, without separate QA; nevertheless three is the most common configuration. ABAP programs are created and undergo first testing in the development system. Afterwards they are distributed to the other systems in the landscape. These actions take place under control of the Change and Transport System (CTS), which is responsible for concurrency control (e.g. preventing two developers from changing the same code at the same time), version management and deployment of programs on the QA and production systems.
    The Web Application Server consists of three layers: the database layer, the application layer and the presentation layer. These layers may run on the same or on different physical machines. The database layer contains the relational database and the database software. The application layer contains the instance or instances of the system. All application processes, including the business transactions and the ABAP development, run on the application layer. The presentation layer handles the interaction with users of the system. Online access to ABAP application servers can go via a proprietary graphical interface, the SAPGUI, or via a Web browser.
    edit Transactions
    We call an execution of an ABAP program using a transaction code a transaction. There are dialog, report, parameter, variant, and as of release 6.10, OO transactions. A transaction is started by entering the transaction code in the input field on the standard toolbar, or by means of the ABAP statements CALL TRANSACTION or LEAVE TO TRANSACTION. Transaction codes can also be linked to screen elements or menu entries. Selecting such an element will start the transaction.
    A transaction code is simply a twenty-character name connected with a Dynpro, another transaction code, or, as of release 6.10, a method of an ABAP program. Transaction codes linked with Dynpros are possible for executable programs, module pools, and function groups. Parameter transactions and variant transactions are linked with other transaction codes. Transaction codes that are linked with methods are allowed for all program types that can contain methods. Transaction codes are maintained in transaction SE93.
    So, a transaction is nothing more than the SAP way of program execution—but why is it called “transaction”? ABAP is a language for business applications and the most important features of business applications were and still are are transactions. Since in the early days of SAP, the execution of a program often meant the same thing as carrying out a business transaction, the terms transaction and transaction code were chosen for program execution. But never mix up the technical meaning of a transaction with business transactions. For business transactions, it is the term LUW (Logical Unit of Work) that counts. And during one transaction (program execution), there can be many different LUW’s.
    Let’s have a look at the different kind of transactions:
    edit Dialog Transaction
    These are the most common kind of transactions. The transaction code of a dialog transaction is linked to a Dynpro of an ABAP program. When the transaction is called, the respective program is loaded and the Dynpro is called. Therefore, a dialog transaction calls a Dynpro sequence rather than a program. Only during the execution of the Dynpro flow logic are the dialog modules of the ABAP program itself are called. The program flow can differ from execution to execution. You can even assign different dialog transaction codes to one program.
    edit Parameter Transaction
    In the definition of a parameter transaction code, a dialog transaction is linked with parameters. When you call a parameter transaction, the input fields of the initial Dynpro screen of the dialog transaction are filled with parameters. The display of the initial screen can be inhibited by specifying all mandatory input fields as parameters of the transaction.
    edit Variant Transaction
    In the definition of a variant transaction code, a dialog transaction is linked with a transaction variant. When a variant transaction is accessed, the dialog transaction is called and executed with the transaction variant. In transaction variants, you can assign default values to the input fields on several Dynpro screens in a transaction, change the attributes of screen elements, and hide entire screens. Transaction variants are maintained in transaction SHD0.
    edit Report Transaction
    A report transaction is the transaction code wrapping for starting the reporting process. The transaction code of a report transaction must be linked with the selection screen of an executable program. When you execute a report transaction, the runtime environment internally executes the ABAP statement SUBMIT—more to come on that.
    edit OO Transaction
    A new kind of transaction as of release 6.10. The transaction code of an OO transaction is linked with a method of a local or global class. When the transaction is called, the corresponding program is loaded, for instance methods an object of the class is generated and the method is executed.
    edit Types of ABAP programs
    In ABAP, there are two different types of programs:
    edit Report programs(Executable pools)
    A Sample ReportReport programs AKA Executable pools follow a relatively simple programming model whereby a user optionally enters a set of parameters (e.g. a selection over a subset of data) and the program then uses the input parameters to produce a report in the form of an interactive list. The output from the report program is interactive because it is not a passive display; instead it enables the user, through ABAP language constructs, to obtain a more detailed view on specific data records via drill-down functions, or to invoke further processing through menu commands, for instance to sort the data in a different way or to filter the data according to selection criteria. This method of presenting reports has great advantages for users who must deal with large quantities of information and must also have the ability to examine this information in highly flexible ways, without being constrained by the rigid formatting or unmanageable size of "listing-like" reports. The ease with which such interactive reports can be developed is one of the most striking features of the ABAP language.
    The term "report" is somewhat misleading in the sense that it is also possible to create report programs that modify the data in the underlying database instead of simply reading it.
    A customized screen created using Screen Painter,which is one of the tool available in ABAP workbench(T-code = SE51).
    edit Online programs
    Online programs (also called module pools) do not produce lists. These programs define more complex patterns of user interaction using a collection of screens. The term “screen” refers to the actual, physical image that the users sees. Each screen also has a “flow logic”; this refers to the ABAP code invoked by the screens, i.e. the logic that initializes screens, responds to a user’s requests and controls the sequence between the screens of a module pool. Each screen has its own Flow Logic, which is divided into a "PBO" (Process Before Output) and "PAI" (Process After Input) section. In SAP documentation the term “dynpro” (dynamic program) refers to the combination of the screen and its Flow Logic.
    Online programs are not invoked directly by their name, but are associated with a transaction code. Users can then invoke them through customizable, role-dependent, transaction menus.
    Apart from reports and online programs, it is also possible to develop sharable code units such as class libraries, function libraries and subroutine pools.
    edit Subroutine Pools
    Subroutine pools, as the name implies, were created to contain selections of subroutines that can be called externally from other programs. Before release 6.10, this was the only way subroutine pools could be used. But besides subroutines, subroutine pools can also contain local classes and interfaces. As of release 6.10, you can connect transaction codes to methods. Therefore, you can now also call subroutine pools via transaction codes. This is the closest to a Java program you can get in ABAP: a subroutine pool with a class containing a method – say – main connected to a transaction code!
    edit Type Pools
    Type pools are the precursors to general type definitions in the ABAP Dictionary. Before release 4.0, only elementary data types and flat structures could be defined in the ABAP Dictionary. All other types that should’ve been generally available had to be defined with TYPES in type pools. As of release 4.0, type pools were only necessary for constants. As of release 6.40, constants can be declared in the public sections of global classes and type pools can be replaced by global classes.
    edit Class Pools
    Class pools serve as containers for exactly one global class. Besides the global class, they can contain global types and local classes/interfaces to be used in the global class. A class pool is loaded into memory by using one of its components. For example, a public method can be called from any ABAP program or via a transaction code connected to the method. You maintain class pools in the class builder.
    edit Interface Pools
    Interface pools serve as containers for exactly one global interface—nothing more and nothing less. You use an interface pool by implementing its interface in classes and by creating reference variables with the type of its interface. You maintain interface pools in the class builder.
    edit ABAP Workbench
    The ABAP Workbench contains different tools for editing Repository objects. These tools provide you with a wide range of assistance that covers the entire software development cycle. The most important tools for creating and editing Repository objects are:
    ABAP Editor for writing and editing program code
    ABAP Dictionary for processing database table definitions and retrieving global types
    Menu Painter for designing the user interface (menu bar, standard toolbar, application toolbar, function key assignment)
    Screen Painter for designing screens (dynamic programs) for user dialogs
    Function Builder for displaying and processing function modules (routines with defined interfaces that are available throughout the system)
    Class Builder for displaying and processing ABAP Objects classes
    edit The ABAP Dictionary
    Enforces data integrity
    Manages data definitions without redundancy
    Is tightly integrated with the rest of the ABAP/4 Development Workbench.
    Enforcing data integrity is the process of ensuring that data entered into the system is logical, complete, and consistent. When data integrity rules are defined in the ABAP/4 Dictionary, the system automatically prevents the entry of invalid data. Defining the data integrity rules at the dictionary level means they only have to be defined once, rather than in each program that accesses that data.
    The following are examples of data lacking integrity:
    A date field with a month value of 13
    An order assigned to a customer number that doesn’t exist
    An order not assigned to a customer
    Managing data definitions without redundancy is the process of linking similar information to the same data definition. For example, a customer database is likely to contain a customer’s ID number in several places. The ABAP Dictionary provides the capability of defining the characteristics of a customer ID number in only one place. That central definition then can be used for each instance of a customer ID number.
    The ABAP Dictionary’s integration with the rest of the development environment enables ABAP programs to automatically recognize the names and characteristics of dictionary objects.
    Additionally, the system provides easy navigation between development objects and dictionary definitions. For example, as a programmer, you can double-click on the name of a dictionary object in your program code, and the system will take you directly to the definition of that object in the ABAP/4 Dictionary.
    When a dictionary object is changed, a program that references the changed object will automatically reference the new version the next time the program runs. Because ABAP is interpreted, it is not necessary to recompile programs that reference changed dictionary objects.
    edit ABAP Syntax
    The syntax of the ABAP programming language consists of the following elements:
    Statements
    An ABAP program consists of individual ABAP statements. Each statement begins with a keyword and ends with a period.
    edit "Hello World" PROGRAM
    WRITE 'Hello World'.
    This example contains two statements, one on each line. The keywords are PROGRAM and WRITE. The program displays a list on the screen. In this case, the list consists of the line "My First Program".
    The keyword determines the category of the statement. For an overview of the different categories, refer to ABAP Statements.
    edit Formatting ABAP Statements
    ABAP has no format restrictions. You can enter statements in any format, so a statement can be indented, you can write several statements on one line, or spread a single statement over several lines.
    You must separate words within a statement with at least one space. The system also interprets the end of line marker as a space.
    The program fragment
    PROGRAM TEST.
    WRITE 'This is a statement'.
    could also be written as follows:
    PROGRAM TEST. WRITE 'This is a statement'.
    or as follows:
    PROGRAM
    TEST.
    WRITE
    'This is a statement'.
    Use this free formatting to make your programs easier to understand.
    edit Special Case: Text Literals
    Text literals are sequences of alphanumeric characters in the program code that are enclosed in quotation marks. If a text literal in an ABAP statement extends across more than one line, the following difficulties can occur:
    All spaces between the quotation marks are interpreted as belonging to the text literal. Letters in text literals in a line that is not concluded with quotation marks are interpreted by the editor as uppercase. If you want to enter text literals that do not fit into a single line, you can use the ‘&’ character to combine a succession of text literals into a single one.
    The program fragment
    PROGRAM TEST.
    WRITE 'This
    is
    a statement'.
    inserts all spaces between the quotation marks into the literal, and converts the letters to uppercase.
    This program fragment
    PROGRAM TEST.
    WRITE 'This' &
    ' is ' &
    'a statement'.
    combines three text literals into one.
    edit Chained Statements
    The ABAP programming language allows you to concatenate consecutive statements with an identical first part into a chain statement.
    To concatenate a sequence of separate statements, write the identical part only once and place a colon ( after it. After the colon, write the remaining parts of the individual statements, separating them with commas. Ensure that you place a period (.) after the last part to inform the system where the chain ends.
    Statement sequence:
    WRITE SPFLI-CITYFROM.
    WRITE SPFLI-CITYTO.
    WRITE SPFLI-AIRPTO.
    Chain statement:
    WRITE: SPFLI-CITYFROM, SPFLI-CITYTO, SPFLI-AIRPTO.
    In the chain, a colon separates the beginning of the statement from the variable parts. After the colon or commas, you can insert any number of spaces.
    You could, for example, write the same statement like this:
    WRITE: SPFLI-CITYFROM,
    SPFLI-CITYTO,
    SPFLI-AIRPTO.
    In a chain statement, the first part (before the colon) is not limited to the keyword of the statements.
    Statement sequence:
    SUM = SUM + 1.
    SUM = SUM + 2.
    SUM = SUM + 3.
    SUM = SUM + 4.
    Chain statement:
    SUM = SUM + : 1, 2, 3, 4.
    edit Comments
    Comments are texts that you can write between the statements of your ABAP program to explain their purpose to a reader. Comments are distinguished by the preceding signs * (at the beginning of a line) and " (at any position in a line). If you want the entire line to be a comment, enter an asterisk (*) at the beginning of the line. The system then ignores the entire line when it generates the program. If you want part of a line to be a comment, enter a double quotation mark (") before the comment. The system interprets comments indicated by double quotation marks as spaces.
    PROGRAM SAPMTEST *
    WRITTEN BY KARL BYTE, 06/27/1995 *
    LAST CHANGED BY RITA DIGIT, 10/01/1995 *
    TASK: DEMONSTRATION *
    PROGRAM SAPMTEST.
    DECLARATIONS *
    DATA: FLAG " GLOBAL FLAG
    NUMBER TYPE I " COUNTER
    PROCESSING BLOCKS *
    Advantages of ABAP over Contemporary languages
    ABAP OBJECTS
    Object orientation in ABAP is an extension of the ABAP language that makes available the advantages of object-oriented programming, such as encapsulation, interfaces, and inheritance. This helps to simplify applications and make them more controllable.
    ABAP Objects is fully compatible with the existing language, so you can use existing statements and modularization units in programs that use ABAP Objects, and can also use ABAP Objects in existing ABAP programs.
    edit ABAP Statements – an Overview
    The first element of an ABAP statement is the ABAP keyword. This determines the category of the statement. The different statement categories are as follows:
    edit Declarative Statements
    These statements define data types or declare data objects which are used by the other statements in a program or routine. The collected declarative statements in a program or routine make up its declaration part.
    Examples of declarative keywords:
    TYPES, DATA, TABLES
    edit Modularization Statements
    These statements define the processing blocks in an ABAP program.
    The modularization keywords can be further divided into:
    · Defining keywords
    You use statements containing these keywords to define subroutines, function modules, dialog modules and methods. You conclude these processing blocks using the END statements.
    Examples of definitive keywords:
    METHOD ... ENDMETHOD, FUNCTION ... ENDFUNCTION, MODULE ... ENDMODULE.
    · Event keywords
    You use statements containing these keywords to define event blocks. There are no special statements to conclude processing blocks - they end when the next processing block is introduced.
    Examples of event key words:
    AT SELECTION SCREEN, START-OF-SELECTION, AT USER-COMMAND
    edit Control Statements
    You use these statements to control the flow of an ABAP program within a processing block according to certain conditions.
    Examples of control keywords:
    IF, WHILE, CASE
    edit Call Statements
    You use these statements to call processing blocks that you have already defined using modularization statements. The blocks you call can either be in the same ABAP program or in a different program.
    Examples of call keywords:
    CALL METHOD, CALL TRANSACTION, SUBMIT, LEAVE TO
    Operational Statements These keywords process the data that you have defined using declarative statements.
    Examples of operational keywords:
    MOVE, ADD
    edit Unique Concept of Internal Table in ABAP
    Internal tables provide a means of taking data from a fixed structure and storing it in working memory in ABAP. The data is stored line by line in memory, and each line has the same structure. In ABAP, internal tables fulfill the function of arrays. Since they are dynamic data objects, they save the programmer the task of dynamic memory management in his or her programs. You should use internal tables whenever you want to process a dataset with a fixed structure within a program. A particularly important use for internal tables is for storing and formatting data from a database table within a program. They are also a good way of including very complicated data structures in an ABAP program.
    Like all elements in the ABAP type concept, internal tables can exist both as data types and as data objects A data type is the abstract description of an internal table, either in a program or centrally in the ABAP Dictionary, that you use to create a concrete data object. The data type is also an attribute of an existing data object.
    edit Internal Tables as Data Types
    Internal tables and structures are the two structured data types in ABAP. The data type of an internal table is fully specified by its line type, key, and table type.
    edit Line type
    The line type of an internal table can be any data type. The data type of an internal table is normally a structure. Each component of the structure is a column in the internal table. However, the line type may also be elementary or another internal table.
    edit Key
    The key identifies table rows. There are two kinds of key for internal tables - the standard key and a user-defined key. You can specify whether the key should be UNIQUE or NON-UNIQUE. Internal tables with a unique key cannot contain duplicate entries. The uniqueness depends on the table access method.
    If a table has a structured line type, its default key consists of all of its non-numerical columns that are not references or themselves internal tables. If a table has an elementary line type, the default key is the entire line. The default key of an internal table whose line type is an internal table, the default key is empty.
    The user-defined key can contain any columns of the internal table that are not references or themselves internal tables. Internal tables with a user-defined key are called key tables. When you define the key, the sequence of the key fields is significant. You should remember this, for example, if you intend to sort the table according to the key.
    edit Table type
    The table type determines how ABAP will access individual table entries. Internal tables can be divided into three types:
    Standard tables have an internal linear index. From a particular size upwards, the indexes of internal tables are administered as trees. In this case, the index administration overhead increases in logarithmic and not linear relation to the number of lines. The system can access records either by using the table index or the key. The response time for key access is proportional to the number of entries in the table. The key of a standard table is always non-unique. You cannot specify a unique key. This means that standard tables can always be filled very quickly, since the system does not have to check whether there are already existing entries.
    Sorted tables are always saved sorted by the key. They also have an internal index. The system can access records either by using the table index or the key. The response time for key access is logarithmically proportional to the number of table entries, since the system uses a binary search. The key of a sorted table can be either unique or non-unique. When you define the table, you must specify whether the key is to be unique or not. Standard tables and sorted tables are known generically as index tables.
    Hashed tables have no linear index. You can only access a hashed table using its key. The response time is independent of the number of table entries, and is constant, since the system access the table entries using a hash algorithm. The key of a hashed table must be unique. When you define the table, you must specify the key as UNIQUE.
    edit Generic Internal Tables
    Unlike other local data types in programs, you do not have to specify the data type of an internal table fully. Instead, you can specify a generic construction, that is, the key or key and line type of an internal table data type may remain unspecified. You can use generic internal tables to specify the types of field symbols and the interface parameters of procedures . You cannot use them to declare data objects.
    edit Internal Tables as Dynamic Data Objects
    Data objects that are defined either with the data type of an internal table, or directly as an internal table, are always fully defined in respect of their line type, key and access method. However, the number of lines is not fixed. Thus internal tables are dynamic data objects, since they can contain any number of lines of a particular type. The only restriction on the number of lines an internal table may contain are the limits of your system installation. The maximum memory that can be occupied by an internal table (including its internal administration) is 2 gigabytes. A more realistic figure is up to 500 megabytes. An additional restriction for hashed tables is that they may not contain more than 2 million entries. The line types of internal tables can be any ABAP data types - elementary, structured, or internal tables. The individual lines of an internal table are called table lines or table entries. Each component of a structured line is called a column in the internal table.
    edit Choosing a Table Type
    The table type (and particularly the access method) that you will use depends on how the typical internal table operations will be most frequently executed.
    edit Standard tables
    This is the most appropriate type if you are going to address the individual table entries using the index. Index access is the quickest possible access. You should fill a standard table by appending lines (ABAP APPEND statement), and read, modify and delete entries by specifying the index (INDEX option with the relevant ABAP command). The access time for a standard table increases in a linear relationship with the number of table entries. If you need key access, standard tables are particularly useful if you can fill and process the table in separate steps. For example, you could fill the table by appending entries, and then sort it. If you use the binary search option with key access, the response time is logarithmically proportional to the number of table entries.
    edit Sorted tables
    This is the most appropriate type if you need a table which is sorted as you fill it. You fill sorted tables using the INSERT statement. Entries are inserted according to the sort sequence defined through the table key. Any illegal entries are recognized as soon as you try to add them to the table. The response time for key access is logarithmically proportional to the number of table entries, since the system always uses a binary search. Sorted tables are particularly useful for partially sequential processing in a LOOP if you specify the beginning of the table key in the WHERE condition.
    edit Hashed tables
    This is the most appropriate type for any table where the main operation is key access. You cannot access a hashed table using its index. The response time for key access remains constant, regardless of the number of table entries. Like database tables, hashed tables always have a unique key. Hashed tables are useful if you want to construct and use an internal table which resembles a database table or for processing large amounts of data.
    edit Advanced Topics
    edit Batch Input: Concepts
    Processing Sessions
    The above figure shows how a batch input session works.A batch input session is a set of one or more calls to transactions along with the data to be processed by the transactions. The system normally executes the transactions in a session non-interactively, allowing rapid entry of bulk data into an R/3 System.
    A session records transactions and data in a special format that can be interpreted by the R/3 System. When the System reads a session, it uses the data in the session to simulate on-line entry of transactions and data. The System can call transactions and enter data using most of the facilities that are available to interactive users.
    For example, the data that a session enters into transaction screens is subject to the same consistency checking as in normal interactive operation. Further, batch input sessions are subject to the user-based authorization checking that is performed by the system.
    edit Advantages of ABAP over Contemporary languages
    ABAP Objects offers a number of advantages, even if you want to continue using procedural programming. If you want to use new ABAP features, you have to use object-oriented interfaces anyway.
    Sharing Data: With ABAP shared objects, you can aggregate data once at a central location and the different users and programs can then access this data without the need for copying.
    Exception Handling: With the class-based exception concept of ABAP, you can define a special control flow for a specific error situation and provide the user with information about the error.
    Developing Persistency: For permanent storage of data in ABAP, you use relational database tables by means of database-independent Open SQL, which is integrated in ABAP. However, you can also store selected objects transparently or access the integrated database or other databases using proprietary SQL.
    Connectivity and Interoperability: The Exchange Infrastructure and Web services are the means by which developers can implement a service-oriented architecture. With Web services, you can provide and consume services independently of implementation or protocol. Furthermore, you can do so within NetWeaver and in the communication with other systems. With the features of the Exchange Infrastructure, you can enable, manage, and adapt integration scenarios between systems.
    Making Enhancements: With the Enhancement Framework, you can enhance programs, function modules, and global classes without modification as well as replace existing code. The Switch Framework enables you activate only specific development objects or enhancements in a system.
    edit Considerable Aspects
    It follows a list of aspects to be considered during development. The list of course is not complete.
    edit Dynpro persistence
    When implementing dynpros one has to care for himself to read out and persist the necessary fields. Recently it happened to me that I forgot to include a field into the UPDATE-clause which is an error not so easy to uncover if you have other problems to be solved in the same package. Here, tool-support or built-in mechanisms would help.
    The developer could help himself out by creating something like a document containing a cookbook or guide in which parts of a dynpro logic one has to care about persistence. With that at hand, it would be quite easy finding those bugs in short time. Maybe a report scanning for the definition of the dynpro fields to be persisted could scan the code automatically, too.
    edit Memory Cache
    It should be common-sense that avoiding select-statements onto the database helps reducing the server load. For that the programmer either can resort to function modules if available. This maybe is the case for important tables. Or the programmer needs to implement his own logic using internal tables. Here, the standard software package could provide the developer with a tool or a mechanism auto-generating memory cached tables resp. function modules implementing this.
    Sometimes buffering of database tables could be used, if applicable. But that would require an effort in customizing the system and could drain down system performance overall, especially if a table is involved that has a central role.
    edit Interfaces
    It should be noticed that some function modules available have an incomplete interface. That means, the interface does not include all parameters evaluated by the logic of the function module. For example, global variables from within the function group could be read out, which cannot be influenced by the general caller. Or memory parameters are used internally to feed the logic with further information.
    One workaround here would be copying the relevant parts of the logic to a newly created function module and then adapt it to the own context. This sometimes is possible, maybe if the copied code is not too lengthy and only a few or no calls to other logic is part of it.
    A modification of the SAP code could be considered, if the modification itself is unavoidable (or another solution would be not justifiable by estimated effort to spend on it) and if the location of the modification seems quite safe against future upgrades or hot fixes. The latter is something that could be evaluated by contacting the SAP hotline or working with OSS message (searching thru existing one, perhaps open a new one).
    edit Example
    'From SAP NetWeaver:'
    set an exclusive lock at level object-type & object-id
    IF NOT lf_bapi_error = true.
    IF ( NOT istourhd-doc_type IS INITIAL ) AND
    ( NOT istourhd-doc_id IS INITIAL )
    CALL FUNCTION 'ENQUEUE_/DSD/E_HH_RAREF'
    EXPORTING
    obj_typ = istourhd-doc_type
    obj_id = istourhd-doc_id
    EXCEPTIONS
    foreign_lock = 1
    system_failure = 2
    OTHERS = 3.
    IF sy-subrc 0.
    terminate processing...
    lf_bapi_error = true.—
    ...and add message to return table
    PERFORM set_msg_to_bapiret2
    USING sy-msgid gc_abort sy-msgno
    sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4
    gc_istourhd gc_enqueue_refdoc space
    CHANGING lt_return.
    ENDIF.
    ENDIF.
    ENDIF. " bapi error
    edit Example Report(Type - ALV(Advanced List Viewer))
    REPORT Z_ALV_SIMPLE_EXAMPLE_WITH_ITAB .
    *Simple example to use ALV and to define the ALV data in an internal
    *table
    *data definition
    tables:
    marav. "Table MARA and table MAKT
    Data to be displayed in ALV
    Using the following syntax, REUSE_ALV_FIELDCATALOG_MERGE can auto-
    matically determine the fieldstructure from this source program
    Data:
    begin of imat occurs 100,
    matnr like marav-matnr, "Material number
    maktx like marav-maktx, "Material short text
    matkl like marav-matkl, "Material group (so you can test to make
    " intermediate sums)
    ntgew like marav-ntgew, "Net weight, numeric field (so you can test to
    "make sums)
    gewei like marav-gewei, "weight unit (just to be complete)
    end of imat.
    Other data needed
    field to store report name
    data i_repid like sy-repid.
    field to check table length
    data i_lines like sy-tabix.
    Data for ALV display
    TYPE-POOLS: SLIS.
    data int_fcat type SLIS_T_FIELDCAT_ALV.
    select-options:
    s_matnr for marav-matnr matchcode object MAT1.
    start-of-selection.
    read data into table imat
    select * from marav
    into corresponding fields of table imat
    where
    matnr in s_matnr.
    Check if material was found
    clear i_lines.
    describe table imat lines i_lines.
    if i_lines lt 1.
    Using hardcoded write here for easy upload
    write: /
    'No materials found.'.
    exit.
    endif.
    end-of-selection.
    To use ALV, we need a DDIC-structure or a thing called Fieldcatalogue.
    The fieldcatalouge can be generated by FUNCTION
    'REUSE_ALV_FIELDCATALOG_MERGE' from an internal table from any
    report source, including this report.
    Store report name
    i_repid = sy-repid.
    Create Fieldcatalogue from internal table
    CALL FUNCTION 'REUSE_ALV_FIELDCATALOG_MERGE'
    EXPORTING
    I_PROGRAM_NAME = i_repid
    I_INTERNAL_TABNAME = 'IMAT' "capital letters!
    I_INCLNAME = i_repid
    CHANGING
    CT_FIELDCAT = int_fcat
    EXCEPTIONS
    INCONSISTENT_INTERFACE = 1
    PROGRAM_ERROR = 2
    OTHERS = 3.
    *explanations:
    I_PROGRAM_NAME is the program which calls this function
    I_INTERNAL_TABNAME is the name of the internal table which you want
    to display in ALV
    I_INCLNAME is the ABAP-source where the internal table is defined
    (DATA....)
    CT_FIELDCAT contains the Fieldcatalouge that we need later for
    ALV display
    IF SY-SUBRC 0.
    write: /
    'Returncode',
    sy-subrc,
    'from FUNCTION REUSE_ALV_FIELDCATALOG_MERGE'.
    ENDIF.
    *This was the fieldcatlogue
    Call for ALV list display
    CALL FUNCTION 'REUSE_ALV_LIST_DISPLAY'
    EXPORTING
    I_CALLBACK_PROGRAM = i_repid
    IT_FIELDCAT = int_fcat
    TABLES
    T_OUTTAB = imat
    EXCEPTIONS
    PROGRAM_ERROR = 1
    OTHERS = 2.
    *explanations:
    I_CALLBACK_PROGRAM is the program which calls this function
    IT_FIELDCAT (just made by REUSE_ALV_FIELDCATALOG_MERGE) contains
    now the data definition needed for display
    I_SAVE allows the user to save his own layouts
    T_OUTTAB contains the data to be displayed in ALV
    IF SY-SUBRC 0.
    write: /
    'Returncode',
    sy-subrc,
    'from FUNCTION REUSE_ALV_LIST_DISPLAY'.
    ENDIF.
    first learn basic programing afterwards
    go through commands, statements , events, functional modules.....etc.
    and implement these stuff, in programing,. and do practising.
    Check the following links:
    http://www.sapbrainsonline.com/TUTORIALS/TECHNICAL/ABAP_tutorial.html
    http://sap-img.com/
    http://sapabaplive.blogspot.com/2007/07/download-abap-in-21-days.html
    http://help.sap.com/saphelp_40b/helpdata/en/4f/991f82446d11d189700000e8322d00/applet.htm
    http://www.sapbrainsonline.com/TUTORIALS/TECHNICAL/ABAP_tutorial.html
    http://www.esnips.com/web/SAPAbapCertificationDocs/
    Start with this.Refer this
    For BDC:
    http://myweb.dal.ca/hchinni/sap/bdc_home.htm
    https://www.sdn.sap.com/irj/sdn/wiki?path=/display/home/bdc&
    http://www.sap-img.com/abap/learning-bdc-programming.htm
    http://www.sapdevelopment.co.uk/bdc/bdchome.htm
    http://www.sap-img.com/abap/difference-between-batch-input-and-call-transaction-in-bdc.htm
    http://help.sap.com/saphelp_47x200/helpdata/en/69/c250684ba111d189750000e8322d00/frameset.htm
    http://www.sapbrain.com/TUTORIALS/TECHNICAL/BDC_tutorial.html
    Check these link:
    http://www.sap-img.com/abap/difference-between-batch-input-and-call-transaction-in-bdc.htm
    http://www.sap-img.com/abap/question-about-bdc-program.htm

  • ABAP Objects and Web Dynpro

    Hello everyone,
    I would like to know if it is possible to have instances of a class as a part of a controller context. You know, like if you added a service call to a BAPI or a function group, but with method calls to an object instead.
    I have a feeling, that it is uncommon to bring Web Dynpro and the object orientation of ABAP Objects together.
    For example, i don't want the event handling code of my controllers to call function groups, which in turn make calls to my object oriented model. Is there a way to skip that nasty imperative step?
    Sorry for asking questions which may sound vague or naive, I'm kind of a beginner regarding Web Dynpro and ABAP.
    cheers,
    Jens Barthel

    There's no need at all to have function modules in the way.
    You can have either controller attributes or context attributes defined as object references, and then call methods from those objects instead...
    In both cases, you just have to use TYPE REF TO instead of TYPE when defining the attributes.
    Furthermore, if you have a central class through which you interact with your OO model, you can define it as Assistance class and then you'll have an instance automatically in all the controllers...the drawback / advantage is that you do not control its instantiation which is done by the framework.
    Regards
    Edited by: Alejandro Bindi on Oct 14, 2008 6:23 PM

  • Does WD ABAP harbingers the down fall of WD JAVA

    Hi All,
             I want to discuss whether the dawn of WD ABAP harbingers the dusk of WD JAVA or is it just to add versatility to WD.
    So should JAVA developers pack their bags :O  and look out for more avenues ??????
    Please discuss.
    Cheers
    Umang

    Hi,
    This seems like the hottest debate in SAP shops these days. There has been a slow and steady build up towards SAPu2019s move to Java based development in the last few years with Netweaver. And that seemed to be culminating in SAPu2019s WEBDYNPRO framework which optimizes the MVC paradigm into something most suitable for business application development. Traditional Java developers hitherto using JSPDynpPage or DynPage development for Portal development seem to be smitten by Webdynpro for Java and swear by ease of development of common business applications using Webdynpro for Java. It is apparently robust and high performance. It brings to the Java world the basic tenets of SAPu2019s traditional dynpro programming where the developer strictly works in a module pool framework for PBO and PAI, does simplified coding, and scaling, performance and best practices are implicit in the framework itself. So far so good.
    And then, last year SAP came out with the same framework for ABAP language. Which suddenly seems like natural progression for SAPu2019s ABAP development community - to develop web based business applications within the familiar SE80 environment which also brings to the table all the goodies associated with the Webdynpro framework.
    So as SAP development shops were gearing for significant changes in their skill mix (trying to bring on a mix of Java skills inhouse), suddenly there is a new found hope that afterall, after all the scare and uncertainity of the move towards Java, finally there was a Knight in form of Webdynpro for ABAP that can bring back the glory and stability to ABAP developers career.
    But the question is how to fairly decide how to go about preferring one language to another with the Webdynpro paradigm.
    Why is WEBDYNPRO good for Java development?
    Relatively easy and fast application development as compared to other usual J2EE options via use of visual models/code-editors. Comparable with Java Server Faces (JSF).
    Generated applications independent of different UIs u2013 like Web, Rich-clients, Mobile devices.
    Scalability, robustness and performance are handled by the framework to a large extend
    Code available for reuse and modification
    What is SAPu2019s own take on Webdynpro for Java?
    SAPu2019s is using Webdynpro for Java as a strategic tool to produces robust and highly scalable J2EE architecture applications. SAP is in the process of rewriting Employee Self Service (ESS) and Manager Self Service (MSS) applications using Webdynpro for Java. CRM 5.0 uses this functionality. Important SAP Portal applications like User and Role management transaction, Universal Work List (UWL) use Webdynpro for Java.
    What are the downsides of Webdynpro?
    Framework proprietary to SAP u2013 as opposed to any standard J2EE framework (like Java Server Faces)
    Not complete freedom to design user interface elements as only specific objects and their properties can be manipulated
    Not possible to include application data u2018scripletsu2019 into HTML markup
    Cannot use Javascript, DHTML, etc. - so limited freedom to do frontend screen design (as familiar to web developers)
    Custom Style-sheet integration
    Training implications?
    For Webdynpro for Java - there is a learning curve for Java developers, not to mention a very steep one for ABAP developers
    For Webdynpro for ABAP - its other way around - easier for ABAP developers (especially if they are experts in Object Oriented (OO) ABAP). A Java developer would be wasting time learning Webdynpro for ABAP.
    thanks
    Suresh

  • Will ABAP be completely Replace by JAVA

    Hi Friends,
    Will ABAP be replaced by JAVA in future.
    Or
    Will SAP give more importance to ABAP or JAVA
    If I set my  Business Programming in ABAP, Will it sound
    ever
    Please help in knowing the fact

    hi,
    ABAP can't die because its the easiest development tool . It can be easily seen that if you see development cost ABAP development can be completed in less time as compared to Java.  And SAP is not stopping ABAP but just given an option to develop in java. However it will be good for ABAP Developers to learn java. 
    ABAP is not a replacement for any thing and at the same time no other language is a replacement for ABAP.  FYI, ABAP is no more an ABAP/4. It is widely extended with the introduction of Web Application Server starting from release WAS 620. 
    In Object Oriented Paradigm ABAP is the only langauge that goes very near to all the properties of OOP concepts even comparted to JAVA and C++ starting from release WAS 630. You can developed and extend web applications using ABAP. It is much much more than what we see from R/2 and R/3 3.X releases...
    There is nothing to worry about it. Yes SAP is introducing J2EE platform as an alternate to make an implementation faster as in the market there are many JAVA developers compared to ABAP resources. 
    More than this, ABAP is the SAP proprietary language. Except R/3 kernel, every application/transaction including BASIS is written in ABAP. I don't think SAP is that foolish to replace ABAP with some thing else. Look at the development news in SAP AG official web site for more info. One might need to know Java and JSP for developing mySAP portals but starting from SAP NetWeaver (which is planned to be released officially by the next quarter this year) you can developed 
    heterogeneous portals using ABAP itself... 
    Hope the above clarifies how ABAP is moving a head in the programming era. 
    reward if helpful.
    regards,
    keerthi.

  • ABAP Classes Information.

    Good Afternoon,
    I've never programmed using Classes (Object Oriented) in ABAP but i want to start doing so.
    Right now i'm "surfing" in this huge Class Builder and i can see lots of classes... This looks promissing but the problem is that most of the descriptions of the classes are in German and i do read English, French, Spanish, Italian, but unfortunately not German (for now).
    Where can i find information on how to start developing using classes, also information about the existing classes in ABAP (something like the API Documentation in JAVA, preferably in English), examples of programs developed this way or tutorials, and at last... best practices.
    Every help will be most apreciated.
    Best Regards,
    Pedro Gaspar

    Hi,
    Check This Link
    Hope it Helps
    OO Oriented Concept
    http://www.sapgenie.com/abap/OO/
    http://help.sap.com/saphelp_nw04/helpdata/en/ce/b518b6513611d194a50000e8353423/content.htm
    http://esnips.com/doc/5c65b0dd-eddf-4512-8e32-ecd26735f0f2/prefinalppt.ppt
    http://esnips.com/doc/2c76dc57-e74a-4539-a20e-29383317e804/OO-abap.pdf
    http://esnips.com/doc/0ef39d4b-586a-4637-abbb-e4f69d2d9307/SAP-CONTROLS-WORKSHOP.pdf
    Class
    http://help.sap.com/saphelp_nw04/helpdata/en/ef/d94b78ebf811d295b100a0c94260a5/frameset.htm
    http://help.sap.com/saphelp_nw04/helpdata/en/ef/d94b78ebf811d295b100a0c94260a5/frameset.htm
    Mark HelpFul Answers
    Message was edited by: Manoj Gupta

  • Give me some brief introduction on ABAP

    Hi all
    Give me some brief introduction on ABAP

    Hi
    Welcome to SDN
    ABAP is one of many application-specific fourth-generation languages (4GLs) first developed in the 1980s. It was originally the report language for SAP R/2, a platform that enabled large corporations to build mainframe business applications for materials management and financial and management accounting. ABAP used to be an abbreviation of Allgemeiner Berichtsaufbereitungsprozessor, the German meaning of "generic report preparation processor", but was later renamed to Advanced Business Application Programming. ABAP was one of the first languages to include the concept of Logical Databases (LDBs), which provides a high level of abstraction from the basic database level.
    The ABAP programming language was originally used by SAP developers to develop the SAP R/3 platform. It was also intended to be used by SAP customers to enhance SAP applications – customers can develop custom reports and interfaces with ABAP programming. The language is fairly easy to learn for programmers but it is not a tool for direct use by non-programmers. Good programming skills, including knowledge of relational database design and preferably also of object-oriented concepts, are required to create ABAP programs.
    ABAP remains the language for creating programs for the client-server R/3 system, which SAP first released in 1992. As computer hardware evolved through the 1990s, more and more of SAP's applications and systems were written in ABAP. By 2001, all but the most basic functions were written in ABAP. In 1999, SAP released an object-oriented extension to ABAP called ABAP Objects, along with R/3 release 4.6.
    SAP's most recent development platform, NetWeaver, supports both ABAP and Java.
    Implementation
    Where does the ABAP Program Run?
    All ABAP programs reside inside the SAP database. They are not stored in separate external files like Java or C++ programs. In the database all ABAP code exists in two forms: source code, which can be viewed and edited with the ABAP workbench, and "compiled" code ("generated" code is the more correct technical term), which is loaded and interpreted by the ABAP runtime system. Code generation happens implicitly when a unit of ABAP code is first invoked. If the source code is changed later or if one of the data objects accessed by the program has changed (e.g. fields were added to a database table), then the code is automatically regenerated.
    ABAP programs run in the SAP application server, under control of the runtime system, which is part of the SAP kernel. The runtime system is responsible for processing ABAP statements, controlling the flow logic of screens and responding to events (such as a user clicking on a screen button). A key component of the ABAP runtime system is the Database Interface, which turns database-independent ABAP statements ("Open SQL") into statements understood by the underlying DBMS ("Native SQL"). The database interface handles all the communication with the relational database on behalf of ABAP programs; it also contains extra features such as buffering of frequently accessed data in the local memory of the application server.
    Basis
    Basis sits between ABAP/4 and Operating system.Basis is like an operating system for R/3. It sits between the ABAP/4 code and the computer's operating system. SAP likes to call it middleware because it sits in the middle, between ABAP/4 and the operating system. Basis sits between ABAP/4 and the operating system. ABAP/4 cannot run directly on an operating system. It requires a set of programs (collectively called Basis) to load, interpret, and buffer its input and output. Basis, in some respects, is like the Windows environment. Windows starts up, and while running it provides an environment in which Windows programs can run. Without Windows, programs written for the Windows environment cannot run. Basis is to ABAP/4 programs as Windows is to Windows programs. Basis provides the runtime environment for ABAP/4 programs. Without Basis, ABAP/4 programs cannot run. When the operator starts up R/3, you can think of him as starting up Basis. Basis is a collection of R/3 system programs that present you with an interface. Using this interface the user can start ABAP/4 programs. To install Basis, an installer runs the program r3inst at the command-prompt level of the operating system. Like most installs, this creates a directory structure and copies a set of executables into it. These executables taken together as a unit form Basis.
    To start up the R/3 system, the operator enters the startsap command. The Basis executables start up and stay running, accepting requests from the user to run ABAP/4 programs.
    ABAP/4 programs run within the protective Basis environment; they are not executables that run on the operating system. Instead, Basis reads ABAP/4 code and interprets it into operating system instructions. ABAP/4 programs do not access operating system functions directly. Instead, they use Basis functions to perform file I/O and display data in windows. This level of isolation from the operating system enables ABAP/4 programs to be ported without modification to any system that supports R/3. This buffering is built right into the ABAP/4 language itself and is actually totally transparent to the programmer.
    Basis makes ABAP/4 programs portable. The platforms that R/3 can run on are shown in Table. For example, if you write an ABAP/4 program on Digital UNIX with an Informix database and an OSF/Motif interface, that same program should run without modification on a Windows NT machine with an Oracle database and a Windows 95 interface. Or, it could run on an AS/400 with a DB2 database using OS/2 as the front-end.
    SAP also provides a suite of tools for administering the Basis system. These tools perform tasks such as system performance monitoring, configuration, and system maintenance. To access the Basis administration tools from the main menu, choose the path Tools->Administration.
    Platforms and Databases Supported by R/3
    Operating Systems Supported Hardware Supported Front-Ends Supported Databases
    AIX SINIX IBM SNI SUN Win 3.1/95/NT DB2 for AIX
    SOLARIS HP-UX Digital HP OSF/Motif Informix-Online
    Digital-UNIX Bull OS/2 Oracle 7.1
    Windows NT AT&T Compaq Win 3.1/95/NT Oracle 7.1
    Bull/Zenith OSF/Motif SQL Server 6.0
    HP (Intel) SNI OS/2 ADABAS D
    OS/400 AS/400 Win95 OS/2 DB2/400
    SAP Systems and Landscapes
    All SAP data exists and all SAP software runs in the context of an SAP system. A system consists of a central relational database and one or more application servers ("instances") accessing the data and programs in this database. A SAP system contains at least one instance but may contain more, mostly for reasons of sizing and performance. In a system with multiple instances, load balancing mechanisms ensure that the load is spread evenly over the available application servers.
    Installations of the Web Application Server (landscapes) typically consist of three systems: one for development, one for testing and quality assurance, and one for production. The landscape may contain more systems, e.g. separate systems for unit testing and pre-production testing, or it may contain fewer, e.g. only development and production, without separate QA; nevertheless three is the most common configuration. ABAP programs are created and undergo first testing in the development system. Afterwards they are distributed to the other systems in the landscape. These actions take place under control of the Change and Transport System (CTS), which is responsible for concurrency control (e.g. preventing two developers from changing the same code at the same time), version management and deployment of programs on the QA and production systems.
    The Web Application Server consists of three layers: the database layer, the application layer and the presentation layer. These layers may run on the same or on different physical machines. The database layer contains the relational database and the database software. The application layer contains the instance or instances of the system. All application processes, including the business transactions and the ABAP development, run on the application layer. The presentation layer handles the interaction with users of the system. Online access to ABAP application servers can go via a proprietary graphical interface, the SAPGUI, or via a Web browser.
    Transactions
    We call an execution of an ABAP program using a transaction code a transaction. There are dialog, report, parameter, variant, and as of release 6.10, OO transactions. A transaction is started by entering the transaction code in the input field on the standard toolbar, or by means of the ABAP statements CALL TRANSACTION or LEAVE TO TRANSACTION. Transaction codes can also be linked to screen elements or menu entries. Selecting such an element will start the transaction.
    A transaction code is simply a twenty-character name connected with a Dynpro, another transaction code, or, as of release 6.10, a method of an ABAP program. Transaction codes linked with Dynpros are possible for executable programs, module pools, and function groups. Parameter transactions and variant transactions are linked with other transaction codes. Transaction codes that are linked with methods are allowed for all program types that can contain methods. Transaction codes are maintained in transaction SE93.
    So, a transaction is nothing more than the SAP way of program execution—but why is it called “transaction”? ABAP is a language for business applications and the most important features of business applications were and still are are transactions. Since in the early days of SAP, the execution of a program often meant the same thing as carrying out a business transaction, the terms transaction and transaction code were chosen for program execution. But never mix up the technical meaning of a transaction with business transactions. For business transactions, it is the term LUW (Logical Unit of Work) that counts. And during one transaction (program execution), there can be many different LUW’s.
    Let’s have a look at the different kind of transactions:
    Dialog Transaction
    These are the most common kind of transactions. The transaction code of a dialog transaction is linked to a Dynpro of an ABAP program. When the transaction is called, the respective program is loaded and the Dynpro is called. Therefore, a dialog transaction calls a Dynpro sequence rather than a program. Only during the execution of the Dynpro flow logic are the dialog modules of the ABAP program itself are called. The program flow can differ from execution to execution. You can even assign different dialog transaction codes to one program.
    Parameter Transaction
    In the definition of a parameter transaction code, a dialog transaction is linked with parameters. When you call a parameter transaction, the input fields of the initial Dynpro screen of the dialog transaction are filled with parameters. The display of the initial screen can be inhibited by specifying all mandatory input fields as parameters of the transaction.
    Variant Transaction
    In the definition of a variant transaction code, a dialog transaction is linked with a transaction variant. When a variant transaction is accessed, the dialog transaction is called and executed with the transaction variant. In transaction variants, you can assign default values to the input fields on several Dynpro screens in a transaction, change the attributes of screen elements, and hide entire screens. Transaction variants are maintained in transaction SHD0.
    Report Transaction
    A report transaction is the transaction code wrapping for starting the reporting process. The transaction code of a report transaction must be linked with the selection screen of an executable program. When you execute a report transaction, the runtime environment internally executes the ABAP statement SUBMIT—more to come on that.
    OO Transaction
    A new kind of transaction as of release 6.10. The transaction code of an OO transaction is linked with a method of a local or global class. When the transaction is called, the corresponding program is loaded, for instance methods an object of the class is generated and the method is executed.
    Types of ABAP programs
    In ABAP, there are two different types of programs:
    Report programs(Executable pools)
    A Sample ReportReport programs AKA Executable pools follow a relatively simple programming model whereby a user optionally enters a set of parameters (e.g. a selection over a subset of data) and the program then uses the input parameters to produce a report in the form of an interactive list. The output from the report program is interactive because it is not a passive display; instead it enables the user, through ABAP language constructs, to obtain a more detailed view on specific data records via drill-down functions, or to invoke further processing through menu commands, for instance to sort the data in a different way or to filter the data according to selection criteria. This method of presenting reports has great advantages for users who must deal with large quantities of information and must also have the ability to examine this information in highly flexible ways, without being constrained by the rigid formatting or unmanageable size of "listing-like" reports. The ease with which such interactive reports can be developed is one of the most striking features of the ABAP language.
    The term "report" is somewhat misleading in the sense that it is also possible to create report programs that modify the data in the underlying database instead of simply reading it.
    A customized screen created using Screen Painter,which is one of the tool available in ABAP workbench(T-code = SE51).
    Online programs
    Online programs (also called module pools) do not produce lists. These programs define more complex patterns of user interaction using a collection of screens. The term “screen” refers to the actual, physical image that the users sees. Each screen also has a “flow logic”; this refers to the ABAP code invoked by the screens, i.e. the logic that initializes screens, responds to a user’s requests and controls the sequence between the screens of a module pool. Each screen has its own Flow Logic, which is divided into a "PBO" (Process Before Output) and "PAI" (Process After Input) section. In SAP documentation the term “dynpro” (dynamic program) refers to the combination of the screen and its Flow Logic.
    Online programs are not invoked directly by their name, but are associated with a transaction code. Users can then invoke them through customizable, role-dependent, transaction menus.
    Apart from reports and online programs, it is also possible to develop sharable code units such as class libraries, function libraries and subroutine pools.
    Subroutine Pools
    Subroutine pools, as the name implies, were created to contain selections of subroutines that can be called externally from other programs. Before release 6.10, this was the only way subroutine pools could be used. But besides subroutines, subroutine pools can also contain local classes and interfaces. As of release 6.10, you can connect transaction codes to methods. Therefore, you can now also call subroutine pools via transaction codes. This is the closest to a Java program you can get in ABAP: a subroutine pool with a class containing a method – say – main connected to a transaction code!
    Type Pools
    Type pools are the precursors to general type definitions in the ABAP Dictionary. Before release 4.0, only elementary data types and flat structures could be defined in the ABAP Dictionary. All other types that should’ve been generally available had to be defined with TYPES in type pools. As of release 4.0, type pools were only necessary for constants. As of release 6.40, constants can be declared in the public sections of global classes and type pools can be replaced by global classes.
    Class Pools
    Class pools serve as containers for exactly one global class. Besides the global class, they can contain global types and local classes/interfaces to be used in the global class. A class pool is loaded into memory by using one of its components. For example, a public method can be called from any ABAP program or via a transaction code connected to the method. You maintain class pools in the class builder.
    Interface Pools
    Interface pools serve as containers for exactly one global interface—nothing more and nothing less. You use an interface pool by implementing its interface in classes and by creating reference variables with the type of its interface. You maintain interface pools in the class builder.
    ABAP Workbench
    The ABAP Workbench contains different tools for editing Repository objects. These tools provide you with a wide range of assistance that covers the entire software development cycle. The most important tools for creating and editing Repository objects are:
    ABAP Editor for writing and editing program code
    ABAP Dictionary for processing database table definitions and retrieving global types
    Menu Painter for designing the user interface (menu bar, standard toolbar, application toolbar, function key assignment)
    Screen Painter for designing screens (dynamic programs) for user dialogs
    Function Builder for displaying and processing function modules (routines with defined interfaces that are available throughout the system)
    Class Builder for displaying and processing ABAP Objects classes
    The ABAP Dictionary
    Enforces data integrity
    Manages data definitions without redundancy
    Is tightly integrated with the rest of the ABAP/4 Development Workbench.
    Enforcing data integrity is the process of ensuring that data entered into the system is logical, complete, and consistent. When data integrity rules are defined in the ABAP/4 Dictionary, the system automatically prevents the entry of invalid data. Defining the data integrity rules at the dictionary level means they only have to be defined once, rather than in each program that accesses that data.
    The following are examples of data lacking integrity:
    A date field with a month value of 13
    An order assigned to a customer number that doesn’t exist
    An order not assigned to a customer
    Managing data definitions without redundancy is the process of linking similar information to the same data definition. For example, a customer database is likely to contain a customer’s ID number in several places. The ABAP Dictionary provides the capability of defining the characteristics of a customer ID number in only one place. That central definition then can be used for each instance of a customer ID number.
    The ABAP Dictionary’s integration with the rest of the development environment enables ABAP programs to automatically recognize the names and characteristics of dictionary objects.
    Additionally, the system provides easy navigation between development objects and dictionary definitions. For example, as a programmer, you can double-click on the name of a dictionary object in your program code, and the system will take you directly to the definition of that object in the ABAP/4 Dictionary.
    When a dictionary object is changed, a program that references the changed object will automatically reference the new version the next time the program runs. Because ABAP is interpreted, it is not necessary to recompile programs that reference changed dictionary objects.
    ABAP Syntax
    The syntax of the ABAP programming language consists of the following elements:
    Statements
    An ABAP program consists of individual ABAP statements. Each statement begins with a keyword and ends with a period.
    "Hello World" PROGRAM
    WRITE 'Hello World'.
    This example contains two statements, one on each line. The keywords are PROGRAM and WRITE. The program displays a list on the screen. In this case, the list consists of the line "My First Program".
    The keyword determines the category of the statement. For an overview of the different categories, refer to ABAP Statements.
    Formatting ABAP Statements
    ABAP has no format restrictions. You can enter statements in any format, so a statement can be indented, you can write several statements on one line, or spread a single statement over several lines.
    You must separate words within a statement with at least one space. The system also interprets the end of line marker as a space.
    The program fragment
    PROGRAM TEST.
    WRITE 'This is a statement'.
    could also be written as follows:
    PROGRAM TEST. WRITE 'This is a statement'.
    or as follows:
    PROGRAM
    TEST.
    WRITE
    'This is a statement'.
    Use this free formatting to make your programs easier to understand.
    Special Case: Text Literals
    Text literals are sequences of alphanumeric characters in the program code that are enclosed in quotation marks. If a text literal in an ABAP statement extends across more than one line, the following difficulties can occur:
    All spaces between the quotation marks are interpreted as belonging to the text literal. Letters in text literals in a line that is not concluded with quotation marks are interpreted by the editor as uppercase. If you want to enter text literals that do not fit into a single line, you can use the ‘&’ character to combine a succession of text literals into a single one.
    The program fragment
    PROGRAM TEST.
    WRITE 'This
    is
    a statement'.
    inserts all spaces between the quotation marks into the literal, and converts the letters to uppercase.
    This program fragment
    PROGRAM TEST.
    WRITE 'This' &
    ' is ' &
    'a statement'.
    combines three text literals into one.
    Chained Statements
    The ABAP programming language allows you to concatenate consecutive statements with an identical first part into a chain statement.
    To concatenate a sequence of separate statements, write the identical part only once and place a colon ( after it. After the colon, write the remaining parts of the individual statements, separating them with commas. Ensure that you place a period (.) after the last part to inform the system where the chain ends.
    Statement sequence:
    WRITE SPFLI-CITYFROM.
    WRITE SPFLI-CITYTO.
    WRITE SPFLI-AIRPTO.
    Chain statement:
    WRITE: SPFLI-CITYFROM, SPFLI-CITYTO, SPFLI-AIRPTO.
    In the chain, a colon separates the beginning of the statement from the variable parts. After the colon or commas, you can insert any number of spaces.
    You could, for example, write the same statement like this:
    WRITE: SPFLI-CITYFROM,
    SPFLI-CITYTO,
    SPFLI-AIRPTO.
    In a chain statement, the first part (before the colon) is not limited to the keyword of the statements.
    Statement sequence:
    SUM = SUM + 1.
    SUM = SUM + 2.
    SUM = SUM + 3.
    SUM = SUM + 4.
    Chain statement:
    SUM = SUM + : 1, 2, 3, 4.
    Comments
    Comments are texts that you can write between the statements of your ABAP program to explain their purpose to a reader. Comments are distinguished by the preceding signs * (at the beginning of a line) and " (at any position in a line). If you want the entire line to be a comment, enter an asterisk (*) at the beginning of the line. The system then ignores the entire line when it generates the program. If you want part of a line to be a comment, enter a double quotation mark (") before the comment. The system interprets comments indicated by double quotation marks as spaces.
    PROGRAM SAPMTEST *
    WRITTEN BY KARL BYTE, 06/27/1995 *
    LAST CHANGED BY RITA DIGIT, 10/01/1995 *
    TASK: DEMONSTRATION *
    PROGRAM SAPMTEST.
    DECLARATIONS *
    DATA: FLAG " GLOBAL FLAG
    NUMBER TYPE I " COUNTER
    PROCESSING BLOCKS *
    Advantages of ABAP over Contemporary languages
    ABAP OBJECTS
    Object orientation in ABAP is an extension of the ABAP language that makes available the advantages of object-oriented programming, such as encapsulation, interfaces, and inheritance. This helps to simplify applications and make them more controllable.
    ABAP Objects is fully compatible with the existing language, so you can use existing statements and modularization units in programs that use ABAP Objects, and can also use ABAP Objects in existing ABAP programs.
    ABAP Statements – an Overview
    The first element of an ABAP statement is the ABAP keyword. This determines the category of the statement. The different statement categories are as follows:
    Declarative Statements
    These statements define data types or declare data objects which are used by the other statements in a program or routine. The collected declarative statements in a program or routine make up its declaration part.
    Examples of declarative keywords:
    TYPES, DATA, TABLES
    Modularization Statements
    These statements define the processing blocks in an ABAP program.
    The modularization keywords can be further divided into:
    · Defining keywords
    You use statements containing these keywords to define subroutines, function modules, dialog modules and methods. You conclude these processing blocks using the END statements.
    Examples of definitive keywords:
    METHOD ... ENDMETHOD, FUNCTION ... ENDFUNCTION, MODULE ... ENDMODULE.
    · Event keywords
    You use statements containing these keywords to define event blocks. There are no special statements to conclude processing blocks - they end when the next processing block is introduced.
    Examples of event key words:
    AT SELECTION SCREEN, START-OF-SELECTION, AT USER-COMMAND
    Control Statements
    You use these statements to control the flow of an ABAP program within a processing block according to certain conditions.
    Examples of control keywords:
    IF, WHILE, CASE
    Call Statements
    You use these statements to call processing blocks that you have already defined using modularization statements. The blocks you call can either be in the same ABAP program or in a different program.
    Examples of call keywords:
    CALL METHOD, CALL TRANSACTION, SUBMIT, LEAVE TO
    Operational Statements These keywords process the data that you have defined using declarative statements.
    Examples of operational keywords:
    MOVE, ADD
    Unique Concept of Internal Table in ABAP
    Internal tables provide a means of taking data from a fixed structure and storing it in working memory in ABAP. The data is stored line by line in memory, and each line has the same structure. In ABAP, internal tables fulfill the function of arrays. Since they are dynamic data objects, they save the programmer the task of dynamic memory management in his or her programs. You should use internal tables whenever you want to process a dataset with a fixed structure within a program. A particularly important use for internal tables is for storing and formatting data from a database table within a program. They are also a good way of including very complicated data structures in an ABAP program.
    Like all elements in the ABAP type concept, internal tables can exist both as data types and as data objects A data type is the abstract description of an internal table, either in a program or centrally in the ABAP Dictionary, that you use to create a concrete data object. The data type is also an attribute of an existing data object.
    Internal Tables as Data Types
    Internal tables and structures are the two structured data types in ABAP. The data type of an internal table is fully specified by its line type, key, and table type.
    Line type
    The line type of an internal table can be any data type. The data type of an internal table is normally a structure. Each component of the structure is a column in the internal table. However, the line type may also be elementary or another internal table.
    Key
    The key identifies table rows. There are two kinds of key for internal tables - the standard key and a user-defined key. You can specify whether the key should be UNIQUE or NON-UNIQUE. Internal tables with a unique key cannot contain duplicate entries. The uniqueness depends on the table access method.
    If a table has a structured line type, its default key consists of all of its non-numerical columns that are not references or themselves internal tables. If a table has an elementary line type, the default key is the entire line. The default key of an internal table whose line type is an internal table, the default key is empty.
    The user-defined key can contain any columns of the internal table that are not references or themselves internal tables. Internal tables with a user-defined key are called key tables. When you define the key, the sequence of the key fields is significant. You should remember this, for example, if you intend to sort the table according to the key.
    Table type
    The table type determines how ABAP will access individual table entries. Internal tables can be divided into three types:
    Standard tables have an internal linear index. From a particular size upwards, the indexes of internal tables are administered as trees. In this case, the index administration overhead increases in logarithmic and not linear relation to the number of lines. The system can access records either by using the table index or the key. The response time for key access is proportional to the number of entries in the table. The key of a standard table is always non-unique. You cannot specify a unique key. This means that standard tables can always be filled very quickly, since the system does not have to check whether there are already existing entries.
    Sorted tables are always saved sorted by the key. They also have an internal index. The system can access records either by using the table index or the key. The response time for key access is logarithmically proportional to the number of table entries, since the system uses a binary search. The key of a sorted table can be either unique or non-unique. When you define the table, you must specify whether the key is to be unique or not. Standard tables and sorted tables are known generically as index tables.
    Hashed tables have no linear index. You can only access a hashed table using its key. The response time is independent of the number of table entries, and is constant, since the system access the table entries using a hash algorithm. The key of a hashed table must be unique. When you define the table, you must specify the key as UNIQUE.
    Generic Internal Tables
    Unlike other local data types in programs, you do not have to specify the data type of an internal table fully. Instead, you can specify a generic construction, that is, the key or key and line type of an internal table data type may remain unspecified. You can use generic internal tables to specify the types of field symbols and the interface parameters of procedures . You cannot use them to declare data objects.
    Internal Tables as Dynamic Data Objects
    Data objects that are defined either with the data type of an internal table, or directly as an internal table, are always fully defined in respect of their line type, key and access method. However, the number of lines is not fixed. Thus internal tables are dynamic data objects, since they can contain any number of lines of a particular type. The only restriction on the number of lines an internal table may contain are the limits of your system installation. The maximum memory that can be occupied by an internal table (including its internal administration) is 2 gigabytes. A more realistic figure is up to 500 megabytes. An additional restriction for hashed tables is that they may not contain more than 2 million entries. The line types of internal tables can be any ABAP data types - elementary, structured, or internal tables. The individual lines of an internal table are called table lines or table entries. Each component of a structured line is called a column in the internal table.
    Choosing a Table Type
    The table type (and particularly the access method) that you will use depends on how the typical internal table operations will be most frequently executed.
    Standard tables
    This is the most appropriate type if you are going to address the individual table entries using the index. Index access is the quickest possible access. You should fill a standard table by appending lines (ABAP APPEND statement), and read, modify and delete entries by specifying the index (INDEX option with the relevant ABAP command). The access time for a standard table increases in a linear relationship with the number of table entries. If you need key access, standard tables are particularly useful if you can fill and process the table in separate steps. For example, you could fill the table by appending entries, and then sort it. If you use the binary search option with key access, the response time is logarithmically proportional to the number of table entries.
    Sorted tables
    This is the most appropriate type if you need a table which is sorted as you fill it. You fill sorted tables using the INSERT statement. Entries are inserted according to the sort sequence defined through the table key. Any illegal entries are recognized as soon as you try to add them to the table. The response time for key access is logarithmically proportional to the number of table entries, since the system always uses a binary search. Sorted tables are particularly useful for partially sequential processing in a LOOP if you specify the beginning of the table key in the WHERE condition.
    Hashed tables
    This is the most appropriate type for any table where the main operation is key access. You cannot access a hashed table using its index. The response time for key access remains constant, regardless of the number of table entries. Like database tables, hashed tables always have a unique key. Hashed tables are useful if you want to construct and use an internal table which resembles a database table or for processing large amounts of data.
    Advanced Topics
    Batch Input: Concepts
    Processing Sessions
    The above figure shows how a batch input session works.A batch input session is a set of one or more calls to transactions along with the data to be processed by the transactions. The system normally executes the transactions in a session non-interactively, allowing rapid entry of bulk data into an R/3 System.
    A session records transactions and data in a special format that can be interpreted by the R/3 System. When the System reads a session, it uses the data in the session to simulate on-line entry of transactions and data. The System can call transactions and enter data using most of the facilities that are available to interactive users.
    For example, the data that a session enters into transaction screens is subject to the same consistency checking as in normal interactive operation. Further, batch input sessions are subject to the user-based authorization checking that is performed by the system.
    Advantages of ABAP over Contemporary languages
    ABAP Objects offers a number of advantages, even if you want to continue using procedural programming. If you want to use new ABAP features, you have to use object-oriented interfaces anyway.
    Sharing Data: With ABAP shared objects, you can aggregate data once at a central location and the different users and programs can then access this data without the need for copying.
    Exception Handling: With the class-based exception concept of ABAP, you can define a special control flow for a specific error situation and provide the user with information about the error.
    Developing Persistency: For permanent storage of data in ABAP, you use relational database tables by means of database-independent Open SQL, which is integrated in ABAP. However, you can also store selected objects transparently or access the integrated database or other databases using proprietary SQL.
    Connectivity and Interoperability: The Exchange Infrastructure and Web services are the means by which developers can implement a service-oriented architecture. With Web services, you can provide and consume services independently of implementation or protocol. Furthermore, you can do so within NetWeaver and in the communication with other systems. With the features of the Exchange Infrastructure, you can enable, manage, and adapt integration scenarios between systems.
    Making Enhancements: With the Enhancement Framework, you can enhance programs, function modules, and global classes without modification as well as replace existing code. The Switch Framework enables you activate only specific development objects or enhancements in a system.
    Considerable Aspects
    It follows a list of aspects to be considered during development. The list of course is not complete.
    Dynpro persistence
    When implementing dynpros one has to care for himself to read out and persist the necessary fields. Recently it happened to me that I forgot to include a field into the UPDATE-clause which is an error not so easy to uncover if you have other problems to be solved in the same package. Here, tool-support or built-in mechanisms would help.
    The developer could help himself out by creating something like a document containing a cookbook or guide in which parts of a dynpro logic one has to care about persistence. With that at hand, it would be quite easy finding those bugs in short time. Maybe a report scanning for the definition of the dynpro fields to be persisted could scan the code automatically, too.
    Memory Cache
    It should be common-sense that avoiding select-statements onto the database helps reducing the server load. For that the programmer either can resort to function modules if available. This maybe is the case for important tables. Or the programmer needs to implement his own logic using internal tables. Here, the standard software package could provide the developer with a tool or a mechanism auto-generating memory cached tables resp. function modules implementing this.
    Sometimes buffering of database tables could be used, if applicable. But that would require an effort in customizing the system and could drain down system performance overall, especially if a table is involved that has a central role.
    Interfaces
    It should be noticed that some function modules available have an incomplete interface. That means, the interface does not include all parameters evaluated by the logic of the function module. For example, global variables from within the function group could be read out, which cannot be influenced by the general caller. Or memory parameters are used internally to feed the logic with further information.
    One workaround here would be copying the relevant parts of the logic to a newly created function module and then adapt it to the own context. This sometimes is possible, maybe if the copied code is not too lengthy and only a few or no calls to other logic is part of it.
    A modification of the SAP code could be considered, if the modification itself is unavoidable (or another solution would be not justifiable by estimated effort to spend on it) and if the location of the modification seems quite safe against future upgrades or hot fixes. The latter is something that could be evaluated by contacting the SAP hotline or working with OSS message (searching thru existing one, perhaps open a new one).
    Example
    'From SAP NetWeaver:'
    set an exclusive lock at level object-type & object-id
    IF NOT lf_bapi_error = true.
    IF ( NOT istourhd-doc_type IS INITIAL ) AND
    ( NOT istourhd-doc_id IS INITIAL )
    CALL FUNCTION 'ENQUEUE_/DSD/E_HH_RAREF'
    EXPORTING
    obj_typ = istourhd-doc_type
    obj_id = istourhd-doc_id
    EXCEPTIONS
    foreign_lock = 1
    system_failure = 2
    OTHERS = 3.
    IF sy-subrc <> 0.
    terminate processing...
    lf_bapi_error = true.—
    ...and add message to return table
    PERFORM set_msg_to_bapiret2
    USING sy-msgid gc_abort sy-msgno
    sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4
    gc_istourhd gc_enqueue_refdoc space
    CHANGING lt_return.
    ENDIF.
    ENDIF.
    ENDIF. " bapi error
    Example Report(Type - ALV(Advanced List Viewer))
    REPORT Z_ALV_SIMPLE_EXAMPLE_WITH_ITAB .
    *Simple example to use ALV and to define the ALV data in an internal
    *table
    *data definition
    tables:
    marav. "Table MARA and table MAKT
    Data to be displayed in ALV
    Using the following syntax, REUSE_ALV_FIELDCATALOG_MERGE can auto-
    matically determine the fieldstructure from this source program
    Data:
    begin of imat occurs 100,
    matnr like marav-matnr, "Material number
    maktx like marav-maktx, "Material short text
    matkl like marav-matkl, "Material group (so you can test to make
    " intermediate sums)
    ntgew like marav-ntgew, "Net weight, numeric field (so you can test to
    "make sums)
    gewei like marav-gewei, "weight unit (just to be complete)
    end of imat.
    Other data needed
    field to store report name
    data i_repid like sy-repid.
    field to check table length
    data i_lines like sy-tabix.
    Data for ALV display
    TYPE-POOLS: SLIS.
    data int_fcat type SLIS_T_FIELDCAT_ALV.
    select-options:
    s_matnr for marav-matnr matchcode object MAT1.
    start-of-selection.
    read data into table imat
    select * from marav
    into corresponding fields of table imat
    where
    matnr in s_matnr.
    Check if material was found
    clear i_lines.
    describe table imat lines i_lines.
    if i_lines lt 1.
    Using hardcoded write here for easy upload
    write: /
    'No materials found.'.
    exit.
    endif.
    end-of-selection.
    To use ALV, we need a DDIC-structure or a thing called Fieldcatalogue.
    The fieldcatalouge can be generated by FUNCTION
    'REUSE_ALV_FIELDCATALOG_MERGE' from an internal table from any
    report source, including this report.
    Store report name
    i_repid = sy-repid.
    Create Fieldcatalogue from internal table
    CALL FUNCTION 'REUSE_ALV_FIELDCATALOG_MERGE'
    EXPORTING
    I_PROGRAM_NAME = i_repid
    I_INTERNAL_TABNAME = 'IMAT' "capital letters!
    I_INCLNAME = i_repid
    CHANGING
    CT_FIELDCAT = int_fcat
    EXCEPTIONS
    INCONSISTENT_INTERFACE = 1
    PROGRAM_ERROR = 2
    OTHERS = 3.
    *explanations:
    I_PROGRAM_NAME is the program which calls this function
    I_INTERNAL_TABNAME is the name of the internal table which you want
    to display in ALV
    I_INCLNAME is the ABAP-source where the internal table is defined
    (DATA....)
    CT_FIELDCAT contains the Fieldcatalouge that we need later for
    ALV display
    IF SY-SUBRC <> 0.
    write: /
    'Returncode',
    sy-subrc,
    'from FUNCTION REUSE_ALV_FIELDCATALOG_MERGE'.
    ENDIF.
    *This was the fieldcatlogue
    Call for ALV list display
    CALL FUNCTION 'REUSE_ALV_LIST_DISPLAY'
    EXPORTING
    I_CALLBACK_PROGRAM = i_repid
    IT_FIELDCAT = int_fcat
    TABLES
    T_OUTTAB = imat
    EXCEPTIONS
    PROGRAM_ERROR = 1
    OTHERS = 2.
    *explanations:
    I_CALLBACK_PROGRAM is the program which calls this function
    IT_FIELDCAT (just made by REUSE_ALV_FIELDCATALOG_MERGE) contains
    now the data definition needed for display
    I_SAVE allows the user to save his own layouts
    T_OUTTAB contains the data to be displayed in ALV
    IF SY-SUBRC <> 0.
    write: /
    'Returncode',
    sy-subrc,
    'from FUNCTION REUSE_ALV_LIST_DISPLAY'.
    ENDIF.
    Reward points for useful Answers
    Regards
    Anji

  • Differences between Procedural ABAP and OOPs ABAP

    Hi Friends,
    Can any one explain the differences between Procedural ABAP and OOPs ABAP in brief ? pls explain the most important ( atleast 3 or 4 points ). pls don't give me any other links, i will appreciate for good responses... and will be awarded with full points...
    Thanks and Regards
    Vijaya

    Hi
    Core ABAP (procedural) works with Event driven, subroutine driven one
    OOPS ABAP works on the OOPS concepts like Inheritance, polymorphism,abstraction and encapsulation.
    see the doc
    ABAP is one of many application-specific fourth-generation languages (4GLs) first developed in the 1980s. It was originally the report language for SAP R/2, a platform that enabled large corporations to build mainframe business applications for materials management and financial and management accounting. ABAP used to be an abbreviation of Allgemeiner Berichtsaufbereitungsprozessor, the German meaning of "generic report preparation processor", but was later renamed to Advanced Business Application Programming. ABAP was one of the first languages to include the concept of Logical Databases (LDBs), which provides a high level of abstraction from the basic database level.
    The ABAP programming language was originally used by SAP developers to develop the SAP R/3 platform. It was also intended to be used by SAP customers to enhance SAP applications – customers can develop custom reports and interfaces with ABAP programming. The language is fairly easy to learn for programmers but it is not a tool for direct use by non-programmers. Good programming skills, including knowledge of relational database design and preferably also of object-oriented concepts, are required to create ABAP programs.
    ABAP remains the language for creating programs for the client-server R/3 system, which SAP first released in 1992. As computer hardware evolved through the 1990s, more and more of SAP's applications and systems were written in ABAP. By 2001, all but the most basic functions were written in ABAP. In 1999, SAP released an object-oriented extension to ABAP called ABAP Objects, along with R/3 release 4.6.
    SAP's most recent development platform, NetWeaver, supports both ABAP and Java.
    Implementation
    Where does the ABAP Program Run?
    All ABAP programs reside inside the SAP database. They are not stored in separate external files like Java or C++ programs. In the database all ABAP code exists in two forms: source code, which can be viewed and edited with the ABAP workbench, and "compiled" code ("generated" code is the more correct technical term), which is loaded and interpreted by the ABAP runtime system. Code generation happens implicitly when a unit of ABAP code is first invoked. If the source code is changed later or if one of the data objects accessed by the program has changed (e.g. fields were added to a database table), then the code is automatically regenerated.
    ABAP programs run in the SAP application server, under control of the runtime system, which is part of the SAP kernel. The runtime system is responsible for processing ABAP statements, controlling the flow logic of screens and responding to events (such as a user clicking on a screen button). A key component of the ABAP runtime system is the Database Interface, which turns database-independent ABAP statements ("Open SQL") into statements understood by the underlying DBMS ("Native SQL"). The database interface handles all the communication with the relational database on behalf of ABAP programs; it also contains extra features such as buffering of frequently accessed data in the local memory of the application server.
    Basis
    Basis sits between ABAP/4 and Operating system.Basis is like an operating system for R/3. It sits between the ABAP/4 code and the computer's operating system. SAP likes to call it middleware because it sits in the middle, between ABAP/4 and the operating system. Basis sits between ABAP/4 and the operating system. ABAP/4 cannot run directly on an operating system. It requires a set of programs (collectively called Basis) to load, interpret, and buffer its input and output. Basis, in some respects, is like the Windows environment. Windows starts up, and while running it provides an environment in which Windows programs can run. Without Windows, programs written for the Windows environment cannot run. Basis is to ABAP/4 programs as Windows is to Windows programs. Basis provides the runtime environment for ABAP/4 programs. Without Basis, ABAP/4 programs cannot run. When the operator starts up R/3, you can think of him as starting up Basis. Basis is a collection of R/3 system programs that present you with an interface. Using this interface the user can start ABAP/4 programs. To install Basis, an installer runs the program r3inst at the command-prompt level of the operating system. Like most installs, this creates a directory structure and copies a set of executables into it. These executables taken together as a unit form Basis.
    To start up the R/3 system, the operator enters the startsap command. The Basis executables start up and stay running, accepting requests from the user to run ABAP/4 programs.
    ABAP/4 programs run within the protective Basis environment; they are not executables that run on the operating system. Instead, Basis reads ABAP/4 code and interprets it into operating system instructions. ABAP/4 programs do not access operating system functions directly. Instead, they use Basis functions to perform file I/O and display data in windows. This level of isolation from the operating system enables ABAP/4 programs to be ported without modification to any system that supports R/3. This buffering is built right into the ABAP/4 language itself and is actually totally transparent to the programmer.
    Basis makes ABAP/4 programs portable. The platforms that R/3 can run on are shown in Table. For example, if you write an ABAP/4 program on Digital UNIX with an Informix database and an OSF/Motif interface, that same program should run without modification on a Windows NT machine with an Oracle database and a Windows 95 interface. Or, it could run on an AS/400 with a DB2 database using OS/2 as the front-end.
    SAP also provides a suite of tools for administering the Basis system. These tools perform tasks such as system performance monitoring, configuration, and system maintenance. To access the Basis administration tools from the main menu, choose the path Tools->Administration.
    Platforms and Databases Supported by R/3
    Operating Systems Supported Hardware Supported Front-Ends Supported Databases
    AIX SINIX IBM SNI SUN Win 3.1/95/NT DB2 for AIX
    SOLARIS HP-UX Digital HP OSF/Motif Informix-Online
    Digital-UNIX Bull OS/2 Oracle 7.1
    Windows NT AT&T Compaq Win 3.1/95/NT Oracle 7.1
    Bull/Zenith OSF/Motif SQL Server 6.0
    HP (Intel) SNI OS/2 ADABAS D
    OS/400 AS/400 Win95 OS/2 DB2/400
    SAP Systems and Landscapes
    All SAP data exists and all SAP software runs in the context of an SAP system. A system consists of a central relational database and one or more application servers ("instances") accessing the data and programs in this database. A SAP system contains at least one instance but may contain more, mostly for reasons of sizing and performance. In a system with multiple instances, load balancing mechanisms ensure that the load is spread evenly over the available application servers.
    Installations of the Web Application Server (landscapes) typically consist of three systems: one for development, one for testing and quality assurance, and one for production. The landscape may contain more systems, e.g. separate systems for unit testing and pre-production testing, or it may contain fewer, e.g. only development and production, without separate QA; nevertheless three is the most common configuration. ABAP programs are created and undergo first testing in the development system. Afterwards they are distributed to the other systems in the landscape. These actions take place under control of the Change and Transport System (CTS), which is responsible for concurrency control (e.g. preventing two developers from changing the same code at the same time), version management and deployment of programs on the QA and production systems.
    The Web Application Server consists of three layers: the database layer, the application layer and the presentation layer. These layers may run on the same or on different physical machines. The database layer contains the relational database and the database software. The application layer contains the instance or instances of the system. All application processes, including the business transactions and the ABAP development, run on the application layer. The presentation layer handles the interaction with users of the system. Online access to ABAP application servers can go via a proprietary graphical interface, the SAPGUI, or via a Web browser.
    Transactions
    We call an execution of an ABAP program using a transaction code a transaction. There are dialog, report, parameter, variant, and as of release 6.10, OO transactions. A transaction is started by entering the transaction code in the input field on the standard toolbar, or by means of the ABAP statements CALL TRANSACTION or LEAVE TO TRANSACTION. Transaction codes can also be linked to screen elements or menu entries. Selecting such an element will start the transaction.
    A transaction code is simply a twenty-character name connected with a Dynpro, another transaction code, or, as of release 6.10, a method of an ABAP program. Transaction codes linked with Dynpros are possible for executable programs, module pools, and function groups. Parameter transactions and variant transactions are linked with other transaction codes. Transaction codes that are linked with methods are allowed for all program types that can contain methods. Transaction codes are maintained in transaction SE93.
    So, a transaction is nothing more than the SAP way of program execution—but why is it called “transaction”? ABAP is a language for business applications and the most important features of business applications were and still are are transactions. Since in the early days of SAP, the execution of a program often meant the same thing as carrying out a business transaction, the terms transaction and transaction code were chosen for program execution. But never mix up the technical meaning of a transaction with business transactions. For business transactions, it is the term LUW (Logical Unit of Work) that counts. And during one transaction (program execution), there can be many different LUW’s.
    Let’s have a look at the different kind of transactions:
    Dialog Transaction
    These are the most common kind of transactions. The transaction code of a dialog transaction is linked to a Dynpro of an ABAP program. When the transaction is called, the respective program is loaded and the Dynpro is called. Therefore, a dialog transaction calls a Dynpro sequence rather than a program. Only during the execution of the Dynpro flow logic are the dialog modules of the ABAP program itself are called. The program flow can differ from execution to execution. You can even assign different dialog transaction codes to one program.
    Parameter Transaction
    In the definition of a parameter transaction code, a dialog transaction is linked with parameters. When you call a parameter transaction, the input fields of the initial Dynpro screen of the dialog transaction are filled with parameters. The display of the initial screen can be inhibited by specifying all mandatory input fields as parameters of the transaction.
    Variant Transaction
    In the definition of a variant transaction code, a dialog transaction is linked with a transaction variant. When a variant transaction is accessed, the dialog transaction is called and executed with the transaction variant. In transaction variants, you can assign default values to the input fields on several Dynpro screens in a transaction, change the attributes of screen elements, and hide entire screens. Transaction variants are maintained in transaction SHD0.
    Report Transaction
    A report transaction is the transaction code wrapping for starting the reporting process. The transaction code of a report transaction must be linked with the selection screen of an executable program. When you execute a report transaction, the runtime environment internally executes the ABAP statement SUBMIT—more to come on that.
    OO Transaction
    A new kind of transaction as of release 6.10. The transaction code of an OO transaction is linked with a method of a local or global class. When the transaction is called, the corresponding program is loaded, for instance methods an object of the class is generated and the method is executed.
    Types of ABAP programs
    In ABAP, there are two different types of programs:
    Report programs(Executable pools)
    A Sample ReportReport programs AKA Executable pools follow a relatively simple programming model whereby a user optionally enters a set of parameters (e.g. a selection over a subset of data) and the program then uses the input parameters to produce a report in the form of an interactive list. The output from the report program is interactive because it is not a passive display; instead it enables the user, through ABAP language constructs, to obtain a more detailed view on specific data records via drill-down functions, or to invoke further processing through menu commands, for instance to sort the data in a different way or to filter the data according to selection criteria. This method of presenting reports has great advantages for users who must deal with large quantities of information and must also have the ability to examine this information in highly flexible ways, without being constrained by the rigid formatting or unmanageable size of "listing-like" reports. The ease with which such interactive reports can be developed is one of the most striking features of the ABAP language.
    The term "report" is somewhat misleading in the sense that it is also possible to create report programs that modify the data in the underlying database instead of simply reading it.
    A customized screen created using Screen Painter,which is one of the tool available in ABAP workbench(T-code = SE51).
    Online programs
    Online programs (also called module pools) do not produce lists. These programs define more complex patterns of user interaction using a collection of screens. The term “screen” refers to the actual, physical image that the users sees. Each screen also has a “flow logic”; this refers to the ABAP code invoked by the screens, i.e. the logic that initializes screens, responds to a user’s requests and controls the sequence between the screens of a module pool. Each screen has its own Flow Logic, which is divided into a "PBO" (Process Before Output) and "PAI" (Process After Input) section. In SAP documentation the term “dynpro” (dynamic program) refers to the combination of the screen and its Flow Logic.
    Online programs are not invoked directly by their name, but are associated with a transaction code. Users can then invoke them through customizable, role-dependent, transaction menus.
    Apart from reports and online programs, it is also possible to develop sharable code units such as class libraries, function libraries and subroutine pools.
    Subroutine Pools
    Subroutine pools, as the name implies, were created to contain selections of subroutines that can be called externally from other programs. Before release 6.10, this was the only way subroutine pools could be used. But besides subroutines, subroutine pools can also contain local classes and interfaces. As of release 6.10, you can connect transaction codes to methods. Therefore, you can now also call subroutine pools via transaction codes. This is the closest to a Java program you can get in ABAP: a subroutine pool with a class containing a method – say – main connected to a transaction code!
    Type Pools
    Type pools are the precursors to general type definitions in the ABAP Dictionary. Before release 4.0, only elementary data types and flat structures could be defined in the ABAP Dictionary. All other types that should’ve been generally available had to be defined with TYPES in type pools. As of release 4.0, type pools were only necessary for constants. As of release 6.40, constants can be declared in the public sections of global classes and type pools can be replaced by global classes.
    Class Pools
    Class pools serve as containers for exactly one global class. Besides the global class, they can contain global types and local classes/interfaces to be used in the global class. A class pool is loaded into memory by using one of its components. For example, a public method can be called from any ABAP program or via a transaction code connected to the method. You maintain class pools in the class builder.
    Interface Pools
    Interface pools serve as containers for exactly one global interface—nothing more and nothing less. You use an interface pool by implementing its interface in classes and by creating reference variables with the type of its interface. You maintain interface pools in the class builder.
    ABAP Workbench
    The ABAP Workbench contains different tools for editing Repository objects. These tools provide you with a wide range of assistance that covers the entire software development cycle. The most important tools for creating and editing Repository objects are:
    ABAP Editor for writing and editing program code
    ABAP Dictionary for processing database table definitions and retrieving global types
    Menu Painter for designing the user interface (menu bar, standard toolbar, application toolbar, function key assignment)
    Screen Painter for designing screens (dynamic programs) for user dialogs
    Function Builder for displaying and processing function modules (routines with defined interfaces that are available throughout the system)
    Class Builder for displaying and processing ABAP Objects classes
    The ABAP Dictionary
    Enforces data integrity
    Manages data definitions without redundancy
    Is tightly integrated with the rest of the ABAP/4 Development Workbench.
    Enforcing data integrity is the process of ensuring that data entered into the system is logical, complete, and consistent. When data integrity rules are defined in the ABAP/4 Dictionary, the system automatically prevents the entry of invalid data. Defining the data integrity rules at the dictionary level means they only have to be defined once, rather than in each program that accesses that data.
    The following are examples of data lacking integrity:
    A date field with a month value of 13
    An order assigned to a customer number that doesn’t exist
    An order not assigned to a customer
    Managing data definitions without redundancy is the process of linking similar information to the same data definition. For example, a customer database is likely to contain a customer’s ID number in several places. The ABAP Dictionary provides the capability of defining the characteristics of a customer ID number in only one place. That central definition then can be used for each instance of a customer ID number.
    The ABAP Dictionary’s integration with the rest of the development environment enables ABAP programs to automatically recognize the names and characteristics of dictionary objects.
    Additionally, the system provides easy navigation between development objects and dictionary definitions. For example, as a programmer, you can double-click on the name of a dictionary object in your program code, and the system will take you directly to the definition of that object in the ABAP/4 Dictionary.
    When a dictionary object is changed, a program that references the changed object will automatically reference the new version the next time the program runs. Because ABAP is interpreted, it is not necessary to recompile programs that reference changed dictionary objects.
    ABAP Syntax
    The syntax of the ABAP programming language consists of the following elements:
    Statements
    An ABAP program consists of individual ABAP statements. Each statement begins with a keyword and ends with a period.
    "Hello World" PROGRAM
    WRITE 'Hello World'.
    This example contains two statements, one on each line. The keywords are PROGRAM and WRITE. The program displays a list on the screen. In this case, the list consists of the line "My First Program".
    The keyword determines the category of the statement. For an overview of the different categories, refer to ABAP Statements.
    Formatting ABAP Statements
    ABAP has no format restrictions. You can enter statements in any format, so a statement can be indented, you can write several statements on one line, or spread a single statement over several lines.
    You must separate words within a statement with at least one space. The system also interprets the end of line marker as a space.
    The program fragment
    PROGRAM TEST.
    WRITE 'This is a statement'.
    could also be written as follows:
    PROGRAM TEST. WRITE 'This is a statement'.
    or as follows:
    PROGRAM
    TEST.
    WRITE
    'This is a statement'.
    Use this free formatting to make your programs easier to understand.
    Special Case: Text Literals
    Text literals are sequences of alphanumeric characters in the program code that are enclosed in quotation marks. If a text literal in an ABAP statement extends across more than one line, the following difficulties can occur:
    All spaces between the quotation marks are interpreted as belonging to the text literal. Letters in text literals in a line that is not concluded with quotation marks are interpreted by the editor as uppercase. If you want to enter text literals that do not fit into a single line, you can use the ‘&’ character to combine a succession of text literals into a single one.
    The program fragment
    PROGRAM TEST.
    WRITE 'This
    is
    a statement'.
    inserts all spaces between the quotation marks into the literal, and converts the letters to uppercase.
    This program fragment
    PROGRAM TEST.
    WRITE 'This' &
    ' is ' &
    'a statement'.
    combines three text literals into one.
    Chained Statements
    The ABAP programming language allows you to concatenate consecutive statements with an identical first part into a chain statement.
    To concatenate a sequence of separate statements, write the identical part only once and place a colon ( after it. After the colon, write the remaining parts of the individual statements, separating them with commas. Ensure that you place a period (.) after the last part to inform the system where the chain ends.
    Statement sequence:
    WRITE SPFLI-CITYFROM.
    WRITE SPFLI-CITYTO.
    WRITE SPFLI-AIRPTO.
    Chain statement:
    WRITE: SPFLI-CITYFROM, SPFLI-CITYTO, SPFLI-AIRPTO.
    In the chain, a colon separates the beginning of the statement from the variable parts. After the colon or commas, you can insert any number of spaces.
    You could, for example, write the same statement like this:
    WRITE: SPFLI-CITYFROM,
    SPFLI-CITYTO,
    SPFLI-AIRPTO.
    In a chain statement, the first part (before the colon) is not limited to the keyword of the statements.
    Statement sequence:
    SUM = SUM + 1.
    SUM = SUM + 2.
    SUM = SUM + 3.
    SUM = SUM + 4.
    Chain statement:
    SUM = SUM + : 1, 2, 3, 4.
    Comments
    Comments are texts that you can write between the statements of your ABAP program to explain their purpose to a reader. Comments are distinguished by the preceding signs * (at the beginning of a line) and " (at any position in a line). If you want the entire line to be a comment, enter an asterisk (*) at the beginning of the line. The system then ignores the entire line when it generates the program. If you want part of a line to be a comment, enter a double quotation mark (") before the comment. The system interprets comments indicated by double quotation marks as spaces.
    PROGRAM SAPMTEST *
    WRITTEN BY KARL BYTE, 06/27/1995 *
    LAST CHANGED BY RITA DIGIT, 10/01/1995 *
    TASK: DEMONSTRATION *
    PROGRAM SAPMTEST.
    DECLARATIONS *
    DATA: FLAG " GLOBAL FLAG
    NUMBER TYPE I " COUNTER
    PROCESSING BLOCKS *
    Advantages of ABAP over Contemporary languages
    ABAP OBJECTS
    Object orientation in ABAP is an extension of the ABAP language that makes available the advantages of object-oriented programming, such as encapsulation, interfaces, and inheritance. This helps to simplify applications and make them more controllable.
    ABAP Objects is fully compatible with the existing language, so you can use existing statements and modularization units in programs that use ABAP Objects, and can also use ABAP Objects in existing ABAP programs.
    ABAP Statements – an Overview
    The first element of an ABAP statement is the ABAP keyword. This determines the category of the statement. The different statement categories are as follows:
    Declarative Statements
    These statements define data types or declare data objects which are used by the other statements in a program or routine. The collected declarative statements in a program or routine make up its declaration part.
    Examples of declarative keywords:
    TYPES, DATA, TABLES
    Modularization Statements
    These statements define the processing blocks in an ABAP program.
    The modularization keywords can be further divided into:
    · Defining keywords
    You use statements containing these keywords to define subroutines, function modules, dialog modules and methods. You conclude these processing blocks using the END statements.
    Examples of definitive keywords:
    METHOD ... ENDMETHOD, FUNCTION ... ENDFUNCTION, MODULE ... ENDMODULE.
    · Event keywords
    You use statements containing these keywords to define event blocks. There are no special statements to conclude processing blocks - they end when the next processing block is introduced.
    Examples of event key words:
    AT SELECTION SCREEN, START-OF-SELECTION, AT USER-COMMAND
    Control Statements
    You use these statements to control the flow of an ABAP program within a processing block according to certain conditions.
    Examples of control keywords:
    IF, WHILE, CASE
    Call Statements
    You use these statements to call processing blocks that you have already defined using modularization statements. The blocks you call can either be in the same ABAP program or in a different program.
    Examples of call keywords:
    CALL METHOD, CALL TRANSACTION, SUBMIT, LEAVE TO
    Operational Statements These keywords process the data that you have defined using declarative statements.
    Examples of operational keywords:
    MOVE, ADD
    Unique Concept of Internal Table in ABAP
    Internal tables provide a means of taking data from a fixed structure and storing it in working memory in ABAP. The data is stored line by line in memory, and each line has the same structure. In ABAP, internal tables fulfill the function of arrays. Since they are dynamic data objects, they save the programmer the task of dynamic memory management in his or her programs. You should use internal tables whenever you want to process a dataset with a fixed structure within a program. A particularly important use for internal tables is for storing and formatting data from a database table within a program. They are also a good way of including very complicated data structures in an ABAP program.
    Like all elements in the ABAP type concept, internal tables can exist both as data types and as data objects A data type is the abstract description of an internal table, either in a program or centrally in the ABAP Dictionary, that you use to create a concrete data object. The data type is also an attribute of an existing data object.
    Internal Tables as Data Types
    Internal tables and structures are the two structured data types in ABAP. The data type of an internal table is fully specified by its line type, key, and table type.
    Line type
    The line type of an internal table can be any data type. The data type of an internal table is normally a structure. Each component of the structure is a column in the internal table. However, the line type may also be elementary or another internal table.
    Key
    The key identifies table rows. There are two kinds of key for internal tables - the standard key and a user-defined key. You can specify whether the key should be UNIQUE or NON-UNIQUE. Internal tables with a unique key cannot contain duplicate entries. The uniqueness depends on the table access method.
    If a table has a structured line type, its default key consists of all of its non-numerical columns that are not references or themselves internal tables. If a table has an elementary line type, the default key is the entire line. The default key of an internal table whose line type is an internal table, the default key is empty.
    The user-defined key can contain any columns of the internal table that are not references or themselves internal tables. Internal tables with a user-defined key are called key tables. When you define the key, the sequence of the key fields is significant. You should remember this, for example, if you intend to sort the table according to the key.
    Table type
    The table type determines how ABAP will access individual table entries. Internal tables can be divided into three types:
    Standard tables have an internal linear index. From a particular size upwards, the indexes of internal tables are administered as trees. In this case, the index administration overhead increases in logarithmic and not linear relation to the number of lines. The system can access records either by using the table index or the key. The response time for key access is proportional to the number of entries in the table. The key of a standard table is always non-unique. You cannot specify a unique key. This means that standard tables can always be filled very quickly, since the system does not have to check whether there are already existing entries.
    Sorted tables are always saved sorted by the key. They also have an internal index. The system can access records either by using the table index or the key. The response time for key access is logarithmically proportional to the number of table entries, since the system uses a binary search. The key of a sorted table can be either unique or non-unique. When you define the table, you must specify whether the key is to be unique or not. Standard tables and sorted tables are known generically as index tables.
    Hashed tables have no linear index. You can only access a hashed table using its key. The response time is independent of the number of table entries, and is constant, since the system access the table entries using a hash algorithm. The key of a hashed table must be unique. When you define the table, you must specify the key as UNIQUE.
    Generic Internal Tables
    Unlike other local data types in programs, you do not have to specify the data type of an internal table fully. Instead, you can specify a generic construction, that is, the key or key and line type of an internal table data type may remain unspecified. You can use generic internal tables to specify the types of field symbols and the interface parameters of procedures . You cannot use them to declare data objects.
    Internal Tables as Dynamic Data Objects
    Data objects that are defined either with the data type of an internal table, or directly as an internal table, are always fully defined in respect of their line type, key and access method. However, the number of lines is not fixed. Thus internal tables are dynamic data objects, since they can contain any number of lines of a particular type. The only restriction on the number of lines an internal table may contain are the limits of your system installation. The maximum memory that can be occupied by an internal table (including its internal administration) is 2 gigabytes. A more realistic figure is up to 500 megabytes. An additional restriction for hashed tables is that they may not contain more than 2 million entries. The line types of internal tables can be any ABAP data types - elementary, structured, or internal tables. The individual lines of an internal table are called table lines or table entries. Each component of a structured line is called a column in the internal table.
    Choosing a Table Type
    The table type (and particularly the access method) that you will use depends on how the typical internal table operations will be most frequently executed.
    Standard tables
    This is the most appropriate type if you are going to address the individual table entries using the index. Index access is the quickest possible access. You should fill a standard table by appending lines (ABAP APPEND statement), and read, modify and delete entries by specifying the index (INDEX option with the relevant ABAP command). The access time for a standard table increases in a linear relationship with the number of table entries. If you need key access, standard tables are particularly useful if you can fill and process the table in separate steps. For example, you could fill the table by appending entries, and then sort it. If you use the binary search option with key access, the response time is logarithmically proportional to the number of table entries.
    Sorted tables
    This is the most appropriate type if you need a table which is sorted as you fill it. You fill sorted tables using the INSERT statement. Entries are inserted according to the sort sequence defined through the table key. Any illegal entries are recognized as soon as you try to add them to the table. The response time for key access is logarithmically proportional to the number of table entries, since the system always uses a binary search. Sorted tables are particularly useful for partially sequential processing in a LOOP if you specify the beginning of the table key in the WHERE condition.
    Hashed tables
    This is the most appropriate type for any table where the main operation is key access. You cannot access a hashed table using its index. The response time for key access remains constant, regardless of the number of table entries. Like database tables, hashed tables always have a unique key. Hashed tables are useful if you want to construct and use an internal table which resembles a database table or for processing large amounts of data.
    Advanced Topics
    Batch Input: Concepts
    Processing Sessions
    The above figure shows how a batch input session works.A batch input session is a set of one or more calls to transactions along with the data to be processed by the transactions. The system normally executes the transactions in a session non-interactively, allowing rapid entry of bulk data into an R/3 System.
    A session records transactions and data in a special format that can be interpreted by the R/3 System. When the System reads a session, it uses the data in the session to simulate on-line entry of transactions and data. The System can call transactions and enter data using most of the facilities that are available to interactive users.
    For example, the data that a session enters into transaction screens is subject to the same consistency checking as in normal interactive operation. Further, batch input sessions are subject to the user-based authorization checking that is performed by the system.
    Advantages of ABAP over Contemporary languages
    ABAP Objects offers a number of advantages, even if you want to continue using procedural programming. If you want to use new ABAP features, you have to use object-oriented interfaces anyway.
    Sharing Data: With ABAP shared objects, you can aggregate data once at a central location and the different users and programs can then access this data without the need for copying.
    Exception Handling: With the class-based exception concept of ABAP, you can define a special control flow for a specific error situation and provide the user with information about the error.
    Developing Persistency: For permanent storage of data in ABAP, you use relational database tables by means of database-independent Open SQL, which is integrated in ABAP. However, you can also store selected objects transparently or access the integrated database or other databases using proprietary SQL.
    Connectivity and Interoperability: The Exchange Infrastructure and Web services are the means by which developers can implement a service-oriented architecture. With Web services, you can provide and consume services independently of implementation or protocol. Furthermore, you can do so within NetWeaver and in the communication with other systems. With the features of the Exchange Infrastructure, you can enable, manage, and adapt integration scenarios between systems.
    Making Enhancements: With the Enhancement Framework, you can enhance programs, function modules, and global classes without modification as well as replace existing code. The Switch Framework enables you activate only specific development objects or enhancements in a system.
    Considerable Aspects
    It follows a list of aspects to be considered during development. The list of course is not complete.
    Dynpro persistence
    When implementing dynpros one has to care for himself to read out and persist the necessary fields. Recently it happened to me that I forgot to include a field into the UPDATE-clause which is an error not so easy to uncover if you have other problems to be solved in the same package. Here, tool-support or built-in mechanisms would help.
    The developer could help himself out by creating something like a document containing a cookbook or guide in which parts of a dynpro logic one has to care about persistence. With that at hand, it would be quite easy finding those bugs in short time. Maybe a report scanning for the definition of the dynpro fields to be persisted could scan the code automatically, too.
    Memory Cache
    It should be common-sense that avoiding select-statements onto the database helps reducing the server load. For that the programmer either can resort to function modules if available. This maybe is the case for important tables. Or the programmer needs to implement his own logic using internal tables. Here, the standard software package could provide the developer with a tool or a mechanism auto-generating memory cached tables resp. function modules implementing this.
    Sometimes buffering of database tables could be used, if applicable. But that would require an effort in customizing the system and could drain down system performance overall, especially if a table is involved that has a central role.
    Interfaces
    It should be noticed that some function modules available have an incomplete interface. That means, the interface does not include all parameters evaluated by the logic of the function module. For example, global variables from within the function group could be read out, which cannot be influenced by the general caller. Or memory parameters are used internally to feed the logic with further information.
    One workaround here would be copying the relevant parts of the logic to a newly created function module and then adapt it to the own context. This sometimes is possible, maybe if the copied code is not too lengthy and only a few or no calls to other logic is part of it.
    A modification of the SAP code could be considered, if the modification itself is unavoidable (or another solution would be not justifiable by estimated effort to spend on it) and if the location of the modification seems quite safe against future upgrades or hot fixes. The latter is something that could be evaluated by contacting the SAP hotline or working with OSS message (searching thru existing one, perhaps open a new one).
    Example
    'From SAP NetWeaver:'
    set an exclusive lock at level object-type & object-id
    IF NOT lf_bapi_error = true.
    IF ( NOT istourhd-doc_type IS INITIAL ) AND
    ( NOT istourhd-doc_id IS INITIAL )
    CALL FUNCTION 'ENQUEUE_/DSD/E_HH_RAREF'
    EXPORTING
    obj_typ = istourhd-doc_type
    obj_id = istourhd-doc_id
    EXCEPTIONS
    foreign_lock = 1
    system_failure = 2
    OTHERS = 3.
    IF sy-subrc <> 0.
    terminate processing...
    lf_bapi_error = true.—
    ...and add message to return table
    PERFORM set_msg_to_bapiret2
    USING sy-msgid gc_abort sy-msgno
    sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4
    gc_istourhd gc_enqueue_refdoc space
    CHANGING lt_return.
    ENDIF.
    ENDIF.
    ENDIF. " bapi error
    Example Report(Type - ALV(Advanced List Viewer))
    REPORT Z_ALV_SIMPLE_EXAMPLE_WITH_ITAB .
    *Simple example to use ALV and to define the ALV data in an internal
    *table
    *data definition
    tables:
    marav. "Table MARA and table MAKT
    Data to be displayed in ALV
    Using the following syntax, REUSE_ALV_FIELDCATALOG_MERGE can auto-
    matically determine the fieldstructure from this source program
    Data:
    begin of imat occurs 100,
    matnr like marav-matnr, "Material number
    maktx like marav-maktx, "Material short text
    matkl like marav-matkl, "Material group (so you can test to make
    " intermediate sums)
    ntgew like marav-ntgew, "Net weight, numeric field (so you can test to
    "make sums)
    gewei like marav-gewei, "weight unit (just to be complete)
    end of imat.
    Other data needed
    field to store report name
    data i_repid like sy-repid.
    field to check table length
    data i_lines like sy-tabix.
    Data for ALV display
    TYPE-POOLS: SLIS.
    data int_fcat type SLIS_T_FIELDCAT_ALV.
    select-options:
    s_matnr for marav-matnr matchcode object MAT1.
    start-of-selection.
    read data into table imat
    select * from marav
    into corresponding fields of table imat
    where
    matnr in s_matnr.
    Check if material was found
    clear i_lines.
    describe table imat lines i_lines.
    if i_lines lt 1.
    Using hardcoded write here for easy upload
    write: /
    'No materials found.'.
    exit.
    endif.
    end-of-selection.
    To use ALV, we need a DDIC-structure or a thing called Fieldcatalogue.
    The fieldcatalouge can be generated by FUNCTION
    'REUSE_ALV_FIELDCATALOG_MERGE' from an internal table from any
    report source, including this report.
    Store report name
    i_repid = sy-repid.
    Create Fieldcatalogue from internal table
    CALL FUNCTION 'REUSE_ALV_FIELDCATALOG_MERGE'
    EXPORTING
    I_PROGRAM_NAME = i_repid
    I_INTERNAL_TABNAME = 'IMAT' "capital letters!
    I_INCLNAME = i_repid
    CHANGING
    CT_FIELDCAT = int_fcat
    EXCEPTIONS
    INCONSISTENT_INTERFACE = 1
    PROGRAM_ERROR = 2
    OTHERS = 3.
    *explanations:
    I_PROGRAM_NAME is the program which calls this function
    I_INTERNAL_TABNAME is the name of the internal table which you want
    to display in ALV
    I_INCLNAME is the ABAP-source where the internal table is defined
    (DATA....)
    CT_FIELDCAT contains the Fieldcatalouge that we need later for
    ALV display
    IF SY-SUBRC <> 0.
    write: /
    'Returncode',
    sy-subrc,
    'from FUNCTION REUSE_ALV_FIELDCATALOG_MERGE'.
    ENDIF.
    *This was the fieldcatlogue
    Call for ALV list display
    CALL FUNCTION 'REUSE_ALV_LIST_DISPLAY'
    EXPORTING
    I_CALLBACK_PROGRAM = i_repid
    IT_FIELDCAT = int_fcat
    TABLES
    T_OUTTAB = imat
    EXCEPTIONS
    PROGRAM_ERROR = 1
    OTHERS = 2.
    *explanations:
    I_CALLBACK_PROGRAM is the program which calls this function
    IT_FIELDCAT (just made by REUSE_ALV_FIELDCATALOG_MERGE) contains
    now the data definition needed for display
    I_SAVE allows the user to save his own layouts
    T_OUTTAB contains the data to be displayed in ALV
    IF SY-SUBRC <> 0.
    write: /
    'Returncode',
    sy-subrc,
    'from FUNCTION REUSE_ALV_LIST_DISPLAY'.
    ENDIF.
    OOPs ABAP uses Classes and Interfaces which uses Methods and events.
    If you have Java skills it is advantage for you.
    There are Local classes as well as Global Classes.
    Local classes we can work in SE38 straight away.
    But mostly it is better to use the Global classes.
    Global Classes or Interfaces are to be created in SE24.
    SAP already given some predefined classes and Interfaces.
    This OOPS concepts very useful for writing BADI's also.
    So first create a class in SE 24.
    Define attributes, Methods for that class.
    Define parameters for that Method.
    You can define event handlers also to handle the messages.
    After creation in each method write the code.
    Methods are similar to ABAP PERFORM -FORM statements.
    After the creation of CLass and methods come to SE38 and create the program.
    In the program create a object type ref to that class and with the help of that Object call the methods of that Class and display the data.
    Regards
    Anji

  • Oracle Report Printing problem

    Dear All,
    i m using below code on button in oracle forms 6i problem is that when i click on button report should be print
    on network printer but it's print blank page however network printer is not my default printer when i set default printer
    to this network printer its working fine.
    and also its working when i set mode=character and network printer is not default printer but when i set mode=default or bitmap and notwork printer is not default then its print blank page.
         DECLARE
              p_list     PARAMLIST;
         BEGIN
         p_list := get_parameter_list('importdata');
         IF NOT Id_Null(p_list) THEN
    Destroy_Parameter_List('importdata');
         END IF;
              p_list := Create_Parameter_List('importdata');
              Add_Parameter(p_list,'P_IGM_NO',TEXT_PARAMETER,'10117/11');
              Add_Parameter(p_list,'P_INDEX_NO',TEXT_PARAMETER,'498');
              Add_Parameter(p_list,'P_CHR_NO',TEXT_PARAMETER,'CL-APL100/011');
              Add_Parameter(p_list,'P_CONTAINER_NO',TEXT_PARAMETER,'APHU6305929');
              Add_Parameter(p_list,'P_USER',TEXT_PARAMETER,'ALI');
              Add_Parameter(p_list,'P_BAL_QTY',TEXT_PARAMETER,0);
              Add_Parameter(p_list, 'PARAMFORM', TEXT_PARAMETER, 'NO');
              Add_Parameter(p_list,'DESTYPE',TEXT_PARAMETER,'PRINTER');
         Add_Parameter(p_list,'DESNAME',TEXT_PARAMETER,'\\192.168.1.67\epson');
         RUN_PRODUCT(REPORTS,'\\ORASERV\Atlas6I\Import\System\Reports\abc.rep',
         SYNCHRONOUS,
         RUNTIME,
         FILESYSTEM,
         p_list,
         NULL);
         END;

    i have made one oracle 6i reports. its is quite wide.when i run the report it shrink into too small font.
    and i increse it font size it by pressing + button on menu bar it looks okay.
    >
    The + button only causes a zoom in on the screen. It is not affecting the actual layout.
    >
    but the problem is that when i take print out of it ,it's printout comes in its intial format(in small font) evenif i choose different type of paper size or different orientation . it's printout is coming in too small font.
    pl tell me how to overcome this problem>
    The report rendering engine tries to fit the report page into the physical page size. This results in shrinking of font size,etc.
    To fix
    a) reduce the content on the report to something reasonable for printing.(Std paper sizes and orientation)
    b) change the page size selection. Of course, you will need a printer and paper of the size you set.
    Cheers,

  • SURVEY - How to Activate Send Questionnaire Button To Get Survey Returned

    Hello,
    We  have created surveys/questionnaires within SRM using SURVEY cockpit.  We have success now getting Surveys to go to the email address BUT when we hit the SEND Questionnaire button, nothing happens when trying to reply.
    I have located a few posts on this forum but none of them have been the answer to our problem.
    Is this an ABAP object oriented class - ABAP-OO - that needs to be assigned via UBDS/UBDC?
    If so, we are not sure the technical name for it .  Would CL_MPA_HANDLE_ALERT_REPLY happen to be one that might work?
    Any help would be immensely appreciated and points assigned.
    Thank you very much,
    Lynda

    Thank you so much. That was exactly what we needed.  One further question---->
    If we want to retrieve the survey answers from a URL rather than email, where do we have to address the configuration?  TCODES?
    Also, we want to use the web application library to populate a drop list of vendors.  Is that something you have had experience with?
    If you, could you please help?
    Sincerely,
    Lynda Fuller

  • Hi guru's  alv wit oops explain to me good example

    hi guru's  alv wit oops explain to me good example

    Hi
    What is Object Orientation?
    In the past, information systems used to be defined primarily by their functionality: data and functions were kept separate and linked together by means of input and output relations.
    The object-oriented approach, however, focuses on objects that represent abstract or concrete things of the real world. These objects are first defined by their character and their properties which are represented by their internal structure and their attributes (data). The behaviour of these objects is described by methods (functionality).
    Objects form a capsule which combines the character to the respective behaviour. Objects should enable programmers to map a real problem and its proposed software solution on a one-to-one basis.
    Typical objects in a business environment are, for example, ‘Customer’, ‘Order’, or ‘Invoice’. From Release 3.1 onwards, the Business Object Repository (BOR) of SAP Web Applicaton Server ABAP has contained examples of such objects. The BOR object model will be integrated into ABAP Objects in the next Release by migrating the BOR object types to the ABAP class library.
    A comprehensive introduction to object orientation as a whole would go far beyond the limits of this introduction to ABAP Objects. This documentation introduces a selection of terms that are used universally in object orientation and also occur in ABAP Objects. In subsequent sections, it goes on to discuss in more detail how these terms are used in ABAP Objects. The end of this section contains a list of further reading, with a selection of titles about object orientation.
    Objects
    Objects are instances of classes. They contain data and provides services. The data forms the attributes of the object. The services are known as methods (also known as operations or functions). Typically, methods operate on private data (the attributes, or state of the object), which is only visible to the methods of the object. Thus the attributes of an object cannot be changed directly by the user, but only by the methods of the object. This guarantees the internal consistency of the object.
    Classes
    Classes describe objects. From a technical point of view, objects are runtime instances of a class. In theory, you can create any number of objects based on a single class. Each instance (object) of a class has a unique identity and its own set of values for its attributes.
    Object References
    In a program, you identify and address objects using unique object references. Object references allow you to access the attributes and methods of an object.
    In object-oriented programming, objects usually have the following properties:
    Encapsulation
    Objects restrict the visibility of their resources (attributes and methods) to other users. Every object has an interface, which determines how other objects can interact with it. The implementation of the object is encapsulated, that is, invisible outside the object itself.
    Inheritance
    You can use an existing class to derive a new class. Derived classes inherit the data and methods of the superclass. However, they can overwrite existing methods, and also add new ones.
    Polymorphism
    Identical (identically-named) methods behave differently in different classes. In ABAP Objects, polymorphism is implemented by redefining methods during inheritance and by using constructs called interfaces.
    Uses of Object Orientation
    Below are some of the advantages of object-oriented programming:
    · Complex software systems become easier to understand, since object-oriented structuring provides a closer representation of reality than other programming techniques.
    · In a well-designed object-oriented system, it should be possible to implement changes at class level, without having to make alterations at other points in the system. This reduces the overall amount of maintenance required.
    · Through polymorphism and inheritance, object-oriented programming allows you to reuse individual components.
    · In an object-oriented system, the amount of work involved in revising and maintaining the system is reduced, since many problems can be detected and corrected in the design phase.
    Achieving these goals requires:
    · Object-oriented programming languages
    Object-oriented programming techniques do not necessarily depend on object-oriented programming languages. However, the efficiency of object-oriented programming depends directly on how object-oriented language techniques are implemented in the system kernel.
    · Object-oriented tools
    Object-oriented tools allow you to create object-oriented programs in object-oriented languages. They allow you to model and store development objects and the relationships between them.
    · Object-oriented modeling
    The object-orientation modeling of a software system is the most important, most time-consuming, and most difficult requirement for attaining the above goals. Object-oriented design involves more than just object-oriented programming, and provides logical advantages that are independent of the actual implementation.
    This section of the ABAP User’s Guide provides an overview of the object-oriented extension of the ABAP language. We have used simple examples to demonstrate how to use the new features. However, these are not intended to be a model for object-oriented design. More detailed information about each of the ABAP Objects statements is contained in the keyword documentation in the ABAP Editor. For a comprehensive introduction to object-oriented software development, you should read one or more of the titles listed below.
    ABAP supports a hybrid programming model. You can use an object-oriented ("OO") programming model based on classes and interfaces, and you can use the more classic procedural and event-driven programming model based on function modules, subroutines, dialog modules, and event blocks. Both models can be used in parallel. You can use classes inside classic processing blocks or you can call classic procedures from methods. In ABAP Objects, SAP has implemented a cleanup of the ABAP language. Within the scope of this language cleanup, stricter syntax checks are performed in classes that restrict the usage of obsolete language elements.
    Object orientation in ABAP is an extension of the ABAP language that makes available the advantages of object-oriented programming, such as encapsulation, interfaces, and inheritance. This helps to simplify applications and make them more controllable.
    ABAP Objects is fully compatible with the existing language, so you can use existing statements and modularization units in programs that use ABAP Objects, and can also use ABAP Objects in existing ABAP programs.
    Check these links</b>/people/thomas.jung3/blog/2005/09/08/oo-abap-dynpro-programming
    /people/ravikumar.allampallam/blog/2005/02/11/abap-oo-in-action
    This is good for beginners
    /people/sap.user72/blog/2005/05/10/a-small-tip-for-the-beginners-in-oo-abap
    check the below links lot of info and examples r there
    http://www.sapgenie.com/abap/OO/index.htm
    http://www.geocities.com/victorav15/sapr3/abap_ood.html
    http://www.brabandt.de/html/abap_oo.html
    Check this cool weblog:
    /people/thomas.jung3/blog/2004/12/08/abap-persistent-classes-coding-without-sql
    /people/thomas.jung3/blog/2004/12/08/abap-persistent-classes-coding-without-sql
    http://help.sap.com/saphelp_nw04/helpdata/en/c3/225b6254f411d194a60000e8353423/frameset.htm
    http://www.sapgenie.com/abap/OO/
    http://www.sapgenie.com/abap/OO/index.htm
    http://help.sap.com/saphelp_nw04/helpdata/en/c3/225b5654f411d194a60000e8353423/content.htm
    http://www.esnips.com/doc/375fff1b-5a62-444d-8ec1-55508c308b17/prefinalppt.ppt
    http://www.esnips.com/doc/2c76dc57-e74a-4539-a20e-29383317e804/OO-abap.pdf
    http://www.esnips.com/doc/5c65b0dd-eddf-4512-8e32-ecd26735f0f2/prefinalppt.ppt
    http://www.allsaplinks.com/
    http://www.sap-img.com/
    http://www.sapgenie.com/
    http://help.sap.com
    http://www.sapgenie.com/abap/OO/
    http://www.sapgenie.com/abap/OO/index.htm
    http://www.sapgenie.com/abap/controls/index.htm
    http://www.esnips.com/doc/2c76dc57-e74a-4539-a20e-29383317e804/OO-abap.pdf
    http://www.esnips.com/doc/0ef39d4b-586a-4637-abbb-e4f69d2d9307/SAP-CONTROLS-WORKSHOP.pdf
    http://www.sapgenie.com/abap/OO/index.htm
    http://help.sap.com/saphelp_erp2005/helpdata/en/ce/b518b6513611d194a50000e8353423/frameset.htm
    http://www.sapgenie.com/abap/OO/
    these links
    http://help.sap.com/saphelp_47x200/helpdata/en/ce/b518b6513611d194a50000e8353423/content.htm
    For funtion module to class
    http://help.sap.com/saphelp_47x200/helpdata/en/c3/225b5954f411d194a60000e8353423/content.htm
    for classes
    http://help.sap.com/saphelp_47x200/helpdata/en/c3/225b5c54f411d194a60000e8353423/content.htm
    for methods
    http://help.sap.com/saphelp_47x200/helpdata/en/08/d27c03b81011d194f60000e8353423/content.htm
    for inheritance
    http://help.sap.com/saphelp_47x200/helpdata/en/dd/4049c40f4611d3b9380000e8353423/content.htm
    for interfaces
    http://help.sap.com/saphelp_47x200/helpdata/en/c3/225b6254f411d194a60000e8353423/content.htm
    For Materials:
    1) http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCABA/BCABA.pdf -- Page no: 1291
    2) http://esnips.com/doc/5c65b0dd-eddf-4512-8e32-ecd26735f0f2/prefinalppt.ppt
    3) http://esnips.com/doc/2c76dc57-e74a-4539-a20e-29383317e804/OO-abap.pdf
    4) http://esnips.com/doc/0ef39d4b-586a-4637-abbb-e4f69d2d9307/SAP-CONTROLS-WORKSHOP.pdf
    5) http://esnips.com/doc/92be4457-1b6e-4061-92e5-8e4b3a6e3239/Object-Oriented-ABAP.ppt
    6) http://esnips.com/doc/448e8302-68b1-4046-9fef-8fa8808caee0/abap-objects-by-helen.pdf
    7) http://esnips.com/doc/39fdc647-1aed-4b40-a476-4d3042b6ec28/class_builder.ppt
    8) http://www.amazon.com/gp/explorer/0201750805/2/ref=pd_lpo_ase/102-9378020-8749710?ie=UTF8
    1) http://www.erpgenie.com/sap/abap/OO/index.htm
    2) http://help.sap.com/saphelp_nw04/helpdata/en/ce/b518b6513611d194a50000e8353423/frameset.htm
    Sample code
    *"Table declarations...................................................
    TABLES:
    EKKO, " Purchasing Document Header
    CDHDR, " Change document header
    SSCRFIELDS. " Fields on selection screens
    *"Selection screen elements............................................
    SELECT-OPTIONS:
    S_EBELN FOR EKKO-EBELN, " Purchasing Document Number
    S_LIFNR FOR EKKO-LIFNR, " Vendor's account number
    S_EKGRP FOR EKKO-EKGRP, " Purchasing group
    S_BEDAT FOR EKKO-BEDAT, " Purchasing Document Date
    S_UDATE FOR CDHDR-UDATE. " Creation date of the change
    " document
    *" Data declarations...................................................
    Field String to hold Purchase Document Number *
    DATA:
    BEGIN OF FS_EBELN,
    EBELN(90) TYPE C, " Purchase Document Number
    ERNAM TYPE EKKO-ERNAM, " Name of Person who Created
    " the Object
    LIFNR TYPE EKKO-LIFNR, " Vendor's account number
    EKGRP TYPE EKKO-EKGRP, " Purchasing group
    BEDAT TYPE EKKO-BEDAT, " Purchasing Document Date
    END OF FS_EBELN,
    Field String to hold Purchase Document Header *
    BEGIN OF FS_EKKO,
    EBELN TYPE EKKO-EBELN, " Purchasing Document Number
    ERNAM TYPE EKKO-ERNAM, " Name of Person who Created the
    " Object
    LIFNR TYPE EKKO-LIFNR, " Vendor's account number
    EKGRP TYPE EKKO-EKGRP, " Purchasing group
    BEDAT TYPE EKKO-BEDAT, " Purchasing Document Date
    END OF FS_EKKO,
    Field String to hold Account Number and name of the Vendor *
    BEGIN OF FS_LFA1,
    LIFNR TYPE LFA1-LIFNR, " Account Number of Vendor
    NAME1 TYPE LFA1-NAME1, " Name1
    END OF FS_LFA1,
    Field String to hold Change date and the name of the user *
    BEGIN OF FS_CDHDR,
    OBJECTCLAS TYPE CDHDR-OBJECTCLAS, " Object Class
    OBJECTID TYPE CDHDR-OBJECTID, " Object value
    CHANGENR TYPE CDHDR-CHANGENR, " Document change number
    USERNAME TYPE CDHDR-USERNAME, " User name
    UDATE TYPE CDHDR-UDATE, " Creation date of the change
    " document
    END OF FS_CDHDR,
    Field String to hold Change document items *
    BEGIN OF FS_CDPOS,
    OBJECTCLAS TYPE CDPOS-OBJECTCLAS," Object class
    OBJECTID(10) TYPE C, " Object Value
    CHANGENR TYPE CDPOS-CHANGENR, " Document change number
    TABNAME TYPE CDPOS-TABNAME, " Table Name
    FNAME TYPE CDPOS-FNAME, " Field Name
    VALUE_NEW TYPE CDPOS-VALUE_NEW, " New contents of changed field
    VALUE_OLD TYPE CDPOS-VALUE_OLD, " Old contents of changed field
    END OF FS_CDPOS,
    Field String to hold Date Element Name *
    BEGIN OF FS_DATAELE,
    TABNAME TYPE DD03L-TABNAME, " Table Name
    FIELDNAME TYPE DD03L-FIELDNAME, " Field Name
    ROLLNAME TYPE DD03L-ROLLNAME, " Data element (semantic domain)
    END OF FS_DATAELE,
    Field String to hold Short Text of the Date Element *
    BEGIN OF FS_TEXT,
    ROLLNAME TYPE DD04T-ROLLNAME, " Data element (semantic domain)
    DDTEXT TYPE DD04T-DDTEXT, " Short Text Describing R/3
    " Repository Objects
    END OF FS_TEXT,
    Field String to hold data to be displayed on the ALV grid *
    BEGIN OF FS_OUTTAB,
    EBELN TYPE EKKO-EBELN, " Purchasing Document Number
    ERNAM TYPE EKKO-ERNAM, " Name of Person who Created the
    " Object
    LIFNR TYPE EKKO-LIFNR, " Vendor's account number
    EKGRP TYPE EKKO-EKGRP, " Purchasing group
    BEDAT TYPE EKKO-BEDAT, " Purchasing Document Date
    WERKS TYPE LFA1-WERKS, " Plant
    NAME1 TYPE LFA1-NAME1, " Name1
    USERNAME TYPE CDHDR-USERNAME, " User name
    UDATE TYPE CDHDR-UDATE, " Creation date of the change
    " document
    DDTEXT TYPE DD04T-DDTEXT, " Short Text Describing R/3
    " Repository Objects
    VALUE_NEW TYPE CDPOS-VALUE_NEW, " New contents of changed field
    VALUE_OLD TYPE CDPOS-VALUE_OLD, " Old contents of changed field
    END OF FS_OUTTAB,
    Internal table to hold Purchase Document Number *
    T_EBELN LIKE STANDARD TABLE
    OF FS_EBELN,
    Internal table to hold Purchase Document Header *
    T_EKKO LIKE STANDARD TABLE
    OF FS_EKKO,
    Temp Internal table to hold Purchase Document Header *
    T_EKKO_TEMP LIKE STANDARD TABLE
    OF FS_EKKO,
    Internal table to hold Account number and Name of the Vendor *
    T_LFA1 LIKE STANDARD TABLE
    OF FS_LFA1,
    Internal Table to hold Change date and the name of the user *
    T_CDHDR LIKE STANDARD TABLE
    OF FS_CDHDR,
    Internal Table to hold Change document items *
    T_CDPOS LIKE STANDARD TABLE
    OF FS_CDPOS,
    Temp. Internal Table to hold Change document items *
    T_CDPOS_TEMP LIKE STANDARD TABLE
    OF FS_CDPOS,
    Internal Table to hold Data Element Name *
    T_DATAELE LIKE STANDARD TABLE
    OF FS_DATAELE,
    Temp. Internal Table to hold Data Element Name *
    T_DATAELE_TEMP LIKE STANDARD TABLE
    OF FS_DATAELE,
    Internal Table to hold Short Text of the Date Element *
    T_TEXT LIKE STANDARD TABLE
    OF FS_TEXT,
    Internal Table to hold data to be displayed on the ALV grid *
    T_OUTTAB LIKE STANDARD TABLE
    OF FS_OUTTAB.
    C L A S S D E F I N I T I O N *
    CLASS LCL_EVENT_HANDLER DEFINITION DEFERRED.
    *" Data declarations...................................................
    Work variables *
    DATA:
    W_EBELN TYPE EKKO-EBELN, " Purchasing Document Number
    W_LIFNR TYPE EKKO-LIFNR, " Vendor's account number
    W_EKGRP TYPE EKKO-EKGRP, " Purchasing group
    W_VALUE TYPE EKKO-EBELN, " Reflected Value
    W_SPACE VALUE ' ', " Space
    W_FLAG TYPE I, " Flag Variable
    W_VARIANT TYPE DISVARIANT, " Variant
    *--- ALV Grid
    W_GRID TYPE REF TO CL_GUI_ALV_GRID,
    *--- Event Handler
    W_EVENT_CLICK TYPE REF TO LCL_EVENT_HANDLER,
    *--- Field catalog table
    T_FIELDCAT TYPE LVC_T_FCAT.
    AT SELECTION-SCREEN EVENT *
    AT SELECTION-SCREEN ON S_EBELN.
    Subroutine to validate Purchase Document Number.
    PERFORM VALIDATE_PD_NUM.
    AT SELECTION-SCREEN ON S_LIFNR.
    Subroutine to validate Vendor Number.
    PERFORM VALIDATE_VEN_NUM.
    AT SELECTION-SCREEN ON S_EKGRP.
    Subroutine to validate Purchase Group.
    PERFORM VALIDATE_PUR_GRP.
    START-OF-SELECTION EVENT *
    START-OF-SELECTION.
    Subroutine to select all Purchase orders.
    PERFORM SELECT_PO.
    CHECK W_FLAG EQ 0.
    Subroutine to select Object values.
    PERFORM SELECT_OBJ_ID.
    CHECK W_FLAG EQ 0.
    Subroutine to select Changed values.
    PERFORM SELECT_CHANGED_VALUE.
    CHECK W_FLAG EQ 0.
    Subroutine to Select Purchase Orders.
    PERFORM SELECT_PUR_DOC.
    Subroutine to select Vendor Details.
    PERFORM SELECT_VENDOR.
    Subroutine to select Text for the Changed values.
    PERFORM DESCRIPTION.
    END-OF-SELECTION EVENT *
    END-OF-SELECTION.
    IF NOT T_EKKO IS INITIAL.
    Subroutine to populate the Output Table.
    PERFORM FILL_OUTTAB.
    Subroutine to build Field Catalog.
    PERFORM PREPARE_FIELD_CATALOG CHANGING T_FIELDCAT.
    CALL SCREEN 100.
    ENDIF. " IF NOT T_EKKO...
    CLASS LCL_EVENT_HANDLER DEFINITION
    Defining Class which handles events
    CLASS LCL_EVENT_HANDLER DEFINITION .
    PUBLIC SECTION .
    METHODS:
    HANDLE_HOTSPOT_CLICK
    FOR EVENT HOTSPOT_CLICK OF CL_GUI_ALV_GRID
    IMPORTING E_ROW_ID E_COLUMN_ID.
    ENDCLASS. " LCL_EVENT_HANDLER DEFINITION
    CLASS LCL_EVENT_HANDLER IMPLEMENTATION
    Implementing the Class which can handle events
    CLASS LCL_EVENT_HANDLER IMPLEMENTATION .
    *---Handle Double Click
    METHOD HANDLE_HOTSPOT_CLICK .
    Subroutine to get the HotSpot Cell information.
    PERFORM GET_CELL_INFO.
    SET PARAMETER ID 'BES' FIELD W_VALUE.
    CALL TRANSACTION 'ME23N'.
    ENDMETHOD. " HANDLE_HOTSPOT_CLICK
    ENDCLASS. " LCL_EVENT_HANDLER
    *& Module STATUS_0100 OUTPUT
    PBO Event
    MODULE STATUS_0100 OUTPUT.
    SET PF-STATUS 'OOPS'.
    SET TITLEBAR 'TIT'.
    Subroutine to fill the Variant Structure
    PERFORM FILL_VARIANT.
    IF W_GRID IS INITIAL.
    CREATE OBJECT W_GRID
    EXPORTING
    I_SHELLSTYLE = 0
    I_LIFETIME =
    I_PARENT = CL_GUI_CONTAINER=>SCREEN0
    I_APPL_EVENTS =
    I_PARENTDBG =
    I_APPLOGPARENT =
    I_GRAPHICSPARENT =
    I_NAME =
    I_FCAT_COMPLETE = SPACE
    EXCEPTIONS
    ERROR_CNTL_CREATE = 1
    ERROR_CNTL_INIT = 2
    ERROR_CNTL_LINK = 3
    ERROR_DP_CREATE = 4
    OTHERS = 5.
    IF SY-SUBRC <> 0.
    MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
    WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
    ENDIF. " IF SY-SUBRC <> 0
    CALL METHOD W_GRID->SET_TABLE_FOR_FIRST_DISPLAY
    EXPORTING
    I_BUFFER_ACTIVE =
    I_BYPASSING_BUFFER =
    I_CONSISTENCY_CHECK =
    I_STRUCTURE_NAME =
    IS_VARIANT = W_VARIANT
    I_SAVE = 'A'
    I_DEFAULT = 'X'
    IS_LAYOUT =
    IS_PRINT =
    IT_SPECIAL_GROUPS =
    IT_TOOLBAR_EXCLUDING =
    IT_HYPERLINK =
    IT_ALV_GRAPHICS =
    IT_EXCEPT_QINFO =
    IR_SALV_ADAPTER =
    CHANGING
    IT_OUTTAB = T_OUTTAB
    IT_FIELDCATALOG = T_FIELDCAT
    IT_SORT =
    IT_FILTER =
    EXCEPTIONS
    INVALID_PARAMETER_COMBINATION = 1
    PROGRAM_ERROR = 2
    TOO_MANY_LINES = 3
    OTHERS = 4
    IF SY-SUBRC <> 0.
    MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
    WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
    ENDIF. " IF SY-SUBRC <> 0.
    ENDIF. " IF W_GRID IS INITIAL
    CREATE OBJECT W_EVENT_CLICK.
    SET HANDLER W_EVENT_CLICK->HANDLE_HOTSPOT_CLICK FOR W_GRID.
    ENDMODULE. " STATUS_0100 OUTPUT
    *& Module USER_COMMAND_0100 INPUT
    PAI Event
    MODULE USER_COMMAND_0100 INPUT.
    CASE SY-UCOMM.
    WHEN 'BACK'.
    LEAVE TO SCREEN 0.
    WHEN 'EXIT'.
    LEAVE PROGRAM.
    WHEN 'CANCEL'.
    LEAVE TO SCREEN 0.
    ENDCASE.
    ENDMODULE. " USER_COMMAND_0100 INPUT
    *& Form PREPARE_FIELD_CATALOG
    Subroutine to build the Field catalog
    <--P_T_FIELDCAT Field Catalog Table
    FORM PREPARE_FIELD_CATALOG CHANGING PT_FIELDCAT TYPE LVC_T_FCAT .
    DATA LS_FCAT TYPE LVC_S_FCAT.
    Purchasing group...
    LS_FCAT-FIELDNAME = 'EKGRP'.
    LS_FCAT-REF_TABLE = 'EKKO'.
    LS_FCAT-INTTYPE = 'C'.
    LS_FCAT-OUTPUTLEN = '10'.
    APPEND LS_FCAT TO PT_FIELDCAT.
    CLEAR LS_FCAT.
    Purchasing Document Number...
    LS_FCAT-FIELDNAME = 'EBELN'.
    LS_FCAT-REF_TABLE = 'EKKO' .
    LS_FCAT-EMPHASIZE = 'C411'.
    LS_FCAT-INTTYPE = 'C'.
    LS_FCAT-OUTPUTLEN = '10'.
    LS_FCAT-HOTSPOT = 'X'.
    APPEND LS_FCAT TO PT_FIELDCAT .
    CLEAR LS_FCAT .
    Name of Person who Created the Object...
    LS_FCAT-FIELDNAME = 'ERNAM'.
    LS_FCAT-REF_TABLE = 'EKKO'.
    LS_FCAT-OUTPUTLEN = '15' .
    APPEND LS_FCAT TO PT_FIELDCAT.
    CLEAR LS_FCAT.
    Purchasing Document Date...
    LS_FCAT-FIELDNAME = 'BEDAT'.
    LS_FCAT-REF_TABLE = 'EKKO'.
    LS_FCAT-INTTYPE = 'C'.
    LS_FCAT-OUTPUTLEN = '10'.
    APPEND LS_FCAT TO PT_FIELDCAT.
    CLEAR LS_FCAT.
    Vendor's account number...
    LS_FCAT-FIELDNAME = 'LIFNR'.
    LS_FCAT-REF_TABLE = 'EKKO'.
    LS_FCAT-INTTYPE = 'C'.
    LS_FCAT-OUTPUTLEN = '10'.
    APPEND LS_FCAT TO PT_FIELDCAT.
    CLEAR LS_FCAT.
    Account Number of Vendor or Creditor...
    LS_FCAT-FIELDNAME = 'NAME1'.
    LS_FCAT-REF_TABLE = 'LFA1'.
    LS_FCAT-INTTYPE = 'C'.
    LS_FCAT-OUTPUTLEN = '10'.
    LS_FCAT-COLTEXT = 'Vendor Name'(001).
    LS_FCAT-SELTEXT = 'Vendor Name'(001).
    APPEND LS_FCAT TO PT_FIELDCAT.
    CLEAR LS_FCAT.
    Creation date of the change document...
    LS_FCAT-FIELDNAME = 'UDATE'.
    LS_FCAT-REF_TABLE = 'CDHDR'.
    LS_FCAT-INTTYPE = 'C'.
    LS_FCAT-OUTPUTLEN = '10'.
    LS_FCAT-COLTEXT = 'Change Date'(002).
    LS_FCAT-SELTEXT = 'Change Date'(002).
    APPEND LS_FCAT TO PT_FIELDCAT.
    CLEAR LS_FCAT.
    User name of the person responsible in change document...
    LS_FCAT-FIELDNAME = 'USERNAME'.
    LS_FCAT-REF_TABLE = 'CDHDR'.
    LS_FCAT-INTTYPE = 'C'.
    LS_FCAT-OUTPUTLEN = '10'.
    LS_FCAT-COLTEXT = 'Modified by'(003).
    LS_FCAT-SELTEXT = 'Modified by'(003).
    APPEND LS_FCAT TO PT_FIELDCAT.
    CLEAR LS_FCAT.
    Short Text Describing R/3 Repository Objects...
    LS_FCAT-FIELDNAME = 'DDTEXT'.
    LS_FCAT-REF_TABLE = 'DD04T'.
    LS_FCAT-INTTYPE = 'C'.
    LS_FCAT-OUTPUTLEN = '15'.
    APPEND LS_FCAT TO PT_FIELDCAT.
    CLEAR LS_FCAT.
    Old contents of changed field...
    LS_FCAT-FIELDNAME = 'VALUE_OLD'.
    LS_FCAT-REF_TABLE = 'CDPOS'.
    LS_FCAT-INTTYPE = 'C'.
    LS_FCAT-OUTPUTLEN = '12'.
    APPEND LS_FCAT TO PT_FIELDCAT.
    CLEAR LS_FCAT.
    New contents of changed field...
    LS_FCAT-FIELDNAME = 'VALUE_NEW'.
    LS_FCAT-REF_TABLE = 'CDPOS'.
    LS_FCAT-INTTYPE = 'C'.
    LS_FCAT-OUTPUTLEN = '12'.
    APPEND LS_FCAT TO PT_FIELDCAT.
    CLEAR LS_FCAT.
    ENDFORM. " PREPARE_FIELD_CATALOG
    *& Form SELECT_PO
    Subroutine to select all the Purchase Orders
    There are no interface parameters to be passed to this subroutine.
    FORM SELECT_PO .
    SELECT EBELN " Purchasing Document Number
    ERNAM " Name of Person who Created
    " the Object
    LIFNR " Vendor's account number
    EKGRP " Purchasing group
    BEDAT " Purchasing Document Date
    FROM EKKO
    PACKAGE SIZE 10000
    APPENDING TABLE T_EBELN
    WHERE EBELN IN S_EBELN
    AND BEDAT IN S_BEDAT.
    ENDSELECT.
    IF SY-SUBRC NE 0.
    W_FLAG = 1.
    MESSAGE S401(M8).
    ENDIF. " IF SY-SUBRC NE 0
    ENDFORM. " SELECT_PO
    *& Form SELECT_OBJ_ID
    Subroutine to select Object ID
    There are no interface parameters to be passed to this subroutine.
    FORM SELECT_OBJ_ID .
    IF NOT T_EBELN IS INITIAL.
    SELECT OBJECTCLAS " Object Class
    OBJECTID " Object value
    CHANGENR " Document change number
    USERNAME " User name
    UDATE " Creation date
    FROM CDHDR
    INTO TABLE T_CDHDR
    FOR ALL ENTRIES IN T_EBELN
    WHERE OBJECTID EQ T_EBELN-EBELN
    AND UDATE IN S_UDATE
    AND TCODE IN ('ME21N','ME22N','ME23N').
    ENDSELECT.
    IF SY-SUBRC NE 0.
    W_FLAG = 1.
    MESSAGE S833(M8) WITH 'Header Not Found'(031).
    ENDIF. " IF SY-SUBRC NE 0.
    ENDIF. " IF NOT T_EBELN IS INITIAL
    ENDFORM. " SELECT_OBJ_ID
    *& Form SELECT_CHANGED_VALUE
    Subroutine to select Changed Values
    There are no interface parameters to be passed to this subroutine.
    FORM SELECT_CHANGED_VALUE .
    IF NOT T_CDHDR IS INITIAL.
    SELECT OBJECTCLAS " Object class
    OBJECTID " Object value
    CHANGENR " Document change number
    TABNAME " Table Name
    FNAME " Field Name
    VALUE_NEW " New contents of changed field
    VALUE_OLD " Old contents of changed field
    FROM CDPOS
    PACKAGE SIZE 10000
    APPENDING TABLE T_CDPOS
    FOR ALL ENTRIES IN T_CDHDR
    WHERE OBJECTCLAS EQ T_CDHDR-OBJECTCLAS
    AND OBJECTID EQ T_CDHDR-OBJECTID
    AND CHANGENR EQ T_CDHDR-CHANGENR.
    ENDSELECT.
    IF SY-SUBRC NE 0.
    W_FLAG = 1.
    MESSAGE S833(M8) WITH 'Item Not Found'(032).
    ENDIF. " IF SY-SUBRC NE 0.
    ENDIF. " IF NOT T_CDHDR IS INITIAL
    T_CDPOS_TEMP[] = T_CDPOS[].
    ENDFORM. " SELECT_CHANGED_VALUE
    *& Form SELECT_PUR_DOC
    Subroutine to select Purchase Order Details
    There are no interface parameters to be passed to this subroutine.
    FORM SELECT_PUR_DOC .
    IF NOT T_CDPOS IS INITIAL.
    SORT T_EBELN BY EBELN.
    LOOP AT T_CDPOS INTO FS_CDPOS.
    READ TABLE T_EBELN INTO FS_EBELN WITH KEY EBELN =
    FS_CDPOS-OBJECTID BINARY SEARCH.
    IF SY-SUBRC NE 0.
    DELETE TABLE T_EBELN FROM FS_EBELN.
    ENDIF. " IF SY-SUBRC NE 0.
    ENDLOOP. " LOOP AT T_CDPOS...
    LOOP AT T_EBELN INTO FS_EBELN.
    MOVE FS_EBELN-EBELN TO FS_EKKO-EBELN.
    MOVE FS_EBELN-ERNAM TO FS_EKKO-ERNAM.
    MOVE FS_EBELN-LIFNR TO FS_EKKO-LIFNR.
    MOVE FS_EBELN-EKGRP TO FS_EKKO-EKGRP.
    MOVE FS_EBELN-BEDAT TO FS_EKKO-BEDAT.
    APPEND FS_EKKO TO T_EKKO.
    ENDLOOP. " LOOP AT T_EBELN...
    T_EKKO_TEMP[] = T_EKKO[].
    ENDIF. " IF NOT T_CDPOS IS INITIAL
    ENDFORM. " SELECT_PUR_DOC
    *& Form SELECT_VENDOR
    Subroutine to select Vendor details
    There are no interface parameters to be passed to this subroutine.
    FORM SELECT_VENDOR .
    IF NOT T_EKKO IS INITIAL.
    SORT T_EKKO_TEMP BY LIFNR.
    DELETE ADJACENT DUPLICATES FROM T_EKKO_TEMP COMPARING LIFNR.
    SELECT LIFNR " Account Number of Vendor or
    " Creditor
    NAME1 " Name 1
    FROM LFA1
    INTO TABLE T_LFA1
    FOR ALL ENTRIES IN T_EKKO_TEMP
    WHERE LIFNR EQ T_EKKO_TEMP-LIFNR.
    IF SY-SUBRC NE 0.
    MESSAGE S002(M8) WITH 'Master Details'(033).
    ENDIF. " IF SY-SUBRC NE 0.
    ENDIF. " IF NOT T_EKKO IS INITIAL
    ENDFORM. " SELECT_VENDOR
    *& Form DESCRIPTION
    Subroutine to get the description
    There are no interface parameters to be passed to this subroutine.
    FORM DESCRIPTION .
    IF NOT T_CDPOS IS INITIAL.
    SORT T_CDPOS_TEMP BY TABNAME FNAME.
    DELETE ADJACENT DUPLICATES FROM T_CDPOS_TEMP COMPARING TABNAME FNAME
    SELECT TABNAME " Table Name
    FIELDNAME " Field Name
    ROLLNAME " Data element
    FROM DD03L
    INTO TABLE T_DATAELE
    FOR ALL ENTRIES IN T_CDPOS_TEMP
    WHERE TABNAME EQ T_CDPOS_TEMP-TABNAME
    AND FIELDNAME EQ T_CDPOS_TEMP-FNAME.
    IF NOT T_DATAELE IS INITIAL.
    T_DATAELE_TEMP[] = T_DATAELE[].
    SORT T_DATAELE_TEMP BY ROLLNAME.
    DELETE ADJACENT DUPLICATES FROM T_DATAELE_TEMP COMPARING ROLLNAME.
    SELECT ROLLNAME " Data element
    DDTEXT " Short Text Describing R/3
    " Repository Objects
    FROM DD04T
    INTO TABLE T_TEXT
    FOR ALL ENTRIES IN T_DATAELE_TEMP
    WHERE ROLLNAME EQ T_DATAELE_TEMP-ROLLNAME
    AND DDLANGUAGE EQ SY-LANGU.
    IF SY-SUBRC NE 0.
    EXIT.
    ENDIF. " IF SY-SUBRC NE 0.
    ENDIF. " IF NOT T_DATAELE IS INITIAL.
    ENDIF. " IF NOT T_CDPOS IS INITIAL.
    ENDFORM. " DESCRIPTION
    *& Form FILL_OUTTAB
    Subroutine to populate the Outtab
    There are no interface parameters to be passed to this subroutine.
    FORM FILL_OUTTAB .
    SORT T_CDHDR BY OBJECTCLAS OBJECTID CHANGENR.
    SORT T_EKKO BY EBELN.
    SORT T_LFA1 BY LIFNR.
    SORT T_DATAELE BY TABNAME FIELDNAME.
    SORT T_TEXT BY ROLLNAME.
    LOOP AT T_CDPOS INTO FS_CDPOS.
    READ TABLE T_CDHDR INTO FS_CDHDR WITH KEY
    OBJECTCLAS = FS_CDPOS-OBJECTCLAS
    OBJECTID = FS_CDPOS-OBJECTID
    CHANGENR = FS_CDPOS-CHANGENR
    BINARY SEARCH.
    IF SY-SUBRC EQ 0.
    MOVE FS_CDHDR-USERNAME TO FS_OUTTAB-USERNAME.
    MOVE FS_CDHDR-UDATE TO FS_OUTTAB-UDATE.
    READ TABLE T_EKKO INTO FS_EKKO WITH KEY
    EBELN = FS_CDHDR-OBJECTID
    BINARY SEARCH.
    IF SY-SUBRC EQ 0.
    MOVE FS_EKKO-EBELN TO FS_OUTTAB-EBELN.
    MOVE FS_EKKO-ERNAM TO FS_OUTTAB-ERNAM.
    MOVE FS_EKKO-LIFNR TO FS_OUTTAB-LIFNR.
    MOVE FS_EKKO-EKGRP TO FS_OUTTAB-EKGRP.
    MOVE FS_EKKO-BEDAT TO FS_OUTTAB-BEDAT.
    READ TABLE T_LFA1 INTO FS_LFA1 WITH KEY
    LIFNR = FS_EKKO-LIFNR
    BINARY SEARCH.
    IF SY-SUBRC EQ 0.
    MOVE FS_LFA1-NAME1 TO FS_OUTTAB-NAME1.
    ENDIF. " IF SY-SUBRC EQ 0.
    ENDIF. " IF SY-SUBRC EQ 0.
    ENDIF. " IF SY-SUBRC EQ 0.
    MOVE FS_CDPOS-VALUE_NEW TO FS_OUTTAB-VALUE_NEW.
    MOVE FS_CDPOS-VALUE_OLD TO FS_OUTTAB-VALUE_OLD.
    READ TABLE T_DATAELE INTO FS_DATAELE WITH KEY
    TABNAME = FS_CDPOS-TABNAME
    FIELDNAME = FS_CDPOS-FNAME
    BINARY SEARCH.
    IF SY-SUBRC EQ 0.
    READ TABLE T_TEXT INTO FS_TEXT WITH KEY
    ROLLNAME = FS_DATAELE-ROLLNAME
    BINARY SEARCH.
    IF SY-SUBRC EQ 0.
    MOVE FS_TEXT-DDTEXT TO FS_OUTTAB-DDTEXT.
    ENDIF. " IF SY-SUBRC EQ 0.
    ENDIF. " IF SY-SUBRC EQ 0.
    APPEND FS_OUTTAB TO T_OUTTAB.
    CLEAR FS_OUTTAB.
    ENDLOOP.
    ENDFORM. " FILL_OUTTAB
    *& Form GET_CELL_INFO
    Subroutine to get the Cell Information
    --> W_VALUE Holds the value of Hotspot clicked
    FORM GET_CELL_INFO .
    CALL METHOD W_GRID->GET_CURRENT_CELL
    IMPORTING
    E_ROW =
    E_VALUE = W_VALUE
    E_COL =
    ES_ROW_ID =
    ES_COL_ID =
    ES_ROW_NO =
    ENDFORM. " GET_CELL_INFO
    *& Form VALIDATE_PD_NUM
    Subroutine to validate Purchase Document Number
    There are no interface parameters to be passed to this subroutine.
    FORM VALIDATE_PD_NUM .
    IF NOT S_EBELN[] IS INITIAL.
    SELECT EBELN " Purchase Document Number
    FROM EKKO
    INTO W_EBELN
    UP TO 1 ROWS
    WHERE EBELN IN S_EBELN.
    ENDSELECT.
    IF SY-SUBRC NE 0.
    CLEAR SSCRFIELDS-UCOMM.
    MESSAGE E717(M8).
    ENDIF. " IF SY-SUBRC NE 0
    ENDIF. " IF NOT S_EBELN[]...
    ENDFORM. " VALIDATE_PD_NUM
    *& Form VALIDATE_VEN_NUM
    Subroutine to validate Vendor Number
    There are no interface parameters to be passed to this subroutine.
    FORM VALIDATE_VEN_NUM .
    IF NOT S_LIFNR[] IS INITIAL.
    SELECT LIFNR " Vendor Number
    FROM LFA1
    INTO W_LIFNR
    UP TO 1 ROWS
    WHERE LIFNR IN S_LIFNR.
    ENDSELECT.
    IF SY-SUBRC NE 0.
    CLEAR SSCRFIELDS-UCOMM.
    MESSAGE E002(M8) WITH W_SPACE.
    ENDIF. " IF SY-SUBRC NE 0
    ENDIF. " IF NOT S_LIFNR[]...
    ENDFORM. " VALIDATE_VEN_NUM
    *& Form VALIDATE_PUR_GRP
    Subroutine to validate the Purchase Group
    There are no interface parameters to be passed to this subroutine.
    FORM VALIDATE_PUR_GRP .
    IF NOT S_EKGRP[] IS INITIAL.
    SELECT EKGRP " Purchase Group
    FROM T024
    INTO W_EKGRP
    UP TO 1 ROWS
    WHERE EKGRP IN S_EKGRP.
    ENDSELECT.
    IF SY-SUBRC NE 0.
    CLEAR SSCRFIELDS-UCOMM.
    MESSAGE E622(M8) WITH W_SPACE.
    ENDIF. " IF SY-SUBRC NE 0
    ENDIF. " IF NOT S_EKFRP[]...
    ENDFORM. " VALIDATE_PUR_GRP
    *& Form FILL_VARIANT
    Subroutine to fill the Variant Structure
    There are no interface parameters to be passed to this subroutine
    FORM FILL_VARIANT .
    Filling the Variant structure
    W_VARIANT-REPORT = SY-REPID.
    W_VARIANT-USERNAME = SY-UNAME.
    ENDFORM. " FILL_VARIANT
    Check my previous links
    Regards
    Pavan

  • Regarding Object oreinted concepts

    hello all,
    do any one have basic learning material related to Object oreinted concepts in ABAP.
    plz do forward it to me at [email protected]
    thanks for ur help..
    if its useful i'll rewards points.

    Hi
    Here are few links
    http://www.erpgenie.com/abap/OO/defn.htm
    http://help.sap.com/saphelp_nw04s/helpdata/en/ce/b518b6513611d194a50000e8353423/frameset.htm
    http://esnips.com/doc/39fdc647-1aed-4b40-a476-4d3042b6ec28/class_builder.ppt
    http://esnips.com/doc/448e8302-68b1-4046-9fef-8fa8808caee0/abap-objects-by-helen.pdf
    http://esnips.com/doc/92be4457-1b6e-4061-92e5-8e4b3a6e3239/Object-Oriented-ABAP.ppt
    http://esnips.com/doc/5c65b0dd-eddf-4512-8e32-ecd26735f0f2/prefinalppt.ppt
    http://esnips.com/doc/2c76dc57-e74a-4539-a20e-29383317e804/OO-abap.pdf
    http://esnips.com/doc/0ef39d4b-586a-4637-abbb-e4f69d2d9307/SAP-CONTROLS-WORKSHOP.pdf
    Hi
    go through the following limks...
    http://help.sap.com/saphelp_47x200/helpdata/en/ce/b518b6513611d194a50000e8353423/content.htm
    Classes
    http://help.sap.com/saphelp_47x200/helpdata/en/c3/225b5c54f411d194a60000e8353423/content.htm
    Object Handling
    http://help.sap.com/saphelp_47x200/helpdata/en/c3/225b5f54f411d194a60000e8353423/content.htm
    Declaring and Calling methods
    http://help.sap.com/saphelp_47x200/helpdata/en/08/d27c03b81011d194f60000e8353423/content.htm
    Inheritance.
    http://help.sap.com/saphelp_47x200/helpdata/en/dd/4049c40f4611d3b9380000e8353423/content.htm
    Interfaces.
    http://help.sap.com/saphelp_47x200/helpdata/en/c3/225b6254f411d194a60000e8353423/content.htm
    Trigerring and handling Events
    http://help.sap.com/saphelp_47x200/helpdata/en/71/a8a77955bc11d194aa0000e8353423/content.htm
    What is Object Orientation?
    In the past, information systems used to be defined primarily by their functionality: data and functions were kept separate and linked together by means of input and output relations.
    The object-oriented approach, however, focuses on objects that represent abstract or concrete things of the real world. These objects are first defined by their character and their properties which are represented by their internal structure and their attributes (data). The behaviour of these objects is described by methods (functionality).
    Objects form a capsule which combines the character to the respective behaviour. Objects should enable programmers to map a real problem and its proposed software solution on a one-to-one basis.
    Typical objects in a business environment are, for example, ‘Customer’, ‘Order’, or ‘Invoice’. From Release 3.1 onwards, the Business Object Repository (BOR) of SAP Web Applicaton Server ABAP has contained examples of such objects. The BOR object model will be integrated into ABAP Objects in the next Release by migrating the BOR object types to the ABAP class library.
    A comprehensive introduction to object orientation as a whole would go far beyond the limits of this introduction to ABAP Objects. This documentation introduces a selection of terms that are used universally in object orientation and also occur in ABAP Objects. In subsequent sections, it goes on to discuss in more detail how these terms are used in ABAP Objects. The end of this section contains a list of further reading, with a selection of titles about object orientation.
    Objects
    Objects are instances of classes. They contain data and provides services. The data forms the attributes of the object. The services are known as methods (also known as operations or functions). Typically, methods operate on private data (the attributes, or state of the object), which is only visible to the methods of the object. Thus the attributes of an object cannot be changed directly by the user, but only by the methods of the object. This guarantees the internal consistency of the object.
    Classes
    Classes describe objects. From a technical point of view, objects are runtime instances of a class. In theory, you can create any number of objects based on a single class. Each instance (object) of a class has a unique identity and its own set of values for its attributes.
    Object References
    In a program, you identify and address objects using unique object references. Object references allow you to access the attributes and methods of an object.
    In object-oriented programming, objects usually have the following properties:
    Encapsulation
    Objects restrict the visibility of their resources (attributes and methods) to other users. Every object has an interface, which determines how other objects can interact with it. The implementation of the object is encapsulated, that is, invisible outside the object itself.
    Inheritance
    You can use an existing class to derive a new class. Derived classes inherit the data and methods of the superclass. However, they can overwrite existing methods, and also add new ones.
    Polymorphism
    Identical (identically-named) methods behave differently in different classes. In ABAP Objects, polymorphism is implemented by redefining methods during inheritance and by using constructs called interfaces.
    Uses of Object Orientation
    Below are some of the advantages of object-oriented programming:
    · Complex software systems become easier to understand, since object-oriented structuring provides a closer representation of reality than other programming techniques.
    · In a well-designed object-oriented system, it should be possible to implement changes at class level, without having to make alterations at other points in the system. This reduces the overall amount of maintenance required.
    · Through polymorphism and inheritance, object-oriented programming allows you to reuse individual components.
    · In an object-oriented system, the amount of work involved in revising and maintaining the system is reduced, since many problems can be detected and corrected in the design phase.
    Achieving these goals requires:
    · Object-oriented programming languages
    Object-oriented programming techniques do not necessarily depend on object-oriented programming languages. However, the efficiency of object-oriented programming depends directly on how object-oriented language techniques are implemented in the system kernel.
    · Object-oriented tools
    Object-oriented tools allow you to create object-oriented programs in object-oriented languages. They allow you to model and store development objects and the relationships between them.
    · Object-oriented modeling
    The object-orientation modeling of a software system is the most important, most time-consuming, and most difficult requirement for attaining the above goals. Object-oriented design involves more than just object-oriented programming, and provides logical advantages that are independent of the actual implementation.
    This section of the ABAP User’s Guide provides an overview of the object-oriented extension of the ABAP language. We have used simple examples to demonstrate how to use the new features. However, these are not intended to be a model for object-oriented design. More detailed information about each of the ABAP Objects statements is contained in the keyword documentation in the ABAP Editor. For a comprehensive introduction to object-oriented software development, you should read one or more of the titles listed below.
    ABAP supports a hybrid programming model. You can use an object-oriented ("OO") programming model based on classes and interfaces, and you can use the more classic procedural and event-driven programming model based on function modules, subroutines, dialog modules, and event blocks. Both models can be used in parallel. You can use classes inside classic processing blocks or you can call classic procedures from methods. In ABAP Objects, SAP has implemented a cleanup of the ABAP language. Within the scope of this language cleanup, stricter syntax checks are performed in classes that restrict the usage of obsolete language elements.
    Object orientation in ABAP is an extension of the ABAP language that makes available the advantages of object-oriented programming, such as encapsulation, interfaces, and inheritance. This helps to simplify applications and make them more controllable.
    ABAP Objects is fully compatible with the existing language, so you can use existing statements and modularization units in programs that use ABAP Objects, and can also use ABAP Objects in existing ABAP programs.
    Check these links
    /people/thomas.jung3/blog/2005/09/08/oo-abap-dynpro-programming
    /people/ravikumar.allampallam/blog/2005/02/11/abap-oo-in-action
    This is good for beginners
    /people/sap.user72/blog/2005/05/10/a-small-tip-for-the-beginners-in-oo-abap
    Reward all helpfull answers

Maybe you are looking for

  • How to change the Data Base Relation in a universe?

    We are working with BO 6.5a.One universe in connected to a 'DB2/400 (iSeries)'  data base. All Objects in a universe are related to a defined library like <libraryname>.<tablename>.<fieldname>. We like to change the libraryname. Is there any chance t

  • How to convert mp3 software instrument samples to format garageband can use

    Hi and thanks in advance. I'm using GB '08 on OSX 10.4.11 w/ a G4 MDD. ( Sorry folks,  This is the setup that I have and cannot buy a new computer or software at this time) I'm pretty new too DAW and all of this but want to compose music with traditi

  • SharePoint 2010 Designer workflow failing in an Ad hoc manner.

    Hi Friends, We have a SharePoint 2010 Designer workflow with 25 approval stages (supposed to run for around 1.5 yrs. ) . We have a consistent problem in the workflow as it keeps failing with message "error occured" at some stages(not uniform) after a

  • Display ship to party in FBL5N

    hi i want to display ship to party in fbl5n tcoce. i copy the function module SAMPLE_INTERFACE_00001650 and add one field in rfpos and pfposx structure. i can get the field in fbl5n tcode. now i want to know from which table i can get the  ship to pa

  • Rendered effects don't hold on Restart CS4

    I opened a CS3 project in CS4 off an external hard drive. It came up fine but I had to rerender all files as expected and of course it generated all new peak files. But when I saved the project and later reopened it - all renders were gone - the red