ADM 325 Software Logistics
ADM 325 Software LogisticsBy : Rully Kartaga
Place : ASSETA
Objective :
Understand the SAP System Architecture and the client
concept
Plan, set-up, and maintain an SAP System Infrastructure using
the Transport Management System (TMS)
Support Customizing and development projects using software
logistics conceps and tools
Distribute changes in the system landscape by transport and
client copy or client transport
Perform modification adjustment during application of Support
Packages and upgrades of your SAP Systems
Concepts of Change Management
Introduction to Changes in SAP Systems
The only constant in an SAP environment is change. From the
original concept through phases of implementation to maintenance
updates, there is a constant stream of changes in configuration
settings and ABAP code. These changes are necessary to fulfill the
ever changing users requirements and business needs. One of your
main goals as a system administrator or project manager is to
manage these changes. Managing changes means making sure that only
fully tested changes get promoted to the production environment.
The delivered SAP software provides a number of tools to assist you
in fulfilling this important responsibility. Before you can use the
SAP software to control the business processes in your company, you
must first adapt it to your own business needs. This is usually
done in an SAP implementation project. Adapting and configuring is
an ongoing process. Even after you start using the system
productively, you still need to make changes to the SAP
configuration. These configuration changes may be due to business
or organizational changes in your company, or due to the
implementation of new SAP functions. The changes will also be
linked to an upgrade to a new SAP release. These configuration
settings are commonly known as customizing. To control changes in
an SAP system, you must first understand what changes are being
made, who should make them, and what their effects are. The
following figure presents a logical representation of the different
types of data in your SAP database.
Cross-Client Data
The SAP repository makes up the largest portion of your
cross-client data.
The repository contains:
ABAP Dictionary
ABAP program source code
Screen definitions Other objects necessary in the SAP
development environment
Each piece of ABAP Dictionary information is entered only once
and is then available anywhere in the system at any time. The ABAP
Dictionary automatically supplies all new or changed information on
the structure of data, thus providing current runtime objects and
ensuring data consistency and security.
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 of an ABAP program. Rather,
they use a copy generated once only during runtime (early binding).
Runtime objects, such as programs and screens, are automatically
regenerated (late binding) when a time stamp comparison between the
object and the ABAP Dictionary detects a difference.
This combination of early binding and late binding ensures that
the active integration of ABAP Dictionary information does not
affect system-wide performance. All performance-critical
information is stored in the runtime objects and is always kept
up-to-date.
Cross-client customizing is the data contained in a set of
configuration tables.
The data exists once and is shared by all clients in the system,
for example, a factory calendar or the number of decimal places for
currencies.
Client-Specific Data
Client-specific data is visible and applicable to only one
specific client in an SAP system. All client-specific data is
classified as either customizing data, application data, or user
master data.
Customizing data is configuration settings stored in tables
identified as customizing tables by specific delivery classes in
the ABAP Dictionary.
Customizing configures the business processes of a company that
uses SAP software. Changes to customizing are implemented by using
a set of specific transactions known as customizing
transactions.
Application data can be either master or transaction types of
data that is entered into the system through the application
business processes or data loads. Customer master, vendor master,
purchase order, sales order are all examples of application data.
Changes made to application data are controlled by either SAP
authorizations at the user level (this topic is covered in class
CA940) or by restrictions placed by the configuration settings in
the customizing tables at the application process level.
User master data is contained in a specific set of tables that
pertain to the user login ID.s. The user master data contains user
login information such as: user default parameters, user groups,
roles, authorizations, user passwords, and aliases. This data is
controlled by the security and/or user administrator (this topic is
covered in class CA940).SAP Clients
A client, a sub-unit in an SAP system, is technically,
organizationally, and commercially self-contained. A client has its
own set of user master data, application data, and customizing
data. The benefit to having this multi-client capability in an SAP
system is that you can create unique data environments for sets of
users without the necessity of maintaining multiple physical
databases. From a technical view, a client is identified by a
three-digit numeric code ranging from 000 to 999. Every
client-specific table in the database will have this three-digit
identifier as the first field of the primary key.Although data from
different clients is stored in common tables, the data is logically
separated by the SAP kernel. When users log on to an SAP system,
they must choose a specific client. After successful log on, these
users can only access data belonging to this client. The database
interface restricts access to client-dependent data by
automatically adding the client number to all select statements on
tables containing the client key.
SAP recommends a minimum of three standard client roles. The
standard client roles fulfill the optimal minimum requirements of
your SAP system.
Client CUST is the central customizing client where complete
adaptation of SAP to customer-specific needs takes place. All
changes performed in this client are recorded so they can be
supplied to the other clients using the Transport Management System
(TMS). Client QTST is used to test and verify the new customizing
settings in the application. Client PROD is the client for
production activities, that is, where your companys business is
carried out. Customizing changes imported into this client have to
be first tested carefully in the QTST client in order to ensure
that production operation is
free of disruption.
Types of Changes Controlled via TMS
There are four different types of changes to your data that you
control through
the Transport Management System (TMS): Customizing,
Development,
Enhancements, and Modifications.
Customizing basically accomplishes two goals. Customizing
describes the organizational structures of a company to the SAP
software and also defines the business processes that a business
wants to implement.
An SAP R/3 system delivers over 1,000 business process chains.
Most companies only use a very small percentage of these business
processes.
During customizing, entries are made into customizing tables.
During the application execution, the ABAP programs read the
customizing tables that indicate the logic paths the programs
should follow. Most customizing is considered client-specific but
there is also a small amount of cross-client customizing.
Customizing does not require any ABAP code knowledge or code
changes.
Development, enhancements, and modifications all refer to
changes or additions to the SAP repository. Changes to the
repository are always client-independent. All of these types of
changes require knowledge of the ABAP workbench and entail creating
or changing ABAP code or definitions in the ABAP data dictionary.
The type of object being changed determines whether it is
considered a development, enhancement or modification.
Development is creating or making changes to customer created
repository objects. When a customer has the need for reports or
transactions that are not delivered in the SAP standard, the
capability to write them exists within the ABAP workbench. Customer
developed objects must fall within the customer namespace: All
objects must start with either the letter Y or Z.
Modifications are changes to SAP delivered repository objects.
Modifications are allowed but should be avoided because of issues
with support and upgrades. Although modifications sometimes appear
to be an easy fix to a specific problem, be aware these changes
will have to be readdressed whenever an SAP support package
contains that object or whenever you upgrade to a new release of
the software.
Enhancements are a middle ground between development and
modifications.
Enhancements allow you to add customer specific logic flows to
SAP delivered programs without changing the delivered SAP code. If
possible, you should always try to use enhancements before deciding
on using modifications because this avoids the problems with
support and upgrades inherent with modifications. Enhancements are
done using a delivered tool called customer exits. Customer exits
are areas of SAP delivered programs where customers can enter their
own ABAP code. SAP Landscape
The two main goals for the SAP system landscape include
providing the TMS the capability to isolate or protect the
production system from untested or unapproved changes and
delivering the capability to set up and control the separate data
environments required in the software development cycle.
These goals are achieved by using a combination of SAP systems,
clients, and user roles.
The system landscape should enable you to:
Protect application data using
Client roles
Authorization concepts
Perform development, quality assurance, and production
activities in separate environments to ensure
Consistency of repository objects
Secure and stable production environment
The minimum SAP-recommended system landscape consists of three
SAP systems: a production system where users perform their business
functions; a quality assurance system, that is virtually identical
to production, where data owners perform quality assurance testing
of changes; and a development system, where all changes originate
from users performing customizing, developers creating or changing
ABAP code, or system administrators performing maintenance or
upgrade functions.Transport Management System ConfigurationChange
and Transport System Prerequisites
Step 1: Release and export of a change request from the DEV
system
A copy of all objects included in the change request is written
to files in the usr/sap/trans directories. This step also prevents
any further changes from being recorded to the original change
request.
Step 2: Import into the QAS system
The import programs at the operating system level read the files
created in step 1 and copy the objects into the QAS system and
activate the changes. The files are left intact in the
usr/sap/trans directories.
Step 3: Import into the PRD
Once the change is tested and approved, the import programs at
the operating system level read the files created in step 1 and
copy the objects into the PRD system and activate the
changes.Transport Directory Structure
Prior to installing the SAP software, you must allocate some
disk space at the operating system level on the system that you
have chosen to be the transport host, the system where the
transport directory resides.
Most customers choose the development system as the transport
host because it is typically the first system installed. When you
run the install program, the transport directory and its
subdirectories are automatically created.
The Subdirectories of the Transport Directory
bin
Contains the transport parameter profile, called TP_.PFL, and
the domain configuration file, called DOMAIN.CFG.
data
Stores the actual data files of the change requests containing
customizing and development changes.cofiles
Contains the control files or command files used by the
transport tools at the operating system level. The information in
these files includes data on transport types, object classes,
required import steps, and return codes. These files also contain
the current status of the change request in the various systems of
the transport group.
buffer
Contains an import buffer for each SAP system in a transport
group. These buffer files indicate which change requests are to be
imported into the respective system. Buffer files also provide
information on the steps that must be performed for import and the
order in which requests are to be imported.
log
Includes all general log files, as well as all log files
generated by the export and import of change requests or client
copies.
tmp
Needed to temporarily store log files and semaphores during
transport activities.
actlog
Stores the log of user actions in SAP for all change requests
and tasks. This is the only subdirectory of the transport directory
that is not accessed by the transport tools. This directory is
accessed only by the Change and Transport Organizer (CTO).
sapnames
Contains a file for each SAP user working in the CTS. These
files log transport activities for each change request by used
ID.
olddata
Used when you clean up the transport directory. Old exported
data that is to be archived or deleted is stored in this
directory.
eps
The download directory for the SAP Support packages.
Client Copy
Overview of Client Copy and Client Transport Tools
Types of Data in a Client
It is important to understand the types of data that are in a
client. The client copy tools move data based on its type. To
understand what data will be moved when you do a client copy, you
must first understand the types of data that can be moved.
The client copy and client transport tools:
Replacethedataofoneclient with data from another client
Do not combine the data of different clients
Client data is categorized as one of the following types of
data:
Customizing data
User master data Application data as defined by the data table.s
delivery class
Application data can be copied only with the corresponding
customizing data.
Customizing data from the Implementation Guide (IMG) is used to
configure how the SAP system will work. It includes data about how
your company does business. Examples of customizing data include
company codes, plants, sales organizations, pricing conditions.
User master data is information about SAP user accounts.
Application data includes both master data and transaction data.
Examples of master data include materials, customers, and vendors.
Examples of transaction data include purchase orders, sales orders,
production orders, and purchase requisitions.
Client Copy and Transport Tools
Once the client is created, you need to load data into the
client. You can load data from another client that already exists,
or you can load data from client 000.
Local client copy between clients in the same SAP system
Remote client copy between clients in different SAP systems
Client transport between clients of different SAP systems
Remote client copy and client transport differ according to the
way in which data is transferred.
In a remote client copy, data transfers directly between the
source and
the target client using remote function calls (RFCs) through a
network connection.
Local client copy between clients in the same SAP system
Remote client copy between clients in different SAP systems
Client transport between clients of different SAP systems
Remote client copy and client transport differ according to the
way in which
data is transferred.
In a remote client copy, data transfers directly between the
source and
the target client using remote function calls (RFCs) through a
network connection. In a client transport, data is exported to a
file at the operating system
level. At some future time, the client is imported from the file
system
to the target system.
Within the client copy tools, the data you can select to be
copied includes user master data, client-specific customizing data,
and application data.
SAP R/3 Repository objects, such as ABAP programs, are not
transported with the above tools. Development objects can be
transported only using change requests.Local Client Copy
A local client copy copies between clients within the same SAP
system. Both a
local and remote client copy must be initiated from the target
client using the
following steps:
After creating a new client, log on to the target client as SAP*
with the initial
password PASS. Perform the client copy using the menu options
found under
Select the data to be copied using a profile.
Assign the source client for customizing data, application data,
and user
master records.
Begin the client copy. Because copying is a lengthy process, use
background processing.
Remote Client Copy
A remote client copy allows you to copy between clients in
different SAP systems. You can use a remote client copy to
transport client-dependent and client-independent customizing data
between SAP systems.
A remote client copy proceeds in the same way as a local copy,
but sends the data through a remote function call (RFC) connection
to the target client.A remote client copy is easy to use, and does
not require file system space on operating system level. The
limitations of a remote client copy are as follows:
A remote clien tcopy does not create a file at operating system
level, so there is no hard copy of the client to be copied.
Therefore, the same, identical client copy cannot be duplicated at
a later date.
Cross-client customizing objects are copied during a remote
client copy.
To be able to transport all data during the client copy, the
structures of all copied or transported tables in both systems must
be identical.
During remote client copy, an automatic repository consistency
check is performed. If inconsistencies are detected, the client
copy is terminated and an error message is displayed
