MBC40 - Managing ABAP Development Projects

MBC40 Management von ABAP-
Entwicklungsprojekten
Managing ABAP
Development Projects
MBC40
R/3
R/3 Release
Release 4.6C
4.6C 50039104
50039104
© SAP AG 1999
Jul-27-2000
Copyright
Copyright 2000 SAP AG. All rights reserved.

Neither this training manual nor any part thereof may
be copied or reproduced in any form or by any means,
or translated into another language, without the prior
consent of SAP AG. The information contained in this
document is subject to change and supplement without prior
notice.
All rights reserved.
© SAP AG 1999
Trademarks:
Microsoft ®, Windows ®, NT ®, PowerPoint ®, WinWord ®, Excel ®, Project ®, SQL-Server ®, Multimedia Viewer ®,
Video for Windows ®, Internet Explorer ®, NetShow ®, and HTML Help ® are registered trademarks of Microsoft
Corporation.
Lotus ScreenCam ® is a registered trademark of Lotus Development Corporation.
Vivo ® and VivoActive ® are registered trademarks of RealNetworks, Inc.
ARIS Toolset ® is a registered Trademark of IDS Prof. Scheer GmbH, Saarbrücken
Adobe ® and Acrobat ® are registered trademarks of Adobe Systems Inc.
TouchSend Index ® is a registered trademark of TouchSend Corporation.
Visio ® is a registered trademark of Visio Corporation.
IBM ®, OS/2 ®, DB2/6000 ® and AIX ® are a registered trademark of IBM Corporation.
Indeo ® is a registered trademark of Intel Corporation.
Netscape Navigator ®, and Netscape Communicator ® are registered trademarks of Netscape Communications, Inc.
OSF/Motif ® is a registered trademark of Open Software Foundation.
ORACLE ® is a registered trademark of ORACLE Corporation, California, USA.
INFORMIX ®-OnLine for SAP is a registered trademark of Informix Software Incorporated.
UNIX ® and X/Open ® are registered trademarks of SCO Santa Cruz Operation.
ADABAS ® is a registered trademark of Software AG
The following are trademarks or registered trademarks of SAP AG; ABAP/4, InterSAP, RIVA, R/2, R/3, R/3 Retail, SAP
(Word), SAPaccess, SAPfile, SAPfind, SAPmail, SAPoffice, SAPscript, SAPtime, SAPtronic, SAP-EDI, SAP EarlyWatch,
SAP ArchiveLink, SAP Business Workflow, and ALE/WEB. The SAP logo and all other SAP products, services, logos, or
brand names included herein are also trademarks or registered trademarks of SAP AG.
Other products, services, logos, or brand names included herein are trademarks or registered trademarks of their respective
owners.
(C) SAP AG MBC40 ii

SAP Basis Administration Training 4.6
Core Competence Expert Competence

BC505 3 days
Database
MBC30 2 days Administration Oracle
R/3-Technical
Implementation and BC511 5 days
Operation Management Database
Administration Informix
BC305 3 days BC515 2 days
BCtcc* 5 days Database
Technical Core Advanced R/3 Administration SAP DB
Competence System Administration
BC520 3 days
BC315 3 days Database Administration
BC325 3 days MS SQL Server
Software Logistics Workload Analysis BC525 3 days
Database Administration
MY301 2 days BC350** 3 days DB2/400
Workplace TCC Workplace BC530 5 days
Database Administration
*Technical Core Competence Versions DB2/390
BC310 Windows NT / Oracle BC535 3 days
BC312 Windows NT / SAP DB Database Administration
BC314 Windows NT MS SQL Server DB2 UDB
BC317 (Windows NT / UNIX) / DB2
BC360 UNIX / Oracle BC555 2 days
BC361 UNIX / Informix
BC362 UNIX / SAP DB LiveCache Administration
BC370 IBM AS400
Corresponding R/3 Basis Database
BC390 IBM /390
Knowledge Product and/or
**BC350 Workplace (combined with MY301)
SAP Expert Knowledge Book
Administration Training
© SAP AG 1999
(C) SAP AG MBC40 iii

ABAP Workbench
Level 2 Level 3
BC402 3 days BC414 2 days BC490 3 days
ABAP Programming Programming ABAP Performance
Techniques Database Updates Tuning
ABAP Objects: Object-
Oriented Programming Communication
in R/3 Interfaces in ABAP
Techniques of List Enhancements
Processing and SAP Query and Modifications
Programming Dialog Programming
BC400 5 days User Dialogs using EnjoySAP Controls
ABAP Workbench: BC420 5 days BC440 5 days
Concepts and Tools Data Transfer Developing
BC430 2 days Internet Applications
MBC40 2 days ABAP Dictionary
Managing ABAP Recommended supplementary
BC460 3 days courses are:
Development Projects
SAPscript: Forms Design Business Process Technologies
and Text Management CA925, CA926, CA927
CA610 2 days BC095 (Business Integration
Technology)
CATT:Test Workbench and BC619 (ALE), BC620, BC621
Computer Aided Test Tool
© SAP AG 1999
(C) SAP AG MBC40 iv

Management
Management Management
MBC30 2 days MEC010 1 day
R/3 Technical SAP Electronic
Implementation and Commerce
Operation Management
MBC40 2 days ML020 2 days
Managing ABAP Integration of Sales
Development Projects and Distribution
© SAP AG 1999
(C) SAP AG MBC40 v

SAP’s Knowledge Transfer Model
SAP Basis Administration Training 4.6
Core Competence Expert Competence

MBC30 2 days B C505 3 days
R/3-Techni cal D atabase Adm inis trati on
Impl ementation and ORA CLE
Ope rati on Management
B C515 2 days
B Ctcc * 5 days B C305 3 day s D atabase Adm inis trati on
Advanced R/3 SA P DB
Technical Training and

Technical C ore
C ompetence System Administration
B C520 3 days
Empowering Workshops - Application and Cr oss
D atabase Adm inis trati on
B C325 3 days M S S QL S erv er
Application
Software Logi stics
D B2
Empowering Workshops
B C535 3 days
D atabase Adm inis trati on
UDB Workshops Expert Knowledge
EW A10 (SD ) 2 days EWA12 ( PP) 2 days
EWA18 (CO) 2 days IBU sp ecific
http://sapnet.sap.com/EducationServices
Book Series
Technical Optimizatio n Tec hnica l Optimization and Global
o f Pr icing Technical Optimizat ion
*Technical Core Competence Versions o f Bac kflushing of of Pr ofitab ility Analysis W orkshops
EW A11 (SD ) 2 days Produ ction Ord ers
Technical
BC310 Win dows Optimizatio n
NT / Oracle EWA20 ( PP) 2 days
of Due List Proc essing
BC314 Win dows NT M S
including SQL Server
Scheduling Tec hnica l Optimization
BC317 (Window s NT / UNIX) / DB2 o f MRP Ru n and
BC360 UNI EW A13 (SD )
X / Oracle 2 days Long T erm Plann ing
Technical
/ SAP DBOptimizatio n
Cor resp ond ing R/3 Basis
http://sapnet.sap.com/Books
BC362 UNI X EWC13 (PP/CO ) 2 days
of Batch Determinatio n Kno wledge Pro duct
EWC10 ( SD/PP) 2 days Technical Optimizat ion
© SAP AG
EW1999
A14filen(SD)
ame ( author) /2
2 days of Calc ulatio n of
Tec hnica l Optimization Production Orders
Technical Optimizatio n of th e Av ailab ility Check
o f Credit M anag eme nt
EW A15 (SD) 1 day EWC 11 (SD/PP) 2 days
Technical Optimizatio n Tech nica l Opt imization
o f Tex t Det ermination of Co nfigu ration
of Variants
EW A16 (SD) 1 day
Technical Optimizatio n
o f Produc t Selection
EWC 16 (SD) 2 days
EW A17 (SD) 1 day Tec hnica l Optimization
Technical Optimizatio n Shipping and
of Partner Determinat ion Ware hous e Manag ement
© SAP AG KTM mySAP .com f or Tec hn. Impl., IT Cons., Sys. Integration UH / 7
SAP GoingLive Check http://sapnet.sap.com/GoingLiveCheck
SAP EarlyWatch Service http://sapnet.sap.com/EarlyWatch
SAP EarlyWatchAlert http://sapnet.sap.com/EWA
SAP Consulting Services http://sapnet.sap.com/ConsultingServices

http://sapnet.sap.com/BasisKnProd
TeamSAP Support http://sapnet.sap.com/TeamSAPsupport
Knowledge
Empowering Workshops http://sapnet.sap.com/EmpoweringWorkshops Products
Technical
Certification
http://sapnet.sap.com/pa
http://sapnet.sap.com/TechNet
© SAP AG 1999
(C) SAP AG MBC40 vi

Contents
Course Overview................................................................................................................................................... 1
Requirements, Target Group, Duration............................................................................................................. 2
Course Objectives ............................................................................................................................................. 3
Contents ............................................................................................................................................................ 4
Change Levels....................................................................................................................................................... 5
Change Levels................................................................................................................................................... 6
Change Levels................................................................................................................................................... 7
ASAP ................................................................................................................................................................ 8
Personalization .................................................................................................................................................. 9
Personalization ................................................................................................................................................ 10
Workplace ....................................................................................................................................................... 11
ABAP Workbench .......................................................................................................................................... 12
ABAP Programming is Designed for:............................................................................................................. 13
ABAP Workbench Change Levels.................................................................................................................. 14
Change Levels: A Comparison ....................................................................................................................... 15
Implementing Development Projects .............................................................................................................. 16
Modifying Versus Copying............................................................................................................................. 17
ABAP Development Projects - Evaluation ..................................................................................................... 18
The Amount of Work at Upgrade Increases ................................................................................................... 19
Modifications: Critical Repository Object Types............................................................................................ 20
Summary ......................................................................................................................................................... 21
Change Levels: Exercise ................................................................................................................................. 22
ABAP Development Projects and ASAP............................................................................................................ 23
ABAP Development Projects and ASAP........................................................................................................ 24
ASAP as a Part of TeamSAP .......................................................................................................................... 25
ASAP Includes ............................................................................................................................................... 26
ABAP Development Projects in ASAP........................................................................................................... 27
Tools and ASAP.............................................................................................................................................. 28
Summary ......................................................................................................................................................... 29
Project Team ....................................................................................................................................................... 30
Project Team ................................................................................................................................................... 31
Position on the ASAP Roadmap ..................................................................................................................... 32
Roles in Customer Development Projects (1) ................................................................................................. 33
Who Decides if Development is Necessary? .................................................................................................. 38
Integration of Employees into the Project Team (1) ....................................................................................... 39
Integration of Employees into the Project Team (2) ....................................................................................... 40
Registering a Developer in SSCR ................................................................................................................... 41
On-Site Consulting.......................................................................................................................................... 42
Levels of On-Site Consulting: ABAP Workbench.......................................................................................... 43
SAP R/3 Consulting Services.......................................................................................................................... 44
SAP R/3 Education Services: ABAP Workbench........................................................................................... 45
Summary ......................................................................................................................................................... 46
Software Logistics............................................................................................................................................... 47
Software Logistics........................................................................................................................................... 48
Software Logistics: Overview......................................................................................................................... 50
Planning the System Landscape for Development.......................................................................................... 51
Setting up the System Landscape.................................................................................................................... 52
Maintaining the System Landscape................................................................................................................. 53
Centralized and Decentralized Development .................................................................................................. 54
Workbench Organizer and the Transport System ........................................................................................... 55
Software Logistics: Overview......................................................................................................................... 56
Managing Development Projects in the WBO ................................................................................................ 57
Logical and Temporary Designation............................................................................................................... 58
Completing a Project....................................................................................................................................... 59
Functions of a Change Request....................................................................................................................... 60
Sizing Change Requests.................................................................................................................................. 61
(C) SAP AG MBC40 vii

Originals and Copies ....................................................................................................................................... 62
Task Attributes................................................................................................................................................ 63
Changing Customer Copies............................................................................................................................. 64
Changing SAP Copies (Modifications)........................................................................................................... 65
Registering Modifications in SSCR ................................................................................................................ 66
Critical Success Factors: Software Logistics (1)............................................................................................. 67
Critical Success Factors: Software Logistics (2)............................................................................................. 68
Summary (1) ................................................................................................................................................... 69
Summary (2) ................................................................................................................................................... 70
Standardization ................................................................................................................................................... 71
Standardization................................................................................................................................................ 72
Standardization Areas ..................................................................................................................................... 74
Naming Conventions for Repository Objects ................................................................................................. 75
Application Hierarchy and Development Classes........................................................................................... 76
Interface Style Guide....................................................................................................................................... 77
Documentation ................................................................................................................................................ 78
Inline Documentation...................................................................................................................................... 79
Critical Factors for Successful Modification (1) ............................................................................................. 80
Critical Factors for Successful Modification (2) ............................................................................................. 81
Inline Modification Documentation ................................................................................................................ 82
Modification Logbook .................................................................................................................................... 83
Summary ......................................................................................................................................................... 84
Standardization: Exercise................................................................................................................................ 85
Process Design and Technical Design ................................................................................................................ 86
Process Design and Technical Design ............................................................................................................ 87
Business Blueprint: Process & Technical Design ........................................................................................... 89
Process Design: Contents................................................................................................................................ 90
Process Design: Objectives ............................................................................................................................. 91
Producing the Process Design (Template 1) ................................................................................................... 92
Producing the Process Design (Template 2) ................................................................................................... 93
Example: Process Requirement in SD ............................................................................................................ 94
Technical Design: Contents ............................................................................................................................ 95
Technical Design: Objectives.......................................................................................................................... 96
Producing the Technical Design (Template 1)................................................................................................ 97
Producing the Technical Design (Template 2)................................................................................................ 98
Example: Technical Considerations for SD Order.......................................................................................... 99
Critical Factors for Process & Technical Analysis........................................................................................ 100
Process Design Review ................................................................................................................................. 101
Technical Design Review ............................................................................................................................. 102
Summary ....................................................................................................................................................... 103
Process Design and Technical Design: Exercise........................................................................................... 104
Implementation ................................................................................................................................................. 117
Implementation ............................................................................................................................................. 118
Position on the ASAP Roadmap ................................................................................................................... 119
Putting the Data Model into Practice ............................................................................................................ 120
ABAP Dictionary.......................................................................................................................................... 121
Example SD: Appending to Table VBAK & VBRP..................................................................................... 122
Critical Success Factors: Data Model/Dictionary ......................................................................................... 123
Putting the Process Model into Practice........................................................................................................ 124
Data Structure (Language and Dictionary) ................................................................................................... 125
ABAP Keywords........................................................................................................................................... 126
Modularization .............................................................................................................................................. 127
Using ABAP Objects for Customers............................................................................................................. 128
Critical Success Factors: Implementation (1) ............................................................................................... 129
Critical Success Factors: Implementation (2) ............................................................................................... 130
Writing to the Database................................................................................................................................. 131
SAP LUW ..................................................................................................................................................... 132
Container for a Process Step: Screen ............................................................................................................ 133
Example: New Field For Orders, Additional Data B .................................................................................... 134
Critical Success Factors: Writing to the Database ........................................................................................ 135
Reading and Displaying Data........................................................................................................................ 136
Reading and Displaying Data........................................................................................................................ 137
(C) SAP AG MBC40 viii

Difference between Queries and Programs ................................................................................................... 138
Reading and Displaying VBRP Append ....................................................................................................... 139
Critical Success Factors: Reading ................................................................................................................. 140
Enjoy Controls .............................................................................................................................................. 141
ABAP and Front End Presentation................................................................................................................ 142
Choosing a Web Programming Model.......................................................................................................... 143
Characteristics of Transactions ..................................................................................................................... 144
Critical Success Factors: Front End Presentation.......................................................................................... 145
Data Transfer................................................................................................................................................. 146
Communication vs. File Transfer & Data Transfer....................................................................................... 147
Critical Success Factors: Communication..................................................................................................... 148
Data Transfer: Legacy System Migration ..................................................................................................... 149
LSM Workbench........................................................................................................................................... 150
Critical Success Factors: Data Transfer ........................................................................................................ 151
Documentation and Translation .................................................................................................................... 152
Example: Docu. for Data Element ZZADVFLAG........................................................................................ 153
Translation .................................................................................................................................................... 154
Critical Success Factors: Translation ............................................................................................................ 155
Summary: Workbench Tools ........................................................................................................................ 156
Summary ....................................................................................................................................................... 157
Quality Assurance ............................................................................................................................................. 158
Quality Assurance ......................................................................................................................................... 159
Position on the ASAP Roadmap ................................................................................................................... 160
Program Analysis.......................................................................................................................................... 161
Manual Program Analysis (Source Code Review)........................................................................................ 162
Program Analysis Using Tools ..................................................................................................................... 163
Test Organization and Test Workbench........................................................................................................ 164
Roles in Quality Assurance........................................................................................................................... 165
Role Representation in the Test Workbench................................................................................................. 166
Test Organization.......................................................................................................................................... 167
Computer Aided Test Tool (CATT).............................................................................................................. 168
Test Workbench: Status Analysis ................................................................................................................. 169
Test Types..................................................................................................................................................... 170
Status Report and Handover.......................................................................................................................... 171
Status Report ................................................................................................................................................. 172
Status Report (Template) .............................................................................................................................. 173
Summary ....................................................................................................................................................... 174
Maintenance...................................................................................................................................................... 175
Maintenance .................................................................................................................................................. 176
Maintenance .................................................................................................................................................. 177
Development Cycle, Code Freeze, Versions................................................................................................. 178
Different Releases: First Development Cycle ............................................................................................... 179
Different Releases: Database Copy and Upgrade ......................................................................................... 180
Different Releases: Second Cycle ................................................................................................................. 181
Different Releases: Upgrade PRD................................................................................................................. 182
Repository Objects Sensitive to Upgrades .................................................................................................... 183
Avoiding Adjustment .................................................................................................................................... 184
Monitoring: Technical System Operation (1) ............................................................................................... 185
Monitoring: Technical System Operation (2) ............................................................................................... 186
Monitoring Production: Process Operation................................................................................................... 187
Critical Success Factors: Production Operation ............................................................................................ 188
Internal Services: Structure ........................................................................................................................... 189
Summary ....................................................................................................................................................... 190
Conclusion ........................................................................................................................................................ 191
Conclusion .................................................................................................................................................... 192
10 Golden Rules for Development Projects .................................................................................................. 193
10 Golden Rules for Development Projects .................................................................................................. 194
(C) SAP AG MBC40 ix

Course Overview
© SAP AG 1999
(C) SAP AG MBC40 1

Requirements, Target Group, Duration
Requirements:
SAP50 - Basis Technology
Target Group:
Managers of ABAP development projects
Duration: 2 days
© SAP AG 1999
(C) SAP AG MBC40 2

Course Objectives
This course will enable you to:

handle the management tasks to be performed in an ABAP
development project
understand the critical success factors to be considered in
the individual phases of an ABAP development project
© SAP AG 1999
(C) SAP AG MBC40 3

Contents
Course Overview
Unit 1 Change Levels Unit 6 Process and Design

Concept
Unit 2 ASAP
Unit 7 Implementation
Unit 3 Project Team
Unit 8 Quality Assurance
Unit 4 Software Logistics
Unit 9 Maintenance
Unit 5 Standardization
Summary
© SAP AG 1999
(C) SAP AG MBC40 4

Change Levels
6 Process Design and

1 Change Levels
Technical Design
2 ASAP 7 Implementation
3 Project Team 8 Quality Assurance
4 Software Logistics 9 Maintenance
5 Standardization
© SAP AG 1999
(C) SAP AG MBC40 5

Change Levels
Contents:
Change levels
Development project evaluation
Objectives:
At the end of this unit, you will be able to
Explain at which levels you can change the SAP standard
Evaluate change levels
© SAP AG 1999
(C) SAP AG MBC40 6

Change Levels
R/3 business
applications Customer
(SAP standard) programs
Customizing Personalization Modification Enhancement Customer

development
Business ABAP
Engineer Workbench
40
BC
M
© SAP AG 1999
You can tailor the R/3 System to your needs in the following ways:
Customizing: Setting business processes and functions according to an implementation guide.
Possible changes have been anticipated and organized in advance.
Personalization: Changes to the global display characteristics of fields (pre-determining some
input values, removing other input fields from certain screens), user specific menu sequences.
Modification: Customer changes to SAP repository objects. When changes are made by SAP,
customer versions must be adjusted to conform to the new SAP version. Up to Release 4.0B, these
technical adjustments are made manually using upgrade utilities. From Release 4.5A, the
Modification Assistant largely automates this process.
Enhancement: Creation of customer-defined repository objects that are referentially included in
SAP repository objects.
Customer development: Creation of customer-defined repository objects using customer name
spaces.
Customer development, enhancement, and modification are performed using ABAP Workbench
tools. Customizing and most personalization are done with Business Engineer tools. The course
MBC40 deals mainly with managing projects that are, from a technical standpoint, based on the
ABAP Workbench (development projects).
(C) SAP AG MBC40 7

ASAP
Procedure Model Implementation Guide Session Manager
Business Process Scen. Application Components Business Objects

Materials Purchase Purchase Schedule
management
order order item lines
Purchase order
Inventory Information Warehouse consignment Time
R/3
Purchasing system Management
Management
Purchase order
returnable packaging
Request for
quotation
Purchase
requisition Order Purchase order
Re
f
Vendor
third party delivery
Mo erenc
quotation
del e
Enterprise Organization Object-oriented
Process Model
Data Model
Purchase Vendor Vendor Purchase
requisition inquiry quotation information
Shipping
notification
Purchase
order
Vendor
scheduling
agreement
Workflow and Organization
© SAP AG 1999
ASAP contains all SAP implementation tools, specifically:

Reference Models
All models that describe R/3 (process models, data models, organization models)
Implementation Guide
A list of all Customizing activities
(C) SAP AG MBC40 8

Personalization
Simplifying and personalizing an

application is often possible without
using the ABAP Workbench.
Global field display characteristics

SET/GET parameters
Global values
Variant transactions
Parameter transactions
Systemwide table control settings
GuiXT
Enterprise-specific and user-specific
menus
Easy Access menu / area menus
Shortcuts on the desktop
Workplace
© SAP AG 1999
The goal of personalization is to speed up and simplify the business transactions processed within the
R/3 System. Each individual application's transactions are adjusted to the business needs of the
company as a whole or of various user groups. All unnecessary information and functions are
disabled.
The input values of fields on certain screens can be pre-determined using global display
characteristics. Within transactions, individual fields and individual columns of table controls or
even complete screens can be hidden.
In the Easy Access menu, users have only the entries - transactions, reports and Web addresses - they
need for their daily activities. The system administrator can define the user menu for different
activity groups and then assign users to those groups.
The mySAP.com Workplace offers users role-based, personalized Web access to all systems,
functions and services they need for their work. The Workplace links all the mySAP.com
components and external applications users need in the Web browser.
(C) SAP AG MBC40 9

Personalization
Company:
TOP-DOWN configuration Enterprise structure
Business processes
Configuration User roles:

of user roles Area menus
Role-based menus
Transaction variants
Role-based
Area Role-based TA
menus
menus menus
variants Personal
configuration
Personal configuration Favorites
Links
Desktop links
Favorites Links Desktop
© SAP AG 1999
The SAP System adapts itself to the needs and styles of the users: At system start-up, users are
offered only the functions they use in their daily activities. No time is wasted on navigating through
functions that are not needed. Before Release 4.6, user menus were called in the Session Manager or
dynamic menu in R/3; as of Release 4.6A, all users have their own role-based menu, displayed in a
tree structure, when they log on to the R/3 System.
When users choose a function, it is started in the same session. Instead of the role-based menu, the
function that has been executed is then displayed. When users exit a transaction or when they start a
new session, the role-based menu appears automatically.
In activity group maintenance (transaction PFCG), administrators can assemble a menu structure for
an activity group, consisting of transactions, reports, and Internet and intranet links, and thus create a
user menu. Administrators are free to choose the structure and description of the functions included.
The enterprise menu is no longer available as of Release 4.6A.
(C) SAP AG MBC40 10

Workplace
The mySAP.com Workplace

integrates all systems:
mySAP.com components
R/3 as of Release 3.1H
LaunchPad
LaunchPad
personal,
personal, non-SAP components
role-based
role-based
navigation
navigation
Drag&Relate
Drag&Relate
MiniApps
MiniApps
monitoring
monitoring and
and
interaction
interaction
© SAP AG 1999
The Workplace consists of a LaunchPad, MiniApps, and the way in which they are linked
(Drag&Relate).
On the left of the screen, you will find the LaunchPad, a personalized navigation bar based on each
user's role.
On the right of the screen, the MiniApps are displayed according to what has been selected in the
LaunchPad. The mySAP.com Workplace thus integrates all systems: mySAP.com, R/3 and non-
SAP components are displayed in the Web browser, without users needing to log on to different
systems.
Drag&Relate enables users to move information from one area to another. The different
applications can intelligently interpret the information from another area.
When users access the functions of a back-end system (for example, R/3) from their Workplace, the
following components are involved:
The Web browser communicates with an HTTP server that runs on a computer in a different
location. They are linked via Internet or intranet.
Information about the Workplace (user role, personalizing) is located on the Workplace Server.
Users only need to log on once to the Workplace (Single Sign-On).
The Internet Transaction Server (ITS) links the HTTP server to the SAP back-end system.
(C) SAP AG MBC40 11

ABAP Workbench
R/3
Repository
© SAP AG 1999
ABAP Workbench includes all tools necessary for developing client/server applications. Using
highly developed tools, ABAP Workbench supports productive program development on the basis of
early prototyping. All development objects created using the ABAP Workbench are called
Repository objects. They are stored in a special part of the SAP system's central database called the
R/3 Repository.
The ABAP Workbench tools listed below allow you to edit the following repository objects:
Data Modeler: Enterprise data models according to SAP SERM
ABAP Dictionary: Data descriptions and their relationships to one another
ABAP Editor: ABAP source code
ABAP Query: Reports (without using ABAP coding)
Function Builder: Function modules (centrally stored program modules)
Class Builder: Centrally stored OO objects (classes, methods)
Menu Painter: Title settings, menu bar settings, standard toolbar and application toolbar settings
Screen Painter: Screens and their flow logic
Workbench Organizer: Change requests, to ensure orderly development and transport (in
conjunction with the transport system)
(C) SAP AG MBC40 12

ABAP Programming is Designed for:
Business tasks
Client/server architecture
Platform independence
Developing user dialogs
Database accesses
Openness
International use ABAP ABAP
Development in project
teams
RDBMS
Repository
© SAP AG 1999
ABAP stands for Advanced Business Application Programming and is the programming language
developed by SAP for use in application development.
ABAP is designed to support the application development of business tasks (mass data processing,
currency specific display, multilingual capability, and so on).
ABAP is designed for developing user dialogs within a distributed R/3 System. Developers need not
concern themselves with communication or distribution between the different levels.
ABAP programs in conjunction with the SAP Basis are platform independent.
ABAP contains a special set of commands for database access called ABAP Open SQL.
ABAP application development can be done in project teams and is organized by using the
Workbench Organizer.
(C) SAP AG MBC40 13

ABAP Workbench Change Levels
R/3 business Customer

applications programs
(SAP standard)
Customer
Modification Enhancement development
Assisted Customer enhancement With SAP objects

modification Prog./menu/ Without SAP
screen exits
Hard-coded Business transaction objects
events
modification
Business add-ins
Universal
Field exit/
table append
Text enhancement
Easy access
enhancement
User exit
© SAP AG 1999
With customer development, SAP repository objects can be called from within customers' own
programs. For example, a customer can develop his or her own program that calls an SAP function
module.
With enhancements this works the other way around: Here SAP programs call repository objects that
customers have either created or altered themselves. For example, a customer can create a program
exit that an SAP program calls. You can use enhancements in the following places:
in an ABAP program (dynamic program exits)
in the graphical user interface (easy access enhancements, menu exits)
on screens
- by inserting a subscreen in an area pre-determined by SAP (screen exits)
- by executing code written by a customer related to a particular screen field (field exits)
in ABAP Dictionary tables, structures, views, matchcodes (table appends)
as text enhancements (replacing SAP field or keyword documentation).
Business transaction events (BTE or OPEN FI) allow you to call dynamic function modules using
Customizing.
in business add-ins, an interface of one class can be implemented.
Modifications are changes to SAP objects made within the customer system. They are:
driven by user exits (subroutines reserved for customers in objects in the SAP namespace)
assisted or hard-coded at any point desired in SAP repository objects.
Once you have modified an SAP object, you are no longer entitled to free support for this object.
(C) SAP AG MBC40 14

Change Levels: A Comparison
Flexible
No documentation exists
All data is global
Modifi-
Modifi- Caution: Full responsibility for
cation standard functionality
Some documentation
User exits
exists in the IMG
All data is global
Standard environment
SD MM ...
is observed
Enhancements
Detailed
documentation exists
Business SAP interface
Business
CMOD / transaction Limited functionality
SMOD add-ins
events
Fixed
(Change level determined by SAP)
© SAP AG 1999
At the modification level, all SAP original objects can be changed. If you change loops or overwrite
variables, unexpected changes may occur in SAP standard functionality, which is often complex.
User exits are located at functionally defined points in the original SAP object. These FORM
routines or screens are stored in the SAP module pool.
Enhancements are stored in protected and pre-programmed areas. Since the variables used are
defined on an interface, you cannot make uncontrolled changes to the standard.
The enhancements implemented as function modules are documented in and can be activated from
transaction CMOD/SMOD.
Business transaction events are managed using transaction FIBF and are composed of a series of
customized function modules.
Business add-ins are maintained in transactions SE18 and SE19, and are implemented in an
interface in a class. To effectively manage business add-ins, you need knowledge of ABAP
Objects.
(C) SAP AG MBC40 15

Implementing Development Projects
Customizing Is there a
standard function that can be tailored
to meet the customer's needs using Customizing
Customizing or personalization? Personalization
Yes
No
Development/Purchase
Does the standard R/3 System Customer development

contain a similar function? CSP solution
No
Yes
Does the existing application

allow you to use enhancements Enhancement or
to implement the required user exit
function? Yes
No No
Cust. development with

Modification
SAP prog. as model
© SAP AG 1999
If your requirements cannot be met using Customizing or personalization either start a development
project or use a CSP solution (Complementary Software Product).
A development project allows for customer development if no similar function is available within the
SAP standard. You can also adapt the system to meet your needs by adding enhancements, user
exits, modifications, or copies of SAP programs to SAP standard objects.
Modifications can be problematic because all new SAP versions must be adjusted and reconciled
with the customer's modified version after each upgrade. Up to Release 4.0B these technical
adjustments are made manually using upgrade utilities. From Release 4.5A, the Modification
Assistant largely automates this process.
Only make modifications if
Customizing and personalization cannot fulfill your requirements
enhancements and user exits are not planned
copying an SAP object into the customer namespace is not a solution (see following slide).
(C) SAP AG MBC40 16

Modifying Versus Copying
Connection Project
to SAP security
Modify Copy
© SAP AG 1999
Modifying has the advantage that your active Repository objects do not lose their connection to the
SAP standard. Copying, on the other hand, has the advantage that no modification adjustments must
be made to active Repository objects after an upgrade.
Choose copying instead of modifying if
you have to change many parts of the SAP program
your requirements cannot be met by future R/3 release standards
it is not worth transferring the called parts of the program to the copied object (where-used list)
Pay attention to the dependent objects when copying. Note that the choice between modifying and
copying must also be made for all includes attached to your base program. The same applies to
function groups and function modules.
(C) SAP AG MBC40 17

ABAP Development Projects - Evaluation
Implementation requirements ... greater than in Customizing.

Evaluation of implementation consequences
Performance ... may decrease.
Amount of work at upgrade ... increases.
© SAP AG 1999
ABAP development projects can be evaluated according to the following criteria:

How costly is implementation, measured in workdays (creating, implementing, and testing the
concept)?
How does the ABAP development project affect
- performance of production operation
- the amount of work at upgrade?
By calling SAP objects in your repository object, you can greatly reduce the amount of
implementation work. However, repository object changes made by SAP can cause additional work
during an upgrade. For example, For example, SAP may change a screen for which you have written
a batch input program.
(C) SAP AG MBC40 18

The Amount of Work at Upgrade Increases ...
with the degree to which the ABAP

development project depends on SAP
objects
with the frequency with which SAP alters
the SAP objects called or modified
with how critical the modified
SAP object is
Modified repository objects cause

the most work at upgrade
© SAP AG 1999
SAP changes made to the following repository objects are normally only upwardly compatible. You
can therefore regard them as safe for use in customer programs:
function modules that have been released
objects that have been published in the ABAP class library
BAPIs
user exit includes
customer exits
SAP guarantees BAPI stability for two functional releases.
Customer-developed programs that call SAP objects, as well as all objects displayed in the upgrade
utility SPAU, must be tested for functionality and performance after an upgrade. The same applies to
those repository objects automatically upgraded by the Modification Assistant (from Release 4.5A).
To adjust programs you need to know about the processing logic of your individual application.
(C) SAP AG MBC40 19

Modifications: Critical Repository Object Types
ABAP Dictionary Function groups Other
STOP Deleting any SAP repository objects

Not Changing the type or length Incompatible
allowed of a domain, an elementary type changes to
or a table field SAP function
modules
Inserting key fields
Very Changing conversion routines, SAP function module

critical value tables, or fixed values process types
in domains
Tables, fields and selection Transaction codes

Critical of views
Messages
Tables and fields of lock
objects and matchcode objects Logical databases
Administration of matchcode ID
© SAP AG 1999
Modifications are especially critical if

they influence many other repository objects (Dictionary objects, function modules)
adjustments are difficult (menu, pushbuttons, graphical user interfaces (GUIs) before 4.5A) or are
not supported by tools (transaction codes, messages, logical databases).
Without the Modification Assistant (up to 4.0B), modifying GUI statuses and GUI titles and
assigning customer function modules to SAP function groups are considered critical.
(C) SAP AG MBC40 20

Summary
The ABAP Workbench is a high-performance

software tool that provides the openness and
flexibility needed for client/server application
development
ABAP development projects are necessary when

required business processes cannot be added to the
R/3 System using Customizing
Modifications to the R/3 standard should be avoided,

since they dramatically increase the number of
adjustments needed at upgrade
© SAP AG 1999
(C) SAP AG MBC40 21

Change Levels: Exercise
? A third party is offering complimentary

software for R/3. What questions would
you ask this third party?
© SAP AG 1999
(C) SAP AG MBC40 22

ABAP Development Projects and ASAP

1 Change Levels
Technical Design
5 Standardization
© SAP AG 1999
(C) SAP AG MBC40 23

ABAP Development Projects and ASAP
Contents:
ASAP
Planning the tasks in ABAP development projects
Objectives:
Describe which individual tasks the ASAP Roadmap provides
for ABAP development projects
© SAP AG 1999
(C) SAP AG MBC40 24

ASAP as a Part of TeamSAP
People: Processes:
Competent solutions AcceleratedSAP
! SAP
! ASAP Roadmap
Pr
! Consulting partners
! Quality assurance
oc
le
! Complementary
! R/3 Business Engineer
op
software partners
es
! Support, consulting &
! Technology and
Pe
se
education services
hardware partners
Products
s
Products:
Business framework
! The R/3 product family
! Complementary software products (CSP)
! Technology partner products
! Industry Solutions
© SAP AG 1999
TeamSAP is the coordinated network of people, products, and processes that implement SAP R/3.
People: SAP and partners
Products: R/3 Business Framework, complementary software products, technology partner
products, and Industry Business Solutions
Processes: ASAP Roadmap, R/3 Business Engineer, support, consulting and education services
(C) SAP AG MBC40 25

ASAP Includes ...
Roadmap
a step-by-step Implementation Guide complete with
recommendations
Tools
the ASAP Implementation Assistant as a navigation tool for
the Roadmap, questionnaires, project forms, check lists
R/3 Business Engineer tools for creating a Business Blueprint
and for use in configuration
Service & Support
all services including consulting, training, hotline,
EarlyWatch, Going Live Check, support through SAPNet
Training
Knowledge Warehouse, training strategies for the project
team and end users
© SAP AG 1999
AcceleratedSAP (ASAP) is SAP's process-oriented solution for accelerated implementation and

continuous optimization of R/3. It was developed and enhanced by an international team of
consultants. It consists of the ASAP Roadmap, tools, service and support, and training.
The ASAP Roadmap is an implementation plan that includes detailed descriptions of why, when,
how, and by whom certain jobs should be completed. The ASAP Implementation Assistant is the
ASAP Roadmap browser. The ASAP Roadmap contains technical information and numerous
accelerators (questionnaires, project forms, and checklists), which you can use to start your
implementation project.
The Business Engineer is the backbone of ASAP within the R/3 System.
Additional ASAP tools include the Project Estimator, with which project costs and time can be
analyzed in cooperation with your consultant, and the Q&A database for creating a business
blueprint.
(C) SAP AG MBC40 26

ABAP Development Projects in ASAP
oring
ment • Monit
design •Develop •Tuning
•Process •Unit testin
g e
e c h n ic al tion •Chang
•T •Documenta ment
de sig n manage
•Training •Upgra
de
ment
•Integratio
n manage
• Project
team testing
ndscape ng
•System la •Mass testi
s sf er
•Standard •Data tr an
© SAP AG 1999
Project preparation
Project organization and standards, standardizing planning documentation, naming conventions,
and so on
Business Blueprint
Compilation of process and technical concepts using the Business Blueprint and reviews
Implementation
Baseline Customizing, programming, functional testing, transports, unit testing, documentation,
training
Final preparation
Go-live plan, integration test, mass test, documentation, training, customer help desk, data transfer,
cutover
Go live and support
Measurement of the product's business fit with customer requirements and business goals,
monitoring, tuning, reengineering, Change Management
(C) SAP AG MBC40 27

Tools and ASAP
• Templates
• Data Modeler • ABAP Dict.
• Screen Painter • ABAP Editor • Test Work-
• Menu Painter • Function bench/CATT
• Workload
Builder • Tuning tools
• ... • LSM
• Process Workbench
design
• Repository
• Technical
objects
design • Test docu.
• Workbench • Live
2 • Data model
requests 4
• Test logs
5 system
• Screens, • Live dates
interfaces 3 • Manual
• User
documentation
• Training
material
Business Blueprint Realization Final Preparation Go live

© SAP AG 1999
ABAP Workbench Tools are implemented in the following project phases:

Phase 1: Project preparation: No ABAP Workbench tools required
Phase 2: Business Blueprint: Process design template, technical design template, Data Modeler,
Screen Painter (early prototype screens), Menu Painter
Phase 3: Implementation: All ABAP Workbench tools
Phase 4: Final Preparation: Test Workbench, tuning tools, LSM Workbench (Legacy System
Migration)
Phase 5: Go live and support: Tuning tools (in particular workload analysis)
Large reengineering projects are initiated at either phase 1 or phase 2.
(C) SAP AG MBC40 28

Summary
ASAP supplies an integrated foundation for

planning and realization of Customizing and
ABAP development projects.
The five phases on the ASAP Roadmap are:
Project preparation
Business Blueprint
Implementation
Final preparation
Go live and support
© SAP AG 1999
(C) SAP AG MBC40 29

Project Team

1 Change Levels
Technical Design
5 Standardization
© SAP AG 1999
(C) SAP AG MBC40 30

Project Team
Contents:
Roles in customer development projects
Integration of employees into the project team
SAP Services
Objectives:
List the roles in customer development projects
Integrate employees into your development project
Describe which services SAP offers for ABAP development project
support
© SAP AG 1999
(C) SAP AG MBC40 31

Position on the ASAP Roadmap
ring
nt •Monito
•Developme •Tuning
•Process •Unit test in g e
design tion •Chang
•Documenta ment
•Technic
al manage
de
design ment
ation manage
team •Integr
• Project testing
ndscape esting
•System la •Mass t nsfer
s
•Standard •Data t
ra
© SAP AG 1999
(C) SAP AG MBC40 32

Roles in Customer Development Projects (1)
Steering committee
Project management
Development
Project coordination
Technical support
Quality assurance
© SAP AG 1999
Depending on the scope and complexity of your project, the roles described below could be assigned
to one person.
The steering committee consists of those people from the board of directors who initiate and sponsor
the project. The committee has ultimate authority over which direction the project takes.
Project management is responsible for the R/3 implementation project as a whole. Project
management plans the project (budgets, deadlines, personnel, functions), resolves conflicts and
delivers status reports to the steering committee.
Project coordination is responsible for standardization and marketing the project within the company.
In addition, the project coordinators are responsible for project logistics.
Development creates process and technical designs for the project in cooperation with the other
areas, and is responsible for actual implementation.
Planning, carrying out and reviewing testing falls into the area of quality assurance.
Technical support is responsible for removing all technical obstacles to implementation (for
example, server downtime, transport problems, database problems).
(C) SAP AG MBC40 33

Project coordination
Process manager
Marketing representative
Standards coordinator
© SAP AG 1999
Process managers come from the department affected and are responsible for logistics within a
subproject. They support development by creating process designs, drawing up integration plans
together with quality assurance, and are responsible for CATT (Computer Aided Test Tool) test case
input.
Marketing representatives coordinate all internal (company) activities in the areas of project
marketing, training, and consulting. They are responsible for rollout of the subproject and report to
project management (status reports).
Standard coordinators deal with more than one subproject. They are responsible for establishing
company-wide standards for project documentation and communication. They are also responsible
for documenting Customizing and development activities (templates for process and technical
design, naming conventions, programming guides, graphical user interface style guides).
(C) SAP AG MBC40 34

Development
Project manager
Concept developer
Data modeler and Dictionary developer
ABAP developer
Interface developer
SAPscript developer
Information developer
ABAP Workbench consultant
© SAP AG 1999
Development managers coordinate development activities within a subproject. Their responsibilities

include creating development standards for the subproject as a whole, determining the feasibility of
process and technical designs, and writing status reports.
Concept developers analyze both process designs and technical designs. They use the templates
created by standards coordinators.
Data modelers support the creation of data models within the project's technical design using SERM
(Structured Entity Relationship Method) and Data Modeler. Dictionary developers reproduce these
data models in the ABAP Dictionary (for example, tables, data elements, domains, foreign key
dependencies, search help).
ABAP developers implement the process model described in the technical design using the ABAP
Workbench tools. They also create the user interfaces and print lists planned in the process and
technical designs.
Interface developers implement necessary online and offline interfaces (without ABAP, if
applicable).
SAPscript developers use SAPscript to create the forms planned in the process and technical designs.
Information developers write the documentation for what the other developers have created.
(C) SAP AG MBC40 35

Quality assurance
Quality coordinator
Test coordinator
Tester
Quality assurance consultant
© SAP AG 1999
Quality coordinators coordinate all quality assurance activities. This includes writing reviews of
quality assurance activities and generating status reports for project management.
Test coordinators create test catalogs for subprojects documenting individual test cases. They
coordinate test case input. They work closely with process managers during test case creation and
user test organization.
The actual testers come from the user departments where these new functions will be used. They
complete function tests by manually going through test cases and CATT procedures.
Quality assurance consultants deliver technical support for all quality assurance activities. Their
responsibilities include writing reviews and measuring performance using Workload Analysis, SQL
Trace, ABAP Trace and other tools.
(C) SAP AG MBC40 36

Technical support
Transport coordinator
System administrator
Authorization administrator
Technical consultant
© SAP AG 1999
Transport coordinators are responsible for setting up and maintaining correction and transport
mechanisms. They determine in conjunction with the subproject management when and how
transports should take place, and are responsible for conducting them. Transport coordinators solve
transport problems with the CTS (Change and Transport System).
System administrators guarantee the availability of the system landscape for development and
quality assurance. This includes administering operating systems, database systems, networks and
R/3 Systems. In addition, system administrators are responsible for regularly backing up data and for
creating a recovery strategy.
Authorization administrators provide individual employees with authorizations for various R/3
Systems depending on each employee's role (for database management systems and operating
systems too, if necessary).
(C) SAP AG MBC40 37

Who Decides if Development is Necessary?
Decision
maker Project length Scope Object type
Developer or Local to a Simple

dev. manager Less than n days single function
Project n - m days Local to

management a project
Critical
Steering More than m days Global

committee
Very critical
© SAP AG 1999
A company wide procedure should be implemented that determines who is responsible for
development depending on the length, consequences, and object type of the modifications to be
made. This procedure should define a decision maker for each type of development. You can define
separate tables for customer development and modification.
The Repository object classification found in the 'object type' column above are discussed in the unit
on Change Levels.
The degree of any possible side effects that changes to Repository objects might cause can be gauged
with the help of the where-used list.
(C) SAP AG MBC40 38

Integration of Employees into the Project Team (1)
Organization
Project and development team
Documents
Project plan
Project description
Standards
Naming conventions
Programming guidelines
Analysis and development
documentation
© SAP AG 1999
In the organization phase of employee integration, the members of the project and development team
are introduced by name, company, and role in the project. They are informed about the relevant
documents (process and technical design) and about the project planning.
During project description employees are introduced to the project contents. Fundamental
information about the project can also be communicated at this time (for example, whether it is
purely a development project, or if a parallel Customizing project exists, or in which language the
project is being developed and into which languages it will be translated).
In the standards phase employees are informed about the standards for project communication,
project monitoring, naming conventions, process and technical design, programming guides, and
documentation.
(C) SAP AG MBC40 39

Integration of Employees into the Project Team (2)
System landscape
Systems and clients
Transport routes
General considerations
Quantity structure, lead time,
response time
Conditions for use
Logging development
Repository objects, exits
and modifications
Quality assurance
Reviews and test procedures
© SAP AG 1999
The basic system landscape must be explained to all employees assigned to the project. In order to
do this, you must prepare information about systems, clients, transport routes, and transport times.
Project participants must also receive general information about data volume, planned lead and
response times (success criteria), as well as the conditions under which the new function will be used
(for example, data security, archiving, authorizations).
Employees assigned to the project are informed about which development activities must be logged
at various change levels (overview of Repository objects in customer namespace, user and customer
exit list, and modification list).
In the quality assurance phase, employees are informed about the quality assurance measures for the
project.
(C) SAP AG MBC40 40

Registering a Developer in SSCR
Maintain user
1 1
User Edit Goto Info Environment System Help
Create user
User ABAPDEVELOP
Last change 00:00:00 Status revised
Address Logon data Fixed values Task profile Profile Parameters
Profil Typ Text

S_A.Develop Developer
V_Verkauf SD Model profile
Register ABAP Workbench Developer

Registration Edit Selection System Help
2
Register user
User ABAPDEVELOP
Key 07319180563617100772
© SAP AG 1999
Development users need the authorization profile S_A.DEVELOP and the authorizations to navigate
through the business transactions they use and program.
A development user must initially register for an access key in SAPNet. This key must be entered in
the window that appears the first time the user creates or changes a Repository object. SAPNet
generates this key based upon customer number and user name.
A development user is a separate component in the price list.
(C) SAP AG MBC40 41

On-Site Consulting
Written consulting contract

Description of services to be rendered
Contents
Consulting level
Usage dates
Certified application Usage sites
consultant ABAP
Amount of consulting (working hours/days)
Daily rates
Status reports
Development progress, milestone reports
Factors critical for successfully reaching the next
milestone
© SAP AG 1999
Internal or external employees can be used for the development project (SAP consultants or
consulting firm consultants).
If external employees are used on a customer development project, please pay attention to the
following special rules for mutual protection:
All services to be rendered must be described in a written consulting contract. The contents of the
service (technical classification) as well as the level of consulting (coaching, project management,
concept creation, implementation, etc.) must be stated in written form. In addition, background
information for the consulting project (usage dates, usage sites, the amount of consulting in
working hours/days, and day rates) must be put into concrete terms.
External consultants must document the progress of development (describe the individual steps
that were necessary to reach certain milestones) as well as the factors critical for reaching the next
milestone in status reports to the project management.
The SAP R/3 Partner Academy has a program for certifying ABAP application consultants.
(C) SAP AG MBC40 42

Levels of On-Site Consulting: ABAP Workbench
Strategy consulting
Continuous customer service
Coaching
Certified application
consultant ABAP Help with analysis and implementation
Extras
In-house training
Development project review
© SAP AG 1999
External consultants can assist with development projects in the following ways:
Strategy consulting: General procedures in the project
Continuous customer service: Answering questions, active participation in analysis and
implementation
Extras
- In-house training
- Development project review without active participation in analysis and implementation
(C) SAP AG MBC40 43

SAP R/3 Consulting Services
On-Site Consulting / Remote Consulting

GoingLive Check
EarlyWatch
Remote Upgrade
R/3
Remote Archiving
R/3 Conv. Services
Remote Data Migr.
OS / DB Migration
Remote Euro Migr.
Migr.
© SAP AG 1999
SAP GoingLive Check: This prepares your system for production operation by technically
examining the Basis Component and applications (remote examination of the configuration of
system components, sizing plausibility check, performance optimization).
SAP EarlyWatch: The Basis Component and the applications are examined in the live system
(remote examination of R/3 configuration, server configuration, load distribution, database
configuration, capacity planning).
(C) SAP AG MBC40 44

SAP R/3 Education Services: ABAP Workbench
Level 2 Level 3
BC402 3 days BC414 2 days BC490 3 days
ABAP Programming Programming ABAP Performance
Techniques Database Updates Tuning
ABAP Objects: Communication
Object-Oriented Interfaces in ABAP
Programming inR/3
BC425 3 days
BC405 3 days
Enhancements and
Techniques of List
Modifications
Processing and SAP Query
BC412 2 days
BC410 5 days
ABAP Dialog Programming
BC400 5 days Developing User Dialogs Using EnjoySAP Controls
ABAP Workbench: BC420 5 days BC440 5 days
Concepts and Tools Developing Internet
Data Transfer
BC430 2 days Application Components
MBC40 2 days ABAP Dictionary
Managing ABAP BC460 3 days Recommended follow-up
Development Projects SAPscript: Form Printing courses:
and Text Management Business Process Technologies
CA925, CA926, CA927
CA610 2 days BC095 (Business Integration
Test Workbench and Technology)
Computer Aided Test Tool BC619 (ALE), BC620, BC621
© SAP AG 1999
(C) SAP AG MBC40 45

Summary
Certain roles must be determined when creating a project team, both

for the customer and the contractor
Project management coordinates the individual subproject activities
within a project
Subproject management (process managers, development
managers, and quality coordinators) coordinate the activities of the
individual subproject roles
If external consultants are involved in the project, a written contract
should be drawn up
© SAP AG 1999
(C) SAP AG MBC40 46

Software Logistics

1 Change Levels
Technical Design
5 Standardization
© SAP AG 1999
(C) SAP AG MBC40 47

Software Logistics
Contents:
Planning the system landscape
Guaranteeing organized software development in the
Workbench Organizer with
Change requests
Originals and copies
Development classes
Objectives:
Describe what you should take into account when planning a
system landscape for ABAP development objects
Explain how the Workbench Organizer supports organized
software development
© SAP AG 1999
(C) SAP AG MBC40 48

ring
nt •Monito
•Documenta ment
•Technic
al manage
de
design ment
tion manage
eam •Integra
•Project t testing
ndscape esting
•System la •Mass t
•Standard
s ransfer
•Data t
© SAP AG 1999
(C) SAP AG MBC40 49

Software Logistics: Overview
Change requests
© SAP AG 1999
(C) SAP AG MBC40 50

Planning the System Landscape for Development
Define the R/3 system landscape

How many R/3 systems?
Which client roles?
How are client roles to be distributed throughout the R/3 systems?
Caution: Repository objects are not client-specific.
Development Quality Assurance Production

(central maintenance)
Define a construction strategy for the R/3 system landscape

When can the R/3 systems be set up?
Which tools do I need to create and distribute clients?
Define a construction strategy for the R/3 system landscape
© SAP AG 1999
An R/3 System landscape consists of all of a customer's R/3 Systems. Each individual role
(development, testing, test systems, quality assurance, training, production) must be mapped onto
clients within the R/3 Systems.
Repository objects are not client-specific. Thus all changes to Repository objects are immediately
visible in all clients. Example: M1 and M2 are clients in an R/3 System. If a program is saved in M1,
all changes are immediately present in the runtime environment of M2.
We recommend defining Customizing and application table structures as client-specific (see
Implementation unit).
We recommend conducting development, quality assurance, and production in three different clients
in three different R/3 Systems. For greater needs (for example, system landscapes where central
development is conducted in one country and additional development in other countries) complex
system landscapes with more than three systems can be planned. Many customers with fewer needs
work with a two-system landscape. In a two-system landscape, a central maintenance site should be
reserved for development and Customizing. Other clients may be used for sandbox, training or
master data.
System landscapes can be constructed using the tools client copy, transport client and copy database.
After landscape construction, the maintenance phase begins. From here on, changes to Customizing
settings and Repository objects can only be copied or transported using requests.
(C) SAP AG MBC40 51

Setting up the System Landscape
Development system Quality assurance Production system

system
PROD
DEV QTST
Client Client
copy copy Client
transport
Client
MAST transport MAST
Client Client
copy copy
SBOX TRAI
Client-indep. Client-indep. Client-indep.

Customizing Customizing Customizing
Workbench Workbench Repository
Repository Repository
request request objects
objects objects
© SAP AG 1999
For the setup of the system landscape, Customizing is copied and transported using client copy
(within R/3) and client transport (cross-system).
Repository objects are not copied using client copy and client transport. They are transported by
releasing and transporting Workbench requests.
(C) SAP AG MBC40 52

Maintaining the System Landscape
Development system Quality assurance Production system

system
Customizing Customizing
request request
DEV QTST PROD
Client
Client copy
copy
MAST MAST
Client
Client copy
copy
SBOX TRAI
Client-indep. Client-indep. Client-indep.

Customizing Customizing Customizing
Workbench Workbench Repository
Repository Repository
requests requests objects
objects objects
© SAP AG 1999
Once R/3 is live, the system landscape is in the state of maintenance.

All changes to Customizing or Repository objects are recorded in change requests and are
transported using the transport system and client copy with a transport request.
(C) SAP AG MBC40 53

Centralized and Decentralized Development
IN1 QA1 PD1
Development Consolidation Production

USA USA USA
DEV QAS IN2 QA2 PD2
Development Consolidation Development Consolidation Production

Global Global Europe Europe Europe
IN3 QA3 PD3
Development Consolidation Production

Asia Asia Asia
© SAP AG 1999
This system landscape combines centralized international development with decentralized national
development in subsidiaries.
(C) SAP AG MBC40 54

Workbench Organizer and the Transport System
Change
request Transport system
Development system
Quality assurance and

production system
Workbench Organizer
Organized software development using
• Development classes
• Change requests
• Originals and copies
© SAP AG 1999
The Workbench Organizer enables you to develop software in an organized manner.

The transport system transports and tracks objects.
Repository objects are connected to the transport system by their development class and change
request assignments. After a request has been released in a development system, it is then transported
along pre-determined routes into a quality assurance system or a production system.
(C) SAP AG MBC40 55

Software Logistics: Overview
Change requests
© SAP AG 1999
(C) SAP AG MBC40 56

Managing Development Projects in the WBO
Project manager Change request
Workbench Organizer
Task
Employee
Project level
Task
Employee Task
Employee
© SAP AG 1999
At the beginning of a development project, the project manager creates one or more change requests.
The project manager assigns the project team members to a change request. The Workbench
Organizer assigns a project number to the change request (<sid>K9<nnnnn>. Example:
C11K900001.)
The Workbench Organizer creates a task for each member of the project team. Whenever an
employee allocates a Repository object to that change request, the Repository object is automatically
be entered as that employee's task. Thus all Repository objects that an employee works on during a
development program are collected within his or her task folder.
When employees have finished their part of a development project, they release their tasks. This
automatically transfers all of the Repository objects within the task to a change request. Once all
employees have released their tasks, the development manager can release the change request. Hence
a change request contains all the Repository objects that have been created or changed during the
development project.
(C) SAP AG MBC40 57

Logical and Temporary Designation
Create object
Assign object to a
development class
Assign object to a
change request
automatic assignment
to a task
Developer
© SAP AG 1999
If a Repository object is created or changed during a development project, the developer must assign
that Repository object to a development class. Development classes contain all of the objects within
a certain functional area. Development classes are created either when the Workbench Organizer is
set up or afterwards, using the ABAP Workbench.
Each development class has a functional area manager who acts as a contact person for the functional
area. Development classes allow for logical differentiation of Repository objects and serve as
structural help and entry points in the ABAP Workbench.
After development classes have been assigned, the developer assigns the Repository object to a
change request. In contrast to the logical differentiation of Repository objects by development class,
change requests divide things up according to when they happen in the project and thus temporarily
differentiate Repository objects.
Task assignment within a development project is automatically handled by the Workbench
Organizer.
(C) SAP AG MBC40 58

Completing a Project
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
Import
Transport
directory
Administrator
© SAP AG 1999
When development is finished, the developers release their tasks. The objects and object locks are
passed from the task to the change request. However, the objects can still be changed by all
employees assigned to the request.
When the project is finished, the project leader releases the change request. All Repository object
locks within the change request are removed.
Change requests are either transportable or local. This is determined automatically by the
Workbench Organizer according to development class. Only transportable change requests are
transferred to the transport system after all locks are removed:
During a test import, the system checks immediately after export whether all objects can be
imported into the target system.
Repository objects are exported into the central transport directory.
Whether or not exports and test imports are successful is recorded in a change request's transport
log and checked by the developer.
The objects are not imported automatically into the target system. Instead, the system administrator
uses the transport control program tp at operating system level. System administrators and
developers subsequently check the import logs.
(C) SAP AG MBC40 59

Functions of a Change Request
Monitor
development
assignment levels
Enables Versions
teamwork of employees
Change request
Prevent
Fully documents
unauthorized Locks Documentation the changes
access to
Repository
objects
© SAP AG 1999
In a change request, you determine the developers who will work on a project. These employees then
have access to all Repository objects within the change request. By making this kind of access
possible, the Workbench Organizer allows employees to work in a team.
Only project participants may process the Repository objects in the change request. Unauthorized
access to Repository objects is thus avoided.
In the change request documentation, you describe the reasons for the development and its status.
Thus the changes are fully documented. Every new development of or change to a Repository object
can then be followed.
Each time a change request is released, a new full version of the objects it contains is written to the
version database. If a Repository object is processed again, the new version is a stored on the
versions database together with a reverse delta showing the differences between the old and new
versions. Displaying and comparing different versions allows you to track the development history
of an object. The version database allows you to restore previous versions.
(C) SAP AG MBC40 60

Sizing Change Requests
DEVK900001 Workbench Organizer: Requests

Request Project 1 Change requests
- Modifiable
Transportable
Program
+ DEVK900001
Screen
DEVK900011
GUI status + DEVK900003
Central Request
Tcode + DEVK900007
Dictionary + DEVK900011
objects
Messages
Function
modules
Program
Program Includes
GUI status GUI status
DEVK900007
DEVK900003 Request Project 3
Request Project 2
© SAP AG 1999
A change request should contain all Repository objects that

need to be edited and transported within a development project
are technically dependent upon each other in terms of Workbench architecture
Special attention must be paid to those central Repository objects used by more than one subproject
(for example Dictionary objects, messages, or function modules). These are usually part of different
development projects, but often use the same central Repository objects.
If these subprojects are transported together, then only one central transport request is necessary
for all subprojects.
If the subprojects need to be transported at different times, a separate transport request must be
created for each subproject and for the central Repository. The subproject transport must then take
place at the same time as the transport of the central Repository objects. After the central request
has been released, a new central request must be created.
(C) SAP AG MBC40 61

Originals and Copies
Change requests
© SAP AG 1999
(C) SAP AG MBC40 62

Task Attributes
Original Copy
PROG PROG
Development/ ZSCUST01 Repair ZSCUST01
Correction Task
Change request
Copy Copy
Repair Repair
PROG PROG
SAPABAP SAPABAP
© SAP AG 1999
Whenever a Repository object is created, the Workbench Organizer automatically notes which
system it belongs to. Repository objects are only considered 'original' to a single SAP system.
The original version of an object can only exist in one system. All other systems' versions are copies
of the object. Differentiating between originals and copies ensures that changes to Repository objects
can only be made in one development system. This means that the state of objects remains consistent
across systems.
Originals are never overwritten in transports.
Originals can be moved to other R/3 Systems.
SAP objects are copies in all customer systems.
The Workbench Organizer automatically notes whether a developer has changed an original or a
copy. Depending on the type of object, the Workbench Organizer assigns the task attributes
development/correction or repair.
The development/correction attribute is assigned to tasks when you create or change an original. The
repair attribute is assigned to tasks in which you change a copy.
(C) SAP AG MBC40 63

Changing Customer Copies
Repaired
Original copy
Transport not possible: Repair
New original New copy

Change original and transport
© SAP AG 1999
If you need to change a customer copy urgently, you can repair it. During repair, the object is
protected from overwrites by imports.
You should only repair customer copies if you cannot solve the problem quickly by performing a
subsequent transport.
You must make the same changes in the original system of the object and then confirm the repair.
(C) SAP AG MBC40 64

Changing SAP Copies (Modifications)
Repaired
copy Copy
Changing standard functions
Copy Copy
Adjustment
Adjustment
Upgrade Transport the adjustment Upgrade

© SAP AG 1999
Changes to SAP copies are called modifications. Modifications are also a type of repair.
When upgrading, if you add a new development level to an SAP object in your customer system, you
may have to make adjustments to ensure that your repaired SAP object corresponds to the new SAP
object level. The SAP upgrade utilities SPDD (for ABAP Dictionary objects) and SPAU (for all
other Repository objects) can help you with this.
(C) SAP AG MBC40 65

Registering Modifications in SSCR
Object Browser: Program SAPABAP

Development object
Menu 2 Edit Goto Utilities Settings Environment
Customer
Program SAPABAP
system
Register Object
Please enter the key for object

R3TR PROG SAPABAP:
Register Changes to SAP Objects

Registration Edit 2 Selection System Help
Menü
SAPNet R/3 PGMID/Object/Name R3TR PROG SAPABAP

Frontend
Key 07319180563617100772
© SAP AG 1999
Object registration takes place when a registered development user makes changes to Repository
objects. Matchcodes, database indexes, buffer settings, customer objects, preliminary corrections,
and objects that have been changed by automatic generation (for example during Customizing) are
all exempt from registration. If the same user changes the Repository object later, he or she is no
longer prompted for the key. If the object has been registered once, the corresponding key is saved
locally and is automatically called when new changes are undertaken, independent of which
registered user wants to make the changes. This key is valid even with new releases.
The advantages of SSCR (SAP Software Change Registration):
Rapid error correction and thus high availability for modified systems: All changes made to
objects are logged by SAP. SAP Regional Support can use this information to locate and correct
errors. This further increases the availability of your R/3 System.
Reliable Operation: Mandatory change registration decreases the probability of your software
being modified by mistake. This ensures more reliable operation of your R/3 software.
Project security and easier upgrading: In SAPNet, you can control the group of people authorized
to make modifications. Upgrades and release changes are much easier when fewer modifications
have been made.
(C) SAP AG MBC40 66

Critical Success Factors: Software Logistics (1)
When importing single objects, control dependencies

(avoid overshooters)
Leave individually imported transport requests in the buffer
Development manager maintains a list of change requests
for each project or group of projects
Import order numbers in numerical order (lowest numbers
first). Compare numbers with those on the development
manager's list
Observe naming convention for change request texts, e.g.
<project name> <release> <sequence number>
Ensure that non-ABAP development is completed on time
Ensure that developers are available when objects are
imported to the production system so that they can monitor
the production system
© SAP AG 1999
We recommend that you import the complete buffer for a target system. If this is not feasible
because transports need to be available in production operation at a specific time, you must ensure
that transport dependencies are controlled (see list above).
(C) SAP AG MBC40 67

Critical Success Factors: Software Logistics (2)
Quality Assurance
Sufficient test cycles
Transports with priority 2: one test cycle per week
(development manager and process manager sign off
each transport request)
Transports with priority 1: one test cycle per day (project
manager, development manager and process manager
sign off each transport request)
Ensure that application data in the quality assurance system
is similar to application data used in the production system
When to import objects
Avoid importing objects if imported
programs are being executed
© SAP AG 1999
For single object imports, priority 2 transports (that is, transports that do not correct major problems
in the production system) should not be used more than once a week.
Since performance problems often arise in environments with mass data, integration testing should
be performed in the quality assurance system using data similar to data in the production system.
Algorithms that are high-performing on a few hundred data records may cause devastating
performance problems in a production environment.
Make sure you import objects at times when the imported programs are not running.
(C) SAP AG MBC40 68

Summary (1)
Request
Task 1 Task <n>
Correction Repair
(Altered Original) (Altered Copy)
SAP Objects
Customer Objects
(Modifications)
Add-Ons
Add-Ons Patches
Can be
avoided with
Enhancements
Enhancements Support Packages
© SAP AG 1999
Requests reflect the project level. They consist of tasks. Here, all Repository objects are collected
that an employee processes during a development project.
Tasks can either be corrections (when originals have been changed) or repairs (when copies have
been changed). Both customer objects and SAP objects can be repaired. Repairs to SAP objects are
called modifications.
Customer modifications can be necessary for a number of reasons:
The customer wants added functionality for a standard object.
The customer has applied a patch (made a preliminary correction) as directed in an SAP Note.
Modifications can be avoided by using enhancements or Support Packages.
(C) SAP AG MBC40 69

Summary (2)
Repository objects are client-independent

We recommend a three-system landscape for
customers who plan to do their own ABAP
development
The Workbench Organizer facilitates organized
software development by using development classes,
change requests, and originals
All SAP objects in customer systems are copies.
Customer repairs to SAP objects are called
modifications
Modified objects changed by SAP and delivered in an
upgrade are displayed in the upgrade utilities SPDD
and SPAU
© SAP AG 1999
(C) SAP AG MBC40 70

Standardization

1 Change Levels
Technical Design
5 Standardization
© SAP AG 1999
(C) SAP AG MBC40 71

Standardization
Contents:
Naming conventions
Repository object documentation
Incorporating modifications
Objectives:
At the end of this unit, you will be able to:
Create naming conventions for your project
Document Repository objects
List which standards SAP recommends for incorporating
modifications
© SAP AG 1999
(C) SAP AG MBC40 72

ring
nt •Monito
•Documenta ment
•Technic
al manage
de
design ment
•Integratio
n manage
eam
ndscape ting
•System la •Mass tes
•Standard
s nsfer
•Data tra
© SAP AG 1999
(C) SAP AG MBC40 73

Standardization Areas
General Standardization ABAP-specific Standards

Project planning Development project
evaluation
Project implementation
Process design
Project communication
Technical design
Notification management
Naming conventions for
Project documentation
Repository objects
Shared folders
Interface style guide
Contents
Program documentation
Quality assurance
Modification handling
Team building
System landscape,
... Original language
© SAP AG 1999
In the general project environment, project planning, implementation, communication, notification

management, project documentation, quality assurance procedures, team building, and other areas
are standardized.
The following areas are standardized specifically in ABAP development projects:
Evaluation of development projects (see Change Levels)
Process design (see Process Design and Technical Design)
Technical design (see Process Design and Technical Design)
Naming conventions for Repository object: Naming conflicts between customer Repository
objects and Repository objects from SAP and SAP partners can be avoided by using standard
naming conventions.
Interface Style Guide: SAP delivers a style guide that standardizes your interface according to
ergonomic principles.
Program documentation: Repository objects can be documented in various ways.
Modification handling: Installation rules and logbook of all modifications made to a customer's
system
(C) SAP AG MBC40 74

Naming Conventions for Repository Objects
Application
Head office area
SAP
Branch
office
central
SAP Standard Customer namespace
Software (according to SAP Note 16466)
decentralized
Namespace reservation
by the Workbench Organizer
Development
SAP Partners
Namespace reservation
in SAPNet
Complementary
Software
© SAP AG 1999
By using naming conventions, you avoid naming conflicts and give your Repository objects
meaningful names.
The following naming conflicts can occur:
The names of an SAP Repository object and a customer Repository object conflict: Appropriate
naming conventions ensure that SAP Repository objects and customer Repository objects can be
distinguished from one another. SAP Note 16466 gives an overview of the current naming
convention for all Repository objects (normally a Y or Z at the beginning of the name).
The names of two or more customer Repository objects conflict: In decentralized development
scenarios with more than one development system, naming conflicts between customer Repository
objects can occur. Customers can prevent this situation from occurring by reserving namespaces
for development areas within the customer namespace. The Workbench Organizer uses the entries
in view V_TRESN to ensure namespace reservation.
The names of Complementary Software and a customer Repository object conflict: Naming
conflicts that occur when loading Complementary Software from SAP partners can only be solved
by reserving namespaces in SAPNet. To do this, the SAP partner can from Release 4.0 apply for a
name prefix in SAPNet that is then added to all of that partner's Repository objects (see SAP
Notes 84282 and 91032, White Paper Development Namespaces in R/3, purchase order number
E:50021723 or D:50021751).
(C) SAP AG MBC40 75

Application Hierarchy and Development Classes
Repository objects Function modules

MM HR WM
Programs
SD Tables
FI
MM
MM
Application hierarchy
Development classes
SAP Application Hierarchy
- Financial accounting U100
- General ledger accounting U101
- Basic functions
Financial accounting FBAS
External interfaces FYTA
Banks FBI
Customizing for banks FBIC
+ ...
© SAP AG 1999
The application hierarchy and development classes group Repository objects in a logical manner.
The SAP application hierarchy subdivides the Repository according to applications and their
functional parts. Each node in the SAP application hierarchy can be assigned to a development class.
Each Repository object must be assigned to a development class, which in turn must be assigned to
an application hierarchy node.
Repository objects are often made up of sub-objects that are themselves Repository objects.
You can use the Repository Information System to search for Repository objects according to
various criteria.
(C) SAP AG MBC40 76

Interface Style Guide
SAP delivers a style guide that standardizes your

interface according to ergonomic principles
SAP Style Guide

Ergonomics examples
© SAP AG 1999
SAP delivers a style guide that standardizes your interface according to ergonomic principles. In the
online documentation see: BC Basis → BC ABAP Workbench → BC SAP Style Guide.
Ergonomics examples can be found in the Repository Browser under Environment → Ergonomics
examples.
(C) SAP AG MBC40 77

Documentation
Project documentation End user documentation

Internally
Data element documentation
Business Program documentation
Blueprint Technical
design Independent SAPscript text
Process
design Externally
Internally
SAPOffice folder structure
Externally
Technical documentation for a single Repository object

Internally
Repository object (function module, ...)
Inline documentation
© SAP AG 1999
We recommend that you store documentation as follows:

Project documentation:
- Internally in a SAPoffice folder structure
- Externally (for example, on a document server)
End user documentation:
- Documentation at a Repository object (for example, function modules, ...)
- Data element (appears when you press F1 on a screen field)
- Program (appears when you select Help → Extended help on a selection screen)
- Independent SAPscript text called from an application
- Knowledge Engineer
- Winhelp link to R/3
Technical documentation for a single repository object:
- Documentation at a Repository object
- Inline documentation (comments in source code)
Select a central location for your project documentation that is available and known to all project
members.
(C) SAP AG MBC40 78

Inline Documentation
PROGRAM ykdemo.
* Link to external documentation
Object head
* Program task
* Program input and output
* Basic program flow
* Description of LUWs and locks
* Version history: type, author, date, request
Mod. unit
FORM subroutine USING sum.
head
* Modularization unit tasks
* Modularization unit input and output
* Func. method for the following stretch of code
stretches of code
CLEAR sum.
Individual
LOOP AT itab.
sum = sum + itab-sales.
ENDLOOP.
ENDFORM.
© SAP AG 1999
ABAP source code (in programs, screen flow logic, function modules, methods) can be documented
at the following levels:
Object head
modularization unit head
functional methods for stretches of code
(C) SAP AG MBC40 79

Critical Factors for Successful Modification (1)
REPORT sapabap.
Encapsulate instead IF sy-tabix = 1.
*#SD_001...#Insertion
of distributing CALL FUNCTION zfm
CHANGING
REPORT sapabap. counter = count
IF sy-tabix = 1. TABLES
*#SD_001...#Insertion itab = tab.
count = count + 1. ENDIF.
LOOP AT tab
WHERE f1 < 10. FUNCTION zfm.
.... counter = counter + 1.
ENDLOOP. LOOP AT itab
ENDIF. WHERE f1 < 10.
....
ENDLOOP.
Distributed ENDFUNCTION.
Encapsulated
© SAP AG 1999
Customer generated source code should be encapsulated in modularization units instead of

distributed throughout SAP source code (for example when calling customer function modules in
program source code or calling customer subscreens for additional screen fields).
(C) SAP AG MBC40 80

Critical Factors for Successful Modification (2)
Keep encapsuled interfaces compact

Standardize inline documentation
Keep a modification logbook
Confirm and release all repairs and all requests that
contain repairs
© SAP AG 1999
Keep the interfaces with those parts of the program written by the customer (encapsules) compact.
Define a company-wide standard for inline documentation (see the following slides).
Keep a list of all modifications (a modification logbook, see the following slides).
All repairs and all requests that contain repairs must be confirmed and released before an upgrade.
(C) SAP AG MBC40 81

Inline Modification Documentation
PROGRAM sapkdemo.
*#OSS0815 #C11K900001 Smith 03/19/1998 #Valid until 3.1G
n
IF sum < 25.
rectio
r
WRITE mysum.
i m . co
l
*# Pre
*#Area #C11K900003 Meyer 01/19/1998 #Insertion
ion
IF sum < 25.
n s ert
I
WRITE mysum.
*#
*#Area #C11K900002 Ziner 08/12/1997 #Replacement
* IF sum < 10. m ent
ce
* WRITE sum. pl a
IF sum < 25. Re
WRITE mysum.
*#
© SAP AG 1999
We recommend labeling hard modifications to source code as described above:

Preliminary correction: SAP Notes, repair numbers, changed by, change date, note valid until
Customer functionality insertions: areas, repair numbers, changed by, change date, INSERTION
Customer functionality replacements: Areas, repair numbers, changed by, change date,
REPLACEMENT (unnecessary SAP functionality is not deleted, but excluded using asterisks)
Areas are specified within the process design (for example area SD_001 = pricing).
(C) SAP AG MBC40 82

Modification Logbook
Object type (e.g. programs, screens, GUI status) PROG

Object name SAPMV45A
Routine SAVE_DOC
Area SD_001
Repair number C11K90008
Change date 05.04.98
Changed by Smith
Responsible Cramer
Preliminary correction (yes/no) no
SAP Note number, valid until Release x.y -
Reinstallation expense [h] 4
© SAP AG 1999
We recommend that you keep a list of all modifications (of all changes made to Repository objects in
the SAP namespace).
Such a list normally contains the following columns:
Object type (for example, programs, screens, GUI status)
Object name
Routine (if necessary)
Area according to process design or technical design
Repair number
Change date
Changed by
Preliminary correction (yes/no)
SAP Note number, valid until Release x.y
Estimated expense to reinstall the modification during adjustment (measured in hours)
(C) SAP AG MBC40 83

Summary
In addition to standardization undertaken during

general SAP implementation, the following areas
should be standardized in ABAP development
projects:
Process design and technical design
Naming conventions for Repository objects
Application hierarchy
Modification logbook
© SAP AG 1999
(C) SAP AG MBC40 84

Standardization: Exercise
? Discuss the advantages and disadvantages of Early

Prototyping in ABAP development projects.
© SAP AG 1999
(C) SAP AG MBC40 85

Process Design and Technical Design

1 Change Levels
Technical Design
5 Standardization
© SAP AG 1999
(C) SAP AG MBC40 86

Process Design and Technical Design
Contents:
Creating the process design (business analysis)
Creating the technical design (technical analysis)
Objectives:
Describe the typical contents of a process design and a technical
design
Explain the difference between the process design and the
technical design
© SAP AG 1999
(C) SAP AG MBC40 87

ring
ment •Monito
design •Develop •Tuning
•Process •Unit testin
g e
e c h n ic al tion •Chang
•T •Documenta ment
de sig n manage
de
ment
•Integratio
n manage
eam
ndscape ing
•System la •Mass test
•Standard
s sfer
•Data tran
© SAP AG 1999
(C) SAP AG MBC40 88

Business Blueprint: Process & Technical Design
Customizing projects
Development
project 1
ABAP Development Justification Form

Technical
design
Process
design
Development
project n
ss
Busine
int
Bluepr
Technical
design
Process
design
© SAP AG 1999
As part of ASAP, you produce a Business Blueprint (high-level conceptual document). This is the
basis for your Customizing and development projects. You also use it to produce process designs for
the individual parts of the project. From these process designs, you then produce technical designs.
The decision maker in a company uses the template ABAP Development Justification Form to
approve ABAP development projects.
(C) SAP AG MBC40 89

Process Design: Contents
Description of the planned function from the

user's point of view
Process model
Design for user interface, lists, and forms
Definition of offline and online interfaces
Estimates for data volume, throughput, and
response times
Conditions for use
© SAP AG 1999
The process design describes the business processes you intend to implement. It describes both the
processing method (process model) and the process results (user interface, lists, forms). The focal
point of the process design is the user's view, in other words, what to do, not how to do it.
Your process design contains descriptions of the online and offline interfaces for applications or
program modules both in the R/3 System and in non-SAP systems.
It also contains figures for the volumes of data, the throughput (performance for background
processing) and the response times (performance for dialog processing). These estimates provide
criteria against which you can judge your system's functionality later on.
The conditions for use describe aspects such as backup, archiving, authorizations, and restart
capability following a program termination.
(C) SAP AG MBC40 90

Process Design: Objectives
To illustrate the planned function from the user's

point of view (unrelated to the technical solution)
To precisely define the scope of the planned function
To position the function within the system as a whole
To prepare for subsequent development phases
To provide a basis for the first integration test plans
To provide the basis and justification for future
change requirements
© SAP AG 1999
The aim of the process design is to produce a description of the planned function purely from the
user's point of view. It should be totally independent of the technical solution. It must describe
precisely the scope of the planned function and give an indication of its overall position in the
system.
The process design is the basis for the subsequent development phases (technical design,
implementation, and so on), and for the integration test plans.
If the technical design is changed, studying previous versions will help you to understand why the
changes were made.
(C) SAP AG MBC40 91

Producing the Process Design (Template 1)
Administration
Original document, author(s) and history
Organization
Documents
Project plan
Glossary
Overview
Function description with overview diagram
Restrictions, future plans
© SAP AG 1999
The process design contains all relevant administrative details. These include the name and location
of the original document, the author or authors, and a version history with dates and status.
The Organization section lists the project and development team members by name, company, and
role in the project. It also contains references to relevant documents and to the project plan.
The Glossary explains new terms, with reference to the component hierarchy and the object model.
The Overview contains a brief introduction to the function you are implementing. This may include a
graphic, showing how the function fits into the system as a whole. From the function description,
you should be able to see the interfaces that exist to other parts of the system. The Restrictions
section contains a list of processes that are not in the project, but might have been expected. Under
Future plans, you can add other user requirements as they arise during the project.
(C) SAP AG MBC40 92

Producing the Process Design (Template 2)
Program development
Prerequisites
Process model
Descriptions of individual functions
Information development
Project marketing, training, documentation
Data volume, performance
User interface, standards
© SAP AG 1999
In the Program development section, you describe the function from the user's point of view. This
description comprises the prerequisites for the development (for example, R/3 Release, database
release, operating system release). In the process model, you illustrate the functional relationships.
This may be in text or graphical form. It must make clear the interfaces that exist between the new
functions and other parts of the system. From the process model, you can identify the individual
functions. For each of these, you must describe the input data (database table, interactive, version-
led), the processing (authorizations, process flow of the function, calculations, object statuses, error
handling, use of user exits, Customizing), and the output data (contents, layout, availability, change
documents, archiving). In the Restrictions list, you describe the functions that would be possible in
the context of the process model, but are not part of the project. You must also explain the error
handling process for the development, and the Customizing requirements.
In the information development section, explain your project marketing, documentation, and training
plans. Remember to include translation requirements for multi-lingual developments.
The Other considerations section should take into account data volume, throughput (performance for
background processing) and response times. You should also describe the user interface and the lists
and forms that you will be using. The Standards contains the naming conventions and programming
standards for the project. The Conditions for use describe data backup, archiving, and the ability of
the application to restart following a program termination.
(C) SAP AG MBC40 93

Example: Process Requirement in SD
Process requirement:
We want to be able to see from an
SD order whether it was taken by
telephone sales.
© SAP AG 1999
In this course, we will produce a process design and a technical design and later implement the
following requirement: We want to be able to see from an SD order whether it was taken by
telephone sales.
The appendix to this unit contains a detailed process design.
(C) SAP AG MBC40 94

Technical Design: Contents
Process modeling, showing data or message flow

Object and data modeling
Planned modularization units
Description of the user interface, lists, and forms
Implementation (development in customer namespace
using the enhancement concept, Modification)
© SAP AG 1999
In the technical design, you describe the functions you intend to implement, based on the process
design, but from a technical point of view. You should write the technical design in sufficient detail
for the technical implementation (data modeling, programming) to follow on directly from it.
To enable you to do this, you must model the data and processes in detail and work out the
modularization units that you will use. You must also include a technical description of the user
interface, and any lists and forms.
You must examine the implementation possibilities for each data object and process:
Development in customer namespace (Y* or Z* programs)
Enhancement concept, or
Modification of the SAP standard
If your technical design contains options that would not have required modifications but that have
been discarded, give your reasons for choosing a solution involving modifications.
(C) SAP AG MBC40 95

Technical Design: Objectives
Convert the process design into a technical model

Produce a detailed blueprint for the technical
implementation
Prepare for subsequent development phases
Provide a basis for functional test plans
Provide the basis and justification for subsequent
changes caused by changes in the process design
© SAP AG 1999
The aim of the technical design is to produce a technical analysis of the functions you want to
implement that is based on your process design. It translates what the business process requires into
what the technical solution can provide.
The technical design is a basis for the subsequent development phase (implementation) and for the
functional test plans.
If the technical design is changed, studying previous versions will help you to understand why the
changes were made.
(C) SAP AG MBC40 96

Producing the Technical Design (Template 1)
Administration
Original document, author(s) and history
Organization
Documents
Project plan
Process model
Object and data model
Objects
Relationships between objects
Tables
© SAP AG 1999
At the beginning of your technical design, you should include the relevant administrative details
(name and location of the original document, author or authors, and a version history of the
document with date and status).
The Organization section lists the project and development team members by name, company, and
role in the project. It also contains references to relevant documents (especially to the process
design) and to the project plan.
The Process model section should present the process you want to implement, either as text or
graphically. If you have already done this in sufficient detail in the process design, you can refer to it
here. The process model contains information about objects (business objects), functions (methods of
the objects), conditions and alternative paths, input and output (data and message flow) and events.
You can also refer at this point to modularization units (for example, function modules),
Customizing information, interfaces, or Workflow objects.
The Object and data modeling section describes the individual objects (entity types) and explains the
relationships between the objects (relationship types) using the details from the Data Modeler. In this
section, you also describe the tables that you will use (name, description, use, and maintenance),
referring to the data, structures, and check tables from the ABAP Dictionary.
(C) SAP AG MBC40 97

Producing the Technical Design (Template 2)
Modularization units
User interface
Interaction model
Screens
Print lists and forms
Short description of each list and form
Reference to objects in the R/3 System
Other considerations
Compatibility
Conversion requirements
© SAP AG 1999
In the Modularization units section, you describe which functions are to be implemented in which
modularization unit (program, function module, method, or form). You can use program flow
diagrams, Nassi-Shneiderman diagrams or pseudocode to describe the functions.
You describe the user interface in an interaction model. This contains the sequence of screens
(graphic), the distribution of the functions to menus, pushbuttons and function keys, and describes
the configurability of the screens. Under Screens, describe the layout and flow logic of each screen.
You can create a prototype user interface in the ABAP Workbench using the Screen Painter, Menu
Painter, and ABAP Query.
Under Print lists and forms, describe the contents and structure of any lists and forms you intend to
use. The description should include the list or form header, the fields used, and a content summary.
As the implementation phase goes on, you will be able to refer to Repository objects in the system
for modularization (programs, function modules, methods, and forms), user interface (module pools,
reports), lists and forms (reports and forms) in the technical design.
Under Other considerations, you can comment on compatibility with previous versions, conversion
requirements for existing data, and any open issues.
(C) SAP AG MBC40 98

Example: Technical Considerations for SD Order
Customizing
Is there a standard function that No, there is no
can be tailored to meet the customer's ... suitable field in the
needs using Customizing document header
or personalization?
No
Can a similar function be found in Yes, only one detail

the SAP Standard System? ... is missing from the
Development
SD document
management
Yes
Does the existing application Yes -

allow you to use enhancements • Append to VBAK
to implement the required • New field using
function? user exit SAPMV45A
© SAP AG 1999
In the technical analysis, you must decide the change level at which you can implement the business
process requirement (see Classifying and Implementing Development Projects in the Change Levels
unit).
Our requirement from the SD application cannot be met using Customizing, but transactions VA01
(create order), VA02 (change order) and VA03 (display order) already provide basic order
management functions in the standard system. Only an appropriate field is missing.
The requirement can be met using the enhancement concept as follows:
By appending to VBAK (table structure for the order header)
By using a user exit, allowing us to place the new field on the Additional data B screen of the
order administration program (program SAPMV45A).
We do not need to use a modification, which would have required manual adjustment in a system
upgrade.
The detailed technical design is contained in the appendix to this unit.
(C) SAP AG MBC40 99

Critical Factors for Process & Technical Analysis
No conflicts
Possible to implement
Justifiable
Derivable results
Performance
Ability to be updated
Version management
© SAP AG 1999
The process design and technical design must come from the requirements of the users. In particular,
there must be no conflicts between the process design and the technical design.
It must be possible to implement the functions described in the technical design within the resources
available (personnel, budget, systems).
Everyone involved in the project must have a good grasp of the contents of both the process design
and the technical design.
The technical design must be directly derived from the process design. In turn, it must be possible to
deduce the implementation steps directly from the technical design.
The process design specifies the volume of data that needs to be processed, along with acceptable
throughput and response times. After implementation, you can judge the technical design on the
basis of whether these specifications have been met.
If changes are made to the process design or technical design, studying previous versions of the
relevant document can help you to understand why.
(C) SAP AG MBC40 100

Process Design Review
Content
Independent evaluation of the plan
Complete and correct
Consistent and user-friendly
Oriented towards the result, not the method
Style
Lists or tables of key words
Comprehensible (consistent level)
Structured, modular design
Form
Versions
Formal division of sections
© SAP AG 1999
When you evaluate the content of your process design, you should ensure that the required functions
have been described fully and correctly. There should be no conflicts or inconsistencies in the
descriptions of the individual functions, neither should they contain any information that belongs in
the technical design. The process design should make sense to someone who does not know the
process that it describes. It should provide a direct basis for integration test plans. It should also
describe the user interface, lists, forms, and both online and offline interfaces in detail.
As far as style is concerned, you should use short, meaningful descriptions in the form of tables or
overview lists, not long prose descriptions. You should ensure at all stages that you are addressing
the reader at a consistent level. Use a structured modular design for the document, and ensure that
the main thread of the argument is recognizable at all times.
Keep to a formal division of sections in your process design, and keep different versions.

Technical Design Review
Content
Comprehensible process and data model
Reusability, easy and efficient maintenance
Functional test plans easy to derive
Style
Presented at a consistent level
Form
References to the process design
Formal division of sections
Update
Additions following implementation
© SAP AG 1999
When you review the content of your technical design, you must check whether the functions
described can be implemented with the available resources (personnel, budget, systems). The process
model and data model must be comprehensible to all team members. It must be possible to
implement the planned Repository objects efficiently, and they must be easy to maintain. You should
be able to derive a function test plan from your technical design. The ease with which you produced
the technical design from the process design is a criterion against which you can judge its success.
Above all, the content must not contain any conflicts.
In examining the style, you must ensure that you address the reader at a constant level, and that the
document is modular and well-structured.
Ensure that your technical design conforms to the formal division, and that you have kept different
versions. Any references to the process design must be precise. The user interfaces that you describe
must conform to the SAP Style Guide. You should quote the names of any Repository objects that
have already been created.
You should also ensure that you add program names and screen numbers to the process model and
table and structure names to the data model after implementation.

Summary
The process design and technical design are parts of

a customer development project based on the
Business Blueprint
The process design describes the planned function
from the user's point of view
The technical design describes the planned function
from the technical point of view
Use standard templates to create both the process
design and technical design
© SAP AG 1999

Process Design and Technical Design: Exercise
Review
• Perform concept review

• Learn about the case study that will be implemented in the next unit
On the following pages, you will find a process design and a technical
design of an ABAP development project. The goal of this development
project is to incorporate a call center into sales order administration.
There are several errors on the following pages. Analyze the process
design and the technical design and try to find these errors.

Version 3.0
05/10/98
Call Center Reference in Sales

Order Management
Process design

Original Document
The original version of this document is stored in \\xyz under the file name
CALL_CENTER_CONCEPTUAL_DESIGN.
Author(s)
Fritz Facher
History
Version 1.0 Draw 04/27/98
Version 2.0 Draw 05/06/98
Version 3.0 Submitted for release 05/10/98

Organization
Name Company Role / Notes
Knut Leider IDES AG Project manager
Fritz Facher IDES AG Process manager
Carl Clever IDES AG Developer
Anke Freund IDES AG Technical support
Udo Kundig SAP AG Workbench consultant
Documents
Business blueprint IDES AG

Technical design Call Center Reference in Order Management
Project plan
Prototype: by 04/30/98
Development and function test: by 05/29/98
Integration test: by 06/19/98
Live: from July 6, 1998
Glossary
Sold-to party
Business partner who arranges deliveries and services
Call center
Organizational unit that receives and records customer inquiries and sales orders in telephone sales
Billing
Generic term for invoices, credit memos, debit memos and reversal documents
Sales order
Contractual agreement between sales organization and an ordering party for delivery of materials at specific
prices, in specific volumes and to specific deadlines
Delivery
Sales and distribution document for processing a goods delivery
Material
Product, substance or object which is transacted, employed, utilized or produced during production. A material
can also be a service

Availability check
Inventory audit that occurs automatically with every goods movement to prevent the book inventory (balance) of
the physical stock from becoming negative
Sales organization
Organizational unit which is responsible for the sales of products and services. The sales organization is used to
manage the way in which an enterprise subdivides markets according to geographical or industry-specific criteria.
Each business transaction is processed by one sales organization
Sales and distribution document

Proof of a business transaction in sales and distribution processing. A distinction is made here between sales
documents, shipping documents and billing documents.
Overview
Description of function
A sales order is created using the transaction Create sales order (VA01). It should be clear from the sales order
which call center is accepting and recording the sales order.
Overview graphic
Customer orders
goods by telephone
Create sales order
Trigger delivery
Bill
The call center is specified on the header of the sales order.
Restrictions list
Goods ordered in writing or via the Internet are not included in this analysis.

Program development
Process model
An end customer (distribution channel 10) orders a material. This can be done in the following ways:
• In writing (letter/fax)
• By telephone
• Using the Internet.
Following this, an order is created in Sales and Distribution. When creating an order, in addition to fields such as
ordering party, requested delivery date, material and order quantity, the call center records the time at which the
order was taken by telephone.
The information gathered in the order is transferred into the subsequent documents. These documents are used to
further process the business transaction:
• The goods are delivered to the customer using delivery and goods issue posting.
• The transaction is concluded by billing, with the customer being invoiced for the goods delivered and the
services provided.
Descriptions of individual functions
Definition of call centers
Input data
Identifier and text for a call center
Processing
Identifier and text of a call center are created in a user-defined Customizing table. It should be possible to
maintain the call center text in the language supported.
In the call center table, an entry is required if a sales order has not been taken by telephone.
Output data
Table of call centers
Call center reference in order management
Input data
Call center ID
Processing
When creating or changing orders, you should be able to enter the call center ID. In addition to the call center
ID, the call center text should be displayed in the logon language. For this purpose, use the domain SPRAS,
provided by SAP.
When displaying orders, the call center ID and call center text should be displayed.
The call center should appear on the main screen for the order management transactions VA01 (Create sales
order), VA02 (Amend sales order) and VA03 (Display sales order).
Output data
Sales orders with call center reference

Sales by call centers
Input data
Volume of sales orders
Processing
A list is produced which gives the individual sales orders for a call center and the total of all orders for a call
center. The list should be similar to the one below:
Call center ID Order Order item Net amount (items)

----------------------------------------------------------------------------------------------------------------
FRA 90005286 000010 2,847.20 DEM
Total call center FRA 2847.20 DEM
------------------------------------------------------------------------------------------------------------------------
NYC 90005286 000010 5,500.00 DEM
NYC 90005287 000020 22,000.00 DEM
Total call center NYC 27,500.00 DEM
------------------------------------------------------------------------------------------------------------------------
SYD 90005285 000010 40.120,00 DEM
SYD 90005288 000020 2176.00 DEM
Total call center SYD 42,296.00 DEM
------------------------------------------------------------------------------------------------------------------------
Sum total 72,643.20 DEM
Output data
List of call centers with sales volumes
Customizing
The call centers are stored in a user-defined Customizing table.
Information development
Documentation
The field Call Center should be supported by F1 (Help).
Translation
The contents of the call center table must be translated into English and French.

Data volume
Around 200 orders a day are taken worldwide. 120 of these are taken over the telephone.
Response times
The dialog response times in order management should not exceed one second.

Version 1.0
27/07/98
Call Center Reference in Sales

Order Management
Technical
design

Original document
The original version of this document is stored on \\xyz under the file name
CALL_CENTER_DETAILED_DESIGN.
Author(s)
Carl Clever
History
Version 1.0 Submitted for release 04/27/98

Organization
Name Company Role / Notes
Knut Leider IDES AG Project manager
Fritz Facher IDES AG Process manager
Carl Clever IDES AG Developer
Anke Freund IDES AG Technical support
Udo Kundig SAP AG Workbench consultant
Documents
Business blueprint IDES AG

Technical design: Call Center Reference in Order Management
Project plan
Prototype: by 04/30/98
Development and function test: by 05/29/98
Integration test: by 06/19/98
Live: from July 6, 1998
Process model
See Chapter 4.1 Process Model in the process design
Objects, data and tables
Object and data model
Graphic 1: Data model YSDORDER
SAP Enterprise Data Model
Call center and

order management
11001 CV Y16002 T
Logical H Sales
system order
Time
H
19013 V
H
YCALLCENTER
Call
T
CR
Language
center

Tables
The table YCALL is assigned to the entity type YCALLCENTER. This accepts all call centers with a language-
dependent short text.
Field name Key Type Length Description

YMANDT CLNT 3 Client
YCALLID CHAR 3 Call center ID
YSPRAS LANG 1 Language key
YCALLTEXT CHAR 30 Short text call center
The SAP table VBAK contains the header information for a sales order. The order reference for the call center is
entered via the field YCALLID in the table VBAK. YCALLID is implemented as append YAVBAK to the table
VBAK. YAVBAK has the following structure:
Field name Key Type Length Description

YYCALLID CHAR 3 Call center ID
The field YCALLID in the table YCALL is the foreign key for the field YYCALLID of the append YAVBAK.
Modularization units
Programs
The main program for order management is SAPMV45A. The screen 8309 is intended for additional fields which
the end-user can maintain and display in the screen "Additional data B".
Function modules
The function module GET_CALL_CENTER_TEXT determines the call center ID short text for a specific language.
User interface
Interaction model
The end-user calls up the request management using the transactions VA01 (Create order), VA02 (Amend order) or
VA03 (Display order). In these transactions the end-user has the possibility via Goto → Header → Additional data
B to maintain or to display the field Call Center.
Screens
Screen 8309, Program SAPMV45A
The screen Additional Data B should be structured as follows:

Screen 8309 must call up the function module GET_CALL_CENTER_TEXT before displaying the screen. The
short text for the call center entered should be displayed next to the input field.
The actual update of the call center reference in the table VBAK closes an update function module called up by
SAP.
Other considerations
Compatibility
The described technical analysis is based on the complete table work area VBAK and not a selected field from this
being updated by the SAP function module.
Conversion requirements
The sales orders recorded to date should be left without call center reference. By creating the append YAVBAK on
the table VBAK, from an ABAP point of view all the entries obtain a value SPACE and thereby have no further
conversion requirements even though they do not have a call center reference.

Implementation

1 Change Levels
Technical Design
5 Standardization
© SAP AG 1999

Implementation
Contents:
Putting the process model and data model into practice
ABAP basics
Writing to the database
Reading and displaying data
Data transfer
Documentation and translation
Objectives:
Explain the concepts of the ABAP Workbench
List the special features and critical success factors
involved in ABAP programming
© SAP AG 1999

oring
p m e n t •Monit
design •Develo •Tuning
•Process n it t es t ing e
•Technic
al •U
t a t io n •Chang nt
ign •Do cu m e n
ma n ageme
des
•Training de
•Upgra ment
e
•Integratio
n manag
team
•Project ds cape testing
n ing
•Syste m la •Mass test
ds sfer
•Standar •Data tran
© SAP AG 1999

Putting the Data Model into Practice
Putting the data model into practice
Putting the process model into practice
Basics
Data transfer

© SAP AG 1999

ABAP Dictionary
ABAP Workbench
Repository ABAP Function Screen Menu

Dictionary
Browser Editor Builder Painter Painter
Real
World
The ABAP Dictionary is
an active component
Data when you run a program
Datamodel
model
It is integrated into all
ABAP other tools in the ABAP
Dictionary
Workbench.
Database
© SAP AG 1999
The ABAP Dictionary provides active support when you create new programs or maintain existing
components. Its role as a central tool means that information only has to be entered once, and is then
available anywhere in the system. The R/3 runtime environment ensures that objects always work
with the most up to date definitions from the ABAP Dictionary.
During a development project, you can change ABAP Dictionary objects any number of times before
activating them. They are only available in the system once they have been activated. This ensures
data integrity, consistency, and security.

Example SD: Appending to Table VBAK & VBRP
ABAP Dictionary
ZZADVFLAG
Table VBAK
Field 1 Field 2 Field 3 Append ZAVBAK
SAP Customer
Field 1 Field 2 Field 3 ZZADVFLAG
R/3 database
© SAP AG 1999
Here, we implement the data model we developed in the technical design:

First, we add field ZZADVFLAG to table VBAK (order header) using a table append.
Now we must make it possible for the user to enter data in the field on the screen (program
SAPMV45A) (see Example: New Field For Orders, Additional Data B).

Critical Success Factors: Data Model/Dictionary
Application and Customizing tables

are client-specific
References to amounts, quantities, units, date/time,
text
Understandable, process-oriented data element
documentation (F1 help) for end users
Possible entries help (F4 help) using check tables or
fixed values
Alignment with third standard form
Controlled redundancy
© SAP AG 1999
Ensure that application and Customizing tables are client-specific.

Assign a currency key to currency amount fields, units to quantities and measurements, a time zone
to time or date fields, and a language key to language-specific texts.
Data element documentation should be process-oriented and clear to the end user.
You can use check tables or fixed values to provide users with possible entries help.
Table design should be in accordance with the third standard form, performance or modification
reasons permitting (controlled redundancy).

Putting the Process Model into Practice
Basics
Data transfer

© SAP AG 1999

Data Structure (Language and Dictionary)
Data type
Predefined User-defined
Elementary Structured
Structure type Table type Class/interface
ry
na
io
m
ct
ra
Di
og
AP
pr
AB
AP
AB
© SAP AG 1999
The ABAP type concept is based on the following ideas:

User-defined data types can be either elementary or structured. Elementary types cannot be broken
down into other, smaller components. Structured types, on the other hand, consist of any number
of elementary or other structured types.
There are two types of structured data type - structure types and table types:
- Components of any type can be combined to form a structure type (using other terminology:
records).
- Table types (known as arrays in other terminology) can be made up of lines of any type.
Data types that are structure types or table types may contain other structure types or table types as
elements.
ABAP types can be defined either locally in an ABAP program or systemwide in the ABAP
Dictionary. In the ABAP Dictionary,
user-defined elementary types are called data elements
user-defined structure types are called structures.

ABAP Keywords
Declarative keywords
TYPES, DATA, CONSTANTS, PARAMETERS, SELECT-OPTIONS, ...
Event keywords
START-OF-SELECTION, GET, TOP-OF-PAGE, AT USER-COMMAND, ...
Control keywords
IF, CASE, DO, WHILE, CHECK, EXIT, PERFORM, CALL FUNCTION, LOOP, ...
Operational keywords
MOVE, COMPUTE, CLEAR, AUTHORITY-CHECK, ...
© SAP AG 1999
ABAP keywords can be classified into declarative keywords, event keywords, control keywords, and
operational keywords.
For a full list of ABAP statements, open the ABAP Editor and choose Utilities → Help about →
ABAP Overview → ABAP keywords by type.

Modularization
Transaction SUBMIT <prgname>

code, Menu, Program
Program
Report tree
CALL TRANSACTION Transaction
End user
<trancode>
local global
Conventional Subroutines Function modules
Created with ABAP Editor Function Builder
Definition FORM ... ENDFORM FUNCTION ... ENDFUNCTION
Call PERFORM CALL FUNCTION (incl. remotely)
Object-oriented Local classes Global classes

Created with ABAP Editor Class Builder
Definition CLASS ... ENDCLASS CLASS ... ENDCLASS
Call CREATE OBJECT CREATE OBJECT
© SAP AG 1999
The basic modularization units within an ABAP program are subroutines, function modules, and
classes:
Subroutines
- Are defined locally within a program
- Are designed using FORM ... ENDFORM, and called using PERFORM
Function modules
- Are defined globally in the Function Builder. In Release 4.0A, SAP released 735 function
modules for customer use
- Are defined using FUNCTION ... ENDFUNCTION, and called using CALL FUNCTION
- Can also be called in remote system (by Remote Function Call. This is covered later in the
course.)
Classes
- Are defined either locally within a program, or globally in a class library
- Are defined using CLASS ... ENDCLASS, and instantiated using CREATE OBJECT
- These modularization units have an interface for passing references or values. There is a
difference between local data in the modularization unit and the global data of the main
program.

Using ABAP Objects for Customers
State-of-the-art programming model

Modularization of complex customer programs with
encapsulation polymorphism and inheritance
Class methods, interfaces and events
are supported (similar to Java)
Coexistence and integration of ABAP Objects with ABAP
Object orientation in the R/3 standard
Enjoy controls
Business add-ins
Office integration and integration of graphics
© SAP AG 1999
ABAP Objects is released for customer programs as of R/3 Release 4.5. It is fully integrated into
ABAP.
Customer programs can benefit from ABAP Objects in the following ways:
Improved modularization
Enjoy controls, Business add-ins and Office integration are based on the ABAP Objects
programming model:
Use of Enjoy controls in customer programs for user-interface in R/3 Enjoy look & feel
Use of business add-ins (see unit Change Levels)
Integration of Office products (for example, word processing, spreadsheets) into R/3

Critical Success Factors: Implementation (1)
Early use of program analysis tools

Security (authorization concept)
Authorization checks in the program
(AUTHORITY-CHECK)
Customer-defined authorization objects
Performance
SQL
Operations on large internal tables
Communication
© SAP AG 1999
You should start using the program analysis tools (see Quality Assurance) during the program
development phase.
Note the general points about evaluating customer development projects made in the Change Levels
unit.
The ABAP Open SQL statements (SELECT, INSERT, UPDATE, MODIFY, and DELETE) do not
have any built-in authorization checks. You must protect any data that should not be universally
available by checking the user master record of the end user (AUTHORITY-CHECK statement). If
your data model includes objects that you want to protect, you can include them in your own
authorization objects.
The most performance-critical areas of programming are read and write accesses to the database
(SQL), operations on large internal tables, and communication with other systems.

Critical Success Factors: Implementation (2)
End-user acceptance
SAP look and feel (see ergonomic
examples, Style Guide)
F1 and F4 help
Portability
Modularization
© SAP AG 1999
To make your application more acceptable to end users, you should design your screens and lists
according to the SAP ergonomic examples, and provide users with F1 (field) and F4 (possible
entries) help.
Avoid using ABAP statements that restrict the portability of your application:
Native SQL in the EXEC SQL interface
Programming on a particular codepage (for example charfield1 > charfield2).
Use the modularization techniques available in ABAP. This makes your programs easier to
understand, reuse, and maintain.

Writing to the Database
Basics
Data transfer

© SAP AG 1999

SAP LUW
Simple
business process
Process Process Process

step 1 step 2 ... step n
SAP LUW
© SAP AG 1999
An SAP Logical Unit of Work (LUW) contains a series of steps in a business process in the R/3
System that logically belong together.
The steps in the process chain of the business process must be logically related.
In an SAP LUW, to preserve data integrity, either all or none of the steps in a process chain are
processed.
The business process represented in an SAP LUW must be simple. For example, the entire process
from customer order to billing is too large to be included in a single LUW. Instead, you would
separate the various processes into individual steps that can be executed individually, each of which
would then become an SAP LUW. The final decision as to what constitutes a simple process depends
on the entire process and how you have modeled it.
Conflicting access to data being processed by an SAP LUW is avoided by the ABAP locking
concept.
For further information, start the ABAP Editor and choose Utilities → Help about → Term:
Transaction processing.

Container for a Process Step: Screen
Screen Objects
Screen _ _ _ _
Text field
Subscreen
area
Screen attributes
...
Flow logic
PBO. Title
...
PAI. ... ... ... ... ... ...
...
Box
© SAP AG 1999
A single step in a process is represented on an SAP screen. Screens are dynamic programs,
consisting of the screen itself and an underlying flow logic. This dynamic program controls how the
screen is processed. For further information about programming flow logic, see the ABAP User's
Guide.
Screens are containers for other screen objects, such as text fields, subscreens, input/output fields,
table controls, icons, checkboxes, radio buttons, pushbuttons, tabstrip controls, GUI statuses, and
group boxes.

Example: New Field For Orders, Additional Data B
User exit in development class VMOD

SAP Program SAPMV45A, screen 8309
Create order: Header data

Sales document Edit Goto Extras Environment System Help
Standard order Purch. order no.
Sold-to party 1400 A.I.T. GmbH, Köln

Sales Shipping Partner Payment cards Pricing Status Extras A Extras B
Call Center
© SAP AG 1999
Using the Screen Painter, we can place the field VBAK-ZZADVFLAG on screen 8309 of program
SAPMV45A.
Since transactions VA01 to VA03 read and write using the complete table work area of VBAK, we
do not need any extra coding to take care of this. Since we are also using the same update
mechanism as the SAP program, we can be sure that our field will be processed in the same SAP
LUW as the SAP screen fields.

Critical Success Factors: Writing to the Database
Forming SAP LUWs

Logical locks (SAP locking concept)
Ability to restart after termination
Performance for mass processing
Using array operations
Choice of change mechanism
Parallel processing
Number range buffering
Logging (change documents)
Archiving
© SAP AG 1999
When you write data to the database in the R/3 System, note the following:
Forming SAP LUWs
Ability to restart (ability of the program to restart in a consistent state after an abnormal
termination)
Performance
- ABAP uses powerful array operations for reading and writing data.
- If you change a large number of tables,we recommend that you use asynchronous update.
- You can run database updates in parallel down to the physical level (table space, hard disk,
controller).
- If more than one process is competing for access to a number range, you should consider using
number range buffering.
Logging: You can log insertions, changes, and deletions using change documents.
Archiving: The ABAP Workbench contains administration for archiving objects and an API for
integration with archiving systems.

Reading and Displaying Data
Basics
Data transfer

© SAP AG 1999

Reading and Displaying Data
ABAP Query
Read
Logical database Database
ABAP EXPORT
Open SQL IMPORT
Application
ABAP Query
Display
WRITE Table Control
ALV, Tree, ... Tabstrip
Presentation
Enjoy
controls Web
© SAP AG 1999
In programs that work like information systems, data is read from a database table, processed, and
displayed on a list.
You can use the following techniques to read data in ABAP:
ABAP Query: ABAP Query helps you to generate reports, and is intended for users with no ABAP
programming knowledge. The report that the system generates reads and displays the required
data.
Logical Databases: A logical database is an encapsulated data-reading program for frequent
database accesses.
Direct read: Using ABAP Open SQL or IMPORTING data clusters.
You can use the following techniques to display data in ABAP:
Direct output using the WRITE command, or a table control
ABAP Query
Enjoy controls
Output using HTML Browser (Web)
We recommend that you use ABAP Query for information system programs.

Difference between Queries and Programs
Program List
Database (ABAP)
Program
Query
Program generator
Functional area List definition

(Query)
Create lists using

Program: ABAP statements
Query: Description of the result desired
© SAP AG 1999
When you create a query, you first designate a functional area that is generally made up of a special
view of a series of database tables. You can then choose the relevant fields from the functional area
and define the processing method and format.
When you run the query, a program generator creates a list definition that reads, processes and
displays the data.

Reading and Displaying VBRP Append
Sales per Call Center

List Edit Goto System Help
ABC EIS Selections
CC Billing Pos Net value
FRA 90005286 000010 2,847.20 DEM

Sum Call Center FRA 2,847.20 DEM *
NYC 90005282 000010 5,500.00 DEM

NYC 90005287 000020 22,000.00 DEM
Sum Call Center NYC 27,500.00 DEM *
SYD 90005285 000010 40,120.00 DEM

SYD 90005288 000020 2.176.00 DEM
Sum Call Center SYD 42,296.00 DEM *
Sum 72,643.20 DEM **
© SAP AG 1999
To evaluate the Call Center sales , you can use ABAP Query.

Critical Success Factors: Reading
Performance
Optimal SQL operations
Table buffering
Secondary indexes
Redundant writing of data
Parallel processing
© SAP AG 1999
In performance-critical database access, the programmer must address the following questions:
How much load will the SQL statement place on the database? Are there any possible alternatives?
Would it make sense to buffer the table on the application server?
Does the database query support indexes?
Would it make sense to use redundant writing of data to speed up read accesses?
Would it make sense to process on more than one work process in parallel?
Take notice of the general implementation success factors on the two slides Critical Success
Factors: Implementation.

Enjoy Controls
“I really like the new R/3 –

it works the way I do!”
Container controls
HTML controls
Tree controls
Picture controls
ALV grid controls
TextEdit controls
Window resizing
Drag&Drop
© SAP AG 1999
Controls enable programmers to control complex elements using ABAP.

Controls are software components with independent functions at the front end (for example,
scrolling, navigating, and searching no longer require a connection to the application server).
The various controls can be combined using a container control (see slide).
Some typical controls are:
APAP list viewer control (ALV grid control)
Tree control
TextEdit control
HTML control (for displaying HTML documents in the GUI)
For demonstration programs for Enjoy controls, use the menu path Tools → Development
Workbench → Tools → ABAP Workbench → Development → ABAP Editor → Environment →
Control examples. Or use transaction DWDM.
Enjoy transactions can be identified by the the letter N at the end of a classic transaction code. For
example, Change purchase order: ME22 (classic transaction) and ME22N (Enjoy transaction with
Enjoy controls). Other examples: VL01N, FBL1N, CJ20N.
Use ABAP Objects to implement Enjoy controls.
Enjoy SAP controls are not compatible with batch input and CATT.
Note that with Enjoy controls, the grid load from the application server to the front end is 10 times
higher than with classic SAP GUI controls. This is caused by a considerably greater amount of data
initially being transferred to the front end. On the other hand, no communication is required with the
application server, since operations such as navigating in HTML, tree or grid controls are performed
at the front end.

ABAP and Front End Presentation
ABAP in R/3 Proprietary front end Web browser
DIAG
SAP GUI for Windows
SAP GUI for Java

(Unix, Mac, OS/2)
DIAG
R/3 screen on Web
SAP GUI for HTML
DIAG HTTP
Screens
(with Enjoy controls) HTML
Web transaction
templ. (screen based) IAC
RFC-enabled function DIAG HTTP
modules MiniApp
RFC HTTP ITS flow logic
BAPIs
Web RFC
ITS
Java applet
RFC
VB, C, C++, Java
© SAP AG 1999
ABAP processing can be presented either on an HTML-based Web browser or on a proprietary front
end (SAP or customer-programmed front end). With Web browsers, you have installation freedom.
This is not the case with proprietary front ends. For Windows, SAP delivers the SAP GUI for the
Windows Environment. For Unix, Mac and OS/2, SAP delivers the SAP GUI for Java.
The SAP GUI for HTML generically converts the SAP proprietary front end log DIAG into HTTP.
You can thus display R/3 Screens generically in a Web browser.
The Internet Transaction Server (ITS) connects one or more HTTP servers with with or more R/3
Systems. Using the ITS, Internet or intranet users can execute Web-enabled transactions, or Web-
enabled function modules. From the perspective of the R/3 System, the ITS and HTTP servers form
a level between the application and presentation level. From the Internet user's perspective, the ITS
enables interactive HTML pages (generated at runtime).
The HTTP servers supported are Microsoft Internet Information Server and Netscape Enterprise
Server. The Web browsers supported are Microsoft Internet Explorer and Netscape Navigator. These
programs can process, for example, HTML, JAVA and JAVAscript.
Web transaction is a screen-based programming model. ITS FlowLogic and WebRFC are not screen-
based.
A Web transaction consists of three parts:
Web-enabled R/3 transaction
Service file
HTMLBusiness templates (there is a template for each screen; this template is converted to an
HTML page at runtime)
WebRFC calls special function modules in R/3 using the ITS. The HTML code is created in the R/3
System.

Choosing a Web Programming Model
Use
Web transaction, if
your R/3 release is 4.5 or lower, or
you already have an R/3 transaction with simple
screens (without controls)
ITS flow logic, if
your R/3 release is 4.6 or higher, or
you do not have an R/3 transaction with simple
screens
© SAP AG 1999
For the various Web programming models, your programmers need knowledge of the following
topics:
Web transaction:
- ABAP
- HTML
- HTML Business
ITS flow logic:
- ABAP
- HTML
- HTML Business
- ITS flow logic
WebRFC:
- ABAP
- HTML

Characteristics of Transactions
IAC Standard R/3 transaction

High performing
Simple
(for processing in all
(Easy Web Transaction)
situations)
Intended for general use
Intended for
(large number of users)
professional users
Users do not receive training

Users receive training
(none required)
Use of multimedia
and hyperlinks
to other systems
© SAP AG 1999
A Internet Application Component (IAC) makes a small part of the wide range of R/3 functionality
suitable for Web use. This means that Internet users who have not had training can use certain
functions.

Critical Success Factors: Front End Presentation
Hardware enhancements
ITS, Web server
Front end
Increased grid load
DIAG without Enjoy controls: 1-2KB for each dialog step
DIAG with Enjoy controls: 10KB for each dialog step
HTTP: 100KB for each dialog step (compressed to 10KB)
Object-oriented knowledge of programming
Knowledge of Web programming
(ABAP plus HTML, HTML Business,
ITS flow logic, JAVA, VB, C, ...)
© SAP AG 1999
The grid load for the HTTP log is approximately 10 times higher than for the SAP log DIAG with
Enjoy controls. The grid load of HTTP compared with DIAG without Enjoy controls is even around
100 times greater.
For Web presentation, users need knowledge of HTML and Java as well as of ABAP and ITS.
The object-oriented programming model is implemented in ABAP Objects and Java.
ITS Version 4.6D allows the compression of HTML pages between Web server and Web browser
(50 to 90%).

Data Transfer
Basics
Data transfer

© SAP AG 1999

Communication vs. File Transfer & Data Transfer
SAP R/3
External system
Communication
RFC
IDOC/ALE
Data transfer
File transfer & data transfer
Structure of Standard batch/direct input

CALL TRANSACTION USING
legacy system IDOC/ALE
Conversion
Flat file in R/3 structure

© SAP AG 1999
You can connect external systems to the R/3 System as follows:

File transfer and data transfer (see slides about data transfer)
Communication (online connection between two systems).
The R/3 structure can be:
For data transfer with standard batch input or direct input: Flat file in the relevant format
For data transfer with ALE: IDoc

Critical Success Factors: Communication
Systemwide data consistency

Ability to restart after termination
Error tolerance and correction
Performance
Security
Availability
© SAP AG 1999
The LUW principle (compare Writing to the Database) can be ensured across systems with ABAP
keywords.
If an application error occurs that could prevent automatic processing, an automatic message should
be sent to the administrator responsible.
The following mechanisms contribute to the security of the interface:
Authorization checks in receiving system
Authentication of the sending system
Encryption of the data packages

Data Transfer: Legacy System Migration
External system SAP R/3
Data transfer
LSM Workbench
Structure of
legacy system
Conversion
Flat file in R/3 structure

© SAP AG 1999
Data from legacy systems can be converted to R/3 data structures and transferred into the R/3
database using the LSM Workbench.
The LSM Workbench migrates legacy data at data object level (such as material master, debitor
master, creditor master), not at table level.

LSM Workbench
Legacy
system
data Conversion
log Batch input
session
Error
log
Transfer
Spreadsheet Conversion program
interface program (BI, DI)
Direct input
session
Conversion
rules Flat file
Check
against
Customizing
© SAP AG 1999
The Data Transfer Workbench generates conversion programs and uses standard programs to import
the legacy data into the R/3 database.
For the most important master and transaction data, SAP supplies data transfer programs that are part
of the Data Transfer Workbench. If no SAP data transfer program exists (most likely in the case of
customer-defined data structures), you can define new data transfer objects and generate the relevant
programs using the Batch Input Recorder.

Critical Success Factors: Data Transfer
Quality of old data

Data cleanup (especially when importing
data from more than one system)
Planning the dependencies of data transfer objects
Archive handling
Portioning
Performance
No unnecessary dialog steps in batch input or
call transaction Program (e.g. no F4 help in
batch input folders, save as early as possible)
Call transaction vs. batch input
Parallel data transfer programs
Checks (numbers, totals) for quality control
© SAP AG 1999
When you transfer legacy data, consider the following:

Quality of the data: Schedule resources for a data cleanup if necessary
Dependencies between different data transfer objects
How to handle archiving
Optimize batch input folders by repeating recording to remove unnecessary dialog steps. Only
process the dialog steps that are really required, that is, do not record F1 or F4 help, and save the
data as early as possible.
When importing your legacy data, consider to splitting up large quantities of data into several
portions, which you can then import simultaneously using a series of background work processes.
Statistics against which you can check the quality of the data transfer (number of records, sums of
columns)

Documentation and Translation
Basics
Data transfer

© SAP AG 1999

Example: Docu. for Data Element ZZADVFLAG
Data element Create order: Header data
Call Center
Doc.
?
© SAP AG 1999
In our example, we can write end-user documentation for data element ZZADVFLAG. This appears
when the user presses F1 with the cursor in our additional screen field.

Translation
Texts can be translated using

the Translation Organizer
Access using
Worklist
Single object
© SAP AG 1999
In the R/3 System, you can use the Translation Organizer to translate any texts you have written.
Choose Tools → ABAP Workbench → Utilities → Translation → Short/Long texts.
For translating, use your worklist. If necessary, you can also call individual objects directly.

Critical Success Factors: Translation
Multilingual awareness
Centrally-established master language
Translation considerations
Use text symbols
Make text fields 50% longer than
the actual English text
Do not use a series of individual texts
to make one long text
Codepage-independent programming
1 character = 1 byte?
String manipulation
Programming using offset and length
IF charfield1 > charfield2 ?
© SAP AG 1999
Establish a master language for your development project.

If your own development work is going to be translated into other languages, observe the following
rules:
Use text symbols instead of texts for screen objects that cannot otherwise be translated (such as
output in lists).
Make your text fields 50% longer than the English text requires.
Do not use a series of individual texts to make up one longer text.
Multi National Language Support (MLNS) requires that you program independently of codepages.
Avoid ABAP statements that assume "one character = one byte" (for example, using offset and
length) or that are based on a particular character order.

Summary: Workbench Tools
Test
tuning Debugger, ABAP Trace, SQL Trace, Workload, Test Workbench, CATT
Coordination
of transport Workbench Organizer
Transport system
Programs ABAP Editor, ABAP Query, Menu Painter Business Object

Function Builder, Class Builder, Screen Painter Builder,
DB2/400
Context Builder Workflow
Data
description ABAP Dictionary, Data Modeler
Navigation
© SAP AG 1999
The development tools in the ABAP Workbench allow you to create and maintain the following
objects:
Data Modeler: Enterprise data models according to SAP SERM
ABAP Dictionary: Descriptions of application data objects and their relationships
ABAP Editor: ABAP source code (for example, programs, function modules)
ABAP Query: Reports (without using ABAP coding)
Function Builder: Function modules (global subroutines)
Class Builder: Global classes for ABAP Objects
Context Builder: Contexts (buffered results of functional relationships)
Menu Painter: Menus, toolbars, and function key settings
Screen Painter: Screens and their flow logic
Business Object Builder: Business objects (represent central business objects such as general
ledger or G/L account document)
Workflow Wizard: Workflow (Series of steps to be processed by people or the system)
Workbench Organizer: Change requests, to ensure orderly development and transport (in
conjunction with the transport system)

Summary
The ABAP Workbench is a set of powerful tools that

are all accessible from the Repository Browser
With the ABAP Dictionary, data descriptions
are centrally stored
The Screen Painter and the Menu Painter
are used for user interface design
ABAP Query and logical databases
are used for reading data
ABAP enables interfaces from R/3 to R/2, R/3 to
external servers and desktop applications
The LSM Workbench aids is used for
legacy system data migration
With the Translation Organizer, you can translate
texts into other languages
© SAP AG 1999

Quality Assurance

1 Change Levels
Technical Design
5 Standardization
© SAP AG 1999

Quality Assurance
Contents:
Program analysis
Test organization and Test Workbench
Status report and handover
Objectives:
Identify the various review options
Organize and conduct tests using the Test Workbench
Organize status reports and handover
© SAP AG 1999

ring
•Monito
•Tuning
ment e
design •Develop •Chang
•Process ment
ical •Unit testin
g m an e
a g
e c hn de
•T
•Documenta
tion •Upgra
design ment
•Training manage
test
•Project t
eam •Integration
test
•System la
ndscape s •Acceptance
review g
r d
•Standa •Co
s nc e pt •Mass testin er
H andov
•
© SAP AG 1999

Program Analysis
Program analysis
© SAP AG 1999

Manual Program Analysis (Source Code Review)
Meeting the requirements

IF var = str Modularization and structured
PERFORM
ENDIF.
programming
Performance (especially SQL)
© SAP AG 1999
In the source code review, experts examine ABAP source code to ensure that it meets the functional
requirements. They also check the modularization (structured programming), performance
(especially SQL and internal table operations), and the quality and quantity of program
documentation.

Program Analysis Using Tools
Syntax Syntax check Errors

Static analysis
Warnings
Extended program check
Program
termination Dump analysis Runtime errors
Meeting
require- Dynamic analysis Debugging Memory contents
Debugging
ments General memory information
Program interruption
Perfor- ABAP
ABAP runtime
runtime Program flow
mance analysis
analysis
Runtime measurement
Memory requirements
SQL
SQL trace
trace Database accesses
Test Workload
Workload Network, operating system
Database, buffer
Test
Test
Workbench
Workbench Automatic tests
© SAP AG 1999
The ABAP Workbench contains a range of tools for analyzing programs:

In the static check, the system checks the syntax and semantics of the program (for example,
whether the number and types of the parameters passed to a subroutine are correct).
The dump analysis allows you to examine runtime errors.
The dynamic program analyses are performed while a program is running:
- In debugging, you can set breakpoints, and display the attributes and contents of fields.
- ABAP runtime analysis allows you to analyze the flow, runtime, and memory requirements of a
program.
- The SQL trace enables you to analyze SQL statements.
- The Workload Analysis shows the system load. When users are working, the system writes
statistic records, which are displayed by various criteria in the Workload Monitor.
- The Test Workbench allows you to compare the expected behavior of a transaction with its real
behavior. The CATT Workbench provides tools that allow you to manage the results of manual
and automatic tests.

Test Organization and Test Workbench
Program Analysis
© SAP AG 1999

Roles in Quality Assurance
Support Project manager
Report Budget General

cooperation
Quality Process
coordinator coordinator
Scheduling
Quality
assurance Test coordinator Development
consultant
Problem
messages
Tester Developer
Solutions to
problems
© SAP AG 1999
The above chart shows the information flow for the roles described in the unit Project Team:
Quality coordinator:
- Coordinates quality assurance activities
- is responsible for reviews
- Creates status reports for project management
Test coordinator:
- Sets up the test catalog
- Coordinates test case entries, working closely with the process coordinator
- Organizes integration testing, acceptance testing and mass testing
Tester:
- Manually processes test cases or CATT procedures
- Creates test logs
Quality assurance consultant:
- Supports the technical side of quality assurance, responsible for reviews and performance
analyses

Role Representation in the Test Workbench
Developer
Test coordinator
ABAP Development Workbench
Overview Development Test Utilities Administration System Help
Runtime analysis
Rep. Browser Dictionary SQL trace
Execute Check Menu Painter
Test Workbench CATT procedures
Test Organization Manage test catalog
System Log
Dump analysis Perform test Manage test plan
Manage test package
Extended check Assign test package
Test coordinator
Tester
© SAP AG 1999
To access the Test Workbench, choose Tools →ABAP Workbench → Test → Test Workbench.
The assignment of roles to functionality in the Test Workbench is designed as follows:
Developer/Test coordinator: CATT procedures
Test coordinator: Test organization
Tester: Testing

Test Organization
Selection of Assignment of
Collection of test cases test cases
all test cases by purpose to a tester Testing
for an object (period and (period and
purpose-based) person-based)
T est
case
Test Test Test 1
Test case
package T case 2
catalog plan TesteTe
st st case 4
ca
se
3
© SAP AG 1999
The Test Workbench supports systematic development of test catalogs, test plans, test packages and
test cases.
A test catalog is a collection of test cases, presented along with further details, in a hypertext
structure. The divisions in the structure should relate to the component or process view of the
Business Navigator.
A test plan is a particular view of a test catalog. It contains all the test cases that will be required at a
particular time for a particular purpose.
A test package is a view of a test plan from the point of view of a person and a time period. It
contains all the test cases that a particular tester needs to process within a certain period.
A test case is a testable unit in the R/3 System. It often represents a particular business process or
process chain. You can automate test cases in a CATT procedure, and repeat them as often as you
like (see next slide).

Computer Aided Test Tool (CATT)
Use
Generating application data
Integration testing (functionality, performance)
Acceptance testing with manual test cases
Features
Modular structure (test modules)
CATT commands, to control test procedures
Documentation of tests, status analysis
CATT generator (as in batch input)
Screen-oriented: You must adjust changes to screens and
their flow logic in the CATT (cf. batch input)
Cannot be used for Enjoy transactions
Mainly for transactions rather than for lists (reports)
© SAP AG 1999
CATT can be used as follows:

Generating application data or training data (duplicating an environment for exercises)
Describing integration testing and flow management using the Test Workbench
Describing acceptance tests (with manual test cases) and flow management using the Test
Workbench
CATT has the following features:
You can create a CATT procedure using CATT modules.
CATT has an editor, which enables you to string together CATT commands and thus control tests.
The Test Workbench enables you to manage and document tests. Reports on the test results are
available through status analysis in the Test Workbench.
A CATT generator makes it possible to record CATTs by running the transaction.
CATT is screen-oriented. You must therefore adjust changes to screens and their flow logic in the
CATT.
At the moment, you cannot use CATT for transactions that use Enjoy controls.

Test Workbench: Status Analysis
Test catalog TK_LOG1 Test plan/packet TP_LOG1_1

Test plan Edit Goto View System Help
Test catalog TK_LOG1 Test plan/packet TP_LOG1_1 26.05.1997

Cumulative status TP LOG1 1 o.k. untested errors
Example test catalog for Logistics 38 % 38 % 24 %
Sales & Distribution 38 % 38 % 24 %
SD-SLS Sales 33 % 34 % 33 %
Change ordering party - enter goods recipient ... untested

Display order confirmation on screen ... TPAK_LOG1_3 11.04.19
Order - fast change of delivering plant ... TPAK_LOG1_3 11.04.19
SD-SHP Shipping 75 % 25 %
SD-BIL Billing 50 % 50 %
SD-CAS Sales support 100 %
© SAP AG 1999
As test coordinator or project manager, you can check the testing progress of test plans or test
packages. You thus receive an overview of the current test status.
In the Test Workbench, choose Test organization → Manage test catalog. Enter a test catalog and if
possible a test plan or a test package for which you would like to perform a status analysis. Then
choose Utilities → Status analysis.

Test Types
Test organizer Tester Objective
Unit testing Developer Developer Is the implemented version of a

function or group of functions the
same as the planned version?
Test coordinator Process Is the implemented solution for a

Integration test coordinator business process the same as
planned?
Has the project fulfilled the
Acceptance test Test coordinator End user requirements of the end user
(functional, ergonomic)?
Mass testing Test coordinator Developer Does the actual throughput match
up to the plan?
Can this be increased?
© SAP AG 1999
In the table above you can find the test organizer, the tester and the test aim of function tests,
integration tests, acceptance tests and mass tests.

Status Report and Handover
Program analysis
© SAP AG 1999

Status Report
Definition of milestones (intermediate goals)

Status reports
When you reach a milestone
When you hand over responsibility to someone else
© SAP AG 1999
To make the overall progress of the project quantifiable, and to provide the project leadership with
feedback, you should define milestones (intermediate goals).
As a quality assurance measure, and for documentary reasons, you should complete a status report
whenever:
You reach a milestone
Responsibility for development is transferred (for example, from a consultant acting on behalf of a
customer to the customer).

Status Report (Template)
Milestone
Which function has been implemented,
and how long did it take?
What needed to be done to reach the milestone?
Quality assurance
Test types
Test tools
Manual program analysis (source code review)
Program analysis supported by tools
Critical success factors for the next milestone
© SAP AG 1999
For each milestone, describe the intermediate goal that has been reached, and detail the steps that led
to it. Also indicate how long it took to implement that phase of the project, and refer to the overall
project plan.
To aid quality assurance, describe the tests that you have performed, and the tools that you used (for
example, extended program check, CATT, runtime analysis, SQL trace).
Finally, list the success factors critical for reaching the next milestone.

Summary
Quality assurance is a global function, affecting all

stages of your project
The fundamental quality assurance measures are:
Careful writing and maintenance of documentation
Periodic reviews
Systematically organized and conducted testing
using the Test Workbench
Performance analysis in a live system environment
© SAP AG 1999

Maintenance

1 Change Levels
Technical Design
5 Standardization
© SAP AG 1999

Maintenance
Contents:
New development phases in a project
Your project and SAP release upgrades
Objectives:
Administer change management using the Workbench Organizer
List tools which are available to help you integrate your
development project with a new R/3 release
© SAP AG 1999

Maintenance
oring
•Developme
nt •Monit
design g
•Process •Documen t ation •Tunin
e
•Technic
al •Training •Chang ment
e
manag
design ade
•Upgr ment
e
m an ag
t team
•Projec pe •Test
y st e m landsca
•S
rds
•Standa
© SAP AG 1999
Once your system has gone live, you will encounter requests for changes. This will mean modifying
the documents that you produced in phase 2 and the Repository objects that you implemented in
phase 3.

Development Cycle, Code Freeze, Versions
Development cycle 1 Development cycle 2
Change Change
Time
request request
DEV
DEV
DEV Release
Version Release Version
QAS QAS
PRD PRD
© SAP AG 1999
Each change to a Repository object is recorded in a change request by the Workbench Organizer
(refer to the Software Logistics unit).
When you release the change request, the Repository objects in it are marked for transport into the
quality assurance or production system. The quality assurance system contains the "frozen" state of
the development project, even if a new development phase has begun in a new change request in the
development system.
When you release the change request, new versions of all Repository objects are recorded. You can
display, compare and restore old versions using version management.
If you change a Repository object that does not yet have a version in the current R/3 System, the
system generates one as soon as you include the object in the request. This has the following
consequences:
No versions of SAP objects are delivered. This means that when you modify an SAP object, the
original SAP object is saved as a version.
In the quality assurance and production system, the system only manages versions for Repository
objects that are repaired in those systems.

Different Releases: First Development Cycle
Development cycle
Release x
Change
request
Time
DE1 DE1
Rel. x Rel. x
Release
Version
QA1
Rel. x
PRD
Rel. x
© SAP AG 1999

Different Releases: Database Copy and Upgrade
Development cycle
Release x
Change
request
Time
DE1 DE1 DE2
Rel. x Rel. x Rel. x+1
Release
Version
QA2
QA1 Rel. x+1
Rel. x
PRD
Rel. x
© SAP AG 1999

Different Releases: Second Cycle
Development cycle Development cycle

Release x Release x+1
Change Change
request request
DE1 DE1 DE2 DE2

Rel. x Rel. x Rel. x+1 Release Rel. x+1
Release Version
Version
QA2
QA2 Rel x+1
QA1 Rel. x+1
Repair track Correction track

PRD
© SAP AG 1999

Different Releases: Upgrade PRD
Development cycle Development cycle

Release x Release x+1
Change Change
request request
DE1 DE1 DE2 DE2

Rel. x Rel. x Rel. x+1 Release Rel. x+1
Release Version
Version
QA2
QA2 Rel. x+1
QA1 Rel. x+1
Rel. x
PRD PRD
Rel. x Rel. x+1
© SAP AG 1999
If you would like to:

Upgrade your system landscape from Release x to Release x+1
Continue development during the release Customizing and release testing of Release x+1
follow the steps below:
Transport of all change requests from the development system Release x (DE1) to the quality
assurance system Release x (QA1) and production system Release x (PRD)
Database copy DE1 -> DE2, originals move to DE2, upgrade DE2 to Release x+1
Database copy QA1 -> QA2, upgrade DE2 to Release x+1
Develop new functionality in the correction track (DE2, QA2)
Remove errors in the repair track (DE1, QA1, PRD) and (if necessary) in the correction track
Upgrade the production system PRD from Release x to x+1, import new functionality from the
correction track to PRD

Repository Objects Sensitive to Upgrades
• SPDD/SPAU (adjustment)
Modified SAP Repository objects • SAMT (syntax, generation)
Adjustment
Adjustment • Test Workbench / CATT
required
required (meeting requirements,
New performance)
New SAP
SAP standard
standard
Modification
Modification
Customer Repository objects that
• SAMT (syntax, generation)
refer to SAP repository objects • Test Workbench / CATT
(meeting requirements,
performance)
© SAP AG 1999
Use the upgrade utilities SPAU and SPDD to analyze modified Repository objects. You may need to
adjust the new version to the modified version. Call SPDD during the upgrade. In SPDD, you can
adjust tables, elementary types and domains. Call SPAU after the upgrade. In SPAU, you can adjust
all other Repository objects.
SPAU and SPDD determine the Repository objects that need to be adjusted and divide them into the
following areas:
Automatic adjustment: The system adjusts the objects automatically
- Caution: SPAU and SPDD can adjust an object technically. However, this does not mean the
the object necessarily meets the semantic requirements. You therefore need to test the objects
further (see below).
Semi-automatic adjustment: SPDD and SPAU have discovered collisions that you need to resolve
in the splitscreen editor.
Manual adjustment: You modified the object without using the Modification Assistant, and need
to adjust it manually.
After an upgrade, test modified Repository objects and customer Repository objects that refer to SAP
Repository objects to see whether they still meet the requirements of the process design, and for their
syntax, generation, and performance. To do this, you can use SAMT (mass test processing) and the
Test Workbench.

Avoiding Adjustment
SAP enhancement concept

No changes to SAP objects, so no adjustment
required during the upgrade
Automatic import and reset of preliminary

corrections from Online Correction Services
(OCS)
Returning to the SAP standard

Version database and entries in Workbench Organizer
and transport system are retained
© SAP AG 1999
Program enhancements and table appends allow you to enhance SAP objects without the danger of
the changes being overwritten by SAP in an upgrade.
To save you from having to enter preliminary corrections by hand, the service Online Correction
Services has been available since Release 3.0. This service allows you to install and uninstall
Support Packages and patches automatically (call transaction SPAM or choose Tools → ABAP
Workbench → Utilities → Maintenance → Patches).

Monitoring: Technical System Operation (1)
Local and Global Process Monitors (SM66/SM50)

Analyze all processes over 1000 seconds
Perform daily at peak load times
Database Statement Cache (ST04)
Analyze all database statements that cause more than 5% of the
logical reads or 2% of the disk reads
Perform daily, at the latest before database shutdown
Transaction Profile (ST03)
Analyze and compare standard SAP programs and customer
programs with respect to runtimes
Perform daily
Dump Analysis (ST22)
Analyze programs that terminate with the same error several times a
day (e.g. TSV* dumps indicate that the program allocates too much
memory)
Perform daily
© SAP AG 1999
The Local Process Monitor displays the status of all R/3 work processes on the application server
that you are logged on to. The Global Process Monitor displays the R/3 work processes for all
application servers. Dialog processes should not run for more than 1000 seconds. At peak load times,
analyze processes with such runtimes.
The Database Statement Cache displays all parsed and executed SQL statements with the load
(logical reads, disk reads, time). Analyze daily all SQL statements that cause more than 5% of the
logical reads and more than 2% of the disk reads. For further information, refer to course EWB10.
The Transaction Profile of the Workload Analysis displays all standard SAP programs and customer
programs with response times, memory, and CPU and database load. Monitor the applications daily.
The EarlyWatch and EarlyWatch Alert Service offered by TeamSAP Support contain summaries of
the transaction profile. For further information, refer to course BC315.
Monitor dumps in the production system daily. Serious dumps are those that occur several times and
those that begin with TSV*. Such dumps indicate that too much memory is being used in a single
program. The EarlyWatch and EarlyWatch Alert Service offered by TeamSAP Support contain
explanations of critical dumps.

Monitoring: Technical System Operation (2)
Syslog (SM21)
Analyze Syslog entries for irregularities in system operation
(e.g. interfaces not accessible, database errors)
Perform daily
Update Termination (SM22)
Analyze terminated updates, and initiate
subsequent updates if necessary
Perform daily
© SAP AG 1999
In the Syslog, monitor irregularities in system operation, for example, interfaces that are not
accessible and database errors.
Analyze terminated updates daily. If necessary, initiate subsequent updates.

Monitoring Production: Process Operation
Scheduling background programs

Document background jobs (programs, variants, names
of background job, background users, scheduling cycles)
and scheduling using R/3 or CSP
Processing errors
Analyze terminated folders
Analyze ALE inbound processing
Analyze customer-owned status log tables
© SAP AG 1999
As well as technical system operation, which is similar for all R/3 installations, process operation is
crucial for successful production operation.
Document your network of background programs with variants, background job names, background
users, and scheduling cycles. This list must be available for monitoring the technical system
operation.
Background jobs can be scheduled using R/3 or using Complementary Software Products.
For reliable process operation, you must monitor and process errors from all application error logs.
Terminated batch input folders: Transaction SM35
Errors in ALE inbound processing: Transactions WE02 and WE05
Errors in customer-owned status log tables (for example, for terminated CALL TRANSACTION
USING or BAPIs called in R/3).

Critical Success Factors: Production Operation
Define responsibilities for all tasks related to

technical system operation and process operation
Example: Process operation
Who monitors folder processing or ALE inbound
processing for which business objects and how
regularly do they do this?
Define SLA and escalation routes
© SAP AG 1999
Define responsibilities to clarify which person or department is responsible for tasks connected with
the technical system operation and the process operation.
We recommend that you make service level agreements (SLAs) between departments or external
organizations to formally clarify what tasks are to be completed within a specific time window. In
case of an emergency, you should also define escalation routes.

Internal Services: Structure
Problem reporting management

End user support (help desk)
Know-how database
Management and processing
of development requests
© SAP AG 1999
To support your development when your system goes live, you will need problem message
management, a help desk to support the end users, a know-how database, and development request
management.

Summary
Change management for customer objects is

supported by the Workbench Organizer
Modified Repository objects and customer
Repository objects that call SAP Repository
objects must be adjusted and tested after the
upgrade
© SAP AG 1999

Conclusion

1 Change Levels
Technical Design
5 Standardization
© SAP AG 1999

Conclusion
Contents:
10 golden rules for ABAP development projects
Objectives:
understand the 10 golden rules for ABAP development projects
© SAP AG 1999

10 Golden Rules for Development Projects
1 Start a development project only if your requirements

cannot be met using Customizing and Personalizing
2 Consider whether external procurement could be
an alternative to your own development project
(e.g. CSP, SAP Services)
3 Do not just consider the work load caused by implementing
a development project. Also think about consequences for
performance, maintenance and upgrades. In particular, avoid
modifications. If you cannot avoid them, follow the rules
given in this course
4 Implement ABAP development projects in a system
landscape with at least two, preferably three (or more)
systems (Repository objects are cross-client)
5 Always have a plan. Document the process analysis,
the technical analysis and the implementation
© SAP AG 1999
An ABAP development project is aimed at creating an optimized business solution based on the SAP
standard with a minimum development effort..

10 Golden Rules for Development Projects
6 A prototype can be a useful basis for discussion

between process coordinators and end users
7 Store project documentation at a central location
which is known to all project team members
8 Assign all Repository objects that need to be transported
together to one change request. Use a change request to
group together parts of a (sub)project, not the work
of individual developers
9 Consider performance as a critical success factor
(quantity structures in the process design, high-performing
SQL operations in the implementation)
10 Ensure that quality assurance takes place at all stages
of development (reviews, test, documentation)
© SAP AG 1999

MBC40 - Managing ABAP Development Projects

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

MBC40 - Managing ABAP Development Projects

Transféré par

Droits d'auteur :

Formats disponibles

MBC40 Management von ABAP-

Copyright 2000 SAP AG. All rights reserved.

All rights reserved.

(C) SAP AG MBC40 ii

Core Competence Expert Competence

(C) SAP AG MBC40 iii

(C) SAP AG MBC40 iv

(C) SAP AG MBC40 v

Core Competence Expert Competence

Technical Training and

SAP GoingLive Check http://sapnet.sap.com/GoingLiveCheck

SAP EarlyWatch Service http://sapnet.sap.com/EarlyWatch

SAP EarlyWatchAlert http://sapnet.sap.com/EWA

SAP Consulting Services http://sapnet.sap.com/ConsultingServices

(C) SAP AG MBC40 vi

(C) SAP AG MBC40 vii

(C) SAP AG MBC40 viii

(C) SAP AG MBC40 ix

(C) SAP AG MBC40 1

(C) SAP AG MBC40 2

This course will enable you to:

(C) SAP AG MBC40 3

Unit 1 Change Levels Unit 6 Process and Design

(C) SAP AG MBC40 4

6 Process Design and

3 Project Team 8 Quality Assurance

4 Software Logistics 9 Maintenance

(C) SAP AG MBC40 5

(C) SAP AG MBC40 6

Customizing Personalization Modification Enhancement Customer

(C) SAP AG MBC40 7

Procedure Model Implementation Guide Session Manager

Business Process Scen. Application Components Business Objects

Workflow and Organization

ASAP contains all SAP implementation tools, specifically:

(C) SAP AG MBC40 8

Simplifying and personalizing an

Global field display characteristics

(C) SAP AG MBC40 9

Configuration User roles:

(C) SAP AG MBC40 10

The mySAP.com Workplace

(C) SAP AG MBC40 11

(C) SAP AG MBC40 12

(C) SAP AG MBC40 13

R/3 business Customer

Assisted Customer enhancement With SAP objects

(C) SAP AG MBC40 14

(C) SAP AG MBC40 15

Does the standard R/3 System Customer development

Does the existing application

Cust. development with

(C) SAP AG MBC40 16

(C) SAP AG MBC40 17

Implementation requirements ... greater than in Customizing.

ABAP development projects can be evaluated according to the following criteria:

(C) SAP AG MBC40 18

with the degree to which the ABAP

Modified repository objects cause

(C) SAP AG MBC40 19

ABAP Dictionary Function groups Other

STOP Deleting any SAP repository objects

Very Changing conversion routines, SAP function module