Sunday, May 22, 2011

ABAP - Inner Join and Outer Join (Explained)

The data that can be selected with a view depends primarily on whether the view implements an inner join or an outer join. With an inner join, you only get the records of the cross-product for which there is an entry in all tables used in the view. With an outer join, records are also selected for which there is no entry in some of the tables used in the view.
The set of hits determined by an inner join can therefore be a subset of the hits determined with an outer join.
Database views implement an inner join. The database therefore only provides those records for which there is an entry in all the tables used in the view. Help views and maintenance views, however, implement an outer join.
This graphic is explained in the accompanying text

Saturday, May 7, 2011



User-defined types
Database objects
Provides services
Data elements
  Table types
  Database views
Setting and releasing locks, defining an input help (F4 help) and attaching a field help (F1 help) to a screen field are supported.

Data elements: Describe an elementary type by defining the data type, length and possibly decimal places.
Structures: Consist of components that can have any type.
Table types: Describe the structure of an internal table

The ABAP Dictionary permits a central management of all the data definitions used in the R/3 System.

In the ABAP Dictionary you can create user-defined types (data elements, structures and table types) for use in ABAP programs or in interfaces of function modules. Database objects such as tables and database views can also be defined in the ABAP Dictionary and created with this definition in the database.

The ABAP Dictionary also provides a number of services that support program development. For example, setting and releasing locks, defining an input help (F4 help) and attaching a field help (F1 help) to a screen field are supported.

Tables and database views can be defined in the ABAP Dictionary.

These objects are created in the underlying database with this definition. Changes in the definition of a table or database view a re also automatically made in the database.

Indexes can be defined in the ABAP Dictionary to speed up access to data in a table. These indexes are also created in the database.

There are three different type categories in the ABAP Dictionary:

Data elements: Describe an elementary type by defining the data type, length and possibly decimal places.

Structures: Consist of components that can have any type.

Table types: Describe the structure of an internal table.

Any complex user-defined type can be built from these basic types.

Example: The data of an employee is stored in a structure EMPLOYEE with the components NAME, ADDRESS and TELEPHONE. Component NAME is also a structure with components FIRST NAME and LAST NAME. Both of these components are elementary, i.e. their type is defined by a data element. The type of component ADDRESS is also defined by a structure whose components are also structures. Component TELEPHONE is defined by a table type (since an employee can have more than one telephone number).

Types are used for example in ABAP programs or to define the types of interface parameters of function modules.

The ABAP Dictionary supports program development with a number of services:

Input helps (F4 helps) for screen fields can be defined with search helps.

Screen fields can easily be assigned a field help (F1 help) by creating documentation for the data element.

An input check that ensures that the values entered are consistent can easily be defined for screen fields using foreign keys.

The ABAP Dictionary provides support when you set and release locks. To do so, you must create lock objects in the ABAP Dictionary. Function modules for setting and releasing locks are automatically generated from these lock objects; these can then be linked into the application program.

The performance when accessing this data can be improved for database objects (tables, views) with buffering settings.

By logging, you can switch on the automatic recording of changes to the table entries.

The ABAP Dictionary is actively integrated in the development and runtime environments. Each change takes immediate effect in the relevant ABAP programs and screens.

When a program or screen is generated, the ABAP interpreter and the screen interpreter access the type definitions stored in the ABAP Dictionary.

The ABAP tools and the Screen Painter use the information stored in the ABAP Dictionary to support you during program development. An example of this is the Get from Dictionary function in the Screen Painter, with which you can place fields of a table or structure defined in the ABAP Dictionary in a screen.

The database interface uses the information about tables or database views stored in the ABAP Dictionary to access the data of these objects.

The structure of the objects of application development are mapped in tables on the underlying relational database.

The attributes of these objects correspond to fields of the table.

A table consists of columns (fields) and rows (entries). It has a name and different attributes, such as delivery class and maintenance authorization.

A field has a unique name and attributes; for example it can be a key field.

A table has one or more key fields, called the primary key.

The values of these key fields uniquely identify a table entry.

You must specify a reference table for fields containing a currency (data type CURR) or quantity (data type QUAN). It must contain a field (reference field ) with the format for currency keys (data type CUKY) or the format for units (data type UNIT). The field is only assigned to the reference field at program runtime.

The basic objects for defining data in the ABAP Dictionary are tables, data elements and domains. The domain is used for the technical definition of a table field (for example field type and length) and the data element is used for the semantic definition (for example short description).

A domain describes the value range of a field. It is defined by its data type and length. The value range can be limited by specifying fixed values.

A data element describes the meaning of a domain in a certain business context. It contains primarily the field help (F1 documentation) and the field labels in the screen.

A field is not an independent object. It is table -dependent and can only be maintained within a table.

You can enter the data type and number of places directly for a field. No data element is required in this case. Instead the data type and number of places is defined by specifying a direct type .

The data type attributes of a data element can also be defined by specifying a built-in type , where the data type and number of places is entered directly.

A transparent table is automatically created on the database when it is activated in the ABAP Dictionary. At this time the database-independent description of the table in the ABAP Dictionary is translated into the language of the database system used.

The database table has the same name as the table in the ABAP Dictionary. The fields also have the same name in both the database and the ABAP Dictionary. The data types in the ABAP Dictionary are converted to the corresponding data types of the database system.

The order of the fields in the ABAP Dictionary can differ from the order of the fields on the database. This permits you to insert new fields without having to convert the table. When a new field is added, the adjustment is made by changing the database catalog (ALTER TABLE). The new field is added to the database table, whatever the position of the new field in the ABAP Dictionary.

ABAP programs can access a transparent table in two ways. One way is to access the data contained in the table with OPEN SQL (or EXEC SQL). With the other method, the table defines a structured type that is accessed when variables (or more complex types) are defined.

You can also create a structured type in the ABAP Dictionary for which there is no corresponding object in the database. Such types are called structures. Structures can also be used to define the types of variables.

Structures can be included in tables or other structures to avoid redundant structure definitions.

A table may only be included as an entire table.

A chain of includes may only contain one database table. The table in which you are including belongs to the include chain. This means that you may not include a transparent table in a transparent table.

Includes may contain further includes.

Foreign key definitions are generally imparted from the include to the including table. The attributes of the foreign key definition are passed from the include to the including table so that the foreign key depends on the definition in the include.

You must maintain the technical settings when you define a transparent table in the ABAP Dictionary.

The technical settings are used to individually optimize the storage requirements and accessing behavior of database tables.

The technical settings can be used to define how the table should be handled when it is created on the database, whether the table should be buffered and whether changes to entries should be logged.

The table is automatically created on the database when it is activated in the ABAP Dictionary. The storage area to be selected (tablespace) and space allocation settings are determined from the settings for the data class and size category.

The settings for buffering define whether and how the table should be buffered.

You can define whether changes to the table entries should be logged.

The data class logically defines the physical area of the database (for ORACLE the tablespace) in which your table should be stored. If you choose the data class correctly, the table will automatically be created in the appropriate area on the database when it is activated in the ABAP Dictionary.

The most important data classes are master data, transaction data, organizational data and system data.

Master data is data that is rarely modified. An example of master data is the data of an address file, for example the name, address and telephone number.

Transaction data is data that is frequently modified. An example is the material stock of a warehouse, which can change after each purchase order.

Organizational data is data that is defined during customizing when the system is installed and that is rarely modified thereafter. The country keys are an example.

System data is data that the R/3 System itself needs. The program sources are an example.

Further data classes, called customer data classes (USR, USR1), are provided for customers. These should be used for customer developments. Special storage areas must be allocated in the database.

The size category describes the expected storage requirements for the table on the database.

An initial extent is reserved when a table is created on the database. The size of the initial extent is identical for all size categories. If the table needs more space for data at a later time, extents are added. These additional extents have a fixed size that is determined by the size category specified in the ABAP Dictionary.

You can choose a size category from 0 to 4. A fixed extent size, which depends on the database system used, is assigned to each category.

Correctly assigning a size category therefore ensures that you do not create a large number of small extents. It also prevents storage space from being wasted when creating extents that are too large.

Modifications to the entries of a table can be recorded and stored using logging.

To activate logging, the corresponding field must be selected in the technical settings. Logging, however, only will take place if the R/3 System was started with a profile containing parameter 'rec/client'. Only selecting the flag in the ABAP Dictionary is not sufficient to trigger logging.

Parameter 'rec/client' can have the following settings:
rec/client = ALL All clients should be logged.
rec/client = 000[...] Only the specified clients should be logged.
rec/client = OFF Logging is not enabled on this system.

The data modifications are logged independently of the update. The logs can be displayed with the Transaction Table History (SCU3).

Logging creates a 'bottleneck' in the system:

Additional write access for each modification to tables being logged.

This can result in lock situations although the users are accessing different application tables!v

ABAP - Views

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.

Thursday, May 5, 2011

ABAP - Data Dictionary Introduction

Data dictionary provide:
1. Table definition
2. Type definition

Data dictionary can be accessed by transaction code SE11. (SAP Menu->Tools->ABAP Workbench->Development->Data Dictionary).

Table definition.
Display table definition.Go to Transaction Code SE11, enter table name (example: SFLIGHT), click Display.

You can assign the data type, length and short text in different ways:
1. You directly assign the field a data type, field length (and if necessary decimal places) and short text in the table definition.
2. You can assign the field a data element. The data type, field length (and decimal places) are determined from the domain of the data element. The short description of the data element is assigned to the field as a short text. In above case, all fields refer to data element (Field CARRID refer to date element S_CARR_ID). We will explain about data element in Type Definition below.To toggle beetween data element / direct type method click button "Data Element/Direct type".
To display table content, click Utilities -> Table Contents -> Display, then click Execute (F8).
Type DefinitionWe can define type as reusable object. It means that when we create new table, we can create field refer to data element. These type attributes can either be defined directly in the data element or copied from a domain. Data element is an object where we put short text for field, and domain is an object where we store information like data type (CHAR, NUMC) and its length. We can see relation beetween table field, data element and domain in figure below.

Benefit of using this hierarchy is when you change domain, for example change field length, it will change all field length for all table using this domain.
To open a data element, go to TCode SE11, select data type, and enter data element name (for example S_CARR_ID). You will see in this screen that data element S_CARR_ID refer to domain S_CARR_ID ( in this case, data element and domain have a same name), and also display field label tab, it contain short text that appear in short text of table field.
To open a domain, go to TCode SE11, select domain, and enter domain name (for example S_CARR_ID), you will see that this domain have CHAR (character) data type and field length 3.