05 architektur payment engine eng

Konzeptpapier oder Bericht (mit Deckblatt)

Payment Engine Software Architecture

Jrg Wegener

IBS FS, NAD OS IIPayment Engine Software Architecture

- Version 3.0 -

24th July 2003

Distribution:

Payment Engine Project

Table of Contents:

41Introduction

42Conceptual Architecture

42.1Object Orientation

42.2Collections

42.3Components

52.3.1Structure of Components: Internal Layer Model

72.3.2Coupling of Components

83Basics of the Structures of Methods and Classes

83.1Basic Properties of Classes

103.2Basic Properties of Methods

114Business Process Control Classes

114.1Properties of Business Process Control Classes

114.2Properties of Methods for Business Process Control Classes

125Process Classes

125.1Properties of Process Classes

135.2Methods of Process Classes

135.3Using Process Classes

146Entity Classes

146.1Properties of Entity Classes

146.2Methods of Entity Classes

157Persistency Classes

168Technical Topics

168.1The Standard Header

168.2Transaction Control

178.2.1Implementation of Transaction Control in (Business) Process Control Methods

188.2.2Check Method CHECK_TA_CONTROL

188.2.3Transaction Method TA_CONTROL

188.3Logging

188.4Main Memory Synchronization

198.4.1Standard memory synchronisation behaviour

208.4.2Memory synchronisation without reference deletion

208.4.3Memory synchronisation without buffer deletion for persistency classes

218.5Access to External Components

238.6BAPI Wrapper

238.7Error Handling

238.7.1Exception Hierarchy

248.7.2Reactions to Exceptions

318.7.3Processing Exceptions in the Calling Channel

328.7.4Conventions for Using Exceptions at Different Software Layers

329Standard Frameworks and Cookbooks

329.1Business Process Control Classes

329.1.1Standard Frameworks

329.1.2Cookbook

329.2Process Classes


339.2.2Cookbook

339.3Entity Classes


339.3.2Cookbook

339.4Persistency Classes


339.4.2Cookbook

3310Appendix

3310.1Target System of the Payment Engine Architecture

3310.1.1Aims that Can Be Derived from the Application

3410.1.2Aims that Can Be Derived from the Software Creation Process

3510.2Basic Understanding of the Architecture

3510.2.1Business Concept

3511Literature

1 Introduction

This document describes the architecture in the Payment Engine project from the point of view of the concept and the technical software. The application architecture, that is, an overview of the technical components, does not form part of the concept. The document describes in detail how technical components are usually created, how the responsibilities are split between the parts of the components, and how the components are integrated and work together.

The document is a working document that can be changed or added to by the author at any time as a result of practical experience in the project. The latest version will be stored on the Banking server and the different versions will be maintained in a CVS repository by the author.

Firstly, the document describes the conceptual architecture. At a general level, this defines the elements of the architecture and the understanding of business applications on which the elements are based. Then the different elements and layers are described in detail and cross-level global topics are also covered. The last section deals with the progress from architecture to realization using "Cookbooks" and standard frameworks.

The concept is based on the document "Software Architecture in IBU Banking (BCA View)", version 0.4. This is perhaps not evident at first, since the terminology used is sometimes different to the BCA terminology. Section2.3.1 contains a comparison and more detailed description. The document mentioned above can be used as a cross-product guideline for the IBS FS and therefore some areas where the details are to be created according to the requirements of specific products may not be covered in great detail. Topics such as logs, standard headers, transaction control, and so on are therefore specified separately for the Payment Engine in this document.2 Conceptual Architecture

In this document, the term "Conceptual architecture" describes the software elements of the Payment Engine (and some relevant operational systems) and its relationships. These are "abstract objects and components - the content of these objects and components are described here, but not the form of the program technology.

2.1 Object Orientation

The architecture and realization of the Payment Engine are generally object-oriented. Unified Modeling Language (UML) is used for the design and modeling, and ABAP is used for the implementation. A basic knowledge of the concepts of object orientation is required to understand the following sections.

2.2 Collections

ABAP objects themselves is not provided with a standard library of collection classes (as is the case with Java). Instead, it is possible to use internal tables as a way of replacing collections. The key definitions of the internal tables can be used to determine whether an element in a collection may appear a number of times (bag, vector) or only once (set).

2.3 Components

The Payment Engine is made up of a number of independent, technical components that cooperate with one another to complete their tasks. Examples of such components are Payment Order Processing, Route Processing, or Clearing Processing.

Components are larger functional units than classes. They consist of several classes and provide persistence mechanisms. Internally, they are structured according to a uniform model.

The components are decoupled from each other and only communicate via defined interfaces (component interfaces). In some cases, one component may have to access another component directly. One example is the payment order component that has to access the other components in read and write mode. In this case, a defined indirection within the calling component ensures that the payment order can be replaced by an external system if necessary without affecting the other components.

Generally, the functions that a component provides are nuclear from a business view (see also section10.2). These functions are linked to a business process such as "Processing a tape with a large number of payment items" or " Direct processing of a payment order for a cash machine" in a dedicated component responsible for linking individual business steps in a process. In addition, this component, called BPC (for Business Process Control; see section4), is also responsible for the type of coupling of other components (direct sequential method access, workflow, pipes and filters with load distribution over several process instances,...). It can be delivered with the core Payment Engine or created specifically for the requirements of individual customers within an implementation project.

The components presented here correspond to the SAP Business Object. In exactly the same way as the SAP business objects, the components are completely responsible for ensuring internal consistency and for persistence (storage in a database).

2.3.1 Structure of Components: Internal Layer Model

The Payment Engine components always have the same structure. This aids recognition and simple enhancement and maintenance of components.

The interface that the outside world uses to access the components consists of a number of methods from one or more Process Classes. These represent business-nuclear operations (see section3 for a definition of process classes and section10.2 for a technical, theoretical background). Process classes are responsible for ensuring that all technical objects managed by its components (open collectors during clearing, payment orders in payment order management) have the correct business status, and not just individual objects. Example: For a payment order, the process classes are responsible for ensuring that as well as the payment items, the payment order itself has the correct status. The process classes use the functions programmed for the entity classes (see section6).

Entity classes represent the business objects of payment transactions. They are encapsulated by process classes from the outside world and are integrated with one another more closely than the process classes by means of relationships. They do not contain any logic for storing the object status through their lifetime until runtime, but use persistency classes instead (see section7). Objects from entity classes ensure their own internal consistency, but not the consistency between them and objects from other entity classes (the methods of the process classes are responsible for this).

Persistency classes contain the access to the persistency mechanisms (database; theoretically, systems such as MQSeries are also possible) that save the status of the objects over their lifetime in the main memory. Lock management is also situated here, as well as a database table-related buffer mechanisms.

The following generally applies:

Database tables are always the responsibility of exactly one component and are written and read exclusively by persistency methods of the owner component. Exception: Customizing tables.

Persistency objects are accessed exclusively by entity objects of their own component.

Entity objects are accessed by methods of process objects of their own component.

Process object methods are accessed by component-internal or component-external methods and represent the external interfaces of the component.

Customizing tables are combined in a central component and can be read by all components that need the settings made there.

Graphically, you can portray a component as follows:

Note that this layer structure corresponds considerably to the layer structure of the BCA in the document "Software Architecture in IBU Banking (BCA View)" version 0.4, from a content view if not from a terminology view. The terminology used for the Payment Engine here is described in section5.2 of the above-mentioned document (process and entity classes).

The following table compares the component layers of the Payment Engine to the layer architecture of the BCA:

BCA Layer ArchitecturePayment Engine-Component Layer

MAPI layerPublic methods of the process classes

API layerPublic methods of the entity classes

Object layerPrivate methods of process, entity, and persistency classes (no direct equivalent in the form of a layer). The buffering of technical objects that transfer the object layer is done by buffering entity classes.

DB layerPublic methods of persistency classes

From the above table, you can see that the difference between the layer structure of the BCA architecture and the Payment Engine architecture is primarily one of terminology. One main difference however is that the BCA architecture permits an external access to the API layer, whereas the Payment Engine architecture does not permit external access to entity classes. The reason for this is the strict separation of tasks between the methods of the process class and the methods of the entity class (see sections 3 and 6). Further differences arise from the use of the Business Data Toolset (BDT) in BCA, but not in the Payment Engine.

The object term on which the BCA architecture concept is based is oriented on the SAP business object that is responsible for communication with the outside world and for ensuring internal and external consistency and persistence. These are generally units that are larger than programmable technical objects and correspond more to components. In the concept described in this document, "objects" are technical software units (frequently in fine detail); the corresponding abstract level in the Payment Engine is the component (see also [Szyperski97] and [HerzumSims00]).

2.3.2 Coupling of Components

One aim of using a component architecture is the exchangeability of components with other components that have the same functions. In practice however, this is not possible without additional effort, since the similar external components in the business functions only very rarely have exactly identical interfaces. You can, however, make the exchangeability easier by using specific additional encapsulation measures.

One such measure is that the components access each other directly as little as possible and that functions are summarized via a superordinate independent component. This independent component is called Business Process Control (see section4). The process methods then only represent the individual steps of a superordinate transaction and can be combined to create new transactions without modifying the components.

The independent component can ensure the coupling via various mechanisms, dependent on the requirements of the individual customer. The customer can use standard SAP mechanisms or implement the independent component himself as part of an implementation project.

In some cases, however, direct access from one component to another without using independent components is useful. One example is the component "Payment Order Processing. It is useful to access process methods of "Payment Order Processing" directly from subsequent components such as "Route Processing" or "Clearing Processing" in order to post and read payment orders. However, even here, the access is exclusively to the methods of the process class and not to methods of the entity class or persistency class or directly to database tables of the payment order. Special classes are defined for this case. These special classes generate the instances of the process class of the component "Payment Order Processing" for the using component. Here, you can also use "Proxies" instead of direct process objects so that you can connect an external system instead of the SAP payment order component if necessary. See also section8.4.2.

When accessing external components (SAP or non-SAP components) it is not usually possible to work in a LUW. In such scenarios you need to analyze how the connection to the external components should be made:

Synchronous versus asynchronous

Safety requirements (guaranteed message delivery)

Mechanisms for recognizing and tracing errors (logging, restart)

SAP technology (RFC, tRFC, qRFC, IDOC, XI, ) or non-SAP technology (MQSeries, CORBA, )

The decisions made will be specified in the design of the connection proxy for each connection of external components.

The following two figures show the procedure for direct access to other process classes and for using external components.

3 Basics of the Structures of Methods and Classes

3.1 Basic Properties of Classes

Classes appear in two forms in the Payment Engine: Singletons and Multi-instance classes. Singletons are classes with a maximum of one instance and which typically have no status. Examples are the persistency classes (section7), typical process classes (section5) and business process control classes (section4). Multi-instance classes are "classic" classes of which there can be more than one object. Examples are entity classes (section6) and atypical process classes (section5).

All classes have an "s_instance" class method that is responsible for creating instances from the class-external view. You are not permitted to access a constructor from outside a class. You always specify a business key for the object to be created for the "s_instance" method.

For singletons, the "s_instance" method follows the classic pattern [Gamma+95]:

For multi-instance classes, there is a reference table at class level. This table contains the object reference for each business key. The "s_instance" method checks this table to determine whether the object with the transferred business key already exists in the main memory. If it does, the reference is returned. If the key does not exist in the main memory, an instance is created, stored in the reference table, and the reference is returned.

This means that if two different objects access an object of a multi-instance class with the same business key, both receive the same reference returned, provided they are running in the same work process. You want this to happen since, within the work process, no competing parallel access can occur. The classic problem of having several instances of "Customer 4711" in the memory of one work process does not occur.

These two procedures ensure that references to all objects can be found again centrally. This is, for example, important for main memory synchronization.

3.2 Basic Properties of Methods

The following basic properties apply for all public methods of process classes, entity classes, and persistency classes. They are described in more detail for each of the layers in the following sections and converted via standard frameworks in the form of code in section8.6.

All public methods at one level (process classes, entity classes, persistency classes) basically have the same structure. The responsibility for the selected technical topics (see section8) always lies at the same points within the software architecture. Direct access to the standard header (see section8) is never permitted - central technical services must be used; for example, you are not permitted to implement your own transaction handling (ABAP commands "commit work", "rollback work ).

Private methods only provide help functions. They are used to structure the coding and are subject to less strict requirements regarding the formal structure. Central technical functions, as described in section8, are not to be stored in private methods but in places where they are expected according to the standard framework of the method types. Private methods should only be used in the context of the business logic areas of methods (unless the standard framework explicitly states otherwise). They should therefore only contain parts of the business logic.

4 Business Process Control Classes

Component coupling was mentioned in section2.3.2. The control component "Business Process Control contains methods that correspond to subprocesses in ARIS-eEPCs. These methods access one or more methods of process classes sequentially. They represent the interface for the entire Payment Engine as an application, in the same way as the role of the process classes for the individual components.

The methods of these classes are technically contained in themselves, but are not nuclear. That means, that any changes you make in the database do not have to adhere to the all or nothing principle. For example, it is possible to conceive a method that reads a payment order from a tape and saves this in the Payment Engine. If one of the possible hundred thousand payment items had errors, a rollback would not be triggered and the other, correct payment items would be deleted from the database; the logic would be different (for example, logging of payment items with errors and notifying a supervisor).

Business process control classes have no status. They have no technical status that they save for all method executions. It may, however, be useful to save references to instances of process classes intermittently.

The methods of the business process control classes are the basis for parallelization in the Payment Engine. The highest level of the business process control classes (that is called up externally, not by other business process control classes) is responsible for parallelization.

4.1 Properties of Business Process Control Classes

All business process control classes have the same properties, as follows:

They are singletons, that is, there must be only one instance of each class. For details, see section5.

They have a class method "s_instance" that returns a reference to the singleton.

They have a class method "s_memory_synch" that is used for main memory synchronization (see section8.4).

They only access their own methods (if a business process of a higher rank is a summarization of subprocesses) and methods of process classes.

A business process control class is always completely responsible for one business process. Examples would be a class for the mass processing of payment orders (reading and processing tape) or a class for quick individual access (online scenario with customers at cash machines). The business process control classes always have a public method that starts the processing of the complete process and possibly also private methods that are responsible for subsections of the business process.

Each business process control class decides from the technical and subject context for which it is defined, whether and how transaction control takes place. Options are one transaction for a complete business process (useful for individual processing) or a commit/rollback after subprocesses (private methods) for mass processing.

4.2 Properties of Methods for Business Process Control Classes

The methods of business process control classes have the following responsibilities and properties:

They ensure that the standard header is filled correctly before the first process method is accessed. This means that they initialize some fields, derive other fields from general conditions, and so on.

They decide the type of transaction control as described above.

5 Process Classes

Process classes are the technical software equivalent of collections of business process activities that belong together. They provide the component interface for the outside world: If you want to use a component of the Payment Engine, you have to do this by using process classes, since each access to business objects takes place as part of a business process (see 10.2 for a basic overview).

Process classes summarize several process methods that belong together from a technical view. The following can be used as criteria to judge whether methods belong together:

Sequence within a process: Example: All methods that you need when you read a payment order (save payment order in status "Not completed", add payment items, close payment order).

Standard accesses to an entity class, particularly read accesses that are always required by different components. Example: Read payment items, read accompanying sheet.

A typical characteristic of a process class is that it has no status that persists over the life of the software object. This means that the process classes do not write their own attribute to the database. However, they are not necessarily without status in the sense that they have no attributes. References to entity objects can also be held for the duration of the method execution if this is useful from a performance point of view.

If it is necessary for process classes to save a status in the main memory for longer than the lifetime of the process class, you can either connect a workflow or build entity classes that represent the process as a business object and so trigger the persistence of the necessary information in the database layer.

Due to the fact that the process objects have no status with regard to their technical functions and save the references to the entity objects within a process, it makes sense to permit only one instance of a process class for each user. Basically, you can either define all methods of process objects as class methods, or use a "singleton pattern". Class methods have the disadvantage that they cannot be overwritten in subclasses in ABAP objects, or rather, that in subclasses, the methods of superclasses cannot be accessed using "subclass name => method name" (the user must know the inheritance structure and use "superclass => method name. This should be avoided from the view of object orientation). Instance methods can be overwritten. Process objects are therefore implemented as singletons as standard. This enables you to create inheritance structures in the process class area as well. It also enables you to manage several instances of process classes should such a need arise.

5.1 Properties of Process Classes

Process classes have the following properties:

Process classes have a class method "s_instance" that returns a reference to the singleton if the process class is realized as a singleton. See also the description of the singleton pattern in [Gamma+95] and section3.1. If the process class is not realized as a singleton, the "s_instance" method searches for a reference and if necessary, uses a constructor access to create a new instance and defines a reference to the instance in the global reference table in the same way as entity classes (see section6).

The constructor of process classes must not be accessed from outside the class.

Process classes that are not implemented as singletons have a global table that contains a temporary access key for the instance (sequential number, GUID, or similar) that is the technical key for the instance, plus a reference to the instance for which the technical key is valid. If the global table is accessed from outside, the "s_instance" method checks whether an instance already exists for the technical key transferred for the method. If this is the case, the reference is returned. If this is not the case, a new instance is created, defined in the global table, and its reference is returned to the initiator.

They have a class method s_memory_synch that is responsible for main memory synchronization.

They have a class constructor that registers the method s_memory_synch as the event handler for main memory synchronization (see section8.4).

5.2 Methods of Process Classes

The methods of the process classes have the following responsibilities:

Executing transaction control after the execution of the technical logic if they are the owner of the transaction; see section8.2.

Ensuring that all entity objects changed by the methods of the class are consistent. If you have to reset the status of an entity object here, you can do this by using the reset method, which enables a clean, encapsulated history function.

Methods of process classes can be defined with a BAPI wrapper and can be released as BAPIs for use by (SAP internal and external) external systems. BAPIs of the Payment Engine always map to methods of process or BPC classes.

5.3 Using Process Classes

A client who wants to access the process classes of a component must first obtain a reference to a process object. This is not done by accessing the constructor but by accessing the class method "s_instance", which returns a reference to the instance of the process class. Once this access has been executed, the client can then access the actual process methods via the reference.

The following graphic explains the connections:

6 Entity Classes

Entity classes correspond to business objects in the real world. The individual entity objects always correspond to exactly one form of such a business object. This means that here, in contrast to the process classes, it does not make sense to reflect the functions of an entity object via class methods or via a singleton. Within payment order processing, for example, several payment items are processed simultaneously. Therefore the "classic" object-oriented procedure of instance methods is used here with several permitted instances.

The criterion for the definition of entity classes is that they reflect concrete or abstract concepts from the real world. They therefore correspond more to the "classic" objects from object orientation than the process classes.

It is important here that each business object, that is, each payment item, must only be created once as an instance in the memory of a role area. Thus, several payment orders can be managed simultaneously, but for each payment order "4711", there must always be only one software object. This is guaranteed by locking the constructor and by using an "s_instance" class method.

6.1 Properties of Entity Classes

Entity classes have the following properties:

They generally have extensive attribute lists. These are always private. "Public attributes are not permitted. "Protected attributes should only be used in justifiable cases. The aim must be to decouple the classes within an inheritance hierarchy as much as possible.The attributes of an object are not created individually, but rather as single attributes of a structure type.

They are generally not singletons (see above).

An internal table is managed as the class attribute at class level. All objects previously created are defined in this table with their business key and reference. This table is used by the "s_instance" and s_memory_synch class methods (see below).

6.2 Methods of Entity Classes

The constructor, or the "s_instance" method of entity classes, has the following properties:

You are not permitted to access the constructor from outside. This is established in a special setting in the Properties tabstrip of the class.

Instead, in the same way as for process classes, an "s_instance" class method that delivers a reference to an entity object is provided. To do this, the method receives the business key of the object that it is to provide and uses it to check whether the entity object being accessed exists. If this is the case, the reference defined in the class attribute table is returned. If this is not the case, the constructor is accessed with the business key.

The "s_instance" method receives a parameter that specifies whether the entity object is to be accessed in read or write mode (including creation and deletion). This is required for lock management and defined in an instance attribute for the entity object. It is then checked if methods change. The process method is responsible for selecting the mode that the entity object requires. If the entity object is accessed via "s_instance" by a process object that the first process object of the business process does not recognize, and a stricter lock is set, the entity object tries to set the strict lock (using a "reload" from the persistency object). If this attempt is successful, the stricter lock then exists for all users, since there is only one instance of the same entity object (the payment order "4711") in the memory of a work process.

The general methods of the entity classes have the following properties:

They are not responsible for transaction handling. The process classes (or an even higher level) are responsible for transaction handling.

For each form of persistence (read, insert, update, delete), they access the methods of the persistence classes; that is, they do not access the database in any way.

7 Persistency Classes

Persistency classes provide the access mechanisms of the persistent attributes of the entity classes in relational database tables.

Persistency classes each map onto specific entity classes. They each facilitate the persistence of an entity class that requires this. It is, however, also possible that there are entity classes that do not have to be saved persistently because they only have a temporary character during the execution of a process. An example of this is classes that represent technical objects that are in other systems (current account systems).

Persistency classes have the following properties:

They store the information read from the database for access purposes.

Write accesses take place in the internal buffers until they are flushed to the database.

For each database table, there is an internal table with identical structures "at the front" at class level. This table is managed by the persistency class. It is used as a buffer mechanism. In addition to the attributes of the database table(s), a substructure is included which includes technical management information of the persistency class. For example, indicators of the type of locks (previously) set, possible "dirty" flags, or similar.

There is exactly one instance of each persistency class (singleton).Inheritance mechanisms are not used for persistency classes. You could therefore also work with class methods. However, for consistency and uniformity, the singleton pattern with the "s_instance" method is used. This ensures a uniform object creation behaviour in all component layers (principle of "minimal surprise" for the developers).

The initial access to the database (when creating an entity object) takes place via the technical key attributes.

Locks from the enqueue process are only requested in persistency classes.

The methods of persistency classes have the following properties:

When changes are made to data records that are stored in the internal table, the system first checks which lock was requested for the data record. If necessary, a "stricter" lock will be requested. If another process has already requested a write lock for the object, an error is triggered.

The input parameter for the read method has the business key attribute of the entity class plus a GUID and an indicator as to whether a read, a write/read, or no lock is to be requested.In the first step, the system checks whether the data record already exists in the internal table. If it does, it is returned from here. If the entity object requests a stricter lock than the one set, the system tries to create a relevant enqueue order. If this attempt is successful, the lock indicator in the internal table is updated. If the business key attributes are filled and the system does not find the data record in the internal table, the SQL access is carried out via the filled attribute(s). If the business key attributes are filled, the system searches using the business attributes.

The insert method first checks whether a data record with the relevant business key already exists in the ITAB. If this is the case, an error is triggered. If no error occurred, a GUID is created for the new data record. The system then tries to create a write lock for the data record. If this attempt is not successful, an error is triggered. In a third step, the data record is written to the database. In the case of an error (typically because there is a unique index to the technical key which is being violated), an error is triggered. If the procedure is successful (no error up to this point), the data record is written to the internal table. The insert into the database table happens if the corresponding event is triggered; see section???.

The update method first checks whether the data record is defined in the internal table. If it is not, a write lock is requested. If this is not successful, an error is forwarded to the caller. If on the other hand, this request is successful, the data record is read and placed in the internal table. Then the update to the internal table is executed.

The delete method first checks whether the object to be deleted is defined in the internal table. If this is not the case, an error is triggered. Reason: Deletion should only take place as part of the technical deletion of an entity object. To do this, you have to access an instance method of the entity object. In order for the instance to be deleted to exist, you must have accessed the constructor. To be successful, the constructor must have read the attributes of the instance via the persistency class. The object to be deleted should therefore normally be in the internal table.If the method finds the object, it checks whether the lock has the required level (write lock). If this is not the case, the system tries to raise the lock level. If this attempt is successful, the deletion in the internal table is executed.

The following applies for all writing methods: The actual SQL access (and no other logic!) is packed in a function module. Before the function module is accessed, the database method accesses the method GET_FLG_UPDATE_TASK of the standard header. This results in an indicator that shows whether accesses to write to the database should be made in the update task or locally. Dependent on this, the function module containing the SQL command is accessed in the update task or without an update task.

8 Technical Topics

This section covers selected general technical topics. It provides a quick introduction to the basic technical properties of the architecture.

8.1 The Standard Header

All methods have a central, mandatory IMPORT parameter, a reference to the Standard Header. This is always passed on when you access stored methods, that is, from the access to a process method up to the persistency layer and back, the same standard header instance is used.

The standard header is a technical container for transporting attributes that are used generally for managing the system. You can access it only via dedicated methods. Direct access to the attributes is not permitted.

In the standard header you can only store technical information that is needed centrally. Business data is not permitted here.

If you subsequently have to include global control attributes that were not considered in an earlier project phase, you can do this by enhancing the standard header without changing the source code at the points concerned. In this way you have increased flexibility for later changes to the basic design.

Examples of data transported in the standard header are:

The technical organizational unit.

User name if known. This can be provided externally if the user does not log on to the system directly but creates the link to the R/3 system via a middleware and then holds the link open centrally; in this case the name in SY-UNAME may no longer correspond with the user name.

Transaction control information. This tells the process method whether it is to execute the transaction control itself or whether the caller of the process method does this (see section8.2).

An indicator for whether database accesses occur in the update task.

Additional fields and attributes determined during the design of the central services.

8.2 Transaction Control

The transaction control takes place in either the process methods, the BPC methods or the external systems (business process control independence; see section2.3.2, or external systems that access the Payment Engine via BAPI interfaces). Depending on the type of component coupling, it can be useful for process methods to carry out the transaction control themselves (workflow connection or pipes and filters multiplexer coupling), or that the transaction control is carried out centrally as described above (obligatory if you use BAPIs).

After processing the technical logic, all the process methods access a method that handles the transaction control. This is a method in the standard header. You can specify another parameter for this method - this parameter indicates whether a rollback is necessary from the view of the process method (the process method can determine this by evaluating the exceptions of the entity method and/or the error structures in the standard header).

The transaction control method evaluates whether the process method is responsible for the transaction control or not. The first method that declares itself responsible for the transaction control sets a corresponding indicator in the standard header and notes the method name in a text field. If a process method in which no method has declared itself responsible for the transaction control is accessed, the process method takes over the transaction control, enters itself in the field and triggers a commit or a rollback after the technical logic.

When a commit/rollback is triggered, all locks are removed by means of DEQUEUE_ALL. This happens in the method provided by the Payment Engine which calls up the main memory initialization of the Tools & Technology group (see section8.4).

If a process method is to be accessed using a BAPI, the BAPI wrapper must enter an ID in the transaction control field (for example, "BAPI", or the name of the BAPI wrapper module) and thus ensure that no subsequent process method accessed takes over the transaction control. You can use this simple mechanism to ensure that the BAPI program model is adhered to.

8.2.1 Implementation of Transaction Control in (Business) Process Control Methods

Transaction control takes place in two steps: a check step that contains the technical logic of the method and that determines whether the method is responsible for control (see section8.2.2); and a triggering step that may initiate a commit/rollback (see section8.2.3). The general process is as follows:

method whatever.

* Some data declaration etc. ...

data: l_taowner_flg type /pe1/dte_bpe_boolean.

call method i_rcl_standardheader->check_ta_control

exporting

i_ta_owner =

receiving

r_caller_is_responsible = l_taowner_flg.

* Begin of business logic

*

* End of business logic

if l_taowner_flg = con_true.

call method i_rcl_standardheader->ta_control

exporting

i_ta_owner =

i_rollback_flag = .

endif.

endmethod.Here, you should note that TA_CONTROL must also be accessed if the method is exited by triggering an exception.

8.2.2 Check Method CHECK_TA_CONTROL

This method is accessed before the technical logic of the method. The input parameter is the name of the calling method (this should be a combination of class name and method name to ensure that the name remains unique). The method reacts as follows:

If the transaction control was already taken over by another method, this other method retains control. The return parameter R_CALLER_IS_RESPONSIBLE has the value FALSE.

If the transaction control was already taken over by the same method (cyclical access; see section8.2.3), nothing is changed and the value FALSE is returned.

If transaction control is not yet filled, the content of the import parameter is entered in the control field of the standard header and the value TRUE is returned.

The returned value R_CALLER_IS_RESPONSIBLE should be stored in a method-local variable (see section8.2.3).

8.2.3 Transaction Method TA_CONTROL

This method leads to either a commit or a rollback, depending on whether the rollback indicator is returned as TRUE or FALSE. As a check parameter, this has the name of the method that calls it up (this must be identical with the parameter that is transferred to the method CHECK_TA_CONTROL from section8.2.2). The method compares the name that is transferred to the name that is saved in the transaction control field. If they are identical, a commit or a rollback is carried out, depending on the rollback indicator.

This comparison is a safety mechanism that prevents any other method triggering a commit or rollback, apart from the one whose name has been entered in the control field. In most cases, this is sufficient. However, if there are cyclical accesses (M1->M2->M1), the second access of the same method would take over transaction control, not the method instance that originally filled the field! If a commit takes place in the second method access, a rollback in the (surrounding) first method access would at least be partly ineffective and could result in inconsistencies in the database.

For this reason, the return parameter R_CALLER_IS_RESPONSIBLE (see there) was incorporated into the method CHECK_TA_CONTROL (see section8.2.2). The method TA_CONTROL should only be accessed if this return parameter has previously returned the value TRUE. The example coding in section8.2.1 demonstrates this.

8.3 Logging

Parameters and error codes are logged using central modules. These are accessed at defined points in the layers (see section8.6).

The logging is controlled by various logging levels. These specify whether and to what extent logs are to be created. They are defined centrally in Customizing. In the standard framework, you can set an (optional) indicator that overwrites the indicator defined in Customizing. This can be used to specifically test individual methods.

See also the design paper on the Payment Engine application log.

8.4 Main Memory Synchronization

Releasing the main memory is a potential problem with temporary storage (buffers) of data, either in global tables such as in the persistency classes, or in the instances of classes such as in the entity classes. As described in section8.2, when the LUW ends, the locks are released. This means that from this moment, all buffered data can be invalidated by access by third parties. You must therefore delete the buffered data. This leads to the situation that all data has to be re-read, and new locks have to be requested. This ensures cross-process synchronization.

The procedure used for this is the procedure defined by the "Tools & Technology" group for cleaning up the main memory. At the time of a commit or rollback, there is a reaction to an event that basis has provided. This signals the completion of an SAP LUW using a commit or rollback.

In "typical" object-oriented systems, it is often difficult to reach all objects of a class. This problem does not occur in this form in the Payment Engine. Each business process control class, process class, entity class, and persistency class has a "s_memory_synch" class method that acts differently in each of the different classes. This global memory clean up function works as follows for the different levels:

1. There is a maximum of one instance of the business process control or process classes. The reference for this instance is defined in a class variable (singleton pattern). After the instances of the business process control have been deleted, this is the only reference to the instance. An "s_memory_synch" class method initializes this reference; the garbage collector takes care of the rest.

2. After the first two steps, there are no further references to entity objects outside of the entity layer. The "s_memory_synch" method of the entity classes deletes the global (class) reference table where the references to the technical key are stored (see section6). The entity objects can no longer be reached from outside and the garbage collector deletes them.

3. The persistency objects are singletons, just like the process objects. However, these do not have to be deleted. Since the buffering takes place exclusively in class tables (see section7), it is sufficient to initialize them using the "s_memory_synch" method in order to "reset" the classes. You can retain the instance of the process class.

8.4.1 Standard memory synchronisation behaviour

For standard business-oriented classes the following behaviour is the standard behaviour. For exceptions and how to handle them see section8.7.

The functions for main memory synchronization are implemented as follows:

There is a central class /pe1/cl_bpe_memory_synch that triggers main memory synchronization. At the end of a SAP-LUW, the basis triggers the event TRANSACTION_FINISHED of class CL_SYSTEM_TRANSACTION_STATE. Method ON_AFTER_TRANSACTION_END of class/PE1/CL_BPE_MEMORY_SYNCH receives this event and reacts to it.

First, any blocks set by the database methods are removed (using dequeue_all).

Then, an internal Payment Engine event is triggered that also has the name TRANSACTION_FINISHED.

A Payment Engine-specific event is triggered because the name and class of the basis event changed between releases 4.6C and 6.10. The additional encapsulation protects the Payment Engine from any future changes.

The classes of the Payment Engine use class methods that react to the event mentioned above. These bear the name s_memory_synch and have the following properties:

They are private class methods. They are defined as event handlers for the event TRANSACTION_FINISHED of class /PE1/CL_BPE_MEMORY_SYNCH.

They delete the buffer mechanisms of the relevant class. For singletons, the class-global instance reference is deleted. For multi-instance classes, the internal reference table is deleted. For database classes, the database buffer is also deleted.

The methods s_memory_synch must also be registered for definition as event handlers. For this, a class constructor is defined in all classes which takes carries out this registration. For example:method class_constructor.

set handler s_memory_synch.

endmethod.8.4.2 Memory synchronisation without reference deletion

Creating objects and deleting the references to them will sooner or later result in the garbage collector being activated. This is especially likely in the case of big payment orders, with hundreds of thousands of payment items.

For classes for which a lot of objects will have to be created and discarded, an alternative way of memory handling can be used. Here, the objects are created but never deleted. In order to achieve this, the reference table is never deleted; therefore the garbage collector cannot free the memory of the instances.

This recycling of object instances is relevant for the case of large files, where loops over packages of orders and / or items are necessary. The maximum number of objects is determined by the package size of the business process. After each loop iteration, the business process has to commit, forgetting all objects (from a business point-of-view).

In order to implement such a logic, the following changes to the instance management methods (s_instance, constructor, s_memory_synch) and the reference tables will have to be done:

The reference table contains a field flg_instance_in_use. This flag is TRUE if the reference to the instance is used. In this case the business key must be filled as well. If the instance is not used, the business key is to be cleared and the flag contains the value FALSE.

The constructor is empty (except for possible calls to super->constructor). The logic for the initialisation of objects has to be callable directly from the s_instance-method, because if an instance is to be recycled, the constructor cannot be called.

All initialisation logic resides in a method called constructor_logic. This protected method is part of an inheritance hierarchy similar to the one in the constructor: each constructor_logic in a subclass overrides the method from its superclass and has to call super->constructor_logic (plus whatever local initialisation is required).

In the s_instance-method, if a new instance is required (because the business key of the object was not found in s_reftab), the method differentiates between two cases:

The total number of instances in s_reftab is less than the package size from the BPC loop. In this case, a new instance is created normally via create object and inserted into s_reftab. The business key is entered normally, and the field flg_instance_in-use is set to TRUE. Note: because the initialisation logic resides in constructor_logic, this method must be called

The total number equals the package size of the BPC loop. This can only happen when a second or later package is processed. Here, the method s_instance does not create a new instance. Instead, it looks for an entry in s_reftab where the flag flg_instance_in_use is FALSE. Note that the business key of this row of s_reftab will also be empty. The method constructor_logic is called for this instance, and the business key filled as well. Then the flag flg_instance_in_use is set to TRUE.

In the s_memory_synch-method, the reference table is not deleted. Instead, a loop is performed over all the entries which does the following:

Clear the business key.

Keep the instance reference unchanged.

Set the flag flg_instance_in_use to FALSE.

Because the method s_instance will only access this line in s_reftab if it needs to create an instance which is new from the business-point-of-view, and will call constructor_logic on the instance, thereby initialising it, there is no need to clear the instance variables of the instances.

8.4.3 Memory synchronisation without buffer deletion for persistency classes

In some cases it makes sense not to delete the buffers of entity or persistency classes. An example are system tables or customizing tables which rarely change. Other examples are entity classes which are relatively expensive to create, and whose underlying data also rarely changes. However, detecting changes to the buffered data and handling locks are issues which have to be considered. This section provides some hints on how to handle this. It is relevant mainly for the persistency layer, as most of the issues raised concern database access, database locks etc.

The important thing to remember about not deleting the buffer is that all locks will have been released by the time the S_MEMORY_SYNCH method is called. If the buffer is deleted, this is no problem. However, if the buffer is to be retained and locks are needed, then the method S_MEMORY_SYNCH must ensure that the locks are reacquired. To do so, the method has to loop over the internal table of buffered entries and call the corresponding ENQUEUE function module for each entry with the lock level stored in the internal table. What happens if this fails is dependent upon the context and has to be left to the class implementer.

8.4.3.1 Tables which never change

There are tables which never change during the runtime of the Payment Engine. These are system tables which are shipped by SAP, and which are the basis upon that some of the coding is built. An example are tables which define object types (payment item type, payment order type) or system tables defining the payment item states and transitions.

In this case, it is save never to delete the buffer in the database classes. It is also not necessary to use locks. Therefore the aforementioned problems will not arise.

8.4.3.2 Tables which rarely change, and where changes are not time-critical

Some tables, e.g. customising tables, change only rarely. Under the condition that changes to such a customising table are not time-critical, i.e. that it is not a major problem if some work processes use the old version of the table entries for a few minutes, the following scheme can be used.

If the table has been read in one select and then stored in the buffer of the persistency class, an additional static, private attribute of the type timestamp will be added. If the table entries are read and stored in the buffer individually, another column timestamp will be added to the internal buffering table.

In the timestamp field(s), the point in time of the filling of the buffer or the line in the buffer with the entry is noted. If the method S_MEMORY_SYNCH is executed, it will check the timestamp(s) for entries which are older than a specified amount of time. All those values are reread; the other values are treated as described in section8.4.2 (i.e. the locks are reacquired).

8.4.3.3 Tables where changes must be effective immediately

For such tables, there are basically two approaches imaginable:

Do not buffer them at all; do reads from the database instead.

Design a cross-workprocess or even cross-application-server approach. This will be detailed later.

8.5 Access to External Components

Direct access to the process classes of external components from your own process or entity objects is not permitted. A factory class is set between the different components. This is part of the components that the other components want to use (client components). A class that wants to access a process class of the other component obtains the reference to this external process class via the factory class. There are two different cases:

1. The external component is a Payment Engine component and may therefore be accessed directly. In this case, the factory class gets a reference to the instance of the external process class by accessing the "s_instance" method of the external component and then returns this to the caller. The caller uses this reference for further access without indirection. The only additional overhead in comparison to the direct access to the external process class is the one indirection when you first access the process class.

2. The external component is an not a Payment Engine component. In this case, the internal (client) class assumes a defined behavior of the external partner (for example, the current account system). This is modeled as a method in the object model of the Payment Engine. The factory class creates a reference to a proxy whose interface corresponds to the object model. The proxy reflects the other class to the client. From the client view, this behavior is exactly as described in the point above; the difference is not visible for the client. The proxy passes the request on to the person responsible. Mapping can also be carried out here. The proxy can also be realized via XI.

The following diagram shows how the classes named are connected as an object model:

The variant where the factory class accesses the component-external process class that is in the PE system works as follows:

The case where an application is used outside of the Payment Engine is as follows:

In contrast to the other sequence diagram, you can see that from the client class view, the logic has not changed. An additional indirection is applied for the execution of the technical methods. The factory class controls whether a proxy or a process object is created.

8.6 BAPI Wrapper

You can wrap methods of the business process control level or the process layer released for access by external systems with a BAPI shell. The BAPI shell is responsible for:

Filling the standard header. The S_INSTANCE-method of the standard header is accessed and this creates a corresponding object from a transferred structure using the attributes of the standard header.

Transaction control: Create the standard header such that the BAPI shell declares itself responsible for the transaction control (by filling the corresponding field in the standard header; see section8.1).

Preparation of messages that exist in the standard header in the form of an internal table of BAPIRET2 structures. This structure can also be passed on to the caller.

Obtaining an instance of the business process control or the process class by accessing the "s_instance" class method.

Accessing the business method.

Providing customer exits (BadIs) which deal with customer extensions to import and export parameters (ExtensionIn, ExtensionOut).

SAP plans to create a standard framework and a cookbook for the BAPI wrappers.

8.7 Error Handling

Error handling in the Payment Engine is based on the error (exception) classes of ABAP objects as of Release 6.10. In addition, an exception hierarchy has been created for the Payment Engine. In the application logic, you can control how the system reacts to errors. For more details, see below.

8.7.1 Exception Hierarchy

The exceptions in the Payment Engine are based on the static exceptions that the ABAP objects provide. This means that all exceptions that can be triggered in the Payment Engine are derived from the exception CX_STATIC_CHECK.

To enable the central handling of all errors that might occur in the Payment Engine, there is a rule that all error classes in the Payment Engine are collected in one hierarchy under the central class CX_PE_ERROR. Here, additional properties of all exceptions in the Payment Engine are defined. To achieve a better structure, additional abstract classes are given under these classes that organize the errors which were actually triggered in thematic groups. The inheritance hierarchy of the Payment Engine therefore looks as follows:

Additional attributes that are inherited by all subclasses are defined in the class CX_PE_ERROR. These attributes are:

Classname: The name of the class in which the exception occurred is stored here. In CX_ROOT, a mechanism is defined that specifies the include in which the exception occurred; however, a descriptive class name is often useful.

Methodname: The name given under class name.

Errorlevel: This variable is filled with the values that are also used for the classic ABAP messages to determine the error level (E, A, W, X, I, S).

Exception: This variable can be filled if an exception was triggered after the variable SY-SUBRC was not equal to 0. This means that the exact cause of the error can be more easily determined and it allows an exact diagnosis in connection with the class name and method name.

The fields mentioned may be filled by the users if they build an exception into their coding using the Template button.

8.7.2 Reactions to Exceptions

If a method that is accessed by another method triggers an exception and sends this to the initiator, the initiator can react to the exception in five different ways. These five alternatives, which may all be correct depending on the context, are described in detail below.

To be able to understand the alternatives better, you must be aware that exceptions in ABAP objects can be linked to each other. It is possible to catch an exception, create a new one and then hang the original (caught) exception behind the second (created) one. For this, each exception has an attribute previous. If this attribute is filled with a reference to another exception (at RAISE EXCEPTION), you can create a linked list. For example, if a component in the persistency layer causes a database error and the initiating method of the entity layer catches this and hangs it after a technical exception, you would have the following situation:

This mechanism can be used to create an entire chain of cause and effect. How and when this occurs is described in the following subsections:

8.7.2.1 Catching and Ignoring an Exception

Sometimes it can be useful to catch an exception from a subordinate software layer and ignore it. This would mean that the exception had no further consequences: It would not be propagated upwards (caught there) and no further exceptions are forwarded to the initiator. For example: A database exception not found can be ignored by an entity method if this simply executes an internal check for existence in the database and if the non-existence does not represent an error from a business process point of view. In this case, not found would not be sent to the initiator after the reaction had been processed.

Graphically, this can be shown as follows:

Coding example:

TRY.

do something that might result in an exception being thrown

CATCH cx_pe_error.

do nothing here

ENDTRY.

8.7.2.2 Sending the Exception Directly to the Initiator by not Catching It

It is possible not to react to an exception at all. In this case, when an exception occurs in a method that is accessed, the accessing method is interrupted and the exception is sent directly to the previous method. For this, the exception must be declared in the method signature of the method that it is not processing but that it forwards.

This procedure is useful if a method is not capable of reacting to the error in such a way that further processing is possible, or if it is not possible to treat the error in an orderly manner. Examples of this are standard header errors that occur when the fields of the standard header are filled incorrectly in the initiator of a process method or business process control method, or all system errors that cannot be rectified by the Payment Engine. This procedure cannot be used if a reaction of any kind is needed (for example, via transaction control). The implicit assumption that, for example, a rollback is triggered at the initiator when leaving the process method may prove to be false!


WITHOUT enclosing try-catch-endtry

8.7.2.3 Processing the Exception and Sending to the Initiator

In this variant, when an error occurs, the method responds by catching the exception, reacting to it and then forwarding the caught exception. For this, the exception must also be declared in the signature of the method. When the exception is caught, you should bear in mind that you have to store the reference to the caught exception in a local variable.

Process methods are a typical application area. If a technical error occurs in the entity classes, this can often be forwarded to the initiator in the same form. However, before this, transaction control must be accessed so that the error can be reacted to once the process method has transaction authority (for example, using a rollback).

DATA: l_rcl_cx_pe_error TYPE REF TO cx_pe_error. Reference to general PE exception

TRY.


CATCH cx_pe_error INTO l_rcl_cx_pe_error.

react in some way, and raise again:

RAISE EXCEPTION l_rcl_cx_pe_error.

ENDTRY.

8.7.2.4 Replacing a Chain of Exceptions with a Single New Exception

In this case an exception is caught and replaced by a new exception. If the exception that was caught was linked to other exceptions, the whole chain is lost. This makes sense if the exact background information before the exception is sent to the initiator is not of any interest to the initiator.

Example: A process method accesses a read method of an entity class. This leads to the technical error object could not be read that is linked to the database exception not found. However, since the process method simply checks for existence and the non-availability of the object only provides a warning, the chain is replaced by a new technical exception in which the error level is set to warning.

TRY.


CATCH cx_pe_error.

do something, and raise a new exception

RAISE EXCEPTION cx_pe_my_own_exception.

ENDTRY.

8.7.2.5 Replacing the First Exception in a Chain with Another Exception

Here, a new exception is generated. The content of the field previous is copied from the old exception to the field previous of the new exception. This means that the new exception receives the entire chain that was linked to the old exception. Only the exception that occurred last is replaced.

This is useful if a technical error in a specific context is to be reinterpreted.


TRY.



do something

RAISE EXCEPTION cx_pe_my_new_front_exception

EXPORTING

previous = l_rcl_cx_pe_error->previous.

ENDTRY.

8.7.2.6 Adding a New Exception to the Head of an Exception Chain

This is the usual case for error handling. An exception is caught, a new exception is generated in the method that caught it and the previous exception, including all connected exceptions, is linked to this new exception. The new exception is simply added before the exceptions that already exist and it describes the situation from the view of the methods that caught the original exception (chain).

Example: An exception from the database layer not found is caught in the entity layer and interpreted technically. For this, a new exception payment item does not exist is generated. The reference to the original not found exception is written in the previous field of the technical exception that has just been generated.


TRY.



do something

RAISE EXCEPTION cx_pe_new_front_exception

EXPORTING

previous = l_rcl_cx_pe_error.

ENDTRY.

9 Standard Frameworks and Cookbooks

(Comment: This section may be stored in a Payment Engine-specific enhancement of the programming guidelines)

9.1 Business Process Control Classes

9.1.1 Standard Frameworks

To be created.

9.1.2 Cookbook

To be created.

9.2 Process Classes


To be created.

9.2.2 Cookbook

To be created.

9.3 Entity Classes


To be created.

9.3.2 Cookbook

To be created.

9.4 Persistency Classes


To be created.

9.4.2 Cookbook

To be created.

10 Appendix

In this appendix you can find additional sections that are not necessary for a general understanding of the Payment Engine, but that provide interesting insights into the background information.

10.1 Target System of the Payment Engine Architecture

The architecture of an IT system is always molded by business and technical requirements. Even if this is not explicitly clear, such requirements are always implicitly present. In this section, the requirements for the Payment Engine are explicitly presented so that later sections can look in detail at how these requirements can be implemented.

The aims of a software system can be subdivided into those aims that are a result of the application that is to be created and those aims that result from the software lifecycle, which also determines a series of restrictions.

10.1.1 Aims that Can Be Derived from the Application

These aims are:

Performance: The Payment Engine must be able to process large quantities of data quickly. In addition to data processing, realtime access (internet scenario, cash machine, ) with acceptable response times must also be possible.Solution: Buffering at different levels, retrieval of process variants for single and mass processing of payment orders (this point is, however, part of the technical design).

Enhancement possibilities: Payment transaction systems are solutions that have to be able to be integrated in different IT landscapes at the customer. For this reason, it is important to plan mechanisms for customer enhancements.Solution: BADIs in all process methods, proxies for access to external systems, loose coupling of individual components.

Scalability and distribution: Due to the close integration of a payment transaction system in the IT landscape, it is possible to imagine scenarios in which some of the functions of a Payment Engine are distributed over different platforms, and it may be possible that parallel instances have to coexist.Solution: Loose, flexible coupling of components in a customized business process control layer that can be adjusted to the respective customer requirements; coupling of individual components using proxies and factories which allow the distribution of different technical functions on different platforms.

Exchangeability of partial systems: Many customers already have payment transaction systems and may be planning to continue using their functions for specific payment transactions (for example, payment method definition, clearing, ). This implies that the Payment Engine needs to consist of several loosely connected modules..Solution: Loose component coupling.

10.1.2 Aims that Can Be Derived from the Software Creation Process

As well as the aims purely related to the application, the software creation process at SAP (SDLC documents and supports in Horizon) makes additional demands on a system architecture:

Clear structuring of the application. This aim arises from the need to be able to integrate new developers into the project quickly as it makes it easier for them to concentrate on the actual technical aspects of their work. Clear structuring also supports the transfer of the project results to the IBD and the subsequent maintenance of the application by the IBD.Solution: Architecture without Layer Bridging, standard frameworks for method structure, clean design (not a topic for this concept).

Standardized, strict procedures for cross-application topics. Amongst others, these topics include transaction handling, the message concept and lock management. Decisions for these topics must be made as early as possible during the project and in such a way that the consequences of subsequent changes are minimized.Solution: The use of standardized guidelines and standard headers for all levels of the software architecture.

The possibility of making structural changes later at a justifiable cost. This aim is a result of the prototype nature of development for the Payment Engine project. The purpose of the prototype is not only to analyze the technical properties of the system and then be discontinued. Instead, it is to form the basis of the first productive release. As a result, the architecture should be defined from the very beginning so that new technical requirements can also be taken into account at a later date. An example of this would be a requirement later in development that the user ID of the end user should be sent to all methods of the Payment Engine if this is to be used via BAPIs.Solution: Standard headers as containers for technical attributes that can be subsequently changed.

Compatibility with IBS and SAP architectures. This is necessary to be able to use the Payment Engine together with other SAP applications such at the Interface Repository, Workflow, BCA or the Financial Server.Solution: Basing the layers on the general software layers of IBS FS, the use of central tools wherever possible.

Simple handover to IBD. The handover of the project results from NAD to IBD is a crucial part of the project and a prerequisite for its successful completion. In addition, effective support from the IBD is a critical success factor for the product in the marketplace.Solution: Standard structure of all methods (no surprises), precise documentation of all exceptions (if they exist), standard frameworks, documentation of the design in the form of an object model (not part of this concept).

Integration of new employees. Due to the resource situation (within SAP and in the marketplace), it is necessary to integrate new and (sometimes) external employees as quickly as possible. For this, the new employees need to be able to concentrate on the technical logic; That is, the actual complexity of the architecture with respect to technical topics should not concern them. Solution: Standard frameworks and cookbooks, encapsulation of central technical topics.

10.2 Basic Understanding of the Architecture

Behind every architecture, there is an implicit or explicit understanding of that which is depicted and in what way it is depicted. In the procedure model Extreme Programming, there is even talk of a metaphor. In this section, you can see the understanding of business applications in a technical context that forms the basis for the architecture of the Payment Engine. This makes it easier to categorize and comprehend the details of the different elements and layers of the architecture.

10.2.1 Business Concept

An enterprise can be understood as a system that carries out processes related to a certain aim, and therefore interacts with flows of money, goods and information in a business environment. A business application is a representation in the form of an IT system of those aspects of this process (and the money, goods and information it deals with) that are relevant to the management of the enterprise.

The IT system must reflect the business reality as closely as possible. Therefore, it makes sense to structure the IT system in a similar way to the reality that is being depicted.

This results in the following requirements of the IT architecture:

Business objects: Abstract or concrete concepts in the real world that can be created, changed and dismantled during business activity output. They are created, used and dismantled exclusively within activities.

Activities: Fundamental, nuclear operations for business objects. An activity either alters all of the business objects associated with it (success) or none (error).

Business processes: Chains of activities that are connected via events and that can branch to parallel or alternative paths.

These elements can be found in all business process modeling techniques, such as ARIS for example.

The following table maps these elements to the components of the architecture:

Business ConceptArchitectural Element

Business objectObject of an entity class

ActivityMethod of a process class

Business processMethod of a class of the independent component

This architecture is based on the assumption that business objects are only accessed for the purpose of carrying out business processes. The activities correspond to the ARIS activities at the highest level of detail (granularity). The chains of activities that are represented by the methods of the independent component would all be subprocesses (process paths) of ARIS.

11 Literature

[Gamma+95]Gamma et al: Design Patterns. Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading / Massachusetts, 1995.

[Buschmann+96]Buschmann et al: Pattern-Oriented Software Architecture. A System of Patterns. Wiley, Chichester, 1996.

[Hofmeister+99]Hofmeister et al: Applied Software Architecture. Addison-Wesley, Reading / Massachusetts, 1999.

[Bass+98]

Bass et al: Software Architecture in Practice. Addison-Wesley, Reading / Massachusetts, 1998.

[Brown00]

Brown, Alan W.: Large-Scale, Component-Based Development. Prentice Hall, Upper Saddle River, 2000.

[HerzumSims00]Herzum, Peter & Sims, Oliver: Business Component Factory. Wiley, New York, 2000.

[Szyperski97]Szyperski, Clemens: Component Software. Beyond Object-Oriented Programming. Addison-Wesley, Reading / Massachusetts, 1997.

EMBED Word.Picture.8

"Abstract here does not mean "abstract in the sense of a class from which no instances may be created", but "not exactly corresponding to runtime elements".

Independently of this, the rollback segment of most databases would overflow with such large quantities of data; for this reason alone packaging is necessary.

Naturally, they trigger the writing of attributes of entity classes to the database by accessing the corresponding entity class methods.

Strictly speaking, the constructor is a class method, but to explain it more clearly here, the arrow points to the instance.

All process methods except for the "s_instance" class methods and private "help methods" used for better source code structures.

See also section REF _Ref47339917 \r \h 8.4.3 for an alternative to reference table deletion.

For singletons with no status, you can consider whether the instance reference should be deleted or kept.

This does not have to be a class in the sense of object orientation, it can also be a wrapper of function modules.

Otherwise, you get a warning. Non-declaration makes it significantly more difficult for a user to work with a method. For this reason you should not ignore the warning.

N:\jwegener\work\Payment_Engine\Architektur_Payment_Engine\Architektur_Payment_Engine_Eng.doc Page 12

_1074685605.pptSAP AG 2001, Title of Presentation, Speaker Name *

Access to external components I:Other Payment Engine components

Client object

Factory

getReference

P-object inexternalcomponent

s_instance

doSomething


Access to external components II:Non-Payment Engine components

Client object

Factory

getReference

Proxy for access to external system

s_instance

doSomething

External system

doSomething


Representation of a component

Component

ProcessClasses

EntityClasses

PersistencyClasses

Database

ProcessObject

ProcessObject

ProcessObject

EntityObject

EntityObject

EntityObject

EntityObject

EntityObject

PersistencyObject

PersistencyObject

PersistencyObject

External access

_1072789127.doc

: Client

:

SingletonClass

theInstance :

SingletonClass

s_instance( )

[no instance available] constructor

[no instance available] storeRef

returnInstanceRef

method1( )

method2( )

05 architektur payment engine eng

Documents