\documentclass{report}
\usepackage{a4}
\usepackage{graphicx}

% fig{label}{caption}{file}
\def \fig#1#2#3{
  \begin{figure}
    \begin{center}
     \fbox{\rotatebox{270}{\includegraphics[height=12cm]{figures/#3}}}
     \caption{#2} \label{#1}
    \end{center}
  \end{figure}
}

\newcommand\oben[1]{\begin{center}\begin{minipage}{#1}\hrule\medskip}
\newcommand\unten  {\hrule \end{minipage}\end{center}}

\begin{document}

  \begin{figure}
    \begin{flushright}
      \includegraphics[width=3cm]{UniHHLogo.ps}  
      \put(-375,50){Universit\"at Hamburg}
      \put(-375,40){FB Informatik}
      \put(-375,30){Vogt-K\"olln-Str. 30}
      \put(-375,20){22527 Hamburg}
    \end{flushright} 
 \end{figure}

  \vspace{8cm}
  {\center \huge SAP R/3 \\ An Overview of its Concepts and Languages \\}

  \vspace{1.5cm}
  {\center \textbf{Studienarbeit}\\vorgelegt von: \\ Stephan Ziemer\\Ebelingstra\ss e 1\\21073 Hamburg\\
  2ziemer@informatik.uni-hamburg.de\\}


  \vspace{1.5cm}
  {\center Betreuer: \\ Prof. Dr. F. Matthes\\TU Hamburg-Harburg\\f.matthes@tu-harburg.de\\}

  \vspace{1.5cm}
  {\center 5$^{\rm th}$ of August, 1997\\ }
  \vspace{2.5cm}  

  \tableofcontents

%************************************
%*         Introduction             *
%************************************

   \newpage
   {\Huge \bf Motivation and Goals \bigskip}
   \addcontentsline{toc}{chapter}{Motivation and Goals}

    SAP was founded in 1972 by five IBM-programmers.
    They had the idea to create one program suitable for many companies instead of
    writing essentially the same business-software again and again for
    different companies. They abstracted from the needs of a concrete company and
    wrote a program called System R which implements the processes of an
    abstract company. To use System R for a concrete company, it is necessary
    to `customize' System R to suit the specific needs. This kind of software
    is called `standard business software'.

    This text presents an overview of the concepts SAP uses in its R/3-system
    from a computer scientist's point of view. The focus is on the properties and 
    the intended use of the concepts, technical details are omitted wherever possible.
    The objective is to show the concepts behind R/3 and to
    enable the reader to recognize the concepts when they appear
    in the concrete system. The intention is not to replace a handbook or to give a
    detailed introduction to a specific issue in R/3.
    
    The first chapter gives an overview of the system and different views of the
    system. R/3 is divided into the analysis level, the design level and
    the implementation level.
    The second chapter deals with the analysis level, the third and fourth chapter
    deal with the design level and the implementation level, respectively.
    Chapter five outlines the customizing and the system evolution in time.
    In the last chapter the technical architecture is stated.

    The reader should be familiar with the relational data model. Knowledge
    about object-oriented modeling is helpful but not necessary.

  
%************************************
%*            Chapter 1             *
%************************************

   \chapter{Concepts and Languages of R/3}

   The purpose of this chapter is to give a rough overview of
   the scope, the history and the concepts and languages of R/3.

%************************
   \section{Background and Scope of R/3}

   SAP's R/3-system is a package of standard international business applications
   for areas such as Financial Accounting, Controlling, Logistics and Human
   Resources. The R/3 system provides an enterprise solution for all these
   application areas in a distributed client/server environment. Using the
   R/3 system, a company can manage financial accounting around the world,
   receive and track orders for goods, and organize and retrieve employee
   information and records, among many other features. Many Fortune 500
   companies and high-tech companies (including American Airlines, Chevron,
   IBM, Mercedes and Microsoft) run their businesses with the R/3 system.
   \footnote{taken from \cite{kretschmer}.}
   The system is available on many hardware platforms and for many operating
   systems.

   The `R' stands
   for `real time' which means that the system is interactive. `3' means that
   it is the third major version of the program, though there has never
   been a system called `R/1'. `R/1', a retrospective appelation sometimes
   heard today,  refers to a collection of several 
   applications and has never been called so. R/3 was introduced in 1992
   and by the end of 1995 more than 5,200 R/3 systems were installed
   worldwide.
   
%************************
   \section{Integrated Analysis, Design and Implementation}

   This section describes the view R/3 has got of the `real world'. `Real world'
   in this context means companies and their data.

   R/3 uses three levels of abstraction to reflect the real world in the system.
   At each level, three views can be taken: a process view, a funtion view and
   a data view.

   At the top most level, the \emph{analysis level}, a description of R/3 is
   given. Processes are modeled with EPCs(Event-controlled Process Chains) which describe 
   how things are done. An EPC consists of several states and actions and describes 
   side effects like informing someone that an action has taken place.

   Functions are described in terms of SAP modules, each module serving a
   special functional purpose within the company. E.g., the module HR
   (human resources) is to manage the staff data.

   The data is modeled in a relational way\footnote{For more information about the relational
   model see \cite{Schmidt}.}. SAP uses SERM (Structured Entity Relationship Model)
   as modeling technique. SERM was invented by SAP but is closely related to
   the common entity relationship model\footnote{see \cite{Schmidt} for details about
   the entity relationship model.}. The model achieved is called `data model'.

   At the second level, the \emph{design level}, processes are modeled with
   \emph{workflows} which are user-defined EPCs. There is nothing to model
   functions at this level. The data model of the analysis level is implemented
   by relational tables and foreign keys on this level. The R/3 System has got its own data
   dictionary, where all meta data is stored. 

   At the last level, the \emph{implementation level}, processes are modeled with
   development classes. A development class is a set of objects that work on the
   same business objects. Functions are represented as ABAP/4 programs and reports.
   Data is modeled by SQL tables and ABAP/4 variables\footnote{ABAP/4 is the 
   programming language of the R/3 System. Chapter \ref{il} covers ABAP/4 in more detail.}.
   
   The \textit{repository} contains all three levels. It is the central place where any
   meta-data of the system is stored. In the Repository Information System any object
   that can be manipulated is accessible. The data dictionary is a part of
   the repository as well as all development class objects are. See figure \ref{repository}.

   Most parts of the repository are, as nearly all information in R/3,
   saved in one SQL database. Supported databases are, e.g., Informix, Oracle and ADABS D.

   Figure \ref{bmLangs} shows the concepts and languages at each level.
   Figure \ref{bmComps} shows main objects of each level.
   Figure \ref{applicsInR3} gives the modules shipped with R/3 3.0.

   \fig{bmLangs}{Concepts and Languages of the R/3 Repository}{chapter1/bm_langs.eps}
   \fig{bmComps}{Objects of the R/3 Repository}{chapter1/bm_comps.eps}
   \fig{applicsInR3}{Logical Partition of R/3 into Modules}{chapter1/apps_R3.eps}
   \fig{repository}{The Repository}{chapter2/rep_obj.eps}

%************************
   \section{Coexistence of multiple R/3 Clients}

   An R/3 system is split into different clients. A client is a business entity 
   like a subsidiary. Clients have separate data for customizing and application data.
   They share customizing independent data like meta data and global company settings.
   Only data can be client-dependent. All meta-data, e.g. table defintions, are globally
   defined. Client-dependent data is achieved by adding a certain field to a table
   defintion of a table which is to hold client-dependent data. For each row of the
   table, this field holds the number of the client to which the row belongs.

   In a usual R/3 system several clients exist like the default client (number 0000),
   a development client, a testing client and a customizing
   client. The actual client used in business should be in a separate system 
   to avoid side effects by changes of global settings.
   Compare figure \ref{clients}.
   
   \fig{clients}{Clients in R/3}{chapter1/clients.eps}

%************************
   \section{Application and System Evolution}

   Application and system evolution is a serious problem in practice. Updates have
   to be done in a very short time and customizing adjustments should not be
   affected. SAP tries to avoid name clashes by the introduction of naming conventions
   for objects.

   In the R/3 System, the namespace is global and flat for each object type. E.g., tables
   must have a system-wide unique name, but a program object can have the same name as a table.
   There are thousands of named objects of all kinds and combined with a strict limitation of
   length, the names are by no means self-explaining. To worsen the situation,
   English and German names and abbreviations are mixed.

   SAP decided to leave the `name range' Y* and Z*\footnote{all objects which
   names start either with a Y or a Z.} to customer objects. There are exceptions
   from this rule leading to some confusion. SAP guarantees (so far) that there
   will be no name clashes with SAP objects when a new release is installed.

   The example of the namespace dilemma shows what happens to many systems that
   have grown in time: Everywhere in the system one can find legacy objects that
   nobody dares to remove or -in this case- dares to rename for the consequences
   are largely unpredictable. 

%************************
   \section{Running Example: FM Areas and Funds Centers}

   It is not within the scope of this text to describe every feature of R/3. Instead 
   some features will be shown by example and this example is the FM area and
   the funds center.
   \begin{description}
      \item[FM area:] A financial management area (FM area) is the commercial
         organizational unit, with which commitment accounting is conducted.
      \item[Funds Center:] A funds center is a commercial responsibility area
         to which a budget is assigned. \footnote{Definitions taken from \cite{OD}.}
   \end{description}
   A funds center must be assigned to exactly one FM area, several funds centers
   can be assigned to the same FM area. A funds center cannot exist without the
   superordinated FM area. See \cite{OD} for more details.

   Figure \ref{fmarea_in_omt} shows FM area and funds center in the OMT notation
   \footnote{see Appendix.}.
   \fig{fmarea_in_omt}{FM area and funds center in OMT}{chapter1/fma_omt.eps}

   In a university context FM areas could be the departsment, like the department
   of comupter science, and the funds centers represent workgroups who have their
   own budget.


%************************************
%*     Chapter Analysis Level       *
%************************************

   \chapter{Concepts at the Analysis Level} \label{al}

   The purpose of EPCs and the data model is to document the business processes and
   the data relations R/3 implements.

%************************
   \section{Data Modeling: Entities and Relationships}

   The Data Model is a view on the company from a data point of view. There are
   two types of objects in the model.
   \begin{description}
      \item[Entity:] An entity represents real data like the existing funds centers in a
         company. In the graphical notation entities are noted as boxes.
      \item[Relationship:] Describes relationships between entities. The relationship is
         \begin{itemize}
            \item hierarchical, if the key of one entity, the so called 
                  \emph{dependent entity}, depends on exactly one other
                  entity, the so called \emph{source entity}. 
                  This is the equivalent to a foreign key relation in the
                  relational data model. In the graphical notation this is noted with
                  an arrow from the source entity to the dependent entity.
                  The dependent entity is on the right hand side of the source
                  entity and the arrow points to the left edge.
            \item aggregating, if the key of the dependent entity depends on
                  more than one source entity.
            \item referential, if non-key fields of a dependent entity depend on other source entities.
                  This is the equivalent to a foreign key relationship with non-key
                  fields in the relational model. In the graphical notation such a
                  relationship is noted as an arrow pointing to the lower or upper
                  edge of the dependent entity. Again, the dependent entity is on the
                  right hand side of the source entity.
            \item a `is a'  relationship, if one entity is a special instance of another
                  entity. E.g., the entity `Bill' is a special instance of the
                  entity `person'.
         \end{itemize}
         A relationship has got a cardinality:
         \begin{description}
            \item[1:1] each entity of the source entity type has exactly one
                       dependent entity. Noted by a single arrow.
            \item[1:C] each entity of the source entity type has at most one
                       dependent entity, noted by a single arrow with a crossing line.
            \item[1:N] each entity of the source entity type has at least one
                       dependent entity. Noted by a double arrow.
            \item[1:CN] each entity of the source entity type can have any number
                       of dependent entities. Noted by a double arrow with a crossing line.
                       \footnote{taken from \cite{OD}.}
         \end{description}
         There cannot be a direct N:M relationship between entities in the data model.
   \end{description}

   Entities have some additional attributes, like a unique number and flags
   to indicate whether the data is changed during customizing or actual use and
   whether the underling implementation is a table or a view.
   See figures \ref{relationsTypes} and \ref{relationsCard}.

   \fig{relationsTypes}{Types of relationships in the Data Model}{chapter1/rel_type.eps}
   \fig{relationsCard}{Cardinalities of relationships}{chapter1/rel_card.eps}

   Figure \ref{fmarea_in_dm} is an excerpt from the data model for FM areas and
   funds centers.

   \fig{fmarea_in_dm}{Excerpt form the data model}{chapter1/fma_fc.eps}

%************************
   \section{Functional Modeling: R/3 Modules}

   R/3 provides different applications, so called \textit{modules} for the different departments
   of a company. Examples are the Financial Management (FI), Materials Management (MM)
   and so on. Theses applications work with the same data and are highly linked to
   each other. One can hardly use only one module of R/3. One has to use
   either a big part of the R/3 System or one cannot use it at all. 

   This is no doubt a strength and a weakness at the same time. On the one hand using 
   much of the system means handling data efficiently for no conversations of data to 
   other programs are needed and the data is handled in a consistent way, on the other
   hand the system does not scale for smaller or larger companies, making it a bit
   of an overkill for smaller companies. SAP is well aware of this and is currently
   looking for possibilities to make the system more scaleable.

%************************
   \section{Process Modeling: R/3 Reference Model and EPCs}

   The R/3 Reference Model is a representation of the R/3 System using graphical
   models. It describes the various aspects of the SAP R/3 software, i.e.,
   the supported business processes with their possible variants,
   data and organizational structures.

   In the R/3 Reference Model, business processes that can be executed in the
   R/3 System are described graphically as \textit{event controlled process chains} (EPCs).
   An EPC uses events to show the logical and chronological relationships between
   R/3 System functions. \footnote{after the glossary in \cite{OD}.}

   Four different element types can be used to form an EPC:
   \begin{description}
      \item[Function:] describes what is to be done. The symbol is a hexagon.
      \item[Events:] describing when things are to be done or at which stage the process
            is so far. The symbol is a rounded box.
      \item[Organization unit type:] describes who (which part of the company) is 
            involved. The symbol is an ellipse.
      \item[Information object:] describes what kind of information is needed or
            produced.
   \end{description}

   Figure \ref{EPCfc} shows an example of an EPC to create a new funds center.

   EPCs are \emph{not} integrated into the system in a strict sense. They are purely
   informational. There is no guarantee that a given EPC is implemented at all.

   The semantic of EPCs are defined on an informal base only. One can find many
   contradictions and irregularities in many EPCs published by SAP and others.
   Efforts are being made to formalize EPCs so they can be checked automatically
   for inconsistencies. Petri-Nets\footnote{For details about Petri-Nets see \cite{Peterson}.}
   have been used to check EPCs.

   \begin{figure}
      \fbox{\includegraphics[width=12cm, height=8.5cm]{figures/chapter1/wf_fc.eps}      }
      \caption{EPC to create a new funds center} \label{EPCfc}
   \end{figure}


%************************************
%*      Chapter Design Level        *
%************************************

   \chapter{Concepts at the Design Level} \label{dl}

   At the design level the data models of the analysis level are brought
   to a more technical level. Furthermore, the design level is the link
   between the actual implementation and the analyzing model. Up to a 
   certain point, it guarantees that different applications work on the
   same base when they refer to the same analyzing model.

   The main tool of the Design level is the Data Dictionary, holding all
   meta-data of the system and the company's data.

   The objects stored in the Data Dictionary (DDic) can be grouped into
   three groups:
   \begin{itemize}
      \item data modeling elements, i.e. tables, views, data elements and domains
      \item grouped data types, covered in chapter \ref{il}
      \item system oriented elements, covered in chapter \ref{il}.
   \end{itemize}

   The Data Dictionary is part of the Repository and reflects a view on the
   underlying database.

%************************
   \section{Data Modeling: Some Data Ditctionary Objects.}

   \fig{dd1}{Data modeling elements in the DDic}{chapter2/dd_obj1.eps}

   \subsection{Domains and Data Elements}

   A \textit{domain} is a basic elements that hides the technical representation
   of a piece of data. It is based on an external type.
   E.g., the domain \texttt{FICTR} is a sequence of four characters,
   the domain \texttt{FISTL} is a sequence of sixteen characters. The
   external type is in both cases the type `character'.

   Domains based on the external types CURR or QUAN are treated in
   a special way. Domains based on CURR and QUAN describe a
   currency amount or a quantity. There have to be tables, provided
   by the system or by the customer, that
   contain all valid currencies or quantity units, they are called
   reference tables. A field of a table based on CURR or QUAN must refer 
   to an appropriate field of a reference table, the reference field.
   The reference field itself is based on either the external type
   CUKY (currency key) or UNIT. It determines the actually used
   currency, e.g. dollar or DM, or unit, respectively.

   A \textit{data element} describes the business management use of a
   domain. One can think of a data element as a semantical domain.
   E.g., the data element \texttt{FIKRS} describe FM areas and
   uses the domain \texttt{FICTR}. The data element \texttt{FM\_FICTR}
   describes a funds center and uses the domain \texttt{FISTL}.

   \subsection{Tables and Structures}

   The table concept of the R/3 System is similar to the relation concept in
   the relational model of data. An R/3 table consists of one or more fields.
   These fields can either be defined directly or in another table or
   in a structure. A structure is similar to a table,
   but it does not contain any data. See figure \ref{dd3}.
   The advantage of defining fields not directly but in another structure/table
   is, that when the included table/structure is altered, the definition
   of the including table is changed automatically. 

   A field of a table has got a name and an associated data element.
   A field can refer to a check table defining a foreign key
   relationship. The System does not guarantee referential integrity
   automatically. The actual R/3 application has to take care of that.

   Depending on the intended use of a table, it can be realized in different ways
   in the database. A table can be
   \begin{itemize}
      \item transparent (being realized as an identical SQL table)
      \item a pool table (every row of the table is saved with other rows of
            other pool tables in the same SQL table)
      \item a cluster table (the whole table is saved as one row of an SQL table).
   \end{itemize}
   Tables for normal use are transparent, tables with only a few rows, which
   need not to be accessed from outside the system, can be pool tables. 
   Cluster tables are normally used for language-dependent tables, e.g. a table that
   holds a description of an object in various languages.

   It is also possible to define foreign keys. The referring field must
   be based on the same domain as the field referred to. The cardinality of a 
   foreign key relationship \footnote{See figure \ref{relationsCard}} can be set, 
   this is shown in the Data Modeler,
   when appropriate entities for the tables have been defined.

   Foreign keys are important, because the system often uses so called \emph{primary}
   and \emph{secondary} tables. A secondary table is linked via a foreign
   key relationship to a primary table. The referring table is the secondary table,
   the referred table is the primary table.

   The technique of \emph{customizing includes} and 
   \emph{append structures} are used
   to modify standard tables \footnote{These are tables predefined in the system.}.
   \begin{itemize}
      \item Customizing includes are special tables \footnote{ named CI\_*, an exception
            to the rule that the name range for customers is Y* and Z*.}, 
            which are included by standard tables. This is to offer customers the
            chance to change a standard table and to keep the changes over later
            upgrades of the system. Customizing includes are delivered empty and can
            be filled during the customizing process.

      \item Append structures are structures assigned to exactly one table. 
            The append structure refers to the table, not vice versa. The table
            does not `know' that it has a structure assigned. The Data Dictionary
            knows that and propagates changes to the table when necessary. This
            technique should be used to change a standard table when no
            customizing includes are provided for that standard table.
   \end{itemize}

   It is not recommended, though possible, to change standard tables directly.
   The standard tables could be changed with the next update leading to the loss
   of the changes made by the customer.

   This points out that versioning is an important issue in practice. The
   relational model does not cover this problem, object-oriented systems
   still have to prove that they perform better on that. SAP's solution
   to the problem may not be very elegant, but it seems to work.

   \subsection{Views}

   Views give a special view on a data stored in a database \footnote{see \cite{Schmidt} for details.}.
   In R/3, a view consists of one primary table
   and any number of secondary tables \footnote{at most the number of existing secondary 
   tables, of course.}.

   In an addition to the concept of views in the relational model,
   SAP R/3 supports four types of views:
   \begin{description}
      \item[Database view]: A database view is the equivalent to a view in the
           relational model of data.
           If there is more than one table involved, the access is always readonly.
           Views of this type are used frequently to represent an entity in 
           the Data Modeler.
      \item[Projection view]: A projection view hides some columns of a table
           (a projection). The hidden columns will not be sent form the database
           to the application server, reducing the data volume to be 
           transported .\footnote{Refer to chapter \ref{ta} for more details about the
           database and application servers of R/3.}
      \item[Help view]: A help view shows further fields (columns) of a table,
           when a user is to specify a value in a foreign key field and requests
           help for valid inputs. There can be at most one help view per table.
           Matchcodes are a more advanced technique to achieve the same goal.
      \item[Maintenance views]: Maintenance views enable a business-oriented 
           approach to looking at data, while at the same time, making it possible 
           to maintain the data involved. The data can be maintained by the 
           customizing transactions. \footnote{taken from \cite{OD}}
   \end{description}

%************************
%   \section{Function Modeling: BAPIs?}

%************************
   \section{Process Modeling: Workflows}

   The R/3 system allows the user to define his or her own workflows. The technique
   used is the same as the one used for EPCs\footnote{see chapter \ref{al}.}.

   SAP Business Workflow provides technologies and tools for processing and controlling
   cross-application processes automatically.  This involves primarily the coordination 
   \begin{itemize}
      \item of the persons involved
      \item the work steps required
      \item the data to be processed (business objects) 
   \end{itemize}

   Its main aims are to reduce throughput times and the costs involved in managing
   business processes and to increase transparency and quality.\footnote{taken from \cite{OD}}.

   

%************************************
%*     Chapter Implementation Level *
%************************************

   \chapter{Concepts at the Implementation Level} \label{il}

   At the implementation level, the actual business processes are
   implemented. All applications are written in ABAP/4\footnote{Advanced
   Business Application Programming Language, $4^{\rm th}$ generation.}, the
   R/3 programming language. The user-front end is written in ABAP/4 as
   well and can be customized and utilized as far as required. The
   complete functionality of R/3, including the ABAP/4 compiler, is
   accessible in ABAP/4 programs making, e.g., the generation of programs
   on demand possible.

%************************
   \section{Implementation-Oriented Data Dictionary Objects}

   \subsection{Data Types and Type Groups}

   The R/3 System supports five kinds of data types.
   \begin{description}
      \item[External types]: They are the foundation of all types and have an
           equivalent representation in SQL. Any object that
           is to be persistent \footnote{Persistence means in this context to
           be stored in the underlying database. For further details about persistence
           and how it can be achieved see also \cite{fm}.}, must be converted
           to a corresponding object of an external type. Table \ref{tabExtTypes}
           shows the existing external types.
      \item[ABAP/4 data type]: Every ABAP/4 variable is based on an ABAP/4 data type.
           The types are: \texttt{C}(character), \texttt{N}(numeric character),
           \texttt{P}(packed numer), \texttt{F}(floating point), 
           \texttt{I}(integer), \texttt{X}(hexadecimal number),
           \texttt{T}(time) and \texttt{D}(date).

           All external types have a matching definition using ABAP/4 data types. 
      \item[Header line type]: This is an aggregated type. In most cases it is defined
           by referring directly to a structure, which
           is the equivalent concept in the Data Dictionary. Header lines are used to
           define variables which are necassary to exchange data between ABAP/4 and
           the data base, they serve as buffers.
      \item[Internal table type]: An internal table is used to store data during
           the execution of a ABAP/4 program. \footnote{Actually not during the execution
           of an ABAP/4 program, but during the execution of an SAP transaction.}
           Internal tables are not persistent. If the data is to be persitent,
           it must be inserted into a database table.
   \end{description}

   \begin{table}
      \begin{tabular}{|l|p{7.25cm}|l|}
        \hline
        \emph{External type} & \emph{Description} & \emph{output length} \\
        \hline
        INT1 & 1 byte integer, unsigned & 3 \\
        \hline
        INT2 & 2 byte integer, used as length description for LRAW and LCHAR & 5 \\
        \hline
        INT4 & 4 byte integer, signed & 10 \\
        \hline
        FLTP & floating point number & 16 \\
        \hline
        TMS & time (HHMMSS) as 6 characters [CHAR(6)] & 6 \\
        \hline
        DATS & date (YYYYMMDD) as CHAR(8) & 8 \\
        \hline
        CLNT & client number & 3 \\
        \hline
        ACCP & account period (YYYYMM) & 6 \\
        \hline
        CHAR & sequences of characters & $<$256 \\
        \hline
        NUMC & numerical characters & $<$256 \\
        \hline
        LCHAR & same as LRAW but with characters & $<$ 65536 \\
        \hline
        RAW & sequence of bytes & $<$255 \\
        \hline
        LRAW & sequence of bytes beginning with an INT2 as length field & $<$ 65536 \\
        \hline
        DEC & decimal & $<$18 \\
        \hline
        CURR & currency field, realized as DEC & $<$18 \\
        \hline
        CUKY & key for a currency & 5 \\
        \hline
        LANG & language key & 1 \\
        \hline
        QUAN & quantity field & $<$18 \\
        \hline
        UNIT & key for a quantity field & 2 or 3 \\
        \hline
      \end{tabular}
      \caption{External Types in R/3} \label{tabExtTypes}
   \end{table}   

   \emph{Type groups} are collections of user defined data types or constants
   in ABAP/4 code.
   They are stored in the data dictionary for cross-program use.
   
   \fig{dd2}{Data types in the Data Dictionary}{chapter2/dd_obj2.eps}

   \subsection{Lock Objects}

   Lock objects guarantee the consistency of the database when many users
   work on the same data. 
   A lock object can lock one primary table and several secondary tables.

   The lock mode controls the method by which the users are given access 
   to the same data records at the same time. The system supports the
   following lock modes:
   \begin{description}
      \item[E (Exclusive, cumulative)]: This mode means that locked data may only 
           be displayed or processed by a single user at the same time.
           The user owning the lock can request the lock again.
      \item[S (Shared)]: This mode means that several users can simultaneously 
           display the same data. A request for another shared lock is accepted 
           even if it is requested by another user. A call for an exclusive lock 
           is rejected.
      \item[X (Exclusive but not cumulative)]:  
           A lock of type X can be called only once. Any other call for such a lock 
           is rejected, even if the user holding the lock calls.
   \end{description}
   The lock mode can be defined separately for each table in the lock object.
   When a call for a lock occurs, a corresponding entry is inserted into the lock
   table of the system. \footnote{taken form \cite{OD}.}

   Special ABAP/4 code, a so called \emph{function module}, is generated 
   automatically for every lock object. An ABAP/4 program calls the function
   module to request a lock. If the lock is rejected, an exception is thrown.

   \subsection{Matchcodes}

   In the relational model of data, every tuple of a relation is unique and has
   therefore identifying attributes. In practice it can happen that all  or nearly
   all attributes have to be used to identify a tuple. This means a performance
   penalty, because a great amount of data must be processed.
   To perform better, id-attributes like a unique number or a short string are used 
   to identify tuples.

   Using id-attributes is good for the performance but bad for human users. Users
   are often requested to identify a tuple by giving the id-attribute, e.g. when
   processing an incoming order the customer address is requested and the user
   has to type in the customer-id, which, e.g., is a number.
   The purpose of matchcodes is to help the user to find the information by displaying
   non-identifying attributes, which are useless for the system but meaningful
   to humans. In the example, a matchcode could display existing customer-ids and
   additional information, such as name, street and town.

   A matchcode has got a primary table, in which the requested attribute is contained,
   and it can have secondary tables to show associated attributes (fields) of other
   tables. Furthermore a matchcode can show different sets of attributes, each set
   constitutes a so called \emph{matchcode-id}.

   Matchcodes are no database indices. Differences are:
   \begin{itemize}
     \item A matchcode can contain fields from several tables. An index contains 
           fields from only one table.
     \item Matchcodes can be built on the basis of both transparent tables stored
           in the underlying database and using the special table types pool and cluster.
     \item The matchcode structure can be restricted by stipulating selection conditions.
     \item Matchcodes can be used as entry aids in the context of the SAP help system.
     \footnote{differences taken from \cite{OD}.}
   \end{itemize}

   \fig{dd3}{System oriented elements}{chapter2/dd_obj3.eps}

%************************
   \section{Programming in the Large: Development Class Objects}

   A \emph{development class} is a set of logically related development objects. Such
   a set of objects could be, e.g., all objects necessary to manipulate funds centers.

   Figures \ref{dev1} and \ref{dev2} show the development class objects in
   OMT notation.

   \fig{dev1}{Development class objects (1)}{chapter3/dev1.eps}
   \fig{dev2}{Development class objects (2)}{chapter3/dev2.eps}

   \subsection{SAP Transactions}

   A SAP transaction covers a logical process in R/3 (e.g. generating a
   list of customers, changing the address of a customer, booking a flight
   reservation for a customer, executing a program). From the point of view of
   the user, it represents a self-contained unit. In terms of dialog programming,
   it is a complex object which consists of a module pool, screens, etc. and is
   called with a transaction code. \footnote{taken from \cite{OD}.}

   It is helpful to think of a SAP transaction as one basic business process,
   which cannot be interrupted or half fulfilled. SAP transactions are sometimes called
   \textit{logical units of work}(LUW), a LUW can involve more than one
   database transaction (DB-TA).

   SAP transactions can be programmed to comply with the ACID condition
   \footnote{\textbf{A}tomity \textbf{C}onsistency \textbf{I}solation
   \textbf{D}urability, see \cite{Schmidt} for details.}. This is achieved by
   postponing all actual database changes an SAP transaction wants to perform till
   the end of the SAP transaction and then doing all changes within one
   database transaction.

   To coordinate many users working with the same data, lock objects
   must be used. Lock objects lock the data the moment
   they are called and release it by default when the SAP transaction is finished and
   all the changes in the database have been done. Please note that the data is locked
   at the time the user works with the data which can be much ahead of
   the time when the actual change in the database is carried out.

   \subsection{Reports}

   Reports are ABAP/4 programs. They will be explained in more depth in the
   ABAP/4 section of this chapter.

   \subsection{Function Modules}

   A function module is a routine in ABAP/4. In addition, it has got an interface
   which is stored in the Data Dictionary. The concept of function modules is one
   of the most important concepts in R/3.

   Function modules can
   \begin{itemize}
      \item be called from any other ABAP/4 program,
      \item be called via RFC\footnote{Remote Function Call, see \cite{lutz} for details.}
            from programs outside the system,
      \item delay all database transactions till the end of the SAP transaction
            and build by that the fundamental base for fulfilling the
            ACID condition.
   \end{itemize}

   According to the different purposes, there are different types of
   function modules, called \textit{process types}:
   \begin{description}
      \item[Normal]: The function module can be called from inside the
           system only. Database transactions are performed immediately.
      \item[RFC supported]: The function module can be called via RFC from
           outside the system.
      \item[Update with start immediately]: The database transactions are
           delayed until the next `COMMIT WORK' event. Should a database transaction
           fail, retrying is possible. This is a V1-booking.
      \item[Update immediately]: The database transactions are
           delayed until the next `COMMIT WORK' event. Should a database transaction
           fail, retrying is \emph{not} possible. This is also a
           V1-booking.
      \item[Update with start delayed]: The database transactions are performed
           (booked) after all V1-bookings have been performed. This is a V2-booking.
      \item[Sammellauf]: The database transactions can be booked with other
           V2-bookings at one time. This is a V2-booking.
   \end{description}

   Function modules are written in normal ABAP/4 code and can use the full
   functionality of R/3. This is of special interest when a function module
   is called form outside the system, making it possible to control the system
   from outside.

   So called `batch input' can be provided. This is data stored in special
   tables and the system interprets the data as input for the system. With
   batch input everything that can be done interactively can be simulated.

   \emph{Function groups} are a set of logically related function modules.
   The \emph{function library} stores all function modules and allows to search for
   specific modules.

   \subsection{Messages}

   A message in R/3 is a string. Messages are prompted to the user in a modal
   dialog \footnote{dialogs are displayed in separate windows. A modal dialog
   blocks the system until the user has reacted to the dialog. Non-modal dialogs
   allow the user to continue working with the system, the user can react to
   the dialog whenever he or she wants to.}.
   Every message has got a unique number in the message class it is part of.
   A message class is a collection of messages which are used in the same program.
   Nevertheless, it is possible for a program to use many message classes.

   The R/3 system supports 5 types of messages:
   \begin{description}
      \item[Error (E)]: The user made an invalid input and as soon as he or she has
         acknowledged the message, is forced to reenter the required information.
      \item[Warning (W)]: The user may have made possibly invalid input, but can decide,
         whether to reenter the information or to proceed.
      \item[Information (I)]: The user has to acknowledge the message and can
         proceed.
      \item[Success (S)]: This message is not displayed in a modal dialog, but
         in the bottom line of the next screen. A message of this type is purely
         informational and need not be acknowledged.
      \item[Abort (A)]: A critical error has occurred, a reentering of the information
         is not possible. The current SAP transaction is aborted. In most cases,
         technical reasons cause this kind of message to be prompted.
   \end{description}

   Message classes are maintained with a special tool, in terms of ABAP/4 this
   tool is an interactive report. Messages should be language dependent, of course.

   \subsection{Area Menus}

   As stated before, the ABAP/4 programs can use the full functionality of
   the SAP front end, including the menus. An area menu is a menu which
   triggers SAP transactions. Area menus can call any SAP transaction defined in the
   system. Area menus are not assigned
   to an ABAP/4 program and are invoked by a transaction code.
   
   \subsection{Other Development Class Objects}

   \begin{description}
      \item[Logical databases] are used to write reports. They consist of one or more
         database table(s), which are linked by user-defined conditions. Logical databases
         make reporting easier, not more powerful.
      \item[Dialog boxes] are dialogs, which are used quite often in
         the system. It is possible to define new dialog boxes or to use
         predefined, standardized dialog boxes. Several
         kinds of standard dialog boxes are available:
         \begin{itemize}
            \item Confirmation prompt dialog boxes
            \item Dialog boxes for choosing among alternatives
            \item Data print dialog boxes
            \item Text display dialog boxes
         \end{itemize}
         \footnote{taken from \cite{kretschmer}.}
      \item[SET-/GET-parameters] are used to exchange data between SAP transactions.
         Their main purpose is to set values for input fields on the screen.
      \item[CATT-procedure]: CATT stands for Computer Aided Test Tool.
         This tool helps the user to test self-written programs or parts of
         the system functionality with special test data.
   \end{description}

%************************
   \section{Programming in the Small: Program Objects}
   
   Figure \ref{progobj} shows program objects in detail. 
   
   \fig{progobj}{Program objects}{chapter3/progobj.eps}
   
   A program object consists of a \textit{module pool}, written in ABAP/4,
   one or more \textit{DynPros}, and some \textit{GUI stati}. A program object can
   also use at most one \textit{logical database}, the program object
   will then be a \textit{report}.
   
   The \textit{ABAP/4 modules} are called by the \textit{flow logic} and can call other
   subroutines, called \textit{forms}, which cannot be invoked directly
   by the flow logic. Modules and forms can have their own local
   data and have full access to all global variables. The global
   variables can be used for internal purposes and are the interface
   to all database objects.

   The data exchange between DynPro fields and ABAP/4 variables is
   done automatically. Before a screen is displayed, the PBO modules
   fill ABAP/4 variables, which have the same name as the DynPro fields, with
   the appropriate data. The DynPro interpreter then transfers the data into
   the DynPro fields and after input, it transfers the data back into
   the ABAP/4 variables.

   \subsection{GUI Status}

   A GUI status describes which menu bar and buttons should be represented to the
   user at a certain time.

   The \emph{menu bar} holds the menus. Two menus are always present: The system menu and
   the help menu. Menus themselves can contain \emph{menu items}, e.g. `Quit', which
   trigger actions or further submenus, like `Create Object\dots', which lead to
   other menus and menu items. A menu can cascade to a depth of three.

   The \emph{tool bar} holds a set of application independent buttons, the
   \emph{application tool bar} holds a set of application dependent buttons.
   \fig{guistat}{GUI status}{chapter3/guistat.eps}

   \subsection{The Model for interactive Programs}

   To understand the programming concept of R/3 it is necessary to understand the
   model for interactive programs. The R/3 system is mainly event driven, events
   can be triggered by the system itself or by the user.

   The model is screen-oriented, the cycle is processed for every called screen (DynPro).
   \begin{enumerate}
      \item At the beginning of the cycle, everything assigned to the
         PBO\footnote{Process Before Output.} event is executed. In most cases
         this will be actions to prepare data to be presented to the user.
      \item Next, the user does the actual input.
      \item Depending on how the user ended the input,
         \begin{itemize}
            \item additional information is displayed,
            \item another transaction is executed,
            \item the EXIT-COMMAND-event is triggered,
            \item the PAI\footnote{Process After Input.} event is triggered, which
               is the normal case.
         \end{itemize}
      \item The actions assigned to the triggered event are performed.
   \end{enumerate}

   Figure \ref{works} shows a usual basic cycle, figure \ref{dyninter} gives the
   possible execution steps of the DynPro interpreter. 
   
   \fig{works}{The Model for interactive Programs}{chapter3/works.eps}
   \fig{dyninter}{Execution steps of the DynPro interpreter}{chapter3/dyninter.eps}

   \subsection{An Example of a SAP R/3 DynPro}

   This text is not intended to be a handbook for ABAP/4 programming.
   Instead, some of the features will be shown through an example, typical
   of R/3 applications.

   The example is the DynPro 100 of the function group FM22. The function
   group provides functionality to maintain funds centers, like the
   transaction FM2I, which creates a new funds center. Other transactions are
   FM2S (shows an existing funds center) and FM2U (updates/changes an existing
   funds center). It is very common in R/3 to have such three transactions
   (insert/show/update) for one object.

   In DynPro 100, shown in figure \ref{FM2ID100}, the user has to type in
   the funds center (Finanzstelle) and the superordinated FM area (Finanzkreis)
   he or she wants to insert or update or look at.
   This DynPro will be explained in same depth at the end of this chapter, the
   source code is given in appendix \ref{sources}.

   \fig{FM2ID100}{Transaction FM2I, DynPro 100}{chapter3/fm2id100.eps}
   
   \subsection{Components and Attributes of DynPros}

   A DynPro\footnote{Dynamic Program.} consists of several components:
   \begin{description}
      \item[DynPro attributes] tell the DynPro number, the number of the DynPro that
         should follow it by default , and some other attributes
      \item[Screen layout] tells what fields should appear in the DynPro and where
      \item[Field attributes] tell the properties of each field in the DynPro
      \item[Flow logic] tells what ABAP/4 routines should be called for the DynPro
   \end{description}
   \footnote{taken form \cite{OD}, slightly modified.}
   
   The single components will be explained by the example of DynPro 100, Transaction
   FM2I (insert).
   
   \subsubsection{DynPro Attributes}

   Main attributes are:
   \smallskip
   
   \noindent
   \begin{tabular}{|l|l|p{7cm}|}
      \hline
      \emph{Attribute} & \emph{Value} & \emph{Explanation} \\
      \hline
      Progam & SAPLFM22 & to every function group there exists
                            a program object named SAPL\dots \\
      \hline
      Number & 100 & this is DynPro number 100 \\
      \hline
      Original Language & D & the language the DynPro has originally been created in,
                              in this case is was created in German \\
      \hline
      Description & \dots & short description of what the DynPro does \\
      \hline
      Type & normal & this is a normal DynPro, no special functionality \\
      \hline
      Next DynPro & 100 & by default the succeeding DynPro is number 100, itself. \\
     \hline
   \end{tabular}

   \subsubsection{Screen Layout}

   The screen layout is designed with a special tool, the screen painter. The required
   fields are inserted and placed on the screen. This mask will be used later by the
   DynPro interpreter.
   
   \subsubsection{Field Attributes}

   DynPro 100 has got the following fields:
   \smallskip

   \noindent
   \begin{tabular}{|l|l|l|c|p{4.75cm}|}
     \hline
     \emph{Field Name} & \emph{Type} & \emph{Format} & \emph{Length} & \emph{Remark} \\
     \hline
     IFMFCTR-FIKRS & Text & CHAR & 15 & shows the string `Finanzkreis'. \\
     \hline
     IFMFCTR-FIKRS & I/O & CHAR & 4 & in this field the  FM area is typed in. It has got
                                      the matchcode FIKRS assigned. \\
     \hline
     IFMFCTR-FICTR & Text & CHAR & 15 & shows the string `Finanz-stelle'. \\
     \hline
     IFMFCTR-FICTR & I/O & CHAR & 10 & in this field the funds center is typed in.
                                       It has got the matchcode FIST assigned. \\
     \hline
     OK\_CODE & OK & & & returns function code. \\
     \hline
   \end{tabular}
   \quad
   
   The OK-field serves a special purpose: Buttons have got a function code assigned.
   Whenever a button is pressed, the input is ended and the function code of the
   pressed button is written into the OK-field. When the input is ended by pressing
   the return-key, the value of the OK-field is SPACE.
   
   \subsubsection{Flow Logic}

   \begin{figure}
      \oben{15cm}
      \begin{tabbing}
        \quad\=\quad \=\quad \= \kill
        \textbf{PROCESS BEFORE OUTPUT.}\\
        \>\textbf{MODULE} D0100\_INDEPENDENT.\\
        \>\textbf{MODULE} D0100\_MODIFY\_SCREEN.\\
        \>\textbf{MODULE} D0100\_SET\_PF-STATUS. \\
        \\
        \textbf{PROCESS AFTER INPUT.} \\
        \>\textbf{MODULE} D0100\_EXIT \textbf{AT EXIT COMMAND.}\\
        \>\>\textbf{CHAIN.} \\
        \>\>\>\textbf{FIELD:} IFMFCTR-FIKRS, IFMFCTR-FICTR.\\
        \textit{* check for illegal characters}\\
        \>\>\>\textbf{MODULE} CHECK\_SONDERZEICHEN.\\
        \textit{* store key of FM area in a gobal variable}\\
        \>\>\>\textbf{MODULE} D0100\_DB\_KEY\_NOTICE.\\
        \textit{* is the user entitled to do the transaction?}\\
        \>\>\>\textbf{MODULE} AUTHORITY\_CHECK\\
        \textit{ * set a lock on the table FMFCTR, holding the funds centers}\\
        \>\>\>\textbf{MODULE} FMFCTR\_ENQUEUE.\\
        \textit{* read attributes of funds center}\\
        \>\>\>\textbf{MODULE} FMFCTR\_LESEN.\\
        \>\>\textbf{ENDCHAIN.}\\
        \textit{* set next DynPro to be executed}\\
        \>\>\textbf{FIELD} OK\_CODE \textbf{MODULE} D0100\_OK\_CODE.
      \end{tabbing}
      \unten
      \caption{Flow Logic of DynPro 100, Program SAPLFM22} \label{flowlogic100}
   \end{figure}

   The flow logic consists of key words marking the beginning of a section
   to be processed at an event, module calls and error handling.

   Consider the flow logic in figure \ref{flowlogic100}: the module
   D0100\_INDEPENDENT is called after the PBO event has occurred. The module
   D0100\_EXIT is called when the user wants to exit the current transaction,
   the module D0100\_OK\_CODE is called at the PAI event and the input is valid.

   When an error message is issued, all fields enumerated by the FIELD-command
   can be reentered. The CHAIN-ENDCHAIN-command defines a block in which the
   FIELD-COMMAND is valid.
   
   \subsection{Characteristics of ABAP/4}
   
   Some of the ABAP/4 charcteristics are:
   \begin{itemize}
      \item ABAP/4 code is interpreted
      \item the syntax reminds the user of COBOL and BASIC
      \item the syntax is context-sensitive
      \item more than 200 key-words in version 3.0C, with an increasing tendency
      \item little orthogonality.
   \end{itemize}

   From a computer scientist's point of view, the language is very old-
   fashioned and not well designed. Its size and complexity has grown
   in time and SAP was not able, or did not want to, redesign the
   language. This has led to a language full of contradictions and
   irregularities. Nevertheless, in ABAP/4 there are some concepts 
   worth having a closer look at. For a detailed introduction to
   ABAP/4 see, e.g., \cite{koch}, \cite{kretschmer}, \cite{BIS} or
   \cite{matzke}.

   \subsubsection{Consistent Definitions of ABAP/4 variables and DDic Objects}

   A major problem of every programmable database system is to keep the
   definitions of program variables consistent with the definitions made
   in the database, in the case of R/3 the Data Dictionary.

   In R/3 variables can be defined with the `LIKE'-operator, which has
   the form `\textit{variable} \textbf{LIKE} \textit{DDic object}'. This causes
   the ABAP/4 interpreter to look up the definition of the DDic object
   and to use that definition for the ABAP/4 variables.
   E.g. the ABAP/4 statement `\textbf{DATA} G\_FIKRS \textbf{LIKE} FM01-FIKRS \textbf{.}'
   \footnote{excerpt from the include LFM22DEC.}
   defines a variable called G\_FIKRS which has got the same definition as the
   field FIKRS in the table FM01. Since ABAP/4 is interpreted, every time
   the variable G\_FIKRS is defined, it has got the same definition as the
   field FM01-FIKRS in the Data Dictionary.

   The LIKE-operator can be used with any DDic object, especially tables and
   structures. This is very important, because when new fields are added
   or the definition of fields are altered, older programs using the
   table or structure will still work. Otherwise the process of customizing would
   not only include the altering of tables but also the altering of all
   applications using these tables. This would obviously be not feasible.

   \subsubsection{Locking of Database Tables}

   To guarantee data consistency, database tables must be locked the moment
   they are used. As described before, this is done by locking objects
   and the system automatically generates function modules to request (enqueue) and to
   end a lock (dequeue). Figure \ref{locking} shows an example for the invocation
   of a locking object.

   \begin{figure}
      \oben{9cm}
      \begin{tabbing}
         CALLL\=\quad\quad \=\quad \= \kill
         \textbf{CALL FUNCTION} 'ENQUE\_EFMFCTR' \\
         \>\textbf{EXPORTING} \\
         \>\>FIKRS = G\_FIKRS \\
         \>\>FICTR = G\_FICTR \\
         \>\textbf{EXCEPTIONS} \\
         \>\>FOREIGN\_LOCK = 1 \\
         \>\>SYSTEM\_FAILURE = 2 
      \end{tabbing}
      \unten
      \caption{Invocation of a Locking Object} \label{locking}
   \end{figure}

   In ABAP/4, database tables cannot be locked directly, all 
   locking must be done via locking objects. Again, the indirection pays off when
   definitions or dependencies in the Data Dictionary are changed. Old programs
   will still work after a locking object has been changed.

   \subsubsection{Persistency}

   The underlying SQL database is the persistent store for ABAP/4. In addition, ABAP/4
   can handle files, but this is recommended for temporary data or information
   interchange with other programs only.

   ABAP/4 has got a built-in dialect of SQL, the so called \textit{Open SQL} language.
   Open SQL is similar to the usual SQL\footnote{for further information about SQL,
   see, e.g., \cite{Lynch} or \cite{ziemer}.}, there are some modifications due
   to the tight integration in ABAP/4.

   It is also possible to use the SQL language of the underlying database, the language
   is called \textit{Native SQL}. It is not wise to use Native SQL, for the
   applications may not be usable in other R/3 systems.

   \subsubsection{Dynamic Screen Modification}

   Different groups of users are interested in the same objects,
   but they all want to manipulate it from their point of view. Databases take that into
   account by views, R/3 allows to change the screen mask during
   execution. This is done in a PBO module, figure \ref{modyScreen} shows
   an example.

   \begin{figure}
      \oben{12cm}
      \begin{tabbing}
      \quad\=\quad \=\quad \=\quad \= \kill
      \textbf{MODULE} D0100\_MODIFY\_SCREEN. \\
      \>\>\textbf{LOOP AT SCREEN.}  \\
      \>\>\>\textit{''/ if (( Feldname = 'Finanzkreis' ) und ( TA ist abh\"angig ) )}  \\
      \>\>\>\textbf{IF} ( ( SCREEN-NAME = 'IFMFCTR-FIKRS' )  \\
      \>\>\>\textbf{AND} ( FLG\_CALLD = CON\_DEPENDANT\_TA ) ).  \\
      \>\>\>\textit{''/ Feld dient nur zur Anzeige}  \\
      \>\>\>\>SCREEN-INPUT  = 0.        \textit{''/'0A'  in HEX}  \\ 
      \>\>\>\>\textbf{MODIFY} SCREEN.  \\
      \>\>\>\textbf{ENDIF.} \textit{''/ SCREEN-NAME}  \\
      \>\>\textbf{ENDLOOP.} \textit{''/ SCREEN.} \\
      \textbf{ENDMODULE.} \textit{''/ D0100\_MODIFY\_SCREEN} \\
      \end{tabbing}
      \unten
      \caption{Dynamic Screen Modification} \label{modyScreen}
   \end{figure}
   
%*********************************************
%*   Chapter Customizing & System Evolution  *
%*********************************************

   \chapter{Customizing and System Evolution} \label{cu}

   Customizing is a method intended for

   \begin{itemize}
      \item implementing the R/3 System
      \item enhancing of the R/3 System
      \item undertaking a release upgrade and system upgrade.
   \end{itemize}

   \noindent
   Customizing

   \begin{itemize}
      \item provides the \textit{procedure model}, the work breakdown structure for
         implementation and enhancement of the R/3 System
      \item provides tools for system configuration and the necessary
         documentation
      \item provides the \textit{customizing project} which gives the user tools for
         management, processing and evaluation of his or her implementation or
         enhancement projects
      \item gives configuration recommendations and tools to enable this
      \item helps to transfer the System configuration from the development
         environment into the production environment
      \item gives a set of tools for system upgrades and release upgrades.
   \end{itemize}
   \footnote{taken from \cite{OD}.}

   To implement the system means in the customizing context, to introduce R/3
   in the actual company.
   
%************************
   \section{Customizing: The Procedure Model}

   The procedure model is the basic element of customizing. The aim of the procedure
   model is a structured organization of the R/3 implementation.
   \footnote{taken from \cite{OD}.}
   It is a high level description of what is to be done.

   The procedure model consists of four phases:
   \begin{enumerate}
      \item \textbf{Organization and conceptual design}. The focus when creating the conceptual
         design is to use the R/3 reference model to help to work out how the R/3 business
         application components support the company's processes and functions. Other
         steps are e.g. to train the project team and to design interfaces and enhancements.
      \item \textbf{Detailed design and system setup}. The result of the phase `Detailing and
         Implementation' is the checked company-specific application system which will
         be released for phase 3 (production preparation).
      \item \textbf{Preparations for going live}. The result of the `Production Preparation' phase
         is a checked and released production system.
      \item \textbf{Productive operation}. The result of the phase `Production' is the organization
         and execution of a continuous optimization and support of the productive operation.
   \end{enumerate}
   \footnote{result descriptions are taken from \cite{OD}.} Figure \ref{procModel} shows the
   steps of the procedure model in R/3 3.0C.

   \fig{procModel}{The Procedure Model}{chapter4/procmod.eps}

%************************
   \section{Customizing: The Implementation Guide}

   The implementation guide (IMG) describes what has to be done concretely and is related
   to the actual customizing project. Furthermore, it contains the necessary sequence of
   activities and the user can start the appropriate customizing transactions.
   The IMG is the central element of the customizing process.

   Of course, there need to be different IMGs for different companies and projects.
   SAP introduced four levels of IMGs:
   \begin{description}
      \item[The SAP Reference IMG] contains documentation on all the business application
         components supplied by SAP.
      \item[The Enterprise IMG] is a subset of the SAP Reference IMG and contains
         documentation for those components to be implemented only.
      \item[Project IMGs] are Enterprise IMG subsets containing just the documentation
         for Enterprise IMG components to be implemented in particular Customizing projects
      \item[Upgrade Customizing IMGs] are based either on the Enterprise IMG or on a Project
         IMG and show, for a given release upgrade, all the documents that are linked to
         a release note. 
   \end{description}
   \footnote{descriptions taken from \cite{OD}.} IMGs are created by the execution
   of special SAP transactions.

%************************
   \section{Technical Realizing}

   Customizing is realized by filling in data into certain customizing tables or
   leaving them with the default data. R/3 standard modules react to customizing
   data, standard code should not be changed.  In same ABAP/4 modules, R/3 provides
   `gateways' to user-defined ABAP/4 functions. Obviously this is restricted to
   foreseen cases only. But within the implementation process it may prove
   necessary to add additional functionality to the system where no `gateways' or
   customizing is provided. The only way is to write programs which are highly
   linked with standard code, which can lead to trouble when SAP decides to change
   some of the standard code.

%************************
   \section{Common Problems}

   A big problem when implementing R/3 is to find out which SAP modules \footnote{FI, TR, HR,\dots}
   and functions provide the required functionality. E.g., employees may be modeled best as
   suppliers when coming to controlling matters. \footnote{See \cite{FF} for details.}

   A top-down-approach to the problem is
   \begin{enumerate}
      \item to read the functional description of a module in the SAP documentation
         on a high level
      \item to read the documentation `Functions in Detail', provided by SAP
      \item to analyze the EPCs
      \item to analyze the data model
      \item to check the functionality with appropriate testing data.
   \end{enumerate}

   Customizing is a long process which involves a lot of reading. The pure amount of
   documentation for customizing and the problem of finding out the required information
   and functions shows that this way of customizing a large system is a dead end.

%************************
   \section{System Evolution}

   In an R/3 system, there exists exactly one \textit{original} object and any number
   of copies. The \textit{Workbench Organizer} takes care, that no copies of an object
   can be changed. To propagate changes of the original object in the system, the so called
   \textit{transport system} is used. It replaces old copies of the original object with
   new copies.

   The transport system is used for a system upgrade as well. All changes are transported
   from the SAP original objects into client 0, the default client. From there,
   the changes can be transported to the required destinies in the system.
   Development classes are the basic objects, that can be transported.
   

%************************************
%*   Chapter Architectural Aspects  *
%************************************

   \chapter{Architectural Aspects of R/3} \label{ta}

   In this chapter, R/3's technical construction will be sketched briefly. System R
   was first implemented on mainframes and the resulting structure is still clearly
   visible.

%************************
   \section{Distributed Architecture}

   Every R/3 System consists of three tiers or layers:
   \begin{description}
      \item[Presentation layer]: The graphical user interface (SAPGUI) is run on
         this layer. No application logic is processed.
      \item[Application layer]: This layer executes the application logic, like
         DynPros and ABAP/4 modules. It sends the data to be presented to the user
         to the presentation layer.
      \item[Database layer]: This layer holds the system-wide database and the
         central booking process.
   \end{description}
   All three layers must exist, but they may be on one computer. In `normal'
   R/3 systems, the layers will be on separate computers.
   Figure \ref{tiers} shows the three layers and the communication between
   the most important components. \footnote{example taken from \cite{Will}.}
   \fig{tiers}{Three Tiers in an R/3 System}{chapter5/tiers.eps}

   TCP/IP is used as the communication protocol within R/3. With LU 6.2 it is possible
   to communicate with IBM mainframes. Figure \ref{communication} shows protocols
   in R/3.\footnote{picture taken from \cite{Buck}, translated.}

   On top of the communication protocol, a presentation protocol is used for data exchange between the presentation layer
   and the application layer. This SAP protocol is to minimize the amount of
   data to be exchanged for a switch from the current screen to the next.

   Remote SQL is used to exchange data between the database and the application
   layer.
   \fig{communication}{Communication Protocols used in R/3}{chapter5/prots.eps}

%************************
   \section{Process Architecture}

   \fig{SystemOMT}{R/3 in OMT notation}{chapter5/sysOMT.eps}
   Figure \ref{SystemOMT} gives a representation of R/3 in OMT.
   
   An R/3 System consists of at least one presentation server, at least one
   application server and exactly one database server. R/3 does not support
   distributed databases. SAP claims that distributed databases are not safe enough
   for practical use.

   Every application server has got one message server which handles the communication
   with other system servers. There can be at most one gateway server in a R/3 System,
   which handles the communication with other systems, either other R/3 Systems
   or systems form other vendors.

   The central element of an application server is the \textit{dispatcher} which controls
   the \textit{workprocesses}.  The dispatcher assigns the jobs to the appropriate
   workprocess.

   The workprocesses (WP) do the actual work, having their own taskhandler, DynPro processor,
   ABAP/4 processor and database interface. One can imagine a WP as `R/3 in a nutshell',
   being specialized on special jobs.
   \begin{description}
      \item[Dialog WPs]: Execute DynPros and ABAP/4 modules which are called in the
               flow logic. At the beginning of a basic cycle \footnote{see chapter 3.}
               the dispatcher assigns the request by the presentation server to an
               idle Dialog WP, which then does all preparations for screen output, like executing
               the ABAP/4 modules assigned to the PBO event. After transmitting the new
               screen layout to the presentation server, the Dialog WP is idle again. When the
               user has ended the input, the dispatcher will again look for an idle Dialog WP
               to execute the requested actions.
      \item[Batch WPs]: Batch WPs are used instead of Dialog WPs when the input is a
               batch input.
      \item[Spool WPs]: They do the internal spooling, like printing or transferring data to
               the database.
      \item[Enqueue WPs]: An Enqueue WP is specialized on the locking of DDic objects.
   \end{description}
   Figure \ref{WPOMT} shows workprocesses in OMT notation.
   \fig{WPOMT}{Workprocesses}{chapter5/WPOMT.eps}
   
%************************
   \section{Gateways to other Systems}

   R/3 has interfaces to all layers.
   \begin{itemize}
      \item Presentation layer: Intelligent Terminal
      \item Application layer: Files, CPI-C, RFC, OLE (Windows only), email, EDI,
            Business API (BAPI, not implemented in R/3 3.0C)
      \item Database layer: ODBC, Remote SQL.
   \end{itemize}

   The interfaces to the application layer have distinct control possibilities, e.g.:
   \vspace{.25cm}
   
   \noindent
   \begin{tabular}{l|c|c|c|c} % |l|c|r|p{Xcm}
               & Data import & Data export & Control from & Control of \\
               &             &             & outside      & external Software \\
      \hline
      Files    & X           & X & &\\
      \hline   
      RFC      & X           & X            &   X           & X\\
      \hline
      OLE      & X            &X            & X             & X\\
      \hline
      ODBC,    & X            & X & &\\
      remote SQL & & & &
   \end{tabular}
   \vspace{.25cm}
   
   The best way to interact with R/3 on a program to program base is the RFC 
   mechanism for it has full control and is platform-independent. Function modules
   can be called via RFCs, they prove again to be a useful concept.
   \footnote{please refer to \cite{lutz} for further reading about RFCs and R/3.}

%************************************
%*            Conclusion            *
%************************************

   \chapter*{Conclusion}
   \addcontentsline{toc}{chapter}{Conclusion}

   In R/3, SAP implemented some good concepts and ideas:
   \begin{itemize}
      \item The idea of customizing has proved invaluable to business
            software. It is a further step in the concept of re-usability
            of software components, brought to a level that even non-programmers
            can handle.
      \item The concept of ACID transactions not only on the level of databases but
            on the level of business processes overcomes a shortening of the
            relational model of data. SAP transcations are far nearer to the real world.
   \end{itemize}

   But, as always, there less favourable aspects, too:
   \begin{itemize}
      \item The technical realizing of customizing is a dead end.
      \item The ACID property of SAP transactions is not supported by any high-level
            programming concept, leaving the fulfillment of the ACID property entirely to
            the programmer.
      \item ABAP/4 is irregular and contains many useless concepts.
      \item R/3 does not scale in a real sense.
   \end{itemize}

%************************************
%*           Appendix A             *
%************************************

   \appendix
   \chapter{Notation: OMT Class Diagrams}

   In this text OMT\footnote{OMT is a abbreviation for 
   `Object orientated Modeling Technique'.} class diagrams are used to model R/3 itself. 
   Figure \ref{OMT} shows a short summary of OMT symbols. 

   A class has got a name, attributes and operations. 
   A class \textbf{student},e.g., could have \textbf{number} as attribute and 
   \textbf{graduate} as operation. An instance would be a concrete student.
  
   The class \textbf{person} could be a super-class of the class \textbf{student}
   meaning that every student is a person as well.
 
   The class \textbf{student} could be associated with the class \textbf{tutors}
   and the class \textbf{student} aggregates over the class \textbf{registration data}.
   Note the difference 
   between an aggregation and an association: When an instance is deleted, 
   associated instances are \emph{not} deleted, aggregated instances \emph{are}
   deleted. Figure \ref{studOMT} shows the appropriate OMT class  diagram.

   See \cite{Rumbaugh} for further details of the OMT Notation.

   \fig{OMT}{The OMT notation}{append/omt.eps}
   \fig{studOMT}{The Example Screnario}{append/studOMT.eps}

%************************************
%*           Appendix B             *
%************************************

   \chapter{A Meta-Model for R/3}

   Figure \ref{R3Arch} states the R/3 client/server architecture in an
   OMT diagram.
   Figure \ref{completeOMT} shows all R/3 objects mentioned in this text
   in one diagram.

   \begin{figure}[hb]
     \begin{center}
     \fbox{\rotatebox{0}{\includegraphics[height=12cm]{figures/append/R3_arch.eps}}}
     \caption{The R/3 System Architecture} \label{R3Arch}
     \end{center}
   \end{figure}
   
   \begin{figure}
     \rotatebox{90}{\includegraphics[scale=.9]{figures/append/R3_meta}}
     \caption{An Meta-Model for R/3 Objects}
     \label{completeOMT}
   \end{figure}

%************************************
%*           Appendix C             *
%************************************

   \chapter{Source Code of FM22, DynPro 100} \label{sources}

   The complete source code can be found in the program SAPLFM22. The
   code given here is a subset which is executed during DynPro 100.
   The reader should get an impression of what ABAP/4 programs look like.
  
\begin{verbatim}   
* Programmkopf
FUNCTION-POOL FM22 MESSAGE-ID FI.
...
*-----------------------------------------------------------------------
* DEC - lokale Datenbeschreibungen Tabellen / Daten / Field-Symbols
*-----------------------------------------------------------------------
INCLUDE LFM22DEC.
...
*-----------------------------------------------------------------------
* Interne Tabellen
*-----------------------------------------------------------------------

* Interne Tabelle für die Finanzstelle zur Datenhaltung
* und zur Datenübergabe zwischen den Dynpros
DATA: BEGIN OF I_FMFCTR OCCURS 10.
        INCLUDE STRUCTURE IFMFCTR.
DATA: END OF I_FMFCTR.

* Sicherung unbearbeitetes Dynpro
DATA: BEGIN OF I_OLD_FMFCTR.
        INCLUDE STRUCTURE IFMFCTR.
DATA: END OF I_OLD_FMFCTR.
...

TABLES:
        "/ Finanzkreis
        FM01,
        "/ Texte zum Finanzkreis
        FM01T,
        "/ Finanzstelle
        FMFCTR,
        "/ Interne Tabelle für die Dynprofelder der Finanzstelle
        IFMFCTR.

* Feldleiste für die Finanzstelle
DATA: BEGIN OF FFMFCTR.
        INCLUDE STRUCTURE IFMFCTR.
DATA: END OF FFMFCTR.

DATA:
      "/Finanzkreis
      G_FIKRS           LIKE FM01-FIKRS,
      "/Finanzstelle
      G_FICTR           LIKE FMFCTR-FICTR,
      "/Transaktionscode
      G_TCODE           LIKE SY-TCODE,
      "/Flag um zu signalisieren, ob die TA / Function abhängig aufgerufen wurde.
      FLG_CALLD         LIKE SY-CALLD  VALUE 0.
...

MODULE D0100_MODIFY_SCREEN.
*----------------------------------------------------------------------*
*    Dynamische Bildmodifikation für Dynpro 0100:                      *
*    - Feld 'Finanzstelle' auf Länge 10 reduzieren                     *
*    - Feld 'Finanzkreis' ist bei Neuanlage aus der Grafik heraus      *
*      nur ein Anzeigefeld                                             *
*----------------------------------------------------------------------*
*----------------------------------------------------------------------*

"/ Schleife über alle Dynprofelder
   LOOP AT SCREEN.
     "/ if (( Feldname = 'Finanzkreis' ) und ( TA ist abhängig ) )
     IF ( ( SCREEN-NAME = 'IFMFCTR-FIKRS' )
        AND ( FLG_CALLD = CON_DEPENDANT_TA ) ).
        "/ Feld dient nur zur Anzeige
        SCREEN-INPUT  = 0.        "/'0A'  in HEX
        MODIFY SCREEN.
     ENDIF. "/ SCREEN-NAME
   ENDLOOP. "/ SCREEN.

ENDMODULE. "/ D0100_MODIFY_SCREEN
...

MODULE D0100_EXIT.
*----------------------------------------------------------------------*
*      Funktionen, die die aktuelle Bearbeitung beenden                *
*      ohne die PAI-Module, -Prüfungen zu aktivieren.                  *
*      LEAVE TO TRANSACTION löst automatisch das Freigeben aller       *
*      Sperren der Transaktion aus!                                    *
*----------------------------------------------------------------------*
  "/ Zwischenspeichern des OK_CODE
  SAV_OK_CODE = OK_CODE.
  CLEAR OK_CODE.
  "/ Auswerten des OK_CODE
  CASE SAV_OK_CODE.
    "/  ENDE = Beenden
    WHEN 'ENDE'.
         SET SCREEN 0.
         LEAVE SCREEN.
    "/  EINS = In Anlegen-TA verzweigen
    WHEN 'EINS'.
         "/ Rufe Transaktion 'Anlegen'
         LEAVE TO TRANSACTION TR_FICTR_INS.
  ENDCASE.

ENDMODULE. "/ D0100_EXIT
...

MODULE CHECK_SONDERZEICHEN INPUT.
  FIELD-SYMBOLS <F>.

  IF SY-TCODE = TR_FICTR_INS
  OR SY-TCODE = TR_FICTRHI_MNTN.
    IF IFMFCTR-FICTR CA CON_SONDERZEICHEN.
      ASSIGN IFMFCTR-FICTR+SY-FDPOS(1) TO <F>.
      MESSAGE E669 WITH <F>.
    ENDIF.
  ENDIF.
ENDMODULE.                 " CHECK_SONDERZEICHEN  INPUT
...

MODULE D0100_DB_KEY_NOTICE.
*  Schlüssel der Finanzstelle in globalen Variablen merken
   "/Finanzkreis
   CONDENSE IFMFCTR-FIKRS NO-GAPS.
   G_FIKRS = IFMFCTR-FIKRS.
   "/Finanzstelle
   CONDENSE IFMFCTR-FICTR NO-GAPS.
   G_FICTR = IFMFCTR-FICTR.
   "/if ( TA ist unabhängig )
   IF ( FLG_CALLD = CON_INDEPENDANT_TA ).
      "/Variablen initialisieren, die bei abhängigem Aufruf aus der Grafik kommen.
      "/Lese den Finanzkreis
      SELECT SINGLE *
      FROM FM01
      WHERE FIKRS = G_FIKRS.
      "/Objektnummer des Finanzkreises übernehmen
      G_FMA_OBJNR = FM01-OBJNR.
      "/Einfügen ohne kopieren
      FLG_COPY = CON_NEIN.
      "/Variable initialisieren
      CLEAR G_REF_FICTR.
   ENDIF.
ENDMODULE. "/ D0100_DB_KEY_NOTICE
...

MODULE FMFCTR_ENQUEUE INPUT. "/Prozedur zum Sperren einer Finanzstelle aufrufen
  PERFORM FMCTR_ENQUEUE.
ENDMODULE. "/ FMFCTR_ENQUEUE

FORM FMFCTR_ENQUEUE.
"/ if ( Anlegen oder ändern einer Finanzstelle )
   CHECK ( ( G_TCODE = TR_FICTR_INS )
      OR   ( G_TCODE = TR_FICTR_UPD ) ).
      "/ Sperre für eine Finanzstelle anfordern
      CALL FUNCTION 'ENQUEUE_EFMFCTR'
           EXPORTING
             FIKRS    = G_FIKRS
             FICTR    = G_FICTR
           EXCEPTIONS
             FOREIGN_LOCK   = 1
             SYSTEM_FAILURE = 2.
      CASE SY-SUBRC. "/ Fehlerbehandlung
        WHEN 1.  "/bereits von anderem User gesperrt (FOREIGN_LOCK)
             MESSAGE E641 WITH G_FICTR.
        WHEN 2.  "/ SYSTEM_FAILURE bei einer Sperranforderung
             MESSAGE A521 WITH G_FICTR.
      ENDCASE. "/ SY-SUBRC
ENDFORM. "/ FMFCTR_ENQUEUE
...

MODULE FMFCTR_LESEN. 
  PERFORM FMFCTR_LESEN. "/ Aufruf der Prozedur zum Lesen der Finanzstelle
ENDMODULE. "/ FMFCTR_LESEN.

FORM FMFCTR_LESEN.
  DATA: L_FMFCTR_EXISTS LIKE CON_JA. "/Flag Finanzstelle existiert
  IF ( G_TCODE = TR_FICTR_UPD OR G_TCODE = TR_FICTR_SHOW ).
        PERFORM FMFCTR_LESEN_UPD USING    G_FIKRS          "/VALUE
                                          G_FICTR          "/VALUE
                                 CHANGING L_FMFCTR_EXISTS. "/VALUE
  ELSE.
        PERFORM FMFCTR_LESEN_INS USING G_FIKRS       "/VALUE
                                       G_FICTR       "/VALUE
                                       FLG_COPY      "/VALUE
                                       G_REF_FICTR.  "/VALUE
  ENDIF. "/G_TCODE
ENDFORM. "/FMFCTR_LESEN.

FORM FMFCTR_LESEN_INS USING    VALUE(P_FIKRS)
                               VALUE(P_FICTR)
                               VALUE(P_COPY)
                               VALUE(P_REF_FICTR).
  ...
  IF ( L_FMFCTR_EXISTS = CON_JA ). "/ Fehlermeldung und im Dynpro bleiben
    MESSAGE E642 WITH P_FIKRS P_FICTR.
  ...
ENDFORM. "/FMFCTR_LESEN_INS
...

MODULE D0100_OK_CODE INPUT.
*----------------------------------------------------------------------*
* Auswertung der Benutzerkommandos im Dynpro 100                       *
*----------------------------------------------------------------------*

  "/ Zwischenspeichern des OK_CODE
  SAV_OK_CODE = OK_CODE.
  CLEAR OK_CODE.

  "/ Auswerten des OK_CODE
  CASE SAV_OK_CODE.
    "/ ENTER
    WHEN SPACE.
      "/ Folgedynpro 200 aufrufen
      SET SCREEN 200.
      LEAVE SCREEN.
  ENDCASE.

ENDMODULE. "/ D0100_OK_CODE
\end{verbatim}

%************************************
%*           Bibliography           *
%************************************

   \newpage
   \addcontentsline{toc}{chapter}{Bibliography}
   \begin{thebibliography}{99}
     \bibitem{Codd} E.F. Codd, `A Relational Model of Data for
                  Large Shared Data Banks', \textit{Communications of
                  the ACM}, Vol. 13, No.6 (June 1970)
     \bibitem{Buck} R\"udiger Buck-Emden, J\"urgen Galimow, \textit{Die Client/Server-Technologie
                  des Systems R/3}, Addison-Wesley, Bonn 1994
     \bibitem{FF} Marko-Andreas Fricke, Stephan Fr\"olich, \textit{Flexible Haushaltsplanung
                  und Mittel-Controlling f\"ur einen Modellfachbereich}, Diplomarbeit,
                  Universit\"at Hamburg, 1997.
     \bibitem{kretschmer} R. Kretschmer, W. Weiss, \textit{Developing SAP's R/3
                  Applications with ABAP/4}, Sybex, San Francisco, Paris,
                  D\"usseldorf, Soest, 1996
     \bibitem{koch} Christian Koch, \textit{Einf\"uhrung in die ABAP/4
                  Entwicklungsumgebung}, research paper, 1996
     \bibitem{lutz} Sebastian Lutz, \textit{Eine polymorph-typisierte
                  Schnittstelle zwischen SAP R/3 und Tycoon}, Master-Theses,
                  Universit\"at Hamburg, 1997.
     \bibitem{BIS} Florian Matthes, \textit{Betriebswirtschaftliche
                  Informationssysteme am Beispiel SAP R/3}, lecture
                  notes, Technische Universit\"at Hamburg-Harburg,
                  http://www.sts.tu-harburg.de, 1997
     \bibitem{fm} Florian Matthes, \textit{Persistente Objektsysteme}, Springer-Verlag, 1993
     \bibitem{Lynch} E. Lynch, \textit{Understanding SQL}, MacMillan, London England,
                  1990
     \bibitem{matzke} Bernd Matzke, \textit{ABAP/4: Die Programmiersprache
                  des SAP Systems R/3}, Addison Wesley, Bonn, 1996
     \bibitem{Peterson} J. Peterson, \textit{Petri Net Theory and the Modelling
                  of Systems}, Prentice Hall, Englewood Cliffs, Nj., 1981
     \bibitem{Rumbaugh} Rumbaugh, Blaha, Permerlani, Eddy, Lorensen \textit{Object-Oriented
                  Modeling and Design}, Prentice Hall, Englewood Cliffs,
                  New Jersey 1992
     \bibitem{OD} R/3 System Release 3.0C, \textit{Online Documentation}, March 96
     \bibitem{Schmidt} Matthes, Schmidt, `Datenbankmodelle und Datenbanksprachen'
                  in: Schmidt, Lockemann, \textit{Datenbankhandbuch}, Springer-Verlag,
                  1997 (to appear)
     \bibitem{Will} Liane Will, \textit{R/3-Administration}, Addison-Wesley, Bonn 1995
     \bibitem{ziemer} Stephan Ziemer, \textit{SQL}, 1995,
                  http://www.sts.tu-harburg.de/\~\/people/st.ziemer.
   \end{thebibliography}  

\end{document}