Introduction to the

Payment Solution
Software Architecture
Dr. Joerg Wegener
Development Architect SAP Banking, SAP AG
Introduction to the Payment Engine

ESA and NetWeaver

Payment Engine Architecture

Focus on performance
Goals and Characteristics
Functional Overview
Payment Engine Sample Process
Current Challenges in the Payment Industry

Single Euro Payment Area (SEPA)

Potential cost savings in payment transactions

Straight Through Processing

Complexity of new clearing procedures

Insourcing and outsourcing models

...
 Goals and Characteristics I

Integrated component of SAP Core Banking

The Payment Engine enhances SAP Core Banking by adding a
payment transaction component to form an integrated and
efficient complete solution

Architecture
A generic component with well-defined interfaces to upstream
and downstream systems and account-managing systems

An open integration platform for payments and postings

between different position-managing systems

A generic architecture offering independent usability for

payment transactions in large banks and IT centers

Flexible exception control with an integrated postprocessing

function for error handling
 Goals and Characteristics II

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

A high degree of automation of payment transaction

processing, and mapping of current clearing scenarios
regardless of channel, format and clearing system

Improved service due to 24-7 real time processing of payment

orders and online posting of all resulting payment items

One application covers all core processes for domestic and

foreign payment transactions

IT center usability (client capability)

- High performance for mass processing
- Separate control data
 Goals and Characteristics III

Uniform Processing Logic

Implements a non-format dependent and therefore universally
usable payment order for the core processes within the
Payment Engine

Transparency
Integrated status concept
The complete life cycle of the payment order can be traced
(complete audit trail)

Straight Through Processing

Supports Straight Through Processing by adhering to STP
criteria:
- IBAN, BIC, BIF/MIF regulation of charges
Goals and Characteristics
Functional Overview
Payment Engine Sample Process
Architecture
 File Handler Functions

Batch interface for individual and

collective payment orders

Online interface for individual and

collective payment orders

Input Manager with customer format

converter

File Handler database with data from

the original format

Receives outgoing payment orders

from the Payment Engine

Output Manager with customer format

converter for outgoing payment
orders

Receives confirmation from transfer

system

Available
Planned
Release 2.0
 Payment Processing Functions I

Payment order validation

Ordering party item validation

Recipient item validation

Duplicate processing check

Check for recalls

Parking of scheduled payment orders

Release of payment orders and

payment items (principle of dual,
treble or quadruple control)

Receipt of coverage matching

between payment order and coverage

Blank check validation

Available
Planned
Release 2.0
 Payment Processing Functions II

Administration of payment orders in

Payment Engine metaformat (create,
change, reverse, reject, display)

Administration of recalls (create,

change, delete, match, display)

Postprocessing of payment orders

and payment items (release, reject,
reverse, redirect...)

Search for payment orders and

payment items

Simulation processing of a payment

order

Administration of locked checks

Available
Planned
Release 2.0
 Route Processing Functions

Administration of rules for routes,

clearing agreements, customer
agreements and value date
agreements

Determination of route

Determination of clearing agreement

and customer agreement

Determination of value date

Administration of route

Administration of clearing agreement

and customer agreement

Administration of clearing house

Cut-off-dependent route processing

Amount split for outgoing payment

orders

Administration of value date

agreement

Release of changed objects (principle

Available
Planned of dual, treble or quadruple control)
Release 2.0
Determination of Route and Clearing Agreement

Payment
Item
Exception Control

1 Search for Route

2b Search Unsuccessful Clearing
Agreement
R rule set XY / Z

4 Search Unsuccessful

4a Search Successful
2a Search Successful

CA rule set for route XY

Route
XY
3 Search Clearing
Agreement
 Clearing Processing Functions

Clearing = creation of new outgoing

payment orders and coverage orders

Creation, administration, closing and

posting of collectors

Creation, administration, closing and

posting of queues

Authorization using an account-

managing or posting control system

Posting of internal payment items in

an account-managing system

Transfer of outgoing payment orders

to the Output Manager

Currency exchange including posting

in account currency

Calculation and posting of charges

(BEN, OUR, SHR, BIF/MIF etc.)

Available
Planned
Release 2.0
 Exception Control Functions

Exception control

Administration of response types

Administration of rules

Available
Planned
Release 2.0
 Postprocessing Functions

Postprocessing of payment orders

Rejection of payment orders

Reversal of payment orders

Return payment items

Redirection of payment items

Postprocessing of payment items

Start further processing

Workflow connection

Available
Planned
Release 2.0
 General Functions

Application logs

End-of-day processing

Reconciliation

Accrual function

Change documents

Authorization management including

role definition

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

Input Manager Payment

Orders in
1 Payment 3 Metaformat
DME Format PO in PE
File Converter Metaformat Processing
4

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

ESA and NetWeaver

Payment Engine Architecture

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)

SOA = Service Oriented Architecture

 Lose Kopplung zwischen Clients und Servern
 Dynamisches Binden von Services zur Laufzeit
 Beschreibung von Services durch Repositories
 Entkopplung von Schnittstelle und Implememntierung
 Entkopplung von Geschäftsprozesssteuerung und Funktionsblöcken
 Implementierung z. B. mit Web-Services

* 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

Open, Web Services Environment

ESA is the blueprint for complete and services-
based business solutions
 Empowers all people participating in a business People
process Integration
(internal and external, all relevant user roles)
Information
 Manages all information relevant for a business
Integration
process
(structured and unstructured)
Process
 Encompasses all systems relevant to a business Integration
process
(SAP and non-SAP) Enterpr. Services
SAP delivers its business solutions using an
Enterprise Services Architecture
 SAP NetWeaver is the platform that implements an
ESA Existing Systems
 SAP xApps, mySAP Business Suite, etc. are
powered by SAP NetWeaver
Technological changes drive architecture
ESA: Definition
SAP NetWeaver Overview
Architectural implications for SAP Banking
 SAP NetWeaver™
The total integration and application platform for lower TCO

Unifies and aligns people,

SAP NetWeaver™ information and business
processes
People Integration
Multi-Channel Access
 Integrates across technologies and
organizational boundaries
Portal Collaboration  A safe choice with full .NET and J2EE
Composite Application Framework

interoperability
Information Integration

Life Cycle Management

Business Knowledge
The business foundation for SAP
Intelligence Management and partners
Master Data Management  Powers business-ready solutions that
reduce custom integration
Process Integration  Its Enterprise Services Architecture
Integration Business Process increases business process flexibility
Broker Management

… Application Platform …
J2EE ABAP

DBDBand
andOS
OS Abstraction
Abstraction
.NET Websphere
SAP NetWeaver in Detail (SAP Internal View)
Product components and killer features

SAP Mobile Infrastructure

 Tight coupling and alignment

SAP NetWeaver™
with SAP business solutions

SAP Enterprise Portal

 Business packages People Integration
 Collaboration Multi-Channel Access

Portal Collaboration
SAP Business Information Warehouse

Composite Application Framework

 Business content
Information Integration

Life Cycle Management

 Tight integration to SAP
 Open architecture (Crystal,Ascential) Business Knowledge
Intelligence Management
Master Data Management Master Data Management
 Coming in 2003

SAP Exchange Infrastructure Process Integration

 Proxy generation and mapping tools Integration Business Process
Broker Management
 Integration directory
 SAP’s ability to execute
Application Platform
SAP Web Application Server J2EE ABAP
 Proven, scalable, comprehensive toolsets
 Leverage existing infrastructure/skill sets DBDBand
andOS
OS Abstraction
Abstraction
 Web Dynpro – Advantages

Web Development for business

critical applications Web Dynpro Web Dynpro
Tools Meta-Data
 Minimal Coding, maximum Design
 Separation of presentation and
business logic Web Dynpro Runtime
 Connect to any backend
 Focus on patterns .NET J2EE ABAP

Platform independency
 Running on all SAP platforms

Modern web user interface HTML Rendering

Cache for
 Browser based, „zero footprint“ Layout, Data-
Local binding
 Incrementel page reproduction DOM
Events
 Client Side Framework
 Intelligent Caching Web Dynpro Client-side framework
 Personalisation
 Section 508-capable Smart Browser (IE 5.5+, NN 7)
 The future: Metamorphosis of SAP GUIs

high interactivity zero installation

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

Composite Application Framework Information Integration

Life Cycle Management

Business Knowledge
Intelligence Management
Master Data Management

Process Integration
Integration Business Process
Broker Management

Application Platform
J2EE ABAP

DBDBand
andOS
OS Abstraction
Abstraction
Overview Exchange Infrastructure 2.0

Shared Collaboration Execute Collaborative

Knowledge Business Processes
3 rd Party and
Messaging Systems
Design Configuration Runtime
SAP Systems

Integration
Integration Server
Server
Integration
Integration
Integration Integration
Integration
Business Additional Marketplaces
Engine Process Integration
Repository
Repository Directory
Directory Engine
Services
SOAP
Plain HTTP

System Partner Eco -System

System Landscape
Landscape Directory
Directory Runtime Workbench
(additional 3rd Party
Adapters and Industry
Standards)
SAP NetWeaver – SAP Web Application Server

SAP NetWeaver™
People Integration
Multi-Channel Access

Portal Collaboration

Composite Application Framework Information Integration

Life Cycle Management

Business Knowledge
Intelligence Management
Master Data Management

Process Integration
Integration Business Process
Broker Management

Application Platform
J2EE ABAP

DBDBand
andOS
OS Abstraction
Abstraction
SAP Web Application Server
Overview

Open system architecture

 J2EE certified
 Standard-based Web Services
provision Browser Portal 3rd Party XI

 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

Prozess UI, Role Implementation

Blueprint
Reporting

XI Interaction Layer UI Interaction layer Implementation

Scenarios
Modeling
Service Layer Repository Modelling
Content
Platform

Services Events Services Events Implementation

Business Business
Apps &
Logic Logic
Services
Business objects Business objects xApp

Scenarios consist of Blueprint Content, Content Platform, (x)Apps and Services

Introduction to the Payment Engine

ESA and NetWeaver

Payment Engine Architecture

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

Be close to the AM architecture; reuse as much as possible

Performance (several million payment items per day)

Scalability (parallel processing on different machines)

„Principle of least surprise“ for the developers and for the colleagues
from IMS

Strong modularisation (exchangeability of components, both internal and

external ones), loose coupling of components

Consistent handling of all technical issues (transaction control, buffering,

error handling, logging, ...) across all components
Objectives of the architecture
Components, layers and objects
Object creation
Standard header
Transaction control
Database changes (buffers)
Main memory synchronisation
PE layers
Error handling
 Components, Layers and Objects, overview:
Structure of a core (non-BPC) component
External access

Component

Process Process Process Process

Object Object Object
Classes

Entity Entity Entity Entity Entity Entity

Classes Object Object Object Object Object

Persistency Persistency Persistency Persistency

Object Object Object
Classes

Database
 Components, Layers and Objects, overview:
Structure of a core (non-BPC) component

Components consist of three layers:

 The Persistency Layer is responsible for the access to the database, including locks
(enqueues).
 The Entity Layer represents the objects of the real world the PE interacts with
(payment orders, items, clearing agreements etc.). These are the “traditional” objects
of OO approaches. As such, they are typically stateful.
 The Process Layer consists of objects which represent the individual steps, or tasks,
in a business process. They are atomic: they either succeed or fail. If they succeed,
they can change entity objects. If they fail, the entity objects will be reset in memory
to the prior correct state. Dan Woods calls them “read/write services”.
 Another kind of process object provides more fine-grained methods which can leave
an object in an unchecked and unsaved state. They are required for UI access. Dan
Woods calls them “UI-services”.
 Components, Layers and Objects, component coupling: Graphical
overview, factory, proxy
Business Process Control Legend:

BPC Fac Use of a Factory

Object

Component One Component Two

AM
Process Process Process Process
Object Object Object Object

Entity Entity Entity Entity

Object Object Fac Proxy
Object Object

Persistency Persistency Persistency Persistency

Object Object Object Object
BCA
 Components, Layers and Objects, component coupling: factories

Factories are a means of shielding from the client component knowledge

about the nature of the server component.
 The client does not have to know whether a SAP component or an external, third-
party component is providing a service.
 The server component can be exchanged; the change would only affect the factory,
and not the client component.

For performance reasons it is not practical to use a proxy for the

communication between PE-internal component.
 Therefore in the case of PE-to-PE communication, a “direct” reference to the server
class is created (in the factory), while in the case of external communication, a proxy
is created. See also the following two slides.
 The client component does not see the difference at all.
Components, Layers and Objects, component coupling: external
communication

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

In the Payment Engine, all constructors are private. All non-abstract

classes have a class method s_instance, which is responsible for the
instantiation of objects. This is the only method which calls the
constructor.

There are some patterns in OO which require the constructor to be private

(e.g. “singleton”). By making all constructors private, the client class of a
class does not have to know whether the class is a singleton or not.

Furthermore, memory management can be optimised. A possible example

is the reuse of instances of objects in order to avoid garbage collection.

In the case of singletons, the “classic” singleton mechanism is used. In the

case of multi-instance classes, a class table mapping the business key of
the object to its reference is used. This class table is the central repository
of references to objects.
Object creation: singleton

: theInstance :
: Client
SingletonClass SingletonClass
s_instance( )
[no instance available] constructor

[no instance available] storeRef

returnInstanceRef

method1( )

method2( )
Object creation: multi-instance class

: anInstance :
: Client
MultiInstanceClass MultiInstanceClass

s_instance( )
lookupInTable( )
[instance found] returnRef

[instance not found] constructor

instanceReference

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

All methods in the Payment Engine have an obligatory import parameter: a

reference to an object /pe1/cl_bpe_standardheader.

The standard header is a container for technical information and

functionality.

It contains information required for the transaction control, logging and

protocols, and various technical flags and methods.

The standard header is a singleton. However, sometimes it is necessary to

discard the (single) instance and create a new one. To cater for this, the
method “s_instance” contains an import parameter which enforces the
recreation of the standard header instance.

See also the slides on transaction control for an example of the usage of
the standard header.
Standard Header

Process method call

StdHdr Business parameters

Process Object

Entity method call

StdHdr Business parameters

Entity Object

Persistency method call

StdHdr Business parameters

Persistency 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
 Transaction Control (I)

Transaction control (commit/rollback) can happen on the level of process

methods, BPC methods or externally (in the BAPI scenario).

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”.

Each BPC and Process Method checks whether it is responsible (ie., no

other method has claimed responsibility yet). If no other method is
responsible, the method “signs the standard header” with its name (see
following slide).

If a BAPI wrapper writes some string (e.g. “BAPI”) into “ta_owner”, the
BAPI programming model is automatically enforced.
 Transaction Control (II)

Transaction control will usually happen on the level of channels (GUIs,

BAPI wrapper function modules). However, the transaction control
methods of the standard header are only tools. How the tools are used is
dependent upon the context of the specific business process.

Typically, the layer which creates the standard header instance is also the
layer which is responsible for transaction control.

TA control has to be documented in the Payment Engine object model.

If a method (for example, a top-level BPC method) wants to have

transaction control, it has to ensure that the field “ta_owner” of the
Standard Header is empty. This can be achieved by creating a new
instance (calling “s_instance” with the recreation parameter set to TRUE)
and calling “check_ta_control” afterwards.

The business process defines whether a single commit / rollback at the

end is sufficient, or whether an LUW has to end at certain points like the
end of the processing of a package.
Transaction Control (III)

StdHdr
Call with empty TA flag
TA flag

Process Method 1 Process Method 2 PM2 leaves responsibility

with PM1
PM1 declares
StdHdr StdHdr
Itself responsible
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

The database methods of the Payment Engine operate on internal buffers

(performance).

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.

Buffer Fetch all records Temp ITAB

which are to be Insert, update or
inserted, updated delete “from table”
or deleted
Objectives of the architecture
Components, layers and objects
Object creation
Standard header
Transaction control
Database changes (buffers)
Main memory synchronisation
PE layers
Error handling
 Main memory synchronisation: General features

One of the features of ABAP is that at the moment of an ABAP commit or

rollback, all locks are released.

During the duration of an LUW, using locks (enqueues), it is possible to

implement buffering knowing that the data which is buffered is not
changed by some other process.

In the Payment Engine, there is buffering implemented on the database

level (persistency layer) and the business level (entity layer).

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

Whenever the ABAP command “commit work” or “rollback work” is

executed, the runtime basis raises an event “transaction_finished” of the
class “cl_system_transaction_state”.

This event is caught by a technical class. A Payment Engine-event

(“transaction_finished” of the class “/pe1/cl_bpe_memory_synch”) is
raised.

This event is caught in static methods of all Payment Engine-classes

(“s_memory_synch”).

These methods are responsible for the clearing of buffers.

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

User Interface Business Process

Component One Component Two

Process Process
GUI GUI
Service Service Service Service
 Components, Layers and Objects: Graphical overview

PS GUI Business Process Control

Component One Component Two

AM
GUI Process GUI Process
Service Service Service Service

Business Business Business Business

Object Object Proxy
Object Object

Persistency Persistency Persistency Persistency

Object Object Object Object
BCA
Component Structure of the Payment Solution

 PS GUI: The PS GUI is an independent application from the Payment Solution

business components’ point of view.

 Business Process Control: This is the workflow layer of the Payment Solution.

 Services: Services make up the interface of a component. They are differentiated

into GUI services and transactional services. Services can be called externally (e.g.
via BAPIs).

 Business Objects: Business objects provide the functionality of the Payment

Solution.

 Persistency Objects: Specialised database access objects tuned for high

performance and buffered database access.

 Proxy: The proxy is the communication mechanism to external account managing

systems.
 Payment Engine Layers:
Business Process Control Layer

Objects of the BPC are typically singletons (see the chapter on object
creation).

The BPC represents the business process logic.

A BPC method can be regarded as a part of a business process, e.g.

several tasks in an eEPC.

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.

BPC methods can be the owner of transactions.

 Payment Engine Layers:
Process Layer

Process classes and their methods are the interface of a component to the
outside world (channels, other components).

They are typically stateless.

They leave their component behind in a correct state. In other words, if

they change entity objects, they check the entity objects for correctness,
and if this fails, they reset the entity objects to their former state.

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

The entity objects correspond with “traditional” objects in an object-

oriented system.

The methods are structured according to the programming model also

found in the Account Management.
 Set-methods change the state of an object
 Get-methods read the state of an object
 Check-methods make sure that the state of an object (the values of its’ attributes) is
valid
 Save-methods store the object on the database (if the state has been checked
successfully before)
 Reset-methods restore the last correct state of an object. They are called after a
failed call to a check-method.

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).

Exception handling with the new classes follows a new programming

model. It basically works in a way similar to the exception handling model
in C++, Java or Python.

All exception classes must be derived from basis classes (cx_no_check,

cx_dynamic_check or cx_static_check). In the Payment Engine, there is a
central class (cx_pe_error), derived from cx_static_check, from which all
other Payment Engine exceptions are derived.

Under the exception “cx_pe_error” exists a group of abstract exception

classes ordered by component (“cx_pe_<component>_error”). All non-
abstract exceptions are derived from one of these exception classes.

For details see the ABAP documentation of the exception classes.

 Error handling: Exception classes (II)

As all Payment Engine exceptions are ultimately derived from

“cx_pe_error”, some additional attributes defined there can be found in all
Payment Engine exceptions:
 “classname”, “methodname”: to be filled with the “ID” of the method which raised the
exception.
 “errorlevel”: the error level of traditional T100-messages (E, A, W, I, X, S).
 “exception”: a field which can be filled with the value of SY-SUBRC to further clarify
the nature of an error (e.g. the value of SY-SUBRC after a database “not found”
error).
 “context_str_name”: structure name of context information
 “context_str_value”: the content of the context information
 “flg_application_log_written”: flag which shows that the exception has already been
logged in the application log (so logging the same exception several times can be
avoided, unless this is specifically requested).
Error handling: Exception class hierarchy

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

CX_PE_<Component>_SpecificError CX_PE_<Component>_SpecificError CX_PE_<Component>_SpecificError

 Error handling: Handling exceptions, variant 1:
Catching and ignoring an exception

If one catches an exception and does not pass it on or raises a new

exception, the exception is suppressed.

This makes sense if an error reported from another method is not an error
in the view of the calling method.

Example: “Duplicate key” in an insert database method might be okay in

an entity method which simply wants to ensure that some data is stored on
the database, and where the existence of the data is considered okay.
 Error handling: Handling exceptions, variant 1:
Catching and ignoring an exception

Called method: Exception

Catching the exception

Current method:

(nothing)
 Error handling: Handling exceptions, variant 2:
Not reacting to an exception

If a method does not catch an exception, the exception is passed to the

caller of said method.

This is typically used if the method has no chance to react properly to the
exception.

An example might be some standard header error which points to a more

general problem (violation of programming rules), that cannot be handled
by the method in question.
 Error handling: Handling exceptions, variant 2:
Not reacting to an exception

Called method: Exception

Current method: Doing nothing

Exception
 Error handling: Handling exceptions, variant 3:
Catching and re-raising an exception

This variant assumes that an exception which a method catches

adequately describes an error, but that some action has to be taken before
it can be passed on to the caller.

An example can be a process method which catches an error from an

entity method, calls the transaction control for cleanup and re-raises the
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

Called method: Exception

Catching the exception; reacting in some way;

Current method:
re-raising the same exception

Exception
 Error handling: Handling exceptions, variant 4:
Replacing exception(s) with a new exception

This pattern can be used if an exception condition has to be

“reinterpreted”.

The method catches some exception or list of exceptions, throws it away

and raises a new exception.
 Error handling: Handling exceptions, variant 4:
Replacing exception(s) with a new exception

Called method: Exception Old 2 Exception Old 1

Catching the exception; reacting in some way;

Current method:
raising a new exception

Exception New
 Error handling: Handling exceptions, variant 5:
Putting a new exception in front of other exception(s)

This is the usual way to handle an exception.

A method catches an exception and adds it’s own “interpretation” of the

situation at the front of the list of exceptions.
 Error handling: Handling exceptions, variant 5:
Putting a new exception in front of other exception(s)

Called method: Exception Old 2 Exception Old 1

Catching the exception; reacting in some way;

Current method:
raising a new exception; writing caught exception into „previous“

Exception New Exception Old 2 Exception Old 1

Introduction to the Payment Engine

ESA and NetWeaver

Payment Engine Architecture

Focus on performance
Package Processing
Buffering
Database Partitioning
Summary Performance Aspects
Payment Order Processing: Packages

Business Process
3. Package processing

2. Package 4. Individual 5. Package

of items updates finished

PS Component

Buffer

1. Mass read 6. Mass write

Payment Order Processing: Packages

 Package sizes can be configured to optimise hardware utilisation.

 Packages can run in parallel mode.

 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.

 Business objects that are no longer needed are recycled.

Package Processing
Buffering
Database Partitioning
Summary Performance Aspects
Database Partitioning

This could be Clearing Areas

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

Technical database key

Client SegKey GUID Business Attributes

Additional partitioning criterium,

especially useful for DB/2 on zOS
Package Processing
Buffering
Database Partitioning
Summary Performance Aspects
Overview: Performance Features

 Mass access to the database optimises I/O speed and minimises network traffic.

 Package-oriented business logic optimises execution speed on the level of

processes which operate on business objects.

 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).