Unicode Enabled ABAP - Overview

Design Goals
􀂄 Platform independence
􀂋 Identical behavior on Unicode and non-Unicode systems
􀂄 Highest level of compatibility to the pre-Unicode world
􀂋 Minimize costs for Unicode enabling of ABAP Programs
􀂄 Improved security, maintainability, and readability of ABAP programs

Main Features
􀂄 Clear distinction between character and byte processing

1 Character 􀂏 1 Byte

􀂄 Enhanced checks prevent programming based on memory layout assumptions
􀂄 Improved conversion facilities
􀂄 Improved dataset interface
􀂄 Improved support for dynamic programming


Unicode Restrictions – String Processing

Character Processing

CONCATENATE cf1 cf2 TO cf3.
IF cf1 CS cf2. ...
String operations are only allowed for character-like operands
􀂋ABAP types C, N, D, and T, STRING
􀂋 Structures consisting only of characters (C, N, D, T)
􀂋 X and XSTRING are no longer considered character-like types

Byte Processing

CONCATENATE xf1 xf2 TO xf3 IN BYTE MODE.
IF xf1 BYTE-CS xf2. ...
􀂋 Variants of string operations for byte processing

-> Addition „IN BYTE MODE“ for statements
-> Prefix „BYTE-“ for comparison operations

􀂄 Only operands of type X or XSTRING allowed


Unicode Restrictions – Length and Distance

Determining the Length and Distance

􀂄 Counted in bytes or in characters? Specify!
DESCRIBE FIELD...LENGTH... IN (BYTE CHARACTER) MODE
DESCRIBE DISTANCE BETWEEN ... AND ... INTO ...

IN (BYTE CHARACTER) MODE.

* Reference : SPC250 - Making ABAP Programs Unicode Enabled

SAP Version Management

Creating Versions
The aim of version management is to record a complete change history of a Repository object. Versions are created automatically at the following times:
Before a Repository object is changed
Each object changed is entered in a change request. If the latest version in version management is not the active version, the version of the object is saved in version management before it is changed. These backup versions are indicated in the version overview with an S or I.
When a change request is released
When you release the change request with the changed objects, versions are created. The request number is displayed in the version overview for the relevant version.
A version is not created when objects are imported for performance reasons. This is not necessary, since the change history of the object was recorded fully in the development system. However, a comment is added to the version overview if an object has changed as the result of an import.
If you want, you can create extra versions of objects during import. This makes sense, for example, if the development system is reinstalled at regular intervals. This leads to the loss of the versions recorded there.

As well as the times mentioned above, versions are also created at the following times:
Before the import
If the newest version in the version database does not match the active version, then a backup version is made immediately before the import. These versions are indicated in the version overview with an S.
After the import
After the import a version is created of each imported object. The number of the imported request is displayed in the version overview for the created version. If an object exists in several requests that are imported at the same time (for example, with tp import all ) only one version is made of this object, after the import of the final request.
You can use these versions to check what was the active status of an object at which time.
You can also set the SAP System so that versions are not created every time you import objects, just when you import objects as part of a relocation with package change. To do this, set the profile parameter VERS_AT_IMP to C_ONLY .
In addition to the versions created automatically, you can also create temporary versions at any time. To do this, use the Generate version function in the maintenance transactions for the Repository objects. You can use these temporary versions to restore the previous version of an object, even while you are developing it. When a request is released, the temporary versions are deleted and replaced by the version active at this time.


Version Management
You can use version management to compare two versions of a Repository object, and display old versions of objects.
You can access version management whenever you are maintaining an object by choosing Utilities ® Versions ® Version management.
You can also access version management from the Transport Organizer (Transaction SE09):
In the initial screen Choose Environment ® Version management. An overview of versionable objects appears. You can display individual object types and search for particular objects.
In the request overview Position the cursor on an object in the object list of a task or request and choose Object ® Versions.
The version display is object-specific and is similar to the display used in normal object maintenance. Object versions can therefore be easily recognized.

Version Overview
The version overview shows the versions stored in the development database (Repository), as well as the historical versions stored in the version database. Both areas can be empty, such as in the following situations:
An object has been newly created and no versions have yet been created.
An object was deleted after versions were stored
Active and/or revised versions are stored in the development database.
The version overview also provides information on the time and release level when the versions were created.
If a transport request is specified for a version in the version database, this version corresponds to the state of the object
when the request was released, if the request is from the current SAP System
or
after the request was imported, if the request with which the object was transported is from another SAP System.
If a request is specified for an active or revised version, the object is currently being edited in connection with this request, or has been imported with the specified request.
The Cat column in the version overview specifies the reason why the version was created. The following values are possible:

" " Version created when request was released
I Version created during import
S Version created due to a system request (for example, for a backup copy before inclusion in a correction or repair)
U Version was created due to a user request (as an intermediate version) at some point in time. When the request is released, these versions are deleted and replaced by a " " version.

The Fla column in the version overview specifies how the version is flagged. The following values are possible:

" " No special flag exists
I The version last created is not the active version, since the active version was overwritten by an import

In the version overview, you can choose the following functions:
Display a selected version
Compare two selected versions
Restore a selected versionThis function requires change authorization for the Repository object concerned.
Remote comparison with versions of the object in another SAP System

Authorizations in Version Management
The authorization for accessing version management is covered by the authorizations for the ABAP Workbench and the Transport Organizer. It is only for the remote comparison with other SAP Systems that you require a special authorization.
To compare versions of with a remote system, use the user TMSADM, delivered by SAP. This user requires the authorization S_TMSADM_SHO (display authorization for Repository objects) in the remote system. This authorization is in the SAP authorization profile S_A.TMSADM of the user TMSADM.
If the user TMSADM does not have this authorization, then a logon screen appears when you use the remote version comparison. You can enter user and password on this screen. The user that you enter must have the authorization for displaying Repository objects. Otherwise the SAP System rejects the remote comparison.
The user SAPCPIC is used for the remote comparison with SAP Systems which have a release prior to 4.5A. The calling SAP System must have an RFC destination, in which the user is SAPCPIC is entered with the corresponding password.
This user requires the authorization S_RFC_VERS in the target system. This authorization is delivered by SAP in the authorization profile S_A.CPIC of the user SAPCPIC.
If you want to prevent a remote version comparison with a particular SAP System, then delete the authorization S_TMSADM_SHO from the profile S_A.TMSADM and the authorization S_RFC_VERS from the profile S_A.CPIC in the system in question.
To allow the remote comparison again, just add these authorizations to the appropriate profiles.


Archiving Versions
Prerequisites
If the version management data tables VRSX and VRSX2 take up too much space on the database, SAP recommends that you start archiving versions.
Archived versions are displayed in the versions overview, and are marked with an X in the column Arch.
If you choose the options Display or Compare for an archived version the SAP System restores the selected versions from the archive to the database, and then displays them.
You can also restore the complete archive files to the version database.
Archived versions can only be restored to the SAP System from which they were archived.
Procedure
To archive versions, or restore complete archive files from the database, proceed as follows:
1) In the SAP Easy Access menu, choose SAP Menu -> Administration -> System Administration -> Administration -> Data Archiving.
2) Enter the archiving object VERSIONS

Developer Traces

The system developer traces are log files which contain technical information about the SAP work processes and other programs. They are normally used by specialized personnel, especially by SAP support, when looking for problems in the SAP kernel or the runtime programs.

These traces can be useful also for administrators, since some of the files sometimes contain the explicit reason and explanation for system errors.

To display the list of developer traces, from the monitoring menu, select Traces -> Developer traces. The system will display a list with the title Error log files.These files are actually
operating system files located under the work and profile directories. To display the contents of any file, justdouble click on them, or select Log file Display from the menu.


The names of all the developer trace files start with the character string dev. The following list shows the developer trace file names.

Component File name
Dispatcher dev_disp
Work processes dev_w, where is the number of the work process
Dynpro (screen processor) dev_dy
Roll dev_ro
Paging dev_pg
Database interface dev_db
ABAP processor dev_ab
Enqueue process dev_eq
System logging dev_lg
Message server dev_ms
SAPGUI dev_st
APPC−server dev_appc
Transport program calls dev_tp
Remote function calls dev_rfc


You can set the level of tracing to be included in the developer trace files by adding the options to the start command lines of any SAP program. The start commands are normally located in the startup profile of the SAP instances. Available options are

¨ TRACE=0. No trace is written to files.
¨ TRACE=1. Write error messages in the trace file.
¨ TRACE=2. Write the full trace.
¨ TRACE=3. Write the full trace including data blocks.

You can set any of the above trace options for the whole instance, by entering the rdisp/TRACE= parameter in the instance profile file.


****************************************************************

Introduction to Tables & Indexces

The following three types of tables are available in SAP R/3:
¨ Transparent tables
¨ Pool tables
¨ Cluster tables





Transparent tables do exist with the same structure both in the dictionary as well as in the underlying database system, exactly with the same records and field descriptions.
The other two types cannot be directly queried in the underlying database, since those structures are only logically known at the SAP level. These structures can be found in the database but not in a directly readable form.






Pooled Tables, Table Pools, Cluster Tables, and Table Clusters


Pool and cluster tables are logical tables. Physically, these logical tables are arranged as records of transparent tables. The pool and cluster tables are grouped together in other tables, which are of the transparent type. The tables that group together pool tables are known as table pools, or just pools; similarly, table clusters, or just clusters, are the tables which group cluster tables.






* SAP recommends that tables of pool or cluster type be used exclusively for control information such as program parameters, documentation, and so on. Transaction and application data should be stored in transparent tables.






Generating the Table in the Database


Once a table is defined in the ABAP dictionary, it has to be created physically in the underlying database. The generation is performed automatically when activating the table using the ABAP dictionary functions.
There are, however, certain restrictions: only transparent tables are automatically generated. Pool− and cluster−type tables are not automatically generated since, from the database point of view, these type of SAP tables do not match database tables.
This implies that non-transparent tables cannot have secondary indexes, since secondary indexes, just as tables, must also be generated at the database level.






Indexes
The purpose of defining secondary indexes for tables (only for tables of type transparent) is to enhance the access time when performing select operations on the table. The secondary indexes allow access to the table information on which they are defined, using a different order than the one for the primary key. Physically, they behave like a record table subset, ordered by different criteria.
The secondary indexes do actually occupy physical space in the database; therefore, every table update implies a real updating of the secondary indexes. So, if defining secondary indexes helps the search performance, they, however, slow down the updating process.

ABAP dictionary object types

Though it is not Mandatory for a BASIS Consultant to know about ABAP Dictionary in depth, it is always help if we can hve knowledge about this.Here is the small introduction.

The ABAP dictionary can handle eight different object types

Table. As previously explained, a table is a two−dimensional data matrix. A table can contain zero or many rows, corresponding to the predefined table structure (entity type). This is, at the same time, a complex structure, which can be made up of one or several fields (attributes). Every row that makes up the database table has the same structure and properties. The fields that make up the structure of the table records, as well as its attributes, permitted value range, and so on, are set when defining the table.


Structures. The object structure refers to the definition of a compound object that does not have any content. It's like a table or a view, but it never has entries: it's only a structure. These types of objects are used in programs for defining data structures or for defining data in the interfaces from the module pools and the screens. The basic difference between structures and tables (or views) is that the structure does not exist at the underlying database system level; however, both tables and views do exist in the database. Structures only exist as definitions in the dictionary. As a result, structures do not need to be activated.


Views. From the relational database point of view, a view is a virtual table. It contains data which are really stored in other tables. The contents for the views are dynamically generated when called from a program or a transaction. In the simplest form, the fields within a view all come from a single table, where you could select all of them or just a few (projections), or select some of the fields of the table according to specific criteria (selection) using the Select option. Other, more complex forms of views allow for selecting fields from different tables which are related by foreign keys (join operation). You can also use the three methods combined for creating a view: projection, selection, and join.


Data elements. They are a semantic definition of the properties and type for a table field. It's an intermediate object between the object type domain and the table field. A field in R/3 is always associated with a data element, which at the same time is always related to a domain. Some properties of table fields in the SAP environment can only be defined at the data element level, for example, the text elements associated with the fields. As an example, suppose there is a table with the fields manager_name and employee_name. These fields could have the same technical description−they could be strings with 30 characters−char (30). They would be, however, different at the semantic level: the meaning is different, since they relate to names of people at different levels in company. This difference is only reflected with the text elements associated to the data elements, but it is also useful for the online help which can be associated with the fields.


Domains. They are the formal definition of the data type from a technical and syntactical point of view. They set attributes including data type, length, possible value ranges, and so on.


Lock objects. These types of object are used for locking and synchronizing the access to database records in tables. This mechanism is used to enforce data integrity, that is, two users cannot update the same data at the same time. The lock object definition includes the table or tables which can be concurrently accessed, as well as the key fields for the access. A lock object request is not only used to lock a single record from a table but also to lock a complete logical object. Defining a lock object in the data dictionary automatically generates two ABAP function modules which allows for locking (ENQUEUE) and unlocking (DEQUEUE) the object.



Search helps. These are objects that can be used for assigning input help (using the F4 function key) to fields. These types of objects are new with release 4.0 and are meant to replace the functionality of matchcodes. The main difference between search helps and matchcodes is that search helps are physically built based on transparent tables. There are two types of search helps: collective and elementary.


Type group. These objects contain ABAP type definitions. From version 3.0 onward, developers can define their own data types based on standard R/3 data types.


Development classes are logical groups of development objects which are related, normally deployed for the same application module, related reports, and so on. Development classes are particularly important for team development, the transport system, and use within the repository browser, application hierarchy, and so forth.

Data Structure and Data Types of an R/3 System

The R/3 System consists of various data types.
Certain types of data are only accessible from a particular client. Such data types include business application data (documents, material master records, and so on) as well as most Customizing settings.
These settings:
Define the customer's organizational structures (distribution channels, company codes, and so on)
Adjust the parameters of R/3 transactions to fit customer-specific business operations
Client-specific data types are closely interdependent. Thus, when application data is entered, the system checks whether the data matches the client's Customizing settings. If there are inconsistencies, the application data is rejected. Therefore, application data usually only makes business sense in its specific Customizing environment.
In addition to client-specific data, R/3 can have other settings that, once defined, are valid for all clients.
This data includes:
Cross-client Customizing, such as printer settings
The R/3 Repository, which contains all objects in the R/3 Dictionary (tables, data elements, and domains), as well as all ABAP programs, menus, CUAs, and so on
In the case of cross-client settings, an ABAP report that was originally developed in a certain client may be immediately usable in another client.


Corresponding to the various data types in the R/3 System, there are various types of changes and adjustments to data.
The R/3 System is delivered in standard form and must be adjusted to the customer's requirements during the implementation phase. This procedure is called Customizing. As shown in the graphic,Customizing includes both client-specific and cross-client Customizing data. An R/3 upgrade may require a limited amount of additional Customizing.
Unlike Customizing, enhancements or adjustments to the R/3 Repository are not required to operate an R/3 System.
To adapt the R/3 Repository to a customer's requirements, the customer can develop in-house software.
In addition, customer enhancements can be added to the R/3 Repository. In this case, customer defined objects are used to complement the SAP delivery standard. The precise locations where enhancements can be inserted are specified by SAP.
Finally, R/3 objects such as reports and table definitions can be modified directly. In this case, the R/3 Repository delivered by SAP is not merely enhanced; it is changed. During the next R/3 upgrade,these modifications may therefore need to be adjusted before being incorporated into the new Repository. The adjustment can be a time-consuming process.


Customizing settings must be transported between clients.
Changes to the R/3 Repository must be transported between R/3 Systems.