The ABAP Dictionary SAP BASIS

The ABAP Dictionary, known usually as data dictionary, is the central workbench repository utility providing the data definitions and the information relationships that are later used in all the SAP business applications. The ABAP dictionary can be seen as a logical representation or a superior layer over the physical underlying database. The supported database engines must comply with the relational data model. This model is strictly followed by the ABAP dictionary. A data dictionary in computing terms is the source of information in which the system data are defined in a logical way. The data dictionary is the centralized and structured source of information for business applications and the core of a well-structured development environment.

Around a data dictionary, you can assemble other components of a development environment as a programming language, of context-sensitive editors, screen painters and handlers, and so forth. The elements that make up a dictionary are known as metadata. Metadata is the computing term for the data whose function is to describe other data. Actually, the data of the dictionary are not the operational data that tell a customer's address or an article price, but rather a type of data whose function is to define the semantic or syntactic properties of the operational data, such as the type, length, and relationships.

Currently, the relational databases and the transactional systems in general all have and all use a data dictionary as the system core. An advantage of having a data dictionary is avoiding inconsistencies when defining data types that will later be used in different parts of an application; this avoids redundancies and considerably decreases the cost of maintenance. When a type of data is defined in the dictionary, it is available to any program or function module in the application. A change in the definition of a type of data in the dictionary automatically affects any other data, module, function, or program that has data or variables defined using that modified data type. This can be useful when you want to modify all related data types, but at the same time and for the same reason, you must be extremely careful not to negatively affect other system parts (other types or programs) using those data types.

The data dictionary allows developers and system managers to create, modify, or delete data definitions (data types). At the same time, it's a great source of information, not only for the development environment but also for the user—it is a fast and efficient way to answer questions such as which entries exist in a table of the database; what the structure of this table is; this view ...; and what the relation between two different dictionary objects is.

The ABAP Dictionary in SAP Systems

The ABAP dictionary data is the core of the ABAP development environment. It is the source of every definition within SAP applications, from the very basic domains to the company model. It is totally integrated with the other tools of the development environment. The integration of the ABAP dictionary with the development workbench is an active integration. Activating any modification in the data definitions has an immediate effect in all related ABAP programs, function modules, menus, and screens.

Some of the main available functions in the ABAP dictionary are the following:

  • It allows you to add, delete, modify, and, in general terms, manage the definitions of the dictionary data (activation, version handling, etc.).
  • It allows you to reserve the data integrity.
  • It is a central source of information. From the dictionary, you can get information about the defined relations between the system tables.
  • It allows direct access to the data in the underlying database system. The dictionary tells whether a table is active, empty, or contains data, and so forth.
  • It acts as the central layer for software development. The ABAP dictionary is an active component of the SAP environment. Every created or modified element of the data dictionary (every definition) can simultaneously and automatically be used in every software component that includes that definition.
  • The ABAP dictionary is integrated in the development environment and in the SAP application environment using call interfaces. With those call interfaces, the programs can directly access the information stored in the dictionary. At the same time, all the development workbench tools can directly access the data dictionary for creating menu definitions, generating screens, reporting functions, and other activities that always have up-to-date data definition information. For example, when declaring a table inside an ABAP report, there is no need to declare the structure of the table—you only need to declare the name of the table itself. At program generation time, the system directly accesses the data dictionary to look for its structure and properties.
  • The ABAP dictionary permits the documentation of the system data.
  • The dictionary also provides some services that are not directly related to the database for supporting the development environment, for instance, the online documentation associated with the screen fields (accessed when pressing the F1 help key) or the possible entries list for a field (when selecting the F4 function key).
  • The objects created in the ABAP dictionary are themselves data objects within the underlying database. In general, the database tables related to the dictionary start with "DD."
  • The dictionary ensures that the data definitions are flexible and can be updated. Because the SAP system uses an interpretative method, instead of working with original objects, it actually works with internal representations of objects. With this type of operation the system performance is enhanced and has the advantage that the development tools, screen interpreters, database interface, and so forth always access the most current data.When any of the data dictionary objects are used in other parts of the development workbench, for example, within a source code program or in a screen, the developers only have to enter a table name or position the corresponding field in the screen.

The system automatically knows all the object properties and information and automatically creates and initializes all the work areas, symbol tables, and so on. Entering one or more table names with the X TABLES keyword allows the system to automatically know, even in the program edition phase, the properties for the tables and fields making up those tables. For example, if an ABAP report contains the declaration TABLES: TABNA, all information about this table, such as primary key, indexes, field names, and data types, that are all defined in the data dictionary is retrieved when the program is generated.

Any changes to the table do not require the source code for the program to be modified except when explicitly using field names that have been removed from the table structure. When the programs are called after a table structure change, they are automatically regenerated without user intervention, always making the most updated information available by retrieving it from the ABAP dictionary. Before entering the definition of the object types and services of the data dictionary, let's briefly review some important concept and tools of the Dictionary.

Object Activation

There will be many occasions where there is a need to change some objects, which are already being used by other objects within the repository. When the modifications are not simple, that is, when you have to modify many related objects (domains, structures, tables, etc.), you could end up with some inconsistencies in the system. To avoid that unwanted circumstance, the system includes the activation concept, by which two versions of the objects are maintained. The "active" version is the one being used by the other repository objects, and a "saved" version is not used by them. When we are finished modifying all the repository objects, we can activate the set of related objects, guaranteeing a stable environment.

Sometimes the system also activates repository objects indirectly when they use other objects or elements that were previously modified and activated.

Where-Used List

On some occasions, before modifying an element of the DDIC, you need to know whether there is dependence between objects. For example, if you modify the structure of a table, you need to compile the whole ABAP processes that use such a table to verify if the update will create inconsistencies in the system. To facilitate this labor, there is a tool in the system that you can use, known as a "Where-Used List." To access this utility, from the main Data Dictionary screen, select the menu option Utilities | Where-Used List.

The system shows a dialog box with a selection screen to mark the different types of objects for which we want to perform the search.

Where-Used List dialog box

Where-Used List dialog box

Once the object types are selected, press ENTER, and you will get a list of references from which you can perform further navigation.

Where-used list example

Where-used list example

Repository Information System

The Repository Info System, transaction code SE84, is a very useful reporting engine for the whole development environment. Within this tool we have a subtree for finding information about the data dictionary.

Repository Info System

Repository Info System

From this tool, we can look for cross references of any dictionary object. For example, if we want to find all domains (we'll discuss the domain concept later in this chapter) that start with "kn" and of the alphanumeric type, we would do the following: Open the ABAP Dictionary menu tree by clicking on the arrow in the left panel, and then select Domains by double-clicking over it. The system will show new selection fields in the right panel. Enter "kn*" in the Domain field and the value "CHAR" in the Data Type field. Next press the Execute button.

Finding domains in the Repository Info System

Finding domains in the Repository Info System

The system will show a listing with all the hits. From the list we can select those "domains" we want to display. Just mark the corresponding check box and click the Display button.

Hit list of domains

Hit list of domains

The system shows a screen with the first object selected as if we were using the SE11 transaction (initial ABAP Dictionary screen) and also shows in the lower window the list of all selected objects in the previous screen. Double-click on the element to navigate the objects. The action buttons of this new window can be used to remove previously selected objects.

ABAP Dictionary Objects

The objects that can be defined and managed with the ABAP dictionary are as follows:

  • Domains
  • Data elements
  • Structures
  • Table types
  • Tables
  • Views
  • Indexes

The services that can be defined with the dictionary are as follows:

  • Search helps for field data entry
  • Field help (documentation)
  • Lock objects

Domains

Domains are used to make technical definitions that are used by the data elements. The technical attributes defined within a domain are as follows:

  • Field type
  • Length
  • Decimal positions

It's not strictly mandatory to use a domain when defining a data element. We can directly define the type and length; however, the type must be a predefined one.

Displaying domain definition

Displaying domain definition

Domains can also be used to define the range of valid values for the field to which they reference, but exclusively when they are used in screen fields. That means that these values do not restrict, for instance, updated SQL statements in programs. Value restrictions for a field can be performed in two ways:

  • By means of the introduction of fixed values. We can introduce both individual values as well as a range of values. To carry out these inputs, we must select the Value Range tabstrip.
  • Specifying the name of a value table. This input is also performed on the Value Range tabstrip. Unlike the previous method, it is not necessary to carry out this input in the definition of domain. It is necessary to specify the foreign key in the field of the table that uses this domain. The advantage of defining the table in the domain is that when we want to create a foreign key, the system detects this definition and proposes to accept such table.

The foreign keys are used to secure the integrity of the information. To update the foreign keys of a field in a table we must first select the field to treat (clicking the first field of the definition of the field) and press the Foreign Keys icon.

Foreign keys reference

Foreign keys reference

Displaying foreign keys

Displaying foreign keys

Before analyzing the properties of the foreign keys, we must define some concepts:

  • Unique primary key. The definition of a table requires a combination of fields that secure the personalized identification of the table fields. This combination of fields is known as unique primary key.
  • Candidate keys. A table, besides having a unique primary key, can have other candidate keys. This means fields of a candidate key also form the registers of a table.
  • Foreign key table. Table used for the definition of a foreign key field.
  • Verification table. Table used for verifications of consistency of the foreign key field.
  • Foreign key fields. The set of fields that allows accesses to a table of verification from a foreign key field.

The more significant properties in this type of definition are the following:

  • Cardinality. The cardinality describes the existent relationship between the foreign key and the table of possible values of verification. The cardinality always is defined from the point of view of the verification table and the possible values are the following:
    • 1:1—Univocal relationship between the verification table and the table of the foreign key field.
    • 1:N—An entry in the check table can have more than one entry in the foreign key field table.
    • 1:C—An entry in the check table can only correspond with an entry in the foreign key field table, although there can be entries in the check table without correspondence.
    • 1:CN—An entry in the check table can correspond with more than one entry in the foreign key field table, although there can be entries in the check table without correspondence.
  • Field type. This property defines the type of field. The permitted values are the following:
    • Not specified. The field type is not specified.
    • Nonkey fields/candidates. The foreign key fields are not identified by the foreign key table. Therefore, the foreign key fields are not key fields nor are they candidate fields of the foreign key table.
    • Key fields/candidates. The foreign key fields are identified by the foreign key table. A register of the foreign key table uniquely identifies the entries in the foreign key fields.
    • Key fields of a text table. The foreign key table is a "text table" of the check table. This is a subtype of the previous type, key fields/candidates. Text tables is a type of table very often used in SAP systems that is used to maintain multilanguage definitions for the business objects defined in the systems.

Data Elements

Data elements are used to make semantic definitions of fields. They describe an elementary data type that can be used in other dictionary elements, for instance, in tables or data structures. Data elements provide meaning to the domain definitions. The direct attributes for data elements are the following:

  • Search help
  • Labels for screen fields

Using the domain, the data elements acquire the technical settings such as data type, length, and decimal places (if needed). It is not mandatory to use data elements in the definition of a field (structure, table, etc.). We can directly enter the data type and length. This type of definition is known as "direct type." The Hierarchy Domain | Data Element | Field allows the creation of structures that simplifies the definition of the database within the SAP systems. The advantages of making the field definitions using this mechanism are the following:

  • When we modify a domain and activate the changes, all the data elements related to that domain are automatically updated.
  • When a data element is modified (for instance, by means of their associated domain) and we activate those changes, the system will update all the fields of the dictionary that use that domain.
  • When a table field is affected by a change in its related data element or domain, the structure (for instance, a table) is also updated automatically.

As we can see, a simple change in a domain allows us to update multiple changes in the database automatically. Therefore, it is very important to create and define domains and data elements for every application object to be defined in the SAP systems.

Structures

Structures are sets of components of any type. The fields of a structure, and also those of a table, have no entity by themselves, contrary to the definition of domains or data elements. The structures do not have physical correspondence at the database level. These definitions allow us to globally define structured fields that can be used in other dictionary objects or within ABAP programs. Structures can be used in tables or within other structures, which can avoid redundancies when defining these structures.

Table Types

Table types describe the structure of an internal table that can be later used within an ABAP program. This is the way that the system allows for defining internal tables on a global way, that is, that can be used in any type of ABAP program.

Tables

The tables of the ABAP dictionary are an image of the set of tables within the database, and therefore tables are the most important objects within the dictionary. The main characteristics of the tables are the following:

  • Tables are identified by a unique name within the system.
  • A table is made up of columns (fields) and rows (table entries).
  • Fields within a table have a unique name in that table and some attributes are as follows:
    • Whether the field is a key or not. A table can have one or more key fields. The values of the key fields uniquely identify an entry in a table.
    • Field type. The field types of a table are defined using data elements. For the fields of type CURR (currency) and QUAN (quantity) we must specify a reference field and reference table (it can be the same table). The reference field for the currency type must be of type CUKY and for the quantity must be of type UNIT. These references are made field by field.

Technical parameters for a table are the following:

  • Data clas
  • Size category
  • Buffering
  • Logging

Before saving or activating a table of the dictionary, you must enter those technical parameters, and these are very important to optimize the table performance regarding their storage and the access to the table data.To access the technical parameters, from the menu, select Goto | Technical Settings, or just press the Technical Settings button on the application toolbar.

Table technical settings

Table technical settings

Data Class

With the data class parameters you can define the physical area of the database where the data are going to be stored. For instance, for the Oracle database, we are referring to the Tablespace. The possible data classes or storage areas are the following:

  • APPL0
  • APPL1
  • APPL2
  • USER (USER*)
  • Master data (transparent tables)
  • Transactional data (transparent tables)
  • Customizing and organizational data
  • Client data

The physical division of the data according to their nature is established based on the typical use for them. For instance, master data (materials, vendors ...) normally have few modifications, whereas transactional data (accounting posting, sales orders ...) are frequently modified. Organizational data, for instance, currencies, are normally only updated during system implementation or customizing, but once systems are in productive operation, they are rarely modified. It must be noted that customer tables must be assigned to client data classes (USER, USER1, ...) because if they are incorrectly assigned to other class, this can affect the performance of the systems.

Size Category

The size category defines an estimate for the number of rows that the table can have. According to the setting of the size category, the database will decide the value of the storage area. When we create a table, the database reserves physical space, fixed by category to store the table rows. If more space is required, the database will use the size category to determine the size for the extension. It is also important to set this parameter properly because an incorrect value could cause a high number of table extensions. You must take into consideration that the number of extensions can be limited depending on the underlying database engine. This can lead to frequent database reorganizations, and conversely, if the setting is too high for smaller tables, you can have too much unused database storage.

Buffering

Buffering is the feature of the systems to store table rows in the memory of the application servers. With this procedure the access lime to the data is much faster, normally when tables are not heavily updated. The procedure for access to buffered table data is the following:

  • A program requests a database data row.
  • The application server looks for that data in the specific memory for that data type.
  • If the data record is stored within the buffer, the search is done and the system returns the data to the program.
  • If the data record is not in the memory buffer, the regular process of accessing the physical database takes place. Once the program gets the record, it will be kept in the buffer for future access.

A statistical approach used to improve performance estimates is a ratio of 1 to 10, when data are accessed in the application server buffer instead of the database. In any case, the database engines also have some optimization techniques including buffering. When the application server tries to store data rows in the data buffer and there is no more available space, what it does is the asynchronous switching or swapping of the data, letting out of the buffer those data rows that are accessed less frequently. It's very important to control this type of event because excessive swapping might create performance problems on the application server. There might be also performance problems when doing massive updates on the data located in the buffer.

There are three types of buffering:

  • Single records buffer. Only the accessed record is stored in the buffer. In large tables, this might be the only type of buffering permitted.
  • Generic area buffer. The buffer will store all the table entries that correspond to a specific part of the key that has been selected. For example, if the primary key of the table is made up of the first three fields and the generic buffering is established using the first two fields, only the records that match the first two fields of the primary key will be stored in the memory buffers.
  • Fully buffered. The whole table is stored in the buffer. Logically, this type of buffering can only be performed with small tables. When a data record is modified from an application server process, the system includes a synchronization process, in order to avoid inconsistencies within the system. Therefore, the buffering technique is only recommended for those tables that are not frequently modified. The process includes the following phases (for instance, in the case of a full buffering):
  • Initial situation: The data buffer of an application server (let's call it server A) does not have those table records stored because there has not been any accesses to that data since the application server was started. The SAP system has other application servers (for instance, B, C, D, ...) with their corresponding local buffers, which can or cannot have those data records.
  • A program from the application server A accesses some of the records of the table.
  • Because the table has the "buffering" parameter active and we have defined a full buffer, all the entries of the table are stored in the data buffer of that application server A. In this first access, the system will need to request all the information from the database.
  • From that moment, the accesses to that table from that application server will be performed using the data in the buffer, which will increase the performance.
  • We will suppose that the same process happens from another application server (let's call it server B). A program requests access to that table data. Because those data are not in the local data buffer of server B, the system will also access the data from the database, but after that access, the buffer will have all the table records for future accesses.
  • A program or process from server A performs an update to that table, for instance, deletes a record. This server will update a synchronization table (system table) to notify all the other application servers that the table has been modified. This synchronization table reflects which application server performed the update, as well as the entries of the modified table. Additionally, it updates the data buffer with the modifications.
  • At this point, the application server A has the data from the buffer in sync with the database, but this is not the case yet with the other application servers.
  • A program of the application server B accesses some of the data records of the table. Because all the rows of the table are in the buffer, it accesses that information and retrieves the records, which are not actually in the database (deleted in the previous step).
  • At this point, we don't have synchronized data among the application server. The system is providing information that is not current. If this last access to the data was performed from server A, it would not be any problem, because the data buffer is in sync with the database.
  • Now it's time for the synchronization. Every certain period of time, which can be set with a parameter, each application server checks the consistency of its own buffer with the existing entries of the synchronization table. In this way, server B detects that server A made some updates on a table that server B has in its own buffer and sets those entries in its data buffer as "not usable." The last step in the synchronization consists of cleaning the records of the synchronization table.

    From that moment on, any access to the data rows of the table in any of the application servers will be consistent with the actual contents of the table in the physical database, although the same process will happen every time the table is modified or updated by any of the application servers.

  • A program in server B can access the data of the table. Because the table has been marked as invalid in the buffer, the server will access the database and will regenerate the entries in the buffer with the new situation found in the physical database.

The main advantage of this technique is that it minimizes the load in the network. However, if the all the buffers are synchronized every time an update is performed, we would have very significant impact on overall performance. Another disadvantage is that during a short time, some of the data buffers might become obsolete. As a summary for this technique, we must comment that tables with a high number of updates should not have active the "buffering" parameters because this can cause important impacts on the performance due to a high load and swapping of the records in the buffers.

In the transaction code field (OK-CODE) we can enter the command $TAB to reset the content of the data buffer in the application server where the command is executed. We should only use this command when we are aware that there is a synchronization problem in the buffer. In systems with a very large data volume, the process of loading the buffer can last up to several hours, and therefore the use of this command should be restricted with the corresponding authorizations.

Logging

This technical parameter is used to activate the creation of a log over the updated on the table. We should only activate this parameter on a table when we need to analyze the update process on a particular table. Before checking and activating this parameter, and in order for the system to perform the table "logging," it is necessary that the profile instance parameter "rec/client" has a value different from "OFF." Possible values for this parameter are as follows:

  • ALL
  • 000
  • ...
  • OFF
  • "Logging" is performed in every system client.
  • "Logging" is performed in the specified system clients.
  • No "logging" is performed even if the table has the Logging setting activated. Table logs can be displayed using transaction SCU2, Analysis of Changed Customizing Objects and Tables. When we run this transaction, if the instance profile parameter is not active, we will get a warning message.

Evaluation of change logs

Evaluation of change logs

From transaction SCU3 we can not only analyze the modification logs of tables, but we can also display a list of the dictionary tables that have the logging parameter set. Finally, it is very important to observe that this parameter should be only used in special cases and for short periods because it can create performance bottlenecks.

Performance

In order to improve the performance of table access, we can use two techniques:

  • Indexes. This is described in a later section of this chapter.
  • Buffering. We have seen the positive effects of buffering in the previous sections. In the majority of occasions, the creation of indexes with good criteria will improve the performance of the database, but indexes have the disadvantage that it will make the database grow and will also impact the performance in database updates because every new update will have to update also the index.

Likewise, the buffering technique can improve the performance of the accesses of a particular table, but it can also impact the general performance of the system. In conclusion, we see that performance is a complicated issue comprised of the balance between benefits and disadvantages and therefore requires continuous and periodic checking and tuning.

Table Definition Modifications

A very important aspect for the maintenance of the table in the dictionary is the updating or modification of the table definitions. There are some modifications that will not alter the structure of the table at the physical database level. We will deal in this section with those modifications that alter the structure. In these cases, the following situations can happen:

  • Tables without data. There is no problem in this case because the table is deleted (DROP TABLE) and re-created (CREATE TABLE).
  • Tables with data. Under this circumstance, we can have two situations:
    • The table can be modified with an ALTER TABLE statement. In this case, the process is finished without further intervention.
    • The table cannot be modified with an ALTER TABLE statement. In this circumstance, the system will need to perform a conversion process. When we try to carry out a manual activation of the table, the system detects that we cannot carry out the activation for the circumstances previously mentioned and does not allow it, but it proposes a conversion process.

    The steps carried out during a process of conversion are the following:

  • Initial situation: The table has been modified in the dictionary. We have, for example, modified the length of a field. In this situation the system keeps two definitions of table: the active and the saved. The difference between both is the length of one of the table fields. The table contains data and also has indexes that use the modified field. In the database we have, therefore, a table and indexes with a length of one of the fields that has to be modified (converted).
  • The first thing that the system does during the process of conversion is to lock the table so that its structure cannot be modified by any user, even the one that carried out the modification. If this were not the case, we could find the unpleasant situation of loss of data.
  • The table of the database is renamed. The name of the new table follows the naming convention "QCMxxxxx," with "QCM" a fixed value and "xxxxx" the previous name of the table. Also in this step all the secondary indexes defined for the table are erased. It also removes the views that refer to this table. Any program using the initial table cannot use it because it was renamed.
  • Renaming the table activates the version of the new table, that is, it generates the table at the database level but not with the initial name of the table. In this occasion the naming convention is the following: "QCM8xxxxx," with "QCM8" a fixed value and "xxxxx" the previous name of the table. Renaming also creates the primary key of the created table. The created table has no data yet.
  • Now there is a movement or transfer of data between the "QCMxxxxx" and "QCM8xxxxx" tables. For simplifying the description of this step, let's say that the system carries out a type of MOVES-CORRESPONDING using the fields of both structures. Obviously, this is the longest process of the conversion because it requires extra storage space and it is the only step that could create other problems. The more frequent problems that could happen up to this point are the following:
    • Overflow in tablespace. Because there is the need for extra storage, we could have problems with the tablespaces (or similar objects in different database engines). To solve this problem we must increase the storage space of tablespaces.
    • Loss of information if the length of one of the key fields is decreased. When reducing the size of a key field, we could have, logically, lost records for duplicity of keys. We cannot influence the registers that the system will discard. Therefore, if we want to have certain control of this, we must carry out a filter process before beginning the process of conversion.
    • Invalid modification of type. This type of error is not desirable because the situation of the process of conversion reaches a dead end. We must manually recover the original situation of the table before launching the conversion process and discard this type of modification because the system won't be capable of carrying out the conversion. Refer to the online SAP documentation to see more information for this point.
  • Next the system renames the "QCM8xxxxx" table back to the original name, "xxxxx." The secondary indexes are created again. Also, the system creates the views that refer to this table.
  • The "QCMxxxxx" table is erased in the database.
  • The lock of the table is deleted.
  • Analysis of the process. It is always advisable to analyze the result of the process. The system provides the following tools:
    • Transaction SE14—Objects log
    • Transaction SM21—System log analysis (system log, local analysis)
    • Transaction ST22—System dump analysis (ABAP runtime errors)

Obviously, we must review all the ABAP programs that use the modified table because they could be acting in an incorrect way.

Append Structures

The append structures permit us to add client fields to standard tables without having to modify the standard definition of the tables. The append structures are structures of the dictionary that are assigned to one table. If we use the specific customer naming conventions (which is the correct way of doing it), we will ensure that an upgrade process of any type will modify our definitions. When we activate a where table with added append structures, the system adds the fields defined in the append within the database. As happens with other types of structures, the append structures can also be used in ABAP programs in the data object or data types definitions. It is important to emphasize that the name of the fields for fields of the append structures of clients must begin with "ZZ" or "YY."

Unfortunately, the use of append structures is restricted to the following:

  • Transparent tables. You cannot use transparent tables with pool tables or cluster tables.
  • Tables without fields of LCHR or LRAW type. Given the variable characteristics of these fields, they don't permit the compatibility with append structures.

Table Types

The possible types of tables in the dictionary are the following:

  • Transparent type. They are the most frequently used in SAP systems.
  • Pool type.
  • Cluster type.

Transparent Tables

When we activate a transparent table in the dictionary, the database system creates the same table with that definition. The definition in the dictionary is independent of the underlying database configured with the SAP installation (Oracle, MS SQL Server, DB2, and others). The name of the table in the database matches the name used in the definition of the dictionary. The data types used in the definition (dictionary) are converted to the corresponding data types of the used underlying database.

The order of the fields in the dictionary can differ from the physical order of the fields in the table of the database. This permits us to insert fields in the definition without the need of converting the table of the database. Technically, when we add a field in the definition of a table, what is executed in the database is an ALTER TABLE statement. The ABAP programs can access the data stored in these tables in two ways:

  • By means of the statements known as Open SQL. There is a whole of set of ABAP statements that allow us to carry out the common operations with the data of a table, such as reading (SELECT), modifications (UPDATE), new entries (INSERT), or erasing (DELETE) of data. These statements are independent of the underlying database.
  • By means of native statements (Native SQL). We can execute any SQL statements particular to the underlying database engine. To do this, we must include the Native SQL statements between the ABAP sentences SQL EXEC and SQL END.

Views

Often, the data of a business object, for normalization reasons, are distributed in several tables of the database. The database systems provide the possibility of creating objects that relates fields of different tables of the system. These objects are called "views." We can access to the definition of the views from the initial screen of the dictionary.

Views

Views

When defining a view we will find the following technical characteristics:

  • Join of tables. This defines the set of tables that will be related in the view.
  • Projection. This permits us to select the fields (columns) that we want to be part of the definition of the view.
  • Selection. This permits us to select the registers (rows) that we want to use in the view.

There are also other important features of the views that are worth comment. The views can be as follows

  • Inner joins. The view will only include those entries that exist in both tables. The database views implement this type of joins.
  • Outer joins. The table will include all the entries of all the tables in the view, even in the case that there are no entries in some tables. The maintenance views implement this type of join.

We can create four types of views in the system:

  • Database views. They permit us to combine fields of several tables to be used in ABAP programs.
  • Projection views. They permit us to make a select (a projection) of a certain table.

This type of view allows for hiding the complete content of a table to certain users.

  • Maintenance views. These are views that allow a more simple maintenance of complex objects within the application.
  • Help views. These are views that can be used in the search helps. These objects are also created in the dictionary.

In the Table/Join Conditions tabstrip we can enter the name of the tables involved in the definition of the view, as well as the relation conditions between the tables to establish the combination of entries of the tables.

Table/Join conditions

Table/Join conditions

In the tabstrip for the view fields, we have to define the settings for the projection. That is, we have to define the fields to be included in the view. Logically, those fields must belong to the specified tables in the Table/Join Conditions tabstrip. In the Selection Conditions tabstrip we have to enter the selection criteria for the data in the view. That is, we have to enter the conditions that must be met to select those records from the database. The last tabstrip (Maintenance Status) is used to define whether the view is read only or if we allow it to be both read and update access. For the views that can be updated, we can also define whether data maintenance is allowed or not.

Indexes

We can define indexes in the dictionary to increase the performance for data access. These indexes are also created in the underlying database. We can consider an index like a copy of the table, but only including the columns of the table that are defined by the index. The data of the indexes are classified according to the key defined for that index. Given this classification, accessing the data using the index reduces considerably the time to get and read that information, because the system can perform quick binary search using the index key.

We can access the definition and management of the indexes by selecting the menu option Goto | Indexes or just clicking Indexes from the application toolbar. When we create and activate a table, the system creates the table and also an index that is known as "primary", where the key fields of the index matches the key fields of the table. This index can be used when we perform access to the table using key fields for the selection criteria. The remaining indexes are known as secondary indexes.

The table indexes are identified by three characters. The code "0" is reserved for the primary index. The customer indexes must begin with "Z" or "Y." Besides the fields defined within an index (key fields and nonkey fields) the system adds a field with the address (pointer) of the corresponding table. Indexes can be unique or nonunique. A unique index defines which values of the key cannot be duplicated. An example of unique key is the primary key of the table. The nonunique indexes can accept duplicates values in the combination of the key fields.

We can also decide whether the index will be created for some databases. In some circumstances we might consider whether an index is recommended for a particular database; however, it could be not so good for other types of database engines. Fields within the WHERE clause set whether the index will be used for searching and accessing tables, although there are cases in which the system does not use any index for the search (known as table full scan), because there are no criteria of the WHERE clause that match the defined indexes.

When the structure of a table is modified, the system must perform an adjustment of the table indexes. Tables with many updates should not have too many indexes defined because that could create some type of performance bottleneck. We must also try to define table indexes that are somehow related, because the indiscriminate creation of indexes can mean that the database optimizer will not select the right index to use for the table access.

Dictionary Services

Services included in the dictionary are the following:

  • Search helps (F4)
  • Field help documentation (F1)

Field Search Helps (F4)

Field search helps are a common and standard function of the SAP system. They allow the user to enter values for an entry field by selecting them from a list of possible values. The system shows the Possible Entries icon to the right of the field to indicate to the user that the field includes a search help. In order to use that help, we have two options: when in the field, clicking on the Possible Entries button, or just pressing F4. On many occasions, the list of possible entries of a field can be so large that it becomes necessary to perform additional restrictions for the search. One of these restrictions is the number of entries to show, which by default is typically restricted to value "200."If there is no search help defined, the Restriction dialog box is directly related to the field. For instance, when we search for possible values on a date field, pressing the F4 key will show up a calendar.

Calendar as search help

Calendar as search help

An easy way to create a field help, without the need to use the search helps, is the following:

  1. In the definition of a domain, in the tabstrip for the value range, we can enter the list of allowed values, a value range, or a reference table.
    1. In the first section we can enter individual values. We can attach a descriptive text of the value that will appear when the user clicks on the Help button.
    2. We can also enter a value range, which also allows including a descriptive text.
    3. The other possibility is to include a table with reference values. When using this last option, we must perform some additional operations. Let's look at an example. The standard domain "BLART" does not have individual values or ranges but includes the reference table "T003," which is a standard table for Document Types. We are going to use the domain in the definition of the text elements. For example, the data element "BLART" uses the domain "BLART."

Domain BLART with data element

Domain BLART with data element

As we already saw, the data element is used to define the fields of the tables. For example, standard table BKPF includes a field that uses the BLART data element. In the definition of the table we also must define a "foreign key" that allows us to relate the field to a reference table of possible values. To access to this screen, just click on the Foreign Keys button. For example, in the table BKPF, field BLART has a foreign key against the table T003. The system detects that table T003 has been included in the data element used, and therefore it automatically proposes to use the related fields between the reference table (T003) and the foreign key table (BKPF).

Example of foreign keys relations

Example of foreign keys relations

We define fields in ABAP screens (Dynpros) that make direct reference to the fields of the tables in the data dictionary. For example, the initial screen for the FB01 (Post Document, Header Data) is technically known as SAPMF05A-100 and includes the field BLART defined with the reference we described previously.

Attributes for Dynpros

Attributes for Dynpros

With these steps we have created a simple field help. In the example, the user will be able to see the entries from table T003 when pressing F4, over the BLART field, in the initial screen of transaction FB01.

Simple search help

Simple search help

Search Helps

The other possibility for field helps are known as search helps, formerly known in SAP systems as matchcodes. Search helps allow for defining more extensive helps for entering values in screen fields. You can access the maintenance screen for search helps from the initial dictionary transaction SE11.

There are two types of search helps:

  • Collectives, which are used to define a set of elementary helps
  • Elementary, used for defining specifics settings for a search help

Collective Search Helps When we associate to a field a collective search help, the system will show every elementary search help as a tabstrip in the help window. The information entered in a collective search help is the following:

  • Set of parameters for the search help. These are the fields that we will use to associate the help to another element of the ABAP repository, for instance, a field in a table of the dictionary or a screen field. We can enter a default value in the parameters by setting a reference to a memory parameter GET/SET. we can see the standard DEBI with two defined parameters: Customer number (KUNNR) and Company (BUKRS).
  • Individual search help. Some of the individual search helps defined for the standard search help DEBI. By double-clicking on the helps, we will "navigate" to the individual definitions of those search helps. We can include customers' search helps in standard collective search helps. This is technically known as "Append Search Help."

Example of collective search help

Example of collective search help

Included search help

Included search help

Elementary Search Helps Information related to an elementary search help is comprised of the following parts:

  • Name and short description. The short description field is mandatory.
  • Data collection. The possible values or entries for a field are determined at runtime by performing a read access to the database. The selection method or data collection describes which rows will be read. As data collection we have to enter the name of a table or view of the dictionary. For example, using a view we could perform a "previous selection" (refer to the description of views in a previous section), which allows us to filter which records will be read from the database.
  • Dialog behavior. To define the behaviors of a search help window, we can define three types of dialogs:
    • Immediate value display. Once F4 is pressed, the system displays a list of values without showing the restriction or additional criteria screen.
    • Dialog with value restriction. The screen for value restriction is the first one shown. Once a user enters the restrictions or criteria, the system will show the values that match the established restrictions.
    • Dialog depends on value set. This is the most interesting form because the first action that the system does is to evaluate the number of entries to show without any restriction. If the number of entries is less than 100, the list of values will be immediately shown. However, if the number of entries is above 100, then the system will show the restriction value dialog first.
  • "Hot key." This method allows using a search help usually known as "direct notation." This type allows for entering directly in the possible entries field the condition for restricting the search. An example is described in the next section.
  • Parameters. As a general rule, we can say that the parameters defined in this section are the field that are shown in the restricting value dialog and also correspond to the columns of the proposed entries display. There is one exception, when we enter values that can be used in one "search help exit" (see the following entry). Figure shows an example of parameters.
  • Search help exit. These "exits" allow us to enhance the standard features of the search help. Technically, a search help exit corresponds to an ABAP function module. For instance, we could create more complex restrictions; define more dynamic columns in the hit list display, and so on. One of the few exceptions that the SAP systems have when verifying user authorizations are found in the search help exists. If we have several companies running under the same client, a user of a company could see some master data of clients of other companies with these types of exits. In order to avoid this type of potential security problem, we can also implement an AUTHORITY-CHECK function within the exit. Implementing this type of search help exit is not an easy task, and therefore SAP has included some reference examples, such as the function module F4IF_SHLP_EXIT_EXAMPLE.

Search help parameters

Search help parameters&l



Face Book Twitter Google Plus Instagram Youtube Linkedin Myspace Pinterest Soundcloud Wikipedia

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

SAP BASIS Topics