Introduction to Transport Management System (TMS)
Why do we need a Transport System?
The CTS components play an important role in the overall development and customization environment.
CTS is an instrument for:
• Administering & controlling new development requests.
• Managing transports
• Recording of where and by whom changes are made
• Configuring systems landscape
Overview of CTS Components
• CTO (Change and Transport Organizer) – It's the main tool for managing, browsing, and registering the changes done on the repository and customizing objects. It's the central point for organizing the development projects. SE01 is the transaction with new extended view.
• (TMS) Transport Management System – Is used to move, manage, control, copy development objects and customizing settings in an orderly fashion across SAP systems in a landscape through pre-defined transport routes (RFC Connections). The transport process basically consists of exporting of objects out of the source SAP system and importing them into the target SAP system/s.
• Transport Tools – The actual transports happen in the back-end at the OS level using transport tools, which are part of SAP Kernel and includes the program R3trans and the transport control program tp.
The system landscape (also known as SAP System Group) is the arrangement of SAP servers. Ideally, in an SAP environment, a three-system landscape is recommended. It consists of the
1. Development Server – DEV
2. Quality Assurance Server - QAS
3. Production Server - PRD.
Transport cycle in a very basic sense, is the release of new Developments/ Customizing Changes from DEV which are imported in both Quality and Production systems. However, import in PRD can happen only once integration testing and quality check has been performed in QAS (and marked as checked).
What is Customizing? How does TMS help in Customizing
• Customizing is a process to adapt the SAP system according to the customer's need. To perform the customizing, users and consultants take help of SAP Reference Implementation Guide (IMG), which is accessible through transaction SPRO.
• Customizing is ideally done in DEV. The Transport Organizer (SE01) is used in conjunction with IMG to record and transport customized changes further.
Most of the Customizing changes (though, not all) are client-specific, i.e., the changes are supposed to be reflected in a particular client only and not intended for all the system clients. When the Transport Request is exported, it extracts the relevant table entries from the database of the SAP system and copies them to the transport directory. Relevant table entries are locked when the customizing transaction is being used. However, they are unlocked as soon as the changes are saved to a Transport Request.
Repository and Development Changes
• Apart from customizing already existing objects, new developments are also required in most of the cases. Development object is any object that is created (developed) by you in SAP system.
• Collection of all such objects (client-specific or cross-client) is called Repository.
• Development is mostly done with the help of ABAP Workbench (SE80), therefore such changes are also known as Workbench Changes.
• Examples:
o ABAP Dictionary Objects: Tables, Domains, Data elements, etc.
o ABAP Programs, function modules, menus, screens
o Documents, Application defined transport-objects, etc.
• Workbench is also fully integrated with TMS, to record and transport the changes.
Most of the Workbench changes (though, not all), are cross-client, i.e. changes will be reflected in all the system clients of the target system. Objects transported from the source system overwrite objects in the target system that has the same names.
Clients and the type of Data in SAP System
• Conceptually, client is a technical and organizational independent unit, that contains its own set of data (Master Data, Application/ Operational data, Customizing Data)
• Clients create separate environments for users from different user groups or with a different purpose, within same SAP system, without actually using different database.
• From Technical point of view, client is specified using 3-digit numeric ID, which also acts as the value for the table field 'MANDT', in case of client-specific jobs.
Among client specific data, there are 3 types of data:
• User Master Data contains the user login information, including the username, the password and the user defaults, the authorization profiles or roles, and the other useful information such as user groups, communication and so on. This data is physically present in a specific set of tables (the USR* tables).
• Customizing Data contains the configuration settings to customize organizational structure and the business processes for the companies implementing SAP. This data is client dependent and is stored in tables known as customizing tables.
• Application Data are also client dependent and normally users distinguish two types' master data and transactional data.
1. Master Data such as vendor master, material master (tables such as MARA)
2. Transactional data such as sales order, financial documents, Production Orders (POs) and so on.
Client Customization Options
Transport Directory and Its configuration
SAP Transport Directory:
• It is the global transport directory (/usr/sap/trans), which is actually a shared location (residing in the Domain Controller System) among all the member systems of a landscape (system group) .It also contains certain subdirectories, that are created automatically during the installation of the SAP system. This is mandatory for setting up the Transport Management System.
• Basically, Transport Directory is the location where all the changes are saved (in the form of files) after they are released from DEV. Therefore, it acts as a source for the changes to be eventually imported in DEV and PRD. Hence, we have to make sure that the transport directory is shared properly among all the systems in a landscape.
As an example, in Windows NT, the shared directory location can be accessed using the following address: \\<SAPTRANSHOST>\sapmnt\trans where SAPTRANSHOST (Domain Controller System's address) is defined in hosts file in Windows Directory of all SAP systems in the landscape. Domain Controller – is one of the systems in a landscape that act as an overall controller for change management and transport process in the landscape. Domain Controller is chosen (out of D / Q / P) by the team of system administrators, on the basis of system availability and the time of installation.
Main Subdirectories:
• Cofiles: Contains Change Request Information files with complete details and commands.
• Data Files: Contains the actual values and data to be used in implementing the change.
• Log: Contains Transport logs, traces or statistics, used for trouble-shooting, in case any error occurs in the transport process.
• EPS: Download directory for advanced corrections and support packages
Other Subdirectories are:
• bin: Configuration files for tp (Transport Program) and TMS
• olddata: Old Exported Data for archival or deletion
• actlog: Action logs for all requests and tasks
• buffer: Transport buffer for each system declaring the transports to be imported
• sapnames: Information regarding transport requests made by respective users
• tmp: Temporary and data log files
Setting up of Transport Directory and TPPARAM
• While configuring TMS, one of the main pre-requisite is to setting up the Transport Directory and the Transport Parameter file.
• It ensures that the Directory is shared properly among all the systems in a Landscape, for that all the systems taking part in the group/landscape are to be included in the global configuration file TPPARAM (transport parameter file), located under the bin subdirectory of /use/sap/trans. We have to make sure that the entries for all the participating systems are made in this file.
• In case, any entry is missing, copy another system's entry and change the values (for instance, System ID, Host name)
• At the time of installation, transport directory & the sub-directories are created automatically, including an initially configured template of TPPARAM file.
Operating System Tools - TP and R3trans
tp – The Transport Control Program:
• tp is the SAP program that administrators use for performing and planning transports between systems and also in upgrades of the SAP systems. This is used by the CTO and TMS.
• Actually, tp uses other special tools/programs and utilities to perform its functions. Mainly, it calls R3transutility program. However, it also offers a more extensive control of the transport process, ensuring the correct sequence of the exported/imported objects, to avoid severe inconsistencies in the system, which may arise due to wrong sequence.
• tp is located in the standard runtime directory of the SAP system: /usr/sap/SYS/<SID>/exe/run. It is automatically copied in the installation process.
• As a pre-requisite, the tp global parameter file (TPPARAM), must be maintained, specifying at least, hostnames of the systems taking part in the transport process.
• tp is mainly used for performing imports in target systems. It uses utilities called Import Dispatchers –RDDIMPDP & RDDIMPD_CLIENT_<nnn>, these are ought to be scheduled as background jobs in every system where imports will be performed. If for any reason they are deleted, we can schedule these jobs by running report RDDNEWPP.
• These jobs are actually "event triggered", meaning that tp sends a signal (an event) to the R/3 system and the job starts. These events are named as SAP_TRIGGER_RDDIMPDP andSAP_TRIGGER_RRDIMPDP_CLIENT.
R3trans – The Transport Control Program:
• R3trans is the SAP system transport program that can be used for transporting data between different SAP systems. It is normally not used directly, but called from the tp control program or by the SAP upgrade utilities.
• tp controls the transports and generates the r3trans control files, but does not connect to the database itself. All the "real work" is done from R3trans.
• It supports the transporting of data between systems running on different OS and even different DB.
How to configure TMS (Transport Management System)
TMS Configuration
• TMS is the transport tool that assists the CTO for central management of all transport functions. TMS is used for performing:
o Defining Transport Domain Controller.
o Configuring the SAP system Landscape
o Defining the Transport Routes among systems within the system Landscape
o Distributing the configuration
• Transport Domain Controller – one of the systems from the landscape that contains complete configuration information and controls the system landscape whose transports are being maintained jointly. For availability and security reasons, this system is normally the Productive system.
Within transport domain all systems must have a unique System Ids and only one of these systems is identified as the domain controller, the transport domain controller is the system where all TMS configuration settings are maintained. Any changes in to the configuration settings are distributed to all systems in the landscape. A transport group is one or more systems that share a common transport directory. Transport Domain – comprises all the systems and the transport routes in the landscape. Landscape, Group and Domain are the terms that are used synonymously by system administrators.
Step 1:Setting up the Domain Controller
• 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, system will prompt you to create one. When the Transport Domain is created for the first time, following activities happen in the background:
o Initiation of the Transport Domain / Landscape / Group
o Creating the user TMSADM
o Generating the RFC Destinations required for R/3 Configurations, TMSADM is used as the target login user.
o 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.
Step 2:Transaction STMS
Step 3: 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 purpose, 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.
Step 4:Configuring Transport Routes
• Transport Routes – are the different routes created by system administrators and are used to transmit changes between the systems in a system group/landscape. There are two types of transport routes:
o Consolidation (From DEV to QAS) – Transport Layers are used
o Delivery (From QAS to PRD) – Transport Layers not required
• Transport Layer – is used to group the changes of similar kinds, for example, changes are done in development objects of same class/category/package, logically should be sent through same transport route. Therefore transport layers are assigned to all objects coming from DEV system. Layers are used in Consolidation routes, however after testing happens in QAS, layers are not used and the changes are moved using single routes towards PRD system.
Package – (formerly known as Development Class) is a way to classify the objects logically belonging to the same category or project. A package can also be seen as an object itself and is assigned with a specific transport layer (in consolidation route), therefore, changes made in any of the development object belonging to a particular Package, will be transmitted towards target system through a designated Transport Layer only, or else the change will be saved as a Local (non-transportable) modification.
In order to change a parameter, click the pencil icon and make desired changes
Important Parameters to limit login attempts
• login/fails_to_session_end: This parameter specifies the number of times that a user can enter an incorrect password before the system ends the logon attempt. The parameter is to be set to a value lower than the value of parameter
• login/fails_to_user_lock: This parameter specifies the number of times that a user can enter an incorrect password before the system locks the user against further logon attempts. Default value is 12. You can set it to any value between 1 and 99 inclusive.
How to configure Transport Routes and Layers
Consolidation routes – We need to establish a consolidation route for each transport layer. Development/ Integration system is taken as the source of these consolidation routes. Quality assurance/ Consolidation system as the transport target. Any modified objects that have a consolidation route for their transport layer can be included in change/transport requests. After the request has been released the objects can be imported into the consolidation system. If the changes are made to the objects with no consolidation route set-up (or in Customizing requests without a transport target) for their transport layer, such changes will be automatically taken as local change requests, i.e., not-transportable. Only one consolidation route per transport layer per system can be set-up.
Setting up Transport Routes
Once the Domain and other systems of a landscape are defined, we need to connect them with the help of proper transport routes (and layers). As for many customers' systems landscape fall into the same categories, the TMS provides some standard system groups that can be used for easily defining routes. When standard options are used, routes are generated automatically; we can select one of the following options:
• Single System
• Two-System landscape: DEV and PRD
• Three System landscape: DEV, QAS and PRD
If we need to define a more complex transport system, we can also use standard options initially and thereafter define additional consolidation and delivery routes.
Transport Routes – Standard Configuration
Transport Routes – Manual Configuration
Transport Routes
Distributing and Verifying the Configuration
• After the transport route settings are made or modified in domain controller, all other member systems of the domain ought to know the new configuration. For that we need to execute STMS -> Transport Routes Screen -> Systems Overview -> Configuration -> Distribution and Activate Configuration
• Additionally, we should also verify various check-points, to ensure that the whole arrangement is behaving in the desired manner:
o For RFC Connections: Overview -> Systems -> SAP System ->Check -> Connection Test
o For Network: Transport Routes Overview -> Config. -> Check -> Request Consistency
o For tp & TPPARAM: System Overview Screen -> SAP System -> Check -> Transport Tool
What is Transport Request? How to Import/Export it & check logs?
What is a Transport Request?
• Transport Requests (TRs) – are also known as Change Requests. It is a kind of 'Container / Collection' of changes that are made in the development system . It also records the information regarding the type of change, purpose of transport, request category and the target system.
• Each TR contains one or more change jobs, also known as change Tasks (minimum unit of transportable change) . Tasks are stored inside a TR, just like multiple files are stored in some folder. TR can be released only once all the tasks inside a TR are completed, released or deleted.
• Change Task is actually a list of objects that are modified by a particular user. Each task can be assigned to (and released by) only one user, however multiple users can be assigned to each Transport Request (as it can contain multiple tasks). Tasks are not transportable by themselves, but only as a part of TR.
Change requests are named in a standard format as: <SID>K<Number> [Not modifiable by system administrators]
• SID – System ID
• K – Is fixed keyword/alphabet
• Number – can be anything from a range starting with 900001
Example: DEVK900030
Tasks also use the same naming convention, with 'numbers' consecutive to the number used in TR containing them.
For Example, Tasks in the above mentioned TR Example can be named as: DEVK900031, DEVK900032 …
• The project manager or designated lead is responsible to create a TR and assign the project members to the TR by creating task/s for each project member.
• Hence, she/he is the owner with control of all the changes that are recorded in that TR and therefore, she/he can only release that TR.
• However, assigned project members can release their respective change tasks, once completed.
Workbench Request – contains repository objects and also 'cross-client' customizing objects. These requests are responsible for making changes in the ABAP workbench objects.
Customizing Request – contains objects that belong to 'client-specific' customizing. As per client settings these requests are automatically recorded as per when users perform customizing settings and a target system is automatically assigned as per the transport layer (if defined).
SE01 – Transport Organizer – Extended View
Create a Change Request
• Change Request can be created in two ways:
o Automatic – Whenever creating or modifying an object, or when performing customizing settings, system itself displays the 'Dialog box' for creating a change request or mention name of an already created request, if available.
o Manually – Create the change request from the Transport Organizer, and then enter required attributes and insert objects.
>
Release the Transport Request (Export Process)
• Position the cursor on the TR name or a Task name & choose the Release icon (Truck), a record of the TR is automatically added to the appropriate import queues of the systems defined in the TMS.
• Releasing and importing a request generates export & import logs.
The Import Process
Importing TRs into the target system
• After the request owner releases the Transport Requests from Source system, changes should appear in quality and production system; however this is not an automatic process.
• As soon as the export process completes (releasing of TRs), relevant files (Cofiles and Data files) are created in the common transport directory at OS level and the entry is made in the Import Buffer (OS View) / Import Queue (SAP App. View) of the QAS and PRD.
• Now to perform the import, we need to access the import queue and for that we need to execute transaction code STMS -> Import Button OR select Overview -> Imports
• It will show the list of systems in the current domain, description and number of requests available in Import Queue and the status.
Import Queue -> is the list of TRs available in the common directory and are ready to be imported in the target system, this is the SAP Application View, at the OS level it is also known as Import Buffer.
The Import status
Import Queue shows some standard 'status icons' in the last column, here are the icons with their meanings, as defined by SAP:
In case, a request is not added automatically in the import queue/buffer, even though the OS level files are present, then we can add such requests by the following method, however, we should know the name of intended TR:
Import History
We can also check the previous imports that happened in the system as follows:
Transport logs and return codes
• After the transport has been performed, system administrator must check whether it was performed properly or not, for that SAP has provided us with the following type of logs (SE01 -> GOTO -> Transport Logs) :
o Action Log – which displays actions that have taken place: exports, test import, import and so forth.
o Transport Logs – which keep a record of the transport log files.
• One of the important information provided by logs are the return codes:
o 0: The export was successful.
o 4: Warning was issued but all objects were transported successfully.
o 8: A warning was issued and at least one object could not be transported successfully.
o 12 or higher: A critical error had occurred, generally not caused by the objects in the request.
Why do we need a Transport System?
The CTS components play an important role in the overall development and customization environment.
CTS is an instrument for:
• Administering & controlling new development requests.
• Managing transports
• Recording of where and by whom changes are made
• Configuring systems landscape
Overview of CTS Components
• CTO (Change and Transport Organizer) – It's the main tool for managing, browsing, and registering the changes done on the repository and customizing objects. It's the central point for organizing the development projects. SE01 is the transaction with new extended view.
• (TMS) Transport Management System – Is used to move, manage, control, copy development objects and customizing settings in an orderly fashion across SAP systems in a landscape through pre-defined transport routes (RFC Connections). The transport process basically consists of exporting of objects out of the source SAP system and importing them into the target SAP system/s.
• Transport Tools – The actual transports happen in the back-end at the OS level using transport tools, which are part of SAP Kernel and includes the program R3trans and the transport control program tp.
The system landscape (also known as SAP System Group) is the arrangement of SAP servers. Ideally, in an SAP environment, a three-system landscape is recommended. It consists of the
1. Development Server – DEV
2. Quality Assurance Server - QAS
3. Production Server - PRD.
Transport cycle in a very basic sense, is the release of new Developments/ Customizing Changes from DEV which are imported in both Quality and Production systems. However, import in PRD can happen only once integration testing and quality check has been performed in QAS (and marked as checked).
What is Customizing? How does TMS help in Customizing
• Customizing is a process to adapt the SAP system according to the customer's need. To perform the customizing, users and consultants take help of SAP Reference Implementation Guide (IMG), which is accessible through transaction SPRO.
• Customizing is ideally done in DEV. The Transport Organizer (SE01) is used in conjunction with IMG to record and transport customized changes further.
Most of the Customizing changes (though, not all) are client-specific, i.e., the changes are supposed to be reflected in a particular client only and not intended for all the system clients. When the Transport Request is exported, it extracts the relevant table entries from the database of the SAP system and copies them to the transport directory. Relevant table entries are locked when the customizing transaction is being used. However, they are unlocked as soon as the changes are saved to a Transport Request.
Repository and Development Changes
• Apart from customizing already existing objects, new developments are also required in most of the cases. Development object is any object that is created (developed) by you in SAP system.
• Collection of all such objects (client-specific or cross-client) is called Repository.
• Development is mostly done with the help of ABAP Workbench (SE80), therefore such changes are also known as Workbench Changes.
• Examples:
o ABAP Dictionary Objects: Tables, Domains, Data elements, etc.
o ABAP Programs, function modules, menus, screens
o Documents, Application defined transport-objects, etc.
• Workbench is also fully integrated with TMS, to record and transport the changes.
Most of the Workbench changes (though, not all), are cross-client, i.e. changes will be reflected in all the system clients of the target system. Objects transported from the source system overwrite objects in the target system that has the same names.
Clients and the type of Data in SAP System
• Conceptually, client is a technical and organizational independent unit, that contains its own set of data (Master Data, Application/ Operational data, Customizing Data)
• Clients create separate environments for users from different user groups or with a different purpose, within same SAP system, without actually using different database.
• From Technical point of view, client is specified using 3-digit numeric ID, which also acts as the value for the table field 'MANDT', in case of client-specific jobs.
Among client specific data, there are 3 types of data:
• User Master Data contains the user login information, including the username, the password and the user defaults, the authorization profiles or roles, and the other useful information such as user groups, communication and so on. This data is physically present in a specific set of tables (the USR* tables).
• Customizing Data contains the configuration settings to customize organizational structure and the business processes for the companies implementing SAP. This data is client dependent and is stored in tables known as customizing tables.
• Application Data are also client dependent and normally users distinguish two types' master data and transactional data.
1. Master Data such as vendor master, material master (tables such as MARA)
2. Transactional data such as sales order, financial documents, Production Orders (POs) and so on.
Client Customization Options
Transport Directory and Its configuration
SAP Transport Directory:
• It is the global transport directory (/usr/sap/trans), which is actually a shared location (residing in the Domain Controller System) among all the member systems of a landscape (system group) .It also contains certain subdirectories, that are created automatically during the installation of the SAP system. This is mandatory for setting up the Transport Management System.
• Basically, Transport Directory is the location where all the changes are saved (in the form of files) after they are released from DEV. Therefore, it acts as a source for the changes to be eventually imported in DEV and PRD. Hence, we have to make sure that the transport directory is shared properly among all the systems in a landscape.
As an example, in Windows NT, the shared directory location can be accessed using the following address: \\<SAPTRANSHOST>\sapmnt\trans where SAPTRANSHOST (Domain Controller System's address) is defined in hosts file in Windows Directory of all SAP systems in the landscape. Domain Controller – is one of the systems in a landscape that act as an overall controller for change management and transport process in the landscape. Domain Controller is chosen (out of D / Q / P) by the team of system administrators, on the basis of system availability and the time of installation.
Main Subdirectories:
• Cofiles: Contains Change Request Information files with complete details and commands.
• Data Files: Contains the actual values and data to be used in implementing the change.
• Log: Contains Transport logs, traces or statistics, used for trouble-shooting, in case any error occurs in the transport process.
• EPS: Download directory for advanced corrections and support packages
Other Subdirectories are:
• bin: Configuration files for tp (Transport Program) and TMS
• olddata: Old Exported Data for archival or deletion
• actlog: Action logs for all requests and tasks
• buffer: Transport buffer for each system declaring the transports to be imported
• sapnames: Information regarding transport requests made by respective users
• tmp: Temporary and data log files
Setting up of Transport Directory and TPPARAM
• While configuring TMS, one of the main pre-requisite is to setting up the Transport Directory and the Transport Parameter file.
• It ensures that the Directory is shared properly among all the systems in a Landscape, for that all the systems taking part in the group/landscape are to be included in the global configuration file TPPARAM (transport parameter file), located under the bin subdirectory of /use/sap/trans. We have to make sure that the entries for all the participating systems are made in this file.
• In case, any entry is missing, copy another system's entry and change the values (for instance, System ID, Host name)
• At the time of installation, transport directory & the sub-directories are created automatically, including an initially configured template of TPPARAM file.
Operating System Tools - TP and R3trans
tp – The Transport Control Program:
• tp is the SAP program that administrators use for performing and planning transports between systems and also in upgrades of the SAP systems. This is used by the CTO and TMS.
• Actually, tp uses other special tools/programs and utilities to perform its functions. Mainly, it calls R3transutility program. However, it also offers a more extensive control of the transport process, ensuring the correct sequence of the exported/imported objects, to avoid severe inconsistencies in the system, which may arise due to wrong sequence.
• tp is located in the standard runtime directory of the SAP system: /usr/sap/SYS/<SID>/exe/run. It is automatically copied in the installation process.
• As a pre-requisite, the tp global parameter file (TPPARAM), must be maintained, specifying at least, hostnames of the systems taking part in the transport process.
• tp is mainly used for performing imports in target systems. It uses utilities called Import Dispatchers –RDDIMPDP & RDDIMPD_CLIENT_<nnn>, these are ought to be scheduled as background jobs in every system where imports will be performed. If for any reason they are deleted, we can schedule these jobs by running report RDDNEWPP.
• These jobs are actually "event triggered", meaning that tp sends a signal (an event) to the R/3 system and the job starts. These events are named as SAP_TRIGGER_RDDIMPDP andSAP_TRIGGER_RRDIMPDP_CLIENT.
R3trans – The Transport Control Program:
• R3trans is the SAP system transport program that can be used for transporting data between different SAP systems. It is normally not used directly, but called from the tp control program or by the SAP upgrade utilities.
• tp controls the transports and generates the r3trans control files, but does not connect to the database itself. All the "real work" is done from R3trans.
• It supports the transporting of data between systems running on different OS and even different DB.
How to configure TMS (Transport Management System)
TMS Configuration
• TMS is the transport tool that assists the CTO for central management of all transport functions. TMS is used for performing:
o Defining Transport Domain Controller.
o Configuring the SAP system Landscape
o Defining the Transport Routes among systems within the system Landscape
o Distributing the configuration
• Transport Domain Controller – one of the systems from the landscape that contains complete configuration information and controls the system landscape whose transports are being maintained jointly. For availability and security reasons, this system is normally the Productive system.
Within transport domain all systems must have a unique System Ids and only one of these systems is identified as the domain controller, the transport domain controller is the system where all TMS configuration settings are maintained. Any changes in to the configuration settings are distributed to all systems in the landscape. A transport group is one or more systems that share a common transport directory. Transport Domain – comprises all the systems and the transport routes in the landscape. Landscape, Group and Domain are the terms that are used synonymously by system administrators.
Step 1:Setting up the Domain Controller
• 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, system will prompt you to create one. When the Transport Domain is created for the first time, following activities happen in the background:
o Initiation of the Transport Domain / Landscape / Group
o Creating the user TMSADM
o Generating the RFC Destinations required for R/3 Configurations, TMSADM is used as the target login user.
o 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.
Step 2:Transaction STMS
Step 3: 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 purpose, 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.
Step 4:Configuring Transport Routes
• Transport Routes – are the different routes created by system administrators and are used to transmit changes between the systems in a system group/landscape. There are two types of transport routes:
o Consolidation (From DEV to QAS) – Transport Layers are used
o Delivery (From QAS to PRD) – Transport Layers not required
• Transport Layer – is used to group the changes of similar kinds, for example, changes are done in development objects of same class/category/package, logically should be sent through same transport route. Therefore transport layers are assigned to all objects coming from DEV system. Layers are used in Consolidation routes, however after testing happens in QAS, layers are not used and the changes are moved using single routes towards PRD system.
Package – (formerly known as Development Class) is a way to classify the objects logically belonging to the same category or project. A package can also be seen as an object itself and is assigned with a specific transport layer (in consolidation route), therefore, changes made in any of the development object belonging to a particular Package, will be transmitted towards target system through a designated Transport Layer only, or else the change will be saved as a Local (non-transportable) modification.
In order to change a parameter, click the pencil icon and make desired changes
Important Parameters to limit login attempts
• login/fails_to_session_end: This parameter specifies the number of times that a user can enter an incorrect password before the system ends the logon attempt. The parameter is to be set to a value lower than the value of parameter
• login/fails_to_user_lock: This parameter specifies the number of times that a user can enter an incorrect password before the system locks the user against further logon attempts. Default value is 12. You can set it to any value between 1 and 99 inclusive.
How to configure Transport Routes and Layers
Consolidation routes – We need to establish a consolidation route for each transport layer. Development/ Integration system is taken as the source of these consolidation routes. Quality assurance/ Consolidation system as the transport target. Any modified objects that have a consolidation route for their transport layer can be included in change/transport requests. After the request has been released the objects can be imported into the consolidation system. If the changes are made to the objects with no consolidation route set-up (or in Customizing requests without a transport target) for their transport layer, such changes will be automatically taken as local change requests, i.e., not-transportable. Only one consolidation route per transport layer per system can be set-up.
Setting up Transport Routes
Once the Domain and other systems of a landscape are defined, we need to connect them with the help of proper transport routes (and layers). As for many customers' systems landscape fall into the same categories, the TMS provides some standard system groups that can be used for easily defining routes. When standard options are used, routes are generated automatically; we can select one of the following options:
• Single System
• Two-System landscape: DEV and PRD
• Three System landscape: DEV, QAS and PRD
If we need to define a more complex transport system, we can also use standard options initially and thereafter define additional consolidation and delivery routes.
Transport Routes – Standard Configuration
Transport Routes – Manual Configuration
Transport Routes
Distributing and Verifying the Configuration
• After the transport route settings are made or modified in domain controller, all other member systems of the domain ought to know the new configuration. For that we need to execute STMS -> Transport Routes Screen -> Systems Overview -> Configuration -> Distribution and Activate Configuration
• Additionally, we should also verify various check-points, to ensure that the whole arrangement is behaving in the desired manner:
o For RFC Connections: Overview -> Systems -> SAP System ->Check -> Connection Test
o For Network: Transport Routes Overview -> Config. -> Check -> Request Consistency
o For tp & TPPARAM: System Overview Screen -> SAP System -> Check -> Transport Tool
What is Transport Request? How to Import/Export it & check logs?
What is a Transport Request?
• Transport Requests (TRs) – are also known as Change Requests. It is a kind of 'Container / Collection' of changes that are made in the development system . It also records the information regarding the type of change, purpose of transport, request category and the target system.
• Each TR contains one or more change jobs, also known as change Tasks (minimum unit of transportable change) . Tasks are stored inside a TR, just like multiple files are stored in some folder. TR can be released only once all the tasks inside a TR are completed, released or deleted.
• Change Task is actually a list of objects that are modified by a particular user. Each task can be assigned to (and released by) only one user, however multiple users can be assigned to each Transport Request (as it can contain multiple tasks). Tasks are not transportable by themselves, but only as a part of TR.
Change requests are named in a standard format as: <SID>K<Number> [Not modifiable by system administrators]
• SID – System ID
• K – Is fixed keyword/alphabet
• Number – can be anything from a range starting with 900001
Example: DEVK900030
Tasks also use the same naming convention, with 'numbers' consecutive to the number used in TR containing them.
For Example, Tasks in the above mentioned TR Example can be named as: DEVK900031, DEVK900032 …
• The project manager or designated lead is responsible to create a TR and assign the project members to the TR by creating task/s for each project member.
• Hence, she/he is the owner with control of all the changes that are recorded in that TR and therefore, she/he can only release that TR.
• However, assigned project members can release their respective change tasks, once completed.
Workbench Request – contains repository objects and also 'cross-client' customizing objects. These requests are responsible for making changes in the ABAP workbench objects.
Customizing Request – contains objects that belong to 'client-specific' customizing. As per client settings these requests are automatically recorded as per when users perform customizing settings and a target system is automatically assigned as per the transport layer (if defined).
SE01 – Transport Organizer – Extended View
Create a Change Request
• Change Request can be created in two ways:
o Automatic – Whenever creating or modifying an object, or when performing customizing settings, system itself displays the 'Dialog box' for creating a change request or mention name of an already created request, if available.
o Manually – Create the change request from the Transport Organizer, and then enter required attributes and insert objects.
>
Release the Transport Request (Export Process)
• Position the cursor on the TR name or a Task name & choose the Release icon (Truck), a record of the TR is automatically added to the appropriate import queues of the systems defined in the TMS.
• Releasing and importing a request generates export & import logs.
The Import Process
Importing TRs into the target system
• After the request owner releases the Transport Requests from Source system, changes should appear in quality and production system; however this is not an automatic process.
• As soon as the export process completes (releasing of TRs), relevant files (Cofiles and Data files) are created in the common transport directory at OS level and the entry is made in the Import Buffer (OS View) / Import Queue (SAP App. View) of the QAS and PRD.
• Now to perform the import, we need to access the import queue and for that we need to execute transaction code STMS -> Import Button OR select Overview -> Imports
• It will show the list of systems in the current domain, description and number of requests available in Import Queue and the status.
Import Queue -> is the list of TRs available in the common directory and are ready to be imported in the target system, this is the SAP Application View, at the OS level it is also known as Import Buffer.
The Import status
Import Queue shows some standard 'status icons' in the last column, here are the icons with their meanings, as defined by SAP:
In case, a request is not added automatically in the import queue/buffer, even though the OS level files are present, then we can add such requests by the following method, however, we should know the name of intended TR:
Import History
We can also check the previous imports that happened in the system as follows:
Transport logs and return codes
• After the transport has been performed, system administrator must check whether it was performed properly or not, for that SAP has provided us with the following type of logs (SE01 -> GOTO -> Transport Logs) :
o Action Log – which displays actions that have taken place: exports, test import, import and so forth.
o Transport Logs – which keep a record of the transport log files.
• One of the important information provided by logs are the return codes:
o 0: The export was successful.
o 4: Warning was issued but all objects were transported successfully.
o 8: A warning was issued and at least one object could not be transported successfully.
o 12 or higher: A critical error had occurred, generally not caused by the objects in the request.
No comments:
Post a Comment