Professional Documents
Culture Documents
06 PE Architecture Malaga
06 PE Architecture Malaga
Payment Solution
Software Architecture
Dr. Joerg Wegener
Development Architect SAP Banking, SAP AG
Introduction to the Payment Engine
Focus on performance
Goals and Characteristics
Functional Overview
Payment Engine Sample Process
Current Challenges in the Payment Industry
...
Goals and Characteristics I
Architecture
A generic component with well-defined interfaces to upstream
and downstream systems and account-managing systems
Scope of Functions
A high level of performance due to buffering on application and
database levels, distribution of processing in batches and
parallel processing on the scalable system platform
Transparency
Integrated status concept
The complete life cycle of the payment order can be traced
(complete audit trail)
Available
Planned
Release 2.0
Payment Processing Functions I
Available
Planned
Release 2.0
Payment Processing Functions II
Available
Planned
Release 2.0
Route Processing Functions
Determination of route
Administration of route
Payment
Item
Exception Control
4 Search Unsuccessful
4a Search Successful
2a Search Successful
Available
Planned
Release 2.0
Exception Control Functions
Exception control
Administration of rules
Available
Planned
Release 2.0
Postprocessing Functions
Workflow connection
Available
Planned
Release 2.0
General Functions
Application logs
End-of-day processing
Reconciliation
Accrual function
Change documents
Archiving
Available
Planned
Release 2.0
Goals and Characteristics
Functional Overview
Payment Engine Sample Process
PE Sample Process: Processing of a DME Collective Payment Order with Creation of
Collector
OP Rec.
Upstream and Transfer
5 PI
10
PI
2
Route (R) 11
+
File Handler Clearing
Systems
Agreement (CA) 6
Database Route
Processing
12
Value Date
Agreement
7
19
OP R Rec. R
PI CA
13
8 PI CA
9 Account
Output Manager 18
OP
Management
20 14b
PI System
Clearing
Target Format Collective PO Proxy SAP AM/BCA
Format Processing
Converter in PE Metaformat (Interface)
Clear
PI
R 16
14a Rec.
Collect 17 PI CA
PO
Clearing
Collector
Payment Engine 15
Introduction to the Payment Engine
Focus on performance
Technological changes drive architecture
ESA: Definition
SAP NetWeaver Overview
Architectural implications for SAP Banking
Technology Sea Change Ahead
Divergence From Replace to Reuse
Technology Technology
Sea Change Sea Change
SCM
CRM
HR
ERP
PCAs*
Convergence
1993 2003
PCA* = Packaged Composite Application (as delivered through SAP xApps)
Technological changes drive architecture
ESA: Definition
SAP NetWeaver Overview
Architectural implications for SAP Banking
Services and SOA – A Definition*
Services
Softwareeinheit, die eine hohe Granularität aufweist (coarse-grained)
Lässt sich lokalisieren
Existiert nur als eine Instanz
Ist mit anderen Diensten und Anwendungen nur lose gekoppelt (meist
asynchron)
* cw 20/2003
Enterprise Services Architecture (ESA)
Make Web Services work for your business
Objective
Add new levels of flexibility while leveraging
existing investments Snap on business
process
interoperability
Information Integration
… Application Platform …
J2EE ABAP
DBDBand
andOS
OS Abstraction
Abstraction
.NET Websphere
SAP NetWeaver in Detail (SAP Internal View)
Product components and killer features
SAP NetWeaver™
with SAP business solutions
Portal Collaboration
SAP Business Information Warehouse
Platform independency
Running on all SAP platforms
Web
AS SAP GUI for Windows SAP GUI for HTML
6.20 SAP GUI for Java
Web
AS
6.30
Web
AS
specialized
6.40
user client-side WebDynpro
interfaces rendering
(e.g. data + active
t mining, components
(e.g. office)
client-side rendering server-side rendering
CAD, etc.) (dynamic HTML) (static HTML)
zero installation
high interactivity
SAP NetWeaver – Exchange Infrastructure
SAP NetWeaver™
People Integration
Multi-Channel Access
Portal Collaboration
Process Integration
Integration Business Process
Broker Management
Application Platform
J2EE ABAP
DBDBand
andOS
OS Abstraction
Abstraction
Overview Exchange Infrastructure 2.0
Integration
Integration Server
Server
Integration
Integration
Integration Integration
Integration
Business Additional Marketplaces
Engine Process Integration
Repository
Repository Directory
Directory Engine
Services
SOAP
Plain HTTP
SAP NetWeaver™
People Integration
Multi-Channel Access
Portal Collaboration
Process Integration
Integration Business Process
Broker Management
Application Platform
J2EE ABAP
DBDBand
andOS
OS Abstraction
Abstraction
SAP Web Application Server
Overview
Platform independent
Extensible
Evolution of SAP application Internet Communication Manager
Java IDE
server technology
Software Lifecycle
Highly scalable and reliable
Management
Web Dynpro
Highly efficient development Web Services
environment Infrastructure
Workbench
Professional UI development J2EE ABAP
ABAP
Eclipse-based Java IDE
Proven ABAP development tools Database Abstraction
Unified infrastructure
SAP Web Application Server
Common connectivity
Common persistence
Common user management Database
Comprehensive software lifecycle
management
Technological changes drive architecture
ESA: Definition
SAP NetWeaver Overview
Architectural implications for SAP Banking
SAP for Banking: Different solution layers
Application
Technology
Applications
Processes
Roles
Scenario- and Service-oriented Software Architecture
Scenarios
Modeling
Service Layer Repository Modelling
Content
Platform
Business Business
Apps &
Logic Logic
Services
Business objects Business objects xApp
Focus on performance
Objectives of the architecture
Components, layers and objects
Object creation
Standard header
Transaction control
Database changes (buffers)
Main memory synchronisation
PE layers
Error handling
Objectives of the Payment Engine Architecture
„Principle of least surprise“ for the developers and for the colleagues
from IMS
Component
Database
Components, Layers and Objects, overview:
Structure of a core (non-BPC) component
Object
AM
Process Process Process Process
Object Object Object Object
Proxy for
s_instance access to
Factory
external
system
getReference doSomething
doSomething External
system
Client object
Objectives of the architecture
Components, layers and objects
Object creation
Standard header
Transaction control
Database changes (buffers)
Main memory synchronisation
PE layers
Error handling
Object creation
: theInstance :
: Client
SingletonClass SingletonClass
s_instance( )
[no instance available] constructor
returnInstanceRef
method1( )
method2( )
Object creation: multi-instance class
: anInstance :
: Client
MultiInstanceClass MultiInstanceClass
s_instance( )
lookupInTable( )
[instance found] returnRef
storeInstanceInTable( )
returnRef
method1( )
method2( )
Objectives of the architecture
Components, layers and objects
Object creation
Standard header
Transaction control
Database changes (buffers)
Main memory synchronisation
PE layers
Error handling
Standard Header
See also the slides on transaction control for an example of the usage of
the standard header.
Standard Header
Process Object
The ABAP commands “commit work” and “rollback work” are not allowed
inside methods. Instead, there are two methods in the standard header
which are responsible for transaction control.
The method that fills the field “ta_owner” (using the s_instance-method
with “flg_enforce_recreation” on “true”, or “check_ta_control”) has the
responsibility to close the transaction with “commit” or “rollback”.
If a BAPI wrapper writes some string (e.g. “BAPI”) into “ta_owner”, the
BAPI programming model is automatically enforced.
Transaction Control (II)
Typically, the layer which creates the standard header instance is also the
layer which is responsible for transaction control.
StdHdr
Call with empty TA flag
TA flag
PM1 PM1
StdHdr
StdHdr
TA flag
Check => no TA flag
Check => method
TA control
PM1 has TA control
PM1
Objectives of the architecture
Components, layers and objects
Object creation
Standard header
Transaction control
Database changes (buffers)
Main memory synchronisation
PE layers
Error handling
Database Changes: Buffering
All changes (inserts, deletes, updates) are written to the buffer first.
There are two points in time at which the changes are written to the
database:
If a predefined number of changes has been made
If a method in the Standard Header is called, which fires events that cause the
buffers to be written to the database
Writing to the database is done using internal tables and the SQL clause
“from table …”. This is much faster than single inserts.
After a commit / rollback, all these buffers have to be cleared. After this,
the buffers will be rebuilt, and the locks will be reacquired.
Main memory synchronisation: Event handling
Payment Engine-Class
Class
“/pe1/cl_bpe_memory_synch” + s_memory_synch()
Event
Event
“transaction_finished”
“transaction_finished”
Payment Engine-Class
+ s_memory_synch()
Commit or rollback
has happened
Objectives of the architecture
Components, layers and objects
Object creation
Standard header
Transaction control
Database changes (buffers)
Main memory synchronisation
PE layers
Error handling
Process and GUI Services
Process Process
GUI GUI
Service Service Service Service
Components, Layers and Objects: Graphical overview
AM
GUI Process GUI Process
Service Service Service Service
Business Process Control: This is the workflow layer of the Payment Solution.
Objects of the BPC are typically singletons (see the chapter on object
creation).
Some BPC methods do not comply with the BAPI programming model.
These are methods which handle files with a large number of orders and
items. In this case, the method would have to commit at defined points in
the process.
Process classes and their methods are the interface of a component to the
outside world (channels, other components).
They can be the owner of an LUW. Within the process methods, the calls to
“check_ta_control” and “ta_control” are implemented.
They only use the entity methods of their own component, process
methods of other components or technical support methods (e.g. methods
of the standard header).
Payment Engine Layers:
Entity Layer
Entity methods are only called from the process methods of the same
component.
Payment Engine Layers:
Persistency Layer
Persistency classes are the only classes which access the database
tables.
They are responsible for database buffering, enqueues (locks) and bulk-
writing of changes to the database (see the chapter on database buffering).
Objectives of the architecture
Components, layers and objects
Object creation
Standard header
Transaction control
Database changes (buffers)
Main memory synchronisation
PE layers
Error handling
Error handling: Exception classes (I)
Error handling in the Payment Engine uses the new basis class
mechanism: exception classes instead of traditional exceptions (sy-subrc).
CX_ROOT
Classes from the
ABAP Objects
Exception hierarchy
CX_STATIC_CHECK
Top-Level
Exception of the
CX_PE_ERROR Payment Engine
+ classname
+ methodname
+ errorlevel
+ exception
CX_PE_<Component>_ERROR CX_PE_<Component>_ERROR
This makes sense if an error reported from another method is not an error
in the view of the calling method.
(nothing)
Error handling: Handling exceptions, variant 2:
Not reacting to an exception
This is typically used if the method has no chance to react properly to the
exception.
Exception
Error handling: Handling exceptions, variant 3:
Catching and re-raising an exception
The easiest way to implement this is to catch the exception into a local
variable and raise it using “raise exception <localvar>”.
Error handling: Handling exceptions, variant 3:
Catching and re-raising an exception
Exception
Error handling: Handling exceptions, variant 4:
Replacing exception(s) with a new exception
Exception New
Error handling: Handling exceptions, variant 5:
Putting a new exception in front of other exception(s)
Focus on performance
Package Processing
Buffering
Database Partitioning
Summary Performance Aspects
Payment Order Processing: Packages
Business Process
3. Package processing
PS Component
Buffer
Payment orders which fit into one package can be simulated (typically online
orders).
All changes to business objects (orders, items…) of a package are written to the
database as one block.
Package Processing
Buffering
Database Partitioning
Summary Performance Aspects
Buffering in the Payment Solution
PS Component
Business object
Business object
Business object
Object buffer
SAP Object buffer
Object buffer
Application
Server
Persistency object
Table buffer
Network traffic
SAP
Database
Server
Buffering in the Payment Solution
In addition to the SAP Database Server, the Payment Solution buffers all data from
the database (orders, items, master data, customizing data) within its own
persistency objects.
This minimises the network traffic between the Database Server and the
Application Server(s).
There are buffering mechanisms available that are optimized for database
operations and for business functionality.
Segmentation Area A
Client 1
Segmentation Area B
Segmentation Area C
Client 2
Segmentation Area D
Segmentation Area F
Client 3
Segmentation Area G
Database Partitioning
Mass access to the database optimises I/O speed and minimises network traffic.
Database partitioning ensures that parallel processes do not get into conflict on the
database level.
Business object instance reuse ensures that the garbage collector will not slow
down the system periodically (a typical problem encountered with object-oriented
systems).