SAP Champs..

BASIS DAILY ACTIVITIES

2009-11-17T20:52:00.000-08:00

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?

2009-09-13T11:30:00.000-07:00

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

2009-09-11T10:15:00.000-07:00

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

2009-07-29T20:29:00.000-07:00

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

2009-07-21T00:02:00.000-07:00

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

2009-06-20T08:44:00.000-07:00

SAP n Data Migration

2009-06-20T08:39:00.000-07:00

SAP Business process

2009-06-20T08:34:00.000-07:00

BDC Interview Questions

2009-06-20T08:15:00.000-07:00

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

2009-06-19T09:18:00.000-07:00

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

2009-06-19T08:54:00.000-07:00

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

2009-05-11T02:09:00.000-07:00

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

2009-05-11T02:06:00.000-07:00

EVENTS In ABAP

2009-05-09T10:33:00.000-07:00

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)

2009-05-07T23:44:00.000-07:00

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:

2009-05-07T23:12:00.000-07:00

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

2009-05-02T22:05:00.000-07:00

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

2009-05-02T21:57:00.000-07:00

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

2009-05-02T21:49:00.000-07:00

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

2009-04-29T10:34:00.000-07:00

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

2009-04-29T10:15:00.000-07:00

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.

SAP Production Support

2009-04-29T09:42:00.000-07:00

What is SAP Production Support - Ticket Resolving

What are the types of ticket and its importance?

This depends on the SLA. It can be like:
1. Critical.
2. Urgent.
3. High.
4. Medium
5. Low.
The response times and resolution times again are defined in the SLA based on the clients requirement and the charges.
This is probably from the viewpoint of Criticality of the problem faced by the client as defined by SAP.

1) First Level Ticketing:
Not severe problem. Routine errors. Mostly handled by Service desk arrangement of the company (if have one).
Eg: a) Say Credit limit block in working on certain documents?
b) Pricing Condition Record not found even though conditions are maintained?
c) Unable to print a delivery document or Packing list?
PS: In the 4th phase of ASAP Implementation Methodology( i.e Final Preparations for GO-LIVE) SAP has clearly specified that a Service desk needs to be arranged for any sort of Implementation for better handling of Production errors.
Service desk lies with in the client.

2)Second Level Ticketing:
Some sort of serious problems. Those Could not be solved by Service Desk. Should be referred to the Service Company (or may be company as prescribed in SLA).
Eg: a) Credit Exposure (especially open values) doesn't update perfectly to KNKK Table.
b) Inter company Billing is taking a wrong value of the Bill.
c) Need a new order type to handle reservation process
d) New product has been added to our selling range. Need to include this into SAP. (Material Masters, Division attachments, Stock Handling etc.)

3)Third Level Ticketing:
Problems could not be solved by both of the above, are referred to Online Service Support (OSS) of SAP Itself. SAP tries to solve the Problem, sometimes by providing the perfect OSS Notes, fits to the error and rarely SAP logs into our Servers (via remote log-on)for postmortem the problem. (The Medical check-up client, connections, Login id and Passwords stuff are to be provided to SAP whenever they need or at the time of opening OSS Message.)
There are lots of OSS Notes on each issue, SAP Top Notes and Notes explaining about the process of raising a OSS Message.
Sometimes SAP Charges to the client / Service company depending on the Agreement made at the time of buying License from SAP.
Eg: 1) Business Transaction for the Currency 'EUR' is not possible. Check OSS Note - This comes at the time of making Billing.
2) Transaction MMPI- Periods cannot be opened – See OSS Note.
There are many other examples on the issue.

4)Fourth Level Ticketing:
Where rarely, problems reach this level.
Those problem needs may be re-engineering of the business process due to change in the Business strategy. Upgradation to new Version. More or less this leads to extinction of the SAP Implementation.

Client-Server Architecture..

2009-04-26T22:52:00.000-07:00

Enterprise Structure Terminology

2009-04-26T21:50:00.000-07:00

How to Lock user in SAP..

2009-04-14T08:49:00.000-07:00

How to Lock user in SAP?
Go to SU01

Enter the userID to be locked in the user field and click on lock button Then you will see the the following screen if the user is already locked.

click on the unlock button at the bottom left of the window and the user will be unlocked.to lock a user again enter the user id in the user field and click on lock button and you will see the following screen now press on the lock button to lock the user...you can also lock the user at database level. login to the system database.. then run a query to update the USR02 table.

To lock an user.
SQL> UPDATE USR02 SET UFLAG = '64' where BNAME='USERID' AND MANDT='CLIENT'
SQL> COMMIT
To unlock an user
SQL> UPDATE USR02 SET UFLAG = '0' where BNAME='USERID' AND MANDT='CLIENT'
SQL> COMMIT
Here the different values of uflag have different meaning UFLAG value
0 ------ Not locked
16 ------ Mystery values
32 ------ Locked by CUA admin
64 ------ Locked by system Administrator
128 ------ Locked due to incorrect logon attempts or too many failed attempts
192 ------ A combination of both. The user is locked by admin and user tries to logon with incorrect passwords and gets locked ( 192 = 64+128)

SAP- Handling Errors... 1.

2009-04-09T01:08:00.000-07:00

1. Cannot activate a table in SAP
Syntax error in SDCC, table inconsistency between ABAP Dictionary and the database, transport error 8 during the generation of ABAP Dictionary. When you call Transaction SDCC, a termination occurs due to a putative syntax error because a table is not known or active. When you check this with the ABAP dictionary (SE11), you notice, that the table is active or inactive, however it is not possible to activate it. The activation might terminate with the error message 'Inconsistency between ABAP Dictionary and database'. A check of the affected object also delivers this error.
Solution
Proceed as follows:
• Log on as user DDIC
• Call Transaction SE14
• Enter the affected table name and
• select EDIT
• In the following screen, choose Table -> Reconstruct
• Confirm the execution
• Call Transaction SE11
• Enter the affected table name
• Display
• Activate
If - after you chose EDIT -, the error message occurs that the table only exists on the database, you need to activate the source and the runtime object.
• Call Transaction SE37:
-> Function module 'DD_TABL_ACTM' -> Single test
• Under import parameter MODE, enter the number 12 and under TABNAME the corresponding table name
• -> Execute (F8) -> Export parameter ACT_RESULT must be 0
• Call Transaction SE14 again as described above.
• -> Extras -> Database object -> Check,
as well as
-> Extras -> Runtime object -> Check
inconsistencies should no longer be contained.
If you cannot switch to the EDIT mode in Transaction SE14, which means no modifications are allowed in the customer system, then proceed as follows:
• Call function module 'DD_TABL_ACTM' as described above.
• Then call Transaction SE14 again and verify that the table has been activated.
• As a result, this ensures that the SDCC can be executed.
• The menu options in Transaction SE14 are
-> Extras -> Database object -> Check,
as well as
-> Extras -> Runtime object -> Check
inconsistencies should no longer be contained.
• If this is not the case, open a CSN message under the BC-DWB-DIC-ED component.

Some Important ALV Function modules

2009-02-18T06:57:00.000-08:00

REUSE_ALV_LIST_DISPLAY
REUSE_ALV_GRID_DISPLAY
REUSE_ALV_BLOCK_LIST_APPEND
REUSE_ALV_BLOCK_LIST_DATA_GET
REUSE_ALV_BLOCK_LIST_DATA_SET
REUSE_ALV_BLOCK_LIST_DISPLAY
REUSE_ALV_BLOCK_LIST_HS_APPEND
REUSE_ALV_BLOCK_LIST_INIT
REUSE_ALV_BLOCK_LIST_REFRESH
REUSE_ALV_BLOCK_STATUS_GET
REUSE_ALV_CHECKBOX_SET
REUSE_ALV_COMMENTARY_WRITE
REUSE_ALV_EVENTS_GET
REUSE_ALV_EVENTS_TRANSFER
REUSE_ALV_EVENT_NAMES_GET
REUSE_ALV_FIELDCATALOG_MERGE
REUSE_ALV_HIERSEQ_LIST_DISPLAY
REUSE_ALV_HS_LIST_WIDTH_GET
REUSE_ALV_HS_TABLES_GET
REUSE_ALV_LIST_DISPLAY
REUSE_ALV_LIST_LAYOUT_INFO_GET
REUSE_ALV_LIST_LAYOUT_INFO_SET
REUSE_ALV_LIST_WIDTH_GET
REUSE_ALV_POPUP_TO_SELECT
REUSE_ALV_TABLES_GET
REUSE_ALV_TABLE_CREATE

2008-09-20T02:02:00.000-07:00

Internal table

2008-09-20T01:08:00.000-07:00

Purpose of Internal Tables

• In ABAP/4, you work mainly with tables. Tables are the essential data structures in the R/3 System. Long-life data is stored in relational database tables.

• Besides database tables, you can create internal tables which exist only during the runtime of your program. ABAP/4 provides various operations for working with internal tables. You can, for example, search for, append, insert, or delete lines.

• The number of lines in an internal table is not fixed. Depending on requirements, the system increases the size of internal tables at runtime.

• You can use internal tables to perform table calculations on subsets of database tables. For example, you can read a certain part of a database table into an internal table (see Reading Data into an Internal Table).

From the internal table, you can then calculate totals or generate a ranked list.

• Another use for internal tables is reorganizing the contents of database tables according to the needs of your program. For example, you can read data relevant for creating a telephone list from one or several large customer tables into an internal table. During the runtime of your program, you can then access this list directly without having to perform a time-consuming database query for each call.

Structure of Internal Tables

In ABAP/4, you can distinguish between internal table data types, which define the structure of internal tables, and internal table data objects, which are the actual internal tables and can be filled with data. An internal table data type is an abstract definition of a data structure which can be used to declare data objects as internal tables.

Data type

An internal table is one of the two structured data types in ABAP/4. The other structured data type is the field string. An internal table consists of any number of lines which all have the same data type. The data type of the lines can be elementary or structured.

This definition opens a variety of internal table structures which range from lines consisting of one field to lines consisting of field strings which have internal tables as components.

You can define a data type as an internal table by using the TYPES statement with the OCCURS parameter. No memory is occupied when defining a data type.

Data object

A data object which has a data type defined as an internal table is the actual internal table you work with. It occupies memory and you can fill or read its lines.
You create a data object as an internal table by using the DATA statement either with the OCCURS parameter or by referring to another internal table by using the TYPE or LIKE parameters.

Identifying Table Lines

In order to access a certain line of a table, you must specify a field or combination of fields that can be used to identify the line. In the relational data model which is used to store long-life data in the R/3 System, the minimum combination required for this purpose is known as the key. The fields that define the key are called key fields.

Internal Table Index

The index is the sequential number of a table line. It is not a table field, but is created and managed automatically by the system.

You can use the index with the DELETE, INSERT, MODIFY, LOOP, and READ statements. In these statements, you can specify the index either as literal or as variable.
After processing a particular line of an internal table, the system field SY-TABIX generally contains the index of that line.

Internal Table Key

There are two kinds of internal table keys.

Self-defined Key

When reading lines from an internal table using the READ statement, you can specify a self-defined.

Standard Key

By definition, the key fields of an internal table are those fields which are not numeric (type F, I, and P) and are not internal tables. These key fields form the standard key of an internal table.

To obtain the standard key of an internal tables with nested structures (table lines which contain field strings as components), the system breaks down the sub-structures to the level of elementary fields.

LUW - Logical Unit of Work

2008-09-20T01:06:00.000-07:00

An SAP logical unit of work (LUW) is a functionally complete set of steps within a business process in the R/3 System.

The process steps must be logically related.

SAP LUWs work on an all-or-nothing principle: Either all or none of its steps are carried out.

The business process to be mapped must be basic. For example, you would not have a single SAP LUW consisting of all of the steps between a customer processing an order and an invoice being produced. Instead, you would split this up into separate parts, each of which would then be represented in the R/3 System by its own LUW. What constitutes an "elementary" process depends on the overall process and how you have modeled it.

For further information, see the ABAP Editor Keyword documentation for the term transaction processing.

A database logical unit of work (LUW) is a non-separable sequence of database operations. At the beginning and end of the LUW, the database is in a consistent state.

The database LUW is either fully carried out by the database system, or is not carried out at all.

A database LUW is opened with every dialog step and by a database commit of the previous DB LUW.

The database LUW is closed with a database commit. It is only in the commit that the data is written to the database (after which it can no longer be reversed). Before the database commit, you can undo the changes using a database rollback. Here, the database is reset to the status that it had before the first change was made to the current DB LUW.

Data that has been written to the database permanently with a database commit cannot be rolled back.

Database LUWs allow you to encapsulate logically related actions from a business process. For example, when transferring sums of money in financial accounting, you must deduct an amount from one account and then add it to another account. Before and after the process, the data is consistent, but in between the two steps, it can be inconsistent.

For further information, see the ABAP Editor Keyword documentation for the term transaction processing.

The SAP R/3 System is based on the three-tier architecture of a client/server system. The three tiers are the database, application, and presentation server layers.

This architecture, along with the distribution of users' requests (user dispatching), leads to a highly efficient, cost-effective multi-user system.

The three-tier architecture means that a large number of users with low-cost desktop computers (with low performance) can be mapped to a small number of high-performance (and considerably more expensive) work processes on application servers. Each work process on an application server is assigned a work process on a high-performance database server.

Distributing user requests to work processes assigns individual clients at presentation server level to a work process for a particular period. In turn, the work process uses another work process in the database. After the work process has processed the user input in a dialog step, the user, along with the program context, is removed from the work process, which can then be used by another user.

The three-tier architecture is far more scalable than a "fat" client architecture, in which the Presentation and application levels run on one server. With three-tier architecture, the number of database users is considerably lower than the number of users active in the system. This has a positive effect on the behavior of the database.

The three-tier architecture of the R/3 System has certain consequences for process handling. When a work process is released for use by another user (client), an implicit database commit is triggered for the database process assigned to it (via a basis program).

Work processes on the application server and database are released before each user dialog. This Ensures that long user dialogs in which the system is "only displaying a screen" are not included in Database LUWs. The duration of the user interaction will be longer than the DB LUW duration.

Shorter database LUWs lead to less load on the database.

Implicit commits on the database are triggered whenever the work process has to wait. This includes:

When the system sends a new screen
When the system sends a dialog message
When you make a synchronous remote function call (RFC)
When you use the CALL TRANSACTION or SUBMIT statement.

Using an SAP LUW to represent a business process chain usually involves user dialogs as well as the changes to the database. The aim of an R/3 transaction is to represent the information exchanged in the SAP LUW as an indivisible unit in the database. This means that an SAP LUW can only use a single database LUW.

Since SAP LUWs usually involve several database LUWs, you need to bundle the database changes in a single database LUW within your transaction.

Few Technical definations..

2008-09-20T00:58:00.000-07:00

SAP LOCK CONCEPT

2008-09-19T23:18:00.000-07:00

SAP LOCK CONCEPT:

If several users are competing to access the same resource or resources, you need to find a way of synchronizing the access in order to protect the consistency of your data.

Example: In a flight booking system, you would need to check whether seats were still free before making a reservation. You also need a guarantee that critical data (the number of free seats in this case) cannot be changed while you are working with the program.

Locks are a way of coordinating competing accesses to a resource. Each user requests a lock before accessing critical data.

It is important to release the lock as soon as possible, so as not to hinder other users unnecessarily.

Whenever you make direct changes to data on the database in a transaction, the database system sets corresponding locks.

The database management system (DBMS) physically locks the table entries that you want to change (INSERT; UPDATE, MODIFY), and those that you read from the database and intend to change (SELECT SINGLE FROM FOR UPDATE). Other users who want to access the locked record or records must wait until the physical lock has been released. In such a case, the ABAP program waits until the lock has been released again.

At the end of the database transaction, the database releases all of the locks that it has set during the transaction.

In the R/3 System, this means that each database lock is released when a new screen is displayed, since a change of screen triggers an implicit database commits.

To keep a lock set through a series of screens (from the dialog program to the update program), the R/3 System has a global lock table at the application server level, which you can use to set logical locks for table entries.

One application server contains this lock table and a special enqueue work process, which administers all requests for logical locks in the R/3 System. All logical lock requests of the R/3 System run using this work process.

You can also use logical locks to "lock" table entries that do not yet exist on the database (inserting new lines). You cannot do this with physical database locks.

For further information, see the ABAP Editor Keyword documentation for the term Locking.
Logical locks are generated when an entry is written in the lock table. You use function modules to do this.

You can only set a lock if the relevant table entry is not already locked.

The SAP transaction receives information on the success of a lock request from a return code sent via the EXCEPTION interface of the function module. In other words, the control is returned to the program using the function module. The ABAP program does not need to wait.

The SAP transaction can react appropriately by analyzing the return code.

Another user cannot gain access to work with the same table entries that are already locked.

Depending on the bundling technique in use for database updates), the program must delete the lock entries it generated using a lock module, or have them deleted indirectly (see unit Organizing Database Updates).

If the user terminates the program that generated the lock entries (usually a dialog program), the locks are released automatically (implicitly). You can do this by entering /n in the command field, or with the statements LEAVE PROGRAM, LEAVE TO TRANSACTION, and 'A' or 'X'
Messages.

When you call an ENQUEUE function module, the dialog program tries to generate a lock entry.

The export parameters identify the table entry (or entries) that you want to lock.

The program that generates the locks (usually dialog program) analyzes the return code for lock requests and reacts accordingly.

If the lock could not be set; you should normally output an error message.

At the end of the dialog program, you can use the corresponding DEQUEUE function module to delete the entries from the lock table.

DEQUEUE function modules have no exceptions. If you try to release an entry that is not locked, this has no effect.

If you want to release all of the locks that you have set, at the end of your dialog program, you can use the function module DEQUEUE_ALL.

The lock table contains the lock arguments for each table (for lock arguments, see the following slide).

To display the lock table, use transaction SM12.

The entries in the lock table are standard. Locks are always set using the values of the key fields in a table. These form the lock argument.

You pass the values for the lock argument to the lock modules via their interface (function module IMPORT parameters).

If you fail to set any of these parameters, the system interprets it generically, that is, the lock is set for all table lines that meet the criteria specified in the other parameters. The client parameter is an exception to this rule, where the default client SY-MANDT applies.

Lock entries must be assigned to a lock mode.

There are three different lock modes:

Mode 'E' for write locks: This is set if you want to write data to the database (change, create, or delete).

Mode 'S' for read locks: This is set if you want to ensure that the data, which you are reading from the database in your program, is not changed by other users while the program is running. You do not want to change the data itself in your program.

Mode 'X' for write locks: Like mode 'E', mode 'X' is used for writing data to the database. The technical difference between mode 'X' and mode 'E' is that locks of mode 'X' are not accumulated while a program is being executed. (For further details, see the following pages).

If someone tries to lock the same data record again with a second program (different user), the various lock modes take effect as follows:

Write locks ('E' or 'X') mean that any lock attempts from other users are refused, irrespective of the mode in which the lock is attempted.

If a data record is locked in mode 'S' (shared), further locks in mode 'S' may be set by other users.

Lock attempts in other lock modes ('E' or 'X') are refused.

If you want to try to lock a data record more than once while a program is running (for example using a function module that you call up, which sets locks itself), the lock system reacts in the following way:

Mode 'E' write locks are not refused. Instead, a cumulative counter is incremented. The same applies to read locks (mode 'S').

If a data record is locked in mode 'E', a lock request generates a second lock, which is marked as a read lock.

If a data record is locked in mode 'S' and no further read locks are set by other users, a lock attempt in mode 'E' is possible. This generates a second entry in the lock table (for mode 'E').

If a data record is locked in mode 'X', all further lock requests are refused.

If you want to ensure that you are reading up-to-date data in your program (with the intention of changing and returning this to the database), you should use the following procedure for lock requests and database accesses in your program:

First, lock the data that you want to edit.

Then read the current data from the database.

In the next step, process (change) the data in your program and write this to the database.

In the final step, release the locks that you set at the beginning.

This procedure ensures that your changes run fully with lock protection and that you only read data that has been changed consistently by other programs (provided that these also use the SAP lock concept and follow the procedure described here).

Lock modules are created for lock objects and not tables.

Lock objects are maintained in the dictionary. Customer lock objects must begin with "EY" or "EZ".

A lock object is a logical object composed of a list of tables that are linked by foreign key
Relationships. Lock modules are generated for these objects and enable common lock entries to be set for all tables contained in the lock object. This allows combinations of table entries to be locked.

Example: A lock object that contains the tables SFLIGHT and SBOOK enables a flight with its bookings to be locked.

The list of tables for a lock object consists of a primary table. Further table entries are referred to as secondary tables. Only tables with foreign key relationships to the primary table can be used as secondary tables.

With lock objects, you can assign different names for the parameters that describe the fields of the lock arguments for the lock modules. The names of the table fields (key fields of the tables) are proposed by the system.

You can specify the lock mode (a write lock 'E' or 'X' or a read lock 'S') for each table. These function as default values for the lock modules.

After you have assigned tables and default lock modes, lock objects must be generated.

When you activate a lock object, the system generates an ENQUEUE and a DEQUEUE function module.

These have the names ENQUEUE_ and DEQUEUE_ respectively.

If you want to ensure that you are reading current data in your program (with the intention of changing and returning this to the database), you should use the following procedure in your program for lock requests and database accesses:

1. Lock the data that you want to edit.
2. Read the current data from the database.
3. Process (change) the data in your program and write this to the database.
4. Release the locks that you set at the beginning.

This procedure ensures that your changes run fully with lock protection and that you only read data, which has been changed consistently by other programs (with the restriction that these are also using the SAP lock concept and following the procedure described).

If you change the order of the four steps to Read -> Lock -> Change -> Unlock, you run the risk that the data read by your program will not be up to date. Your program can read data before another user's program writes changes to the database. This means that a user of your program will make decisions for entries that are not based on up-to-date data from the database. For this reason, you should always follow the recommended procedure.

Requesting a lock from a program is a communication step with lock administration. The
Communication step requires a certain time interval. If your program sets locks for several objects, this interval occurs more than once.

By using so-called local lock containers, you can reduce these communication intervals with lock administration. To do so, collect the required lock requests of your program and send them together to lock administration.

The locks (delayed execution) can be collected when the lock modules are called. For this purpose, qualify the IMPORT parameter_collect with 'X'. The data transferred via the lock module interface is then registered in a list (lock container) as a lock request that needs to be executed.

The lock container can be terminated using the FLUSH_ENQUEUE function module and sent to lock administration.

When the lock orders of a lock container can be executed, the lock container is deleted.

If one of the locks in a container cannot be set, the function module FLUSH_ENQUEUE triggers the exception FOREIGN_LOCK. In this case, none of the registered lock requests is executed. The registered locks remain in the lock container.

You can delete the contents of an existing lock container with the function module
RESET_ENQUEUE.

The specified function modules have release status internally-released.

ABAP List Viewer

2008-09-19T22:50:00.000-07:00

ABAP List Viewer
The common features of report are column alignment, sorting, filtering, subtotals, totals etc. To implement these, a lot of coding and logic is to be put. To avoid that we can use a concept called ABAP List Viewer (ALV).
Using ALV, we can have three types of reports:
1. Simple Report
2. Block Report
3. Hierarchical Sequential Report
There are some function modules which will enable to produce the above reports without much effort.
All the definitions of internal tables, structures
and constants are declared in a type-pool called SLIS.
Simple Report
The important function modules are:
•Reuse_alv_list_display
•Reuse_alv_fieldcatalog_merge
•Reuse_alv_events_get
•Reuse_alv_commentary_write
•Reuse_alv_grid_display
A. REUSE_ALV_LIST_DISPLAY: This is the function module which prints the data.
The important parameters are:
1. Export:
a. I_callback_program : report id
b. I_callback_pf_status_set : routine where a user can set his own pf status or change the
functionality of the existing pf -status.
c. I_callback_user_command : routine where the function codes are handled.
d. I_structure name : name of the dictionary table
e. Is_Layout : structure to set the layout of the report
f. It_fieldcat : internal table with the list of all fields and their attributes which are to
be printed (this table can be populated automatically by the function
module REUSE_ALV_FIELDCATALOG_MERGE)
g. It_events : internal table with a list of all possible events of ALVand their
corresponding routine names.
2. Tables:
a. t_outtab : internal table with the data to be output
B. REUSE_ALV_FIELDCATALOG_MERGE:
This function module is used to populate a fieldcatalog which is essential to display the data in ALV. If the output data is from a single dictionary table and all the columns are selected, then we need not exclusively create the field catalog. Its enough to mention the table name as a parameter(I_structure_name) in the REUSE_ALV_LIST_DISPLAY. But in other cases we need to create it.
The important parameters are:
1. Export:
a. I_program_name : report id
b. I_internal_tabname : the internal output table
c. I_inclname : include or the report name where all the dynamic forms are handled.
2. Changing
ct_fieldcat : an internal table with the type SLIS_T_FIELDCAT_ALV which is declared in
the type pool SLIS.
C . REUSE_ALV_EVENTS_GET: Returns table of possible events for a a list type
1. Import:
Et_Events : The event table is returned with all possible CALLBACK events for the
specified list type (column ‘NAME’). For events to be processed by the
callback, their ‘FORM’ field must be filled. If the field is initialized, the event
is ignored. The entry can be read from the event table, the field ‘FORM’ filled
and the entry modified using constants from the type pool SLIS.
2. Export:
I_list_type:
0 = simple list
1 = hierarchical-sequential list
2 = simple block list
3 = hierarchical-sequential block list
D. REUSE_ALV_COMMENTARY_WRITE : This is used in the Top-of-page event to print the headings and other comments for the list.
1. It_list_commentary : Internal table with the headings of the type slis_t_listheader.
This internal table has three fields:
Typ : ‘H’ - header, ‘S’ - selection, ‘A’ - action
Key : only when typ is ‘S’.
Info : the text to be printed
E. REUSE_ALV_GRID_DISPLAY: A new function in 4.6 version, to display the results in grid rather than as a list.
Parameters : same as reuse_alv_list_display
HIERARCHICAL REPORTS
A. REUSE_ALV_HIERSEQ_LIST_DISPLAY
1. Export:
a. I_CALLBACK_PROGRAM
b. I_CALLBACK_PF_STATUS_SET
c. I_CALLBACK_USER_COMMAND
d. IS_LAYOUT
e. IT_FIELDCAT
f. IT_EVENTS
g. I_TABNAME_HEADER : Name of the internal table in the program containing the output data of the
highest hierarchy level.
h. I_TABNAME_ITEM : Name of the internal table in the program containing the output data of the
lowest hierarchy level.
i. IS_KEYINFO : This structure contains the header and item table field names which link the two tables
(shared key).
2. Tables
a. T_OUTTAB_HEADER : Header table with data to be output
b. T_OUTTAB_ITEM : Name of the internal table in the program containing the output data of the
lowest hierarchy level.
BLOCK REPORT
This is used to display multiple lists continuously.
The important functions used in this report are:
A. REUSE_ALV_BLOCK_LIST_INIT
B. REUSE_ALV_BLOCK_LIST_APPEND
C. REUSE_ALV_BLOCK_LIST_DISPLAY
D. REUSE_ALV_BLOCK_HS_LIST_APPEND
A. REUSE_ALV_BLOCK_LIST_INIT
Parameters:
a. I_CALLBACK_PROGRAM
b. I_CALLBACK_PF_STATUS_SET
c. I_CALLBACK_USER_COMMAND
This function module is used to set the default GUI status etc.
B. REUSE_ALV_BLOCK_LIST_APPEND
Export :
a. IS_LAYOUT : layout settings for block
b. IT_FIELDCAT : field catalog
c. I_TABNAME : Internal table name of the output data
d. IT_EVENTS : internal table name with all possible events
Tables :
a. T_OUTTAB : internal table with output data.
This function module adds the data to the block.
INTERNAL TABLES IN SLIS
Slis_t_fieldcat_alv :
This internal table contains the field attributes. This internal table can be populated automatically by using ‘REUSE_ALV_FIELDCATALOG_MERGE’.
Important Attributes:
a. col_pos : position of the column
b. fieldname : internal fieldname
c. tabname : internal table name
d. ref_fieldname : fieldname (dictionary)
e. ref_tabname : table (dictionary)
f. key(1) : column with key-color
g. icon(1) : icon
h. hotspot(1) : hotspot
i. Symbol(1) : symbol
j. Checkbox(1) : checkbox
k. just(1) : (R)ight (L)eft (C)ent
l. do_sum(1) : sum up
m. no_out(1) : (O)blig. (X)no out
n. outputlen : output length
o. seltext-l : long key word
p. seltext_m : middle key word
q. seltext_s : short key word
r. reptext_ddic : heading(ddic)
s. ddictxt(1) : (S)hort (M)iddle (L)ong
t. datatype : datatype
SLIS_T_EVENT :
Internal table for storing all the possible events of the ALV. This can be populated by the function module Reuse_alv_events_get
The columns are :
name : name of the event
form : name of the routine
SYNTAXES FOR THE ROUTINES
I_CALLBACK_PF_STATUS_SET
Syntax :
FORM set_pf_status USING rt_extab TYPE slis_t_extab
The table RT_EXTAB contains the function codes which are hidden in the standard interface.
I_CALLBACK_USER_COMMAND
Syntax :
FORM user_command USING r_ucomm LIKE sy-ucomm
rs_selfield TYPE slis_selfield.
The parameter r_ucomm contains the function code.
The structure rs_selfield has the details about the current cursor position.

Implementation Ques..

2008-08-28T09:24:00.000-07:00

1. What are the responsibilities of a functional consultant in an implementation project?
a) Responsibilities in implementation project
- Preparing the functional specification documents.
- Review and approval of functional specifications.
- Designing a road map and setting approval from client.
- Changing existing configuration whenever needed.
- Setting up configuration for new enhancements.
- Handling basic issues of MM module.
b) Responsibilities in support project
- Handling customization, configuration, and enhancement related issues
- Handling tickets on Day to Day basis
- Monitoring S&D reports on daily basis required by clients
- Preparing functional specification documents
- Preparing end user training Documents
2. What are the responsibilities of a technical consultant in an implementation project?
Preparation of technical specifications, getting approvals from functional consultant and PM, assistance to functional consultant.
3.What is ERP and SAP? and why implementing SAP in an organization? Explain the special features of SAP over other ERPs?
SAP is an ERP package. SAP can be fit it any language. It is used to get exact data with a fraction of section which will be use fully for management to take correct decision in a short span of time. Using of sap means there is no need to maintain the
middle management in the organization because the CEO of the company is able to direct the executives directly with the system. SAP is able to integrate all functional organizational units together and retrieve exact data needed by management. Therefore, investing on middle management will become less. and the user will be able to access instance reports using the logistic information systems in SAP.
4.Explain the business flow of an implementation project?
- Project preparation
- Business blue prints
- Fit gap analysis
- Realization
- Go-live
- Support
5. Explain briefly about your role in current/previous project? (If you have one)
6. Explain your functional experience prior to SAP?
7. Can you explain the modern technologies in SAP? Do you use this in your current project?
8. Explain the terms "AS IS" and "FIT GAP ANALYSIS"?
Business blue print stage is called AS-IS process. Fit gap means, before implementing the SAP all the business data is in the form of documents, we cannot keep this data as is in the SAP. There should be a gap. So by filling this gap, we make configuration with the help of these documents. This is called as fit gap analysis. In this stage, we should analysis the gap between as is and is as process.
9. What are the responsibilities of "CORE TEAM" and "FUNCTIONAL TEAM" in an implementation?
Core Team are the power users who are selected for the SAP implementation. The Functional Team gather the initial implementation requirement from these core team users who will be the bridge between the SAP Functional Team and their department users with the expert work knowledge.

Idoc - basics

2008-08-12T03:42:00.000-07:00

SAP IDOC

Basically an IDOC is formed of segments, and comprises of IDOC Type and IDOC Data. IDOC types defines the structure and format of the data being exchanged.

Typically an IDOC will have the following
• Control Record
• Data Records
• Status Records

Control Record:

Will have all the following.
• IDOC number
• IDOC TYPE
• Sender and Receiver Information
• Message Type
Please note that there is only one control record per IDOC and the structure of IDOC control record is the same for all IDOCs.

Data Record:

This basically contains the data, the header data and the line item data for a particular IDOC for example Sales Order or Purchase Order. These are multiple records.

Status Record:

This represents the different status the IDOC goes through. And a status record will have multiple statuses. A status code, Date and Time are assigned.

Modularization FAQ

2008-08-11T10:08:00.000-07:00

1. Does every ABAP/4 have a modular structure?

Yes.

2. What is Modularization and its benefits?

If the program contains the same or similar blocks of statements or it is required to process the same function several times, we can avoid redundancy by using modularization techniques. By modularizing the ABAP/4 programs we make them easy to read and improve their structure. Modularized programs are also easier to maintain and to update.

3. Name the ABAP/4 Modularization techniques.

· Source code module.

· Subroutines.

· Functions.

4. How can we create callable modules of program code within one ABAP/4 program?

· By defining Macros.

· By creating include programs in the library.

5. M is the attribute type of the module program.

6. Is it possible to pass data to and from include programs explicitly?

No. If it is required to pass data to and from modules it is required to use subroutines or function modules.

7. What are subroutines?

Subroutines are program modules, which can be called from other ABAP/4 programs or within the same program.

8. What are the types of Subroutines?

· Internal Subroutines: The source code of the internal subroutines will be in the same ABAP/4 program as the calling procedure (internal call).

· External Subroutines: The source code of the external subroutines will be in an ABAP/4 program other than the calling procedure.

9. It is not possible to create an ABAP/4 program, which contains only Subroutines (T/F).

False.

10. A subroutine can contain nested form and endform blocks. (T/F)

False.

11. Data can be passed between calling programs and the subroutines using Parameters.

12. What are the different types of parameters?

Formal Parameters: Parameters, which are defined during the definition of subroutine with the FORM statement.

Actual Parameters: Parameters which are specified during the call of a subroutine with the PERFORM statement.

13. How can one distinguish between different kinds of parameters?

· Input parameters are used to pass data to subroutines.

· Output parameters are used to pass data from subroutines.

14. What are the different methods of passing data?

· Calling by reference: During a subroutine call, only the address of the actual parameter is transferred to the formal parameters. The formal parameter has no memory of its own, and we work with the field of the calling program within the subroutine. If we change the formal parameter, the field contents in the calling program also changes.

· Calling by value: During a subroutine call, the formal parameters are created as copies of the actual parameters. The formal parameters have memory of their own. Changes to the formal parameters have no effect on the actual parameters.

· Calling by value and result: During a subroutine call, the formal parameters are created as copies of the actual parameters. The formal parameters have their own memory space. Changes to the formal parameters are copied to the actual parameters at the end of the subroutine.

15. The method by which internal tables are passed is By Reference.

16. How can an internal table with Header line and one without header line be distinguished when passed to a subroutine?

Itab [] is used in the form and endform if the internal table is passed with a header line.

17. What should be declared explicitly in the corresponding ABAP/4 Statements to access internal tables without header lines & why?

Work Area. This is required as the Work Area is the interface for transferring data to and from the table.

18. A subroutine can be terminated unconditionally using EXIT. (T/F)

True.

19. A subroutine can be terminated upon a condition using CHECK Statement.

20. Function Modules are also external Subroutines. (T/F).

True.

21. What is the difference between the function module and a normal ABAP/4 subroutine?

In contrast to normal subroutines function modules have uniquely defined interface. Declaring data as common parts is not possible for function modules. Function modules are stored in a central library.

22. What is a function group?

A function group is a collection of logically related modules that share global data with each other. All the modules in the group are included in the same main program. When an ABAP/4 program contains a CALL FUNCTION statement, the system loads the entire function group in with the program code at runtime. Every function module belongs to a function group.

23. What is the disadvantage of a call by reference?

During a call by reference damage or loss of data is not restricted to the subroutine, but will instantly lead to changes to the original data objects.

24. A function module can be called from a transaction screen outside an ABAP/4 program. (T/F).

True.

25. What is an update task?

It is an SAP provided procedure for updating a database.

26. What happens if a function module runs in an update task?

The system performs the module processing asynchronously. Instead of carrying out the call immediately, the system waits until the next database update is triggered with the ‘COMMIT WORK’ command.

27. When a function module is activated syntax checking is performed automatically. (Y/N)

True.

28. What is the use of the RAISING exception?

The raising exception determines whether the calling program will handle the exception itself or leave the exception to the system.

29. What is the difference between internal tables and extract datasets?

· The lines of an internal table always have the same structure. By using extract datasets, you can handle groups of data with different structure and get statistical figures from the grouped data.

· You have to define the structure of the internal table at the beginning. You need not define the structure of the extract dataset.

· In contrast to internal tables, the system partly compresses exact datasets when storing them. This reduces the storage space required.

· Internal tables require special work area for interface whereas extract datasets do not need a special work area for interface.

30.It is possible to assign a local data object defined in a subroutine or function module to a field group. (T/F).

False.

31. What is the difference between field-group header and other field groups?

The header field group is a special field group for the sort criteria. The system automatically prefixes any other field groups with the header field group.

33. Can a filed occur in several field groups.

Yes. But it leads to unnecessary data redundancy.

34. When sorting the extract dataset the fields used as default sort key lie in the Header field group.
35. What does the insert statement in extract datasets do?

It defines the fields of a field group.

36.What does the extract statement do in extract datasets?

The data is written to virtual memory by extract commands.

37. A field-groups statement or an insert statement reverses storage space and transfers values. (T/F).

False.

38. While using extract datasets it is required to have a special workarea for interface (T/F)

False.

39. The LOOP-ENDLOOP on extract datasets can be used without any kind of errors (T/F)

False. It causes runtime errors.

40. The Maximum no of key fields that can be used in a header is 50.
41. While sorting field groups we cannot use more than one key field (T/F).

False.

42. While sorting, if the main storage available is not enough, the system writes data to an external help file. The SAP profile parameter, which determines this help file, is DIR_SORTTMP.

43. The extract statements in field groups can be used before or after processing the sort statements. (T/F)

FALSE.

BDC Faq..

2008-08-11T10:05:00.000-07:00

1. What is full form of BDC Session?

Batch Data Communication Session.

2. 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. How do you find the information on the current screen?

The information on the current screen can be found by SYSTEM à STATUS command from any menu.

4. 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’.

5. 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’.

6. 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.

7. 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).

8. 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.

9. 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.

10. Does the BDC-INSERT function allow multiple transactions to be processed by SAP?

Yes.

11. 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.

User exits

2008-07-24T22:06:00.000-07:00

What are user exits?

What is involved in writing them? What precautions are needed?
User defined functionality included to predefined SAP standards. Point in an SAP program where a customer's own program can be called. In contrast to customer exits, user exits allow developers to access and modify program components and data objects in the standard system.

On upgrade, each user exit must be checked to ensure that it conforms to the standard system.
There are two types of user exit:
User exits that use INCLUDEs.
These are customer enhancements that are called directly in the program.
User exits that use tables.
These are used and managed using Customizing.
Should find the customer enhancements belonging to particular development class.

What are the different ways in which you can make changes to SAP standard software ?

Customizing
Enhancements to the SAP Standard
Modifications to the SAP Standard
Customer Development

What is customizing?

Customizing is the setting of system parameters via SAP's own interface.

Why do you need enhancements?

The standard applications do not offer some of the functionality you need. The R/3 enhancement concept allows you to add your own functionality to SAP's standard business applications.

What are the different types of enhancements ?

Enhancements using customer exits
Customers' potential requirements which are not included in the standard software are incorporated in the standard as empty modification 'shells'. Customers can then fill these with their own coding. Enhancements can relate to programs, menus and screens. Upward compatibility is assured.

In other words, SAP guarantees that the jump from the standard software to the exit and the interface which call the exit will remain valid in future releases.

Enhancements to ABAP/4 Dictionary elements
These are ABAP/4 Dictionary enhancements (creation of table appends), text enhancements (customer-specific key words and documentation for data elements) and field exits (creation of additional coding for data elements).

What is customer development ?
Creating customer-specific objects within the customer name range.

What is SSCR ?
SSCR (SAP Software Change Registration) is a procedure, for registering all manual changes to SAP source coding and SAP Dictionary objects.

What is the difference between modifications and enhancements ?
Modifications mean making changes to the SAP standard functionality.
Enhancements mean adding some functionality to SAP standard functionality.

What are the disadvantages of modification ?
Modifying standard code can lead to errors
Modifications mean more work during software upgrades

What are the advantages of enhancements ?
Do not affect standard SAP source code
Do not affect software upgrades

when do you opt for modification ?
Customer exits are not available for all programs and screens within the R/3 standard applications. You can only use exits if they already exist within the SAP R/3 System . Otherwise you have to opt for modifications .

What are the various types of customer exits ?
Menu exits
Screen exits
Function module exits
Keyword exits

What is a menu exit ?
Adding items to the pulldown menus in standard R/3 applications .

13.What is a screen exit ?
Adding fields to the screens within R/3 applications. SAP creates screen exits by placing special subscreen areas within a standard R/3 screen and calling a customer subscreen from within the standard dynpro's flow logic.

What is a function module exit ?
Adding functionality to R/3 applications. Function module exits play a role in both menu and screen exits.

What is a keyword exit ?
Add documentation to the data elements of key words defined in the ABAP/4 Dictionary. The system displays this documentation whenever a user presses F1 to get online help for a screen field.

How do SAP organizes its exits ?
SAP organizes its exits in packages that are called SAP enhancements. Each SAP enhancement can contain many individual exits.

What is an add-on project ?
To take advantage of the exits available within standard R/3 applications, you need to create an add-on project. This project lets you organize the enhancement packages and exits you want to use. The add-on project also allows you to hang add-on functionality onto the exit hooks contained with SAP enhancements.

Internal Table type...

2008-07-05T06:17:00.000-07:00

What Are Different Types Of Internal Tables and Their Usage

Standard Internal Tables

Standard tables have a linear index. You can access them using either the index or the key. If you use the key, the response time is in linear relationship to the number of table entries. The key of a standard table is always non-unique, and you may not include any specification for the uniqueness in the table definition.

This table type is particularly appropriate if you want to address individual table entries using the index. This is the quickest way to access table entries. To fill a standard table, append lines using the (APPEND) statement. You should read, modify and delete lines by referring to the index (INDEX option with the relevant ABAP command). The response time for accessing a standard table is in linear relation to the number of table entries. If you need to use key access, standard tables are appropriate if you can fill and process the table in separate steps. For example, you can fill a standard table by appending records and then sort it. If you then use key access with the binary search option (BINARY), the response time is in logarithmic relation to
the number of table entries.

Sorted Internal Tables

Sorted tables are always saved correctly sorted by key. They also have a linear key, and, like standard tables, you can access them using either the table index or the key. When you use the key, the response time is in logarithmic relationship 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, and you must specify either UNIQUE or NON-UNIQUE in the table definition. Standard tables and sorted tables both belong to the generic group index tables.

This table type is particularly suitable if you want the table to be sorted while you are still adding entries to it. You fill the table using the (INSERT) statement, according to the sort sequence defined in the table key. Table entries that do not fit are recognised before they are inserted. The response time for access using the key is in logarithmic relation to the number of
table entries, since the system automatically uses a binary search. Sorted tables are appropriate for partially sequential processing in a LOOP, as long as the WHERE condition contains the beginning of the table key.

Hashed Internal Tables

Hashes tables have no internal linear index. You can only access hashed tables by specifying the key. The response time is constant, regardless of the number of table entries, since the search uses a hash algorithm. The key of a hashed table must be unique, and you must specify UNIQUE in the table definition.

This table type is particularly suitable if you want mainly to use key access for table entries. You cannot access hashed tables using the index. When you use key access, the response time remains constant, regardless of the number of table entries. As with database tables, the key of a hashed table is always unique. Hashed tables are therefore a useful way of constructing and
using internal tables that are similar to database tables.

Index Tables

Index table is only used to specify the type of generic parameters in a FORM or FUNCTION. That means that you can't create a table of type INDEX.

Internal tables are not DB tables. Standard and Sorted tables in combined are basically called as Index tables and there nothing else. Here is the hierarchy

Work process...

2008-07-03T12:09:00.000-07:00

FACTS ON INCLUDE & APPEND Structures

2008-07-03T08:52:00.000-07:00

Includes

With tables and structures it is possible to include the fields of another structure as well as to list the individual fields. Individual fields and includes can be combined as required.

If an include is changed, all the tables and structures that contain this include are automatically adjusted.

Example: Structure X is included in tables A and B. If another field is inserted into structure X, this field is also inserted in tables A and B.

Includes can also be nested, i.e. structure A includes structure B, which in turn includes another structure C etc. The maximum nesting depth is limited to nine. A path of nested includes in a table or structure therefore can have at most length nine (excluding the table/structure itself).

Only flat structures can be included. In a flat structure, each field either refers to a data element or is directly assigned a data type and length by direct type entry.

Only structures can be included in a table. Both tables and structures can be included in a structure, but only one table may lie on a path of nested includes.

Example: Table TAB1 includes structure STRUKT1, which in turn includes structure STRUKT2. Only table TAB1 lies on the path of nested includes. It is also possible to include TAB1 in a further structure STRUKT0, but no other table may be included in TAB1 because in this case two tables (TAB1 and TAB2) would lie on a path of nested includes.

Append Structures

Append structures are used for enhancements which are not provided for in the standard (special developments, country versions and adding customer fields to SAP standard tables).

An append structure is assigned to exactly one table. There can however be several append structures to one table. If an append structure is created or changed, the table assigned to it (appending object) is also activated again at activation and the changes also take effect there.

An append structure permits the following enhancements to a table or structure:

Add new fields

Add foreign keys to fields of the appending object

Add search help attachments to fields of the appending object

Appending an append structure or inserting fields in an existing append structure does not lead to the conversion of the table. The fields of the append structure are appended to the database table.

Append structures are created by customers in the customer name range and are thus protected against overwriting in upgrades or release upgrades. After a release upgrade, the new versions of the standard tables are imported and fields contained in append structures are appended to the new standard tables.

Note: Append structures can only be created for transparent tables and structures. It is not possible to add fields with an append structure for transparent tables containing a long field. Furthermore, append structures may not be created for tables and structures of the central Basis of the R/3 System.

SAP Interview Questions- Basics

2008-07-03T00:25:00.000-07:00

What is ERP? - ERP is a package with the techniques and concepts for the integrated management of business as a whole, for effective use of management resources, to improve the efficiency of an enterprise. Initially, ERP was targeted for manufacturing industry mainly for planning and managing core business like production and financial market. As the growth and merits of ERP package ERP software is designed for basic process of a company from manufacturing to small shops with a target of integrating information across the company.
Different types of ERP? - SAP, BAAN, JD Edwards, Oracle Financials, Siebel, PeopleSoft. Among all the ERP’s most of the companies implemented or trying to implement SAP because of number of advantages aver other ERP packages.
What is SAP? - SAP is the name of the company founded in 1972 under the German name (Systems, Applications, and Products in Data Processing) is the leading ERP (Enterprise Resource Planning) software package.

Explain the concept of “Business Content” in SAP Business Information Warehouse? - Business Content is a pre-configured set of role and task-relevant information models based on consistent Metadata in the SAP Business Information Warehouse. Business Content provides selected roles within a company with the information they need to carry out their tasks. These information models essentially contain roles, workbooks, queries, InfoSources, InfoCubes, key figures, characteristics, update rules and extractors for SAP R/3, mySAP.com Business Applications and other selected applications.
Why do you usually choose to implement SAP? - There are number of technical reasons numbers of companies are planning to implement SAP. It’s highly configurable, highly secure data handling, min data redundancy, max data consistency, you can capitalize on economics of sales like purchasing, tight integration-cross function.
Can BW run without a SAP R/3 implementation? - Certainly. You can run BW without R/3 implementation. You can use pre-defined business content in BW using your non-SAP data. Here you simply need to map the transfer structures associated with BW data sources (InfoCubes, ODS tables) to the inbound data files or use 3rd part tool to connect your flat files and other data sources and load data in BW. Several third party ETL products such as Acta, Infomatica, DataStage and others will have been certified to load data in BW.
What is IDES? - International Demonstration and Education System. A sample application provided for faster learning and implementation.
What is WF and its importance? - Business Work Flow: Tool for automatic control and execution of cross-application processes. This involves coordinating the persons involved, the work steps required, the data, which needs to be processed (business objects). The main advantage is reduction in throughput times and the costs involved in managing business processes. Transparency and quality are enhanced by its use.
What is SAP R/3? - A third generation set of highly integrated software modules that performs common business function based on multinational leading practice. Takes care of any enterprise however diverse in operation, spread over the world. In R/3 system all the three servers like presentation, application server and database server are located at different system.
What are presentation, application and database servers in SAP R/3? - The application layer of an R/3 System is made up of the application servers and the message server. Application programs in an R/3 System are run on application servers. The application servers communicate with the presentation components, the database, and also with each other, using the message server. All the data are stored in a centralized server. This server is called database server.
What should be the approach for writing a BDC program? - Convert the legacy system data to a flat file and convert flat file into internal table. Transfer the flat file into sap system called “sap data transfer”. Call transaction(Write the program explicitly) or create sessions (sessions are created and processed ,if success data will transfer).
Explain open SQL vs native SQL? - ABAP Native SQL allows you to include database-specific SQL statements in an ABAP program. Most ABAP programs containing database-specific SQL statements do not run with different databases. If different databases are involved, use Open SQL. To execute ABAP Native SQL in an ABAP program, use the statement EXEC. Open SQL (Subset of standard SQL statements), allows you to access all database tables available in the R/3 System, regardless of the manufacturer. To avoid conflicts between database tables and to keep ABAP programs independent from the database system used, SAP has generated its own set of SQL statements known as Open SQL.
What are datasets? - The sequential files (processed on application server) are called datasets. They are used for file handling in SAP.
What are internal tables check table, value table, and transparent table? - Internal table: It is a standard data type object, which exists only during the runtime of the program. Check table: Check table will be at field level checking. Value table: Value table will be at domain level checking ex: scarr table is check table for carrid. Transparent table: - Exists with the same structure both in dictionary as well as in database exactly with the same data and fields.
What are the major benefits of reporting with BW over R/3? Would it be sufficient just to Web-enable R/3 Reports? - Performance — Heavy reporting along with regular OLTP transactions can produce a lot of load both on the R/3 and the database (cpu, memory, disks, etc). Just take a look at the load put on your system during a month end, quarter end, or year-end — now imagine that occurring even more frequently. Data analysis — BW uses a Data Warehouse and OLAP concepts for storing and analyzing data, where R/3 was designed for transaction processing. With a lot of work you can get the same analysis out of R/3 but most likely would be easier from a BW.
How can an ERP such as SAP help a business owner learn more about how business operates? - In order to use an ERP system, a
business person must understand the business processes and how they work together from one functional area to the other. This knowledge gives the student a much deeper understanding of how a business operates. Using SAP as a tool to learn about ERP systems will require that the
people understand the business processes and how they integrate.
What is the difference between OLAP and Data Mining? - OLAP - On line Analytical processing is a reporting tool configured to understand your database schema ,composition facts and dimensions . By simple point-n-clicking, a user can run any number of canned or user-designed reports without having to know anything of SQL or the schema. Because of that prior configuration, the OLAP engine “builds” and executes the appropriate SQL. Mining is to build the application to specifically look at detailed analyses, often algorithmic; even more often misappropriate called “reporting.
What is “Extended Star Schema” and how did it emerge? - The Star Schema consists of the Dimension Tables and the Fact Table. The Master Data related tables are kept in separate tables, which has reference to the characteristics in the dimension table(s). These separate tables for master data is termed as the Extended Star Schema.
Define Meta data, Master data and Transaction data - Meta Data: Data that describes the structure of data or MetaObjects is called Metadata. In other words data about data is known as Meta Data. Master Data: Master data is data that remains unchanged over a long period of time. It contains information that is always needed in the same way. Characteristics can bear master data in BW. With master data you are dealing with attributes, texts or hierarchies. Transaction data: Data relating to the day-to-day transactions is the Transaction data.
Name some drawbacks of SAP - Interfaces are huge problem, Determine where master data resides, Expensive, very complex, demands highly trained staff, lengthy implementation time.
What is Bex? - Bex stands for Business Explorer. Bex enables end user to locate reports, view reports, analyze information and can execute queries. The queries in workbook can be saved to there respective roles in the Bex browser. Bex has the following components: Bex Browser, Bex analyzer, Bex Map, Bex Web.
What are variables? - Variables are parameters of a query that are set in the parameter query definition and are not filled with values until the queries are inserted into workbooks. There are different types of variables which are used in different application: Characteristics variables, Hierarchies and hierarchy node, Texts, Formulas, Processing types, User entry/Default type, Replacment Path.
What is AWB?. What is its purpose? - AWB stands for Administrator WorkBench. AWB is a tool for controlling, monitoring and maintaining all the processes connected with data staging and processing in the business information whearhousing.
What is the significance of ODS in BIW? - An ODS Object serves to store consolidated and debugged transaction data on a document level (atomic level). It describes a consolidated dataset from one or more InfoSources. This dataset can be analyzed with a BEx Query or InfoSet Query. The data of an ODS Object can be updated with a delta update into InfoCubes and/or other ODS Objects in the same system or across systems. In contrast to multi-dimensional data storage with InfoCubes, the data in ODS Objects is stored in transparent, flat database tables.
What are the different types of source system? - SAP R/3 Source Systems, SAP BW, Flat Files and External Systems.
What is Extractor? - Extractors is a data retrieval mechanisms in the SAP source system. Which can fill the extract structure of a data source with the data from the SAP source system datasets. The extractor may be able to supply data to more fields than exist in the extract structure.

SAP ABAP interview questions

2008-07-03T00:21:00.001-07:00

What is an ABAP data dictionary?- ABAP 4 data dictionary describes the logical structures of the objects used in application development and shows how they are mapped to the underlying relational database in tables/views.
What are domains and data element?- Domains:Domain is the central object for describing the technical characteristics of an attribute of an business objects. It describes the value range of the field. Data Element: It is used to describe the semantic definition of the table fields like description the field. Data element describes how a field can be displayed to end-user.
What is foreign key relationship?- A relationship which can be defined between tables and must be explicitly defined at field level. Foreign keys are used to ensure the consistency of data. Data entered should be checked against existing data to ensure that there are now contradiction. While defining foreign key relationship cardinality has to be specified. Cardinality mentions how many dependent records or how referenced records are possible.

Describe data classes.- Master data: It is the data which is seldomly changed. Transaction data: It is the data which is often changed. Organization data: It is a customizing data which is entered in the system when the system is configured and is then rarely changed. System data:It is the data which R/3 system needs for itself.
What are indexes?- Indexes are described as a copy of a database table reduced to specific fields. This data exists in sorted form. This sorting form ease fast access to the field of the tables. In order that other fields are also read, a pointer to the associated record of the actual table are included in the index. Yhe indexes are activated along with the table and are created automatically with it in the database.
Difference between transparent tables and pooled tables.- Transparent tables: Transparent tables in the dictionary has a one-to-one relation with the table in database. Its structure corresponds to single database field. Table in the database has the same name as in the dictionary. Transparent table holds application data. Pooled tables. Pooled tables in the dictionary has a many-to-one relation with the table in database. Table in the database has the different name as in the dictionary. Pooled table are stored in table pool at the database level.
What is an ABAP/4 Query?- ABAP/4 Query is a powerful tool to generate simple reports without any coding. ABAP/4 Query can generate the following 3 simple reports: Basic List: It is the simple reports. Statistics: Reports with statistical functions like Average, Percentages. Ranked Lists: For analytical reports. - For creating a ABAP/4 Query, programmer has to create user group and a functional group. Functional group can be created using with or without logical database table. Finally, assign user group to functional group. Finally, create a query on the functional group generated.
What is BDC programming?- Transferring of large/external/legacy data into SAP system using Batch Input programming. Batch input is a automatic procedure referred to as BDC(Batch Data Communications).The central component of the transfer is a queue file which receives the data vie a batch input programs and groups associated data into “sessions”.
What are the functional modules used in sequence in BDC?- These are the 3 functional modules which are used in a sequence to perform a data transfer successfully using BDC programming: BDC_OPEN_GROUP - Parameters like Name of the client, sessions and user name are specified in this functional modules. BDC_INSERT - It is used to insert the data for one transaction into a session. BDC_CLOSE_GROUP - This is used to close the batch input session.
What are internal tables?- Internal tables are a standard data type object which exists only during the runtime of the program. They are used to perform table calculations on subsets of database tables and for re-organising the contents of database tables according to users need.
What is ITS? What are the merits of ITS?- ITS is a Internet Transaction Server. ITS forms an interface between HTTP server and R/3 system, which converts screen provided data by the R/3 system into HTML documents and vice-versa. Merits of ITS: A complete web transaction can be developed and tested in R/3 system. All transaction components, including those used by the ITS outside the R/3 system at runtime, can be stored in the R/3 system. The advantage of automatic language processing in the R/3 system can be utilized to language-dependent HTML documents at runtime.
What is DynPro?- DynPro is a Dynamic Programming which is a combination of screen and the associated flow logic Screen is also called as DynPro.
What are screen painter and menu painter?- Screen painter: Screen painter is a tool to design and maintain screen and its elements. It allows user to create GUI screens for the transactions. Attributes, layout, filed attributes and flow logic are the elements of Screen painter. Menu painter: Menu painter is a tool to design the interface components. Status, menu bars, menu lists, F-key settings, functions and titles are the components of Menu painters. Screen painter and menu painter both are the graphical interface of an ABAP/4 applications.
What are the components of SAP scripts?- SAP scripts is a word processing tool of SAP which has the following components: Standard text. It is like a standard normal documents. Layout sets. - Layout set consists of the following components: Windows and pages, Paragraph formats, Character formats. Creating forms in the R/3 system. Every layout set consists of Header, paragraph, and character string. ABAP/4 program.
What is ALV programming in ABAP? When is this grid used in ABAP?- ALV is Application List viewer. Sap provides a set of ALV (ABAP LIST VIEWER) function modules which can be put into use to embellish the output of a report. This set of ALV functions is used to enhance the readability and functionality of any report output. Cases arise in sap when the output of a report contains columns extending more than 255 characters in length. In such cases, this set of ALV functions can help choose selected columns and arrange the different columns from a report output and also save different variants for report display. This is a very efficient tool for dynamically sorting and arranging the columns from a report output. The report output can contain up to 90 columns in the display with the wide array of display options.
What are the events in ABAP/4 language?- Initialization, At selection-screen, Start-of-selection, end-of-selection, top-of-page, end-of-page, At line-selection, At user-command, At PF, Get, At New, At LAST, AT END, AT FIRST.
What is CTS and what do you know about it?- The Change and Transport System (CTS) is a tool that helps you to organize development projects in the ABAP Workbench and in Customizing, and then transport the changes between the SAP Systems and clients in your system landscape. This documentation provides you with an overview of how to manage changes with the CTS and essential information on setting up your system and client landscape and deciding on a transport strategy. Read and follow this documentation when planning your development project.
What are logical databases? What are the advantages/ dis-advantages of logical databases?- To read data from a database tables we use logical database. A logical database provides read-only access to a group of related tables to an ABAP/4 program. Advantages: i)check functions which check that user input is complete, correct,and plausible. ii)Meaningful data selection. iii)central authorization checks for database accesses. iv)good read access performance while retaining the hierarchical data view determined by the application logic. dis advantages: i)If you donot specify a logical database in the program attributes,the GET events never occur. ii)There is no ENDGET command,so the code block associated with an event ends with the next event statement (such as another GET or an END-OF-SELECTION).
What is a batch input session?- BATCH INPUT SESSION is an intermediate step between internal table and database table. Data along with the action is stored in session ie data for screen fields, to which screen it is passed, program name behind it, and how next screen is processed.
How to upload data using CATT ?- These are the steps to be followed to Upload data through CATT: Creation of the CATT test case & recording the sample data input. Download of the source file template. Modification of the source file. Upload of the data from the source file.
What is Smart Forms?- Smart Forms allows you to create forms using a graphical design tool with robust functionality, color, and more. Additionally, all new forms developed at SAP will be created with the new Smart Form solution.
How can I make a differentiation between dependent and independent data?- Client dependent or independent transfer requirements include client specific or cross client objects in the change requests. Workbench objects like SAPscripts are client specific, some entries in customizing are client independent. If you display the object list for one change request, and then for each object the object attributes, you will find the flag client specific. If one object in the task list has this flag on, then that transport will be client dependent.
What is the difference between macro and subroutine?- Macros can only be used in the program the are defined in and only after the definition are expanded at compilation / generation. Subroutines (FORM) can be called from both the program the are defined in and other programs . A MACRO is more or less an abbreviation for some lines of code that are used more than once or twice. A FORM is a local subroutine (which can be called external). A FUNCTION is (more or less) a subroutine that is called external. Since debugging a MACRO is not really possible, prevent the use of them (I’ve never used them, but seen them in action). If the subroutine is used only local (called internal) use a FORM. If the subroutine is called external (used by more than one program) use a FUNCTION.

SAP R/3 INTERVIEW ARCHITECTURE QUESTIONS

2008-07-02T22:38:00.001-07:00

1. What guarantees the integration of all application modules?

The R/3 basis system guarantees the integration of all application modules. The R/3 basis s/w provides the run time environment for the R/3 applications ensures optimal integration, defines a stable architectural frame for system enhancements, and contains the administration tools for the entire system.One of the main tasks of the basis system is to guarantee the portability of the complete system.

2. What are the central interfaces of the R/3 system?

Presentation Interface.

Database Interface.

Operating system Interface.

3. Which interface controls what is shown on the p.c.?

Presentation Interface.

4. Which interface converts SQL requirements in the SAP development system to those of the database?

Database Interface.

5. What is SAP dispatcher?

SAP dispatcher is the control agent that manages the resources for the R/3 applications.

6. What are the functions of dispatcher?

Equal distribution of transaction load to the work processes.

Management of buffer areas in main memory.

Integration of the presentation levels.

Organization of communication activities.

7. What is a work process?

A work process is where individual dialog steps are actually processed and the work is done. Each work process handles one type of request.

8. Name various work processes of R/3 system?

Dialog or Online (processes only one request at a time).

Background (Started at a specific time)

Update (primary or secondary)

Enque (Lock mechanism).

Spool (generated online or during back ground processing for printing).

9. Explain about the two services that are used to deal with communication.

Message Service: Used by the application servers to exchange short internal messages, all system communications.

Gateway Service: Enables communication between R/3 and external applications using CPI-C protocol.

10. Which work process triggers database changes?

Update work process.

11. Define service (within R/3)?

A service is a process or group of processes that perform a specific system function and often provide an application-programming interface for other processes to call.

12. What are the roll and page areas?

Roll and page areas are SAP R/3 buffers used to store user contexts (process requests). The SAP dispatcher assigns process requests to work processes as they are queued in the roll and page areas.

Paging area holds data from the application programs.

Roll area holds data from previous dialog steps and data that characterize the user.

13. What are the different layers in R/3 system?

Presentation Layer.

Application Layer.

Database Layer.

14. What are the phases of background processing?

Job Scheduling.

Job Processing.

Job Overview.

15. What components of the R/e system initiate the start of background jobs at the specified time?

The batch scheduler initiates the start of background job. The dispatcher then sends this request to an available background work process for processing.

16. Define Instance.

An instance is an administrative unit in which components of an R/3 systems providing one or more services are grouped together. The services offered by an instance are started and stopped at random. All components are parameterized using a joint instance profile. A central R/3 system consists of a single instance in which all-necessary SAP services are offered. Each instance uses separate buffer areas.

17. From hardware perspective, every information system can be divided into three task areas Presentation, Application Logic and Data Storage.

The R/3 Basis software is highly suitable for use in multi-level client/server architectures.

18. What are R/3 Basis configurations?

A central system with centrally installed presentation software.

Two-level client/server system with rolled out presentation software.

Two-level client/server system. Presentation and Application run on the same computer.

Three-level client/server system. Presentation, Application and database each run on separate computers.

19. What is a Service in SAP terminology?

A service refers to something offered by a s/w component.

20. What is Server in SAP terminology?

A component can consist of one process or a group and is then called the server for the respective service.

21. What is a client in SAP terminology?

A S/W component that uses the service (offered by a s/w component) is called a Client. At the same time these clients may also be servers for other services.

22.What is a SAP system?

The union of all s/w components that are assigned to the same databases is called as a SAP system.

23. What is the means of communications between R/3 and external applications?

The means of communication between R/2,R/3 and external applications is via the CPI-C handler or SAP Gateway, using the CPI-C Protocol.

24. What is the protocol used by SAP Gateway process?

The SAP Gateway process communicates with the clients based on the TCP/IP Protocol.

25. Expand CPI-C.

Common Program Interface Communication.

26. What is a Spool request?

Spool requests are generated during dialog or background processing and placed in the spool database with information about the printer and print format. The actual data is places in the Tem Se (Temporary Sequential objects).

27. What are different types of Log records?

V1 and V2. V1 must be processed before V2. But, we can have more than one V2 logs.

28. What are the types of Update requests?

An update request can be divided into one primary (V1) and several Secondary update components (V2). Time-critical operations are placed in V1 component and those whose timing is less critical are placed in V2 components. If a V1 update fails, V2 components will not be processed.

29. Dialog work processes perform only one dialog step and then available for the next request.

30. Explain what is a transaction in SAP terminology.

In SAP terminology, a transaction is series of logically connected dialog steps.

31. Explain how SAP GUI handles output screen for the user.

The SAP front-end s/w can either run on the same computer or on different computers provided for that purpose. User terminal input is accepted by the SAP terminal program SAP GUI, converted to SAP proprietary format and sent to the SAP dispatcher. The dispatcher coordinates the information exchange between the SAP GUIs and the work processes. The dispatcher first places the processing request in request queues, which it then processes. The dispatcher dispatches the requests one after another, to the available work process. The actual processing takes place in the work process. When processing is complete, the result of a work process is returned via the dispatcher to the SAP GUI. The SAP GUI interprets the received data and generates the output screen for the user.

SAP ABAP Real Time Questions

2008-07-02T22:22:00.001-07:00

Which client number you use for the current project?
You are running a report. It is taking long time for execution. What steps will you do to reduce the execution time.
After running a BDC program in background, next day morning when you see the results, few records are not updated(error records). What will you do then?
You are given functional specs for a BDC program and you need to decide whether to write a method call transaction or a session. How u will decide?
What is the difference between report and script?
what are the differences between scripts & smart forms?
what are enhancements?
what are user-exits?
what is badi?
what is the difference between user-exit & BADIs?
what is the difference between user-exit & customer-exit?
how do you get functional specs when you are assigned some object? (specs through email..??)
How do you write technical specs?
Howdo you write UTP?(unit test plan)

Differences between LSMW and BDC

2008-07-02T13:30:00.001-07:00

Batch Data Communication (BDC) is the oldest batch interfacing technique that SAP provided since the early versions of R/3. BDC is not a
typical integration tool, in the sense that, it can be only be used for uploading data into R/3 and so it is not bi-directional.
BDC works on the principle of simulating user input for transactional screen, via an ABAP program. Typically the input comes in the form
of a flat file. The ABAP program reads this file and formats the input data screen by screen into an internal table (BDCDATA). The
transaction is then started using this internal table as the input and executed in the background.

In Call Transaction, the transactions are triggered at the time of processing itself and so the ABAP program must do the error handling.
It can also be used for real-time interfaces and custom error handling & logging features. Whereas in Batch Input Sessions, the ABAP
program creates a session with all the transactional data, and this session can be viewed, scheduled and processed (using
Transaction SM35) at a later time. The latter technique has a built-in error processing mechanism too.

Batch Input (BI) programs still use the classical BDC approach but doesnt require an ABAP program to be written to format the
BDCDATA. The user has to format the data using predefined structures and store it in a flat file. The BI program then reads this and
invokes the transaction mentioned in the header record of the file.

Direct Input (DI) programs work exactly similar to BI programs. But the only difference is, instead of processing screens they validate
fields and directly load the data into tables using standard function modules. For this reason, DI programs are much faster (RMDATIND - Material Master DI program works at least 5 times faster) than the BDC counterpart and so ideally suited for loading large volume data. DI programs are
not available for all application areas.

LSMW is an encapsulated data transfer tool. It can provide the same functionality as BDC infact much more but when coming to techinical perspective most the parameters are encapulated. To listout some of the differences :

LSMW is basicaly designed for a fuctional consultant who do not do much coding but need to explore the fuctionality while BDC is designed for a technical consultant.
LSMW offers different techinque for migrating data: Direct input ,BAPI,Idoc,Batch input recording. While bdc basically uses recording.
LSMW mapping is done by SAP while in BDC we have to do it explicitly .
LSMW is basically for standard SAP application while bdc basically for customized application.
Coding can be done flexibly in BDC when compared to LSMW

Secondary Index

2008-07-02T12:46:00.000-07:00

Creating a secondary index

There are two types of indexes: Primary index and secondary index. Primary index is automatically created using the primary keys defined.

Secondary index could be created as per the user requirement. This article discusses about creating a secondary index.

Go to transaction SE11.

LOGICAL DATABASE

2008-06-17T12:10:00.001-07:00

What are logical databases? What are the advantages/disadvantages of logical databases?

Ans :- A Logical Database is a hierarchical structure of tables. Use the GET statement to process Logical Databases.
LDB consists of logically related tables grouped together - used for reading and processing data.

Advantages
1. No need of programming for retrieval , meaning for data selection
2. Easy to use standard user interface, have check completeness of user input.

Disadvantages

1. Fast in case of lesser no. of tables But if the table is in the lowest level of hierarchy, all upper level tables should be read so performance is slower.

Preparation of the data records by the L.D.B and reading of the data records in the actual report are accomplished with the command pair.
Put and Get.
The three main elements of LDB are
Structure, Selections, Database Program.

A look on DATA DICTIONARY

2008-06-17T12:05:00.000-07:00

DATA TYPES AND DATA OBJECT:

To work with data at runtime, you need to store it in the program at runtime and address it from your program. The system needs to know the type of the data (for example, character string, whole number, table consisting of name, currency amount, and date, and so on). A data object is a named memory area that is structured according to a particular data type . The type normally specifies all of the attributes of the data object. Using the name, you can access the contents, that is the data, directly. The name may be a compound name consisting of more than one single name.

You could regard a data type as being similar to the construction plans for a building. The plans could be used for more than one building, which would all have the same type, but you would still be able to tell them apart. Suppose the buildings were used for storage. You would find a particular item using the address of the building, and knowing on which floor, in which room, and in which shelf or bin it was stored. You would have to consider carefully when drawing up your plans the kinds of things you would want to store in your buildings.

The ABAP language is very flexible. Some of the attributes of a data type do not have to be specified until you use it to declare a data object, or, in some cases, not until runtime. It also allows you to use data objects that you have already declared or ABAP Dictionary objects as the basis for new types or data objects.

There are various places in the ABAP Workbench in which you can store and define data types:

ABAP Dictionary

The ABAP Dictionary contains 23 predefined data types, which serve as a basis for all other ABAP Dictionary objects (such as domains, data elements, data types, and so on). These ABAP Dictionary types are available for use globally throughout the system.

As well as the Dictionary objects used to access tables (tables, views, search helps, and so on), you can also (from Release 4.5) create global data types in the ABAP Dictionary.

Previously, the only way to define global data types was to use a type group. Type groups are still supported, but the concept is actually obsolete now that it is possible to define global data types in the ABAP Dictionary.

ABAP programs

Data types that you define in an ABAP program are local, that is, only valid within that program. You use the ten predefined ABAP data types as a basis for your own types.

Both global and local data types fit into the schematic diagram above. The names used above should make it easier for you to understand the following slides and the online documentation.

The technical attributes of an elementary field are defined by an elementary type .

A structure type consists of components.
A table type consists of a line type , access type , key definition, and key type .
In certain exceptional cases, types only desscribe part of the attributes of a data object. For example, a table type does not specify how many lines the table will have. This attribute is not set until runtime, and only affects that one data object.

You can nest types "deeply" to any level. That means:
A structured type can have components that are themselves structured or table types. This enables you to construct very complex data types. However, the smallest indivisible unit is always an elementary type.

The ABAP Dictionary contains a series of predefined data types to represent the external data types of the various database systems.

When you define a field with type CURR in the ABAP Dictionary, you must always link to a currency. You do this by specifying a field with the type CUKY. (When you create a list, you use the CURRENCY addition in the WRITE statement). The same applies to type QUAN, which must always link to a field with type UNIT.

Type FLTP is useful for calculations involving very large or very small numbers. This usually only occurs in scientific applications or when making estimates.

For business calculations, you should always use type DEC or QUAN. The arithmetic is the same as that to which you are used "on paper" - the system calculates precisely to the last decimal place.

A typical use for type NUMC is for postal code fields - fields in which only digits should be allowed, but with which you do not want to perform calculations. (It is, however, possible to use conversions and calculate with alpha-numeric data.) For further details about arithmetic and conversions, refer to the Statements unit.

Based on their underlying data type, some data objects are displayed according to formatting options (for example, country-specific date formats). Each user defines these formats in their user defaults.
All of these data types apart from string and rawstring are elementary types. For technical reasons, these are classified as nested types. This has consequences for certain uses, such as the INTO clause of a SELECT statement.

Data element

Data elements have a business meaning (field label, help text, and so on). Up to and including Release 4.0, it was only possible to specify the technical attributes of a data element by specifying a domain. Each domain had to have a predefined Dictionary type assigned to it. This is still possible. However, it is now possible to enter a predefined Dictionary type directly. If you want to ensure that the technical attributes of a group of data elements can only be changed centrally, you should continue to use domains.

As part of ABAP Objects, you can now designate a data element a reference type and declare global types for references to global classes or interfaces. Note that, in this case, the type of the data element is no longer elementary, but nested. The same applies when you use the predefined types string and rawstring.

Structure

Each component of a structure must have a name so that it can be addressed directly. For the type of a component you may specify a predefined Dictionary type, a data element, a structured type, or a table type. This allows you to construct nested data types. Note the consequences we have already mentioned with particular kinds of access. For example, if a structure contains a component with the type reference or string, you cannot use INTO CORRESPONDING FIELDS OF in a SELECT statement. Instead, you must list the components in the INTO clause.

The data type of an internal table is fully specified by its:

Line type
The line type defines the attributes of the individual fields. You can specify any ABAP data type.

Key definition
The key fields and their sequence determine the criteria by which the system identifies table lines.

Key type
You can define the key as either unique or non-unique . The uniqueness of the key must be compatible with the access type you have chosen for the table. If the key is unique, there can be no duplicate entrie s in the table.

Access type

Unlike database tables, the system assigns line numbers to certain kinds of internal tables. This means that you can use the index to access lines as well as the key. We sometimes use the term "table type " to refer to this.

We can also divide up internal table types into three kinds by their access type:

Standard tables.

In a standard table, you can access data using either the table index or the key. Since the key of a standard table always has to be non-unique for compatibility reasons, the system searches the whole table each time you access it using the key. Consequently, you should always use the index to access a standard table whenever possible.

Sorted tables.

In a sorted table, the system automatically stores the entries and inserts new entries sorted by the table key. The system uses a binary search on the table when you access it using the key. You can specify the key of a sorted table as unique. You will often use the key to access a sorted table, but it is also possible to use the index. Standard tables and sorted tables are generically known as index tables.

Hashed tables.

You can only access a hashed table using the key. There are certain conditions under which you can considerably reduce the access times to large tables by using a hashed table.

The key of a hashed table must always be unique.

You do not have to specify the access type fully. You can either omit it altogether, or specify it partially (index table). The table type is then generic, and, by omitting certain attributes, we can use it to specify the types of interface parameters.

To find out the access type of an internal table at runtime, use the statement DESCRIBE TABLE KIND .

The line type specifies the semantic and technical attributes of the individual fields in a line. As already mentioned, you can specify either another table type, a structured type, or an elementary type. If you only use an elementary type, the internal table will have a single column with no component name (unstructured table

Key definition

The default key consists of all character (alphanumeric) components of the line type that are not themselves table types. In this case, it would be empty (only possible with standard tables).

It is particularly useful to name the line type , that is, the whole line, as the key if the table type is unstructured.

You can also name key components and their sequence explicitly.

A final possibility is not to specify the key, leaving it generic instead.
Key type As well as defining the key as unique and non-unique , you can specify a generic key type by omitting the specificatio n.

Type F is useful for calculations involving very large or very small numbers. This usually only occurs in scientific applications or when making estimates.

For business calculations, you should always use type P. The arithmetic is the same as that to which you are used "on paper" - the system calcualtes precisely to the la st decimal place.

A typical use for type N is for postal code fields - fields in which only digits should be allowed, but with which you do not want to perform calculations. (It is, however, possible to use conversions and calculate with alpha-numeric data.) For further details about arithmetic and conversions, refer to the Statements unit.

Unlike type C, N, or X fields, the length of a string or hexadecimal string is not statically defined. Instead, it is variable, and, at runtime, will always take the length of its current contents. The memory is managed dynamically by the system. Strings and hexadecimal strings can have any length.

You cannot currently use STRING or XSTRING to specify the type of a screen field.
You can only define a new data type based on an existing type. Use the TYPE addition to refer to data types, that is, predefined ABAP types, user-defined local types, predefined ABAP Dictionary types, user-defined ABAP Dictionary types, or fields or entire lines from database tables. If you refer to an ABAP Dictionary type, changes to the global type are automatically passed on to your type. This ensures that your type is always compatible with the corresponding ABAP Dictionary object. Types that refer to the ABAP Dictionary also have the advantages of formatting options, field help, and possible entries help.

The underlying ABAP Dictionary data type is converted into the corresponding ABAP data type when the program is generated. For further information, refer to the ABAP syntax documentation for the TABLES statement.

If a global and a local data type both have the same name, the system uses the local type .

Use the LIKE addition to refer to the type of a data object that you have already declared. This also applies to the next slides.

Elementary types

The length specification after the type name for ABAP data types C, N, and X specifies the number of characters in the type. For type P fields, you can also set the number of decimal places. If you omit these specifications, the system uses the default values (refer to the chart under Predefined ABAP Types).

Structured type s Use the statements

TYPES BEGIN OF .
And TYPES END OF .
to enclose the list of components in your structure. Any type definitions may appear between the two statements. You can also construct nested data types.
To refer to the line type of a table type or an internal table, use the additions TYPE LINE OF or LIKE LINE OF respectively.

Table types Similarly to when you create table types in the ABAP Dictionary, you must specify various attributes here:

The line type after ... TABLE OF (as always, if you refer to a data type, use TYPE, if you refer to a data object that has already been declared, used LIKE);

The access type before TABLE OF ... (If you omit this, the system uses the default access type, which is standard. You can also specify a generic table type using INDEX or ANY.);

The key definition after the key type (to specify the default key, use the DEFAULT KEY addition); You can also specify fields from the (flat) line type and specify the sequence explicitly. If the table is unstructured, you can use the TABLE LINE addition);

The key type after ...WITH (UNIQUE or NON-UNIQUE).
If you omit the key specification entirely, the system uses the non-unique default key.

For information about the optional INITIAL SIZE addition, refer to the page Declaring Internal Tables.

We have not yet introduced reference types. These will be discussed in conjunction with field symbols and references.

Similarly to when you define data types, you must specify a type when you declare data objects. You can do this in one of two ways:

Either by referring to a data type (using the TYPE addition), or a data object in the program that has already been declared (using the LIKE addition). You can use exactly the same syntax variants in the DATA statement as when you declare local data types using the TYPES statement.

You can also construct a field, structure, or internal table directly in a DATA statement, without having to define your own data type first.
In most cases, you will want to change the value of data objects at runtime. They are therefore also known as variables. You can assign a starting value to a data object using the VALUE addition. If you do not, the system assigns it the initial value appropriate to its type (see the table under Predefined ABAP Types).

There are two further statements that you can use to declare special data objects:

STATICS declares local variables in a subroutine whose values are retained in subsequent subroutine calls instead of being initialized again. For further information, refer to the Subroutines uint.

CLASS-DATA, an ABAP Objects statement, allows you to declare static class attributes.
With the exception of the WITH HEADER LINE addition, the syntax for declaring internal table objects is exactly the same as that used to define table types or other kinds of data objects. The addition allows you to create an internal table with a header line . However, this is an obsolete programming technique, and you should consequently no longer use it. For more information about header lines, along with general information about internal tables, refer to the Internal Table Operations unit.

Dynamic table extension

Unlike arrays in other programming languages, the number of lines in an internal table is increased automatically by the ABAP runtime environment as required. You therefore do not have to worry about managing the size of the table, but only about inserting, reading, or deleting lines. This makes chained lists redundant in ABAP.

INITIAL SIZE addition

When you create an internal table, the system allocates 256 bytes to it. The system then allocates a block of 8 KB to the table when you first add data, followed by further 8KB blocks as required. If you are only expecting to place a few lines in your table, or are using nested internal tables, it may be worth restricting the first automatic extension using the addition INITIAL SIZE . You may do this either in the data object definition or in the type definition. is the maximum number of lines that you are expecting to put in the table. When the system first allocates memory, it allocates the product of and the length of the line. In the second step, it allocates twice that amount, and then in subsequent steps, it allocates between 12 and 16 KB.

Selection screens are a special kind of screen whose layout you program directly in the processing logic using ABAP statements . In an executable (type 1) program, there is a standard selection screen (screen number 1000). The definition of the standard selection screen does not require the statements that normally mark the beginning and end of a selection screen definition, neither does it require an explicit call. The following statements allow you to easily create screens on which the user can enter data.

PARAMETERS creates an input field on the selection screen with the type you specify and a variable in the program with the same name. You cannot use f, string, xstring, or references to specify the type.

SELECT-OPTIONS creates a pair of "from - to" fields on the screen, in which it is possible to enter sets of complex selections for a specified variable. The values that the user enters are stored in an internal table that the system creates automatically. The internal table has four fields sign, option, low, and high.
You can also create this kind of table using …{TYPE|LIKE} RANGE OF … . However, tables declared in this way are not linked to the selection screen.

For further information about these statements, refer to the courses BC405 (Techniques of List Processing and ABAP Query) and BC410 (Programming User Dialogs).
Constants and literals are fixed data objects - you cannot change their values at runtime.

You define constants using the ABAP keyword CONSTANTS. In it, you must use the VALUE addition to assign a value to your constant.

Recommendation:

Avoid using literals wherever possible. Use constants instead. Your programs will then be easier to maintain.

Literals allow you to specify a value directly in an ABAP statement. There are two kinds of literals - numeric literals and text literals. Text literals must always be enclosed in single quotes. Integers (including a minus sign if appropriate) can be represented as numeric literals. They are mapped to the data types i and p (based on the interval that each data type can represent).

Example :

DATA: result1 TYPE i, result2 LIKE result1.
result1 = -1000000000 / 300 * 3. "result1: 999.999-
result2 = -10000000000 / 300 * 3. "result2: 10.000.000-
A numeric literal can contain up to 31 digits.
All other values (decimal and floating point numbers, strings, and so on) must be given as text literals. The system converts the data type if necessary.

A text literal can contain up to 255 characters.
If you want a single quote to appear in a text literal, you must use two single quotes in order for it to be interpreted as part of the literal and not the closing single quote.

Text symbols are a special form of text literals. You can create a set of text symbols for any program. These can be used for output in various ways. The advantage of text symbols over normal text literals is that they can be translated. Furthermore, text elements are stored separately from the program source code, making your program easier to understand.

Text symbols are often used to create lists that are not language-specific. You can also use them to assign texts dynamically to screen objects. (Static text elements for screen objects are a special case, and can be translated).
You can display text symbols in two different ways using the WRITE statement:

WRITE text-. (where can be any three-character ID).
WRITE ''(). (where can be any three-character ID). In this
case, is displayed if there is a text for it in the current logon language. If there is not, the default text is displayed.

When you use screens, the system automatically transports field contents from the processing logic to the screen and back, but only where screen fields and ABAP fields have the same names.

Restriction:

If you use screen fields with a reference to the ABAP Dictionary (Get from Dictionary function in the Screen Painter), you must use the TABLES statement to declare a data object with the same name as the ABAP Dictionary object in order for the field transport to work. Structures you declare like this are often referred to as work areas.

There are numerous advantages to using an ABAP Dictionary reference: Dictionary objects normally include foreign key checks, field help, possible entries, and the necessary error dialogs. Consequently you can catch inconsistent data as soon as the user enters it and before you even leave the screen.

If you program your own field checks, the field contents must already have been transported to the program. If you forget to reset the field when a check fails, an unwanted value may remain in the work area. You also face the same danger if you are not sure whether work areas are shared by more than one program.

To avoid these dangers, you should regard TABLES work areas as an interface between the screen and program, and only use them in this context. They provide data for the screen at the end of the PBO event, and receive it again when the values are transported from the screen.

Logical databases are special ABAP programs that you can attach to an executable (type 1) program. They read data from the database and pass it to the executable program. Because the task of reading the data has been passed to the logical database, your own ABAP program becomes considerably simpler.

The logical database passes the data to your program using interface work areas that you declare using the NODES statement. The statement creates a variable that refers to the data type in the ABAP Dictionary with the same name.

The data is passed to your program record by record. Each time the logical database makes a record available to your program, the corresponding GET or GET LATE event is triggered. In your program, you can code the relevant event blocks.
You can determine the type of the data record returned by the logical database using the TYPE addition However, you are restricted to types that are supported by the logical database.

The data object SPACE is a constant with type C and length 1. It contains a single space.

The system automatically creates a structure called sy for each program, based on the ABAP Dictionary structure syst. The individual components of the structure are known as system fields .

They contain values that inform you about the current state of the system. The values are updated automatically by the ABAP runtime environment.

You can access individual system fields using the notation sy-.
System fields are variables, so you can change them in your programs. However, you should only do this in cases where it is explicitly recommended in the documentation (for example, navigating between list levels by manipulating sy-lsind). In all other cases, you should only read the contents of system fields, since by changing them you might overwrite information that is important for subsequent steps in the program.
The online documentation contains a list of all system fields with notes on their use. You can also display the structure syst in the ABAP Dictionary.

You declare field symbols using the FIELD-SYMBOLS <> statement. The brackets (<>) are part of the syntax.

Field symbols allow you symbolic access to an existing data object. All of the changes that you make to the field symbol are applied to the data object assigned to it. If the field symbol is not typed (TYPE ANY), it adopts the type of the data object. By specifying a type for the field symbol, you can ensure that only compatible objects are assigned to it.

Field symbols are similar to dereferenced pointers .

You use the ASSIGN statement to assign a data object to the field symbol <>. To lift a type restriction, use the CASTING addition. The data object is then interpreted as though it had the data type of the field symbol. You can also do this with untyped field symbols using the CASTING TYPE addition.

Use the expression <> IS ASSIGNED to find out whether the fie ld symbol <> is assigned to a field.

The statement UNASSIGN <>. sets the field symbol <> so that it points to nothing.

The logical expression <> IS ASSIGNED is then false.
An untyped field symbol that does not have a data object assigned to it behaves (for compatibility reasons) like a constant with type C and length 1.

The statement TYPES TYPE REF TO data. *) defines a reference type to a data object. DATA... defines the corresponding reference itself. Such a reference is a field in which an address can be stored.

The GET REFERENCE OF INTO statement writes the address of the data object (already declared) into the reference variable. In other words, the reference points to the data object in memory.

Thus ABAP uses reference semantics (changes apply to the address) as well as value semantics, as used in field symbols (where changes apply to the data objects). However, in ABAP, reference semantics is restricted to assignments.

The dereferencing operator ->* in the ASSIGN statement allows you to assign the data object to which the reference points to a field symbol. You can then access the value of the data object.

You can create a data object with a specified type at runtime using the CREATE DATA
statement. This data object has no name, but the reference points to its address.

You can use type casting dynamically when you assign a data object to a field symbol. The graphic presents an example of this.
The name of the database table is not known until runtime (and consequently, neither is the line type).

Since you cannot specify a dynamic INTO clause in the SELECT statement, the system writes the data records into the long character field line.

The assignment to field symbol and the type casting then make it possible to access the field as though it were a flat structure. All type attributes are inherited from the database table. (You can also refer to the line type of an ABAP Dictionary object using the TYPE addition.)

If you knew the component names, you could display the fields directly using
WRITE -... .

However, you will not normally know the names of the components. In this case, you must use the ASSIGN COMPONENT variant, in which the components of the structure are assigned one-by-one to the field symbol and then displayed. When the loop runs out of components, the program reads the next data record.

Problem

The address of line must satisfy the same address rules as a table structure (address must be divisible by four with no remainder). You can force this by declaring an integer field dummy directly before declaring line. (Integers are always stored at addresses that are divisible by four.)

Unlike conventional data objects, you can specify the type of a data object created at runtime dynamically. The above example is a slightly modified version of the example on the previous page.

This time, the idea is the create the data object for the INTO clause dynamically at runtime . In this case, the type is already known (you have entered the table name), and there are no more alignment problems. The statement ASSIGN d_ref->* to assigns the data object to the field symbol. The data type of the table is inherited by the field symbol, so type casting is no longer necessary.

Instead of using a long character field, you can now write the data record into the data object with the same type to which the reference d_ref is pointing, by using the field symbol .

You will sometimes need to find out the attributes of a data object at runtime , especially when you use field symbols and references. The DESCRIBE FIELD statement returns various type attributes of variables.

Caution:

If you query the length of a field with type string or xstring, the system does not return the length of the string. Instead, it returns the length of the string reference, which is always eight bytes. To find out the length of the string, use the OUTPUT-LENGTH addition.

The statement DESCRIBE TABLE LINES returns the number of lines in an internal table.

Since the introduction of ABAP Objects, there is now a system called the RTTI concept (Run Time Type Information) that you can use to find out type attributes at runtime. It is based on system classes. The concept includes all ABAP types, and so covers all of the functions of the statements DESCRIBE FIELD and DESCRIBE TABLE.

TYPES OF TABLE IN SAP

2008-06-17T11:49:00.000-07:00

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.

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.

Concept of VIEWS in SAP

2008-06-17T11:47:00.001-07:00

Views :Data about an application object is often distributed on several tables. By defining a :view, you can define an application-dependent view that combines this data. The structure of such a view is defined by specifying the tables and fields used in the view. Fields that are not required can be hidden, thereby minimizing interfaces. A view can be used in ABAP programs for data selection.

The data of a view is derived from one or more tables, but not stored physically. The simplest form of deriving data is to mask out one or more fields from a base table (projection) or to include only certain entries of a base table in the view (selection). More complicated views can comprise several base tables, the individual tables being linked with a relational join operation.

The base tables of the view must be selected in the first step of a view definition. In the second step, these tables must be linked by defining the join conditions. It is also possible to use the join condition from a foreign key defined between the tables .

In the third step, you must select the fields of the base tables to be used in the view. Selection conditions that restrict the records in the view can be formulated in the fourth step.

Four different view types are supported. These differ in the way in which the view is implemented and in the methods permitted for accessing the view data.

· Database views implemented with an equivalent view on the database.

· Projection views used to hide fields of a table (only projection).

· Help views used as selection method in search helps

· Maintenance views permit you to maintain the data distributed on several tables for one application object at one time.

Database views implement an inner join. The other view types implement an outer join

The join conditions for database views can be formulated using equality relationships between any base fields. The join conditions for the other view types must be obtained from existing foreign keys. Tables therefore can only be combined in a maintenance view or help view if they are linked to one another with foreign keys.

The maintenance status whether you can only read data with the view or whether you can also insert and change data with it.

Database Views :

Data about an application object is often distributed on several database tables. A database view provides an application-specific view on such distributed data.

Database views are defined in the ABAP Dictionary. A database view is automatically created in the underlying database when it is activated.

Application programs can access the data of a database view using the database interface. You can access the data in ABAP programs with both OPEN SQL and NATIVE SQL. However, the data is actually selected in the database. Since the join operation is executed in the database in this case, you can minimize the number of database accesses in this way. Database views implement an inner join (see Inner and Outer Join )

If the database view only contains a single table, the maintenance status can be used to determine if data records can also be inserted with the view. If the database view contains more than one table, you can only read the data.

Database views should be created if want to select logically connected data from different tables simultaneously. Selection with a database view is generally faster than access to individual tables. When selecting with views, you should also ensure that there are suitable indexes on the tables contained in the view.

Since a database view is implemented in the database, a database view may only contain transparent tables.

The technical settings of a database view control whether the view data should be buffered.

Projection Views :

Projection views are used to hide fields of a table. This can minimize interfaces; for example when you access the database, you only read and write the field contents actually needed.

A projection view contains exactly one table. You cannot define selection conditions for projection views.

There is no corresponding object in the database for a projection view. The R/3 System maps the access to a projection view to the corresponding access to its base table. You can also access pooled tables and cluster tables with a projection view.

The maintenance status of the view controls how the data of the table can be accessed with the projection view.

Help Views:

You have to create a help view if a view with outer join is needed as selection method of a search help

The selection method of a search help is either a table or a view. If you have to select data from several tables for the search help, you should generally use a database view as selection method. However, a database view always implements an inner join. If you need a view with outer join for the data selection, you have to use a help view as selection method.

All the tables included in a help view must be linked with foreign keys. Only foreign keys that have certain attributes can be used here. The first table to be inserted in the help view is called the primary table of the help view. The tables added to this primary table with foreign keys are called secondary tables.

The functionality of a help view has changed significantly between Release 3.0 and Release 4.0. In Release 3.0, a help view was automatically displayed for the input help (F4 help) for all the fields that were checked against the primary table of the help view. This is no longer the case in Release 4.0.

As of Release 4.0, you must explicitly create a search help that must be linked with the fields for which it is offered (see Linking Search Helps with Screen Fields ).

Existing help views are automatically migrated to search helps when you upgrade to a release higher than 4.0.

A help view implements an outer join, i.e. all the contents of the primary table of the help view are always displayed. You therefore should not formulate a selection condition for fields in one of the secondary tables of the help view. If records of these secondary tables cannot be read as a result of this selection condition, the contents of the corresponding fields of the secondary table are displayed with initial value.

Search Helps :

The input help (F4 help) is a standard function of the R/3 System. The user can display the list of all possible input values for a screen field with the input help. The possible input values can be enhanced with further information. This is meaningful especially when the field requires the input of a formal key.

Standard Input Help Process

A user calls an input help with the following steps (some steps can be omitted, depending on the definition of the input help):

The user starts the input help to display the possible input values for a field (search field) in a screen template.

The system offers the user a number of possible search paths. The user selects one of these search paths. Each search path offers a number of restrictions to limit the number of possible input values. These values are offered in a Dialog box for value restriction when the search path is selected.

The user enters restrictions if required and then starts the search.

The system determines the values that satisfy the entered restrictions (hits) and displays them as a list (hit list).

The user selects the most suitable line from the hit list by double-clicking. The value of the search field is returned to the screen template (possibly together with other values).

Steps 2 and 3 are omitted if there is only a single search path available. In this case the dialog box for the value selection is offered immediately. You can also output the hit list directly after starting the input help. Steps 2 to 4 are omitted in this case.

Function of a Search Help

This standard process can be completely defined by creating a search help in the ABAP Dictionary. This search help only has to be assigned to the screen fields in which they should be available.

There are two types of search help:

· Elementary search helps describe a search path. The elementary search help must define where the data of the hit list should be read from (selection method), how the exchange of values between the screen template and selection method is implemented (interface of the search help) and how the online input help should be defined (online behavior of the search help).

· Collective search helpscombine several elementary search helps. A collective search help thus can offer several alternative search paths.

Maintenance Views :

Maintenance views offer easy ways to maintain complex application objects.

Data distributed on several tables often forms a logical unit, for example an application object, for the user. You want to be able to display, modify and create the data of such an application object together. Normally the user is not interested in the technical implementation of the application object, that is in the distribution of the data on several tables.

A maintenance view permits you to maintain the data of an application object together. The data is automatically distributed in the underlying database tables. The maintenance status determines which accesses to the data of the underlying tables are possible with the maintenance view.

All the tables in a maintenance view must be linked with foreign keys, that is the join conditions for maintenance views are always derived from the foreign key

cannot directly enter the join conditions as for database views.

There are some restrictions for the attributes of the foreign keys with which the tables in a maintenance view can be linked .

A standardized table maintenance transaction is provided (SM30), permitting you to maintain the data from the base tables of a maintenance view together.

Maintenance mechanisms, like screens and processing programs, must be created from the view definition with the transaction Generate Table View (SE54). This makes it possible to create easy-to-use maintenance interfaces in a simple manner.

LOCK OBJECT CONCEPT IN SAP

2008-06-17T11:44:00.000-07:00

If several users are competing to access the same resource or resources, you need to find a way of synchronizing the access in order to protect the consistency of your data.

Example: In a flight booking system, you would need to check whether seats were still free before making a reservation. You also need a guarantee that critical data (the number of free seats in this case) cannot be changed while you are working with the program.

Locks are a way of coordinating competing accesses to a resource. Each user requests a lock before accessing critical data.

It is important to release the lock as soon as possible, so as not to hinder other users unnecessarily.

Whenever you make direct changes to data on the database in a transaction, the database system sets corresponding locks.

The database management system (DBMS) physically locks the table entries that you want to change (INSERT; UPDATE, MODIFY), and those that you read from the database and intend to change (SELECT SINGLE FROM FOR UPDATE). Other users who want to access the locked record or records must wait until the physical lock has been released. In such a case, the ABAP program waits until the lock has been released again.

At the end of the database transaction, the database releases all of the locks that it has set during the transaction.

In the R/3 System, this means that each database lock is released when a new screen is displayed, since a change of screen triggers an implicit database commits.

To keep a lock set through a series of screens (from the dialog program to the update program), the R/3 System has a global lock table at the application server level, which you can use to set logical locks for table entries.

One application server contains this lock table and a special enqueue work process, which administers all requests for logical locks in the R/3 System. All logical lock requests of the R/3 System run using this work process.

You can also use logical locks to "lock" table entries that do not yet exist on the database (inserting new lines). You cannot do this with physical database locks.

For further information, see the ABAP Editor Keyword documentation for the term Locking.
Logical locks are generated when an entry is written in the lock table. You use function modules to do this.

You can only set a lock if the relevant table entry is not already locked.

The SAP transaction receives information on the success of a lock request from a return code sent via the EXCEPTION interface of the function module. In other words, the control is returned to the program using the function module. The ABAP program does not need to wait.

The SAP transaction can react appropriately by analyzing the return code.

Another user cannot gain access to work with the same table entries that are already locked.

Depending on the bundling technique in use for database updates), the program must delete the lock entries it generated using a lock module, or have them deleted indirectly (see unit Organizing Database Updates).

If the user terminates the program that generated the lock entries (usually a dialog program), the locks are released automatically (implicitly). You can do this by entering /n in the command field, or with the statements LEAVE PROGRAM, LEAVE TO TRANSACTION, and 'A' or 'X'
Messages.

When you call an ENQUEUE function module, the dialog program tries to generate a lock entry.

The export parameters identify the table entry (or entries) that you want to lock.

The program that generates the locks (usually dialog program) analyzes the return code for lock requests and reacts accordingly.

If the lock could not be set; you should normally output an error message.

At the end of the dialog program, you can use the corresponding DEQUEUE function module to delete the entries from the lock table.

DEQUEUE function modules have no exceptions. If you try to release an entry that is not locked, this has no effect.

If you want to release all of the locks that you have set, at the end of your dialog program, you can use the function module DEQUEUE_ALL.

The lock table contains the lock arguments for each table (for lock arguments, see the following slide).

To display the lock table, use transaction SM12.

The entries in the lock table are standard. Locks are always set using the values of the key fields in a table. These form the lock argument.

You pass the values for the lock argument to the lock modules via their interface (function module IMPORT parameters).

If you fail to set any of these parameters, the system interprets it generically, that is, the lock is set for all table lines that meet the criteria specified in the other parameters. The client parameter is an exception to this rule, where the default client SY-MANDT applies.

Lock entries must be assigned to a lock mode.

There are three different lock modes:

Mode 'E' for write locks: This is set if you want to write data to the database (change, create, or delete).

Mode 'S' for read locks: This is set if you want to ensure that the data, which you are reading from the database in your program, is not changed by other users while the program is running. You do not want to change the data itself in your program.

Mode 'X' for write locks: Like mode 'E', mode 'X' is used for writing data to the database. The technical difference between mode 'X' and mode 'E' is that locks of mode 'X' are not accumulated while a program is being executed. (For further details, see the following pages).

If someone tries to lock the same data record again with a second program (different user), the various lock modes take effect as follows:

Write locks ('E' or 'X') mean that any lock attempts from other users are refused, irrespective of the mode in which the lock is attempted.

If a data record is locked in mode 'S' (shared), further locks in mode 'S' may be set by other users.

Lock attempts in other lock modes ('E' or 'X') are refused.

If you want to try to lock a data record more than once while a program is running (for example using a function module that you call up, which sets locks itself), the lock system reacts in the following way:

Mode 'E' write locks are not refused. Instead, a cumulative counter is incremented. The same applies to read locks (mode 'S').

If a data record is locked in mode 'E', a lock request generates a second lock, which is marked as a read lock.

If a data record is locked in mode 'S' and no further read locks are set by other users, a lock attempt in mode 'E' is possible. This generates a second entry in the lock table (for mode 'E').

If a data record is locked in mode 'X', all further lock requests are refused.

If you want to ensure that you are reading up-to-date data in your program (with the intention of changing and returning this to the database), you should use the following procedure for lock requests and database accesses in your program:

First, lock the data that you want to edit.

Then read the current data from the database.

In the next step, process (change) the data in your program and write this to the database.

In the final step, release the locks that you set at the beginning.

This procedure ensures that your changes run fully with lock protection and that you only read data that has been changed consistently by other programs (provided that these also use the SAP lock concept and follow the procedure described here).

Lock modules are created for lock objects and not tables.

Lock objects are maintained in the dictionary. Customer lock objects must begin with "EY" or "EZ".

A lock object is a logical object composed of a list of tables that are linked by foreign key
Relationships. Lock modules are generated for these objects and enable common lock entries to be set for all tables contained in the lock object. This allows combinations of table entries to be locked.

Example: A lock object that contains the tables SFLIGHT and SBOOK enables a flight with its bookings to be locked.

The list of tables for a lock object consists of a primary table. Further table entries are referred to as secondary tables. Only tables with foreign key relationships to the primary table can be used as secondary tables.

With lock objects, you can assign different names for the parameters that describe the fields of the lock arguments for the lock modules. The names of the table fields (key fields of the tables) are proposed by the system.

You can specify the lock mode (a write lock 'E' or 'X' or a read lock 'S') for each table. These function as default values for the lock modules.

After you have assigned tables and default lock modes, lock objects must be generated.

When you activate a lock object, the system generates an ENQUEUE and a DEQUEUE function module.

These have the names ENQUEUE_ and DEQUEUE_ respectively.

If you want to ensure that you are reading current data in your program (with the intention of changing and returning this to the database), you should use the following procedure in your program for lock requests and database accesses:

1. Lock the data that you want to edit.
2. Read the current data from the database.
3. Process (change) the data in your program and write this to the database.
4. Release the locks that you set at the beginning.

This procedure ensures that your changes run fully with lock protection and that you only read data, which has been changed consistently by other programs (with the restriction that these are also using the SAP lock concept and following the procedure described).

If you change the order of the four steps to Read -> Lock -> Change -> Unlock, you run the risk that the data read by your program will not be up to date. Your program can read data before another user's program writes changes to the database. This means that a user of your program will make decisions for entries that are not based on up-to-date data from the database. For this reason, you should always follow the recommended procedure.

Requesting a lock from a program is a communication step with lock administration. The
Communication step requires a certain time interval. If your program sets locks for several objects, this interval occurs more than once.

By using so-called local lock containers, you can reduce these communication intervals with lock administration. To do so, collect the required lock requests of your program and send them together to lock administration.

The locks (delayed execution) can be collected when the lock modules are called. For this purpose, qualify the IMPORT parameter_collect with 'X'. The data transferred via the lock module interface is then registered in a list (lock container) as a lock request that needs to be executed.

The lock container can be terminated using the FLUSH_ENQUEUE function module and sent to lock administration.

When the lock orders of a lock container can be executed, the lock container is deleted.

If one of the locks in a container cannot be set, the function module FLUSH_ENQUEUE triggers the exception FOREIGN_LOCK. In this case, none of the registered lock requests is executed. The registered locks remain in the lock container.

You can delete the contents of an existing lock container with the function module
RESET_ENQUEUE.

The specified function modules have release status internally-released.

Open SQL vs Native SQL

2008-06-17T10:49:00.000-07:00

Question : What is Open SQL vs Native SQL?

Question :What does an EXEC SQL statement do in ABAP? What is the disadvantage of using it?

If you write a business application, there is always a database on backend. 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 backend, 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: 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. Right? Can we say SAP did “Write Once. Run Anywhere” before Java?

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.

I have never used Native SQL in my experiences more than 6 years for ABAP programming. I tried it, you can be sure it works. All ABAP programs in SAP R/3 System have been written with Open SQL. But I sometimes encountered Native SQL statements in original ABAP programs. I think 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.)

Disadvanteges

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.

ASAP Methodology

2008-06-17T04:30:00.000-07:00

Introduction

Enterprise application software has to cover a broad spectrum of functionality, yet be configured flexibly enough to meet specific requirements, which can vary enormously. SAP’s answers to this challenge are AcceleratedSAP and the R/3 Business Engineer, providing a comprehensive solution for implementing R/3 quickly, easily, and according to your own needs even during productive operation.

Born out of the need to cost effectively configure R/3 to order, AcceleratedSAP and the Business R/3 Engineer support custom configuration of R/3. You can tailor the R/3 components, functions and organizational structures to your needs, hiding and/or deactivating those functions that are not required.

Fig. 1: The R/3 Business Engineer Complements ASAP

AcceleratedSAP (ASAP) is SAP's standard implementation methodology. It contains the Roadmap, a step-by-step guide that incorporates experience from many years of implementing R/3. Along with that, AcceleratedSAP contains a multitude of tools, accelerators and useful information to assist all team members in implementing R/3. Quality checks are incorporated at the end of each phase to easily monitor deliverables and critical success factors. ASAP is delivered as a PC-based package, so that - if required - an implementation project can begin prior to having an R/3 System installed.

The R/3 Business Engineer contains a set of configuration and implementation tools which enable you or your consultants to define and configure R/3 and also to adapt an existing configuration to new needs or changed circumstances. The Business Engineer is resident to R/3.

So that its customers can implement R/3 as quickly as possible, SAP has standardized the implementation procedure, simplified the way functions are presented and reduced the technical complexity of implementation.

AcceleratedSAP and the Business Engineer help you configure R/3 according to your own needs using proven, industry-specific business scenarios and processes. Whether implementing new processes in your enterprise or restructuring old ones, R/3 can release the full potential of change for you. AcceleratedSAP and the Business Engineer help you determine which of R/3’s proven processes are most suited to your business, and then help you configure to meet your specific needs. The benefit is obvious: Restructuring enterprise processes in the R/3 System leads to a rapid and efficient production startup, meaning a faster return on investment.

By simplifying configuration, ASAP and the Business Engineer make the power of R/3 more accessible, helping companies to lower their dependence on expensive specialists or outside consultants. The user-friendliness of ASAP and the Business Engineer make them particularly suitable for the following groups:

Business professionals who need to discuss, prototype and design their business blueprint (enterprise model)
IS departments of large enterprises who need to customize R/3 applications more efficiently and more rapidly
Small and medium-sized companies previously wary of implementing R/3 because of the perceived scale of such projects
Consultants and SAP partners looking for an efficient way of offering their customers configure-to-order or wishing to develop R/3-based solutions for niche markets

Together, AcceleratedSAP and the Business Engineer empower you to manage cost, time and quality without compromising on implementation requirements. Some of the features offered are:

q Reduced implementation times and faster return on investment through structured planning and preconfiguration

Intuitive understanding of the wide range of functions offered by R/3

Process optimization using proven scenarios, processes and value chains, illustrating clearly the software’s capabilities and offering practical help when you configure the R/3 System.

q High quality installations through comprehensive procedural guidelines

q Optimizing business processes using SAP Business Workflow, via process monitoring and automation of procedures

Continuous, dynamic adjustment and optimization of R/3 applications

The capability to copy configured areas, for example, by transferring existing settings to new organizational units.

AcceleratedSAP and the Business Engineer are designed for openness and new platforms, using HTML-based documentation. Compatibility with many third-party modeling tools and software packages, for example, Microsoft Excel, is ensured.

Available Tools

Embarking on an implementation project requires a lot of careful thought beforehand. You need to think about what you want to accomplish, the optimum sequence, and the business cases that are best suited to your needs. But SAP has already done a lot of the thinking for you and packaged its findings in the following tools. They are then described in more detail in the following chapters organized according to the corresponding AcceleratedSAP phases.

AcceleratedSAP (ASAP): A comprehensive solution for the introduction of the R/3 System in your enterprise. ASAP and most of its tools can be used independently of an R/3 installation.

The tools available for AcceleratedSAP are:

The Project Estimator, an internal SAP tool which enables SAP consultants to accurately gauge the required resources, the costs and the time frame of implementation. The Project Estimator takes into account the project scope and several project and risk factors.
The Concept Check Tool, a tool enabling you to carry out quality checks on the project preparation, technical infrastructure and R/3 configuration settings. This is done mainly during the first two implementation phases of the R/3 project. In this way you are alerted to potential data volume and configuration conflicts that could lead to performance issues if not addressed.
The Implementation Assistant: The ASAP navigation tool that accompanies you through the five phases of implementation down to the task level. It includes a description and a detailed "how-to" for each task in the Roadmap. Along with that, many tools, templates and documents are hyperlinked to the task. The Implementation Assistant contains the following elements:

ASAP Implementation Roadmap and Project Plan. The Roadmap contains the five phases, from which you can drill down into work packages, activities and tasks. The Project Plan contains three components, a budget plan, a resource plan and a work plan. These are explained in more detail in the next chapter.

The ASAP Roadmap is the successor of the R/3-based Procedure Model, which was used until Rel. 3.1 in R/3 implementation projects.

Knowledge Corner, containing tips and tricks for configuration from consultants, detailed documentation on SAP’s implementation services, information on technical tools, as well as simplification guidebooks and R/3 Customizing wizards.

Question and Answer Database (Q&Adb). Using the R/3 Reference Model structure, the Q&Adb is used to assist in gathering requirements for business processes, conversions, reports, interfaces, enhancements and authorizations. The database provides useful questionnaires to help you define the process needs and also serves as a repository for all this information. Since it is a database, it allows for flexible reporting. The business requirements generated from the Q&Adb are collectively known as the Business Blueprint.

Business Process Master List, to manage configuration, testing and the creation of end user documentation. The Business Process Master List is linked to pre-written Business Process Procedures (BPPs), detailled end-user documentation for R/3 transactions.
Issues Database: supporting project management, this database supports the entering, monitoring and managing of issues that come up during the project.

R/3 Business Engineer: The implementation tools for the high-quality configuration of the R/3 System are:

R/3 Reference Model: Comprehensive graphical process flows describing the R/3 functionality from different points of view. It contains scenarios, processes and functions, as well as components. The R/3 Reference Model can be viewed using SAP's Business Navigator and the Business Navigator Web, or using third-party modeling tools available from modeling partners.

Implementation Guide (IMG): Used to configure all system parameters for the business processes in R/3. It contains project management functionality and a menu-driven view of all R/3 Customizing activities. Every activity can be documented in detail, and responsibilities and statuses can be assigned.

Preconfigured systems:

Preconfigured US and Canadian clients: Provides a head start on baseline configuration. It includes a preconfigured US/Canadian chart of accounts, print forms, account determination, units of measure, etc. The predefined test sequences that are included can be a starting point for integration testing.
Preconfigured industry systems: A number of complete preconfigured clients consisting of an industry-specific model and preconfigured business processes for the needs of a particular industry in R/3 are available. For more information on preconfigured systems, see the description of Phase 2, Business Blueprint or the information on the IDES System in this chapter.

Continuous Business Engineering

In today’s fast-moving, ever-changing business climate, companies are in a constant state of flux and their mission-critical applications must adapt and evolve at the same speed. If software cannot grow with the needs of a company, the company will quickly find itself in a straightjacket.

Furthermore, an ERP application needs to let you move forward fast, knowing that you can roll back changes without downtime.

An enterprise's organizational structure and the corresponding R/3 implementation created using the Business Engineer are not "set in concrete", they can be modified at any time. Examples of possible changes, which can be made rapidly include the following:

Addition or removal of entities within the organization structure (for example, business units, production plants, warehouses, etc.)
Introduction of new staff, promotion, reallocation of work tasks, and maintenance of authorization profiles

Changes to the reporting or cost/profit center structure

New and concurrent currencies
Accommodation of changed legal requirements (for example, new tax rates, new employment legislation)
Activation or deactivation of R/3 functions
Optimization of business processes
Support for new and multiple versions of R/3

In addition, SAP offers a range of services if you want support for some of these changes, for example, conversion services to support mergers and acquisitions. Standard Euro services are a further example of the available services.

AcceleratedSAP and R/3 Business Engineer take the hassle out of implementation procedures and change management. Modifications can be made at any time, and the compatibility of changes can be verified with other configuration decisions, thus supporting their smooth, trouble-free introduction into the productive system.

SAP Implementation

2008-06-16T02:27:00.001-07:00

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 organisation.

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 organisation 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 requirment 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

2008-06-16T02:24:00.000-07:00

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.

LOGICAL DATABASES

2008-06-16T02:22:00.001-07:00

In general, the system reads data that will appear in a list from the database.

You can use OPEN SQL or NATIVE SQL statements to read data from the database.

The use of a logical database provides you with an alternative to having to program database accesses individually. Logical databases retrieve data records and make them available to ABAP programs.

The same logical database can be the data source for several Quick Views, queries, and programs. In the Quick View, the LDB can be specified directly as a data source. A query works with the logical database when the functional area that generated the query is defined with a logical database. In the case of type 1 programs, the LDB is entered in the attributes or called using function module LDB_PROCESS. See appendix for information on how to use the function module.

Logical databases offer several advantages:

The system generates a selection screen. The use of selection screen versions or variants provides the required flexibility.

The user does not have to know the exact structure of the tables involved (especially the foreign key dependencies); the data is made available in the correct order at GET events.

Performance improvements within logical databases directly affect all programs linked to the logical database, without having to change the programs themselves.

Maintenance can be performed at a central location.

Authorization checks can also be performed centrally.

A logical database is an ABAP program that reads predefined data from the database and makes it available to other programs.

A hierarchical structure determines the order in which the data is supplied to the programs. A logical database also provides a selection screen that checks user entries and conducts error dialogs. These can be extended in programs.

SAP provides some 200 logical databases in Release 4.6. The names of logical databases have been extended to 20 places in Release 4.0 (namespace prefix max. 10 characters).

In the case of executable programs, you can enter a logical database in the attributes.

Use the NODES statement to specify the nodes of the logical database that You want to use in the program. NODES allocates the appropriate storage space for the node - that is, a work area or a table area depending on the node type.

The logical database makes the data records available for the corresponding GET events.
The sequence in which these events are processed is determined by the structure of the logical database.

Logical databases are made up of several sub-objects. The structure determines the hierarchy, and thus the read sequence of the data records.

Node names can contain up to 14 characters. There are four different node types.

Table (type T): The node name is the name of a transparent table (this type corresponds to the concept prior to Release 4.0A). The table name must be identical to the node name. Deep types (complex) are not allowed.

DDIC type (type S): Any node name is possible. It is assigned a structure or a table type from the Dictionary. The node name can differ from the type name. Deep structures are possible.

Type groups (type C): The node type is defined in a type group. The name of the type group must be maintained in the "Type group" field. You should generally prefer DDIC types, as the other applications that use the logical database (such as SAP Query) can access them (short texts, and so on).

Dynamic nodes (type A): These nodes do not have a fixed type; they are not classified until the program runtime. Which types are generally allowed is determined when the structure is created.

Nodes are declared using language element NODES.

Processing blocks are always allocated to an event. A processing block is closed by the next event key word, the start of form routines, or by the end of the program.

The START-OF-SELECTION event is triggered before control is given to the read routine of the logical database. The END-OF-SELECTION event is triggered after all GET events have been processed - that is, all data records have been read and processed.

The GET event is triggered whenever the logical database supplies data for this node. This means that GET events are processed several times, and that data has already been read from the database for these events. The sequence in which the GET events are processed is determined by the structure of the logical database.

The GET LATE event is triggered when all subordinate nodes of node have been processed, before the data is read for the next ; that is, whenever a hierarchy level has been completed.

At the start of the event, the system automatically adds a line feed and configures the default formats (for example, INTENSIFIED ON).

CHECK statements end the current processing block.

STOP statements end program processing. However, in contrast to the EXIT statement, the processing block END-OF-SELECTION is processed first (if it exists).

If there is a STOP statement within the END-OF-SELECTION processing block, program processing ends immediately and a list is displayed.

The EXIT statement exits the program and displays the list.

You can also use the REJECT statement. The data record is not processed further. Processing continues on the same hierarchy level when the next data record is read. REJECT, unlike the CHECK statement, can also be used within a subroutine.

Use the selection include dbsel to define selection screens for logical databases. The addition FOR NODE assigns selections to individual logical nodes. The appearance of a selection screen thus directly depends on the NODES statement contained within your program.

A field selection can be defined for the individual nodes. To do this, you have to specify the addition FIELD SELECTION FOR NODE in the SELECTION-SCREEN statement. You can then use GET FIELDS to restrict the amount of data returned.

You can designate individual nodes for dynamic selection using the addition DYNAMIC SELECTIONS FOR NODE. The Dynamic selection pushbutton then appears on your selection screen. You can determine which selection fields can be set by choosing a particular selection view yourself (type: CUS) or by using the selection view delivered by SAP (type: SAP).

With large logical databases you can define several selection screen versions. Each selection screen version contains a subset of your selection criteria (language element: EXCLUDE). Specify the name of a selection screen version in the program attributes.

When you enter a logical database in the attributes of your type 1 program, the system processes the selection screen of the logical database. The concrete characteristics of the selection screen depend upon the node specified in the NODES statement. If you specify a node of type T (table), you can also declare the table work area with the TABLES statement.

If you address only subordinate nodes (in the hierarchy) of the logical database in the program (for example sflight), the selection screen criteria for the superior node in the hierarchy (spfli) also appear. You can thus restrict the dataset to be read so that it meets your specific requirements.

Note: A logical database always reads in accordance with its structure. This means that if you only need data from a node deep in the hierarchy, you will achieve better performance by programming the access yourself. This avoids unnecessary reading of the database.

If the logical database supports dynamic selections, the pushbutton for Dynamic selections appears on the selection screen. When the user presses this button, a second selection screen is displayed.
This screen allows the user to select additional database fields. The system transfers the selections directly to the logical database program and therefore to the database (dynamic selections).

he selection view determines which fields are displayed on the selection screen. Create your own view with type CUS, and have it override the view with type SAP.

Database program sapdb for logical database is a collection of subroutines, each of which is performed for specific events. For example, subroutine is processed once at the start of the database program. This program can be used to define default values for the selection screen of the LDB.

Other subroutines also exist that are processed during events PBO (Process Before Output) and PAI (Process After Input) of the selection screen. Checks, such as authorization checks (AUTHORITY-CHECK), are usually performed during event PAI.

The database accesses (SELECT statements) are programmed in the put_ subroutines. These subroutines may be processed several times, depending on which selection criteria the user specifies. The sequence in which these subroutines are processed is determined by the structure of the logical database.

Database access (SELECT statements) should be programmed with optimal performance in mind. When creating a logical database you generate the corresponding database program after first having determined its structure and selection attributes. You can find performance tips in the comment lines.

When a program that has been assigned a logical database is started, control is initially passed to the database program of the logical database. Each event has a corresponding subroutine in the database program - for example, subroutine init for event INITIALIZATION. During the interaction between the LDB and the associated program, the subroutine is always processed first, followed by the event (if there is one in the report).

Logical database programs read data from a database according to the structure declared for the logical database. They begin with the root node and then process the individual "branches" consecutively from top to bottom.

The logical database reads the data in the put_ subroutines. During event PUT, control is passed from the database program to the GET event of the associated report.

The data is made available in the corresponding work areas in the report. The processing block defined for the GET event is performed. Control then returns to the logical database.
PUT activates the next form subroutine found in the structure. This flow is continued until the report has collected all the available data.

The depth of data read in the structure depends upon a program's GET events. A logical database reads to the lowest GET event contained within the structure attributes. Only those GET events for which processing is supposed to take place are written into the report program. Logical databases read all data records found on the direct access path.

If you specify a logical database and declare additional selections in the program attributes that refer to the fields of a node not designated for dynamic selection, you must use the CHECK statement to see if the current data record fulfills the selection criteria.

If the data record does not fulfill these selection criteria, current event block processing ends.

Understanding TICKETS in SAP

2008-06-16T02:19:00.000-07:00

Handling tickets is called Issue Tracking system. The errors or bugs forwarded by the end user to the support team are prioritized under three seviority High, Medium and Low.

Each and every seviority as got its time limits before that we have to fix the error.
The main job of the supporting consultant is to provide assistance on line to the customer or the organisation where SAP is already implemented for which the person should be very strong in the subject and the process which are implemented in SAP at the client side to understand,to analyse,to actuate and to give the right solution in right time.This is the job of the support consultant.

The issues or the tickets(problems) which are arised is taken care of on priority basis by the support team consultants.
The work process in support projects are given below for your reference.

1. The customer or the end user logs a call through any tool or by mail (RADIX).
2. Each one of the support team is a part of support group.
3. Whenever a customer logs a call he /she has to mention to which work group (by name).
4. Once the calls came to the work group the support consultant or the team need to send an IR (Initial Response) to the user depending upon the priority of the calls. (Top,High,Med,Low,None)
5. Then the error is fixed, debugged by the support consultant or the team. Then after testing properly by generating TR(Transport Request through the basis admin)
6. Then it is informed to the end user/customer/super user about the changes which have moved to the production server by CTS process.
These are the process. In summary, what I understand is that if any configuration or customization is required to solve the issue, then the consultant have to work on DEV Client, then the end user will test it in the QA client and after approval the BASIS consultant has to transport it to the PRODUCTION
client.
An example:
Tickets in SD can be considered as the problems which the end user or the employee in the company face while working on R/3. Tickets usually occur during the implementation or after the implementation of the project. There can be numerous problem which can occur in the production
support and a person who is working in the support has to resolve those tickets in the limited duration,
every ticket has the particular deadline alert so your responsibility is to finish it before that deadline.

To begin with , we should give "TICKET" to you for not knowing it.
Here is an eg of a ticket raise:
End user is not able to

1. Create Sales order for a customer from a New plant , since shipping point determination is not
happened . ( Without Shipping point the document becomes INCOMPLETE and he will not be able to
proceed further like DELIVERY, BILLING).
He raises a ticket and the priority is set in one of the below:

1. Low 2. Medium 3. High.
Now you need to solve this ticket. You would analyze the problem and identify that the SP configuration has to be done for the new plant.
You would request a transport for DEV CLIENT to BASIS. You do the change and Request one more Transport to BASIS for QA client. The End user will test the same by creating a sales order for the new plant and approve it.
Finally, you request a transport to move the changes to PRODUCTION. Once the change is deployed in production the TICKET is closed. What I have given is a small example. You would get some real issues with severity HIGH in your day-day support.

In maintenance and Support projects what happens is if a customer is facing any problem while executing any particular transaction or report etc .

He calls up the Call center (help desk) and explains the problem and the help desk ppl will create a ticket based on the users requirement.these ticket are assigned to

1. User will encounter a error/problem
2. User will call up the Help desk.
3. Help desk will take the inputs from the user and routes it to the
concerned group (technical or functional).
4. Technical guys will accept the ticket taking the ownership and will work on that.
5. He solves the issue and sends a mail to the user for conmfirmation.
6. After users confimation the ticket will be closed by the technical or functional
consultant.

tickets(A number ) is a Incident that is created for a issue that is asked by a client .. Let us say you are working in suppot and client asks you to do some changes to a report.
we will create a ticket and update the ticket with the client requirment and also the progress of the work that is being done on that ticket and the time that you have spent on doing the changes or resolving that ticket.

Different company uses differnt incident manament system for the tracking the time spent by a consultant on the issue.. and the terminology varies from company to company.. some one say it a ticket, token,incident, task..

Few of the used incident managment softwares are Remedy, Symergy, PMT, Lotus Note..