CTS - Exercise Part1

The purpose of this document is to give a deep understanding and practical demonstration,

how transportation takes place between two systems. I completed this task as a part of my

assignment to satisfy required course work. You have three exercises in this document,

step by step instruction along with pictorial diagrams will make CTS (transportation system

in SAP) easy and more understandable for you.

The basic requirement to complete this exercise is that you should have access to two

learning system (not production system) configured for CTS. Here I used two systems one’s

name is SM7 and other is Ruby

Prepared and presented by
NASIR GONDAL

WHAT IS C.T.S.?

CTS is the central tool for managing changes to Customizing and Repository data that we
make in the IMG or ABAP Workbench. It records all changes in the change requests.
Documentation can be created for a change request, where one can define changes in more
detail. This document makes it easier to see which data was changed by which user and the
purpose behind it.

After finishing work in IMG or ABAP Workbench, we can release the change request. This
released change request can be used to copy the changes from this client to other
clients/systems. This automatic procedure is known as a transport. Transport of changes
by the CTS allows us to develop in one environment, test the development work in a test
environment, and then, if the tests are successful, use it productively. Transports of
changes between clients and systems are subject to rules defined in the CTS configuration
in the system landscape.

SYSTEM LANDSCAPE

They system landscape basically is the set-up or arrangement of your SAP servers. Ideally,
in an SAP environment, a three-system landscape exists. A three-system landscape
consists of the Development Server-DEV, Quality Assurance Server-QAS and the
Production Server-PROD. This kind of set-up is not primarily designed to serve as server
clusters in case of system failure, the objective to enhance “configuration pipeline
management”.

At this juncture, it is important to state that a test system - Sandbox can also exit
separately. The essence of the sandbox is to test the configuration of the business
processes of a company, especially at the inception of the project (before the Business Blue
Print is signed). It can also serve as a practice environment, even after go-live.

Change and Transport Management System (CTS) by Nasir Gondal. Page 1 of 54

Pipeline is the environment where the configuration in the development system is moved
to the quality assurance system and finally to the production system. The whole idea is to
ensure that the configuration of these systems is in sync at any point in time. Suffice to say
that, configuration/changes are first made in the Development system, thoroughly tested
in the Quality Assurance system before been loaded into the production (Live) system.

This approach throws up the transport management system concept. Transport
management system is the coordination of the movement of objects and configuration
changes from the development system to the Quality Assurance system and then to the
Production system. At times, this sequence of movement is not possible, especially in cases
where an SAP note mandates that changes be made directly on the production system.

Three Tier landscape

In this type of landscape each central clients has its own SAP System. This consists of a
development system DEV, a quality assurance system QAS, and a production system PRD.
The development system contains the Customizing client CUST, the quality assurance
system contains the quality assurance client QTST, and the production system contains the
production client PROD.

Make all changes to Customizing data and Repository objects in the Customizing client.
When you release the corresponding change requests, they are transported into the quality
assurance client. This means that changes to cross-client data only appear in the quality
assurance client after the transport. In the quality assurance client you can test whether the
transports are complete, or whether any linked changes are missing and are still in
unreleased change requests. If the test is successful, the change requests are transported
into the production client. The production client is completely separate from the other
clients as regards cross-client data.


If you need other clients with additional roles you can set them up in one of the three
systems. Set up the development test client (TEST) and the prototype client (SAND) in the
development system. Set up the training client (TRNG) in the quality assurance system.

Two Tier landscape

A two-system landscape is an alternative for smaller SAP implementations where little
Workbench development takes place. The two-system landscape does not include a
separate quality assurance system QAS. The quality assurance client is also in the
development system DEV.


As in the three-system landscape, the production client is completely separate from the
other clients. The disadvantage of a two-system landscape is that cross-client data is used
in both the Customizing and quality assurance clients. This means that any changes that
are made to cross-client data in the Customizing client can affect the tests in the quality
assurance client. You can also not guarantee that transports from the Customizing client
will be complete. Although all tests in the quality assurance client were successful, errors
could still occur after the transport into the production client. This problem is caused by
changes being made to cross-client data and then not being transported.

One-tier landscape

We do not recommend a one-system landscape containing all central clients in a single SAP
System. Joint usage of hardware resources and cross-client data places serious restrictions
on how a single system operates. In particular, once the system is used productively, you
can no longer develop in it, unless you stop productive operation for the development and
test phases.


TRANSPORT MANAGEMENT SYSTEM

The Transport Management System (TMS) supports administrators in organizing,
performing and monitoring imports. The TMS also helps you to set up your system
landscape, particularly the configuration of the transport routes.

All SAP Systems that are subject to the administration of the TMS form a transport
domain. This is usually all SAP Systems in the system landscape. Certain system settings
are the same for all systems within a transport domain, such as the transport routes. To
achieve this, one SAP System in the transport domain has the reference configuration, with
all other SAP Systems in the transport domain taking copies of this reference configuration.
The system with the reference configuration is known as the Transport Domain Controller;
only in this system can you make changes to the reference configuration. Each time you
change the reference configuration, you must distribute the new configuration to all
systems. The TMS automatically generates RFC connections between the systems in a
domain so that they can communicate.

Transport Organizer

The Transport Organizer provides functions for creating, documenting and releasing
change requests during the Customizing and development process. The Transport
Organizer is designed specifically for use by the development team and the project
managers of a development or implementation project.

Transport Layers & Routes

Any projects developed using the same SAP system need to be transported via the same
routes and these are grouped together to form a transport layer. Objects delivered by SAP
belong to the transport layer “SAP”. This is a standard layer. Other transport layers are
generally only needed when new development systems are included in the system group.
Once the transport layer is set up the transport routes can be set up. There are two types of
transport routes consolidation and delivery routes. The former is used to transport any
modified objects included in transportable change requests. After the request has been
released the objects can be imported into the consolidation system. The delivery routes


transport all change requests that are imported into the route’s source system and flag
them for import into the route’s target system.

Transport with Import Queue

Import queues can be used as a transition between development and administration. All
changes released by developers can be seen immediately by the administrator in the
queues. The TMS provides easy-to-use functions for displaying and editing the import
queues. Import queues are a particularly good way of automating transports in your system
landscape. They can significantly reduce the amount of work for system administrators
responsible for a large number or transports; automation reduces the administrator tasks
mainly to monitoring and troubleshooting. There are two ways of releasing requests; Mass
and single transports


PRACTICAL - LAB WORK


LOGIN DETAILS & SYSTEM INFORMATION

SOURCE SYSTEM:

NAME: SM7

Client: 01

LOGIN: XXX

PASSWORD: XXX

TARGET SYSTEM

NAME: Ruby

Client: 800

LOGIN: XXX

PASSWORD: XXX


What you will do in this tutorial:

You will create and configure a default printer for your office. After making necessary
changes, you will transport to target system. On successful import in target system you test
it and conform.

CREATE PRINTER (Part-1)

Step 1

Login: SM7

User ID: XXX

Password: XXX

Step 2

 Use Transaction code “SPAD”

 Spool Adminstration: Initial Screen appears (Ref: Fig1A)

 Select Display

 The screen will look like (Fig: 1B). Click on EDIT icon to enable change mode


 Select CREATE icon to create a new output device.(Ref: Fig1C)

Step 3

 Enter (Ref: Fig 1D)
o Output Device as “ZXX_PRINTER”
o Short Name as “ZXX”
o Select Device Type from drop down list as “HP5000: HP LaserJet 5000 R4.x”
o Select Device Class from drop down list as “Standard Printer”


 Go to tab (Ref: Fig 1E)
 Select Host Spool Access Method from drop down list as “G: Front End Printing
with Control Tech”
 Enter Host Printer as “__default”

 SAVE

 Note: On successful save message will appear as


Step 4

TRANSPORT REQUEST (PART-2):

 Click on icon once, and it will take back you to the “Spool Administration: List
of Output Devices”.
 Your device (ZXX_PRINTER) being displayed on the screen (Ref:Fig1F)

 Note: If it doesn’t appearing click on to refresh the screen to see your device.

Step 5

 Click on your device (ZXX_PRINTER)

 Press TRUCK as shown in fig:1G


 An information dialog will appear click OK (Ref:Fig1H)

Step 6

 Prompt for Workbench request screen appears (Ref: Fig 1i)

 Select to create new request

 Create Request Screen Appears (Ref: Fig1j)
 Enter
o Short Description as “ZXX Transport Request”
o Note: Do not enter/change any data; Leave it as it is

o SAVE


 Note down system generated request number(Ref: Fig1K) for future references

 Press OK

 Note: Message appears as

 Go to Main menu using back arrow or

**** End of Part-1 ****


EXPORT (PART-2)

Step 7

Login: SM7

User ID: XXX

Password: XXX

Step 8

 Use transaction code “SE10”

 Transport organizer Screen appears
 Enter (Ref: Fig 1L)
o user as “CO-XX”
o Select “Customizing Requests”
o Select “Workbench Requests”
o Select “Modifiable”
o Select Display


 Note: Available requests will get displayed in hierarchical structure (Ref: Fig1M)

 We can release a request or can check the status. Refer request ref. number:
SM7K901230. This request has a child node SM7K901231. Child node is system
generated

Step 9

 Select child node and press Truck icon (Ref: Fig1M)
 The message displays at left bottom with your request reference. Expand your
request node by clicking on it

 Repeat this step for original request (SM7K901230). Result will display as shown
in Fig: 1N
 Note: Use refresh button to get your screen to show Fig: 1N


Take snap short of this screen (Ref: Fig: 1N) and send to ANDREW

**** End of Part-2 ****


IMPORT (PART-3)

Step 10

Logon to Target System: Ruby SM7 (S40)

Client: 800

User ID: XXX

Password: XXX

Step 11

 Use transaction “STMS”

 Note: Transport Management System screen appears (Ref: Fig1O)

 Select IMPORT OVERVIEW
 Import overview screen appears showing Number of Import queues (Ref: Fig1P)


Step 12

 Check queue of Rbuy-S40. Double click on S40 (Ref: Fig1Q)
 Status of request SM7K901230 is displayed along with all other incoming request
o Note: Filter can be applied based on user

 Note the status of your request

 If request has a symbol in column Number, click the icon on menu bar (Ref:
Fig1Q)
 Acknowledge message (if any)

Result: You are ready to import your request


Step 13

 Select you request and press
 NOTE:

is used for single request import and is used for whole queue import.

 Import Transport Request Screen appears (Ref: Fig1R)

Step 14

 Enter (Ref: Fig 1S)
o Target Client: 800
o Go to Date tab, Select Immediate
o Go to Execution Tab, Select radio button “Synchronous”

o Press


 Acknowledge next message, Press “Yes”
 Note Change in Status (Ref: Fig 1T)

Take snap short of this screen (Ref: Fig: 1T) and send to ANDREW

**** End of Part-3 ****


TESTING (Part-4)

Step 15

Logon to Target System: Ruby SM7 (S40)

Client: 800

User ID: XXX

Password: XXX

Step 16

 Use transaction code “SPAD”
 Spool Adminstration: Initial Screen will appear
 Enter (Ref: Fig 1U)

o Click on Display

o List of available devices will get displayed (Ref: Fig1V)
o Search your device (ZXX_PRINTER)
o If found, device is successfully imported into target system


*** End of Part-4 ***

****** End of Tutorial ******


CTS - Exercise Part1

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Viewers also liked

Viewers also liked (9)

Similar to CTS - Exercise Part1

Similar to CTS - Exercise Part1 (20)

Recently uploaded

Recently uploaded (20)

CTS - Exercise Part1