ABAP PROJECT OVERVIEW

MANAGING ABAP PROJECT OBJECT-ABAP PROJECT OVERVIEW:

TeamSAP is the coordinated network of people, processes & products from SAP & partners that delivers fast, integrated and assured solutions over time.

There are three key components: People, Processes, and Products.

The people component represents SAP and its partners. Any R/3 implementation team is usually composed of multiple organizations which bring different skills to the table.

Our objective with TeamSAP is to ensure that the right vendor skills are coordinated, at the right time, with appropriate quantities and management.

The product, SAP’s Business Framework, is a vital piece of TeamSAP because it’s the platform on which SAP and non-SAP applications work together. It also provides the flexibility to change over time and includes R/3 business components, integration technologies, and open interfaces that allow R/3 and complementary partner software to operate together.
Third party software and hardware products are certified by SAP within this infrastructure. Certification programs for TeamSAP partners that are part of the Business Framework include Joint Development Partners, Certified Interface Partners, and Technology Partners.

The processes represent SAP an its partners working together to synthesize the knowledge gained in over 11,000 completed R/3 installations. Three key areas that reflect this experience: the ASAP Roadmap and accelerators, Business Engineer, and Services, Support and Training.

AcceleratedSAP (ASAP) is SAP’s total process-oriented solution for accelerated implementation and continuous optimization of R/3. ASAP was developed and enhanced with the knowledge of a team of international consultants. It consists of the ASAP Roadmap, tools, service & 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 check lists), with which you can start your implementation project.

The Business Engineer makes up 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.

ABAP Workbench Tools are implemented in the following project phases:

Phase 1: Project Preparation

no ABAP Workbench tools

Phase 2: Business Blueprint

process design template, technical design template, Data Modeler, Screen Painter (Early Prototype Screens), Menu Painter

Phase 3: Realization

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.
Depending on the scope and complexity of your project the roles described below could fall to one and the same person.

The steering committee consists of those people from the board of directors initiating and sponsoring the project and 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 proje ct (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 responsibility for project logistics belongs to the project coordinators.

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 all falls into the area of quality assurance.

Technical support is responsible for clearing away all technical obstacles to implementation (server downtime, transport problems, database problems, etc.).

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).

Standards coordinators deal with more than one subproject and are responsible for establishing standards for project documentation and communication company wide. They are also responsible for customizing and development activities documentation (templates for process and technical design, naming conventions, programming guides, graphical user interface style guides).

Development managers coordinate development activities within a subproject. His or her 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 using 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 the Data Modeler. Dictionary developers reproduce these data models in the ABAP Dictionary (tables, data elements, domains, foreign key dependencies, search help, etc.).

ABAP developers implement the process model described in the technical design using the tools provided by the ABAP Workbench. They also create the user interfaces and print lists foreseen in both the process and technical designs.
Interface developers implement necessary online and offline interfaces (outside of ABAP if necessary).

SAPscript developers use SAPscript to create the forms foreseen in both the process
and technical designs.

Information developers write the documentation for what the other developers have created.

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 the individual test case. They coordinate test case input and work together with process managers during test case creation and user test organization.

The actual testers come from the user departments where these new functions are going to be used. They complete function tests by manually going through test cases and CATT procedures.

Quality assurance consultants deliver technical support for all of these quality assurance activities. Their responsibilities include writ ing reviews and measuring performance using Workload Analysis, SQL Trace, ABAP Trace and other tools.

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 using 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 the roll they play (for database management systems and operating systems too, if necessary).

An R/3 system landscape is made up of all of a customer‘s R/3 systems taken as a whole. Each individual role (development, testing, test systems, quality assurance, training, production) must be mapped onto a client within the R/3 system.
Repository objects are client independent. Thus all changes to Repository objects are immediately visible in all clients. For example: if M1 and M2 are clients in an R/3 system and a program is saved in M1, any changes made to the program will immediately influence M2’s runtime environment.

SAP recommends defining Customizing and application table structures as client specific (see Realization unit).

SAP recommends 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 with one central maintenance site for development and Customizing. Other clients for sand-box, training or master data may be deployed over the systems.

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 out changes to Customizing settings and Repository objects can only be copied or transported using requests .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 transported by client copy or client transport but instead are transported by releasing and importing Workbench requests.

Once in production, 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 the function copy request
The Change & Transport Organizer consists of the tools Workbench Organizer and Customizing Organizer.

In the Workbench Organizer you can only see Workbench requests. In the Customizing Organizer, Customizing and Workbench requests are visible.

Changes to customizing and Repository objects are recorded in change requests. There are two types of change requests :

Client dependent customizing is recorded in Customizing requests.
Client independent customizing and Repository Objects are recorded in Workbench requests.

Repository objects are:

Assigned to development classes.

Have versions Locked for access of non-team members as long as the Workbench request is not rele ased. This system landscape combines central international development with national development in subsidiaries.

The Workbench Organizer allows the user to develop software in an organized manner.
The transport system provides for transport execution and registration.
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.

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 are anticipated and thus organized in advance.

Personalization: Changes to the global display characteristics of fields (pre-determing some input values, removing other input fields from certain screens), user specific menu sequences.

Modification: Customer changes to SAP Repository objects. When such 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 will greatly automate 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 undertaken using ABAP Workbench tools, Customizing and most Personalization are done with Business Engineer tools. Thus the course MBC40 deals mainly with managing projects that are, from a technical standpoint, based on the ABAP Workbench (development projects ).

The Business Engineer contains all of SAP’s implementation tools, specifically:

Reference Models

All Remodels that describe R/3 (process models, data models, organization models)

Implementation Guide

A list of all Customizing activities

The goal of Personalization is to speed up and simplify the business transactions that are going to be 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 predetermined using global display characteristics. Within transactions, individual fields and individual columns of table controls or even complete screens can be hidden.

Using area menus, the Session Manager (installed on a front end or transaction SESS) enables customized shortcuts, reporting trees and menu sequences to meet specific needs of different user groups within the company.

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 and 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 (no knowledge of the ABAP language necessary)

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

Workbench Organizer Change requests (ensure organized object development
and transport in conjunction with the transport system)

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, etc.).

ABAP is also designed for developing user dialogs in a distributed R/3 system. Developers need not concern themselves with communication and distribution aspects of the system.

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 which is organized by using the Workbench Organizer.

SAP Repository objects can be called from within a customer’s own program. 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 the customer has either created or alter himself. For example, a customer can create a program exit that an SAP program calls. Enhancements can take place in the following places:

in an ABAP program (program exits)
in the graphical user interface (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 or Dictionary structures (table appends )
as text enhancements (replacing SAP field or keyword documentation).
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 at any point desired in SAP Repository objects.


Customizing Customizing Development/Purchase Development/Purchase

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. Otherwise, you can try to meet the customer’s 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 will largely automate this process.

You should only make modifications if

Customizing and Personalization cannot fulf ill your requirements

enhancements and user exits are not foreseen

copying an SAP object into the customer namespace is not useful (see following slide).

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 numerous parts of the SAP program your requirements are not going to be met by future R/3 release standards.

Pay attention to the dependent objects when copying. For example, the choice between modifying and copying must also be made for all of the includes attached to your base program. The same applies within function groups respectively function modules.
ABAP development projects can be evaluated according to the following criteria:
How costly is implementation, measured in man hours (creating, implementing, and testing the concept)?

How does the ABAP development project affect performance
the amount of work at upgrade?

By calling SAP objects in your Repository object, you can greatly reduce the amount of work required to implement it. Repository object changes made by SAP can also make for additional work during an upgrade. For example, SAP might change the interface of a screen for which you have written a batch input program.

The following Repository objects are normally only changed by SAP in an upwardly compatible manner and therefore, can be regarded safe for use in customer programs:

function modules that have been released
objects that are public in the ABAP Class Builder
BAPIs (Business Application Programming Interface)
user exit includes
customer exits

SAP guarantees BAPI stability for two functional rele ases.

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 holds true for those Repository objects automatically upgraded by the Modification Assistant (from Release 4.5A).

For the adjustment of programs you need knowledge of the process logic of your individual application.

Modifications are especially critical when they influence numerous other Repository objects (Dictionary objects, function modules) adjustments are difficult (menu, pushbuttons, graphical user interfaces (GUIs) before 4.5A) or not supported by tools (transaction codes, messages, logical databases).

Without the help of the Modification Assistant (before 4.5A) modifying GUI statuses and GUI titles and assigning customer function modules to SAP function groups are considered critical.

In the general project environment, project planning, implementation, communication, notification management, project documentation, quality assurance procedures, teamwork 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 objects

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 different ways.

Modification Handling

Installation rules and logbook of all modifications made to a customer’s system
central central decentralized decentralized

By instituting 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
Naming conventions delineate between SAP Repository objects and customer Repository objects. Tip 16466 delivers an overview of all of the current naming convention for 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 that namespaces remain intact.

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 SAP OSS. To do this, the SAP partner can from Release 4.0 apply for a name prefix in SAP OSS that is then added to all of that partner’s Repository objects (OSS notes 84282 and 91032, White Paper Development Namespaces in R/3, purchase order number E:50021723 or D:50021751).

The application hierarchy and development classes serve to 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.

Often Repository objects are made up of subobjects that are also Repository objects.
The Repository Information System allows you to search for Repository objects according to various criteria.

SAP delivers a Style Guide that standardizes your interface according to ergonomic principles .

Ergonomics examples can be found in the Repository Browser under Environment
Ergonomics examples.

SAP recommends to store documentation as follows:

Project documentation

internally in a SAPoffice folder structure
externally (e.g. on a document server).

End user documentation

Documentation at the repository object data element (appears when you hit F1 on a screen field) program (appears when you select Help Extended help on a selection screen)

Independent SAPScript text called by an application

Technical documentation of a single repository object
documentation at a repository object (e.g. function modules, ...)

Inline documentation (comments in source code)

Select a central storage for your project documentation that is available and known to all project members.

ABAP source code (in programs, screen flow logic, function modules, methods) can be documented at the following levels:

object heads modularization unit heads

functional methods for stretches of code 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).

Keep the interfaces with those parts of the program written by the customer (encapsules) compact.

Define a company-wide standard for online 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 is run.

SAP recommends labeling hard modifications to source code as described above:
Preliminary Correction OSS 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).
SAP recommends keeping 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 (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)
OSS note number, valid until Release x.y
estimated expense to reinstall the modification during adjustment (measured in hours).