ERP II Lecture 4 - Notes

Created @March 31, 2024 1:08 AM

Class BINF209

Type Lecture

Text SAP ERP Change and Transport Management

Intro
What is SAP ERP Change and Transport
Management
SAP ERP Architecture uses the client/server architecture, and it uses
change and transport management to manage the database included in the
architecture.

CTM specifically to manage changes made during customization and

development, and ensure consistency across multiple systems

Change and transport management is concerned with the following:

The role the database plays in the architecture

The architecture of the database itself, including data components and

clients

CTM involves recording and organizing changes in "change requests."

These change requests are then transported to different clients and SAP
systems within the overall system landscape.

The transport process involves two steps:

Releasing and exporting the change requests from the development

system.

Importing them into the target SAP system.

The techniques used for CTM are also known as "software logistics" - the
process of moving or transporting changes made to the SAP software.

ERP II Lecture 4 - Notes 1

 Data in SAP Database/SAP ERP Database
Unlike most software, SAP ERP doesn't separate the software program from
the data it manages.

most softwares el codes bt3tha w data byb2o separated

SAP ERP software is unique in that it combines the application functionality

(what the software does) and business data within the same database.

This central database stores nearly everything users interact with, including
transaction data, program code, text, menus, screens, and even printer and
fax settings.

In essence, the SAP ERP database contains virtually all system-related

components, with only a few exceptions like the kernel residing outside.

kernel is the core program that manages the system

The SAP ERP database can be logically divided into two parts: the
Repository and customer data

Kol el fat da 3shan basically y2oli en:

Key Point: Both the SAP repository (application functionality) and

customer data (business data) reside within the same central SAP ERP
database. This is unlike most software where these elements are stored
separately.

ABAP Dictionary
The SAP runtime environment consists of all ABAP programs required
during SAP execution. The ABAP interpreters in the runtime environment do
not use the original ABAP program. Rather, they use a copy buffered from
the system database in the main memory once this program is called by the
end-user for the first time (early binding).

Runtime objects, like programs and screens, are automatically regenerated

in the main memory (late binding) when a time stamp comparison between
the object and the ABAP Dictionary (in the database) detects a difference
between them.

This combination of early binding and late binding ensures that accesses
on ABAP Dictionary information don’t negatively affect the system

ERP II Lecture 4 - Notes 2

 performance. This is because reading data from the main memory is much
faster than reading it from the hard disks.

SAP Repository
—> Da awel part of the SAP ERP database w hwa da el application functionality

—> Repository provides the data structures and programs needed to maintain
data within the SAP ERP system.

There is only ONE central repository that serves all clients in the system.

It provides the runtime environment for the various business applications

ABAP Dictionary:
ABAP stands for Advanced Business Application Programming, and it is a
SAP programming language

—>The core of the repository, which stores definitions for data structure and
relationships between all data elements.

SAP ERP uses these definitions to interpret and generate application

objects used during runtime, such as programs and screens. These objects
are known as Repository objects.

Every part of ABAP dictionary information is entered once only,

and it is made available to the system at any time

fa kda baimprove efficiency

It automatically provides all needed all needed, changed, or new

information

Hence, it provides current runtime objects and ensures data consistency

and security

SAP runtime environment consists of all ABAP programs during execution

of SAP

Early binding:
—> di haga bthsl when el system btidentify el code aw data needed before el
run of the program, where my program asln readily available fl RAM bdl ma
by3od yaccess kol mra mn slower Hard Disk

ERP II Lecture 4 - Notes 3

 In SAP ERP, this happens when a user first executes an ABAP program:
The system:

1. Locates the program definition in the ABAP Dictionary (database).

2. Creates a copy of the program code and stores it in the main memory
(RAM) which is much faster to access.

RAM asr3 kter fa system hy2dr yretrieve it alatoul w yexecute faster

3. This copy serves as the reference for future executions of the program
by the user.

Runtime objects, like programs and screens, are automatically regenerated

in memory

Late binding:
—> hna ba nfs el ksa shwaya bs it occurs during program execution/run lma
system tkon mhtaga t3rf specific code aw data 3shan yst5dmha f part mo3yn
fl code

In SAP ERP, late binding comes into play when:

The program definition in the ABAP Dictionary might have changed

since the initial execution (early binding).

The program dynamically references other data elements during

runtime.

For late binding to ensure up to date info:

The system compares timestamps of the program copy in memory with

its definition in the ABAP Dictionary.

If a difference is detected (indicating an update), the in-memory copy is

automatically regenerated/recreated using the latest information from
the dictionary.

—> Early and late binding work hand in hand, early binding el awl byhsl when a
user byexecute l awl mra fa btb2a stored as a copy fl RAM for faster access w
mmkn t3ml msln occasional late binding to compare el timestamps w make
sure data is up to date

Early and late binding ensure that the access the user has on the ABAP
dictionary does not negatively affect system performance, because reading

ERP II Lecture 4 - Notes 4

 data from the main memory is faster than reading it from the hard disk
(database)

Remember:

main memory (RAM) fast access time, and volatile memory

Hard disk (database) slow access time, delays, and non-volatile

memory

Repository objects:
—> are application objects within the SAP ERP system that are generated and
interpreted using data structure definitions stored in the ABAP Dictionary.

objects di mmkn tb2a program msln aw screens kda bs more

specifically:

ABAP Dictionary objects

ABAP Programs

Screens

Interface definitions

These objects can be standard SAP objects or those i customize using

ABAP workbench.

→ During an SAP ERP implementation, you might need to customize the system
by adapting the Repository to fit your specific needs.

ABAP Workbench:
—> provides tools for creating or modifying Repository objects, allowing you to
add or change table structures or programs.

simply by3ml customization

Examples of customizing objects

Settings for organizational units (plants, company codes, and so on)

Settings for control tables

SAP recommends against altering standard SAP objects in the

Repository.

ERP II Lecture 4 - Notes 5

 Kinds of changes on Repository caused by Workbench:
Own development:

Customer developed objects like new reports, screens, and tables

da eli hwa ana b3ml creation of new objects

Extension/enhancements:

They are anticipated customer-developed objects that are referenced

by the standard SAP objects

They don’t change the SAP standards, but they enhance the software

Y3ni mn el a5er SAP expects eno you’d want to change certain things
like tables, fa they give you the option to do so (enhance them) without
changing the object’s core structure unlike modifications

Modification:

Changes made to standard SAP objects in the customer system

Customer data
—> Da tany part of the SAP ERP database w hwa da el business data

Customer data is the other main logical component of the SAP ERP
database alongside the Repository.

think of it like a spreadsheet file (an analogy)

It includes any information entered into the system by the customer

organization, either during the initial implementation or ongoing business
operations.

—> Customer data consists of three categories:

Customizing data:
—> This is the configuration data that results from Customizing, which is a
mandatory task during SAP ERP implementation

hna basically zy hagat related to formatting settings/configurations eno

bzbt el text font w kda

It defines what kind of application data can be created and its appearance
within the system.

ERP II Lecture 4 - Notes 6

 Examples of customizing data include:

Organizational units (companies, plants, sales organizations).

Purchase order process flow.

Production planning distribution requirements.

Multi-language text for reports.

Application data (master data + transaction data):

—> This is also called business data and it is the data required for or generated
by day-to-day business activities processed within the system.

di k2naha el data eli actually bd5la f cells el excel msln

el data eli bt5li the whole business running asln

—> Application data is all SAP ERP business data, including both master data
and transaction data.

Master data: a foundation for processing daily transactions.

Transaction data: generated by daily business operations.

While logically consisting of both master and transaction data, there's no

formal distinction between the two within the system.

It's influenced by customizing settings, which determine what type of data

can be generated and how it appears.

User master data:

This data includes user IDs, passwords, and authorization levels for
individuals using the SAP ERP system.

di data that focuses basically ala who uses the system and how

User master data is crucial for SAP ERP's security system.

It stores user information for authentication and transaction authorization.

When a user logs in, the system verifies the user ID and password against
the user master data.

User authorization profiles determine which transactions a user can access.

ERP II Lecture 4 - Notes 7

 Concept of SAP Client
SAP Client: is a self-contained unit in the system with its own separate
master records and its own tables. This ensures data isolation between
different clients.

Basically, momken a3tber clients ka2eno different sub-systems of the

main SAP system, each developed for a different purpose (training
client, test client etc.)

Kol client 3ndo its own customer data bs msh separate repository
3shan SAP has a central repository that serves all clients

Technical realization: refers to when a concept is translated practically

into the system. y3ny btt3ml real aw 5las bst5dmha in practical work

Regarding the SAP client, technical realization is achieved when the

client number is declared as a primary or foreign key in every business-
related table in the database

Client Data Components:

Data components of an SAP ERP client: are the types of data a user can
access after logging on to a particular client

As you can see below, el client data components are the same as the 3
categories of the customer data

—> Client dependent: means en data di unique lel client da bs w ay client tany
cant access it

—> Client INdependent: da m3nah en el data is shared by all clients in the same
SAP ERP system

ERP II Lecture 4 - Notes 8

 Customizing data: Most is client-dependent affecting only the specific
client it's configured for.

some is client-independent like:

Adjustments to global settings that affect all clients (e.g., defining a

printer).

Creation or changes to Repository objects (e.g., a table to store

pricing strategy).

Application data: All is client-dependent.

User master data: All is client-dependent, valid only within the client where
the user record is created.

Standard Clients in an ERP System:

—> SAP delivers three standard clients with the SAP ERP system: Client 000,
Client 001, and Client 066.

Client 000:
Reserved by SAP for maintaining standard functionalities and baseline
configurations within the system.

Used for testing upgrades and transporting new features to other clients.

Contains basic sample configurations for organizational structures and

business parameters (e.g., payment and tax structures relevant to German
organizations).

Not modifiable or deleted by the customer due to its special role.

Contains no application data.

Client 001:
A copy of Client 000, including its sample organizational structure and
configuration.

Can be modified by the customer for their specific needs.

Contains no application data.

It is known as CUST and it serves as the user’s customizing and

development

ERP II Lecture 4 - Notes 9

 client
, which the user can use for their implementation process

Client 066:
Reserved for SAP to access customer systems remotely for services like
EarlyWatch® and GoingLive™ Check.

Contains almost no data and serves as a mechanism for secure remote

access for system monitoring.

Should not be modified or deleted by the customer.

The SAP System Landscape

—> SAP System Landscape refers to the collection of SAP systems and clients
you use to manage your organization's SAP ERP implementation.

btcontain hgat to help with system initial installation w business need

configuration w production launch

bt3 da et3ml 3shan ehna mhtageen ntransfer customizing/development

changes w business data mn one client aw SAP system lel tanya

hna mfrood ageb minimum 2 SAP systems 3shan 1 is risky cuz it will act as
a single point of failure

—> The image below shows a three-system landscape, and ideal case,
where each one of the system’s central clients has their own SAP system

ERP II Lecture 4 - Notes 10

 Standards systems homa el big, shaded blocks w eli smalls white boxes are
clients specific for each system

awl 3 mn kol system hma el standard

Clients within an SAP system provide isolated environments for application

data while sharing the same central Repository and client-independent
Customizing settings.

Because of the functional and technical limitations of multiple clients in

a single SAP system—including sharing a common Repository—SAP
recommends that you distribute the critical clients among several SAP
systems.

i guess that means all 3 systems share the same central repo not sure
bs somehow still independent 3shan they are separate systems

Standard Systems:
The recommended three-system landscape includes:

Development System (DEV): Used for customization and development

activities.

—> NEXT: Changes are recorded and transported to the quality assurance
system for testing.

Quality Assurance System (QAS): Sometimes called the test or

consolidation system

This receives the altered programs, and developed objects from the
development system and performs quality assurance over them to
ensure data consistency and that data transports are complete.

Used for testing functionalities without affecting production.

Allows integration and verification of changes before moving them

to production.

—> NEXT: If quality assurance testing is successful, the change request is

sent to the production system

Change request is a request for modifications and alterations in the

SAP system

Production System (PRD): Where business data is collected and

accessed.

ERP II Lecture 4 - Notes 11

 It contains the system functionality; it handles the day-to-day
business transactions and hold critical business data

DEV Client Roles:

CUST: This is the central client for customization and development
activities using the ABAP Workbench.

All changes made here are documented in change requests for

transport to other clients.

TEST (Unit Test): This client is recommended for unit testing

customizations and developments before transporting them to the quality
assurance client. It allows for maintaining sample application data separate
from the customization environment.

SAND (Sandbox): This client acts as a "playground" for testing

customization efforts before impacting the CUST client.

After testing in the sandbox, changes can be implemented in the main

customization client (CUST).

QAS Client Roles:

QTST (Quality Assurance Testing): This client provides a testing
environment for new and existing customizations, as well as business
application functionalities. You can add and manipulate application data
here for quality assurance purposes.

TRNG (End User Training): This client provides a training environment for
end-users who will be working with production data in SAP ERP.

PROD Client Roles:

PROD (Production): This is the heart of the system, where your daily
business operations occur.

It holds your critical production data. Customizations are only

implemented here after thorough testing in the QTST client.

NOTE:

ERP II Lecture 4 - Notes 12

 Transport of Customizing and
Development Changes
Change Requests:
—> gya mn esmaha, request l change ana 3iza a3mlo fa b2oul fiha ana h8yr eh

Information carrier that is managed by transport organizer.

Used for the collection and administration of all repository changes and
customizing settings.

Used for transporting data or copying corrections from one system to

another.

Released corrections can be entered into a change request.

When this change request is released, transport of corrections is

carried out.

For example, corrections can be transported from the development

system to a quality assurance system.

Change requests and their associated tasks act as the central mechanism
for recording all object changes within the system.

When customizing objects or modifying Repository objects, the system

records the changes in a dedicated task.

ERP II Lecture 4 - Notes 13

 Change Task (Change Job):
—> di haga within el change request as in btbreak down el change request ala
steps so8yra w kol task btfocus ala heta mn el overall change request

They are stored inside a change object (they’re like files in a folder).

A change task is usually a list of objects that have been modified by a

certain user.

A change request can only be released once all the change tasks inside it
are completed, released, or deleted.

Tasks can only be transported through change requests; they can’t be

transported by themselves.

Every change task is released by only one user, but multiple users can be
assigned to change requests (because change requests contain many
tasks).

Each task is owned by a single user and essentially represents a list of

objects they have modified.

Multiple tasks are grouped together into a single change request, which
reflects a specific project objective.

Beyond recording changed objects, users can document the details and
purpose of each change within the corresponding task.

This structure provides a comprehensive history of all modifications made

throughout the SAP ERP implementation process.

Types of Change Requests

There are two main types of change requests to record software changes
during SAP ERP implementation:

Customizing Change Requests

Workbench Change Requests

Customizing Change Requests:

—> After changes or customization have been made, they must be recorded to
change requests so that they can be transported to other systems and clients

Serve the client-dependent changes.

ERP II Lecture 4 - Notes 14

 record client-specific changes made through IMG activities.

Most Customizing activities fall under this category.

Workbench Change Requests:

When you create or change a non-local repository object it is recorded to a
workbench change request

Serve the changes of the:

Client-independent customizing changes (cross-client) changes.

All repository objects (created with ABAP Workbench): Programs,

tables, authority objects, etc.

—> Three types of Workbench Change Requests:

Transportable Change Request:

Most commonly used type of Workbench Change Request because

most changes are created with the intention of transferring those
changes to other systems as well.

Example is repository objects that are created and meant to be

transported to other systems.

Specifies a transport layer to move the request over.

Local Change Request:

Used if transport layer provided is invalid.

Unclassified Request:

When a Workbench Request type is not specified.

Note:

Changes in application data and user master data are not recorded in
change requests.

Technical Procedure of the Transports:

IMP
—> di zy process kda bt7sl when changes aw modifications bthsl lel objects or
so w process di mnha eni mhtaga a release el changes di, then export w import

ERP II Lecture 4 - Notes 15

 to targeted client.
—> Process di btbd2 fl DEV system (since di eli fiha options el customization) w
mfrod ba btwsl el changes di lel other systems

Preparation of changes
Recall change requests act as a collection of tasks, listing the various
objects modified within the database.

This information allows you to update other clients in your system

landscape with these changes.

The technical procedure for transporting these changes involves two steps:

Transporting: Releasing and exporting the changes from your SAP

system to the operating system level.

Importing: Importing the changes into another SAP system within your
landscape.

1) Transporting:
—> this involves 2 things

a) Release:
Changes in the system start with releasing change requests.

To release a change request, all its individual tasks must be

documented and released first.

The documentation should include detailed information on how to

perform the task, as well as a description of the correction (change)
that happened, and the cause of the change.

Before releasing tasks in a change request, they must be tested for

coherency and effectiveness (unit testing).

obv released after successful completion here

b) Export:
Release of a change request initiates the export process.

The export process involves physically copying recorded objects from the
database which are going to be included in the transport directory.

ERP II Lecture 4 - Notes 16

 The transport directory is a file system accessible by all SAP systems
within the landscape.

When objects in the change request are exported, the change request ID
number will automatically be added to the import queue of the next client or
system.

Import queue is a list of change requests that have been released and
exported and are waiting for imports.

It extracts objects from the database level and places them on the
operating system level with a control file and a transport log.

It is done in the source system.

Usually done automatically.

2) Import of changes
Copies of the changed objects listed in a released change request are
taken from the transport directory into the database of the target system
and client.

The import queue of the target client and system will have been notified
during the export process that a request is ready for import.

Imports are not automatic; administrators use tp to perform it.

It is performed in the target system.

It inserts the exported objects into the database following the instructions
that come from the control file along with the data files from the export
process.

The figure in slides

ERP II Lecture 4 - Notes 17

 QTST In PRD is a mistake it should be PROD

This image shows three systems, customizing system and client, quality
assurance system, and production system, and it shows the transport process,

0. Route definition: using TMS to identify route for the order in which changes
travel from DEV → QAS →PRD

1. Exporting from DEV: In DEV you document, release, and unit test all tasks
within a change request then this triggers export so the change request
goes through releases and coherence checks and is then exported to the
directory (\usr\sap\trans)

y3ny hna byhsl awl haga el release then export from to el directory

where a change request ID is added to the import queue of the next

client.

2. Importing to QAS: TMS reads the change request files from the transport
directory and imports them (unpacks them) into the database of the QAS
system (testing environment).

This allows thorough testing of the changes in QAS before deploying

them to the critical production system.

After successful import, the change request is removed from the QAS
import queue and automatically added to the import queue of the next
system in the route - PRD.

3. Importing to PRD: Once testing confirms the changes function correctly in

QAS, you can import them into the PRD system (live environment).

ERP II Lecture 4 - Notes 18

 The TMS again reads the same change request files from the transport
directory and imports them into the PRD system's database.

By using the same packed files, TMS ensures consistency between the
QAS and PRD environments, minimizing the risk of unexpected behavior
in production.

The figure and explanation in Book:

Before transportation and import can occur, you must define strict transport
routes between the different SAP ERP systems in the system landscape.

k2naha plan

To define the routes that change requests will follow, use the Transport
Management System (TMS), which is called with Transaction STMS.

The TMS is essentially the “traffic cop” of change requests: it centrally

monitors the export process to ensure that changes are delivered in the
correct order and notifies you of errors during import.

hrfyn like what cops do, ensure things are in order w lw hsal errors fl
import hy2oli

During an import, files in the transport directory corresponding to each

change request are read and copied into the database of the target system
(exported). In Figure 4.6, the target system of the development system is
the quality assurance system.

ERP II Lecture 4 - Notes 19

 After change requests have been imported successfully, they are deleted
from the import queue, and are automatically added to the import queues of
the next target clients and systems, as defined by the transport route
specified in the TMS.

Typically, the target SAP system after an import to the quality

assurance system is the production system.

Subsequent imports into SAP systems such as the production system are
similarly monitored and triggered in the TMS.

During these imports, the files corresponding to the change requests in

the transport directory are again copied to the database of the target
system. By using the same files that were originally exported from the
development system and tested in the quality assurance system, the
TMS ensures that the same changes are delivered to both SAP systems.

Structure of the Transport Directory

Heard eno msh hys2l f da w eno its for my knowledge bs read just in case

Main components of trans folder:

cofiles: This is the control file directory containing information about the
steps of the transportable change requests as well as the return codes.

ERP II Lecture 4 - Notes 20

 log: Under this directory, all the individual and general transport logs,
statistics, and trace files are located. Administrators should refer to this
directory for troubleshooting functions.

tmp: This is the temporary directory containing some auxiliary temporary

files with control flags, semaphores, and so forth.

buffer: Contains special buffer files with the SID of every system in the
transport group. These files include control information on the transports
that will be imported into other systems and the order of them.

sapnames: Contains information on SAP users performing exports and

keeps track of the status for each change request.rt parameter file.

data: This directory contains the transport data files.

bin: Contains the TPPARAM file, which is the global transport parameter file

Change and Transport System (CTS)

—> SAP refers to tools that support change management as the change and
transport system which includes the following tools:

Change and Transport Organizer (CTO):

—> The Change and Transport Organizer (CTO) helps IT manage development
projects by allowing the distribution of project work for individual developers or
teams between different change requests.

consists of:

Customizing Organizer: enables the creation, documentation, and

release of change requests generated during Customizing

ERP II Lecture 4 - Notes 21

 Enables implementers of SAP ERP to track, view and change the
change requests

Most Used Component

Workbench Organizer: provides a similar functionality as

Customizing organizer but regarding the ABAP workbench

Transport Organizer: provides support for transports that do not fall

within customizing organizer or the workbench organizer

Change requests record all changes made to development objects and

Customizing settings.

Objects from the areas of Customizing and the ABAP Workbench are
managed and recorded in separate requests.

Special checks have been implemented for each of these

applications.

Transport Management System (TMS):

—> The Transport Management System (TMS) is used to model and manage
your system landscape.

y3ny It is used to organize, monitor, and perform inputs for all the
systems within the landscape

—> It is used to import change requests into the quality assurance system for
testing and verification

It provides tools for configuring your system landscape, as well as for

organizing, carrying out, and monitoring transports.

Program tp and R3trans

—> both reside at operating level

TP (Transport Control Program):

—> basically this is used to control imports and exports

The program tp resides at the operating level.

It is used for planning and performing transports between systems.

It controls both the export and import processes.

bs mainly imports 3shan exports are automatic

ERP II Lecture 4 - Notes 22

 The export phase:

Done in the source system.

Extracts the objects from the database and places them on files
at the operating system level, together with a control file and a
transport log.

The import phase:

Performed in the target system.

The exported objects are inserted into the database following the
instructions on the control file that came along with the data files
of the export.

It is responsible for reading change requests in the import queue and

adjusting import queues after imports have been completed
successfully.

It offers extensive control over the transport process ensuring that

imports and exports were done in the right sequence (because an
incorrect can cause inconsistencies in the system).

ensure correct order of imported/exported objects

Used in CTO and TMS.

Doesnt directly handle the data itself but relies on R3Trans to do the
heavy stuff

R3Trans:

When exporting, tp triggers R3trans.

It is also a tool that resides at the operating level.

It creates the operating system data file for the export, and it reuses this
data file during imports.

It is used to communicate with the database in order to read and insert

data as instructed by tp

Concept of SAP Package

—> Packages: cluster different development objects within an SAP System.

ERP II Lecture 4 - Notes 23

 Elements that logically belong together are grouped into a common
Package.

Packages vs. Change Requests:

Package:

permanent

Used for grouping development objects within an SAP system

Provide a logical grouping of related objects

Can be transported between systems

Change request:

temporary until export

Used for collecting and administering all repository changes and

customizing settings

Used for transporting data or copying corrections from one system to

another

Exported and imported to transfer changes between systems

First make a change request, then a package

ERP II Lecture 4 - Notes 24