SAP Transport Management System (STMS) - What is STMS & How to Configure

[samarjeet_singh]

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.

1. Customizing--: It is the process of keeping entries into the standard tables such as company code, credit control area etc [SPRO]
2. 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]
3. 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 packagein 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}

1. These modifications are required to adjust in the development system and recorded into a change request.
2. 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.

1. 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:

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

Thanks & Regards

Samarjeet Singh