BASIS DAILY ACTIVITIES

SAP DAILY ACTIVITIES

1] Check that all the application servers are up:
sm51 SAP Servers
sm04/al08 Logon Users

2] Check that daily backup are executed without errors
db12 Backup logs: overview

3] SAP standard background jobs are running successfully. Review for cancelled and critical jobs.
sm37 Background jobs--- Check for successful completion of jobs. Enter * in user-id field and verify that all critical successful jobs and review any cancelled jobs.

4] Operating system Monitoring
st06

5] Extents monitoring
db02 Database monitoring--Check for max-extents reached

6] Check work-processes(started from sm51)
sm50 Process overview-- All work processes with a running or waiting status.

7] Check system log
sm21 System log-- Set date and time to before the last log review. Check for errors ,warning, security, message-bends,database events.

8] Review workload statistics
st03 Workload analysis of
sto2 tune summary instance

9] Look for any failed updates
sm13 update records

10] check for old locks
sm12 lock entry list

11] Check for spool problems
sp01 spool request screen-- check for spool that are in request for over an hour.

12] Review and resolve dumps
st22 ABAP Dump analysis

13] Checking .trc file in SAP trace directory for block corruption on daily basis.
C:\ORacle\sid\saptrace

14] Archive backup
brarchive -f force -cds -c
Insert the archive backup tape

15] Review NT system logs for problem
-> NT system log- look 4 errors or failures
-> NT security log- failed logon 2 sap servers
-> NT Application log -look 4 errors or failures

What is BASIS?

BASIS- A set of middleware programs and tools that provide the underlying base that enable applications to be interoperable across operating systems. SAP Basis includes a RDBMS, GUI, and client server architecture. Beyond the interface aspect of Basis, it also includes such components as a data dictionary as well as user and system administration.

Basis is a business application software integrated solution. Simply, Basis is the administration of the SAP system.

It's a piece of middleware which links the application with the database and the operating system. Basis is most commonly associated with the GUI interface to the SAP, and the Basis administrator is an SAP, professional who is responsible for configuring the SAP environment, including the GUI screens and SAP application servers.

R/3 Basis includes client/server architecture and configuration, a relational database management system (RDBMS), and a graphical user interface (GUI). In addition to the interface between system elements, Basis components include a development environment for R/3 applications, and a data dictionary, as well as user and system administration and monitoring tools.

Client Copy

Client Copy
Purpose
You can use the client copy to create, for example the following clients:

· new clients from the SAP reference client 000 during initial installation of an SAP system.

· training clients

· demo clients

· test clients

· production clients

The source client can be in the same or another system.

You can copy selected parts of an existing client into another client, e.g. the user master data with the copy profile SAP_USER, with the client copy tools.

You are strongly advised to use the profile SAP_CUST to copy client 000 to create your first client because the consistency of the application data in the SAP delivery client is not guaranteed.

You are no longer required to transport clients before you can copy them between systems. You can make a remote copy instead. SAP will continue to support the transport function.


Preparation
Target client
You can create a new client in the client maintenance (transaction SCC4). You need a user with sufficient authorization in the target client, for the client copy.

The newly-created client contains the initial benutzer SAP* with the password PASS, which you can use to copy a client.


The user SAP* is inactive by default in a new client. To activate the user SAP*, set the profile parameter login/no_automatic_user_sapstar to 0, and restart the application server.


You do not need to delete an existing client before the copy.

Resource requirements
Copying clients requires a large amount of system resources. To avoid premature termination due to bottlenecks, you should ensure that enough resources are available by considering the following points:

· Database storage space

Perform a test run before copying a client. The total of copied and deleted data in kB is at the end of the log file.

For ORACLE, INFORMIX, ADABAS and DB2/CS databases, you can check the test run log to see whether there is sufficient database space available.

Storage requirements can only be estimated, because space already allocated, but not yet used, is not taken into account. A client without application data needs approximately 500 MB in the database. In most databases, space made free by deleting data is only available after a reorganization.

For pool tables, the estimate is very imprecise, because their extent size is very large. You must assume that a new extent is required for each pool table, which must be added to the estimate.

· Runtime

Copying a client can take several hours or even days. Users or background processes in clients other than the source or target clients, can make the time longer. For example, locks in a third client in the same system can obstruct the processing of individual objects. You can technically work in the system while client copy is running, but you are strongly advised not to do so, or only in exceptional cases.

You may have to increase the standard timeout value for these processes if you are working in the foreground with slow databases, large clients or clients with a lot of users:

§ ...

i. To increase the default timeout value, call the transaction Maintain Profile Parameters (RZ 11).

ii. Specify the profile parameter rdisp/max_wprun_time.

iii. Choose Display.

iv. Choose Change Value.

v. Specify a new value for the profile parameter.

We recommend a value of 2000 seconds.

If you use parallel processes, dialog processes are used even if the job is scheduled in the background. The standard timeout value is usually sufficient. If the database is loaded by additional processes, it can be advisable to increase the profile parameter.

· System load

Copying or transporting a client can take a long time because large amounts of data are moved. One or more dialog processes are occupied for this time. The database interface is heavily loaded.

Protecting clients against user logon
· You must ensure that no users logon to the system during the copy. For technical reasons, only the target client is locked. If, e.g. the lock is not reset after a copy is cancelled, you can reset it by calling the transaction SCC3 in any client.

Users who are in the target client before the start of the copy cannot be locked automatically, so you must ensure that they leave the system.

· The source and target clients should both be additionally protected by a system message (SM02). Monitor compliance in both clients (e.g. in SM04)

· You should not work in the source client either during the copy.

Constraints
· You cannot access archived data in the target client if the target client number is not the same as the source client number.

· Change documents (tables CDHDR, PCDHDR, CDPOS and PCDPOS): User administration change documents and generic logs (application log tables BAL*) are not copied

Functional Specifications

Functional Specifications

Functional specifications (functional specs), in the end, are the blueprint for how you want a particular report and transaction to look and work. It details what the report will do, how a user will interact with it, and what it will look like. By creating a blueprint of the report or transaction first, time and productivity are saved during the development stage because the programmers can program instead of also working out the logic of the user-experience. It will also enable you to manage the expectations of your clients or management, as they will know exactly what to expect.

A key benefit of writing up a Functional Spec is in streamlining the development process. The developer working from the spec has, ideally, all of their questions answered about the report or transaction and can start building it. And since this is a spec that was approved by the client, they are building nothing less than what the client is expecting. There should be nothing left to guess or interpret when the spec is completed.

Functional Specification
A functional specification (or sometimes functional specifications) is a formal document used to describe in detail for software developers a product's intended capabilities, appearance, and interactions with users. The functional specification is a kind of guideline and continuing reference point as the developers write the programming code. (At least one major product development group used a "Write the manual first" approach. Before the product existed, they wrote the user's guide for a word processing system, then declared that the user's guide was the functional specification. The developers were challenged to create a product that matched what the user's guide described.) Typically, the functional specification for an application program with a series of interactive windows and dialogs with a user would show the visual appearance of the user interface and describe each of the possible user input actions and the program response actions. A functional specification may also contain formal descriptions of user tasks, dependencies on other products, and usability criteria. Many companies have a guide for developers that describes what topics any product's functional specification should contain.
For a sense of where the functional specification fits into the development process, here are a typical series of steps in developing a software product:

Requirements:
This is a formal statement of what the product planners informed by their knowledge of the marketplace and specific input from existing or potential customers believe is needed for a new product or a new version of an existing product. Requirements are usually expressed in terms of narrative statements and in a relatively general way.

Objectives: Objectives are written by product designers in response to the Requirements. They describe in a more specific way what the product will look like. Objectives may describe architectures, protocols, and standards to which the product will conform. Measurable objectives are those that set some criteria by which the end product can be judged. Measurability can be in terms of some index of customer satisfaction or in terms of capabilities and task times. Objectives must recognize time and resource constraints. The development schedule is often part or a corollary of the Objectives.
Functional specification.: The functional specification (usually functional spec or just spec for short) is the formal response to the objectives. It describes all external user and programming interfaces that the product must support.
Design change requests: Throughout the development process, as the need for change to the functional specification is recognized, a formal change is described in a design change request.

Logic Specification:
The structure of the programming (for example, major groups of code modules that support a similar function), individual code modules and their relationships, and the data parameters that they pass to each other may be described in a formal document called a logic specification. The logic specification describes internal interfaces and is for use only by the developers, testers, and, later, to some extent, the programmers that service the product and provide code fixes to the field.

User documentation:
In general, all of the preceding documents (except the logic specification) are used as source material for the technical manuals and online information (such as help pages) that are prepared for the product's users.
Test plan: Most development groups have a formal test plan that describes test cases that will exercise the programming that is written. Testing is done at the module (or unit) level, at the component level, and at the system level in context with other products. This can be thought of as alpha testing. The plan may also allow for beta test. Some companies provide an early version of the product to a selected group of customers for testing in a "real world" situation.

The Final Product:
Ideally, the final product is a complete implementation of the functional specification and design change requests, some of which may result from formal testing and beta testing. The cycle is then repeated for the next version of the product, beginning with a new Requirements statement, which ideally uses feedback from customers about the current product to determine what customers need or want next.
Most software makers adhere to a formal development process similar to the one described above. The hardware development process is similar but includes some additional considerations for the outsourcing of parts and verification of the manufacturing process itself.

Understanding SAP LANDSCAPE

SAP LANDSCAPE:

Landscape is like a server system or like a layout of the servers or some may even call it the architecture of the servers viz. SAP is divided into three different lanscape DEV, QAS and PROD.

DEV would have multiple clients for ex: 190- Sandbox, 100- Golden, 180- Unit Test.

QAS may again have mutiple clients for ex: 300- Integration Test, 700 to 710 Training.

PROD may have something like a 200 Production.

These names and numbers are the implementer's discreet on how they want it or they have been using in their previous implementations or how is the client's business scenario.

Now whatever you do in the Sandbox doesn't affect the other servers or clients. Whenever you think you are satisfied with your configuration and you think you can use it moving forward, you RE-DO it in the golden client (remember, this is a very neat and clean client and you cannot use it for rough usage).

As you re-do everything that you had thought was important and usable, you get a transport request pop up upon saving everytime. You save it under a transport request and give your description to it. Thus the configuration is transported to the Unit Test client (180 in this example).

You don't run any transaction or even use the SAP Easy Access screen on the 100 (golden) client. This is a configuration only client. Now upon a successful tranport by the Basis guy, you have all the configuration in the Testing client, just as it is in the Golden client. The configuration remains in sync between these two clients.

But in the Testing client you can not even access SPRO (Display IMG) screen. It's a transaction only client where you perform the unit test. Upon a satisfactory unit test, you move the good configuration to the next SERVER (DEV).

The incorrect or unsatisfactory configuration is corrected in Golden (may again as well be practised in the sandbox prior to Golden) and accordingly transported back to 180 (Unit Test) until the unit test affected by that particular config is satisfactory.

The Golden client remains the 'database' (if you wanna call it that) or you may rather call it the 'ultimate' reference client for all the good, complete and final configuration that is being used in the implementation.

In summary:

Landscape : is the arrangement for the servers

IDES : is purely for education purpose and is NOT INCLUDED in the landscape.

DEVELOPMENT ---> QUALITY ----> PRODUCTION

DEVELOPMENT : is where the the consultants do the customization as per the company's requirement.

QUALITY : is where the core team members and other members test the customization.

PRODUCTION : is where the live data of the company is recorded.

A request will flow from Dev->Qual->Prod and not backwards.

1. Sandbox server:

In the initial stages of any implementation project, You are given
a sandbox server where you do all the configuration/customization as per the companies business process.

2. Development Server:

Once the BBP gets signed off, the configuration is done is development server and saved in workbench requests, to be transported to Production server.

3. Production Server:

This is the last/ most refined client where the user will work after project GO LIVE. Any changes/ new develpoment is done is development client and the request is transported to production.

These three are landscape of any Company. They organised their office in these three way. Developer develop their program in Development server and then transport it to test server. In testing server tester check/test the program and then transport it to Production Server. Later it will deploy to client from production server.

Presentaion Server- Where SAP GUI have.
Application Server - Where SAP Installed.
Database Server - Where Database installed.

What is the meaning of "R" in R/3 systems?

R/3 stands for realtime three tier architecture. This is the kind of architrecture SAP R/3 system has.

R/3 means three layers are installed in Different system/server and they are connected with each other.

1)Presentation
2)Application.
3)Data base server.

Data Migration

SAP n Data Migration

SAP Business process

BDC Interview Questions

ABAP BDC Interview Questions

1 What should be the approach for writing a BDC program?
Ans.: 1. Analysis the Data.2. Generate SAP structure.3. Develop transfer program 4. Create sequential file. 5. Create batch input program. 6. Process batch input data

2 What is the alternative to batch input session?
Ans. : Call transaction & call dialog

What are the steps in a BDC session ?
The first step in a BDC session is to identify the screens of the transaction that the program will process. Next step is to write a program to build the BDC table that will be used to submit the data to SAP. The final step is to submit the BDC table to the system in the batch mode or as a single transaction by the CALL TRANSACTION command.

3 What are the problems in processing batch input sessions? How is batch input process different from processing on line?
Ans.: Sessions cannot be run in parallel and not fast.

4 What do you do when the system crashes in the middle of a BDC batch session?
Check no. of records already updated and delete them from input file and run BDC again.

5 What do you do with errors in BDC batch session?
Analysis and correct input file format and entries in internal table BDCDATA.

6 WHAT are the commands that allow you to process sequential file? And what is their syntax?
Ans :- READ DATASET (reading) and TRANSFER (writing)
OPEN DTASET (dataset name) for(input/output appending) in (binary text ) mode at POSITION (position) MESSAGE(field)
READ DATASET (dataset name ) INTO (field)
CLOSE DATASET (dataset name)
DELETE DATASET (dataset name)
TRANSFER (field) to (dataset name)

7 What is the process for transferring data from legacy system to SAP?
Ans :- FTP file transfer, Manufacturer –specific field transfer NFS(network file system)/BDC.

8 Explain the process to transfer a record to a dataset?
Ans :- TRANSFER (field) to (dataset name).

9 Why batch input?
Ans :- To input a large amount of information at off peak times.

10 Can data be put directly into the database?
Ans :- No, only after the data has been entered via transaction.

11 Explain at high level, the batch input process?
Ans :- Batch data is placed into queues called batch input sessions , then placed into the application programs for maintenance into the database.
12 What are the function modules associated with batch input?
Ans :- BDC_OPEN_GROUP , BDC_CLOSE_GROUP , BDC_INSERT

13 What is the structure of the BDC table?
Ans :- Program/Dynpro/start/field name/ field content.

14 Write out a coding example for filling a BDC Table.
Ans :- FORM (NAME)
REFEESH (bdc table)
CLEAR (bdc table)
MOVE (program name) to (bdc table)-PROGRAM
(number1) TO (bdc table)-DYNPRO
‘X’ TO (bdc table)-DYNBEGIN
APPEND (bdc table)
CLEAR(bdc table)
MOVE: (field1) TO (bdc table)-FNAM
(field2) TO (bdc table)-FVAL
APPEND (bdc table)

15How do you find the transaction number, program number and field names?
Ans :- Transaction no.,program no. – System -> status
Field names - F1, Technical help

16 What are the processing modes for Batch Input?
Ans :- Process on screen(foreground) , Display errors only and process in the background

17What are the available OK Codes that can be utilized during batch input processing?
Ans :- /n – terminates current batch input transaction and marks as incorrect.
/bdel – delete current batch input transaction from session.
/bend – terminate batch input processing and mark session as incorrect.
/bda – change display mode to process the session on screen instead of displaying only errors.
/bde – change display mode to display only errors instead of processing the session on the screen.

18 What is the effect of the BDC_CURSOR field name in the BDC table?
Ans :- You can set the cursor and enter as a corresponding field value the name of the field on which the cursor is to be positioned .

19 How many types of BDCs you have done?
21Why you choose Call transaction and/or session method?
Call transaction is mainly used when you want to update the database using a single transaction , you can also update the database in asynchronous mode, where as session is used to perform huge database updations using more than one transaction and which will last for a long time.

22 How you trap errors in call Transaction
Errors while updating the database using call transaction technique are trapped using a structure bdcmsgcall, whose field msgtyp become ‘e’ when an error record is encountered. Those records are formatted using format_message function call in the desired format and stored in an internal table for listing of all error records in one shot.

23 What are different types of Update modes
In BDC’s we have two types of updation modes – 1) Synchronous 2) Asynchronous

24 What is main difference between session method and LSMW
In the context of session method,
the method of updating is “Batch Input” ,
we require a program to be coded,
But in the context of LSMW method,
The methods of updating
using “Batch Input/Direction Input”
from an IDOC,
from a BAPI structure.
No source code is required, the complete operation is performed in 16 steps sequence

25 What is main difference between CATT and LSMW
Using LSMW you can update any kind of data but no changes to database are allowed, where as CATT tool can update only master data, which also allows changes to the master data and also a significant testing of data is possible

26 What is BDC and How you use it?
BC Basis Components--ABAP workbench--BC Basis Programming interfaces--Data transfer
During data transfer, data is transferred from an external system into the SAP R/3 System. •Transfer data from an external system into an R/3 System as it is installed. •Transfer data regularly from an external system into an R/3 System.
Example: If data for some departments in your company is input using a system other than the R/3 System, you can still integrate this data in the R/3 System. To do this, you export the data from the external system and use a data transfer method to import it into the R/3 System.
Batch input with batch input sessions : Data consistency check with the help of screen logic.
With the batch input method, an ABAP program reads the external data that is to be entered in the R/3 System and stores the data in a "batch input session". The session records the actions that are required to transfer data into the system using normal SAP transactions.
When the program has generated the session, you can run the session to execute the SAP transactions in it. You can explicitly start and monitor a session with the batch input management function (by choosing System ® Services ® Batch input), or have the session run in the background processing system.
Use the BDC_OPEN_GROUP function module to create a new session. Once you have created a session, then you can insert batch input data into it with BDC_INSERT. Use the BDC_INSERT function module to add a transaction to a batch input session. Use the BDC_CLOSE_GROUP function module to close a session after you have inserted all of your batch input data into it.

What is Dataset and how you use it?
ABAP/4 provides three statements for handling files:
The OPEN DATASET statement opens a file.
The CLOSE DATASET statement closes a file.
The DELETE DATASET statement deletes a file.
To open a file for read access, use the FOR INPUT option of the OPEN DATASET statement
To open a file for write access, use the FOR OUTPUT option of the OPEN DATASET statement
To open a file for appending data to the file, use the FOR APPENDING option of the OPEN DATASET statement
To process a file in binary mode, use the IN BINARY MODE option of the OPEN DATASET statement
To process a file in text mode, use the IN TEXT MODE option of the OPEN DATASET statement
To open a file at a specific position, use the AT POSITION option of the OPEN DATASET statement
When you work with the operating systems UNIX or WINDOWS NT, you can send an operating system command with the statement OPEN DATASET. To do so, use the option FILTER
To receive the operating system message after trying to open a file, use the MESSAGE option of the OPEN DATASET statement
To close a file on the application server, use the CLOSE DATASET statement
To delete a file on the application server, use the DELETE DATASET statement
To write data to a file on the application server, use the TRANSFER statement
To read data from a file on the application server, use the READ DATASET statement.

36 Give real time work done by u in BDC ? Transactions used ? parameters passed with functions.
37 will ask u for screen no's and dynpro names for BDC that u say u have done.
39 Which technical field in the BDCDATA table holds the last cursor position?
41 What is true about the LSMW: (choose correct option/s)
Part of the SAP system
Processes hierarchical data files (header and position)
Needs a source field for every target field

44 How do you read a LOCAL sequential file?
45 How do you write a sequential file?
46 How do you send the BDCDATA table in a Call Transaction statement?
47 What loop do you code for a READ DATASET statement?
51 What are the steps in a BDC session ?
The first step in a BDC session is to identify the screens of the transaction that the program will process. Next step is to write a program to build the BDC table that will be used to submit the data to SAP. The final step is to submit the BDC table to the system in the batch mode or as a single transaction by the CALL TRANSACTION command.

52 How do you find the information on the current screen ?
Status command from any menu.The information on the current screen can be found by System

53 How do you save data in BDC tables ?
The data in BDC tables is saved by using the field name ‘BDC_OKCODE’ and field value of ‘/11’

54 What is the last entry in all BDC tables ?
In all BDC tables, the last entry is to save the data by using the field name BDC_OKCODE and a field value of ‘/11’.

55 What is a multiple line field ?
A multiple line field is a special kind of field which allows the user to enter multiple lines of data into it.

56 How do you populate data into a multiple line field ?
To populate data into a multiple line field, an index is added to the field name to indicate which line is to be populated by the BDC session (Line index ).

57 Write the BDC table structure.
BDC table structure
FIELD TYPE DESCRIPTION
Program CHAR(8) Program name of transaction
DynPro CHAR(4) Screen number of transaction
DynBegin CHAR(1) Indicator for new screen
Fnam CHAR(35) Name of database field from
Screen
Fval CHAR(80) Value to submit to field

58 Does the CALL TRANSACTION method allow multiple transactions to be processed by SAP ?
No. The CALL TRANSACTION method allows only a single transaction to be processed by SAP.

59 Does the BDC_INSERT function allow multiple transactions to be processed by SAP ?
Yes.

60 What is the syntax for ‘CALL TRANSACTION’ ?
CALL TRANSACTION trans [ using bdctab MODE mode ].
Three possible entries are there for MODE.
A - show all screens
E - show only screens with errors
N - show no screens
Which mode of ‘CALL TRANSACTION’ method allows background processing ?
N is the only mode that allows background processing.

61 Is it possible to use ‘CALL TRANSACTION’ without a BDC table ?
Yes, it is possible to use ‘CALL TRANSACTION’ without a BDC table. In such case, the current program is suspended, the transaction specified is brought up, and a user must enter the data into the screens.

62 What is TCODE ?
TCODE is the transaction code for the transaction that should be used to process the data in the BDC table being inserted.

63 What are the function modules that need to be called from BDC program to submit the transactions for processing ?
- BDC_OPEN_GROUP
- BDC_INSERT
- BDC_CLOSE_GROUP

64 How many sessions will be opened using BDC_OPEN_GROUP ?
Only one session can be created using the BDC_OPEN_GROUP functon.

65 What is ‘BATCH INPUT’ or ‘BDC’ ?
The SAP system offers two primary methods (BDC SESSION METHOD, CALL TRANSACTION METHOD) for transferring data into the system from other systems and Non-SAP systems. These two methods are collectively called as ‘BATCH INPUT’ or ‘Batch Data Communication’ (BDC).

66 What are the advantages in Batch Input ?
The Batch Input ensures Data integrity.
No manual interaction is required during Data transfer.

67 What is the functionality of ‘Classical Batch Input’ ?
In ‘Classical Batch Input’ an ABAP/4 program reads the external data that is to be entered in the SAP system and stores the data in a Batch Input session. This session stores the actions that are required to enter your data using normal SAP transactions.
68 Which Function Modules are used in ‘Classical Batch Input’ ?
BDC_OPEN_GROUP , BDC_INSERT, BDC_CLOSE_GROUP.

69 What is Synchronous Database update ?
During the processing no transaction is stored until the previous transaction has been written to the Database. This is called Synchronous Database update.

70 What are the differences between CALL TRANSACTION and BATCH INPUT SESSION ?
- The most important aspects of the batch session interface are:
- Asynchronous processing
- Transfers data for multiple transactions
- Synchronous database update
During processing, no transaction is started until the previous transaction has been written to the database.
- A batch input processing log is generated for each session
- Sessions cannot be generated in parallel
The most important aspects of the CALL TRANSACTION USING interface are:
- Synchronous processing
- Transfers data for a single transaction
- Synchronous and asynchronous database updating both possible
The program specifies which kind of updating is desired.
- Separate LUW for the transaction
The system performs a database commit immediately before and after the CALL TRANSACTION USING statement.
No batch input processing log is generated

71 What are the types of Batch Input ?
Classical Batch Input
Call Transaction
Call Dialog

72 What is BDC_OKCODE ?
The command field is identified by a special name in batch input called BDC_OKCODE. This name is constant and always identifies the command field.

73 How can we execute a function in a BDC session ?
We can execute a function in a transaction by entering the function code or function key number in the command field of an SAP session. A function key number must be prefixed with the / (slash) character. A function code must be prefixed with the = character.
Example:
BDCDATA-FNAM = 'BDC_OKCODE'
BDCDATA-FVAL = '=UPDA'

74 How can we position the cursor on a particular field ?
BDCDATA-FNAM = ‘BDC_CURSOR’
BDCDATA-FVAL =

75 Who are Dialog users and who are Background users ?
Dialog users are normal interactive users in the SAP system. Background users are user master records that are specially defined for providing authorizations for background processing jobs.

76 What is the use of BDC_INSERT ?
We add a transaction to a Batch Input Session by using this function.

77 What are the update modes in CALL TRANSACTION ?
S : Synchronous
A : Asynchrnous
L : Local

78 What does the message parameter indicates ?
The message parameter indicates there all system messages issued during a CALL TRANSACTION are written into the internal table . The internal table must have the structure of BDCMSGCOLL.

79 What is Direct Input ?
To enhance the batch input procedure, the system offers the direct input technique especially for transferring large amount of data. This technique doesn’t create sessions but stores the data directly. The direct input programs must be executed in the back ground only. To maintain and start these programs, use program RBMVSHOW or the transaction BMVO.

80 What are the features of Recording Function ?
recording transaction runs
creating batch input sessions from the recorded transaction runs.
Generating a batch input program from the recorded data.

81 What is synchrnous database update ?
During the processing, no transaction is stored until the previous transaction has been written to the database. This is called Synchronous database update.

82 How do you set up batch process?
Data analysis: Analyze the data that is to be transferred to the SAP System.
||
Generate SAP structures: Generate SAP data structures for incorporation into your data export program.
||
Develop transfer program: You can write the program in ABAP/4 or as an external program.
||
Create sequential file: Export the data that is to be transferred, to a sequential file.
||
Create batch input program: ABAP/4 batch input program that will read the data to be transferred from the sequential file.
||
Process batch input data: Process the data and add it to the SAP System. You can do this either by:
batch-input session method or Call transaction method.
||
Analyse results: Check that all data has been successfully processed.
||
Analyse Error session: Correct and re-process erroneous data.

83 Where do you use BDC?
transferring data from another system when you install your SAP System
regularly transferring data that is captured by a non-SAP system in your company into the SAP System. Assume, for example, that data collection in some areas of your company is still performed by a non-SAP system. You can still consolidate all of your data in the SAP System by exporting the data from the other system and reading it into the SAP System with batch input.
You can also use batch input to transfer data between two R/3 Systems. However, there are more direct methods for doing this, such as RFC (remote function calls).

84 What has to be done to the packed fields before submitting to a BDC session?
Declare these fields in the internal table as characters and the length of the field should be same as the field length of the field's data element. This internal table is used to hold the data fetched from the sequential file using WS-upload function module

What is LSMW
The LSMW is a cross-application component (CA) of the SAP R/3 System.
The tool has interfaces with the Data Transfer Center and with batch input and direct input processing as well as standard interfaces BAPI and IDoc in R/3.
The LSMW comprises the following main functions:
Read data (legacy data in spreadsheet tables and/or sequential files).
Function Read data replaces and enhances functions Spreadsheet interface and Host interface of LSMW version 1.0. You can use any combination out of PC and server files now.
Convert data (from the source into the target format).
Import data (to the database used by the R/3 application).

TCODE - LSMW

SAP ABAP T-codes

S001 ABAP/4 Development Weorkbench.

SO01 Business Workflow

S002 System Administration.

SA38 Execute a program.

SCAT Computer Aided Test Tool

SCU0 Compare Tables

SE01 Old Transport & Corrections screen

SE03 Groups together most of the tools that you need for doing transports. In total, more than 20 tools can be reached from this one transaction.

SE09 Workbench Organizer

SE10 New Transport & Correction screen

SE11 ABAP/4 Dictionary Maintenance SE12 ABAP/4 Dictionary Display SE13 Maintain Technical Settings (Tables)

SE12 Dictionary: Initial Screen - enter object name.

SE13 Access tables in ABAP/4 Dictionary.

SE14 Utilities for Dictionary Tables

SE15 ABAP/4 Repository Information System

SE16 Data Browser: Initial Screen.

SE16N Table Browser (the N stands for New, it replaces SE16).

SE17 General Table Display

SE24 Class Builder

SE30 ABAP/4 Runtime Analysis

SE32 ABAP/4 Text Element Maintenance

SE35 ABAP/4 Dialog Modules

SE36 ABAP/4: Logical Databases

SE37 ABAP/4 Function Modules

SE38 ABAP Editor

SE39 Splitscreen Editor: Program Compare

SE41 Menu Painter

SE43 Maintain Area Menu

SE48 Show program call hierarchy. Very useful to see the overall structure of a program.

SE49 Table manipulation. Show what tables are behind a transaction code.

SE51 Screen Painter: Initial Screen.

SE54 Generate View Maintenance Module

SE61 R/3 Documentation

SE62 Industry utilities

SE63 Translation

SE64 Terminology

SE65 R/3 document. short text statistics SE66 R/3 Documentation Statistics (Test!)

SE68 Translation Administration

SE71 SAPscript layout set

SE71 SAPScript Layouts Create/Change

SE72 SAPscript styles

SE73 SAPscript font maintenance (revised)

SE74 SAPscript format conversion

SE75 SAPscript Settings

SE76 SAPscript Translation Layout Sets

SE77 SAPscript Translation Styles

SE80 ABAP/4 Development Workbench

SE81 SAP Application Hierarchy

SE82 Customer Application Hierarchy

SE83 Reuse Library. Provided by Smiho Mathew.

SE84 ABAP/4 Repository Information System

SE85 ABAP/4 Dictionary Information System

SE86 ABAP/4 Repository Information System

SE87 Data Modeler Information System

SE88 Development Coordination Info System

SE91 Maintain Messages

SE92 Maintain system log messages

SE93 Maintain Transaction.

SEARCH_SAP_MENU From the SAP Easy Access screen, type it in the command field and you will be able to search the standard SAP menu for transaction codes / keywords. It will return the nodes to follow for you.

SEU Object Browser

SHD0 Transaction variant maintenance

SM04 Overview of Users (cancel/delete sessions)

SM12 Lock table entries (unlock locked tables)

SM21 View the system log, very useful when you get a short dump. Provides much more info than short dump

SM30 Maintain Table Views.

SM31 Table Maintenance

SM32 Table maintenance

SM33 Display Table Parameter ID TAB

SM35 View Batch Input Sessions

SM37 View background jobs

SM50 Process Overview.

SM51 Delete jobs from system (BDC)

SM62 Display/Maintain events in SAP, also use function BP_EVENT_RAISE

SMEN Display the menu path to get to a transaction

SMOD Transactions for processing/editing/activating new customer enhancements.

CMOD Transactions for processing/editing/activating new customer enhancements.

SNRO Object browser for number range maintenance.

SPRO Start SAP IMG (Implementation Guide).

SQ00 ABAP/4 Query: Start Queries

SQ01 ABAP/4 Query: Maintain Queries

SQ02 ABAP/4 Query: Maintain Funct. Areas

SQ03 ABAP/4 Query: Maintain User Groups

SQ07 ABAP/4 Query: Language Comparison

ST05 Trace SQL Database Requests.

ST22 ABAP Dump analysis

SU53 Display Authorization Values for User.

WEDI EDI Menu. IDOC and EDI base.

WE02 Display an IDOC

WE07 IDOC Statistics

SAP BASIS T-Codes

SAP BASIS T-Codes

AL11 Display SAP Directories
BD54 Maintain Logical Systems
OSS1 Logon to Online Service System
SALE IMG Application Link Enabling
SARA Archive Management
SCC3 Copy Analysis Log
SCC4 Client Administration
SCC5 Client Delete
SCC7 Client Import Post-Processing
SCC8 Client Export
SCC9 Remote client copy
SCCL Local Client Copy
SCU0 Customizing Cross-System Viewer
SICK Installation Check
SM01 Lock Transactions
SM02 System Messages
SM04 User Overview
SM12 Display and Delete Locks
SM13 Display Update Records
SM14 Update Program Administration
SM21 System Log
SM35 Batch Input Monitoring
SM50 Work Process Overview
SM51 List of SAP Servers
SM56 Number Range Buffer
SM58 Asynchronous RFC Error Log
SM59 RFC Destinations (Display/Maintain)
SM66 System Wide Work Process Overview
SAINT SAP Add-on Installation Tool
SPAM SAP Patch Manager (SPAM)
SPAU Display modified DE objects
SPDD Display modified DDIC objects
ST11 Display Developer Traces
ST22 ABAP/4 Runtime Error Analysis
SU56 Analyze User Buffer

Alert Monitoring

AL01 SAP Alert Monitor
AL02 Database alert monitor
AL04 Monitor call distribution
AL05 Monitor current workload
AL16 Local Alert Monitor for Operat.Syst.
AL18 Local File System Monitor
RZ20 CCMS Monitoring

Configuration

FILE Cross-Client File Names/Paths
RZ04 Maintain Operation Modes and Instances
RZ10 Maintenance of Profile Parameters
RZ11 Profile parameter maintenance
SE93 Maintain Transaction Codes
SM63 Display/Maintain Operating Mode Sets
SPRO Customizing: Initial Screen
SWU3 Consistency check: Customizing

Database Administration

DB01 Analyze exclusive lockwaits
DB02 Analyze tables and indexes
DB12 DB Backup Monitor
DB13 DBA Planning Calendar
DB15 Data Archiving: Database Tables
Jobs

SM36 Define Background Job
SM37 Background Job Overview
SM39 Job Analysis
SM49 Execute External OS commands
SM62 Maintain Events
SM64 Release of an Event
SM65 Background Processing Analysis Tool
SM69 Maintain External OS

Monitoring

AL08 Current Active Users
OS01 LAN check with ping
RZ01 Job Scheduling Monitor
RZ03 Presentation, Control SAP Instances
ST01 System Trace
ST02 Setups/Tune Buffers
ST04 Select DB activities
ST05 Performance trace
ST06 Operating System Monitor
ST10 Table call statistics
ST03 Performance, SAP Statistics, Workload
ST07 Application monitor
STAT Local transaction statistics
STUN Performance Monitoring (not available in R/3 4.6x)

Spool

SP01 Output Controller
SP11 TemSe directory
SP12 TemSe Administration
SPAD Spool Administration

Transports

SCC1 Client Copy - Special Selections
SE01 Transport Organizer
SE06 Set Up Workbench Organizer
SE07 CTS Status Display
SE09 Workbench Organizer
SE10 Customizing Organizer
SE11 ABAP/4 Dictionary Maintenance
SE16 Data Browser
SE80 Repository Browser
SM30 Call View Maintenance
SM31 Table Maintenance
STMS Transport Management System

User Administration

PFCG Profile Generator (Activity Group Maintenance)
PFUD User Master Data Reconciliation
SU01 User Maintenance
SU01D User Display
SU02 Maintain Authorization Profiles
SU03 Maintain Authorizations
SU05 Maintain Internet users
SU10 User Mass Maintenance
SMLG Maintain Logon Group
SUPC Profiles for activity groups
SUIM Infosystem Authorizations

Other Transactions

AL22 Dependent objects display
BAOV Add-On Version Information
SA38 ABAP reporting
SE38 ABAP Editor
HIER Internal Application Component Hierarchy Maintenance
ICON Display Icons
WEDI IDoc and EDI Basis
WE02 IDoc display
WE07 IDoc statistics
WE20 Partner profiles
WE21 Port definition
WE46 IDoc administration
WE47 Status Maintenance
$TAB Refreshes the table buffers
$SYNC Refreshes all buffers, except the program buffer

SAP Implementation

Successfully Implementing SAP

Implementing a package can be a traumatic affair for both the customer and the vendor. Get it wrong and the vendor may get paid late or have to resort to lawyers to get paid and tarnish their reputation. For the company the new package may not work the way they expected, be late or cost a more than budgeted for and take management will take their eye off running their business.

Top five factors to consider would be:

1. Set up a Project Board,
2. Secure the resources,
3. Complete the GAP Analysis,
4. Have detailed Cut Over Plans,
5. Train the users.

Taking each one in turn:

The Project Board

The correct set up and operation of the Project Board in my view is major factor in the success failure of the project. The Project Board will consist of the stakeholders, key users and the vendor. The Project Board is part of the governance of the project. The Project Board will meet regularly to ensure that the project plans are created and being executed as planned, moves from stage to stage with all the deliverables being signed off is resourced properly.

The Resources

Three types of resources are absolutely necessary -- end users, change team and technicians.

Early involvement by the end users is absolutely necessary, as they will be the ones living with the system for hopefully many years to come. They will want to feel involved in its implementation. Buy in from the end users of the system is absolutely essential if the system is to have a long and stable life in any organization.

The Change Team will identify the gaps between the package and the business requirements, re-engineer some of the businesses process to cope with the package, train the users to ensure implementation is smooth as possible into the business.

The Technical Team will prepare the systems environment for the package, apply any software fixes from the vendor, implement the software in the best way possible for the organization set up and tune the software for the particular technical environment.

GAP Analysis

A through gap analysis will identify the gaps between how the business operates ad its needs against what the package can can't do. For each gap there will be one of three outcomes which must be recorded and actioned, GAP must be closed and customised software can be developed close the gap, GAP must be closed but software cannot be written therefore a workaround is required, GAP does not need to be closed.

In simple terms:

Gap means small cracks. In SAP world. In information technology, gap analysis is the study of the differences between two different information systems or applications( ex; existing system or legacy system with Client and new is SAP), often for the purpose of determining how to get from one state to a new state. A gap is sometimes spoken of as "the space between where we are and where we want to be." Gap analysis is undertaken as a means of bridging that space.
Actual gap analysis is time consuming and it plays vital role in blue print stage.

Cut Over Plans

Detailed plans need to be developed for cutting over from the old system(s) to the new. Parallel runs of what will happen over the conversion period using test data, convert and watch for a period after wards to ensure nothing unexpected happens.

Train Users

Well trained users will support and defend the system on site. Unsupportive users will continually undermine the system and eventually it will be replaced. Therefore the more effort you put into helping the users master the system early the better.

Difference between the User Exit & Gap analysis.

Both are quiet a different and has a small relation.

User exits are standard gate ways provided by SAP to exit the standard code and we can write our own code with the help of ABAP workbench. its not new functionality which we are trying to build in sap but its slight enhancement within the same code.

Gap analysis is start point of Realization and once blue print is finished we have to find the realization of sap system for client requirement and there will be certain gaps when compared to system fit. Those gaps can be closed either by re-engineering of business process to fit with SAP or we have to use USER exits in case of small deviations or complete enhancements with the help of ABAP to fit with the SAP system.

SAP LANDSCAPE

SAP LANDSCAPE:

Landscape is like a server system or like a layout of the servers or some may even call it the architecture of the servers viz. SAP is divided into three different lanscape DEV, QAS and PROD.


DEV would have multiple clients for ex: 190- Sandbox, 100- Golden, 180- Unit Test.

QAS may again have mutiple clients for ex: 300- Integration Test, 700 to 710 Training.

PROD may have something like a 200 Production.

These names and numbers are the implementer's discreet on how they want it or they have been using in their previous implementations or how is the client's business scenario.

Now whatever you do in the Sandbox doesn't affect the other servers or clients. Whenever you think you are satisfied with your configuration and you think you can use it moving forward, you RE-DO it in the golden client (remember, this is a very neat and clean client and you cannot use it for rough usage).

As you re-do everything that you had thought was important and usable, you get a transport request pop up upon saving everytime. You save it under a transport request and give your description to it. Thus the configuration is transported to the Unit Test client (180 in this example).

You don't run any transaction or even use the SAP Easy Access screen on the 100 (golden) client. This is a configuration only client. Now upon a successful tranport by the Basis guy, you have all the configuration in the Testing client, just as it is in the Golden client. The configuration remains in sync between these two clients.

But in the Testing client you can not even access SPRO (Display IMG) screen. It's a transaction only client where you perform the unit test. Upon a satisfactory unit test, you move the good configuration to the next SERVER (DEV).

The incorrect or unsatisfactory configuration is corrected in Golden (may again as well be practised in the sandbox prior to Golden) and accordingly transported back to 180 (Unit Test) until the unit test affected by that particular config is satisfactory.

The Golden client remains the 'database' (if you wanna call it that) or you may rather call it the 'ultimate' reference client for all the good, complete and final configuration that is being used in the implementation.


In summary:

Landscape : is the arrangement for the servers

IDES : is purely for education purpose and is NOT INCLUDED in the landscape.

DEVELOPMENT ---> QUALITY ----> PRODUCTION

DEVELOPMENT : is where the the consultants do the customization as per the company's requirement.

QUALITY : is where the core team members and other members test the customization.

PRODUCTION : is where the live data of the company is recorded.

A request will flow from Dev->Qual->Prod and not backwards.

1. Sandbox server:

In the initial stages of any implementation project, You are given
a sandbox server where you do all the configuration/customization as per the companies business process.

2. Development Server:

Once the BBP gets signed off, the configuration is done is development server and saved in workbench requests, to be transported to Production server.

3. Production Server:

This is the last/ most refined client where the user will work after project GO LIVE. Any changes/ new develpoment is done is development client and the request is transported to production.

These three are landscape of any Company. They organised their office in these three way. Developer develop their program in Development server and then transport it to test server. In testing server tester check/test the program and then transport it to Production Server. Later it will deploy to client from production server.

Presentaion Server- Where SAP GUI have.
Application Server - Where SAP Installed.
Database Server - Where Database installed.

What is the meaning of "R" in R/3 systems?

R/3 stands for realtime three tier architecture. This is the kind of architrecture SAP R/3 system has.

R/3 means three layers are installed in Different system/server and they are connected with each other.

1)Presentation
2)Application.
3)Data base server.

EVENTS In ABAP

Event Block

•Reporting events

INITIALIZATION
START-OF-SELECTION
GET
END-OF-SELECTION

•Selection screen events

AT SELECTION-SCREEN OUTPUT
AT SELECTION-SCREEN ON VALUE REQUEST
AT SELECTION-SCREEN ON HELP REQUEST
AT SELECTION-SCREEN ON
AT SELECTION-SCREEN ON BLOCK
AT SELECTION-SCREEN ON RADIOBUTTON GROUP
AT SELECTION SCREEN
AT SELECTION SCREEN ON END OF

•List events

TOP-OF-PAGE
END-OF-PAGE
AT LINE-SELECTION
AT PF
AT USER-COMMAND

Cross Applications (Definitions)

1 Application Link Enabling (ALE)

The ALE concept supports the construction and operation of distributed applications.
The basic principle is the guarantee of a distributed, yet fully integrated, R/3 System installation.

It incorporates the controlled exchange of business data messages whilst ensuring data consistency across loosely coupled R/3 Systems.
The integration of various applications is achieved by using synchronous and asynchronous communication, rather than by means of a central database.
ALE comprises three layers:

• the applications services,
• the distribution services,
• the communications services.

2 Transaction Data

Transaction data is data that results from daily business management processes. Examples of transaction data are purchase order data and accounting data.

3 CO-PA

Abbreviation for Controlling - Profitability Analysis.

4 EDI - Electronic Data Interchange

Electronic Data Interchange is the electronic exchange of structured data (e.g. commercial documents) that is not limited to a single company, but which may take place between business partners at home or abroad who can be using different hardware, software and communication services.

5 Filter Object

A specific instance of the filter object type to which an organizational unit has been assigned, for example, "Plant" ® "Plant 0001".

6 Filter Object Type

A filter object type is a selection criterion in the distribution reference model that specifies the criteria which determine whether a function type can be used several times in a distributed system.

7 Function

A specific instance of a function type in the customer model.

8 Function Type

A function type defines a self-contained process in an application. An example of this is the posting for a movement of goods in inventory management.

9 Function Type, Distributable

A collection of function types which may be grouped together because of the related use of the various function types, and which may be seen as being distinct from other function types.

10 IDoc

Abbreviation of intermediate document (IDoc type )

11 IDoc Type - Intermediate Document Type

An intermediate document type is the structure of the data container used for transporting data from a system to a target system. It is independent of any specific application data.

12 Logical System

A logical system is a system in which different applications are integrated and run using common data. In SAP terms, this means a client in a database.

13 Information Structures

The most important key figures are selected from the mass of data arising from operational applications and are stored in special statistics files known as information structures. These include information on the time period, the characteristics and the key figures. An information structure can be distributed.

14 Key Figures

Key figures represent information that is periodically gathered or evaluated for characteristics (for example, lead time, deviation from schedule, capacity utilization, order stocks, quantities and rejects).

15 Bulk Processing

Several IDocs may be grouped into a packet and processed in a single step. This is called bulk processing.

16 Characteristic

A characteristic is a piece of information that can be used to effect a division in a group of objects, for example, plant, work center, material).

17 Message Type

The messages exchanged between systems are of various message types. The message type depends on the data contained and the process involved. It determines the technical structure of the message, the IDoc type. For example, the ORDERS message type is used for purchase order messages.

18 Periods

Periods include days, weeks, months and accounting periods.

19 Item Category

An item category is a classification that distinguishes between various types of item in, for example, an order (e.g. cost-free items, standard items). The way that processing is controlled depends on the item category.

20 Serialization

If several IDocs are sent within a short period of time then "overtaking" can occur, so that later changes arrive sooner than changes that were actually made earlier. In order to avoid incorrect updates being made, a serialization mechanism must be used that can spot "overtaking" and report it.

21 SOP

Sales & Operations Planning.

22 Customer Distribution Model

The customer stores the exact distribution of functions across his various systems in the customer distribution model. The logical systems and message flows are specified here, possibly based on defined listings.

23 Distribution Reference Model

The reference model is included in the standard delivery from SAP. It specifies which functions can be distributed and how, and which data is exchanged between the fucntions. The customer uses the reference model as the basis for his customer distribution model .

24 Workflow

A workflow is defined as a sequence of processing steps (work item ). There may be branching points within this sequence.

A workflow has a container. This holds the parameters used in the processing steps.
In order to terminate the processing steps of a workflow, an event is triggered. The parameters are passed from the current step to the workflow container.

The workflow manager checks which processing step should be called next. For example, if an 'Idoc read' step is terminated and a parameter indicating an error is passed, a step will be started that initiates manual processing.

An error will also cause an event to be triggered If a function module has been called directly. However, in contrast to the situation with a workflow, it does not cause a workflow step to be terminated, but rather an error workflow is started.

25 Work Item

A work item represents the run-time environment for a standard task that is defined once in the system. A standard task contains a method that can be used for processing a specific object.

Complete SAP Modules:

Complete SAP Modules:
SAP Basis
• Remote Function Calls (RFC)
• Common Program Interface Communications (CPI-C)
• Electronic Data Interchange (EDI)
• Object Linking and Embedding (OLE)
• Application Link Enabling (ALE)
• Customising (BC-CUS)
• Client Server Technology (BC - CST)
• Network Integration (BC - NET)
• ABAP Programming and Runtime Environment (BC - ABA)
• Basis Services/ Communication Interfaces (BC - SRV)
• Computing Center Management System (BC - CCM)
• Upgrade General (BC - UPG)
• Change and Transport System (BC - CTS)
• Operating System Platform(BC - OP)
• Database Interface, database platforms (BC - DB)
• Front End Services (BC - FES)
• ABAP Workbench (BC - DWB)
• Documentation and Translation Tools (BC - DOC)
• Security (BC - SEC)
• Controls and Control Framework (BC - CI)
• Business Management (BC - BMT)
• Middleware (BC - MID)
• Computer Aided Test Tool (BC - CAT)
• Ready to Run R/3 (BC - BRR)
• Authorisations System Monitoring with CCMS Workload Alert Monitor
SAP Hardware
• AS400
• AT&T
• Bull
• Compaq Digital
• HP
• IBM
• Sequent
• SNI
• Sun
SAP Database
• Adabas D
• DB2 for AIX
• DB2/400
• Informix
• MS SQL
• My SQL
• Oracle
• Sybase
Operating System
• AIX
• HP UX
• MS Windows NT OS/400
• Sinux
• Solaris
• Unix

ABAP/4 Programming
• SAP Script
• Business Workflow (BC - WF)
• ALE
• EDI
• Business Connector
• Business Server Pages
• Internet Application Server
• Mercator Report Painter
• Dialog Programming
• Repository Information System
• Menu Painter
• ABAP 00
• IDOCS
• LSMW
• Smartforms
• EBP
• ASAP methodology
• ALV reporting
• Report writer
• ABAP Query
• Data Dictionary
• Screen Painter

SAP FI (Financial Accounting)
• Accounts Payable (FI- AP)
• Accounts Receivable (FI - AR)
• Asset Accounting (FI - AA)
• General Ledger Accounting (FI - GL)
• Special Ledger (FI - SL)
• Funds Management (FI - FM)
• Travel Management (FI-TM)

SAP TR (Treasury)
• Cash Management (TR - CM)
• Treasury Management (TR - TM)
• Loans Management (TR - LM)
• Funds Management (TR - FM)
• Market Risk Management (TR - MRM)
• Information System
SAP CO (Controlling)
• Cost Centre Accounting (CO - CCA)
• Overhead Cost Controlling (CO - OM)
• Activity Based Coding (CO - ABC)
• Product Cost Controlling (CO - PC)
• Profitability Analysis (CO - PA)
• Material Ledger (CO - ML)
SAP EC (Enterprise Controlling)
• Consolidation (EC - CS)
• Profit Center Accounting (EC - PCA)
• Executive Information System (EC-EIS)
• Business Planning and Budgeting
SAP IM (Investment Management)
• Investment Programmes
• Investment Measures (orders/products)
• Appropriation Requests
• Corporation Wide Budgeting
• Depreciation Forecast
• Automatic Settlement of Fixed Assets
• Information System
SAP HR (Human Resource)
• Personnel Administration
• Benefits Administration
• Compensation Management
• Recruitment
• Travel Management
• Personnel Development
• Organisational Management
• Training and Events Management
• Personnel Planning
• Time Management
• Incentive
• Wages
• Workflow
• Internet Scenarios
• Payroll
• Information System
SAP SMB
• SAP SMB
SAP BW
• Data Warehousing
• BI Platform
• BI Suite - Business Explorer
• Development Technologies
• ODS Structures
• Info Cube
• Design Build
SAP IS (Industry Solutions) / SAP for Industries
• Aerospace & Defence
• Retail
• Consumer Products
• Defence & Security
• Insurance
• Industrial Machinery & Components
• Logistics Service Providers
• Mill Products
• Higher Education & Research
• Automotive
• Banking
• Telecoms
• Chemicals
• Pharmaceuticals
• Life Sciences
• Mining
• Media
• Public Sector
• Service Provider
• Utilities
• Healthcare
• Oil & Gas
• Postal Services
SAP SD (Sales and Distribution)
• Master Data
• Sales
• Special Business Transactions
• Shipping
• Billing
• Credit Control
• Sales Support
• QM in SD
• Internet
• Transportation
• Foreign Trade
• Sales Information System
• Electronic Data Interchange
SAP Logistics Information System
• Sales Information System
• Purchasing Information System
• Inventory Controlling
• Production Planning and Control Information System
• Plant Maintenance Information System
• Project Information System
• Retail Information System
SAP QM - Quality Management
• Planning
• Inspections
• Control
• Notifications
• Certificates
• Test Equipment Management
• QM-IS
SAP MM (Materials Management)
• Logistics (General)
• Logistics Information System
• Purchasing
• Inventory Management
• Invoice Verification
• Inventory / Valuations
• Materials Planning
• Workflow
• External Services Management
• QM in MM
• Warehouse Management
SAP PM (Plant Maintenance)
• Preventative Maintenance
• Service Management
• Maintenance Order Management
• Maintenance Projects
• Equipment and Technical Objects
• Structuring Technical Systems
• Maintenance Planning
• PM Processing
• Work Clearance Management
• Internet Scenarios
• Customising
• Information System
SAP CS (Customer Service)
• Service Processing
• Service Contracts
• Controlling
• Workflow in Customer Service
SAP PP (Production Planning)
• Make to Order (CR)
• Make to Order (PIR)
• Repetitive Manufacturing
• PP for Process Industries (PP - PI)
• PP - Processes
• Sales and Operations Planning
• Master Planning
• Capacity requirements
• KANBAN
• Production Orders
• Product Cost Planning
• Assembly Orders
• Plant Data Collection
• Information System
SAP CA (Cross Application Components)
• Application Link Enabling (ALE)
• SAP Business Workflow
SAP PS (Project Systems)
• Basic Data
• Operational Structures
• Project Planning
• Approval
• Project Execution and Integration
• Information System
• Work Breakdown Structure
mySAP SRM (Supplier Relationship Management)
• Self Service Procurement
• Service Procurement
• Plan Driven Procurement
• Spend Analysis
• Strategic Sourcing
• Catalogue Content Management
mySAP SEM
• Business Consolidation (SEM-BCS)
• Business Information Collection (SEM-BIC)
• Business Planning and Simulation (BW-BPS)
• Corporate Performance Monitor (SEM-CPM)
• Stakeholder Relationship Management (SEM-SRM)
mySAP CRM (Customer Relationship Management)
• CRM Enterprise
• Field Applications
• E-Commerce
• Interaction Center
• Channel Management
• Industry Specific CRM
mySAP Product Life Cycle Management
• Document Management
• Enterprise Content Management
• Engineering Change Management
• Classification
• Basic Data for Process Manufacturing
SAP SCM (SAP Supply Chain Management)
• SCM Process and Business Scenarios
• SAP Advance Planning and Optimization (SAP - APO)
• SAP Forecasting and Replenishment
• SAP Inventory Collaboration Hub (SAP - OCH)
• SAP Event Management (SAP - EM)
• SCM Basis

SAP Netweaver
• SAP Masterdata Management
• Portal Content
• Information Integration
• Process Integration
• Life Cycle Management
• Knowledge Management
• SAP Visual Composer
• SAP Business Intelligence
• People Integration
• Application Platform
• Security
• SAP Web Application Server
• SAP Business Information Warehouse
• SAP Enterprise Portal
• SAP Solution Manager
• SAP Mobile Engine

ABAP Performance Standards

Following are the performance standards need to be following in writing ABAP programs:

1. Unused/Dead code

Avoid leaving unused code in the program. Either comment out or delete the unused situation. Use program --> check --> extended program to check for the variables, which are not used statically.

2. Subroutine Usage

For good modularization, the decision of whether or not to execute a subroutine should be made before the subroutine is called. For example:

This is better:
IF f1 NE 0.

PERFORM sub1.

ENDIF.

FORM sub1.
...
ENDFORM.

Than this:

PERFORM sub1.

FORM sub1.
IF f1 NE 0.
...
ENDIF.

ENDFORM.

3. Usage of IF statements

When coding IF tests, nest the testing conditions so that the outer conditions are those which are most likely to fail. For logical expressions with AND , place the mostly likely false first and for the OR, place the mostly likely true first.

Example - nested IF's:

IF (least likely to be true).

IF (less likely to be true).

IF (most likely to be true).
ENDIF.
ENDIF.
ENDIF.

Example - IF...ELSEIF...ENDIF :

IF (most likely to be true).

ELSEIF (less likely to be true).

ELSEIF (least likely to be true).

ENDIF.

Example - AND:

IF (least likely to be true) AND
(most likely to be true).

ENDIF.

Example - OR:

IF (most likely to be true) OR
(least likely to be true).

4. CASE vs. nested Ifs

When testing fields "equal to" something, one can use either the nested IF or the CASE statement. The CASE is better for two reasons. It is easier to read and after about five nested IFs the performance of the CASE is more efficient.

5. MOVE statements

When records a and b have the exact same structure, it is more efficient to MOVE a TO b than to MOVE-CORRESPONDING a TO b.

MOVE BSEG TO *BSEG.

is better than

MOVE-CORRESPONDING BSEG TO *BSEG.

6. SELECT and SELECT SINGLE

When using the SELECT statement, study the key and always provide as much of the left-most part of the key as possible. If the entire key can be qualified, code a SELECT SINGLE not just a SELECT. If you are only interested in the first row or there is only one row to be returned, using SELECT SINGLE can increase performance by up to three times.

7. Small internal tables vs. complete internal tables


In general it is better to minimize the number of fields declared in an internal table. While it may be convenient to declare an internal table using the LIKE command, in most cases, programs will not use all fields in the SAP standard table.

For example:

Instead of this:

data: t_mara like mara occurs 0 with header line.

Use this:

data: begin of t_mara occurs 0,

matnr like mara-matnr,
...
end of t_mara.

8. Row-level processing and SELECT SINGLE


Similar to the processing of a SELECT-ENDSELECT loop, when calling multiple SELECT-SINGLE commands on a non-buffered table (check Data Dictionary -> Technical Info), you should do the following to improve performance:

o Use the SELECT into to buffer the necessary rows in an internal table, then

o sort the rows by the key fields, then

o use a READ TABLE WITH KEY ... BINARY SEARCH in place of the SELECT SINGLE command. Note that this only make sense when the table you are buffering is not too large (this decision must be made on a case by case basis).

9. READing single records of internal tables


When reading a single record in an internal table, the READ TABLE WITH KEY is not a direct READ. This means that if the data is not sorted according to the key, the system must sequentially read the table. Therefore, you should:

o SORT the table

o use READ TABLE WITH KEY BINARY SEARCH for better performance.

10. SORTing internal tables

When SORTing internal tables, specify the fields to SORTed.

SORT ITAB BY FLD1 FLD2.

is more efficient than

SORT ITAB.

11. Number of entries in an internal table


To find out how many entries are in an internal table use DESCRIBE.

DESCRIBE TABLE ITAB LINES CNTLNS.

is more efficient than

LOOP AT ITAB.

CNTLNS = CNTLNS + 1.

ENDLOOP.

12. Performance diagnosis

To diagnose performance problems, it is recommended to use the SAP transaction SE30, ABAP/4 Runtime Analysis. The utility allows statistical analysis of transactions and programs.

13. Nested SELECTs versus table views

Since releASE 4.0, OPEN SQL allows both inner and outer table joins. A nested SELECT loop may be used to accomplish the same concept. However, the performance of nested SELECT loops is very poor in comparison to a join. Hence, to improve performance by a factor of 25x and reduce network load, you should either create a view in the data dictionary then use this view to select data, or code the select using a join.

14. If nested SELECTs must be used

As mentioned previously, performance can be dramatically improved by using views instead of nested SELECTs, however, if this is not possible, then the following example of using an internal table in a nested SELECT can also improve performance by a factor of 5x:

Use this:
form select_good.

data: t_vbak like vbak occurs 0 with header line.
data: t_vbap like vbap occurs 0 with header line.

select * from vbak into table t_vbak up to 200 rows.
select * from vbap
for all entries in t_vbak
where vbeln = t_vbak-vbeln.
...
endselect.

endform.

Instead of this:
form select_bad.

select * from vbak up to 200 rows.

select * from vbap where vbeln = vbak-vbeln.
...
endselect.

endselect.

endform.

Although using "SELECT...FOR ALL ENTRIES IN..." is generally very fast, you should be aware of the three pitfalls of using it:

Firstly, SAP automatically removes any duplicates from the rest of the retrieved records. Therefore, if you wish to ensure that no qualifying records are discarded, the field list of the inner SELECT must be designed to ensure the retrieved records will contain no duplicates (normally, this would mean including in the list of retrieved fields all of those fields that comprise that table's primary key).

Secondly, if you were able to code "SELECT ... FROM FOR ALL ENTRIES IN TABLE " and the internal table is empty, then all rows from will be retrieved.

Thirdly, if the internal table supplying the selection criteria (i.e. internal table in the example "...FOR ALL ENTRIES IN TABLE ") contains a large number of entries, performance degradation may occur.

15. SELECT * versus SELECTing individual fields

In general, use a SELECT statement specifying a list of fields instead of a SELECT * to reduce network traffic and improve performance. For tables with only a few fields the improvements may be minor, but many SAP tables contain more than 50 fields when the program needs only a few. In the latter case, the performace gains can be substantial. For example:

Use:

select vbeln auart vbtyp from table vbak

into (vbak-vbeln, vbak-auart, vbak-vbtyp)

where ...

Instead of using:

select * from vbak where ...

16. Avoid unnecessary statements

There are a few cases where one command is better than two. For example:

Use:

append to .

Instead of:

= .

append (modify ).

And also, use:

if not [] is initial.

Instead of:

describe table lines .

if > 0.

17. Copying or appending internal tables


Use this:

[] = []. (if is empty)

Instead of this:

loop at .

append to .

endloop.

However, if is not empty and should not be overwritten, then use:

append lines of [from index1] [to index2] to .

Background Job Processing

Understanding Background Job Processing

In background processing, the SAP System automatically runs any report or program in the specified time or time intervals. The background processing system starts your job and runs the program(s) that you specify. Afterwards, you can check whether your job was executed successfully and display a log of any system messages.

Features:
* Running a report in the background does not tie up the SAP sessions you are currently working with.
* You can shift the execution of reports to the evening or other periods depending on load on the SAP System.
* Background processing is the only way you can execute long-running jobs.

Background jobs run in a special type of work process—the background work process—that is different from dialog work processes in two ways:
* A dialog step has a run-time limit that prevents users from interactively running especially long reports. By default, the system terminates any dialog step in a transaction that exceeds 300 seconds. Although the limit can be changed (in the system profile parameter rdisp/max_wprun_time ), it is always in effect for dialog work processes. No such limit applies to background work processes.
* Background work processes allocate memory differently than dialog work processes so that background work processes can become as large as they need to in allocated memory to allow for processing large volumes of data.

The clients 000, 001 and 066

Understanding the clients 000, 001 and 066


Clients 000, 001 and 066 are standard clients that are pre-delivered by SAP. These clients are not supposed to be used in development, quality and production environments.

Client 000 is basically used as working client only when you do support pack upgrade or ABAP load generations (SGEN) and implementing additional languages, etc. Otherwise, client 000 should not be used as a working client. The same applies to client 001. But the only exception with 001 is, with Solution Manager, 001 will be your working client. You will do all configurations and obtain support from SAP through this client. With other Systems like BW and CRM, this client (001) will not be a working client. Two standard users (SAP* and DDIC) are defined in the clients 000 and 001.

The client 066 is used only for EarlyWatch functions (Monitoring and Performance). The user EarlyWatch is delivered in client 066 and is protected using the password SUPPORT. This password needs to be changed for security purposes.

Usefull SAP Tansactions

Usefull Tansactions List
--------------------------------------------------------------------
OSS1 SAP Online Service System
OY19 Compare Tables
S001 ABAP Development Workbench
S002 System Administration.
SA38 Execute a program.
SCAT Computer Aided Test Tool
SCU0 Compare Tables
SE01 Old Transport & Corrections screen
SE09 Workbench Organizer
SE10 Customizing Organizer
SE10 Customizing organizer – requests for user (To release for transport – enter user name, press Enter. Select changed object and select ReleaseSE10 New Transport & Correction screen
SE11 ABAP/4 Dictionary Maintenance SE12 ABAP/4 Dictionary Display SE13 Maintain Technical Settings (Tables)
SE11 ABAP/4 Dictionary.
SE12 Dictionary: Initial Screen – enter object name
SE13 Access tables in ABAP/4 Dictionary.
SE14 ABAP/4 Dictionary: Database Utility.
SE14 Utilities for Dictionary Tables
SE15 ABAP/4 Repository Information System
SE15 ABAP/4 Repository Information System.
SE16 Data Browser
SE16 Data Browser: Initial Screen.
SE16 Display table contents
SE17 General Table Display
SE30 ABAP/4 Runtime Analysis
SE30 ABAP/4 Runtime Analysis: Initial Screen.
SE30 Run Time Analysis (press Tips and Tricks button for good stuff)
SE32 ABAP/4 Text Element Maintenance
SE35 ABAP/4 Dialog Modules
SE36 ABAP/4: Logical Databases
SE37 ABAP/4 Function Library.
SE37 ABAP/4 Function Modules
SE38 ABAP Editor
SE38 ABAP/4 Editor.
SE38 ABAP/4 Program Development
SE39 Splitscreen Editor: Program Compare
SE41 Menu Painter
SE43 Maintain Area Menu
SE51 Screen Painter
SE51 Screen Painter: Initial Screen.
SE54 Generate View Maintenance Module
SE61 R/3 Documentation
SE62 Industry utilities
SE63 Translate Short/Long Text.
SE63 Translation
SE64 Terminology
SE65 R/3 documents. Short text statistics SE66 R/3 Documentation Statistics (Test!)
SE68 Translation Administration
SE71 SAPscript layout set
SE71 SAPscript Layouts Create/Change
SE72 SAPscript styles
SE73 SAPscript font maintenance (revised)
SE74 SAPscript format conversion
SE75 SAPscript Settings
SE76 SAPscript Translation Layout Sets
SE77 SAPscript Translation Styles
SE80 ABAP/4 Development Workbench
SE80 Repository Browser: Initial Screen.
SE81 SAP Application Hierarchy
SE82 Customer Application Hierarchy
SE84 ABAP/4 Repository Information System
SE85 ABAP/4 Dictionary Information System
SE86 ABAP/4 Repository Information System
SE87 Data Modeler Information System
SE88 Development Coordination Info System
SE91 Maintain Messages
SE92 Maintain system log messages
SE93 Maintain Transaction Codes
SE93 Maintain Transaction.
SEU Object Browser
SHD0 Transaction variant maintenance
SM04 Overview of Users (cancel/delete sessions)
SM04 Overview of Users.
SM12 Deletion of lock entries (in the event you have you are locked out).
SM12 Lock table entries (unlock locked tables)
SM21 View the system log, very useful when you get a short dump. Provides much more info than short dump
SM30 Maintain Table Views.
SM31 Table Maintenance
SM32 Table maintenance
SM35 View Batch Input Sessions
SM37 View background jobs
SM50 Process Overview.
SM51 Delete jobs from system (BDC)
SM62 Display/Maintain events in SAP, also use function BP_EVENT_RAISE
SMEN Display the menu path to get to a transaction
SMOD/CMOD Transactions for processing/editing/activating new customer enhancements.
SNRO Object browser for number range maintenance.
SPRO Start SAP IMG (Implementation Guide).
SQ00 ABAP/4 Query: Start Queries
SQ01 ABAP/4 Query: Maintain Queries
SQ02 ABAP/4 Query: Maintain Funct. Areas
SQ03 ABAP/4 Query: Maintain User Groups
SQ07 ABAP/4 Query: Language Comparison
ST05 Trace SQL Database Requests.
SU53 Display Authorization Values for User.

Human Resources

PA03 Change Payroll control record
PA20 Display PA Infotypes
PA30 Create/Change PA Infotypes
PP02 Quick Entry for PD object creation
PU00 Delete PA infotypes for an employee. Will not be able to delete an infotype if there is cluster data assigned to the employee.

Sales and Distribution (SD)

OLSD Config for SD. Use Tools-Data Transfer-Conditions to setup SAP supplied BDC to load pricing data
VA01 Create Sales/Returns Order Initial Screen
VB21 Transaction for Volume Lease Purchases (done as a sales deal)
VK15 Transaction used to enter multiple sales conditions (most will be entered here)
VL02 Deliveries

SAP Office

SO00 send a note through SAP, can be sent to Internet, X400, etc

Financial Accounting (FI)

FGRP Report Writer screen
FM12 View blocked documents by user
FST2 Insert language specific name for G/L account.
FST3 Display G/L account name.
KEA0 Maintain operating concern.
KEKE Activate CO-PA.
KEKK Assign operating concern.
KL04 Delete activity type.
KS04 Delete a cost centre.
KSH2 Change cost centre group – delete.
OBR2 Deletion program for customers, vendors, G/L accounts.
OKC5 Cost element/cost element group deletion.
OKE1 Delete transaction data.
OKE2 Delete a profit centre.
OKI1 Determine Activity Number: Activity Types (Assignment of material number/service to activity type)
OMZ1 Definition of partner roles.
OMZ2 Language dependent key reassignment for partner roles.

Material Management (MM)

MM06 Flag material for deletion.
OLMS materials management configuration menu, most of the stuff under this menu is not under the implementation guide


MM configuration transactions

OLMB Inventory management/Physical Inventory
OLMD MM Consumption-Based Planning
OLME MM Purchasing
OLML Warehouse Management
OLMR Invoice Verification
OLMS Material Master data
OLMW MM Valuation/Account Assignment

Configuration related

OLE OLE demo transaction
OLI0 C Plant Maintenance Master Data
OLI1 Set Up INVCO for Material Movements
OLI8 Set Up SIS for Deliveries
OLIA C Maintenance Processing
OLIP C Plant Maintenance Planning
OLIQ New set-up of QM info system
OLIX Set Up Copying/Deleting of Versions
OLIY Set Up Deletion of SIS/Inter.Storage
OLIZ Stat Set Up INVCO: Invoice Verify
OLM2 Customizing: Volume-Based Rebates
OLMB C RM-MAT Inventory Management Menu
OLMD C RM-MAT MRP Menu
OLME C MM Menu: Purchasing
OLML C MM Menu for Warehouse Management
OLMR C RM-MAT Menu: Invoice Verification
OLMS C RM-MAT Master Data Menu
OLMW C RM-MAT Valuation/Acct. Asset. Menu
OLPA SOP Configuration
OLPE Sales order value
OLPF SPRO Start SAP IMG (Implementation Guide).
OLPK Customizing for capacity planning
OLPR Project System Options
OLPS Customiing Basic Data
OLPV Customizing: Std. Value Calculation
OLQB C QM QM in Procurement
OLQI Analysis OLVD C SD Shipping Menu
OLVF C SD Billing Menu
OLQM Customizing QM Quality Notifications
OLQS C QM Menu Basic Data
OLQW C QM Inspection Management
OLQZ Quality Certificates
OLS1 Customizing for Rebates
OLSD Customizing: SD
OLVA C SD Sales Menu
OLVS C SD Menu for Master Data

Open SQL vs Native SQL

What is Open SQL vs Native SQL?

If you write a business application, there is always a database on back end. So SAP R/3 uses a database too. It is a special database? No. SAP uses standard databases like Oracle, IBM DB2, MS SQL Server, etc. If you have a database on back end, it is inevitable that you must use SQL. SAP uses SQL to select, insert and update data inside database. However, the problem is that if you use different databases, your code whatever it is whether ABAP or not, SQL can vary. In that situation although programmers tend to use Standard SQL which is valid for all databases, the problems sometimes occur to switch one database to different database. What I am trying to say is SAP had invented a new way to solve this problem i.e. Open SQL.

Open SQL

Open SQL consists of a set of ABAP statements that perform operation on central database in the R/3 System. The results of the operations and any error messages are independent of the database system in use. Open SQL thus provides a uniform syntax and semantics for all of database systems supported by SAP. ABAP programs that only use Open SQL statements will work in any SAP R/3 System, regardless of the database system in use. Open SQL statements can work with database tables that have been created in the ABAP Dictionary.
The method actually is simple that when a programmer writes an ABAP program with Open SQL statements, the kernel SAP programs convert Open SQL statements to real / native SQL statements for database in use. So like that write once, run for all databases and even for all operating systems. Like Java’s “Write Once. Run Anywhere“. Think about Java, even the Java uses the same principal that is Java Virtual Machine which looks like SAP’s kernel programs.

Open SQL contains the following keywords:
• SELECT - Reads data from database tables.
• INSERT - Adds lines to database tables.
• UPDATE - Changes the contents of lines of database tables.
• MODIFY - Inserts lines into database tables or changes the contents of existing lines.
• DELETE - Delete lines from database tables.
• OPEN CURSOR, FETCH, CLOSE CURSOR - Reads lines of database tables using the cursor.

All Open SQL statements fill the following two system fields with return codes:

• SY-SUBRC
After every Open SQL statement, the system field SY-SUBRC contains 0 if the operation was successful, a value other than 0 if not.

• SY-DBCNT
After an OPEN SQL statement, the system field SY-DBCNT contains the number of database lines processed.

Native SQL

Native SQL is real SQL for database in use. It means beside OPEN SQL, if you need you can use the native SQL for databases. 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, and therefore integrate data that is not part of the R/3 System.

As a rule, an ABAP program containing database-specific SQL statements will not run under different database systems. If your program will be used on more than one database platform, only use Open SQL statements.

All ABAP programs in SAP R/3 System have been written with Open SQL. But sometimes you can see Native SQL statements in original ABAP programs. If you have a different database instant in the same database, you can use Native SQL statement to connect and do operation on this database instant. Let me clarify this a little bit. Let’s assume you have an SAP R/3 system that uses Oracle database instant ORC1. You have an other application, even it uses the same database Oracle, but as normally different database instant ORC2. So like data inside ABAP program, you can use Native SQL statements to connect ORC2, non-SAP database instant, to integrate SAP R/3 and non-SAP system. It is kind of an integration activity.

If you create a table by using database tools, without ABAP Dictionary, you are not able to use Open SQL to reach this table. You just can use Native SQL to do that.
Native SQL statements bypass the R/3 database interface. There is no table logging, and no synchronization with the database buffer on the application server. For this reason, you should, wherever possible, use Open SQL to change database tables declared in the ABAP Dictionary. In particular, tables declared in the ABAP Dictionary that contain log columns with types LCHR and LRAW should only be addressed using Open SQL, since the columns contain extra, database-specific length information for the column. Native SQL does not take this information into account, and may therefore produce incorrect results. Furthermore, Native SQL does not support automatic client handling. Instead, you must treat client fields like any other.
To ensure that transactions in the R/3 System are consistent, you should not use any transaction control statements (COMMIT, ROLLBACK WORK), or any statements that set transaction parameters (isolation level…) using Native SQL.

Using Native SQL, you can
• Transfer values from ABAP fields to the database
• Read data from the database and process it in ABAP programs.
Native SQL works without the administrative data about database tables stored in the ABAP Dictionary. Consequently, it cannot perform all of the consistency check used in Open SQL. This places a larger degree responsibility on application developers to work with ABAP fields of the correct type. You should always ensure that the ABAP data type and the type of database column are identical.

Native SQL Advantages and Disadvantages - EXEC SQL statement

Advantages
• Tables are not declared in ABAP Dictionary can be accessed. (e.g. Tables belonging to sys or system user of Oracle, etc.)
• To use some of the special features supported by the database-specific SQL. (e.g. Passing hints to Oracle optimizer.)

Disadvantages
• No syntax check is performed whatever is written between EXEC and ENDEXEC.
• ABAP program containing database-specific SQL statements will not run under different database systems.
• There is no automatic client handling for client dependent tables.
• Care has to be taken during migration to higher versions.