Introduction
The following CTS document is going to help each and every person who is already involved in the correction and transport procedure of this company or wants to know about the correction and transport system(CTS) from SAP. I have tried to cover the SAP versions 2.2, 3.1 and 4.5. I found out that most of our systems in Pandesic are using 3.1H version and users are not using the Transport Management System (TMS); so the Transport Management System is not covered in this document. I used lot of tips to help the basis users to solve the transport problems. Users will find some differences in the features between the 3.1H version and 45B version of Correction and Transport system .This document also covers the CTS difference between 2.2 version and 3.1 version.
I hope each and every person of this company who is performing the transport can take advantage of this document.
The Change and Transport System (CTS) is a tool that helps you to organize development projects in the ABAP Workbench and in Customizing, and then transport the changes between the SAP Systems and clients in your system landscape. This documentation provides you with an overview of how to manage changes with the CTS and essential information on setting up your system and client landscape and deciding on a transport strategy. Read and follow this documentation when planning your development project.
The Correction and Transport System
Changes created in the development system must somehow be moved, then incorporated into the test system, then subsequently moved and incorporated into the production system. The SAP Correction and Transport System (CTS) serves this purpose and is the vehicle by which SAP moves objects such as programs, screens, configurations or security settings from one system to the next. Additionally, the CTS ensures consistency between systems by maintaining log entries for any attempted or completed activities. If used correctly, the CTS creates an effective and standardized procedure for managing and recording changes made to the system while providing an excellent mechanism for integrating either newly created objects or existing objects that have been altered to meet the customer’s needs.
Release Changes in CTS
As a user of the CTS it is important that you become highly knowledgeable about its capabilities (i.e. changing objects, incorporating them into other systems and optimal use of existing error prevention methods). As a Basis administrator your goal is hopefully to be able to effectively communicate with other users of your SAP system. Therefore, "speaking the language" of CTS becomes an important aspect of your job. However, with new releases of SAP it is sometimes the case that terminology may need to be changed to better reflect the purpose of specialized utilities or to show the expansion of utility functionality. Such is the case within the CTS. Upon installing the newer 3.0 and higher releases of the system, version 2.x user will find that the correction control utility originally referred to as correction/repair," is now called task.
Additionally, where a transport, previously moved objects in release 2.x, is now the change request in version 3.0 and higher. Although, for the sake of simplicity, this book will focus on terminology specific to software releases 3.0 and higher, learning the differences in the terminology used from one system release to the next can benefit you greatly if you intend to work with various system releases.
Another change that you may wish to note is that from release 3.0 and up, the ABAP/4 development workbench includes the workbench organizer for managing software development objects. More importantly however, is that SAP recommends that the workbench organizer be used, as it has the added advantage of being fully integrated into the ABAP/4 development workbench.
CTS Transaction Terminology: Release 2.x versus 3.0 (& up)
Release 3.0 (& up) Release 2.0
Workbench Organizer (SE09) Correction and Transport System
Customizing Organizer (SE10)
Transport System (SE01)
Change Request Transport request
-Transportable - Consolidation request (K transport)
-Local
- Empty
-Customizing request
Transport request Transport request
-Transport Originals -Transport with change authorization(C type)
-Transport of Copies - Transport without change authorization (T type)
Task Correction/Repair
Tasks
- Development/Correction -Correction request
- Repair -Repair request
Change Request Transport
Object Category
-Repository
-Client Dependent customizing
-Client Independent customizing
IMG Tools -> Customizing
SE09 and SE10 transactions to use Only SE01
SE06 Setup workbench organizer SE06 Setup workbench organizer
The process of integrating objects moved using the CTS is called migration. Migration involves two aspects of the CTS’s functionality, namely the correction control system and a transport system. As objects are migrated from the development environment to the test environment (ideally) and finally into the production environment. The correction control system uses tasks to record changes in the development environment. The transport system uses change requests to move objects from development system to other systems. Using SAP’s correction and transport tools, table data such as configuration and application data, can be moved from one system to another and from one client to another client in any given system.
Once a SAP object has been changed, it is referred to as a "repair. SAP designed the system in such a way that all the changes for any SAP object are automatically recorded. Always the system generates the repair requests for you and after the repair is done to the object it is entered automatically to the repair editor by the repair process. After all the steps to the repair process is done you can release the repairs from the source SAP system database. Later in this chapter we will find more about repairs and how to release the change requests.
Please note that in this chapter the release 3.0 and higher terminology will be used to address the CTS. In the CTS process, after the objects are created or changed in the development environment, a task is assigned to those objects. To automatically generate the tasks in the system, the recording for the individual client should be on in T000 table. It has to be done manually by executing transaction SCC4 and changing the client attributes there as shown in chapter 9. Many objects can be assigned to a single task. It is always recommended to place all the related objects in one task. A change request consists of one task or number of tasks. After the task is released from the system, all the objects from the task get transferred to the change request editor. The second step is to release the change request and export all the objects to the data directory and cofiles directory of the system. The third step is to use the system level SAP command TP in the target system to move the object from one system to another or one client to another. The TP command is executed in the operating system level to import a change request to the target system. It is very important to remember that objects can be directly transported using change requests. When the change recording is not on for a client as we have seen in chapter 9 the change request screen does not pop up for the users automatically; so some times developers put their objects directly in the change request editor to transport objects.
Components of the R/3 CTS system:
The CTS system is actually made up of various components which allow for the movement of objects and help to maintain comparable and up-to-date changes from one system to the next. Here is a list of the components you may encounter while using the CTS to perform various tasks.
-Tasks, Change requests and Repairs
- Correction system or Workbench Organizer
- Transport System
- Development class
- Transport layer
- System types in the CTS pipeline.
- Repository objects
- Customizing objects
- Unix file systems in the transport process
- Important SAP delivery class and table types and tables in the CTS process
- Programs in the CTS process
- Version Management
- TP and R3trans program
Overview of Task, Change Request and Repair:
TASK: Corrections and repairs are recorded in tasks and transported using the change requests. It can control changes to internal components of the system that includes data dictionary objects, ABAP/4 programs, screens, CUA definitions, and documentation. The task can register and can keep the documentation of all the changes to the system objects. Once the objects are locked the system prevents parallel changes to the system objects. For existing objects, the system ensures that only a single original copy of each object exists. The previous version of an object can be restored and two versions of the objects can be compared. The CTS system asks for a change request number (if the recording is on in that client) whenever a customizing change is done or a new object is created with a development class other than $TMP (local object development class). A task is automatically created under a change request. User has to release the task first to release the change request. The user can be able to create or modify the object only after he or she opened a task. Opening a task registers the change with the system. Once the user releases a task, the objects in task get transferred to the change request.
After the unit testing in customizing master client is completed, a task is released to its change request. After a task is released, it can no longer be modified. If the user wants to modify the same objects, which were included in the released task, he has to create a new task. A task can not be deleted after it is released. The attributes also can not be changed. All the objects in the tasks should have a development class other then $TMP(local objects development class); otherwise those objects can not be transported.
A user needs to take the following steps to release a task:
Select a task
Press the release icon
Then the user is going to see a large editor for the documentation. Provide a good documentation about the task and save it.
Now the task will be released
Verify that the task is released by looking at the log for the task or if you refresh the SE09 or SE10 screen then the task can be found in released section of that screen.
Important Tips: A task can not be released if it is empty, user does not have the proper authorization, the objects are not locked properly and the objects are not locked in another task or change request. Some objects can be manually added to a task. When creating a change request and task, the user should create the right type of request (CUST or SYST). Changes to customizing objects belong to CUST and Changes to client independent and ABAP/4 development workbench belong to SYST category. If a task is already released then the objects of that task or change request can be easily added to the new one by selecting include template from file menu in SE01, SE09 or SE10.
Change Requests: After a task is released, the objects are moved to a change request. Using the change requests the sap objects get transported from one system to another. There are four categories of change requests: Transportable, Customizing, Local and Not assigned. Change requests containing SYST type changes and CUST type changes belong to transportable category. Only client dependant changes or CUST type changes belong to Customizing category. If the change request contains ‘Local Objects’, then it belongs to Local category. If the change request is created manually through Workbench Organizer and no repository object is assigned to it then that belongs to ‘Not assigned’ category.
After the task is released, if the task does not have a change request then a window pops asking for one as following:
User has to choose from either existing requests category or new request category. It is very important for the user to know that he should not select a change request that is already released. As we have seen before, in a development team usually the team leaders assign the tasks to the developers. After the work is done, developers release their tasks to the change request created by the team leader. To release the change request, select the request and then select the release button in the toolbar.
It is recommended that the users should describe the purpose and status of the development with every change request. This gives complete change documentation for all the developments and the changes made to the system. After the change requests are released, the new versions for those objects are created in the version database of the system. The cycle goes on for every change request created for every change made to the objects. The version database helps the user the compare the old version with the new version and restoring a particular version in case it is necessary.
Important tips: A transport can be created manually through SE01 and different types of objects can be directly added to the editor to get transported to the target system. Also a released change request or task can be included as a template in that transport.
Repairs: The way SAP System is designed, the users can only edit an original version of an object. So the user has to access the system, where the original of an object is located. In the other systems the users can only display the objects. Anytime the user wants to edit an object other than its original system; he has to create a repair for that object. When the repair is done to an object, the entire object is locked. As long as the repairs are not released, the objects in the repairs can not be overwritten by any other transports.
Repairs are displayed separately at the top of the correction and transport menu. User gets a warning if the repaired object in the target is being transported. If the original objects of SAP are changed then repairs are created, also if the original objects of development system are changed in staging or production systems then the repairs are created. To create a repair for SAP objects, those objects must be registered in OSS system and after the objects are registered the registration keys from the OSS system must be applied to the repaired system. The OSS is the online service system that is connected remotely with the customer system and it has the following features for the customers:
Problem and information database
SAP news
Up-to-date release, upgrade and installation information
Online assistance
Registration for SAP software change
Checking the transport logs:
Transport logs are written to common directory in operating system. The logs can be displayed within any SAP system in the CTS pipeline. To examine the log files using SE09 and SE10, select the change request and then Goto -> Action logs and Goto -> Transport logs. Action logs records and shows all the actions in the transport process. For example, export, test import and import. The transport logs keeps all the information about the log files generated by the transport process. A user can also display the logs from transaction SE01. After going to the display screen of a released transport, the user can press the log button to display the logs. The following four levels of information are available in the transport log.
Actions performed and the return code for those actions.
Additional error messages if any.
End-user log
Details for developers and other users.
Any level can be selected from the summery of a transport display.
In 45B version you can use the expand button to expand the transport log screen as following:
As we know already from the return code helps a user to know the status of the transport. A return code can be from 0 to12, 0 being the best and 12 being the worst. The following are the return codes and their meanings:
0 Transport was successful in export phase and import phase.
4 Warning messages are there. The objects in the change request are
transported, but there are some warnings the system wants the user to be aware of. For example if you want to transport some object deletions then the system will show you a warning.
8 Individual object could not be transported successfully. For example while using "tp import" command you might get a return code 8 if you are trying to transport user table data to the target system without transporting the table structure.
12 The system has generated a fetal error. The error is not generally caused by the transport, but it can be a database error.
13 Operating system terminated the transport .
Correction System or Workbench Organizer:
The correction system or workbench organizer uses tasks to record all the changes in the SAP system (The recording option for the client must be turned on if you want to record all the changes). The workbench organizer records and manages the changes to objects in the SAP system. There are different types of objects involved in the process. For example ABAP/4 dictionary objects, ABAP/4 programs, Screens, CUA definitions, documentation, Application defined transport commands and Customizing objects. The workbench organizer prevents parallel changes to the same object by ensuring that only one copy of each and every object exists within any particular system. If one developer changes the object then it locks the object for other users until it gets released from the system. The main objective of this is to manage the system in such a way that correction and development work can only be carried out on the original object in the original system. As a user you are only allowed to modify an object if you open a change request to record the changes. The workbench organizer gets activated for every change to the system automatically, then save all the changes to the objects in the original system on a version database that stores all the change versions of a object.
From release 3.0 onwards, The Workbench Organizer is completely integrated in the ABAP/4 development Workbench, which includes the customizing tools. A group of people can work on a project by adding tasks and change requests. Using the SAP security profiles and authorizations access to the functionality of Workbench Organizer can be controlled.
Authorizations for the CTS System
Using the required authorizations you can control the user access for creating, modifying, releasing or exporting the tasks or change requests. SAP provides all the predefined authorizations for Workbench Organizer (transaction SE09) and Customizing Organizer (transaction SE10) and Transport system (transaction SE01). Though the SAP provides essential CTS authorizations for a SAP project, still for further requirements you can define your own authorizations. In a SAP implementation project, different users play different roles. For example, a basis administrator should have all the authorization to configure and manage the CTS system, a functional team leader should have complete authorizations to Workbench Organizer (transaction SE09) and Customizing Organizer (transaction SE10) and functional user or developer at least should have authorizations to edit and release a task. The following profiles from SAP can be used for different areas of responsibility.CTS authorizations for a SAP project, still for further requirements you can define your own authorizations. In a SAP implementation project, different users play different roles. For example, a basis administrator should have all the authorization to configure and manage the CTS system, a functional team leader should have complete authorizations to Workbench Organizer (transaction SE09) and Customizing Organizer (transaction SE10) and functional user or developer at least should have authorizations to edit and release a task. The following profiles from SAP can be used for different areas of responsibility.
S_A.SYSTEM Basis System administrator (user gets All authorizations within the Workbench Organizer and the transport system)
The "S_A.SYSTEM" contains the authorization "S_CTS_ALL" that permits the user to execute all the transactions within the Workbench Organizer and the transport system. This authorization also allows the user to execute the enhanced transport tools (SE03 transaction or Goto->Tools in the Workbench Organizer) and the special function "Set System Change Options" (transaction SE06). We recommend assigning this profile and authorization to only basis administrators for security of the SAP system; so the authorizations for system change options remain in one group of users. If you are a 2.2 user then you must know that from release 3.0 you do not have to logon as DDIC to execute all the transactions Workbench Organizer and the transport system if you have "S_CTS_ALL". Any user can execute those special transactions (for example SE06)
If they have "S_CTS_ALL".
S_A.SHOW Display authorizations to all the basis components
The S_A.SHOW contains the authorization "S_CTS_SHOW" that permits the user to display transport logs, information about tasks and change requests.
S_A.CUSTOMIZ For Project leaders responsible for customizing
The "S_A.CUSTOMIZ " profile contains authorization "S_CTS_PROJEC" and this authorization allows a user to create, edit, and lock and release/export tasks and change requests.
S_A.DEVELOP for Developers in a SAP project
The "S_A.DEVELOP" profile contains authorization "S_CTS_DEVELO" and this authorization restricts the user to development work on tasks. The user can only release the task to a change request. The user is not allowed to change the owner of a task or release a change request.
The authorization object used in the Workbench Organizer and Transport System is called S_TRANSPRT. It consists of the fields Activity and Object in the Workbench Organizer/CTS. The following values are used:
S_TRANSPRT
Activity Description
01 Insert or generate
02 Change
03 Display
04 Print
05 Lock
06 Delete
30 Set up object list
43 Release
51 Initialize
60 Transport
61 Export
65 Reorganization
70 Management, administration
72 Create object lists
75 Release external requests
90 Change owner
Objects in Workbench Organizer/CTS
INIT SE06: Initialize Workbench Organizer and transport system
ORDR Change request
PATC Patches, Hot Packages
PIEC Object list
TASK Task (repair or correction)
TRAN Transport of copies
UPGR Upgrade/Installation
Change request management and Workbench organizer are very important tools used in customizing process of an R/3 system. To customize an R/3 system, first make any changes to the system environment required by specific customer needs. Since all changes that are made to the system are recorded in order to transport changes to another system, any changes you do make are kept consistent between systems. Average environment of SAP consists of three systems. For example: DEV for development, STG/TST/QAS for staging or testing and PRD/PR1 for production. The architecture of all SAP systems involved in the correction and transport process of a SAP implementation project is called a CTS pipeline or CTS landscape.
In a SAP recommended customizing process the following steps are followed:
1. The functional team leader creates a change requests and tasks under it. Then he/she assigns those tasks to the team members for customizing.
2. The team members perform the customizing work and all the changes to the objects are recorded to task/tasks.
3. The team members release the task or tasks manually to change request or change requests.
4. Finally the functional team leaders release the change request/requests and export the objects from the source system database to the operating system.
5. Then the Import process starts into the QAS/STAGE system and the appropriate testing is performed.
6. If the objects are functioning properly in a staging or QA environment, the same change request is moved to production environment. On the other hand if those objects are not functioning the way they are suppose to, then those objects will be fixed in DEV environment and go through the same cycle again.
The CTS pipeline and customizing:
The following is an example of a change request management process in a project where there are three clients in development environment (DEV). Client 100 for customizing and for development and client 300 for sandbox (this client is used as a playground). There will be a QAS environment having only one client 100. After all transports are tested properly in QAS environment, they would be transported to the Production (PRD) client 100 environment.
The customizing process in Client 100:
At the start of a customizing project, the project leader creates a change request and assigns the project team members to it. The customizing organizer then creates a task for each project team member. When the project team member performs a customizing transaction in the IMG, the settings are saved to the task in the change request. A task contains all the customizing settings that the projects team member made during the customizing project.
As project team members finish their project work, they release their tasks. The task objects are then passed to the change request. When all team members have released their tasks, the project team leader releases the change request. The change requests contain all the customizing efforts for the whole project.
The development process in Client 100 or configuration master client:
The development and customizing processes are very similar. A project leader is required to create one or more change requests for all project members and is responsible for the release of that change request for transport to the downstream system. The workbench organizer is responsible for all change requests containing client-independent objects, such as ABAP/4 programs, screens, menus, data dictionary changes and global setting. If a Repository object is created, it must be assigned to an appropriate development class.
In a change request, you can specify which team members’ work on the project. Every team member specified in a change request can access all the objects in the change request. Only project team members are allowed to maintain the objects in the change request. This prevents other users from unintentional changing of any objects.
Important Questions to ask yourself before following the Transport Procedures
- What time will transport take place daily.
- Who is responsible for a change request during the various phases of transporting? For example who will be creating the change requests? Who will release them after the development work is done? Who is going to keep the change request master list for a functional module.
- How will all transports be verified before being distributed and re-distributed? The verification process defined by the functional and basis group to make sure that all the objects of the change request goes through proper test in test system before moving forward in the CTS path.
- What if a transport is successful, but testing proves that the contents are incorrect? The change request should be checked properly before you release it. Sometime the developer uses same task or change request for different development objects; if the wrong objects are transported then you can not perform a good test in the target.
- Is notification sign-off required for transporting? If you get a notification signoff from the user who released the change request, then the objects for a particular configuration are being transported and all those objects should not be changed in the source system until it is tested properly in the target system.
- For example security profile changes will be effective for Client100 (master configuration client) so that only project team leaders will have authorization to create the transport/change request. The project team leads have responsibility as ‘gate keepers’ for the configuration. Following this procedure a SAP project will have two advantages: the control of all the change requests will be handled by one person in that module and every body will not try to configure their own by not talking to each other in the team.
Development Environment:
Enterprise and Project IMG is created and defined in client 300
Project team leader or customizing team leader creates initial IMG view for the projects within the customizing and development client 300.
Project team leader or customizing team leader creates a change request for every IMG view. (Therefore, an IMG view must be the highest unit of customizing activities that can be independently tested or transported.)
Customizing activities occur.
Customizing occurs in the configuration and development client 300.
Once the prototype hierarchy customizing has occurred, the master client (client 100) is created.
Automatic recording of all changes is established in the configuration and development master client 100.
When customizing is complete for a view, it is tested properly in client 300 before applying it manually to the master client 100.
If customizing changes are not up to the requirements after unit testing, they are completed in the configuration and development client 300.
Once unit testing is complete, the customizing is done manually and documented in master client 100; tasks are created for every customizing activity in a view and the project team leader or customizing team leader releases the transport.
Transports are released from the development master into the CTS buffer until the Quality Assurance System is established.
Quality Assurance System/ Test or QA system:
Quality Assurance System QAS is created.
Quality Assurance System is installed.
The CTS buffer contents are transported into the quality assurance test master client.
Any outstanding customizing activities are completed.
The 10-20% customizing that could not be completed in the first phase of transports needs to be completed. The customizing views are created in configuration and development client 300. After the customizing is complete in 100, before the test continues a client copy will be done to create a reset client 050 in DEV with all the customizing and no data. We recommend having a backup configuration master client (in this example client 050) that is a copy of just customizing data from client 100. In case something happens to Master configuration client 100 and configured objects gets corrupted, you can restore the configured objects from the backup client instead of restoring the whole database.
Then the test will continue with the data in client 100 and transported into QA test master client 100.
Validation testing takes place in the quality assurance test master client.
Any discrepancies or customizing changes are done in the configuration and development clients and transported into quality assurance test master.
Test master client is validated and signed off. By validating and signing off from the QAS system, you are ensuring that all the tests are conducted successfully without any error. The entire configuration is working according to the customer’s requirement.
After the signoff procedure is completed in QAS environment, it is time to create the production instance and applying the signed off change requests.
Important Tip: The project or customizing team leader creates a change request for each IMG view. When change requests are associated with an IMG view level, it is necessary that the change requests be created by assigning the IMG views to the appropriate team member or group. This enables the change requests to be integrated within project management and become an integral part of the process.
The following is procedure is very important for the customizing or development process:
1. Release a development change
2. Freeze development of the object(s) included in the change request
3. Import and verify the change in the quality assurance environment
4. Sign-off on the change
5. Release the development object(s) so that further development may be allowed
There are four different kinds of objects that can be transported in SAP environment.
1. Locally created in development environment objects such as tables, dynpros, screens, ABAP/4 programs, etc.
2. Objects originally came from SAP. (Changes to these objects are called repairs)
3. Table entries.
4. Scripts (Forms and layout sets)
To make the CTS process easy for the users, SAP uses workbench organizer and customizing organizer from release 3.0 onward. Later in the chapter we will learn more about workbench organizer and customizing organizer. The following is the complete process to transport objects from one system to another in CTS pipeline using workbench organizer and customizing organizer:
1. For the workbench organizer and customizing organizer to work properly, the CTS system should be initialized and configured first using transaction SE06 transaction. It is recommended to have a CTS pipeline design first before using SE06 transaction. If you know how your CTS pipeline is going to look like then it will be easy to chose the right option from the following screen. In this process all the systems are defined in TSYST table, the transport route is defined in TWSYS table and the recipient systems are defined in TASYS table. The SE06 initialization process goes through screen by screen to configure TASYS, TSYST and TWSYS tables.
2. Make sure that the RDDIMPDP program is scheduled as a background job in each client. RDDNEW PP program should be executed to start the RDDIMPDP in a client. It is recommended to schedule RDDIMPDP program as event driven.
3. Development class and Transport layers needs to be created
4. Customizing and development work starts in development system.
5. Task and Change requests are released from the system using SE09 or SE10 (SE01 can also be used, but not recommended from 3.X onward) and exported to the data file and cofiles of the system.
6. Make sure TP is working properly using different tools.
7. Logon to the Unix level or NT level and do the transport to target system. Going to /usr/sap/trans/bin in the UNIX level and use the tp command. Example: tp import devk902345 qas client U1.
8. If the TMS (Transport manageent system is available from 3.1H) system is available then use that tool for transporting the change request.
9. Check the return codes of the logs in SE10/SE09/SE01 or TMS to find out if the objects are transported properly.
Configuring the CTS system:
The CTS system or the Workbench Organizer (WBO) must be setup at least once using SE06 transaction.The above procedure can be done after the SAP instance is installed. It is recommended to know the CTS pipeline beforehand; when the user is doing CTS configuration using SE06. It is very important to know the roles of all the systems in the CTS pipeline. For a successful implementation of a SAP project, it is very important to design an appropriate CTS landscape. The user has to logon as DDIC in client 000 to configure the CTS system. The DDIC user needs S_CTS_ALL authorization to setup the workbench organizer using SE06.
Important tips: If the user gets a message in SE06 transaction to use the transport management system to do any changes to CTS configuration, then he/she should know that the Transport Management System (TMS) is already configured that system and all the changes to CTS system should be done there.
We will see more about the Transport Management System later in this chapter. User should know different system types before configuring the Workbench Organizer in SE06.
R/3 system types in a typical SAP environment: Integration (Development), Consolidation (Quality Assurance) and Delivery (Production)
In a SAP project the development work is done in the integration system. This system is the original owner of all the objects. The development system does not permit to transport originals to the consolidation system. After the customizing and development work is done, then the pre-defined change requests are released to the quality assurance or consolidation system. The development class of an object defines the integration and consolidation system for that object.
All the change requests are transported to the consolidation system using transport utility TP. Then all the changed objects are tested and verified in the consolidation system. This system is used as a staging area for the changed objects, so this system is also called staging system. The correction of original object is not allowed here; any change to the original objects is called a repair. SAP recommends doing the corrections only in the original system or in this case development system except some special scenarios.
After all the change requests are tested properly in the consolidation system, they get transported to the delivery or production system. In a CTS pipeline there can e multiple delivery or production systems.
To make the multiple delivery systems work properly in the CTS pipeline; they should be defined properly in the TASYS table and in Workbench organizer settings.
Figure 10.5
In the initial screen for setting up the Workbench Organizer SE06 as shown in figure 10.5 , the appears by default. The system picks up the exact sid name that was given to the SAP instance when it was installed. This name is very unique in the CTS pipeline. Also as shown in figure 10.5 the system status box there are two fields: R3 standard installation and Database copy or migration (in 45B system); there are three fields as: new installation, database copy and modified with workbench organizer in 3.1H version.
The first entry "New installation" can be used if it is a new installed system or the system was installed from SAP R/3 CDs using R3INST utility.
The second entry "Database copy" can be used if the system is database copy of another R/3 system.
For example, DEV system is installed first and then it was copied to TRN system for end user training. Now while doing the configuration for Workbench Organizer in TRN system, the user can use the entry "Database copy".
The third entry "Modified with the Workbench Organizer" is used when the Workbench Organizer is already been configured.
In the right hand side of the 3.1H SE06 transaction screen "System configuration" box is there. To chose the right entry from this box, the user should know how many systems are there in the CTS pipeline and what role each system will be playing. For example if there are three systems in the CTS pipeline and they are acting as develop, consolidation and delivery system then the user should chose "3 system group". It is very important for the user to know that the option that will be selected here can directly affect the TSYST, TASYS, TWSYS and DEVL tables.
The following are the options in system configuration box:
- Single system: This entry is selected if there is only one system in the CTS pipeline. This system will act as development, consolidation and delivery. Usually in very small implementation (training centers) this kind of system is found.
- Test and Production system: In this case the test system acts as integration and consolidation; the other system acts as a delivery system. The current system can be a test system or it can be a production system or delivery system.
- 3 system group: This entry is chosen if there are three systems in the CTS pipeline. Three of them are acting as development, consolidation and production system. This kind of implementation is very common in the SAP world.
- Any configuration: In this case user needs to enter the values in TSYST, TASYS and TWSYS tables. When the CTS pipeline is real complicated or user wants to configure the Workbench Organizer in his/her own way this entry is chosen.
By selecting the "create" button after the selection is done, user can start configuring the Workbench Organizer. The list of available systems is shown in the next screen and the user can enter other systems here. After each screen user should continue with the "continue" button until the whole process is done.
It is better to check TASYS, TSYST, DEVL and TWSYS tables to see if all the entries are defined correctly. The consolidation and delivery system name can be changed any time after the configuration is done, but the user has to release all the change requests from the system to do that.
Following are the tables used to setup the Workbench Organizer:
TSYST (figure 10.6): Table TSYST defines all the systems in the CTS pipeline. This table must be identical in all the systems in the CTS pipeline.
Figure 10.6
DEVL (figure 10.7): Table DEVL contains all the transport layers. As we have seen before a transport layer defines the transport path from the integration system to the consolidation system. DEVL also must be identical in all the systems in the pipeline.
Figure 10.7
TASYS (figure 10.8): This table defines all the systems in the CTS pipeline for which change request will be delivered automatically after the successful import into the consolidation system. Change requests other than those defined by the consolidation path can be made to the delivery system if the cross transports are allowed. This table must be identical in all the system in the CTS pipeline.
Figure 10.8
TWSYS (figure 10.9): This indicates the consolidation routes for the change requests. This table also must be identical in the CTS pipeline.
Figure 10.9
Define the appropriate system change option:
User can follow path SE06 -> System change option to set the system change option. There are four different change options and user can use each of this option in different systems and in different phase of the project.
Objects cannot be changed: This option does not allow creation or changes to the objects in ABAP/4 Development Workbench. This option is suitable for a production environment when the objective is not to allow any user to do any change to the system.
Only original objects: With this option only the SAP owned or system owned objects could be changed. For example when SAP specialists are working in the production environment and they want to change some system objects, this option can be chosen.
All customer objects: All objects not owned by SAP can be modified or repaired using the Workbench Organizer. This is the right option for a sand box system, where end users want to change their customizing or development objects. In this environment it is not secured to give the system object change access to the users.
All objects can be changed: This option allows changing any object in the system. With this option the system is totally open for any changes. All changes are made using the Workbench Organizer. This option is chosen generally in the development or sandbox environment.
Client Dependant and Client Independent objects
There are two kinds of SAP objects: client dependent and client independent. A SAP system can have several clients. Objects used in several clients are called client dependant objects such as ABAP/4 programs. Objects used in a specific client are called client dependant objects. In SAP system, a table can be client dependant or client independent. The best way to know whether a table is client dependant or not a user can open the table attributes in SE12 or SE11 transaction and look for a mandt field. If the mandt field is there in a table then that table is a client dependant table. MANDT implies the client name or number.
Workbench Organizer and Customizing Organizer:
The objectives of Workbench Organizer are logging of system changes with change management, organizing development objects, revision management and transport functionality. The change management is automatically activated. It registers all changes, maintains original copies and tracks the customization in each client. The Workbench Organizer records and controls changes to the following objects:
ABAP/4 dictionary objects, ABAP/4 programs, Screens, User interface definitions, Documentation, Application-defined transport objects and customizing objects.
The Workbench Organizer is automatically activated every time a user edits a repository object. The recording of the objects in the request ensures that all changes made in the ABAP/4 development workbench is customizing are registered. The Workbench Organizer is fully integrated into the ABAP/4 development workbench and the customizing tools. Using the above feature user can switch to the Workbench Organizer from all the transactions of customizing and ABAP/4 development workbench. The entire Workbench Organizer change requests and tasks can be found in transaction SE09 as we have seen before in figure 10.1.
The team leaders in a SAP project implementation divide the project work using the Workbench Organizer. Different change requests are created for different developers to record all the changes in the customizing and development process. The process of linking several users to enable to work in-group in a project is controlled by tasks, which belong to a common change request. Developments, Corrections and repairs are recorded in tasks a transported using change requests. First the team leader creates a change request for a particular group of developers or individual developer. The tasks under the change requests are assigned to different developers. A very important feature of Workbench Organizer is the transport type and the target system is automatically assigned and no longer need to be maintained by the user as 2.2 version. The change requests record all the changes made to development objects or customizing settings. The customizing objects and the ABAP/4 Development Workbench objects are recorded in separate requests. The tasks are released first by different developers that are assigned to them in the project and then the team leaders or the appropriate user release the change requests to export them to the common transport file system. In SE10 and SE09 transactions, the users can see the requests and task numbers with the short descriptions and user names. Authorizations are available to restrict the access of particular user groups to the functions of the Workbench Organizer. Once the objects are included in a change request, they are locked against all the development work. Only the users who created the change request can edit it. Other users are only allowed to display the objects in the request, until they have been released. Each development object is assigned to a development class that indicates the area that object belongs to. The objects of entire ABAP/4 Development Workbench are based on development classes.
Customizing Organizer in detail: the Customizing Organizer manages the customizing requests. The Workbench Organizer (SE09) only records the changes to SYST objects (ABAP/4 repository and customizing for all clients), the SAP R/3 system also provides Customizing Organizer transaction (SE10) that can used to record changes to both SYST and CUST (client specific customizing) objects. As we know already in release 3.0 and onward the Workbench Organizer, Customizing Organizer and the transport system also automatically record all changes to customizing settings. If the recording is on for the client in client maintenance process using T000 table, mainly customizing requests are generated. This ensures that the changes to customizing objects can be transported to target client with out affecting the other clients in the target. If the recording is not on for the source client then no guarantee can be given that the result of the transport can be restricted to one client in target system. If the transport contains client independent objects, then it is recommended from SAP to adjust the corresponding settings in the target client in order to assess the changes in all the clients. The figure 10.10 shows an example of client level settings.
Figure 10.10
Role of the client shows whether the client is development, test, demo, training, and customizing or production client.
Record Keeping can be set for each client separately. For example no change option does allow any users to change anything in the system.
Logon procedure lock by the flag is set in the target client while the client copy is going on. Only SAP* and DDIC users are allowed to logon at this time. Other users get the warning message about the client copy when they try to logon.
Client cascade lock is restricted to user DDIC to prevent a normal customer client from being damaged by an upgrade. In upgrade process many client specific tables are cascaded in all customer clients. For example in client 066 (early watch client) this setting is applied, because the client is not meant to use the normal SAP standard.
Execution of the CATT (Computer Aided Test Tool) procedure allows restarting test run repeatedly. This process changes the database contents, so user should know whether to declare this as property in the client or not.
In Customizing Organizer the configuration decides whether customizing requests will be transported or it is local. After the Customizing Organizer decides that the request will be transported, it finds out the destination of the change request. The customizing objects are not locked against the other users. They do not have any original system like ABAP/4 Development Workbench. Changes to the customizing settings can be recorded in a development/correction that is assigned to a change request or to a customizing request. In transaction SE10 we can see SYST category change requests and CUST category change requests. Most of the changes made to the customizing objects fall into CUST category. Client independent customizing and the development objects from the ABAP/4 Development Workbench fall in SYST category and are recorded in Workbench Organizer, but also we can see them in Customizing Organizer (SE10). The following figure 10.11 displays an example of Customizing Organizer.
Figure 10.11
Transport system:
Transport system is a complementary tool to the workbench organizer. The workbench organizer records all the changes in a SAP system and transport system transport all those changes to other SAP systems. The transport system is used to move objects from one SAP system to another SAP system in an orderly manner. The transport system uses the change requests to copy objects from a source system to the target system. The objects are transported in two steps:
1. All the objects from the source system database are exported to common transport directory.
2. The objects are imported to the target system database using a SAP UNIX command TP.
All the SAP systems in the CTS pipeline share a common transport directory /usr/sap/trans; that file system is mounted to all the other systems. All the R/3 systems in the CTS pipeline or landscape must have unique names or sid ids. For example development system can have a unique name DEV. In the case where objects at the source and target systems share a common name, the source system object as part of the transport overwrites the target system object. If a change request has been recorded for an object indicating that it is to be deleted, this task will be accomplished by the system after the transport is complete.
As we have seen earlier in this chapter in a development project, the team leaders define the change requests and the tasks first for all the team members. The team members start doing the customizing and development work and all the changes get recorded in the tasks. After the team members release all the tasks, the team leaders release the change requests. In the release process all the objects get exported to the common transport directory and the transport to the appropriate target system takes place at the Unix level or operating system level.
If the recording for a particular client is on then all the customizing table entries automatically get recorded in the workbench organizer. Users can also manually add the entries to the editor of the change requests and transport them from one system to another. A change request contains a list of objects to be transported, information on the purpose of the transport, the type of the transport that is taking place, one of two possible request categories (SYST or CUST) and the target system.
All the ABAP/4 repository and customizing for all the clients belong to SYST category while all client specific customizing belong to CUST category. Tasks and change requests from CUST category can only have CUST category objects; that is client specific. As SYST allows combination of objects the CUST category can be a part of SYST category. The tasks and requests of category SYST can have CUST category objects too. The CUST category is like a subclass of the SYST category.
In figure 10.12, we can see how the tasks and change requests are presented in a tree structure for a user in SE09.
Figure 10.12
Though from release 3.0 it is recommended to use SE09 or SE10 to perform all the CTS tasks, you can still create a transport request using transaction SE01 and add the objects to it as release 2.0. The user can go through the menu from Workbench Organizer to come to SE01 (The SE01 screen has changed from version 3.1 to 4.5 B). The path is Environment -> Transport system. To create a new transport request a user can click on create button. The user can use different transport types (K- Transportable change request, C- Transport of originals and T- Transport of copies) as described in transport types section of this chapter. In version 4.5B version, in se01 screen the user can chose transports of copies, relocations to create a T type transport or can display an individual change request.
Also the user can click on the create button to create a change request as shown in the following figure 10.13.
Figure 10.13
It is very important for the users to provide the right information for the transport. For example the target system from development system in a project is usually a staging or Quality Assurance (QA) system except some special cases.
In version 3.1 and below the C transport type is chosen if the user wants to move the original objects from source to target. That means the target system is going to be the owner of the objects after the transport. If transport is done to an integration or development system from a sandbox system the C transport type is chosen. K transport is chosen, if the target is test, consolidation, and delivery or production system.
The transport types and how they are used
K type: The system owner does not get changed with K type transport. This kind of transport is only allowed to consolidation and production system. After the K type of transport is done no correction is allowed to those objects. Any changes to K type transport objects in consolidation system are called repair.
The repairs can be done to those objects if the change option is selected in SE06 and change option is there in client level selection in T00 table. Generally K type transport is used for stage and production environment.
C type: With the C type transport the ownership of that object is also transferred to the target. After the transport is done, the target system is the owner of the transported objects. The objects will be originals of the target system. These kind of transports are generally done in a four tier architecture, where a bundle of development objects can go from the sandbox environment to development environment or development environment to integration environment and vice versa. SAP recommends doing these transports when the objects should move to another system for further development work.
T type: T type is called a transport of copy. The ownership of the object remains with the source; the target system just gets the copy of the objects. When a sap patch is applied to the development system and transported to other systems, those are perfect example of T type transports.
After the short description, target system and transport type is provided, now the user is ready to put the objects in the transport editor. When working with Workbench Organizer, the objects are automatically in the editor after the tasks are released. To go to the editor user can press the editor button on the toolbar. The system now will display a maintain object list window as shown in the following figure 10.14.
Figure 10.14
User can enter the objects in the editor by pressing the insert button on the tool bar. There are following five columns in the maintain object list screen:
PgmID Obj Obj. Name Funct. ObjStatus
R3TR TABU ZBAS K LOCKED
PgmID: This is used for an object type in the system. R3TR is a very important program ID used for table, data elements and domains. User can use F4 key to find all the possible entries.
Obj: This is used for the object type. For example TABL is used for the table structure, TABU for data, DOMA for the domain, TRAN for transaction. Using the F4 key can see all the object types available.
Obj. Name: This is the name used to identify the object within the system. If the object is a table then the table name is used here.
Funct: This field is normally grayed out but can be used if part of the table contents s need to be transported. Although some object types do not have an associated object function, for those that do, simply select the menu, then the function to access the Funct field.
The following are the possible entries for Funct field:
Normally: transport to the target system
D The object was deleted (only functions with deleted objects)
M Delete and recreate on the database
K Object keys according to entries in the key list. If you drill down on an object in the transport editor, all the table keys can be found.
K is the most used function type. Users generally see this kind of transport request. Most of the time some entries or keys are transported from the table using function type K. while doing the customizing, users can create a manual request and use this key to take the right entries or keys from the table.
Obj. Status: This is the object status field. This field is maintained by the system. The following are the possible entries for this field and each of this entry has different meaning to it.
ObjStatus Description
LOCKED Object locked
NOT_IMP Object not imported
ERR_IMP Error importing object
OK_IMP Object imported
OK_GEN Object imported and generated
A transport request should be protected using the path Request/task -> Request -> Protect, so that no other tasks can be assigned to the transport request. If the transport is protected, the objects in the transport object list get a LOCKED status and no other users can modify the objects in the list. The protection utility is very helpful for those developers who work on the same objects for a long period of time and not ready yet to release the transport. If the transport has a LOCKED status instead of LOCKEDALL status, then some of the objects in the request are not locked. The status of a transport can be DOCUMENT or RELEASED too.
When the status of a transport is RELEASED, that means the transport is already released from the system and incorporated into a target system. It also cannot be modified anymore. If the status is DOCUMENT, then the owner of the transport is still modifying the transport request. If the transport is a brand new transport and no objects are added yet to the transport; then the status of that transport will be DOCUMENT.
After the objects are placed in the maintain object list window without any error, it should be saved by clicking the save button. Now you are ready to release the transport by pressing the release button. After the transport is released the objects are no more locked and the transport can not be modified anymore. If the user wants to work on the same objects again then a new transport must be created. The release job exports the objects from the transport to the operating system. A data file and cofile is created for that transport. The SAP utility TP uses the cofile or a control file to do the transport to the target system. The release function also performs an import test in the target system to verify if the objects in the transport would overwrite originals. The user can disable this function by using "/testimport = no" parameter in TPPARAM file. Where would be the System IDentification tag created when the system is installed (e.g. DEV for the development system). The user should always check the system log after doing the transport to insure that the transport has proceeded as expected and that there have not been any errors. From the return code of the export, user can know whether the objects were released and exported successfully.
Development class:
A development class is a set of development environment objects that are mutually dependent upon one another. The development class binds a class of objects together. Those classes of objects must be developed and transported together. By basing the development work on development classes, a developer or customizing person can ensure that no required objects are missed. A developer can generate a list of the objects that belong to a class; then he/she can use this list as a command file in a change request. A development class also specifies the attributes that help to organize tasks and change requests. A development class specifies an integration and a consolidation system for the objects in the class. The development class can be defined in the TDEVC table. To create a development class use the menu path tools -> ABAP/4 Workbench and select the button