STMS [SAP Transport Management System]

Domain Controller–: It is used to control the landscape. There will be only one domain
controller in the landscape. Initially it is set to development and later can be moved to on
higher available system such as PRD/QAS/Pre-production but to keep the things simple
most of the cases we keep DEV as Domain Controller
Member Systems–: The other systems are included in the domain and referred as member
systems.
The 2 options get popped up when STMS transaction is executed either to configure domain
or include the system in the domain.
Domain controller is created by using DOMAIN_SID and other members are included by
respective HOSTNAME’s and INSTANCE Number’s.
Steps to Include System in the Domain–:

1. Execute T-code STMS in the member system.

 A popup window prompts to configure domain controller or include in the domain

 Specify the Domain Controller [DOMAIN_SID]
 Target Host
 System Number

USER–: TMSADM [Default User]

TMSADM is a communication user created during TMS configuration
   2. A message SAP System waited to be included in the transport Domain is displayed to
the external system.
Approving the Inclusion of Systems:

 Logon to the domain controller [000 Client]

 Execute T-Code STMS
 From the Menu à Systemsà Select the system that Needs to be approved.
 The system is waiting to be included
 Select the system and click on APPROVE from the menus SAP System.

CREATING VIRTUAL SYSTEM’s

1. It is a standard practice in the industry to create Virtual Systems as the real systems
could not be available during the initial configuration [DEV Server is procured during
the implementation, QAS will be procured after 3 to 4 months from the Kickoff date
and the PRD is procured there after]
2. Virtual Systems can be replaced by real systems and the configuration new points to
the real systems.
3. Execute T-code STMS [Domain Controller]–> Menu overview systems–>SAP
Systemsà Create–> Virtual System

TRANSPORT GROUP
It is a naming convention group_SID to configure all the systems to a single transport group
i.e, all the developments which are performed in the development system will be
automatically available to other systems in the landscape.
The group of systems which shares the transport directory in common are said to be in a
group but due to sensitivity of PRD it is moved into a separate group.

NOTE–: It specifies where the transport requests are grouped – transport group
                       Z>  à Adjust Import Queue.
This Icon will be enabled only if we are using different transport groups.
Virtual System–: addressing the transport requests.
ADOPTING A SYSTEM-:
The SAP system is adopted by using customizing and development.

A. Customizing–: It is the process of keeping entries into the standard tables such as
B. company code, credit control area etc [SPRO]
C. Cross-Client Customizing–: It is the process of keeping entries into the cross-
client tables like logical systems, client tables, password, and restrictions tables etc
[SALE, SCC4, SM30, –> [USR40]
D. Development–:If the customizing does not suits the requirements then
development is opted to develop programs, function modules, screens, menus,
transactions, tables field etc.

In the customer namespace “Y”, “Z” or “company name”

 Programs are developed in SE38

 Functional modules are developed in SE37
 Screens are developed in SE51
 Menus are developed in SE41
 Transactions are developed in SE93
  Tables and fields created are developed in SE11
 Forms are developed in SE71

All the above repository objects can be developed in SE80

Change Request-: It is used to record the changes that are performed during customizing,
cross-client customization and development.

 These change requests are created in SE01/SE09/SE10 and stored table E070
 The naming convention of the change requests are <SID>K9xxxxxxxx
 These change requests are created by project manager and assigned to project team
members.
 Each change request contains one or more tasks [tasks are similar to change request
number and associated with a change request]
 If the tasks are not released then the associated change requests is not release.

 The tasks or change requests are owned by the user and can be released by the
owners or the superadmin.

NOTE–: It is not the responsibility of a basis consultants to release the change

request, but considering the SOW.
Change requests locks the objects and the locks are release once the change
requests are released.
CHANGE Request Release–:
The change requests are release in SE01/SE09/SE10.
Once the change requests are released they are called as TRANSPORT REQUSTS
and no changes are allowed to that request [After Release]
The change requests contains the changes in the database and they could not e
copied to other systems using table copy/table export etc
So SAP introduced change request mechanism to record the changes during
customizing and development and upon release, transport to other systems
independent of OS and DB.

SCC1–:
It is used to copy the change requests bw clients in the same systems for unit
testing before they are released. It is used for client specific objects.
TP–: It is a transport protocol which is used to export the change requests and import
transport requests.
Change Request Release–:  Release of change requests are performed by developers and
functional consultants and once change request is released it is referred as TR.
The transport requests are stored in trans directory
[usr/sap/trans]
Transport directory is used for transport, support packages, binaries for
transportation of requests, add-ons, languages, third party tools, upgrades and
enhancements packages.
 1. BUFFER–: Buffer directory is created to host all the transport definitions [address of
change requests]

Transport request number, name of the owner and time stamp

NOTE-: Virtual system name and real system name should be same. If they
differ then all the change requests have to be added manually.
STMS–>extras–>other requests–>add [tp add to buffer <TR>]

1. BIN–: It is used to provide the configuration file for domain controller and TP profile
parameters.

 TP (tp.exe) is an agent (executable) which is used to transport the objects [Move

the objects from database to OS and vice-versa between the systems]

    DOMAIN.CFG–:  It contains the configuration of domain such as the systems,

user (TMSADM)

TMSADM is a communication user which is created during TMS configuration. It is used by

TP to transport the objects bw the systems.
TMSUP and TMSADM RFC connections are created bw all the systems in the
landscape to facilitate the transports.
TP_DOMAIN_SID.PFL –: is used to provide profile parameters for TP. It specifies the
profile, exe locations along with TP version.
Example–:
     
TP Import <TR> SID CLNT100 pf = E:usr\sap\trans\bin\TP_DOMAIN_SID.PFL

1. BUFFER–: It is used to address the transport requests based on the systems in the
landscape. Each system in the landscape contains to identify their requests. The
transport requests can be added manually by using command.

tp addto buffer <TR> SID CLNT100 pf=E:\usr\sap\trans\bin\

Tp_Domain_SID.PFL

1. CO-FILES–: Command/control files which are used to govern the transports.

Transports are moved by using the co-files which start with “K” [K900201]
2. DATA–: It is a data file where the actual changes are available. Cofile moves the
corresponding data files when transported is initiated with the help of TP, they comes
with extension “R” [R901201]

NOTE–:  Cofiles and corresponding Datafiles are must to transport an object.

1. EPS–: Electronic Panel Service

   
           It is used to host the patches. The patches are downloaded to this
directory i.e, EPS/in
It is used to apply Support Packages, languages add-ons etc.
 1. SAPNAMES–: The name of the developer/functional consultant who is
developing/customizing the changes and release them to the trans directory.
2. TMP–: It is used during transport/add-ons and support packages application. If this
directory contains any entries. Consider the application [transports, add-ons and
support packages] are choked/blocked or aborted.

LOG–: It is used to display the transport logs. In SAP naming conventions transports means
it can be an export/import. These logs are stored in this directory.
ALOG–: Application Log Specifies the username, transport request, time stamp of the
request release (export/import)
                               
SLOG–: It specifies the Job Steps.
ULOG–: It specifies the TP commands
Secstore–: is a transaction which is used to check the RFC connections which are pointed
to obsolete system. The connections with “RED” mark can be deleted.
WHEN A TRANSPORT REQUEST IS RELEASED

 User selects the change request in SE01 and release them.

 TP gets initiated and connects to DB to convert the DB specific changes to OS
independent changes and creates “COFILE” that’s starts with “K” and DATAFILES
that starts with “R”
 Cofile is a command/control file which is used to control the transports.
 Datafile contains the data that need to be imported into target systems.
 TP also writes into entry into SAPNAMES directory [in the usersname file]
 TP writes ALOG,ULOG and SLOG in the trans/log directory.
 TP writes the transport request number into target system buffer file [trans/buffer]
 TP is controlled by using TP profile TP_DOMAIN_SID.PFL

Development

 It is the process of development programs, reports, screens, menus, functional

modules to cater to the requirements of the customer.
 These are system specific and recorded to change request of type work bench
requests.
 In order to develop the program we need to use the customer namespace Y or Z.
 The user who develop the programs need to be registered in market place and obtain
a onetime developer key (which is chargeable) this needs to be entered during
development of the object.

DEVELOPMENT CLASS/PACKAGE–:

 It is used to group the objects which is of similar nature probably based on modules
or sub-modules or a company code.

Execute Transaction SE80, select package and create a new package. Package
definition requires the following inputs-:

1. Short Description
2. Application Components [modules]
3. Software component—HOME
4. Package Type—main or sub package
5. Transport layer—It is a path which is used to move the objects bw the systems. This
layer is mandatory for defining the transport route bw the systems.

Each program/repository objects need to be assigned with a valid

development class/package, if they are assigned to $TMP class or saved as
Local Objects, they are not transportable.
Transport Layers are defined in STMS

 They are used to establish the path to move the objects.

 SAP is a standard transport layer used to move SAP standard objects. Z<SID> is
custom layer by default available to move the development objects.
 Whenever an object is defined it need to move to a respective package in the other
systems in the landscape.
 So while defining the object they are assigned to a development class/package.
 Development class/packages are defined in SE80
 While defining a development class it needs a transport layer which is defined in
STMS
 Each program is assigned to a development class/package

Program Definition/Development Class/Package

Development class/Package transport layer
Transport layer- transport routes
Transport routes are assigned to transport systems which forms a landscape
Execute STMS – Transport routes – establish the landscape

DEV is the system where integration/development and customizing is initiated

which is referred as Consolidation System.
QAS is the system where consolidation of objects, testing, quality assurance,
training etc is initiated, which is referred as Integration System
PRD is the system where business activities are performed [without any
development, testing and quality] which is referred as Delivery System.
TRANSPORT ROUTES:
Integration Route and Delivery Route

 These routes are provided default in system

 The route between consolidation and integration system is referred as
CONSOLIDATION ROUTE
 The route between integration system and delivery system is refereed as DELIVERY
ROUTE

IMPORT THE TRANSPORT REQUESTS-:

1. The system landscape is defined and STMS is consistent

2. If the systems are not in the initial landscape then manually add transport requests.
 3. In the systems are sharing the transport directory [/usr/sap/trans] then no copy is
required, if the systems belong to different transport groups then copy of requests is
required by using option adjust IMPORT QUEUE.

Execute STMS –> click on IMPORT –> Select the system –> click on IMPORT/IMPORT all to
import the transport request(s).

Specify the client number, specify the schedule to import [immediate,

later, date and time, after event, during system startup etc]
Provide the unconditional modes [overwrite originals, leave the requests
in queue for later import]
Monitor the TP LOG [ULOG/ALOG/SLOG]
While importing the request it checks for command {control file} along
with data file, these are mandatory for import.
***Disable the fully loaded truck after the implementation by
using parameter
No_import_all = 1
The sequence of the transport requests is very important and mandatory.
Example–:

1. Development Package
2. Domains
3. Data elements and table
4. Programs
5. Screens
6. Menus
7. Function Modules

IMPORT PROCESS

 The TP with the help of r3trans import the data into database reading
cofiles/datafiles.
 Every package, add-on, language, support patches are applied using “tp” and
“r3trans”, these are swapped with extensions .car or .sar [compressed/sap archive].
These are uncompressed/dissembled during deployment.
 tp and r3trans converts the OS independent cofiles/datafiles to database specific
format during import.
 Tp, sapcar and r3trans are OS/DB/32/64, Unicode and non-unicode dependent.
 Tp reads the transport profile, checks the transport directory, its permissions
writability to log, sapnames, tmp dir.

IMPORT TROUBLE SHOOTING-:

1. Check tp connectivity and to errors [STMSàsystemsàcheckàtransport directory, tool

and tp connection]

If GUI is not accessible then use command

>tp connect SID pf=/usr/sap/trans/bin/TP_SOMAIN_DEV.PFL
    2. Check the “RDDIMPDP” jobs are scheduled in client 000 with user like DDIC
    3. Ensure that STMS is configured and it is consistent
    4. Check whether tp is able to read the transport profile, check the transport directory
and its permissions writability to log,sapnames, tmp dir
    5. Check the tmp directory which should not contains any hanging recods.
    6. Check the log directory for ULOG, ALOG, SLOG and transport specific log [check the
return codes]
    7. In R/3, check if the transport RDDIMPDP is scheduled correctly and event_triggered.
To check on the success of all related background processes [RDD* jobs] via tcode SM37
    8. Problems may result from wrong version of tp or r3trans, tp not running [unix-: ps –
ef|grep tp] use task manager on windows
    9. Check whether database has enough space or enough free disk space.
  10. When analyzing a problem, compare the logs and buffer entries into tables TRBAT and
TRJOB.
  11. If a communication problem between tp and R3 is indicated, try calling SAPEVT on
operating system level and see if it trigger RDDIMPDP.
  12. If multiple tp are running then delete/kill all of them and restore the transport [which
will start from the point where it has been stopped]
  13. Check whether any objects in locked/repaired status in SE03 and release/unlock them.
  14. Ensure that at least 2 background jobs are in place.
  15. Local change requests or the objects that are assigned to a $tmp class are never
transported.
  16. Do not delete Pat01/Pat01/tmp/TRBAT/TRJOB directory entries manually.
Import the requests in STMS-:
Import the requests manually using tp commands at OS level.
SU –sidadm
Cd /usr/sap/trans/tmp
Ls –lrt
By executing these commands you can view the files writing into tmp directory. Size gets
increased.
          Ps –ef|grep tp –> to check tp is connected or not
MODIFICATION ADJUSTMENT-:
                                        While applying support packages some of the objects
are modified/uploaded.
Due to this modification the system may be inconsistent and these objects are
displayed in SPDD and SPAU.
SPDD–> Data Dictionary Objects [domain, data elements, table, structure, view]
SPAU–> {Screens, menus, functional modules etc}
 a. These modifications are required to adjust in the development system and recorded
into a change request.
b. These changes are transported to other systems in the language using STMS, but
while applying support packages it prompts to include the transport requests if any,
so that no changes are required/allowed in the other systems.

Add-on Conflicts–: When add-on’s are applied they may conflict with existing basis
packages.

a. SAP provides CRT [conflict resolution transport]. These are applied manually using
TP at OS level tp add to buffer and tp import <tr>.

Preliminary Transports/Emergency Transports:

a. There are some changes which are required in production with immediate effect
where there is no time for quality checks. Then it is copied manually and imported
into production system, however the transport request remain in the queue for later
import.