The Development of Transport Request Sys

The Development of Transport Request System
in SAP using ABAP Language
by
Ahmad Fikri Amer Hamzah
Dissertation submitted in a partial fulfillment of

the requirement for the
Bachelor of Technology (Hons)
(Business Information Systems)
July 2005 I Jan 2006
Universiti Teknologi PETRONAS

Bandar Seri Iskandar
31750 Tronoh
Perak Darul Ridzuan
'C
~
ss-'\( .-~
,{l.._)-
\) ~ ... "......, -- Le~"'\<./ ~, .. ~-,
~-vtb
'1-J 0\\o.w-Y I'o<..>N'-V' t.e~-"\
TABLE OF CONTENTS
CERTIFICATION OF APPROVAL ................................................ ..

CERTIFICATION OF ORIGINALITY.............................................. n
LIST OF ILLUSTRATIONS............................................................ m
LIST OF ABBREVIATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 1v
LIST OF APPENDICES .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ... v

ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .... VI
CHAPTER! INTRODUCTION ......................................... .

1.1 Background of the study .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. I
1.2 Problem Statement .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ... 2
1.3 Objectives and Scope of the Study .. .. .. .. .. .. .. .. .. ... 3
CHAPTER2 LITERATURE REVIEW................................. 6
CHAPTER3 METHODOLOGY/PROJECT WORK................ 9
3.1 Waterfall Model of Development Cycle.............. 9
3.2 Procedure Identification .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. . I0
3.3 Tools .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ... II
CHAPTER4 RESULT AND DISCUSSION............................ 14
4.1 System Development Phase Based on Waterfall 14
Model ........................................................ ..
4.2 Transport Request Rejection Process .. .. .. .. .. .. .. .... 17
4.3 Process Flow from AS-IS to TO-BE...................... 19
4.4 Use Case Diagram for Transport Request . . . . . . . . . . . . 22
4.5 Data Flow Diagram for Transport Request .. .. .. .. ... 23
4.6 Transport Request Configuration for Mini SAP .. ... 26
4.7 Database Configuration .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. . 27
4.8 The System Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.9 Technical System Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.10 Time Benefit Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 36
CHAPTERS CONCLUSION AND RECOMMENDATION....... 38
5.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2 Recommendation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... 39
REFERENCES 40
APPENDICES 42
CERTIFICATION OF APPROVAL
The Development of Transport Request System

in SAP using ABAP Language
by
Ahmad Fikri Amer Hamzah
A project dissertation submitted to the

Business Information Systems Programme
Universiti Teknologi PETRONAS
in partial fulfilment of the requirement for the
BACHELOR OF ENGINEERING (Hons)
(CHEMICAL ENGINEERING)
.l!JJJ
Approved by,
........ .l ..................................... .
MR KHAIRUL SHAFEE KALID
Project Supervisor
UNIVERSITI TEKNOLOGI PETRONAS

TRONOH, PERAK
July 2005 I Jan 2006
CERTIFICATE OF ORIGINALITY
This is certify that I am responsible for the work submitted in this project, that the
original work in my own expect as specified in the references and acknowledgements,
and that the original work contained herein have not been undertaken or done by
unspecified sources or persons.
~-Si
AHMAD FIKRI AMER HAMZAH
ii
LIST OF ILLUSTRATIONS
Figure 3.1 Waterfall Model for the System Development............................... 10

Figure 4.1 SAP System Architecture at the Customer site . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . 15
Figure 4.2 Transformation between AS-IS Process Flow to TO-BE Process Flow.. 20
Figure 4.3 Transport Change Workflow Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . 22
Figure 4.4 Data Flow Diagram for Transport Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... 24
Figure 4.5 Configuration ofMBS (DEV and QAS system) and RPR (PRD system) 27
Figure 4.6 Entity Relationship Diagram for Developed System . . . . . . . . . . . . . . . . . . . . . ... 29
Figure 4. 7 Screen Create Request that include all details regarding the transport ... 30
Figure 4.8 Pending list of transport request for approval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Figure 4.9 Screen shot on the list of pending transport request to QAS and PRD . . . 32
Figure 4.10 Transport maintenance screen for quality assurance server . . . . . . . . . . . . ... 33
Figure 4.11 Transport analysis screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . .. . 34
Figure 4.12 Screen Flow of Transaction ZTRS in SAP.................................. 35
Table 4.1 Description on Actor Task in Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 22
Table 4.2 Details description on the data flow diagram processes . . . . . . . . . . . . . . . . . . . . . 25
Table 4.3 Time execution comparison between AS-IS process and TO-BE process 36
iii
LIST OF ABBREVIATIONS
DEY - Development System

QAS - Quality Assurance System
PRD - Production System
SAP - Software Application Programming
ABAP - Advanced Business Application Programming
TMS - Transport Management System
MBS - Act as DEY and QAS for the project implementation
RPR - Act as PRD for the project implementation
IV
LIST OF APPENDICES
Appendix A: Transport Request Hardcopy Form 43

Appendix B: Database Table 45
Appendix B.!: Table ZTRSDET Fields Details 46
Appendix B.2: Table ZTRSREQ Fields Details 48
Appendix B.3: Table ZTRSREJ Fields Details 49
Appendix C: User Manual 50
Appendix D: Developer Manual (Technical Specification) 65
Appendix E: Report on Final Presentation 77
v
ABSTRACT
A transport request is a process of transferring SAP system components from one system
to another and the components to be transported are specified in the object list of a
transport request. Current transport request process is using hardcopy form that is
printed with the details about the requester, the change request and change request id.
The usage of the form rise problems that include the problem on storage and filing the
forms, standardizing the form structure, and the process is not easy to monitor and
analyze. The purpose of the study is to develop a system in SAP that can cater for
change request transportation to different client server where the system is fully
integrated with all SAP functionality and can overcome all problems that rise from the
used of hardcopy form. Manual paper-based process is transformed into automate-based
process that is integrated within SAP. The boundary for the study is within transport
architecture in SAP and the transport architecture focus on two system environment with
several clients. ABAP programming is used as the programming language to develop the
entire graphical user interface including screen, and analysis. The implementation of the
project involves identification of the business process flow analysis on the SAP transport
architecture, designing and creating database tables and graphical user interface,
developing program code for screens and analysis, and running program testing that
includes subsystem, integration and system testing. The system is be able to cater for all
user requirements in term of requesting a transport request, communication between
requester and approver, perform transport process, and generates analysis for the
management.
VI
CHAPTER I
INTRODUCTION
1.1 BACKGROUND OF THE STUDY
The transport workflow provides a framework for transporting enhancements or

new developments of existing business functions through a system landscape. System
landscape consists of elements like servers, databases, systems, and systems components.
These elements recite in three basic generic environments that are DEV system, QAS
system, and PRD system. Changes to the standard SAP "off the shelf' product are made
in the DEV system or also known as Customizing and Development system. Basic testing
in relation to the system architecture may also being done in this system where small
quantity of realistic data is stored (Dimension Consulting. com, 2005).
Rigorous testing of changes occurs in the QAS system known as Quality
Assurance system, where contains large amount of realistic data that may be a copy from
PRD system in order to facilitate realistic testing (DimensionConsulting.com, 2005).
PRD or Production system is the "live" version of the system where contains all business
transaction data (DimensionConsulting.com, 2005). Normal users only interact with PRD
system to perform day-to-day operation and changes should be moved into this system
only after they have been thoroughly tested. Therefore, the transport workflow will
transport enhancement or changes between DEV system, QAS system and PRD system
from developer to user supported with enhancement testing. A transport management
system that is currently not in SAP is needed to cater for transport request by the
developer to transport administration.
1
1.2. PROBLEM STATEMENT
1.2.1 Problem identification
When a user requests for change transport to QAS or PRD, a paper-based

transport request form is filled before it is approved for transport. The form contains
details on requester, change request id, details on approval and transport process result
(see Appendix A). As workload increase, number of forms that needed to be stored also
increase, and question regarding form storage rise. The form storage required specific
filing system and it is hard to maintain.
Throughout the end of the business period, top management is having difficulty in
performing analysis on the transport request, for example forms that are process for a
specific month in a year are hard to locate and it is time consuming.
The management is also having difficulty to the issue of standardizing the form
elements such as font size and short forms. This will lead to the auditing problem which
will be performed by the external auditor. They will question about the not standardized
forms and the reasons it should ever happen.
1.2.2 Significant of the Project
The system is implemented to tackle the problems faced using the hard copy
form. Besides, it can also provide extra functionally like email for notification purpose
that can help in increasing the efficiency of the business process.
Details regarding change request id that stores the changes on SAP system, is
located within the SAP itself and it could not be accessed from outside SAP. By applying
the developed system, SAP Team will found no difficulty in retrieving data as all
required details are integrated within the SAP.
All fields that are entered by the user will be stored in a normalized database
server. This can overcome the problem of form filing. Data will be stored in server and it
2
will not require additional storage since SAP is using server to store its own database.
Plus, storage for this transport request form will not consume a lot of hard disk space
because on average, transport is requested only twice a day compared to other business
operation that may involves up to hundreds and thousands of transaction per day.
The system can limit user action in the sense that it provides drop down menu or
check box selection for certain input that can help to standardize data entered by user.
SAPscript is use for printing purpose able to provide a good standards output.
1.3. OBJECTIVES AND SCOPE OF THE STUDY
1.3.1 Objectives of the project
This project caters and overcome the weakness of hard copy forms that is
currently used by the organization and transforms the existing business process into
automated-based system. It is targeted to simplify the tasks of the SAP consultants when
requesting a transport. The objectives of the project are:
I. To analyze transport process in customer site that uses 2 different servers for
development and production. The development server contains two client servers
while production server contains single client server.
2. To develop a system in SAP to cater for change request transportation to different
client server that can ease user to create transport request.
The system will have integration with the SAP system in order to ensure for
smooth transport process flow.
3. To design an additional database tables that will be used to store information and
details on a transport request.
The database table will be normalized and field will be linked to existing SAP
database fields to ensure for efficiency of data storage.
4. To design screens and its fields that will be used to perform task in the transport
process such as create request, approval, and rejection.
3
1.3.2 Scope of the project
The study for the project includes specific boundary and limitations so that the
study does not tum into wrong direction. Several outlines have been address to cater for
the boundary of the study:
I. Analysis caters in the boundary of transport in SAP.
2. Transport process is between two different SAP systems with several client
environments.
3. The transport can process for all change request id to any client in the system
environment.
4. The system used ABAP language as the programming language.
1.3.3 Relevancy of the project
Change request transport is one of the important tools that SAP provided for their
client to transfer their changes such as business reporting analysis to other client or
system. Developer experience handling transport request shows that it is best to get
connected with SAP system during the transport request. Since all data are located in the
SAP system itself, it would be easier to extract those data like change request id from its
database table before requesting for transport.
Auditing process for software development by third party will check for the
standardize business process used by user. Using the system, input can be clearly
standardized using certain functionality in SAP and ABAP programming.
1.3.4 Feasibility of the project
The project implementation calculated to complete in 24 weeks approximately in

two semester of study. Considering all time consuming that need to be divided to other
4
subjects, 24 weeks is an adequate period to come out with a complete working final
product.
During the first half of the project implementation, research and analysis is done
mainly to cater for understanding the business process as well as identifying any related
information that necessary in developing this project. One of the related analyses that
have been made is about the transport protocol in SAP and understanding methods on
how the data traveled within every client and server.
Resources such as hardware and software that are needed to implement the project
are available at the faculty facilities. Computer that is used to run SAP system can easily
be found at the lab facilities provided by the university. Any related tools are well
integrated in SAP system itself such as SE80 transaction that is used to implement the
system design.
Since transport process related to Basis module m SAP, therefore Mini SAP
system will be fully used during the project implementation because Mini SAP system
provide best interface in configuring Basis module. Mini SAP system can be installed in
standalone computer and the installation required free license only. By installing the
system to the standalone computer, it can help the student to testing and amendment on
the system architecture thoroughly. The limitation of access and security on the UTP
testing SAP system can be overcome with the Mini SAP system.
5
CHAPTER2
LITERATURE REVIEW AND/OR THEORY
Client/server configurations in SAP R/3 can be divided into 3 different tiers.

There are one-tier configuration, two-tier configuration, and three-tier configuration. The
fundamental services in a business application programming system are presentation
services, application services, and database services (Basis System Kernal, 2004).
In one tier-configuration, all processing tasks are performed on one server, as in
classic mainframe processing. The two tier configuration usually implemented using
special presentation servers that are responsible solely for formatting the graphical user
interface. This type of configuration is particularly useful for processing-intensive
applications such as simulation, but due to the additional administrative requirements is
usually used for the test purposes only. In the three-tier configuration, separate servers
are used for each tier. Using data for the database server, several different application
servers can operate at the same time. This can released the load from on the individual
servers to achieve optimal performance.
A transport request process is the transfer of SAP System components from one
system to another and the components to be transported are specified in the object list of
a transport request (help.sap.com, 2005). The SAP System maintains a transport log of all
actions during export and import. Each transport consists of an export process and an
import process. The export process reads objects from the source system and stores them
in a data file at operating system level while the import process reads objects from the
data file and writes them to the database ofth~ target system.
The transport request is used when tqe new changes needed to be copied to the
other system architecture. All changes that are done in SAP whether it is a reporting
creation or amendment, or maintaining SAB system landscape, a change request id is
created and the changes recite in it. The transport request will used that change request id
to transport the changes to other system architecture using transport module provided by
SAP.
6
In order to create a good IT infrastructure, it is requires that some awareness of
the business functionality being addressed. The server, storage, and network
infrastructure solutions focused on SAP business application software where the choice
and configuration of these software components plays an important role for the hardware
configurations and ongoing IT operations needed (HP.com, 2005).
Although SAP software is generally independent of any one particular relational
database management system (RDBMS), there are some important software architecture
concepts that apply to each database (HP.com, 2005). Just like SAP software, each
RDBMS has a kernel, or a set of executables that enable the database application to run.
These kernel files are compiled specifically for each server OS platform. The actual data
stored in the database is logically stored as rows within relational tables. Physically,
however, the data is stored in data files on disks, configured with a file system or as raw
disks.
STMS is the transaction in SAP that is used to perform transport to specific target
client server (Ramachandran, 2005). It collect all released change requests that are ready
for transport and check for the consistency by passing the return value of the transport.
Configuration of transaction STMS can be done through SAP Mini system to get
real environment of the transport system (Giovanni, 2005). Parameters need to be set by
the user that has Administrator privilege.
Command prompt can be used to check for the setup server whether it is alive or
not (Ramachandran, 2005). This way, transport administration does not have to log on to
the server to monitor the system. If some cases that SAP could not be access, command
prompt can give good interface for interaction between the user and server.
When organizations decide how they want to manage the creation and progression
of changes in their SAP systems, they typically create procedures and manual processes
that incorporate a reasonable degree of flexibility. Such procedures and processes usually
recognize that different types of change should have their own rules concerning testing,
approval and migration. For example, the approval and migration requirements for a
minor bug fix are normally different from the requirements for a major development.
Manual procedures may also contain quite flexible provisions about who is eligible to
approve a change in the absence of a normal signatory. By contrast, the same procedures
7
tend to embody a highly idealized view as to how these changes are typically progressed
(Wilkin, 2005).
One of the main purposes of the rules and procedures is to prevent damage to an
organization's production system. Such damage may cause considerable disruption,
resulting in loss of business and incurring considerable repair costs (Wilkin, 2005). The
damage may occur when the changes that are introduced have not been properly tested or
approved or transports are imported in an incorrect sequence.
Transport Management System (TMS) in SAP need to be configured thoroughly
in order to be able to create transportable requests; otherwise no transport will be able to
other systems. Transport routes will allow the system to dram a transport path between
systems. A system without a transport route cannot export transport request (Huseyin,
2002). The transport routes are used to define in which target system you want to
consolidate change requests, and which SAP Systems are forwarded this information
automatically (SAP Library, 2006).
TMS can be configured in three types of setting that are virtual system, external
system and domain link.
8
CHAPTER3
METHODOLOGY/PROJECT WORK
3.1. WATERFALL MODEL OF DEVELOPMENT CYCLE
Implementation of the project is based on the waterfall model in system

development life cycle. During the first half of the semester, the first four phase of the
waterfall model need to be completed:
I. Document the system concept
2. Identify system requirement and analyze them
3. Break the system into pieces (Architecture Design)
4. Design each pieces (detailed design)
• please refer to Chapter 4 Result and Discussion for thorough explanation

on every phase of implementation
During the second half of the semester, process of creating the database, graphical
user interface, testing and implementation of the system is done. The phase includes the
fifth up to seventh phase of the waterfall model:
5. Code the system components and test them individually
6. Integrate the pieces and test the system
7. Deploy the system.
9
Document system
concepts
Identify system
requirement and
analyze them
Break the system into

pieces (Architecture
Design)
Design each pieces

(detailed design)
Code the system

components and test
them individually
Integrate the pieces

and test the system
IImplement wnh real data
Figure 3.1 Waterfall Model for the System Development
Under the waterfall model, development for every step can be made flexible
whereby if the requirement is not complete, the phase of development can return to the
previous state (pint.com, 2005). Nevertheless, developer needs to ensure that each step of
constructing the system is completed.
3.2. PROCEDURE IDENTIFICATION
Implementation of this project consists of 7 major tasks that spread from setting
up client server environment using SAP configuration up to system testing.
10
The tasks that have been allocated for first half of the project implementation
include:
I. Setting up system with target client environment.
Mini SAP is used to create two servers for the purpose transport. These systems
will be linked on domain using transaction STMS. The transport route is
configured to allow for transport.
2. Analysis on business process flow.
The business flow include process of the requester request for the transport,
approval is done for every transport, communication between approver and
requester, transportation to each change request id to target server, and user
acceptance toward the changes.
3. Identify related transaction in executing transport process.
Transport Administrator uses standard transactions to perform transport and client
copy between DEY, QAS and PRD system such as STMS.
The tasks that have been allocated for second half of the project implementation
include:
4. Identify standard database table and fields involved.
In order to integrate the system with the standard fields in SAP, SAP standard
fields from transport transaction need to be linked to the developed system.
5. Modeling new database table.
6. Develop system graphical user interface: screens, elements of the screen,
transaction code of the system, and function help.
7. Testing: Server testing, subsystem testing, integration testing, system testing
3.3. TOOLS
The project development involved within Mini SAP system that is installed in a
standalone computer. Mini SAP system is chosen to be the platform of implementing the
system because student does not have the authorization toward the testing SAP system
II
provided by UTP. Nevertheless, Mini SAP system can provide a wide range of
functionality that student needs in order to cater for the project. Thus, implementing in
the Mini SAP system can also provide same environment in SAP especially for Basis
Module. Basis Module is a wide range of functionality that any SAP system should have
and it can provide sufficient support toward the project.
All tools needed during execution of project are located within the SAP system
itself (Ramachandran, 2005). Therefore no additional tool like hardware and software is
needed. All SAP technical transactions that required are:
• SE80- Object Navigator

It is a tool for central processing of Repository objects. In the Object Navigator,
all objects belonging to a particular category are displayed in the navigation area
as a tree structure and can be processed by forwards navigation.
• SEll - ABAP Dictionary
The ABAP Dictionary describes the logical structure of application development
objects such as tables, views and data types, as well as their representation in the
structures of the underlying relational database. The ABAP Dictionary is an active
data dictionary and is fully integrated in the ABAP Workbench.
• SE37- ABAP Function Modules
It is a module to maintain Function Modules that can be used as a tool for testing
for standard Function Module. Mainly for this project, SE37 is used to test any
relevant function module on its functionality usage.
• SE71- SAPscript Form
It is a module to maintain SAP script form in SAP. The transaction can be used to
create, copy, display, change, or delete a SAPscript.
• STMS - Transport Management System
It is a set of all tools in the SAP System for organizing, performing and
monitoring transports between SAP Systems. The Transport Management System
is part of the Change and Transport System.
• SCC 1 - Client copy transport
12
It is a function for copying a client. This applies in particular to copying the entire
customizing context (environment) of a source client to a target client, either
within one SAP system or to a different SAP system. The system settings
determine what is to be copied.
13
CHAPTER4
RESULT AND DISCUSSION
4.1. SYSTEM DEVELOPMENT PHASE BASED ON WATERFALL

MODEL
4.1.1. Identify System Requirement
• Approval will be made upon any transport to every client for the targeted system;
each transport into any target system need to be approve by QAS controller, team
leader and/or project manager. The purpose of this action is to monitor any
changes that the SAP team (requester) has done and whether that the changes
follows all guideline in meeting the user needs.
• Requestor can send notification to approver noticing about new change request;
upon any changes to the system, a means of communication need to be created to
inform the approver that there are new changes that needs for approval and
transport.
• Approver and requestor can communicate freely upon any issue during any
transport phase; approver need to communicate with the requester to ask about the
transport details and to inform the requester about the approved or rejected the
request.
• The same transport id can be transported again under correction status; if any
error should happen during the transport request, the same transport id can be
transport again and the system should be able to cater for the requirement
• Can be used for both client copy and transport management; for transport within
the same server to different client, a client copy is perform by the Transport Team
and if the transport is between a different system, a transport management is done.
14
• User should have advantage to navigate to standard SAP transaction by using the
system
o releasing the change request
o transporting directly
o automatically detecting return code and response to each return code
uniquely
4.1.2. Break the system in subsystem (Architedure Design)
Change request management architecture consists of at least 2 servers with

several clients. A simple architecture will contains 2 servers, one for development
(K460), and one for production (N4000). A simple development server may consist of at
least 2 different clients for multi checking (038 and 088).
,1------'lll'+---1 ~-i
SAP F10nt End SA.P Frm rt E·rd
Figure 4.1 SAP System Architecture at the Customer site
15
• Server
o Development server: K460
o Production server: N4000
o need for two or more servers environment to enable for change request
transport architecture
• Client
o K460 038 DEY
o K460 088 QAS
o N4000 088 PRD
o need for two or more clients in one server architecture to enable for client
copy architecture
• Database Object
o tables
o data elements
o domains
o foreign key linkage
• Screens
o screen elements
o screen integration
• Testing
o server testing - server working, and can perform transport task
o subsystem testing- test each individual subsystem by its own, by ensuring
it to work without error
o integration testing - integrate each subsystem between one another and
check for integration logic. Two primary integration:
'
• between newly created subsystem

• between stand~ system/transaction in SAP
o system testing - test, system as a whole after all subsystem have been
integrated
16
4.1.3. Design each subsystem (Detailed Design)
• Server with client

SIMS in SAP mini; client and server environment is created to mimic the
architecture of the targeted customer. This is to ensure that the system can be
adapted to the targeted customer SAP environment without any complexity. But
the system will be ensured to follow standard SAP architecture to minimize
complexity upon any client and server upgrade for example creating new server
and adding new client.
• Database object
Database created using Data Dictionary to add new field to fit to client
requirement. Fields will be linked to standard SAP database fields when
necessary, to ensure that all database tables are integrated with the standard table.
• Screens
Development of screen includes the creation of screen elements usmg screen
painter. Apply the standard structure in SAP to get the linkage between screen and
database table. Ensure all linkage and screen creation to follow standard screen
architecture, to allow for future enhancement of the SAP system will have no
defect.
4.2. TRANSPORT REQUEST REJECTION PROCESS
Upon approval process, not all transport will be approved to be transported and
the required person may reject the transport request. Upper level management who have
better experience in term of managing the system integrity and performance have better
judgment regarding the matter compare to the developer who request the transport.
Among others, the reasons for rejection are as follows:
17
• The task not complete:
Usually this happen at team leader approval level whereby the team leader do not
approved the transport since not all tasks are completely configured by other team
members.
• Redundancy of object:
From time to time, developer may not realize that they are creating the same
changes regarding the same object, and the approver who realize the situation will
reject the changes so that the integrity of data can be maintain in the production.
• Authorization purposes:
If the changes can grant access or limit authorization to non appropriate user, the
project manager will reject the request and the developer needs to apply other
approach to meet the user requirement.
Approval is important in transport request process because it can help the

manager to monitor each change that submitted the SAP team. Manager can have better
view on the task that the users required developer to create and whether the developer
creating the right objects in the system. The reasons to monitor the system are listed as
follows:
• Prevent damage to production system.

Since the production system contains data that the organization uses to run its
daily operation, any damage to the system cannot be entertained because it can
cause considerable disruption, resulting in loss of business and incurring
considerable repair costs (Wilkin, 2005).
• Ensure the production system is clean from rubbish.
Rubbish such as incomplete reporting, damage SAPscript form, and unused
objects can congest the system and drop the production performance.
• Maintain integrity of production system:
Ensure that the system is not burden with unnecessary processing that may cause
damage the system.
18
4.3. PROCESS FLOW FROM AS-IS TO TO-BE
The AS-IS process for the transport request is shown in Figure 4.2(A). It shows
the process flow of the current transport request applied by the SAP Team. It starts with a
change request submitted by requester to the support team and the request need to get
team leader and QAS controller approval before it can be transported to QAS. Then user
will be required to test the changes before it can be approved by the project manager for
PRD transport. Along the way of the transport process, requester will have to be there
physically especially during the approval by team leader, QAS controller, and project
manager. Then user will have to test the changes again in PRD so ensure the changes
really meet their expectation.
There can also be rejection on any approval process and in the case that it happen,
the process will jump to previous steps and requester need to reconfigure the changes that
are about to be transported. There are several cases where the changes cannot be
transported to PRD, for example, if the changes required amendment of the PRO
configuration, sometimes project manager will not approved the request if the
configuration is not needed in PRD. In this case, the requester has to look for alternative
to counter the user problems. There are also cases where user is not satisfy with the
solution and the requester needs to redo the solution before it is transported again to
required system.
On all processes in AS-IS process flow, the requester need to be there to facilitate
the transport flow. The approver need to bring the transport form to the appropriate
person to ask for approval and it consume time as the person might not be available there
and the requester need to explain about the request three times to three different approver.
19
Start
Requester
Team leader
System
System
QAS Controller
Basis& Basis&
Development Development
Team Team
User, Requester User, Requester
System
Project Manager
Basis& Basis&
Development Development
Team Team
Ussr, Requester user, Requester
Figure 4.2 Transformation between AS-IS process flow to TO-BE process flow
20
The developed system will create a slightly different process flow that is shown in
Figure 4.2(B), whereby most of the requester tasks have been delegated to the system.
Process flow TO-BE will make full use of the SAP system functionally in
communicating between SAP user. All notification about the transport process is done
through transaction SBWP which this transaction acts as the email application for SAP
user. Notification about the approval or rejection status, and transport status can easily
catered using this tool.
The shaded area m Figure 4.2 shows the transformation between the AS-IS
process flow to TO-BE process flow. It is clearly indicated that before any approval by
the appropriate person, the person will be notify via email through transaction SBWP.
After any approval and transport, the requestor will also be notified indicating whether
the transport is approved or rejected and whether the transport is completed or not. This
email function has already embedded in SAP system and the project is fully implemented
the function in order to prevent it from wasted.
21
4.4. USE CASE DIAGRAM FOR TRANSPORT REQUEST
Transport Change Workflow
Requester Create Request
Reject request
«extends
Approve Request
Transport request ;--T-----t=--

Team Leader
Test Changes Basis and

Development Team
OAS Controller
Project Manager User
Figure 4.3 Transport Change Workflow Use Case
Table 4.1 Description on Actor Task in Use Case Diagram

Actor Task Description
Requester Create Request:
- Fill in form for request
- Input details about changes
- List change request id that need to be transported
Team leader, QAS Approve request I Reject request
controller, project manager - after reviewing the changes, decide to whether
approve or reject the request
22
User Test Changes
- Test changes that going to be transported to
production
- Test changes that have be transported to production
Basis and Development Transport Request
Team - Released the change request id
- Transport the change request id to target
client/server
Figure 4.3 shows the actor and use case that involves in the business flow of the
system. The actors involve include Requestor, team leader, QAS controller, project
manager, Basis and development team, and user. All actors except user are from the SAP
department at client site while user is a novice user and do not know about technical
specification of SAP. Requester is the person who performs a request for SAP transport.
Team leader, QAS controller, and project manager are an upper level management who
review the request and approve or reject the request before it can be transported.
Table 4.1 provides detailed description on the actors' tasks in the use case
diagram.
4.5. DATA FLOW DIAGRAM FOR THE TRANSPORT REQUEST
On most processes in the Data Flow Diagram as shown in Figure 4.4, the request
form itself becomes the input and output of the system. The request form traveled
through all the processes and retrieve approval information along the way. In some cases,
the processes will stop on one of the approval process if the request is rejected by the
approver. If this happen, the form would directly cross all other remaining process and
head offto the requester to notify the requester about the rejected form. Upon completion
of all processes, appropriate details will be updated immediately to the database.
23
ZTRSDET
ZTRSREJ
Approval Request
Details Details
Request Form-----,
Request
Fonn Request Form-----,
Request
--Details
ZTRSDET
ZTRSREJ QAS
,..____Approval COiltrOl'i8t
'-------' Details
Request
QAS Fonn
,.----IReque,,..._--,
Fonn
Change
RequestiD
QAS Transport
J
.---r-----
ZTRSREQ
Oelails c__ _ _ __
Complete
Request
Fonn
~
Request
Fonn
Request Form-----,
PRO
Request
Fonn Transported
Fonn Acceptance
Details
Request Form-----,
L-
's, . < I
,---- BfJ~iS:P, f'o--1 Project
Manager
r~nt
PRO
Transport
t
Change Approval
Request
Request Details
Details Details
10
ZTRSDET
ZTRSREQ
ZTRSREJ
Figure 4.4 Data Flow Diagram for the Process
24
Table 4.2 Detail description on the data flow diagram processes
Process Description
Team Leader Team leader reviews the changes that are submitted by
Approval requester.
Then decides whether to approve or reject the request. The
details will be updated immediately in table ZTRSDET. If the
request is rejected, table ZTRSREJ will also be updated.
QAS Controller QAS controller reviews the changes that are submitted by
Approval requester.
details will be updated immediately in the ZTRSDET. If the
Basis QAS Transport Upon receiving approved request form, Basis team will work
out the transport request to QAS using appropriate change
request ID.
Details will be updated to the database immediately upon
successful transport.
User Acceptance Test User will review the transport that has been done at QAS and
perform user acceptance. The details will be updated
immediately to the database.
Project Manager Project manager reviews the changes that are submitted by
Approval requester.
details will be updated immediately in the ZTRSDET. If the
Basis PRD Transport Upon receiving approved request form, Basis team will work
out the transport request to PRD using appropriate change
request ID.
Details will be updated to the database immediately upon a
successful transport. A complete form (contains all transport
25
and approval details) is send back to requester for review.
Table 4.2 shows the details description on every process in data flow diagram
including its input and output.
4.6. TRANSPORT MANAGEMENT CONFIGURATION IN MINI

SAP
To enable a transport process, Transport Management System (TMS) in SAP need

to be configured. TMS configuration can be done through transaction STMS in SAP.
First step is to define one instance as the Transport Domain Controller (Giovanni, 2005).
For this project, instance called MBS is chosen to the Transport Domain Controller
because that instance applies all criteria to be Transport Domain Controller. MBS is the
development system where all configurations are done there before it is transported to
production system and it has high availability which will always be available for other
system to be connected to.
Then, other instance that acts as a production system is added to MBS to be able
to move transport. The instance is named RPR that represent PRD in the customer site.
Configuration of the TMS is done by adding Background Work Process (BTC) to
the instance profile, then by logging on to the SAP system using super user id, TMS is
configured. TMS configuration is usually done only once in one system environment
because the configuration is usually fixed for whole implementation ofthe business. SAP
Basis team is responsible to administrate the configuration if any amendment needs to be
done.
A transport profile is the text based configuration that contains information
regarding the configuration that has been made to the system. The transport profile
contains following information (BasisConsultant.com, 2005):
• Databases form various target system
• Parameters describing the frequency of the transport
o Global parameter (for all SAP system in the network)
26
o Local parameter (only for specific SAP system)
o Operating system-dependent
o Database-dependent
• Additional information for system maintenance
Figure 4.5 Screen shot shows the configuration ofMBS (DEV and QAS system) and
RPR (PRD system)
After the configurations have been completed using domain link, the interface of
SIMS system list will look like Figure 4.5. Both systems have been connected using
domain link and MBS system is set as the domain controller. A transport route is then
created so that change request id can be transported to the production system from quality
assurance system.
4.7. DATABASE CONFIGURATION
Additional database tables are created and linked to the existing standard table in
SAP to allow the developed system to function properly. These tables store data on the
requester details along with change request id that is used for transport. All details
regarding the approval and rejection of the transport request are also stored in the
database for future used.
27
Figure 4.5 shows entity relationship diagram of the database configuration. Some
fields in the created database are linked with the existing standard tables in SAP such as
change request id and SAP user name. The new tables that are created for the developed
system are ZTRSDET, ZTRSREQ, and ZTRSREJ.
ZTRSDET is the table that stored all details regarding the requester, transport
properties such as its description. It is the main table ofthe system. ZTRSREQ stored list
of change request id for single form. Since one transport request can have several change
request id, therefore it is best to normalize the table that the change request id is stored in
different table than the details table (ZTRSDET). They are linked using primary key
'FORMID' that stored unique transport request form id. Therefore the relationship is I to
many for the two tables.
Another table is ZTRSREJ that stored details on the reject form. It contains details
such as date of rejection and rejects log details. Since not all transport requests will be
rejected (most will have approved status), therefore the relationship for those tables is 0
or I to I. Table USR02 is the standard SAP user table where is stored details on a single
user and it is used to link to the requester SAP id.
28
'CTARiF~ct,nal Area]
TRGTQ : QAS]
TRGTP [Client: PRO]
TDATS {Create Date]
TDATC [last Changed]
TOFC1 [Indicator: Client]
TOFC2 [Indicator: New/Fix]
EOFC1 [EOC 1]
EOFC2 [EOC 2]
EOFC3 [EOC 3]
EOFCOTH [EOC Text]
DESTX [Text Header]
TSKRE [Task/request]
TLEAD [Team Leader]
QASCT [QAS Controller]
PRMGR [Project Manager]
[TL Approval]
SDATT [Tl Approval Date]
QASST [QAS Approval]
SDATQ [QAS Approval Date]
PRMST
SDATP I
QAS]
PRO]
[Transport date QAS]
[Transport date PRO]
STATQ [Status QAS]
ST ATP [Status PRO]
Figure 4.6 Entity Relationship Diagram for Developed System
Refer Appendix B for more information regarding the fields' description for each
table.
4.8 THE SYSTEM INTERFACE
The developed system can be access through transaction ZTRS in the SAP Mini
system. The transaction has been created and link to the program file so that the system
can be called without having to execute the program name.
The initial screen of the system provides information on the pending approval and
transport. All pending approval from team leader, gas controller, and project manager are
29
counted and displayed in the initial screen so that the approver knows about the approval
that they need to make when they first execute the program. While the pending transport
stated on the no of transport that need to be made either to QAS or PRD.
4.8.1 Creating Request
The important element of the system is to create request or proposal. This

function allows the user or requester to create a requset and apply for approval before the
change request id can be transported to QAS or PRD. The screen for creating request is
shown in Figure 4.7.
Create Request
·~
(!) Yes ().No Will this change a process step?

':i:' Yes No Will this change the. screen fields?
.(~i Yes No Will this effect data migration activities?
Others
Desc
Team Leader
QAS Controller
Project Manager
Figure 4.7 Screen Create Request that include all details regarding the transport
30
Unlike the normal hardcopy form, the create request screen can easily be populate
with data as the screen used advance technique to request information which used
dropdown menu, help function that provide list of available input and option button that
enable user to easily choose the request form attributes. The change request id can easily
be populated in the transport request whereby the requester only need to browse through
the list in the SAP system and choose which id that needs to be transported. This function
eliminates the need of user to refer to the SAP system to get the change request id and list
it in the hardcopy form.
4.8.2 Approval and Reject Request
Request Approval
·~ i/i ~prws • ,@ Reject .·
.. ,_./'-~ . _,"~·-. , .. ,.. ' ._,. ~ ..''i' ,.;;:.,_.,_,,, ··.> . ;~:{QL'. ·,·_, .,o·:-1'>•";khli~U ( -~ ,,, -:·;,;·.-,-, .
-- F19B52
·,;:
;<
,.
ProposaiiD . . Requester Team Leader-, Status QAS Controller status Project Manager status ()\CDJ·
BCUSER TEAHLEADER [~] QASCTRL ·::J [I .;.J!J
F19974 FIKRI TEAMLEADER ~j QASCTRL f:ZJ PRDJMGR [] . ...EJ
j:· F1 8881 BCUSER . TEAMLEADER [~j QASCTRL , jij PRDJMGR []
-c--:".,.-r . ): .
'I F18B82
F19B84
BCUSER
BCUSER
TEAHLEADER
TEAHLEADER
-- [~I
n
QASCTRL ~
LJ _L
- - -,J-1-
... l
[-1
[]
,.. ·.
F18B86 FIKRI TEAHLEADER · I_] [J

F19B89 FIKRI TEAHLEADER Gii ~ASCTRL !_:;[! PROJMGR L-1
'>··
·-·-
F19B91 FIKRI IDHLEADER ., lY._i QASCTRL u iJ
F1BB92 BCUSER . TEA"LEADER r··-·
l.)
'
--;
I I -c.J :> . .
.
,--1
F19993 BCUSER TEAMLEADER ~ QASCTRL , __, r_J••
F16B94 FIKRI TEAMLEADER · [~ QASCTRL PROJMGR [] >~·
.,,. F,).~
FIKRI -...
.. LL.
..
.CI ,. EJ
i':.i"' •. .•. • .· • /i'.'•/{: 1<1.1•1•1 ....
:1• .1•1
Figure 4.8 Pending list of transport request for approval
Figure 4.8 shows the list of pending transport request that request for the approval
from the team leader, qas controller, and project manager. The list provide a quick view
on the pending request that ease the approver to know that they need to perform approval
on which request. It listed the pending approval by specifying the required person SAP id
for easy view by the required person. The approval is grouped based on the approver so
that the approver will know on which level that the approval is requested.
31
This screen can be navigated to an overview screen in which the approver can
review the request before approve it. If the approver does not satisfy with the request, the
approver can reject the request and input the reject log regarding the reason that the
request is rejected, by clicking on the reject button located above on the application
toolbar of the screen.
The screen is designed such a way so that it can provide easiness for the user
especially the approver to use the approve function and get better navigation especially
when getting an overview of the request details.
4.8.3 Transport Maintenance
The screen for transport maintenance listed all requests that have been authorized
and available to be transported to QAS or PRD. Only request that have been approved by
qas controller can be transported to the QAS and only request that have been approved by
project manager can be transported to PRD. Figure 4.9 shows the initial screen of
transport list in transaction ZTRS.
Pending Transport Request

Transport
Figure 4.9 Screen shot on the list of pending transport request to QAS and PRD
The basis team who authorized to perform the transport can get an overview of
the request by accessing the overview function by clicking on the overview button that
located in the application toolbar of the screen. The transport maintenance can be
performed by clicking on the transport button and the system will navigate the user to the
maintenance screen for the appropriate server.
32
Figure 4.10 Transport maintenance screen for quality assurance server
Figure 4.10 shows the transport maintenance screen after the basis team accessing
the transport maintenance function from the pending transport request screen. Only tab
for the required server is enabled for maintenance for each level of transport for each
request. For example, only tab for quality assurance is enabled if the form is required to
be transported to this server. For the time being, the tab for production transport is
disabled to indicate the process for production transport is still not authorized.
The basis team needs to specify the return code for the each change request id that
specified the status of the change request id whether it is successfully transported, or have
warning message, error message, or have fatal error. If the change request id does not
have successful return code, it can be transported again and the process for maintaining
the transport process is still valid for the request.
4.8.4 Management Analysis
Analysis for the transport request can be accessed through function analysis that is
created within the main system interface. It can be accessed through the menu list of
Management -+ Analysis. The system will navigate the user to the screen that contains
links to the analysis reporting that created using ABAP language. The management can
33
accessed the analysis by clicking on the button provided and the system will navigate the
user to the selection screen for the analysis. After specifying the parameters, system will
generate the list of reporting that can be used by the management to perform analysis
regarding the transport request.
Figure 4.11 Transport analysis screen
Figure 4.11 shows the transport analysis screen that contains two links to the
analysis request by date and request details by date. Both ofthis linked will navigate to
the selection screen of the analysis and the user can specify the parameters for input
before generating the analysis. Management can used the analysis function to monitor the
transport request and get an overview of the transport process in the SAP system.
4.9 TECHNICAL SCREEN FLOW
The initial screen of transaction ZTRS can be used to navigate to four main
screens that include screen for create request, request approval, pending transport, and
transport analysis. Figure 4.10 shows the navigation between the initial screen and the
main function of the system.
At the create request screen, user can choose to open an existing transport request
through screen 0300. The screen will be prompt as dialog box and get input from user.
34
The screen also allows the user to select a list of functional area (screen 1000) by given
module when certain restriction is obeyed.
Open Transport
Proposal
(Screen 0300)
Create Proposal
(Screen 0200) Select Functional
Area
(Screen 1000)
View Proposal
{Screen 0200)
Proposal Approve
Approval Proposal
(Screen 0400) (Screen 0500)
Initial Screen
(Screen 01 00) Reject Proposal
{Screen 0600)
View Proposal
Pending (Screen 0200)
Transport
(Screen 0800)
Transport
Remark
(Screen 0700)
Transport
Analysis
(Screen 0900)
Figure 4.10 Screen Flow of Transaction ZTRS in SAP
From the screen approval, user is allowed to have an overview on the selected
transport request through screen 0200. For approval and rejection, user can used screen
0500 and screen 0600 respectively.
Basis team can perform maintenance on the transport process at screen 0800
where the screen will list any pending transport request to development and production
system. They can have an overview on the request by navigating to screen 0200 and
perform the transport remark at screen 0700.
35
Screen 0900 is used to Jist the available analyses that are generated using ABAP
and navigate to each program respectively.
4.10 TIME BENEFIT COMPARISON
AS-IS Business Process In seconds TO-BE Business Process In seconds

1. Creating Request I. Creating Request
• Complete form details 180 • Complete form 150
• List change request id 240 details
• Search data from 120
system
2. Team Leader Approval 2. Team Leader Approval
• Physically meet the 240 • Notification via SAP 10
approver email (automated
• Return 240 process)
• Reply via SAP email 10
(automated process)
3. QAS Controller Approval 3. QAS Controller Approval
(automated process)
4. Transport Process QAS 4. Transport Process QAS
• Physically meet SAP 270 • Notification via SAP 10
Basis Team email (automated
• Transport process to 300 process)
QAS system • Transport process to 300
270
• Return QAS system
10
• Reply via SAP email
(automated process)
5. Project Manager Approval 5. Project Manager Approval
(automated process)
6. Transport Process PRO 6. Transport Process PRO
• Physically meet SAP 270 • Notification via SAP 10
Basis Team email (automated
• Transport process to 300 process)
36
PRD system • Transport process to 300
• Return 270 PRD system
(automated process)
Total 3780 970
=63 min = 16 min
Time reduce to 25.67% (970/3780 * 100)
Time execution of the developed system has be able to reduce to 25.67% whereby
the developed system managed to cut many unnecessary times especially during the
request for the approval and transport to quality assurance system and production system.
By replacing the physical process of meeting the required person, the system have used
email function in SAP to notify the user and the requester do not need to meet the
approver or basis team physically.
The process of listing the change request id has also been speed up because the
requester can used the function on SAP to link to the change request id list and choose
the required change request id for the request.
37
CHAPTERS
CONCLUSION AND RECOMMENDATION
5.1. CONCLUSION
Transport request is a crucial activity to transport the changes between one server
environment and the other server environment. The transport request serves the
organization needs to cater for the installation of customized product in different
environment without having to create the same changes to the other system. From the
analysis, it is found that the system is manageable to be completed within the time period
with the given resources.
During the first half of the project implementation, analysis have been made in the
sense that to understand the business process, analyze the business requirement,
understand the concepts of transportation within SAP. Research mainly work through the
process of identifying what are the processes and steps in performing the transport for
both between same the client in same server and different server.
During the second half of the project implementation, server to mimic the SAP
environment at the customer site has been generated within SAP Mini that has be
installed in a standalone computer. Database has been developed and normalizes to allow
the new system to operate properly. Testing has been done thoroughly throughout the
system implementation to ensure that the system is in good shape and to prevent for
major breakdown especially during the integration of the subsystem.
The developed system is managed to create satisfaction to the user in speeding up
the business processes and activities. This system has help to eliminate the unnecessary
time wastage in requesting for approval and replace the process with automated email
alert function. Since the email function is fully implemented in SAP and by default the
function embedded when deploying a SAP system, the function is now take to full use by
the SAP team thus prevent the function from being wasted.
38
5.2 RECOMMENDATION
Currently the developed system is not integrated with the Transport Management
System (TMS) is SAP therefore after performing the transport process the Basis team
needs to maintain the transport on a single change request id to the developed system.
The maintenance includes the recording on the transport return code which indicates
whether the system is successfully transported or not.
The integration do not taken place because Mini SAP system that the student use
to developed the project is not in capable for the function. In order for the integration to
be successful, two clients need to be created in one development server and two servers
need to be linked and connected in order to allow for full transport between the system
client and servers, but the server linkage generates unknown error and needed standard
SAP table is not build-in in the system.
Therefore for the next step of implementation, the system should be deployed in a
SAP system that implements the requirement and the integration can took place.
39
REFERENCES
[I] Solution Manager System Landscape Retrieved October I 0, 2005, from

http://help.sap.com/saphelp nw04/helpdata/en/la/Obb569d534344b9(4c6b3(deaa
4(alcontent.htm
[2] SAP Change Management- a brief overview Retrieved September 26, 2005, 8-11
from http://www. dimensionconsulting. com/Change Management. pdf
[3] SAP System Architecture Overview Retrieved October I 0, 2005, I & 25-26 from
http://www.hp.com/hpbooks/prentice/chapters/0130280844.pd(
[4] Ramachandran, Joy V., Useful Transaction Code Retrieved October 9, 2005 from
http://www.sapgenie.com/sapgenie/docs/useful-tcodes.pd(
[5] Davila, Giovanni, Configuring STMSfor Mini SAP Retrieved October 12, 2005
from http://www.sapadministration.com/knowledge/minisap46d!STMSconfig.pd(
[6] Ramachandran, Joy V., Basis Administration Tips Retrieved October 3, 2005 from
http://www.sapgenie.com/sapgenieldocs/tips%20and%20tricks.pd(
[7] Chapter 4 The Web Design Process Retrieved November 12 2005 from
http:llwww.pint.com/classes/webpub3/presentations/chapter4/small.pd(
[8] Types of Testing In The Development Process Retrieved November 12, 2005 from
http:/lwww. coleyconsulting. co. ukltesttype. htm
[9] Schaefer, Marc. Change Request Management with SAP Solution Manager
Retrieved November 11' 2005 from
http://www.saphosting. com/partners/ChaRM pdf
[10] Stallings, William Data and Computer Communications Retrieved November 11,
2005 from http://www.bridgeport.edu/-elleithv!CpE471/Slides/02-
Protoco!Architecture.ppt
[ 11] Serena Team Track Connector for SAP R/3 Software Retrieved November 11, 2005
from http://www.serena.com/Sharedlpdfs!TeamTrack/TT Connector SAP. pdf
[12] About the Benchmark - SAP Retrieved November 15, 2005 from
40
http://www.ideasinternational.com/info(ile/isap3.html
[13] Wilkin , Bob Ten questions to ask when evaluating SAP change management
solutions Retrieved November II, 2005 from http://2Jc[rpartll.com/
files/library/data management/ten questions.pd[
[14] SAP Library Glossary Retrieved November II, 2005 from
http://help.sap.com/saphelp glossary/en/index.htm
[15] Huseyin Bilgen Initial TMS Configuration After Installation Retrieved December
28, 2005 from http://www.boobboo.nildram.co.uk/Documentation/Transports/
tmscon(pd[
41
APPENDICES
42
APPENDIX A:
TRANSPORT REQUEST HARDCOPY FORM
43
Product: [ X ] SAP Source Client: 038 DEV
Target Client: ] 088 QAS Quality Assurance Client

088 PRD
Change Request No:
New
Fix
[ Yes No ] Will this change a process step
[Yes I No ] Will this change screen fields
[Yes I No ] Will this effect data migration activities
Others: - - - - - - - - - - - - - - - - - - -
Description
Tasks I Request: Change request

(pi's tick) All tasks released
To be released
By Team Lo;•m'L FI-CO

(Name, Signature & Date) ] MM
] SD
[ ] HR
Others: _ _ _ _ _ _ _ __
By QAS C-UIIUUIIOJ App. Mgr.

(Name, Signature & Date)
Return Code
0 Transport (export and import test) was successful
4 Warning messages were generated
8 Error messages were generated
12 Fatal error has occurred
Return Codes:
Error
*Form must be approved before can do the transport) [STBOOl/REV 2.0 24/04/05]
44
APPENDIXB:
DATABASE TABLE
45
APPENDIX B.l: TABLE ZTRSDET FIELDS DETAILS
FIELD KEY TYPE LENGTH TEXT

CLIENT X CLNT 3 Client
FORMID X CHAR 13 Form ID
BNAME X CHAR 12 Requester SAP ID
RIDNO X NUMC 6 RID Number
MODID CHAR 3 Module ID
FNCTAR CHAR 30 Functional Area
TRGTQ CHAR 1 Target Client: QAS
TRGTP CHAR 1 Target Client: PRD
TDATS DATS 8 Request Creation Date
TDATC DATS 8 Last Changed

TOFCl CHAR 1 Type of change indicator: Client
TOFC2 CHAR 1 Type of change indicator: New/Fix
EOFC1 CHAR 1 EOC: Will this change a process steps?
EOFC2 CHAR 1 EOC: Will this change the screen fields?
EOFC3 CHAR 1 EOC: Will this effect data migration
activity?
EOFCOTH CHAR 50 Effect of Change Other Text

DESTX CHAR 72 Text Header Description
TSKRE CHAR 1 Task/request Indicator
TLEAD CHAR 12 Team Leader

QASCT CHAR 12 QAS Controller
PRMGR CHAR 12 Project Manager
TLEST CHAR 1 Status Approval: Team Leader
SDATT DATS 8 Team Leader Status Approval Date
QASST CHAR 1 Status Approval: QAS Controller
SDATQ DATS 8 QAS Controller Status Approval Date
PRMST CHAR l Status Approval: Project Manager
46
SDATP DATS 8 Project Manager Status Approval Date
TRNQT CHAR 12 Transporter ID - QAS
TRNPT CHAR 12 Transporter ID - PRD
TDATE DATS 8 Transport date- 088 QAS
TDTPR DATS 8 Transport date- 088 PRD
STATQ CHAR I Status form (QAS)
STATP CHAR I Status form (PRD)
47
APPENDIX B.2: TABLE ZTRSREQ FIELDS DETAILS

REQID X CHAR 20 Request ID
QASTS CHAR 2 QAS Return Code
PRDTS CHAR 2 PRD Return Code
STATQR CHAR I Request Status (QAS)
STATPR CHAR I Request Status (PRD)
48
APPENDIX B.3: TABLE ZTRSREJ FIELDS DETAILS

BNAME X CHAR 12 Requester SAP ID
PRSTA X CHAR I Person Status: I - TL; 2- QAS; 3 -PM
DATER X DATS 8 Date Reject
TLINI CHAR 60 Comment text line
TLIN2 CHAR 60 Comment text line
TUNS CHAR 60 Comment text line
49
APPENDIXC:
USER MANUAL
50
Transport Request System
in SAP
User Manual
Author: Ahmad Fikri Amer Hamzah

Supervised by: Mr. Khairul Syafee Kalid
51
Table of Content
Execute transaction ZTRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Main Menu.............................................................................. 1
Create Request .. . .. .. .. .. . .. . .. .. .. .. .. .. .. . . .. .. .. .. .. . .. .. . . .. . . .. .. . .. .. .. .. . .. . .. .. . 3
Open ex1stmg request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Send email to required person .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ... 7
Approval................................................................................. 7
Rejection .. . .. . .. . .. . .. .. .. .. . .. .. .. .. . .. .. .. .. .. .. .. . .. . .. .. . . .. . .. .. .. .. .. .. .. .. .. . .. ... 9
Transport Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Analysis for Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 12
52
Transport Request System in SAP
User Manual
l. Execute transaction ZTRS

a. Execute transaction ZTRS by key in 'ZTRS' in the command field at the
initial screen of SAP.
• ZTRS is the transaction that is used to call the system
Figure 1 Execute transaction ZTRS
2. Main Menu
a. After transaction ZTRS is successfully executed, screen at Figure 2 will
appear.
Fignre 2 Main menu of transaction ZTRS
53
ii
iii
iv
Figure 3 Details on Main Menu function
b. Details on each functions are as follows:

i. Button to navigate to create request screen
11. Menu bar that group functions in two sections that are Request
and Management. Under Request, contains Transport request and
Approval, while under Management contains Analysis.
o Transport Request-Navigate to create request screen
o Approval- Navigate to Approval and Rejection screen
o Analysis- Navigate to analysis screen
111. Navigation button
o I§ Back button
o rmJ Exit button
o This button applied for every section in the system
IV. Pending request section
o Approval button- Navigate to approval and rejection screen
o Text box next to approval button- Shows the pending
approval request to the team leader, qas controller, and project
manager.
o Transport button- Navigate to transport listing screen
54
o Text box next to transport button - Shows the pending
transport to development server or production server
3. Create Request
a. To execute create request function, perform one of the listed method:
1. Click on buton~ to navigate to create request screen
u. Choose Request from menu bar. Click on Transport Request.
1\pproval
iii. Press F5 button on keyboard.

b. Screen at Figure 4 will appear.
Figure 4 Create request screen
c. Fill in all attributes regarding the transport request

• To activate Functional Area input box, fill in the SAP Module and
then press Enter button on keyboard
55
• To get list of available input for functional area, perform one on the
method:
o Click on~ that located next to the field

o Press button F4 on keyboard to get the listed functional area
based on the SAP module
• Choose available input from the list of functional area
• Complete other details on the Attributes tab.
d. List the change request id of the form
• Choose Change Request tab
• To get list of available input for change request id, perform one on the
method:
o Click on ~tha located next to the field

o Press button F4 on keyboard to get the listed functional area
based on the SAP module
• Click ~ to add another change request id space. (one by one)
• Click IBJ to add another change request id space. (ten by ten)

• Click~ to delete one row of change request id
e. To save the request, click on [QJ that located at the standard tool bar.
f. A message is prompt stating the request has been created and saved, and
the form id for the request.
Figure 5 Example of save message that prompt upon the saved request
56
4. Open existing request
a. Click on ~tha located at the application toolbar of create request

screen.
b. Screen below will appear
c. Type in the form id or press F4 to get the list of form id.
d. Click~ to proceed with the process
e. Click 1~. cC~-0teil to halt the process

f. When successfully open a form, new features will appear on screen:
1. Edit Request- allow user editing on the request as long as the

form is not approved or rejected by the required person.
Only creator of the request can edit the form.
ii. Delete Request- allow user to delete the request.
Only creator of the request can delete the form.
57
iii. Additional attribute of the form appear on the right side of the
screen.
• The requester SAP id
• Request created date
• Last changed date
• The request status that include approval status and transport
status.
g. To save the edited form, click on the save button
58
5. Send email to required person
a. Click on I3J that located next to the approver input field. The button will
only be available for action when the field for the required person is filled
and saved.
b. Email will be send automatically to the required person.
6. Approval
a. At the main screen of transaction ZTRS, click on Approval button.
Figure 6 Approval screen
c. The approval screen listed all pending approval by their position that are
team leader, qas controller, and project manager.
59
d. Choose the form that need to be maintained as shown in the example
above.
e. Click Approve button

f. Screen below will appear
g. Tick on the checkbox or the required person
h. Click~ to proceed with approval
60
7. Rejection
a. Follow steps 6a- 6d.
b. Click Approve button

c. Screen below will appear
d. Tick on the checkbox or the required person

e. Enter reject comments
f. Click~ to proceed with approval
g. Click~ £an.:~ to halt the process
61
8. Transport Maintenance
a. At the main screen of transaction ZTRS, click on Transport button.
Figure 7 Transport maintenance screen
c. The transport screen listed all pending transport to the required server for
development and production.
d. Choose the form that need to be maintained as shown in the example

above.
e. Click on button tl~£:i} 1]1ldrt,5 to proceed with the transport. Only

authorized person will be allowed to access this function.
62
Figure 8 Transport remark screen. Only applicable to BASIS team.
f. Screen in Figure 8 will appear.
g. Maintain the return code for each change request id.

1. Success- return code 0; means the transport is successful
ii. Warning- return code 4; means the transport is not successful
iii. Error- return code 8; means the transport is not successful
IV. Fatal- return code 12; means the transport is not successful
h. Click r~j to save when complete maintain the request.

1. For transport to production server, the tab will change to
from
63
9. Analysis for Management
a. Click on Management at the menu bar and choose Analysis or press F6 on
the keyboard to activate the function.
b. Screen in Figure 9 will appear
Figure 9 Transport analysis screen
c. Click on the buttons available for analysis.

d. Currently the analyses that available are Request by Date and Request
Details by Date.
64
APPENDIXD:
DEVELOPER MANUAL (TECHNICAL SPECIFICATION)
65
Technical Specification -Transaction ZTRS
1. General status information

Developer Ahmad Fikri Amer Hamzah
Version 1
Date (last modified) 6/19/2006
Report ID ZTRS_TRANS
Transaction Code ZTRS
2. Screens Declaration
Screen No Description GUI Status GUI Title
0100 Main Screen S_0100 T_0100
0200 Create Request Screen S_0200I T_0200I
S_0200L T_0200L
S_0200V T_0200V
0201 Subscreen for tabstrip
Attributes (0200)
0202 Subscreen for tabstrip Change
Request (0200)
0300 Open existing form S_0300 T_0300
0400 Pending list for Approval S_0400 T_0400
0500 Approval screen S_0500 T_0500
0600 Reject screen S_0600 T_0600
0700 Transport maintenance screen S_0700 T_0700
0701 Subscreen for Quality Assurance
(0700)
0702 Subscreen for Production (0700)
0800 Pending list for Transport S_0800 T_0800
0900 Analysis screen S_0900 T_0900
1000 List of functional area by s- 1000 T_1000
module
3. GUI Title Text

1 GUI Title 1 Text
66
T_0100 Transport Management System
T_0200I Create Request
T_0200L Edit Request - Form &
T_0200V View Form &
T_0300 Open Transport Request
T_0400 Request Approval
T_0500 Approve Request
T_0600 Reject Request
T_0700 Transport Remark
T_0800 Pending Transport Request
T_0900 Transport Analysis
T_1000 Select Functional Area
4. Technical description of report
Main include program used:

INCLUDE ZTRS_TRANSTOP. ~for declaration
INCLUDE ZTRS_TRANS001 . ~to store module Process Before Output
INCLUDE ZTRS_TRANSI01 . ~to store module Process After Input
INCLUDE ZTRS_TRANSF01. ~to store all subroutines in the program
Other Include program used (PBO):

INCLUDE ztrs_transo01 - 0100. ~ for screen 100
INCLUDE ztrs_transo01 - 0200. ~ for screen 200, 201, 202
INCLUDE zt rs_ t ranso01 - 0300. ~ for screen 300
INCLUDE ztrs_transo01_0600. ~ for screen 600
INCLUDE ztrs_transo01 - 0700. ~ for screen 700, 701, 702
INCLUDE zt rs_ t ranso01 - 0800. ~ for screen 800
Other Include program used (PAll:

INCLUDE ztrs_transi01_0100. ~for screen 100
INCLUDE ztrs_transi01_0200. ~for screen 200,201,202
INCLUDE ztrs_transi01_0300. ~for screen 300
67
INCLUDE ztrs_transi01 - 0400. ~ for screen 400
INCLUDE ztrs_transi01 - 0500. ~ for screen 500
INCLUDE ztrs transi01 - 0600. ~ for screen 600
INCLUDE ztrs transi01 - 0700. ~ for screen 700, 701, 702
INCLUDE ztrs_transi 01 0800. ~ for screen 800
INCLUDE ztrs transi01 0900. ~ for screen 900
INCLUDE ztrs transi01 1000. ~ for screen 1000
Subroutines:
FORM save_request.
Assign data that need to be save under subroutine ''assign_det_0200".
Check whether the form is an existing form or mew form by checking in
the load_indic variable. If it is initial, then the form is new. Get
new form id.
Assign change request id under subroutine "assign_transport_id''.
Input data into table ztrsdet and ztrsreq.
FORM get_form_id.
Use function module "NUMBER_GET_NEXT" to get the next number for form
id. Concatenate 'F' into the retrieved id.
FORM get_as4text.
Get text for each change request id that is written by user into the
table control by retrieving it from standard SAP table. Store it
temporarily in the internal table.
FORM confirm_loss.
Use function module "POPUP_TO_CONFIRM_LOSS_OF_DATA" to make
confirmation on the loss of data that will trigger on the back button
from screen create request.
FORM load_existing.
Call screen 0300
FORM clear_data.
Clear all work area and internal table in order to get fresh variable.
68
FORM assign_det_9299.
Assign data from screen 0200 into work area before it is saved into the
database table.
FORM assign_transport_id.
Assign change request id for each request into an internal table before
it is saved into the database table.
FORM get_form.
When open an existing form, select data from table ztrsdet, ztrsreq,
and ztrsrej. Assign indicator to load_indic variable to remark that it
is an existing form.
FORM get_approval_reject.
Get the number of request that is still in approval mode whether by the
team leader, qas controller or by project manager.
FORM get_transport.
Get the number of request that required for transport to development
server or production server.
FORM assign_load_9291.
On load form, assign screen element based on data saved in the database
table (for screen 0201).
FORM get_detail_9291.
Get details from the screen element, and assigned it to the variable
declared before proceeding with any next step (for screen 0201).
FORM assign_load_9292.
On load form, assign screen element based on data saved in the database
table (for screen 0202).
FORM edit_proposal.
If team leader status is pending or still not requested, set variable
edit_indic to "E1''. If team leader have approved the request, set
variable edit_indic to ''E2". If team leader have rejected the request,
no editing allowed.
69
If qas controller status is pending or still not requested, set
variable edit_indic to "E2''. If qas controller have approved the
request, set variable edit_indic to ''E3''. If qas controller have
rejected the request, no editing allowed.
If qas controller have approved the request, check if the transport to
development server have completed or not, if yes, proceed with editing,
if not, process halt.
If project manager status is pending or still not requested, set
variable edit_indic to ''E3". If project manager have approved the
request, set variable edit_indic to "E4''. If project manager have
rejected the request, no editing allowed.
If project manager have approved the request, check if the transport to
production server have completed or not, if yes, proceed is complete,
if not, process halt.
FORM approve_request.
Call screen 0500.
FORM view_proposal_0400.
Retrieve data from database before assigning it to all screen elements.
Leave to screen 0200. Set variable load indic to 'V' to indicate only
view is allowed by this user.
FORM approve_request_0500.
Check for all person approval that is team leader, qas controller, and
project manager. Check for only authorized person to do the approval.
If yes, proceed with approval and send email to requester to notify
about the approval. For qas controller approval and project manager
approval, upon successful approval, email is also send to the basis
team to notify about the pending transport to development and
production.
FORM reject_request.
Call screen 0600.
FORM reject_request_0600.
Same process with subroutine approve_request_0500 with only email
notification to the requester.
70
FORM assign_approval_status_text.
To assign status text based on the status of current request. The
status is regarding the approval and rejection and status on the
transport to the required server that are shown on screen 0200.
FORM get_transport_data_0800.
Get a list of pending transport to development server and production
server.
FORM view_proposal_0800.
Retrieve data from database before assigning it to all screen elements.
Leave to screen 0200. Set variable load_indic to 'W' to indicate only
view is allowed by this user.
FORM get_transport_detail.
Retrieved transport details for the selected form and assigned it to
screen element if screen 0700. Assigned data to subscreen 0701 and 0702
using subroutine "assign_data_0701" and "assign_data_0702".
FORM save_transport_0700.
For development server, use subroutine "save_transport_q" and for
production server use subroutine "save_transport_p".
FORM save_transport_q
Update field for development server only for table ztrsreq, ztrsdett,
and ztrsdet.
FORM save_transport_p
Update field for production server only for table ztrsreq, ztrsdett,
and ztrsdet.
FORM assign_data_0701
Assign data for subscreen 0701 in the transport maintenance screen
0700.
FORM assign_data_0702
71
Assign data for subscreen 8782 in the transport maintenance screen
8788.
FORM delete_proposal
Delete data from table ztrsdet, ztrsdett, ztrsreq, and ztrsrej.
FORM confirm_delete
Request for confirmation to delete the form.
FORM send_email
Check for email variable email_indic, to populate the email content
based on the required person.
FORM setup_trx_and_rtx_mailboxes
Setup the mailbox for transaction STMS
FORM create_and_send_mail_object
Create and send the email with its content to the required person.
FORM collect_data_functional_area
Retrieved data from function module "RS_COMPONENT_VIEW" to get the
functional area of a SAP module. Store it into internal table
it_tbl 1888.
72
Screen Technical Layout
Screen Layout
0100
0200
' ~ At-ribu~lG,h·g:;._Rj1
i!
I
:iII
II
tl I
,~-
0201
. c:i'~-to;d1
Type· d. l.··. ·c····h····ange. -.'.'.'.·c. ::.:·'"-;-···.··:· l§ji~]
[
0 ~_1.:-If!£'
·----"""""""""""""' ·---
~l
' E'ffeCf'·Clf>Change .,
~.;,1 •6J ~fl:riL ci:~;g-p·teP?l
~:· ~Yt <YNO Will .this change the· screen field~?J"
. "J&-~i;:·=1 ~} 11. t-~ ef ~ ec~ dat;·.migr~-:f vi ~}es?
73
.·.·
0202 . .. . ....
· ...
!--············································ -~r ... : . ~- - .. -~· . ···---·- ···-·-
--- -1~ .
. ~I .•. ~ . .+1·-~ . __ -- !
.l .k -· ------··-- ·---- -- ••..•
r-tt·. ·····=- =·=· =~· ~=

..
·
0300
.
j--- .
1-- ......
.• ...•.... · ·. ·.' .•.. ...• .
l ifo_r,. id!l• •··. I

0500
i- ~=!;
; IPrqjB'C_t
.
'Mafl.o3~i"APprv
. .• .....[l .;
.·........
74
0600 Teal{-~:r APProVal,:, ~,
QAS Coriti-Oller A.pprJ;'IVal-· :fl
[Project Manag'er Approva'l- [l
'i~:·D. "
i ~_ueptr .. 1
0700
': ~.;-' _I
I
ic
0701
c:-
·c
~0'- I"'
0702
:
::;
75
8888
8988 [
·-~'
Requst~- B'V' ifat9 .·-:~
1888
' .
76
APPENDIXE:
REPORT ON FINAL PRESENTATION
77
REPORT ON FINAL PRESENTATION
External examiner: Mr Izurrin, Prestigious Discovery Sdn Bhd

Lecturer: Mr Khairul Shafee Kalid (supervisor)
Dr Ahmad Kamil Mahmood (internal examiner)
Duration: 22 minutes
Presentation Outline:
Introduction
• Background
• Problem Statement
• Objectives
• Scope
Methodology
• Development Model
• Tools
System Architecture
Discussion
• Process Flow
• Use Case Diagram
• Data Flow Diagram
• Entity Relationship Diagram
System
• System Functionality
• Rejection Process
• System Benefit
• System Demo
Project Limitation
Conclusion
Q&A
78
Presentation Material (screen shot Flash)
I. • The initial screen of the flash

111\n:iduction
Pmje<:! Tho Development ol presentation
Metlwddogy Transport Rouoost SVStllm
ArcNieelura
Diswssion
In
SAP USIDU ABAP IBDUUIUB
• Greetings the external examiner,
System
., internal examiner, supervisor and
Co~u1i
Lirrilalion
II Ahmad Flkl'l Amer Hamzah
3570 the members' of the floor
'" Business tnronnatlon Systems
• Introduce myself and Final Year
'
aupervl•od by
MrKllaTrul Sharee Kalld
'""'"'
Project topic
2. """""""""""""to/T,.n•pot<Roqu..,!IW<m
lnS.OPuo~AeL•
• Explain regarding the project
lnlroduc!i011
Project
Project -~ Background background that includes
Methodclogy A transport request process is the transfer
Arehiledure
of SAP System components from one system
to another
clarification on what is the
Pi,wSl;ion
System The components to be transported are
specified in the object list of a transport request
transport process in SAP and the
Limi!ation
Cllnclusion Three basic generic environments that are change request id

development system, quality assurance system,
"' and production system
• Explaining on the system
!: The system is developed to transform current

paper-based system into auto'mated-based
system that is integrated within SAP background
3. ro.P ... IOl"''ontofTtonoport Roqooo\5,.tom

In SAP u~no A9.., """""..,.
~
• Listing the problems that
1~\roductmn
ProjeCI
Proj.,ct
Problem Statement associated with the current system
Me!hodology A paper-based transport request lorm is tilled
A1cl1itooure before it is approved for transport
- Required specific filing system
and why do we need the
DlsCtJsslon -II is hard to maintain (standardizing problem)
developed system in the business
'"""
Llmilalion
Difficulty In performing analysis on the
transport request
COI\dusion process
'" Requester need to meet physically
with the approver
- Consume time
I
'"·";''
'"~
4. Th>.""'"'""""""'"'Tnmoo<tll<quortSy...,m
'"""""''"'l"l>APLI"'I••o•
~.-,"'
• Explaining on the objectives of the
ln~oducU01
Project
Project
Objectives 1 scope study and project scope
M•!hodoiagy Objectives
·To analyze transport process in customer site
Arcl1ileclure
that uses 2 different serv~ for development • Project scope is important because
DiS<;Ussion and production
·To develop a system in SAP to cater for change
S)'lilem
request transportation it can limit the boundary that the
llrrtitattOn -To design on additional database
-To design screens and its fields to perform tasks
Conclu•ion
in the transport proce.ss project caters
"' Scope
-Analysis caters In tho boundary of transport In SAP
'
-Transport process is between lwo differenl SAP
systems with several dent environments
'·'·"'"' -The system used ABAP language as the
progro,mming language
'"''""
79
T~ Daw!lopti>On!<>!Tra"'port Roq.,..._
5. In Sid' Nln; AliA!' Lon;u11110
• Explaining on the development
lntroduclloo
Methodology
Project Development model that is used as the model to
Melhodology
Arcllltecture develop the project
DisMslon
System
Click here to vlew the Development Model • The waterfall model includes
CoodusiOIJ
several phases and during the
"'
presentation, each phase is
explained thoroughly
0 i~l!':>J·<ro.e-} .o:- __ ,:rat!J":!

Development Model· Walertall Model
6. n,o P<"~enlo
lnS.O.PuolngAIIIIP Longuo;e
Tro .. ~t R•quo.t SV>t.m
• List the tools that are used during
lntrodut:tion
Pro)eel
Methodology
Tools the project implementation
Methodology
E1111 SE88 • Object- Navigator
SEll
Ardlilocture SE37 • All tools are located within SAP
D~cusion SE71
System
"'"
SCC1
itself and do not required extra
Limitation
Conclusion software to create the system
"'
7. Tho O.•olopmontollronopott R"'lU05! &~Item

In SAP uolng AUP u.._ge • Explain on the business process
ln~oduci
Projoc:t
Arc:hitilctur:e
architecture and how do transport
MethClihllogy
Architecture process related in the architecture
Diocussion
S)lltem
Llmilotion
Conclusioo
"'
80
8. • Differ the AS-IS process to TO-
ln~oducti
Proje<:l
BE process flow and how the flow
Methodology
from current system change to the
Discussion
System Click here to view the Process flow
developed system
Limitation
Concluaion • Emphasize on the shaded area
a& A
where all the changes taken place
9. TOe Dnolopm..,lol Tfonopoft lloqu-tSyot<m

lnSIII'uolngARAPlO ... UO!lO • Explain regarding the use case
lnlroduction
Project
Piacussion Use Case diagram for the business process
M~lhodgy
Archlteclure • There are six user and each user

DisCIJSslon
System
Click here to view the Use Case Diagram
have specific task that they need
llmltalion
Conclusron to complete
Q&A
81
10. The ~velopmntQfTrs
In s.+.Puslng ABAP ~"'l•ve
R<tqu..t Syot.m
• List the functionality of the system

lntrodudion
Project
Functionality and notify that all functionality
Methodology Create request
ArchiteclUrll Edit request will be explained thoroughly
Delete request
Discussi011 Notification via SAP email
System - Approval during the project demonstration
Umita\ion Rejection
Transport maintenance
Conclusion Analysis
Q&A Prinl request form
II. Tho Dovetop01ont ofTra'<porl Requ .. t Syotom

In SAP uolnv Allo\P L•ngu>ge
• Explain on one of the element in
IWoducUon
System
Rejection the business process that is
"'"'
Methodology Reasons lor rejection
, The task not complete rejection process
Ardlitecture
- Redundancy of object
Oiacussi<Jn - Authorization purposes
System -
Reasons to monitor the system
• Information that is explained
Limitation
- Prevent damage to production system
Condusion - Ensure the production system is clean reasons for rejection and the
Q&A from rubbish
- Maintain integrity of production system
reason to monitor the transport
process
12. Tho Po.. lo.,...nt OI'Tronopott Requ .. t SVol<>m

lns.u>uslog.U.O.PL>-
• System benefits is the important
Introduction 0~·.- "8U-~&mL
Project
System
Benefits elements in the system
MsthDdology Reduce process tlme'to 26%
Ardlitecture - Requirement of requester to meet approver implementation and the reason
physically have been replaced with internal
Discussion email function in SAP
System (click here) why do people need to use the
Umitalion
Speed up the transport analysis
Conclusion - Generate understandable reporting using
developed system
O&A ABAP by click of button
• Explain on the two main benefit of

the system that includes business
processing time reduction to 26%
""''"""'".'"'"" and speed up the transport analysis
1C•"'"""""'-""
180 , ComiO~
'" ·'""""""'"'"'"'"'"'
''"" •~
"'"
ll\1: • Explain how do the processing
l """'"'"'""'"'" time can reduce to the minimum
. ~;.,'! "~ '"' MD , "'~ SOF<<elol
["'~
'"'"'" l<~· ' R<>o>i
'"~=
~· S/.P ""''
!~·;. c•••,.,..,: -,·,;;;s"'"'....-.,:,.""' - level using time benefit

I
."""'"'... "'""' ....
'"~
,
1'?
240
, Noln<~
, Rop'f '"~ "'

lio SAP ·~
SAP "~'
comparison table
''"""' '"'""'""'""'"'i
~ . ""''''""
"""''""""""""' 110 , N<.,ft<otM >ill SAP
''"""'""'"'"'"')
om~l
·~"'
."'"""""' "~'
"''
J1a , R"~
{w~"')
-m
• '"'"""" "'"'"' '"QA>
wo SAP om~l
82
14. Th<, Dell<lopm.enl at Transport ~oqi!Mt
lnSI.Pusri!ABo~
SVolo"'
• During the system demonstration,
'"",...
Introduction
Project
Syate10 Demonwation I explain all the functionality in
Methodology
Architecture the system thoroughly
Oiswssion
System
Llmillltioll
Proceed with the system
C<Jnclusion
. Q&A
.t
···-"'·'"'"
15. Tbo Do•olopmento!Tron<i><>rt ~\left

lnS.I.PuolngAIAPLa'!liU>IJO
svotom
• Explain the limitation of the
lnlroduc;lion
Project
:t.imita.ticn system due to the limitation in the
MalhodoJogy The developed system is only partially
Architecture integrated with the Transport Management SAP
System (TMS) is SAP
Okscusslon -Basis team needs to maintain the transport
System process after performing transport to
- required server
Limitation
Coni;lusioo Reason
Q&A - Min"1 SAP do not allow for transport even
though the linkage between servers is
complete
!.:
'"''""·-
-The required standard SAP table is not
build-in In the SAP system
16. Th• Doll<lo.,....nt ofTranopott Roquootsystem

JnSA;><rologASAPLangu.ofl<'
• Conclude that the system able to
lnkoduction
Proje<lt
Conclusion create satisfaction to the user and
Methodology The developed system is managed to create
Architecture
satisfaction to the user in speeding up the help in eliminating unnecessary
business processes and activities
Di:~CVSon
System It help to eliminate the unnecessary lime time wastage

wastage in requesting for approval and
LlrrJialiorl
replaced with automated email alert
Conclusion - function
Q&A
\·';:~il
I
17. Th< O.volapm<!n\ afTr•nopcut Roquost syotem
• Conduct question and answer
..
lns.\Puo!"AEIO>~·g
lnlroduction
Projo:ct
, session and open the floor for any
Me\hodoiOSJy
Archllat:lure
inquiry
Dis~:on
System • 3 questions have been given to me

Questions & Answers
limilation
Con~lusi and I manage to answer the
Q&A -
questions perfectly
83
Question & Answer:
Dr Kamil: Explain more on why does approver need to reject a transport request?
Answer:
There are 3 main reasons the can lead the approver to reject the request:
a. The task not complete:
In real SAP project environment, there are man developers working for same
target but doing different job tasks and scope. Let's say that one of the
developers have completed the tasks and ready for transport and he have
requested for the transport from the team leader. The team leader who knows
more on the progress of the group may not approve the request since not all the
developers have completed their job. In the team leader perspective, transport
should only be taken place when all of the tasks under the project completed
otherwise it need to be postpone.
b. Redundancy of object:
When time goes by, there are many changes in the company structure including
the restructuring of the company staffs. The new staff may not know the task of
previous developer regarding the SAP working scope. When the new staff
creates one configuration and need to transport it, the request may have been
created before and it will generate redundancy in the SAP system. The upper
level management such as the project manager knows that the object created
have redundancy, thus reject the request.
c. Authorization purposes:
Authorization for user has limitation depends on their job scope and if the
granted authorization is not appropriate for the specific user, the approver may
reject the request of transport.
84
Mr Izurrin: Is there any specific period of time that the approver needs to approve the
request?
Answer:
There is no specific period of time to approve the request. This business process of
approver who have received the request, to approve it do not change from the AS-IS
process to TO-BE process. It does not effect the overall time taken to calculate the
overall processing time for the whole one business process. The section that the system
has improved is that the process of letting the approver knows that there is a pending
request that required his/her approval. The current system required the requester to meet
physically with the approver but it has been enhanced in the proposed system whereby it
has been replaced with email alert function.
Mr Izurrin: Referring to the reason of rejection slide, it the system has the capability to
detect the error rather than the approver reject the request?
Answer:
All ofthe errors that cause rejection by the approver are categorized as the logical error
that a system cannot detect. It is logically correct and the system does not find any
mistake that can violate the SAP execution for business process. A system should be
integrated with intelligent in order to recognize the logical error created by human and is
known as the expert system. The scopes of the project do not include the development of
an expert system as it required more enhancements toward understanding the human
logic. Therefore the developed system does not have the ability in identifying this type
of error.
85

The Development of Transport Request Sys

Uploaded by

Copyright:

Available Formats

The Development of Transport Request Sys

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

The Development of Transport Request Sys

Uploaded by

Copyright:

Available Formats

The Development of Transport Request System

in SAP using ABAP Language

Ahmad Fikri Amer Hamzah

Dissertation submitted in a partial fulfillment of

July 2005 I Jan 2006

Universiti Teknologi PETRONAS

CERTIFICATION OF APPROVAL ................................................ ..

LIST OF APPENDICES .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ... v

CHAPTER! INTRODUCTION ......................................... .

The Development of Transport Request System

Ahmad Fikri Amer Hamzah

A project dissertation submitted to the

UNIVERSITI TEKNOLOGI PETRONAS

Figure 3.1 Waterfall Model for the System Development............................... 10

DEY - Development System

Appendix A: Transport Request Hardcopy Form 43

1.1 BACKGROUND OF THE STUDY

The transport workflow provides a framework for transporting enhancements or

1.2.1 Problem identification

When a user requests for change transport to QAS or PRD, a paper-based

1.2.2 Significant of the Project

1.3. OBJECTIVES AND SCOPE OF THE STUDY

1.3.1 Objectives of the project

1.3.3 Relevancy of the project

1.3.4 Feasibility of the project

The project implementation calculated to complete in 24 weeks approximately in

Client/server configurations in SAP R/3 can be divided into 3 different tiers.

3.1. WATERFALL MODEL OF DEVELOPMENT CYCLE

Implementation of the project is based on the waterfall model in system

• please refer to Chapter 4 Result and Discussion for thorough explanation

Break the system into

Design each pieces

Code the system

Integrate the pieces

IImplement wnh real data

Figure 3.1 Waterfall Model for the System Development

3.2. PROCEDURE IDENTIFICATION

• SE80- Object Navigator

4.1. SYSTEM DEVELOPMENT PHASE BASED ON WATERFALL

4.1.1. Identify System Requirement

4.1.2. Break the system in subsystem (Architedure Design)

Change request management architecture consists of at least 2 servers with

SAP F10nt End SA.P Frm rt E·rd

Figure 4.1 SAP System Architecture at the Customer site

• between newly created subsystem

• Server with client

4.2. TRANSPORT REQUEST REJECTION PROCESS

Approval is important in transport request process because it can help the

• Prevent damage to production system.

User, Requester User, Requester

Ussr, Requester user, Requester

Transport Change Workflow

Requester Create Request

Transport request ;--T-----t=--

Test Changes Basis and

Project Manager User

Figure 4.3 Transport Change Workflow Use Case

Table 4.1 Description on Actor Task in Use Case Diagram

4.5. DATA FLOW DIAGRAM FOR THE TRANSPORT REQUEST