detecting fraud patterns using data obtained from the...
TRANSCRIPT
Detecting Fraud Patterns Using Data
Obtained from the Application
Platform
Diploma Thesis
for the examination as
Graduate Engineer (University of Cooperative Education)
in Information Technology studies
at the University of Cooperative Education Karlsruhe
written by
Nico HerzbergMatr.-Nr. 122492
September 2006
Duration 3 months
Course TIT03VNS
Company SAP AG
Walldorf
Company Supervisor Dr. Julien Vayssiere
University Supervisor Prof. Dr. Heinrich Braun
University of Cooperative Education Karlsruhe
SAP Research CEC Brisbane
Diploma Thesis
Detecting Fraud Patterns Using
Data Obtained from the
Application Platform
Company Supervisor Dr. Julien Vayssiere
University Supervisor Prof. Dr. Heinrich Braun
written by
Nico HerzbergMatr.-Nr. 122492
September 2006
c©2006 Nico Herzberg
Non-Disclosure Note
The following diploma thesis contains confidential data of SAP Australia Pty
Ltd and SAP AG. Publication or duplication of this diploma thesis - or just in
extracts - is strictly prohibited without explicit permission of SAP Australia
Pty Ltd or SAP AG. This diploma thesis is only to be made accessible to the
correctors as well as the members of the examination board.
III
Abstract
The ability to help SAP customers prevent and detect fraud is a growing issue
for SAP, mainly because of recent regulatory changes, such as the Sarbanes-
Oxley act, and also because, in many business areas, software is replacing hu-
mans and operates on business data automatically. The SAP Research project
FRODO aims at investigating fraud detection in SAP applications.
The object of my investigation is SAP’s new Application Platform. The Ap-
plication Platform is based on the Service-Oriented Architecture concept and
provides different Business Object data sources and access methods to this
data. Investigated data sources are the Business Objects themselves and the
Technical Object ChangeDocument. The access methods identified include
core and compound services as well as the Business Information Warehouse
and the use of an own FRODO Business Object. The investigation targets on
possibilities of accessing data from the Application Platform in order to detect
fraud on it. A methodology is developed and used for the investigation to select
the best solutions. The most promising solutions, namely accessing the Tech-
nical Object ChangeDocument using its core services and accessing Business
Object data via Business Information Warehouse using XML for Analysis, are
implemented in Java for further validation. Based on these implementations
some discussions are made. A comparison to the R/3 prototype of FRODO
transpired that there are no serious differences at the moment, because in all
versions the data has to be extracted by hand.
Thus, further questions, problems and new ideas exist. Further development
on the FRODO prototype targets on real-time fraud detection and therefore,
the implemented access methods have to be verified for that focus.
IV
Kurzreferat
Finanzbetrug zu vermeiden und zu erkennen gehort heute zu den Anforderun-
gen von Kunden an SAP Systeme. Dies fundiert erstens auf neuen Gesetzge-
bungen, wie zum Beispiel dem Sarbanes-Oxley Act aus den USA und zweitens
auf der Tatsache, dass Software mehr und mehr den Einfluß des Menschen in
Geschaftsprozessen verdrangt. Das SAP Research Projekt FRODO untersucht
aktive Betrugserkennung in SAP Anwendungen.
Untersuchungsgegenstand dieser Arbeit ist SAP’s neue”Application Platform“,
welche auf dem Konzept der Service-Oriented Architecture aufbaut. Rele-
vante Daten sind in den Business Objekten selbst und im Technischen Objekt
ChangeDocument verfugbar. Als Zugriffsmethoden sind Core und Compound
Services, sowie das Business Information Warehouse und ein eigenes FRODO
Business Objekt identifiziert. Die Untersuchungen zielen auf die Moglichkeit,
auf Daten der”Application Platform“ von außen zugreifen und damit Be-
trugserkennung gewahrleisten zu konnen. Um die besten Losungen identi-
fizieren zu konnen, wurde ein Vorgehensmodell entwickelt und wahrend der
Untersuchung verwendet. Die Strategien”Zugriff auf ChangeDocument uber
Core Services“ und”Zugriff auf Business Objekt Daten uber das Business In-
formation Warehouse unter Verwendung von XML for Analysis“ sind in Java
implementiert, um sie besser bewerten zu konnen. Auf Basis der Programme
konnen diverse Diskussionen gefuhrt werden. Der Vergleich zum R/3 FRODO
Prototypen zeigt im Moment keine Verbesserung auf, da in allen Losungen die
Daten per Hand extrahiert werden mussen.
Folglich bestehen noch viele offene Fragen, Probleme und neue Ideen. Der
Fokus von FRODO wird in Zukunft auf Betrugserkennung in Echtzeit zielen.
Fur diese Anforderung mussen die implementierten Zugriffmethoden bewertet,
gegebenenfalls angepasst oder gar verworfen werden.
V
Preface
This diploma thesis “Detecting Fraud Patterns using data obtained from the
Application Platform” was written in the context of my studies in Informa-
tion Technologies at the University of Cooperative Education Karlsruhe in
cooperation with SAP AG and SAP Australia Pty Ltd. The thesis represents
the results of the research effort conducted from June 5th to September 8th,
2006.
Working on the diploma thesis was a challenging task since it required an
in-depth understanding of a new concept that is being set up for the whole
development process of a software company. Due to the fact that there is only
a few pieces of written documentation available about the new architecture,
good cooperation with colleagues was required. Additionally, the conditions
are always exposed to changes and this makes work even more interesting.
Keeping up the pace and finishing the work on this project could not have been
realized without the support of many people. I hereby would like to thank
• Dr. Julien Vayssiere for great supervision and good teamwork during the
further development of the prototype
• Prof. Dr. Heinrich Braun for supervising me excellently as the represen-
tative of the university
• The AP/SRM team for supporting the whole project with experience
and knowledge as well as forwarding contacts
• The whole SAP Research team in Brisbane for a great time and a lot of
support
• All SAP colleagues, who supported me with information and experience
VI
Preface
• Christian Mockel and Philip Crow for checking the language
• My girlfriend Doreen Seifert and my family for supporting me and keep-
ing everyday life problems away from me
Brisbane, September 2006
Nico Herzberg
VII
Table of Contents
1 Introduction 1
1.1 Fraud and Fraud Detection . . . . . . . . . . . . . . . . . . . . 1
1.2 Motivation and Planned Work . . . . . . . . . . . . . . . . . . 4
1.3 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Basics and State-of-the-Art 7
2.1 Reference Scenario for Fraud Detection . . . . . . . . . . . . . 7
2.2 The FRODO Prototype for Fraud Detection in R/3 . . . . . . . 10
2.3 Realization of Service-Oriented Architecture at SAP: enterprise
SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Business Intelligence and SAP Business Information Warehouse 16
2.5 Structure of the Application Platform . . . . . . . . . . . . . . 18
2.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3 Specification and Exploration of Possible Access Methods 23
3.1 Investigation Methodology . . . . . . . . . . . . . . . . . . . . 23
3.2 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.1 Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.2 Access Methods . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Identifying Concrete Strategies and Classifying them . . . . . . 33
3.3.1 List of Possible Strategies . . . . . . . . . . . . . . . . . . . . . 33
3.3.2 Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4 Ranking of Possible Solutions . . . . . . . . . . . . . . . . . . . 38
3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4 Implementation of Solutions 46
4.1 Accessing the TecO ChangeDocument by Using its Core Services 47
4.1.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.1.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
VIII
Table of Contents
4.1.3 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.2 Receiving BW Data of BOs Using XML for Analysis . . . . . . 53
4.2.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2.3 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5 Validation 60
5.1 Validation of Test Results . . . . . . . . . . . . . . . . . . . . . 60
5.2 Comparison to the R/3 Solution . . . . . . . . . . . . . . . . . 62
6 Final Remark 63
6.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.2 Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.3 Further Questions & Recommendations . . . . . . . . . . . . . 64
7 Summary 66
A Why the Application Platform? A - 1
B Process Integration Monitor (PIM) A - 4
C Generic Data Warehouse Solution A - 6
D Code for Accessing ChangeDocument Using GCPs A - 8
E Code for Accessing BW Using XML for Analysis A - 18
F Contacts A - 23
Glossary XVIII
Bibliography XXVII
IX
List of Figures
1.1 Scope of Project “Fraud Detection in SRM” . . . . . . . . . . . 4
1.2 FRODO Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Invoice Handling (based on [Vay06]) . . . . . . . . . . . . . . . 8
2.2 Invoice Handling with Duplicates (based on [Vay06]) . . . . . . 8
2.3 Suspicious Pattern of Financial Fraud (based on [Vay06]) . . . . 9
2.4 Structure and Function of FRODO [Vay06] . . . . . . . . . . . . 10
2.5 From Log File to Audit Trail [Vay06] . . . . . . . . . . . . . . . 11
2.6 FRODO’s Function with Composite Events (based on [Vay06]) . 12
2.7 Structure of SOA [Ebe04] . . . . . . . . . . . . . . . . . . . . . 14
2.8 Correlation between Technology Platform and Application Plat-
form [SAP06d] . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.9 Function of a Data Warehouse (based on [SAP04]) . . . . . . . 17
2.10 Structure of the AP (ESA - Big Picture) . . . . . . . . . . . . . 19
2.11 Integration Scenario Model of Reference Scenario . . . . . . . . 21
3.1 Investigation Methodology . . . . . . . . . . . . . . . . . . . . . 24
3.2 Services of a BO (based on [SAP06c]) . . . . . . . . . . . . . . . 29
3.3 FRODO on Top of BW . . . . . . . . . . . . . . . . . . . . . . . 30
3.4 MDX Example [SAP06a] . . . . . . . . . . . . . . . . . . . . . . 31
3.5 Strategy Overview . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.6 FRODO as a Completely External Solution . . . . . . . . . . . 36
3.7 FRODO with Components Inside the AP . . . . . . . . . . . . . 37
3.8 FRODO as an Element of AP/A1S . . . . . . . . . . . . . . . . 37
4.1 Waterfall Model for Development . . . . . . . . . . . . . . . . . 46
4.2 Implementation of GCP in the Big Picture . . . . . . . . . . . . 47
4.3 Program Sequence Diagram for Accessing ChangeDocument Using
GCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.4 Program Sequence Diagram for XML/A Solution . . . . . . . . 54
X
List of Figures
4.5 XML/A Solution in the Big Picture . . . . . . . . . . . . . . . . 55
5.1 Graph of Software Measurement Results . . . . . . . . . . . . . 62
A.1 From former IT to Process Innovation Technology (based on [Dit05]) A - 1
A.2 Paradigm from Automotive Industry [FMW06] . . . . . . . . . A - 2
A.3 Software Development in the Future [Red06] . . . . . . . . . . . A - 3
C.1 Structure of a Generic Solution . . . . . . . . . . . . . . . . . . A - 6
F.1 Contact Mind Map . . . . . . . . . . . . . . . . . . . . . . . . . A - 28
XI
List of Tables
3.1 Evaluation of Solutions . . . . . . . . . . . . . . . . . . . . . . . 32
3.2 Meaning of the Evaluation Symbols . . . . . . . . . . . . . . . . 39
3.3 Evaluation of Accessing BO Data Using Core Services . . . . . . 39
3.4 Evaluation of Accessing BO Data Using Compound Services . . 40
3.5 Evaluation of Accessing Data Using SAP BW on BO Data . . . 42
3.6 Evaluation of Accessing ChangeDocument Using Core Services . 42
3.7 Evaluation of Accessing ChangeDocument Using Compound Ser-
vices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.8 Evaluation of Accessing Data Using SAP BW on ChangeDocument
Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.9 Summary of all Strategies . . . . . . . . . . . . . . . . . . . . . . 45
5.1 High-level Measurement Results of the Software Validation Phase 61
B.1 Evaluation of Accessing Data Using PIM . . . . . . . . . . . . . A - 5
C.1 Evaluation of a Generic BW Solution . . . . . . . . . . . . . . . A - 7
F.1 SAP Contacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . A - 27
XII
Listings
2.1 Rules written in Jena Rules Language [Vay06] . . . . . . . . . . 12
2.2 Colloquial Rules [Vay06] . . . . . . . . . . . . . . . . . . . . . . 13
3.1 LCP Call of a BO Core Service in ABAP . . . . . . . . . . . . . 27
3.2 GCP Call of a BO Core Service . . . . . . . . . . . . . . . . . . 27
4.1 Structure of Connection Property File for Using GCP . . . . . . 50
4.2 Connection to the AP . . . . . . . . . . . . . . . . . . . . . . . 50
4.3 Section from BO Model Interface IChangeDocument.java . . . . 51
4.4 Code for Query Creation and Data Receiving . . . . . . . . . . 51
4.5 Response to SalesOrder Query . . . . . . . . . . . . . . . . . . . 52
4.6 SOAP Request to BI System . . . . . . . . . . . . . . . . . . . . 55
4.7 Property File for Connection to a BI System . . . . . . . . . . . 56
4.8 Connection and Data Sending in XML/A solution . . . . . . . . 56
4.9 Reference Data Structured in XML . . . . . . . . . . . . . . . . 58
4.10 SOAP Response of the BI System . . . . . . . . . . . . . . . . . 58
D.1 Main.java of XML/A Solution . . . . . . . . . . . . . . . . . . . A - 8
D.2 Main.java of XML/A Solution . . . . . . . . . . . . . . . . . . . A - 12
E.1 Main.java of XML/A Solution . . . . . . . . . . . . . . . . . . . A - 18
XIII
List of Abbreviations
A1S mySAP All-In-One/Service-Enabled
A2A Application to Application
ABAP Advanced Business Application Programming
AP Application Platform
B2B Business to Business
BI Business Intelligence
BIS Basis Information System
BO Business Object
BPP Business Process Platform
BW Business Information Warehouse
DU Deployment Unit
DW Data Warehouse
ESA Enterprise Services Architecture
ESI Enterprise Services Infrastructure
ESR Enterprise Services Repository
FI Financials
GCP Generic Core Service Consumer Proxy
HR Human Resources
HTTP Hypertext Transfer Protocol
XIV
List of Abbreviations
IDE Integrated Development Environment
ISV Independent Software Vendor
IT Information Technology
JDK Java Development Kit
LCP Local Client Proxy
MDM Master Data Management
MDX MultiDimensional Expressions
PC Process Component
PIC Process Integration Content
PIM Process Integration Monitor
RDF Resource Description Framework
RFC Remote Function Call
SAP Systems, Applications and Products in data processing
SOA Service-Oriented Architecture
SQL Structured Query Language
SRM Supplier Relationship Management
TecO Technical Object
TP Technology Platform
UI User Interface
WSDL Web Service Description Language
XML eXtensible Markup Language
XML/A XML for Analysis
XSD XML Schema Definition
XV
Notices to Typography and
Writing Conventions
Figures and Tables
The figures and tables used in this document are labeled and listed either
in the table of figures or in the list of tables. If figures or tables are taken
from other literature the source referring to the bibliography is given in the
label. Sources with the notation “based on” are taken out of literature and are
modified according to the author’s needs and the current knowledge status.
Listings
The used listings are labeled and listed in listings. They represent program
code most times. For explaining the code, the lines of listings are numbered
and are referenced in the text.
Abbreviations
Abbreviations are usually given in brackets after their initial use following
the written term they stand for. Additionally, they are listed in the list of
abbreviations at the beginning of this document.
Terms in Italics
Terms in italics are components of the Application Platform. This convention
is inline with the writing style of the documents in the ESA Architecture Series
2006.
Terms Written in Typewriter Style
Terms written in typewriter style are code or code components, e.g. JAR files
or class names.
XVI
Notices to Typography and Writing Conventions
Literature Indication
References to literature are given directly in the text or in squared brackets
by a reference which consists of the family name of the first author or the
name of the publisher and the year of publication. This reference is listed and
explained in the bibliography in detail.
Citation
Citations are presented in double quotes. The source of the citation is written
behind the citation according to the literature indication.
The Asterisk ∗
Terms highlighted with the asterisk are explained in the glossary at the end of
the document.
Words and Terms Written in Quotes
Words or Terms written in quotes are proper names.
XVII
CHAPTER1
Introduction
The topic “Detecting Fraud Patterns using data obtained from the Application
Platform” can be classified in the branch of Information Technology (IT) com-
bined with business background. More specifically, the Application Platform∗
(AP) is the core of the technology investigation. The AP is designed to build
application solutions by service compositions and follows the model-driven ap-
proach by using these services. The topic of financial fraud detection is at the
core of the business research. First of all, the definition and the background
on fraud and fraud detection are presented. In addition to that, research into
existing fraud detection projects is required as well as a plan for solving the
task at hand.
1.1 Fraud and Fraud Detection
A short definition of fraud is that it “is an intentional deception perpetrated
to secure an unfair gain.” [Onl06]. Fraud is a form of white collar crime and
one of the most often committed ones in Germany. Other forms of white collar
crime are stealing goods from stock or corruption for instance. White collar
crime makes up about half of all the financial damage of all registered crimes
in Germany. Over 70 percent of all German companies think that white collar
crime is a big problem and predict an increasing rate of those crimes in the
next few years. Some companies appraise their loss caused by fraud during the
last 3 years to over one billion Euro [KPM06].
1
1.1. Fraud and Fraud Detection
In most forms of white collar crimes, no IT system is involved. Examples such
as stealing from stock and corruption are independent from IT and therefore
are out of scope for SAP Research. At SAP Research especially financial
fraud is of interest, because in most of the scenarios, systems from SAP and
other software vendors are involved. Different perpetrators are possible. They
could come from internal ranks as well as from the external side. This type
of fraud is “pervasive throughout the economy and affects organisations of all
sizes” [MBCV06, p. 45]. In other words financial fraud is stealing money from
a company, for example
• Someone sends a fictitious invoice to the company and receives the money
into his account.
• An employee duplicates an invoice and receives the payback of the second
payment at his own account.
• A supplier sends excessive invoices which are always approved by the
same person in the company. This fraud scenario is a kind of collusion,
because internal and external culprits work together.
• Someone commits fraud in Human Resources (HR) by creating an arti-
ficial employee and getting the salary paid to themselves.
• Someone commits fraud while faking a supplier and approving invoices
for that supplier1.
54 percent of the Australians interviewed and New Zealand respondents of the
KPMG financial fraud survey had one or more fraud cases between 2002 and
2004. That created an average loss of AU$ 2.1 million per affected organization
[KPM04]. Governments also broach the issue of fraud and adopt some legal
fundamentals. After big financial frauds, like that of Enron2 or WorldCom3,
the pressure grew on companies and public organizations and consequently,
they have to develop and implement strategies against fraud. One example
for that is the Sarbanes-Oxley legislation in the US, which aims on ensuring
1 E.g. A senior executive of a German company stole over one million Euro with thisfraud method.
2 In 2000 Enron initiated one of the biggest company scandals in the US while committingfalsification of a balance sheet [Wik06b].
3 In 2004 WorldCom was involved in a stock market scandal while committing wrongentries of more than US$ 11 billion [Wik06c].
2
1.1. Fraud and Fraud Detection
the correctness of financial reports. It prescribes some methods of definitions
and descriptions of business processes and their controlling systems [Wik06d].
A second example is the Australian Fraud and Corruption Standard which
gives recommendations for fraud detection methodologies. The future trends
in software development will produce more complex and automated systems.
These new systems, however, will create new access points for perpetrating
fraud because human checks will be removed more and more. Thus, variety
and complexity of fraud is likely to increase in the future [MBCV06].
Fighting fraud is an issue to be dealt with and be carried out in three different
ways:
• Prevention
• Real-time detection
• Periodical analysis
Today, in SAP’s software, to meet future requirements, prevention is imple-
mented by segregating duties between roles. This means that different system
authorizations enable separation into different groups and roles. For example
it is possible to assign one HR employee to the role for creating employees
and another one to the role for approving these employee creations. Real-time
detection is not yet implemented, maybe it will be realized by one of the next
FRODO∗ versions. At the moment, fraud detection is still a mostly manual
task performed by auditors. They have the possibility to get support from the
Audit Information System∗, but this only helps with better reports and visual-
izations and not with an active detection of fraud patterns. Thus, responsible
employees have difficulties in working with the big amount of data produced.
In order to meet the demand for simple, effective and periodical or real-
time fraud detection in existing and future SAP products, SAP Research
proposes the research project called FRODO. The acronym FRODO stands
for “Fraud Detection in Open and Heterogeneous Environments”. On the
one hand, FRODO stands for a collaborative project with the Information
Security Institute of Queensland University of Technology. The project has
a cross-disciplinary approach which connects research in the branches of IT,
business and law. On the other hand, FRODO is a Java Web application pro-
3
1.2. Motivation and Planned Work
totype for fraud detection [Vay06]. This paper covers the technical side of the
FRODO project and thus the word “FRODO” will be used in the meaning of
the application prototype.
1.2 Motivation and Planned Work
The strategy of SAP is aligned with the requirements expressed by its cus-
tomers. At the moment, SAP’s approach is based on a Service-Oriented
Architecture∗ (SOA) for its new software products. This requires new develop-
ments and new products for replacing the old R/3∗ systems. But the current
prototype of FRODO works with data from SAP R/3 and is not up-to-date
with the new strategy. Another weakness is that FRODO only covers a few
fraud scenarios especially in the Supplier Relationship Management∗ (SRM).
Thus, an SAP internal project called “Fraud Detection in SRM” between the
department of AP/SRM and SAP Research was initiated. The work focused
on two points (highlighted in figure 1.1).
• Identification and prioritization of fraud scenarios in invoicing.
• Feasibility study that clarifies if it is possible to detect fraud with data
from services based on the new AP. In case of a positive result of the
studies, a mediator between FRODO and the AP should be implemented.
Figure 1.1: Scope of Project “Fraud Detection in SRM”
4
1.2. Motivation and Planned Work
The project “Fraud Detection in SRM” can also be seen as a validation of the
SAP’s Enterprise Service-Oriented Architecture4 (enterprise SOA)∗ , because
FRODO should act as an external tool and should use AP services. Thus, many
people pay a lot of attention to this project and therefore the outcome of the
thesis will be a demonstration of the strengths and weaknesses of enterprise
SOA.
The scope of this diploma thesis is the technical part of the collaborative
FRODO project between SAP Research and AP/SRM which demands for a
feasibility study about accessing the data stored in AP. Thus, the question is
how is it possible to connect FRODO with AP to develop an AP/A1S with
fraud detection (figure 1.2).
Figure 1.2: FRODO Objectives
Depending on the outcome of the feasibility study, an implementation of a new
version of FRODO may be required. This further development can be seen as
a mediator between mySAP All-In-One/Service-Enabled∗ (A1S) and FRODO
(see highlighted part in figure 1.1). Additionally, aspects like data volume,
performance and software effort should be investigated. Therefore, different
software solutions are required and a evaluation is demanded at the end of the
work.
4 The term Enterprise Services Architecture (ESA) has been renamed as Enterprise Ser-vice Oriented Architecture or enterprise SOA.
5
1.3. Methodology
1.3 Methodology
The work on the technology part of the project begins with searching and
defining a reference scenario (section 2.1) which is used for developing dif-
ferent solutions and secures a representative test and validation phase. The
next step is setting the fundamentals and the basics to understand the topic.
Therefore an orientation on the topics FRODO itself (section 2.2), enterprise
SOA (section 2.3), SAP NetWeaver∗ (section 2.3), SAP Business Intelligence∗
(BI) (section 2.4), and AP (section 2.5) is necessary. Afterwards, the research
begins with the identification of strategies for accessing the relevant data of the
application platform (section 3.2). Therefore, the usage of tools, like ARIS∗
and the Integration Builder∗ is necessary. These tools provide different views
of the AP and its objects. Every strategy will be explored and validated in
different investigation steps (section 3.3 and section 3.4). The most promising
access strategies will be polished and implemented (section 4). To compare the
different solutions (section 5.2), developing test scenarios is necessary to check
the implementations. Also the comparison with the R/3 prototype is discussed
(section 5.2). The work is concluded and some questions and recommendations
are given after the validation phase. Also the future of the FRODO project
is drafted with some words (chapter 6). A summary of the research results
finishes the technical part of the project “Fraud Detection in SRM” (chapter
7).
6
CHAPTER2
Basics and State-of-the-Art
Setting up the fundamental knowledge about relevant technologies and prod-
ucts is the first step towards developing new strategies for collecting data from
the AP. Therefore, it is necessary to understand the reference fraud scenario
in detail as well as the functioning of FRODO. Additionally, it is required
to know the basics about the technology environment which is given by SAP
NetWeaver and the AP.
2.1 Reference Scenario for Fraud Detection
The following financial fraud scenario will be used as a reference for the im-
plementation and research work presented in this document. As the example
is complex, three areas of business are touched. The first one is the Master
Data Management∗ (MDM). It is responsible for the central management of
master data, e.g. a vendor’s bank details. The other area involved is SRM.
This sector contains details about planning and controlling relationships with
vendors. One essential function is processing invoices of vendors. SRM offers
the opportunity to verify and approve invoices and after that, sending them to
the Financials∗ (FI) part of the system for payment.
The following figures show events along two timelines, also called audit trails,
one for the MDM and one for the SRM and FI areas5 together. Vertical arrows
5 For describing the scenario and for the work of FRODO it is not necessary to separate
7
2.1. Reference Scenario for Fraud Detection
represent single actions of the process. In the SRM line, the approval actions
on a received invoice are shown, including the FI conducted payment process.
The state of the vendor’s bank details is obtained from MDM.
The next diagram (figure 2.1) describes the normal situation when an invoice is
received in the SRM. After a time for verifying and approving the invoice, the
SRM system sends a payment request to FI. FI calls the MDM for retrieving
the bank details of the supplier. Finally, the payment is triggered.
Figure 2.1: Invoice Handling (based on [Vay06])
Figure 2.2 shows that an invoice was duplicated and paid twice.
Figure 2.2: Invoice Handling with Duplicates (based on [Vay06])
Duplicating invoices is not yet an act of fraud, because duplicating is used as
a regular operation for quickly setting up a recurring payment. An example
the SRM and FI in two audit trails.
8
2.1. Reference Scenario for Fraud Detection
scenario therefore is that a company receives screws for 10.000 Euro every
month and the invoice arrives as a letter. Thus, duplicate an invoice is more
efficient, instead of typing in all data every month. Another possibility is that
invoices appear as duplicates due to an error.
The pattern of Figure 2.3, however, is suspicious since at the moment of paying
the second invoice the vendor’s bank details were in a transitory state, namely
the bank details flapped. This is an indication that a third person is maybe
trying to receive the money of the second payment on another account.
Figure 2.3: Suspicious Pattern of Financial Fraud (based on [Vay06])
The analysis of the single audit trails of each system shows nothing suspicious.
The MDM part looks like a mistake made while changing data was reverted
after detection. In the SRM appears similar to the scenario described in figure
2.2. On closer examination of both trails with reference to the time, a possible
fraud becomes evident, because the second invoice payment happened while
the bank details were in a transitory state.
Now the question is, if this scenario is possible, since SAP systems enforce a
segregation of duties strategy. The ideal situation is that different employees
work either with master data or in SRM but not in both. In big companies
the strategy can be fulfilled and the employees who work with the MDM work
center are other people than the ones working in SRM. The situation in small-
size companies, however, is a different one; namely, that one person has the
9
2.2. The FRODO Prototype for Fraud Detection in R/3
authorization to create and change master data and the very same person is
also responsible for approving invoices. Collusion is another possible fraud
scenario, as the two people involved can have different roles.
2.2 The FRODO Prototype for Fraud Detection
in R/3
The two fundamental elements of FRODO are events and patterns. The events
differentiate themselves in through audit trails couched base events and com-
posite events. Figure 2.4 shows the structure and the function of FRODO.
Figure 2.4: Structure and Function of FRODO [Vay06]
The patterns are expressed in single rules by an user with expertise in financial
auditing. The financial auditor has the possibility to create new patterns based
on existing ones. These patterns describe a certain composition of base and
composite events. The system administrator has to export log files from the
different applications in the R/3 system, for example from SRM, MDM or
Customer Relationship Management. By parsing the log files and tables, event
10
2.2. The FRODO Prototype for Fraud Detection in R/3
streams are created. Figure 2.5 is an example for the log file structure. Every
log file line expresses one event on the audit trail.
Figure 2.5: From Log File to Audit Trail [Vay06]
Once all these event streams are in the same store, FRODO searches for
matches for the patterns. If in the timelines a set of events matches a pattern,
a composite event is created. As well as base events, this composite event can
be analyzed with the help of the event visualization portal. The portal allows
top-down investigations from general to precise. Thus, responsible people can
investigate both the base events and the found composite events. [Vay06].
For a better understanding of the function of FRODO, explaining FRODO’s
handling on the reference scenario is helpful. In the next figure (figure 2.6) the
fraud scenario and the composite events are shown. The timeline symbolizes
the event streams and every change in color stands for a single event (drawn
as dashed circles). The fraud detection in the shown example uses three differ-
ent patterns. The first one recognizes duplicate invoices and their payments.
The second pattern creates a second composite event which shows that the
bank details of a vendor were changed and reverted to the initial value after
some time. The third composite event detects a possible fraud by combining
composite events one and two.
11
2.2. The FRODO Prototype for Fraud Detection in R/3
Figure 2.6: FRODO’s Function with Composite Events (based on [Vay06])
The patterns for fraud detection are written in the cryptic looking Jena rules
language. Listing 2.1 shows the rules for the composite event “BankDetails-
Flapping” (composite event 2 in figure 2.6).
Listing 2.1: Rules written in Jena Rules Language [Vay06]1 ?e1[rdf:type → sap:VendorBankDetailsChangedAccountingEvent; sap:at → ?t1 ;
sap:bankDetails → ?bd ;
2 sap:clientID → ?client ; sap:vendor → ?vendor],
3 ?e2[rdf:type → sap:VendorBankDetailsChangedAccountingEvent; sap:at → ?t2 ;
sap:bankDetails → ?bdo ;
4 sap:clientID → ?client ; sap:vendor → ?vendor],
5 ?e3[rdf:type → sap:VendorBankDetailsChangedAccountingEvent; sap:at → ?t3 ;
sap:bankDetails → ?bd ;
6 sap:clientID → ?client ; sap:vendor → ?vendor],
7 le(?t1, ?t2),
8 le(?t2, ?t3),
9 notEqual (?bd , ?bdo),
10 makeTemp (?s)
11 →12 ?s[ rdf:type → sap:BankDetailsFlapping ; sap:firstFlap → ?e2 ; sap:secondFlap
→ ?e3 ; sap:startTime → ?t2 ;
13 sap:endTime → ?t3 ; sap:clientID → ?client ; sap:vendor → ?vendor ];
Colloquially, the rules are formed like the following example.
12
2.3. Realization of Service-Oriented Architecture at SAP: enterprise SOA
Listing 2.2: Colloquial Rules [Vay06]
IF two events of type VendorBankDetailsChanged
{are related to the same vendor AND
result in the second event reverting the bank details to the state it
was before the first event}
THEN create a new event of BankAccountFlippingEvent
2.3 Realization of Service-Oriented Architecture
at SAP: enterprise SOA
Eric A. Marks and Michael Bell claim that “Service-oriented architecture
(SOA) is a concept whose time has come” [BM06]. Primarily, SOA is a manage-
ment concept and basically the idea of aiming at higher flexibility on enterprise
IT infrastructure and lower the impact of change on the company. The con-
cept follows the idea that IT infrastructure should be aligned with business
processes. Processes should be composed with single functionality providing
building blocks. This helps companies to react faster on business changes by
replacing single building blocks of the process or restructuring the sequence of
the blocks according to a business process.
This requirement leads to the second meaning of SOA which defines the system
architecture concept. It describes that professional services and functionalities
have to be provided as single services. These services are applicable by stan-
dardized interfaces [Wik06e], they exist independently from each other, and
consequently, the business functionalities are well-bounded. For the descrip-
tion of the structure and interfaces of the services, the Extensible Markup
Language∗ (XML) standards are used. The communication between services
is realized by messages based on a standard communication framework.
Simply, a typical structure of SOA can be displayed with the following figure.
13
2.3. Realization of Service-Oriented Architecture at SAP: enterprise SOA
Figure 2.7: Structure of SOA [Ebe04]
The left hand side shows the service consumer’s request of functionality from
the service provider on the right side. The consumer calls a service of the
provider and may sends data as parameter of the request. After receiving
the results, the consumer uses these for further working. The intermediary is
optional and has different tasks. It can forward the original message or process
and change the message before forwarding [Wol05]. The important thing is
that consumer and provider communicate using service interfaces which are
described and known to each party. Mostly these interfaces are described with
Web Services Description Language∗ (WSDL) files6.
Now the question is why SOA is required. Business needs have evolved in
another direction over the past few years. If a company wants to be successful,
it has to be able to react quickly on business changes. With this ability,
enterprises can differentiate themselves from their competitors. Additionally,
the main goal of a company is to increase its productivity and saving money. As
a task of IT management is to decrease the Total Costs of Ownership reusing
already existing modules to compose and design new processes is of utmost
importance.
SAP meets this demand with a special implementation of SOA called the
enterprise SOA. Enterprise SOA follows industry standards, such as XML and
WSDL; thus, the architecture is open for customers and third parties. It
6 For further information see official W3C website to WSDLhttp://www.w3.org/TR/wsdl.html
14
2.3. Realization of Service-Oriented Architecture at SAP: enterprise SOA
follows the approach to start software development with modeling and going
down to implementation. In enterprise SOA, a development process begins
with specification and design through models and ends with code generation
and implementation.
Enterprise SOA is implemented in the Enterprise Service Infrastructure (ESI)
in SAP NetWeaver and is used in application building on ESI. The further
development of SAP NetWeaver as the Technology Platform (TP) and the AP
is based on ESI completely7.
For a better understanding of the premises of the thesis, knowledge of the
correlation between AP and TP is important. To simplify future software
architecture of SAP will look like the following figure (figure 2.8).
Figure 2.8: Correlation between Technology Platform and Application Platform[SAP06d]
The term Business Process Platform or the abbreviation BPP is often used in
different contexts in reference to AP and SAP NetWeaver. One opinion is that
it is the further development of SAP NetWeaver including a possible extension
by the AP [SAP06f]. Another thesis defines BPP as the combination of TP
and AP [SAP06d]. However, the use of the term BPP is avoided in this thesis,
because the meaning is not yet clear.
7 More details about the decisions for AP are written down in appendix A.
15
2.4. Business Intelligence and SAP Business Information Warehouse
The TP is represented by SAP NetWeaver. NetWeaver was introduced as in-
dependent integration and application platform for heterogeneous landscapes.
One task of SAP NetWeaver is to provide the communication layer for com-
posite applications∗. An important building block of the TP is the Enterprise
Services Repository∗ (ESR) which contains entries about all services of the
system as well as all models. ESR is the interface between SAP internal and
external applications and can be seen as a library for reusable components.
Among other things, it contains a list of available web services for internal and
external use. Additionally, SAP NetWeaver harbored other SAP components,
like the Enterprise Portal for instance.
2.4 Business Intelligence and SAP Business
Information Warehouse
One component of the TP SAP NetWeaver is BI. BI itself describes systems
and processes for analysis of a company. It consists of three phases. The first
one is the definition and inquiry of key data. This is realized with SAP Business
Information Warehouse∗ (BW) which holds the data on his own database in a
redundant way. Thus, it is possible to create a specific report for collecting data
from BO instances. The second phase is the combination of the collected data.
This is the task of Analytics∗ which provides pre-defined applications and the
environment with SAP Visual Composer to create own analytic applications.
In the third part the data have to communicate to the responsible people. This
is the task of the SAP Enterprise Portal, which provide all required things to
show the results in a UI [Wik06a].
BW is SAP’s product for Data Warehousing. Data Warehouses (DW) are
responsible to collect and store information from different sources at a central
point. Therefore, it is necessary to have a separate database. Thus, BW
provides the definition and the merge of key data by holding this data in a
redundant way. The sources can be operative SAP systems, other business
systems or external data sources. The reporting is located on top of SAP
BW. It is realized with reports or queries from the BW to format the data in
different ways. A typical example for such an analysis is the exploration of an
16
2.4. Business Intelligence and SAP Business Information Warehouse
inventory. With the analytical results the user can detect conspicuities and
abnormalities and can decide for special actions. This decisions and actions
are essential for a successful company [SAP04]. The general usage of a DW
can be show in a simple picture (figure 2.9).
Figure 2.9: Function of a Data Warehouse (based on [SAP04])
The possibilities of the BW can be summarized in the three points:
• Combination of data from different sources
• Overcoming of heterogeneous problems at different layers
• Preparation of data in a user friendly way
SAP BW consists of the two main components InfoObjects and InfoCubes.
The InfoObjects represent the business evaluation objects and the InfoCubes
are the data container. An InfoCube consists of data base tables which are
connected via the so-called star schema.
17
2.5. Structure of the Application Platform
2.5 Structure of the Application Platform
Since the AP structure is more interesting for the thesis purpose than TP and
BPP, a more explicit explanation is inevitable. In general, the AP can be
seen as a stock of predefined components. On the AP, the business logic and
process logic is defined separately. AP consists of small separated building
blocks. The smallest building blocks are the business logic representing BOs.
AP implements all of the processes. Thus, the definition also is given, when
which message has to be sent to whom.
At the AP, the biggest abstract building blocks are the DUs. They build an ab-
stract layer for flexible activation and deactivation of certain functional areas.
DUs are executable independently on different systems and they contain one or
more Process Components∗ (PCs), single BOs, engines or other components.
PCs group BOs in business-relevant and meaningful units. PCs themselves
are modeling entities which are reusable for process integration models and
integration scenarios. One PC is always assigned to one DU only, not across
DUs.
BOs contain the business logic and implement the main service providers.
Thus, they build the basic elements of business applications. BOs encapsulate
semantically related data together with BO logic and rules. They are accessible
through their service interface and are listed in the ESR. A BO can provide one
or more service interfaces. SupplierInvoice or Supplier are examples for these
uniquely identifiable business entities. SupplierInvoice for example belongs
to the PC Supplier Invoicing Processing, which is part of the DU Supplier
Invoicing.
To understand the structure and the elements of the AP in detail, another
view on AP is drawn in figure 2.10.
18
2.5. Structure of the Application Platform
Figure 2.10: Structure of the AP (ESA - Big Picture)
SAP NetWeaver delivers the technical infrastructure on which the AP is based.
The dashed rectangle shows the two-layered AP. The Foundation Layer con-
tains the reusable PCs that are accessible from all DUs. Furthermore, this
layer includes master data, e.g. Supplier or Business Partner, and reusable
service components, such as pricing, date or time. The foundation is part of
every AP instance. In the application layer, the predefined processes can be
found.
All AP resources, like the BOs, are completely service enabled for UI, composi-
tion and process integration. For communicating with other services, the BOs
provide one or more service interfaces. Here, service means service interfaces
with their implementation offered by a concrete IT system. In other words,
such a service interface has one or more service operations, which means that
they can provide different functionalities. The service interfaces are callable
locally from other components of one DU or via messages from outside the AP
or other DUs.
The services are differentiated in the different service types:
• Core services∗
19
2.5. Structure of the Application Platform
• Compound services∗
• Enterprise services∗
Core services access the BO directly and are used for internal communica-
tion in DUs. They provide generic functions such as reading data or saving
data. For example the BO SupplierInvoice implement the method Retrieve for
getting data from a BO instance. These generics are grouped in interface pat-
terns, e.g. Access or Query, with individually defined service interfaces. The
compound services are web services using core services and are usually used
for message-based process integration. These services secure the communica-
tion for Application to Application (A2A) and Business to Business (B2B)
communication, because core services are unsuitable for this type of com-
munication. For example SupplierInvoice provides a service interface called
SupplierInvoiceProcessingInvoicingIn for creating new invoices. The group of
enterprise services are compound services “used in the execution of a business
process step which has a significant meaning and impact for the business of
an enterprise” [XKS06, p. 12]. All of the provided compound and enterprise
services are listed in the ESR and all service interfaces are described in that
repository.
The communication between the different BOs is direct, if they communicate
with BOs of the same DU or of the Foundation Layer. Direct means, that
the communication type is synchronous and two-way. With two-way commu-
nications, the caller waits for a response and is blocked while accessing. Oth-
erwise, the communication works with messages as do BOs of different DUs
when communicating with each other. This communication is asynchronous
and only one-way.
In order to consolidate the knowledge the reference scenario should be drawn
as an integration scenario model out of the ARIS tool. This shows the involved
PCs, their DUs and their relevant communication channels. The figure below
(figure 2.11) shows the PCs involved in the reference example in the dashed
area. The Supplier Invoice Processing is triggered after an invoice arrived ei-
ther from Purchase Order Processing, from the Inbound Delivery Processing
or from the Customer Invoice Processing at the supplier. This PC executes
the verification and the approval of invoices. Afterwards, a Due Item Process-
20
2.5. Structure of the Application Platform
ing can become necessary. During Payment Processing , the real payment is
triggered. All of the PCs call the Accounting PC eventually.
Figure 2.11: Integration Scenario Model of Reference Scenario
The whole business logic is hidden in the PCs and their BOs and the call to
master data for instance is not shown, because the Foundation Layer is called.
This call will be executed using a Local Client Proxy∗ (LCP) directly in the
coding. Only the process logic is shown in an abstract way by drawing the
different communications between the relevant PCs.
In conclusion, the business processes themselves are the user of the build-
ing blocks. They are controlled interplays between services and executions of
21
2.6. Summary
services to achieve a predefined business result. They can interact across ap-
plications, thus AP deliver ultimate flexibility. Eric A. Marks and Michael
Bell’s opinion is right and the time of SOA has come, because the needs of
the customers require simple and efficient business process oriented IT land-
scapes.
2.6 Summary
The based reference scenario for the research is a fraud scenario where MDM
and SRM in connection with FI are involved. The SAP’s customers require
for detecting such fraud scenarios, because in small enterprises the prevention
concept segregation of duties can not be implemented in an easy way like in big
companies. The FRODO project should cover this issue while working with
patterns to detect specified event combinations. Such patterns are expressed
with rules by people with financial expertise. The new prototype should work
in the environment of the AP and the new version of SAP NetWeaver as the
TP. The AP and the TP follows the implementation of SAP’s enterprise SOA.
The first product working on top of the AP is A1S for mid-size companies. The
AP itself consists of different hierarchical components. BOs are the smallest
building blocks and can be capsulated in PCs and/or in DUs. The BOs provide
their functionality as services which can be invoked in different ways depending
on the location of the consumer. The communication between these services is
realized with messages. Thus, the architecture provides many starting points
for getting data out of the AP.
22
CHAPTER3
Specification and Exploration of
Possible Access Methods
The aim of the feasibility study is identifying and exploring of strategies for
collecting data from the AP. The data has to be accessible from the external
software tool FRODO, because the approach of the FRODO project is to work
side-by-side with the AP, and not as a part of it. Thus, the deployment of
the FRODO prototype is similar to that of an Independent Software Vendor8
(ISV).
At the beginning of the feasibility study, a strategy using the Process Integra-
tion Monitor (PIM) was investigated. This investigation is explained in the
appendix B, because it became irrelevant for further work on the thesis, but
it lead to other strategies.
3.1 Investigation Methodology
While investigating the different strategies, a methodology became visible
which allows dividing the theoretical part in single steps to extract suitable
solutions.
8 ISVs are very important for SAP to build up an ecosystem to cover all costumer needs.The network is necessary, because SAP cannot fulfill all customer requirements. Forthat case, enterprise SOA enables partners to develop niche products.
23
3.1. Investigation Methodology
The first step is to identify which relevantdata exists (sources) and how this data canbe accessed (access methods).
Afterwards, all sources are systematicallycombined with the access methods and areinvestigated if accessing the data from out-side is possible.
The out-coming and suitable combinationsare listed and explained shortly.
Based on the list, classifying strategies indifferent groups is possible. These groupsallow the validation of the first require-ment. Changes on AP elements are notallowed.
On the base of the first validation the othergiven requirements has to be investigated.The strategies must fulfill the following re-quirements:• Collected data has to provide infor-
mation about changes in a BO in-stance and about its history.
• The transferred data volume shouldbe optimized and the performanceshould be acceptable.
• The software effort should be accept-able in initial implementation, main-tenance and administration.
The last step is to verify if the strategyrefers to the reference example. Finally,a decision has to be made which strate-gies should be implemented in order to testtheir practical behavior.
Figure 3.1: Investigation Methodology
24
3.2. Components
3.2 Components
According to the introduced methodology, identifying the data sources is nec-
essary as well as the access methods. Therefore, becoming acquainted with
the given AP and TP possibilities is inevitable. Afterwards, the data sources
can be combined with the access methods and these combinations can be val-
idated.
3.2.1 Sources
Business Objects
BOs are the basic elements of future business applications, because they con-
tain the business logic and implement the service providers. BO means an
object of the AP which holds and works on business data. In relation to the
reference scenario the important BOs are SupplierInvoice and Supplier. The
SupplierInvoice controls the payment obligation to pay the supplier for goods
received or services rendered. The BO SupplierInvoice belongs to the PC Sup-
plier Invoice Processing and the DU Supplier Invoicing [RWK06]. Supplier
contains information to identify the business partner rather the supplier. The
BO Supplier exists in the PC Business Partner Data Management which is
located in the Foundation Layer of the AP [Str05].
Platform Change Documents
A transaction is a record of changes done to a BO and is described by the time
stamp, the user account and the data changed. Thus, these changes have to be
logged for reproducing the change path and investigating the BO instance his-
tory. This requirement is covered by Platform Change Documents∗ [PKVC06].
The possibility to observe the changes is modeled and implemented as a Tech-
nical Object∗ (TecO), a special kind of a BO, with the name ChangeDocu-
ment. It exists directly in the Foundation Layer and does not belong to any
DU. ChangeDocument provides the enterprise SOA core services Retrieve, Re-
trieveByAssociation and Queries to read Platform Change Documents. At the
moment of current investigations, it implements only one compound service
for XML archiving.
25
3.2. Components
The creation of ChangeDocument items is called in a generic way during the
“After Save” activities by the ESI framework. Thus, during the development of
BOs no attention needs to be drawn on calling the TecO ChangeDocument to
create Platform Change Documents. After ChangeDocument is called from the
ESI, it uses the Retrieve and RetrieveByAssociation services to create before
and after images of the changed BO instance. Hence, the BOs has to provide
an implementation of the Retrieve and RetrieveByAssociation services, but
additional code is not required [PKVC06]. A1S provides a UI for configuring
the monitoring of BOs and their actions and displaying items. Therefore,
mandatory and optional settings are available. For every changed element of a
BO instance a change document line item is created, by which the possibility
is offered to reproduce the history of a BO instance.
The suitable data sources are the relevant BOs themselves, like Supplier and
SupplierInvoice, and the TecO ChangeDocument, which provides information
about data changes of BO instances.
3.2.2 Access Methods
Core Services
Core services are stateful and synchronous services that provide elementary
service operations on BO nodes. They represent the atomic functionalities of
the AP in a standardized way and wrap the business logic. As a consequence
of their standardization, they are not modeled in the ESR. Core services are
important for building up UIs, for example with Web Dynpro∗, and enable the
implementation of higher level A2A and B2B compound services. Examples
for such core service operations are finding instances or reading and modifying
instance data. These service operations are integrated in interface patterns,
like the Access interface. This interface delivers the operations Create, Re-
trieve, Update and Delete. The operations and their parameters are derived
from the BO node model and so generic core services can be offered. Thus, all
BOs can be handled in the same way and this provides the possibility to build
intelligent generic engines. Therefore, “Core services are generic and provide
each business object node with something like its own toolbox” [FMW06, p.
18]. Apart from Access, three other important interface patterns exists: As-
26
3.2. Components
sociation, Query and Action. Core services communicate only synchronously
with each other [FMW06].
Data can be accessed from a BO instance by using core services in general.
Usually, calls are realized by using a LCP and can look like the following
ABAP∗ code example (listing 3.1).
Listing 3.1: LCP Call of a BO Core Service in ABAP
1 CALL METHOD cl_esf_lcp_factory⇒get_lcp_facade
2 RECEIVING
3 out_lcp_facade = lr_lcp_facade.
4 ** get lcp
5 CALL METHOD lr_lcp_facade→get_lcp
6 EXPORTING
7 in_bo_name = /srmap/if_fnd_constants_bo⇒c_bo_po
8 RECEIVING
9 out_lcp = mr_lcp_po.
10 CALL METHOD mr_lcp_po→retrieve
11 EXPORTING
12 in_bo_node_name = /srmap/if_fndx_pd_template⇒co_bo_node -root
13 in_node_ids = lt_node_ids
14 IMPORTING
15 out_data = lt_po_root_nodes.
In the first step, the LCP facade is created by calling a function of a factory
class (lines 1 - 3 in listing 3.1). This LCP facade provides a method to get a
LCP (lines 5 - 9 in listing 3.1). Then, the LCP is used to access BO nodes
with a retrieve action (lines 10 - 15 in listing 3.1). Therefore, the BO node
name and the node IDs have to be transferred (lines 12 and 13 in listing 3.1).
The outcome is a list of the called BO nodes which contain actual data of the
BO instances (line 16 in listing 3.1).
The other way is to access the core services using Generic Core Service Con-
sumer Proxies∗ (GCP). This technology is also used by the UI of A1S. GCPs
enable Java applications to call core services from outside the DU by using Re-
mote Function Calls∗ (RFC) or SOAP∗. For such calls the user, e.g. FRODO,
needs authorizations for sending RFC or SOAP calls. Such a call looks like
the following code example.
27
3.2. Components
Listing 3.2: GCP Call of a BO Core Service
1 // Get connection
2 ConnectionData connectionData = getConnectionData ();
3
4 // Get a service facade instance establishing a connection with a backend
system
5 IServiceFacade serviceFacade = null;
6 try {
7 serviceFacade = ServiceFacadeFactory.createServiceFacade(connectionData , new
Locale("en"));
8 } catch (Exception e) {
9 e.printStackTrace ();
10 }
11
12 // Load the ChangeDocument BO model
13 IBOModel model = serviceFacade.getBOModel(ISalesOrder.ESR_NAME);
14
15 // Create a query
16 IQuery query = model.createQuery(ISalesOrder.Root.ESR_NAME , ISalesOrder.Root.
QUERY_HEADER_ESR);
17
18 // Execute Query
19 query.execute ();
20
21 // Get the results
22 IBONode node = query.getResultBONode ();
23
24 // Process input data
25 dumpBONode(node , IChangeDocument.Root.NAME + ": Only 5 records are returned");
26
27 // Close connection to the backend system
28 serviceFacade.close ();
After connecting to the AP (lines 2 - 10 in listing 3.2), the relevant BO model
is loaded (line 13 in listing 3.2). In this case it is the BO Model of ChangeDoc-
ument. Afterwards, a query is created and submitted to the AP system (lines
16 and 19 in listing 3.2). The query delivers data which can be processed in
the next steps (lines 22 and 25 in listing 3.2). At the end, the connection to
the backend system has to be closed (line 28 in listing 3.2).
Compound Services
Core services are too finely grained to be used directly for A2A or B2B com-
munication. Compound services are implemented individually for each BO
and enable A2A and B2B interfaces to access only the needed attributes and
actions. Thus, they are driven by the process needs and the access is limited
in data unlike the core services. Usually, compound services are not reusable
28
3.2. Components
services. Therefore, they are not limited at one BO, but may combine calls
to any number of BOs. In detail, they are the “implementation of the service
interfaces, the definition of the interface in the ESR and the corresponding ser-
vice configuration in the system providing the service” [SAP06e, p. 6]. Com-
pound services are implemented by using core services to access and modify
the business object instances. The compound service interfaces are modeled in
ESR and provide synchronous or asynchronous communication between service
consumer and provider. The services can be invoked from SAP and Non-SAP
application code. Figure 3.2 shows the context between core and compound
services [FMW06].
Figure 3.2: Services of a BO (based on [SAP06c])
The diagram (figure 3.2) shows that the compound services are the interface to
the PC’s external world. Other PCs from other DUs, composite applications
and a B2B Partner can access the business logic via the compound services
only. That compound services work internally by using core services becomes
visible. Thus, the separation is clear, a compound service is never a core service
and vice versa.
In general, using compound services is possible to collect BO data from external
tools. For using the compound services, service consumer proxy classes need to
29
3.2. Components
be generated. Such a class provides one callable method for every operation.
To develop a compound service, a service interface has to be modeled in the
ESR. Afterwards, a service provider in ABAP has to be generated. Only then
the BO can be accessed with LCPs. For the usage with Java, a client has to
be created for the service provider via WSDL.
SAP Business Information Warehouse
BW is one part of SAP BI and builds up the DW of SAP. BW collects and
stores information from different sources in one central point.
Figure 3.3: FRODO on Top of BW
Firstly, a suitable InfoCube is inevitable, either by using an existing one or
implementing a new one to ensure that the relevant data exists in the BW
database. The next step is the access to this data by the FRODO mediator
(see figure 3.3).
Data access is possible in three different ways. The first one is to copy the
needed data to FRODO’s limited data storage with the BW interface Open
Hub service. Therefore, a Open Hub destination has to be created in the BI
system. The second strategy is to implement the mediator of FRODO as an
analysis tool. This means that the mediator directly accesses the tables on the
30
3.2. Components
database. The third way is the usage of XML for Analysis∗ (XML/A). The
Multidimensional Expressions∗ (MDX) processor of the BI system provides a
usable basis for the XML/A interface. By using XML/A, the implementation
is very simple. Only a SOAP request has to be sent to the BI and a XML
file with the results can be received. The request can be designed with queries
written in MDX.
Such a MDX statement is similar to the Structured Query Language (SQL)
and consists of SELECT, FROM and WHERE parts (see figure 3.4).
Figure 3.4: MDX Example [SAP06a]
The SELECT definition looks a little bit different to a SQL statement, because
it is divided in ON COLUMNS and ON ROWS. With this statements the axes
can be defined. FROM and WHERE are equal to SQL; namely with FROM
the InfoCube is selected and with WHERE some filters are configured.
In figure 3.4 is shown, that the columns profit, document number and open
orders are selected with the specification of ON COLUMNS. These details are
shown for different locations which is specified with ON ROWS. The source
is a InfoCube with the name OD SD C03/SAP DEMO OLEDB. The data is
limited on time January and on location US with the WHERE statement.
31
3.2. Components
Own FRODO Business Object
A possible solution is the development of an own BO for FRODO, the task of
which is to access other BOs. After collecting the data, handling can happen
in two ways. On the one hand, the BO only combines the collected data and
provides it to an external application via the in-built compound service. On
the other hand, the BO can also analyze the data itself and present the results
in its own UI. The development of an own BO, however, is time-consuming and
the management effort is huge, because changes at the AP need to be approved
by the Process Integration Content (PIC) Council9 for the development.
Accessing the data sources is feasible by using core and compound services, as
well as using BW or an own BO for FRODO.
Matrix
To connect data sources with the access methods the different possibilities are
combined with each other (step two of the introduced methodology). The
combinations are drawn in table 3.1 and the entries refer to the solution list in
chapter 3.3.1.
Coreservice
Compoundservice
BW OwnFRODO
BOBO 1. 2. 3. 4.ChangeDocument 5. 6. 7. 8.
Table 3.1: Evaluation of Solutions
9 The PIC Council is the round table of integration experts from all development units.Their tasks are design of semantically correct interfaces and data types, ensuring inter-national standard, encouraging reuse of data types, establishing SAP-wide consolidationand improving the Integration Guidelines [SAP06b].
32
3.3. Identifying Concrete Strategies and Classifying them
3.3 Identifying Concrete Strategies and
Classifying them
Referring to the methodology, clearly defining all strategies, resulted from the
combination of data sources and access methods, and explaining them in a
short way is inevitable. Afterwards, the concrete strategies can be ordered in
different groups.
3.3.1 List of Possible Strategies
Bearing in mind general combinations, strategies can easily be defined.
1. Accessing BOs through their core services
Firstly, accessing the BOs via their core services is possible. Therefore,
GCPs can be used. The data can be queried by the interface pattern
Query and the received information can be provided FRODO in struc-
tured files. In relation to the reference scenario the BOs SupplierInvoice
and Supplier have to be accessed for instance.
2. Accessing BOs through their compound services
Accessing the relevant BO can happen using its given compound services.
Afterwards, working on the received data needs to be done, to filter out
the relevant information, if the information is available. In relation to
the reference scenario, using existing compound services is necessary, e.g.
from both SupplierInvoice and Supplier BO.
3. Accessing BO data over BW
Accessing the BW database to get the data of a BO instance and ex-
ecuting the analysis on this data is another option. For accessing this
data, BW provides three possibilities: XML/A, Open Hub or direct ac-
cess to database tables. Additionally, a generic solution is possible as
well. This solution works with an interface layer between FRODO and
BW and aims on a very generic approach with a regard to a future scope.
However, the implementation effort is too huge for this thesis. Thus, the
33
3.3. Identifying Concrete Strategies and Classifying them
solution is not investigated but explained in appendix C in more detail.
4. Collecting BO data with an own FRODO BO
One strategy is to develop a special BO for FRODO which accesses the
relevant BOs over their core services. The FRODO BO itself can only
merge the data and provide it to the analysis part of FRODO outside
(solution 4a) with a compound service; or the BO executes the analysis
itself and provides the results to a UI which is part of A1S (solution 4b).
5. Accessing ChangeDocument via core services
One way to access the BO ChangeDocument can be to use its core ser-
vices. Therefore, the use of GCPs is possible. With that it is possible
to query relevant data with the use of suitable interface patterns, e.g.
Query. Afterwards, the data can be provided in structured files.
6. Accessing ChangeDocument via compound service
From outside, ChangeDocument can be accessed in two different ways;
one is to use the existing compound service for archiving and analyze the
out-coming XML file. The other one is to request a general compound
service for the TecO ChangeDocument or implement one. At the moment
of research, in SAP architecture departments, the additional compound
service is discussed.
7. Accessing ChangeDocument data via BW
Accessing the BW database is another possibility to get the data of
ChangeDocument and execute the analysis on that data. Therefore, the
access possibilities are using XML/A, Open Hub service or accessing the
database tables directly.
8. Accessing ChangeDocument via FRODO BO
Developing a special BO for FRODO for accessing the data from the
TecO ChangeDocument is also an option. The created BO uses the core
services of the ChangeDocument and forwards it either to the external
FRODO tool (solution 8a) or executes the analysis by itself and provides
the results to an UI which is part of A1S (solution 8b). These variants
are like solutions 4a and 4b.
34
3.3. Identifying Concrete Strategies and Classifying them
Figure 3.5 shows all solutions to access the needed data.
Figure 3.5: Strategy Overview
3.3.2 Classification
FRODO takes in the role of an ISV product. ISVs should not be able to
change the AP. Additionally, the effort of receiving approval for a development
on AP from the PIC Council bears no relation to its use. According to the
based methodology, the identified solutions can be classified in three different
groups.
For reason of simplicity, the TecO ChangeDocument is not drawn separately in
the next diagrams and can therefore be regarded as a BO like the other BOs,
e.g. SupplierInvoice.
The first class describes solutions which only use existing services and compo-
nents of the TP or the AP. At the AP level the BOs provide core and compound
35
3.3. Identifying Concrete Strategies and Classifying them
services to allow access to some of their data and BW provides the access to
data for external applications on the TP site (see figure 3.6).
Figure 3.6: FRODO as a Completely External Solution
For the first class strategy one and two can be applied, namely accessing BOs
with their core or compound services, as well as solution three, the usage of
BW which provides the data of the BOs. In this category is also the access
of ChangeDocument using core and compound services (solutions five and six)
and the access of ChangeDocument by using BW (solution seven).
Class two contains external solutions with an individual component inside the
AP. The component at the AP is typically a BO. The function of the BO
depends on the strategy (see figure 3.7).
Category two contains the solutions 4a and 8a, both of them using a FRODO
BO to access either BOs or ChangeDocument. After merging the data, these
solutions forward the data to the external FRODO tool to analyze the data
and to display the results over the tool’s own UI.
36
3.3. Identifying Concrete Strategies and Classifying them
Figure 3.7: FRODO with Components Inside the AP
The third class describes completely new solutions.
Figure 3.8: FRODO as an Element of AP/A1S
They consist of a BO at the AP and an element in A1S. Thus, the detection
37
3.4. Ranking of Possible Solutions
logic is implemented in the BO and the old FRODO prototype is not used
anymore. Here, the results are displayed over the UI component in A1S.
Solutions 4b and 8b belong to class three. Strategies 4b and 8b use the FRODO
BO to analyze the data from the BOs and show the results in their own UI
located in A1S. The mentioned solutions are working without any external
application and consequently, the old FRODO prototype stands outside with
no functions relating to the AP.
According to the first requirement, claiming no changes on SAP internal devel-
opments, only the solutions of class one are possible. Thus, the more detailed
investigations target on the solutions using core and compound services or
BW either on BOs or on ChangeDocument in concordance to the other re-
quirements.
3.4 Ranking of Possible Solutions
Step three of the investigation methodology ranks the possible strategies based
on three features.
• Firstly, the collected data must provide information about changes of the
BO instance. Important information is for instance the responsible user
and the time of change. The reference scenario requires for collecting
information about the times of changing bank details and the person
who did the changes in the master data.
• Secondly, transferred data volume and performance should be in an ac-
ceptable range. FRODO’s current approach is to serve as a tool for
periodical analysis. Thus, the data volume is huge after a few weeks or
months, whereas a productive system’s data volume needs to be held as
small as possible.
• A third criterion should be the software effort. The effort can be regarded
from three different views. One is the initial effort to implement a running
solution. The second view is investigating maintenance costs while the
software is running. These costs consider the effort if the product needs
38
3.4. Ranking of Possible Solutions
bug-fixing or if the solution is used with other platforms or other data
sources. The last point of view should be the administration. FRODO
should quickly be working with new scenarios without much additional
effort.
The in the last investigation (see chapter 3.3.2) identified solution should be
evaluated in tables. Every criterion is evaluated by symbols shown in the
following table.
Evaluation MeaningCriterion is dissatisfyingCriterion is acceptableCriterion is fulfilled in a good wayCriterion is not appreciable and needs evaluation in a practical test
Table 3.2: Meaning of the Evaluation Symbols
Accessing BOs Using their Core Services
Core services are not useful for FRODO’s approach, because they only return
the current state of the BO instance but no information about changes and
history. Data volume and performance are in an optimal range, because with
the Query interface pattern only required data can be requested. The initial
implementation effort is in an average range. On the one hand, core services
are called and so only the mediator has to be implemented, but on the other
hand, FRODO needs authorization to call the BO’s core services. This requires
for every fraud scenario a huge effort in maintaining the authorization for a
special FRODO user.
Requirement EvaluationInformation about changes and historyData volume & PerformanceSoftware effortUsable for FRODO
Table 3.3: Evaluation of Accessing BO Data Using Core Services
39
3.4. Ranking of Possible Solutions
Accessing BOs over their core services fulfills the criteria in an average to
a dissatisfying way. Thus, this solution is not useful for the new FRODO
prototype.
Accessing BOs Using their Given Compound Services
Compound services of BOs are not applicable because they are based on core
services and core services only return the current state of the BO instance
but no information about changes and history. The data volume and the
performance have to be verified in a practical implementation, because in case
of given compound services the response might have too much overhead. In
this case overhead means useless data for fraud detection. Thus, the compound
services of the single BOs are only usable to a limited extent. The initial
implementation effort should be small because only existing services can be
used and so only the mediator has to be implemented. The maintenance
effort is acceptable but the administration effort is huge, since every new fraud
scenario requires new compound services to be searched and the software has
to be modified for the new data sources.
Requirement EvaluationInformation about changes and historyData volume & PerformanceSoftware effortUsable for FRODO
Table 3.4: Evaluation of Accessing BO Data Using Compound Services
This solution fulfills the criteria in a dissatisfying way. Thus, this solution
is not usable for accessing data from the AP for providing it to the FRODO
tool.
Accessing the BO Data Using BW
For collecting history data of a BO instance from outside the AP, three access
methods provided by BW are possible. The differences are in performance,
transferred data volume and software effort.
• The first strategy with XML/A depends on the quantity of needed data.
40
3.4. Ranking of Possible Solutions
If the volume is small, the strategy is good, because data is available in
XML format. However, if the volume becomes bigger it is not the best
solution. The reason is the property of XML files, because the overhead
multiplier of such a file can be between 10 and 1,000 compared to the
needed data. By using XML/A, the implementation is very simple. Thus,
the initial software effort is small for this solution, because the program
has to create the SOAP request only and has to parse the received XML
file. For new scenarios new BW sources have to be searched and new
MDX queries have to be written. Thus, maintenance and administration
effort is minimal.
• The second strategy using the BI Open Hub service is acceptable, be-
cause transferred volume and performance is average. Using this variant,
FRODO has more or less its own DW. This may grow with the further
developments on project FRODO if FRODO is going to be used with
other data sources from other vendors. The initial effort is acceptable
since an Open Hub destination has to be created in the BW for every
data source. Therefore, for every new scenario the relevant BW database
tables have to be identified. The Open Hub service provides all techni-
cal background and hence implementation is very simple with further
maintenance and administration expenses in an acceptable range.
• The last solution, namely direct access to the BW database tables, pro-
vides the best value in transferred data volume and performance. There
is no effort with FRODO special data mining. The BW might have to be
configured to have the relevant data in the BW database. The initial soft-
ware effort is acceptable, because access methods for the different data
sources have to be implemented. For every new scenario on the other
hand, relevant data has to be searched in the BW and new access meth-
ods have to be implemented. Thus, the maintenance and administrative
effort is huge and not acceptable.
The most promising solution in this strategy area is accessing BW via the
XML/A interface, because it is very simple to implement. The other solutions
are applicable for FRODO but require for more implementation effort.
41
3.4. Ranking of Possible Solutions
Requirement EvaluationXML/A
EvaluationOpenHub
Evaluationdirectaccess
Information about changes and historyData volume & PerformanceSoftware effortUsable for FRODO
Table 3.5: Evaluation of Accessing Data Using SAP BW on BO Data
Accessing ChangeDocument via Core Services
Using core services for accessing the TecO ChangeDocument is another op-
tion. ChangeDocument provides, like all BOs, some interface patterns, like
Query. Query enables applications to query relevant data from different BO
instances. Thus, data volume and performance are optimal. The task of
ChangeDocuments is to store and provide information about the history of
several BO instances. The usage of the TecO ChangeDocument is exactly the
strategy which completely targets at the approach of the FRODO project. The
implementation is simple, because only a query has to be submitted from a
Java application. For different scenarios only different queries have to be sub-
mitted and the receiving data should be presented in structured files. Thus,
maintenance and administration requires only for a few effort, because only
the Java application is the point where new requirements regarding to new
scenarios and new data sources have to be fulfilled.
Requirement EvaluationInformation about changes and historyData volume & PerformanceSoftware effortUsable for FRODO
Table 3.6: Evaluation of Accessing ChangeDocument Using Core Services
This solution is a very promising one, because the AP is not affected by
changes. The implementation will happens only at the FRODO site.
42
3.4. Ranking of Possible Solutions
Accessing ChangeDocument Using a Compound Service
The solution of implementation using a compound service is another good
strategy in the field of using the TecO ChangeDocument. The requirements
information about changes and history, data volume, and performance are ful-
filled in the best way. The existing compound service for XML archiving cannot
be used for the FRODO approach, because it is not accessible from outside.
The service is an outbound interface and so it is only triggered directly from
the BO and not from outside. Thus, the creation of an additional compound
service should be discussed. The discussion handles topics like the missing
security concept for such a compound service. Other development teams are
also interested in having such a service to access ChangeDocument data from
outside of the AP. For the new compound service the software effort is huge,
because it has to be encroach upon the AP. For the new compound service a
new service interface has to be modeled in the ESR and the underlie service
provider has to be implemented. For new scenarios, the filter for received data
has to be modified only. As a consequence, maintenance and administration
is minimal.
Requirement EvaluationInformation about changes and historyData volume & PerformanceSoftware effortUsable for FRODO
Table 3.7: Evaluation of Accessing ChangeDocument Using Compound Services
This solution is also useful, but about the use of the new compound service, the
PIC Council has to decide. At the moment, some security compunctions are
left about accessing the TecO ChangeDocument from outside. The solution is
an exception regarding to the first requirement which claims for no changes on
the AP, because ChangeDocument is especially developed for storing history
data of BO instances and very useful for FRODO. The new compound service
would be an additional component and the development would be controlled
by the developer of ChangeDocument.
43
3.4. Ranking of Possible Solutions
Accessing ChangeDocument Data via BW
Accessing the data of ChangeDocument from outside the AP is also possible
with BW, but for ChangeDocument a new InfoCube has to be developed.
Developing an InfoCube requires huge effort in management and development.
Thus, the initial implementation effort is very huge. Maintenance and admin-
istration, however, would be in an acceptable range, because only the filter in
FRODO has to be customized for new scenarios. Afterwards, all three BW
access methods can be used.
• The XML/A solution might have too much overhead, depending on the
data volume.
• Using the Open Hub solution is acceptable, but with this solution FRODO
has more or less its own DW.
• Direct access is the most promising access method in this area, because
it is the fastest and most optimal in data volume.
Requirement EvaluationXML/A
EvaluationOpenHub
Evaluationdirectaccess
Information about changes and historyData volume & PerformanceSoftware effortUsable for FRODO
Table 3.8: Evaluation of Accessing Data Using SAP BW on ChangeDocumentData
In this strategy area all solutions are acceptable, but the initial effort to develop
an own InfoCube for ChangeDocument is too huge and the ratio between effort
and use are not within acceptable parameters.
44
3.5. Conclusion
3.5 Conclusion
In the following table (table 3.9) the outcome of the previous investigations
should be summarized. According to the investigation methodology, some
solutions are selected for implementation.
Strategy Informationabout
changesand history
Datavolume &perfor-mance
Softwareeffort
Usable forFRODO
BOsCore serviceCompound service
BW
XML/AOpen HubDirect access
TecO Change DocumentCore serviceCompound service
BW
XML/AOpen HubDirect access
Table 3.9: Summary of all Strategies
After consolidating the research results, the implementation effort will focus on
the strategy to using the core services of the TecO ChangeDocument. Addi-
tionally, the possibility for accessing BW using the XML/A interface should be
investigated in more detail. The BW solution focuses only on accessing BOs,
because the development of a new InfoCube for ChangeDocument requires
too much effort.
45
CHAPTER4
Implementation of Solutions
The two most promising solutions now need to be implemented and evaluated
according to the following steps. The strategies are:
• Access the TecO ChangeDocument by using its core services
• Receiving BW data of BOs using XML/A
Each solution is implemented separately and the development follows the “Wa-
terfall Model” of software engineering as shown in figure 4.1.
Figure 4.1: Waterfall Model for Development
The specification and analysis phases were performed in the previous chapters
(dashed rectangles in figure 4.1), because they are very similar for all the strate-
gies. Thus, for every strategy, design, implementation and testing have to be
46
4.1. Accessing the TecO ChangeDocument by Using its Core Services
investigated (rectangles in figure 4.1). In the design phase, the access method
is made more concrete from a programmer’s perspective. The implementation
is the coding of the solution; highlights are described in detail. Afterwards,
the software has to be tested for correctness.
4.1 Accessing the TecO ChangeDocument by
Using its Core Services
Using core services of ChangeDocument is one implementation for accessing
data of BO instances. The software is designed in a theoretical way first.
Afterwards, the design is implemented and finally, the software is tested.
4.1.1 Design
For understanding how this approach solves the problem, it should be presented
in the big picture of the AP architecture.
Figure 4.2: Implementation of GCP in the Big Picture
47
4.1. Accessing the TecO ChangeDocument by Using its Core Services
The high-level overview of the software solution is drafted with a program
sequence diagram in figure 4.3.
Figure 4.3: Program Sequence Diagram for Accessing ChangeDocument UsingGCP
The access to the TecO ChangeDocument requires a connection to the backend
system. Therefore, a central point should be available, where the connection
can be configured. A property file is adequate for that and should contain data
about:
• Connection data service
• Host name
• System group
• System name
• Client
48
4.1. Accessing the TecO ChangeDocument by Using its Core Services
• User language
• User name
• Password
With this data the connection can be set up and the first step is completed.
Retrieving the right data should be realized with queries. After creating the
query for getting the relevant data, the query is sent to the backend system.
The client side is now able to receive the requested data. The received data
should be converted into a Resource Description Framework∗ (RDF) file. These
RDF files enable the current FRODO prototype to analyze the data and detect
fraud.
4.1.2 Implementation
The outcome of the design phase is implemented in Java by using the Integrated
Development Environment (IDE) SAP NetWeaver Developer Studio10. The
code is written according to the ESF Java Client example11. For running the
code beside the APIs provided by the Java Development Kit (JDK) 1.5, the
following JAR files are required. These are provided in the folders of the ESF
Java Client example.
cache.jar esf.base.metadata api.jar
com.sap.directory.runtime.container.mod api.jar esf.base.rpe.jar
com.sap.directory.runtime.mod api.jar esf.client.gcp api.jar
com.sap.directory.services api.jar esf.client.gcp core.api
com.sap.exception.facade.jar esf.client.smp.jar
com.sap.tc.cmi api.jar esi.metadata api.jar
esf.base.cds api.jar esi.metadata core.api
esf.base.edo api.jar logging.jar
esf.base.internal.jar sapjco.api
The connection is realized by the connection data service provided by the
10 SAP NetWeaver Developer Studio is based on Eclipse and is extended with functionalityaccording to SAP’s technologies and development guidelines.
11 Information and Sample code available at SAP BIS(https://bis.wdf.sap.corp/twiki/bin/view/Sapinternal/ESFEndToEndSamples)
49
4.1. Accessing the TecO ChangeDocument by Using its Core Services
ESF client metadata API. The connection parameters are configured with a
property file like the following listing 4.1.
Listing 4.1: Structure of Connection Property File for Using GCP
1 cds.channel=JCO
2 mshost=ldcias1.wdf.sap.corp
3 group=PUBLIC
4 r3name=AS1
5 client =100
6 lang=EN
7 USER=HERZBERGNI
8 PASSWD=thesis
In detail the connection set up looks like the following code. After getting
a connection data service from a factory, the service can be used to retrieve
generic connection data (lines 2 and 3 in listing 4.2). These generic data are
updated with the specific parameters from the property file (line 8 in listing
4.2). With that connection data a service facade can be instantiated and the
connection is set up (lines 11 - 16 in listing 4.2). Before building up the query,
a BO model has to be instantiated by using the service facade (line 19 in listing
4.2).
Listing 4.2: Connection to the AP
1 // Get Connection Data Service and generic Connection Data
2 IConnectionDataService cds = ConnectionDataServiceFactory.
getConnectionDataService ();
3 ConnectionData cd = cds.getConnectionData(ConnectionData.channelGeneric ,
ConnectionData.typeGeneric);
4
5 ...
6
7 // Add properties to the generic Connection Data
8 cd.putAll(props);
9
10 // Get a service facade instance establishing a connection with a backend
system
11 IServiceFacade serviceFacade = null;
12 try {
13 serviceFacade = ServiceFacadeFactory.createServiceFacade(cd, new Locale("en"
));
14 } catch (Exception e) {
15 e.printStackTrace ();
16 }
17
18 // Load the ChangeDocument BO model
50
4.1. Accessing the TecO ChangeDocument by Using its Core Services
19 IBOModel model = serviceFacade.getBOModel(ISalesOrder.ESR_NAME);
For instantiating a BO model, an interface of the BO has to be generated.
This can be realized with a Java application called BODescriptionGenerator.
The application is included in the sample project “esf.sample” provided in the
SAP Basis Information System (BIS). The interface describes the structure
of the BO model. The following figure shows a section of one of the inter-
faces, the whole code can be found in appendix D. In this case, the interface
IChangeDocument.java is shown in listing 4.3.
Listing 4.3: Section from BO Model Interface IChangeDocument.java
1 public interface IChangeDocument {
2 String NAMESPACE = "http :// sap.com/xi/AP/IS/PlatformChangeDocument/Global";
3 String NAME = "ChangeDocument";
4 IESRName ESR_NAME = ESRNameFactory.createESRName("ChangeDocument", "http
:// sap.com/xi/AP/IS/PlatformChangeDocument/Global");
5
6 // BO Node ChangeDocumentItem
7 interface ChangeDocumentItem {
8 String NAME = "ChangeDocumentItem";
9 IESRName ESR_NAME = ESRNameFactory.createESRName("ChangeDocumentItem", "")
;
10 ...
11 }
Afterwards, the query can be created and configured (lines 2 - 7 in list-
ing 4.4). The query is of the type IQuery and can be specified with meth-
ods like createSelectOption() (lines 6 and 7 in listing 4.4). Relevant at-
tributes can be identified with the BO browser delivered in the software project
“esf.samples”. After submitting the query with the method execute() (line
10 in listing 4.4), the received data is handled (line 12 in listing 4.4).
Listing 4.4: Code for Query Creation and Data Receiving
1 // Create a query
2 IQuery query = model.createQuery(IChangeDocument.Root.ESR_NAME.getFullName (),
IChangeDocument.Root.QUERY_QUERY_BY_BUSINESS_OBJECT_NAME_ANDID);
3 // Limit the number of results
4 query.setMaximumResultElements (5);
5 // Set query options
6 query.createSelectOption("ObjectTypeCode", ISelectOption.Operator.EQUAL , "
00001", null);
51
4.1. Accessing the TecO ChangeDocument by Using its Core Services
7 query.createSelectOption("ObjectId", ISelectOption.Operator.EQUAL , "00001",
null);
8
9 // Execute Query
10 query.execute ();
11 // Get the results
12 IBONode node = query.getResultBONode ();
In the implemented example, the received data is simply printed out to the
Java console. The whole software code is attached in appendix D.
4.1.3 Test
In the test scenario, retrieving some ChangeDocument data from a BO should
be possible, namely the data for the BO SupplierInvoice should be queried.
Due to the fact that the author has no authorization to access the development
systems and the sandbox systems do not provide real data of BO instances, the
execution of the software results that no data is available. Among other things
this causes in the fact that the TecO ChangeDocument is still in development.
The GCP implementation, however, is correct because the implementation
works with another BO, namely the BO SalesOrder. The response from the
system looks like the text in the following listing (listing 4.5).
Listing 4.5: Response to SalesOrder Query
Root: Only 5 records are returned
ID: 5000000675
TypeCode: SO
PostingDateTime: null
SystemAdministrativeData$CreationDataTime: 2006 -04 -27 06 :20:34 .0
SystemAdministrativeData$CreationSystemAccountUserID: T.P.KUMAR
SystemAdministrativeData$LastChangeDateTime: 2006 -06 -13 12 :30:09 .0
SystemAdministrativeData$LastChangeSystemAccountUserID: DEYS
SellerParty$SellerID: 5
BuyerParty$BuyerID: 6
Incoterms$ClassificationCodeContent: TES
Incoterms$TransferLocationName: null
TotalGrossAmount: null
TotalNetAmount: null
TotalTaxAmount: null
CurrencyCode: EUR
PurchaseOrderPostingDateTime: null
52
4.2. Receiving BW Data of BOs Using XML for Analysis
PurchaseOrderReferenceID: null
Status$AvailableToPromiseConfirmationStatusCode: 1
Status$AcceptanceStatusCode: 1
Status$InvoicingCompletionStatusCode: 1
Status$ArchivingStatusCode: 1
Status$LifeCycleStatusCode: null
...
4.2 Receiving BW Data of BOs Using XML for
Analysis
Accessing data of BW is possible with the use of the MDX processor given by
the BI system. After the design phase the ideas are implemented in Java and
tested with a test scenario.
4.2.1 Design
The usage of the MDX processor interface XML/A of the BI system is simple.
Firstly, a SOAP request has to be created. This request contains property
data, e.g. for formatting, and the MDX query. The MDX statement is the
main point in the SOAP request. The MDX query enables the software to
query the relevant data from an InfoProvider, e.g. an InfoCube. Afterwards,
the connection to the MDX processor has to be built up. This is realized with
a property file where the following data is configured:
• Host
• Port
• Client
• User
• Password
The request has to be sent to the MDX processor. The response of the backend
system is also in the SOAP format. The relevant data is provided in a struc-
53
4.2. Receiving BW Data of BOs Using XML for Analysis
tured form in XML in the SOAP body. This XML data has to be extracted
and converted to a RDF file. The current FRODO prototype can use the RDF
file for analyzing and detecting fraud.
The use of this technology for the approach of the FRODO project is drawn
in figure 4.4.
Figure 4.4: Program Sequence Diagram for XML/A Solution
To arrange this solution in the right way, the following figure should highlight
the involved components.
54
4.2. Receiving BW Data of BOs Using XML for Analysis
Figure 4.5: XML/A Solution in the Big Picture
4.2.2 Implementation
For the implementation of the design requirements the IDE SAP NetWeaver
Developer Studio is used as well for writing Java code. In this case, JDK 1.5
provides all the APIs required.
To follow the program sequence, given in the design phase, a SOAP request is
built up. This is done by string concatenations, because no WSDL is available.
Only an example of a SOAP Request is provided by documentations. In this
string, the MDX statement is included. The SOAP request looks like the
following code (listing 4.6).
Listing 4.6: SOAP Request to BI System
1 <SOAP -ENV:Envelope xmlns:SOAP -ENV=’http: // schemas.xmlsoap.org/soap/envelope/’
SOAP -ENV:encodingStyle=’http: // schemas.xmlsoap.org/soap/encoding/’>
2 <SOAP -ENV:Body >
3 <Execute xmlns=’urn:schemas -microsoft -com:xml -analysis ’ SOAP -
ENV:encodingStyle=’http: // schemas.xmlsoap.org/soap/encoding/’>
4 <Command >
5 <Statement >
55
4.2. Receiving BW Data of BOs Using XML for Analysis
6 select [Measures ]. members on columns , non empty [0 VC_COUN ]. levels (1)
.members * [0 VC_REG ]. levels (1).members dimension properties
member_name , member_caption on rows from [$0 BWVC_C03] where ([0
FISCYEAR ].[ K41999 ])
7 </Statement >
8 </Command >
9 <Properties >
10 <PropertyList >
11 <DataSourceInfo >default </DataSourceInfo >
12 <Catalog >Foodmart 2000</Catalog >
13 <Format >Tabular </Format >
14 <ReturnCellProperties >true</ReturnCellProperties >
15 <AxisFormat >TupleFormat </AxisFormat >
16 <Content >SchemaData </Content >
17 </PropertyList >
18 </Properties >
19 </Execute >
20 </SOAP -ENV:Body >
21 </SOAP -ENV:Envelope >
Line six in listing 4.6 shows the MDX statement. The whole part where some
properties (lines 9 - 18 in listing 4.6) are set is not changeable by variables in
the program, only the fixed string can be changed.
After creating the SOAP request, the connection to the BI system is created.
Therefore, the URLConnection of the package java.net is used (lines 1 - 16 in
listing 4.8). The parameters of the connection are written down in a property
file like the following code (listing 4.7).
Listing 4.7: Property File for Connection to a BI System
1 host=ldcia1y.wdf.sap.corp
2 port =50085
3 client =100
4 user=DISPLAY
5 passwd=SHOWME
Listing 4.8: Connection and Data Sending in XML/A solution
1 URL url = new URL(readproperties("connectionString"));
2
3 // Set up the connection
4 URLConnection conn = url.openConnection ();
5
6 // Add user
7 conn.setRequestProperty("sap -user",readproperties("user"));
8 // Add password
56
4.2. Receiving BW Data of BOs Using XML for Analysis
9 conn.setRequestProperty("sap -password",readproperties("password"));
10 // Add property Accept -Encoding
11 conn.setRequestProperty("Accept -Encoding","gzip , compress");
12
13 // Connection requires output
14 conn.setDoOutput(true);
15 // Connect to the URL
16 conn.connect ();
17
18 // Define OutputStream
19 OutputStreamWriter wr = new OutputStreamWriter(conn.getOutputStream ());
20 // Send SOAP request to the server
21 wr.write(data);
22 wr.flush();
23
24 // Get response
25 BufferedReader rd = new BufferedReader(new InputStreamReader(conn.
getInputStream ()));
Additionally, setting the Hypertext Transfer Protocol (HTTP) header line
“Accept-Encoding” to “gzip, compress” (line 11 in listing 4.8) in the con-
nection configuration is recommended since some SAP systems are configured
to send out compressed data. However, if this is not allowed they deliver a
message that the host is replaced temporarily (HTTP error code 302) and the
real error message, which expresses the missing HTTP header, is hidden. Thus,
the host is not reachable and the connection failed.
After the connection, the data is sent with OutputStreamWriter (line 21 in
listing 4.8) and the response is received with the help of an InputStreamReader
(line 25 in listing 4.8). In the example, the received data is printed out on the
Java console.
4.2.3 Test
In the test scenario, information about invoices should be available. Again,
due to the fact that the author has no authorization to access a productive
system and the sandbox systems do not provide real data about invoices, the
execution of the software received only SOAP requests with an empty data
part.
Yet, the implementation still works with other systems and other MDX state-
57
4.2. Receiving BW Data of BOs Using XML for Analysis
ments, namely the QB8 system with a MDX query for sales data. The response
shows that also a XML Schema Definition (XSD) is delivered which describes
the XML structure of the reference data (lines 7 - 33 in listing 4.10). In the
section at the bottom the real data exists (lines 34 - 36 in listing 4.10). This
data are structured in XML and the data record for Australia for instance
looks clearly arranged like the following listing 4.9.
Listing 4.9: Reference Data Structured in XML
1 <row>
2 <C000000 >AUS</C000000 >
3 <C000001 >Australia </C000001 >
4 <C000002 >AUSNRD </C000002 >
5 <C000003 >AUS/NRD</C000003 >
6 <C000004 >49.996 ,60 DM</C000004 >
7 <C000005 >X</C000005 >
8 <C000006 >224 ,470 PC</C000006 >
9 <C000007 >0,3 PC</C000007 >
10 <C000008 >1</C000008 >
11 <C000009 >892 ,000</C000009 >
12 </row>
The whole SOAP response in this case looks like the following listing (listing
4.10).
Listing 4.10: SOAP Response of the BI System
1 <?xml version="1.0"?>
2 <SOAP -ENV:Envelope xmlns:SOAP -ENV="http: // schemas.xmlsoap.org/soap/envelope/"
SOAP -ENV:encodingStyle="http: // schemas.xmlsoap.org/soap/encoding/">
3 <SOAP -ENV:Body >
4 <ExecuteResponse xmlns="urn:schemas -microsoft -com:xml -analysis">
5 <return xmlns:xsd="http: //www.w3.org /2001/ XMLSchema" xmlns:xsi="http: //
www.w3.org /2001/ XMLSchema -instance">
6 <root xmlns="urn:schemas -microsoft -com:xml -analysis:rowset" xmlns:xsd=
"http: //www.w3.org /2001/ XMLSchema" xmlns:xsi="http: //www.w3.org
/2001/ XMLSchema -instance">
7 <xsd:schema xmlns="urn:schemas -microsoft -com:xml -analysis:rowset"
targetNamespace="urn:schemas -microsoft -com:xml -
analysis:rowset" xmlns:xsi="http: //www.w3.org /2001/ XMLSchema -
instance" xmlns:xsd="http: //www.w3.org /2001/ XMLSchema"
xmlns:sql="urn:schemas -microsoft -com:xml -sql"
elementFormDefault="qualified">
8 <xsd:element name="root">
9 <xsd:complexType >
10 <xsd:sequence minOccurs="0" maxOccurs="unbounded">
11 <xsd:element name="row" type="row" />
12 </xsd:sequence >
58
4.2. Receiving BW Data of BOs Using XML for Analysis
13 </xsd:complexType >
14 </xsd:element >
15 <xsd:simpleType name="uuid">
16 <xsd:restriction base="xsd:string">
17 </xsd:restriction >
18 </xsd:simpleType >
19 <xsd:complexType name="row">
20 <xsd:sequence minOccurs="0" maxOccurs="unbounded">
21 <xsd:element name="C000000" type="xsd:string" sql:field="[0
VC_COUN ].[ LEVEL01 ].[ MEMBER_NAME]"/>
22 <xsd:element name="C000001" type="xsd:string" sql:field="[0
VC_COUN ].[ LEVEL01 ].[ MEMBER_CAPTION]"/>
23 <xsd:element name="C000002" type="xsd:string" sql:field="[0
VC_REG ].[ LEVEL01 ].[ MEMBER_NAME]"/>
24 <xsd:element name="C000003" type="xsd:string" sql:field="[0
VC_REG ].[ LEVEL01 ].[ MEMBER_CAPTION]"/>
25 <xsd:element name="C000004" type="xsd:string" sql:field="[
Measures ].[0 VC_AMT]"/>
26 <xsd:element name="C000005" type="xsd:string" sql:field="[
Measures ].[0 VC_DATE]"/>
27 <xsd:element name="C000006" type="xsd:string" sql:field="[
Measures ].[0 VC_MAX]"/>
28 <xsd:element name="C000007" type="xsd:string" sql:field="[
Measures ].[0 VC_MIN]"/>
29 <xsd:element name="C000008" type="xsd:string" sql:field="[
Measures ].[0 VC_ORD]"/>
30 <xsd:element name="C000009" type="xsd:string" sql:field="[
Measures ].[0 VC_ZHL]"/>
31 </xsd:sequence >
32 </xsd:complexType >
33 </xsd:schema >
34 <row><C000000 >AUS</C000000 ><C000001 >Australia </C000001 ><C000002 >AUSNRD </
C000002 ><C000003 >AUS/NRD</C000003 ><C000004 >49.996 ,60DM</C000004 ><C000005 >
X</C000005 ><C000006 >224 ,470 PC</C000006 ><C000007 >0,3 PC</C000007 ><C000008
>1</C000008 ><C000009 >892 ,000</C000009 ></row>
35 <row><C000000 >DE</C000000 ><C000001 >Germany </C000001 ><C000002 >DE BAW</C000002 ><
C000003 >DE/BAW</C000003 ><C000004 >1.102.729 ,84 DM</C000004 ><C000005 >X</
C000005 ><C000006 >1.134 ,620 KG</C000006 ><C000007 >0,9 KG</C000007 ><C000008 >
2</C000008 ><C000009 >297 ,000</C000009 ></row>
36 <row><C000000 >DE</C000000 ><C000001 >Germany </C000001 ><C000002 >DE BAY</C000002 ><
C000003 >DE/BAY</C000003 ><C000004 >1.068.745 ,64 DM</C000004 ><C000005 >X</
C000005 ><C000006 >1.183 ,430 KG</C000006 ><C000007 >0,6 KG</C000007 ><C000008 >
2</C000008 ><C000009 >293 ,000</C000009 ></row>
37 </root>
38 </return >
39 </ExecuteResponse >
40 </SOAP -ENV:Body >
41 </SOAP -ENV:Envelope >
59
CHAPTER5
Validation
The aim of the validation phase is to discuss the received results of the imple-
mented software. Additionally, the new solutions should be compared to the
R/3 solution of FRODO.
5.1 Validation of Test Results
Due to the fact that retrieving relevant data cannot be tested yet, the ac-
curacy of the data delivered by the different backend systems cannot be val-
idated. Nevertheless, the implemented software is tested with similar data.
Software measurements are not possible in detail, because the provided sand-
box systems do not have enough data to arrange representative data volume
and performance measurements. Thus, the quality of the software can only
be appreciated in a high-level way. Therefore, the test scenarios from the
previous chapter (section 4.1.3 and section 4.2.3) are executed 20 times and
the time from program start to program termination is measured in the Java
code directly by using the Date class from the package java.util.Date.The
recorded times are measurement results of the program executions on a lo-
cal computer in Brisbane (Australia) at a local time of 3.45 PM to 4.00 PM.
The backend systems are located in Germany. Thus, network times should be
considered as well. For instance a ping from Australia to Germany takes an
average time of 330ms. The results of the measurement are presented in the
next table.
60
5.1. Validation of Test Results
Run GCP solution XML/A solution1 20,760s 22,141s2 15,301s 12,818s3 15,312s 12,067s4 17,285s 12,087s5 15,322s 12,077s6 16,113s 18,116s7 15,312s 12,818s8 15,261s 12,808s9 15,352s 12,048s10 15,312s 12,057s11 15,412s 12,038s12 15,312s 12,788s13 15,332s 18,897s14 15,382s 12,788s15 15,322s 12,068s16 17,485s 12,798s17 15,372s 12,838s18 15,331s 12,067s19 15,412s 12,058s20 15,382s 12,849s
Average 15,854s 13,511s
Table 5.1: High-level Measurement Results of the Software Validation Phase
The average time of the GCP solution is approximately 16s and 13.5s of the
XML/A solution. Thus, the XML/A solution is more than 2 seconds faster.
On a closer look, the results seem conspicuous since the results of the GCP
solution are nearly constant and the results of the XML/A solution differ much
more. For that solution the peak time is 22s and the minimum is 12s. For a
representative conclusion further measurements with more and relevant data
are recommended. Known from experience, XML’s performance goes down
if the data volume grows. A definitive conclusion of the validation phase is
that retrieving data from the AP is possible with the help of the implemented
programs. For more lucidity, the measurement results are drawn in the next
graph (figure 5.1).
61
5.2. Comparison to the R/3 Solution
Figure 5.1: Graph of Software Measurement Results
5.2 Comparison to the R/3 Solution
In comparison to the R/3 solution, no serious differences are visible. In all
solutions the data has to be extracted by hand. By hand means in this case,
the use a given tools to extract data from a data source and store this in a RDF
file. Afterwards, the RDF files have to be imported in FRODO for detecting
fraud. Only the data sources are different. The old solution works with data
from R/3 systems. One implemented solution works with a kind of a BO of the
AP, specifically, the TecO ChangeDocument is directly called from outside.
The second implementation works with data from BW.
62
CHAPTER6
Final Remark
After the investigations, the gained results need to be discussed. Additionally,
the future of the FRODO project has to be outlined as well as ideas for further
investigations and further development.
6.1 Conclusion
In conclusion, accessing data from BO instances can be realized from outside
the AP. The working applications proof that AP is accessible from outside and
therewith, enterprise SOA successfully passed the validation mentioned in the
introduction (chapter 1), because SAP’s software architecture is ready for the
needs of ISVs and customers. Data can be retrieved from the AP using different
solutions (chapter 3.3.1). The most promising ones are implemented in simple
examples (chapter 4). The different technologies have their own characteristics
and thus, every solution has advantages and disadvantages. Before the very
first implementation were the numerous SAP technologies (chapter 2), each
with different data sources (chapter 3.2.1) and access methods (chapter 3.2.2).
Furthermore, the AP is still in development and therefore, AP is not ready
for projects like FRODO yet. It is comparable with Leonardo Da Vinci’s idea
of a helicopter. He even drafted that idea in detail, but the world and the
technology were not yet ready for such an ascent. Additionally, while creating
the thesis, many changes needed to be investigated. Projects like FRODO
always have low priority for colleagues involved in AP development, because
63
6.2. Outlook
they are necessarily more concerned with getting the AP running. Thus, the
initial focus of the thesis changed during the preparation. Focusing on the
implementation became less important, whereas attention was more and more
drawn on the different solutions and their possibilities.
6.2 Outlook
The focus of the FRODO project changed over the time, especially in the last
three weeks of preparing the thesis. For the next few months, investigations
will target on real-time fraud detection. The further development of FRODO
will draw attention on automating the steps, because FRODO still needs to
be supported with data manually. In order to become more user friendly, this
has to be changed. The usability will improve with further development effort
and the functionality will broaden. The generic BW solution in appendix C
should seriously be thought about as an object for another thesis.
Additionally, the implemented examples can also be used for projects with
other focuses. The examples show completely different ways of accessing data
from BO instances. The recommendations can be used for improving the
implementation of AP.
6.3 Further Questions & Recommendations
For further development, the question is if the two implemented solutions for
accessing data from AP are suitable for real-time fraud detection. Thus, the
question has to be answered, how real-time fraud detection can be realized.
On that matter, ideas exist on using the implementation to access the TecO
ChangeDocument via GCPs. For real-time detection repeating queries in
short periods is possible, because in this area real-time means reactions in
a time frame of one to five minutes. Another option would be to react on
event occurrences. Such events can rise either from ChangeDocument itself
or from a tool around ChangeDocument; PIM is recommended as the tool.
64
6.3. Further Questions & Recommendations
Additionally, another question is in which direction the development of the
TecO ChangeDocument will go, whether there will be new compound services
and a security concept for ChangeDocument or not. Another question aims
at the Generic BW solution (see appendix C), the potential of this solution
and if it can be used for real-time fraud detection.
65
CHAPTER7
Summary
FRODO is SAP’s research project targeting on the requirement for active fraud
detection in business systems. SAP stands at the beginning of a new software
era and thus, research projects have to be up-to-date. The task of the thesis
was to access data of BO instances from the AP.
The first step was to become familiar with the area of fraud and fraud detection;
understanding how the FRODO prototype works was indispensable. In order
to always have a reference, the example of fraud in SRM in connection with
MDM was introduced. Moreover, becoming acquainted with the different SAP
architectures and technologies was necessary. Thus, especially SAP NetWeaver
and the AP is introduced. Additionally, SAP BI was explained in general.
With the aim of finding good solutions for the implementations, a methodol-
ogy was developed and followed while investigating different solutions. The
first step was to identify data sources and access methods. Afterwards, the
combinations of both were investigated. While researching, different require-
ments were considered. The two most promising solutions, namely accessing
the TecO ChangeDocument using GCPs and accessing BW via XML/A were
concreted. The software was designed and implemented in small examples.
The two examples could be compared with each other and the results were
discussed. The working applications are the proof, that AP is also able to
provide data also for consumers from outside. Solving this problem created
significant effort due to the fact that AP is still in development. The new
66
SAP software architecture is not ready for projects like FRODO yet. Thus,
the topic provides more potential for interesting research and investigations.
Nonetheless enterprise SOA does ensure concepts for accessing the AP from
outside, like ISVs and customers will do in the future.
67
APPENDIXA
Why the Application Platform?
To understand the decisions for AP the new architecture should be shown from
the business point of view. Therefore, understanding the evolution of TP and
AP regarding the change from integration coding to business modeling (see
figure A.1) is necessary [Dit05].
Figure A.1: From former IT to Process Innovation Technology (based on [Dit05])
At the moment, the structure of application landscapes looks like the left di-
agram of figure A.1. SAP R/3 is also implemented according to this scheme.
Functional components are closed in packages and are hardwired to other sys-
tems. Hence, the process integration between different systems is hard coded
and thus they are inflexible. The User Interfaces (UI) are static objects placed
on top of the applications; the database is directly accessed by all components.
A - 1
All components are tight coupled to each other. In the future, software de-
velopment will be revolutionized by the new AP and the TP, which enable a
loose coupling of the components of a system.
AP is designed to build application solutions by service compositions and real-
izes that idea by the model-driven approach using services. Thus, SAP, ISVs,
and customers can implement new features and extend existing business pro-
cesses. Both platforms fulfill the SOA requirements and build the foundation
for SAP business solutions. The idea of AP is transferred from the automotive
industry. Today, many different car models are built with the same parts. For
instance in the Volkswagen group the different car types share up to 70 per-
cent of the parts, e.g. chassis and engines (figure A.2). The main difference is
the body of the cars. This saves a lot of money both in development and in
maintenance.
Figure A.2: Paradigm from Automotive Industry [FMW06]
More than 50 percent of the processes in SAP solutions are the same as well,
thus the paradigm from the automotive industry should be copied [FMW06].
With AP, the possibility is given to share parts which all solutions can use
together. Consequently, a final solution consists only of implementing the
body and connecting the single parts. The Invoicing functionality, for ex-
ample, is almost the same in Supply Chain Management systems, in Cus-
tomer Relationship Management systems and in Enterprise Resources Plan-
ning systems [SAP06f]. In the future AP will offer one Deployment Unit∗
(DU) Invoicing which is usable for any application, built on SAP NetWeaver
A - 2
and AP. With the TP and AP only, nothing will work because the content,
e.g. UI, composite applications and Analytics, are missing. The body based
on TP and AP plus customizing will represent the solution. Such bodies will
be created with a model-driven approach at lowest effort and time.
One of these bodies will be delivered with A1S. A1S is developed as a final
product for mid-size companies and has to deliver UI, composite applications
and Analytics. Composite applications consist of different functions of dif-
ferent sources, e.g. functionalities offered by the services. Thus, composite
applications are the predefined applications and the solution is ready with
individual configuration and small customizing effort. In order to influence
the process logic at one point only, the composite application and the UI of-
fer the possibility to arrange the different services. Analytics offers analytical
data concerning the business data and are embedded in the applications SAP
provides [XKS06].
Thus, software development is split into two parts, as the following graphic
(figure A.3) shows.
Figure A.3: Software Development in the Future [Red06]
There will be experts for developing new functionalities for the platform. In
detail, they will develop new Business Objects∗ (BOs) or will extend existing
ones. On the other side there will be developers for connecting business objects
to create composite applications as well as UIs.
A - 3
APPENDIXB
Process Integration Monitor
(PIM)
Another considered strategy for accessing data from BO instances of the AP
was the use of PIM, which is still a research project. PIM supports real-
time monitoring and enables exposing the actual process integration models
for various scenarios. Additionally, PIM compares them to the ARIS specified
process integration model for quality purpose. PIM enables the side-by-side
visualization of the A1S state and the ARIS model, which shows the actual flow
between DUs, PCs and BOs. Hence, the task of the monitor is to generate
representations of process integration maps for chosen business scenarios at
inter and intra DU level [SAP05].
PIM consists of two components the Monitor Observer and the Monitor Server.
It delivers an observer for every DU instance, which runs independently, scan-
ning for new interaction events. The observer also enables interaction event
queuing and is responsible for sending the events to the Monitor Server. The
server merges all posted events from the observers and notifies the front-end of
new events [SAP05]. PIM captures messages as well as LCP calls. Thus, it can
monitor all service calls whether they address core services or compound ser-
vices. Currently, PIM is still at the stage of development and the development
team is still experimenting with different ideas. One way is to use the ESF
trace, but this ESF feature has to be enabled in the system. Usually, the ESF
trace is switched off because it is very resource consuming. Thus, the developer
perform investigations on designing an own BO or using workflow events. The
A - 4
current implementation of PIM is based on the workflow solution.
Messages and LCP calls in general can be monitored and log files can be
built up for FRODO to use. Later, either an interface of the PIM core can
be used or the BO for PIM. But PIM recognizes only that an change event
happened, but cannot deliver data about the responsible action or user for
instance. Therefore, it is necessary to query the data in a second step. PIM
delivers some filter mechanisms and thus, the data volume and performance
would be acceptable, because it is a trade-off between event notification and
data retrieving. Additionally, the software effort is too huge to use this strat-
egy. Thus, the investigation stops after a shallow research.
Requirement EvaluationInformation about changes and historyData volume & PerformanceSoftware effortUsable for FRODO
Table B.1: Evaluation of Accessing Data Using PIM
Anyway, the experiences gained during developing PIM will help in finding
ways to access the given BO ChangeDocument without the existence of a com-
pound service. The developer tried different strategies but most of them were
too much of a hack and therefore do not conform to the AP model guidelines.
Additionally, PIM is under investigation for the real-time approach again, be-
cause event notification is important for that issue.
A - 5
APPENDIXC
Generic Data Warehouse
Solution
A generic solution for accessing data for detecting fraud is to be built according
to the following structure.
Figure C.1: Structure of a Generic Solution
The idea of the generic solution is to implement FRODO with an interface.
This interface follows a target structure. However, in one request only five
different fields are required, whereas in another request twelve fields are re-
quired. Therefore, the structure needs to be variable, because the size of the
requested database tables varies. Thus, the code of FRODO does not have to
be changed while connecting a new data source to FRODO. The target struc-
A - 6
ture should be flexible definable with something like a meta concept. This
enables FRODO to run simultaneously in different instances to solve different
fraud detections. In this case, the target structure has to be adjusted to the
data source. On the data source layer the system landscapes consist of differ-
ent databases and different data warehouses. Additionally, FRODO should be
able to work with flat files12. This heterogeneous situation must be mapped
to one target structure. Therefore, the data sources are described with single
descriptors. The descriptors are directly on top of the data sources and work
on this data directly. The effort of implementing a descriptor for every data
source can become a huge one. A solution for that problem will be the use of
meta data from the business logic layer to summarize some data sources. Thus,
the descriptors and the mapping layer are only responsible for the handshake
between data source and target structure. This offers the opportunity to map
the data to the target structure and FRODO is able to detect fraud with the
provided data.
This solution makes FRODO a generic fraud detection tool for every data
source. If a data source should be used, a descriptor has to be delivered.
This can be part of a customer’s tasks. A customer can also be an internal
department like SRM which would like to use fraud detection (solution idea
from Rene Roser).
This solution fulfills all requirements in an excellent way, except the software
effort. In detail the initial implementation effort is huge, but the solution is
very future-proof. Thus, a closer investigation is recommended, e.g. in another
thesis.
Requirement EvaluationInformation about changes and historyData volume & PerformanceSoftware effortUsable for FRODO
Table C.1: Evaluation of a Generic BW Solution
12 Flat file is a generic description of text file formats like CSV for instance. They areused to exchange data between systems in a simple structured way.
A - 7
APPENDIXD
Code for Accessing
ChangeDocument Using GCPs
Listing D.1: Main.java of XML/A Solution1 /*
2 * Access ChangeDocument via GCPs
3 */
4 import java.io.IOException;
5 import java.io.InputStream;
6 import java.util.Date;
7 import java.util.Locale;
8 import java.util.Properties;
9 import com.sap.dictionary.runtime.container .*;
10 import com.sap.tc.esf.cds.ConnectionData;
11 import com.sap.tc.esf.cds.ConnectionDataServiceFactory;
12 import com.sap.tc.esf.cds.IConnectionDataService;
13 import com.sap.tc.esf.gcp.api .*;
14 // import com.sap.tc.esf.test.refcase. ISalesOrder ;
15
16 /**
17 * This is a simple example to show , how is it possible to get data from
ChangeDocument .
18 * The connection settings are written down in single property files.
19 *
20 * Copyright (c)2006 SAP AG
21 *
22 * @author Nico Herzberg (D041659)
23 *
24 */
25
26 public class Main {
27
28 /**
29 * Main method
30 *
31 * @param args
A - 8
32 * Possible input parameters
33 */
34 public static void main(String [] args) {
35
36 // Get connection
37 ConnectionData connectionData = getConnectionData ();
38
39 // Get a service facade instance establishing a connection with a backend
system
40 IServiceFacade serviceFacade = null;
41 try {
42 serviceFacade = ServiceFacadeFactory.createServiceFacade(connectionData ,
new Locale("en"));
43 } catch (Exception e) {
44 e.printStackTrace ();
45 }
46
47 // Load the ChangeDocument BO model
48 IBOModel model = serviceFacade.getBOModel(IChangeDocument.ESR_NAME);
49
50 // Create a query
51 IQuery query = model.createQuery(IChangeDocument.Root.ESR_NAME.getFullName
(), IChangeDocument.Root.QUERY_QUERY_BY_BUSINESS_OBJECT_NAME_ANDID);
52 // Limit the number of results
53 query.setMaximumResultElements (5);
54 // Set query options
55 query.createSelectOption("ObjectTypeCode", ISelectOption.Operator.EQUAL , "
00001", null);
56 query.createSelectOption("ObjectId", ISelectOption.Operator.EQUAL , "00001"
, null);
57
58 // Execute Query
59 query.execute ();
60 // Get the results
61 IBONode node = query.getResultBONode ();
62
63 // Process input data
64 dumpBONode(node , IChangeDocument.Root.NAME + ": Only 5 records are
returned");
65
66 // Close connection to the backend system
67 serviceFacade.close ();
68
69 }
70
71 /**
72 * Method for getting connection data from the property file
73 *
74 * @return
75 * Data about the connection to one backend system
76 */
77 public static ConnectionData getConnectionData () {
78
79 // Get Connection Data Service and generic Connection Data
A - 9
80 IConnectionDataService cds = ConnectionDataServiceFactory.
getConnectionDataService ();
81 ConnectionData cd = cds.getConnectionData(ConnectionData.channelGeneric ,
ConnectionData.typeGeneric);
82
83 // Open property file
84 InputStream is = Class.class.getResourceAsStream("/AS1_connection.
properties");
85 Properties props = new Properties ();
86 try {
87 props.load(is);
88 is.close ();
89 } catch (IOException x) {
90 x.printStackTrace ();
91 }
92
93 // Add properties to the generic Connection Data
94 cd.putAll(props);
95
96 // Return Connection Data
97 return cd;
98 }
99
100 /**
101 * Method for handle the incoming data.
102 *
103 * @param boNode
104 * The business object node to be dumped
105 * @param text
106 * Description text of the dump
107 */
108 public static void dumpBONode(final IBONode boNode , final String text) {
109 System.out.println("\n" + text);
110
111 final int elementCount = boNode.size();
112 final int structSize = boNode.getDescriptor ().getDataStructure ().
getShallowStructureDescriptor ().size();
113 for (int i = 0; i < elementCount; i++) {
114 IBONodeElement element_i = boNode.getBONodeElement(i);
115 System.out.println ();
116 for (int j = 0; j < structSize; j++) {
117 System.out.println(" " + element_i.getDescriptor ().
getShallowAttributeDescriptor(j).getName () + ": "
118 + getContent(element_i.getAttributeValue(j)));
119 }
120 }
121
122 if (elementCount == 0) {
123 System.out.println(" no data available");
124 } else {
125 System.out.println("...............................");
126 System.out.println(" number of entries: " + elementCount);
127 }
128 }
A - 10
129
130 /**
131 * Get content for requested field
132 *
133 * @param value
134 * The descriptor of a field
135 * @return
136 * The value for the requested field
137 */
138 public static Object getContent(Object value) {
139 if (value instanceof ICctContainer) {
140 value = (( ICctContainer)value).getComponentValue("content");
141 }
142 return value;
143 }
144 }
A - 11
Lis
ting
D.2
:M
ain.
java
ofX
ML/A
Solu
tion
1import
com.sap.esi.esm.*;
2 3/**
4*
5*
Model
Descriptor
Interface
for
ChangeDocument.
6*
7*/
8public
interface
IChangeDocument
{
9String
NAMESPACE
="http://sap.com/xi/AP/IS/PlatformChangeDocument/Global";
10
String
NAME
="ChangeDocument";
11
IESRName
ESR_NAME
=ESRNameFactory.createESRName("ChangeDocument",
"http://sap.com/xi/AP/IS/PlatformChangeDocument/Global"
);
12
13
//
BO
Node
ChangeDocumentItem
14
interface
ChangeDocumentItem
{
15
String
NAME
="ChangeDocumentItem";
16
IESRName
ESR_NAME
=ESRNameFactory.createESRName("ChangeDocumentItem",
"");
17
//
IAssociation
ToRoot
18
String
ASSOCIATION_TO_ROOT
="ToRoot";
19
IESRName
ASSOCIATION_TO_ROOT_ESR
=ESRNameFactory.createESRName("ToRoot",
"");
20
//
IAssociation
ToParent
21
String
ASSOCIATION_TO_PARENT
="ToParent";
22
IESRName
ASSOCIATION_TO_PARENT_ESR
=ESRNameFactory.createESRName("ToParent",
"");
23
//
Query
QueryByNodeNameAndNodeID
24
String
QUERY_QUERY_BY_NODE_NAME_AND_NODEID
="QueryByNodeNameAndNodeID";
25
IESRName
QUERY_QUERY_BY_NODE_NAME_AND_NODEID_ESR
=ESRNameFactory.createESRName("QueryByNodeNameAndNodeID",
"");
26
IESRName
QUERY_QUERY_BY_NODE_NAME_AND_NODEID_INPUT_STRUCTURE_ESR
=ESRNameFactory.createESRName("
LineItemQueryInputParameter",
"http://sap.com/xi/AP/IS/PlatformChangeDocument/Global");
27
String
QUERY_QUERY_BY_NODE_NAME_AND_NODEID_BUSINESS_OBJECT_NODE_TYPE_CODE
="BusinessObjectNodeTypeCode";
28
String
QUERY_QUERY_BY_NODE_NAME_AND_NODEID_OBJECTID
="ObjectID";
29
String
QUERY_QUERY_BY_NODE_NAME_AND_NODEID_FROM_DATE_TIME
="FromDateTime";
30
String
QUERY_QUERY_BY_NODE_NAME_AND_NODEID_TO_DATE_TIME
="ToDateTime";
A - 12
31
//
Attribute
ChangeDocumentItemID(qualified
name,
esr
name)
32
String
_CHANGE_DOCUMENT_ITEMID_CCTS
="ChangeDocumentItemID";
33
IESRName
_CHANGE_DOCUMENT_ITEMID_CCTS_ESR
=ESRNameFactory.createESRName("ChangeDocumentItemID",
"");
34
//
Attribute
ObjectNodeTypeCode(qualified
name,
esr
name)
35
String
_OBJECT_NODE_TYPE_CODE_CCTS
="ObjectNodeTypeCode";
36
IESRName
_OBJECT_NODE_TYPE_CODE_CCTS_ESR
=ESRNameFactory.createESRName("ObjectNodeTypeCode",
"");
37
//
Attribute
BusinessObjectNodeFieldName(qualified
name,
esr
name)
38
String
_BUSINESS_OBJECT_NODE_FIELD_NAME_CCTS
="BusinessObjectNodeFieldName";
39
IESRName
_BUSINESS_OBJECT_NODE_FIELD_NAME_CCTS_ESR
=ESRNameFactory.createESRName("BusinessObjectNodeFieldName",
"");
40
//
Attribute
ObjectID(qualified
name,
esr
name)
41
String
_OBJECTID
="ObjectID";
42
IESRName
_OBJECTID_ESR
=ESRNameFactory.createESRName("ObjectID",
"");
43
//
Attribute
ParentObjectID(qualified
name,
esr
name)
44
String
_PARENT_OBJECTID
="ParentObjectID";
45
IESRName
_PARENT_OBJECTID_ESR
=ESRNameFactory.createESRName("ParentObjectID",
"");
46
//
Attribute
ModificationTypeCode(qualified
name,
esr
name)
47
String
_MODIFICATION_TYPE_CODE_CCTS
="ModificationTypeCode";
48
IESRName
_MODIFICATION_TYPE_CODE_CCTS_ESR
=ESRNameFactory.createESRName("ModificationTypeCode",
"");
49
//
Attribute
BusinessObjectElementOldContent(qualified
name,
esr
name)
50
String
_BUSINESS_OBJECT_ELEMENT_OLD_CONTENT_CCTS
="BusinessObjectElementOldContent";
51
IESRName
_BUSINESS_OBJECT_ELEMENT_OLD_CONTENT_CCTS_ESR
=ESRNameFactory.createESRName("BusinessObjectElementOldContent",
"
");
52
//
Attribute
BusinessObjectElementNewContent(qualified
name,
esr
name)
53
String
_BUSINESS_OBJECT_ELEMENT_NEW_CONTENT_CCTS
="BusinessObjectElementNewContent";
54
IESRName
_BUSINESS_OBJECT_ELEMENT_NEW_CONTENT_CCTS_ESR
=ESRNameFactory.createESRName("BusinessObjectElementNewContent",
"
");
55
//
Attribute
ChangeReasonText(qualified
name,
esr
name)
56
String
_CHANGE_REASON_TEXT_CCTS
="ChangeReasonText";
57
IESRName
_CHANGE_REASON_TEXT_CCTS_ESR
=ESRNameFactory.createESRName("ChangeReasonText",
"");
58
//
Attribute
AdditionalBusinessObjectInformation(qualified
name,
esr
name)
59
String
_ADDITIONAL_BUSINESS_OBJECT_INFORMATION_CCTS
="AdditionalBusinessObjectInformation";
60
IESRName
_ADDITIONAL_BUSINESS_OBJECT_INFORMATION_CCTS_ESR
=ESRNameFactory.createESRName("
AdditionalBusinessObjectInformation",
"");
A - 13
61
}
62
63
//
BO
Node
ChangeDocumentRecord
64
interface
ChangeDocumentRecord
{
65
String
NAME
="ChangeDocumentRecord";
66
IESRName
ESR_NAME
=ESRNameFactory.createESRName("ChangeDocumentRecord",
"");
67
//
IAssociation
ToRoot
68
String
ASSOCIATION_TO_ROOT
="ToRoot";
69
IESRName
ASSOCIATION_TO_ROOT_ESR
=ESRNameFactory.createESRName("ToRoot",
"");
70
//
IAssociation
ToParent
71
String
ASSOCIATION_TO_PARENT
="ToParent";
72
IESRName
ASSOCIATION_TO_PARENT_ESR
=ESRNameFactory.createESRName("ToParent",
"");
73
//
Query
QueryByBusinessObjectNameAndRootNodeID
74
String
QUERY_QUERY_BY_BUSINESS_OBJECT_NAME_AND_ROOT_NODEID
="QueryByBusinessObjectNameAndRootNodeID";
75
IESRName
QUERY_QUERY_BY_BUSINESS_OBJECT_NAME_AND_ROOT_NODEID_ESR
=ESRNameFactory.createESRName("
QueryByBusinessObjectNameAndRootNodeID",
"");
76
IESRName
QUERY_QUERY_BY_BUSINESS_OBJECT_NAME_AND_ROOT_NODEID_INPUT_STRUCTURE_ESR
=ESRNameFactory.createESRName("
ChangeDocumentRecordNodeQueryInputParameter",
"http://sap.com/xi/AP/IS/PlatformChangeDocument/Global");
77
String
QUERY_QUERY_BY_BUSINESS_OBJECT_NAME_AND_ROOT_NODEID_OBJECT_TYPE_CODE
="ObjectTypeCode";
78
String
QUERY_QUERY_BY_BUSINESS_OBJECT_NAME_AND_ROOT_NODEID_OBJECT_ID
="ObjectId";
79
String
QUERY_QUERY_BY_BUSINESS_OBJECT_NAME_AND_ROOT_NODEID_FROM_DATE_TIME
="FromDateTime";
80
String
QUERY_QUERY_BY_BUSINESS_OBJECT_NAME_AND_ROOT_NODEID_TO_DATE_TIME
="ToDateTime";
81
String
QUERY_QUERY_BY_BUSINESS_OBJECT_NAME_AND_ROOT_NODEID_USER_ACCOUNTID
="UserAccountID";
82
//
Attribute
CompleteNodeHierarchy(qualified
name,
esr
name)
83
String
_COMPLETE_NODE_HIERARCHY_CCTS
="CompleteNodeHierarchy";
84
IESRName
_COMPLETE_NODE_HIERARCHY_CCTS_ESR
=ESRNameFactory.createESRName("CompleteNodeHierarchy",
"");
85
//
Attribute
CompleteChangedAttributePath(qualified
name,
esr
name)
86
String
_COMPLETE_CHANGED_ATTRIBUTE_PATH_CCTS
="CompleteChangedAttributePath";
87
IESRName
_COMPLETE_CHANGED_ATTRIBUTE_PATH_CCTS_ESR
=ESRNameFactory.createESRName("CompleteChangedAttributePath",
"");
88
//
Attribute
BusinessObjectElementName(qualified
name,
esr
name)
89
String
_BUSINESS_OBJECT_ELEMENT_NAME_CCTS
="BusinessObjectElementName";
90
IESRName
_BUSINESS_OBJECT_ELEMENT_NAME_CCTS_ESR
=ESRNameFactory.createESRName("BusinessObjectElementName",
"");
91
//
Attribute
BusinessObjectElementNewContent(qualified
name,
esr
name)
A - 14
92
String
_BUSINESS_OBJECT_ELEMENT_NEW_CONTENT_CCTS
="BusinessObjectElementNewContent";
93
IESRName
_BUSINESS_OBJECT_ELEMENT_NEW_CONTENT_CCTS_ESR
=ESRNameFactory.createESRName("BusinessObjectElementNewContent",
"
");
94
//
Attribute
BusinessObjectElementOldContent(qualified
name,
esr
name)
95
String
_BUSINESS_OBJECT_ELEMENT_OLD_CONTENT_CCTS
="BusinessObjectElementOldContent";
96
IESRName
_BUSINESS_OBJECT_ELEMENT_OLD_CONTENT_CCTS_ESR
=ESRNameFactory.createESRName("BusinessObjectElementOldContent",
"
");
97
//
Attribute
UserAcountID(qualified
name,
esr
name)
98
String
_USER_ACOUNTID_CCTS
="UserAcountID";
99
IESRName
_USER_ACOUNTID_CCTS_ESR
=ESRNameFactory.createESRName("UserAcountID",
"");
100
//
Attribute
BusinessPartnerFormattedName(qualified
name,
esr
name)
101
String
_BUSINESS_PARTNER_FORMATTED_NAME_CCTS
="BusinessPartnerFormattedName";
102
IESRName
_BUSINESS_PARTNER_FORMATTED_NAME_CCTS_ESR
=ESRNameFactory.createESRName("BusinessPartnerFormattedName",
"");
103
//
Attribute
ChangeDateTime(qualified
name,
esr
name)
104
String
_CHANGE_DATE_TIME_CCTS
="ChangeDateTime";
105
IESRName
_CHANGE_DATE_TIME_CCTS_ESR
=ESRNameFactory.createESRName("ChangeDateTime",
"");
106
//
Attribute
ModificationTypeCode(qualified
name,
esr
name)
107
String
_MODIFICATION_TYPE_CODE_CCTS
="ModificationTypeCode";
108
IESRName
_MODIFICATION_TYPE_CODE_CCTS_ESR
=ESRNameFactory.createESRName("ModificationTypeCode",
"");
109
//
Attribute
ChangeReasonText(qualified
name,
esr
name)
110
String
_CHANGE_REASON_TEXT_CCTS
="ChangeReasonText";
111
IESRName
_CHANGE_REASON_TEXT_CCTS_ESR
=ESRNameFactory.createESRName("ChangeReasonText",
"");
112
//
Attribute
AdditionalBusinessObjectInformation1(qualified
name,
esr
name)
113
String
_ADDITIONAL_BUSINESS_OBJECT_INFORMATION1_CCTS
="AdditionalBusinessObjectInformation1";
114
IESRName
_ADDITIONAL_BUSINESS_OBJECT_INFORMATION1_CCTS_ESR
=ESRNameFactory.createESRName("
AdditionalBusinessObjectInformation1",
"");
115
//
Attribute
AdditionalBusinessObjectInformation2(qualified
name,
esr
name)
116
String
_ADDITIONAL_BUSINESS_OBJECT_INFORMATION2_CCTS
="AdditionalBusinessObjectInformation2";
117
IESRName
_ADDITIONAL_BUSINESS_OBJECT_INFORMATION2_CCTS_ESR
=ESRNameFactory.createESRName("
AdditionalBusinessObjectInformation2",
"");
118
//
Attribute
AdditionalBusinessObjectInformation3(qualified
name,
esr
name)
119
String
_ADDITIONAL_BUSINESS_OBJECT_INFORMATION3_CCTS
="AdditionalBusinessObjectInformation3";
120
IESRName
_ADDITIONAL_BUSINESS_OBJECT_INFORMATION3_CCTS_ESR
=ESRNameFactory.createESRName("
A - 15
AdditionalBusinessObjectInformation3",
"");
121
}
122
123
//
BO
Node
Root
124
interface
Root
{
125
String
NAME
="Root";
126
IESRName
ESR_NAME
=ESRNameFactory.createESRName("Root",
"");
127
//
IAssociation
UserIdentity
128
String
ASSOCIATION_USER_IDENTITY
="UserIdentity";
129
IESRName
ASSOCIATION_USER_IDENTITY_ESR
=ESRNameFactory.createESRName("UserIdentity",
"");
130
//
IAssociation
ChangeDocumentItem
131
String
ASSOCIATION_CHANGE_DOCUMENT_ITEM
="ChangeDocumentItem";
132
IESRName
ASSOCIATION_CHANGE_DOCUMENT_ITEM_ESR
=ESRNameFactory.createESRName("ChangeDocumentItem",
"");
133
//
IAssociation
ChangeDocumentRecord
134
String
ASSOCIATION_CHANGE_DOCUMENT_RECORD
="ChangeDocumentRecord";
135
IESRName
ASSOCIATION_CHANGE_DOCUMENT_RECORD_ESR
=ESRNameFactory.createESRName("ChangeDocumentRecord",
"");
136
//
Action
MoveToArchive
137
String
ACTION_MOVE_TO_ARCHIVE
="MoveToArchive";
138
IESRName
ACTION_MOVE_TO_ARCHIVE_ESR
=ESRNameFactory.createESRName("MoveToArchive",
"");
139
//
Action
CheckArchivability
140
String
ACTION_CHECK_ARCHIVABILITY
="CheckArchivability";
141
IESRName
ACTION_CHECK_ARCHIVABILITY_ESR
=ESRNameFactory.createESRName("CheckArchivability",
"");
142
//
Query
Archive
143
String
QUERY_ARCHIVE
="Archive";
144
IESRName
QUERY_ARCHIVE_ESR
=ESRNameFactory.createESRName("Archive",
"");
145
//
Query
ArchivePreSelection
146
String
QUERY_ARCHIVE_PRE_SELECTION
="ArchivePreSelection";
147
IESRName
QUERY_ARCHIVE_PRE_SELECTION_ESR
=ESRNameFactory.createESRName("ArchivePreSelection",
"");
148
//
Query
QueryByBusinessObjectNameAndID
149
String
QUERY_QUERY_BY_BUSINESS_OBJECT_NAME_ANDID
="QueryByBusinessObjectNameAndID";
150
IESRName
QUERY_QUERY_BY_BUSINESS_OBJECT_NAME_ANDID_ESR
=ESRNameFactory.createESRName("QueryByBusinessObjectNameAndID",
""
);
151
IESRName
QUERY_QUERY_BY_BUSINESS_OBJECT_NAME_ANDID_INPUT_STRUCTURE_ESR
=ESRNameFactory.createESRName("
A - 16
RootNodeQueryInputParameter",
"http://sap.com/xi/AP/IS/PlatformChangeDocument/Global");
152
String
QUERY_QUERY_BY_BUSINESS_OBJECT_NAME_ANDID_OBJECT_TYPE_CODE
="ObjectTypeCode";
153
String
QUERY_QUERY_BY_BUSINESS_OBJECT_NAME_ANDID_OBJECT_ID
="ObjectId";
154
String
QUERY_QUERY_BY_BUSINESS_OBJECT_NAME_ANDID_FROM_DATE_TIME
="FromDateTime";
155
String
QUERY_QUERY_BY_BUSINESS_OBJECT_NAME_ANDID_TO_DATE_TIME
="ToDateTime";
156
String
QUERY_QUERY_BY_BUSINESS_OBJECT_NAME_ANDID_USER_IDENTITYUUID
="UserIdentityUUID";
157
//
Attribute
ChangeDocumentID(qualified
name,
esr
name)
158
String
_CHANGE_DOCUMENTID_CCTS
="ChangeDocumentID";
159
IESRName
_CHANGE_DOCUMENTID_CCTS_ESR
=ESRNameFactory.createESRName("ChangeDocumentID",
"");
160
//
Attribute
ObjectTypeCode(qualified
name,
esr
name)
161
String
_OBJECT_TYPE_CODE_CCTS
="ObjectTypeCode";
162
IESRName
_OBJECT_TYPE_CODE_CCTS_ESR
=ESRNameFactory.createESRName("ObjectTypeCode",
"");
163
//
Attribute
BusinessObjectRootObjectID(qualified
name,
esr
name)
164
String
_BUSINESS_OBJECT_ROOT_OBJECTID
="BusinessObjectRootObjectID";
165
IESRName
_BUSINESS_OBJECT_ROOT_OBJECTID_ESR
=ESRNameFactory.createESRName("BusinessObjectRootObjectID",
"");
166
//
Attribute
UserIdentityUUID(qualified
name,
esr
name)
167
String
_USER_IDENTITYUUID_CCTS
="UserIdentityUUID";
168
IESRName
_USER_IDENTITYUUID_CCTS_ESR
=ESRNameFactory.createESRName("UserIdentityUUID",
"");
169
//
Attribute
ChangeDateTime(qualified
name,
esr
name)
170
String
_CHANGE_DATE_TIME_CCTS
="ChangeDateTime";
171
IESRName
_CHANGE_DATE_TIME_CCTS_ESR
=ESRNameFactory.createESRName("ChangeDateTime",
"");
172
//
Attribute
TransactionID(qualified
name,
esr
name)
173
String
_TRANSACTIONID_CCTS
="TransactionID";
174
IESRName
_TRANSACTIONID_CCTS_ESR
=ESRNameFactory.createESRName("TransactionID",
"");
175
//
Attribute
SystemNumber(qualified
name,
esr
name)
176
String
_SYSTEM_NUMBER_CCTS
="SystemNumber";
177
IESRName
_SYSTEM_NUMBER_CCTS_ESR
=ESRNameFactory.createESRName("SystemNumber",
"");
178
//
Attribute
ArchivingStatus(qualified
name,
esr
name)
179
String
_ARCHIVING_STATUS
="ArchivingStatus";
180
IESRName
_ARCHIVING_STATUS_ESR
=ESRNameFactory.createESRName("ArchivingStatus",
"");
181
}
182
}
A - 17
APPENDIXE
Code for Accessing BW Using
XML for Analysis
Listing E.1: Main.java of XML/A Solution1 /*
2 * Call BW data by Using XML/A interface of the MDX processor
3 */
4
5 import java.net .*;
6 import java.io.FileInputStream;
7 import java.io.InputStreamReader;
8 import java.io.OutputStreamWriter;
9 import java.io.BufferedReader;
10 import java.io.File;
11 import java.util.Properties;
12
13 import java.util.Date;
14
15 /**
16 * This is a simple example to show , how is it possible to get data from BW.
In this
17 * case the query language MDX is used. The connection settings are written
down in the file
18 * properties .ini
19 *
20 * Copyright (c)2006 SAP AG
21 *
22 * @author Nico Herzberg (D041659)
23 *
24 */
25
26 public class Main {
27
28 /**
29 * Main method
30 *
A - 18
31 * @param args
32 * Possible input parameters
33 */
34 public static void main(String [] args) {
35
36 // Definiton of the MDX Statement
37 String MDXstatement = new String ();
38 MDXstatement = "select [Measures ]. members on columns , non empty [0 VC_COUN
]. levels (1).members * [0 VC_REG ]. levels (1).members dimension
properties member_name , member_caption on rows from [$0BWVC_C03]
where ([0 FISCYEAR ].[ K41999 ])";
39
40 // Call method connect and provide MDX statement
41 connect(MDXstatement);
42 }
43
44 /**
45 * Method for connecting to the MDX processor and sending the SOAP request
and handle the response
46 *
47 * @param MDXstatement
48 * Statement for query relevant data from BW
49 */
50 public static void connect (String MDXstatement){
51
52 // Build up the SOAP Request
53 String data = createSOAPRequest(MDXstatement);
54
55 // Create and send request
56 try{
57 // Build up the URL
58 URL url = new URL(readproperties("connectionString"));
59 // Set up the connection
60 URLConnection conn = url.openConnection ();
61
62 // Add user
63 conn.setRequestProperty("sap -user",readproperties("user"));
64 // Add password
65 conn.setRequestProperty("sap -password",readproperties("password"));
66 // Add property Accept -Encoding
67 conn.setRequestProperty("Accept -Encoding","gzip , compress");
68
69 // Connection requires output
70 conn.setDoOutput(true);
71 // Connect to the URL
72 conn.connect ();
73
74 // Define OutputStream
75 OutputStreamWriter wr = new OutputStreamWriter(conn.getOutputStream ())
;
76 // Send SOAP request to the server
77 wr.write(data);
78 wr.flush();
79
A - 19
80 // Get response
81 BufferedReader rd = new BufferedReader(new InputStreamReader(conn.
getInputStream ()));
82 // Variable for reading input
83 String line;
84 // Reading input
85 while ((line = rd.readLine ()) != null) {
86 System.out.println(line);
87 }
88 // Close writer and reader
89 wr.close();
90 rd.close();
91 } catch (Exception e){
92 System.out.println("Error while connecting to backend system");
93 }
94 }
95
96 /**
97 * Method for reading the property file
98 *
99 * @param field
100 * Parameter for defining which property is required
101 * @return
102 * The value of the requested property , in case of connectionString
the whole URL
103 */
104 public static String readproperties(String field){
105
106 // Open property file
107 Properties prop = new Properties ();
108 File file = new File("C:// Documents and Settings // d041659 // workspace //MDX
//src// properties.ini");
109 String property = new String ();
110
111 // Read relevant data for connection string and build it up
112 if (field .equalsIgnoreCase("connectionString"))
113 {
114 prop.clear ();
115 try {
116 FileInputStream in = new FileInputStream(file.getAbsolutePath ());
117 prop.load(in);
118 in.close();
119 } catch (Exception e) {
120 System.out.println("Error while loading property file");
121 }
122 property = "http ://" + prop.getProperty("host")+":"+prop.getProperty("
port")+"/sap/bw/xml/soap/xmla"+"?sap -client="+prop.getProperty("
client");
123 }
124
125 // Read user
126 if (field .equalsIgnoreCase("user"))
127 {
128 prop.clear ();
A - 20
129 try {
130 FileInputStream in = new FileInputStream(file.getAbsolutePath ());
131 prop.load(in);
132 in.close();
133 } catch (Exception e) {
134 System.out.println("Error while loading property file");
135 }
136 property = prop.getProperty("user");
137 }
138
139 // Read password
140 if (field .equalsIgnoreCase("password"))
141 {
142 prop.clear ();
143 try {
144 FileInputStream in = new FileInputStream(file.getAbsolutePath ());
145 prop.load(in);
146 in.close();
147 } catch (Exception e) {
148 System.out.println("Error while loading property file");
149 }
150 property = prop.getProperty("passwd");
151 }
152
153 // Return requested property
154 return property;
155 }
156
157 /**
158 * Method for creating the SOAP Request with the MDX statement
159 *
160 * @param MDXstatement
161 * Statement for Query the relevant data from BW
162 * @return
163 * The SOAP response
164 */
165 public static String createSOAPRequest(String MDXstatement){
166
167 String request = new String ();
168
169 request = "<SOAP -ENV:Envelope "
170 + " xmlns:SOAP -ENV=’http :// schemas.xmlsoap.org/soap/envelope/’"
171 + " SOAP -ENV:encodingStyle=’http :// schemas.xmlsoap.org/soap/encoding
/’>"
172 + " <SOAP -ENV:Body >"
173 + " <Execute xmlns=’urn:schemas -microsoft -com:xml -analysis ’"
174 + " SOAP -ENV:encodingStyle=’http :// schemas.xmlsoap.org/soap/encoding
/’>"
175 + " <Command >"
176 + " <Statement >"
177 + MDXstatement
178 + " </Statement >"
179 + " </Command >"
180 + " <Properties >"
A - 21
181 + " <PropertyList >"
182 + " <DataSourceInfo >default </ DataSourceInfo >"
183 + " <Catalog >Foodmart 2000 </ Catalog >"
184 + " <Format >Tabular </Format >"
185 + " <ReturnCellProperties >true </ ReturnCellProperties >"
186 + " <AxisFormat >TupleFormat </ AxisFormat >"
187 + " <Content >SchemaData </Content >"
188 + " </PropertyList >"
189 + " </Properties >"
190 + " </Execute >"
191 + " </SOAP -ENV:Body >"
192 + " </SOAP -ENV:Envelope >";
193
194 return request;
195 }
196 }
A - 22
APPENDIXF
Contacts
While working on the thesis expertise were identified and contacts are tied. For
further work on the FRODO project the different contacts are listed in the next
table. Additionally, some comments to the people are written down. Thus,
similar problems can be addressed in future to the right people directly.
A - 23
Know
ledge
Fie
ldSurn
ame
Fir
stnam
eU
ser
IDFunct
ion
Com
men
ts
Fra
ud
Vay
ssie
reJu
lien
I028
859
Seni
orR
esea
rche
rP
roje
ctle
adFR
OD
O
Vos
sN
oelle
D04
0491
PLM
Con
sult
ant
Aut
hor
ofth
esis
“Con
cept
ion
and
anal
ysis
ofm
etho
dsfo
rde
tect
ing
and
prev
enti
ngof
invo
ice
frau
din
SRM
”
Fra
ud
De-
tect
ion
Vay
ssie
reJu
lien
I028
859
Seni
orR
esea
rche
rP
roje
ctle
adFR
OD
O
SR
MSa
laPao
laD
0204
22D
evel
opm
ent
Man
ager
AP
/SR
MIn
volv
edin
proj
ect
“Fra
udD
etec
tion
inSR
M”
Rei
ner
Rob
ert
D02
3473
Dev
elop
erA
P/S
RM
Invo
lved
inpr
ojec
t“F
raud
Det
ecti
onin
SRM
”
Hoc
hwar
thPas
cal
D03
1154
Dev
elop
erA
P/S
RM
Invo
lved
inpr
ojec
t“F
raud
Det
ecti
onin
SRM
”
Wol
lny
Step
han
D04
0407
Dev
elop
erA
P/S
RM
Invo
lved
inpr
ojec
t“F
raud
Det
ecti
onin
SRM
”
Vos
sN
oelle
D04
0491
PLM
Con
sult
ant
Aut
hor
ofth
esis
“Con
cept
ion
and
anal
ysis
ofm
etho
dsfo
rde
tect
ing
and
prev
enti
ngof
invo
ice
frau
din
SRM
”
AR
ISH
ochw
arth
Pas
cal
D03
1154
Dev
elop
erA
P/S
RM
Invo
lved
inpr
ojec
t“F
raud
Det
ecti
onin
SRM
”
AP
Schm
itt
Mat
thia
sD
0273
13D
evel
oper
AP
Mas
ter
Dat
a
Sadi
qW
asim
I025
248
Seni
orR
esea
rche
r
A - 24
Wol
lny
Step
han
D04
0407
Dev
elop
erA
P/S
RM
Invo
lved
inpr
ojec
t“F
raud
Det
ecti
onin
SRM
”
XI
Bun
dsch
uhA
lexa
nder
I028
930
Kno
wle
dge
Tra
nsfe
rX
IR
IGA
PA
Klin
glFr
ank
D02
9075
Con
sult
ant
XI
Pla
tfor
mC
han
geD
ocu
men
ts
Pie
lka
Kai
-Uw
eD
0026
71P
MP
CD
Mei
er-B
arth
old
Dir
kD
0260
48So
luti
onM
anag
emen
tP
CD
Gue
nthe
rM
arti
nD
0263
69So
luti
onM
anag
emen
tP
CD
Ana
lysi
s,pr
epar
atio
nan
dvi
sual
izat
ion
ofda
tafo
rau
dito
rs
Hup
pert
And
reas
D02
0682
Solu
tion
Arc
hite
ctP
CD
Kri
shna
moo
rthy
Raj
aI0
2237
4D
evel
opm
ent
Man
ager
PC
D
GC
PK
aise
rJe
nsD
0415
07D
evel
oper
ESI
Cor
eE
SF
Kra
iss
Ach
imD
0380
15D
evel
opm
ent
Man
ager
ESI
Cor
eE
SF
Wel
zel
Oliv
erD
0248
17D
evel
oper
Man
ager
ESI
Cor
eE
SF
Rit
ter
Step
han
D02
0760
Dev
elop
men
tE
SIU
IA
utho
r“S
peci
ficat
ion
ESF
Gen
eric
Con
-su
mer
Pro
xy”
Mue
ller
Hel
mut
D02
2323
Dev
elop
erE
SIU
IA
utho
r“S
peci
ficat
ion
ESF
Gen
eric
Con
-su
mer
Pro
xy”
Rog
geM
arti
nD
0218
62D
evel
oper
Org
Man
agem
ent
Hoc
hwar
thPas
cal
D03
1154
Dev
elop
erA
P/S
RM
Invo
lved
inpr
ojec
t“F
raud
Det
ecti
onin
SRM
”
Ser
vic
esB
ende
rJo
achi
mD
0200
94D
evel
opm
entM
anag
erE
SIToo
ls
A - 25
ESR
Jaco
biA
nne
D03
0735
Dev
elop
erE
SIC
ore
ESX
GD
TB
ross
ler
And
reas
D03
3985
Dev
elop
erA
P/S
RM
Ser
vic
eIn
terf
aces
Scho
ttV
olke
rD
0293
52D
evel
oper
AP
Haf
ner
Sasc
haD
0325
48D
evel
oper
AP
/FIN
/HC
M
AB
AP
Jaco
biA
nne
D03
0735
Dev
elop
erE
SIC
ore
ESX
LC
PW
olln
ySt
epha
nD
0404
07D
evel
oper
AP
/SR
MIn
volv
edin
proj
ect
“Fra
udD
etec
tion
inSR
M”
Har
tig
Mar
tin
D03
0326
Dev
elop
erE
SIC
ore
ESF
Java
Jagu
sch
And
reD
0384
06D
evel
oper
ESI
Too
lsSp
ecia
list
for
Java
Clie
ntP
roxy
gene
rati
on
BW
Ros
erR
ene
D03
9585
Dev
elop
erA
naly
tics
Spec
ialis
tfo
rB
I,B
Wan
dA
naly
tics
Tra
nSa
nD
0311
82D
evel
oper
SRM
BW
Spec
ialis
t
Hoe
risc
hM
icha
elD
0256
71K
now
ledg
eTra
nsfe
rB
IN
WR
IGE
ME
A,
Spec
ialis
tfo
rB
IO
pen
Hub
Serv
ice
Ulm
erC
edri
cI0
2404
8R
esea
rche
rP
roje
ctw
ith
BW
XM
L/A
Bie
dens
tein
Stef
anD
0274
64D
evel
oper
BI
Schn
eide
rC
arin
aD
0417
59St
uden
tA
P/S
RM
Invo
lved
inpr
ojec
t“F
raud
Det
ecti
onin
SRM
”
Schu
man
nR
olf
D03
8903
Dev
elop
erA
P/S
RM
BIA
ccel
er-
ator
Pet
erA
lexa
nder
D02
4877
PM
OB
I
Anal
ytics
Ros
erR
ene
D03
9585
Dev
elop
erA
naly
tics
Spec
ialis
tfo
rB
I,B
Wan
dA
naly
tics
Sori
ngH
elge
D02
9621
BI
Con
tent
Dev
elop
men
t
A - 26
Deg
beon
Mic
hael
aD
0272
19B
IC
onte
ntD
evel
opm
ent
Poo
nen
Sanj
ayI8
1046
1SV
PA
naly
tics
PIM
Sadi
qW
asim
I025
248
Seni
orR
esea
rche
r
Avi
tzur
Aha
ron
I031
688
Dev
elop
erA
P/S
CM
Tab
leF.1
:SA
PC
onta
cts
A - 27
Figure F.1: Contact Mind Map
A - 28
Glossary
ABAP
ABAP is a programming language, developed by SAP.
Analytics
Analytics is embedded in applications and offers analytical data concern-
ing to business data.
Application Platform (AP)
The AP is build on top of SAP NetWeaver and is designed to build
application solutions by service compositions to follow a model-driven
approach by using these services.
ARIS
ARIS based on the ARIS concept and is a toolset provided by IDS Scheer
AG for creating, maintaining and optimizing business processes.
Audit Information System (AIS)
The Audit Information System is a tool which supports internal, external
and tax audits as well as data security by offering different views on
financial data on SAP’s databases.
Business Information Warehouse (BW)
SAP BW is a component of BI and is SAP’s data warehouse product.
XVIII
Glossary
Business Object (BO)
BOs build the basic elements of business applications. They contain
business logic and implement the main service providers.
Composite application
Composite applications are predefined applications which use functions
of several services.
Compound services
Compound services work internally with core services and allow the ac-
cess of BOs from outside of DUs.
Core services
Core services access BOs directly and provide for that generic functions.
They can be called via LCPs and GCPs.
Deployment Unit (DU)
DUs are building blocks of the AP which contains PCs and/or BOs.
Enterprise services
Enterprise services are compound services which are used in a business
process.
Enterprise Services Repository (ESR)
The ESR is the interface between SAP internal and external applications
and provides them descriptions about the services.
Enterprise SOA
Enterprise SOA is SAP’s implementation of the system architecture con-
cept SOA.
XIX
Glossary
Extensible Markup Language (XML)
XML is a W3C standard for building up documents with a tree structure.
Financials (FI)
FI is responsible for the accounting of a company.
FRODO
FRODO means either the software prototype for detecting financial fraud
or the name of the SAP Research project.
Generic Core Service Consumer Proxy (GCP)
GCPs enable Java applications to call core services from outside the DU
by using RFCs or SOAP. The former term for GCP was Generic Client
Proxy.
Integration Builder
The Integration Builder is a tool for setting up the SAP XI.
Local Client Proxy (LCP)
With LCPs is it possible to call the core services of a BO from inside of
the same DU.
Master Data Management (MDM)
MDM is the business area which is responsible for the central manage-
ment of master data.
Multidimensional Expressions (MDX)
MDX is a query language for databases, developed by Microsoft.
XX
Glossary
mySAP All-In-One/Service-Enabled (A1S)
A1S is the new business solution for mid-size enterprises and the first
one which uses the AP.
Platform Change Documents
Platform Change Documents contain information about the change of
BO instances. They are created by the TecO ChangeDocument.
Process Component (PC)
PCs are building blocks of the AP and can group BOs in business-relevant
and meaningful units.
R/3
SAP R/3 is an enterprise information system which exists since 1992. A
R/3 system allows the computer aided handling of typical business tasks.
Remote Function Call
RFCs enable function calls of R/3 building blocks from external appli-
cations.
Resource Description Framework (RDF)
RDF is a formal language for providing meta data in the World Wide
Web.
SAP Business Intelligence (BI)
SAP Business Intelligence is a system based on SAP NetWeaver for sys-
tematical analysis of enterprises and their environment.
SAP NetWeaver
XXI
Glossary
NetWeaver is SAP’s technology platform based on enterprise SOA for
integrating heterogeneous systems and building up a business process
platform.
Service-Oriented Architecture (SOA)
SOA is on the one hand a management concept which demands for a
business oriented IT infrastructure. On the other hand SOA is a system
architecture concept for providing services.
SOAP
SOAP is a protocol for exchanging information between different systems
or executing RFCs.
Supplier Relationship Management (SRM)
SRM is the business area for plan and control relationships with suppliers.
Technical Object (TecO)
Technical Objects are special BOs for supporting the technical infras-
tructure or IT Service and Application Management of AP.
Web Dynpro
Web Dynpro is SAP’s standard programming model for implementing
UIs. It follows the Model View Controller design pattern.
Web Services Description Language (WSDL)
WSDL is a XML specification for describing web services to exchange
information. WSDL is independent from any platforms, programming
languages and protocols.
XML for Analysis (XML/A)
XXII
Glossary
XML/A is a protocol for exchanging data between clients and server over
HTTP and SOAP.
XXIII
Bibliography
[BM06] Michael Bell and Eric A. Marks. Service-Oriented Architecture: A
Planning and Implementation Guide for Business and Technology.
John Wiley & Sons, 2006.
[Dit05] Georg Dittmar. Adaptive Computing - Technical Overview. 2005.
[Ebe04] Peter Eberlein. Synchronous Cross Component Communication.
2004.
[FMW06] Thomas Fiedler, Holger Meinert, and Volker Wiechers. Services.
ESA Architecture Series 2006. February 2006. Available via SAP
Corporate Portal – Product & Technology Group – Architecture –
Media Library – ESA Architecture Series.
[ILK06] Tahar Wl Idrissi-Lamghari and Hartmut Koerner. Analytics. ESA
Architecture Series 2006. February 2006. Available via SAP Corpo-
rate Portal – Product & Technology Group – Architecture – Media
Library – ESA Architecture Series.
[Kay03] Doug Kaye. Loosely Coupled - The Missing Pieces of Web Services.
RDS Press, 2003.
[KPM04] KPMG. Fraud Survey 2004, 2004. Available via
http://www.kpmg.com.au/.
[KPM06] KPMG. Studie 2006 zur Wirschaftskriminalitat in Deutschland,
2006. Available via http://www.kpmg.de/.
[MBCV06] George Mohey, Peter Best, Andrew Clark, and Julien Vayssiere.
Australian research council - linkage projects (round two) - applica-
XXIV
Bibliography
tion form for funding commencing in 2006 - project id: Lp0669644,
2006.
[Onl06] Online Ethics Center for Engineering and Science. Onlineethics.org
- The Online Ethics Center For Engineering and Science at Case
Western Reserve University. August 2006.
[PKVC06] Kai-Uwe Pielka, Raja Krishnamoorthy, Kritesh Vasing, and
Sumana Chakraborty. AP Development Guideline for: Platform
Change Documents, April 2006.
[Red06] Michael Redford. BPP: Da ist musik drin. SAP News, February
2006.
[RWK06] Robert Reiner, Andre Wagner, and Benjamin Klehr. SAP Business
Object: SupplierInvoice, May 2006.
[SAP04] SAP AG. BW305 - Business Information Warehouse - Reporting
und Analyse, 2004.
[SAP05] SAP AG. Software Design Description - Process Integration Moni-
tor, 2005.
[SAP06a] SAP AG. MDX as basis for the interfaces, September 2006. Avail-
able via http://help.sap.com/saphelp nw04/helpdata/en/start.htm
– SAP Library – SAP NetWeaver – Information Integration – SAP
Business Information Warehouse – Additional Development Tech-
nologies – Open Analysis Interfaces.
[SAP06b] SAP AG. PIC council. Available via SAP Corporate Portal, August
2006.
[SAP06c] SAP AG. SAP NetWeaver as a ‘Business Process Platform’, Febru-
ary 2006.
[SAP06d] SAP AG. Unit 1: Architecture overview. Application Platform
Architecture Basics. July 2006. Available via SAP Corporate Por-
tal – Application Platform – Knowledge Transfer – Architecture
XXV
Bibliography
Knowledge Transfer – AP Architecture Overview – Link to PPT
presentations.
[SAP06e] SAP AG. Unit 4: Services. Application Platform Architecture Ba-
sics. July 2006. Available via SAP Corporate Portal – Application
Platform – Knowledge Transfer – Architecture Knowledge Transfer
– AP Architecture Overview – Link to PPT presentations.
[SAP06f] SAP TV. What is BPP? Video available via
http://directbeam:1080/noauth Inside What is BPP e 4204.asx,
2006.
[Str05] Uwe Stromberg. SAP Business Object Template: Business Partner,
May 2005.
[Vay06] Julien Vayssiere. Fraud Detection at SAP Research, 2006.
[Wik06a] Wikipedia. Business-intelligence. Available via
http://de.wikipedia.org/wiki/Business Intelligence, August 2006.
[Wik06b] Wikipedia. Enron. Available via
http://de.wikipedia.org/wiki/Enron, August 2006.
[Wik06c] Wikipedia. MCI worldcom. Available via
http://de.wikipedia.org/wiki/WorldCom, August 2006.
[Wik06d] Wikipedia. Sarbanes-Oxley Act. Available via
http://de.wikipedia.org/wiki/SOX, August 2006.
[Wik06e] Wikipedia. Serviceorientierte Architektur. Available via
http://de.wikipedia.org/wiki/Serviceorientierte Architektur, Au-
gust 2006.
[Wol05] Stephan Wollny. Implementation of the business object ‘Suppli-
erInvoice’ and its services according to the enterprise services ar-
chitecture. Master’s thesis, University of Cooperative Education
Mannheim, March 2005.
XXVI
Bibliography
[XKS06] XU Product Architecture, Knowledge Transfer, and SAP AG. The
big picture. ESA Architecture Series 2006. February 2006. Avail-
able via SAP Corporate Portal – Product & Technology Group –
Architecture – Media Library – ESA Architecture Series.
XXVII
Statement of Academic
Honesty
“Hereby, I declare:
• That the diploma thesis on hand with the topic ‘Detecting Fraud Patterns
using data obtained from the Application Platform’ was created without
any help of a third party.
• That directly or indirectly used thoughts of third party sources are high-
lighted in the according places within the document
• That the diploma thesis was not submitted to any other university or
published in the past. I am aware, that a dishonest statement will have
legal consequences.”
Brisbane, 08.09.2006 Signature:
XXVIII