sap software logistics

Chapter 4SAP SOFTWARE LOGISTICS

All 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.

4 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 17

LIMU REPS - ABAP Report Source Code Text LIMU REPT - ABAP Report Description LIMU VARI - ABAP Report Variant 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 “sub-” object 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 SAP’s 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 browser–based 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.


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.

It’s 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 UPGRADING SAP

4.1.3 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. It’s 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 Type (dimension) Description

DEVCLASS CHAR (30) Name of Development Class

INTSYS CHAR (10) Integration system, obsolete

CONSYS CHAR (10) Consolidation system, obsolete

CTEXT CHAR (60) Description of development class

AS4USER CHAR (12) User/Creator of development class

NAMESPACE CHAR (10) Name space of development class

COMPONENT CHAR (20) 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.


TIP Assume you’re 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 Description Example Object

Y* SAP partners Table YINVOICE

Z* Customer development ABAP ZTEST

A* – X* SAP developments 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:


OBJECT CHAR (4) Object type like REPS or TABU

TABNAME CHAR (30) Name of customizing table

FIELDNAME CHAR (30) Field in table

KEYLOW CHAR (30) Name-range, like Y* and Z*

IGNOREFLAG CHAR (1) Can name-range be ignored?

GENFLAG CHAR (1) Generation flag

LASTNAME CHAR (12) Name of last editor

LASTDATE DATS Date of last change

22 UPGRADING SAP

For the upgrade, it’s important to know whether an object is a customer-development object or if it’s 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 third-party 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 SAP’s own namespaces, are stored in table TRNSPACE, which has the following layout:


NAMESPACE CHAR (10) Namespace name

ROLE CHAR (1) Role of namespace

LICENSE CHAR (20) License key

EDITFLAG CHAR (1) Modifications allowed

SSRCFLAG CHAR (1) SSCR dialog box

SAPFLAG CHAR (1) SAP standard delivered

GEN_ONLY CHAR (1) 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 Owner Description

/BMC/ BMC Software BMC Patrol (Trak) objects

/SAPDMC/ SAP A.G. Legacy Data Migration Workbench

/BI0/ SAP A.G. SAP BW standard objects

/BIC/ SAP A.G. SAP BW customer objects

/VIRSA/ SAP A.G. Virsa (SAP GRC)

An object with the name ZTEST, which belongs to a namespace /XYZ/, needs to be identified with “/XYZ/ZTEST.”


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:


CLIENT (MANDT) CLNT (CHAR (3) ) SAP logon client

OBJECT CHAR (10) Name of Number Range Object

SUBOBJECT CHAR (6) Number range subobject value

NRRANGENR CHAR (2) Number Range version

TOYEAR NUMC 4 Fiscal year for document

FROMNUMBER CHAR (20) Start range

TONUMBER CHAR (20) End range

NRLEVEL NUMC 20 Current number

EXTERNIND CHAR (1) External number range

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:


OBJECT CHAR (4) Object type (PROG, TABL)

HIKEY CHAR (120) Key used in CTS

LEN INT (10) Length of CTS key

EDTFLAG CHAR (1) Special editor required

TRKORR CHAR (20) Request/Task

AUTHOR CHAR (12) Creator of object

LOKEY CHAR (120) 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:



PGMID CHAR (4) Object ID (as in TADIR)

OBJECT CHAR (4) Object type (as in TADIR)

OBJ_NAME CHAR (40) Object name (as in TADIR)

ACCESSKEY CHAR (20) 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:


UNAME CHAR (12) User name (as in USR02)

ACCESSKEY CHAR (20) Developer key from SAP

TIP If you want to prevent any development in your system, you just delete all entries from table DEVACCESS. 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 it’s 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 UPGRADING SAP

4.2.1 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


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:


TABNAME CHAR (10) Pooled table name

VARKEY CHAR (n) Maximum key length

DATALN INT2 (5) Length of VARDATA row

VARDATA RAW (n) 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 it’s 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.


CLKEY1 CHAR (*) First key field

CLKEY2 CHAR (*) Second key field

……………. ……………. ……………..

CLKEYN CHAR (*) Last key field

PAGENO INT2 (5) Number of next page

TIMESTMP CHAR (14) Time stamp field

PAGELN INT2 (5) Length of VARDATA row

VARDATA RAW (*) 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.


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 it’s 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 Description Example Table

‘A’ – Application Table Protected against SAP import, only insertions

MARA, USR02, EKKO, KNA1

‘S’ – System Table Maintenance by SAP only CCPROF

‘W’ – System Table Maintenance by SAP only DD02L

‘E’ – Control table SAP and customer do have different name ranges

ATR1

‘C’ – Customizing table Maintenance by customer, SAP will not change entries in this table

T001, TVKO

‘G’ – Customizing table Protected against SAP import, only insertions

RFCDES

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:


TABART name Description TABART name Description

APPL0 Master data SAUS Exchange tables

APPL1 Transaction data SDIC ABAP DDIC tables

APPL2 Customizing data SDOCU Documentation tables

SLDEF Repository switch SLOAD Report load tables

SPROT Spool and log tables SSRC Source tables

TEMP Temporary tables USER1 User-defined tables

USER2 User-defined tables USER3 User-defined tables

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, it’s possible to specify the TABART of this new table. The TABART will determine in which tablespace the table is created; it’s 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, it’s 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 it’s 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 UPGRADING SAP

4.2.5 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):


TABNAME CHAR (30) Table name (like in DD02L)

TABKAT CHAR (2) Table size category

TABART CHAR (5) Table data class (like in DDART)

PUFFERUNG CHAR (1) Table buffering indicator

PROTOKOLL CHAR (1) Is table logging on?

TRANSPFLAG CHAR (1) Converted to transparent table?

ACTFLAG CHAR (1) Activation flag

BUFALLOW CHAR (1) 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 Description

OFF Table logging switched OFF for entire system

Nnn Table logging switched ON for this client nnn

nnn, mmm, ppp Table logging switched ON for these clients

ALL Table logging switched ON for entire system


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:


OBJNAME CHAR (30) Name of DB object (table, view…)

DBSYS CHAR (10) Name of RDBMS (e.g., Informix)

OBJTYPE CHAR (4) Table, view, index …etc.

DIFFKIND NUMC (2) Type of inconsistency

SOURCE CHAR (40) 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):


OBJECTNAME CHAR (30) Name of customizing object

OBJECTTYPE CHAR (1) Type of object

CLIDEP CHAR (1) Is object client specific?

LANGDEP CHAR (1) Is object language specific?

ALEDEP CHAR (1) Is object ALE specific?

OBJCATEG CHAR (4) Object category

TRCOMPLETE CHAR (1) Object transport must be complete

TRDISJUNCT CHAR (1) Object is disjunct to other objects

The following Customizing object types are known to the SAP system:

OBJECTTYPE Description

C View cluster (transaction oriented)

L Logical transport object

S Table with text

T Individual transaction object

V View

D 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,


using transaction SPRO (Customizing IMG), you’re 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.


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


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 (Model-View-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 UPGRADING SAP

4.5 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 transaction-code. 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.


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 it’s called “Consolidation System,” and a production system is called a “Delivery System.”


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:


TRKORR CHAR (20) Request/Task number

TRFUNCTION CHAR (1) Request or Task?

TRSTATUS CHAR (1) Status of request in CTS

TARSYSTEM CHAR (10) Target system

AS4USER CHAR (12) Owner of request

AS4TEXT CHAR (120) 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 it’s 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):


TRKORR CHAR (20) Task number

A4POS NUMC 6 Position of object in list

PGMID CHAR (4) Object ID (as in TADIR)

OBJECT CHAR (4) Object type (as in TADIR)

OBJ_NAME CHAR (20) 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.


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 It’s 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 Variable Name Variable Value

AIX LIBPATH /usr/sap/SID/SYS/exe/run

HP-UX SHLIB_PATH /usr/sap/SID/SYS/exe/run

Solaris (SunOS) LD_LIBRARY_PATH /usr/sap/SID/SYS/exe/run

Linux LD_LIBRARY_PATH /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.


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.

It’s 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 Job Name ABAP Program Description

X RDDDIC0L RDDDIC0L ADO export

J RDDMASGL RDDMASGL Mass activation

B RDDTACOL RDDTACOL TACOB activation

S RDDDIS0L RDDGENBB Distributor

N RDDGEN0L RDDGENBB Import conversion

M RDDMASGL RDDMASGL Mass activation for enqueue

Y RDDGEN0L RDDGENBB Matchcode conversion

O RDDGEN0L RDDGENBB Batch conversion

D RDDDIC1L RDDDIC1L ADO import

V RDDVERSL RDDVERSL Create version information

R RDDEXECL RDDEXECL XPRA execution

G RDDDIC3L RDDDIC3L ABAP generation (compilation)

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 Description

DD02L Table header information; fields are: tabname – Name of table as4local – is table activated? tabclass – Data class table belongs to (TRANSP, INTTAB, CLUSTER, POOL, VIEW,

APPEND) 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


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 UPGRADING SAP

4.5.7 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.


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, you’re 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


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 so-called 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.


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, it’s not possible to have multiple clients in one single SAP instance; therefore, it’s recommended to use:

Figure 4.29: SAP client landscape for InfoCube-based applications.

Also, for these systems, it’s 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 it’s 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, it’s also possible to use R3trans. However, it’s 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.


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 552711—Client 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.


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 don’t 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, it’s 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.


(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 it’s 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 IS-Oil. 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.”


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

it’s 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.


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 so-called “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.


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 Table Description

PAT00 Patch steps

PAT01 Patch status

PAT02 Conflicts between patches and add-ons

PAT03 Patch directory

PAT07 Patch prerequisites

PAT09 Patch history

TEPSIN EPS bundle inbox

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.


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


→ 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 industry-specific 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 Media SAP for Automotive SAP for Mill Products SAP for Banking SAP for Mining SAP for Chemicals SAP for Oil and Gas SAP for Consumer Products SAP for Pharmaceuticals SAP for Engineering and Construction SAP for Utilities SAP for Professional Services SAP for Healthcare SAP for Public Sector SAP for High Tech SAP for Retail SAP for Higher Education and

Research SAP for Service Providers SAP for Industrial Machinery and

Components SAP for Telecommunications SAP for Insurance 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-Oil–specific 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,


you still need a special upgrade-software kit, which does contain the new IS-Solution.

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 Description Log file

INITPUT Enter all parameters

DBCHK Determine RDBMS release DBINFO.LOG

74 UPGRADING SAP

RFCCHK RFC connection test RFCCHK.LOG

BATCHCHK Check Batch engine BATCHCHK.LOG

VERSCHK Check SAP release

ADDSPAREQ Prepare DB space check

EXECIS Check for installed IS-Solutions EXECIS.LOG

IS_CHK Display installed IS-Solutions ISOUT.LOG

READDATA Read software from CD-ROM

KEY_CHK Enter key from OSS note

PATCH_CHK Check status of Support Packages PATCHOUT.LOG

CLNT_CHK Client locked or updated? CLNTOUT.LOG

CNV_CHK Check TBATG conversations TBATGCHK.LOG

TRBATCHK Check if TRBAT is empty TRBATCHK.LOG

INTCHK Check if inactive nametab is empty DDXTnCHK.LOG

IS_READ Copy IS-Solution to /usr/sap/put

SPACECHK Check DB freespace DBINFO.LOG

FREECHK Check OS filesystem freespace

ISC_IMP Import IS command files ISC_IMP.LOG

IS_MERGE Check imported command files

JOB_RDDIT021 Merge add-on in table TODIR RDDIT021.LOG

REPACHK Check for open repairs REPACHK.LOG

ADJUSTCHK Determine DDIC object adjusted ADJUSTCHK.LOG

MODPROF Stop system and adjust profiles ALPUPDP.LOG

STARTR3 Start R/3 system

DDIC_yy Import of DDIC objects DDIC.ELG

JOB_UMOD20 Adjust BSEG table PSUMOD20.LOG

ACT_yy Activate new DDIC objects ACT.ELG

CON_yy Conversion of DDIC objects CONV.ELG

TABIM_yy Import entries in tables TABIM.ELG

ADOIM_yy ADO import, conv.matchcodes ADOIM.ELG

XPRA_yy Run XPRA reports XPRAS.ELG

JOB_RDDIT023 Update AVERS table PDDIT023.LOG

JOB_RSSPAM02 Load missing CRTs RSSPAM02.LOG

JOB_RDDIT020 Update AVERS table again PDDIT020.LOG

END Load end ENDCOMS.LOG


ENDCHK Test target system

MODPROFP Modify profiles and start system ALPUPDP.LOG

CHK_POSTUP Display P errors

SPAUINFO Display SPAU list

EXITINFO Display exit information

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, it’s 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 UPGRADING SAP

4.10 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 drawback—every 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.


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.


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. It’s 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. It’s 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, it’s only shipped as part of certain Basis Support Packages.

The following table shows which SAP releases require what Basis Support Package:

SAP Basis Release Minimum Precondition

4.5B SAPKH45B45

4.6B SAPKB46B33

4.6C SAPKB46C25

4.6D SAPKB46D14

6.10 SAPKB61027

6.20 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 Basis release

SAP 3.1I_COM SAP R/3 3.1H and 3.1I

SAP 4.0B_COM SAP R/3 4.0B

SAP 4.0B_EXT SAP R/3 4.0B in extended maintenance

SAP 4.5B SAP R/3 4.5B


SAP 4.6D SAP R/3 4.6B and 4.6C

SAP 6.40 non-Unicode SAP Web AS 6.10 until 6.40 non-Unicode

SAP 6.40 Unicode SAP Web AS 6.10 until 6.40 Unicode

SAP 7.00 non-Unicode SAP AS 7.00 non-Unicode

SAP 7.00 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, it’s

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.


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:


SPRAS LANG (1) Language key

LASPEZ CHAR (1) Language specification

LAHQ CHAR (1) Degree of translation

LAISO CHAR (2) 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 it’s 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):


TABNAME CHAR (40) Name of table (as in DD02L)

DDLANGUAGE CHAR (2) Language key (as in T002)

DDTEXT CHAR (120) 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,


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

Documents

copyright

sap archive

conflict resolution

truncate table

se38 abap

sap menu painter

sap software

sap service