Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Abstract
SAP is the market leader for integrated business administration systems, and its SAP R/3
product is a comprehensive enterprise resource planning software system which integrates
modules for nance, material management, sales and distribution, etc. Despite its interna-
tional commercial success, the models, languages and architecture of this system are to a large
degree unknown to computer scientists.
The goal of this tutorial is to present the distributed system architecture, the data model,
the database programming language, the transaction and process model and the system evo-
lution concepts of SAP R/3 from a computer science perspective and to relate them to estab-
lished database and distributed system concepts. The presentation will help attendees under-
stand how SAP R/3 relates to their own research and development work and will provide a
well-structured foundation for a further study of SAP R/3's innovative system concepts.
Contents
1 SAP R/3: Past, Presence and Future 3
2 The Integrated R/3 Repository 4
2.1 Integrated Analysis, Design and Implementation . . . . . . . . . . . . . . . . . 4
2.2 Coexistence of Multiple R/3 Clients . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Application and System Evolution . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4 Running Example: FM Areas and Funds Centers . . . . . . . . . . . . . . . . . 7
3 Enterprise Modeling with R/3 7
3.1 Data Modeling: Entities and Relationships . . . . . . . . . . . . . . . . . . . . 8
3.2 Functional Decomposition: R/3 Modules . . . . . . . . . . . . . . . . . . . . . . 9
3.3 Process Modeling: R/3 Reference Model and EPCs . . . . . . . . . . . . . . . . 9
4 Objects of the R/3 Data Dictionary 11
4.1 Data Modeling: Selected Data Dictionary Objects . . . . . . . . . . . . . . . . 12
4.1.1 Domains and Data Elements . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.2 Tables and Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.3 Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2 Process Modeling: Work
ows . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5 Programming with ABAP/4 and the DynPro Concept 14
5.1 Implementation-Oriented Data Dictionary Objects . . . . . . . . . . . . . . . . 14
5.1.1 Data Types and Type Groups . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1.2 Lock Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1.3 Matchcodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2 Programming in the Large: Development Class Objects . . . . . . . . . . . . . 16
5.2.1 R/3 Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2.2 Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2.3 Function Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2.4 Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2.5 Area Menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2.6 Other Development Class Objects . . . . . . . . . . . . . . . . . . . . . 19
5.3 Programming in the Small: Program Objects . . . . . . . . . . . . . . . . . . . 20
5.3.1 GUI Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.3.2 Dynpros { Elements of Interactive Transaction . . . . . . . . . . . . . . 21
5.3.3 An Example of an R/3 DynPro . . . . . . . . . . . . . . . . . . . . . . . 21
5.3.4 Components and Attributes of DynPros . . . . . . . . . . . . . . . . . . 23
5.3.5 Characteristics of ABAP/4 . . . . . . . . . . . . . . . . . . . . . . . . . 25
6 Customizing R/3: Concepts and Techniques 26
6.1 Customizing: The Procedure Model . . . . . . . . . . . . . . . . . . . . . . . . 26
6.2 Customizing: The Implementation Guide . . . . . . . . . . . . . . . . . . . . . 27
6.3 Customizing R/3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.4 System Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7 R/3's Process and System Architecture 28
7.1 Client/Server Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.2 Process Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.3 External Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
A Overview: R/3 Terminology and Concepts 31
B Source Code of FM22, DynPro 100 32
Further Reading 38
1 SAP R/3: Past, Presence and Future
The Past The company SAP, Walldorf, Germany, was founded in 1972 by ve IBM pro-
grammers. Their core business idea was to build one program suitable for many companies
instead of writing essentially the same business software again and again for dierent com-
panies. The system abstracts from the needs of a concrete company and implements the
processes of a generic company.
The `R' in R/3 stands for `real time' which means that the system is interactive and not
based on batch processing. `3' means that it is the third major version of the program, though
there has never been a system called `R/1'. R/3 was introduced in 1992 and by the end of 1995
more than 5,200 R/3 systems were installed worldwide. The latest release of R/3 is 4.0 (Feb
1998). There is still a number of R/2 installations, but SAP intends to move this customer
basis to R/3.
R/3 is a package of standard international business applications for areas such as Finan-
cial Accounting, Controlling, Logistics and Human Resources. R/3 provides an enterprise
solution for all these application areas in a distributed client/server environment. Using R/3,
a company can manage nancial accounting around the world, receive and track orders for
goods, and organize and retrieve employee information and records, among many other fea-
tures. Many Fortune 500 companies and high-tech companies (including American Airlines,
Chevron, IBM, Mercedes and Microsoft) run their businesses with R/3. The system is avail-
able on many hardware platforms and for many operating systems (Unix / NT).
To use R/3 for a concrete company, it is necessary to `customize' R/3 to suit the specic
needs. This kind of software is called `standard business software' or standard ERP software
(enterprise resource planning). Ideally, a customized R/3 installation can follow the evolu-
tion of R/3 (taking into account new tax or law regulations, new currencies, etc.) without
additional development eort.
The Future Hot technical topics for the future evolution of R/3 are [SAPHome 1997]
componentization (customers will be able to install and evolve independent releases of R/3
modules), business objects and BAPIs (newly developed client applications written in Java,
VisualBasic, Delphi etc. will have stable, semantically-rich APIs to the R/3 backend), the R/3
Business Engineer (customization will take place at a higher abstraction level than screens and
tables), and OO ABAP (a fully-upward-compatible extension of ABAP/4 with late binding
and a form of inheritance).
The Presence R/3 in its current release 4.0 is a massive client/server development and
application system which uses relational databases (Oracle, ADABAS-D, Informix, . . . ) as its
back-end. Cooperation between functions takes place by a traditional, tight database integra-
tion. In 1994, R/3 already comprised 7.000.000 lines of code, 100.000 function calls, 20.000
distinct functions 21.000 reports, 17.000 menu denitions and 14.000 function modules [Bun-
desministerium fur Forschung und Technologie 1994]. There are 500 developers working on
the core R/3 system, its size grows annually by an estimated 10 percent. Each customer has
to install the full R/3 application which consumes several GB on disk excluding any actual
business data.
The rest of this tuorial gives you an idea of the following technologies underlying R/3
which are also the basis for R/3's future development.
The integrated R/3 repository
Enterprise modeling with R/3
Objects of the R/3 data dictionary
Programming in the large
Programming in the small
Customizing R/3: concepts and techniques
R/3's process and system architecture
OMT class diagrams (similar to UML class diagrams) are used for conceptual modeling
purposes [Rumbaugh et al. 1991; Fowler and Scott 1997].
2 The Integrated R/3 Repository
Similar to a DBMS, R/3 relies heavily on meta-data describing its own data structures,
functions (modules) and processes (work
ows). Consistency between the meta-data and the
actual data is preserved either manually or automatically by the development tools. Using
the R/3 Repository Information System, developers can access and browse (textual, tabular
and graphical representions of) repository objects. This section provides a bird-eye view of
the repository and its major conceptual entities (see Fig. 4).
`
(YHQW %XVLQHVV 'HYHORSPHQW
FRQWUROOHG (QJHQHHULQJ FODVV 3URFHVV
SURFHVV 9LHZ
FKDLQ (3&
`
6$3 0RGXOH
)XQFWLRQ
$%$3 9LHZ
`
6$3 6(50 'DWD
UHDO ZRUOG
'LFWLRQDU\ 'DWD
64/ 9LHZ
5 5HSRVLWRU\
'DWD 'LFWLRQDU\
`
(YHQW :RUNIORZ 7UDQVDFWLRQ
)XQFWLRQ 3URFHVV
9LHZ
`
3URJUDP
5HSRUW )XQFWLRQ
9LHZ
`
(QLW\ 7DEOH $%$3
5HDO ZRUOG 'RPDLQ
5HODWLRQVKLS YDULDEOH 'DWD
)RUHLJQ NH\ 64/ WDEOH 9LHZ
&RQVLVWHQF\
0DQXDO 0DQXDO 7RRO
VXSSRUWHG `EHWZHHQ
PDLQWHQDQFH
OHYHOV
5 5HSRVLWRU\
&RQVXOWDQW &XVWRPL]LQJ
GDWD 'DWD
REMHFWV
&RPSDQ\ $SSOLFDWLRQ
GDWD
6\VWHP 5
5HSRVLWRU\
'DWD
GLFWLRQDU\
&RQVLVWV $SSOLFDWLRQ
2EMHFW
1DPH
&RQVLVWV 'HYROSPHQW FODVV
&RQVLVWV RI
GLFWLRQDU\ REMHFW
REMHFW
2ZQHU
6WDWH 7UDQVSRUW
7UDQVSRUW
&OLHQW ZLWK
ZLWK VHSHUDWH
VHSHUDWH GDWD
GDWD
5 V\VWHP
FRQWDLQLQJ
VKDUHG
GDWD
&OLHQW
&OLHQW
ZLWK
ZLWK
VHSHUDWH
VHSHUDWH
GDWD
GDWD
There are thousands of named objects of all kinds and combined with a strict limitation of
length (approx. 8 characters), the names are by no means self-explanatory. To worsen the
situation, English and German names and abbreviations are mixed.
SAP decided to leave the `name range' of all objects with a name that starts either with a
Y or a Z to customer objects. There are exceptions from this rule leading to some confusion.
SAP guarantees that there will be no name clashes with R/3 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 nd legacy objects that nobody dares to
remove or |in this case|- dares to rename for the consequences are largely unpredictable.
)XQGV FHQWHU
7KH )0 DUHD LV WKH FRPPHUFLDO RUJDQL]DWLRQDO XQLW ZLWKLQ ZKLFK FRPPLWPHQW DFFRXQWLQJ LV
FRQGXFWHG
)XQGV FHQWHU
+LHUDUFKLFDO
$JJUHJDWLQJ
5HIHUHQWLDO ,V D
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.
There cannot be a direct N:M relationship between entities in the data model!
Entities have some additional attributes, like a unique entity type number and
ags to
indicate whether the data is changed during customizing or during normal system operation
and whether the underling implementation is a table or a view. See Fig. 7 and Fig. 8.
Figure 9 is an excerpt from the data model for FM areas and funds centers. The full R/3
data model documented through this notation is distributed by SAP as huge posters which
are several square meters in size.
(DFK HQWLW\ RI WKH VRXUFH HQWLW\ W\SH KDV DW PRVW RQH GHSHQGHQW HQWLW\
&
(DFK HQWLW\ RI WKH VRXUFH HQWLW\ W\SH KDV DW OHDVW RQH GHSHQGHQW HQWLW\
0
(DFK HQWLW\ RI WKH VRXUFH HQWLW\ W\SH FDQ KDYH DQ\ QXPEHU RI GHSHQGHQW HQWLWLHV
&0
$9 $9
)LQDQFLDO + )XQGV &HQWHU
0DQDJHPHQW
$UHD
$9
&XUUHQF\
5
FKRRVH
)0 DHUD
)0 DUHD
H[LVWV
In the R/3 Reference Model, business processes that can be executed in the R/3 System
are described graphically as event controlled process chains (EPCs). An EPC uses events to
show the logical and chronological relationships between R/3 System functions [SAP AG 1996]
using the following graphical elements:
Function: describes what is to be done. The symbol is a hexagon.
Events: describing when things are to be done or at which stage the process is so far. The
symbol is a rounded box.
Organization unit type: describes who (which part of the company) is involved. The sym-
bol is an ellipse.
Information object: describes what kind of information is needed or produced.
Figure 10 shows a concrete example of an EPC to create a new funds center.
EPCs are 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 semantics of EPCs are dened on an informal base only. One can nd many con-
tradictions and irregularities in many EPCs published by SAP and others. Eorts are being
made to formalize EPCs so they can be checked automatically for inconsistencies.
6WDWH
'HILQHV YDOXHV
)LHOG
1DPH
The data dictionary itself is conceptually and technically a part of the integrated R/3
repository.
''LF REMHFW
'RPDLQ 7\SH
JURXS
%DVHG
RQ
'DWD W\SH
3URMHFWHG WR
1DPH
6WDWXV
,QFOXGHV ,QFOXGHV
7UDQVDFWLRQ
6WDUWV 3URJUDP REMHFW )XQFWLRQ 0HVVDJH /RJLFDO
8VHV
$XWKRUL]DWLRQ 0HVVDJH
REMHFW 1XPEHU
5HSRUW )XQFWLRQ PRGXOH
5(3257352*5$0 )81&7,21322/
,QWHUIDFH
%XVLQHVV 6(7*(7
'LDORJ ER[ $UHD PHQX &$77 SURFHGXUH
HQJHQHHULQJ SDUDPHWHU
REMHNW ,QWHUIDFH
&DOOV
8VHV
3URJUDPP REMHNW *8, VWDWXV 7UDQVDFWLRQV
&RGH
6WDUWV ZLWK
0RGXOH SRRO
LQ $%$3
'\Q3UR 3%2 3$, 6XEURXWLQH *OREDO *8, *8,
PRGXOH PRGXOH )RUP GDWD WLWOH VWDWXV
1XPEHU 7\SH &RGH
6FUHHQ
&DOOV
)ORZ ORJLF
([HFXWHV
'DWD H[FKDQJH E\ HTXDOLW\ RI QDPHV
'\Q3UR ILHOG
Dialog boxes are dialogs, which are used quite often in the system. It is possible to de-
ne new dialog boxes or to use predened, standardized dialog boxes. Several kinds of
standard dialog boxes are available [Kretschmer and Weiss 1997]: Conrmation prompt
dialog boxes, dialog boxes for choosing among alternatives, data print dialog boxes, and
text display dialog boxes.
SET-/GET-parameters are used to exchange data between R/3 transactions. Their main
purpose is to set values for input elds on the screen.
CATT-procedures (Computer Aided Test Tool procedures) are procedures submitted to
the R/3 CATT tool which help developers to test newly developed code, customized
parts of the system etc. with test data (simulating batch or user input).
*8, VWDWXVREMHFW
&RGH
5HIHUHQFHV
&RGH &RGH
0HQX LWHP
&RGH
actions or further submenus, like `Create Object. . . ', which lead to other menus and menu
items. A menu can cascade up to a depth of three levels
The tool bar is container for application-independent buttons, the application tool bar is
a container for application dependent buttons.
5.3.2 Dynpros { Elements of Interactive Transaction
To understand the programming concept of R/3 it is necessary to understand the model for
interactive programs. R/3 is mainly event-driven, events can be triggered by the system itself
or by the user.
The model is essentially screen-oriented, the follwoing cycle is processed for every screen
called (DynPro, see Fig. 19 and Fig. 20):
1. At the beginning of the cycle, everything attached to the PBO (Process Before Output)
event is executed. In most cases this will be actions to prepare data to be presented to
the user.
2. Next, the user does the actual input.
3. Depending on how the user terminated the input,
additional information is displayed,
another transaction is executed,
the EXIT-COMMAND-event is triggered,
the PAI (Process After Input) event is triggered, which is the normal case.
4. The actions assigned to the triggered event are performed.
'\Q3UR $ '\Q3UR %
WLPH
/HDYH WR
3URFHVV WUDQVDFWLRQ
VFUHHQ
2.&2'(
W\SH 7"
$7 (;,7
)"
&200
)"
$1'
2.&2'(
7UDQVIHU GDWD
([HFXWH 7UDQVIHU GDWD IURP W\SH ("
IURP $%$3 *LYH
3%2 '\Q3UR ILHOGV LQWR 1H[W
PRGXOHV
YDULDEOHV LQWR
'\Q3UR ILHOGV
KHOS
$%$3 YDULDEOHV 3%2
([HFXWH
6XE
3$,
URXWLQHV
/RFN FHUWDLQ PRGXOHV
'\Q3UR ILHOGV 0(66$*(
W\SH ("
6XE
URXWLQHV
center). It is very common in R/3 to have these three transactions (insert/show/update) for
a given object type.
In DynPro 100 (see Fig. 21), 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
means that DynPro 100 is shared by multiple transactions. The full source code can be found
in appendix B.
5.3.4 Components and Attributes of DynPros
A DynPro (Dynamic Program) consists of several components [SAP AG 1996]:
DynPro attributes include the DynPro number, the number of the DynPro that should
follow it by default, and some other attributes.
Screen layout species which elds should appear in the DynPro and where
Field attributes are properties of each eld in the DynPro.
Flow logic species which ABAP/4 routines should be called for the DynPro.
These components will be explained using the example of DynPro 100, Transaction FM2I
(insert).
DynPro Attributes
Attribute Value Explanation
Progam SAPLFM22 to every function group there exists a program
object named SAPL. . .
Number 100 this is DynPro number 100
Original Language D the language the DynPro has originally been cre-
ated in, in this case is was created in German
Description ... short description of what the DynPro does
Type normal this is a normal DynPro, no special functionality
Next DynPro 100 by default the next DynPro executed will be the
Dynpro 100
PROCESS BEFORE OUTPUT.
MODULE D0100 INDEPENDENT.
MODULE D0100 MODIFY SCREEN.
MODULE D0100 SET PF-STATUS.
PROCESS AFTER INPUT.
MODULE D0100 EXIT AT EXIT COMMAND.
CHAIN.
FIELD: IFMFCTR-FIKRS, IFMFCTR-FICTR.
* check for illegal characters
MODULE CHECK SONDERZEICHEN.
* store key of FM area in a gobal variable
MODULE D0100 DB KEY NOTICE.
* is the user entitled to do the transaction?
MODULE AUTHORITY CHECK
* set a lock on the table FMFCTR, holding the funds centers
MODULE FMFCTR ENQUEUE.
* read attributes of funds center
MODULE FMFCTR LESEN.
ENDCHAIN.
* set next DynPro to be executed
FIELD OK CODE MODULE D0100 OK CODE.
Screen Layout The screen layout is designed with a special tool, the screen painter. The
required elds are inserted and placed on the screen. This mask will be used later by the
DynPro interpreter.
Field Attributes
Field Name Type Format Length Remark
IFMFCTR-FIKRS Text CHAR 15 string literal `Finanzkreis'.
IFMFCTR-FIKRS I/O CHAR 4 input eld for FM area associated
with matchcode FIKRS to assist
user-input
IFMFCTR-FICTR Text CHAR 15 string literal `Finanzstelle'
IFMFCTR-FICTR I/O CHAR 10 input eld for funds center associ-
ated with matchcode FIST to as-
sist user-input
OK CODE OK function return code (menu selec-
tion, abort, . . . )
The OK-eld serves a special purpose: Buttons are identied by a function code. Whenever
a button is pressed, user input is terminated and the function code of the button is stored in
the OK-eld. When input is terminated by pressing the return-key, the value of the OK-eld
is SPACE.
Flow Logic The
ow logic consists of keywords identifying the beginning of a section to
be processed at an event, module calls and error handling.
Consider the
ow logic in Fig. 22: 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.
CALL FUNCTION 'ENQUE EFMFCTR'
EXPORTING
FIKRS = G FIKRS
FICTR = G FICTR
EXCEPTIONS
FOREIGN LOCK = 1
SYSTEM FAILURE = 2
When an error message is issued, all elds enumerated by the FIELD-command can be
reentered. The CHAIN-ENDCHAIN-command denes a block in which the FIELD-COMMAND
is valid.
5.3.5 Characteristics of ABAP/4
Some of the ABAP/4 charcteristics are:
ABAP/4 code is interpreted
the syntax reminds the user of COBOL and BASIC
the syntax is context-sensitive
more than 200 key-words in version 3.0C, with an increasing tendency
little orthogonality.
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., [Kretschmer and Weiss 1997], [Curran 1996a] or [Matzke
1996].
Consistent Denitions of ABAP/4 variables and DDic Objects A major prob-
lem of every programmable database system is to keep the denitions of program variables
consistent with the denitions made in the database, in the case of R/3 the Data Dictionary.
In R/3, variables can be dened with the `LIKE'-operator, which has the form `variable
LIKE DDic object '. This causes the ABAP/4 interpreter to look up the denition of the
DDic object and to use that denition for the ABAP/4 variables. For example, the ABAP/4
statement `DATA G FIKRS LIKE FM01-FIKRS .' (include le LFM22DEC) denes a vari-
able called G FIKRS which has the same denition as the eld FIKRS in the table FM01.
Since ABAP/4 is interpreted, every time the variable G FIKRS is dened, it uses the same
denition as the eld 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 elds are added or the denition of elds are altered,
older programs using the table or structure will still work. Otherwise the process of customiz-
ing would not only include the altering of tables but also the altering of all applications using
these tables. This would obviously not be feasible.
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 23 shows an example for the invocation of a locking object.
In ABAP/4, database tables cannot be locked directly, all locking must be done via lock-
ing objects. Again, the indirection pays o when denitions or dependencies in the Data
Dictionary are changed. Old programs will still work after a locking object has been changed.
MODULE D0100 MODIFY SCREEN.
LOOP AT SCREEN.
"/ if (( Feldname = 'Finanzkreis' ) und ( TA ist abhangig ) )
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
Persistence The underlying SQL database is the persistent store for ABAP/4. In addi-
tion, ABAP/4 can handle les, but this is recommended for temporary data or information
interchange with other programs only.
ABAP/4 uses a built-in dialect of SQL, the so called Open SQL language. Open SQL is
similar to standard SQL, there are some modications 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 Native SQL. It is not wise to use Native SQL, for the applications may not be usable
in other R/3 systems.
Dynamic Screen Modication Dierent 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 like the one shown in Fig. 24.
2. Detailed design and system setup. The result of the phase `Detailing and Imple-
mentation' is the checked company-specic application system which will be released for
phase 3 (production preparation).
3. Preparations for going live. The result of the `Production Preparation' phase is a
checked and released production system.
4. Productive operation. The result of the phase `Production' is the organization and
execution of a continuous optimization and support of the productive operation.
Figure 25 shows these steps of the procedure model as dened for R/3 3.0C [SAP AG
1996].
6$3*8, 6$3*8,
3& 6$3*8,
SURFHVV SURFHVV
SURFHVV
3UHVHQWDWLRQ VHUYHU
'LVSDWFKHU
'\Q3UR SURFHVVRU '\Q3UR SURFHVVRU
:RUNSURFHVV :RUNSURFHVV
$SSOLFDWLRQ VHUYHU
&HQWUDO
ERRNLQJ 5'%06
SURFHVV
'DWDEDVH VHUYHU
TCP/IP is used as the communication protocol within R/3. With LU 6.2 it is possible to
communicate with IBM mainframes. Fig. 27, adapted from [Buck-Emden and Galimow 1997],
shows the use of network protocols by R/3.
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 minimizes the
amount of data to be exchanged for a switch from the current screen to the next and during
bulk data display.
Remote SQL is used to exchange data between the database and the application layer.
6HVVLRQ
OD\HU
$33&
7UDQVSRUW
OD\HU /8
7&3,3
1HWZRUN
OD\HU
OD\HU
5 V\VWHP
3UHVHQWDWLRQ VHUYHU $SSOLFDWLRQ VHUYHU 'DWDEVH VHUYHU
:RUNSURFHVV
%DWFK
:RUNSURFHVV
6SRRO
(QTXHXH
7DVNKDQGOHU
%RRNLQJ
'\Q3UR
SURFHVVRU
0HVVDJH
$%$3
SURFHVVRU
'DWDEDVH
LQWHUIDFH
Spool WPs: They do the internal spooling, like printing or transferring data to the database.
Enqueue WPs: An Enqueue WP is specialized on the locking of DDic objects.
:RUNSURFHVV
'LVSDWFKHU
7DVNKDQGOHU
SURFHVVRU
SURFHVVRU
'DWDEDVH
LQWHUIDFH
$%$3
'\Q3UR
$SSOLFDWLRQ VHUYHU
0HVVDJH VHUYHU
5 V\VWHP
*DWHZD\ VHUYHU
0HVVDJH
(QTXHXH
%RRNLQJ
'LDORJ
6SRRO
%DWFK
'DWDEVH VHUYHU
Figure 30: R/3 Architecture
TABLES:
5HSRVLWRU\
'DWD
$SSOLFDWLRQ
GLFWLRQDU\
&RQVLVWV
2EMHFW
1DPH
&RQVLVWV 'HYROSPHQW FODVV
&RQVLVWV RI
7UDQVSRUW
,QFOXGHV 6WDUWV
7UDQVDFWLRQ 3URJUDP REMHFW )XQFWLRQ /RJLFDO 0 HVVDJH
%XVLQHVV 6(7
JURXS GDWDEDVH FO DVV 'LDORJ ER[
6WUXFWXUH 7\SH &RGH 9HUVLRQ HQJHQHHULQJ SDU
'DWD 'RPDLQ 9LHZ /RFN 0DWFK
7DEOH 6WDUWV ZLWK REMHNW ,QWHUIDFH
HOHPHQW JURXS REMHFW FRGH 8VHV
,PSRUWV
7\SH REMHNW
3ULPDU\ 6HFRQGDU\ $XWKRUL]DWLRQ 0 HVVDJH
%DVHG -RLQFRQG REMHFW
$SSHQGV RQ WDEOH WDEOH 6HFRQGDU\ 1XPEHU
3ULPDU\
6HFRQGDU\ WDEOH WDEOH
'DWD W\ SH 3ULPDU\
WDEOH WDEOH 5HSRUW )XQFWLRQ PRGXOH
)LHOG )LHOG
5(3257 352*5$0
)81&7,21322/ :RUNIORZ 'DWD PRGHO
'HILQHV YDOXHV
1DPH 1DPH ,QWHUIDFH
3URMHFWLRQ
([WHUQDO $%$3 +HDGHU ,QWHUQDO )LHOG 6HOHFW
W\SH
FRQGLWLRQ
GDWD W\SH OLQH WDEOH V\ PERO
)XQFWLRQ NH\
3URMHFWHG WR DVVLJQPHQW
0 RGXOH SRRO
LQ $%$3 &RGH
64/ W\ SH )LHOG
'DWD H[FKDQJH E\ HTXDOLW\ RI QDPHV
'\Q3UR ILHOG
"/ FM area
FM01,
"/ Text for FM area
FM01T,
"/ Funds center
FMFCTR,
"/ Internal table for Dynpro fields of the Funds center
IFMFCTR.
DATA:
"/ FM area identification
G_FIKRS LIKE FM01-FIKRS,
"/ Funds center identification
G_FICTR LIKE FMFCTR-FICTR,
"/ Transaction code
G_TCODE LIKE SY-TCODE,
"/Flag to signal that the transaction / function module has been
"/ called indepndently
FLG_CALLD LIKE SY-CALLD VALUE 0.
...
MODULE D0100_MODIFY_SCREEN.
*----------------------------------------------------------------------*
* Dynamic screen modification for Dynpro 0100: *
* - truncate the output size of the field FM area to 10 characters *
* - disable input to the FM area identification field if the *
* screen is called from within another transaction *
*----------------------------------------------------------------------*
MODULE D0100_EXIT.
*----------------------------------------------------------------------*
* Functions called if the the current processing is terminated *
* without executing the checks of the PAI modules. *
* LEAVE TO TRANSACTION releases all locks held by the transaction *
*----------------------------------------------------------------------*
"/ get the return code determined by the user
"/ indicate that procssing can continue
SAV_OK_CODE = OK_CODE.
CLEAR OK_CODE.
"/ Evaluate the saved return code
CASE SAV_OK_CODE.
"/ ENDE = quit
WHEN 'ENDE'.
SET SCREEN 0.
LEAVE SCREEN.
"/ EINS = branch to transaction "create funds center"
WHEN 'EINS'.
"/ branc to this transaction
LEAVE TO TRANSACTION TR_FICTR_INS.
ENDCASE.
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.
* keep key of the FM area
CONDENSE IFMFCTR-FIKRS NO-GAPS.
G_FIKRS = IFMFCTR-FIKRS.
"/ store the FM center
CONDENSE IFMFCTR-FICTR NO-GAPS.
G_FICTR = IFMFCTR-FICTR.
" / if called from another transaction (here a graphical display of an FM area)
IF ( FLG_CALLD = CON_INDEPENDANT_TA ).
"/ initialize variables using values passed from the preceding graphical display
SELECT SINGLE *
FROM FM01
WHERE FIKRS = G_FIKRS.
"/store object number of the FM area
G_FMA_OBJNR = FM01-OBJNR.
"/set a flag to force an insertion without a copy in a later
"/ processing stage
FLG_COPY = CON_NEIN.
"/initialize variable (sic!)
CLEAR G_REF_FICTR.
ENDIF.
ENDMODULE. "/ D0100_DB_KEY_NOTICE
...
FORM FMFCTR_ENQUEUE.
"/ if ( creation or update of a funds center )
CHECK ( ( G_TCODE = TR_FICTR_INS )
OR ( G_TCODE = TR_FICTR_UPD ) ).
"/ request a lock for this funds center
CALL FUNCTION 'ENQUEUE_EFMFCTR'
EXPORTING
FIKRS = G_FIKRS
FICTR = G_FICTR
EXCEPTIONS
FOREIGN_LOCK = 1
SYSTEM_FAILURE = 2.
CASE SY-SUBRC. "/ exception handling (-> inform user)
WHEN 1. "/already locked by another user (FOREIGN_LOCK)
MESSAGE E641 WITH G_FICTR.
WHEN 2. "/ SYSTEM_FAILURE
MESSAGE A521 WITH G_FICTR.
ENDCASE. "/ SY-SUBRC
ENDFORM. "/ FMFCTR_ENQUEUE
...
MODULE FMFCTR_LESEN.
PERFORM FMFCTR_LESEN. "/ call a function to read the funds center
ENDMODULE. "/ FMFCTR_LESEN.
FORM FMFCTR_LESEN.
DATA: L_FMFCTR_EXISTS LIKE CON_JA. "/Funds center already exists
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.