Saturday, 10 August 2013

sample code To capture the Lead selection values in webdynpro abap

  DATA lo_nd_it_mara TYPE REF TO if_wd_context_node.
  DATA lt_it_mara TYPE wd_this->elements_it_mara.
  DATA ls_it_mara TYPE wd_this->element_it_mara.
  DATA it_mara_new TYPE wd_this->elements_it_mara.
  DATA ls_mara_new TYPE wd_this->element_it_mara.

*   navigate from <CONTEXT> to <IT_MARA> via lead selection
  lo_nd_it_mara = wd_context->get_child_node( name = wd_this->wdctx_it_mara ).
  lo_nd_it_mara->get_static_attributes_table( IMPORTING table = lt_it_mara ).

  DATA:   ld_element   TYPE REF TO if_wd_context_element,
          it_rows  TYPE wdr_context_element_set,
          wa_rows LIKE LINE OF it_rows.
  DATA: ld_index TYPE i.

*** to get the lead selected values

  ld_element   = lo_nd_it_mara->get_lead_selection( ).
  it_rows  = lo_nd_it_mara->get_selected_elements( including_lead_selection = abap_true ).

  LOOP AT it_rows INTO wa_rows.
    CALL METHOD wa_rows->get_static_attributes
        static_attributes = ls_mara_new."wa_selrow.

    READ TABLE lt_it_mara INTO ls_it_mara WITH KEY matnr = ls_mara_new-matnr.
    ld_index = sy-tabix. "index of selected row

    APPEND ls_it_mara TO it_mara_new.

  IF it_mara_new IS NOT INITIAL.
    DATA lo_nd_it_mara_new TYPE REF TO if_wd_context_node.
    DATA lt_it_mara_new TYPE wd_this->elements_it_mara_new.

* navigate from <CONTEXT> to <IT_MARA_NEW> via lead selection
    lo_nd_it_mara_new = wd_context->get_child_node( name = wd_this->wdctx_it_mara_new ).
    SORT it_mara_new BY matnr.
    lo_nd_it_mara_new->bind_table( it_mara_new ).

Monday, 1 July 2013

Link related to Datebase table - useful

Table buffering in SAP - important

Pls refer the belo link:

 Which Tables should be Buffered?  Locate the document in its SAP Library structure
Only transparent tables and pooled tables can be buffered. Cluster tables cannot be buffered.
Character data types must be assigned to all key fields of buffered tables, that is the data type of the field must be mapped to one of the ABAP types C, N, D or T (see
Mapping to ABAP Data Types).The following two points speak against table buffering:
  • The data read by the application must always be up-to-date. Delays caused by the synchronization mechanism (see
Synchronization of Local Buffers) cannot be accepted.
  • The table data is frequently modified. In this case the cost of synchronization could be greater than the gain in performance resulting from buffering. Roughly speaking, it does not make sense to buffer a table if more than one percent of the accesses to the table are modifying accesses.

  • The table containing currency exchange rates is updated only once a day, but it is read frequently. Buffering is recommended in this case.
    Typical candidates for buffering include customizing and system tables. In certain cases master data with customizing character can also be buffered.
    The contents of buffered tables are not always up-to-date in a distributed system. You can bypass the buffer and read the data directly from the database table with the ABAP command "SELECT SINGLE ... BYPASSING BUFFER". If a buffered table is accessed frequently with this command, you should consider whether it is really necessary for the table to be buffered or whether it is essential to have the current state of the database.
    You must define whether and how a table is buffered in its technical settings (see
    Technical Settings).


    Start of Content Area
    Background documentation Buffering Database Tables  Locate the document in its SAP Library structure
    Buffering a table improves the performance when accessing the data records contained in the table.
    The table buffers reside locally on each application server in the system. The data of buffered tables can thus be accessed directly from the buffer of the application server. This avoids the time-consuming process of accessing the database.
    This graphic is explained in the accompanying text
    Buffering is particularly important in client/server environments, as it takes considerably longer to access a table with the network than it does to access a table that is buffered locally. Depending on the network load, this factor can lie between 10 and 100.
    The difference in performance is somewhat less marked in central systems (systems with only one application server) than in local ones (systems with several application servers). However, even in central systems, a reduction in process changes and increased sophistication of the buffering over that provided by the database system have a noticeable effect on performance.
    How are the Buffers Filled?If a program accesses the data of a buffered table, the database interface determines whether this data is in the buffer of the application server. If this is the case, the data is read directly from the buffer. If the data is not in the buffer of the application server, it is read from the database and loaded into the buffer. The next access to this data can then use the buffer.
    buffering type determines which records are loaded into the buffer during an access.This graphic is explained in the accompanying text
    How are the Local Buffers Synchronized?A buffered table is generally read on all application servers and held in the buffer there. If a program changes the data contained in the table on an application server, this is noted in the log table by the database interface. The buffers still have the old status on all the other application servers, so that the programs might read obsolete data.
    synchronization mechanism runs at a fixed time interval, usually every 1-2 minutes. The log table is read and the buffer contents that were changed by other servers are invalidated. In the next access, the data of invalidated tables is read directly from the database and updated in the buffer.DisplacementIf more space is required in the buffer due to new data, the data that has not been accessed for the longest time is displaced. The data is displaced asynchronously at certain times that are defined dynamically by the buffer accesses. The data is only displaced if at this time the free space in the buffer is less than a given value or if the access quality is not good enough.Resetting the Table BuffersYou can reset the table buffers on the corresponding application servers by entering $TAB in the command field. All the data in the buffer is invalidated.
    Only use this command if inconsistencies occurred in the buffer! It can take several hours to fill the buffers in large systems. Performance is considerably reduced during this time.
    See also:Local Buffer SynchronizationWhich Tables Should be Buffered?
    How are Table Buffers Implemented Technically?
    Which Accesses Proceed Directly to the Database?How can you Analyze the Buffer Quality?

    Work Processes in SAP

    Work Processes 
    Work processes execute the individual dialog steps in R/3 applications. The next two sections describe firstly the structure of a work process, and secondly the different types of work process in the R/3 System.Structure of a Work ProcessWork processes execute the dialog steps of application programs. They are components of an application server. The following diagram shows the components of a work process:

    Each work process contains two software processors and a database interface.
    Screen ProcessorIn R/3 application programming, there is a difference between user interaction and processing logic. From a programming point of view, user interaction is controlled by screens. As well as the actual input mask, a screen also consists of flow logic. The screen flow logic controls a large part of the user interaction. The R/3 Basis system contains a special language for programming screen flow logic. The screen processor executes the screen flow logic. Via the dispatcher, it takes over the responsibility for communication between the work process and the SAPgui, calls modules in the flow logic, and ensures that the field contents are transferred from the screen to the flow logic.ABAP-ProzessorThe actual processing logic of an application program is written in ABAP - SAP’s own programing language. The ABAP processor executes the processing logic of the application program, and communicates with the database interface. The screen processor tells the ABAP processor which module of the screen flow logic should be processed next. The following screen illustrates the interaction between the screen and the ABAP processors when an application program is running.
    Database InterfaceThe database interface provides the following services:
    • Establishing and terminating connections between the work process and the database.
    • Access to database tables
    • Access to R/3 Repository objects (ABAP programs, screens and so on)
    • Access to catalog information (ABAP Dictionary)
    • Controlling transactions (commit and rollback handling)
    • Table buffer administration on the application server.
    The following diagram shows the individual components of the database interface:

    The diagram shows that there are two different ways of accessing databases: Open SQL and Native SQL.
    Open SQL statements are a subset of Standard SQL that is fully integrated in ABAP. They allow you to access data irrespective of the database system that the R/3 installation is using. Open SQL consists of the Data Manipulation Language (DML) part of Standard SQL; in other words, it allows you to read (SELECT) and change (INSERT, UPDATE, DELETE) data. The tasks of the Data Definition Language (DDL) and Data Control Language (DCL) parts of Standard SQL are performed in the R/3 System by the ABAP Dictionary and the authorization system. These provide a unified range of functions, irrespective of database, and also contain functions beyond those offered by the various database systems.
    Open SQL also goes beyond Standard SQL to provide statements that, in conjunction with other ABAP constructions, can simplify or speed up database access. It also allows you to buffer certain tables on the application server, saving excessive database access. In this case, the database interface is responsible for comparing the buffer with the database. Buffers are partly stored in the working memory of the current work process, and partly in the shared memory for all work processes on an application server. Where an R/3 System is distributed across more than one application server, the data in the various buffers is synchronized at set intervals by the buffer management. When buffering the database, you must remember that data in the buffer is not always up to date. For this reason, you should only use the buffer for data which does not often change.
    Native SQL is only loosely integrated into ABAP, and allows access to all of the functions contained in the programming interface of the respective database system. Unlike Open SQL statements, Native SQL statements are not checked and converted, but instead are sent directly to the database system. Programs that use Native SQL are specific to the database system for which they were written. R/3 applications contain as little Native SQL as possible. In fact, it is only used in a few Basis components (for example, to create or change table definitions in the ABAP Dictionary).
    The database-dependent layer in the diagram serves to hide the differences between database systems from the rest of the database interface. You choose the appropriate layer when you install the Basis system. Thanks to the standardization of SQL, the differences in the syntax of statements are very slight. However, the semantics and behavior of the statements have not been fully standardized, and the differences in these areas can be greater. When you use Native SQL, the function of the database-dependent layer is minimal.
    Types of Work ProcessAlthough all work processes contain the components described above, they can still be divided into different types. The type of a work process determines the kind of task for which it is responsible in the application server. It does not specify a particular set of technical attributes. The individual tasks are distributed to the work processes by the dispatcher.
    Before you start your R/3 System, you determine how many work processes it will have, and what their types will be. The dispatcher starts the work processes and only assigns them tasks that correspond to their type. This means that you can distribute work process types to optimize the use of the resources on your application servers.
    The following diagram shows again the structure of an application server, but this time, includes the various possible work process types:

    The various work processes are described briefly below. Other parts of this documentation describe the individual components of the application server and the R/3 System in more detail.
    Dialog Work ProcessDialog work processes deal with requests from an active user to execute dialog steps.Update Work ProcessUpdate work processes execute database update requests. Update requests are part of an SAP LUW that bundle the database operations resulting from the dialog in a database LUW for processing in the background.Background Work ProcessBackground work processes process programs that can be executed without user interaction (background jobs).Enqueue Work ProcessThe enqueue work process administers a lock table in the shared memory area. The lock table contains the logical database locks for the R/3 System and is an important part of the SAP LUW concept. In an R/3 System, you may only have one lock table. You may therefore also only have one application server with enqueue work processes.Spool Work ProcessThe spool work process passes sequential datasets to a printer or to optical archiving. Each application server may contain only one spool work process.
    The services offered by an application server are determined by the types of its work processes. One application server may, of course, have more than one function. For example, it may be both a dialog server and the enqueue server, if it has several dialog work processes and an enqueue work process.
    You can use the system administration functions to switch a work process between dialog and background modes while the system is still running. This allows you, for example, to switch an R/3 System between day and night operation, where you have more dialog than background work processes during the day, and the other way around during the night.

    Lock concept in sap

    Start of Content Area
    The R/3 Lock Concept  Locate the document in its SAP Library structure
    Das R/3 SperrkonzeptReasons for Setting LocksSuppose a travel agent want to book a flight. The customer wants to fly to a particular city with a certain airline on a certain day. The booking must only be possible if there are still free places on the flight. To avoid the possibility of overbooking, the database entry corresponding to the flight must be locked against access from other transactions. This ensures that one user can find out the number of free places, make the booking, and change the number of free places without the data being changed in the meantime by another transaction. Lock Mechanisms in the Database SystemThe database system automatically sets database locks when it receives change statements (INSERT, UPDATE, MODIFY, DELETE) from a program. Database locks are physical locks on the database entries affected by these statements. You can only set a lock for an existing database entry, since the lock mechanism uses a lock flag in the entry. These flags are automatically deleted in each database commit. This means that database locks can never be set for longer than a single database LUW; in other words, a single dialog step in an R/3 application program.
    Physical locks in the database system are therefore insufficient for the requirements of an R/3 transaction. Locks in the R/3 System must remain set for the duration of a whole SAP LUW, that is, over several dialog steps. They must also be capable of being handled by different work processes and even different application servers. Consequently, each lock must apply on all servers in that R/3 System.
    SAP LocksTo complement the SAP LUW concept, in which bundled database changes are made in a single database LUW, the R/3 System also contains a lock mechanism, fully independent of database locks, that allows you to set a lock that spans several dialog steps. These locks are known as SAP locks.
    The SAP lock concept is based on lock objects. Lock objects allow you to set an SAP lock for an entire application object. An application object consists of one or more entries in a database table, or entries from more than one database table that are linked using foreign key relationships.
    Before you can set an SAP lock in an ABAP program, you must first create a lock object in the ABAP Dictionary. A lock object definition contains the database tables and their key fields on the basis of which you want to set a lock. When you create a lock object, the system automatically generates two function modules with the names
    ENQUEUE_<lock object name> and DEQUEUE_<lock object name> . You can then set and release SAP locks in your ABAP program by calling these function modules in a CALL FUNCTION statement.This graphic is explained in the accompanying text
    See also: Example Transaction: SAP Locking.These function modules are executed in a special enqueue work process. Within an R/3 System, enqueue work processes run on a single application server. This server maintains a central lock table for the entire R/3 System in its shared memory.
    This graphic is explained in the accompanying text
    The enqueue function module sets an SAP lock by writing entries in the central lock table. If the lock cannot be set because the application object (or a part of it) is already locked, this is reflected in the return code sy-subrc. The following diagram shows the components of the R/3 System that are involved in setting a lock.
    Unlike the database, which sets physical locks, the SAP lock mechanism sets logical locks. This means that
    • A locked database entry is not physically locked in the database table.
    The lock entry is merely entered as a lock argument in the central R/3 lock table. The lock argument is made up of the primary key field values for the tables in the lock object. These are import parameters of the enqueue function module. The lock is independent of database LUWs. It is released either implicitly when the database update or the SAP transaction ends, or explicitly, using the corresponding dequeue function module. You can use a special parameter in the update function module to set the exact point at which the lock is released during the database update.
    • A locked entry does not necessarily have to exist in a database table.
    You can, for example, set a lock as a precaution for a database entry that is not written to the database until the update at the end of the SAP LUW.
    • The effectiveness of the locks depends on cooperative application programming.
    Since there are no physical locks in the database tables themselves, all programs that use the same application objects must look in the central table themselves for any locks. There is no mechanism that automatically prevents a program from ignoring the locks in the lock table.Lock TypesThere are two types of lock in the R/3 System:
    • Shared lock
    Shared locks (or read locks) allow you to prevent data from being changed while you are reading it. They prevent other programs from setting an exclusive lock (write lock) to change the object. It does not, however, prevent other programs from setting further read locks.
    • Exclusive lock
    Exclusive locks (or write locks) allow you to prevent data from being changed while you are changing it yourself. An exclusive lock, as its name suggests, locks an application object for exclusive use by the program that sets it. No other program can then set either a shared lock or an exclusive lock for the same application object.
    Lock DurationWhen you set a lock, you should bear in mind that if it remains set for a long time, the availability of the object to other transactions is reduced. Whether or not this is acceptable depends on the nature of the task your program is performing.
    Remember in particular that setting too many shared locks without good reason can have a considerable effect on programs that work with database tables. If several programs running concurrently all set a shared lock for the same application object in the system, it can make it almost impossible to set an exclusive lock, since the program that needs to set that lock will be unable to find any time when there are no locks at all set for that object. Conversely, a single exclusive lock prevents all other programs from reading the locked object.
    At the end of an SAP LUW, you should release all locks. This either happens automatically during the database update, or explicitly, when you call the corresponding dequeue function module. Locks that are not linked to a database update are released at the end of the SAP transaction.

    Update Function module

    It is basically used to bundle distributed updates within different programs spots, to one place (in FM).

    Such FM would store all the UPDATE/INSERT/DELETE statements which otherwise you would write in some program place. Now when system reaches CALL FUNCTION 'XXX' IN UDPDATE TASK it doesn't go inside. Instead in registeres this XXX FM in VBLOG table (you can see update tasks in SM13) to be executed later. Now when in program it reaches COMMIT WORK statement, it looks into that table and calls each registered functions.
    The aim is to either COMMIT all the changes at once, or ROLLBACK them all. This means that if inside one of any FM these statements are encountered system writes changes to DB permanently. Next it clears VBLOG table (so no FM are registered for change anymore) and continues the program.


    Creating Update Function Modules  Locate the document in its SAP Library structure
    To create a function module, you first need to start the Function Builder. Choose Tools ® ABAP Workbench, Function Builder. For more information about creating function modules, refer to the ABAP Workbench Tools documentation.To be able to call a function module in an update work process, you must flag it in the Function Builder. When you create the function module, set the Process Type attribute to one of the following values:
    • Update with immediate start
    Set this option for high priority ("V1") functions that run in a shared (SAP LUW). These functions can be restarted by the update task in case of errors.
    • Update w. imm. start, no restart
    Set this option for high priority ("V1") functions that run in a shared (SAP LUW). These functions may not be restarted by the update task.
    • Update with delayed start
    Set this option for low priority ("V2") functions that run in their own update transactions. These functions can be restarted by the update task in case of errors.
    To display the attributes screen in the Function Builder, choose Goto Administration.
    Defining the InterfaceFunction modules that run in the update task have a limited interface:
    • Result parameters or exceptions are not allowed since update-task function modules cannot report on their results.
    • You must specify input parameters and tables with reference fields or reference structures defined in the ABAP Dictionary.

    CALL FUNCTION update_function IN UPDATE TASK
                                 [EXPORTING p1 = a1 p2 = a2 ...]
                                 [TABLES t1 = itab1 t2 = itab2 ...].

    This statement registers the update function module specified in update_function. update_function must be a character-type field, which during execution of the statement contains the name of an update function module in uppercase letters.

    An update function module is a function module, for which in the Function Builder the property update module is marked. The registration of an update function module is an essential part of the update task.

    The function module is not executed immediately, but is scheduled for execution in a special work process (update work process). For this purpose, the name of the function module including the passed actual parameters is stored as a log record in the database table VBLOG. If the statement is executed during the update task, the addition IN UPDATE TASK is ignored.

    If the statement
    SET UPDATE TASK LOCAL is executed before registration of an update function module in the current SAP LUW, registration takes place in the ABAP memory rather than on the database, and for the current work process.

    The actual execution is triggered by the statement COMMIT WORK. The formal parameters of the function module receive the values of the actual parameters from table VBLOG. A function module that is registered several times will also be excuted several times with the respective parameter values.
    If a COMMIT WORK statement is not executed after registration of a function module during execution of the current program, the function module is not executed and is deleted from table VBLOG at the end of the program.

    Addition 1

    ... EXPORTING p1 = a1 p2 = a2 ...

    Addition 2

    ... TABLES t1 = itab1 t2 = itab2 ...


    The additions EXPORTING and TABLES have the same syntax and meaning as in the parameter_list of the general function module call, except that for EXPORTING, no Referenzvariablen or data objects that contain reference variables can be output as actual parameters.


    • The additions IMPORTING, CHANGING and EXCEPTIONS of the general function module call may be specified, but they are ignored during the execution. The additions for a dynamic parameter transfer are not allowed.

    • While an update function module is processed in an update work process, you are not allowed to execute the statements SUBMIT, CALL DIALOG, CALL SCREEN, CALL TRANSACTION, COMMIT WORK, ROLLBACK WORK and all other statements that provoke a database commit.

    • If during the update an error occurs, the update work process executes a database rollback, returns the log record with a note into table VBLOG and informs the user whose program has created the log record by SAPMail. After removing the error cause, the returned log records can be updated again.

    LUW and SAP LUW

    Transactions and Logical Units of Work  Locate the document in its SAP Library structure

    In everyday language, a transaction is a sequence of actions that logically belong together in a business sense and that either procure or process data. It covers a self-contained procedure, for example, generating a list of customers, creating a flight booking, or sending reminders to customers. From the user’s viewpoint, it forms a logical unit.
    The completeness and correctness of data must be assured within this unit. In the middle of a transaction, the data will usually be inconsistent. For example, when you transfer an amount in financial accounting, this must first be deducted from one account before being credited to another. In between the two postings, the data is inconsistent, since the amount that you are posting does not exist in either account. It is essential for application programmers to know that their data is consistent at the end of the transaction. If an error occurs, it must be possible to undo the changes made within a logical process.
    There are three relevant concepts in this context:
    Database Logical Unit of Work (LUW)
    A database LUW is the mechanism used by the database to ensure that its data is always consistent.
    An SAP LUW is a logical unit consisting of dialog steps, whose changes are written to the database in a single database LUW.
    SAP Transaction
    An SAP transaction is an ABAP application program that you start using a transaction code. It may contain one or more SAP LUWs.
    The following sections of this documentation explain these three terms in more detail.

    Database Logical Unit of Work (LUW)  Locate the document in its SAP Library structure

    From the point of view of database programming, a database LUW is an inseparable sequence of database operations that ends with a database commit. The database LUW is either fully executed by the database system or not at all. Once a database LUW has been successfully executed, the database will be in a consistent state. If an error occurs within a database LUW, all of the database changes since the beginning of the database LUW are reversed. This leaves the database in the state it was in before the transaction started.
    This graphic is explained in the accompanying text
    The database changes that occur within a database LUW are not actually written to the database until after the database commit. Until this happens, you can use a database rollback to reverse the changes. In the R/3 System, database commits and rollbacks can be triggered either implicitly or using explicit commands.
    Implicit Database Commits in the R/3 System
    A work process can only execute a single database LUW. The consequence of this is that a work process must always end a database LUW when it finishes its work for a user or an external call. Work processes trigger an implicit database commit in the following situations:
    ·        When a dialog step is completed
    Control changes from the work process back to the SAP GUI.
    ·        When a function module is called in another work process (RFC).
    Control passes to the other work process.
    ·        When the called function module (RFC) in the other work process ends.
    Control returns to the calling work process.
    ·        When a WAIT statement interrupts the work process.
    Control passes to another work process.
    ·        Error dialogs (information, warning, or error messages) in dialog steps.
    Control passes from the work process to the SAP GUI.
    Explicit Database Commits in the R/3 System
    There are two ways to trigger an explicit database commit in your application programs:
    ·        Call the function module DB_COMMIT
    The sole task of this function module is to start a database commit.
    ·        Use the ABAP statement COMMIT WORK
    This statement starts a database commit, but also performs other tasks (refer to the keyword documentation for COMMIT WORK).
    Implicit Database Rollbacks in the R/3 System
    The following cases lead to an implicit database rollback:
    ·        Runtime error in an application program
    This occurs whenever an application program has to terminate because of an unforeseen situation (for example, trying to divide by zero).
    ·        Termination message
    Termination messages are generated using the ABAP statement MESSAGE with the message type A or X. In certain cases (updates), they are also generated with message types I, W, and E. These messages end the current application program.
    Explicit Database Rollbacks in the R/3 System
    You can trigger a database rollback explicitly using the ABAP statement ROLLBACK WORK. This statement starts a database rollback, but also performs other tasks (refer to the keyword documentation for ROLLBACK WORK).
    From the above, we can draw up the following list of points at which database LUWs begin and end.
    A Database LUW Begins
    ·        Each time a dialog step starts (when the dialog step is sent to the work process).
    ·        Whenever the previous database LUW ends in a database commit.
    ·        Whenever the previous database LUW ends in a database rollback.
    A Database LUW Ends
    ·        Each time a database commit occurs. This writes all of the changes to the database.
    ·        Each time a database rollback occurs. This reverses all of the changes made during the LUW.
    Database LUWs and Database Locks
    As well as the database changes made within it, a database LUW also consists of database locks. The database system uses locks to ensure that two or more users cannot change the same data simultaneously, since this could lead to inconsistent data being written to the database. A database lock can only be active for the duration of a database LUW. They are automatically released when the database LUW ends. In order to program SAP LUWs, we need a lock mechanism within the R/3 System that allows us to create locks with a longer lifetime (refer to The R/3 Locking Concept).


    Logical Unit of Work (LUW )
    A Logical Unit of Work (LUW or database transaction) is an inseparable sequence of database operations which must be executed either in its entirely or not at all. For the database system, it thus constitutes a unit.

    LUWs help to guarantee database integrity. When an LUW has been successfully concluded, the database is once again in a correct state. If, however, an error occurs within an LUW, all database changes made since the beginning of the LUW are canceled and the database is then in the same state as before the LUW started.

    In the R/3 System, there are three terms frequently used in this context:
    Database Logical Unit of Work (LUW)
    A database LUW is the mechanism used by the database to ensure that its data is always consistent.
    An SAP LUW is a logical unit consisting of dialog steps, whose changes are written to the database in a single database LUW.
    SAP Transaction
    An SAP transaction is an application program that you start using a transaction code. It may contain one or more SAP LUWs.

    Friday, 28 June 2013

    To Create Title bar and Message bar in FPM and to edit at screen level

    To edit the component at screen level:

    we have to open the application with Admin access, for that we have to add some parameters in the application
    &sap-config-mode = X
    and &sap-client = 110(development client name)

    To put title bar:
    for the title bar we have to give the text in IDR application settings
    and for the message area in the main application in the display we havedeclare the same in global settings.

    Thursday, 27 June 2013

    Usefull functional modules in sap ABAP

    Useful ABAP Function Modules

    Function Module to execute unauthorized transactions
    TRANSACTION_CALL_VIA_RFC To execute some unauthorized transactions.
    Function Modules for creating programs (Useful when you are generating programs)
    RS_PROGRAM_CHECK_NAME To check program names if you are generating them.
    RS_CORR_INSERT To insert the correction request in the repository.
    REPS_OBJECT_ACTIVATE To activate repository objects, for example - to activate a newly generated program.
    RS_DELETE_PROGRAM To delete the program.
    RS_ACCESS_PERMISSION To lock or unlock a program.
    Function Modules related to Date and Time Calculations
    CALCULATE_DATE Calculates the future date based on the input .
    DATE_TO_DAY Returns the Day for the entered date. 
    DATE_COMPUTE_DAY Returns weekday for a date
    DATE_GET_WEEK Returns week for a date
    RP_CALC_DATE_IN_INTERVAL Add days / months to a date
    DAY_ATTRIBUTES_GET Returns attributes for a range of dates specified
    MONTHS_BETWEEN_TWO_DATES To get the number of months between the two dates.
    END_OF_MONTH_DETERMINE_2 Determines the End of a Month.
    HR_HK_DIFF_BT_2_DATES Find the difference between two dates in years, months and days.
    FIMA_DAYS_AND_MONTHS_AND_YEARS Find the difference between two dates in years, months and days.
    MONTH_NAMES_GET Get the names of the month
    WEEK_GET_FIRST_DAY Get the first day of the week
    HRGPBS_HESA_DATE_FORMAT Format the date in dd/mm/yyyy format
    SD_CALC_DURATION_FROM_DATETIME Find the difference between two date/time and report the difference in hours
    L_MC_TIME_DIFFERENCE Find the time difference between two date/time
    HR_99S_INTERVAL_BETWEEN_DATES Difference between two dates in days, weeks, months
    LAST_DAY_OF_MONTHS Returns the last day of the month
    DATE_CHECK_PLAUSIBILITY Check for the invalid date.
    DATE_2D_TO_4D_CONVERSION Year entry: 2-character to  4-character.
    DAY_IN_WEEK Input date and will give the name of the day 1-monday,2-Tuesday....
    SD_DATETIME_DIFFERENCE Give the difference in Days and Time for 2 dates
    Holidays and Factory Calendar
    HOLIDAY_GET Gives holidays for a country.It has two flags Freeday(for weekends)and Holiday(for public holidays).
    FACTORYDATE_CONVERT_TO_DATE returns the calendar date for the factory date and the factory calendar passed
    DATE_CONVERT_TO_FACTORYDATE returns the factory date for the date and factory calendar passed
    Popup for dates
    F4_DATE Displays a popup dialog to choose date
    POPUP_TO_SELECT_MONTH Display a pop-up to select a month
    Function Modules related to (ALV)   SAP LIST VIEWER
    REUSE_ALV_GRID_DISPLAY ALV GridControl full screen
    REUSE_ALV_FIELDCATALOG_MERGE Create field catalog from dictionary structure or internal table
    Function Module related to Change Tracking
    CHANGEDOCUMENT_READ_HEADERS Read and format change documents
    CHANGEDOCUMENT_READ read change document headers and items to get the old and new values
    Function Modules Related To Formatting
    CLOI_PUT_SIGN_IN_FRONT Displays the negative sign in front of the numeral
    RKD_WORD_WRAP Wrap text into several lines
    CONVERSION_EXIT_ALPHA_INPUT Pad zeros to the number at the left
    CONVERSION_EXIT_ALPHA_OUTPUT Eliminate zeros to the number at the left
    READ_EXCHANGE_RATE Exchange Convertion
    SPELL_AMOUNT Transforms numeric values into text
    Function Modules Related To Dialog Prompts
    POPUP_TO_CONFIRM Displays a popup dialog with a user defined message for confirmation
    POPUP_TO_GET_VALUE Displays a popup dialog requesting a value for a particular table-fieldname
    SAPGUI_PROGRESS_INDICATOR Displays a progress bar with text to denote the percentage of completion and status
    FILENAME_GET Displays a popup dialog to get the presentation server filename
    F4_DATE Displays a popup dialog to choose date
    POPUP_TO_SELECT_MONTH Display a pop-up to select a month
    GET_PRINT_PARAMETERS Printer parameters
    F4IF_INT_TABLE_VALUE_REQUEST F4 help also returning the value to be displayed in internal table
    F4IF_FIELD_VALUE_REQUEST F4 help for fields that are only known at runtime
    Function modules related to RFC communication
    RFC_CONNECTION_CLOSE Close a RFC connection
    RFC_GET_SYSTEM_INFO Give system's information of a remote system
    {+}Function modules related to reading/writing files on application server (named AS below) or Frontend +
    FILE_READ_AND_CONVERT_SAP_DATA Uploads the file from either presentation or application server into an internal table
    SUBST_GET_FILE_LIST To get the list of files from AS
    ALSM_EXCEL_TO_INTERNAL_TABLE Legacy Data Transfer w/ Excel
    WS_FILE_DELETE Delete files on AS server
    PFL_COPY_OS_FILE Copy AS files
    EPS_GET_DIRECTORY_LISTING Returns all files from an AS directory
    FILENAME_GET Displays a popup dialog to get an AS filename (FILE transaction)
    GUI_UPLOAD Upload a file from the presentation server
    GUI_DOWNLOAD Downloads an Internal Table to the PC
    Function Modules related to sending emails
    SO_NEW_DOCUMENT_ATT_SEND_API1 Sends emails with texts and attachments
    SO_NEW_DOCUMENT_SEND_API1 Sends emails with texts.
    Function Modules related to data maintenance
    VIEW_MAINTENANCE_CALL To maintain data from a table or view (SM30)
    Amount and Currency
    CURRENCY_AMOUNT_SAP_TO_IDOC Convert currency to IDOC format
    CLOI_PUT_SIGN_IN_FRONT Move the negative sign from the left hand side of a number, to the right hand side of the number. Note that The result will be left justified (like all character fields), not right justifed as numbers normally are.
    CONVERT_TO_FOREIGN_CURRENCY Convert local currency to foreign currency.
    CONVERT_TO_LOCAL_CURRENCY Convert from foreign currency to local currency
    CONVERT_AMOUNT_TO_CURRENCY Convert an amount from a currency to another (exchange rate taken from database tables)
    CONVERT_CURRENCY_BY_RATE Convert an amount from a currency to another, according to the passed exchange rate
    BAPI_CURRENCY_CONV_TO_EXTERNAL Conversion of Currency Amounts into External Data Format
    BAPI_CURRENCY_CONV_TO_INTERNAL Conversion of Currency Amounts into Internal Data Format
    SPELL_AMOUNT to get Amount in words
    HR_IN_CHG_INR_WRDS Changes INR amount to words.
    Function Modules related to FI, CO and SD Modules
    FOR_ALL_SKC1A Account subtotal
    VC_I_GET_CONFIGURATION Sales Purchase details configuration
    SD_PRINT_TERMS_OF_PAYMENT Print terms for unique payment
    SD_PRINT_TERMS_OF_PAYMENT_SPLI Print terms for some parcels payment
    J_1B_NF_DOCUMENT_READ Read NF details
    J_1B_NF_VALUE_DETERMINATION Read values from NF returned combined with J_1B_NF_DOCUMENT_READ using.
    Function Module related to HR-ABAP
    HR_MAINTAIN_MASTERDATA This function module is used to maintain master data for employees and applicants.
    HR_READ_INFOTYPE This function module reads the data records of an HR infotype that exist for employees and applicants.
    HR_INFOTYPE_OPERATION This function module is used to maintain employees and applicants data.
    CU_READ_RGDIR This function module is used to read RGDIR of cluster CU.
    PYXX_READ_PAYROLL_RESULT This function module reads complete payroll result for all country versions, from file PCL2 cluster.
    HR_GET_PAYROLL_RESULTS This function module is used to fetch the payroll results for employees .
    HR_RELATION_MAINTAIN This function module is to maintain the relation between employee and position.

    Wednesday, 26 June 2013

    Steps to create collective search help

    Creating Collective Search Helps  
           1.      In the initial screen of the ABAP Dictionary, select object class Search help, enter the name of the search help and choose Create.
    A dialog box appears in which you must select the type of search help.
           2.      Select Collective search help and choose .
    The maintenance screen for collective search helps is displayed.
           3.      Enter an explanatory text in the field Short Text.
    You can for example find the search help at a later time using this short text.
           4.      In the Definition tab page enter the parameters of the collective search help.
    Select the Imp flag if it is an import parameter. Select the Exp flag if it is an export parameter.
    Define the types for the parameters of a collective search help by assigning a data element. Enter the name of the data element that describes the contents of the search help parameter in the Data element field.
    You can assign the parameter a default value in the Default value field.
           5.      In exceptions it could be necessary to change the standard process defined by the search help. You can implement the deviation from the standard using a search help exit.
    In this case enter the name of the search help exit in the corresponding field.
           6.      On the Included search helps tab page, define the search helps that you want to include in the collective search help.
    You can include elementary search helps and collective search helps.
    Use the Hide flag to control whether an included search help should appear in the dialog box for selecting the elementary search help. If the flag is set, the search help is not offered.
    It makes sense to hide search help inclusions if one or more search paths in the standard system should not be used in a specific SAP System. Similarly, search help inclusions can also be already hidden in the standard system because they only can be used meaningfully in a few cases. You have to cancel the flag in this case.
           7.      Position the cursor one after the other on each allocated search help and choose Parameter assignment.
    In the next screen, enter the parameter names of the elementary search helps to which the corresponding parameters of the collective search help should be assigned in the field Reference parameter.
    You can select the parameters contained in the included search help using the input help. Create a proposal for the assignment with Proposal.
           8.      Save your entries.
    A dialog box appears in which you have to assign the search help a development class.
           9.      Choose .

    Friday, 14 June 2013

    To change table entries in production

    To change the table entries in production follow the below steps(With Fireid)

    To Achieve this

    Stop Point at line 44

    Stop Point at line 216

    When saving the entries and switching to debugging

    SY-SUBRC – 0 (This will be 4. Make it 0)

    after puting break point follow the below:
    Enter the transaction: uase16n Enter the table: vbap Enter &sap_edit it in transaction place  and press enter Enter the order number: 75000275 and click on execute 


    Wednesday, 12 June 2013

    Steps to work on Table control in module pool

    Step1: create a module pool progream in SE80 with TOP include.

    Step2: create the screen by right clicking the program and enter the mandatory parameters.

      Here to place the table on the table control we have two ways.

    1) Click on the Dictionary symbol on the screen top right corner with red light(middle)

    2) One window will open and here you can give the standard structure neme, click on get from dictonary and select the required fields and click on OK and place the same in table control created.

    It may give some problems is displaying the data.


    2) in window Give the structure created in the Table/Field name and and click on get from program, it will show all the fields declared in that structure. select the required fields to display.

    Here you wont get the headers defaultly, you have to drage and drop a TEXT on top of the corresponding column and give the name over there for that column.

    Step3: Now Drag and drop the table control icon in tool bar to the screen and specfy some name( ex:TC) to the table control and select the chek boxes of RESIZING and SEPARATORS.

    step4: Come back to the TOP include and declere the internal table and you have to write control ststement.

    TABLES mara.

    Here 'TC' is the etable control name.(here dont copy the code just write it other wise in you will face dumps)

    Step5: Now Double click on the screen(9001) and Enable the PF status in PBO
    Step6: In PBO write the select statement to select the data into internal table.

      MODULE fetch_data.
      module FETCH_DATA output.
     select * from mara into TABLE it_mara UP TO 30  ROWS.

    Step7: After fetching the data write the loop ststement like below.
       LOOP AT it_mara WITH CONTROL tc CURSOR tc-current_line.

    *Here TC is the table control(in screen) name.

    Step8: Now come to the PAI module.
    write the below statements and write the modify ststement in the module.
        LOOP AT it_mara.
        MODULE modify_tc.

      module MODIFY_TC input.
    MODIFY it_mara INDEX tc-current_line.
    endmodule.                 " MODIFY_TC  INPUT

    Step9: Activate the Program globally.
    Step10: Cretate Transaction for the same program amd execute.

    Thursday, 9 May 2013

    Sample report individual pagelength and page headers and columns headers

    Even if you suppress the standard page header by using the NO STANDARD PAGE
    HEADING option of the REPORT statement, you can activate the display of the
    individual components using WITH-TITLE and WITH-HEADING.

    REPORT demo_list_new_page_options LINE-SIZE 40.
    WRITE: 'Page', sy-pagno.
    WRITE: 'Page', sy-pagno.
    WRITE: 'Page', sy-pagno.
    WRITE: 'Page', sy-pagno.
    WRITE: 'Page', sy-pagno.

    To change the Line size of the individual pages:

    REPORT demo_list_new_page_line_c_1 LINE-SIZE 40 LINE-COUNT
    DO 4 TIMES.
    WRITE / sy-index.
    WRITE: / 'Next Loop:'.
    DO 6 TIMES.
    WRITE / sy-index.
    This program

    Sample report page breaks unconditionally and conditionally

    Unconditionally page breaks by defining NEW-PAGE.

    To program unconditional page breaks, use the NEW-PAGE statement.
    REPORT demo_list_new_page LINE-SIZE 40.
    WRITE: 'TOP-OF-PAGE', sy-pagno.
    ULINE AT /(17).
    DO 2 TIMES.
    WRITE / 'Loop:'.
    DO 3 TIMES.
    WRITE / sy-index.

    Conditional page breaks by defining block of lines:

    REPORT demo_list_reserve LINE-SIZE 40 LINE-COUNT 8(2).
    DO 4 TIMES.
    WRITE / sy-index.
    DO 2 TIMES.
    WRITE / sy-index.
    WRITE: / 'LINE 1',
    / 'LINE 2',
    / 'LINE 3'.

    Sample report line count, line size, end of page


    WRITE'SY-LINCT:', sy-linct.
    DO 6 TIMES.
    WRITE / sy-index.

    WRITE: /30 'Page', sy-pagno.

    Sample report LIST Display code

    REPORT demo_list_standard.
    TABLES spfli.
    ULINE AT /(62).
    SELECT * FROM spfli WHERE connid GE 0017
    AND connid LE 0400.
    WRITE: / sy-vline, spfli-connid, sy-vline,
    (15) spfli-cityfrom, 26 sy-vline,
    31 spfli-cityto, 51 sy-vline, 62 sy-vline,
    / sy-vline, 8 sy-vline,
    spfli-deptime UNDER spfli-cityfrom, 26 sy-vline,
    spfli-arrtime UNDER spfli-cityto, 51 sy-vline,
    spfli-fltime, 62 sy-vline.
    ULINE AT /(62).

    WRITE: /10 'SAP *** SAP *** SAP *** SAP *** SAP *** SAP',
    /19(43) 'Flight Information System',
    /19(43) 'International Connections'.

    WRITE, SKIP, and ULINE statements output fields of the table
    work area SPFLI as well as horizontal and vertical lines to the list.