Chapter 13 W orkbench Organizer

Principles of organized software developm ent

- developm ent classes
- change requests and tasks
- originals
SAP system types
Integration of the W orkbench Organizer into the
ABAP/4 Developm ent W orkbench
Avoiding m odifications

SAP AG
Chapter 13 Objectives

Using the W orkbench Organizer to coordinate your

develoment projects
Distinguishing the different system types and their
purposes
Understanding the integration of the W orkbench
Organizers into the ABAP/4 Developm ent Workbench
and the transport system
Getting to know the problem s that occur during
m odifications and understanding the concepts
required to avoid these problems

SAP AG
 W BO and Transport System Objectives
SAP System SAP System

PROG PROG
ZZABCD00 Transport system ZZABCD00
Performing transports
Edit
Confirming transports

W orkbench Organizer
Organized software
developm ent with
- development class
- change request
- original concept

SAP AG

The Workbench Organizer supports organized software development.

The transport system performs and tracks transports.
 Managing Development Projects in the WBO

Project leader Change request

Project management
task
employee
Project level

in the WBO
task

employee task

employee

SAP AG BC400 / 13 - 1

At the start of a development project, the project leader creates a change request and assigns the
project team members to it. The Workbench Organizer assigns a project number (<sid>K9<nnnnn>,
e.g. C11K900001) to the change request.
The Workbench Organizer (WBO) also creates a task for each project team member. If a project team
member assigns a Repository object to the change request, the Repository object is entered in that
member’s task. The task thus contains all the Repository objects which a project team member is
processing in the development project.
As project team members finish their work in a development project, they release their tasks. The task
objects are then passed to the change request. When all project team members have released their
tasks, the project leader releases the change request. A change request thus contains all the Repository
objects which have been created or changed within a development project.
 Classification of Repository Objects

Create object

Assign object to
a development class

Assign object to
a change request

Automatic assignment
to a task

developer
SAP AG

When creating or changing a Repository object in the course of a development project, the developer
assigns the Repository object to a development class. Development classes combine together objects
of the same functional area. All objects of a development class have the same transport path. You
create development classes either with the Workbench Organizer or later in the ABAP/4 Development
Workbench.
There is a contact person responsible for each development class. Development classes allow a logical
division of Repository objects. In the ABAP/4 Development Workbench, they not act as a structural
aid and support access.
After assigning the development classes, the developer assigns the Repository object to a change
request. In contrast to the logical division of Repository objects, the change request is a project-related
division. The change request is locked for the duration of the modification and released upon
completion.
The WBO automatically assigns the task within the development project.
 Actions on Project Completion

Create object
development
Assign object to a
development class

Assign object to a
change request

Automatic assignment lock

Release
to a task task
Release change
request

im port
transport
directory
adm inistrator
SAP AG

When the development work has been completed, the developer releases the task. Although the
objects and the object locks pass from the task to the change request, any employee involved in the
request can change the objects. This is because the Workbench Organizer automatically creates a new
task if needed.
When the project has been completed, the project manager releases the change request. All the
locks on the objects of the change request are then also released.
Change requests can either be transportable or only for local use. The Workbench Organizer
determines this automatically from the development class. After release, only transportable change
requests are transferred to the transport system:
In the case of a test import, the system checks immediately after the export whether all the objects
can be imported into the target system.
The Repository objects are exported to the central transport directory.
The success (or otherwise) of the export and test import is recorded in the transport log of a change
request and checked by the developer.
The import into the target system does not happen automatically, but is triggered by the system
administrator who executes the transport control program tp at operating system level. The developer
then checks the import logs at the end.
 Functions of a Change Request

m anage
versions
facilitate Assign to Versions
team work
team member

Change request

complete
no unauthorized Lock Documentation change
docum entation
access to
Repository objects

SAP AG

In a change request, you determine which developers are to work on a project. Project members are
authorized to access all objects of the change request. The Workbench Organizer thus enables project
members to work in a team.
Since only project members are authorized to edit the objects of a change request, unauthorized access
is avoided.
In the change request documentation, you describe the impetus for a development project and its
status. This documentation contains a complete description of the change and thus allows you to track
all new developments of and changes to Repository objects.
When you release a change request, a complete version for all objects is stored in the version database.
If you edit a Repository object again later, the current version becomes the complete copy and the
difference between the old version and the new version is stored in the version database. Displaying
and comparing versions allows you to determine the status of a version. You can restore old versions.
 Local Objects

$TMP

local
local object
object

SAP AG

Instead of assigning a customer development class to an object, you can flag them for local use only.
Local objects are not controlled by the Workbench Organizer and the transport system.
Since local objects are created and changed without being assigned to a change request, no versions
exist and they cannot be transported.
The development class for local objects is $TMP.
You can assign a local object to another development class at a later stage.
 Deleting Repository Objects

task
task

change
change
request
request

SAP AG

You delete objects with normal change requests.

Non-existent objects are detected during export and are also deleted in the target system.
During export, the TADIR entries are deleted.
 Originals and Copies

Copy
Copy
Original
Original
PROG PROG
ZSCUST01 ZSCUST01
task

change request

SAP AG

When creating Repository objects, the Workbench Organizer automatically notes the system. The
Repository object is considered as the original object in an R/3 System.
An object is original only in one system. All other systems contain copies of the original objects.
The original system concept is meant to ensure that changes to Repository objects are only possible in
the integration system. Since you create objects in the integration system, all the originals are in this
system. There is thus one central location for changing Repository objects.
When you transport a Repository object to a consolidation system, it exists there as a copy. Although
changes to copies can be made in exceptional cases, you are recommended to change the original in
the integration system and then transport it to other systems. By doing this, you avoid inconsistencies
in different development versions.
Transports never overwrite original objects.
 SAP Objects as Copies

Original
Original Copy
Copy
PROG
ZSCUST01 PROG
task ZSCUST01

change request

Copy Copy
Copy
Copy

PROG PROG
SAPABAP SAPABAP

change request

SAP AG

In all customer systems, SAP objects are copies.

 Task Attributes

original copy

PROG PROG
development/ ZSCUST01 repair ZSCUST01
correction task

change request

copy copy

repair repair
PROG PROG
SAPABAP SAPABAP

SAP AG

The Workbench Organizer detects automatically whether you are changing the original or a copy.
Depending on the attribute of an object , the Workbench Organizer assigns the task attributes
Development/correction or Repair.
The task attribute Development/correction is assigned if you are creating an object or changing the
original, but the task attribute Repair applies if you are changing a copy.
 Changes to Customer Copies

repaired
repaired
original
original copy
copy
Transport not possible: Repair

new
new original
original new
new copy
copy
Change
Change the
the original
original and
and transport
transport
SAP AG

If you need to change a customer copy urgently, you can perform a repair. During the repair, the
repaired object cannot be overwritten by imports.
You make repairs to customer copies only if you cannot use a later transport to solve the problem.
If you do repair customer copies, you have to make the same changes in the original system and
confirm the repair.
 Changes to SAP Copies (Modifications)

repaired
repaired copy
copy copy
copy

Change standard functionality

copy copy
copy
modification
modification copy

Transport
Transport modifications
modifications
upgrade upgrade
SAP AG

Changes made to SAP copies are considered to be modifications. Modifications are also repairs.
However, modifications pose far more problems than repairs to customer objects because customers
are not in a position to update the originals in the SAP development systems.
If you import a new version of an SAP object into your customer system in the context of an upgrade,
you must adjust your repaired SAP object to the new SAP object.
 Change Levels

Custmer Enhance- Customizing

develop- ments
ments

Cust. ABAP/4 R/3 business

program modifications
DW applications
(SAP standard)

R/3 Basis

System Software

SAP AG

There are four types of SAP System adjustments for satisfying customer requirements:
Customizing: This involves setting system parameters using your a special interface. Changes are
thus scheduled and organized in advance. Customizing is mandatory before using the system in a
live environment.
Modifications: Modifications are customer-specific changes to SAP Repository objects. When SAP
objects are changed, the customer version has to be modified to match the new SAP version.
Enhancements: These are customer changes to SAP Repository objects without modifications.
Customer developments: Customer-specific objects according to the usual conventions.
 Enhancement Concept

Enhancements
Program enhancem ent
- program exits
Cust. ABAP/4 R/3 business - menu exits
program DW applications - screen exits
(SAP standard) - field exits
Dictionary
enhancement
R/3 Basis - table appends
- CI includes
Text enhancement
System software - docum entation
- key words

SAP AG

When you make enhancements to SAP software, you avoid the conventional modification process.
In this case, SAP application programmers have to pre-define program, menu exits and screen exits as
well as CI includes.
The customer can use any of the following options:
Program exit: This exit is pre-defined by the SAP application programmer and allows the
customer’s programmer to add additional sections of code.
Menu exit: This exit is predefined by the SAP application programmer and allows the customer’s
programmer to add customer-specific menu options to SAP menus.
Screen exit: This exit is predefined by the SAP application programmer and allows the customer’s
programmer to define a customer-specific subscreen.
Field exit: This involves branching from a screen field with a data element reference in a function
module. These branches can apply either globally (across screens and module pools) or locally (for
a specific screen or module pool).
 Registering Developers in SSCR
O bject Browser: Program SAPABAP
Dev. Object Edit Goto Utilities Settings Environm ent

Customer
Program ZABAP
system
Add Developer

You are not registered as a developer.

Please register in R/3 OSS. When
registering in OSS, you will get an
access key.

Developer Registration

SAP OSS User THIERM

Key 07319180563617100772

SAP AG

A developer must request a key in the OSS to get registered. The request is triggered when you create
or changes a Repository object for the first time. The OSS assigns the key depending on the customer
number and the user name.
To register as a developer, proceed as follows:
Log onto the OSS. If you do not have a user name for the OSS, contact a colleague who already has
an OSS user name. This person can register you in the OSS.
Choose Reg. developm. The system then displays the Installation type dialog box. Choose Customer
installation and then Continue.
In the External Installation Number dialog box, enter the installation number and choose Continue.
To find out the installation number, choose System -> Status. Choose the desired installation
number by double-clicking on the relevant line.
In the Contact Persons dialog box, choose the desired name.
In the External Installation Number dialog box, choose Continue.
In the Developer Registration dialog box, enter your user name and choose Register.
The system then displays a 20-digit developer key. Copy the key using the Cut and Paste function or
enter the key manually in the R/3 System when requested.
Chapter 13 Summary

At the start of a development project, the project leader

creates a change request.
Each member of the project team is assigned a task and
releases it when work on the objects is complete.
W hen a project has been completed, the project leader
releases the change request and triggers the automatic
export process. Imports are performed at operating
system level by the system adm inistrator.
An object is the original in the system in which it was
created. W hen making changes to customer objects, you
should always change the original.
SAP delivers all objects as copies. You should not make
changes to SAP objects (modifications), since they then
have to be modified on release upgrade.

SAP AG BC400 / 13 - 1
Exercise Chapter 13: Workbench Organizer

1. Name of your report: ZBCA#19#M1

Name of your development class: ZY##
##: Group number

Task:
Create development class ZY## which should belong to the
transport layer ZDEV. Assign a new change request to your
development class.
Allow the group next to you to modify your development class.
All other groups should not be authorized to change the
development class and should also not be unable to append
objects to your change request.
Write the report ZBCA##M1 and assign it to your development
class ZY## and the change request of the group next to you.
The report should output 'Transports are fun'.
Release the task in the change request of the group next to
you.
Release the task in your own change request and your own
change request. Check the action and transport log.
Solution Chapter 13: Workbench Organizer
• Go into Transaction SE80, enter the development class
ZY20#, Display, confirm dialog box, enter short description
and transport layer, Save.
• Create request, maintain short description, add group next to
you as team member, choose Enter, Back.
• Go into Transaction SE09, display own requests,
Request/task => Request => Protect.
• Write report as before, enter your own development class
and change request of the group next to you.
• Go into Transaction SE09, display your own requests.
Double-click on change request of the group next to you.
Click and release your own task.
• Double-click on your own request, click and release your
own task. Release your own request when the group next to
you has released its own task.
• Click on your own request, Goto => Logs => Action log
and/or Goto => Logs => Transport log.