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 Herzberg
Matr.-Nr. 122492
September 2006
Duration
Course
Company
Company Supervisor
University Supervisor
3 months
TIT03VNS
SAP AG
Walldorf
Dr. Julien Vayssière
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 Vayssière
University Supervisor Prof. Dr. Heinrich Braun
written by
Nico Herzberg
Matr.-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 SarbanesOxley act, and also because, in many business areas, software is replacing humans 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 Application 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 Technical 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 gehört heute zu den Anforderungen von Kunden an SAP Systeme. Dies fundiert erstens auf neuen Gesetzgebungen, 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
Geschäftsprozessen verdrängt. 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. Relevante Daten sind in den Business Objekten selbst und im Technischen Objekt
ChangeDocument verfügbar. Als Zugriffsmethoden sind Core und Compound
Services, sowie das Business Information Warehouse und ein eigenes FRODO
Business Objekt identifiziert. Die Untersuchungen zielen auf die Möglichkeit,
auf Daten der Application Platform“ von außen zugreifen und damit Be”
trugserkennung gewährleisten zu können. Um die besten Lösungen identifizieren zu können, wurde ein Vorgehensmodell entwickelt und während der
Untersuchung verwendet. Die Strategien Zugriff auf ChangeDocument über
”
Core Services“ und Zugriff auf Business Objekt Daten über das Business In”
formation Warehouse unter Verwendung von XML for Analysis“ sind in Java
implementiert, um sie besser bewerten zu können. Auf Basis der Programme
können diverse Diskussionen geführt werden. Der Vergleich zum R/3 FRODO
Prototypen zeigt im Moment keine Verbesserung auf, da in allen Lösungen die
Daten per Hand extrahiert werden müssen.
Folglich bestehen noch viele offene Fragen, Probleme und neue Ideen. Der
Fokus von FRODO wird in Zukunft auf Betrugserkennung in Echtzeit zielen.
Für diese Anforderung müssen 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 Information 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 Vayssière for great supervision and good teamwork during the
further development of the prototype
• Prof. Dr. Heinrich Braun for supervising me excellently as the representative 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 Möckel and Philip Crow for checking the language
• My girlfriend Doreen Seifert and my family for supporting me and keeping 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
4.2
4.2.1
4.2.2
4.2.3
Test . . . . . . . . . .
Receiving BW Data of
Design . . . . . . . . .
Implementation . . . .
Test . . . . . . . . . .
. . . . . . . . . . . . . . . . .
BOs Using XML for Analysis
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
.
.
.
.
.
52
53
53
55
57
5
5.1
5.2
Validation
Validation of Test Results . . . . . . . . . . . . . . . . . . . . .
Comparison to the R/3 Solution . . . . . . . . . . . . . . . . .
60
60
62
6
6.1
6.2
6.3
Final Remark
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Further Questions & Recommendations . . . . . . . . . . . . .
63
63
64
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 Platform [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
3.2
3.3
3.4
3.5
3.6
3.7
Evaluation of Solutions . . . . . . . . . . . . . . . . . . . . . . .
Meaning of the Evaluation Symbols . . . . . . . . . . . . . . . .
Evaluation of Accessing BO Data Using Core Services . . . . . .
Evaluation of Accessing BO Data Using Compound Services . .
Evaluation of Accessing Data Using SAP BW on BO Data . . .
Evaluation of Accessing ChangeDocument Using Core Services .
Evaluation of Accessing ChangeDocument Using Compound Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.8 Evaluation of Accessing Data Using SAP BW on ChangeDocument
Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.9 Summary of all Strategies . . . . . . . . . . . . . . . . . . . . . .
32
39
39
40
42
42
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
43
44
45
Listings
2.1
2.2
3.1
3.2
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
D.1
D.2
E.1
Rules written in Jena Rules Language [Vay06] . . . . . .
Colloquial Rules [Vay06] . . . . . . . . . . . . . . . . . .
LCP Call of a BO Core Service in ABAP . . . . . . . . .
GCP Call of a BO Core Service . . . . . . . . . . . . . .
Structure of Connection Property File for Using GCP . .
Connection to the AP . . . . . . . . . . . . . . . . . . .
Section from BO Model Interface IChangeDocument.java
Code for Query Creation and Data Receiving . . . . . .
Response to SalesOrder Query . . . . . . . . . . . . . . .
SOAP Request to BI System . . . . . . . . . . . . . . . .
Property File for Connection to a BI System . . . . . . .
Connection and Data Sending in XML/A solution . . . .
Reference Data Structured in XML . . . . . . . . . . . .
SOAP Response of the BI System . . . . . . . . . . . . .
Main.java of XML/A Solution . . . . . . . . . . . . . . .
Main.java of XML/A Solution . . . . . . . . . . . . . . .
Main.java of XML/A Solution . . . . . . . . . . . . . . .
XIII
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
12
13
27
27
50
50
51
51
52
55
56
56
58
58
A-8
A - 12
A - 18
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
CHAPTER
1
Introduction
The topic “Detecting Fraud Patterns using data obtained from the Application
Platform” can be classified in the branch of Information Technology (IT) combined 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 approach 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 artificial 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
2
3
E.g. A senior executive of a German company stole over one million Euro with this
fraud method.
In 2000 Enron initiated one of the biggest company scandals in the US while committing
falsification of a balance sheet [Wik06b].
In 2004 WorldCom was involved in a stock market scandal while committing wrong
entries 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 implemented 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 visualizations 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 realtime 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 customers. At the moment, SAP’s approach is based on a Service-Oriented
Architecture∗ (SOA) for its new software products. This requires new developments 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 Service 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 different 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
CHAPTER
2
Basics and State-of-the-Art
Setting up the fundamental knowledge about relevant technologies and products 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 implementation 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 smallsize 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 composite 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 different 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 “BankDetailsFlapping” (composite event 2 in figure 2.6).
Listing 2.1: Rules written in Jena Rules Language [Vay06]
1
2
3
4
5
6
7
8
9
10
11
12
13
? e1 [ rdf:type → s a p : V e n d o r B a n k D e t a i l s C h a n g e d A c c o u n t i n g E v e n t ; sap:at → ? t1 ;
sap:bankDetails → ? bd ;
sap:clientID → ? client ; sap:vendor → ? vendor ] ,
? e2 [ rdf:type → s a p : V e n d o r B a n k D e t a i l s C h a n g e d A c c o u n t i n g E v e n t ; sap:at → ? t2 ;
sap:bankDetails → ? bdo ;
sap:clientID → ? client ; sap:vendor → ? vendor ] ,
? e3 [ rdf:type → s a p : V e n d o r B a n k D e t a i l s C h a n g e d A c c o u n t i n g E v e n t ; sap:at → ? t3 ;
sap:bankDetails → ? bd ;
sap:clientID → ? client ; sap:vendor → ? vendor ] ,
le (? t1 , ? t2 ) ,
le (? t2 , ? t3 ) ,
notEqual (? bd , ? bdo ) ,
makeTemp (? s )
→
? s [ rdf:type → s a p : B a n k D e t a i l s F l a p p i n g ; sap:firstFlap → ? e2 ; s ap: se co ndF la p
→ ? e3 ; sap:startTime → ? t2 ;
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 V e n d o r B a n k D e t a i l s C h a n g e d
{ 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 B a n k A c c o u n t F l i p p i n g E v e n t
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 management concept and basically the idea of aiming at higher flexibility on enterprise
IT infrastructure and lower the impact of change on the company. The concept 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 standardized interfaces [Wik06e], they exist independently from each other, and
consequently, the business functionalities are well-bounded. For the description 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
http://www.w3.org/TR/wsdl.html
official
14
W3C
website
to
WSDL
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 independent integration and application platform for heterogeneous landscapes.
One task of SAP NetWeaver is to provide the communication layer for composite 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 abstract 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 contains 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, composition 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 communication 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 patterns, 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 communication for Application to Application (A2A) and Business to Business (B2B)
communication, because core services are unsuitable for this type of communication. 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 communications, the caller waits for a response and is blocked while accessing. Otherwise, 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 either 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 building 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 applications, 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 landscapes.
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
CHAPTER
3
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 Integration 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. For
that case, enterprise SOA enables partners to develop niche products.
23
3.1. Investigation Methodology
The first step is to identify which relevant
data exists (sources) and how this data can
be accessed (access methods).
Afterwards, all sources are systematically
combined with the access methods and are
investigated if accessing the data from outside is possible.
The out-coming and suitable combinations
are listed and explained shortly.
Based on the list, classifying strategies in
different groups is possible. These groups
allow the validation of the first requirement. Changes on AP elements are not
allowed.
On the base of the first validation the other
given requirements has to be investigated.
The strategies must fulfill the following requirements:
• Collected data has to provide information about changes in a BO instance and about its history.
• The transferred data volume should
be optimized and the performance
should be acceptable.
• The software effort should be acceptable in initial implementation, maintenance and administration.
The last step is to verify if the strategy
refers to the reference example. Finally,
a decision has to be made which strategies should be implemented in order to test
their practical behavior.
Figure 3.1: Investigation Methodology
24
3.2. Components
3.2 Components
According to the introduced methodology, identifying the data sources is necessary 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 validated.
3.2.1 Sources
Business Objects
BOs are the basic elements of future business applications, because they contain 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 Supplier 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 history. This requirement is covered by Platform Change Documents∗ [PKVC06].
The possibility to observe the changes is modeled and implemented as a Technical Object∗ (TecO), a special kind of a BO, with the name ChangeDocument. It exists directly in the Foundation Layer and does not belong to any
DU. ChangeDocument provides the enterprise SOA core services Retrieve, RetrieveByAssociation 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, Retrieve, 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
2
3
4
5
6
7
8
9
10
11
12
13
14
15
CALL METHOD c l _ e s f _l c p _ f a c t o r y⇒ge t_ lc p_ fac ad e
RECEIVING
out_lcp_facade = lr_lcp_facade .
** get lcp
CALL METHOD lr_lcp_facade→get_lcp
EXPORTING
in_bo_name = / srmap / i f _ f n d _ c o n s t a n t s _ b o⇒c_bo_po
RECEIVING
out_lcp = mr_lcp_po .
CALL METHOD mr_lcp_po→retrieve
EXPORTING
in_bo_node_name = / srmap / i f _ f n d x _ p d _ t e m p l a t e⇒co_bo_node - root
in_node_ids = lt_node_ids
IMPORTING
out_data = l t_po _roo t _ n o d e s .
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 Consumer 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 Remote 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
2
// Get c o n n e c t i o n
ConnectionData connectionData = g e t C o n n e c t i o n D a t a () ;
3
4
5
6
7
8
9
10
// Get a service facade inst a n c e e s t a b l i s h i n g a c o n n e c t i o n with a backend
system
IServiceFacade serviceFacade = null ;
try {
serviceFacade = S e r v i c e F a c a d e F a c t o r y . c r e a t e S e r v i c e F a c a d e ( connectionData , new
Locale ( " en " ) ) ;
} catch ( Exception e ) {
e . printStackTrace () ;
}
11
12
13
// Load the C h a n g e D o c u m e n t BO model
IBOModel model = serviceFacade . getBOModel ( ISalesOrder . ESR_NAME ) ;
14
15
16
// Create a query
IQuery query = model . createQuery ( ISalesOrder . Root . ESR_NAME , ISalesOrder . Root .
QU ERY_ HEAD ER_ ESR ) ;
17
18
19
// Execute Query
query . execute () ;
20
21
22
// Get the results
IBONode node = query . getResul tB O N o d e () ;
23
24
25
// Process input data
dumpBONode ( node , IChangeDocume n t . Root . NAME + " : Only 5 records are returned " ) ;
26
27
28
// Close c o n n e c t i o n to the backend system
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 ChangeDocument. 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 communication. 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 service configuration in the system providing the service” [SAP06e, p. 6]. Compound 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.
BO
ChangeDocument
Core
service
Compound
service
BW
1.
5.
2.
6.
3.
7.
Own
FRODO
BO
4.
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 international standard, encouraging reuse of data types, establishing SAP-wide consolidation
and 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 structured 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 executing the analysis on this data is another option. For accessing this
data, BW provides three possibilities: XML/A, Open Hub or direct access 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 services. 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 components 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 developments, 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 requirements.
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 acceptable 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
Meaning
Criterion is
Criterion is
Criterion is
Criterion is
dissatisfying
acceptable
fulfilled in a good way
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
Information about changes and history
Data volume & Performance
Software effort
Usable for FRODO
Evaluation
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
Information about changes and history
Data volume & Performance
Software effort
Usable for FRODO
Evaluation
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, because 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 technical 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, provides 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 software 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 methods 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
Evaluation Evaluation Evaluation
XML/A
Open
direct
Hub
access
Information about changes and history
Data volume & Performance
Software effort
Usable 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 option. 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 submitted 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
Information about changes and history
Data volume & Performance
Software effort
Usable for FRODO
Evaluation
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 fulfilled 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
Information about changes and history
Data volume & Performance
Software effort
Usable for FRODO
Evaluation
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 administration, 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
Evaluation Evaluation Evaluation
XML/A
Open
direct
Hub
access
Information about changes and history
Data volume & Performance
Software effort
Usable for FRODO
Table 3.8: Evaluation of Accessing Data Using SAP BW on ChangeDocument
Data
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
Information
about
changes
and history
Data
volume &
performance
Software
effort
Usable for
FRODO
BW
BOs
Core service
Compound service
XML/A
Open Hub
Direct access
BW
TecO Change Document
Core service
Compound service
XML/A
Open Hub
Direct 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. Additionally, 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
CHAPTER
4
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 “Waterfall 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 strategies. 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 Using
GCP
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
11
SAP NetWeaver Developer Studio is based on Eclipse and is extended with functionality
according to SAP’s technologies and development guidelines.
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
2
3
4
5
6
7
8
cds . channel = JCO
mshost = ldcias1 . wdf . sap . corp
group = PUBLIC
r3name = AS1
client =100
lang = EN
USER = HERZBERGNI
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
2
3
// Get C o n n e c t i o n Data Service and generic C o n n e c t i o n Data
I C o n n e c t i o n D a t a S e r v i c e cds = C o n n e c t i o n D a t a S e r v i c e F a c t o r y .
g e t C o n n e c t i o n D a t a S e r v i c e () ;
ConnectionData cd = cds . ge t Co n n e c t i o n D a t a ( Co nn ec tio nD at a . channelGeneric ,
ConnectionData . typeGeneric ) ;
4
5
...
6
7
8
// Add p r o p e r t i e s to the generic C o n n e c t i o n Data
cd . putAll ( props ) ;
9
10
11
12
13
14
15
16
// Get a service facade inst a n c e e s t a b l i s h i n g a c o n n e c t i o n with a backend
system
IServiceFacade serviceFacade = null ;
try {
serviceFacade = S e r v i c e F a c a d e F a c t o r y . c r e a t e S e r v i c e F a c a d e ( cd , new Locale ( " en "
));
} catch ( Exception e ) {
e . printStackTrace () ;
}
17
18
// Load the C h a n g e D o c u m e n t 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 interfaces, 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
2
3
4
public interface IChangeDocum en t {
String NAMESPACE = " http :// sap . com / xi / AP / IS / P l a t f o r m C h a n g e D o c u m e n t / Global " ;
String NAME = " ChangeDocumen t " ;
IESRName ESR_NAME = ESRN am eF ac tor y . createESRName ( " Ch an ge Do cum en t " , " http
:// sap . com / xi / AP / IS / P l a t f o r m C h a n g e D o c u m e n t / Global " ) ;
5
// BO Node C h a n g e D o c u m e n t I t e m
interface C h a n g e Do c u m e n t I t e m {
String
NAME
= " ChangeDocumentItem ";
IESRName ESR_NAME = ESRN am eF ac tor y . createESRName ( " C h a n g e D o c u m e n t I t e m " , " " )
;
...
6
7
8
9
10
11
}
Afterwards, the query can be created and configured (lines 2 - 7 in listing 4.4). The query is of the type IQuery and can be specified with methods like createSelectOption() (lines 6 and 7 in listing 4.4). Relevant attributes 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
2
3
4
5
6
// Create a query
IQuery query = model . createQuery ( I Ch a n g e D o c um e n t . Root . ESR_NAME . getFullName () ,
IChangeDocument . Root . Q U E R Y _ Q U E R Y _ B Y _ B U S I N E S S _ O B J E C T _ N A M E _ A N D I D ) ;
// Limit the number of results
query . s e t M a x i m u m R e s u l t E l e m e n t s (5) ;
// Set query options
query . c r e a t e S e l ec t O p t i o n ( " Obje ct Typ eC od e " , ISelectOption . Operator . EQUAL , "
00001 " , null ) ;
51
4.1. Accessing the TecO ChangeDocument by Using its Core Services
7
query . c r e a t e S e l ec t O p t i o n ( " ObjectId " , ISelectOption . Operator . EQUAL , " 00001 " ,
null ) ;
8
9
10
11
12
// Execute Query
query . execute () ;
// Get the results
IBONode node = query . getResul tB O N o d e () ;
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
Po stin gDat eTi me: null
S y s t e m A d m i n i s t r a t i v e D a t a $ C r e a t i o n D a t a T i m e : 2006 -04 -27 06 :20:34 .0
S y s t e m A d m i n i s t r a t i v e D a t a $ C r e a t i o n S y s t e m A c c o u n t U s e r I D : T . P . KUMAR
S y s t e m A d m i n i s t r a t i v e D a t a $ L a s t C h a n g e D a t e T i m e : 2006 -06 -13 12 :30:09 .0
S y s t e m A d m i n i s t r a t i v e D a t a $ L a s t C h a n g e S y s t e m A c c o u n t U s e r I D : DEYS
SellerParty $ SellerID: 5
BuyerParty $ BuyerID: 6
Incoterms $ C l a s s i f i c a t i o n C o d e C o n t e n t : TES
Incoterms $ T r a n s f e r L o c a t i o n N a m e : null
T ot al G ro s sA mo u nt : null
TotalNetAmount: null
TotalTaxAmount: null
CurrencyCode: EUR
P u r c h a s e O r d e r P o s t i n g D a t e T i m e : null
52
4.2. Receiving BW Data of BOs Using XML for Analysis
P u r c h a s e O r d e r R e f e r e n c e I D : null
Status $ A v a i l a b l e T o P r o m i s e C o n f i r m a t i o n S t a t u s C o d e : 1
Status $ A c c e p t a n c e S t a t u s C o d e : 1
Status $ I n v o i c i n g C o m p l e t i o n S t a t u s C o d e : 1
Status $ A r c h i v i n g S t a t u s C o d e : 1
Status $ L i f e C y c l e S t a t u s C o d e : 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
2
3
4
5
< SOAP - ENV:Envelope xmlns:SOAP - ENV = ’ http: // schemas . xmlsoap . org / soap / envelope / ’
SOAP - E NV : en co d in g St yl e = ’ http: // schemas . xmlsoap . org / soap / encoding / ’ >
< SOAP - ENV:Body >
< Execute xmlns = ’ urn:schemas - microsoft - com:xml - analysis ’ SOAP E NV :e n co d in gS t yl e = ’ http: // schemas . xmlsoap . org / soap / encoding / ’ >
< Command >
< Statement >
55
4.2. Receiving BW Data of BOs Using XML for Analysis
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
select [ Measures ]. members on columns , non empty [0 VC_COUN ]. levels (1)
. members * [0 VC_REG ]. levels (1) . members dimension properties
member_name , m emb er _c apt io n on rows from [$0 BWVC_C03 ] where ([0
FISCYEAR ].[ K41999 ])
</ Statement >
</ Command >
< Properties >
< PropertyList >
< DataSourceInfo > default </ D at aS our ce In fo >
< Catalog > Foodmart 2000 </ Catalog >
< Format > Tabular </ Format >
< R e t u r n C e l l P r o p e r t i e s > true </ R e t u r n C e l l P r o p e r t i e s >
< AxisFormat > TupleFormat </ AxisFormat >
< Content > SchemaData </ Content >
</ PropertyList >
</ Properties >
</ Execute >
</ SOAP - ENV:Body >
</ 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
2
3
4
5
host = ldcia1y . wdf . sap . corp
port =50085
client =100
user = DISPLAY
passwd = SHOWME
Listing 4.8: Connection and Data Sending in XML/A solution
1
URL url = new URL ( readproperti es ( " c o n n e c t i o n S t r i n g " ) ) ;
2
3
4
// Set up the c o n n e c t i o n
URLConnection conn = url . ope nC on ne cti on () ;
5
6
7
8
// Add user
conn . s e t R e q u e s t P ro p e r t y ( " sap - user " , re ad pr ope rt ie s ( " user " ) ) ;
// Add password
56
4.2. Receiving BW Data of BOs Using XML for Analysis
9
10
11
conn . s e t R e q u e s t P ro p e r t y ( " sap - password " , re ad pro pe rt ies ( " password " ) ) ;
// Add property Accept - Encodi n g
conn . s e t R e q u e s t P ro p e r t y ( " Accept - Encoding " ," gzip , compress " ) ;
12
13
14
15
16
// C o n n e c t i o n requires output
conn . setDoOutput ( true ) ;
// Connect to the URL
conn . connect () ;
17
18
19
20
21
22
// Define O u t p u t S t r e a m
O u t p u t S tr e a m W r i t e r wr = new O u t p u t S t r e a m W r i t e r ( conn . g e t O u t p ut S t r e a m () ) ;
// Send SOAP request to the server
wr . write ( data ) ;
wr . flush () ;
23
24
25
// Get response
BufferedReader rd = new Buffer edR ea de r ( new I n p u t S t r e a m R e a d e r ( conn .
getInputStream () ) ) ;
Additionally, setting the Hypertext Transfer Protocol (HTTP) header line
“Accept-Encoding” to “gzip, compress” (line 11 in listing 4.8) in the connection 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
2
3
4
5
6
7
8
9
10
11
12
< row >
< C000000 > AUS </ C000000 >
< C000001 > Australia </ C000001 >
< C000002 > AUSNRD </ C000002 >
< C000003 > AUS / NRD </ C000003 >
< C000004 > 49.996 ,60 DM </ C000004 >
< C000005 >X </ C000005 >
< C000006 > 224 ,470 PC </ C000006 >
< C000007 >0 ,3 PC </ C000007 >
< C000008 >1 </ C000008 >
< C000009 > 892 ,000 </ C000009 >
</ 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
2
3
4
5
6
7
8
9
10
11
12
<? xml version = " 1.0 " ? >
< SOAP - ENV:Envelope xmlns:SOAP - ENV = " http: // schemas . xmlsoap . org / soap / envelope / "
SOAP - E NV : en co d in gS t yl e = " http: // schemas . xmlsoap . org / soap / encoding / " >
< SOAP - ENV:Body >
< ExecuteResponse xmlns = " urn:schemas - microsoft - com:xml - analysis " >
< return xmlns:xsd = " http: // www . w3 . org /2001/ XMLSchema " xmlns:xsi = " http: //
www . w3 . org /2001/ XMLSchema - instance " >
< root xmlns = " urn:schemas - microsoft - com:xml - a n a ly s i s : r o w se t " xmlns:xsd =
" http: // www . w3 . org /2001/ XMLSchema " xmlns:xsi = " http: // www . w3 . org
/2001/ XMLSchema - instance " >
< xsd:schema xmlns = " urn:schemas - microsoft - com:xml - a n a l ys i s : r o w se t "
target N a m e s p ac e = " urn:schemas - microsoft - com:xml analysis:rowse t " 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 "
e l e m e n t Fo r m D e f a u l t = " qualified " >
< xsd:element name = " root " >
< xsd:complexTyp e >
< xsd:sequence minOccurs = " 0 " maxOccurs = " unbounded " >
< xsd:element name = " row " type = " row " / >
</ xsd:sequence >
58
4.2. Receiving BW Data of BOs Using XML for Analysis
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
</ xsd:complexTy p e >
</ xsd:element >
< xsd:simpleType name = " uuid " >
< xsd:restrictio n base = " xsd:string " >
</ xsd:restricti o n >
</ xsd:simpleType >
< xsd:complexType name = " row " >
< xsd:sequence minOccurs = " 0 " maxOccurs = " unbounded " >
< xsd:element name = " C000000 " type = " xsd:string " sql:field = " [0
VC_COUN ].[ LEVEL01 ].[ MEMBER_NAME ] " / >
< xsd:element name = " C000001 " type = " xsd:string " sql:field = " [0
VC_COUN ].[ LEVEL01 ].[ ME MB ER _CA PT IO N ] " / >
< xsd:element name = " C000002 " type = " xsd:string " sql:field = " [0
VC_REG ].[ LEVEL01 ].[ MEMBER_NAME ] " / >
< xsd:element name = " C000003 " type = " xsd:string " sql:field = " [0
VC_REG ].[ LEVEL01 ].[ ME MB ER _CA PT IO N ] " / >
< xsd:element name = " C000004 " type = " xsd:string " sql:field = " [
Measures ].[0 VC_AMT ] " / >
< xsd:element name = " C000005 " type = " xsd:string " sql:field = " [
Measures ].[0 VC_DATE ] " / >
< xsd:element name = " C000006 " type = " xsd:string " sql:field = " [
Measures ].[0 VC_MAX ] " / >
< xsd:element name = " C000007 " type = " xsd:string " sql:field = " [
Measures ].[0 VC_MIN ] " / >
< xsd:element name = " C000008 " type = " xsd:string " sql:field = " [
Measures ].[0 VC_ORD ] " / >
< xsd:element name = " C000009 " type = " xsd:string " sql:field = " [
Measures ].[0 VC_ZHL ] " / >
</ xsd:sequence >
</ xsd:complexType >
</ xsd:schema >
< row > < C000000 > AUS </ C000000 > < C000001 > Australia </ C000001 > < C000002 > AUSNRD </
C000002 > < C000003 > AUS / NRD </ C000003 > < C000004 > 49.996 ,60 DM </ C000004 > < C000005 >
X </ C000005 > < C000006 > 224 ,470 PC </ C000006 > < C000007 >0 ,3 PC </ C000007 > < C000008
>1 </ C000008 > < C000009 > 892 ,000 </ C000009 > </ row >
< 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 >
< 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 >
</ root >
</ return >
</ ExecuteResponse >
</ SOAP - ENV:Body >
</ SOAP - ENV:Envelope >
59
CHAPTER
5
Validation
The aim of the validation phase is to discuss the received results of the implemented 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 accuracy of the data delivered by the different backend systems cannot be validated. Nevertheless, the implemented software is tested with similar data.
Software measurements are not possible in detail, because the provided sandbox 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 local 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
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Average
GCP solution
20,760s
15,301s
15,312s
17,285s
15,322s
16,113s
15,312s
15,261s
15,352s
15,312s
15,412s
15,312s
15,332s
15,382s
15,322s
17,485s
15,372s
15,331s
15,412s
15,382s
XML/A solution
22,141s
12,818s
12,067s
12,087s
12,077s
18,116s
12,818s
12,808s
12,048s
12,057s
12,038s
12,788s
18,897s
12,788s
12,068s
12,798s
12,838s
12,067s
12,058s
12,849s
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
CHAPTER
6
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
CHAPTER
7
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 methodology 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 requirements 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
APPENDIX
A
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 diagram 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 systems. 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 development 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 realizes that idea by the model-driven approach using services. Thus, SAP, ISVs,
and customers can implement new features and extend existing business processes. 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 percent 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 example, is almost the same in Supply Chain Management systems, in Customer Relationship Management systems and in Enterprise Resources Planning 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 different 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 offer 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
APPENDIX
B
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 realtime 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, scanning 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 services. 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 strategy. Thus, the investigation stops after a shallow research.
Requirement
Information about changes and history
Data volume & Performance
Software effort
Usable for FRODO
Evaluation
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 compound 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, because event notification is important for that issue.
A-5
APPENDIX
C
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 required. 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 different 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
Information about changes and history
Data volume & Performance
Software effort
Usable for FRODO
Evaluation
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 are
used to exchange data between systems in a simple structured way.
A-7
APPENDIX
D
Code for Accessing
ChangeDocument Using GCPs
Listing D.1: Main.java of XML/A Solution
1
2
3
4
5
6
7
8
9
10
11
12
13
14
/*
* Access C h a n g e D o c u m e n t via GCPs
*/
import java . io . IOException ;
import java . io . InputStream ;
import java . util . Date ;
import java . util . Locale ;
import java . util . Properties ;
import com . sap . dictionary . runtime . container .*;
import com . sap . tc . esf . cds . Con ne cti on Da ta ;
import com . sap . tc . esf . cds . C o n n e c t i o n D a t a S e r v i c e F a c t o r y ;
import com . sap . tc . esf . cds . I C o n n e c t i o n D a t a S e r v i c e ;
import com . sap . tc . esf . gcp . api .*;
// import com . sap . tc . esf . test . refcase . I S a l e s O r d e r ;
15
16
17
18
19
20
21
22
23
24
/* *
* This is a simple example to show , how is it p o s s i b l e to get data from
ChangeDocument .
* The c o n n e c t i o n settings are written down in single p r o p e r t y files .
*
* C o p y r i g h t ( c ) 2006 SAP AG
*
* @author Nico Herzberg ( D041659 )
*
*/
25
26
public class Main {
27
28
29
30
31
/* *
* Main method
*
* @param args
A-8
32
33
34
*
Possible input p a r a m e t e r s
*/
public static void main ( String [] args ) {
35
// Get c o n n e c t i o n
ConnectionData connectionD at a = g e t C o n n e c t i o n D a t a () ;
36
37
38
// Get a service facade i n s t a n c e e s t a b l i s h i n g a c o n n e c t i o n with a backend
system
IServiceFacade serviceFacade = null ;
try {
serviceFacade = S e r v i c e F a c a d e F a c t o r y . c r e a t e S e r v i c e F a c a d e ( connectionData ,
new Locale ( " en " ) ) ;
} catch ( Exception e ) {
e . printStackTrace () ;
}
39
40
41
42
43
44
45
46
// Load the C h a n g e D o c u m e n t BO model
IBOModel model = serviceFacade . getBOModel ( I C h a ng e D o c u m en t . ESR_NAME ) ;
47
48
49
// Create a query
IQuery query = model . createQuery ( I Ch a n g e D o c um e n t . Root . ESR_NAME . getFullName
() , IChangeDocument . Root . Q U E R Y _ Q U E R Y _ B Y _ B U S I N E S S _ O B J E C T _ N A M E _ A N D I D ) ;
// Limit the number of results
query . s e t M a x i m u m R e s u l t E l e m e n t s (5) ;
// Set query options
query . c r e a t e S e l e ct O p t i o n ( " Ob je ct Typ eC od e " , ISelectOption . Operator . EQUAL , "
00001 " , null ) ;
query . c r e a t e S e l e ct O p t i o n ( " ObjectId " , ISelectOption . Operator . EQUAL , " 00001 "
, null ) ;
50
51
52
53
54
55
56
57
// Execute Query
query . execute () ;
// Get the results
IBONode node = query . get R e s u l t BO N o d e () ;
58
59
60
61
62
// Process input data
dumpBONode ( node , IChangeD o c u me n t . Root . NAME + " : Only 5 records are
returned " ) ;
63
64
65
// Close c o n n e c t i o n to the backend system
serviceFacade . close () ;
66
67
68
69
}
70
71
72
73
74
75
76
77
/* *
* Method for getting c o n n e c t i o n data from the p r o p e r t y file
*
* @return
*
Data about the c o n n e c t i o n to one backend system
*/
public static ConnectionDat a g e t C o n n e c t i o n D a t a () {
78
79
// Get C o n n e c t i o n Data Service and generic C o n n e c t i o n Data
A-9
I C o n n e c t i o n D a t a S e r v i c e cds = C o n n e c t i o n D a t a S e r v i c e F a c t o r y .
g e t C o n n e c t i o n D a t a S e r v i c e () ;
ConnectionData cd = cds . g e t C o n n e c t i o n D a t a ( Co nn ec tio nD at a . channelGeneric ,
ConnectionData . typeGeneric ) ;
80
81
82
// Open property file
InputStream is = Class . class . g e t R e s o u r c e A s S t r e a m ( " / AS 1_ co nn ect io n .
properties " ) ;
Properties props = new Properties () ;
try {
props . load ( is ) ;
is . close () ;
} catch ( IOException x ) {
x . printStackTrace () ;
}
83
84
85
86
87
88
89
90
91
92
// Add p r o p e r t i e s to the generic C o n n e c t i o n Data
cd . putAll ( props ) ;
93
94
95
// Return C o n n e c t i o n Data
return cd ;
96
97
98
}
99
100
101
102
103
104
105
106
107
108
109
/* *
* Method for handle the in c o m i n g data .
*
* @param boNode
*
The business object node to be dumped
* @param text
*
D e s c r i p t i o n text of the dump
*/
public static void dumpBONode ( final IBONode boNode , final String text ) {
System . out . println ( " \ n " + text ) ;
110
final int elementCount = boNode . size () ;
final int structSize = boNode . getDescriptor () . g e t D a t a S t r u c t u r e () .
g e t S h a l l o w S t r u c t u r e D e s c r i p t o r () . size () ;
for ( int i = 0; i < elementCount ; i ++) {
IBONodeElement element_i = boNode . g e t B O N o d e E l e m e n t ( i ) ;
System . out . println () ;
for ( int j = 0; j < structSize ; j ++) {
System . out . println ( " " + element_i . getDescriptor () .
g e t S h a l l o w A t t r i b u t e D e s c r i p t o r ( j ) . getName () + " : "
+ getContent ( element_i . g e t A t t r i b u t e V a l u e ( j ) ) ) ;
}
}
111
112
113
114
115
116
117
118
119
120
121
if ( elementCount == 0) {
System . out . println ( " no data available " ) ;
} else {
System . out . println ( " . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . " ) ;
System . out . println ( " number of entries : " + elementCount ) ;
}
122
123
124
125
126
127
128
}
A - 10
129
/* *
* Get content for r e q u e s t e d field
*
* @param value
*
The d e s c r i p t o r of a field
* @return
*
The value for the r e q u e s t e d field
*/
public static Object getContent ( Object value ) {
if ( value instanceof ICctContainer ) {
value = (( ICctContainer ) value ) . g e t C o m p o n e n t V a l u e ( " content " ) ;
}
return value ;
}
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
}
A - 11
A - 12
30
29
28
27
26
25
24
23
22
21
20
19
18
17
16
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
// BO Node C h a n g e D o c u m e n t I t e m
interface C h a n g e D o c u m e n t I t e m {
String
NAME
= " ChangeDocumentItem ";
IESRName ESR_NAME = E SRN am eF ac tor y . createESRName ( " C h a n g e D o c u m e n t I t e m " , " " ) ;
// I A s s o c i a t i o n ToRoot
String
A S S O C I A T I O N _ T O _ R O O T = " ToRoot " ;
IESRName A S S O C I A T I O N _ T O _ R O O T _ E S R = ES RN am eFa ct or y . createESRName ( " ToRoot " , " " ) ;
// I A s s o c i a t i o n T o P a r e n t
String
A S S O C I A T I O N _ T O _ P A R E N T = " ToParent " ;
IESRName A S S O C I A T I O N _ T O _ P A R E N T _ E S R = ES RN am eF act or y . createESRName ( " ToParent " , " " ) ;
// Query Q u e r y B y N o d e N a m e A n d N o d e I D
String
QUERY_QUERY_BY_NODE_NAME_AND_NODEID = " QueryByNodeNameAndNodeID ";
IESRName Q U E R Y _ Q U E R Y _ B Y _ N O D E _ N A M E _ A N D _ N O D E I D _ E S R = E SR Nam eF ac to ry . createESRName ( " Q u e r y B y N o d e N a m e A n d N o d e I D " , " " ) ;
IESRName Q U E R Y _ Q U E R Y _ B Y _ N O D E _ N A M E _ A N D _ N O D E I D _ I N P U T _ S T R U C T U R E _ E S R = ES RNa me Fa cto ry . createESRName ( "
L i n e I t e m Q u e r y I n p u t P a r a m e t e r " , " http :// sap . com / xi / AP / IS / P l a t f o r m C h a n g e D o c u m e n t / Global " ) ;
String Q U E R Y _ Q U E R Y _ B Y _ N O D E _ N A M E _ A N D _ N O D E I D _ B U S I N E S S _ O B J E C T _ N O D E _ T Y P E _ C O D E = " B u s i n e s s O b j e c t N o d e T y p e C o d e " ;
String Q U E R Y _ Q U E R Y _ B Y _ N O D E _ N A M E _ A N D _ N O D E I D _ O B J E C T I D = " ObjectID " ;
String Q U E R Y _ Q U E R Y _ B Y _ N O D E _ N A M E _ A N D _ N O D E I D _ F R O M _ D A T E _ T I M E = " FromDateTime " ;
String Q U E R Y _ Q U E R Y _ B Y _ N O D E _ N A M E _ A N D _ N O D E I D _ T O _ D A T E _ T I M E = " ToDateTime " ;
/* *
*
* Model D e s c r i p t o r I n t e r f a c e for C h a n g e D o c u m e n t .
*
*/
public interface I C h a ng e D o c u m en t {
String NAMESPACE = " http :// sap . com / xi / AP / IS / P l a t f o r m C h a n g e D o c u m e n t / Global " ;
String NAME = " Ch an ge Do cum en t " ;
IESRName ESR_NAME = E SRN am eF ac tor y . createESRName ( " Ch an ge Doc um en t " , " http :// sap . com / xi / AP / IS / P l a t f o r m C h a n g e D o c u m e n t / Global "
);
import com . sap . esi . esm .*;
Listing D.2: Main.java of XML/A Solution
A - 13
60
59
58
57
56
55
54
53
52
51
50
49
48
47
46
45
44
43
42
41
40
39
38
37
36
35
34
33
32
31
// A t t r i b u t e C h a n g e D o c u m e n t I t e m I D ( q u a l i f i e d name , esr name )
String
_CHANGE_DOCUMENT_ITEMID_CCTS = " ChangeDocumentItemID ";
IESRName _ C H A N G E _ D O C U M E N T _ I T E M I D _ C C T S _ E S R = ES RNa me Fa cto ry . createESRName ( " C h a n g e D o c u m e n t I t e m I D " , " " ) ;
// A t t r i b u t e O b j e c t N o d e T y p e C o d e ( q u a l i f i e d name , esr name )
String
_OBJECT_NODE_TYPE_CODE_CCTS = " ObjectNodeTypeCode ";
IESRName _ O B J E C T _ N O D E _ T Y P E _ C O D E _ C C T S _ E S R = E SRN am eF ac tor y . createESRName ( " O b j e c t N o d e T y p e C o d e " , " " ) ;
// A t t r i b u t e B u s i n e s s O b j e c t N o d e F i e l d N a m e ( q u a l i f i e d name , esr name )
String
_BUSINESS_OBJECT_NODE_FIELD_NAME_CCTS = " BusinessObjectNodeFieldName ";
IESRName _ B U S I N E S S _ O B J E C T _ N O D E _ F I E L D _ N A M E _ C C T S _ E S R = E SR Na meF ac to ry . createESRName ( " B u s i n e s s O b j e c t N o d e F i e l d N a m e " , " " ) ;
// A t t r i b u t e O b j e c t I D ( q u a l i f i e d name , esr name )
String
_OBJECTID = " ObjectID " ;
IESRName _OBJECTID_ESR = ES RN ame Fa ct ory . createESRName ( " ObjectID " , " " ) ;
// A t t r i b u t e P a r e n t O b j e c t I D ( q u a l i f i e d name , esr name )
String
_ P A R E N T _ O B J E C T I D = " Pa re nt Ob jec tI D " ;
IESRName _ P A R E N T _ O B J E C T I D _ E S R = E SR Na meF ac to ry . createESRName ( " Pa re nt Ob jec tI D " , " " ) ;
// A t t r i b u t e M o d i f i c a t i o n T y p e C o d e ( q u a l i f i e d name , esr name )
String
_MODIFICATION_TYPE_CODE_CCTS = " ModificationTypeCode ";
IESRName _ M O D I F I C A T I O N _ T Y P E _ C O D E _ C C T S _ E S R = ES RNa me Fa cto ry . createESRName ( " M o d i f i c a t i o n T y p e C o d e " , " " ) ;
// A t t r i b u t e B u s i n e s s O b j e c t E l e m e n t O l d C o n t e n t ( q u a l i f i e d name , esr name )
String
_BUSINESS_OBJECT_ELEMENT_OLD_CONTENT_CCTS = " BusinessObjectElementOldContent ";
IESRName _ B U S I N E S S _ O B J E C T _ E L E M E N T _ O L D _ C O N T E N T _ C C T S _ E S R = E SR Na meF ac to ry . createESRName ( " B u s i n e s s O b j e c t E l e m e n t O l d C o n t e n t " , "
");
// A t t r i b u t e B u s i n e s s O b j e c t E l e m e n t N e w C o n t e n t ( q u a l i f i e d name , esr name )
String
_BUSINESS_OBJECT_ELEMENT_NEW_CONTENT_CCTS = " BusinessObjectElementNewContent ";
IESRName _ B U S I N E S S _ O B J E C T _ E L E M E N T _ N E W _ C O N T E N T _ C C T S _ E S R = E SR Na meF ac to ry . createESRName ( " B u s i n e s s O b j e c t E l e m e n t N e w C o n t e n t " , "
");
// A t t r i b u t e C h a n g e R e a s o n T e x t ( q u a l i f i e d name , esr name )
String
_CHANGE_REASON_TEXT_CCTS = " ChangeReasonText ";
IESRName _ C H A N G E _ R E A S O N _ T E X T _ C C T S _ E S R = ESR Na me Fa cto ry . createESRName ( " C h a n g e R e a s o n T e x t " , " " ) ;
// A t t r i b u t e A d d i t i o n a l B u s i n e s s O b j e c t I n f o r m a t i o n ( q u a l i f i e d name , esr name )
String
_ADDITIONAL_BUSINESS_OBJECT_INFORMATION_CCTS = " AdditionalBusinessObjectInformation ";
IESRName _ A D D I T I O N A L _ B U S I N E S S _ O B J E C T _ I N F O R M A T I O N _ C C T S _ E S R = ES RN am eFa ct or y . createESRName ( "
AdditionalBusinessObjectInformation ", "");
A - 14
91
90
89
88
87
86
85
84
83
82
81
80
79
78
77
76
75
74
73
72
71
70
69
68
67
66
65
64
63
62
61
// BO Node C h a n g e D o c u m e n t R e c o r d
interface C h a n g e D o c u m e n t R e c o r d {
String
NAME
= " ChangeDocumentRecord ";
IESRName ESR_NAME = E SRN am eF ac tor y . createESRName ( " C h a n g e D o c u m e n t R e c o r d " , " " ) ;
// I A s s o c i a t i o n ToRoot
String
A S S O C I A T I O N _ T O _ R O O T = " ToRoot " ;
IESRName A S S O C I A T I O N _ T O _ R O O T _ E S R = ES RN am eFa ct or y . createESRName ( " ToRoot " , " " ) ;
// I A s s o c i a t i o n T o P a r e n t
String
A S S O C I A T I O N _ T O _ P A R E N T = " ToParent " ;
IESRName A S S O C I A T I O N _ T O _ P A R E N T _ E S R = ES RN am eF act or y . createESRName ( " ToParent " , " " ) ;
// Query Q u e r y B y B u s i n e s s O b j e c t N a m e A n d R o o t N o d e I D
String
QUERY_QUERY_BY_BUSINESS_OBJECT_NAME_AND_ROOT_NODEID = " QueryByBusinessObjectNameAndRootNodeID ";
IESRName Q U E R Y _ Q U E R Y _ B Y _ B U S I N E S S _ O B J E C T _ N A M E _ A N D _ R O O T _ N O D E I D _ E S R = ES RNa me Fa cto ry . createESRName ( "
QueryByBusinessObjectNameAndRootNodeID ", "");
IESRName Q U E R Y _ Q U E R Y _ B Y _ B U S I N E S S _ O B J E C T _ N A M E _ A N D _ R O O T _ N O D E I D _ I N P U T _ S T R U C T U R E _ E S R = ES RN am eFa ct or y . createESRName ( "
C h a n g e D o c u m e n t R e c o r d N o d e Q u e r y I n p u t P a r a m e t e r " , " http :// sap . com / xi / AP / IS / P l a t f o r m C h a n g e D o c u m e n t / Global " ) ;
String Q U E R Y _ Q U E R Y _ B Y _ B U S I N E S S _ O B J E C T _ N A M E _ A N D _ R O O T _ N O D E I D _ O B J E C T _ T Y P E _ C O D E = " Ob je ct Ty peC od e " ;
String Q U E R Y _ Q U E R Y _ B Y _ B U S I N E S S _ O B J E C T _ N A M E _ A N D _ R O O T _ N O D E I D _ O B J E C T _ I D = " ObjectId " ;
String Q U E R Y _ Q U E R Y _ B Y _ B U S I N E S S _ O B J E C T _ N A M E _ A N D _ R O O T _ N O D E I D _ F R O M _ D A T E _ T I M E = " FromDateTime " ;
String Q U E R Y _ Q U E R Y _ B Y _ B U S I N E S S _ O B J E C T _ N A M E _ A N D _ R O O T _ N O D E I D _ T O _ D A T E _ T I M E = " ToDateTime " ;
String Q U E R Y _ Q U E R Y _ B Y _ B U S I N E S S _ O B J E C T _ N A M E _ A N D _ R O O T _ N O D E I D _ U S E R _ A C C O U N T I D = " UserAccountID " ;
// A t t r i b u t e C o m p l e t e N o d e H i e r a r c h y ( q u a l i f i e d name , esr name )
String
_COMPLETE_NODE_HIERARCHY_CCTS = " CompleteNodeHierarchy ";
IESRName _ C O M P L E T E _ N O D E _ H I E R A R C H Y _ C C T S _ E S R = E SR Nam eF ac tor y . createESRName ( " C o m p l e t e N o d e H i e r a r c h y " , " " ) ;
// A t t r i b u t e C o m p l e t e C h a n g e d A t t r i b u t e P a t h ( q u a l i f i e d name , esr name )
String
_COMPLETE_CHANGED_ATTRIBUTE_PATH_CCTS = " CompleteChangedAttributePath ";
IESRName _ C O M P L E T E _ C H A N G E D _ A T T R I B U T E _ P A T H _ C C T S _ E S R = E SR Na meF ac to ry . createESRName ( " C o m p l e t e C h a n g e d A t t r i b u t e P a t h " , " " ) ;
// A t t r i b u t e B u s i n e s s O b j e c t E l e m e n t N a m e ( q u a l i f i e d name , esr name )
String
_BUSINESS_OBJECT_ELEMENT_NAME_CCTS = " BusinessObjectElementName ";
IESRName _ B U S I N E S S _ O B J E C T _ E L E M E N T _ N A M E _ C C T S _ E S R = ES RN ame Fa ct ory . createESRName ( " B u s i n e s s O b j e c t E l e m e n t N a m e " , " " ) ;
// A t t r i b u t e B u s i n e s s O b j e c t E l e m e n t N e w C o n t e n t ( q u a l i f i e d name , esr name )
}
A - 15
120
119
118
117
116
115
114
113
112
111
110
109
108
107
106
105
104
103
102
101
100
99
98
97
96
95
94
93
92
String
_BUSINESS_OBJECT_ELEMENT_NEW_CONTENT_CCTS = " BusinessObjectElementNewContent ";
IESRName _ B U S I N E S S _ O B J E C T _ E L E M E N T _ N E W _ C O N T E N T _ C C T S _ E S R = E SR Na meF ac to ry . createESRName ( " B u s i n e s s O b j e c t E l e m e n t N e w C o n t e n t " , "
");
// A t t r i b u t e B u s i n e s s O b j e c t E l e m e n t O l d C o n t e n t ( q u a l i f i e d name , esr name )
String
_BUSINESS_OBJECT_ELEMENT_OLD_CONTENT_CCTS = " BusinessObjectElementOldContent ";
IESRName _ B U S I N E S S _ O B J E C T _ E L E M E N T _ O L D _ C O N T E N T _ C C T S _ E S R = E SR Na meF ac to ry . createESRName ( " B u s i n e s s O b j e c t E l e m e n t O l d C o n t e n t " , "
");
// A t t r i b u t e U s e r A c o u n t I D ( q u a l i f i e d name , esr name )
String
_ U S E R _ A C O U N T I D _ C C T S = " UserAcountID " ;
IESRName _ U S E R _ A C O U N T I D _ C C T S _ E S R = ES RN am eFa ct or y . createESRName ( " UserAcountID " , " " ) ;
// A t t r i b u t e B u s i n e s s P a r t n e r F o r m a t t e d N a m e ( q u a l i f i e d name , esr name )
String
_BUSINESS_PARTNER_FORMATTED_NAME_CCTS = " BusinessPartnerFormattedName ";
IESRName _ B U S I N E S S _ P A R T N E R _ F O R M A T T E D _ N A M E _ C C T S _ E S R = E SR Na meF ac to ry . createESRName ( " B u s i n e s s P a r t n e r F o r m a t t e d N a m e " , " " ) ;
// A t t r i b u t e C h a n g e D a t e T i m e ( q u a l i f i e d name , esr name )
String
_ C H A N G E _ D A T E _ T I M E _ C C T S = " Ch an ge Dat eT im e " ;
IESRName _ C H A N G E _ D A T E _ T I M E _ C C T S _ E S R = ESR Na me Fac to ry . createESRName ( " Ch an ge Dat eT im e " , " " ) ;
// A t t r i b u t e M o d i f i c a t i o n T y p e C o d e ( q u a l i f i e d name , esr name )
String
_MODIFICATION_TYPE_CODE_CCTS = " ModificationTypeCode ";
IESRName _ M O D I F I C A T I O N _ T Y P E _ C O D E _ C C T S _ E S R = ES RNa me Fa cto ry . createESRName ( " M o d i f i c a t i o n T y p e C o d e " , " " ) ;
// A t t r i b u t e C h a n g e R e a s o n T e x t ( q u a l i f i e d name , esr name )
String
_CHANGE_REASON_TEXT_CCTS = " ChangeReasonText ";
IESRName _ C H A N G E _ R E A S O N _ T E X T _ C C T S _ E S R = ESR Na me Fa cto ry . createESRName ( " C h a n g e R e a s o n T e x t " , " " ) ;
// A t t r i b u t e A d d i t i o n a l B u s i n e s s O b j e c t I n f o r m a t i o n 1 ( q u a l i f i e d name , esr name )
String
_ADDITIONAL_BUSINESS_OBJECT_INFORMATION1_CCTS = " AdditionalBusinessObjectInformation1 ";
IESRName _ A D D I T I O N A L _ B U S I N E S S _ O B J E C T _ I N F O R M A T I O N 1 _ C C T S _ E S R = ESR Na me Fac to ry . createESRName ( "
AdditionalBusinessObjectInformation1 ", "");
// A t t r i b u t e A d d i t i o n a l B u s i n e s s O b j e c t I n f o r m a t i o n 2 ( q u a l i f i e d name , esr name )
String
_ADDITIONAL_BUSINESS_OBJECT_INFORMATION2_CCTS = " AdditionalBusinessObjectInformation2 ";
IESRName _ A D D I T I O N A L _ B U S I N E S S _ O B J E C T _ I N F O R M A T I O N 2 _ C C T S _ E S R = ESR Na me Fac to ry . createESRName ( "
AdditionalBusinessObjectInformation2 ", "");
// A t t r i b u t e A d d i t i o n a l B u s i n e s s O b j e c t I n f o r m a t i o n 3 ( q u a l i f i e d name , esr name )
String
_ADDITIONAL_BUSINESS_OBJECT_INFORMATION3_CCTS = " AdditionalBusinessObjectInformation3 ";
IESRName _ A D D I T I O N A L _ B U S I N E S S _ O B J E C T _ I N F O R M A T I O N 3 _ C C T S _ E S R = ESR Na me Fac to ry . createESRName ( "
A - 16
151
150
149
148
147
146
145
144
143
142
141
140
139
138
137
136
135
134
133
132
131
130
129
128
127
126
125
124
123
122
121
AdditionalBusinessObjectInformation3 ", "");
// BO Node Root
interface Root {
String
NAME
= " Root " ;
IESRName ESR_NAME = E SRN am eF ac tor y . createESRName ( " Root " , " " ) ;
// I A s s o c i a t i o n U s e r I d e n t i t y
String
A S S O C I A T I O N _ U S E R _ I D E N T I T Y = " UserIdentity " ;
IESRName A S S O C I A T I O N _ U S E R _ I D E N T I T Y _ E S R = E SRN am eF ac tor y . createESRName ( " UserIdentity " , " " ) ;
// I A s s o c i a t i o n C h a n g e D o c u m e n t I t e m
String
ASSOCIATION_CHANGE_DOCUMENT_ITEM = " ChangeDocumentItem ";
IESRName A S S O C I A T I O N _ C H A N G E _ D O C U M E N T _ I T E M _ E S R = ES RNa me Fa ct ory . createESRName ( " C h a n g e D o c u m e n t I t e m " , " " ) ;
// I A s s o c i a t i o n C h a n g e D o c u m e n t R e c o r d
String
ASSOCIATION_CHANGE_DOCUMENT_RECORD = " ChangeDocumentRecord ";
IESRName A S S O C I A T I O N _ C H A N G E _ D O C U M E N T _ R E C O R D _ E S R = ES RN ame Fa ct ory . createESRName ( " C h a n g e D o c u m e n t R e c o r d " , " " ) ;
// Action M o v e T o A r c h i v e
String
A C T I O N _ M O V E _ T O _ A R C H I V E = " MoveToArchive " ;
IESRName A C T I O N _ M O V E _ T O _ A R C H I V E _ E S R = ESR Na me Fac to ry . createESRName ( " MoveToArchive " , " " ) ;
// Action C h e c k A r c h i v a b i l i t y
String
ACTION_CHECK_ARCHIVABILITY = " CheckArchivability ";
IESRName A C T I O N _ C H E C K _ A R C H I V A B I L I T Y _ E S R = ES RNa me Fa cto ry . createESRName ( " C h e c k A r c h i v a b i l i t y " , " " ) ;
// Query Archive
String
QUERY_ARCHIVE = " Archive " ;
IESRName Q U E R Y _ A R C H I V E _ E S R = ES RN ame Fa ct or y . createESRName ( " Archive " , " " ) ;
// Query A r c h i v e P r e S e l e c t i o n
String
QUERY_ARCHIVE_PRE_SELECTION = " ArchivePreSelection ";
IESRName Q U E R Y _ A R C H I V E _ P R E _ S E L E C T I O N _ E S R = E SRN am eF ac tor y . createESRName ( " A r c h i v e P r e S e l e c t i o n " , " " ) ;
// Query Q u e r y B y B u s i n e s s O b j e c t N a m e A n d I D
String
QUERY_QUERY_BY_BUSINESS_OBJECT_NAME_ANDID = " QueryByBusinessObjectNameAndID ";
IESRName Q U E R Y _ Q U E R Y _ B Y _ B U S I N E S S _ O B J E C T _ N A M E _ A N D I D _ E S R = E SR Na meF ac to ry . createESRName ( " Q u e r y B y B u s i n e s s O b j e c t N a m e A n d I D " , " "
);
IESRName Q U E R Y _ Q U E R Y _ B Y _ B U S I N E S S _ O B J E C T _ N A M E _ A N D I D _ I N P U T _ S T R U C T U R E _ E S R = ES RN ame Fa ct ory . createESRName ( "
}
A - 17
182
181
180
179
178
177
176
175
174
173
172
171
170
169
168
167
166
165
164
163
162
161
160
159
158
157
156
155
154
153
152
}
}
R o o t N o d e Q u e r y I n p u t P a r a m e t e r " , " http :// sap . com / xi / AP / IS / P l a t f o r m C h a n g e D o c u m e n t / Global " ) ;
String Q U E R Y _ Q U E R Y _ B Y _ B U S I N E S S _ O B J E C T _ N A M E _ A N D I D _ O B J E C T _ T Y P E _ C O D E = " Ob je ct Typ eC od e " ;
String Q U E R Y _ Q U E R Y _ B Y _ B U S I N E S S _ O B J E C T _ N A M E _ A N D I D _ O B J E C T _ I D = " ObjectId " ;
String Q U E R Y _ Q U E R Y _ B Y _ B U S I N E S S _ O B J E C T _ N A M E _ A N D I D _ F R O M _ D A T E _ T I M E = " FromDateTime " ;
String Q U E R Y _ Q U E R Y _ B Y _ B U S I N E S S _ O B J E C T _ N A M E _ A N D I D _ T O _ D A T E _ T I M E = " ToDateTime " ;
String Q U E R Y _ Q U E R Y _ B Y _ B U S I N E S S _ O B J E C T _ N A M E _ A N D I D _ U S E R _ I D E N T I T Y U U I D = " U s e r I d e n t i t y U U I D " ;
// A t t r i b u t e C h a n g e D o c u m e n t I D ( q u a l i f i e d name , esr name )
String
_CHANGE_DOCUMENTID_CCTS = " ChangeDocumentID ";
IESRName _ C H A N G E _ D O C U M E N T I D _ C C T S _ E S R = E SRN am eF act or y . createESRName ( " C h a n g e D o c u m e n t I D " , " " ) ;
// A t t r i b u t e O b j e c t T y p e C o d e ( q u a l i f i e d name , esr name )
String
_ O B J E C T _ T Y P E _ C O D E _ C C T S = " Ob je ct Typ eC od e " ;
IESRName _ O B J E C T _ T Y P E _ C O D E _ C C T S _ E S R = ESR Na me Fac to ry . createESRName ( " Ob je ct Typ eC od e " , " " ) ;
// A t t r i b u t e B u s i n e s s O b j e c t R o o t O b j e c t I D ( q u a l i f i e d name , esr name )
String
_BUSINESS_OBJECT_ROOT_OBJECTID = " BusinessObjectRootObjectID ";
IESRName _ B U S I N E S S _ O B J E C T _ R O O T _ O B J E C T I D _ E S R = ES RNa me Fa ct ory . createESRName ( " B u s i n e s s O b j e c t R o o t O b j e c t I D " , " " ) ;
// A t t r i b u t e U s e r I d e n t i t y U U I D ( q u a l i f i e d name , esr name )
String
_USER_IDENTITYUUID_CCTS = " UserIdentityUUID ";
IESRName _ U S E R _ I D E N T I T Y U U I D _ C C T S _ E S R = E SRN am eF act or y . createESRName ( " U s e r I d e n t i t y U U I D " , " " ) ;
// A t t r i b u t e C h a n g e D a t e T i m e ( q u a l i f i e d name , esr name )
String
_ C H A N G E _ D A T E _ T I M E _ C C T S = " Ch an ge Dat eT im e " ;
IESRName _ C H A N G E _ D A T E _ T I M E _ C C T S _ E S R = ESR Na me Fac to ry . createESRName ( " Ch an ge Dat eT im e " , " " ) ;
// A t t r i b u t e T r a n s a c t i o n I D ( q u a l i f i e d name , esr name )
String
_ T R A N S A C T I O N I D _ C C T S = " TransactionID " ;
IESRName _ T R A N S A C T I O N I D _ C C T S _ E S R = ES RN am eFa ct or y . createESRName ( " TransactionID " , " " ) ;
// A t t r i b u t e S y s t e m N u m b e r ( q u a l i f i e d name , esr name )
String
_ S Y S T E M _ N U M B E R _ C C T S = " SystemNumber " ;
IESRName _ S Y S T E M _ N U M B E R _ C C T S _ E S R = ES RN am eFa ct or y . createESRName ( " SystemNumber " , " " ) ;
// A t t r i b u t e A r c h i v i n g S t a t u s ( q u a l i f i e d name , esr name )
String
_ A R C H I V I N G _ S T A T U S = " A r c h iv i n g S t a tu s " ;
IESRName _ A R C H I V I N G _ S T A T U S _ E S R = ES RN am eFa ct or y . createESRName ( " A r c h iv i n g S t a tu s " , " " ) ;
APPENDIX
E
Code for Accessing BW Using
XML for Analysis
Listing E.1: Main.java of XML/A Solution
1
2
3
/*
* Call BW data by Using XML / A i n t e r f a c e of the MDX p r o c e s s o r
*/
4
5
6
7
8
9
10
11
import
import
import
import
import
import
import
java . net .*;
java . io . FileInputStrea m ;
java . io . I n pu t St re a mR e a d e r ;
java . io . O u t p ut S t r e a m W r i t e r ;
java . io . BufferedReader ;
java . io . File ;
java . util . Properties ;
12
13
import java . util . Date ;
14
15
16
17
18
19
20
21
22
23
24
/* *
* This is a simple example to show , how is it p o s s i b l e to get data from BW .
In this
* case the query language MDX is used . The c o n n e c t i o n s e t t i n g s are written
down in the file
* p r o p e r t i e s . ini
*
* C o p y r i g h t ( c ) 2006 SAP AG
*
* @author Nico Herzberg ( D041659 )
*
*/
25
26
public class Main {
27
28
29
30
/* *
* Main method
*
A - 18
31
32
33
34
* @param args
*
Possible input p a r a m e t e r s
*/
public static void main ( String [] args ) {
35
// D e f i n i t o n of the MDX S t a t e m e n t
String MDXstatement = new String () ;
MDXstatement = " select [ Measures ]. members on columns , non empty [0 VC_COUN
]. levels (1) . members * [0 VC_REG ]. levels (1) . members dimension
properties member_name , me mb er _c apt io n on rows from [ $0BWVC_C03 ]
where ([0 FISCYEAR ].[ K41999 ]) " ;
36
37
38
39
// Call method connect and provide MDX s t a t e m e n t
connect ( MDXstatement ) ;
40
41
42
}
43
44
45
46
47
48
49
50
/* *
* Method for c o n n e c t i n g to the MDX p r o c e s s o r and sending the SOAP request
and handle the respon s e
*
* @param M D X s t a t e m e n t
*
S t a t e m e n t for query r e l e v a n t data from BW
*/
public static void connect ( String MDXstatement ) {
51
52
53
// Build up the SOAP Request
String data = cr ea t eS O A P R e q u e s t ( MDXstatement ) ;
54
55
56
57
58
59
60
// Create and
try {
// Build up the
URL url = new
// Set up the
URLConnection
send request
URL
URL ( rea dp ro pe rti es ( " c o n n e c t i o n S t r i n g " ) ) ;
connection
conn = url . ope nC on nec ti on () ;
61
62
63
64
65
66
67
// Add user
conn . s e t R e q u e s t Pr o p e r t y ( " sap - user " , re ad pro pe rt ie s ( " user " ) ) ;
// Add password
conn . s e t R e q u e s t Pr o p e r t y ( " sap - password " , re ad pro pe rt ie s ( " password " ) ) ;
// Add property Accept - E n c o d i n g
conn . s e t R e q u e s t Pr o p e r t y ( " Accept - Encoding " ," gzip , compress " ) ;
68
69
70
71
72
// C o n n e c t i o n require s output
conn . setDoOutput ( true ) ;
// Connect to the URL
conn . connect () ;
73
74
75
76
77
78
// Define O u t p u t S t r e a m
O u t p u t St r e a m W r i t e r wr = new O u t p u t S t r e a m W r i t e r ( conn . g e t O u t p u tS t r e a m () )
;
// Send SOAP request to the server
wr . write ( data ) ;
wr . flush () ;
79
A - 19
// Get response
BufferedReader rd = new Bu ff er ed Rea de r ( new I n p u t S t r e a m R e a d e r ( conn .
getInputStream () ) ) ;
// Variable for reading input
String line ;
// Reading input
while (( line = rd . readLine () ) != null ) {
System . out . println ( line ) ;
}
// Close writer and reader
wr . close () ;
rd . close () ;
} catch ( Exception e ) {
System . out . println ( " Error while connecting to backend system " ) ;
}
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
}
95
96
97
98
99
100
101
102
103
104
/* *
* Method for reading the p r o p e r t y file
*
* @param field
*
P a r a m e t e r for d e f i n i n g which p r o p e r t y is r e q u i r e d
* @return
*
The value of the r e q u e s t e d property , in case of c o n n e c t i o n S t r i n g
the whole URL
*/
public static String readpro pe rt ies ( String field ) {
105
106
107
108
109
// Open property file
Properties prop = new Properties () ;
File file = new File ( " C :// Documents and Settings // d041659 // workspace // MDX
// src // properties . ini " ) ;
String property = new String () ;
110
111
112
113
114
115
116
117
118
119
120
121
122
123
// Read relevant data for c o n n e c t i o n string and build it up
if ( field . eq uals Igno reC a s e ( " c o n n e c t i o n S t r i n g " ) )
{
prop . clear () ;
try {
FileInputStream in = new F i l eI n p u t S t r ea m ( file . g e t Ab s o l u t e Pa t h () ) ;
prop . load ( in ) ;
in . close () ;
} catch ( Exception e ) {
System . out . println ( " Error while loading property file " ) ;
}
property = " http :// " + prop . getProperty ( " host " ) + " : " + prop . getProperty ( "
port " ) + " / sap / bw / xml / soap / xmla " + " ? sap - client = " + prop . getProperty ( "
client " ) ;
}
124
125
126
127
128
// Read user
if ( field . eq uals Igno reC a s e ( " user " ) )
{
prop . clear () ;
A - 20
try {
FileInputStream in = new F i l eI n p u t S t r ea m ( file . g e t Ab s o l u t e Pa t h () ) ;
prop . load ( in ) ;
in . close () ;
} catch ( Exception e ) {
System . out . println ( " Error while loading property file " ) ;
}
property = prop . getProperty ( " user " ) ;
129
130
131
132
133
134
135
136
}
137
138
// Read password
if ( field . eq uals Igno reC a s e ( " password " ) )
{
prop . clear () ;
try {
FileInputStream in = new F i l eI n p u t S t r ea m ( file . g e t Ab s o l u t e Pa t h () ) ;
prop . load ( in ) ;
in . close () ;
} catch ( Exception e ) {
System . out . println ( " Error while loading property file " ) ;
}
property = prop . getProperty ( " passwd " ) ;
}
139
140
141
142
143
144
145
146
147
148
149
150
151
152
// Return r e q u e s t e d prop e r t y
return property ;
153
154
155
}
156
157
158
159
160
161
162
163
164
165
/* *
* Method for creating the SOAP Request with the MDX s t a t e m e n t
*
* @param M D X s t a t e m e n t
*
S t a t e m e n t for Query the r e l e v a n t data from BW
* @return
*
The SOAP respon s e
*/
public static String c re at e S O A P R e q u e s t ( String MDXstatement ) {
166
167
String request = new String () ;
168
169
170
171
172
173
174
175
176
177
178
179
180
request = " < SOAP - ENV : Envelope "
+ " xmlns : SOAP - ENV = ’ http :// schemas . xmlsoap . org / soap / envelope / ’ "
+ " SOAP - ENV : encodingStyle = ’ http :// schemas . xmlsoap . org / soap / encoding
/’>"
+ " < SOAP - ENV : Body > "
+ " < Execute xmlns = ’ urn : schemas - microsoft - com : xml - analysis ’"
+ " SOAP - ENV : encodingStyle = ’ http :// schemas . xmlsoap . org / soap / encoding
/’>"
+ "
< Command > "
+ "
< Statement > "
+ MDXstatement
+ "
</ Statement > "
+ "
</ Command > "
+ "
< Properties > "
A - 21
+
+
+
+
+
+
+
+
+
+
+
+ "
181
182
183
184
185
186
187
188
189
190
191
192
"
< PropertyList > "
"
< DataSourceInfo > default </ DataSourceInfo > "
"
< Catalog > Foodmart 2000 </ Catalog > "
"
< Format > Tabular </ Format > "
"
< ReturnCellProperties > true </ ReturnCellProperties > "
"
< AxisFormat > TupleFormat </ AxisFormat > "
"
< Content > SchemaData </ Content > "
"
</ PropertyList > "
"
</ Properties > "
" </ Execute > "
" </ SOAP - ENV : Body > "
</ SOAP - ENV : Envelope > " ;
193
return request ;
194
}
195
196
}
A - 22
APPENDIX
F
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
A - 24
Matthias
Wasim
Schmitt
Sadiq
Noelle
Voss
AP
Stephan
Wollny
Pascal
Pascal
Hochwarth
Hochwarth
Robert
Reiner
ARIS
Paola
Sala
SRM
Julien
Vayssière
Noelle
Voss
Fraud Detection
Julien
Vayssière
Fraud
First name
Surname
Knowledge
Field
I025248
D027313
D031154
D040491
D040407
D031154
D023473
D020422
I028859
D040491
I028859
User ID
Senior Researcher
Developer AP Master Data
Developer AP/SRM
PLM Consultant
Developer AP/SRM
Developer AP/SRM
Developer AP/SRM
Development Manager AP/SRM
Senior Researcher
PLM Consultant
Senior Researcher
Function
Involved in project “Fraud Detection in
SRM”
Author of thesis “Conception and analysis
of methods for detecting and preventing of
invoice fraud in SRM”
Involved in project “Fraud Detection in
SRM”
Involved in project “Fraud Detection in
SRM”
Involved in project “Fraud Detection in
SRM”
Involved in project “Fraud Detection in
SRM”
Project lead FRODO
Author of thesis “Conception and analysis
of methods for detecting and preventing of
invoice fraud in SRM”
Project lead FRODO
Comments
A - 25
Services
GCP
Platform
Change
Documents
XI
Martin
Pascal
Rogge
Hochwarth
Joachim
Helmut
Mueller
Bender
Stephan
Ritter
Raja
Krishnamoorthy
Oliver
Andreas
Huppert
Welzel
Martin
Guenther
Achim
Dirk
Meier-Barthold
Kraiss
Kai-Uwe
Pielka
Jens
Frank
Klingl
Kaiser
Alexander
Stephan
Bundschuh
Wollny
D020094
D031154
D021862
D022323
D020760
D024817
D038015
D041507
I022374
D020682
D026369
D026048
D002671
D029075
I028930
D040407
Development Manager ESI Tools
Developer AP/SRM
Developer Org Management
Developer ESI UI
Development ESI UI
Developer Manager ESI Core
ESF
Development Manager ESI Core
ESF
Developer ESI Core ESF
Development Manager PCD
Solution Architect PCD
Solution Management PCD
Solution Management PCD
PM PCD
Consultant XI
Knowledge Transfer XI
Developer AP/SRM
Involved in project “Fraud Detection in
SRM”
Author “Specification ESF Generic Consumer Proxy”
Author “Specification ESF Generic Consumer Proxy”
Analysis, preparation and visualization of
data for auditors
RIG APA
Involved in project “Fraud Detection in
SRM”
A - 26
Volker
Sascha
Stephan
Martin
Schott
Hafner
Jacobi
Wollny
Hartig
Service
Interfaces
ABAP
LCP
Rene
Helge
Roser
Soring
Analytics
Alexander
Peter
Rolf
Schumann
BI Accelerator
Carina
Schneider
Cedric
Ulmer
Stefan
Michael
Hoerisch
Biedenstein
San
Tran
XML/A
Rene
Roser
BW
Andre
Jagusch
Java
Anne
Andreas
Brossler
GDT
Anne
Jacobi
ESR
D029621
D039585
D024877
D038903
D041759
D027464
I024048
D025671
D031182
D039585
D038406
D030326
D040407
D030735
D032548
D029352
D033985
D030735
BI Content Development
Developer Analytics
PMO BI
Developer AP/SRM
Student AP/SRM
Developer BI
Researcher
Knowledge Transfer BI
Developer SRM
Developer Analytics
Developer ESI Tools
Developer ESI Core ESF
Developer AP/SRM
Developer ESI Core ESX
Developer AP/FIN/HCM
Developer AP
Developer AP/SRM
Developer ESI Core ESX
Specialist for BI, BW and Analytics
Involved in project “Fraud Detection in
SRM”
Project with BW
NW RIG EMEA, Specialist for BI Open
Hub Service
BW Specialist
Specialist for BI, BW and Analytics
Specialist for Java Client Proxy generation
Involved in project “Fraud Detection in
SRM”
A - 27
PIM
Wasim
Aharon
Avitzur
Sanjay
Poonen
Sadiq
Michaela
Degbeon
Developer AP/SCM
Senior Researcher
SVP Analytics
BI Content Development
Table F.1: SAP Contacts
I031688
I025248
I810461
D027219
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 concerning 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 access 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 concept 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 management 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 applications.
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 systematical 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 infrastructure 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 Corporate 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
http://www.kpmg.com.au/.
2004,
2004.
Available
via
[KPM06] KPMG. Studie 2006 zur Wirschaftskriminalität in Deutschland,
2006. Available via http://www.kpmg.de/.
[MBCV06] George Mohey, Peter Best, Andrew Clark, and Julien Vayssière.
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 Monitor, 2005.
[SAP06a] SAP AG. MDX as basis for the interfaces, September 2006. Available via http://help.sap.com/saphelp nw04/helpdata/en/start.htm
– SAP Library – SAP NetWeaver – Information Integration – SAP
Business Information Warehouse – Additional Development Technologies – 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’, February 2006.
[SAP06d] SAP AG. Unit 1: Architecture overview. Application Platform
Architecture Basics. July 2006. Available via SAP Corporate Portal – 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 Basics. 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 Vayssière. 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
http://de.wikipedia.org/wiki/Enron, August 2006.
via
[Wik06c] Wikipedia.
MCI
worldcom.
Available
http://de.wikipedia.org/wiki/WorldCom, August 2006.
via
[Wik06d] Wikipedia.
Sarbanes-Oxley Act.
http://de.wikipedia.org/wiki/SOX, August 2006.
via
Available
[Wik06e] Wikipedia.
Serviceorientierte Architektur.
Available via
http://de.wikipedia.org/wiki/Serviceorientierte Architektur, August 2006.
[Wol05]
Stephan Wollny. Implementation of the business object ‘SupplierInvoice’ and its services according to the enterprise services architecture. 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. Available 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 highlighted 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