SAP Software Logistics

Chapter
SAP SOFTWARE LOGISTICS
ll changes to the software and customizing, which need to be promoted through an SAP application landscape, are managed through a process known as Software Logistics. This SAP term includes all processes and tools that are used to deploy, update, promote, and remove application objects or complete components. There are several processes, procedures, and tools available to the customer in order to achieve this. The most common tool is TMS (formerly known as CTS Change and Transport System) and it is embedded in the SAP Basis layer.
All programs, screens, menus, texts, master data, transaction data, and configuration data reside in tables. These tables are stored in a relational database, which is hosted by a relational database management system or RDBMS. SAP supports various RDBMS vendors like Oracle, Microsoft SQLServer, IBM DB2 (several versions), SAPDB/MaxDB (formerly known as Adabas/D), and Informix4 (acquired by IBM). The development of programs, screens, and menus for SAP configuration is just changing the content of tables. Therefore, the promotion of these changes through a SAP landscape is just a copy process of table data from one system to another system, or from one client to another client.
Informix database support is only available under special conditions
15
16
UPGRADING SAP
Figure 4.1: Database tables in SAP.
In case an ABAP program is developed in system D01 and needs to be promoted to the test system A01, a set of tools is used to extract the data from the table that keeps all the ABAP programs (SAP stores all ABAP programs in table REPOSRC). This extraction is downloaded into two separate flat-files at the operating system level and copied from D01 to the A01 system. On the A01 system, the data is uploaded and inserted in the appropriate tables. A similar process is followed for other types of development or configuration data.
4.1
SAP DEVELOPMENT OBJECTS

In order to manage all these different objects like ABAP programs, reports, screens and table structures, SAP has organized these objects in classes. Each object is identified by its Object-Identifier, which consist of two parts:. The first part is the so-called PGMID and the second is the Object Type. The Object Identifier is used to classify all objects in the SAP system.
4.1.1
Object Classification
The link between objects and their object identifiers is kept in table TADIR, which is better known as the Object Directory. This Object Directory is used by the Transport Workbench to prepare objects for transportation between SAP systems. SAP has grouped their object identifiers in two main groups: Whole- and Sub-object identifiers. Whole object identifiers are referring to one or more objects that can be transported to another SAP system as a single identity. For example, we can take the Whole object R3TR PROG object identifier that consists of several sub-objects.
SAP SOFTWARE LOGISTICS LIMU REPS LIMU REPT LIMU VARI - ABAP Report Source Code Text - ABAP Report Description - ABAP Report Variant
17
We can transport these individual sub-objects separately, however, if we want to transport them together, we just include R3TR PROG into the transport. There are two Whole- object identifiers: R3TR, which refer to transportable objects and R3OB, which are application objects. All subobject identifiers start with LIMU. The combination of the PGMID, object type, and object name is unique in the system and stored in table TADIR. For example, ABAP program RSPFPAR is stored in its own unique row in TADIR as R3TR PROG RSPFPAR. A complete list of supported object identifiers in SAP R/3 can be found in Appendix A, however, SAP BW does have additional object identifiers that are unknown to R/3. TIP In table TADIR, you will find a PGMID that is called HEAD and object type SYST and object name <your database SID. When you have to reinitialize the Transport Organizer with SE06 or STMS after a database refresh using one of SAPs system copy guides, this particular row in table TADIR is adjusted.
4.1.2
ABAP
ABAP is a programming language that is shipped with all SAP software products based on the SAP NetWeaver ABAP AS. The history of ABAP is almost the same as the history of SAP AG itself. ABAP was created as a reporting language for SAP R/2, the predecessor of SAP R/3, in the late 1970s. ABAP stood for Allgemeiner Berichts- und Aufbereitingsprozessor, which in English means General Reporting and Preparation Processor. With the release of SAP R/3 in 1992, SAP also released a new evolved ABAP/4, which stood for Advanced Business Application Programs/fourth generation language. SAP R/1 and SAP R/2 were both programmed in Assembler/370 and at that time ABAP was basically a sequence of assembler macros and instructions. In order to overcome some shortages of ABAP, SAP developed ABAP/3, which was a third-generation language extension of ABAP and offered the ability to create business programs and dialog controlled transactions. The programming language ABAP/4 is accessed through the ABAP Workbench, which allows developers to create programs, screens, and menus. The business functionality of R/3, BW, CRM, SRM, and APO is entirely written in ABAP/4. The combination of ABAP/4 language, the ABAP Workbench, and the scalability of the SAP Basis Kernel helped some companies decide to use it as their enterprise development platform. SAP has evolved this to the standalone SAP Web Application Server as a runtime platform for general applications. SAP still implements improvements on their ABAP AS. Even now a lot of development effort has been shifted into the Java AS space. ABAP supports object
18
UPGRADING SAP orientation and is therefore called ABAP Objects. The latest development includes the support of Web browserbased applications and server-side scripting. SAP answered to the increasing demand for so-called xSP-based Web servers (x Server Pages, like ASP = Microsoft Active Server Pages and JSP = Sun Java Server Pages) with BSP (Business Server Pages). BSP allows developers to combine HTML with ABAP coding and generate HTML output for Web browsers. Both server-based scripting through BSP and client-based scripting through JavaScript is supported. ABAP code is written in the ABAP Editor, which is part of the ABAP (or Developers) Workbench and stored as ABAP source code in table D010S for SAP Basis release up to 4.6C or table REPOSRC for releases as of 6.10. After the program is written, it is generated (or compiled) to executable code. This executable code (also known as report load) is stored in the tables D010L, D010Q, and D010Y for SAP Basis release up to 4.6C or table REPOLOAD for releases as of 6.10.. However, this load is not directly executed by the CPU, but rather through the ABAP Virtual Machine, which resides in the SAP Kernel. This process is more or less similar to the Java language, where the Java source code is compiled by the javac compiler into a platform-neutral class (Java byte code) format that is interpreted by the Java Virtual Machine (jre or java). There is a significant difference between the two byte-code formats; SAP uses Little- and Big-Endian formats to store their compiled coding. Therefore, ABAP report loads cannot be exchanged between a machine, which supports Little Endian (such as Alpha or Intel) and a machine that supports Big Endian (such as SPARC, HP-PA, and PowerPC). In case a database is exchanged between these kinds of machines, all ABAP report loads need to be regenerated. After the generation of the ABAP source code, the resultant ABAP loads are stored in three different tables. The ABAP load consists of four tables in the database: D010LINF, D010L, D010Q, and D010Y. The table D010Y is no longer used as of SAP releases above 4.6. Table D010L or REPOLOAD contains the actual ABAP load, tables D010Q and D010Y contain the line references or the symbol table of the generated program. Table D010LINF contains general information about the load, such as the last time of change and the size of the data in D010L, D010Q, and D010Y. When you run your application servers (dialog instances) in a mixed environment on Intel CISC machines and UNIX RISC machines, you will have double growth in these load tables: both Little- and Big-Endian data will be stored. Every time an ABAP program is changed, it needs to be regenerated before it can be used. If a program has not been generated in advance, the ABAP Virtual Machine will do this on the fly. However, this will impact the end-users response time. During one of the upgrade phases, better know as Repository Switch, the entire library of ABAP programs is changed. However, the ABAP report load is not changed, therefore, all ABAP programs need to be regenerated after the upgrade.
19
Figure 4.2: Edit, compile, and run an ABAP program.
TIP The compilation phase of ABAP programs is known under two terms: generation and activation. Both terms are used by SAP. When you perform an OS/DB migration using the R3load toolset, the ABAP load tables are not copied over. After the migration, you have to run SGEN to populate them again. Its also possible to delete all entries from this table in case of an inconsistency: (1) Be sure all users are of the system (2) Delete all ABAP loads (for Oracle RDBMS): SQL> truncate table SAPR3.D010L; SQL> truncate table SAPR3.D010Q; SQL> truncate table SAPR3.D010Y; SQL> truncate table SAPR3.D010LINF; (3) Run transaction SGEN to regenerate all ABAP loads As of SAP Basis release 6.10 and above, the ABAP Source and Load tables have been changed. The ABAP source is stored in table REPOSRC and all ABAP load is stored in REPOLOAD. Therefore you remove the load inconsistency by just delete all rows from table REPOLOAD only, using truncate table statement. More information can be found in SAP Note 668560.
20
4.1.3
UPGRADING SAP
Development Classes
All objects in the SAP system are grouped in Development Classes. Through this mechanism, development objects that have a logical relationship can be easily managed. Assume your company will develop certain functionality in SAP for business usage, which consists of several ABAP programs, screens, transactions, and tables. All these different objects can be assigned to one single development class. This applies for both SAP objects and for all customer and partner objects. Development classes, which are identified by their unique name, can be created using transaction code SE80 in the Development Workbench. After a new development class has been defined, newly created objects can be assigned to it. Its relatively easy to exchange all development objects belonging to one single development class between two SAP systems. Third-party development objects, for example, certain industry-specific programs, are delivered with their own development class. SAP has extended this mechanism by the introduction of Name Spaces. Development classes are stored in table TDEVC and because there is a maintenance dialog available, they can be maintained using SM30. The TDEVC table has the following structure (most important fields): Field DEVCLASS INTSYS CONSYS CTEXT AS4USER NAMESPACE COMPONENT Type (dimension) CHAR (30) CHAR (10) CHAR (10) CHAR (60) CHAR (12) CHAR (10) CHAR (20) Description Name of Development Class Integration system, obsolete Consolidation system, obsolete Description of development class User/Creator of development class Name space of development class SAP Component
The development class $TMP is a special development class, which contains local objects. These objects are not assigned to a regular development class and therefore can not be transported to another SAP system. The $TMP development class is normally used to perform quick development of programs. However, you can assign local objects to a regular development class, so transportation of these objects to other SAP systems is possible. Since the release of SAP Web Application Server 6.10, SAP has renamed the development class into Development Package or just Package. However, a package is more than just a new name for development classes. Packages can contain other packages as well. Packages are more or less object-oriented development classes.
21
TIP Assume youre performing an upgrade of an SAP instance, which is a copy of another SAP instance, and you need to adjust an object during the upgrade, which is part of a non-existing development. You cannot use TMS during the upgrade; however, ABAP report RSWBODVC (as of SAP R/3 release 4.6) offers the ability to create missing development classes.
4.1.4
Name-Ranges
To make distinction between objects developed by SAP or by its customers, SAP has introduced the concept of name-ranges. Name-ranges are reserved naming conventions, which is used for object-names. Objects, for instance tables or ABAP programs that starts with the letter Z, do belong do the customer. All objects that start with letter Y are reserved for either customers or SAP partners. All other objects are belonging to SAP. Name-Range Y* Z* A* X* Description SAP partners Customer development SAP developments Example Object Table YINVOICE ABAP ZTEST ABAP RSUSR003
When you create a new object in the name-ranges Y* and Z*, you only need to have a developer access-key, which can be obtained from the SAP Service Marketplace. For objects in the name-range A*-X*, you also need an object-key. SAP uses this to keep track of all changed objects that are part of SAP standard delivered objects. Both developer- and object-keys are stored in SAP tables DEVACCESS and ADIRACCESS. Name-range also does exist for customizing tables and generated reports. These individual name-ranges are stored in table TRESC, which has the following structure: Field OBJECT TABNAME FIELDNAME KEYLOW IGNOREFLAG GENFLAG LASTNAME LASTDATE Type (dimension) CHAR (4) CHAR (30) CHAR (30) CHAR (30) CHAR (1) CHAR (1) CHAR (12) DATS Description Object type like REPS or TABU Name of customizing table Field in table Name-range, like Y* and Z* Can name-range be ignored? Generation flag Name of last editor Date of last change
22
UPGRADING SAP For the upgrade, its important to know whether an object is a customerdevelopment object or if its delivered by SAP. The upgrade will preserve all customer-developed objects during the upgrade and restore it afterward. This means custom-created developments are not destroyed.
4.1.5
Namespaces
Namespaces are identifiers assigned exclusively by SAP that enable SAP customers, SAP Partners, and SAP itself, to develop objects, components, and software products without the risk of name clashes. SAP namespaces need to be registered with SAP first before they can be used. This is done online using the following URL: http://service.sap.com/namespace. When you deploy software (ABAP programs, screens, or tables) from thirdparty vendors, it is possible that this software comes with its own namespace. The namespace identifier is included as an object in the transport request as well. All installed namespaces, including SAPs own namespaces, are stored in table TRNSPACE, which has the following layout: Field NAMESPACE ROLE LICENSE EDITFLAG SSRCFLAG SAPFLAG GEN_ONLY Type (dimension) CHAR (10) CHAR (1) CHAR (20) CHAR (1) CHAR (1) CHAR (1) CHAR (1) Description Namespace name Role of namespace License key Modifications allowed SSCR dialog box SAP standard delivered Only generated objects allowed
Since the introduction of namespaces in SAP R/3 4.0B, a significant number of namespaces have been registered with SAP. Some known namespaces are: Namespace /BMC/ /SAPDMC/ /BI0/ /BIC/ /VIRSA/ Owner BMC Software SAP A.G. SAP A.G. SAP A.G. SAP A.G. Description BMC Patrol (Trak) objects Legacy Data Migration Workbench SAP BW standard objects SAP BW customer objects Virsa (SAP GRC)
An object with the name ZTEST, which belongs to a namespace /XYZ/, needs to be identified with /XYZ/ZTEST.
23
4.1.6
Number Ranges
The SAP R/3 database is a large collection of all kinds of documents: purchasing order documents, contracts, HR records, goods movement letters, sales order documents, etc. These different documents are uniquely identified by a document number. This document number is just a sequential number that is generated by SAP or assigned by an external source, for example, the end user of some application. Number ranges within SAP are implemented using Number Range Objects, which are basically kinds of counters. Every time a new document is created, for example, a sales order document using transaction VA01, SAP will use this counter to assign a unique number to this document and increase the value of this counter by one. For each document in the system, SAP has its dedicated Number Range Objects residing in table NRIV. This NRIV table is client specific, which means you can have the same sales order document number in the database, but each belongs to its own client. The table NRIV has the following structure: Field OBJECT SUBOBJECT NRRANGENR TOYEAR FROMNUMBER TONUMBER NRLEVEL EXTERNIND Type (dimension) CHAR (10) CHAR (6) CHAR (2) NUMC 4 CHAR (20) CHAR (20) NUMC 20 CHAR (1) Description SAP logon client Name of Number Range Object Number range subobject value Number Range version Fiscal year for document Start range End range Current number External number range
CLIENT (MANDT) CLNT (CHAR (3) )
The maintenance of Number Range Objects is done at two levels as part of the general customizing through IMG (Implementation Management Guide) using transaction SPRO or using transaction SNRO. Transaction SNRO includes all Number Range Objects. A number range is assigned to a particular fiscal year and contains both a start and end value. If the flag EXTERNIND is set to X, SAP will not create a new document number for you, but leaves this up to the user to fill in. Playing around with number ranges can be quite dangerous. Changed values might lead to the creation of duplicate document numbers.
4.1.7
Development Locks
SAP uses a few flags and tables to store Development Locks. These locks are used to protect objects against overwrites and protect the SAP system against
24
UPGRADING SAP duplicate objects. The TLOCK table contains all locks that are used for objects that reside in Transport Requests. As soon as a developer creates an object, an entry is added to the TADIR table. When, during its creation, the object is also added to a transport request, another entry is added to the TLOCK table. All tables that are in maintenance status are listed in table TLOCK. Only when an object is released in TMS will the TLOCK entry will be removed. When another developer tries to change an object, which resides in an unreleased transport request so it has its own entry in table TLOCK, the developer will get an error message. Table TLOCK has the following structure: Field OBJECT HIKEY LEN EDTFLAG TRKORR AUTHOR LOKEY Type (dimension) CHAR (4) CHAR (120) INT (10) CHAR (1) CHAR (20) CHAR (12) CHAR (120) Description Object type (PROG, TABL) Key used in CTS Length of CTS key Special editor required Request/Task Creator of object Key used in CTS
If we create a new ABAP program called ZTEST, the OBJECT field will contain value PROG and HIKEY will contain a text similar to ZTEST yyyyyyyyyyyyyyyy. The second most important lock in the SAP system is the Repair Flag. This flag resides in table TADIR in field SRCDEP. The repair flag is set to X, when an object is changed in an SAP system that has not been marked as a development system. SAP uses this mechanism to protect Consolidation (quality assurance) and Integration (production) systems against modifications. When the repair flag is set to an object in the SAP production system, it will protect this object against overwrites from outside like transports and Support Packages. The repair flag can be removed using transaction SE03. There is a phase in the upgrade process that checks whether there are objects locked in transport requests and whether the system contains repair flags. For the transport locks it checks table TLOCK and for repair flags it checks table TADIR.
4.1.8
Development Keys
In order to develop something in SAP, two keys are required: the object key, which is bound to a certain SAP-shipped object, and a developer key. The object key is only required for SAP objects. This means that customer objects are excluded from this mechanism. Developer keys are required for any developer working on the system. The object keys are bound to each object, listed in table TADIR, and stored in table ADIRACCESS:
25
Field PGMID OBJECT OBJ_NAME ACCESSKEY
Type (dimension) CHAR (4) CHAR (4) CHAR (40) CHAR (20)
Description Object ID (as in TADIR) Object type (as in TADIR) Object name (as in TADIR) Modification key from SAP
This mechanism is put in place as an extra hurdle to manage all changes to standard SAP objects. This table might be of help to check what objects have been changed in the SAP system. The developer keys are stored in another table called DEVACCESS. Table DEVACCESS has the following layout: Field UNAME ACCESSKEY Type (dimension) CHAR (12) CHAR (20) Description User name (as in USR02) Developer key from SAP
TIP If you want to prevent any development in your system, you just delete all entries from table DEV ACCESS. However, you have to be sure no new keys can be obtained from the SAP Service Marketplace. Deleting all entries from table ADIRACCESS, after the upgrade, will prevent developers from modifying standard SAP again.
4.2
DATA TABLES
Data is organized at different levels within the SAP software. Whether its R/3, BW, APO, or CRM, these components are following the same structure. All SAP data is stored in database tables. These tables are organized at development-view level and from a technical-view level.
Figure 4.3: Data table with its attributes.
26
4.2.1
UPGRADING SAP
Table Types
There are several types of tables that SAP supports. These table types are: Transparent tables Pooled tables Clustered tables And besides these three table types, SAP also supports: Structures Views Appends Let us first concentrate on the physical table types. These are tables containing rows (or records) that are stored in the database. An average SAP R/3 instance has more than 10,000 tables in the database. Most of them are transparent tables. A fourth table type would be INDX tables that were introduced with the HR module in SAP R/3. INDX tables are actually transparent tables, but have an extra logical structure on top. This structure is unique to SAP HR and can only be interpreted as such. Transparent tables are tables that have a 1:1 relationship between the SAP Dictionary and the underlying database. If you look at the table definition in transaction SE11, you will see exact the same layout compared with what you see with, for example, SQLPLUS in Oracle.
Figure 4.4: SAP transparent table mechanism.
Pooled tables These logical tables can be viewed by transaction SE11 or SE16, but cannot be accessed directly using SQLPLUS or any other database tool. If you look at the table using any database tool, you will only see the table pool that
27
contains pooled tables. The DBSL is responsible for accessing these tables from within ABAP programs. This means that an ABAP program does not experience the difference between a transparent table, pooled table, or a clustered table. The difference is only noticed when the table is accessed using database tools like SQLPLUS or ODBC. The mechanism of pooled tables was introduced by SAP to support a large number of tables. In the early days of SAP R/3, not all RDBMS vendors were able to support a large number of tables. This was because all customizing of SAP R/3 lies in tables and the number of rows per table can be very small. Therefore, SAP designed a mechanism to combine these small tables into bigger tables. An example of this is the ATAB table, which you can access using SQLPLUS. This ATAB table contains hundreds of small customizing and control tables, such as AT01 and DDSYN. The structure of a table pool is as follows: Field TABNAME VARKEY DATALN VARDATA Type (dimension) CHAR (10) CHAR (n) INT2 (5) RAW (n) Description Pooled table name Maximum key length Length of VARDATA row Pooled table data itself
All the pooled tables are listed in field TABNAME. Data that belongs to that particular table is stored in field VARDATA, which is a RAW data field. RAW data fields normally can not be accessed using a database tool like SQLPLUS.
Figure 4.5: SAP Pooled table mechanism.
28
UPGRADING SAP Clustered tables are similar to pooled tables in the sense that they are also not accessible using database tools like SQLPLUS at the RDBMS level. The SAP DBSL layer takes care of the proper access by ABAP programs. Clustered tables are logical tables that are grouped together in a table cluster or just cluster. Clustering of tables is supported by most of the RDBMS vendors and its therefore not a SAP-specific mechanism like pooled tables. Tables that are clustered do have a common set of keys and therefore clustered tables and table clusters share a set of data fields. Field CLKEY1 CLKEY2 . CLKEYN PAGENO TIMESTMP PAGELN VARDATA Type (dimension) CHAR (*) CHAR (*) . CHAR (*) INT2 (5) CHAR (14) INT2 (5) RAW (*) Description First key field Second key field .. Last key field Number of next page Time stamp field Length of VARDATA row Other fields data
Figure 4.6: SAP Clustered table mechanism.
An example of a table cluster is the RFBLG table, which is used by the FI module in SAP R/3. It contains the table BSEG that contains all financial posting documents.
29
Figure 4.7: Relationship between BSEG and RFBLG.
Performance of accessing data is the main reason to put tables in a cluster. It requires a significantly lower number of disk I/Os to access data and therefore its purely a performance gain. However, there are also drawbacks to pooled and clustered tables. You cannot access them directly from the RDBMS level. This means that if you want to use external (third-party or custom written) programs to access this data, you have to use ABAP instead or you have to start considering converting the data. SAP allows you to convert certain pooled and clustered tables to transparent tables in order to make them more open. However, first read the appropriate OSS notes before you start using transaction SE14 to do this job. During upgrades it can happen that pooled and clustered tables are converted into transparent tables. Since the first release of SAP R/3 back in 1992, SAP has reduced the number of pooled and clustered tables significantly. Modern SAP tools like BW, CRM, APO, and SRM do not contain pooled or clustered tables at the application level. Besides real tables, SAP also supports virtual tables, such as views, structures, and appends. Views are data access objects, which offer a certain view to one or more tables. Views are constructed using SQL statements like: CREATE VIEW V_T000 AS SELECT MANDT, NAME FROM T000; This view, V_T100, will only show the fields MANDT and NAME of table T000. Structures are memory-only structures that are runtime bound. This means that the table structure is created at the initialization step of an ABAP program and is destroyed at the end. Structures are used to organize and map data in
30
UPGRADING SAP programs, which does not have to be stored permanently. Structures are often used in combination with internal tables. Internal tables are tables that only exist in memory and can be compared with an ARRAY in Pascal of BASIC or a STRUCT in C. As of SAP AS 6.40 ABAP, a new concept of Shared Memory Object was introduced. This shared object is basically a Structure that can be shared between work processes and therefore is not destroyed at the termination of the ABAP program. Appends are additional fields added to existing tables. Appends can be added to tables by using include constructions.
4.2.2
Table Delivery Types

Table Delivery Types is a mechanism to protect tables against changes, overwrites, and deletions that occur during upgrades and Support Packages. Each table has a Delivery Type, which is an attribute that tells the Software Logistics tool how to treat this table. These are the table delivery types to consider: Table Delivery Types A Application Table S System Table W System Table E Control table C Customizing table Description Example Table
Protected against SAP MARA, USR02, EKKO, import, only insertions KNA1 Maintenance by SAP only Maintenance by SAP only CCPROF DD02L
SAP and customer do have ATR1 different name ranges Maintenance by customer, T001, TVKO SAP will not change entries in this table
G Customizing table Protected against SAP RFCDES import, only insertions With by SAP, we mean SAP Support Packages or SAP Release upgrades. The Delivery Type attribute is stored in table field DD02L.CONTFLAG.
4.2.3
Table Data Classes

The data class determines the link between the SAP database table and its physical or technical location. Each table has a so-called TABART attribute, which assigns the table to a data class. The following data classes (or TABARTs) exist in an SAP R/3 system:
31
TABART name APPL0 APPL1 APPL2 SLDEF SPROT TEMP USER2
Description Master data Transaction data Customizing data Repository switch Temporary tables User-defined tables
TABART name SAUS SDIC SDOCU SLOAD USER1 USER3
Description Exchange tables ABAP DDIC tables Documentation tables Report load tables Source tables User-defined tables User-defined tables
Spool and log tables SSRC
Field DD02L.CONTFLAG contains the value, which assigns each table to a certain data class. The TABART (data class) itself is stored in table DDART and the relationship between a table and the storage container in the database is stored in TA<DB> for tables and IA<DB> for indexes. An SAP R/3 system running on Oracle uses tables TAORA and IAORA to store the link between TABARTs and Oracle tablespaces. TIP When a developer creates its own table in SE11, its possible to specify the TABART of this new table. The TABART will determine in which tablespace the table is created; its therefore important to set a project standard that guides developers to use the correct data classes and thus tablespaces or devspaces. When an additional tablespace is created with a tool like SAPDBA, or BRTOOLS in Oracle, it will also create a new TABART for you. The name convention for this is USERnn, where nn is a sequential number between 0 and 99. TABARTs are also used by the R3load tool, which is part of the OS/DB Migration kit and used during upgrade phase EU_IMPORT.
4.2.4
Indexes
In order to improve access times to the data in the database, its possible to create and use indexes. A table might have one or more indexes defined. However, an index can only be defined for one table only. An index is a separate information container, which has its own name and table spaces and contains certain key fields that are sorted. There are two types of indexes: primary and secondary indexes. The main purpose of secondary indexes is to increase the performance on transparent tables during DML operations. Indexes are maintained per individual tables by transaction SE11 Indexes. TIP SAP software is shipped with a large number of indexes defined. Only add additional indexes when its absolutely required. Indexes might decrease performance when bulk inserts or updates are done on the database. SAP BW offers the ability to drop all indexes for an InfoCube before the data loads and rebuilds them afterward.
32
4.2.5
UPGRADING SAP
Table Technical Settings

Besides TABART assignments, tables also have other technical settings as well. Important settings are Table Category, which is used for table size growth and Table Logging. This table logging can be used to capture all row changes per table. Especially for customizing tables, it can be practical to use table logging. It is not recommended to use it for application (master and transactional) tables because of the large number of rows. Technical table settings are stored in DDIC table DD09L. This table contains the following structure (only the important fields are shown here): Field TABNAME TABKAT TABART PUFFERUNG PROTOKOLL TRANSPFLAG ACTFLAG BUFALLOW Type (dimension) CHAR (30) CHAR (2) CHAR (5) CHAR (1) CHAR (1) CHAR (1) CHAR (1) CHAR (1) Description Table name (like in DD02L) Table size category Table data class (like in DDART) Table buffering indicator Is table logging on? Converted to transparent table? Activation flag Table buffering allowed?
The Size category field is used to indicate the growth rate of the table. Tables that will grow fast need to be stored in large table spaces like PSAPBTABD or PSAPSTABD. The PBUFFERUNG and BUFALLOW fields are used to control the table buffering mechanism of SAP. To increase the query performance of the SAP application, you can switch on memory buffering for certain tables. Table buffering settings of tables can be changed using transaction SE11 Technical Settings.
4.2.6
Table Logging
An import flag (DD09L.PROTOKOLL), which is set per table in the SAP system, is the table logging option. This option allows you to track all changes performed on a certain table. Before this option can be used, the instance parameter client/ rec needs to be set. Support values are: client/rec value OFF Nnn nnn, mmm, ppp ALL Description Table logging switched OFF for entire system Table logging switched ON for this client nnn Table logging switched ON for these clients Table logging switched ON for entire system
33
After the activation of the table logging option, SAP starts to store all data changes in table DBTABPRT (SAP R/3 releases up to 4.0B) or DBTABLOG (SAP R/3 releases 4.5A and higher). Only for tables where the technical setting table logging is switched are taken into account. Because the data can grow significantly, you should only use this option on customizing tables and user-master tables for security audit purposes. The contents of these tables can be viewed using report RSVTPROT or transaction SCU3. You can also use SCU3 to delete obsolete data from these tables. It is important to control the growth of these tables, especially before an upgrade to SAP R/3 4.7 Enterprise. The structure of DBTABLOG will change; therefore, a conversion is required.
4.2.7
DBDIFF
There are tables in the database that are not known to the SAP Data Dictionary and therefore cannot be accessed by SAP through ABAP OpenSQL. These tables are listed in table DBDIFF. Examples of such tables are D010S (ABAP Source up to 4.6C) and MLICHECK (table with the license key information for SAP releases up to 7.00). After a fresh install of SAP, the ABAP program RADBDIF is executed; this program checks whether the table DBDIFF is consistent. Table DBDIFF has the following layout: Field OBJNAME DBSYS OBJTYPE DIFFKIND SOURCE Type (dimension) CHAR (30) CHAR (10) CHAR (4) NUMC (2) CHAR (40) Description Name of DB object (table, view) Name of RDBMS (e.g., Informix) Table, view, index etc. Type of inconsistency ABAP to create DB object
The DIFFKIND field indicates the reason for the difference between the DD (Data Dictionary) and the DB (Database): 01 Mandatory in database, not in dictionary 02 Mandatory in dictionary, not in database 04 Field type(s) difference between database and dictionary 08 Other definition (fields, sequence) in dictionary compared in database 60 Secondary index needs to be created before the primary index 61 Table without indexes 99 Optional object, should not be checked by RADDBDIF Tables like D010S, D010L, D010Q, and MLICHECK are known to the database, but not known to the SAP dictionary and therefore DIFFKIND has value 01. DIFFKIND value 99 is applicable for tables that reside in the database for RDBMS management reasons, such as table MSSQL_LOGIN_INFO on Microsoft
34
UPGRADING SAP SQLServer or table PLAN_TABLE on Oracle and DB/2. For maintenance of the DBDIFF table, SAP created the DBDIFFVIEW object, which can be edited through transaction SM30.
4.3
CUSTOMIZING OBJECTS
Besides physical objects like ABAP programs, screens, and tables, SAP also contains logical objects like Customizing Objects. Customizing objects are implemented through several mechanisms, for example, through views or logical transport objects (individual table rows or keys). All customizing objects can be viewed by using transaction SOBJ, which offers you the ability to see what tables are attached to the object. The information that SOBJ uses is stored in several tables: OBJH (Object Header), OBJT (Object Text elements), and OBJM (Object Method functions). Table OBJH contains all relevant information for customizing objects (only the most important fields are shown here): Field OBJECTNAME OBJECTTYPE CLIDEP LANGDEP ALEDEP OBJCATEG TRCOMPLETE TRDISJUNCT Type (dimension) CHAR (30) CHAR (1) CHAR (1) CHAR (1) CHAR (1) CHAR (4) CHAR (1) CHAR (1) Description Name of customizing object Type of object Is object client specific? Is object language specific? Is object ALE specific? Object category Object transport must be complete Object is disjunct to other objects
The following Customizing object types are known to the SAP system: OBJECTTYPE C L S T V D Description View cluster (transaction oriented) Logical transport object Table with text Individual transaction object View Dummy object (SAP internal usage)
The most common customizing object is that of the type view, which means that when you want to configure the controlling areas in your SAP R/3 system,
35
using transaction SPRO (Customizing IMG), youre basically maintaining view V_TKA01_GD. This customizing object links to the following customizing tables T001, TKA00, TKA01, TKA02, TKVS, and TKVST. The table TKA01 is marked as being the primary table. Tables that are created by the customers themselves using transaction SE11 are also listed in here as type S.
Figure 4.8: Customizing object embedded in IMG.
The fields CLIDEP, LANGDEP, and ALEDEP indicate how these customizing objects need to be treated by client copies, language imports and ALE distributions. The field OBJCATEG classifies all objects in categories: CUST (client-dependent customizing), CUSY (client independent or cross-client customizing), APPL (application object), and SYST (system or workbench object). INFO The content of the SAP delivery clients 000 and 001 are affected by upgrades. SAP only adds or changes values within client 000. See SAP Note 129260 for more details.
4.4
OTHER OBJECTS
Next to tables, ABAP programs and screens, a SAP system also has several other objects. Objects are managed through the Development Workbench and in particular the Object Browser under transaction SE80. These other objects are: Search Helps and MatchCode Object which is a special dictionary object for helping end users find certain documents in the system. SAP, however, has stopped using match codes in their applications. The new search facilities are based on Search Helps and the introduction of an external search and index tool called
36
UPGRADING SAP T-Rex should eliminate the need for embedded search objects. Search Helps are objects that are connected to screen input fields and direct the end user to press F4. This shows a small dialog box that offers the ability to enter the search criteria.
Figure 4.9: Search Helps are implemented as F4 in input fields.
The objects can be accessed through transaction SE11. Data Model Under transaction SD11 a case tool resides that offers the ability to create and edit data models according to the ERD-schema technique.
Figure 4.10: SAP graphics view of ERD data modeler.
Copyright SAP AG.
Screen All dialog screens in SAP are identified as objects. A screen is created or maintained through transaction SE51 (SAP Screen Painter). Each screen consists of one or more screen numbers, which are connected to each other using the screen flow. The ABAP coding is connected to screen numbers using PAI (Process After Input) and PBI (Process Before Input) modules. These modules are event-handlers written in ABAP and are triggered after a user response.
37
Figure 4.11: SAP Screen Painter.
Copyright SAP AG.
Function Module Is a piece of ABAP code that can be called from other programs by using the statement CALL FUNCTION. Function modules are created and maintained through transaction SE37 and contain various attributes. The possible attributes are: Normal Function module: Can be called with CALL FUNCTION statement Remote Function module: This function can be called from within another system using CALL FUNCTION USING DESTINATION. Update Function module: This function code is executed by a UPD or UP2 process asynchronously. This option has four suboptions: Start Immediately: Function module is directly executed Start Immediately, No restore: Same as above, except for restart option Start delayed: This is a so-called V2 update Collective Run: This is a so-called V3 update Menu SAP offers a large number of menus, which can be created and maintained through transaction SE41 (SAP Menu Painter). The created menu items can be used to start certain ABAP programs and transactions. Text Element is an object that can be assigned to a location on a screen. By creating different translations for one text element, SAP offers the ability to make screen language independent. Text elements can be created and maintained using transaction SE32. The transaction SE63 is used for translations. Message are the text messages, which are shown at the bottom of the SAPGUI screen in case of an information notification, warning or error message. All messages are grouped into Message Classes and can be maintained using transaction SE91. There are four types of messages:
38
UPGRADING SAP
Figure 4.12: SAP Menu Painter.
Copyright SAP AG.
Information: Just to inform the user, such as P.O. 354825 has been created. Warning: Just to inform the user of a small issue. Error: To inform the user about a recoverable error. For example, a wrong data entry. Abort: A serious error from which SAP cannot recover from. For example, a situation around an application or database server that is down. BSP Business Server Pages are SAP solution for server-side scripting. The BSP is a dynamic HTML extension that is using the ABAP Personality of the SAP Web Application Server 6.10 or higher. The following example displays five times the text hello world on the Web browser: <%@page language=abap%> <html> <body> <center> <% do 5 times. %> <font size=<%=sy-index%>> Hello World! <br> </font> <% enddo. %> </center> </body> </html> The page is shown at http://<hostname>:8080/sap/bc/mypage, which is exported from the SAP system using transaction SICF to the ICMan (Internet Connection
39
Manager). The BSP pages are objects that are created and maintained through transaction SE80 Object Browser. The page is written in HTML and all ABAP code is added using <% %> tags. SAP also supports Java and Web DynPro for the server-side scripting and supports JavaScript for client-side scripting. Web Dynpro - As of SAP NetWeaver 7.0, the ABAP language has been extended with Web Dynpro for ABAP. This extension fulfills the requirement to create screen-based, event-driven applications that ease the development cycle of user interfaces. The Web Dynpro technology is based on the screen painter with additional options and adopted from the Java community. The screens (type R3TR WDYN) are built using transaction SE80 Object Web dynpro and interpreted by the Dynpro processor. The Web Dynpro for ABAP is based on the MVC (ModelView-Controller) development paradigm.
Figure 4.13: SAP Web Dynpro builder.
Copyright SAP AG.
Once in Web Dynpro, a user screen is painted and ABAP coding can be generated or is added to the various screen elements. The Web Dynpro for Java code is built using the SAP Development Studio, which is the IDE (Integrated Development Editor) for Java in SAP, where in ABAP the code is developed through the ABAP Workbench instead.
40
4.5
UPGRADING SAP
CORRECTION AND TRANSPORT SYSTEM

The Correction and Transport System (CTS) is a toolkit that is available in all SAP Components that are based on the ABAP engine. The CTS is used to manage all development object changes and corrections in the SAP system. It is used to promote these changes in a controlled fashion through a so-called SAP system landscape. It keeps track of all development objects and configuration changes by putting them into change or development requests. The CTS toolkit can be divided into two components. The first component is called CTO (Change and Transport Organizer) and is located in R/3 and accessible through transactions, such as SE01, SE03, SE06, and SE09. The second component is called Transport Tools that consists of several executables like tp and R3trans, which are located at the operating-system level.
Figure 4.14: SAP CTS, CTO, and TMS.
Copyright SAP AG.
The CTO contains three different organizers, each with its own transactioncode. Besides these three, other transaction-codes are available to manage CTO activities: SE01 Transport organizer. SE03 Configuration of the CTO. SE06 Creation of a unique SAP instance. SE09 Workbench organizer: This utility can be used to manage transport requests, which do contain development objects, such as ABAP programs, screens, text, and messages. SE10 Customizing organizer: This utility can be used to manage transport requests, which do contain customizing settings. Since SAP R/3 4.0A, SAP has added new functionality to the CTS toolkit, called TMS (Transport Management System) and can be accessed through transaction STMS.
41
4.5.1
Transport Activities
A variety of tasks are related to CTS. This goes from setting up a system landscape to the promotion of changes through such a system landscape. A system landscape consists of multiple SAP component systems like R/3 or BW, which are logically linked. The functional meaning of such a landscape is the division of a development, a test, and a production environment or system. This setup should guarantee the consistency of all development activities. All transport activities are closely related to both ABAP development and business configuration. Each new development object or configuration change is captured in a so-called transport request. A transport request is a container of objects that contain objects (ABAP programs, screens, menus, texts, messages, table definitions, or structures) or configuration data. In order to keep the production system reliable, a variety of tools are available to promote changes from development to the test system and to the production system. These tools offer the ability to setup a change management and control process and should prevent objects being promoted from development to other systems without the correct approvals.
4.5.2
Transport Management System

The Transport Management System, or TMS for short, is a set of tools and procedures that take care of promoting changes and new developments through a SAP system landscape. In order to fulfill this task a certain deployment setup is developed by SAP. A TMS setup is based on a so-called transport domain concept. A transport domain is a group of SAP instances that can be managed centrally. The most common setup is to cluster all three SAP instances (development, acceptance, and production) within one single transport domain. The transport domain is managed through a domain controller, which can be any machine within the landscape. The most common place to put this functionality would be the SAP development instance. Besides a transport domain controller, a second instance can be set up as being a backup domain controller. In the case of a system or hardware failure on the domain controller, transports can still be executed. In case transports from different landscapes are managed through one single system, a transport domain can consists of multiple system landscapes. The transport requests itself are transported through files, which are stored in the transport directory. All SAP systems that share the same transport directory belong to the same transport group. For UNIX-based SAP systems, the transport directory resides in /usr/sap/trans, which can be NFS exported/imported to other systems in the transport group. The transport domain, domain controller, and transport group all refer to the physical environment. However, at the logical level, we do have transport routes. Transport routes define the route transport requests follow through a SAP
42
UPGRADING SAP landscape. The simplest transport route runs from development to acceptance and further on to production.
Figure 4.15: One transport domain with two transport groups.
The transport layers are part of the TMS setup that can be accessed through transaction code STMS.
Figure 4.16: Standard transport route for three system landscapes.
INFO The official SAP terminology for a development system is Integration System, for acceptance systems its called Consolidation System, and a production system is called a Delivery System.
43
4.5.3
Transport Requests
A Transport Request (also known as a Correction) is a container with tasks. A task is a container with objects. An object can be a table definition, an ABAP program, a screen definition, a text translation, or a customizing setting.
Figure 4.17: Relationships between request, task, and objects.
Each request has at least one task, but it can have more. Each task has at least one object, however, it can also have more. All Transport Requests and Tasks are stored in a single table. This table, E070, has the following structure: Field TRKORR TRFUNCTION TRSTATUS TARSYSTEM AS4USER AS4TEXT Type (dimension) CHAR (20) CHAR (1) CHAR (1) CHAR (10) CHAR (12) CHAR (120) Description Request/Task number Request or Task? Status of request in CTS Target system Owner of request Description of request
A request or task number has the following naming convention: <SID>K9nnnnn; where <SID> is the SAP System Identifier of the system where the request is created. This is usually the development system. The nnnnn is a sequential number that is stored in table E070L. Table E070L contains only two fields, from which field TRKORR contains the last released number. TIP In some cases its nice to make a distinction between Transport Requests belonging to Project #1 and Project #2. By modifying the value specified in field E070L.TRKORR, it possible to manipulate the Transport Request numbers. For example,: all transports D01K900001 until D01K901000 belong to Project #1 and all transports D01K901001 until D01K902000 belong to Project #2. Bear in mind that both projects should run in sequential order and therefore cannot run in parallel.
44
UPGRADING SAP The objects that reside in a task are stored in table E071. Table E071 has the following structure (only important fields are shown here): Field TRKORR A4POS PGMID OBJECT OBJ_NAME Type (dimension) CHAR (20) NUMC 6 CHAR (4) CHAR (4) CHAR (20) Description Task number Position of object in list Object ID (as in TADIR) Object type (as in TADIR) Name of object
Transport Requests can be created upfront by transaction SE01 or on-the-fly when a new development object is created or an existing one is changed. With transaction SE03, certain attributes of Transport Requests can be modified. Before objects can be transported through the SAP system landscape, both tasks and the Transport Request first need to be released. During the release function, under transaction SE01, a co- and datafile are created.
Figure 4.18: The initial screen of transaction SE01.
Copyright SAP AG.
45
The creation of both files is done by tp, which calls R3trans to extract the data from the database and writes it to the locations /usr/sap/trans/data and /usr/sap/trans/cofiles.
Figure 4.19: Files are created once a Transport Request is released.
4.5.4
Transport Tools
The STMS transaction is just a user-friendly shell on top of all kinds of transport tools. The transport tools are responsible for all export and import activities during the transport process. These tools also play an important role during the upgrade of your SAP system. Two major programs form the Transport tools: tp and R3trans. TP, which stands for Transports and Programs, is an executable on the operating system level. This is the primary program doing all uploads, imports, and exports of objects like programs, add-ons, language imports, loading support packages, and upgrades. In other words, every object that is changed, deleted, or added to any of the SAP instances in your landscape is performed by tp. TIP Its important for the Transport Tools tp and R3trans to work with the correct RDBMS shared library, which is vendor specific, such as dboraslib for Oracle and dbadb2slib for DB2. The Transport Tools can find this library by using a LIBPATH environment variable: OS AIX HP-UX Solaris (SunOS) Linux Variable Name LIBPATH SHLIB_PATH LD_LIBRARY_PATH LD_LIBRARY_PATH Variable Value /usr/sap/SID/SYS/exe/run /usr/sap/SID/SYS/exe/run /usr/sap/SID/SYS/exe/run /usr/sap/SID/SYS/exe/run
The tp program uses different methods for this. Either it connects to the database itself or it uses R3trans for this. Or, as a last option, it uses ABAP programs in the SAP system to perform its job.
46
UPGRADING SAP
Figure 4.20: Three methods of tp accessing the database.
The tp program calls R3trans directly via a fork() system call. ABAP programs are started indirectly by using sapevt. The sapevt program triggers the RDDIMPDP (Import Dispatcher) ABAP program, which should be scheduled in the SAP system waiting for an event. The RDDIMPDP program is scheduled in the SAP system using the RDDNEWDP program.
4.5.5
Transport Steps
When an import is done for a particular transport request, regardless of its contents the following steps are performed on the target (or receiving) system: Step 1. Command File Import During this step, the information about the transport request itself is loaded into the target system. Updates are done on tables E070 and E071. Step 2. DDIC Import During this step, information about the layout or structure of the new tables, or table structure changes is loaded in the SAP system and stored in tables like DD01L, DD02L, DD03L, and DD04L. If the transport request does not have table information included, this step is skipped. Step 3. Activation During this step, all new tables or table changes are activated. If the transport request does not have table information, this step is skipped. Step 4. Main Import During this phase, rows or records are loaded from the transport request data file into the relevant tables in the target SAP system by using R3trans. This phase will also import the ABAP source (which resides in table REPOSRC) into the target system. This phase is skipped in cases where there are no data rows to load. Step 5. Match Code Activation This special phase is only performed if match code objects are included in the transport request.
47
Step 6. ADO Import When application-defined objects, such as SAPScipt Forms, are included in the transport request, the import is performed during this phase. Step 7. Version Management During this phase, all version data is updated in the system. This provides the ability to back out to older versions of programs and definitions. Step 8. XPRA Execute Programs After Put / Import In this phase, additional programs run in batches that modify data tables. Step 9. Generate During this phase all ABAP programs or function modules are generated or compiled from ABAP source code into ABAP byte code. This step is only executed when ABAP source code is included in the transport request. Its very easy to determine up front what steps will be executed for a transport request. By using tp showbuffer you can list all required steps per transport request. Besides these nine main steps executed by tp, various other ABAP programs are executed during the import. These ABAP programs are executed by tp though the sapevt program.
Figure 4.21: tp calls sapevt to start ABAP programs.
Each transport request consists of two files: the cofile (control file) and the datafile. The cofile contains metadata about the transport request and the data file contains all data, such as ABAP source, screen definitions, and table row data. The tp tool uses the cofile to prepare the import of the transport request into the SAP system. The information in the cofile is used to determine the sequence of the ABAP programs. Two control tables within the SAP system, named TRBAT and TRJOB, are used as a communication channel between tp and the ABAP programs. The control tables contain certain values, which represent the steps that are performed in the SAP system during an import.
48
UPGRADING SAP
Function Code X J B S N M Y O D V R G
Job Name RDDDIC0L RDDTACOL RDDDIS0L RDDGEN0L RDDGEN0L RDDGEN0L RDDDIC1L RDDVERSL RDDEXECL RDDDIC3L
ABAP Program RDDDIC0L RDDTACOL RDDGENBB RDDGENBB RDDGENBB RDDGENBB RDDDIC1L RDDVERSL RDDEXECL RDDDIC3L
Description ADO export Mass activation TACOB activation Distributor Import conversion Mass activation for enqueue Matchcode conversion Batch conversion ADO import Create version information XPRA execution ABAP generation (compilation)
RDDMASGL RDDMASGL
RDDMASGL RDDMASGL
The following ABAP programs can be distinguished: RDDDICnL, responsible for both table imports as ABAP compilations; RDDMASGL, which does the table activation; and RDDGENBB, which does all the data conversions.
4.5.6
DDIC Import
The DDIC (Data Dictionary) Import phase is used to import information over information, the so-called metadata. For example, if the transport request contains a new table, the information about the layout of this table is imported into the SAP system. Several tables in the SAP system contain information about each table. Table Name DD02L Description Table header information; fields are: tabname Name of table as4local is table activated? tabclass Data class table belongs to (TRANSP, INTTAB, APPEND) CLUSTER, POOL, VIEW,
clidep Whether table is client dependant or not buffered Whether table is buffered in memory DD02T Table texts; fields are: tabname Name of table ddlanguage Language key ddtext Text itself
49
DD03L
Field information; fields are: tabname Name of table fieldname Name of field keyflag Whether field has a key checktable Pointer to check table position Relative position of field in table
DD01L
Domain information; fields are: domname Name of the domain datatype Type of domain length Length of domain in bytes
DD04L
Data elements; fields are: rollname Name of data element domname Which domain the data element belongs
DD09L
Table technical settings; fields are: tabname Name of table tabkat Category of the table tabart Data class table protocol Whether table logging is switched on
The SAP table relationship model on tables and it fields, can be illustrated as follows:
Figure 4.22: Relationship model for SAP tables.
50
4.5.7
UPGRADING SAP
Activation and Distribution

After the information about new tables is imported, or in cases where existing tables have been updated, the new table definition needs to be activated. Each table has three different objects in the SAP system: (1) the definition in the Data Dictionary, (2) a nametab object, and (3) a runtime object. The definition in the Data Dictionary was already described previously. The nametab object is information about the table that is used by the DBSL (Data Base Software Layer) to generate SQL code during ABAP program execution. The nametab itself consist of two tables, namely DDNTT (Table header) and DDNTF (Table fields). The runtime object is the transparent table in the SAP database. This object can be accessed with SQL statements. The entire process of table activation, distribution, and conversion can be illustrated by the following example. This six-step example will show the activation of a table that is revised with an additional field, with and without data.
Figure 4.23: Table activation phase.
In step [1] the original table TAB01 (DDIC, nametab, and runtime object) is shown. In step [2] the table TAB01 is adjusted through transaction SE11 and an additional field is added. In step [3] the table is activated, which means an entry in the inactive nametab (table DDXTT and DDXTF) is created. In step [4] the distributor will determine what conversion method to use: (1) conversion through shadow table QCM<tablename> and a conversion ABAP program or (2) just a drop/re-create or other SQL statement.
51
Figure 4.24: Table distribution phase.
The result of the distribution phase is stored in either table TATAF or TBATG (Table for Batch Conversions). In case TAB01 contains data that needs to be kept, a conversion will be performed, such as in step [5]:
Figure 4.25: Table conversion phase.
The conversion phase first renames the table TAB01 to QCMTAB01 and creates a new table TAB01 according to the new layout. Through an ABAP program, all data is read from table QCMTAB01 and after conversion inserted into table TAB01. After the process is finished, table QCMTAB01 is dropped and new indexes are created.
52
UPGRADING SAP In case TAB01 is empty, the distributor will adjust the table in the database by using conventional SQL statements DROP TABLE/CREATE TABLE or ALTER TABLE. This looks like step [6], Move nametab.
Figure 4.26: Table Move nametab phase.
This move nametab-phase is executed by program tp.
4.5.8
Running the XPRA Job

The XPRA (Execute Report After Put) is a general set of ABAP programs that take care of master data or customizing data conversions, which are affected by the change of certain ABAP programs. This conversion is different from the table conversion related to table layout adjustments. The XPRA reports always run in a batch or background work process. The tp tool uses the RFC mechanism to see whether the job has completed successfully or not. Examples of XPRA reports are: Report RSA1XP04 ensures that the status information for connections to SAP BW systems is set to inactive in the RSASIDOC table. Report AGR_XPRA_REGENERATE_SAP_NEW is taking care of the SAP menu items after the upgrade to a higher version. The execution of XPRA reports is an essential part of the elapse time of upgrades and the implementation of Support Packages. In cases where a severe error occurs and a descriptive SAP note tells you to ignore the message, youre able to exclude the XPRA from the upgrade or Support Package. In order to do this you have to run ABAP report RSXPRAUP and enter the transport request, which contains this
53
XPRA. The name of the transport request can normally obtained from the error log .ELG. INFO For more information on the subject of excluding XPRA programs, see SAP note 122597.
4.6
CLIENT COPIES
After a new SAP R/3 installation, the SAP system is only delivered with the socalled delivery clients: 000, 001, and 066. The client 000 is empty, which means that there is no master or transaction data stored in this client. It is primarily used to manage Data Dictionary objects. In the past, this client was also used to apply Support Packages and to correct Data Dictionary changes through SPDD and SPAU.
Client 000 SAP Reference Client

The SAP Reference Client is shipped by default in any SAP system and contains a copy of all default SAP customizing settings. It contains sample entries for organizational structures and other module-specific customizing. The SAP Reference Client contains settings like: Tables with default settings. (The content of these tables are independent of the organizational units.) No master or transaction data (application data) Default settings for all customizing objects Examples of organizational units (company codes, business area, sales areas, purchase organizations, controlling areas, etc.) During SAP release upgrades, new default settings are written to this client, which may overwrite or replace existing ones. TIP You should not make changes to client 000 as it may be overwritten by applying Support Packages or during SAP release upgrades.
Client 001 Production Preparation Client

The Production Preparation Client is identical to the client 000 SAP Reference Client, which means that table entries (rows) are similar. The only major difference between client 000 and client 001 is the existence of additional example customizing in client 001: tax rules, sample charts of accounts, and certain validation and substitution rules. Client 001 remains untouched during the implementation of Support Packages or a SAP release upgrade.
54
UPGRADING SAP
Client 066 EarlyWatch Client

The SAP EarlyWatch Client is exclusively used by the SAP Global Active Support organization to run GoLive and EarlyWatch reports. This client only contains user-master records and authorization profiles. To prevent customers from using client 000 and 001 for productive usage, SAP provides the ability to create new clients and copy client-specific content from one client to the other. SAP supports different methods to copy content between clients: per table basis, per group of tables, or through an entire client copy. When a client copy is done, SAP offers the ability to do this even between different SAP systems.
Figure 4.27: Local client copy versus Remote client copy.
The recommendation would be to leave all client numbers between 000 and 099 exclusively to SAP, and start numbering clients used by the customer at 100 and above. A typical client layout would look like this:
Figure 4.28: SAP client landscape example.
55
This example with three SAP instances, named Development, Quality Assurance, and Production contains nine clients. There is a separation of clients for business configuration customizing, development of reports and transactions, development of interfaces, and testing. The Gold Config client contains the initial content before a new development life cycle is started. The QAS instance contains three clients for the acceptance process of development and customizing (test against production data), unit testing (both integration testing and data conversion testing), and a separate training client, if required. In some cases it is recommended to have a separate SAP instance for training purposes. And lastly we have the production instance with one single production client. TIP In cases where the client numbers are kept the same throughout the landscape, such as 100-100-100, it is easier to refresh instances by making use of complete database copies. For SAP applications that make use of InfoCubes, such as BW, SEM, or APO, its not possible to have multiple clients in one single SAP instance; therefore, its recommended to use:
Figure 4.29: SAP client landscape for InfoCube-based applications.
Also, for these systems, its important to keep the client numbers the same in case you would like to use entire database copies for system refreshes. TIP When designing new InfoCubes, add the source-system info-object as field. In this case its possible to use one development and test client in BW for multiple development clients. Otherwise you have to run multiple BW systems in order to support multiple clients in R/3. The client copy process itself consists of four major steps: (1) Manual preparation This step is executed by the system engineer and consists of the addition of the new client to the client table, followed by the configuration and scheduling of
56
UPGRADING SAP the client copy. The engineer also has to take care of the database in terms of space requirements. (2) Initialization When the client copy is actually started, it first creates a list of all tables that need to be copied. If table field DD02L.CLIDEP = X, the table will be copied unless the table is added to the client copy exception table by the system engineer. Also, a list of XPRAs is created that are executed after the copy process. (3) Actual copy process During this step, which can take hours, each row of the table belonging to the source client is copied over to the target client. So the copy is within the same table, only the client number (TABNAME.MANDT) is changed. The SQL statement look likes this:
LOOP FOR ALL TABLES in DD02L do IF DD02L.CLIDEP=X and TABNAME not in ClientCopyExceptionTable do LOOP FOR ALL ROWS in TABNAME where MANDT=SOURCENUMBER do INSERT VALUE (TABNAME.MANDT = TARGETNUMBER , TABNAME.FIELD-A = TABNAME.FIELD-A , TABNAME.FIELD-B = TABNAME.FIELD-B , TABNAME.FIELD-C = TABNAME.FIELD-C , . ) ENDLOOP ENDIF ENDLOOP
So the copy process is a copy loop for rows into a copy loop for tables. (4) Postprocessing During the postprocessing phase certain XPRA programs are executed. Besides using the internal client copy method, which is based on SCC3 and SCCL, its also possible to use R3trans. However, its not recommended to use R3trans for internal client copies. The client copy process is executed through transaction code SCC1, which will eventually execute reports RSCLICOP for SAP R/3 releases below 4.6C or RSCLCCOP for higher releases. The steps executed by a client copy are stored in table CCCFLOW. This table, CCCFLOW, contains several fields to control the process. The output logs of the client copy can be viewed using transaction code SCC3.
57
Tables can be excluded from the client copy process using report RSCCEXPT, which offers the ability to add tables to a list of tables that are skipped during the client copy process. There are tables you might consider excluding from the client copy like CDCLS, CDPOS, and CDHDR. These tables are used by the ALE engine. INFO For more information on client copies, have a look at SAP Note 552711Client Copy FAQs
4.6.1
Remote Client Copies

The process of a Remote Client Copy is similar to the Local Client Copy except for a few differences. First of all, there are multiple ways of doing a remote client copy. The first method is based on transaction SCC9 Remote Client Copy. The second method works with R3trans. The SCC9 Remote Client Copy function has significantly improved over time. This process uses an RFC connection between the source and target system. The initial release of the SCC9 functionality was only able to copy tables remotely in sequence. Later versions are able to copy tables in parallel.
Figure 4.30: Remote client copy using SCC9 RFC.
In order to run the SCC9 client copy over parallel RFC links, certain RFC groups need to be put in place. The second option is to use R3trans instead of transaction SCC9. The R3trans method works slightly different. This method uses two command files, one for export and one for import. # R3trans export called: exportclient100.r3t export client = 100 file = /usr/sap/trans/data/clientexport100.dat use commandfile=/usr/sap/trans/cofiles/<COMMANDFILE>
58
UPGRADING SAP
Figure 4.31: Remote client copy using R3trans manually.
# R3trans import called: importclient200.r3t import buffersync=yes client = 200 file = /usr/sap/trans/data/clientexport100.dat First export on source system: source-host> cd /usr/sap/trans/bin source-host> R3trans exportclient100.r3t copy over all files to target system; all logs are written to r3trans.log target-host> cd /usr/sap/trans/bin target-host> R3trans importclient200.r3t The tool R3trans can also be used to copy individual tables over from one system or client to another. # R3trans export Called: EKPO (client 100 only) table copy export client = 100 file /usr/sap/trans/data/tableEKPOcl100.dat select * from EKPO TIP For more information on the various aspects of using R3trans to export clients or individual tables, please have a look at SAP Note 1942.
59
4.6.2
Multiclient Manager
As of SAP Web Application Server 6.40, SAP started to support the MPC facility. MPC, or Multiple Production Clients, offers you the ability to run multiple clients on one SAP system. Until SAP release 6.40, this option was not supported for production systems and was only used in non-production systems such as development, acceptance, and training. The reason behind this strategy change is the so-called ASP (Application Service Provider) market, where different business applications from different companies are transparently hosted on a limited set of SAP instances. The ASP term is now also known as SaaS (Software as a Service). In order to support ABAP programming in an MPC environment, SAP offers a set of tools and programs to prevent conflicts. Transaction MCLIMAN is one of them.
4.7
SUPPORT PACKAGES
Support Packages, also known as OCS (Online Correction Support), are a set of bug fixes that eliminate errors in the SAP system. SAP introduced Support Packages as of SAP R/3 release 3.0A as an addition to release upgrades. Since SAP R/3 3.0A, the delta upgrade has been replaced by the so-called repository switch method. However, applying Support Packages can be compared with a delta upgrade, although you dont change the SAP release. In the early days of Support Packages, when they were still called Hot Packages, SAP never added new functionality into it. Today, additional functionality may be added to a Support Package. The entire Euro Conversion kit was shipped through Support Packages. Support Packages are bound to the SAP release and add-ons used in the system. Fixes in Support Packages, however, are not necessarily bound to SAP R/3 release; it can happen that a certain bug resides in several R/3 releases and therefore needs to be fixed in all those releases. This means that if you upgrade an R/3 4.6C Support Package level 20 system to R/3 4.72 Support Package level 5, you might partially downgrade the system. Figure 4.32 illustrates the location of a certain bug fix in several different Support Package bundles, each belonging to a specific SAP R/3 release. Individual bug fixes are also described in OSS notes, which are known as Source Code Corrections. These ABAP source code corrections can be applied manually using the SE38 ABAP editor. However, its more efficient to use SNOTE Note Assistant or wait until SAP releases a new bundle of Support Packages.
60
UPGRADING SAP
Figure 4.32: Bug fixes can reside in several Support Packages.
4.7.1
Support Package Types

SAP has released several different kinds of Support Packages: Hot Packages (HP), Legal Change Packages (LCP) and Conflict Resolution Transports (CRT). Since SAP R/3 4.6A even more Support Packages have been introduced: SAP_BASIS, SAP_ APPL, SAP_ABAP, and SAP_HRP. And last but not least, with the introduction of SAP R/3 4.7 Enterprise, the Support Package structure has changed again. (1) Hot Packages This type of Support Package was introduced in SAP R/3 3.0A and covers all functional and Basis modules. Has been replaced by SAP_APPL, SAP_BASIS, and SAP_ABAP. (2) Legal Change Packages This type of Support Package is only applicable for an R/3 system running the HR module. It was introduced in SAP R/3 3.1H and has been replaced by SAP_HRP packages. (3) Conflict Resolution Transports This Support Package is basically a fix for modifications of standard SAP. When a customer uses a certain R/3 add-on, such as IS-Oil or IS-Hospital (IS-Heath), these add-ons may modify certain core R/3 objects, such as adding additional screens, programs, or table fields. Normal Support Packages are not aware of these modifications and will overwrite them. CRTs are additional transports that need to be added to the Support Packages in order to prevent such overwrite. (4) SAP_APPL This Support Package type contain fixes for all SAP R/3 modules except HR (Human Resource). (5) SAP_BASIS This Support Package type contains only fixes that belong to the Basis layer, such as fixes for the Batch Engine, CCMS, and User Management.
61
(6) SAP_ABAP This type of Support Package type contains only fixes that are related to the ABAP Development Workbench and other development tools; so all SE-related transactions. (7) SAP_HRP This Support Package type contains only fixes for the HR module and is therefore the successor of the LCP Support Package type.
4.7.2
SAP Patch Manager

The SAP Patch Manager, also known as SPAM, can be invoked by using transaction code SPAM. This tool is used to implement Support Packages in all ABAP-related SAP applications; whether its R/3, BW, CRM, or APO. This toolset, as of now called SPAM, provides the ability to load all kinds of Support Packages from various sources, such as CD-ROMs, file systems, the Internet, and desktop into the SAP system. SPAM has a variety of tools to accommodate the load of Support Packages: (1) EPS Electronic Parcel Service, can be used to download Support Packages from OSS or the SAP Support Marketplace. The EPS stores all downloaded SAR (SAP archive format) files in /usr/sap/trans/EPS/in. (2) SPAM Queue This queue needs to be prepared before the actual load of the Support Package occurs. The queue can contain a mix of different Support Package types, such as SAP_BASIS, SAP_APPL, SAP_HRP, and CRTs. TIP Always check the appropriate OSS notes on the exact SPAM Queue layout. There are restrictions around certain combinations of Support Packages. In other words: not all Support Packages can be combined in one queue. (3) Import Tool The actual tool that does the load of the Support Packages into the SAP system. (4) SPAM Update Manager This tool is used to patch the SAP Patch Manager itself. TIP Always update your SAP Patch Manager with the latest SPAM update before you apply new Support Packages into your SAP system.
4.7.3
Conflict Resolution Transports

If your SAP system also contains add-on components, such as Industry Solutions, you need to take care of Conflict Resolution Transports, or CRTs for short. CRTs contain corrections on top of Support Packages that apply to add-on modifications made to standard SAP.
62
UPGRADING SAP
Figure 4.33 CRT prevents overwriting of add-on modifications.
Figure 4.33 illustrates the modification of Core R/3 by an add-on, such as ISOil. This regular Support Package, however, will overwrite this modification. To prevent that from happening, the CRT will correct this. TIP Always check whether a system contains any add-ons by using transaction SE16, Table Browser, and then check the table AVERS (add-on version table). Also, check all OSS notes related to any add-on described in this table. SAP has introduced many more add-ons besides Industry Solutions. As of SAP ERP2005 or ERP 6.0, all industry solutions are embedded in the core release of SAP. Therefore, CRTs are no longer required.
4.7.4
Support Package Import Phases

After downloading Support Packages from either a CD-ROM or the Internet (using the SAP Download Manager) into the EPS directory, the import queue can be defined. The import phases will use this import queue as the source for all Support Package imports. SPAM executes the following phases during the import of Support Packages: (1) PROLOGUE During this phase, certain checks are done, such as authorization checks, and a check if previous Support Packages are confirmed. (2) CHECK_REQUIREMENTS During this phase, the transport tool tp checks whether it is able to connect to the database. (3) DISASSEMBLE In this phase all EPS packages, located in /usr/sap/trans/ EPS/in, are extracted into individual transport files (both co- and data-files) and stored in /usr/sap/trans/cofiles and /usr/sap/trans/data.
63
TIP Be sure that your /usr/sap/trans filesystem is large enough to hold both EPS and extracted co- and datafiles. Certain Support Package bundles can become very big. (4) DISASSEMBLE_PATCH During this phase, tp will create co-files of every datafile shipped with the Support Package. The exact statement is: tp createcofile s <datafile> (5) ADD_TO_BUFFER In this phase, all transports shipped with the Support Packages are added to the transport buffer. The exact statement is: tp addtobuffer <change request> (6) TEST_IMPORT During this phase, all open repairs and change requests are checked for objects that will be replaced during the import. (7) IMPORT_OBJECT_LIST During this phase, a list of all objects that are shipped with the Support Packages are imported in the system. The list is used to check whether there are conflicts between modifications, add-ons, and these shipped objects. (8) OBJECT_LOCKED_? This phase checks if objects that will be replaced are locked in a transport request. (9) SCHEDULE_RDDIMPDP This phase will check whether RDDIMPDP is scheduled as a periodic job. If not, it will schedule this job. (10) ADDON_CONFLICTS_? In this phase, the list, created in IMPORT_ OBJECT_LIST, is used to check for conflicts between import objects and any of the installed add-ons. (11) SPDD_SPAU_CHECK During this phase, a list of modification adjustments is made and stored in a table that is later presented in transactions SPDD (for Data Dictionary modifications) and SPAU (for ABAP modifications). (12) DDIC_IMPORT In this phase, tp will import all Data Dictionary objects into the system. (13) DELETE_FROM_BUFFER This phase will clean up import buffers. (14) AUTO_MOD_SPDD During this phase, SPAM will check whether certain Data Dictionary object modifications can be adjusted automatically. (15) RUN_SPDD? This phase will prompt you in case adjustments need to be made in transaction SPDD. (16) IMPORT_PROPER This phase, with the longest elapse time, will do the import of all Support Packages. This phase is primarily executed by tp and follows the same steps as an ordinary import request: (a) Command File import (b) DDIC import (c) Activation (d) ADO imports (e) Conversions
64
UPGRADING SAP (f ) Version updates (g) Execution of XPRAs (h) Generation of ABAP programs and screens (17) AUTO_MOD_SPAU Same phase as AUTO_MOD_SPDD, except this time its for ABAP programs and screens. (18) RUN_SPAU? This phase will prompt you when modifications to ABAP programs and screens need to be adjusted. However, due to the fact that ABAP objects can be handled with versions, you may ignore this phase and sort this out at a later stage. (19) EPILOGUE In this phase, some administration and control tables are updated with the correct version information. After applying the Support Packages using SPAM, the administrator needs to confirm the patch queue. The only remaining task is to sort out the SPAU list.
Figure 4.34: Transaction SPAM (Support Package Manager).
Copyright SAP AG.
4.7.5
Support Packages in R/3 Enterprise

SAP has changed the way modules are organized in R/3 Enterprise. Certain functionality has been moved from core R/3 into the so-called Extensions. These extensions are grouped into Extension Sets. Therefore, by disconnecting certain functionality from Core R/3, a new group of Support Packages is introduced as well.
65
Figure 4.35: Different Support Packages in SAP R/3 Enterprise.
Figure 4.35 shows the different component layers of an SAP R/3 4.7 Enterprise system. The second box illustrates the different Support Packages and their interrelationship with SAP R/3 4.7. Besides these new extensions, the number of plug-ins has also been increased. Because applying Support Packages to an SAP R/3 Enterprise system has become more complex, SAP has developed the SPAM Queue Calculator. This tool will calculate the ideal combination of Support Packages in order to prevent conflicts. The second new feature of SPAM in R/3 Enterprise is the Support Package Shadow Import. This feature will reduce the SAP application downtime caused by the import of Support Packages. The idea behind this feature is to import, activate, and convert all objects belonging to the Support Package into a shadow repository and, at the end of all phases, switch to the new coding.
Figure 4.36: SAP Support Package Shadow Import.
Copyright SAP AG.
This new feature provides the ability to reduce SAP application downtime during import of Support Packages by about 60% when compared to the old
66
UPGRADING SAP method. Downtime savings are achieved, especially when the Import Queue contains all kinds of CRTs for plug-ins and other add-ons. Due to this significant savings, SAP has decided to downgrade the functionality to SAP R/3 4.6C as well. This is shipped as part of a SPAM update. The method is relatively easy and based on a set of tables that form the socalled shadow repository and are created in parallel to the existing repository. After the entire Support Packages are imported into the shadow repository, the system will switch from the existing repository to the new shadow repository. This switch is the only phase that requires application downtime. The method described here is similar to what we know from SAP release upgrades as the Repository Switch.
4.7.6
Support Package Stacks

The SP (Support Package) Stacks are sets of Support Packages and patches for the respective SAP release and must be used in the given combination. SAP recommends implementing these SP Stacks regularly. The technology for applying Support Packages and patches will not change. SP Stacks should be seen as an entity unto themselves customers must obtain the minimum requirements and dependencies between individual components, and apply the Support Packages and patches specified in the SP Stack together. The intention of SP Stacks is to offer better mechanisms to apply support packages to complex systems that contain a lot of different components. Therefore, SP stacks are released synchronously.
Figure 4.37: SAP Support Package Stacks.
Copyright SAP AG.
67
4.7.7
Support Packages as of NetWeaver 7.0

With the introduction of SAP NetWeaver 7.0, which is based on SAP Application Server 7.00, SAP introduced a new concept for deploying Support Packages. In the past, Support Packages were directly downloaded through the SAP Support Marketplace, either by Internet Explorer or by the SAP Download Manager. The only requirement was to have access to the download section. However, due to the complexity and number of different Support Packages, SAP has decided to control the download through the SAP Solution Manager. This is done through a tool called the Maintenance Optimizer. Now that all the industry solutions are embedded in our SAP ECC 6.0 system, the number of components has grown significantly. The SAP ECC 6.0 component, which is the central core component of the SAP ERP 2005 Business Suite, consists of a core system (formerly known as R/3) and various add-ons and industry solutions. With the options of embedded installations (also known as MCOS Multiple Components in One System) you can expand the installation functionality even more.
Figure 4.38: SAP ERP 2005 components.
Copyright SAP AG.
Once these components are activated or added to the SAP system they become subject to patch and change management. The implementation of Support Packages to an SAP ECC 6.0 system can be quiet complex. Therefore, SAP has decided to help administrators in this task by supplying tools. Both the SAP Maintenance
68
UPGRADING SAP Optimizer and the SAP SLM (Software Lifecycle Manager) are examples of such tools.
Figure 4.39: mySAP ERP 2005 Business Suite Support Package Stacks. Copyright SAP AG.
4.7.8
Tables Used with SPAM

The SAP Patch Manager uses various tables to keep track of progress, status of each step, and history of all applied patch bundles. The tables are in the PAT*name range: Table Name PAT00 PAT01 PAT02 PAT03 PAT07 PAT09 TEPSIN Patch steps Patch status Conflicts between patches and add-ons Patch directory Patch prerequisites Patch history EPS bundle inbox Table Description
TIP These tables contain some nice information you can use in case of problems, however, it is strongly recommended not to change the contents of these tables yourself.
4.7.9
SPAM Queue Conflicts

Not all Support Packages can be combined in one single queue for import. The reason for this is caused by the way SPAM works. All import steps are performed in sequential order for all objects in the queue. This means that for all included Support Packages, all objects are first imported into the SAP system. Secondly, all objects are activated and at last all data for these objects is imported. So each step is only executed once, regardless of the number of Support Packages.
69
However, it is possible that changes or modifications to certain objects are included more than once. Assume we have a table TABX that is modified in SP1 by adding a new field to it. This extra field, however, is removed again in SP2. Because SP2 is applied after SP1, the table will lack the new field. As soon as the TABIM (table import) phase starts, it will first import all SP1-specific data and then import SP2-specific data. The SP1-specific TABIM phase, however, expects this new field to be there. So the INSERT statement will fail due to a missing table field.
Figure 4.40: Error in TABIM phase due to missing fields.
In this example the error occurs in the TABIM phase, although in most cases the error occurs in the ACT phases when there is an incompatibility between domain definitions, data elements, and table fields. This can all be prevented upfront by importing all Support Packages in batches, which do not have conflicts. Information about possible conflicts between Support Packages can be found in the relevant OSS notes. Search for the term OCS or OSS to find all these relevant notes.
4.7.10 SAP Download Manager

There are several ways to obtain the Support Packages: (1) using transaction SPAM, (2) by connecting to the OSS SAP system in Walldorf, or (3) by requesting for the so-called OCS Bundle CD-ROMs. In order to save costs on CD-ROM media, SAP has introduced a third source for your OCS bundles: The Internet. The SAP Download Manager is a J2SE (Java 2 Standard Edition) based tool that runs on your PC and connects to SAP through the Internet using HTTPS. You first need to add the requested OCS packages to the download basket.
70
UPGRADING SAP This basket is part of the OCS Patch area on the SAP Service Marketplace. So first use the ordinary Microsoft Internet Explorer Web interface for selecting the packages and add them to the download basket, and use the separate SAP Download Manager to really download them to your PC. With the introduction of NetWeaver 7.0, this process has changed (see Section 4.8).
Figure 4.41: Screen-shot of SAP Download Manager.
Besides Support Packages and kernel patches, entire installation and upgrade kits can be obtained using the SAP Download Manager.
4.8
SAP MAINTENANCE OPTIMIZER

In order to keep the Total Cost of Ownership (TCO) low for implementing Support Packages and patches on the SAP NetWeaver and Business Suite, SAP has released a tool that helps to determine the right patch sets. As explained in the previous section, the number of components has dramatically increased and therefore the number of different patches has also increased. By using the SAP Maintenance Optimizer (MOP) the support team can locate the required patch files much easier. The MOP is implemented as a component inside the SAP Solution Manager and deployed through a Support Package. The MOP tool is accessed through Transaction SOLUTION_MANAGER Select Solution Change Management
71
Support Package Stacks. This will show a screen with all the components in your landscape. The MOP is using the SAP Landscape Directory (SLD) to obtain this information. A properly installed and configured SLD is thus a requirement for using the MOP.
Figure 4.42: SAP Maintenance Optimizer in Solution Manager.
Copyright SAP AG.
After the selection of the system, the MOP tool is invoked by pressing the Maintenance Optimizer button. This will bring up the guided procedure for obtaining the right Support Package.
Figure 4.43: SAP Maintenance Optimizer download wizard.
Copyright SAP AG.
72
UPGRADING SAP After the required patch files have been selected, the package needs to be confirmed and is checked by SAP against the license agreement. Once checked, the files appear in the Download Basket residing in the SAP Support Marketplace. As of this writing, the files can be downloaded using the regular process with the SAP Download Manager. This means that the files are not downloaded using the MOP tool. The tool is just used to prepare the download activity. Once done, the files are downloaded to the PC. From this moment onward the process of applying Support Packages is exactly the same as in the past.
4.9
INDUSTRY SOLUTIONS AND ADD-ONS

SAP covers both the horizontal and the vertical marketplace, which means it delivers functional software products for general businesses and for industryspecific businesses. This industry-specific functionality is implemented through IS-Solutions, which are additions to the standard core R/3. Known IS-Solutions are IS-Oil for the oil and gas industry, IS-Media for the media and publishing industry, and IS-Healthcare for hospitals. List of IS-Solutions: SAP for Aerospace and Defense SAP for Automotive SAP for Banking SAP for Chemicals SAP for Consumer Products SAP for Professional Services SAP for Public Sector SAP for Retail SAP for Service Providers SAP for Telecommunications SAP for Media SAP for Mill Products SAP for Mining SAP for Oil and Gas SAP for Pharmaceuticals SAP for Healthcare SAP for High Tech SAP for Higher Education and Research SAP for Industrial Machinery and Components SAP for Insurance
SAP for Engineering and Construction SAP for Utilities
There are two types of IS-Solutions: Solutions that modify the standard core SAP and solutions that do not modify standard SAP. IS-Oil, which was one of the first IS-Solutions released by SAP, for example, does modify standard SAP. This means that standard SAP programs, screens, and tables are modified and/ or overwritten by IS-Oilspecific coding. The result of this is that every time an upgrade is performed or Support Packages are loaded into the system, the system needs to take care of this exceptional situation. When loading Support Packages into the system, CRTs (Conflict Resolution Transports) are loaded with the Support Packages. During upgrades, the IS_SELECT phase will take care of this. However,
73
you still need a special upgrade-software kit, which does contain the new ISSolution. The second type is basically an add-on and is installed on top of the standard core R/3.
Figure 4.44: Two types of SAP IS-Solutions.
An example of the second type IS-Solution is IS-Utilities, which can be installed into an R/3 system that has been already used for several years. . With SAP ERP 6.0 it is possible to use multiple IS-Solutions in a single SAP system. Next to IS-Solutions, SAP has released all kinds of add-ons to R/3 and other components. These add-ons are, for example, PI, or Plug-Ins, that are used for BW, APO, or SAP Enterprise Portals. Other add-ons are, for example, SAP EH&S (Environment Heath and Safety) for management of dangerous goods and SAP FS-CD (Financial Services Collections and Disbursements) for the insurance companies. The installation process is similar to IS-Solutions and may also modify standard SAP coding. Therefore, you need to know what add-ons are installed in your SAP system. As mentioned in previous sections, as of SAP ERP 6.0 all Industry Solutions are embedded in the system by default. However, it just becomes active after the Industry Solution is switched on. TIP Use transaction code BAOV or look at table AVERS to see what IS-Solutions or add-ons are loaded on your system.
4.9.1
Installation Using R3up

The installation process of IS-Solutions differs from product to product; certain (recently released) solutions are installed using transaction code SAINT and other products, such as IS-Oil and IS-Utilities, use R3up (same tool as the R/3 Upgrade tool) to install. The following phases are executed to install an IS-Solution using R3up: Phase INITPUT DBCHK Description Enter all parameters Determine RDBMS release DBINFO.LOG Log file
74
UPGRADING SAP
RFCCHK BATCHCHK VERSCHK ADDSPAREQ EXECIS IS_CHK READDATA KEY_CHK PATCH_CHK CLNT_CHK CNV_CHK TRBATCHK INTCHK IS_READ SPACECHK FREECHK ISC_IMP IS_MERGE JOB_RDDIT021 REPACHK ADJUSTCHK MODPROF STARTR3 DDIC_yy JOB_UMOD20 ACT_yy CON_yy TABIM_yy ADOIM_yy XPRA_yy JOB_RDDIT023 JOB_RSSPAM02 JOB_RDDIT020 END
RFC connection test Check Batch engine Check SAP release Prepare DB space check Check for installed IS-Solutions Display installed IS-Solutions Read software from CD-ROM Enter key from OSS note Check status of Support Packages Client locked or updated? Check TBATG conversations Check if TRBAT is empty Check if inactive nametab is empty Copy IS-Solution to /usr/sap/put Check DB freespace Check OS filesystem freespace Import IS command files Check imported command files Merge add-on in table TODIR Check for open repairs Determine DDIC object adjusted Stop system and adjust profiles Start R/3 system Import of DDIC objects Adjust BSEG table Activate new DDIC objects Conversion of DDIC objects Import entries in tables ADO import, conv.matchcodes Run XPRA reports Update AVERS table Load missing CRTs Update AVERS table again Load end
RFCCHK.LOG BATCHCHK.LOG
EXECIS.LOG ISOUT.LOG
PATCHOUT.LOG CLNTOUT.LOG TBATGCHK.LOG TRBATCHK.LOG DDXTnCHK.LOG DBINFO.LOG ISC_IMP.LOG RDDIT021.LOG REPACHK.LOG ADJUSTCHK.LOG ALPUPDP.LOG DDIC.ELG PSUMOD20.LOG ACT.ELG CONV.ELG TABIM.ELG ADOIM.ELG XPRAS.ELG PDDIT023.LOG RSSPAM02.LOG PDDIT020.LOG ENDCOMS.LOG
75
ENDCHK MODPROFP CHK_POSTUP SPAUINFO EXITINFO
Test target system Modify profiles and start system Display P errors Display SPAU list Display exit information ALPUPDP.LOG
Most of the phases and their sequence are exactly the same as with a release upgrade.
4.9.2
Installation Using SAINT

Besides using R3up as an add-on installation tool, SAP also uses another tool to deploy add-ons. The transaction code SAINT will start the SAP Add-On Installation Tool, which is part of SPAM (SAP Patch Manager). When you patch the SPAM tool, you also patch the SAINT tool; therefore, its called a SPAM/SAINT patch.
Figure 4.45: SAINT SAP Add-On Installation Tool.
Copyright SAP AG.
The SAINT tool is relatively easy to use. It offers an installation wizard that guides the engineer through the entire installation process. The steps the SAINT tool uses to import software into your SAP system are quite similar to the way Support Packages are imported.
76
4.10
UPGRADING SAP
ENHANCEMENT FRAMEWORK
SAP supports various methods for adjusting the software: customizing, enhancements, and modifications. Customizing is the process whereby the standard SAP software is parameterized. An enhancement adjusts an existing piece of SAP code so it is serving a business process better. A modification really changes a bit of standard SAP code and has a big drawbackevery time SAP changes their code, the modification needs to be reviewed and changed (back) again. The evolution of enhancements in SAP started with the ability to use User Exit. These are spots in the SAP code where a customer can add or adjust code by themselves. The code itself is embedded in the standard SAP workflow and does not touch SAP code, however, the location of code might change over time. A very well-known User Exit is MV45AZFF, which is used by SAP order processing. Where an User Exit is based on the PERFORM statement, a Customer Exit is based on Function Modules and therefore has a better parameter interface defined. Another advantage is the ability to put all code in its own customer namespace, which is, by default, not overwritten during an upgrade. Another option, introduced in SAP 4.6, is the Business Add-In. These BADIs are based on ABAP objects and provide the ability to have multiple versions. As of SAP NetWeaver 7.0, a new paradigm has been introduced under the name Enhancement Framework that brings all enhancement techniques under one roof. This framework includes the following technologies: Source Code Enhancement Function Group Enhancement Class Enhancement Kernel-BADI Enhancement
Figure 4.46: Evolution of enhancement technologies.
Copyright SAP AG.
77
The Enhancement Framework tools have been embedded in the ABAP Workbench under transaction SE80 called Enhancement Information System. The ABAP objects language has been extended with two keywords to support the addition of enhancements in ABAP programs: ENHANCEMENT-POINT and ENHANCEMENT-SECTION.
Figure 4.47: Additional ABAP language statements for enhancements.
Copyright SAP AG.
A new transaction, SPAU_ENH, provides the ability to keep, during the upgrade process, old classic BADI implementations and move them into the new Enhancement Framework concept. Therefore, existing BADI code can be kept and unchanged after the upgrade to NetWeaver 7.0, SAP ERP 6.0, or Business Suite 2005.
4.11
SWITCH FRAMEWORK
SAP also introduced the Switch Framework in NetWeaver 7.0. This new switch framework is used to implement Enterprise Extensions and Industry Extensions. The switch framework expands the capabilities of the Enhancement Framework by providing the ability to switch on sets of enhancements. To make Switch Framework handling easier, and to better group the individual switch settings, SAP is also introducing business function sets and business functions. A business function set corresponds to an industry solution. Each
78
UPGRADING SAP business function set is a group of business functions, and each business function group consists of a set of switch settings. The following objects are subject to the Switch Framework: By package assignment Appends, SI-, CI-includes for structures in DDIC Fixed-value appends to domains Secondary indexes Append search helps Enhancement implementations Switch Business Configuration Sets (Switch BC Sets) By direct assignment Screen elements and flow logic Menu entries and functions IMG nodes Customizing By using the Switch Framework, you will be able to activate an entire Industry Solution, such as IS-Oil or IS-Media. In some cases, it is also possible to activate multiple IS-Solutions in your system. However, there are some restrictions depending on the combination of the IS-Solutions. Once an IS-Solution is activated, it cannot be switched off. During the switch phase, all kinds of programs, data, and tables are generated. Two transactions are important here: SFW3 for the creation of a Business Function Set (BFS) and SFW5 to activate a Business Function Set.
Figure 4.48: Switch Framework architecture.
Copyright SAP AG.
79
The combination of both Enhancement-Points and the Switch Framework enables customers to deploy different internal releases at the same time. As an example, a single development system can be used to hold various releases that are switched on or off. This means that certain release-specific objects are switched on in one system, but switched off in the other.
4.12
SAP NOTES
Bug fixes are collected in Support Packages. There is also an option to apply individual source code corrections. These corrections are described in SAP notes that can be found at http://service.sap.com/notes. The implementation of individual SAP notes can be quite labor intensive. The source code needs to be changed manually using the SE38 ABAP Editor. Because you have to make these modifications to standard SAP code, you have to obtain an object key first through the SAP Service Marketplace. Its recommended to use the Modification buttons in the SE38 ABAP Editor, which can be used to mark modifications in the ABAP source code. During upgrades and the implementation of Support Packages, transactions SPDD (Dictionary Objects) and SPAU (ABAP Objects) need to be performed in order to determine what to do with the modifications. Its much more efficient when the modification browser can be used to support decisions in SPAU and SPDD. The most efficient way of implementing SAP notes is by using the SAP NoteAssistant, which can be accessed through transaction SNOTE.
Figure 4.49 Apply SAP notes using NoteAssistant.
Copyright SAP AG.
80
UPGRADING SAP The SAP NoteAssistant provides the ability to connect to SAP, download the source code correction specified in the SAP Note, and apply this code automatically (including updates to the modification database). The SAP NoteAssistant is supported as of SAP R/3 4.5B, however, its only shipped as part of certain Basis Support Packages. The following table shows which SAP releases require what Basis Support Package: SAP Basis Release 4.5B 4.6B 4.6C 4.6D 6.10 6.20 Minimum Precondition SAPKH45B45 SAPKB46B33 SAPKB46C25 SAPKB46D14 SAPKB61027 SAPKB62013
INFO Additional information about the SAP NoteAssistant can be found in SAP Note 560756.
4.13
RELEASE UPGRADES
An SAP release upgrade is the most complex topic of the software logistics in SAP. During a SAP release upgrade, the entire repository of objects is replaced with a newer version. The techniques used during an upgrade are similar to the import of individual transports and the implementation of Support Packages.
4.14
SAP KERNEL PATCHES

The SAP Kernel is responsible for running all transactions in the system, interpreting the ABAP code, and accessing the data in the tables. The SAP kernel consists of various executables, which resides in the /sapmnt/SID/exe directory. In general, the SAP Kernel is downward compatible according to this scheme: SAP Kernel Bundle SAP 3.1I_COM SAP 4.0B_COM SAP 4.0B_EXT SAP 4.5B SAP R/3 4.0B SAP R/3 4.0B in extended maintenance SAP R/3 4.5B SAP Basis release SAP R/3 3.1H and 3.1I
81
SAP 4.6D SAP 6.40 non-Unicode SAP 6.40 Unicode SAP 7.00 non-Unicode SAP 7.00 Unicode
SAP R/3 4.6B and 4.6C SAP Web AS 6.10 until 6.40 non-Unicode SAP Web AS 6.10 until 6.40 Unicode SAP AS 7.00 non-Unicode SAP AS 7.00 Unicode
Each SAP Kernel bundle consists of several binaries, which all have their own patch level codes. The exact patch level of a binary can be obtained through the -V option at the command prompt of the operating system: $ cd /sapmnt/SID/exe $ ./disp+work v ; SAP kernel (dispatcher + workprocesses) $ ./R3trans v ; Transport tool $ ./tp v ; Transport driver program $ ./icman v ; Internet connection manager There are two types of SAP Kernels: Unicode and non-Unicode. It depends on the character set used in the SAP database which of the two should be used. All new SAP installations are based upon the Unicode database, however, a lot of older SAP systems are still based on non-Unicode. Another important part of the SAP Kernel is the dynamic link libraries (DLLs for Microsoft Windows and .o files for UNIX), such as lib_dbsl (Database-specific interface libraries), dboraslib for Oracle, dbmsslib for Microsoft SQLServer, and the rfclib32 for all RFC communication. In most cases when disp+work executable is upgraded, you also have to upgrade the lib_dbsl. In case the SAP JCo (Java Connector) is used on the SAP system, be sure that the latest copy of rfclib32 is used as well. NOTE For the latest information on SAP Kernel patches, read SAP Note 19466. The SAP Kernels can be downloaded in .SAR (SAP Archive format) from http://service.sap. com/patches.
4.15
ENHANCEMENT PACKS
As of SAP ERP 2005, a new type of software deployment package is available, called an Enhancement Package. An Enhancement Package extends SAP ERP 2005 with new functionality that is normally released through SAP upgrades. To reduce the number of ERP releases, SAP has decided to keep the 2005 release as a core release up to at least 2010 and only add new functionality to the system through Enhancement Packs. So if a customer would like to leverage new functionality, its
82
UPGRADING SAP no longer required to go through an entire upgrade process, but rather implement one or more Enhancement Packs instead.
Figure 4.50: mySAP ERP 2005 Enhancement Package strategy.
Copyright SAP AG.
Enhancement Packages do not replace Support Packages. Support Packages are released to fix bugs and contain performance improvements. Enhancement Packages contain new functionality that is added to the ERP applications and can be licensed seperately. The functionality that has been added to the system through Enhancement Packages will become part of the next major SAP release. Implementing Enhancement Package is optional to the customer and need to be considered on a case-by-case basis. Enhancement Packages are incremental, which means that if you do not have any installed in your system and you would like to install Number 2, it automatically installs Number 1. Due to the fact that Enhancement Packages are new functionality, which means new programs, screens, and DDIC objects, you have to implement Support Packages for these Enhancement Packages as well. This results in a much more complex Support Package strategy. To support customers with this, SAP has released tools like SLM (SAP Life-Cycle Manager) and the MOP (SAP Maintenance Optimizer). Tools like these should help to reduce the complexity and effort of applying Support Packages. SAP will also release Enhancement Packages for other Business Suite components like CRM, SRM, PLM and SCM.
4.16
LANGUAGES
SAP applications based on the ABAP engine are multilanguage, which means that multiple languages can be used by end users. Depending on the release status, the SAP system supports up to 30 different languages. The language in which a dialog user works is specified during logon by making a selection on the logon screen. Alternatively, it can be specified by a system parameter or by a default setting in the user master record.
83
After a fresh install of an SAP system only German (DE) and English (EN) are available as languages. Additional languages need to be imported into the system using the Language management tool accessible through transaction SMLT. The different languages are implemented as text elements, which are identified by a language key. All SAP support languages have their own unique language key that is specified in table T002: Field SPRAS LASPEZ LAHQ LAISO Type (dimension) LANG (1) CHAR (1) CHAR (1) CHAR (2) Description Language key Language specification Degree of translation ISO 639 Language code
When an additional language needs to be installed in the system the language key needs to be available in this table. Through transaction SMLT, you will be able to select the appropriate language and add it to the list. For every language in the system, whether its imported or not, there is a line item in the overview screen of SMLT. By selecting this line, you can see all import details of this particular language. If the language has not been imported into the SAP system, this line will provide the ability to start loading the language. Languages are imported by using R3load, up to SAP R/3 release 4.6C or by using R3trans as of SAP R/3 4.6C. The language import files are delivered as R3load or Transport files (co- and datafiles) on a CD-ROM. During the import phase in SMLT, you can specify the location of these installation files.
Figure 4.51: Initial screen of SMLT Language Management (SAP R/3 4.6C).
Copyright SAP AG.
84
UPGRADING SAP As already stated, languages are implemented as text elements. All text elements are stored in tables, with at least two fields: language key and text. So when a text is put on the screen it points to a row in a table, identified by a language key. As mentioned before, table DD02L contains all table definitions in SAP. The table DD02T points back to DD02L, lists all relevant language fields, and contains all texts in different languages for all table names. Table DD02L points to DD02T, which contains (most important fields are shown here): Field TABNAME DDLANGUAGE DDTEXT Type (dimension) CHAR (40) CHAR (2) CHAR (120) Description Name of table (as in DD02L) Language key (as in T002) Text it self
For example, DD02T.TABNAME = USR02, DD02T.DDLANGUAGE=D and DD02T.DDTEXT=Anmeldedaten. Text elements are available for all kinds of SAP tables: Master, Transaction, System, and Customizing tables. For example, the customizing table TVKO that contains all Sales Organizations is accompanied with table TVKOT for the text elements. Although a table or ABAP program can have multiple text elements, one for each installed language, there is only one Master Language. The master language is the language where the objects are created and maintained in. The master language, which on most occasions is English or German, of each object is specified in table TADIR field MASTERLANG. TIP Text elements, and therefore languages and translations, are stored in tables with (TVKOT) and without (DD02T) the client-specification field MANDT. Therefore, assume that languages are client independent. The customer can decide whether it translates certain text elements using the Translation Workbench, which can be accessed using transaction SE63. The translation workbench is a tool for translating language-dependent texts. The tool can be used to translate additional texts in incompletely translated languages. For example, if you want to use the Danish language, but the language is not (yet) available from SAP, the option is to install the Danish language in SMLT, but without importing the language. The Danish language is completely supplemented with either English or German. The dialog user, who logs-on in Danish will only see English or German texts. This provides the ability to translate certain text elements into Danish yourself, for example, to cope with legal requirements. This could be done for Dangerous Goods Movement documents. As of release 4.6C, SAP switched from R3load to R3trans for language imports. The reason for this is related to Support Packages. In SAP releases older than 4.6C,
85
you could not install new additional foreign languages to your system if there were already Support Packages applied.
Figure 4.52: Language import problem of SAP R/3 up to release 4.6B.
If you did so, the new language is only added in the core of the SAP system, all objects that were modified due to Support Packages will not have a proper translation. The solution to this problem is to include, in all Support Packages, the text element of all supported languages. During the normal implementation of Support Packages, SAP will only import those languages that are installed in the system. When an additional language is added to the system at a later stage, the SMLT tool will import missing text elements belonging to that new language and from the already applied Support Packages. In order to do this, the co- and datafiles of these Support Packages need to be available for accessing. A negative consequence of this new method is the increased size of each Support Package.
Figure 4.53: Language import option as of SAP R/3 4.6C.
TIP You do not have to keep all co- and datafiles online in order to add additional languages to your system. SMLT is able to disassemble all required files from the EPS package. Just store all required EPS packages in /usr/sap/transEPS/in.

SAP Software Logistics

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SAP Software Logistics

Uploaded by

Copyright:

Available Formats

Chapter

SAP SOFTWARE LOGISTICS

Informix database support is only available under special conditions

Figure 4.1: Database tables in SAP.

SAP DEVELOPMENT OBJECTS

SAP SOFTWARE LOGISTICS

Figure 4.2: Edit, compile, and run an ABAP program.

SAP SOFTWARE LOGISTICS

SAP SOFTWARE LOGISTICS

CLIENT (MANDT) CLNT (CHAR (3) )

SAP SOFTWARE LOGISTICS

Field PGMID OBJECT OBJ_NAME ACCESSKEY

Figure 4.3: Data table with its attributes.

Figure 4.4: SAP transparent table mechanism.

SAP SOFTWARE LOGISTICS

Figure 4.5: SAP Pooled table mechanism.

Figure 4.6: SAP Clustered table mechanism.

SAP SOFTWARE LOGISTICS

Figure 4.7: Relationship between BSEG and RFBLG.

Table Delivery Types

Table Data Classes

SAP SOFTWARE LOGISTICS

TABART name APPL0 APPL1 APPL2 SLDEF SPROT TEMP USER2

TABART name SAUS SDIC SDOCU SLOAD USER1 USER3

Spool and log tables SSRC

Table Technical Settings

SAP SOFTWARE LOGISTICS

SAP SOFTWARE LOGISTICS

Figure 4.8: Customizing object embedded in IMG.

Figure 4.9: Search Helps are implemented as F4 in input fields.

Figure 4.10: SAP graphics view of ERD data modeler.

Copyright SAP AG.

SAP SOFTWARE LOGISTICS

Figure 4.11: SAP Screen Painter.

Copyright SAP AG.

Figure 4.12: SAP Menu Painter.

Copyright SAP AG.

SAP SOFTWARE LOGISTICS

Figure 4.13: SAP Web Dynpro builder.

Copyright SAP AG.

CORRECTION AND TRANSPORT SYSTEM

Figure 4.14: SAP CTS, CTO, and TMS.

Copyright SAP AG.

SAP SOFTWARE LOGISTICS

Transport Management System

Figure 4.15: One transport domain with two transport groups.

Figure 4.16: Standard transport route for three system landscapes.

SAP SOFTWARE LOGISTICS

Figure 4.17: Relationships between request, task, and objects.

Figure 4.18: The initial screen of transaction SE01.

Copyright SAP AG.

SAP SOFTWARE LOGISTICS

Figure 4.19: Files are created once a Transport Request is released.

Figure 4.20: Three methods of tp accessing the database.

SAP SOFTWARE LOGISTICS

Figure 4.21: tp calls sapevt to start ABAP programs.

SAP SOFTWARE LOGISTICS

Figure 4.22: Relationship model for SAP tables.

Activation and Distribution

Figure 4.23: Table activation phase.

SAP SOFTWARE LOGISTICS

Figure 4.24: Table distribution phase.

Figure 4.25: Table conversion phase.