Detecting Fraud Patterns Using Data Obtained from the ...bpt.hpi.uni-potsdam.de/pub/Public/NicoHerzberg/Thesis_Nico_Herzberg.pdf · This diploma thesis “Detecting Fraud Patterns

Detecting Fraud Patterns Using Data

Obtained from the Application

Platform

Diploma Thesis

for the examination as

Graduate Engineer (University of Cooperative Education)

in Information Technology studies

at the University of Cooperative Education Karlsruhe

written by

Nico HerzbergMatr.-Nr. 122492

September 2006

Duration 3 months

Course TIT03VNS

Company SAP AG

Walldorf

Company Supervisor Dr. Julien Vayssiere

University Supervisor Prof. Dr. Heinrich Braun

University of Cooperative Education Karlsruhe

SAP Research CEC Brisbane

Diploma Thesis

Detecting Fraud Patterns Using

Data Obtained from the

Application Platform

Company Supervisor Dr. Julien Vayssiere

University Supervisor Prof. Dr. Heinrich Braun

written by

Nico HerzbergMatr.-Nr. 122492

September 2006

c©2006 Nico Herzberg

Non-Disclosure Note

The following diploma thesis contains confidential data of SAP Australia Pty

Ltd and SAP AG. Publication or duplication of this diploma thesis - or just in

extracts - is strictly prohibited without explicit permission of SAP Australia

Pty Ltd or SAP AG. This diploma thesis is only to be made accessible to the

correctors as well as the members of the examination board.

III

Abstract

The ability to help SAP customers prevent and detect fraud is a growing issue

for SAP, mainly because of recent regulatory changes, such as the Sarbanes-

Oxley act, and also because, in many business areas, software is replacing hu-

mans and operates on business data automatically. The SAP Research project

FRODO aims at investigating fraud detection in SAP applications.

The object of my investigation is SAP’s new Application Platform. The Ap-

plication Platform is based on the Service-Oriented Architecture concept and

provides different Business Object data sources and access methods to this

data. Investigated data sources are the Business Objects themselves and the

Technical Object ChangeDocument. The access methods identified include

core and compound services as well as the Business Information Warehouse

and the use of an own FRODO Business Object. The investigation targets on

possibilities of accessing data from the Application Platform in order to detect

fraud on it. A methodology is developed and used for the investigation to select

the best solutions. The most promising solutions, namely accessing the Tech-

nical Object ChangeDocument using its core services and accessing Business

Object data via Business Information Warehouse using XML for Analysis, are

implemented in Java for further validation. Based on these implementations

some discussions are made. A comparison to the R/3 prototype of FRODO

transpired that there are no serious differences at the moment, because in all

versions the data has to be extracted by hand.

Thus, further questions, problems and new ideas exist. Further development

on the FRODO prototype targets on real-time fraud detection and therefore,

the implemented access methods have to be verified for that focus.

IV

Kurzreferat

Finanzbetrug zu vermeiden und zu erkennen gehort heute zu den Anforderun-

gen von Kunden an SAP Systeme. Dies fundiert erstens auf neuen Gesetzge-

bungen, wie zum Beispiel dem Sarbanes-Oxley Act aus den USA und zweitens

auf der Tatsache, dass Software mehr und mehr den Einfluß des Menschen in

Geschaftsprozessen verdrangt. Das SAP Research Projekt FRODO untersucht

aktive Betrugserkennung in SAP Anwendungen.

Untersuchungsgegenstand dieser Arbeit ist SAP’s neue”Application Platform“,

welche auf dem Konzept der Service-Oriented Architecture aufbaut. Rele-

vante Daten sind in den Business Objekten selbst und im Technischen Objekt

ChangeDocument verfugbar. Als Zugriffsmethoden sind Core und Compound

Services, sowie das Business Information Warehouse und ein eigenes FRODO

Business Objekt identifiziert. Die Untersuchungen zielen auf die Moglichkeit,

auf Daten der”Application Platform“ von außen zugreifen und damit Be-

trugserkennung gewahrleisten zu konnen. Um die besten Losungen identi-

fizieren zu konnen, wurde ein Vorgehensmodell entwickelt und wahrend der

Untersuchung verwendet. Die Strategien”Zugriff auf ChangeDocument uber

Core Services“ und”Zugriff auf Business Objekt Daten uber das Business In-

formation Warehouse unter Verwendung von XML for Analysis“ sind in Java

implementiert, um sie besser bewerten zu konnen. Auf Basis der Programme

konnen diverse Diskussionen gefuhrt werden. Der Vergleich zum R/3 FRODO

Prototypen zeigt im Moment keine Verbesserung auf, da in allen Losungen die

Daten per Hand extrahiert werden mussen.

Folglich bestehen noch viele offene Fragen, Probleme und neue Ideen. Der

Fokus von FRODO wird in Zukunft auf Betrugserkennung in Echtzeit zielen.

Fur diese Anforderung mussen die implementierten Zugriffmethoden bewertet,

gegebenenfalls angepasst oder gar verworfen werden.

V

Preface

This diploma thesis “Detecting Fraud Patterns using data obtained from the

Application Platform” was written in the context of my studies in Informa-

tion Technologies at the University of Cooperative Education Karlsruhe in

cooperation with SAP AG and SAP Australia Pty Ltd. The thesis represents

the results of the research effort conducted from June 5th to September 8th,

2006.

Working on the diploma thesis was a challenging task since it required an

in-depth understanding of a new concept that is being set up for the whole

development process of a software company. Due to the fact that there is only

a few pieces of written documentation available about the new architecture,

good cooperation with colleagues was required. Additionally, the conditions

are always exposed to changes and this makes work even more interesting.

Keeping up the pace and finishing the work on this project could not have been

realized without the support of many people. I hereby would like to thank

• Dr. Julien Vayssiere for great supervision and good teamwork during the

further development of the prototype

• Prof. Dr. Heinrich Braun for supervising me excellently as the represen-

tative of the university

• The AP/SRM team for supporting the whole project with experience

and knowledge as well as forwarding contacts

• The whole SAP Research team in Brisbane for a great time and a lot of

support

• All SAP colleagues, who supported me with information and experience

VI

Preface

• Christian Mockel and Philip Crow for checking the language

• My girlfriend Doreen Seifert and my family for supporting me and keep-

ing everyday life problems away from me

Brisbane, September 2006

Nico Herzberg

VII

Table of Contents

1 Introduction 1

1.1 Fraud and Fraud Detection . . . . . . . . . . . . . . . . . . . . 1

1.2 Motivation and Planned Work . . . . . . . . . . . . . . . . . . 4

1.3 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Basics and State-of-the-Art 7

2.1 Reference Scenario for Fraud Detection . . . . . . . . . . . . . 7

2.2 The FRODO Prototype for Fraud Detection in R/3 . . . . . . . 10

2.3 Realization of Service-Oriented Architecture at SAP: enterprise

SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4 Business Intelligence and SAP Business Information Warehouse 16

2.5 Structure of the Application Platform . . . . . . . . . . . . . . 18

2.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3 Specification and Exploration of Possible Access Methods 23

3.1 Investigation Methodology . . . . . . . . . . . . . . . . . . . . 23

3.2 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2.1 Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2.2 Access Methods . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.3 Identifying Concrete Strategies and Classifying them . . . . . . 33

3.3.1 List of Possible Strategies . . . . . . . . . . . . . . . . . . . . . 33

3.3.2 Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.4 Ranking of Possible Solutions . . . . . . . . . . . . . . . . . . . 38

3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4 Implementation of Solutions 46

4.1 Accessing the TecO ChangeDocument by Using its Core Services 47

4.1.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.1.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

VIII

Table of Contents

4.1.3 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.2 Receiving BW Data of BOs Using XML for Analysis . . . . . . 53

4.2.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.2.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.2.3 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5 Validation 60

5.1 Validation of Test Results . . . . . . . . . . . . . . . . . . . . . 60

5.2 Comparison to the R/3 Solution . . . . . . . . . . . . . . . . . 62

6 Final Remark 63

6.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

6.2 Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6.3 Further Questions & Recommendations . . . . . . . . . . . . . 64

7 Summary 66

A Why the Application Platform? A - 1

B Process Integration Monitor (PIM) A - 4

C Generic Data Warehouse Solution A - 6

D Code for Accessing ChangeDocument Using GCPs A - 8

E Code for Accessing BW Using XML for Analysis A - 18

F Contacts A - 23

Glossary XVIII

Bibliography XXVII

IX

List of Figures

1.1 Scope of Project “Fraud Detection in SRM” . . . . . . . . . . . 4

1.2 FRODO Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1 Invoice Handling (based on [Vay06]) . . . . . . . . . . . . . . . 8

2.2 Invoice Handling with Duplicates (based on [Vay06]) . . . . . . 8

2.3 Suspicious Pattern of Financial Fraud (based on [Vay06]) . . . . 9

2.4 Structure and Function of FRODO [Vay06] . . . . . . . . . . . . 10

2.5 From Log File to Audit Trail [Vay06] . . . . . . . . . . . . . . . 11

2.6 FRODO’s Function with Composite Events (based on [Vay06]) . 12

2.7 Structure of SOA [Ebe04] . . . . . . . . . . . . . . . . . . . . . 14

2.8 Correlation between Technology Platform and Application Plat-

form [SAP06d] . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.9 Function of a Data Warehouse (based on [SAP04]) . . . . . . . 17

2.10 Structure of the AP (ESA - Big Picture) . . . . . . . . . . . . . 19

2.11 Integration Scenario Model of Reference Scenario . . . . . . . . 21

3.1 Investigation Methodology . . . . . . . . . . . . . . . . . . . . . 24

3.2 Services of a BO (based on [SAP06c]) . . . . . . . . . . . . . . . 29

3.3 FRODO on Top of BW . . . . . . . . . . . . . . . . . . . . . . . 30

3.4 MDX Example [SAP06a] . . . . . . . . . . . . . . . . . . . . . . 31

3.5 Strategy Overview . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.6 FRODO as a Completely External Solution . . . . . . . . . . . 36

3.7 FRODO with Components Inside the AP . . . . . . . . . . . . . 37

3.8 FRODO as an Element of AP/A1S . . . . . . . . . . . . . . . . 37

4.1 Waterfall Model for Development . . . . . . . . . . . . . . . . . 46

4.2 Implementation of GCP in the Big Picture . . . . . . . . . . . . 47

4.3 Program Sequence Diagram for Accessing ChangeDocument Using

GCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.4 Program Sequence Diagram for XML/A Solution . . . . . . . . 54

X

List of Figures

4.5 XML/A Solution in the Big Picture . . . . . . . . . . . . . . . . 55

5.1 Graph of Software Measurement Results . . . . . . . . . . . . . 62

A.1 From former IT to Process Innovation Technology (based on [Dit05]) A - 1

A.2 Paradigm from Automotive Industry [FMW06] . . . . . . . . . A - 2

A.3 Software Development in the Future [Red06] . . . . . . . . . . . A - 3

C.1 Structure of a Generic Solution . . . . . . . . . . . . . . . . . . A - 6

F.1 Contact Mind Map . . . . . . . . . . . . . . . . . . . . . . . . . A - 28

XI

List of Tables

3.1 Evaluation of Solutions . . . . . . . . . . . . . . . . . . . . . . . 32

3.2 Meaning of the Evaluation Symbols . . . . . . . . . . . . . . . . 39

3.3 Evaluation of Accessing BO Data Using Core Services . . . . . . 39

3.4 Evaluation of Accessing BO Data Using Compound Services . . 40

3.5 Evaluation of Accessing Data Using SAP BW on BO Data . . . 42

3.6 Evaluation of Accessing ChangeDocument Using Core Services . 42

3.7 Evaluation of Accessing ChangeDocument Using Compound Ser-

vices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.8 Evaluation of Accessing Data Using SAP BW on ChangeDocument

Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.9 Summary of all Strategies . . . . . . . . . . . . . . . . . . . . . . 45

5.1 High-level Measurement Results of the Software Validation Phase 61

B.1 Evaluation of Accessing Data Using PIM . . . . . . . . . . . . . A - 5

C.1 Evaluation of a Generic BW Solution . . . . . . . . . . . . . . . A - 7

F.1 SAP Contacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . A - 27

XII

Listings

2.1 Rules written in Jena Rules Language [Vay06] . . . . . . . . . . 12

2.2 Colloquial Rules [Vay06] . . . . . . . . . . . . . . . . . . . . . . 13

3.1 LCP Call of a BO Core Service in ABAP . . . . . . . . . . . . . 27

3.2 GCP Call of a BO Core Service . . . . . . . . . . . . . . . . . . 27

4.1 Structure of Connection Property File for Using GCP . . . . . . 50

4.2 Connection to the AP . . . . . . . . . . . . . . . . . . . . . . . 50

4.3 Section from BO Model Interface IChangeDocument.java . . . . 51

4.4 Code for Query Creation and Data Receiving . . . . . . . . . . 51

4.5 Response to SalesOrder Query . . . . . . . . . . . . . . . . . . . 52

4.6 SOAP Request to BI System . . . . . . . . . . . . . . . . . . . . 55

4.7 Property File for Connection to a BI System . . . . . . . . . . . 56

4.8 Connection and Data Sending in XML/A solution . . . . . . . . 56

4.9 Reference Data Structured in XML . . . . . . . . . . . . . . . . 58

4.10 SOAP Response of the BI System . . . . . . . . . . . . . . . . . 58

D.1 Main.java of XML/A Solution . . . . . . . . . . . . . . . . . . . A - 8

D.2 Main.java of XML/A Solution . . . . . . . . . . . . . . . . . . . A - 12

E.1 Main.java of XML/A Solution . . . . . . . . . . . . . . . . . . . A - 18

XIII

List of Abbreviations

A1S mySAP All-In-One/Service-Enabled

A2A Application to Application

ABAP Advanced Business Application Programming

AP Application Platform

B2B Business to Business

BI Business Intelligence

BIS Basis Information System

BO Business Object

BPP Business Process Platform

BW Business Information Warehouse

DU Deployment Unit

DW Data Warehouse

ESA Enterprise Services Architecture

ESI Enterprise Services Infrastructure

ESR Enterprise Services Repository

FI Financials

GCP Generic Core Service Consumer Proxy

HR Human Resources

HTTP Hypertext Transfer Protocol

XIV

List of Abbreviations

IDE Integrated Development Environment

ISV Independent Software Vendor

IT Information Technology

JDK Java Development Kit

LCP Local Client Proxy

MDM Master Data Management

MDX MultiDimensional Expressions

PC Process Component

PIC Process Integration Content

PIM Process Integration Monitor

RDF Resource Description Framework

RFC Remote Function Call

SAP Systems, Applications and Products in data processing

SOA Service-Oriented Architecture

SQL Structured Query Language

SRM Supplier Relationship Management

TecO Technical Object

TP Technology Platform

UI User Interface

WSDL Web Service Description Language

XML eXtensible Markup Language

XML/A XML for Analysis

XSD XML Schema Definition

XV

Notices to Typography and

Writing Conventions

Figures and Tables

The figures and tables used in this document are labeled and listed either

in the table of figures or in the list of tables. If figures or tables are taken

from other literature the source referring to the bibliography is given in the

label. Sources with the notation “based on” are taken out of literature and are

modified according to the author’s needs and the current knowledge status.

Listings

The used listings are labeled and listed in listings. They represent program

code most times. For explaining the code, the lines of listings are numbered

and are referenced in the text.

Abbreviations

Abbreviations are usually given in brackets after their initial use following

the written term they stand for. Additionally, they are listed in the list of

abbreviations at the beginning of this document.

Terms in Italics

Terms in italics are components of the Application Platform. This convention

is inline with the writing style of the documents in the ESA Architecture Series

2006.

Terms Written in Typewriter Style

Terms written in typewriter style are code or code components, e.g. JAR files

or class names.

XVI

Notices to Typography and Writing Conventions

Literature Indication

References to literature are given directly in the text or in squared brackets

by a reference which consists of the family name of the first author or the

name of the publisher and the year of publication. This reference is listed and

explained in the bibliography in detail.

Citation

Citations are presented in double quotes. The source of the citation is written

behind the citation according to the literature indication.

The Asterisk ∗

Terms highlighted with the asterisk are explained in the glossary at the end of

the document.

Words and Terms Written in Quotes

Words or Terms written in quotes are proper names.

XVII

CHAPTER1

Introduction

The topic “Detecting Fraud Patterns using data obtained from the Application

Platform” can be classified in the branch of Information Technology (IT) com-

bined with business background. More specifically, the Application Platform∗

(AP) is the core of the technology investigation. The AP is designed to build

application solutions by service compositions and follows the model-driven ap-

proach by using these services. The topic of financial fraud detection is at the

core of the business research. First of all, the definition and the background

on fraud and fraud detection are presented. In addition to that, research into

existing fraud detection projects is required as well as a plan for solving the

task at hand.

1.1 Fraud and Fraud Detection

A short definition of fraud is that it “is an intentional deception perpetrated

to secure an unfair gain.” [Onl06]. Fraud is a form of white collar crime and

one of the most often committed ones in Germany. Other forms of white collar

crime are stealing goods from stock or corruption for instance. White collar

crime makes up about half of all the financial damage of all registered crimes

in Germany. Over 70 percent of all German companies think that white collar

crime is a big problem and predict an increasing rate of those crimes in the

next few years. Some companies appraise their loss caused by fraud during the

last 3 years to over one billion Euro [KPM06].

1

1.1. Fraud and Fraud Detection

In most forms of white collar crimes, no IT system is involved. Examples such

as stealing from stock and corruption are independent from IT and therefore

are out of scope for SAP Research. At SAP Research especially financial

fraud is of interest, because in most of the scenarios, systems from SAP and

other software vendors are involved. Different perpetrators are possible. They

could come from internal ranks as well as from the external side. This type

of fraud is “pervasive throughout the economy and affects organisations of all

sizes” [MBCV06, p. 45]. In other words financial fraud is stealing money from

a company, for example

• Someone sends a fictitious invoice to the company and receives the money

into his account.

• An employee duplicates an invoice and receives the payback of the second

payment at his own account.

• A supplier sends excessive invoices which are always approved by the

same person in the company. This fraud scenario is a kind of collusion,

because internal and external culprits work together.

• Someone commits fraud in Human Resources (HR) by creating an arti-

ficial employee and getting the salary paid to themselves.

• Someone commits fraud while faking a supplier and approving invoices

for that supplier1.

54 percent of the Australians interviewed and New Zealand respondents of the

KPMG financial fraud survey had one or more fraud cases between 2002 and

2004. That created an average loss of AU$ 2.1 million per affected organization

[KPM04]. Governments also broach the issue of fraud and adopt some legal

fundamentals. After big financial frauds, like that of Enron2 or WorldCom3,

the pressure grew on companies and public organizations and consequently,

they have to develop and implement strategies against fraud. One example

for that is the Sarbanes-Oxley legislation in the US, which aims on ensuring

1 E.g. A senior executive of a German company stole over one million Euro with thisfraud method.

2 In 2000 Enron initiated one of the biggest company scandals in the US while committingfalsification of a balance sheet [Wik06b].

3 In 2004 WorldCom was involved in a stock market scandal while committing wrongentries of more than US$ 11 billion [Wik06c].

2

1.1. Fraud and Fraud Detection

the correctness of financial reports. It prescribes some methods of definitions

and descriptions of business processes and their controlling systems [Wik06d].

A second example is the Australian Fraud and Corruption Standard which

gives recommendations for fraud detection methodologies. The future trends

in software development will produce more complex and automated systems.

These new systems, however, will create new access points for perpetrating

fraud because human checks will be removed more and more. Thus, variety

and complexity of fraud is likely to increase in the future [MBCV06].

Fighting fraud is an issue to be dealt with and be carried out in three different

ways:

• Prevention

• Real-time detection

• Periodical analysis

Today, in SAP’s software, to meet future requirements, prevention is imple-

mented by segregating duties between roles. This means that different system

authorizations enable separation into different groups and roles. For example

it is possible to assign one HR employee to the role for creating employees

and another one to the role for approving these employee creations. Real-time

detection is not yet implemented, maybe it will be realized by one of the next

FRODO∗ versions. At the moment, fraud detection is still a mostly manual

task performed by auditors. They have the possibility to get support from the

Audit Information System∗, but this only helps with better reports and visual-

izations and not with an active detection of fraud patterns. Thus, responsible

employees have difficulties in working with the big amount of data produced.

In order to meet the demand for simple, effective and periodical or real-

time fraud detection in existing and future SAP products, SAP Research

proposes the research project called FRODO. The acronym FRODO stands

for “Fraud Detection in Open and Heterogeneous Environments”. On the

one hand, FRODO stands for a collaborative project with the Information

Security Institute of Queensland University of Technology. The project has

a cross-disciplinary approach which connects research in the branches of IT,

business and law. On the other hand, FRODO is a Java Web application pro-

3

1.2. Motivation and Planned Work

totype for fraud detection [Vay06]. This paper covers the technical side of the

FRODO project and thus the word “FRODO” will be used in the meaning of

the application prototype.

1.2 Motivation and Planned Work

The strategy of SAP is aligned with the requirements expressed by its cus-

tomers. At the moment, SAP’s approach is based on a Service-Oriented

Architecture∗ (SOA) for its new software products. This requires new develop-

ments and new products for replacing the old R/3∗ systems. But the current

prototype of FRODO works with data from SAP R/3 and is not up-to-date

with the new strategy. Another weakness is that FRODO only covers a few

fraud scenarios especially in the Supplier Relationship Management∗ (SRM).

Thus, an SAP internal project called “Fraud Detection in SRM” between the

department of AP/SRM and SAP Research was initiated. The work focused

on two points (highlighted in figure 1.1).

• Identification and prioritization of fraud scenarios in invoicing.

• Feasibility study that clarifies if it is possible to detect fraud with data

from services based on the new AP. In case of a positive result of the

studies, a mediator between FRODO and the AP should be implemented.

Figure 1.1: Scope of Project “Fraud Detection in SRM”

4

1.2. Motivation and Planned Work

The project “Fraud Detection in SRM” can also be seen as a validation of the

SAP’s Enterprise Service-Oriented Architecture4 (enterprise SOA)∗ , because

FRODO should act as an external tool and should use AP services. Thus, many

people pay a lot of attention to this project and therefore the outcome of the

thesis will be a demonstration of the strengths and weaknesses of enterprise

SOA.

The scope of this diploma thesis is the technical part of the collaborative

FRODO project between SAP Research and AP/SRM which demands for a

feasibility study about accessing the data stored in AP. Thus, the question is

how is it possible to connect FRODO with AP to develop an AP/A1S with

fraud detection (figure 1.2).

Figure 1.2: FRODO Objectives

Depending on the outcome of the feasibility study, an implementation of a new

version of FRODO may be required. This further development can be seen as

a mediator between mySAP All-In-One/Service-Enabled∗ (A1S) and FRODO

(see highlighted part in figure 1.1). Additionally, aspects like data volume,

performance and software effort should be investigated. Therefore, different

software solutions are required and a evaluation is demanded at the end of the

work.

4 The term Enterprise Services Architecture (ESA) has been renamed as Enterprise Ser-vice Oriented Architecture or enterprise SOA.

5

1.3. Methodology

1.3 Methodology

The work on the technology part of the project begins with searching and

defining a reference scenario (section 2.1) which is used for developing dif-

ferent solutions and secures a representative test and validation phase. The

next step is setting the fundamentals and the basics to understand the topic.

Therefore an orientation on the topics FRODO itself (section 2.2), enterprise

SOA (section 2.3), SAP NetWeaver∗ (section 2.3), SAP Business Intelligence∗

(BI) (section 2.4), and AP (section 2.5) is necessary. Afterwards, the research

begins with the identification of strategies for accessing the relevant data of the

application platform (section 3.2). Therefore, the usage of tools, like ARIS∗

and the Integration Builder∗ is necessary. These tools provide different views

of the AP and its objects. Every strategy will be explored and validated in

different investigation steps (section 3.3 and section 3.4). The most promising

access strategies will be polished and implemented (section 4). To compare the

different solutions (section 5.2), developing test scenarios is necessary to check

the implementations. Also the comparison with the R/3 prototype is discussed

(section 5.2). The work is concluded and some questions and recommendations

are given after the validation phase. Also the future of the FRODO project

is drafted with some words (chapter 6). A summary of the research results

finishes the technical part of the project “Fraud Detection in SRM” (chapter

7).

6

CHAPTER2

Basics and State-of-the-Art

Setting up the fundamental knowledge about relevant technologies and prod-

ucts is the first step towards developing new strategies for collecting data from

the AP. Therefore, it is necessary to understand the reference fraud scenario

in detail as well as the functioning of FRODO. Additionally, it is required

to know the basics about the technology environment which is given by SAP

NetWeaver and the AP.

2.1 Reference Scenario for Fraud Detection

The following financial fraud scenario will be used as a reference for the im-

plementation and research work presented in this document. As the example

is complex, three areas of business are touched. The first one is the Master

Data Management∗ (MDM). It is responsible for the central management of

master data, e.g. a vendor’s bank details. The other area involved is SRM.

This sector contains details about planning and controlling relationships with

vendors. One essential function is processing invoices of vendors. SRM offers

the opportunity to verify and approve invoices and after that, sending them to

the Financials∗ (FI) part of the system for payment.

The following figures show events along two timelines, also called audit trails,

one for the MDM and one for the SRM and FI areas5 together. Vertical arrows

5 For describing the scenario and for the work of FRODO it is not necessary to separate

7

2.1. Reference Scenario for Fraud Detection

represent single actions of the process. In the SRM line, the approval actions

on a received invoice are shown, including the FI conducted payment process.

The state of the vendor’s bank details is obtained from MDM.

The next diagram (figure 2.1) describes the normal situation when an invoice is

received in the SRM. After a time for verifying and approving the invoice, the

SRM system sends a payment request to FI. FI calls the MDM for retrieving

the bank details of the supplier. Finally, the payment is triggered.

Figure 2.1: Invoice Handling (based on [Vay06])

Figure 2.2 shows that an invoice was duplicated and paid twice.

Figure 2.2: Invoice Handling with Duplicates (based on [Vay06])

Duplicating invoices is not yet an act of fraud, because duplicating is used as

a regular operation for quickly setting up a recurring payment. An example

the SRM and FI in two audit trails.

8

2.1. Reference Scenario for Fraud Detection

scenario therefore is that a company receives screws for 10.000 Euro every

month and the invoice arrives as a letter. Thus, duplicate an invoice is more

efficient, instead of typing in all data every month. Another possibility is that

invoices appear as duplicates due to an error.

The pattern of Figure 2.3, however, is suspicious since at the moment of paying

the second invoice the vendor’s bank details were in a transitory state, namely

the bank details flapped. This is an indication that a third person is maybe

trying to receive the money of the second payment on another account.

Figure 2.3: Suspicious Pattern of Financial Fraud (based on [Vay06])

The analysis of the single audit trails of each system shows nothing suspicious.

The MDM part looks like a mistake made while changing data was reverted

after detection. In the SRM appears similar to the scenario described in figure

2.2. On closer examination of both trails with reference to the time, a possible

fraud becomes evident, because the second invoice payment happened while

the bank details were in a transitory state.

Now the question is, if this scenario is possible, since SAP systems enforce a

segregation of duties strategy. The ideal situation is that different employees

work either with master data or in SRM but not in both. In big companies

the strategy can be fulfilled and the employees who work with the MDM work

center are other people than the ones working in SRM. The situation in small-

size companies, however, is a different one; namely, that one person has the

9

2.2. The FRODO Prototype for Fraud Detection in R/3

authorization to create and change master data and the very same person is

also responsible for approving invoices. Collusion is another possible fraud

scenario, as the two people involved can have different roles.

2.2 The FRODO Prototype for Fraud Detection

in R/3

The two fundamental elements of FRODO are events and patterns. The events

differentiate themselves in through audit trails couched base events and com-

posite events. Figure 2.4 shows the structure and the function of FRODO.

Figure 2.4: Structure and Function of FRODO [Vay06]

The patterns are expressed in single rules by an user with expertise in financial

auditing. The financial auditor has the possibility to create new patterns based

on existing ones. These patterns describe a certain composition of base and

composite events. The system administrator has to export log files from the

different applications in the R/3 system, for example from SRM, MDM or

Customer Relationship Management. By parsing the log files and tables, event

10


streams are created. Figure 2.5 is an example for the log file structure. Every

log file line expresses one event on the audit trail.

Figure 2.5: From Log File to Audit Trail [Vay06]

Once all these event streams are in the same store, FRODO searches for

matches for the patterns. If in the timelines a set of events matches a pattern,

a composite event is created. As well as base events, this composite event can

be analyzed with the help of the event visualization portal. The portal allows

top-down investigations from general to precise. Thus, responsible people can

investigate both the base events and the found composite events. [Vay06].

For a better understanding of the function of FRODO, explaining FRODO’s

handling on the reference scenario is helpful. In the next figure (figure 2.6) the

fraud scenario and the composite events are shown. The timeline symbolizes

the event streams and every change in color stands for a single event (drawn

as dashed circles). The fraud detection in the shown example uses three differ-

ent patterns. The first one recognizes duplicate invoices and their payments.

The second pattern creates a second composite event which shows that the

bank details of a vendor were changed and reverted to the initial value after

some time. The third composite event detects a possible fraud by combining

composite events one and two.

11


Figure 2.6: FRODO’s Function with Composite Events (based on [Vay06])

The patterns for fraud detection are written in the cryptic looking Jena rules

language. Listing 2.1 shows the rules for the composite event “BankDetails-

Flapping” (composite event 2 in figure 2.6).

Listing 2.1: Rules written in Jena Rules Language [Vay06]1 ?e1[rdf:type → sap:VendorBankDetailsChangedAccountingEvent; sap:at → ?t1 ;

sap:bankDetails → ?bd ;

2 sap:clientID → ?client ; sap:vendor → ?vendor],

3 ?e2[rdf:type → sap:VendorBankDetailsChangedAccountingEvent; sap:at → ?t2 ;

sap:bankDetails → ?bdo ;


5 ?e3[rdf:type → sap:VendorBankDetailsChangedAccountingEvent; sap:at → ?t3 ;

sap:bankDetails → ?bd ;


7 le(?t1, ?t2),

8 le(?t2, ?t3),

9 notEqual (?bd , ?bdo),

10 makeTemp (?s)

11 →12 ?s[ rdf:type → sap:BankDetailsFlapping ; sap:firstFlap → ?e2 ; sap:secondFlap

→ ?e3 ; sap:startTime → ?t2 ;

13 sap:endTime → ?t3 ; sap:clientID → ?client ; sap:vendor → ?vendor ];

Colloquially, the rules are formed like the following example.

12

2.3. Realization of Service-Oriented Architecture at SAP: enterprise SOA

Listing 2.2: Colloquial Rules [Vay06]

IF two events of type VendorBankDetailsChanged

{are related to the same vendor AND

result in the second event reverting the bank details to the state it

was before the first event}

THEN create a new event of BankAccountFlippingEvent

2.3 Realization of Service-Oriented Architecture

at SAP: enterprise SOA

Eric A. Marks and Michael Bell claim that “Service-oriented architecture

(SOA) is a concept whose time has come” [BM06]. Primarily, SOA is a manage-

ment concept and basically the idea of aiming at higher flexibility on enterprise

IT infrastructure and lower the impact of change on the company. The con-

cept follows the idea that IT infrastructure should be aligned with business

processes. Processes should be composed with single functionality providing

building blocks. This helps companies to react faster on business changes by

replacing single building blocks of the process or restructuring the sequence of

the blocks according to a business process.

This requirement leads to the second meaning of SOA which defines the system

architecture concept. It describes that professional services and functionalities

have to be provided as single services. These services are applicable by stan-

dardized interfaces [Wik06e], they exist independently from each other, and

consequently, the business functionalities are well-bounded. For the descrip-

tion of the structure and interfaces of the services, the Extensible Markup

Language∗ (XML) standards are used. The communication between services

is realized by messages based on a standard communication framework.

Simply, a typical structure of SOA can be displayed with the following figure.

13


Figure 2.7: Structure of SOA [Ebe04]

The left hand side shows the service consumer’s request of functionality from

the service provider on the right side. The consumer calls a service of the

provider and may sends data as parameter of the request. After receiving

the results, the consumer uses these for further working. The intermediary is

optional and has different tasks. It can forward the original message or process

and change the message before forwarding [Wol05]. The important thing is

that consumer and provider communicate using service interfaces which are

described and known to each party. Mostly these interfaces are described with

Web Services Description Language∗ (WSDL) files6.

Now the question is why SOA is required. Business needs have evolved in

another direction over the past few years. If a company wants to be successful,

it has to be able to react quickly on business changes. With this ability,

enterprises can differentiate themselves from their competitors. Additionally,

the main goal of a company is to increase its productivity and saving money. As

a task of IT management is to decrease the Total Costs of Ownership reusing

already existing modules to compose and design new processes is of utmost

importance.

SAP meets this demand with a special implementation of SOA called the

enterprise SOA. Enterprise SOA follows industry standards, such as XML and

WSDL; thus, the architecture is open for customers and third parties. It

6 For further information see official W3C website to WSDLhttp://www.w3.org/TR/wsdl.html

14


follows the approach to start software development with modeling and going

down to implementation. In enterprise SOA, a development process begins

with specification and design through models and ends with code generation

and implementation.

Enterprise SOA is implemented in the Enterprise Service Infrastructure (ESI)

in SAP NetWeaver and is used in application building on ESI. The further

development of SAP NetWeaver as the Technology Platform (TP) and the AP

is based on ESI completely7.

For a better understanding of the premises of the thesis, knowledge of the

correlation between AP and TP is important. To simplify future software

architecture of SAP will look like the following figure (figure 2.8).

Figure 2.8: Correlation between Technology Platform and Application Platform[SAP06d]

The term Business Process Platform or the abbreviation BPP is often used in

different contexts in reference to AP and SAP NetWeaver. One opinion is that

it is the further development of SAP NetWeaver including a possible extension

by the AP [SAP06f]. Another thesis defines BPP as the combination of TP

and AP [SAP06d]. However, the use of the term BPP is avoided in this thesis,

because the meaning is not yet clear.

7 More details about the decisions for AP are written down in appendix A.

15

2.4. Business Intelligence and SAP Business Information Warehouse

The TP is represented by SAP NetWeaver. NetWeaver was introduced as in-

dependent integration and application platform for heterogeneous landscapes.

One task of SAP NetWeaver is to provide the communication layer for com-

posite applications∗. An important building block of the TP is the Enterprise

Services Repository∗ (ESR) which contains entries about all services of the

system as well as all models. ESR is the interface between SAP internal and

external applications and can be seen as a library for reusable components.

Among other things, it contains a list of available web services for internal and

external use. Additionally, SAP NetWeaver harbored other SAP components,

like the Enterprise Portal for instance.

2.4 Business Intelligence and SAP Business

Information Warehouse

One component of the TP SAP NetWeaver is BI. BI itself describes systems

and processes for analysis of a company. It consists of three phases. The first

one is the definition and inquiry of key data. This is realized with SAP Business

Information Warehouse∗ (BW) which holds the data on his own database in a

redundant way. Thus, it is possible to create a specific report for collecting data

from BO instances. The second phase is the combination of the collected data.

This is the task of Analytics∗ which provides pre-defined applications and the

environment with SAP Visual Composer to create own analytic applications.

In the third part the data have to communicate to the responsible people. This

is the task of the SAP Enterprise Portal, which provide all required things to

show the results in a UI [Wik06a].

BW is SAP’s product for Data Warehousing. Data Warehouses (DW) are

responsible to collect and store information from different sources at a central

point. Therefore, it is necessary to have a separate database. Thus, BW

provides the definition and the merge of key data by holding this data in a

redundant way. The sources can be operative SAP systems, other business

systems or external data sources. The reporting is located on top of SAP

BW. It is realized with reports or queries from the BW to format the data in

different ways. A typical example for such an analysis is the exploration of an

16

2.4. Business Intelligence and SAP Business Information Warehouse

inventory. With the analytical results the user can detect conspicuities and

abnormalities and can decide for special actions. This decisions and actions

are essential for a successful company [SAP04]. The general usage of a DW

can be show in a simple picture (figure 2.9).

Figure 2.9: Function of a Data Warehouse (based on [SAP04])

The possibilities of the BW can be summarized in the three points:

• Combination of data from different sources

• Overcoming of heterogeneous problems at different layers

• Preparation of data in a user friendly way

SAP BW consists of the two main components InfoObjects and InfoCubes.

The InfoObjects represent the business evaluation objects and the InfoCubes

are the data container. An InfoCube consists of data base tables which are

connected via the so-called star schema.

17

2.5. Structure of the Application Platform

2.5 Structure of the Application Platform

Since the AP structure is more interesting for the thesis purpose than TP and

BPP, a more explicit explanation is inevitable. In general, the AP can be

seen as a stock of predefined components. On the AP, the business logic and

process logic is defined separately. AP consists of small separated building

blocks. The smallest building blocks are the business logic representing BOs.

AP implements all of the processes. Thus, the definition also is given, when

which message has to be sent to whom.

At the AP, the biggest abstract building blocks are the DUs. They build an ab-

stract layer for flexible activation and deactivation of certain functional areas.

DUs are executable independently on different systems and they contain one or

more Process Components∗ (PCs), single BOs, engines or other components.

PCs group BOs in business-relevant and meaningful units. PCs themselves

are modeling entities which are reusable for process integration models and

integration scenarios. One PC is always assigned to one DU only, not across

DUs.

BOs contain the business logic and implement the main service providers.

Thus, they build the basic elements of business applications. BOs encapsulate

semantically related data together with BO logic and rules. They are accessible

through their service interface and are listed in the ESR. A BO can provide one

or more service interfaces. SupplierInvoice or Supplier are examples for these

uniquely identifiable business entities. SupplierInvoice for example belongs

to the PC Supplier Invoicing Processing, which is part of the DU Supplier

Invoicing.

To understand the structure and the elements of the AP in detail, another

view on AP is drawn in figure 2.10.

18


Figure 2.10: Structure of the AP (ESA - Big Picture)

SAP NetWeaver delivers the technical infrastructure on which the AP is based.

The dashed rectangle shows the two-layered AP. The Foundation Layer con-

tains the reusable PCs that are accessible from all DUs. Furthermore, this

layer includes master data, e.g. Supplier or Business Partner, and reusable

service components, such as pricing, date or time. The foundation is part of

every AP instance. In the application layer, the predefined processes can be

found.

All AP resources, like the BOs, are completely service enabled for UI, composi-

tion and process integration. For communicating with other services, the BOs

provide one or more service interfaces. Here, service means service interfaces

with their implementation offered by a concrete IT system. In other words,

such a service interface has one or more service operations, which means that

they can provide different functionalities. The service interfaces are callable

locally from other components of one DU or via messages from outside the AP

or other DUs.

The services are differentiated in the different service types:

• Core services∗

19


• Compound services∗

• Enterprise services∗

Core services access the BO directly and are used for internal communica-

tion in DUs. They provide generic functions such as reading data or saving

data. For example the BO SupplierInvoice implement the method Retrieve for

getting data from a BO instance. These generics are grouped in interface pat-

terns, e.g. Access or Query, with individually defined service interfaces. The

compound services are web services using core services and are usually used

for message-based process integration. These services secure the communica-

tion for Application to Application (A2A) and Business to Business (B2B)

communication, because core services are unsuitable for this type of com-

munication. For example SupplierInvoice provides a service interface called

SupplierInvoiceProcessingInvoicingIn for creating new invoices. The group of

enterprise services are compound services “used in the execution of a business

process step which has a significant meaning and impact for the business of

an enterprise” [XKS06, p. 12]. All of the provided compound and enterprise

services are listed in the ESR and all service interfaces are described in that

repository.

The communication between the different BOs is direct, if they communicate

with BOs of the same DU or of the Foundation Layer. Direct means, that

the communication type is synchronous and two-way. With two-way commu-

nications, the caller waits for a response and is blocked while accessing. Oth-

erwise, the communication works with messages as do BOs of different DUs

when communicating with each other. This communication is asynchronous

and only one-way.

In order to consolidate the knowledge the reference scenario should be drawn

as an integration scenario model out of the ARIS tool. This shows the involved

PCs, their DUs and their relevant communication channels. The figure below

(figure 2.11) shows the PCs involved in the reference example in the dashed

area. The Supplier Invoice Processing is triggered after an invoice arrived ei-

ther from Purchase Order Processing, from the Inbound Delivery Processing

or from the Customer Invoice Processing at the supplier. This PC executes

the verification and the approval of invoices. Afterwards, a Due Item Process-

20


ing can become necessary. During Payment Processing , the real payment is

triggered. All of the PCs call the Accounting PC eventually.

Figure 2.11: Integration Scenario Model of Reference Scenario

The whole business logic is hidden in the PCs and their BOs and the call to

master data for instance is not shown, because the Foundation Layer is called.

This call will be executed using a Local Client Proxy∗ (LCP) directly in the

coding. Only the process logic is shown in an abstract way by drawing the

different communications between the relevant PCs.

In conclusion, the business processes themselves are the user of the build-

ing blocks. They are controlled interplays between services and executions of

21

2.6. Summary

services to achieve a predefined business result. They can interact across ap-

plications, thus AP deliver ultimate flexibility. Eric A. Marks and Michael

Bell’s opinion is right and the time of SOA has come, because the needs of

the customers require simple and efficient business process oriented IT land-

scapes.

2.6 Summary

The based reference scenario for the research is a fraud scenario where MDM

and SRM in connection with FI are involved. The SAP’s customers require

for detecting such fraud scenarios, because in small enterprises the prevention

concept segregation of duties can not be implemented in an easy way like in big

companies. The FRODO project should cover this issue while working with

patterns to detect specified event combinations. Such patterns are expressed

with rules by people with financial expertise. The new prototype should work

in the environment of the AP and the new version of SAP NetWeaver as the

TP. The AP and the TP follows the implementation of SAP’s enterprise SOA.

The first product working on top of the AP is A1S for mid-size companies. The

AP itself consists of different hierarchical components. BOs are the smallest

building blocks and can be capsulated in PCs and/or in DUs. The BOs provide

their functionality as services which can be invoked in different ways depending

on the location of the consumer. The communication between these services is

realized with messages. Thus, the architecture provides many starting points

for getting data out of the AP.

22

CHAPTER3

Specification and Exploration of

Possible Access Methods

The aim of the feasibility study is identifying and exploring of strategies for

collecting data from the AP. The data has to be accessible from the external

software tool FRODO, because the approach of the FRODO project is to work

side-by-side with the AP, and not as a part of it. Thus, the deployment of

the FRODO prototype is similar to that of an Independent Software Vendor8

(ISV).

At the beginning of the feasibility study, a strategy using the Process Integra-

tion Monitor (PIM) was investigated. This investigation is explained in the

appendix B, because it became irrelevant for further work on the thesis, but

it lead to other strategies.

3.1 Investigation Methodology

While investigating the different strategies, a methodology became visible

which allows dividing the theoretical part in single steps to extract suitable

solutions.

8 ISVs are very important for SAP to build up an ecosystem to cover all costumer needs.The network is necessary, because SAP cannot fulfill all customer requirements. Forthat case, enterprise SOA enables partners to develop niche products.

23

3.1. Investigation Methodology

The first step is to identify which relevantdata exists (sources) and how this data canbe accessed (access methods).

Afterwards, all sources are systematicallycombined with the access methods and areinvestigated if accessing the data from out-side is possible.

The out-coming and suitable combinationsare listed and explained shortly.

Based on the list, classifying strategies indifferent groups is possible. These groupsallow the validation of the first require-ment. Changes on AP elements are notallowed.

On the base of the first validation the othergiven requirements has to be investigated.The strategies must fulfill the following re-quirements:• Collected data has to provide infor-

mation about changes in a BO in-stance and about its history.

• The transferred data volume shouldbe optimized and the performanceshould be acceptable.

• The software effort should be accept-able in initial implementation, main-tenance and administration.

The last step is to verify if the strategyrefers to the reference example. Finally,a decision has to be made which strate-gies should be implemented in order to testtheir practical behavior.

Figure 3.1: Investigation Methodology

24

3.2. Components

3.2 Components

According to the introduced methodology, identifying the data sources is nec-

essary as well as the access methods. Therefore, becoming acquainted with

the given AP and TP possibilities is inevitable. Afterwards, the data sources

can be combined with the access methods and these combinations can be val-

idated.

3.2.1 Sources

Business Objects

BOs are the basic elements of future business applications, because they con-

tain the business logic and implement the service providers. BO means an

object of the AP which holds and works on business data. In relation to the

reference scenario the important BOs are SupplierInvoice and Supplier. The

SupplierInvoice controls the payment obligation to pay the supplier for goods

received or services rendered. The BO SupplierInvoice belongs to the PC Sup-

plier Invoice Processing and the DU Supplier Invoicing [RWK06]. Supplier

contains information to identify the business partner rather the supplier. The

BO Supplier exists in the PC Business Partner Data Management which is

located in the Foundation Layer of the AP [Str05].

Platform Change Documents

A transaction is a record of changes done to a BO and is described by the time

stamp, the user account and the data changed. Thus, these changes have to be

logged for reproducing the change path and investigating the BO instance his-

tory. This requirement is covered by Platform Change Documents∗ [PKVC06].

The possibility to observe the changes is modeled and implemented as a Tech-

nical Object∗ (TecO), a special kind of a BO, with the name ChangeDocu-

ment. It exists directly in the Foundation Layer and does not belong to any

DU. ChangeDocument provides the enterprise SOA core services Retrieve, Re-

trieveByAssociation and Queries to read Platform Change Documents. At the

moment of current investigations, it implements only one compound service

for XML archiving.

25

3.2. Components

The creation of ChangeDocument items is called in a generic way during the

“After Save” activities by the ESI framework. Thus, during the development of

BOs no attention needs to be drawn on calling the TecO ChangeDocument to

create Platform Change Documents. After ChangeDocument is called from the

ESI, it uses the Retrieve and RetrieveByAssociation services to create before

and after images of the changed BO instance. Hence, the BOs has to provide

an implementation of the Retrieve and RetrieveByAssociation services, but

additional code is not required [PKVC06]. A1S provides a UI for configuring

the monitoring of BOs and their actions and displaying items. Therefore,

mandatory and optional settings are available. For every changed element of a

BO instance a change document line item is created, by which the possibility

is offered to reproduce the history of a BO instance.

The suitable data sources are the relevant BOs themselves, like Supplier and

SupplierInvoice, and the TecO ChangeDocument, which provides information

about data changes of BO instances.

3.2.2 Access Methods

Core Services

Core services are stateful and synchronous services that provide elementary

service operations on BO nodes. They represent the atomic functionalities of

the AP in a standardized way and wrap the business logic. As a consequence

of their standardization, they are not modeled in the ESR. Core services are

important for building up UIs, for example with Web Dynpro∗, and enable the

implementation of higher level A2A and B2B compound services. Examples

for such core service operations are finding instances or reading and modifying

instance data. These service operations are integrated in interface patterns,

like the Access interface. This interface delivers the operations Create, Re-

trieve, Update and Delete. The operations and their parameters are derived

from the BO node model and so generic core services can be offered. Thus, all

BOs can be handled in the same way and this provides the possibility to build

intelligent generic engines. Therefore, “Core services are generic and provide

each business object node with something like its own toolbox” [FMW06, p.

18]. Apart from Access, three other important interface patterns exists: As-

26

3.2. Components

sociation, Query and Action. Core services communicate only synchronously

with each other [FMW06].

Data can be accessed from a BO instance by using core services in general.

Usually, calls are realized by using a LCP and can look like the following

ABAP∗ code example (listing 3.1).

Listing 3.1: LCP Call of a BO Core Service in ABAP

1 CALL METHOD cl_esf_lcp_factory⇒get_lcp_facade

2 RECEIVING

3 out_lcp_facade = lr_lcp_facade.

4 ** get lcp

5 CALL METHOD lr_lcp_facade→get_lcp

6 EXPORTING

7 in_bo_name = /srmap/if_fnd_constants_bo⇒c_bo_po

8 RECEIVING

9 out_lcp = mr_lcp_po.

10 CALL METHOD mr_lcp_po→retrieve

11 EXPORTING

12 in_bo_node_name = /srmap/if_fndx_pd_template⇒co_bo_node -root

13 in_node_ids = lt_node_ids

14 IMPORTING

15 out_data = lt_po_root_nodes.

In the first step, the LCP facade is created by calling a function of a factory

class (lines 1 - 3 in listing 3.1). This LCP facade provides a method to get a

LCP (lines 5 - 9 in listing 3.1). Then, the LCP is used to access BO nodes

with a retrieve action (lines 10 - 15 in listing 3.1). Therefore, the BO node

name and the node IDs have to be transferred (lines 12 and 13 in listing 3.1).

The outcome is a list of the called BO nodes which contain actual data of the

BO instances (line 16 in listing 3.1).

The other way is to access the core services using Generic Core Service Con-

sumer Proxies∗ (GCP). This technology is also used by the UI of A1S. GCPs

enable Java applications to call core services from outside the DU by using Re-

mote Function Calls∗ (RFC) or SOAP∗. For such calls the user, e.g. FRODO,

needs authorizations for sending RFC or SOAP calls. Such a call looks like

the following code example.

27

3.2. Components

Listing 3.2: GCP Call of a BO Core Service

1 // Get connection

2 ConnectionData connectionData = getConnectionData ();

3

4 // Get a service facade instance establishing a connection with a backend

system

5 IServiceFacade serviceFacade = null;

6 try {

7 serviceFacade = ServiceFacadeFactory.createServiceFacade(connectionData , new

Locale("en"));

8 } catch (Exception e) {

9 e.printStackTrace ();

10 }

11

12 // Load the ChangeDocument BO model

13 IBOModel model = serviceFacade.getBOModel(ISalesOrder.ESR_NAME);

14

15 // Create a query

16 IQuery query = model.createQuery(ISalesOrder.Root.ESR_NAME , ISalesOrder.Root.

QUERY_HEADER_ESR);

17

18 // Execute Query

19 query.execute ();

20

21 // Get the results

22 IBONode node = query.getResultBONode ();

23

24 // Process input data

25 dumpBONode(node , IChangeDocument.Root.NAME + ": Only 5 records are returned");

26

27 // Close connection to the backend system

28 serviceFacade.close ();

After connecting to the AP (lines 2 - 10 in listing 3.2), the relevant BO model

is loaded (line 13 in listing 3.2). In this case it is the BO Model of ChangeDoc-

ument. Afterwards, a query is created and submitted to the AP system (lines

16 and 19 in listing 3.2). The query delivers data which can be processed in

the next steps (lines 22 and 25 in listing 3.2). At the end, the connection to

the backend system has to be closed (line 28 in listing 3.2).

Compound Services

Core services are too finely grained to be used directly for A2A or B2B com-

munication. Compound services are implemented individually for each BO

and enable A2A and B2B interfaces to access only the needed attributes and

actions. Thus, they are driven by the process needs and the access is limited

in data unlike the core services. Usually, compound services are not reusable

28

3.2. Components

services. Therefore, they are not limited at one BO, but may combine calls

to any number of BOs. In detail, they are the “implementation of the service

interfaces, the definition of the interface in the ESR and the corresponding ser-

vice configuration in the system providing the service” [SAP06e, p. 6]. Com-

pound services are implemented by using core services to access and modify

the business object instances. The compound service interfaces are modeled in

ESR and provide synchronous or asynchronous communication between service

consumer and provider. The services can be invoked from SAP and Non-SAP

application code. Figure 3.2 shows the context between core and compound

services [FMW06].

Figure 3.2: Services of a BO (based on [SAP06c])

The diagram (figure 3.2) shows that the compound services are the interface to

the PC’s external world. Other PCs from other DUs, composite applications

and a B2B Partner can access the business logic via the compound services

only. That compound services work internally by using core services becomes

visible. Thus, the separation is clear, a compound service is never a core service

and vice versa.

In general, using compound services is possible to collect BO data from external

tools. For using the compound services, service consumer proxy classes need to

29

3.2. Components

be generated. Such a class provides one callable method for every operation.

To develop a compound service, a service interface has to be modeled in the

ESR. Afterwards, a service provider in ABAP has to be generated. Only then

the BO can be accessed with LCPs. For the usage with Java, a client has to

be created for the service provider via WSDL.

SAP Business Information Warehouse

BW is one part of SAP BI and builds up the DW of SAP. BW collects and

stores information from different sources in one central point.

Figure 3.3: FRODO on Top of BW

Firstly, a suitable InfoCube is inevitable, either by using an existing one or

implementing a new one to ensure that the relevant data exists in the BW

database. The next step is the access to this data by the FRODO mediator

(see figure 3.3).

Data access is possible in three different ways. The first one is to copy the

needed data to FRODO’s limited data storage with the BW interface Open

Hub service. Therefore, a Open Hub destination has to be created in the BI

system. The second strategy is to implement the mediator of FRODO as an

analysis tool. This means that the mediator directly accesses the tables on the

30

3.2. Components

database. The third way is the usage of XML for Analysis∗ (XML/A). The

Multidimensional Expressions∗ (MDX) processor of the BI system provides a

usable basis for the XML/A interface. By using XML/A, the implementation

is very simple. Only a SOAP request has to be sent to the BI and a XML

file with the results can be received. The request can be designed with queries

written in MDX.

Such a MDX statement is similar to the Structured Query Language (SQL)

and consists of SELECT, FROM and WHERE parts (see figure 3.4).

Figure 3.4: MDX Example [SAP06a]

The SELECT definition looks a little bit different to a SQL statement, because

it is divided in ON COLUMNS and ON ROWS. With this statements the axes

can be defined. FROM and WHERE are equal to SQL; namely with FROM

the InfoCube is selected and with WHERE some filters are configured.

In figure 3.4 is shown, that the columns profit, document number and open

orders are selected with the specification of ON COLUMNS. These details are

shown for different locations which is specified with ON ROWS. The source

is a InfoCube with the name OD SD C03/SAP DEMO OLEDB. The data is

limited on time January and on location US with the WHERE statement.

31

3.2. Components

Own FRODO Business Object

A possible solution is the development of an own BO for FRODO, the task of

which is to access other BOs. After collecting the data, handling can happen

in two ways. On the one hand, the BO only combines the collected data and

provides it to an external application via the in-built compound service. On

the other hand, the BO can also analyze the data itself and present the results

in its own UI. The development of an own BO, however, is time-consuming and

the management effort is huge, because changes at the AP need to be approved

by the Process Integration Content (PIC) Council9 for the development.

Accessing the data sources is feasible by using core and compound services, as

well as using BW or an own BO for FRODO.

Matrix

To connect data sources with the access methods the different possibilities are

combined with each other (step two of the introduced methodology). The

combinations are drawn in table 3.1 and the entries refer to the solution list in

chapter 3.3.1.

Coreservice

Compoundservice

BW OwnFRODO

BOBO 1. 2. 3. 4.ChangeDocument 5. 6. 7. 8.

Table 3.1: Evaluation of Solutions

9 The PIC Council is the round table of integration experts from all development units.Their tasks are design of semantically correct interfaces and data types, ensuring inter-national standard, encouraging reuse of data types, establishing SAP-wide consolidationand improving the Integration Guidelines [SAP06b].

32

3.3. Identifying Concrete Strategies and Classifying them

3.3 Identifying Concrete Strategies and

Classifying them

Referring to the methodology, clearly defining all strategies, resulted from the

combination of data sources and access methods, and explaining them in a

short way is inevitable. Afterwards, the concrete strategies can be ordered in

different groups.

3.3.1 List of Possible Strategies

Bearing in mind general combinations, strategies can easily be defined.

1. Accessing BOs through their core services

Firstly, accessing the BOs via their core services is possible. Therefore,

GCPs can be used. The data can be queried by the interface pattern

Query and the received information can be provided FRODO in struc-

tured files. In relation to the reference scenario the BOs SupplierInvoice

and Supplier have to be accessed for instance.

2. Accessing BOs through their compound services

Accessing the relevant BO can happen using its given compound services.

Afterwards, working on the received data needs to be done, to filter out

the relevant information, if the information is available. In relation to

the reference scenario, using existing compound services is necessary, e.g.

from both SupplierInvoice and Supplier BO.

3. Accessing BO data over BW

Accessing the BW database to get the data of a BO instance and ex-

ecuting the analysis on this data is another option. For accessing this

data, BW provides three possibilities: XML/A, Open Hub or direct ac-

cess to database tables. Additionally, a generic solution is possible as

well. This solution works with an interface layer between FRODO and

BW and aims on a very generic approach with a regard to a future scope.

However, the implementation effort is too huge for this thesis. Thus, the

33


solution is not investigated but explained in appendix C in more detail.

4. Collecting BO data with an own FRODO BO

One strategy is to develop a special BO for FRODO which accesses the

relevant BOs over their core services. The FRODO BO itself can only

merge the data and provide it to the analysis part of FRODO outside

(solution 4a) with a compound service; or the BO executes the analysis

itself and provides the results to a UI which is part of A1S (solution 4b).

5. Accessing ChangeDocument via core services

One way to access the BO ChangeDocument can be to use its core ser-

vices. Therefore, the use of GCPs is possible. With that it is possible

to query relevant data with the use of suitable interface patterns, e.g.

Query. Afterwards, the data can be provided in structured files.

6. Accessing ChangeDocument via compound service

From outside, ChangeDocument can be accessed in two different ways;

one is to use the existing compound service for archiving and analyze the

out-coming XML file. The other one is to request a general compound

service for the TecO ChangeDocument or implement one. At the moment

of research, in SAP architecture departments, the additional compound

service is discussed.

7. Accessing ChangeDocument data via BW

Accessing the BW database is another possibility to get the data of

ChangeDocument and execute the analysis on that data. Therefore, the

access possibilities are using XML/A, Open Hub service or accessing the

database tables directly.

8. Accessing ChangeDocument via FRODO BO

Developing a special BO for FRODO for accessing the data from the

TecO ChangeDocument is also an option. The created BO uses the core

services of the ChangeDocument and forwards it either to the external

FRODO tool (solution 8a) or executes the analysis by itself and provides

the results to an UI which is part of A1S (solution 8b). These variants

are like solutions 4a and 4b.

34


Figure 3.5 shows all solutions to access the needed data.

Figure 3.5: Strategy Overview

3.3.2 Classification

FRODO takes in the role of an ISV product. ISVs should not be able to

change the AP. Additionally, the effort of receiving approval for a development

on AP from the PIC Council bears no relation to its use. According to the

based methodology, the identified solutions can be classified in three different

groups.

For reason of simplicity, the TecO ChangeDocument is not drawn separately in

the next diagrams and can therefore be regarded as a BO like the other BOs,

e.g. SupplierInvoice.

The first class describes solutions which only use existing services and compo-

nents of the TP or the AP. At the AP level the BOs provide core and compound

35


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


Figure 3.7: FRODO with Components Inside the AP

The third class describes completely new solutions.

Figure 3.8: FRODO as an Element of AP/A1S

They consist of a BO at the AP and an element in A1S. Thus, the detection

37

3.4. Ranking of Possible Solutions

logic is implemented in the BO and the old FRODO prototype is not used

anymore. Here, the results are displayed over the UI component in A1S.

Solutions 4b and 8b belong to class three. Strategies 4b and 8b use the FRODO

BO to analyze the data from the BOs and show the results in their own UI

located in A1S. The mentioned solutions are working without any external

application and consequently, the old FRODO prototype stands outside with

no functions relating to the AP.

According to the first requirement, claiming no changes on SAP internal devel-

opments, only the solutions of class one are possible. Thus, the more detailed

investigations target on the solutions using core and compound services or

BW either on BOs or on ChangeDocument in concordance to the other re-

quirements.

3.4 Ranking of Possible Solutions

Step three of the investigation methodology ranks the possible strategies based

on three features.

• Firstly, the collected data must provide information about changes of the

BO instance. Important information is for instance the responsible user

and the time of change. The reference scenario requires for collecting

information about the times of changing bank details and the person

who did the changes in the master data.

• Secondly, transferred data volume and performance should be in an ac-

ceptable range. FRODO’s current approach is to serve as a tool for

periodical analysis. Thus, the data volume is huge after a few weeks or

months, whereas a productive system’s data volume needs to be held as

small as possible.

• A third criterion should be the software effort. The effort can be regarded

from three different views. One is the initial effort to implement a running

solution. The second view is investigating maintenance costs while the

software is running. These costs consider the effort if the product needs

38


bug-fixing or if the solution is used with other platforms or other data

sources. The last point of view should be the administration. FRODO

should quickly be working with new scenarios without much additional

effort.

The in the last investigation (see chapter 3.3.2) identified solution should be

evaluated in tables. Every criterion is evaluated by symbols shown in the

following table.

Evaluation MeaningCriterion is dissatisfyingCriterion is acceptableCriterion is fulfilled in a good wayCriterion is not appreciable and needs evaluation in a practical test

Table 3.2: Meaning of the Evaluation Symbols

Accessing BOs Using their Core Services

Core services are not useful for FRODO’s approach, because they only return

the current state of the BO instance but no information about changes and

history. Data volume and performance are in an optimal range, because with

the Query interface pattern only required data can be requested. The initial

implementation effort is in an average range. On the one hand, core services

are called and so only the mediator has to be implemented, but on the other

hand, FRODO needs authorization to call the BO’s core services. This requires

for every fraud scenario a huge effort in maintaining the authorization for a

special FRODO user.

Requirement EvaluationInformation about changes and historyData volume & PerformanceSoftware effortUsable for FRODO

Table 3.3: Evaluation of Accessing BO Data Using Core Services

39


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.


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


If the volume is small, the strategy is good, because data is available in

XML format. However, if the volume becomes bigger it is not the best

solution. The reason is the property of XML files, because the overhead

multiplier of such a file can be between 10 and 1,000 compared to the

needed data. By using XML/A, the implementation is very simple. Thus,

the initial software effort is small for this solution, because the program

has to create the SOAP request only and has to parse the received XML

file. For new scenarios new BW sources have to be searched and new

MDX queries have to be written. Thus, maintenance and administration

effort is minimal.

• The second strategy using the BI Open Hub service is acceptable, be-

cause transferred volume and performance is average. Using this variant,

FRODO has more or less its own DW. This may grow with the further

developments on project FRODO if FRODO is going to be used with

other data sources from other vendors. The initial effort is acceptable

since an Open Hub destination has to be created in the BW for every

data source. Therefore, for every new scenario the relevant BW database

tables have to be identified. The Open Hub service provides all techni-

cal background and hence implementation is very simple with further

maintenance and administration expenses in an acceptable range.

• The last solution, namely direct access to the BW database tables, pro-

vides the best value in transferred data volume and performance. There

is no effort with FRODO special data mining. The BW might have to be

configured to have the relevant data in the BW database. The initial soft-

ware effort is acceptable, because access methods for the different data

sources have to be implemented. For every new scenario on the other

hand, relevant data has to be searched in the BW and new access meth-

ods have to be implemented. Thus, the maintenance and administrative

effort is huge and not acceptable.

The most promising solution in this strategy area is accessing BW via the

XML/A interface, because it is very simple to implement. The other solutions

are applicable for FRODO but require for more implementation effort.

41


Requirement EvaluationXML/A

EvaluationOpenHub

Evaluationdirectaccess

Information about changes and historyData volume & PerformanceSoftware effortUsable for FRODO

Table 3.5: Evaluation of Accessing Data Using SAP BW on BO Data

Accessing ChangeDocument via Core Services

Using core services for accessing the TecO ChangeDocument is another op-

tion. ChangeDocument provides, like all BOs, some interface patterns, like

Query. Query enables applications to query relevant data from different BO

instances. Thus, data volume and performance are optimal. The task of

ChangeDocuments is to store and provide information about the history of

several BO instances. The usage of the TecO ChangeDocument is exactly the

strategy which completely targets at the approach of the FRODO project. The

implementation is simple, because only a query has to be submitted from a

Java application. For different scenarios only different queries have to be sub-

mitted and the receiving data should be presented in structured files. Thus,

maintenance and administration requires only for a few effort, because only

the Java application is the point where new requirements regarding to new

scenarios and new data sources have to be fulfilled.


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


Accessing ChangeDocument Using a Compound Service

The solution of implementation using a compound service is another good

strategy in the field of using the TecO ChangeDocument. The requirements

information about changes and history, data volume, and performance are ful-

filled in the best way. The existing compound service for XML archiving cannot

be used for the FRODO approach, because it is not accessible from outside.

The service is an outbound interface and so it is only triggered directly from

the BO and not from outside. Thus, the creation of an additional compound

service should be discussed. The discussion handles topics like the missing

security concept for such a compound service. Other development teams are

also interested in having such a service to access ChangeDocument data from

outside of the AP. For the new compound service the software effort is huge,

because it has to be encroach upon the AP. For the new compound service a

new service interface has to be modeled in the ESR and the underlie service

provider has to be implemented. For new scenarios, the filter for received data

has to be modified only. As a consequence, maintenance and administration

is minimal.


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


Accessing ChangeDocument Data via BW

Accessing the data of ChangeDocument from outside the AP is also possible

with BW, but for ChangeDocument a new InfoCube has to be developed.

Developing an InfoCube requires huge effort in management and development.

Thus, the initial implementation effort is very huge. Maintenance and admin-

istration, however, would be in an acceptable range, because only the filter in

FRODO has to be customized for new scenarios. Afterwards, all three BW

access methods can be used.

• The XML/A solution might have too much overhead, depending on the

data volume.

• Using the Open Hub solution is acceptable, but with this solution FRODO

has more or less its own DW.

• Direct access is the most promising access method in this area, because

it is the fastest and most optimal in data volume.

Requirement EvaluationXML/A

EvaluationOpenHub

Evaluationdirectaccess

Information about changes and historyData volume & PerformanceSoftware effortUsable for FRODO

Table 3.8: Evaluation of Accessing Data Using SAP BW on ChangeDocumentData

In this strategy area all solutions are acceptable, but the initial effort to develop

an own InfoCube for ChangeDocument is too huge and the ratio between effort

and use are not within acceptable parameters.

44

3.5. Conclusion

3.5 Conclusion

In the following table (table 3.9) the outcome of the previous investigations

should be summarized. According to the investigation methodology, some

solutions are selected for implementation.

Strategy Informationabout

changesand history

Datavolume &perfor-mance

Softwareeffort

Usable forFRODO

BOsCore serviceCompound service

BW

XML/AOpen HubDirect access

TecO Change DocumentCore serviceCompound service

BW

XML/AOpen HubDirect access

Table 3.9: Summary of all Strategies

After consolidating the research results, the implementation effort will focus on

the strategy to using the core services of the TecO ChangeDocument. Addi-

tionally, the possibility for accessing BW using the XML/A interface should be

investigated in more detail. The BW solution focuses only on accessing BOs,

because the development of a new InfoCube for ChangeDocument requires

too much effort.

45

CHAPTER4

Implementation of Solutions

The two most promising solutions now need to be implemented and evaluated

according to the following steps. The strategies are:

• Access the TecO ChangeDocument by using its core services

• Receiving BW data of BOs using XML/A

Each solution is implemented separately and the development follows the “Wa-

terfall Model” of software engineering as shown in figure 4.1.

Figure 4.1: Waterfall Model for Development

The specification and analysis phases were performed in the previous chapters

(dashed rectangles in figure 4.1), because they are very similar for all the strate-

gies. Thus, for every strategy, design, implementation and testing have to be

46

4.1. Accessing the TecO ChangeDocument by Using its Core Services

investigated (rectangles in figure 4.1). In the design phase, the access method

is made more concrete from a programmer’s perspective. The implementation

is the coding of the solution; highlights are described in detail. Afterwards,

the software has to be tested for correctness.

4.1 Accessing the TecO ChangeDocument by

Using its Core Services

Using core services of ChangeDocument is one implementation for accessing

data of BO instances. The software is designed in a theoretical way first.

Afterwards, the design is implemented and finally, the software is tested.

4.1.1 Design

For understanding how this approach solves the problem, it should be presented

in the big picture of the AP architecture.

Figure 4.2: Implementation of GCP in the Big Picture

47


The high-level overview of the software solution is drafted with a program

sequence diagram in figure 4.3.

Figure 4.3: Program Sequence Diagram for Accessing ChangeDocument UsingGCP

The access to the TecO ChangeDocument requires a connection to the backend

system. Therefore, a central point should be available, where the connection

can be configured. A property file is adequate for that and should contain data

about:

• Connection data service

• Host name

• System group

• System name

• Client

48


• User language

• User name

• Password

With this data the connection can be set up and the first step is completed.

Retrieving the right data should be realized with queries. After creating the

query for getting the relevant data, the query is sent to the backend system.

The client side is now able to receive the requested data. The received data

should be converted into a Resource Description Framework∗ (RDF) file. These

RDF files enable the current FRODO prototype to analyze the data and detect

fraud.

4.1.2 Implementation

The outcome of the design phase is implemented in Java by using the Integrated

Development Environment (IDE) SAP NetWeaver Developer Studio10. The

code is written according to the ESF Java Client example11. For running the

code beside the APIs provided by the Java Development Kit (JDK) 1.5, the

following JAR files are required. These are provided in the folders of the ESF

Java Client example.

cache.jar esf.base.metadata api.jar

com.sap.directory.runtime.container.mod api.jar esf.base.rpe.jar

com.sap.directory.runtime.mod api.jar esf.client.gcp api.jar

com.sap.directory.services api.jar esf.client.gcp core.api

com.sap.exception.facade.jar esf.client.smp.jar

com.sap.tc.cmi api.jar esi.metadata api.jar

esf.base.cds api.jar esi.metadata core.api

esf.base.edo api.jar logging.jar

esf.base.internal.jar sapjco.api

The connection is realized by the connection data service provided by the

10 SAP NetWeaver Developer Studio is based on Eclipse and is extended with functionalityaccording to SAP’s technologies and development guidelines.

11 Information and Sample code available at SAP BIS(https://bis.wdf.sap.corp/twiki/bin/view/Sapinternal/ESFEndToEndSamples)

49


ESF client metadata API. The connection parameters are configured with a

property file like the following listing 4.1.

Listing 4.1: Structure of Connection Property File for Using GCP

1 cds.channel=JCO

2 mshost=ldcias1.wdf.sap.corp

3 group=PUBLIC

4 r3name=AS1

5 client =100

6 lang=EN

7 USER=HERZBERGNI

8 PASSWD=thesis

In detail the connection set up looks like the following code. After getting

a connection data service from a factory, the service can be used to retrieve

generic connection data (lines 2 and 3 in listing 4.2). These generic data are

updated with the specific parameters from the property file (line 8 in listing

4.2). With that connection data a service facade can be instantiated and the

connection is set up (lines 11 - 16 in listing 4.2). Before building up the query,

a BO model has to be instantiated by using the service facade (line 19 in listing

4.2).

Listing 4.2: Connection to the AP

1 // Get Connection Data Service and generic Connection Data

2 IConnectionDataService cds = ConnectionDataServiceFactory.

getConnectionDataService ();

3 ConnectionData cd = cds.getConnectionData(ConnectionData.channelGeneric ,

ConnectionData.typeGeneric);

4

5 ...

6

7 // Add properties to the generic Connection Data

8 cd.putAll(props);

9


system


12 try {

13 serviceFacade = ServiceFacadeFactory.createServiceFacade(cd, new Locale("en"

));



16 }

17


50


19 IBOModel model = serviceFacade.getBOModel(ISalesOrder.ESR_NAME);

For instantiating a BO model, an interface of the BO has to be generated.

This can be realized with a Java application called BODescriptionGenerator.

The application is included in the sample project “esf.sample” provided in the

SAP Basis Information System (BIS). The interface describes the structure

of the BO model. The following figure shows a section of one of the inter-

faces, the whole code can be found in appendix D. In this case, the interface

IChangeDocument.java is shown in listing 4.3.

Listing 4.3: Section from BO Model Interface IChangeDocument.java

1 public interface IChangeDocument {

2 String NAMESPACE = "http :// sap.com/xi/AP/IS/PlatformChangeDocument/Global";

3 String NAME = "ChangeDocument";

4 IESRName ESR_NAME = ESRNameFactory.createESRName("ChangeDocument", "http

:// sap.com/xi/AP/IS/PlatformChangeDocument/Global");

5

6 // BO Node ChangeDocumentItem

7 interface ChangeDocumentItem {

8 String NAME = "ChangeDocumentItem";

9 IESRName ESR_NAME = ESRNameFactory.createESRName("ChangeDocumentItem", "")

;

10 ...

11 }

Afterwards, the query can be created and configured (lines 2 - 7 in list-

ing 4.4). The query is of the type IQuery and can be specified with meth-

ods like createSelectOption() (lines 6 and 7 in listing 4.4). Relevant at-

tributes can be identified with the BO browser delivered in the software project

“esf.samples”. After submitting the query with the method execute() (line

10 in listing 4.4), the received data is handled (line 12 in listing 4.4).

Listing 4.4: Code for Query Creation and Data Receiving

1 // Create a query

2 IQuery query = model.createQuery(IChangeDocument.Root.ESR_NAME.getFullName (),

IChangeDocument.Root.QUERY_QUERY_BY_BUSINESS_OBJECT_NAME_ANDID);

3 // Limit the number of results

4 query.setMaximumResultElements (5);

5 // Set query options

6 query.createSelectOption("ObjectTypeCode", ISelectOption.Operator.EQUAL , "

00001", null);

51


7 query.createSelectOption("ObjectId", ISelectOption.Operator.EQUAL , "00001",

null);

8

9 // Execute Query




In the implemented example, the received data is simply printed out to the

Java console. The whole software code is attached in appendix D.

4.1.3 Test

In the test scenario, retrieving some ChangeDocument data from a BO should

be possible, namely the data for the BO SupplierInvoice should be queried.

Due to the fact that the author has no authorization to access the development

systems and the sandbox systems do not provide real data of BO instances, the

execution of the software results that no data is available. Among other things

this causes in the fact that the TecO ChangeDocument is still in development.

The GCP implementation, however, is correct because the implementation

works with another BO, namely the BO SalesOrder. The response from the

system looks like the text in the following listing (listing 4.5).

Listing 4.5: Response to SalesOrder Query

Root: Only 5 records are returned

ID: 5000000675

TypeCode: SO

PostingDateTime: null

SystemAdministrativeData$CreationDataTime: 2006 -04 -27 06 :20:34 .0

SystemAdministrativeData$CreationSystemAccountUserID: T.P.KUMAR

SystemAdministrativeData$LastChangeDateTime: 2006 -06 -13 12 :30:09 .0

SystemAdministrativeData$LastChangeSystemAccountUserID: DEYS

SellerParty$SellerID: 5

BuyerParty$BuyerID: 6

Incoterms$ClassificationCodeContent: TES

Incoterms$TransferLocationName: null

TotalGrossAmount: null

TotalNetAmount: null

TotalTaxAmount: null

CurrencyCode: EUR

PurchaseOrderPostingDateTime: null

52

4.2. Receiving BW Data of BOs Using XML for Analysis

PurchaseOrderReferenceID: null

Status$AvailableToPromiseConfirmationStatusCode: 1

Status$AcceptanceStatusCode: 1

Status$InvoicingCompletionStatusCode: 1

Status$ArchivingStatusCode: 1

Status$LifeCycleStatusCode: null

...

4.2 Receiving BW Data of BOs Using XML for

Analysis

Accessing data of BW is possible with the use of the MDX processor given by

the BI system. After the design phase the ideas are implemented in Java and

tested with a test scenario.

4.2.1 Design

The usage of the MDX processor interface XML/A of the BI system is simple.

Firstly, a SOAP request has to be created. This request contains property

data, e.g. for formatting, and the MDX query. The MDX statement is the

main point in the SOAP request. The MDX query enables the software to

query the relevant data from an InfoProvider, e.g. an InfoCube. Afterwards,

the connection to the MDX processor has to be built up. This is realized with

a property file where the following data is configured:

• Host

• Port

• Client

• User

• Password

The request has to be sent to the MDX processor. The response of the backend

system is also in the SOAP format. The relevant data is provided in a struc-

53


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


Figure 4.5: XML/A Solution in the Big Picture

4.2.2 Implementation

For the implementation of the design requirements the IDE SAP NetWeaver

Developer Studio is used as well for writing Java code. In this case, JDK 1.5

provides all the APIs required.

To follow the program sequence, given in the design phase, a SOAP request is

built up. This is done by string concatenations, because no WSDL is available.

Only an example of a SOAP Request is provided by documentations. In this

string, the MDX statement is included. The SOAP request looks like the

following code (listing 4.6).

Listing 4.6: SOAP Request to BI System

1 <SOAP -ENV:Envelope xmlns:SOAP -ENV=’http: // schemas.xmlsoap.org/soap/envelope/’

SOAP -ENV:encodingStyle=’http: // schemas.xmlsoap.org/soap/encoding/’>

2 <SOAP -ENV:Body >

3 <Execute xmlns=’urn:schemas -microsoft -com:xml -analysis ’ SOAP -

ENV:encodingStyle=’http: // schemas.xmlsoap.org/soap/encoding/’>

4 <Command >

5 <Statement >

55


6 select [Measures ]. members on columns , non empty [0 VC_COUN ]. levels (1)

.members * [0 VC_REG ]. levels (1).members dimension properties

member_name , member_caption on rows from [$0 BWVC_C03] where ([0

FISCYEAR ].[ K41999 ])

7 </Statement >

8 </Command >

9 <Properties >

10 <PropertyList >

11 <DataSourceInfo >default </DataSourceInfo >

12 <Catalog >Foodmart 2000</Catalog >

13 <Format >Tabular </Format >

14 <ReturnCellProperties >true</ReturnCellProperties >

15 <AxisFormat >TupleFormat </AxisFormat >

16 <Content >SchemaData </Content >

17 </PropertyList >

18 </Properties >

19 </Execute >

20 </SOAP -ENV:Body >

21 </SOAP -ENV:Envelope >

Line six in listing 4.6 shows the MDX statement. The whole part where some

properties (lines 9 - 18 in listing 4.6) are set is not changeable by variables in

the program, only the fixed string can be changed.

After creating the SOAP request, the connection to the BI system is created.

Therefore, the URLConnection of the package java.net is used (lines 1 - 16 in

listing 4.8). The parameters of the connection are written down in a property

file like the following code (listing 4.7).

Listing 4.7: Property File for Connection to a BI System

1 host=ldcia1y.wdf.sap.corp

2 port =50085

3 client =100

4 user=DISPLAY

5 passwd=SHOWME

Listing 4.8: Connection and Data Sending in XML/A solution

1 URL url = new URL(readproperties("connectionString"));

2

3 // Set up the connection

4 URLConnection conn = url.openConnection ();

5

6 // Add user

7 conn.setRequestProperty("sap -user",readproperties("user"));

8 // Add password

56


9 conn.setRequestProperty("sap -password",readproperties("password"));

10 // Add property Accept -Encoding

11 conn.setRequestProperty("Accept -Encoding","gzip , compress");

12

13 // Connection requires output

14 conn.setDoOutput(true);

15 // Connect to the URL

16 conn.connect ();

17

18 // Define OutputStream

19 OutputStreamWriter wr = new OutputStreamWriter(conn.getOutputStream ());

20 // Send SOAP request to the server

21 wr.write(data);

22 wr.flush();

23

24 // Get response

25 BufferedReader rd = new BufferedReader(new InputStreamReader(conn.

getInputStream ()));

Additionally, setting the Hypertext Transfer Protocol (HTTP) header line

“Accept-Encoding” to “gzip, compress” (line 11 in listing 4.8) in the con-

nection configuration is recommended since some SAP systems are configured

to send out compressed data. However, if this is not allowed they deliver a

message that the host is replaced temporarily (HTTP error code 302) and the

real error message, which expresses the missing HTTP header, is hidden. Thus,

the host is not reachable and the connection failed.

After the connection, the data is sent with OutputStreamWriter (line 21 in

listing 4.8) and the response is received with the help of an InputStreamReader

(line 25 in listing 4.8). In the example, the received data is printed out on the

Java console.

4.2.3 Test

In the test scenario, information about invoices should be available. Again,

due to the fact that the author has no authorization to access a productive

system and the sandbox systems do not provide real data about invoices, the

execution of the software received only SOAP requests with an empty data

part.

Yet, the implementation still works with other systems and other MDX state-

57


ments, namely the QB8 system with a MDX query for sales data. The response

shows that also a XML Schema Definition (XSD) is delivered which describes

the XML structure of the reference data (lines 7 - 33 in listing 4.10). In the

section at the bottom the real data exists (lines 34 - 36 in listing 4.10). This

data are structured in XML and the data record for Australia for instance

looks clearly arranged like the following listing 4.9.

Listing 4.9: Reference Data Structured in XML

1 <row>

2 <C000000 >AUS</C000000 >

3 <C000001 >Australia </C000001 >

4 <C000002 >AUSNRD </C000002 >

5 <C000003 >AUS/NRD</C000003 >

6 <C000004 >49.996 ,60 DM</C000004 >

7 <C000005 >X</C000005 >

8 <C000006 >224 ,470 PC</C000006 >

9 <C000007 >0,3 PC</C000007 >

10 <C000008 >1</C000008 >

11 <C000009 >892 ,000</C000009 >

12 </row>

The whole SOAP response in this case looks like the following listing (listing

4.10).

Listing 4.10: SOAP Response of the BI System

1 <?xml version="1.0"?>

2 <SOAP -ENV:Envelope xmlns:SOAP -ENV="http: // schemas.xmlsoap.org/soap/envelope/"

SOAP -ENV:encodingStyle="http: // schemas.xmlsoap.org/soap/encoding/">

3 <SOAP -ENV:Body >

4 <ExecuteResponse xmlns="urn:schemas -microsoft -com:xml -analysis">

5 <return xmlns:xsd="http: //www.w3.org /2001/ XMLSchema" xmlns:xsi="http: //

www.w3.org /2001/ XMLSchema -instance">

6 <root xmlns="urn:schemas -microsoft -com:xml -analysis:rowset" xmlns:xsd=

"http: //www.w3.org /2001/ XMLSchema" xmlns:xsi="http: //www.w3.org

/2001/ XMLSchema -instance">

7 <xsd:schema xmlns="urn:schemas -microsoft -com:xml -analysis:rowset"

targetNamespace="urn:schemas -microsoft -com:xml -

analysis:rowset" xmlns:xsi="http: //www.w3.org /2001/ XMLSchema -

instance" xmlns:xsd="http: //www.w3.org /2001/ XMLSchema"

xmlns:sql="urn:schemas -microsoft -com:xml -sql"

elementFormDefault="qualified">

8 <xsd:element name="root">

9 <xsd:complexType >

10 <xsd:sequence minOccurs="0" maxOccurs="unbounded">

11 <xsd:element name="row" type="row" />

12 </xsd:sequence >

58


13 </xsd:complexType >

14 </xsd:element >

15 <xsd:simpleType name="uuid">

16 <xsd:restriction base="xsd:string">

17 </xsd:restriction >

18 </xsd:simpleType >

19 <xsd:complexType name="row">

20 <xsd:sequence minOccurs="0" maxOccurs="unbounded">

21 <xsd:element name="C000000" type="xsd:string" sql:field="[0

VC_COUN ].[ LEVEL01 ].[ MEMBER_NAME]"/>


VC_COUN ].[ LEVEL01 ].[ MEMBER_CAPTION]"/>


VC_REG ].[ LEVEL01 ].[ MEMBER_NAME]"/>


VC_REG ].[ LEVEL01 ].[ MEMBER_CAPTION]"/>

25 <xsd:element name="C000004" type="xsd:string" sql:field="[

Measures ].[0 VC_AMT]"/>


Measures ].[0 VC_DATE]"/>


Measures ].[0 VC_MAX]"/>


Measures ].[0 VC_MIN]"/>


Measures ].[0 VC_ORD]"/>


Measures ].[0 VC_ZHL]"/>

31 </xsd:sequence >

32 </xsd:complexType >

33 </xsd:schema >

34 <row><C000000 >AUS</C000000 ><C000001 >Australia </C000001 ><C000002 >AUSNRD </

C000002 ><C000003 >AUS/NRD</C000003 ><C000004 >49.996 ,60DM</C000004 ><C000005 >

X</C000005 ><C000006 >224 ,470 PC</C000006 ><C000007 >0,3 PC</C000007 ><C000008

>1</C000008 ><C000009 >892 ,000</C000009 ></row>

35 <row><C000000 >DE</C000000 ><C000001 >Germany </C000001 ><C000002 >DE BAW</C000002 ><

C000003 >DE/BAW</C000003 ><C000004 >1.102.729 ,84 DM</C000004 ><C000005 >X</

C000005 ><C000006 >1.134 ,620 KG</C000006 ><C000007 >0,9 KG</C000007 ><C000008 >

2</C000008 ><C000009 >297 ,000</C000009 ></row>

36 <row><C000000 >DE</C000000 ><C000001 >Germany </C000001 ><C000002 >DE BAY</C000002 ><

C000003 >DE/BAY</C000003 ><C000004 >1.068.745 ,64 DM</C000004 ><C000005 >X</

C000005 ><C000006 >1.183 ,430 KG</C000006 ><C000007 >0,6 KG</C000007 ><C000008 >

2</C000008 ><C000009 >293 ,000</C000009 ></row>

37 </root>

38 </return >

39 </ExecuteResponse >

40 </SOAP -ENV:Body >

41 </SOAP -ENV:Envelope >

59

CHAPTER5

Validation

The aim of the validation phase is to discuss the received results of the imple-

mented software. Additionally, the new solutions should be compared to the

R/3 solution of FRODO.

5.1 Validation of Test Results

Due to the fact that retrieving relevant data cannot be tested yet, the ac-

curacy of the data delivered by the different backend systems cannot be val-

idated. Nevertheless, the implemented software is tested with similar data.

Software measurements are not possible in detail, because the provided sand-

box systems do not have enough data to arrange representative data volume

and performance measurements. Thus, the quality of the software can only

be appreciated in a high-level way. Therefore, the test scenarios from the

previous chapter (section 4.1.3 and section 4.2.3) are executed 20 times and

the time from program start to program termination is measured in the Java

code directly by using the Date class from the package java.util.Date.The

recorded times are measurement results of the program executions on a lo-

cal computer in Brisbane (Australia) at a local time of 3.45 PM to 4.00 PM.

The backend systems are located in Germany. Thus, network times should be

considered as well. For instance a ping from Australia to Germany takes an

average time of 330ms. The results of the measurement are presented in the

next table.

60

5.1. Validation of Test Results

Run GCP solution XML/A solution1 20,760s 22,141s2 15,301s 12,818s3 15,312s 12,067s4 17,285s 12,087s5 15,322s 12,077s6 16,113s 18,116s7 15,312s 12,818s8 15,261s 12,808s9 15,352s 12,048s10 15,312s 12,057s11 15,412s 12,038s12 15,312s 12,788s13 15,332s 18,897s14 15,382s 12,788s15 15,322s 12,068s16 17,485s 12,798s17 15,372s 12,838s18 15,331s 12,067s19 15,412s 12,058s20 15,382s 12,849s

Average 15,854s 13,511s

Table 5.1: High-level Measurement Results of the Software Validation Phase

The average time of the GCP solution is approximately 16s and 13.5s of the

XML/A solution. Thus, the XML/A solution is more than 2 seconds faster.

On a closer look, the results seem conspicuous since the results of the GCP

solution are nearly constant and the results of the XML/A solution differ much

more. For that solution the peak time is 22s and the minimum is 12s. For a

representative conclusion further measurements with more and relevant data

are recommended. Known from experience, XML’s performance goes down

if the data volume grows. A definitive conclusion of the validation phase is

that retrieving data from the AP is possible with the help of the implemented

programs. For more lucidity, the measurement results are drawn in the next

graph (figure 5.1).

61

5.2. Comparison to the R/3 Solution

Figure 5.1: Graph of Software Measurement Results

5.2 Comparison to the R/3 Solution

In comparison to the R/3 solution, no serious differences are visible. In all

solutions the data has to be extracted by hand. By hand means in this case,

the use a given tools to extract data from a data source and store this in a RDF

file. Afterwards, the RDF files have to be imported in FRODO for detecting

fraud. Only the data sources are different. The old solution works with data

from R/3 systems. One implemented solution works with a kind of a BO of the

AP, specifically, the TecO ChangeDocument is directly called from outside.

The second implementation works with data from BW.

62

CHAPTER6

Final Remark

After the investigations, the gained results need to be discussed. Additionally,

the future of the FRODO project has to be outlined as well as ideas for further

investigations and further development.

6.1 Conclusion

In conclusion, accessing data from BO instances can be realized from outside

the AP. The working applications proof that AP is accessible from outside and

therewith, enterprise SOA successfully passed the validation mentioned in the

introduction (chapter 1), because SAP’s software architecture is ready for the

needs of ISVs and customers. Data can be retrieved from the AP using different

solutions (chapter 3.3.1). The most promising ones are implemented in simple

examples (chapter 4). The different technologies have their own characteristics

and thus, every solution has advantages and disadvantages. Before the very

first implementation were the numerous SAP technologies (chapter 2), each

with different data sources (chapter 3.2.1) and access methods (chapter 3.2.2).

Furthermore, the AP is still in development and therefore, AP is not ready

for projects like FRODO yet. It is comparable with Leonardo Da Vinci’s idea

of a helicopter. He even drafted that idea in detail, but the world and the

technology were not yet ready for such an ascent. Additionally, while creating

the thesis, many changes needed to be investigated. Projects like FRODO

always have low priority for colleagues involved in AP development, because

63

6.2. Outlook

they are necessarily more concerned with getting the AP running. Thus, the

initial focus of the thesis changed during the preparation. Focusing on the

implementation became less important, whereas attention was more and more

drawn on the different solutions and their possibilities.

6.2 Outlook

The focus of the FRODO project changed over the time, especially in the last

three weeks of preparing the thesis. For the next few months, investigations

will target on real-time fraud detection. The further development of FRODO

will draw attention on automating the steps, because FRODO still needs to

be supported with data manually. In order to become more user friendly, this

has to be changed. The usability will improve with further development effort

and the functionality will broaden. The generic BW solution in appendix C

should seriously be thought about as an object for another thesis.

Additionally, the implemented examples can also be used for projects with

other focuses. The examples show completely different ways of accessing data

from BO instances. The recommendations can be used for improving the

implementation of AP.

6.3 Further Questions & Recommendations

For further development, the question is if the two implemented solutions for

accessing data from AP are suitable for real-time fraud detection. Thus, the

question has to be answered, how real-time fraud detection can be realized.

On that matter, ideas exist on using the implementation to access the TecO

ChangeDocument via GCPs. For real-time detection repeating queries in

short periods is possible, because in this area real-time means reactions in

a time frame of one to five minutes. Another option would be to react on

event occurrences. Such events can rise either from ChangeDocument itself

or from a tool around ChangeDocument; PIM is recommended as the tool.

64

6.3. Further Questions & Recommendations

Additionally, another question is in which direction the development of the

TecO ChangeDocument will go, whether there will be new compound services

and a security concept for ChangeDocument or not. Another question aims

at the Generic BW solution (see appendix C), the potential of this solution

and if it can be used for real-time fraud detection.

65

CHAPTER7

Summary

FRODO is SAP’s research project targeting on the requirement for active fraud

detection in business systems. SAP stands at the beginning of a new software

era and thus, research projects have to be up-to-date. The task of the thesis

was to access data of BO instances from the AP.

The first step was to become familiar with the area of fraud and fraud detection;

understanding how the FRODO prototype works was indispensable. In order

to always have a reference, the example of fraud in SRM in connection with

MDM was introduced. Moreover, becoming acquainted with the different SAP

architectures and technologies was necessary. Thus, especially SAP NetWeaver

and the AP is introduced. Additionally, SAP BI was explained in general.

With the aim of finding good solutions for the implementations, a methodol-

ogy was developed and followed while investigating different solutions. The

first step was to identify data sources and access methods. Afterwards, the

combinations of both were investigated. While researching, different require-

ments were considered. The two most promising solutions, namely accessing

the TecO ChangeDocument using GCPs and accessing BW via XML/A were

concreted. The software was designed and implemented in small examples.

The two examples could be compared with each other and the results were

discussed. The working applications are the proof, that AP is also able to

provide data also for consumers from outside. Solving this problem created

significant effort due to the fact that AP is still in development. The new

66

SAP software architecture is not ready for projects like FRODO yet. Thus,

the topic provides more potential for interesting research and investigations.

Nonetheless enterprise SOA does ensure concepts for accessing the AP from

outside, like ISVs and customers will do in the future.

67

APPENDIXA

Why the Application Platform?

To understand the decisions for AP the new architecture should be shown from

the business point of view. Therefore, understanding the evolution of TP and

AP regarding the change from integration coding to business modeling (see

figure A.1) is necessary [Dit05].

Figure A.1: From former IT to Process Innovation Technology (based on [Dit05])

At the moment, the structure of application landscapes looks like the left di-

agram of figure A.1. SAP R/3 is also implemented according to this scheme.

Functional components are closed in packages and are hardwired to other sys-

tems. Hence, the process integration between different systems is hard coded

and thus they are inflexible. The User Interfaces (UI) are static objects placed

on top of the applications; the database is directly accessed by all components.

A - 1

All components are tight coupled to each other. In the future, software de-

velopment will be revolutionized by the new AP and the TP, which enable a

loose coupling of the components of a system.

AP is designed to build application solutions by service compositions and real-

izes that idea by the model-driven approach using services. Thus, SAP, ISVs,

and customers can implement new features and extend existing business pro-

cesses. Both platforms fulfill the SOA requirements and build the foundation

for SAP business solutions. The idea of AP is transferred from the automotive

industry. Today, many different car models are built with the same parts. For

instance in the Volkswagen group the different car types share up to 70 per-

cent of the parts, e.g. chassis and engines (figure A.2). The main difference is

the body of the cars. This saves a lot of money both in development and in

maintenance.

Figure A.2: Paradigm from Automotive Industry [FMW06]

More than 50 percent of the processes in SAP solutions are the same as well,

thus the paradigm from the automotive industry should be copied [FMW06].

With AP, the possibility is given to share parts which all solutions can use

together. Consequently, a final solution consists only of implementing the

body and connecting the single parts. The Invoicing functionality, for ex-

ample, is almost the same in Supply Chain Management systems, in Cus-

tomer Relationship Management systems and in Enterprise Resources Plan-

ning systems [SAP06f]. In the future AP will offer one Deployment Unit∗

(DU) Invoicing which is usable for any application, built on SAP NetWeaver

A - 2

and AP. With the TP and AP only, nothing will work because the content,

e.g. UI, composite applications and Analytics, are missing. The body based

on TP and AP plus customizing will represent the solution. Such bodies will

be created with a model-driven approach at lowest effort and time.

One of these bodies will be delivered with A1S. A1S is developed as a final

product for mid-size companies and has to deliver UI, composite applications

and Analytics. Composite applications consist of different functions of dif-

ferent sources, e.g. functionalities offered by the services. Thus, composite

applications are the predefined applications and the solution is ready with

individual configuration and small customizing effort. In order to influence

the process logic at one point only, the composite application and the UI of-

fer the possibility to arrange the different services. Analytics offers analytical

data concerning the business data and are embedded in the applications SAP

provides [XKS06].

Thus, software development is split into two parts, as the following graphic

(figure A.3) shows.

Figure A.3: Software Development in the Future [Red06]

There will be experts for developing new functionalities for the platform. In

detail, they will develop new Business Objects∗ (BOs) or will extend existing

ones. On the other side there will be developers for connecting business objects

to create composite applications as well as UIs.

A - 3

APPENDIXB

Process Integration Monitor

(PIM)

Another considered strategy for accessing data from BO instances of the AP

was the use of PIM, which is still a research project. PIM supports real-

time monitoring and enables exposing the actual process integration models

for various scenarios. Additionally, PIM compares them to the ARIS specified

process integration model for quality purpose. PIM enables the side-by-side

visualization of the A1S state and the ARIS model, which shows the actual flow

between DUs, PCs and BOs. Hence, the task of the monitor is to generate

representations of process integration maps for chosen business scenarios at

inter and intra DU level [SAP05].

PIM consists of two components the Monitor Observer and the Monitor Server.

It delivers an observer for every DU instance, which runs independently, scan-

ning for new interaction events. The observer also enables interaction event

queuing and is responsible for sending the events to the Monitor Server. The

server merges all posted events from the observers and notifies the front-end of

new events [SAP05]. PIM captures messages as well as LCP calls. Thus, it can

monitor all service calls whether they address core services or compound ser-

vices. Currently, PIM is still at the stage of development and the development

team is still experimenting with different ideas. One way is to use the ESF

trace, but this ESF feature has to be enabled in the system. Usually, the ESF

trace is switched off because it is very resource consuming. Thus, the developer

perform investigations on designing an own BO or using workflow events. The

A - 4

current implementation of PIM is based on the workflow solution.

Messages and LCP calls in general can be monitored and log files can be

built up for FRODO to use. Later, either an interface of the PIM core can

be used or the BO for PIM. But PIM recognizes only that an change event

happened, but cannot deliver data about the responsible action or user for

instance. Therefore, it is necessary to query the data in a second step. PIM

delivers some filter mechanisms and thus, the data volume and performance

would be acceptable, because it is a trade-off between event notification and

data retrieving. Additionally, the software effort is too huge to use this strat-

egy. Thus, the investigation stops after a shallow research.


Table B.1: Evaluation of Accessing Data Using PIM

Anyway, the experiences gained during developing PIM will help in finding

ways to access the given BO ChangeDocument without the existence of a com-

pound service. The developer tried different strategies but most of them were

too much of a hack and therefore do not conform to the AP model guidelines.

Additionally, PIM is under investigation for the real-time approach again, be-

cause event notification is important for that issue.

A - 5

APPENDIXC

Generic Data Warehouse

Solution

A generic solution for accessing data for detecting fraud is to be built according

to the following structure.

Figure C.1: Structure of a Generic Solution

The idea of the generic solution is to implement FRODO with an interface.

This interface follows a target structure. However, in one request only five

different fields are required, whereas in another request twelve fields are re-

quired. Therefore, the structure needs to be variable, because the size of the

requested database tables varies. Thus, the code of FRODO does not have to

be changed while connecting a new data source to FRODO. The target struc-

A - 6

ture should be flexible definable with something like a meta concept. This

enables FRODO to run simultaneously in different instances to solve different

fraud detections. In this case, the target structure has to be adjusted to the

data source. On the data source layer the system landscapes consist of differ-

ent databases and different data warehouses. Additionally, FRODO should be

able to work with flat files12. This heterogeneous situation must be mapped

to one target structure. Therefore, the data sources are described with single

descriptors. The descriptors are directly on top of the data sources and work

on this data directly. The effort of implementing a descriptor for every data

source can become a huge one. A solution for that problem will be the use of

meta data from the business logic layer to summarize some data sources. Thus,

the descriptors and the mapping layer are only responsible for the handshake

between data source and target structure. This offers the opportunity to map

the data to the target structure and FRODO is able to detect fraud with the

provided data.

This solution makes FRODO a generic fraud detection tool for every data

source. If a data source should be used, a descriptor has to be delivered.

This can be part of a customer’s tasks. A customer can also be an internal

department like SRM which would like to use fraud detection (solution idea

from Rene Roser).

This solution fulfills all requirements in an excellent way, except the software

effort. In detail the initial implementation effort is huge, but the solution is

very future-proof. Thus, a closer investigation is recommended, e.g. in another

thesis.


Table C.1: Evaluation of a Generic BW Solution

12 Flat file is a generic description of text file formats like CSV for instance. They areused to exchange data between systems in a simple structured way.

A - 7

APPENDIXD

Code for Accessing

ChangeDocument Using GCPs

Listing D.1: Main.java of XML/A Solution1 /*

2 * Access ChangeDocument via GCPs

3 */

4 import java.io.IOException;

5 import java.io.InputStream;

6 import java.util.Date;

7 import java.util.Locale;

8 import java.util.Properties;

9 import com.sap.dictionary.runtime.container .*;

10 import com.sap.tc.esf.cds.ConnectionData;

11 import com.sap.tc.esf.cds.ConnectionDataServiceFactory;

12 import com.sap.tc.esf.cds.IConnectionDataService;

13 import com.sap.tc.esf.gcp.api .*;

14 // import com.sap.tc.esf.test.refcase. ISalesOrder ;

15

16 /**

17 * This is a simple example to show , how is it possible to get data from

ChangeDocument .

18 * The connection settings are written down in single property files.

19 *

20 * Copyright (c)2006 SAP AG

21 *

22 * @author Nico Herzberg (D041659)

23 *

24 */

25

26 public class Main {

27

28 /**

29 * Main method

30 *

31 * @param args

A - 8

32 * Possible input parameters

33 */

34 public static void main(String [] args) {

35

36 // Get connection

37 ConnectionData connectionData = getConnectionData ();

38


system


41 try {

42 serviceFacade = ServiceFacadeFactory.createServiceFacade(connectionData ,

new Locale("en"));



45 }

46


48 IBOModel model = serviceFacade.getBOModel(IChangeDocument.ESR_NAME);

49

50 // Create a query

51 IQuery query = model.createQuery(IChangeDocument.Root.ESR_NAME.getFullName

(), IChangeDocument.Root.QUERY_QUERY_BY_BUSINESS_OBJECT_NAME_ANDID);

52 // Limit the number of results

53 query.setMaximumResultElements (5);

54 // Set query options

55 query.createSelectOption("ObjectTypeCode", ISelectOption.Operator.EQUAL , "

00001", null);

56 query.createSelectOption("ObjectId", ISelectOption.Operator.EQUAL , "00001"

, null);

57

58 // Execute Query




62

63 // Process input data

64 dumpBONode(node , IChangeDocument.Root.NAME + ": Only 5 records are

returned");

65

66 // Close connection to the backend system

67 serviceFacade.close ();

68

69 }

70

71 /**

72 * Method for getting connection data from the property file

73 *

74 * @return

75 * Data about the connection to one backend system

76 */

77 public static ConnectionData getConnectionData () {

78

79 // Get Connection Data Service and generic Connection Data

A - 9

80 IConnectionDataService cds = ConnectionDataServiceFactory.

getConnectionDataService ();

81 ConnectionData cd = cds.getConnectionData(ConnectionData.channelGeneric ,

ConnectionData.typeGeneric);

82

83 // Open property file

84 InputStream is = Class.class.getResourceAsStream("/AS1_connection.

properties");

85 Properties props = new Properties ();

86 try {

87 props.load(is);

88 is.close ();

89 } catch (IOException x) {

90 x.printStackTrace ();

91 }

92

93 // Add properties to the generic Connection Data

94 cd.putAll(props);

95

96 // Return Connection Data

97 return cd;

98 }

99

100 /**

101 * Method for handle the incoming data.

102 *

103 * @param boNode

104 * The business object node to be dumped

105 * @param text

106 * Description text of the dump

107 */

108 public static void dumpBONode(final IBONode boNode , final String text) {

109 System.out.println("\n" + text);

110

111 final int elementCount = boNode.size();

112 final int structSize = boNode.getDescriptor ().getDataStructure ().

getShallowStructureDescriptor ().size();

113 for (int i = 0; i < elementCount; i++) {

114 IBONodeElement element_i = boNode.getBONodeElement(i);

115 System.out.println ();

116 for (int j = 0; j < structSize; j++) {

117 System.out.println(" " + element_i.getDescriptor ().

getShallowAttributeDescriptor(j).getName () + ": "

118 + getContent(element_i.getAttributeValue(j)));

119 }

120 }

121

122 if (elementCount == 0) {

123 System.out.println(" no data available");

124 } else {

125 System.out.println("...............................");

126 System.out.println(" number of entries: " + elementCount);

127 }

128 }

A - 10

129

130 /**

131 * Get content for requested field

132 *

133 * @param value

134 * The descriptor of a field

135 * @return

136 * The value for the requested field

137 */

138 public static Object getContent(Object value) {

139 if (value instanceof ICctContainer) {

140 value = (( ICctContainer)value).getComponentValue("content");

141 }

142 return value;

143 }

144 }

A - 11

Lis

ting

D.2

:M

ain.

java

ofX

ML/A

Solu

tion

1import

com.sap.esi.esm.*;

2 3/**

4*

5*

Model

Descriptor

Interface

for

ChangeDocument.

6*

7*/

8public

interface

IChangeDocument

{

9String

NAMESPACE

="http://sap.com/xi/AP/IS/PlatformChangeDocument/Global";

10

String

NAME

="ChangeDocument";

11

IESRName

ESR_NAME

=ESRNameFactory.createESRName("ChangeDocument",

"http://sap.com/xi/AP/IS/PlatformChangeDocument/Global"

);

12

13

//

BO

Node

ChangeDocumentItem

14

interface

ChangeDocumentItem

{

15

String

NAME

="ChangeDocumentItem";

16

IESRName

ESR_NAME

=ESRNameFactory.createESRName("ChangeDocumentItem",

"");

17

//

IAssociation

ToRoot

18

String

ASSOCIATION_TO_ROOT

="ToRoot";

19

IESRName

ASSOCIATION_TO_ROOT_ESR

=ESRNameFactory.createESRName("ToRoot",

"");

20

//

IAssociation

ToParent

21

String

ASSOCIATION_TO_PARENT

="ToParent";

22

IESRName

ASSOCIATION_TO_PARENT_ESR

=ESRNameFactory.createESRName("ToParent",

"");

23

//

Query

QueryByNodeNameAndNodeID

24

String

QUERY_QUERY_BY_NODE_NAME_AND_NODEID

="QueryByNodeNameAndNodeID";

25

IESRName

QUERY_QUERY_BY_NODE_NAME_AND_NODEID_ESR

=ESRNameFactory.createESRName("QueryByNodeNameAndNodeID",

"");

26

IESRName

QUERY_QUERY_BY_NODE_NAME_AND_NODEID_INPUT_STRUCTURE_ESR

=ESRNameFactory.createESRName("

LineItemQueryInputParameter",

"http://sap.com/xi/AP/IS/PlatformChangeDocument/Global");

27

String

QUERY_QUERY_BY_NODE_NAME_AND_NODEID_BUSINESS_OBJECT_NODE_TYPE_CODE

="BusinessObjectNodeTypeCode";

28

String

QUERY_QUERY_BY_NODE_NAME_AND_NODEID_OBJECTID

="ObjectID";

29

String

QUERY_QUERY_BY_NODE_NAME_AND_NODEID_FROM_DATE_TIME

="FromDateTime";

30

String

QUERY_QUERY_BY_NODE_NAME_AND_NODEID_TO_DATE_TIME

="ToDateTime";

A - 12

31

//

Attribute

ChangeDocumentItemID(qualified

name,

esr

name)

32

String

_CHANGE_DOCUMENT_ITEMID_CCTS

="ChangeDocumentItemID";

33

IESRName

_CHANGE_DOCUMENT_ITEMID_CCTS_ESR

=ESRNameFactory.createESRName("ChangeDocumentItemID",

"");

34

//

Attribute

ObjectNodeTypeCode(qualified

name,

esr

name)

35

String

_OBJECT_NODE_TYPE_CODE_CCTS

="ObjectNodeTypeCode";

36

IESRName

_OBJECT_NODE_TYPE_CODE_CCTS_ESR

=ESRNameFactory.createESRName("ObjectNodeTypeCode",

"");

37

//

Attribute

BusinessObjectNodeFieldName(qualified

name,

esr

name)

38

String

_BUSINESS_OBJECT_NODE_FIELD_NAME_CCTS

="BusinessObjectNodeFieldName";

39

IESRName

_BUSINESS_OBJECT_NODE_FIELD_NAME_CCTS_ESR

=ESRNameFactory.createESRName("BusinessObjectNodeFieldName",

"");

40

//

Attribute

ObjectID(qualified

name,

esr

name)

41

String

_OBJECTID

="ObjectID";

42

IESRName

_OBJECTID_ESR

=ESRNameFactory.createESRName("ObjectID",

"");

43

//

Attribute

ParentObjectID(qualified

name,

esr

name)

44

String

_PARENT_OBJECTID

="ParentObjectID";

45

IESRName

_PARENT_OBJECTID_ESR

=ESRNameFactory.createESRName("ParentObjectID",

"");

46

//

Attribute

ModificationTypeCode(qualified

name,

esr

name)

47

String

_MODIFICATION_TYPE_CODE_CCTS

="ModificationTypeCode";

48

IESRName

_MODIFICATION_TYPE_CODE_CCTS_ESR

=ESRNameFactory.createESRName("ModificationTypeCode",

"");

49

//

Attribute

BusinessObjectElementOldContent(qualified

name,

esr

name)

50

String

_BUSINESS_OBJECT_ELEMENT_OLD_CONTENT_CCTS

="BusinessObjectElementOldContent";

51

IESRName

_BUSINESS_OBJECT_ELEMENT_OLD_CONTENT_CCTS_ESR

=ESRNameFactory.createESRName("BusinessObjectElementOldContent",

"

");

52

//

Attribute

BusinessObjectElementNewContent(qualified

name,

esr

name)

53

String

_BUSINESS_OBJECT_ELEMENT_NEW_CONTENT_CCTS

="BusinessObjectElementNewContent";

54

IESRName

_BUSINESS_OBJECT_ELEMENT_NEW_CONTENT_CCTS_ESR

=ESRNameFactory.createESRName("BusinessObjectElementNewContent",

"

");

55

//

Attribute

ChangeReasonText(qualified

name,

esr

name)

56

String

_CHANGE_REASON_TEXT_CCTS

="ChangeReasonText";

57

IESRName

_CHANGE_REASON_TEXT_CCTS_ESR

=ESRNameFactory.createESRName("ChangeReasonText",

"");

58

//

Attribute

AdditionalBusinessObjectInformation(qualified

name,

esr

name)

59

String

_ADDITIONAL_BUSINESS_OBJECT_INFORMATION_CCTS

="AdditionalBusinessObjectInformation";

60

IESRName

_ADDITIONAL_BUSINESS_OBJECT_INFORMATION_CCTS_ESR


AdditionalBusinessObjectInformation",

"");

A - 13

61

}

62

63

//

BO

Node

ChangeDocumentRecord

64

interface


{

65

String

NAME

="ChangeDocumentRecord";

66

IESRName

ESR_NAME

=ESRNameFactory.createESRName("ChangeDocumentRecord",

"");

67

//

IAssociation

ToRoot

68

String

ASSOCIATION_TO_ROOT

="ToRoot";

69

IESRName

ASSOCIATION_TO_ROOT_ESR

=ESRNameFactory.createESRName("ToRoot",

"");

70

//

IAssociation

ToParent

71

String

ASSOCIATION_TO_PARENT

="ToParent";

72

IESRName

ASSOCIATION_TO_PARENT_ESR

=ESRNameFactory.createESRName("ToParent",

"");

73

//

Query

QueryByBusinessObjectNameAndRootNodeID

74

String

QUERY_QUERY_BY_BUSINESS_OBJECT_NAME_AND_ROOT_NODEID

="QueryByBusinessObjectNameAndRootNodeID";

75

IESRName

QUERY_QUERY_BY_BUSINESS_OBJECT_NAME_AND_ROOT_NODEID_ESR


QueryByBusinessObjectNameAndRootNodeID",

"");

76

IESRName

QUERY_QUERY_BY_BUSINESS_OBJECT_NAME_AND_ROOT_NODEID_INPUT_STRUCTURE_ESR


ChangeDocumentRecordNodeQueryInputParameter",


77

String

QUERY_QUERY_BY_BUSINESS_OBJECT_NAME_AND_ROOT_NODEID_OBJECT_TYPE_CODE

="ObjectTypeCode";

78

String

QUERY_QUERY_BY_BUSINESS_OBJECT_NAME_AND_ROOT_NODEID_OBJECT_ID

="ObjectId";

79

String

QUERY_QUERY_BY_BUSINESS_OBJECT_NAME_AND_ROOT_NODEID_FROM_DATE_TIME

="FromDateTime";

80

String

QUERY_QUERY_BY_BUSINESS_OBJECT_NAME_AND_ROOT_NODEID_TO_DATE_TIME

="ToDateTime";

81

String

QUERY_QUERY_BY_BUSINESS_OBJECT_NAME_AND_ROOT_NODEID_USER_ACCOUNTID

="UserAccountID";

82

//

Attribute

CompleteNodeHierarchy(qualified

name,

esr

name)

83

String

_COMPLETE_NODE_HIERARCHY_CCTS

="CompleteNodeHierarchy";

84

IESRName

_COMPLETE_NODE_HIERARCHY_CCTS_ESR

=ESRNameFactory.createESRName("CompleteNodeHierarchy",

"");

85

//

Attribute

CompleteChangedAttributePath(qualified

name,

esr

name)

86

String

_COMPLETE_CHANGED_ATTRIBUTE_PATH_CCTS

="CompleteChangedAttributePath";

87

IESRName

_COMPLETE_CHANGED_ATTRIBUTE_PATH_CCTS_ESR

=ESRNameFactory.createESRName("CompleteChangedAttributePath",

"");

88

//

Attribute

BusinessObjectElementName(qualified

name,

esr

name)

89

String

_BUSINESS_OBJECT_ELEMENT_NAME_CCTS

="BusinessObjectElementName";

90

IESRName

_BUSINESS_OBJECT_ELEMENT_NAME_CCTS_ESR

=ESRNameFactory.createESRName("BusinessObjectElementName",

"");

91

//

Attribute

BusinessObjectElementNewContent(qualified

name,

esr

name)

A - 14

92

String

_BUSINESS_OBJECT_ELEMENT_NEW_CONTENT_CCTS

="BusinessObjectElementNewContent";

93

IESRName

_BUSINESS_OBJECT_ELEMENT_NEW_CONTENT_CCTS_ESR

=ESRNameFactory.createESRName("BusinessObjectElementNewContent",

"

");

94

//

Attribute

BusinessObjectElementOldContent(qualified

name,

esr

name)

95

String

_BUSINESS_OBJECT_ELEMENT_OLD_CONTENT_CCTS

="BusinessObjectElementOldContent";

96

IESRName

_BUSINESS_OBJECT_ELEMENT_OLD_CONTENT_CCTS_ESR

=ESRNameFactory.createESRName("BusinessObjectElementOldContent",

"

");

97

//

Attribute

UserAcountID(qualified

name,

esr

name)

98

String

_USER_ACOUNTID_CCTS

="UserAcountID";

99

IESRName

_USER_ACOUNTID_CCTS_ESR

=ESRNameFactory.createESRName("UserAcountID",

"");

100

//

Attribute

BusinessPartnerFormattedName(qualified

name,

esr

name)

101

String

_BUSINESS_PARTNER_FORMATTED_NAME_CCTS

="BusinessPartnerFormattedName";

102

IESRName

_BUSINESS_PARTNER_FORMATTED_NAME_CCTS_ESR

=ESRNameFactory.createESRName("BusinessPartnerFormattedName",

"");

103

//

Attribute

ChangeDateTime(qualified

name,

esr

name)

104

String

_CHANGE_DATE_TIME_CCTS

="ChangeDateTime";

105

IESRName

_CHANGE_DATE_TIME_CCTS_ESR

=ESRNameFactory.createESRName("ChangeDateTime",

"");

106

//

Attribute

ModificationTypeCode(qualified

name,

esr

name)

107

String

_MODIFICATION_TYPE_CODE_CCTS

="ModificationTypeCode";

108

IESRName

_MODIFICATION_TYPE_CODE_CCTS_ESR

=ESRNameFactory.createESRName("ModificationTypeCode",

"");

109

//

Attribute

ChangeReasonText(qualified

name,

esr

name)

110

String

_CHANGE_REASON_TEXT_CCTS

="ChangeReasonText";

111

IESRName

_CHANGE_REASON_TEXT_CCTS_ESR

=ESRNameFactory.createESRName("ChangeReasonText",

"");

112

//

Attribute

AdditionalBusinessObjectInformation1(qualified

name,

esr

name)

113

String

_ADDITIONAL_BUSINESS_OBJECT_INFORMATION1_CCTS

="AdditionalBusinessObjectInformation1";

114

IESRName

_ADDITIONAL_BUSINESS_OBJECT_INFORMATION1_CCTS_ESR


AdditionalBusinessObjectInformation1",

"");

115

//

Attribute


name,

esr

name)

116

String



117

IESRName




"");

118

//

Attribute


name,

esr

name)

119

String



120

IESRName



A - 15


"");

121

}

122

123

//

BO

Node

Root

124

interface

Root

{

125

String

NAME

="Root";

126

IESRName

ESR_NAME

=ESRNameFactory.createESRName("Root",

"");

127

//

IAssociation

UserIdentity

128

String

ASSOCIATION_USER_IDENTITY

="UserIdentity";

129

IESRName

ASSOCIATION_USER_IDENTITY_ESR

=ESRNameFactory.createESRName("UserIdentity",

"");

130

//

IAssociation

ChangeDocumentItem

131

String

ASSOCIATION_CHANGE_DOCUMENT_ITEM

="ChangeDocumentItem";

132

IESRName

ASSOCIATION_CHANGE_DOCUMENT_ITEM_ESR

=ESRNameFactory.createESRName("ChangeDocumentItem",

"");

133

//

IAssociation


134

String

ASSOCIATION_CHANGE_DOCUMENT_RECORD

="ChangeDocumentRecord";

135

IESRName

ASSOCIATION_CHANGE_DOCUMENT_RECORD_ESR

=ESRNameFactory.createESRName("ChangeDocumentRecord",

"");

136

//

Action

MoveToArchive

137

String

ACTION_MOVE_TO_ARCHIVE

="MoveToArchive";

138

IESRName

ACTION_MOVE_TO_ARCHIVE_ESR

=ESRNameFactory.createESRName("MoveToArchive",

"");

139

//

Action

CheckArchivability

140

String

ACTION_CHECK_ARCHIVABILITY

="CheckArchivability";

141

IESRName

ACTION_CHECK_ARCHIVABILITY_ESR

=ESRNameFactory.createESRName("CheckArchivability",

"");

142

//

Query

Archive

143

String

QUERY_ARCHIVE

="Archive";

144

IESRName

QUERY_ARCHIVE_ESR

=ESRNameFactory.createESRName("Archive",

"");

145

//

Query

ArchivePreSelection

146

String

QUERY_ARCHIVE_PRE_SELECTION

="ArchivePreSelection";

147

IESRName

QUERY_ARCHIVE_PRE_SELECTION_ESR

=ESRNameFactory.createESRName("ArchivePreSelection",

"");

148

//

Query

QueryByBusinessObjectNameAndID

149

String

QUERY_QUERY_BY_BUSINESS_OBJECT_NAME_ANDID

="QueryByBusinessObjectNameAndID";

150

IESRName

QUERY_QUERY_BY_BUSINESS_OBJECT_NAME_ANDID_ESR

=ESRNameFactory.createESRName("QueryByBusinessObjectNameAndID",

""

);

151

IESRName

QUERY_QUERY_BY_BUSINESS_OBJECT_NAME_ANDID_INPUT_STRUCTURE_ESR


A - 16

RootNodeQueryInputParameter",


152

String

QUERY_QUERY_BY_BUSINESS_OBJECT_NAME_ANDID_OBJECT_TYPE_CODE

="ObjectTypeCode";

153

String

QUERY_QUERY_BY_BUSINESS_OBJECT_NAME_ANDID_OBJECT_ID

="ObjectId";

154

String

QUERY_QUERY_BY_BUSINESS_OBJECT_NAME_ANDID_FROM_DATE_TIME

="FromDateTime";

155

String

QUERY_QUERY_BY_BUSINESS_OBJECT_NAME_ANDID_TO_DATE_TIME

="ToDateTime";

156

String

QUERY_QUERY_BY_BUSINESS_OBJECT_NAME_ANDID_USER_IDENTITYUUID

="UserIdentityUUID";

157

//

Attribute

ChangeDocumentID(qualified

name,

esr

name)

158

String

_CHANGE_DOCUMENTID_CCTS

="ChangeDocumentID";

159

IESRName

_CHANGE_DOCUMENTID_CCTS_ESR

=ESRNameFactory.createESRName("ChangeDocumentID",

"");

160

//

Attribute

ObjectTypeCode(qualified

name,

esr

name)

161

String

_OBJECT_TYPE_CODE_CCTS

="ObjectTypeCode";

162

IESRName

_OBJECT_TYPE_CODE_CCTS_ESR

=ESRNameFactory.createESRName("ObjectTypeCode",

"");

163

//

Attribute

BusinessObjectRootObjectID(qualified

name,

esr

name)

164

String

_BUSINESS_OBJECT_ROOT_OBJECTID

="BusinessObjectRootObjectID";

165

IESRName

_BUSINESS_OBJECT_ROOT_OBJECTID_ESR

=ESRNameFactory.createESRName("BusinessObjectRootObjectID",

"");

166

//

Attribute

UserIdentityUUID(qualified

name,

esr

name)

167

String

_USER_IDENTITYUUID_CCTS

="UserIdentityUUID";

168

IESRName

_USER_IDENTITYUUID_CCTS_ESR

=ESRNameFactory.createESRName("UserIdentityUUID",

"");

169

//

Attribute

ChangeDateTime(qualified

name,

esr

name)

170

String

_CHANGE_DATE_TIME_CCTS

="ChangeDateTime";

171

IESRName

_CHANGE_DATE_TIME_CCTS_ESR

=ESRNameFactory.createESRName("ChangeDateTime",

"");

172

//

Attribute

TransactionID(qualified

name,

esr

name)

173

String

_TRANSACTIONID_CCTS

="TransactionID";

174

IESRName

_TRANSACTIONID_CCTS_ESR

=ESRNameFactory.createESRName("TransactionID",

"");

175

//

Attribute

SystemNumber(qualified

name,

esr

name)

176

String

_SYSTEM_NUMBER_CCTS

="SystemNumber";

177

IESRName

_SYSTEM_NUMBER_CCTS_ESR

=ESRNameFactory.createESRName("SystemNumber",

"");

178

//

Attribute

ArchivingStatus(qualified

name,

esr

name)

179

String

_ARCHIVING_STATUS

="ArchivingStatus";

180

IESRName

_ARCHIVING_STATUS_ESR

=ESRNameFactory.createESRName("ArchivingStatus",

"");

181

}

182

}

A - 17

APPENDIXE

Code for Accessing BW Using

XML for Analysis

Listing E.1: Main.java of XML/A Solution1 /*

2 * Call BW data by Using XML/A interface of the MDX processor

3 */

4

5 import java.net .*;

6 import java.io.FileInputStream;

7 import java.io.InputStreamReader;

8 import java.io.OutputStreamWriter;

9 import java.io.BufferedReader;

10 import java.io.File;

11 import java.util.Properties;

12

13 import java.util.Date;

14

15 /**

16 * This is a simple example to show , how is it possible to get data from BW.

In this

17 * case the query language MDX is used. The connection settings are written

down in the file

18 * properties .ini

19 *

20 * Copyright (c)2006 SAP AG

21 *

22 * @author Nico Herzberg (D041659)

23 *

24 */

25

26 public class Main {

27

28 /**

29 * Main method

30 *

A - 18

31 * @param args

32 * Possible input parameters

33 */

34 public static void main(String [] args) {

35

36 // Definiton of the MDX Statement

37 String MDXstatement = new String ();

38 MDXstatement = "select [Measures ]. members on columns , non empty [0 VC_COUN

]. levels (1).members * [0 VC_REG ]. levels (1).members dimension

properties member_name , member_caption on rows from [$0BWVC_C03]

where ([0 FISCYEAR ].[ K41999 ])";

39

40 // Call method connect and provide MDX statement

41 connect(MDXstatement);

42 }

43

44 /**

45 * Method for connecting to the MDX processor and sending the SOAP request

and handle the response

46 *

47 * @param MDXstatement

48 * Statement for query relevant data from BW

49 */

50 public static void connect (String MDXstatement){

51

52 // Build up the SOAP Request

53 String data = createSOAPRequest(MDXstatement);

54

55 // Create and send request

56 try{

57 // Build up the URL

58 URL url = new URL(readproperties("connectionString"));

59 // Set up the connection

60 URLConnection conn = url.openConnection ();

61

62 // Add user

63 conn.setRequestProperty("sap -user",readproperties("user"));

64 // Add password

65 conn.setRequestProperty("sap -password",readproperties("password"));

66 // Add property Accept -Encoding

67 conn.setRequestProperty("Accept -Encoding","gzip , compress");

68

69 // Connection requires output

70 conn.setDoOutput(true);

71 // Connect to the URL

72 conn.connect ();

73

74 // Define OutputStream

75 OutputStreamWriter wr = new OutputStreamWriter(conn.getOutputStream ())

;

76 // Send SOAP request to the server

77 wr.write(data);

78 wr.flush();

79

A - 19

80 // Get response

81 BufferedReader rd = new BufferedReader(new InputStreamReader(conn.

getInputStream ()));

82 // Variable for reading input

83 String line;

84 // Reading input

85 while ((line = rd.readLine ()) != null) {

86 System.out.println(line);

87 }

88 // Close writer and reader

89 wr.close();

90 rd.close();

91 } catch (Exception e){

92 System.out.println("Error while connecting to backend system");

93 }

94 }

95

96 /**

97 * Method for reading the property file

98 *

99 * @param field

100 * Parameter for defining which property is required

101 * @return

102 * The value of the requested property , in case of connectionString

the whole URL

103 */

104 public static String readproperties(String field){

105

106 // Open property file

107 Properties prop = new Properties ();

108 File file = new File("C:// Documents and Settings // d041659 // workspace //MDX

//src// properties.ini");

109 String property = new String ();

110

111 // Read relevant data for connection string and build it up

112 if (field .equalsIgnoreCase("connectionString"))

113 {

114 prop.clear ();

115 try {

116 FileInputStream in = new FileInputStream(file.getAbsolutePath ());

117 prop.load(in);

118 in.close();


120 System.out.println("Error while loading property file");

121 }

122 property = "http ://" + prop.getProperty("host")+":"+prop.getProperty("

port")+"/sap/bw/xml/soap/xmla"+"?sap -client="+prop.getProperty("

client");

123 }

124

125 // Read user

126 if (field .equalsIgnoreCase("user"))

127 {

128 prop.clear ();

A - 20

129 try {


131 prop.load(in);

132 in.close();



135 }

136 property = prop.getProperty("user");

137 }

138

139 // Read password

140 if (field .equalsIgnoreCase("password"))

141 {

142 prop.clear ();

143 try {


145 prop.load(in);

146 in.close();



149 }

150 property = prop.getProperty("passwd");

151 }

152

153 // Return requested property

154 return property;

155 }

156

157 /**

158 * Method for creating the SOAP Request with the MDX statement

159 *

160 * @param MDXstatement

161 * Statement for Query the relevant data from BW

162 * @return

163 * The SOAP response

164 */

165 public static String createSOAPRequest(String MDXstatement){

166

167 String request = new String ();

168

169 request = "<SOAP -ENV:Envelope "

170 + " xmlns:SOAP -ENV=’http :// schemas.xmlsoap.org/soap/envelope/’"

171 + " SOAP -ENV:encodingStyle=’http :// schemas.xmlsoap.org/soap/encoding

/’>"

172 + " <SOAP -ENV:Body >"

173 + " <Execute xmlns=’urn:schemas -microsoft -com:xml -analysis ’"

174 + " SOAP -ENV:encodingStyle=’http :// schemas.xmlsoap.org/soap/encoding

/’>"

175 + " <Command >"

176 + " <Statement >"

177 + MDXstatement

178 + " </Statement >"

179 + " </Command >"

180 + " <Properties >"

A - 21

181 + " <PropertyList >"

182 + " <DataSourceInfo >default </ DataSourceInfo >"

183 + " <Catalog >Foodmart 2000 </ Catalog >"

184 + " <Format >Tabular </Format >"

185 + " <ReturnCellProperties >true </ ReturnCellProperties >"

186 + " <AxisFormat >TupleFormat </ AxisFormat >"

187 + " <Content >SchemaData </Content >"

188 + " </PropertyList >"

189 + " </Properties >"

190 + " </Execute >"

191 + " </SOAP -ENV:Body >"

192 + " </SOAP -ENV:Envelope >";

193

194 return request;

195 }

196 }

A - 22

APPENDIXF

Contacts

While working on the thesis expertise were identified and contacts are tied. For

further work on the FRODO project the different contacts are listed in the next

table. Additionally, some comments to the people are written down. Thus,

similar problems can be addressed in future to the right people directly.

A - 23

Know

ledge

Fie

ldSurn

ame

Fir

stnam

eU

ser

IDFunct

ion

Com

men

ts

Fra

ud

Vay

ssie

reJu

lien

I028

859

Seni

orR

esea

rche

rP

roje

ctle

adFR

OD

O

Vos

sN

oelle

D04

0491

PLM

Con

sult

ant

Aut

hor

ofth

esis

“Con

cept

ion

and

anal

ysis

ofm

etho

dsfo

rde

tect

ing

and

prev

enti

ngof

invo

ice

frau

din

SRM

”

Fra

ud

De-

tect

ion

Vay

ssie

reJu

lien

I028

859

Seni

orR

esea

rche

rP

roje

ctle

adFR

OD

O

SR

MSa

laPao

laD

0204

22D

evel

opm

ent

Man

ager

AP

/SR

MIn

volv

edin

proj

ect

“Fra

udD

etec

tion

inSR

M”

Rei

ner

Rob

ert

D02

3473

Dev

elop

erA

P/S

RM

Invo

lved

inpr

ojec

t“F

raud

Det

ecti

onin

SRM

”

Hoc

hwar

thPas

cal

D03

1154

Dev

elop

erA

P/S

RM

Invo

lved

inpr

ojec

t“F

raud

Det

ecti

onin

SRM

”

Wol

lny

Step

han

D04

0407

Dev

elop

erA

P/S

RM

Invo

lved

inpr

ojec

t“F

raud

Det

ecti

onin

SRM

”

Vos

sN

oelle

D04

0491

PLM

Con

sult

ant

Aut

hor

ofth

esis

“Con

cept

ion

and

anal

ysis

ofm

etho

dsfo

rde

tect

ing

and

prev

enti

ngof

invo

ice

frau

din

SRM

”

AR

ISH

ochw

arth

Pas

cal

D03

1154

Dev

elop

erA

P/S

RM

Invo

lved

inpr

ojec

t“F

raud

Det

ecti

onin

SRM

”

AP

Schm

itt

Mat

thia

sD

0273

13D

evel

oper

AP

Mas

ter

Dat

a

Sadi

qW

asim

I025

248

Seni

orR

esea

rche

r

A - 24

Wol

lny

Step

han

D04

0407

Dev

elop

erA

P/S

RM

Invo

lved

inpr

ojec

t“F

raud

Det

ecti

onin

SRM

”

XI

Bun

dsch

uhA

lexa

nder

I028

930

Kno

wle

dge

Tra

nsfe

rX

IR

IGA

PA

Klin

glFr

ank

D02

9075

Con

sult

ant

XI

Pla

tfor

mC

han

geD

ocu

men

ts

Pie

lka

Kai

-Uw

eD

0026

71P

MP

CD

Mei

er-B

arth

old

Dir

kD

0260

48So

luti

onM

anag

emen

tP

CD

Gue

nthe

rM

arti

nD

0263

69So

luti

onM

anag

emen

tP

CD

Ana

lysi

s,pr

epar

atio

nan

dvi

sual

izat

ion

ofda

tafo

rau

dito

rs

Hup

pert

And

reas

D02

0682

Solu

tion

Arc

hite

ctP

CD

Kri

shna

moo

rthy

Raj

aI0

2237

4D

evel

opm

ent

Man

ager

PC

D

GC

PK

aise

rJe

nsD

0415

07D

evel

oper

ESI

Cor

eE

SF

Kra

iss

Ach

imD

0380

15D

evel

opm

ent

Man

ager

ESI

Cor

eE

SF

Wel

zel

Oliv

erD

0248

17D

evel

oper

Man

ager

ESI

Cor

eE

SF

Rit

ter

Step

han

D02

0760

Dev

elop

men

tE

SIU

IA

utho

r“S

peci

ficat

ion

ESF

Gen

eric

Con

-su

mer

Pro

xy”

Mue

ller

Hel

mut

D02

2323

Dev

elop

erE

SIU

IA

utho

r“S

peci

ficat

ion

ESF

Gen

eric

Con

-su

mer

Pro

xy”

Rog

geM

arti

nD

0218

62D

evel

oper

Org

Man

agem

ent

Hoc

hwar

thPas

cal

D03

1154

Dev

elop

erA

P/S

RM

Invo

lved

inpr

ojec

t“F

raud

Det

ecti

onin

SRM

”

Ser

vic

esB

ende

rJo

achi

mD

0200

94D

evel

opm

entM

anag

erE

SIToo

ls

A - 25

ESR

Jaco

biA

nne

D03

0735

Dev

elop

erE

SIC

ore

ESX

GD

TB

ross

ler

And

reas

D03

3985

Dev

elop

erA

P/S

RM

Ser

vic

eIn

terf

aces

Scho

ttV

olke

rD

0293

52D

evel

oper

AP

Haf

ner

Sasc

haD

0325

48D

evel

oper

AP

/FIN

/HC

M

AB

AP

Jaco

biA

nne

D03

0735

Dev

elop

erE

SIC

ore

ESX

LC

PW

olln

ySt

epha

nD

0404

07D

evel

oper

AP

/SR

MIn

volv

edin

proj

ect

“Fra

udD

etec

tion

inSR

M”

Har

tig

Mar

tin

D03

0326

Dev

elop

erE

SIC

ore

ESF

Java

Jagu

sch

And

reD

0384

06D

evel

oper

ESI

Too

lsSp

ecia

list

for

Java

Clie

ntP

roxy

gene

rati

on

BW

Ros

erR

ene

D03

9585

Dev

elop

erA

naly

tics

Spec

ialis

tfo

rB

I,B

Wan

dA

naly

tics

Tra

nSa

nD

0311

82D

evel

oper

SRM

BW

Spec

ialis

t

Hoe

risc

hM

icha

elD

0256

71K

now

ledg

eTra

nsfe

rB

IN

WR

IGE

ME

A,

Spec

ialis

tfo

rB

IO

pen

Hub

Serv

ice

Ulm

erC

edri

cI0

2404

8R

esea

rche

rP

roje

ctw

ith

BW

XM

L/A

Bie

dens

tein

Stef

anD

0274

64D

evel

oper

BI

Schn

eide

rC

arin

aD

0417

59St

uden

tA

P/S

RM

Invo

lved

inpr

ojec

t“F

raud

Det

ecti

onin

SRM

”

Schu

man

nR

olf

D03

8903

Dev

elop

erA

P/S

RM

BIA

ccel

er-

ator

Pet

erA

lexa

nder

D02

4877

PM

OB

I

Anal

ytics

Ros

erR

ene

D03

9585

Dev

elop

erA

naly

tics

Spec

ialis

tfo

rB

I,B

Wan

dA

naly

tics

Sori

ngH

elge

D02

9621

BI

Con

tent

Dev

elop

men

t

A - 26

Deg

beon

Mic

hael

aD

0272

19B

IC

onte

ntD

evel

opm

ent

Poo

nen

Sanj

ayI8

1046

1SV

PA

naly

tics

PIM

Sadi

qW

asim

I025

248

Seni

orR

esea

rche

r

Avi

tzur

Aha

ron

I031

688

Dev

elop

erA

P/S

CM

Tab

leF.1

:SA

PC

onta

cts

A - 27

Figure F.1: Contact Mind Map

A - 28

Glossary

ABAP

ABAP is a programming language, developed by SAP.

Analytics

Analytics is embedded in applications and offers analytical data concern-

ing to business data.

Application Platform (AP)

The AP is build on top of SAP NetWeaver and is designed to build

application solutions by service compositions to follow a model-driven

approach by using these services.

ARIS

ARIS based on the ARIS concept and is a toolset provided by IDS Scheer

AG for creating, maintaining and optimizing business processes.

Audit Information System (AIS)

The Audit Information System is a tool which supports internal, external

and tax audits as well as data security by offering different views on

financial data on SAP’s databases.

Business Information Warehouse (BW)

SAP BW is a component of BI and is SAP’s data warehouse product.

XVIII

Glossary

Business Object (BO)

BOs build the basic elements of business applications. They contain

business logic and implement the main service providers.

Composite application

Composite applications are predefined applications which use functions

of several services.

Compound services

Compound services work internally with core services and allow the ac-

cess of BOs from outside of DUs.

Core services

Core services access BOs directly and provide for that generic functions.

They can be called via LCPs and GCPs.

Deployment Unit (DU)

DUs are building blocks of the AP which contains PCs and/or BOs.

Enterprise services

Enterprise services are compound services which are used in a business

process.

Enterprise Services Repository (ESR)

The ESR is the interface between SAP internal and external applications

and provides them descriptions about the services.

Enterprise SOA

Enterprise SOA is SAP’s implementation of the system architecture con-

cept SOA.

XIX

Glossary

Extensible Markup Language (XML)

XML is a W3C standard for building up documents with a tree structure.

Financials (FI)

FI is responsible for the accounting of a company.

FRODO

FRODO means either the software prototype for detecting financial fraud

or the name of the SAP Research project.

Generic Core Service Consumer Proxy (GCP)

GCPs enable Java applications to call core services from outside the DU

by using RFCs or SOAP. The former term for GCP was Generic Client

Proxy.

Integration Builder

The Integration Builder is a tool for setting up the SAP XI.

Local Client Proxy (LCP)

With LCPs is it possible to call the core services of a BO from inside of

the same DU.

Master Data Management (MDM)

MDM is the business area which is responsible for the central manage-

ment of master data.

Multidimensional Expressions (MDX)

MDX is a query language for databases, developed by Microsoft.

XX

Glossary

mySAP All-In-One/Service-Enabled (A1S)

A1S is the new business solution for mid-size enterprises and the first

one which uses the AP.

Platform Change Documents

Platform Change Documents contain information about the change of

BO instances. They are created by the TecO ChangeDocument.

Process Component (PC)

PCs are building blocks of the AP and can group BOs in business-relevant

and meaningful units.

R/3

SAP R/3 is an enterprise information system which exists since 1992. A

R/3 system allows the computer aided handling of typical business tasks.

Remote Function Call

RFCs enable function calls of R/3 building blocks from external appli-

cations.

Resource Description Framework (RDF)

RDF is a formal language for providing meta data in the World Wide

Web.

SAP Business Intelligence (BI)

SAP Business Intelligence is a system based on SAP NetWeaver for sys-

tematical analysis of enterprises and their environment.

SAP NetWeaver

XXI

Glossary

NetWeaver is SAP’s technology platform based on enterprise SOA for

integrating heterogeneous systems and building up a business process

platform.

Service-Oriented Architecture (SOA)

SOA is on the one hand a management concept which demands for a

business oriented IT infrastructure. On the other hand SOA is a system

architecture concept for providing services.

SOAP

SOAP is a protocol for exchanging information between different systems

or executing RFCs.

Supplier Relationship Management (SRM)

SRM is the business area for plan and control relationships with suppliers.

Technical Object (TecO)

Technical Objects are special BOs for supporting the technical infras-

tructure or IT Service and Application Management of AP.

Web Dynpro

Web Dynpro is SAP’s standard programming model for implementing

UIs. It follows the Model View Controller design pattern.

Web Services Description Language (WSDL)

WSDL is a XML specification for describing web services to exchange

information. WSDL is independent from any platforms, programming

languages and protocols.

XML for Analysis (XML/A)

XXII

Glossary

XML/A is a protocol for exchanging data between clients and server over

HTTP and SOAP.

XXIII

Bibliography

[BM06] Michael Bell and Eric A. Marks. Service-Oriented Architecture: A

Planning and Implementation Guide for Business and Technology.

John Wiley & Sons, 2006.

[Dit05] Georg Dittmar. Adaptive Computing - Technical Overview. 2005.

[Ebe04] Peter Eberlein. Synchronous Cross Component Communication.

2004.

[FMW06] Thomas Fiedler, Holger Meinert, and Volker Wiechers. Services.

ESA Architecture Series 2006. February 2006. Available via SAP

Corporate Portal – Product & Technology Group – Architecture –

Media Library – ESA Architecture Series.

[ILK06] Tahar Wl Idrissi-Lamghari and Hartmut Koerner. Analytics. ESA

Architecture Series 2006. February 2006. Available via SAP Corpo-

rate Portal – Product & Technology Group – Architecture – Media

Library – ESA Architecture Series.

[Kay03] Doug Kaye. Loosely Coupled - The Missing Pieces of Web Services.

RDS Press, 2003.

[KPM04] KPMG. Fraud Survey 2004, 2004. Available via

http://www.kpmg.com.au/.

[KPM06] KPMG. Studie 2006 zur Wirschaftskriminalitat in Deutschland,

2006. Available via http://www.kpmg.de/.

[MBCV06] George Mohey, Peter Best, Andrew Clark, and Julien Vayssiere.

Australian research council - linkage projects (round two) - applica-

XXIV

Bibliography

tion form for funding commencing in 2006 - project id: Lp0669644,

2006.

[Onl06] Online Ethics Center for Engineering and Science. Onlineethics.org

- The Online Ethics Center For Engineering and Science at Case

Western Reserve University. August 2006.

[PKVC06] Kai-Uwe Pielka, Raja Krishnamoorthy, Kritesh Vasing, and

Sumana Chakraborty. AP Development Guideline for: Platform

Change Documents, April 2006.

[Red06] Michael Redford. BPP: Da ist musik drin. SAP News, February

2006.

[RWK06] Robert Reiner, Andre Wagner, and Benjamin Klehr. SAP Business

Object: SupplierInvoice, May 2006.

[SAP04] SAP AG. BW305 - Business Information Warehouse - Reporting

und Analyse, 2004.

[SAP05] SAP AG. Software Design Description - Process Integration Moni-

tor, 2005.

[SAP06a] SAP AG. MDX as basis for the interfaces, September 2006. Avail-

able via http://help.sap.com/saphelp nw04/helpdata/en/start.htm

– SAP Library – SAP NetWeaver – Information Integration – SAP

Business Information Warehouse – Additional Development Tech-

nologies – Open Analysis Interfaces.

[SAP06b] SAP AG. PIC council. Available via SAP Corporate Portal, August

2006.

[SAP06c] SAP AG. SAP NetWeaver as a ‘Business Process Platform’, Febru-

ary 2006.

[SAP06d] SAP AG. Unit 1: Architecture overview. Application Platform

Architecture Basics. July 2006. Available via SAP Corporate Por-

tal – Application Platform – Knowledge Transfer – Architecture

XXV

Bibliography

Knowledge Transfer – AP Architecture Overview – Link to PPT

presentations.

[SAP06e] SAP AG. Unit 4: Services. Application Platform Architecture Ba-

sics. July 2006. Available via SAP Corporate Portal – Application

Platform – Knowledge Transfer – Architecture Knowledge Transfer

– AP Architecture Overview – Link to PPT presentations.

[SAP06f] SAP TV. What is BPP? Video available via

http://directbeam:1080/noauth Inside What is BPP e 4204.asx,

2006.

[Str05] Uwe Stromberg. SAP Business Object Template: Business Partner,

May 2005.

[Vay06] Julien Vayssiere. Fraud Detection at SAP Research, 2006.

[Wik06a] Wikipedia. Business-intelligence. Available via

http://de.wikipedia.org/wiki/Business Intelligence, August 2006.

[Wik06b] Wikipedia. Enron. Available via

http://de.wikipedia.org/wiki/Enron, August 2006.

[Wik06c] Wikipedia. MCI worldcom. Available via

http://de.wikipedia.org/wiki/WorldCom, August 2006.

[Wik06d] Wikipedia. Sarbanes-Oxley Act. Available via

http://de.wikipedia.org/wiki/SOX, August 2006.

[Wik06e] Wikipedia. Serviceorientierte Architektur. Available via

http://de.wikipedia.org/wiki/Serviceorientierte Architektur, Au-

gust 2006.

[Wol05] Stephan Wollny. Implementation of the business object ‘Suppli-

erInvoice’ and its services according to the enterprise services ar-

chitecture. Master’s thesis, University of Cooperative Education

Mannheim, March 2005.

XXVI

Bibliography

[XKS06] XU Product Architecture, Knowledge Transfer, and SAP AG. The

big picture. ESA Architecture Series 2006. February 2006. Avail-

able via SAP Corporate Portal – Product & Technology Group –

Architecture – Media Library – ESA Architecture Series.

XXVII

Statement of Academic

Honesty

“Hereby, I declare:

• That the diploma thesis on hand with the topic ‘Detecting Fraud Patterns

using data obtained from the Application Platform’ was created without

any help of a third party.

• That directly or indirectly used thoughts of third party sources are high-

lighted in the according places within the document

• That the diploma thesis was not submitted to any other university or

published in the past. I am aware, that a dishonest statement will have

legal consequences.”

Brisbane, 08.09.2006 Signature:

XXVIII