Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

need definition

Former Member
0 Likes
704

hi abapers,

i need some definition which can be understand in easy manner.. they are

1. diff b/w cluster and pooled table...?

2. diff b/w break and watch point...?

3. what is SAP dispatcher...?

4. what is work process..?

plz send the definition which everyone can understand..

thanx.

Ashraf.

1 ACCEPTED SOLUTION
Read only

gopi_narendra
Active Contributor
0 Likes
652

1. Pooled tables can be used to store control data (e.g. screen sequences, program parameters or temporary data). Several pooled tables can be combined to form a table pool. The table pool corresponds to a physical table on the database in which all the records of the allocated pooled tables are stored.

Cluster tables contain continuous text, for example, documentation. Several cluster tables can be combined to form a table cluster. Several logical lines of different tables are combined to form a physical record in this table type.

2. break point is the point at which u want ur program to stop during execution

watch point is the point at which u want ur program to stop during execution for a particular value of a field used in the program

Regards

Gopi

5 REPLIES 5
Read only

gopi_narendra
Active Contributor
0 Likes
653

1. Pooled tables can be used to store control data (e.g. screen sequences, program parameters or temporary data). Several pooled tables can be combined to form a table pool. The table pool corresponds to a physical table on the database in which all the records of the allocated pooled tables are stored.

Cluster tables contain continuous text, for example, documentation. Several cluster tables can be combined to form a table cluster. Several logical lines of different tables are combined to form a physical record in this table type.

2. break point is the point at which u want ur program to stop during execution

watch point is the point at which u want ur program to stop during execution for a particular value of a field used in the program

Regards

Gopi

Read only

uwe_schieferstein
Active Contributor
0 Likes
652

Hello Ashraf

You will find a good comparison between pooled and cluster tables in the SAP online help

<a href="http://help.sap.com/saphelp_erp2005vp/helpdata/en/cf/21f083446011d189700000e8322d00/content.htm">Pooled and Cluster Tables</a>

A <b>break-point is static</b> meaning that the program will always stop when it <b>reaches the break-point.

A watch-point is dynamic</b> meaning that the program will only stop if a certain condition is fulfilled (e.g. stop at sy-subrc = 0). Watch-points always check the contents of program variables at runtime. If the specified condition is never met the program will never stop at the watch-point.

Fo a definition of work process and dispatcher have a look at

<a href="http://help.sap.com/saphelp_erp2005vp/helpdata/en/35/26b165afab52b9e10000009b38f974/content.htm">Display and Control Work Processes</a>

Regards

Uwe

Read only

Former Member
0 Likes
652

Asraf,

1.What are pooled tables?

These are logical tables, which must be assigned to a table pool when they are defined. Pooled tables can be used to store control data (such as screen sequences or program parameters).

What is a table cluster?

A table cluster combines several logical tables in the ABAP/4 Dictionary. Several logical rows from different cluster tables are brought together in a single physical record. The records from the cluster tables assigned to a cluster are thus stored in a single common table in the database.

2. Break point means At particular Point It will stop the process.Here you can go

line by line.

Watch point means at particular value It will stop the Process.

Ex : You are looping internal table which is having thousands.

In this you want to check the the particular record.Instead of preesing F5

Or F6 till that record ,there is option in Watch point where you can give

your column name & record value.Then process will stop at particular

record.

3. Dispatcher

Each application server contains a dispatcher. The dispatcher is the link between the work processes and the users logged onto the application server. Its task is to receive requests for dialog steps from the SAPgui and direct them to a free work process. In the same way, it directs screen output resulting from the dialog step back to the appropriate user.

4.Work processes execute the dialog steps of application programs. They are components of an application server. The following diagram shows the components of a work process:

Each work process contains two software processors and a database interface.

Screen Processor

In R/3 application programming, there is a difference between user interaction and processing logic. From a programming point of view, user interaction is controlled by screens. As well as the actual input mask, a screen also consists of flow logic. The screen flow logic controls a large part of the user interaction. The R/3 Basis system contains a special language for programming screen flow logic. The screen processor executes the screen flow logic. Via the dispatcher, it takes over the responsibility for communication between the work process and the SAPgui, calls modules in the flow logic, and ensures that the field contents are transferred from the screen to the flow logic.

ABAP Processor

The actual processing logic of an application program is written in ABAP - SAP’s own programming language. The ABAP processor executes the processing logic of the application program, and communicates with the database interface. The screen processor tells the ABAP processor which module of the screen flow logic should be processed next. The following screen illustrates the interaction between the screen and the ABAP processors when an application program is running.

Database Interface

The database interface provides the following services:

Establishing and terminating connections between the work process and the database.

Access to database tables

Access to R/3 Repository objects (ABAP programs, screens and so on)

Access to catalog information (ABAP Dictionary)

Controlling transactions (commit and rollback handling)

Table buffer administration on the application server.

The following diagram shows the individual components of the database interface:

The diagram shows that there are two different ways of accessing databases: Open SQL and Native SQL.

Open SQL statements are a subset of Standard SQL that is fully integrated in ABAP. They allow you to access data irrespective of the database system that the R/3 installation is using. Open SQL consists of the Data Manipulation Language (DML) part of Standard SQL; in other words, it allows you to read (SELECT) and change (INSERT, UPDATE, DELETE) data. The tasks of the Data Definition Language (DDL) and Data Control Language (DCL) parts of Standard SQL are performed in the R/3 System by the ABAP Dictionary and the authorization system. These provide a unified range of functions, irrespective of database, and also contain functions beyond those offered by the various database systems.

Open SQL also goes beyond Standard SQL to provide statements that, in conjunction with other ABAP constructions, can simplify or speed up database access. It also allows you to buffer certain tables on the application server, saving excessive database access. In this case, the database interface is responsible for comparing the buffer with the database. Buffers are partly stored in the working memory of the current work process, and partly in the shared memory for all work processes on an application server. Where an R/3 System is distributed across more than one application server, the data in the various buffers is synchronized at set intervals by the buffer management. When buffering the database, you must remember that data in the buffer is not always up to date. For this reason, you should only use the buffer for data which does not often change.

Native SQL is only loosely integrated into ABAP, and allows access to all of the functions contained in the programming interface of the respective database system. Unlike Open SQL statements, Native SQL statements are not checked and converted, but instead are sent directly to the database system. Programs that use Native SQL are specific to the database system for which they were written. R/3 applications contain as little Native SQL as possible. In fact, it is only used in a few Basis components (for example, to create or change table definitions in the ABAP Dictionary).

The database-dependent layer in the diagram serves to hide the differences between database systems from the rest of the database interface. You choose the appropriate layer when you install the Basis system. Thanks to the standardization of SQL, the differences in the syntax of statements are very slight. However, the semantics and behavior of the statements have not been fully standardized, and the differences in these areas can be greater. When you use Native SQL, the function of the database-dependent layer is minimal.

Types of Work Process

Although all work processes contain the components described above, they can still be divided into different types. The type of a work process determines the kind of task for which it is responsible in the application server. It does not specify a particular set of technical attributes. The individual tasks are distributed to the work processes by the dispatcher.

Before you start your R/3 System, you determine how many work processes it will have, and what their types will be. The dispatcher starts the work processes and only assigns them tasks that correspond to their type. This means that you can distribute work process types to optimize the use of the resources on your application servers.

The following diagram shows again the structure of an application server, but this time, includes the various possible work process types:

The various work processes are described briefly below. Other parts of this documentation describe the individual components of the application server and the R/3 System in more detail.

Dialog Work Process

Dialog work processes deal with requests from an active user to execute dialog steps.

Update Work Process

Update work processes execute database update requests. Update requests are part of an SAP LUW that bundle the database operations resulting from the dialog in a database LUW for processing in the background.

Background Work Process

Background work processes process programs that can be executed without user interaction (background jobs).

Enqueue Work Process

The enqueue work process administers a lock table in the shared memory area. The lock table contains the logical database locks for the R/3 System and is an important part of the SAP LUW concept. In an R/3 System, you may only have one lock table. You may therefore also only have one application server with enqueue work processes.

Spool Work Process

The spool work process passes sequential datasets to a printer or to optical archiving. Each application server may contain several spool work process.

The services offered by an application server are determined by the types of its work processes. One application server may, of course, have more than one function. For example, it may be both a dialog server and the enqueue server, if it has several dialog work processes and an enqueue work process.

You can use the system administration functions to switch a work process between dialog and background modes while the system is still running. This allows you, for example, to switch an R/3 System between day and night operation, where you have more dialog than background work processes during the day, and the other way around during the night.

Pls. Mark if useful

Read only

Former Member
0 Likes
652

Hi Ashraf,

1)For Tables

http://www.erpgenie.com/abap/tables.htm

A major diffrence between the two is in case of cluster tables there must be some relationship ( a common filed) between the tables which form the cluster , but this is not required in case of Pool tables.

Second is cluster table store very large volume of data , where as pooltables are usually creeted by pooling together those table where the volume of data and modification/updates to data is less.

2)Check this link

http://help.sap.com/saphelp_nw2004s/helpdata/en/c6/617cbee68c11d2b2ab080009b43351/frameset.htm

Regards,

Priyanka.

Read only

Former Member
0 Likes
652

hi

good

1->

Pooled Table : Pooled tables are logical tables that must be assigned to a table pool when they are defined. Pooled tables are used to store control data. Several pooled tables can be cominied in a table pool. The data of these pooled tables are then sorted in a common table in the database.

Cluster Table : Cluster tables are logical tables that must be assigned to a table cluster when they are defined. Cluster tables can be used to strore control data. They can also be used to store temporary data or texts, such as documentation.

2->

go through this link

http://help.sap.com/saphelp_nw2004s/helpdata/en/f1/792442db42e22ce10000000a1550b0/content.htm

3->

go through this link

http://dev.mysql.com/doc/maxdb/en/ab/61fe41af01c417e10000000a155106/content.htm

4->

go through this link

http://help.sap.com/saphelp_46c/helpdata/en/fc/eb2e7d358411d1829f0000e829fbfe/content.htm

thanks

mrutyun^