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:
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.
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.
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
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
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
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
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
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:
The services that can be defined with the dictionary are as follows:
Domains are used to make technical definitions that are used by the data elements. The technical attributes defined within a domain are as follows:
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
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:
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
Displaying foreign keys
Before analyzing the properties of the foreign keys, we must define some concepts:
The more significant properties in this type of definition are the following:
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:
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:
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 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 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.
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:
Technical parameters for a table are the following:
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
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:
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.
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 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 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:
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.
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.
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:
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.
In order to improve the performance of table access, we can use two techniques:
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:
The steps carried out during a process of conversion are the following:
Obviously, we must review all the ABAP programs that use the modified table because they could be acting in an incorrect way.
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:
The possible types of tables in the dictionary are the following:
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:
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.
When defining a view we will find the following technical characteristics:
There are also other important features of the views that are worth comment. The views can be as follows
We can create four types of views in the system:
This type of view allows for hiding the complete content of a table to certain users.
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.
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.
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.
Services included in the dictionary are the following:
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
An easy way to create a field help, without the need to use the search helps, is the following:
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
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
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
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:
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:
Example of collective search help
Included search help
Elementary Search Helps Information related to an elementary search help is comprised of the following parts:
Search help parameters
SAP BASIS Related Interview Questions
|SAP CRM Interview Questions||SAP HR Interview Questions|
|SAP ABAP Interview Questions||SAP HANA Interview Questions|
|SAP Crystal Reports Interview Questions||SAP SOLMAN Interview Questions|
|SAP Security Interview Questions||SAP BPC Interview Questions|
|SAP Netweaver Interview Questions||SAP UI5 Interview Questions|
|SAP Smart Forms Interview Questions|
Sap Basis Tutorial
Sap: From Sap R/3 To Sap Netweaver
The Architecture Of The Sap Web Application Server
Sap Netweaver: An Overview
Using Sap Systems
Upgrading To Sap R/3 Enterprise: The First Step Into Sap Netweaver
The Change And Transport System
Development Options With Sap Solutions: Abap Engine
User Management And Security In Sap Environments
Web Application Server System Management
Performance And Troubleshooting With Sap Solutions
Sap For It Managers: Implementation, Planning, Operation, And Support Of Sap Systems
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.