Transport ABAP and interface in 4.5

Hello
I noticed that sometimes, when I create a report and it's screens, the transport does not capture everything.
I want to have in one TP the ABAP created in SE38 and the screens and text filelds created in SE80
How can I do that?
TIA

Hello Scott
Go to transaction <b>SE80</b> and choose from the context menu (of your program object) the function <b>"Other Functions" -> "Write Transport Request entry".</b> This should create all required transport objects for the transport request. If your dynpros are still missing repeat the step described above for the missing (sub-)objects.
Regards
  Uwe

Similar Messages

  • ABAP and Java Stack: Which to choose/supported standards and components?

    Hello,
    I am trying to understand the role of the two stacks in NW. Maybe anyone has a few
    hints where I can find answers to the following questions:
    - An overview of supported Standards (Java 5 since when?)
    - An overview of which component runs on which stack? Portal->Java, Integration Server->ABAP and so on.
    - Guidelines when to install both stacks and when to use just one stack? When do I use which one?
    - Has SAP an stategy towards an one Stack solution (possibly Java?)
    Best regards and thanks for any pointers!
    Stefan

    An overview of supported Standards (Java 5 since when?)
    Go to service.sap.com/pam
    Product Availability Matrix will tell you about supported version and platforms.
    An overview of which component runs on which stack? Portal->Java, Integration Server->ABAP and so on.
    Usually the question goes the other direction: what stacks we need for implementation of a particular function?
    More and more products require ABAP backend and Java frontend.
    For example Employee Self Service has been transerred from ABAP only ITS based to ABAP backend and Java frontend.
    Same with SRM.
    Guidelines when to install both stacks and when to use just one stack? When do I use which one?
    Same as above, driven by business requirements, not technology.
    Has SAP an stategy towards an one Stack solution (possibly Java?)
    No. Core business functions are still being developed on ABAP and interface, GUI etc utilize JAVA.
    Regards,
    Slava

  • Transport classes and programs to another server

    Except for transport routing and charm copy function, do we have other ways to do so?
    for example copy or so forth.
    best regards,
    Blake Le

    Hi Blake
    SAP R/3 Correction and Transport System
    Operating system level files in the transport process:
    The SAP C program TP, requires a special file structure for the transport process. The file system is operating system dependent. TP uses a transport directory or file system, which is called /usr/sap/trans.
    The /usr/sap/trans file system is generally NFS mounted form the development system to other systems unless a system is defined as a single system in the CTS pipeline. All the sub directories should have <SID>adm as the owner and sapsys as the group; and proper read, write and execute access should be given to owner and the group. The TP imports are always performed by <SID>adm.
    The following are the subdirectories in /usr/sap/trans:
    /data
    /cofiles
    /bin
    /log
    /actlog
    /buffer
    /sapnames
    /tmp
    /usr/sap/trans/data: holds the data of transport objects after they are released . The example of a data file is R904073.DEV. The extension DEV means the data file was released from the DEV or development system.
    /usr/sap/trans/cofiles: The cofiles directory holds the command files for all change requests. These files are like a command or control files used to import the data files. The common directory for CTS system is /usr/sap/trans. After a change request is released from the source system , the data is exported immediately to the file system of the operating system. The SAP transport utility TP uses the cofile to transport a data file. The example of a file in cofiles directory is K904073.DEV.
    /usr/sap/trans/bin: holds the most important file TPPARAM in the CTS system. TPPARAM file has all the information about the CTS systems in the CTS pipeline. TPPARAM file is the parameter file for the transport program TP and it is the common file for all the systems in the CTS pipeline. As you know already that /usr/sap/trans should be NFS mounted to all the systems in a CTS pipeline, TP program has access to the TPPARAM file from all the systems. The following is an example of typical TPPARAM file for five SAP systems in the CTS pipeline:
    #@(#) TPPARAM.sap 20.6 SAP 95/03/28
    Template of TPPARAM for UNIX #
    First we specify global values for some parameters, #
    later the system specific incarnation of special parameters #
    global Parameters #
    transdir = /usr/sap/trans/
    dbname = $(system)
    alllog = ALOG$(syear)$(yweek)
    syslog = SLOG$(syear)$(yweek).$(system)
    System spezific Parameters #
    Beispiel T11 #
    DEV/dbname = DEV
    DEV/dbhost = sap9f
    DEV/r3transpath = /usr/sap/DEV/SYS/exe/run/R3trans
    QAS/dbname = QAS
    QAS/dbhost = sap8f
    QAS/r3transpath = /usr/sap/QAS/SYS/exe/run/R3trans
    TRN/dbname = TRN
    TRN/dbhost = sap17
    TRN/r3transpath = /usr/sap/TRN/SYS/exe/run/R3trans
    PRE/dbname = PRE
    PRE/dbhost = sap19f
    PRE/r3transpath = /usr/sap/PRE/SYS/exe/run/R3trans
    PRD/dbname = PRD
    PRD/dbhost = sap18f
    PRD/r3transpath = /usr/sap/PRD/SYS/exe/run/R3trans
    /usr/sap/trans/log: holds the entire log files, trace files and statistics for the CTS system. When the user goes to SE09 (workbench organizer) or SE10 (customizing organizer) transaction and opens the log for a transport, the log file for that transport will be read from /usr/sap/trans/log directory. Each change request should have a log file. Examples of log files are DEVG904073.QAS, DEVI904073.QAS and DEVV904073.QAS. The name of a log file consists of the names of the change request, the executed step, and the system in which the step was executed:
    <source system><action><6 digits>.<target system>
    Now we can analyze the above example DEVG904073. QAS. The <source system> = DEV, <action> = G or report and screen generation, <6 digits> = 904073 (these six digits numbers are exactly the same number as the six digits of the transport) and the <target system> = QAS
    Possible values for <action> are:
    A: Dictionary activation
    D: Import of application-defined objects
    E: R3trans export
    G: Report and screen generation
    H: R3trans dictionary import
    I: R3trans main import
    L: R3trans import of the command files
    M: Activation of the enqueue modules
    P: Test import
    R: Execution of reports after put (XPRA)
    T: R3trans import of table entries
    V: Set version flag
    X: Export of application-defined objects.
    /usr/sap/trans/actlog: holds action log files. The example of an action file is DEVZ902690.DEV. The following are the contents of the file:
    1 ETK220 u201C==================================================u201D u201C=================
    =============================
    1 ETK191 u201C04/30/1998u2033 Action log for request/task: u201CDEVK902690u2033
    1 ETK220 u201C==================================================u201D u201C=================
    =============================
    1 ETK185 u201C04/30/1998 18:02:32u2033 u201CMOHASX01u2033 has reincluded the request/task
    4 EPU120 Timeu2026 u201C18:02:32u2033 Run timeu2026 u201C00:00:00u2033
    1 ETK193 u201C04/30/1998 18:02:33u2033 u201CMOHASX01u2033 owner, linked by u201CMOHASX01u2033 to u201CDEVK902691u2033
    4 EPU120 Timeu2026 u201C18:02:33u2033 Run timeu2026 u201C00:00:00u2033
    1 ETK190 u201C05/04/1998 11:02:40u2033 u201CMOHASX01u2033 has locked and released the request/task
    1 ETK194 u201C05/04/1998 11:02:40u2033 **************** End of log *******************
    4 EPU120 Timeu2026 u201C11:02:40u2033 Run timeu2026 u201C00:00:09u2033
    ~
    ~u201DDEVZ902690.DEVu201D 10 lines, 783 characters
    /usr/sap/trans/buffer: transport buffer of the target systems; contains control information on which requests are to be imported into which systems and in what order the imports must occur. The /usr/sap/trans/buffer will have a directory for each system in the CTS pipeline. For example the buffer file for DEV system is /usr/sap/trans/buffer/DEV.
    /usr/sap/trans/sapnames: holds information pertaining to transport requests for each system user. There are files for each user who released change requests from the system.
    /usr/sap/trans/tmp: holds information about temporary data and log files. While the transport is occurring the Basis administrator can find a file that is related to the transport in the tmp directory; that file shows the exact status if the transport (What objects are being imported at that time).
    Important SAP delivery class and table types and tables in the CTS process:
    Delivery class
    The delivery class defines who (i.e. the SAP system itself or the customer) is responsible for maintaining the table contents. In addition the delivery class controls how the table behaves in a client copy and an upgrade. For example when you select a SAP defined profiles to perform a client copy, certain tables are selected according to their delivery class. DD02L table can show what delevery class a table belongs to.
    The following delivery classes exist:
    A: Application table.
    C: Customizing table, maintenance by customer only.
    L: Table for storing temporary data.
    G: Customizing table, entries protected against overwriting.
    E: Control table.
    S: System table, maintenance only by SAP.
    W: System table, contents can be transported via own TR objects.
    Table type
    The table type defines whether a physical table exists for the logical table description defined in the ABAP/4 Dictionary and how the table is stored on the database.
    The following are different table types in SAP:
    Transparent Tables
    There is a physical table on the database for each transparent table. The names of the physical table and the logical table definition in the ABAP/4 Dictionary are same. For every transparent table in SAP, there is a table in database. The business and application data are stored in transparent tables.
    Structure
    No data records exist on the database for a structure. Structures are used for the interface definition between programs or between screens and programs.
    Append Structure
    An Append structure defines a subset of fields which belong to another table or structure but which are treated as a separate object in the correction management. Append structures are used to support modifications.
    The following table types are used for internal purposes, for example to store control data or for continuous texts:
    Pooled table
    Pooled tables can be used to store control data (e.g. screen sequences, program parameters or temporary data). Several pooled tables can be combined to form a table pool. The table pool corresponds to a physical table on the database in which all the records of the allocated-pooled tables are stored.
    Cluster table
    Cluster tables contain continuous text, for example documentation. Several cluster tables can be combined to form a table cluster. Several logical lines of different tables are combined to form a physical record in this table type. This permits object-by-object storage or object-by-object access. In order to combine tables in clusters, at least part of the keys must agree. Several cluster tables are stored in one corresponding table on the database.
    Tables in CTS process:
    TRBAT and TRJOB:
    TRJOB and TRBAT are the major tables in the CTS process. After TP program has sent the event to the r3 system, RDDIMPDP checks table TRBAT in the target system to find out if there is an action to be performed. Mass activation, distribution, or table conversions are the examples of actions. If there is action to be performed, RDDIMPDP starts the appropriate program in the background task. RDDIMPDP then reschedules itself.
    By checking table TRJOB, RDDIMPDP automatically recognizes if a previous step was aborted, and restarts this step. For each transport request , TP program inserts an entry into table TRBAT. If the return code 9999 in this table then the step is waiting to be performed. Return code 8888 indicates that the step is active and currently being processed. A return code of 12 or less indicates that the step is finished. In addition, TP inserts a header entry to let the RDDIMPDP program know to start processing. The column return code will therefore contain a B for begin. When RDDIMPDP is started, it sets the header entry to R(un), and starts the required program. When all the necessary actions are performed for all the transport requests, the column return code contains all the return codes received, and the column TIMESTAMP contains the finishing time. The header entry is set to F(inished). TP monitors the entries in TRBAT and TRJOB tables. When the header entry in TRBAT is set to finished. The entry in TRJOB is deleted.
    Transport Tables SE06
    TDEVC - Development classes
    TASYS - Details of the delivery. Systems in the group that should automatically receive requests, have to be specified in table TASYS.
    TSYST - The transport layers will be assigned to the integration systems. ( Define all systems)
    TWSYS - Consolidation routes ( define consolidation path)
    DEVL - Transport layers are defined here
    In u201CConfiguring the CTS systemu201D section, We will learn more about the transport tables in SE06 transaction
    Programs in the CTS process:
    In the CTS table section we learned about the RDDIMPDP program. RDDIMPDP program needs to be scheduled in all the clients in an instance. It is recommended to schedule the RDDIMPDP as event driven.
    RDDPUTPP and RDDNEWPP programs can be used to schedule RDDIMPDP program in the background.
    The ABAP/4 programs that RDDIMPDP starts are determined by the transport step to be executed that is entered in the function field of table TRBAT.
    Function Job Name Description of transport Steps
    J RDDMASGL Activation of ABAP/4 dictionary objects
    M RDDMASGL Activation of match codes and lock objects
    S RDDDISOL Analysis of database objects to be converted
    N RDDGENOL Conversion of database objects
    Y RDDGENOL Conversion of matchcode tables
    X RDDDICOL Export of AD0 objects
    D RDDDIC1L Import of AD0 objects
    E RDDVERSE Version management update during export
    V RDDVERSL Version management update during import
    R RDDEXECL Execution of programs for post - import processing
    G RDDDIC3L Generation of ABAP/4 programs and screens
    Version Management:
    One of the important features of Workbench Organizer is Version Management. This feature works for all the development objects. Using the version management feature the users can compare and retrieve previous versions of objects.
    Version management provides for comparisons, restore of previous versions, documentation of changes and assistance in the adjustment of data after upgrading to a new release. With the release of a change request, version maintenance is automatically recorded for each object. If an object in the system has been changed N times, it will have N delta versions and one active version. To display version management, for ABAPs use transaction SE38 and for tables, domains and data elements use SE11. The path to follow is Utilities -> Display version. Using version management the users can view existing version for previously created ABAP code, make changes to the code, compare code versions and restore original version of the code. Now the users will be restore previous versions without cut and paste steps of the past.
    TP and R3trans program:
    The basis administrator uses TP program to transport SAP objects from one system to another. TP is a C program delivered by SAP that runs independently of the R/3 system. TP program uses the appropriate files located in a common transport directory /usr/sap/trans. TP starts C programs, ABAP/4 programs and special operating system commands to its job. R3trans is one of the most important utility program called by TP. Before using the TP program, the basis administrator needs to make sure that the CTS system is setup properly and the right version of TP is running in the system. The TP program is located in the run time directory /usr/sap/<SID>/SYS/exe/run directory. It is automatically copied in the install process. A global parameter file TPPARAM that contains the databases of the different target systems and other information for the transport process controls TP. The global parameter file determines which R3trans is used for each system. If the parameter r3transpath is not defined properly then no export and import can be done. The basis administrator should make sure that the default value u201Cr3transpathu201D is properly defined. Later in this chapter we will learn more about TP and R3trans; also we are going to see how they are used.
    Configuring the TPPARAM file:
    Each time TP is started, it must know the location of the global parameter file. As we have seen before TPPARAM file should be in directory /usr/sap/trans/bin. The parameters in TPPARAM can either global (valid for each and every system in the cts pipeline) or local to one system. Th parameters are either operating system dependant (these parameters preceded by a keyword corresponding to the specific operating system) or database dependant (contain a keyword corresponding to a specific database system).
    The global parameter file provides variables that can be used for defining parameters. The variables can be defined in format: $(xyz). The brackets can be substituted with the u201C\u201D-character if required.
    The following pre-defined variables are available for the global parameter file:
    $(cpu1): The CPU name can be sun or as4 for example. In heterogeneous networks this variable is very important.
    $(cpu2): Acronym for the name of the operating system. The example for this variable can be
    hp-ux, or sunos . This is an operating system specific variable.
    $(dname): Used for the day of the week (SUN,MON,u2026.).
    $(mday): Used for the day of the current month (01-31).
    $(mname): Used for the name of the month (JANu2026DEC).
    $(mon): Used for the Month (01-12).
    $(system): R/3 System name.
    $(wday): Day of the week (00-06, Sunday=00, Monday=01, Tuesday=02 and so on).
    $(yday): Day of the current year (001-366). Using the number any day of the year can be chosen.
    $(year): Year (Example:1998 or 1999).
    $(syear): Short form of the year (two positions).
    $(yweek): Calendar week (00-53). The first week begins with the first Sunday of the year.
    For the database connection:
    The transport environment also needs parameters to connect to the R/3 System database. As we know already the every instance in the R/3 CTS pipeline has its own database, therefore specific parameters should be defined for each database system. From dbtype parameter of RSPARAM file, TP program identifies the database system.
    The two parameters u201Cdbnameu201D and u201Cdbhostu201D are required for ORACLE databases.
    DBHOST: is the name of the computer on which the database processes execute. TCP/IP name of the host if NT is being used.
    DBNAME: is the name of the database instance.
    As of Release 3.0E, two new parameters have been introduced.
    DBLOGICALNAME: The default value is $(system). The logical name that was used to install the database.
    DBCONFPATH: The default value is $(transdir).
    The parameters u201Cdbnameu201D and u201Cdbhostu201D are also used for INFORMIX databases in an installation:
    DBHOST: Same as Oracle.
    DBNAME: Name of the database instance, uppercase and lowercase are distinguished here.
    INFORMIXDIR : u201C/informix/<SAPSID>u201D is the default value. Defines the directory namewhere the database software can be found.
    INFORMIXSQLHOSTS: u201C$(informixdir)/etc/sqlhosts[.tli|.soc]u201Cis default value under Unix. The name of the SQLhosts file with its complete path is defined with this parameter.
    INFORMIX_SERVER: u201C$(dbhost)$(dbname)shmu201D is the default value. The name of the database server may be specified for a local connect.
    INFORMIX_SERVERALIAS: u201C$(dbhost)$(dbname)tcpu201Dis the default vlue. The name of the database server can be specified for a remote connect.
    For Microsoft SQL Server database the two parameters u201Cdbnameu201D and u201Cdbhostu201D are also required. DBHOST: The TCP/IP name of the host on which the database is running.
    DBNAME: The database instance name.
    For DB2 in AS/400 only u201Cdbhostu201D is required.
    DBHOST: System name of the host on which the database is running.
    If theu201DOptiConnectu201D is used, the following line should be specified:
    OPTICONNECT 1
    For DB2/ AIX
    The two parameters u201Cdbnameu201D and u201Cdbhostu201D are required
    DBHOST: The host on which the database processes are running. It is the TCP/IP name of the host for Windows NT (As we have seen in the earlier examples).
    DBNAME: Database instance name.
    The DB2 for AIX Client Application Enabler Software must also be installed on the host on which tp is running.
    ALLLOG: u201CALOGu201D $(syear) $(yweek)u201Dis the default value. This variable can be used in TPPARAM file to specify the name of a file in which tp stores information about every transport step carried out for a change request anywhere in the transport process. The file always resides in the log directory.
    SYSLOG: u201CSLOG $(syear) $(yweek).$(system)u201D is the default value. This variable can be used to name a file in which tp stores information about the progress of import actions in a certain R/3 System. The file does not store information for any particular change request. The file always resides in the log directory.
    tp_VERSION: Zero is the default value. If this parameter is set to not equal to zero, a lower version of tp may not work with this TPPARAM file. If the default value (zero) is set, the parameter has no affect.
    STOPONERROR: (Numeric value) The default value is 9. When STOPONERROR is set to zero, tp is never stopped in the middle of an u201Cimportu201D or u201Cputu201D call. When STOPONERROR is set to a value greater than zero, tp stops as soon as a change request generates a return code that is equal to or greater than this value (The numeric value of the STOPONERROR parameter is stored in the variable BADRC). Change requests, which still have to be processed for the current step, are first completed. A u201CSYNCMARKu201D in the buffer of the R/3 System involved, sets a limit here. tp divides the value of this parameter between two internal variables. STOPONERROR itself is treated as a boolean variable that determines whether tp should be stopped, if the return code is too high.
    REPEATONERROR (Numeric value too): The default value is 9. The REPEATONERROR parameter is similar to STOPONERROR. The difference is, REPEATONERROR specifies the return code up to which a change request is considered to be successfully processed. Return codes less than REPEATONERROR are accepted as u201Cin Orderu201D. Change requests that were not processed successfully stay in the buffer.
    NEW_SAPNAMES: Default value is u201CFALSEu201D. A file is created for each user of the R/3 System group in the u201Csapnamesu201D subdirectory of the transport directory. Except some of the operating system,the name of the user is the name of the file. It is very important to remember hat the special characters or length of the file name could cause problems. If all the R/3 Systems in the transport group have at least Release level 3.0.; TP program is efficient to handle this problem. The user names are modified to create file names that are valid in all operating systems and the real user names are stored in a corresponding file.
    Though we have seen so many parameters, for the minimum configuration the following two parameters are very important.
    TRANSDIR: specifies the name of the common transport directory. The following is a typical example from TPPARAM of Unix as we have seen before.
    transdir = /usr/sap/trans/
    DBHOST: contains the name of the database host. In Windows NT environment, this is the TCP/IP host name. The following is an example in Unix:
    DEV/dbname = DEV
    DEV/dbhost = sap9f
    DEV/r3transpath = /usr/sap/DEV/SYS/exe/run/R3trans
    For TP, to control u2018Start and Stopu2019 command files and database in R/3 the following important parameters are specified in TPPARAM:
    Parameters for the tp Function u201CPUTu201D: LOCK_EU (boolean) default value is u201CTRUEu201D. Though from version 3.1 onward the tp put command is used seldom in cts process still it is important to know how this parameter works. When u201Ctp putu201D is used, it changes the system change option . If the parameter is set to u201CFALSEu201D nothing gets changed. If the parameter is set to u201CTRUEu201D, the system change option is set to u201CObjects cannot be changedu201D at the beginning of the call, and gets changed back to its previous value at the end of the call. The u201Ctp putu201D command will give the exact status of the locking mechanism.
    LOCKUSER (used as boolean value): Default value is u201CTRUEu201D. This parameter is about the user login while tp put call is executed. If this parameter is set to u201CFALSEu201D, no locking mechanism for the users takes affect. If this parameter is defined as u201CTRUEu201D then a character is set in the database level; so only DDIC and SAP* can log on to the system. Users that have already logged on are not affected (this is a reason for activating the parameters STARTSAP and STOPSAP). The charactertor is removed at the end of the call, and all the users can log on to the SAP R/3 System again.
    STARTSAP: Default value is u201D u201C.or u201CPROMPTu201D for Windows NT . This parameter is used by TP to start an R/3 System. It is not necessary for the clients to make tp start and stop R/3 system..
    STOPSAP: Default value is u201D u201Cor u201CPROMPTu201D for Windows NT. TP uses this parameter to stop an R/3 System.
    STARTDB: Default value is u201D u201C. TP uses the value of this parameter to start the database of an R/3 System.
    The parameter is not active under Windows NT.
    STOPDB: Default value is u201D u201C. TP uses the value of this parameter to stop the database of an R/3 System.
    This parameter is not active under Windows NT.
    The above parameters in UNIX can be used as following:
    STARTSAP = startsap R3
    STOPSAP = stopsap R3
    STARTDB = startsap db
    STOPDB = stopsap db
    In Windows NT:
    STARTSAP =
    $(SAPGLOBALHOST)\sapmnt\$(system)\sys\exe\run\startsap.exe
    R3 <SID> <HOST NAME> <START PROFILE>
    STOPSAP =
    $(SAPGLOBALHOST)\sapmnt\$(system)\sys\exe\run\stopsap.exe
    R3 <SID> <HOST NAME> <INSTANCE> <PROFILE PATH + Instance profile>
    The parameters STARTDB and STOPDB are not active under Windows NT.
    Parameters for the tp function u201CCLEAROLDu201D
    DATALIFETIME (Numeric): Default value is u201C200u2033. When the data file has reached a minimum age, it is moved to the subdirectory old data with tp check. tp clearold all. The life span of the data files in the data sub directory can be set in days with this all, parameter.
    OLDDATALIFETIME (Numeric): Default value is u201C365u2033. When a file located in the olddata subdirectory is no longer needed for further actions of the transport system and has reached a minimum age, it is removed with tp check.all, tp clearold all. The minimum age in days can be set with this parameter.
    COFILELIFETIME (Numeric): Default value is u201C365u2033. This parameter is used just like DATALIFETIME parameter.
    LOGLIFETIME (Numeric): Default value is u201C200u2033. This parameter applies to the life span of the log files. When the log files in log subdirectory is no longer needed for the transport system and has reached a minimum age, it is deleted with the calls tp check.all, tp clearold all. The minimum age in days can be defined with this parameter.
    The Three Key Utilities of the CTS system (TP, R3trans and R3chop):
    TP: Earlier in this chapter we have seen the objectives of TP. The TP transport control program is a utility program that helps the user to transport objects from one system to another. TP program is the front-end for the utility R3trans. TP stands for u201CTransports and Putsu201D. To make the TP work successfully the CTS system needs to be correctly configured. The following steps are very important for TP to run properly.
    The transport directory /usr/sap/trans must be installed and NFS mounted to all the systems in the CTS pipe line.
    RDDIMPDP program must be running (event driven is recommended) in each client. RDDIMPDP can be scheduled in the background by executing RDDNEWPP or RDDPUTPP. Use the tp checkimpdp <sap sid> command in /usr/sap/trans/bin directory as <sid>adm user to check RDDIMPDP program.
    Use the tp connect <sap sid> command in /usr/sap/trans/bin directory to see whether the tp program is connecting to the database successfully or not. To run TP command the user has to logon as <sid>adm in source or target system.
    The R/3 Systems in the CTS pipeline must have different names.
    The Global CTS Parameter File TPPARAM must be correctly configured.
    The source system (for the export) and target system ( for the import) must have at least two background work processes. TP always schedules the C class job, so if all the background jobs are defined as A class job then there will be problems in transport steps.
    Important Tips :.It is always better to have the up to date TP version installed in your system. A user can ftp a current version of TP from SAPSERV4 of SAP. Though R3trans and other utility programs can be used to do the transport, it is recommended to use TP whenever possible for the following reasons..
    The exports and imports are done separately using TP program. For example: when a transport is released from the system, the objects are exported from the source database to the operating system and then the import phase starts to transport those objects to the target system.
    TP takes care of the order of the objects. The order, that was followed to export the objects; the same order will be followed to import them to the target database.
    The TP command processes all change requests or transports in the SAP system buffer that have not yet been imported successfully. All the import steps are executed automatically after TP calls R3trans program to execute the following necessary steps:
    Dictionary Import: ABAP/4 dictionary objects will be imported in this step.
    Dictionary Activation: Name tabs or runtime descriptions will be written inactively. The R/3 system keeps running until the activation phase is complete. The enqueue modules are the exceptions in the running phase. After the activation of new dictionary structure the new actions are decided to get the runtime objects to the target system.
    Structure conversion: If necessary the table structure is changed in this phase.
    Move Nametabs: The new ABAP/4 Dictionary runtime objects which were inactive up to now are moved into the active runtime environment in this process. The database structures are adjusted accordingly. From the first step to the Main import step inconsistencies can occur to the R/3 system. After the main import phase all the inconsistency ca be solved.
    Main import with R3trans: All the data are imported completely and the system comes to a consistent state.
    Activation of enqueue-objects: The enqueue-objects cannot be activated in the same way as the objects of the ABAP/4 Dictionary, so they have to be activated after the main import in this step. They are then used directly in the running system.
    Structure Conversion of match codes, Import application defined objects, versioning and execution of user defined activities are some of the steps after activation of enqueue-objects. The next step is generation of ABAP/4 programs and screens, where all the programs and screens associated with the change request are generated. When all the import steps are completed successfully, the transport request is removed from the import buffer.
    It is recommended by SAP to schedule regular periods for imports into the target system (e.g. daily, weekly or monthly). Shorter periods between imports are not advisable. The transport to production should not be done in the off hours when the users are not working
    TP can be started with different parameters. The u201Ctp helpu201D command can help user to generate a short description about the use of the command.
    The following are the some important commands of TP:
    For export:
    tp export <change request>: The complete objects in the request from the source system will be transported. This command also used by SAP System when it releases a request.
    tp r3e <change request>: R3trans export of one transport request.
    tp sde <change request>: Application defined objects in one transport request can be exported.
    tp tst <change request> <SAP system >: The test import for transport request can be done using this command.
    tp createinfo <change request>: This command creates a information file that is automatically done during the export.
    tp verse <request>: This command creates version creates versions of the objects in the specified request.
    To Check the transport buffer, global parameter file and change requests:
    tp showbuffer <sid>: Shows all the change requests ready to be imported to the target system.
    tp count <sid>: Using this command users can find out the number of requests in the buffer waiting for import.
    tp go <sid>: This command shows the environment variables needed for the connection to the database of the <sid> or target system.
    tp showparams <sid>: All the values of modifiable tp parameters in the global parameter file. The default value is shown for parameters that have not been set explicitly.
    To import the change requests or transports:
    tp addtobuffer <request>.<sid>: If a change request is not in the buffer then this command is used to add it to the buffer, before the import step starts.
    tp import all <sid>: This command imports all the change requests from the buffer to the target system.
    tp put <sid>: The objective of this command is same as u201Ctp import all <sid>u201D, but this command locks the system. This command also starts and stops the SAP system, if the parameters startsap and stopsap parameters are not set to u201D u201C.
    tp import <change request> <sid>: To import a single request from the source system to target system.
    tp r3h <change request>| all <sid>: Using this command user can import the dictionary structures of one transport or all the transport from the buffer.
    tp act <change request>|all <sid>: This command activates all the dictionary objects in the change request.
    tp r3i <change request> | all <sid>: This command imports everything but dictionary structures of one.
    tp sdi <change request>|all <sid>: Import application-defined objects.
    tp gen <change request>|all <sid>: Screen and reports are generated using this command.
    tp mvntabs <sid>: All inactive nametabs will be activated with this command.
    tp mea <change request>|all <sid>: This command will activate the enqueue modules in the change request.
    When you call this command, note the resulting changes to the import sequence.
    Additional tp utility options:
    tp check <sid>|all (data|cofiles|log|sapnames|verbose): User uses this command to find all the files in the transport directory that are not waiting for imports and they have exceeded the minimum time specified using the COFILELIFETIME, LOGFILELIFETIME, OLDDATALIFETIME and DATALIFETIME parameters of TPPARAM file.
    tp delfrombuffer <request>.<sid>: This command removes a single change request from the buffer. In case of TMS, the request will be deleted from the import queue.
    tp setstopmark <sid>: A flag is set to the list of requests ready for import into the target system. When the user uses the command tp import all <sapsid> and tp put <sapsid>, the requests in front of this mark are only processed. After all the requests in front of the mark have been imported successfully, the mark is deleted.
    tp delstopmark <sid>: This command deletes the stop mark from the buffer if it exists.
    tp cleanbuffer <sapsid>: Removes all the change requests from the buffer that are ready for the import into the target system.
    tp locksys <sid>: This command locks the system for all the users except SAP* and DDIC. The users that have already logged on are not affected by the call.
    tp unlocksys <sid>: This command unlocks the system for all the users.
    tp lock_eu <sid>: This command sets the system change option to u201Csystem can not be changedu201D tmporarily.
    tp unlock_eu <sid>: This command unlocks the system for all the changes.
    tp backupall <sid>: This command starts a complete backup using R3trans command. It uses /usr/sap/trans/backup directory for the backup.
    tp backup delta <sid>: Uses R3trans for a delta backup into /usr/sap/trans/backup directory.
    tp sapstart <sid>: To start the R/3 system.
    tp stopsap <sid>: To stop the R/3 system.
    tp dbstart <sid>: To start the database.
    tp dbstop <sid>: To stop the database.
    Unconditional modes for TP: Unconditional modes are used with the TP program and these modes are intended for the special actions needed in the transport steps. Using unconditional mode user can manipulate the rules defined by the workbench organizer. The unconditional mode should be used when needed, otherwise it might create problems for the R/3 system database. Unconditional mode is used after the letter u201CUu201D in the TP command. Unconditional mode can be a digit between 0 to 9 and each has a meaning to it. The following is a example of a import having unconditional mode.
    tp import devk903456 qas client100 U12468
    0: Called a overtaker; change request can be imported from buffer without deleting it and then uncoditional mode 1 is used to allow another import in the correct location.
    1: If U1 is used with the export then it ignores the correct status of the command file; and if it is used with import then it lets the user import the same change request again.
    2: When used with tp export, it dictates the program to not to expand the selection with TRDIR brackets. If used in tp import phase, it overwrites the originals.
    3: When used with tp import, it overwrites the system-dependant objects.
    5: During the import to the consolidation system it permits the source systems other than the integration system.
    6: When used in import phase, it helps to overwrite objects in unconfirmed repairs.
    8: During import phase it ignores the limitations caused by the table classification.
    9: During import it ignores that the system is locked for this kind of transport.
    R3trans: TP uses R3trans program to transport data from one system to another in the CTS pipeline. efficient basis administrator can use R3trans directly to export and import data from and into any SAP systems. Using this utility transport between different database and operating system can e done without any problems. Different versions of R3trans are fully compatible with each other and can be used for export and import. The basis administrator has to be careful using R3trans for different release levels of R/3 software; logical inconsistency might occur if the up to date R3trans is not used for the current version of R/3 system.
    The syntax for using the control file is following:
    R3trans [<options>] <control file> (several options used at the same time; at least one option must be there)
    For example: R3trans u2013u 1 u2013w test.log test
    In the above example a unconditional mode is used, a log file u201Ctest.logu201D file is used to get the log result and a control file u201Ctestu201D, where the instructions are given for the R3trans to follow. The user needs to logon as <sid>adm to execute R3trans.
    The following options are available for the R3trans program:
    R3trans -d : This command is used to check the database connection .
    R3trans -u <int>: Unconditional mode can be used as we have seen in the above example.
    R3trans -v : This is used for verbose mode. It writes additional details to the log file
    R3trans -i <file>: This command directly imports data from data file without a control file.
    R3trans -l <file>: This provides output of a table of contents to the log file.
    R3trans -n : This option provides a brief information about new features of R3trans.
    R3trans u2013t: This option is used for the test mode. All modifications in the database are rolled back.
    R3trans -c <f1> [<f2>]: This command is used for conversion. The <f1> file will be copied to <f2> file after executing a character set conversion to the local character set.
    Important tips: Do not confuse the backup taken using R3trans with database backup. The backups taken using R3trans are logical backups of objects. In case something happens to the SAP system these backups can not be used for recovery. R3trans backups can be only used to restore a copy of a particular object that has been damaged or lost by the user.
    R3trans -w <file>: As we have seen in the above example this option can be used to write to a log file. If no file is mentioned then trans.log is default directory for the log.
    R3trans also can be used for the database backup.
    R3trans u2013ba: This command is used for a complete backup. we will see in the next paragraph how to use
    the control file for the backup.
    R3trans u2013bd: This command is used for a delta backup if the user does not want a complete backup.
    R3trans u2013bi: This option will display backup information.
    The following are some of the examples of control files:
    We have already learned how to use a command for the logical backup of the objects in the database. To get a complete backup the following example control file can be used.
    backup all
    file = /usr/sap/trans/backall
    The option u201Cfile = u2026u201D is the name of the directory into which the data files are to be written. If you are taking a complete backup of DEV system then the backup file is going to look like u201CDEV.A000.bcku201D the next complete
    Reward if useful
    Regards
    divya

  • ABAP AND DATABASES

    Hi Experts..
    I would like to know how to create a databases in SQL and have access from ABAP.. to Modify, Consult and do the basic operations like insert information, drop and modify in the respective tables.
    I'm ussing MiniSap Minigui 6.2 on Windows XP and the BCUSER
    Thank you very much for your help
    REGARDS

    HI Araceli,
    Database Access using Advanced Business Application Programming (ABAP)
    Basics :
    Accessing the Database in the R/3 System is performed through the interface provided by the SAP System, which in the SAP System is referred to as the Database Interface. A user can access the database from his/her program through Open SQL and Native SQL depending upon the circumstances.
    About SQL
    The Structured Query Language (SQL) is a largely standardized language, which is used for accessing relational databases. It can be divided as follows:
    Data Manipulation Language (DML)
    These statements are for reading and changing data in database tables.
    Data Definition Language (DDL)
    These statements are for creating and administering database tables.
    Data Control Language (DCL)
    These statements are used for authorization and consistency checks.
    So  each database has a programming interface. This programming interface allows the user to access the database tables by using SQL statements. But, these SQL statements in the programming interfaces are not fully standardized. So, you must refer to the documentation of that system for a list of the SQL statements available and also their correct syntax in order to access a specific database system.
    Interface thru data base
    Each work process on an application server must have a database interface if you want to make the R/3 system independent of the database system, and also to use it correctly despite the differences in the SQL syntax between various databases. By means of this interface only, the R/3 system can communicate with the database. All of the database requests from the R/3 system are converted into the correct Standard SQL statements for the database system by the database interface. In order to perform this function, it has to use a database-specific component, which shields the differences between database systems from the rest of the database interface. You have to choose the appropriate layer when installing the R/3 system. A user can access a database from a program through Open SQL and Native SQL.
    Open SQL
    Open SQL are statements that make up a subset of Standard SQL which is fully integrated in ABAP. Open SQL consists of Data Manipulation Language (DML) which is a part of Standard SQL.
    One of the ways to access the database from a program is Open SQL. These Open SQL statements are nothing but a subset of Standard SQL, which is fully integrated in ABAP. Irrespective of which database system the R/3 installation is using, they allow you to access data. When I said that, Open SQL consists of the Data Manipulation Language (DML). I meant that it allows you to read (i.e. to SELECT) and change (For example  to INSERT, UPDATE, DELETE) data.
    Moreover, Open SQL also goes beyond Standard SQL. This is to provide statements that can simplify or speed up database access in conjunction with other ABAP constructions. Apart from that, it also gives you the freedom to buffer certain tables on the application server, thereby enabling you to save excessive database access. In this case, the database interface is responsible for comparing the buffer with the database. As far as buffer storage is concerned, they may be stored in two parts: the working memory of the current work process, and the shared memory for all work processes on an application server. The data in the various buffers is synchronized at set intervals by buffer management where an R/3 system is distributed across more than one application server. It should be noted that data in the buffer is not always up to date when you are buffering the database. That is why you should only use the buffer for data which does not change often. You can specify whether a table can be buffered in its definition in the ABAP Dictionary.
    Open SQL consists of a set of ABAP statements. These statements perform operations on the central database in the R/3 system. The results of the operations and any error messages which come out of it are independent of the current database system. Thus, uniform syntax and semantics for all of the database systems supported by SAP is provided by Open SQL. Regardless of the current database system, the ABAP programs, which use Open SQL statements only, will work in any R/3 system. Moreover, Open SQL statements work only with database tables that have been created in the ABAP Dictionary.
    You have the freedom to combine columns belonging to different database tables to a database view (or view for short) in the ABAP Dictionary. Views are also handled in exactly the same way as database tables in Open SQL statements.
    Some Open SQL keywords are as follows:
    SELECT - It reads data from database tables.
    INSERT - It adds rows to database tables.
    UPDATE - It changes the contents of rows of database tables.
    MODIFY - It inserts rows into database tables or changes the content of existing rows.
    DELETE - It deletes rows from database tables.
    OPEN CURSOR, FETCH, CLOSE CURSOR - It reads rows of database tables using the cursor.
    Return Codes
    The following two system fields are filled with return codes by all Open SQL statements:
    SY-SUBRC: The system field SY -SUBRC contains the value 0 after every Open SQL statement if the operation was successful. When a value is other than 0, then it is unsuccessful.
    SY-DBCNT: The system field SY-DBCNT contains the number of database lines processed after an open SQL statement.
    Native SQL
    The other possible way to access the database from a program is Native SQL. It is only loosely integrated into ABAP. It allows access to all of the functions contained in the programming interface of the respective database system. Native SQL statements are not checked and converted as compared to Open SQL statements. Unlike Open SQL, these are sent directly to the database system. The function of the database-dependent layer remains minimal when you use Native SQL. The Programs which use Native SQL are written specifically for a database system. You should avoid using Native SQL wherever possible when writing R/3 applications. However, you can use it in some parts of the R/3 Basis System, for instance, for creating or changing table definitions in the ABAP Dictionary.
    Regardless of the database platform that your R/3 system is using, Open SQL allows you to access database tables, which are declared in the ABAP Dictionary. Native SQL allows you to use database specific SQL statements in an ABAP program. This means that you can use database tables that are not administered by the ABAP Dictionary. Aside from that, you can also integrate data that is not part of the R/3 system.
    As a rule, an ABAP program that contains database-specific SQL statements will not run under different database systems. You have to use Open SQL statements only, if your program is used on more than one database platform.
    You must proceed with the EXEC SQL statement, and follow the ENDEXEC statement to use a: Native SQL statement. For example
    Listing 1
    EXEC SQL [PERFORMING
    ENDEXEC.There is no period after Native SQL statements. Also, using quotation marks (") or an asterisk (*) at the beginning of a native SQL statement's line does not introduce a comment as it would in normal ABAP syntax. You need to know if the table and field names are case-sensitive in your chosen database.
    The data is transported between the database table and the ABAP program using host variables in Native SQL statements. These are preceded in a Native SQL statement by a colon ( and are declared in the ABAP program. The elementary structures can be used as host variables. The structures of an INTO clause are treated exceptionally, as though all of their fields are listed individually. If the selection in a Native SQL SELECT statement is a table, then you can pass it to ABAP line by line using the PERFORMING addition. For each line read, the program calls a subroutine
    . Further, you can process the data within the subroutine. 
    After the ENDEXEC statement, SY-DBCNT contains the number of lines processed as it does in Open SQL. In almost all cases, SY-SUBRC contains the value a after the ENDEXEC statement. Cursor operations form an exception: after FETCH, SY-SUBRC is 4 if no more records could be read. This is also applied when you read a result set using EXEC SQL PERFORMING.
    Native SQL Scope 
    Native SQL is very important as it allows you to execute nearly all available statements through the SQL programming interface (usually known as SQL Call Interface or similar) for directly executing SQL program code (using EXEC IMMEDIATE or a similar command). The statements that are not supported are listed in the following section:
    ·         Native SQL and the Database Interface,
    ·         Native SQL and Transactions
    ·         Native SQL and the Database Interface
    Native SQL statements bypass the R/3 database interface. With the database buffer on the application server, there is no table logging, and no synchronization. Therefore, you should use Open SQL to change database tables declare in the ABAP dictionary wherever possible. Since the columns contain extra database specific length information for the column tables declared in the ABAP dictionary, containing long columns with the type LCHAR or LRAW should only be addressed using Open SQL. Native SQL may not produce the correct result, as it does not take this information into account. Native SQL does not support automatic client handling. Instead, you must treat a client field like any other field
    Native SQL and Transactions
    One should not use any transaction control statement such as COMMIT, ROLLBACK WORK, or any statements that set transaction parameters using Native SQL to ensure that transaction in the R/3 System are consistent.
    ABAP Dictionary
    The ABAP Dictionary is nothing but a part of the ABAP Workbench. It allows you to create and administer database tables. There are no statements from the DDL part of Standard SQL in Open SQL. It should be noted that normal application programs should not create or change their own database tables.
    To create and change database tables, the ABAP Dictionary has to use the DDL part of Open SQL. Besides this, it also administers the ABAP Dictionary in the database. In addition, the ABAP Dictionary contains meta-descriptions of all database tables in the R/3 system. Here, only database tables appears in the Dictionary, which you have created using the ABAP Dictionary. Open SQL statements can only access tables, which exists in the ABAP Dictionary.
    Authorization and Consistency Checks
    With regard to authorization and consistency checks, the DCL part of Standard SQL is not used in R/3 programs. Whereas, the work processes which are within the R/3 system are logged into the database system as users with full rights. By using the R/3 authorization concept, the authorizations of programs or users to read or change database tables is administered within the R/3 system. In addition, transactions must equally ensure their own data consistency using the R/3 locking concept.
    The R/3 lock concept allows you to monitor your system with regards to lock logics. The R/3 lock concept works closely together with the R/3 updates.
    As an example, say that a travel agent wants to book a flight for a customer who wants to fly to a particular city with a certain airline on a certain day. If there are still available seats on the flight, then the booking will be possible, otherwise it will lead to overbooking. Hence, the database entry corresponding to the flight must be locked against access from other transactions to avoid the possibility of overbooking. This is because two agents might both be doing this same thing at the same time, and we need to make sure that we don't overbook.
    Lock Mechanisms 
    When the database system receives change statements (INSERT, UPDATE, MODIFY, DELETE) from a program, it automatically sets database locks. Database locks are locks on the database entries affected by statements to prevent problems. Since the lock mechanism uses a, lock flag in the entry, you can only set a lock for an existing database entry. After each database commit, these flags are automatically deleted. This means that database locks can never be set for longer than a single database LUW, a single dialog step in an R/3 application program.
    Therefore, physical locks in the database system are 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 application servers. As a result, each lock must apply on all servers in that R/3 system.
    Database Accesses of the NetWeaver AS ABAP
    The NetWeaver AS ABAP stores long-term data in a central relational database table. In a relational database model, the real world is represented by tables. A table is a two-dimensional matrix, consisting of lines and columns (fields). The smallest possible combination of fields that can uniquely identify each line of the table is called the key. Each table must have at least one key, and each table has one key that is defined as its primary key. Relationships between tables are represented by foreign keys.
    Standard SQL
    SQL (Structured Query Language) is a largely standardized language for accessing relational databases. It can be divided into three areas:
    ·        Data Manipulation Language (DML)
    Statements for reading and changing data in database tables.
    ·        Data Definition Language (DDL)
    Statements for creating and administering database tables.
    ·        Data Control Language (DCL)
    Statements for authorization and consistency checks.
    Each database has a programming interface that allows you to access the database tables using SQL statements. The SQL statements in these programming interfaces are not fully standardized. To access a specific database system, you must refer to the documentation of that system for a list of the SQL statements available and their correct syntax.
    The Database Interface
    To avoid incompatible situations between different database tables and to make the NetWeaver AS ABAP system independent of the database system in use, each work process on an ABAP application server contains a database interface. The NW AS communicates with the database solely through the database interface. The database interface converts all of the database requests from the NW AS into the correct Standard SQL statements for the database system in use. To do this, it uses a database-specific component that shields the differences between database systems from the rest of the database interface. You choose the this component when you install NetWeaver AS ABAP in accordance with the database in use.
    ABAP programs have two options for accessing the database interface: Open SQL and Native SQL.
    Open SQL
    Open SQL statements are a fully integrated subset of Standard SQL within ABAP. They enable the ABAP programs to access data irrespective of the database system installed. 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.
    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. In SAP systems that are distributed across more than one application server, the data in the various buffers is synchronized at set intervals by 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. You specify whether a table can be buffered in its definition in the ABAP Dictionary.
    Native SQL
    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. When you use Native SQL, the function of the database-dependent layer is minimal. Programs that use Native SQL are specific to the database system for which they were written. When developing generally valid ABAP applications, you should – as far as possible – avoid using Native SQL. In some components of the SAP System, Native SQL is used – for example, in the ABAP Dictionary for creating or changing tables.
    The ABAP Dictionary
    The ABAP Dictionary, part of the ABAP Workbench, allows you to create and administer database tables. Open SQL contains no statements from the DDL part of Standard SQL. Normal application programs should not create or change their own database tables.
    The ABAP Dictionary uses the DDL part of Open SQL to create and change database tables. It also administers the ABAP Dictionary in the database. The ABAP Dictionary contains meta descriptions of all database tables in the NetWeaver AS ABAP system. Only database tables that you create using the ABAP Dictionary appear in the Dictionary. Open SQL statements can only access tables that exist in the ABAP Dictionary.
    Authorization and Consistency Checks
    The DCL part of Standard SQL is not important in ABAP programs. The work processes within the ABAP application server are logged on to the database system as users with full authorization. The authorizations of programs or program users to read or change database tables is managed by the authorization concept. Equally, transactions must ensure their own data consistency in the database using the SAP locking concept. For more information, refer to the chapter Data Consistency.
    Work Processes
    Work processes execute the individual dialog steps of ABAP application programs. They are components of ABAP application servers. The next two sections describe firstly the structure of a work process, and secondly the different types of work process in NetWeaver AS ABAP.
    Structure of a Work Process
    The following diagram shows the components of a work process:
    Screen Processor
    In ABAP 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, which controls a large part of the user interaction. NetWeaver AS ABAP 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 Processor
    The actual processing logic of an application program is written in ABAP - SAP’s own programming 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 Interface
    The database interface provides the following services:
    ·        Establishing and terminating connections between the work process and the database.
    ·        Access to database tables
    ·        Access to 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 ABAP 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 your 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 NetWeaver AS ABAP 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 ABAP 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 ABAP application server. Where NetWeaver AS ABAP is distributed across more than one ABAP 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. In Native SQL, you can primarily use database-specific SQL statements. The Native SQL interface sends them as is to the database system where they are executed. You can use the full SQL language scope of the respective database which makes all programs using Native SQL specific for the database system installed. In addition, there is a small set of SAP-specific Native SQL statements which are handled in a special way by the Native SQL interface. ABAP applications contain as little Native SQL as possible. In fact, it is only used in a few 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 NetWeaver AS ABAP. 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 Process
    Before you start NetWeaver AS ABAP, you determine how many work processes each ABAP application server will have, and what their types will be. Since all work processes have the same structure (see preceding section), the type of work process does not determine the technical attrributes of the ABAP application server but the type of tasks to be performed on it. 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 ABAP application servers.
    The following diagram shows again the structure of an ABAP application server, but this time, includes the various possible work process types:
    Dialog Work Process
    Dialog work processes deal with requests from an active user to execute dialog steps (see also Dialog Programming).
    Update Work Process
    Update 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 Process
    Background work processes process programs that can be executed without user interaction (background jobs).
    Enqueue Work Process
    The enqueue work process administers a lock table in the shared memory area. The lock table contains the logical database locks for NetWeaver AS ABAP and is an important part of the SAP LUW concept. In NW AS, you may only have one lock table. You may therefore also only have one ABAP application server with enqueue work processes. Normally, a single enqueue work process is sufficient to perform the required tasks.
    Spool Work Process
    The spool work process passes sequential datasets to a printer or to optical archiving. Each ABAP application server may contain only one spool work process.
    Role of Work Processes
    The types of its work processes determine the services that an ABAP application server offers. The 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 SAP 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.
    thanks
    karthik
    reward me points if usefull

  • 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

  • Diff b/w msg mapping and interface mapping

    hi
      i have some doubt's:
       1. diff b/w msg mapping and interface mapping
       2. What is product in SLD? usually who creates the product,technical,business system??
    thx in advance..

    hI Smartsoft General User  ,
    The following r excellent websites on mapping which differentiate msg mapping and interface mapping in detail:
    Excellent PDF Document on Mapping
    http://help.sap.com/bp_bpmv130/Documentation/Operation/MappingXI30.pdf
    Mapping Development with the ABAP Workbench
    http://help.sap.com/saphelp_nw04/helpdata/en/10/5abb2d9df242f6a62e22e027a6c382/content.htm
    ABAP Mappings
    http://help.sap.com/saphelp_nw04/helpdata/en/ba/e18b1a0fc14f1faf884ae50cece51b/content.htm
    how to create a flat file out of an IDoc-XML by means of an ABAP mapping program and the J2EE File Adapter.
    https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/46759682-0401-0010-1791-bd1972bc0b8a
    How to Use ABAP Mapping in XI 3.0
    https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/e3ead790-0201-0010-64bb-9e4d67a466b4
    These r excellent websites in SLD:
    How To…Handle the SLD for SAP XI
    https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/9e76e511-0d01-0010-5c9d-9f768d644808
    How To…Handle Caches in SAP XI 3.0
    https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/1a69ea11-0d01-0010-fa80-b47a79301290
    http://www.sap-press.de/download/dateien/751/sap_press_exchange_infra_engl.pdf
    cheers!
    gyanaraj
    ****Pls reward points if u find this helpful

  • ABAP and JAVA sync issue

    Hello,
    We are having MI 7.0 at SPS15.Am trying to apply add to our system(we created SDA file from NWA as an addon).SDA addon getting deployed but its not getting sync between ABAP and Java stack even if is run reload sever time from NWA->Administrator->Mobile Infrastructure->Mobile Components.I can see add-on when i check from SDM but it cannot see when i search under Mobile component in NWA.Application logs shows below error.
    #703543993#/Applications                                                                                #sap.com/tcmobileadmin~ea#com.sap.ip.mi.ejb.mcd.MobileContainerBean.Method---:                                                                                Processfunction#J2EE_GUEST#0##n/a##8e6d577024d511e1a299001635730592#SAPEngine_Ap                                                                                plication_Thread[impl:3]_10##0#0#Error#1#com.sap.ip.mi.ejb.mcd.MobileContainerBe                                                                                an#Plain####
    #1.#001635730592001800000015000030100004B3E6C1311ED1#1323703575929#/Applications                                                                                #sap.com/tcmobileadmin~ea#com.sap.ip.mi.ejb.mcd.MobileContainerBean.Method---:                                                                                Processfunction#J2EE_GUEST#0##n/a##a19424a024d511e18ede001635730592#SAPEngine_Ap                                                                                plication_Thread[impl:3]_9##0#0#Error#1#com.sap.ip.mi.ejb.mcd.MobileContainerBea                                                                                n#Plain####
    #1.#001635730592000F00000016000030100004B3E6C662CEBE#1323703663073#/Applications                                                                                #sap.com/tcmobileadmin~ea#com.sap.ip.mi.ejb.mcd.MobileContainerBean.Method---:                                                                                Processfunction#J2EE_ADMIN#47##n/a##d588777024d511e1c64a001635730592#SAPEngine_A                                                                                pplication_Thread[impl:3]_18##0#0#Error#1#com.sap.ip.mi.ejb.mcd.MobileContainerB                                                                                ean#Plain####
    #1.#001635730592002000000015000030100004B3E6CDC2D7E4#1323703786809#/Applications                                                                                #sap.com/tcmobileadmin~ea#com.sap.ip.mi.ejb.mcd.MobileContainerBean.Method---:                                                                                Processfunction#J2EE_GUEST#0##n/a##1f482a9024d611e18dc1001635730592#SAPEngine_Ap                                                                                plication_Thread[impl:3]_29##0#0#Error#1#com.sap.ip.mi.ejb.mcd.MobileContainerBe                                                                                an#Plain####
    #1.#00163573059200260000000C000030100004B3E6D02A2DDA#1323703827137#/Applications                                                                                #sap.com/tcmobileadmin~ea#com.sap.ip.mi.ejb.mcd.MobileContainerBean.Method---:                                                                                Processfunction#J2EE_GUEST#0##n/a##37527e6024d611e1a43c001635730592#SAPEngine_Ap                                                                                plication_Thread[impl:3]_39##0#0#Error#1#com.sap.ip.mi.ejb.mcd.MobileContainerBe                                                                                an#Plain####
    #1.#00163573059200350000000B000030100004B3E6D1150767#1323703842528#/Applications                                                                                #sap.com/tcwddispwda#com.sap.ip.mi.admin.wd.paramset.Details.Method-->wdDoModi                                                                                fyView()#J2EE_ADMIN#56##uwsvt729.merck.com_VZ1_12609950#J2EE_ADMIN#2e05832024d61                                                                                1e1b753001635730592#SAPEngine_Application_Thread[impl:3]_33##0#0#Error#1#com.sap                                                                                .ip.mi.admin.wd.paramset.Details#Plain###Specify all parameters#
    #1.#00163573059200250000007C000030100004B3E6F8460AEE#1323704500063#/Applications                                                                                #sap.com/tcmobileadmin~ea#com.sap.ip.mi.ejb.mcd.MobileContainerBean.Method---:                                                                                Processfunction#J2EE_GUEST#0##n/a##c86ab33024d711e185b5001635730592#SAPEngine_Ap                                                                                plication_Thread[impl:3]_22##0#0#Error#1#com.sap.ip.mi.ejb.mcd.MobileContainerBe                                                                                an#Plain####
    #1.#001635730592002F00000015000030100004B3E728C1AF02#1323705313486#/Applications                                                                                #sap.com/tcmobileadmin~ea#com.sap.ip.mi.ejb.mcd.MobileContainerBean.Method---:                                                                                Processfunction#J2EE_GUEST#0##n/a##ad1da59024d911e1a138001635730592#SAPEngine_Ap                                                                                plication_Thread[impl:3]_37##0#0#Error#1#com.sap.ip.mi.ejb.mcd.MobileContainerBe                                                                                an#Plain####
    #1.#001635730592000F0000000000002A400004B3E754A629F8#1323706045836#/Applications                                                                                /CMS/PCS#sap.com/tcSLCMS~PCS#com.sap.cms.pcs.serverAPI.CmsOrganizerAdapter#J2E                                                                                E_GUEST#0##n/a##61feecc024db11e1b4cb001635730592#SAPEngine_Application_Thread[im                                                                                pl:3]_26##0#0#Info#1#com.sap.cms.pcs.serverAPI.CmsOrganizerAdapter#Plain###CMS o                                                                                rganizer proxy is waiting for requests#
    #1.#001635730592000F0000000100002A400004B3E754A659EE#1323706045848#/Applications                                                                                /CMS/PCS#sap.com/tcSLCMS~PCS#com.sap.cms.pcs.serverAPI.CmsManagerAdapter#J2EE_                                                                                GUEST#0##n/a##61feecc024db11e1b4cb001635730592#SAPEngine_Application_Thread[impl                                                                                :3]_26##0#0#Info#1#com.sap.cms.pcs.serverAPI.CmsManagerAdapter#Plain###CMS manag                                                                                er proxy is waiting for requests#
    #1.#001635730592000F0000000200002A400004B3E754A6715D#1323706045854#/Applications                                                                                /CMS/PCS#sap.com/tcSLCMS~PCS#com.sap.cms.pcs.transport.proxy.CmsLogViewer#J2EE                                                                                GUEST#0##n/a##61feecc024db11e1b4cb001635730592#SAPEngineApplication_Thread[imp                                                                                l:3]_26##0#0#Info#1#com.sap.cms.pcs.transport.proxy.CmsLogViewer#Plain###CMS Log                                                                                Viewer is waiting for requests#
    #1.#001635730592000F0000000300002A400004B3E754A67B77#1323706045857#/Applications                                                                                /CMS#sap.com/tcSLCMS~PCS#com.sap.cms.recovery.RecoveryServlet#J2EE_GUEST#0##n/                                                                                a##61feecc024db11e1b4cb001635730592#SAPEngine_Application_Thread[impl:3]_26##0#0                                                                                #Info#1#com.sap.cms.recovery.RecoveryServlet#Plain###CMS recovery servlet is wai                                                                                ting for requests#
    #1.#001635730592000F0000000400002A400004B3E754A67CE5#1323706045857#/Applications                                                                                /CMS#sap.com/tcSLCMS~PCS#com.sap.cms.recovery.RecoveryServlet#J2EE_GUEST#0##n/                                                                                a##61feecc024db11e1b4cb001635730592#SAPEngine_Application_Thread[impl:3]_26##0#0                                                                                #Info#1#com.sap.cms.recovery.RecoveryServlet#Plain###start recovery#
    #1.#001635730592000F0000000500002A400004B3E754AA7F91#1323706046120#/Applications                                                                                /CMS#sap.com/tcSLCMS~PCS#com.sap.cms.recovery.pcs.QueueItemRecovery#J2EE_GUEST                                                                                #0#SAP J2EE Engine JTA Transaction : [0ffffffc069ffffff9e0008]#n/a##61feecc024db                                                                                11e1b4cb001635730592#SAPEngine_Application_Thread[impl:3]_26##0#0#Info#1#com.sap                                                                                .cms.recovery.pcs.QueueItemRecovery#Plain###CMS recovery found 0 QueueItem(s) wi                                                                                th state Import running in 0 queue(s). Start check if they are really running or                                                                                need recovery.#
    #1.#001635730592000F0000000600002A400004B3E754AA8344#1323706046121#/Applications                                                                                /CMS#sap.com/tcSLCMS~PCS#com.sap.cms.recovery.pcs.QueueItemRecovery#J2EE_GUEST                                                                                #0#SAP J2EE Engine JTA Transaction : [0ffffffc069ffffff9e0008]#n/a##61feecc024db                                                                                11e1b4cb001635730592#SAPEngine_Application_Thread[impl:3]_26##0#0#Info#1#com.sap                                                                                .cms.recovery.pcs.QueueItemRecovery#Plain###Finished check and recovery for all                                                                                CMS QueueItems of state Import running. Checked Items: 0; Recovered Items: 0; Re                                                                                covery Failed Items: 0; Real running Items: 0#
    #1.#001635730592000F0000000700002A400004B3E754AAACBA#1323706046132#/Applications                                                                                /CMS#sap.com/tcSLCMS~PCS#com.sap.cms.recovery.pcs.QueueItemRecovery#J2EE_GUEST                                                                                #0#SAP J2EE Engine JTA Transaction : [0ffffffc069ffffff9e0008]#n/a##61feecc024db                                                                                11e1b4cb001635730592#SAPEngine_Application_Thread[impl:3]_26##0#0#Info#1#com.sap                                                                                .cms.recovery.pcs.QueueItemRecovery#Plain###CMS recovery found 0 QueueItem(s) wi                                                                                th state Assembly running in 0 queue(s). Start check if they are really running                                                                                or need recovery.#
    #1.#001635730592000F0000000800002A400004B3E754AAAEE5#1323706046132#/Applications                                                                                /CMS#sap.com/tcSLCMS~PCS#com.sap.cms.recovery.pcs.QueueItemRecovery#J2EE_GUEST                                                                                #0#SAP J2EE Engine JTA Transaction : [0ffffffc069ffffff9e0008]#n/a##61feecc024db                                                                                11e1b4cb001635730592#SAPEngine_Application_Thread[impl:3]_26##0#0#Info#1#com.sap                                                                                .cms.recovery.pcs.QueueItemRecovery#Plain###Finished check and recovery for all                                                                                CMS QueueItems of state Assembly running. Checked Items: 0; Recovered Items: 0;                                                                                Recovery Failed Items: 0; Real running Items: 0#
    #1.#001635730592000F0000000900002A400004B3E754AAB68F#1323706046134#/Applications                                                                                /CMS#sap.com/tcSLCMS~PCS#com.sap.cms.recovery.RecoveryServlet#J2EE_GUEST#0##n/                                                                                a##61feecc024db11e1b4cb001635730592#SAPEngine_Application_Thread[impl:3]_26##0#0                                                                                #Info#1#com.sap.cms.recovery.RecoveryServlet#Plain###finished recovery#
    #1.#00163573059200140000000300002A400004B3E7AA40154F#1323707482010#/Applications                                                                                #sap.com/tcmobileadmin~ea#com.sap.ip.mi.ejb.mcd.MobileContainerBean.Method---:                                                                                Processfunction#J2EE_GUEST#0##n/a##b9c439d024de11e1a4ee001635730592#SAPEngine_Ap                                                                                plication_Thread[impl:3]_10##0#0#Error#1#com.sap.ip.mi.ejb.mcd.MobileContainerBe                                                                                an#Plain####
    Thanks

    Hi,
    Tha ABAP stack consists of the Integration Server which in turn contains your Integration Engine and Business Process Engine.
    The J2EE stack contains the Adapter Engine and your IR and ID run on the J2EE engine.
    Ever wondered how and where the XI pipeline gets executed? It happens in the ABAP stack.
    All messsages picked by the Adapter Framework running on the J2EE engine are passed to the Integration Engine, which does the routing. The mapping program again gets executed on the Java stack and the rest of the pipeline servies are executed again on the ABAP stack and so  on.
    Take a look at the XI overview doc to understand this better,
    https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/a3d3c390-0201-0010-c490-bd85917138c8
    Regards,
    Bhavesh

  • What's the difference between transport route and transport layer

    what's the difference between transport route and transport layer,Can somebody give me some explaination? thks in advance!

    Hi,
    Transport Layer in ABAP Workbench
        The Change and Transport System supports the distribution of development
        work on large projects across multiple SAP Systems.
        The packages in each development system are grouped into one transport
        layer.
        The transport layer determines whether objects are assigned to a local
        or transportable change request.
    Use
        Each of your SAP development systems is assigned a transport layer as
        its standard transport layer. If you use Extended Transport Control, you
        can assign different standard transport layers to certain clients.
        You can define at the most one consolidation target for each SAP System
    and transport layer.
    When you create a package, it is assigned the standard transport layer
    of the SAP System.
    If you want to assign a different transport layer to a package, you
    require the administration authorization for the Change and Transport
    System.
    The objects in a package automatically have the transport attributes
    defined for the corresponding transport layer.
    o   If a consolidation route originating in their SAP System is defined,
         then the objects are assigned to a transportable request, and
         transported into the consolidation target when it is released.
    o   If a consolidation route is not defined, the objects are assigned to
         a local request, and are not transported.
    Customizing settings are not assigned to a package. They have the
    transport attributes of the standard transport layer of the system or
    client.
    It is best to assign a package a standard transport layer for which a
    consolidation route originating in the development system is defined.
    To display and maintain the transport layers and routes, use the
    Transport Management System (transaction STMS).
    Only the system adminstrator can make changes.
    Caution:
         The tables TSYST, DEVL, TWSYS, TASYS are no longer productive as of
         Release 4.0A and cannot be maintained.
    Regards
    Ben

  • Drop Down in ALV  ABAP and NOT in OO - ABAP

    Hello Everyone....
    I m workin on an ALV which is in simple ABAP and not in OO-ABAP. There is some selection criteria on the first screen , as soon as the user fulfills the requirement an ALV GRID is displayed in which the last column is editable.
      But the Problem is that i wanna make that editable field in ALV as drop down which would contain values from the database table.
      Suggest me some method , so that i dont have to do much changes in my code .
      A Sample code will be very benificial .
    Thanx n Regards,
    Harpreet.

    Hi Harpreet,
    [compiled from sap online help - always a good chice]
    To make an input/output field into a list box, you must set the value L or LISTBOX in the Dropdown attribute in the Screen Painter. The visLg attribute determines the output width of the list box and the field. You can assign a function code to a list box field. In this case, the PAI event is triggered as soon as the user chooses a value from the list, and the function code is placed in the SY-UCOMM and OK_CODE fields. If you do not assign a function code, the PAI event must be triggered in the usual way – that is, when the user chooses a pushbutton or an element from the GUI status.
    If you have assigned a list box to an input/output field, you can use the Value list attribute of the screen element to determine how the value list should be compiled. There are two options:
    Value list from input help (recommended)
    If you do not enter anything in the value list attribute, the text field uses the first column displayed in the input help assigned to the screen field. The input help can be defined in the ABAP Dictionary, the screen, or a POV dialog module. It should be laid out in two columns. The key is automatically filled.
    Value list from PBO modules (not recommended).
    If you enter A in the value list attribute, you must fill the value list yourself before the screen is sent (for example, in the PBO event) using the function module VRM_SET_VALUES. When you do this, you must pass an internal table with the type VRM_VALUES to the import parameter VALUES of the function module. VRM_VALUES belongs to the type group VRM. The line type is a structure consisting of the two text fields KEY (length 40) and TEXT (length 80). In the table, you can combine possible user entries from the KEY field with any texts from the TEXT component. You specify the corresponding input/output field in the import parameter ID.
    Examples
    Example
    Dropdown box with a value list from input help (recommended)
    *& Report DEMO_DROPDOWN_LIST_BOX                                 *
    REPORT demo_dropdown_list_box.
    *& Global Declarations                                           *
    * Screen Interfaces
    TABLES sdyn_conn.
    DATA   ok_code TYPE sy-ucomm.
    * Global data
    TYPES: BEGIN OF type_carrid,
             carrid type spfli-carrid,
             carrname type scarr-carrname,
           END OF type_carrid.
    DATA itab_carrid TYPE STANDARD TABLE
         OF type_carrid WITH HEADER LINE.
    *& Processing Blocks called by the Runtime Environment           *
    * Event Block START-OF-SELECTION
    START-OF-SELECTION.
    CALL SCREEN 100.
    * Dialog Module PBO
    MODULE status_0100 OUTPUT.
      SET PF-STATUS 'SCREEN_100'.
    ENDMODULE.
    * Dialog Modules PAI
    MODULE cancel INPUT.
      LEAVE PROGRAM.
    ENDMODULE.
    MODULE user_command_0100 INPUT.
      CASE ok_code.
        WHEN 'SELECTED'.
          MESSAGE i888(sabapdocu) WITH sdyn_conn-carrid.
    ENDCASE.
    ENDMODULE.
    * Dialog Module POV
    MODULE create_dropdown_box INPUT.
      SELECT carrid carrname
                    FROM scarr
                    INTO CORRESPONDING FIELDS OF TABLE itab_carrid.
      CALL FUNCTION 'F4IF_INT_TABLE_VALUE_REQUEST'
           EXPORTING
                retfield        = 'CARRID'
                value_org       = 'S'
           TABLES
                value_tab       = itab_carrid
           EXCEPTIONS
                parameter_error = 1
                no_values_found = 2
                OTHERS          = 3.
      IF sy-subrc <> 0.
    ENDIF.
    ENDMODULE.
    The next screen (statically defined) for screen 100 is 100. The only input field on the screen is the component SDYN_CONN-CARRID. Its Dropdown attribute is set to L, and it has the output length 20. The Value list attribute is empty, and it has the function code SELECTED. The function codes of the buttons EXECUTE and CANCEL. CANCEL are defined in the GUI status as having the function type E.
    The screen flow logic is as follows:
    PROCESS BEFORE OUTPUT.
      MODULE status_0100.
    PROCESS AFTER INPUT.
      MODULE cancel AT EXIT-COMMAND.
      MODULE user_command_0100.
    PROCESS ON VALUE-REQUEST.
      FIELD sdyn_conn-carrid MODULE create_dropdown_box.
    Users cannot enter any values into the screen fields. When they choose the input field on screen 100, the system displays a list box. The Value list attribute is empty, so the system launches the input mechanism. In this case, the event block PROCESS ON VALUE-REQUEST is created in the screen flow logic. This event block controls all other mechanisms. A two-column internal table is filled in the appropriate dialog module and passed to the input help using the F4IF_INT_TABLE_VALUE_REQUEST function module. The system inserts the two columns of the table into the list box.
    When the user chooses a line in the list box, the PAI event is triggered using the function code SELECTED and the value in the first column of the internal table is copied to the input field.
    Regards,
    Clemens

  • Individual business system for ABAP and Java Stack

    Hi All,
    I need to send message from a system to XI via ABAP proxy and Java proxy. The sender's ABAP and Java proxy use the same message interface to communicate with XI. Should I create one business system for the ABAP stack and one for Java stack of the sender system?
    Thanks + Best Regards
    Jerome

    Are you sending same message type from ABAP proxy and Java Proxy to XI?
    If you have ABAP proxy, why do you need Java Proxy? Actually you cannot create any Java proxies on ABAP bases systems. What kind of system sender is? Java proxies are created for pure Java based applications.
    Let me know if I didnt understand your question correctly. If so, please explain in detail why you need both proxies and what is your sender application.
    --Archana

  • Is it possible to transport ABAP querys/ Report painter between systems

    Hi all
    Is it possible to transport ABAP querys/ Report painter object between one r/3 system and another ?

    Hi,
    Its possible to transport SAP Query (Global Area). When you save the infoset it will ask you to the request id for transport
    For SAP Queries in Standard area, there is a transport icon in the SQ02 screen which would transport it to required destinations
    thanks
    Sriram

  • Transport abap query from one client to another--v--urgent---v----urgent

    hi,
    i have an abap query in one client and want to copy to another client.can i do this if so what are the steps involved .i tried the options like in query go to environment and then to transport .i also tried to do by running the programe RSAQR3TR.but it was transporting in the same client .i want to transfer into another client.plz help me out asap .

    hi,
    Create a request related to that Table Definition and add data content in the request like
    R3TR-TABL-<table name>
    R3TR-TABU-<table name>
    R3TR-TABD-<table name>
    and release the request
    Take the DATA files and CO files related to that request in a Pen drive and put the same into the new server DATA and CO files and import using STMS.
    For new program, it gets transported along with the program.
    For changed program (which has already been transported once), you need to include texts in transport request - just go to Selection texts, save them in the transport request and you're all set.
    whenever you assign a request number to the program
    and also the selection texts willbe stored under that request number
    so when u release the program
    the selection texts will also go
    after releasing the request if you change only the seleciton texts
    only the changes done to selection texts will reach the target
    and the rest of the things remain same
    so when ever you release a request all the things under that request
    will go

  • Difference between Conversion progs and INTERFACES

    Hi  plz     tell me  ...
    whats  the difference between    Conversion progs and Interfaces in ABAP .
    wat are  conversion progs  ( exmple) and interfaces  ( exmple ) ?
    thnks in advance....

    Hi
    CONVERSION programs are the ones which have one time usage, usually when a legacy system is being replaced by a system like SAP, then the data has to be mapped from the legacy system to SAP system. Here the data to be converted is given on a flat file & is uploaded to SAP tables mostly using LSMW only. Conversions programs are BDC,BAPI and LSMW programs in which you upload all the related tables from the flat files.Those are one time programs.
    Interface programs are those programs in which you fetch the data from the application server and process on theose data.These are helpful when you have to run any program in the backgroup when the presentation server is not working.
    INTERFACE programs are the ones which are run at regular intervals, say weekly, monthly or even daily. Here the legacy system continues to co-exist along with SAP system, the legacy system might be useful for certain functionalities but the data might have to run thru SAP transactions for complex data maintenance at regular intervals.
    In Simple
    CONVERSIONS : Converting Legacy System DATA into a flat file
    INTERFACES : Converting Flat File into SAP
    Conversion Program
    http://help.sap.com/saphelp_erp2005/helpdata/en/d3/a65a14e96911d1b401006094b944c8/frameset.htm
    Interface Program
    http://help.sap.com/saphelp_erp2005/helpdata/en/64/be5b4150b38147e10000000a1550b0/frameset.htm
    <b>Reward if usefull</b>

  • Help regarding ABAP and ABAP Objects

    Dear all,
    I am very new in abap and abap objects. But i have some expr. in other language..specialy development. Right now i am working for srm module...So i want to move my self into abap object and specialy in workflow...Please provide me help regarding this...along with the starting point for this.
    Best Regards
    Vijay Patil

    hi
    Object Oriented prg
    A programming technique in which solutions reflect real world objects
    What are objects ?
    An object is an instantiation of a class. E.g. If “Animal” is a class, A cat
    can be an object of that class .
    With respect to code, Object refers to a set of services ( methods /
    attributes ) and can contain data
    What are classes ?
    A class defines the properties of an object. A class can be instantiated
    as many number of times
    Advantages of Object Orientated approach
    Easier to understand when the system is complex
    Easy to make changes
    Encapsulation - Can restrict the visibility of the data ( Restrict the access to the data )
    Polymorphism - Identically named methods behave differently in different classes
    Inheritance - You can use an existing class to define a new class
    Polymorphism and inheritance lead to code reuse
    Have a look at these good links for OO ABAP-
    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.
    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/
    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
    Hope this helps
    if it helped, you can acknowledge the same by rewarding
    regards
    ankit

  • SAP certified professional - ABAP system interfaces with SAP netweaver 7.0

    Hi,
    I have one and half years experience in ABAP. I want to do "SAP CERTIFIED DEVELOPMENT PROFESSIONAL - ABAP SYSTEM INTERFACES WITH SAP NETWEAVER 7.0".
    I am currently in U.S and would like to do the certification here. Whom do I need to contact and what are the documents I need to furnish. Please throw some light on the process.
    Thanks,
    Poonam.

    Dear Poonam,
    the "Professional"-Certification is very very hard - during my last Certifcation Exam, all candidates with the Pro-Exam failed (I was so glad I chose the normal certification...)
    Here's how to book your exam:
    Go to [http://www.sap.com/services/education/certification/index.epx|http://www.sap.com/services/education/certification/index.epx] and follow the instructions ("visit the local SAP Education Web site for the country").
    Figure out the exam code for your certification. Example: For the US, there is a downloadable list (PDF) of exams available, called "list of the available certification exams".
    Schedule the exam according to the rules of your region - here is the link for the US:
    [http://www.sap.com/usa/services/education/certification/exam.epx|http://www.sap.com/usa/services/education/certification/exam.epx]
    Regards,
    Klaus

Maybe you are looking for

  • I think my hard drive is....DEAD

    I have an ibook G4 and the hard drive makes a very loud clicking noise, when i turn it on, the chime comes on and sometimes there is a ? mark, but sometimes it boots, but when it does almost every move of the mouse results in the beach ball. are ther

  • Summary Report question regarding data that is included and data that is not.

    I have a survey that is running at the momemt with about 15% of the expected responses(250-300) which I'll gather over the next couple of weeks. When I check the current Summary Report it omits several of the questions and answers shown in the curren

  • AIA on Oracle SOA Suite 11g

    Hi , Is it possible to install AIA 2.5 Foundation pack on Oracle SOA Suite 11g. Can you please share any oracle documentation in this regard? Regards, Sam

  • Backup Manager on OEM

    Hi, I'm really stuck and frustrated with this one:- I'm trying to issue backup jobs from Enterprise Manager but I keep getting VNI-2015 : authentication error. I'm sure I've set the node credentials correctly and the user is a local user on the NT Se

  • No reflow for Adobe Reader LE?

    My pocket pc has adobe reader le 2.0 pre installed but when open document, no reflow. Am I missing something?