SAP Transport Management System (STMS)
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/Pre7/
production but to keep things simple most of the cases we keep DEV as Domain Controller
Member Systems–: The other systems are included in the domain referred to as member systems.
How to Configure STMS
- Log on to the SAP system, which is decided to be the Domain Controller, in client 000 and enter the transaction code STMS.
- If there is no Domain Controller already, a system will prompt you to create one. When the Transport Domain is created for the first time, the following activities happen in the background:
- Initiation of the Transport Domain / Landscape / Group
- Creating the user TMSADM
- Generating the RFC Destinations required for R/3 Configurations, TMSADM is used as the target login user.
- Creating DOMAIN.CFG file in usr/sap/trans/bin directory – This file contains the TMS configuration and is used by systems and domains for checking existing configurations.
--> A popup window prompts to configure domain controller or include in the domain
1.Specify the Domain Controller [DOMAIN_SID]
2.SID, Description
3.Save your entries.
You are asked for the password of user TMSADM.
- Enter a secure password that you do not use for any other purpose.
USER–: TMSADM [Default User]
TMSADM is a communication (System user now) created during TMS configuration
2. Adding SAP systems to the Transport Domain
- Log on to SAP systems (to be added in the domain) in client 000 and start transaction STMS.
- TMS will check the configuration file DOMAIN.CFG and will automatically propose to join the domain (if the domain controller already created). 'Select' the proposal and save your entries.
- For security purposes, system status will still be in 'waiting' status, to be included in the transport domain.
- For complete acceptance, login to Domain Controller System (Client 000) -> STMS -> Overview -> Systems. New system will be visible there. From the menu choose 'SAP System' -> Approve.
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 that shares the transport directory in common is said to be in a group but due to the 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 company code, credit control area, etc [SPRO]
B. 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]
C. Development–:If the customizing does not suit 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”
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 in 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 are not released.
The tasks or change requests are owned by the user and can be released by the owners or the super admin.
NOTE–: It is not the responsibility of a basis consultant to release the change request, but considering the SOW.
Change requests locks the objects and the locks are released 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 REQUESTS and no changes are allowed to that request [After Release]
The change requests contain the changes in the database and they could not get copied to other systems using table copy/table export etc
So SAP introduced a 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 that 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 a change request is released it is referred to 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, a 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 transports.
TP_DOMAIN_SID.PFL –: is used to provide profile parameters for TP. It specifies the profile, exe locations along TP version.
Example–:
tp addto buffer <TR> SID CLNT100 pf=E:\usr\sap\trans\bin\Tp_Domain_SID.PFL
TP Import <TR> SID CLNT100 pf = usr\sap\trans\bin\TP_DOMAIN_SID.PFL U18
What does U18 mean:
U represents Unconditional mode that will be used while importing transport. Here is the explanation of different option that can be used:
1: Ignore that this change request was already imported into this system and import everything again.
If you do not set this mode, only objects that have not already been imported successfully are imported again.
2: Overwrite originals
6: Overwrite repaired objects
8: Ignore the restriction resulting from table classifications and import all table entries into specified clients
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 the command.
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 come 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, timestamp of the request release (export/import)
SLOG–: It specifies the Job Steps.
ULOG–: It specifies the TP commands
Secstore–: is a transaction that is used to check the RFC connections
which are pointed to an obsolete system. The connections with the “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 username file]
TP writes ALOG,ULOG and SLOG in the trans/log directory.
TP writes the transport request number into the 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.
Transport layer—
It is a path that 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 that 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 are assigned to transport systems that form 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 to as Integration System
PRD is the system where business activities are performed [without any development, testing and quality] which is referred to as Delivery System.
TRANSPORT ROUTES:
Integration/consolidation Route and Delivery Route
These routes are provided default in the 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 a 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 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 imports the data into the 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
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, it's permissions writability to log, sapnames, tmp dir.
IMPORT TROUBLESHOOTING-:
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 the 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.
Alert Moderator
Add-on Conflicts–: When add-ons 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 that are required in production with immediate effect where there is no time for quality checks. Then it is copied manually and imported into the production system, however, the transport request remains in the queue for later import.
Comments
Post a Comment