156 concept bankingservices_deposits and loans

© 2010 SAP AG

Best-Practice Document

Operations Concept for SAP Banking Services

(Deposits and Loans)

Dietmar-Hopp-Allee 16 D-69190 Walldorf

DATE

November 2010

SOLUTION MANAGEMENT PHASE SAP SOLUTION

Operations & Continuous Improvement SAP for Banking

TOPIC AREA SOLUTION MANAGER AREA

Business Process Operations

Best Practice Operations Concept for SAP Banking Services (Deposits and Loans)

© 2010 SAP AG page 2/74

Date Alteration Reason Version

19.07.2010 Creation 0.1

Table of Contents

1 Management Summary 4

1.1 Goal of Using this Service 4

1.2 Staff and Skills Requirements 4

1.3 General Aspects of Banking Operations 7

2 Error and Exception Handling 8

2.1 Usage of Postprocessing Office (PPO) 8

2.1.1 Purpose 8

2.2 Prerequisites 9

2.2.1 Activation of PPO 9

2.2.2 Activation of ECH 9

2.2.3 Usage of Worklists 10

2.2.4 Usage of Priorities for Business Processes 10

2.3 PPO Order Processing 11

2.3.1 Manual Processing via the PPO Desktop 11

2.3.2 Automatic Processing 17

2.4 PPO Setup Checklist 18

3 Parallel Processing Framework 19

3.1 Purpose 19

3.2 Prerequisites 19

3.2.1 Number of Background Jobs 19

3.2.2 Repeat of Mass Runs 19

3.3 Deletion of Mass Run Data 20

3.4 Aborted Mass Runs 21

4 Clearing Payment Items 22

4.1 Purpose 22


4.3 Clearing Process 23

5 Post Processing of Payment Items via Posting Control Office 25

5.1 Usage of Posting Control Office (PCO) 25

5.1.1 Purpose 25

5.1.2 Post Processing Possibilities 25

5.1.3 Usage of Worklists 26

5.2 PCO Order Processing 27

5.2.1 Manual Processing via the Posting Control Office 27

5.2.2 Automatic Processing 30

5.3 PCO Setup Checklist 31

6 Correspondence Monitoring and Archiving 33

6.1 Purpose 33


© 2010 SAP AG page 3/74

6.2 Prerequisites for Archiving and Deletion 33

6.3 Monitoring 33

6.4 Archiving and Deletion 35

7 Automatic Postprocessing of Payment Distribution Items 36

7.1 Purpose 36


7.3 Reprocessing 36

8 Monitoring of the Banking Services System 38

8.1.1 Performance-Oriented Monitoring and Analysis 38

8.1.1.1 MassMan Monitoring Analysis Tool 38

8.1.1.2 Workload Monitor – ST03 41

8.1.1.3 Single Record Statistics – STAD 42

8.1.1.4 Trace Analysis – ST05/ SE30/ST12 43

8.1.1.5 Database Monitor – ST04 45

8.1.1.6 Operating System Monitor – ST06/ OS07 47

8.1.1.7 Workprocess Overview – SM50/ SM66 48

8.1.1.8 SAP Code Inspector – SCI 50

8.1.2 Technical-Oriented Monitoring and Memory Analysis 52

8.1.2.1 SAP Memory Configuration Monitor - ST02 52

8.1.2.2 ABAP Dump Analysis - ST22 53

8.1.2.3 System Log - SM21 54

8.1.2.4 Computing Center Management System – CCMS/ RZ20 55

8.1.2.5 Analyze Memory Consumption - S_MEMORY_INSPECTOR 56

8.1.2.6 Transactional RFC – SM58 57

8.1.2.7 Message Monitoring- Integration Engine – SXMB_MONI 58

8.1.2.8 Snapshot Monitoring /SDF/MON 58

8.1.3 Application-Oriented Monitoring 61

8.1.3.1 Parallel Processing Monitor - RBANK_PP_MONITOR 61

8.1.3.2 Job Overview – SM37 62

8.1.3.3 Display Application Log – SLG1 64

9 Housekeeping of the SAP Banking Services System 68

9.1.1 Cross-Application Housekeeping 68

9.1.2 Banking Services System Housekeeping 68

9.1.2.1 Deletion Report for RBANK_PP_MONITOR Process Data 68

9.1.2.2 Deletion Report for "Account Settlement" Simulation Data 69

9.1.2.3 Adapt Product Pricing List to Related Contracts Report 69

9.1.2.4 Check Financial Conditions Customizing 69

9.1.2.5 Delete Reports in Account Management via Delete Objects 69

10 Background Information and References 71

10.1 Overview of the Most Important Best Practice Documents 71

10.2 Overview of the Most Important Transactions 71

10.3 Overview of the Most Important Regular Jobs 72


© 2010 SAP AG page 4/74

1 Management Summary

With implementing and operating an SAP Banking Services solution, there is the need to cover two major

challenges. The first challenge is to provide a suitable environment for the daily business, mostly driven by

payments initiated by ATMs, automatically generated periodic items, or different online calls to the system (for

example, display account balance). The main focus of the daily business is dialog processing. The end-to-

end performance of the processes is crucial in daily processing.

The second challenge is nighttime, or end-of-day, processing. End-of-day processing groups together a

number of steps and reports and executes them in a single process chain (mostly in batch mode) without any

manual interaction. The daily end-of-day processing within a bank is a critical process because the data that

is posted or stored during the day is processed and settled, and any kind of error could lead to delays. If the

end-of-day processing runs longer than the given time window, the daily business is affected by system load

and certain data is not available on time. During end-of-day processing, high volumes have to be processed

in the given time window; therefore, data throughput is crucial.

We created this operations concept to provide SAP Banking Services customers focusing on deposits and

loans with best practices for operating their SAP system. We do not cover organizational areas in terms of

organization structure, but we do address necessary standard roles that should be defined for smooth

operation of the Banking system. Other focus areas are operation topics like system monitoring,

housekeeping, and error and exception handling.

In some chapters, you will only find a high-level description or a short introduction to the topic, either because

there are already best-practice documents available, or to keep this document lean and provide a point of

entry for customers who are starting with an SAP system for the first time or want to have a check against

their current banking operations concept.

This best-practice document completes the best practices for end-of-day processing and operations

(available on SAP Service Marketplace Best Practices).

1.1 Goal of Using this Service

This best-practice document is based on workshops and experiences from the productive operation of

different SAP Banking Services customers. It provides best-practice guidance to Banking customers about

how to operate an SAP Banking Services system and the main daily operations tasks that have to be

executed when using Loans on platform and / or Deposit Management on SAP Banking Services.

1.2 Staff and Skills Requirements

In the document “Best Practices for End-of-Day Processing SAP Deposits Management” in the “Staff and

Skills Requirements” section, you will find an introduction to the needed skill requirements to fulfill the

necessary tasks and responsibilities.


© 2010 SAP AG page 5/74

The following table describes the roles and their major responsibilities during setup and operation of the

production system. It also includes the role that will act as an expert contact person in case of an error during

the operation phase.

Section/ Roles Tasks/Responsibilities

Job Control/Job Scheduler

Person responsible for the job control tool of the bank

- Compare acquired and provided functionalities and find gaps in the tool

- Get details for job scheduling from banking business process owner

- Implement, test, and operate the job scheduling tool

- Communicate with the provider of the job scheduling tool

- Hand over tasks of job control to first-level support

Business Process Monitoring

Person responsible for the Business Process Monitoring tool of the bank

- Compare acquired and provided functionalities and find gaps in the tool

- Get detail from banking business process owner and job scheduler for operation

- Implement, test, and operate the Business Process Monitoring tool

- Communicate with the provider of the Business Process Monitoring (BPMon) tool

- Hand over tasks of BPMon to first-level support

- (Optional) Monitor banking business process together with first-level support

SAP Basis / Administration

Person(s) responsible for the infrastructure, data base and SAP-Basis

- Define the available number of technical batch work processes

- Define the degree of parallelization per report / program

- Analyze and resolve performance issues

- Define and implement the technique for file transfers

- Ensure high availability of the system

- Provide technical monitoring and special matter expert in case of technical issues

First Level Support /CCoE (Service Desk and Command Center)

Person / group from the support team of the bank who will be responsible for the support of the productive system

- Define, for every report / program, what to do in case of an error

- Identify criticality of an issue (resolve the error immediately or during the next day)

- Set up and run service desk (initial contact in case of production errors)

- Provide monitoring and job control during operation

- Perform root cause analysis

SAP standard program

- Define variants and variables


© 2010 SAP AG page 6/74

Section/ Roles Tasks/Responsibilities

contact

Functional responsibility SAP-program X (SAP-standard)

- Define dependencies between jobs, also cross-system (process owner)

- Define test cases

- Test resolved errors (retest)

- Support operations and perform error solving in case of system incidents

Customer specific program contact

Functional responsibility SAP-program Y/Z (customer-specific development)



- Define test cases

- Test resolved errors (retest)

- Support operations and perform error solving in case of system incidents

SAP Developer

Developer SAP-program Y/Z (customer-owned development)



- Define test cases

- Resolve errors

Banking Process Owner (EoD and components) Person who is familiar with the process of the existing core banking system(s)

- Be responsible for the technical core business process flow

- Decide which programs of the SAP standard are relevant (focus on EoD [end-of-day processing])

- Evaluate dependencies between relevant programs/jobs

- Evaluate sequence of the programs / jobs

- Evaluate the functional and / or technical reason for an existing program

Duty Manager or Service Manager

- Coordinate roles and tasks during setup and system operation

- Implement and maintain all IT Service Management processes

- Be responsible for the efficient delivery of IT services according to SLAs

There are different activities during the EoD process. Some of the activities take place immediately, some of

them take place proactively, and some of them take place only if there is an error.

Some errors that occur during the EoD processing need to be solved immediately, but many errors can be

solved the next day, or even later. A clear, defined operations handbook with detailed dependencies between

all relevant process steps and detailed expectation handling for known error cases is mandatory.


© 2010 SAP AG page 7/74

SAP standard transactions (for example, SM37, SM66) and SAP Banking-related monitoring tools like

RBANK_PP_MONITOR and Business Process Monitoring for Banking help you to get the process status

right in time to quickly react to errors.

Also see RunSAP Document: End of day/Batch Processing Deposit Management https://websmp207.sap-ag.de/~sapidb/011000358700000671032009E

1.3 General Aspects of Banking Operations

As already described in the Management Summary, operations of an SAP Banking Services system can be

divided into daily and nightly processing. While daily processing is driven by online processing and E2E

performance, nightly processing is characterized by high system load via batch processing by automated

process chains, posting cut-off, and processing of high data volume in a given time window.

The operations for daily and nightly processing are different, but it is important in both cases to guarantee

high system availability, system and core process performance, and fast resolution of errors or to avoid or

reduce the error situation proactively, for example, by performing system and business process monitoring.

To support the operations team in handling these challenges we created this best-practice document. It

introduces you to the different standard functionalities and SAP tools to perform error and exception handling,

system and business process monitoring, and basic administration topics.

https://websmp207.sap-ag.de/~sapidb/011000358700000671032009E


© 2010 SAP AG page 8/74

2 Error and Exception Handling

2.1 Usage of Postprocessing Office (PPO)

2.1.1 Purpose

The Post Processing Office (PPO) supports the processing of errors that originate in any business process.

All the data relevant for processing errors is combined in a postprocessing order. You can therefore process

error messages from mass runs of different object types, for example.

The Postprocessing Office replaces the application logs of the mass runs as the initial function for error

processing. You only need to call up the error logs to display an overview of the objects that were processed

successfully in the mass runs.

The Postprocessing Office has the following advantages:

Overview of all the information required to process the events in any business processes.

Possibility to navigate to relevant objects

Extensive selection options

Distribution of postprocessing orders to worklists for processing

Reference to events of same object in other business processes

Reference between objects from different application logs

Authorization checks

Status management

Processing history

There are two kinds of PPO orders: “classic” orders and orders created by the Error and Conflict Handler

(ECH). Classic PPO orders contain only information about the failed object (such as the account), additional

objects (such as business partners), and the error messages that occurred during processing. Once the error

is solved, the relevant report can be restarted to reprocess the object and the user can set the PPO order to

completed. This type of PPO order is created, for example, by the account settlement and account statement

mass runs.

The ECH PPO orders are normally used by services. ECH PPO orders contain all data that is necessary to

perform a business process step, for example, to post an item triggered by a service. It is therefore possible

to repeat the erroneous step either manually from the PPO Desktop or automatically via a report once the

error has been solved.

Many mass runs are executed during end-of-day processing, and these can potentially create PPO orders.

Therefore, you should perform monitoring and processing of PPO orders on a daily basis to ensure that all


© 2010 SAP AG page 9/74

business processes have a consistent state from a business process point of view. Your aim is to solve the

causing errors and to complete the PPO orders on the same day. But other mass runs that run during the day

may also create PPO orders, so you should also monitor PPO during the day.

PPO orders may be created, for example, by:

Missing or incorrect customizing, for example, missing exchange rates or incorrect product settings

Locks, for example, dialog locks, account balance locks, or posting locks

Business rule violations

Authorization issues

2.2 Prerequisites

2.2.1 Activation of PPO

By default, creation of “classic” PPO orders is deactivated. You have to activate the creation in Customizing

by choosing Cross-Application Components General Application Functions Postprocessing Office

Postprocessing Office Business Processes Activate Creation of Postprocessing Orders.

It is recommended that you activate PPO for at least the following components:

FS-AM

FS-MCM

PRI (Pricing -- Use transaction /n/SAPPO/PPO2 to work on Pricing PPO orders;

there is no specific transaction for Pricing.)

To activate PPO for all business process of a component, leave the business process blank. At a minimum,

the following entries should exist in the table:

Component Business Process Act.

FS-AM X

FS-MCM X

PRI X

2.2.2 Activation of ECH

ECH does not need to be activated, because ECH orders are created by default.


© 2010 SAP AG page 10/74

In Customizing, you can define a resolution strategy for the ECH PPO orders per component and business

process. If nothing is defined in Customizing, the general default resolution strategy is applied. The default

resolution strategy is:

Create PPO orders

Allow automatic and manual retry

Allow manual finish and fail

Use no residence time and no resubmission group

Use the following IMG activity to define your own resolution strategy if the default does not fit in your case:

Cross-Application Components General Application Functions Error and Conflict Handler Define

Resolution Strategy.

2.2.3 Usage of Worklists

You should also consider if it makes sense to use worklists for PPO orders. With worklists, you are able to

assign responsibilities for specific business processes to specific users or organizations. For example, if

specific users should take care of item-specific errors, you can assign these users to an item worklist. Other

users may take care of settlement-specific errors. You can assign these users to a settlement worklist.

To define worklists in Customizing, choose Financial Services Account Management or Master Contract

Management Postprocessing Office Worklist.

Once a worklist has been created, you can assign a PPO business processes to it. Afterward, you can assign

users or organizations to the worklist. You must perform the assignment of users or organizations to a

worklist via the SAP Easy Access menu: Financial Services Account Management / Master Contract

Management Postprocessing Office Worklist Change Assignment.

When a user starts a PPO transaction, for example, BCA_PPO2 with “Order Assignment” = 1, the user sees

PPO orders that are assigned to his or her worklists and the orders that have no worklist.

2.2.4 Usage of Priorities for Business Processes

You can assign a priority to a business process. The priority can be used as selection criterion on the

selection screen of the PPO transactions. It can also be used as a filter criterion within the PPO Desktop. For

example, you can assign priority “high” to settlement-related PPO orders and priority “low” to settlement–

simulation-related PPO orders.


© 2010 SAP AG page 11/74

The Customizing path to assign the priority to a business process is: Cross-Application Components

General Application Functions Postprocessing Office Postprocessing Office Business Processes

Assign Priority to Business Processes.

2.3 PPO Order Processing

2.3.1 Manual Processing via the PPO Desktop

Within banking services from SAP, the following transactions are available to edit or display PPO orders:

PPO orders for application component Account Management (FS-AM)

BCA_PPO2 - Edit Postprocessing Order

BCA_PPO3 - Display Postprocessing Order

PPO orders for application component Master Contract Management (FS-MCM)

MCM_PPO2 - Edit Postprocessing Order

MCM_PPO3 - Display Postprocessing Order

PPO orders for Posting Lock Management

PLM_PPO2 - Edit Postprocessing Order

PLM_PPO3 - Display Postprocessing Order

General PPO transactions (application-component-independent)

/n/SAPPO/PPO2 - Edit Postprocessing Order

/n/SAPPO/PPO3 - Display Postprocessing Order


© 2010 SAP AG page 12/74

PPO Entry Screen of Transaction BCA_PPO2

If you call, for example, transaction BCA_PPO2, the selected PPO orders are displayed after you execute the

report.


© 2010 SAP AG page 13/74

PPO Desktop – Overview List

In the overview list you will find information about the main object, the business process, the main error

message, the status, and so on. You can use the Select layout icon to modify the appearance of the

list, for example, to display the priority and the worklist.

The status traffic light shows the processing state of an order.

= Order not processed

= Order in process

= Order processing completed

If you right-click on an order in the overview list, a context menu appears. The context menu allows you to:

Change status of the order

Change processor

Change worklist

Display details

Repeat, discard, or confirm (only available for ECH PPO orders)

You can also select multiple orders by using the Ctrl or Shift keys. You can then perform an action for

multiple orders, for example, repeat or complete from the context menu.

If you select Display Details from the context menu or if you double-click on an order, the detail screen

appears.


© 2010 SAP AG page 14/74

The detail screen is split into the following areas:

Header area

Shows important information like the main object, the main error message, and the status of the order

Order area

Contains detailed information about the order

Object area

Provides data about the erroneous object, for example, the account or master contract

Log area

Contains the messages that were written to the log by the originating process, as well as the

messages that occurred during reprocessing; the messages should help you to analyze the causing

error


© 2010 SAP AG page 15/74

PPO Details Screen of an ECH PPO Order in Edit Mode

The Details screen provides the following processing options:

Change Worklist Assignment (via the menu)

Change Processor Assignment (via the menu)

Complete Order (only available for classic PPO orders)

You can set the status to Completed by pressing the button.

Note: Only press this button if the causing error has been solved!

Process Order (only available for ECH PPO orders)


© 2010 SAP AG page 16/74

When you press the button, the order is assigned to your user and the status is changed to In

process. In addition the following buttons appear:

Use this button to repeat the process step. As a prerequisite, the actual error must be

solved. If the repetition of the process step is successful, the order is set to status Completed and the

log is updated accordingly.

If you press this button, the status of the order is changed to Completed. In most

cases no further actions are performed, for example, sending of a message to the initiating process.

An order should only be confirmed if the causing error is solved or if the process step has been

executed manually, for example, by posting an item in dialog. Otherwise, the confirmation can lead to

inconsistencies in the business process!

Example:

Assume you started a process that posts items in the account managing system via service or RFC

call. Because of missing customizing, the item is not posted and a PPO order is created. The

initiating process is already successfully finished at this stage. If you press Confirm without solving

the causing problem and without repeating, nothing is posted. The initiating process relies on the

correct processing.

If you press this button, the status of the order is changed to Completed. In most cases,

no further actions are performed, for example, sending a message to the initiating process, so an

order should only be discarded if the object is processed in another way or if the error cannot be

solved at all. In the latter case, you should identify the initiating process and perform the necessary

steps to achieve a consistent state. If you discard a PPO order, this could also lead to inconsistencies

in the business process!

According to the resolution strategy setup in Customizing, buttons may not appear. See Customizing: Cross-

Application Components General Application Functions Error and Conflict Handler Define Resolution

Strategy.

For the error analysis use the messages in the log area, consider the long texts of the messages for further

details. If the order was created out of a mass run, you can display the mass run log (same as transaction

SLG1 to display a log) out of the PPO order by pressing the first log icon in the log area. The

corresponding mass run is for interest, because if you analyzed and resolved the causing error, the mass run

should be restarted to reprocess the faulty objects. Before you restart, you should complete the orders,

because if the mass run is repeated and the causing error is not solved, a new PPO order is created.

If the PPO order is created by ECH, use the repeat functionality of the PPO to reprocess the object.


© 2010 SAP AG page 17/74

2.3.2 Automatic Processing

Automatic processing or reprocessing of PPO orders helps you to minimize human intervention. Automatic

processing is possible in the following ways:

Reprocessing of orders (report /SAPPO/RESUBMIT_ORDERS_2)

o Orders that were created because of a lock can be reprocessed.

o Orders for which the causing error has been resolved can be reprocessed.

o It is recommended that you schedule the reprocessing report /SAPPO/RESUBMIT_ORDERS_2

periodically (also multiple times a day) depending on the resubmission group.

Selection Screen of Resubmission Report

Closing of orders (report /SAPPO/CLOSE_ORDERS_2)

o It is possible to automatically close orders, but this should be handled with care. Once an

order is closed, it can no longer be edited.

o Orders are closed independently, whether or not the causing error has been solved.

o The report should not be scheduled as a periodic job.

Deletion of orders (report /SAPPO/DELETE_ORDERS)


© 2010 SAP AG page 18/74

o Once an order is closed (status Completed), it can be deleted from the system. Deletion of

orders should also be handled with care, because once you have deleted an order you no

longer have a history.

o The report should not be scheduled as a periodic job.

2.4 PPO Setup Checklist

The following list describes how to work with PPO for existing processes where PPO is already integrated.

On top of that, PPO can be integrated into a customer’s own processes, but this takes a few more activities.

Activate PPO creation for AM or MCM business process (SPRO Account Management / Master

Contract Management Postprocessing Office Business Processes Activate Creation of

Postprocessing Orders).

Configure PPO-specific settings (SPRO Account Management / Master Contract Management

Postprocessing Office).

If desired, use organizational data and create worklists for special business processes and users or

user groups.

Start working with the component-specific (BCA_PPO2, BCA_PPO3, MCM_PPO2, MCM_PPO3) or

generic (/SAPPO/PPO2, /SAPPO/PPO2) PPO transactions.


© 2010 SAP AG page 19/74

3 Parallel Processing Framework

3.1 Purpose

The Parallel Processing Framework (PPF) supports the parallel execution of application-specific processes.

The tool enables parallel execution (usage of several application servers) of runtime-intensive mass

processing. The application allocates the data to be processed to packages that are transferred to the tool.

The tool administers these packages and controls their processing in parallel background jobs. Basis job

scheduling controls the execution of these jobs.

You can schedule mass runs with an external job scheduling tool, like Central Process Scheduling by

Redwood for SAP NetWeaver.

All of the mass runs provided by Banking Services from SAP Deposits and Loans Management use the PPF.

It is also possible to use the PPF for customer-specific mass runs.

3.2 Prerequisites

3.2.1 Number of Background Jobs

By default, a mass run uses only one background job for processing. The number of background jobs has to

be increased by you so that it suits your requirements. The number of background jobs depends on your

system settings (especially on the number of batch processes among all your application servers) and on

other issues, for example, how many objects should be processed by a mass run. You should also consider

the reports that run in parallel, because if you reserve too many batch jobs for one report, the other reports

running in parallel can use fewer resources and may take longer.

You can set up the number of jobs to be used in Customizing by choosing Financial Services Account

Management / Master Contract Management Tools Parallel Processing Maintain Job Distribution.

3.2.2 Repeat of Mass Runs

To avoid errors resulting from lock situations you can define the number of parallel and sequential repeats per

application type in the Parallel Processing Framework configuration (Customizing: Financial Services

Account Management / Master Contract Management Tools Parallel Processing Maintain Customer

Settings for Application Types).


© 2010 SAP AG page 20/74

Setup of Direct and Sequential Repeats

The application itself makes the decision about repeat behavior. The object can be repeated only if the

application sets a certain status for an object within parallel processing.

Parallel repeat means that packages that include objects with a certain status are repeated in parallel (with

the same number of jobs defined for the run) after all packages have been processed once. If a sequential

repeat is defined, all packages that include objects with a certain status are repeated in one single

background job after the parallel repeat(s). Two to three parallel repeats and one sequential repeat may be

sufficient.

3.3 Deletion of Mass Run Data

If a mass runs ends without errors, all mass-run-related data is deleted from the system automatically. This is

to avoid waste in the system. If a mass run ends with errors, the mass-run-related data is stored in the

system as long as the mass run is repeated successfully or the administrative data is deleted. You should

check the state of the mass runs regularly with transaction BANK_PP_MONITOR. You can use report

RBANK_DELETE_RUNS to delete the administrative data, as well as locks, object worklists, and package

data for old runs.

Runs should not be deleted until it is clear why certain errors occurred. It is recommended that you check

what kind of error happened, for example, processing errors resulting in PPO orders or a program

termination. In principle, it is not that critical if run data is deleted, because the mass run can be re-started

with the same parameters. The only critical thing is that if a report sets locks on which other mass runs rely

on, these locks are deleted and therefore a succeeding mass run could process the object. It is

recommended that you analyze the causing error first. If the root cause of the error is corrected, restart the

mass run, using the same external run ID (if this option is provided by the mass run).


© 2010 SAP AG page 21/74

External Run ID of a Mass Run

You can select the erroneous mass run from a list by using the F4 value help for the External Run ID field. If

no external run ID is provided by the mass run, simply restart the run.

3.4 Aborted Mass Runs

If a mass run ends with an application return code 8 = terminated, then you must check why the mass run

has been aborted. It could be that a short dump occurred during the processing of an object. In this case, the

related background job is also terminated. For the whole mass run, this means that the available background

jobs have to process the rest of the packages. The mass run ends with technical job status finished although

there was a short dump. The application return code is 8 = terminated. Furthermore, if all other objects are

processed successfully, the counters in the log tell you that x due objects have been selected and x objects

have been processed successfully. Depending on the termination point, the objects of the aborted package

have not been counted and therefore are not reflected in the counters. In any case, you should analyze the

cause of the error and restart the mass run when the causing error is solved.


© 2010 SAP AG page 22/74

4 Clearing Payment Items

4.1 Purpose

SAP Deposits and Loans Management have accounts for posting processing, which you can use for a

temporary posting transfer (such as working accounts). This means that there is a business requirement that

each item or item group posted on a working account has one or more offsetting items that clear these items

or item groups. You can clear items on the same day or at a later date.

To find out which items have not been cleared, clearing items reference each other (cleared). Items that have

not been referenced are thus not part of a cleared business transaction.

Examples of this type of clearing account:

Outstanding receivable accounts

Collective accounts

Holding accounts

Clearing accounts for payment transactions

Disbursement accounts for account closure

Process interim accounts (used by Combined Settlement for postings)

You can close open items on these accounts by using the clearing functionality. Monitoring of the clearing

accounts is necessary to check if open items exists, because the nature of the postings on these clearing

accounts is only temporary. The aim is to clear all items on these accounts.

4.2 Prerequisites

You have created the products required for the clearing accounts in the customizing under Financial Services

Account Management Product Management Product Definition Account Products Create

Account Products. In the Clearing feature, you have defined the transaction types for taking differences off

the books for manual clearing, and for automatic removal from the books with clearing. Furthermore, you

have defined the period for the automatic removal from the books and/or the Can Be Cleared Externally

attribute, and the Period for External Clearing in Days.


© 2010 SAP AG page 23/74

Account Product Setup for Clearing

4.3 Clearing Process

You should schedule the mass run RBCA_CLEARING_EXT_RUN_PP so that it runs daily in the end-of-day

processing. The report finds all the items that have an external clearing reference and clears them from the

system if the total of the generated reference group is zero.

With report RBCA_PAYMITEM_CLEARING_LIST (transaction BCA_CLEARING_LIST), you should check,

on a daily basis, if there are open items. If this is the case, you should analyze the reason why they are still

open.

In the SAP Easy Access screen, choose Account Management Account Turnovers, Balances and Key

Figures Payment Item Display Open Items for Clearing Account.

Display of Open Items with Transaction BCA_CLEARING_LIST


© 2010 SAP AG page 24/74

Alternatively you can use transaction BCA_PAYMITEM_MAINTN to find which items are cleared and which

are not.

Clearing Status in Transaction Display Payment Item (BCA_PAYMITEM_MAINTN)

Note: Not all relevant fields may be displayed by default. Use the field catalog to select the fields you want to

display, for example, the Ext. Clearing Ref. or Clearing Ref. Exists fields.

It is also possible to manually clear items. From the SAP Easy Access screen, choose Account Management

Account Turnovers, Balances and Key Figures Payment Item Clear Payment Item.


© 2010 SAP AG page 25/74

5 Post Processing of Payment Items via Posting Control Office

5.1 Usage of Posting Control Office (PCO)

5.1.1 Purpose

The Posting Control Office is used to handle special situations and problems that occur during posting of

payment items. All necessary information is collected in a posting control order that for most cases is directly

linked to the erroneous payment items. In special cases, there is only one posting control order for several

payment items of one account (for example, insufficient funds cause more than one payment item to fail). The

posting control order is then linked to the account itself instead of the payment item.

Possible problems that can occur for a payment item might be more technical related errors, such as:

Value (mandatory attribute not entered)

Value range (entered value not within defined value range)

Format (entered value has a format error, such as text in a date attribute)

Or business rules errors, like:

Account Posting Check failure

Insufficient funds

Access Limit violation

Account Name Check failure

Prenote missing or cannot be matched

For each of these problems, you can define actions in the rule set that define if the payment items should be

posted nonetheless, processed in the Posting Control Office, or cancelled right away.

5.1.2 Post Processing Possibilities

Depending on the rules, the following response types might be triggered for the erroneous payment item.

Response Status of item Explanation

Post Posted Item is posted on target account.

Reallocation Posted Item is posted on target account. Response creates posting control order.

Postprocessing In Postprocessing Response creates posting control order.

Redirect Posted

New target account specified in the posting control rules in customizing.

Response creates posting control order for redirection to suspense account.


© 2010 SAP AG page 26/74

Return Returned Return reason (mandatory) specified in the posting

control rules in customizing.

Reject Not relevant Rejection reason (optional) specified in the posting

control rules in customizing.

A posting control order is created for responses Reallocation, Postprocessing, and Redirect. These orders

can be processed manually in the Posting Control Office or automatically.

Process Overview Posting Control Order

5.1.3 Usage of Worklists

All exceptions that cannot be resolved automatically by the posting control rules are sent to post processing.

This means that a posting control order is created and the person responsible has to process the payment

item manually.

Posting control orders are assigned to different worklists according to specific parameters. Any number of

worklists can be defined using different criteria (up to six) for worklist determination. These criteria can be

assigned to priorities/rankings.

After correctly defining the worklist, the system assigns each payment item to a worklist if it is sent to post

processing, and matches the criteria.


© 2010 SAP AG page 27/74

Users have to be assigned to one or more worklists to be able to work with the Posting Control Office.

Transaction PCO works like a pile of orders, and a user will see all orders that are assigned to his or her

worklist, one after each other.

Posting Control Order – User Assignment to Worklists

5.2 PCO Order Processing

5.2.1 Manual Processing via the Posting Control Office

The main entry transaction for the Posting Control Office is PCO. It is possible to define complex filters on

which the selection of posting control orders is based.

One major attribute is the worklist. Users can filter for posting control orders in their worklist and start the

PCO processing. They will be shown one posting control order after another that fulfills the filter requirements

until all orders are processed.


© 2010 SAP AG page 28/74

The following screen will be displayed for each posting control order.

Change filter

settings

Choose worklist

options


© 2010 SAP AG page 29/74

The desktop is designed to offer all functionality needed to process a posting control order. You can find

general information about the affected account and the posting control order in the header data.

When you open a posting control order, a resubmission is done trying to post the payment item. The results

are shown in the log area. If the order is processed successfully, it is closed and the next one is selected. In

case of an error, all messages are displayed in the log area so that the processor knows what the problem is.

The information area shows the data of the posting control order and relevant account data. The active tab

depends on the error category of the posting control order.

In the detail area, data of the payment item is displayed so you can get more background about the item that

was not successfully processed, including which checks failed. If the posting control order is not assigned to

an item (account order), this screen is missing; instead, the account view is shown. In the account view, all

relevant items for the erroneous account are displayed in a list.

For error resolution and individual processing of posting control orders of a single account, you can use

transactions PCO02 (Edit) and PCO03 (Display). You can find the posting control orders directly via GUID or

by entering the account identification. You can use further selection criteria if necessary.

Log Area

Information Area

Detail Area

Header Area


© 2010 SAP AG page 30/74

You can perform the following actions in PCO to solve posting problems:

Prepare all information relevant for making posting control decision

Post / return / reject / transfer post turnover

Transfer to automatic processing function

Temporarily postpone processing

Close posting control order

The processor can remove the issue causing the posting problem (for example, posting lock), accept the

error and overrule the system response (for example, accept overdraft due to insufficient funds), or decline

the posting (return / reject an item).

The action taken is saved in the action log of the posting control office and the item processing is finished.

5.2.2 Automatic Processing

For automatic processing, two mass runs are available that offer the following functionality:

Select posting control order by ID

Or by account identification


© 2010 SAP AG page 31/74

Resubmission

o Check whether limit problems still exist

o Item in postprocessing: Renewed posting attempt

o Item in reallocation: Renewed check of posted item

o Item posted on suspense account: Renewed posting attempt on original account

Execute final processing

o Renewed resubmission

o Execution of final response from posting control rules

These mass runs support the users’ manual work and will clear all posting control orders after certain time

elapsed.

The resubmission run checks if problems are resolved in the meantime (for example, insufficient funds) and if

the payment item can now be posted without error. If this is not the case, the final processing run will

eventually pick up the order when it is due and process it (either post or return/reject) based on the settings in

configuration. The main goal is to solve all problems before any legal regulations kick in that require a final

processing state.

Orders can be assigned to automatic processing only so that no manual activity is necessary at all. In this

case, the benefit for the customer (compared to direct processing) is that certain problems that prevent a

posting are solved within the few hours or days that the posting control order exists.

For example, money for a life insurance policy cannot be withdrawn due to insufficient funds. The first

reaction is postprocessing; the item will only be parked at the account. For two days, a regularly scheduled

resubmission run checks to see if funds are sufficient, and posts the item as soon as it is possible. If enough

money is not available after two days, the item is returned in the final processing run. The benefit for the

customer is that there is a “grace period” of up to two days to provide enough money. For the bank, no

additional manual effort is necessary to provide this service.

5.3 PCO Setup Checklist

Activate PCO in Configuration (SPRO Financial Services Account Management Basic

Settings Activate Special Components).

Configure PCO-specific settings (SPRO Financial Services Posting Control Office).

Maintain organizational data (PPOME) and use in worklist assignment (PCO_WL_ASS_MAINTAIN).

Define main rule set and decide what needs to be processed within PCO (SPRO Financial

Services Account Management Item Manangement Posting Control Rules Define Main

Rule Set).


© 2010 SAP AG page 32/74

Start working with transactions PCO and PCO02.


© 2010 SAP AG page 33/74

6 Correspondence Monitoring and Archiving

6.1 Purpose

Correspondence is used to inform customers about specific events, such as the termination of an account, or

about periodic events, for example, in the form of a bank statement.

In the SAP Deposits and Loans Management System, correspondence is based on correspondence

requests. A correspondence request contains the necessary data for printing. Several mass processing

reports create correspondence requests, for example, during end-of-day processing. In addition,

correspondence requests can be created as event-controlled, for example, during termination of an account.

To print the correspondence, you must schedule the mass run RBCA_COPR_RUN_PP. The report

RBCA_COPR_RUN_PP creates and outputs the correspondence based on the correspondence requests,

and should be part of the end-of-day processing.

It is necessary to monitor correspondence to ensure that all correspondence requests are processed

successfully.

Archiving and deletion of correspondence requests helps you to optimize your system performance and to

ease the load on your database.

6.2 Prerequisites for Archiving and Deletion

To archive or delete a correspondence request, you have to perform the necessary setup in Customizing.

Choose Financial Services Account Management Archiving Archiving Objects Define Residence

Time for Correspondence Types (CORRSPND Object). In this activity, you define the residence time for the

correspondence requests depending on the correspondence type. If you want to delete correspondence

requests without archiving them, set the Delete indictor. Once the residence time for a correspondence type

is exceeded, you can archive or delete the related correspondence requests.

6.3 Monitoring

Report RBCA_COPR_RUN_PP creates PPO orders in case of errors. The PPO business process used is

BCA_COPR.

In addition, you can use report RBCA_CORR_HISTORY to check if all created correspondences have been

printed. On the selection screen of the report, use the technical status to select the correspondences that

have not been printed.


© 2010 SAP AG page 34/74

Usage of Technical Status of Report RBCA_CORR_HISTORY to Display Correspondences Not Printed

An additional transaction that you can use for monitoring purposes is transaction SP01 Output Controller.

With this transaction you can check whether all requests sent to the output controller have been processed

successfully.

Status of Spool Request in the Output Controller


© 2010 SAP AG page 35/74

6.4 Archiving and Deletion

You have the ability to archive correspondence requests, and you have the possibility to delete

correspondence requests without archiving. You can archive with transaction SARA for the archiving object

CORRSPND. You can delete with report RBCA_CORR_DELETE. Whether a correspondence request can be

archived or deleted depends on the residence type of the related correspondence type.


© 2010 SAP AG page 36/74

7 Automatic Postprocessing of Payment Distribution Items

7.1 Purpose

At the end of the day, you must ensure that incoming payments from borrowers are successfully processed.

The processing of incoming payments, for example, the clearing of open items, is done by payment

distribution. Errors can occur during processing. In any scenario, if the payment distribution system

encounters a failure during the clearing process (for example, if the posting date falls before the account

opening date or if the rule set was not found), the payment distribution system sends the payment distribution

items to the Posting Control Office for postprocessing. Some of the Posting Control Orders could be

reprocessed automatically, so human interaction is not always necessary.

7.2 Prerequisites

Payment distribution items are generated by payment distribution when a payment item of any payment type

is posted to a clearing account. Payment distribution items are processed according to the rule set for

payment distribution defined in Customizing or the attached payment distribution directive by report

/FSPD/RIPD_MASS_RUN_PP1.

Also see Customizing: Financial Services Account Management Product Management Payment

Distribution Define Rules for Payment Distribution.

7.3 Reprocessing

You should run report /FSPD/RIPD_MASS_RUN_PP2 to automatically reprocess failed payment distribution

items. The run can be processed during the day or during end-of-day processing.

Additionally, check the Posting Control Office for failed payment distribution items, because not all failed

items can be reprocessed automatically.

Note: The automatic reprocessing report of the Posting Control Office does not process payment distribution

items.

SAPEVENT:DOCU_LINK/DS:GLOS.452AC39343740570E10000000A155436


© 2010 SAP AG page 38/74

8 Monitoring of the Banking Services System

It is high priority for the Operations team to monitor the system during nighttime processing as well as during

daily processing. In the following chapters we will introduce SAP Banking Services customers to the SAP

transactions, reports, and tools that can be used for performance, technical, and application monitoring.

We also provide the necessary information for the Business Process Monitoring for SAP Banking Services

that is offered via the SAP Solution Manager.

Also see the following RunSAP Documents: Parallelization, Packaging, Monitoring for SAP Banking https://websmp207.sap-ag.de/~sapidb/011000358700001878872008E Business Process Performance Monitoring for Banking Solutions https://websmp207.sap-ag.de/~sapidb/011000358700001829372008E

8.1.1 Performance-Oriented Monitoring and Analysis

8.1.1.1 MassMan Monitoring Analysis Tool

MassMan is a monitoring tool that basically displays the main information about the mass runs (based on the

Parallel Processing Framework) that are currently running or have been running on the given system. The

aim of this functionality is to provide information like parallelization settings, which normally need to be

collected using several different transactions, on one single screen. Besides the monitoring functionality,

MassMan is also a data collector for SAP Solution Manager Business Process Monitoring (BPM), where all

the information from MassMan can be reported and used for automatic alerting. Besides the daily monitoring

of mass runs, MassMan is also suitable for performance testing.

You can implement MassMan by applying the latest ST-A/PI package on the relevant satellite system.

To open MassMan, use transaction ST13 and choose MASS_MAN_MONITORING application with F4 help.

Analysis & Service Tools Launchpad




© 2010 SAP AG page 39/74

Always enter a date so old runs are not confused with the list of runs.

MassMan – Mass Run Analysis Tool


© 2010 SAP AG page 40/74

Example of a Mass Run

The main purpose of MassMan is to ease monitoring of the mass activities on a system and speed up the

recognition of problems, their analysis, and the definition of necessary actions depending on the situation:

Abnormal runtimes (low throughput, expected runtime is out of range)

Unusual data volumes

Cancellations of runs

Processing problems (due to data quality)

Features:

Cumulated view of mass run information via ALV display:

o Status

o Duration and estimated duration

o Progress

o Throughput

o CPU and DB usage per server

o Number and status of parallel jobs

o Amount of processed data with categories, like accounts processed successfully or accounts failed

o Detailed view of child jobs of a particular mass run

o Convenient interface to standard analysis tools (SM37, SM66, PP monitor, and so on)

Historization of data:

o To compare behavior of future and past runs

o Keep data even for deleted/archived runs


© 2010 SAP AG page 41/74

8.1.1.2 Workload Monitor – ST03

Workload analysis provides a comprehensive overview on throughput and response times. Workload analysis

can be used to prioritize performance problems and also shows the load distribution for application programs

and transactions.

The Workload Monitor (transaction ST03) displays statistics about response times, memory use, and

database accesses for all transaction steps and all SAP components.

You can decide between “total” (for all instances) and the instance itself and select the appropriate time

period. On the screen you can see the statistical performance data from the SAP system. If you select

Workload overview on the left side of the screen, you will find a breakdown of statistics on response times

and throughput by the different task types, such as Dialog, Update, Background, and Spool, further divided

into RFC and HTTP for Dialog.

Workload Monitor

Along with the information for each task type, you get the number of transaction steps, the average response

time, and the average CPU and database time per transaction step. This information helps you to identify and

understand performance problems and possible causes.

To collect the statistical records regularly, you have to schedule and run the RSCOLL00 program (name

SAP_COLLECTOR_FOR_PERFORMANCE) every hour as a background job.


© 2010 SAP AG page 42/74

8.1.1.3 Single Record Statistics – STAD

After you have identified programs or single transactions as expensive (for example, after performing a

detailed workload analysis) you can start a detailed performance analysis for these programs and

transactions by using transaction STAD. The statistical information includes response time, memory

requirements, database accesses, and so on. These records are collected by the collector RSCOLL00 and

are deleted after a certain time. A screen with the statistical records that match your selection criteria

displays:

Single-Record Statistics


© 2010 SAP AG page 43/74

The single-record statistics allow you to identify a problem that might not be visible in the average values of

the transaction profile.

As a result, you can detect, for example, communication problems that have high roll wait times; other high

CPU times could imply time-consuming calculations.

8.1.1.4 Trace Analysis – ST05/ SE30/ST12

If a program or a transaction with a critical runtime behavior is identified, start the performance analysis. Most

of the performance issues are based on non-optimal coding or non-optimal database accesses.

By using transaction ST05 (SQL trace), you trace select statements reading records on database level.

If, through an SQL trace, you identify an SQL statement with a long runtime, you should perform a second

and third SQL trace to deepen your analysis and to get a trace analysis with already buffered data. If a lot of

select statements are processed during your trace, use the summary function of the SQL trace to get an

overview of the most expensive SQL statements. Identical database selects often impact the performance

and should therefore be avoided. They can be detected via the functionality “List of identical select

statements.”

SQL Summarized Statements Sorted by Duration

A suspicious select should be checked in detail by displaying the execution plan. Select arguments and

indexes chosen by the database or buffer selects should be checked for best performance.


© 2010 SAP AG page 44/74

With transaction SE30 (Run time analysis) you can trace ABAP coding by using the name of the program,

function module, or transaction code.

Within an ABAP trace, first check if the time consumption is more on database or ABAP level. If database

accesses consume more time, it is an early sign that select statements should be analyzed in more detail. To

begin the analysis for the ABAP trace, sort the results by net time first.

ABAP Trace per Call

In both tools, you need to switch tracing on or off during the time frame of the performance measurements.

You can combine the tools, tracing ABAP code, and SQL statements by using transaction code ST12.


© 2010 SAP AG page 45/74

Select Trace Analyses

When you switch on or activate a trace, traced records are written into a trace file. After you deactivate or

switch off the trace, the result can be evaluated via selecting the relevant trace file, based on the time stamp.

8.1.1.5 Database Monitor – ST04

SAP supports different relational database systems. Even each database system has its own architecture,

SAP provides with the Database Monitor, transaction ST04 fundamental database analysis and monitoring

functions. You get database snapshots related to the currently active database processes and the

assignment of the database processes to the SAP work processes as shown, for example, in transaction

SM50 (local work process overview).


© 2010 SAP AG page 46/74

Database Monitor

The Database Monitor relies on performance data out of the database system and, in addition, data collected

directly by the SAP system, for example, in the database interface for the SAP work processes.

In the “Shared SQL Area” (also called the “Shared Cursor Cache” or “Shared SQL Cache”), you find details

related to the number of executions of an SQL statement, the number of logical and physical read accesses

per statement, the number of rows that were read, and the response times.


© 2010 SAP AG page 47/74

Shared SQL Area

Monitoring the data buffer of the database system is very important, because non-optimal buffer settings

could decrease overall system performance. The most important buffer in a database system is the “data

buffer” or “data cache,” which stores parts of the most recently read database tables and their indexes.

Reading the buffer is much more effective and faster than reading the data from the hard disks.

8.1.1.6 Operating System Monitor – ST06/ OS07

The operation system monitor is a very helpful tool to get an impression of the overall system performance.

The main screen of the operation system monitor, via transaction ST06 or OS07, lists the most important

performance data for the operation system and the related hardware, such as hard disk, memory, and CPU.

Program SAPOSCOL renews all data every 10 seconds (if scheduled).

For the categories:

CPU

Memory

Disk

LAN

File system


© 2010 SAP AG page 48/74

You can check and analyze different key figures, such as utilization, traffic, and response times. You get

these values by a snapshot--previous hours or the last 30 days--so it is not only possible to get an overview

of the current performance situation, but you can also do a review of the last month.

Operation System Monitor

If the sum of the physical memory and swap space is smaller than the total amount of memory required by

the SAP system, the database, and other programs, this may cause program terminations or even operating

system failure. You should therefore ensure that there is sufficient swap space available.

The unused CPU capacity should generally be at least 20% per hour. This enables the system to

accommodate temporary workload peaks. The paging rate should not become too large; paging should not

be critical for performance if, every hour, less than 20% of the physical main memory is paged. For

asynchronous operation systems like Windows NT, the value is indicated as the “paged-in rate”; for other

operation systems that page only when necessary, like the most UNIX derivates, the key statistic is the

“page-out rate.”

8.1.1.7 Workprocess Overview – SM50/ SM66

An SAP instance provides workprocess slots, which are used by the dialog or batch processing. For each

single process/dialog step, for example, if you press F8 or Enter within a certain program or report, the time

between pressing the key and the screen is available again, this processing uses a workprocess.

You can display these workprocesses with transaction SM50 for the application server on which you are


© 2010 SAP AG page 49/74

logged on, or with transaction SM66 for all available application servers of the SAP instance (global

workprocess overview).

Several types of workprocesses are defined. DIA will support dialog processing and BTC batch jobs or

background processing. The amount and the allocation of the workprocesses need to be customized to

customer needs and application demands.

The workprocess overview gives you a first impression of the used process slots. If you watch the work

process overview for several minutes and repeatedly choose the REFRESH button to update the overview,

you can usually determine whether there is a current performance problem related to the number of work

processes in the SAP instance. The main indication of a performance problem for processes is that all the

work processes of a particular type (such as DIALOG or UPDATE) are occupied.

You can get further details and activities of the workprocesses by double-clicking or selecting Process details

in the menu (/Process /Details) or by pressing Ctrl+Shift_F11.

You can get additional information about current database accesses of the relevant workprocess in the Action

and Table fields in the overview. If an access on one specific table is very time consuming and the elapsed

clock time for the process step increases, a further analysis of this process step should be taken into account.

You can detect insufficient memory consumption via ST02 /Detailed analysis menu /SAP Memory /Mode list

by setting focus on the relevant user. You can also check current memory consumption of a certain

workprocess by double-clicking on the relevant workprocess ID.


© 2010 SAP AG page 50/74

Work Process Overview

8.1.1.8 SAP Code Inspector – SCI

The Code Inspector is a tool for checking static ABAP coding and DDIC objects (generally: TADIR objects)

under aspects of performance, security, reliability, and statistical information.

To call the Code Inspector for a single object from ABAP editor (SE38), function builder (SE37), or the class

builder (SE24) choose Object Check Code Inspector from the menu, where “Object” stands for

“Program,” “Function module,” or “Class.” The respective single objects are then checked with a Default

Check Variant.

To check a number of objects, for example all objects of a package, use transaction SCI to:

Create an Object Set that contains your objects

Create a Check Variant containing the checks you want to execute on the objects

Create an Inspection combining the Object Set with the Check Variant, and run it

Results of an Inspection: After the inspection run is ready, click Results. You will get a list of identified code

lines by using standardized searching methods. All results need to be checked in detail before modifying it.

The inspection results are arranged in a tree. Open the result tree by clicking on the folders. The leaves of the

tree are the check messages.

Each message contains:


© 2010 SAP AG page 51/74

The source code position (or name of the TADIR object)

A short explanatory text

For further explanation:

Click the information icon in front of the message .

Double-click the message text to attain the inspected object.

Code Inspector: Inspection Results


© 2010 SAP AG page 52/74

Inspection Results: Help Text for a Message

Note: Code Inspector can only inform you that some coding might slow down performance. A static tool

cannot replace the developer’s knowledge of a program. Use ST05 (SQL-Trace), SE30 (Runtime Analysis),

and/or ST30 (Global Performance Analysis) to trace your running code.

Also see RunSAP Document: Manage Code Quality with Code Inspector https://websmp207.sap-ag.de/~sapidb/011000358700000486422009E

8.1.2 Technical-Oriented Monitoring and Memory Analysis

8.1.2.1 SAP Memory Configuration Monitor - ST02

You can check the usage and size of the SAP memory areas via transaction ST02 (SAP Memory

Configuration Monitor). For SAP buffers, a displacement should not occur (an exception is the program

buffer, where up to 10,000 displacements is still okay). The Extended Memory or Roll buffer should not

become full.

After starting the SAP Memory Configuration Monitor for the instance, the main screen Tune Summary

appears. It displays information on configuration and utilization of the SAP buffer, SAP Extended Memory

(EM), and the SAP Heap Memory.



© 2010 SAP AG page 53/74

Main Screen of the Memory Configuration Monitor (Tune Summary)

In the SAP Buffer area you can find details like hit ratio, allocated memory space, free space, and swaps.

If buffers are too small, the database has to be accessed often to reload data. Therefore, you should check

that the hit ratio for the buffers is 98% or higher (exceptions are the single record buffer, the export/ import

buffer, and the program buffer). A minimum buffer quality is required to ensure smooth operations of the SAP

system.

It is also important that you monitor the SAP Memory with the areas Roll area, Paging Area, Extended

Memory, and Heap Memory. In the SAP Memory section, you can find information for the current and max

use of memory. By choosing Current Parameters, you can display the current system settings. With the

Detailed Analysis Monitor, you have the possibility to call other monitors and can retrieve more detailed and

historical information regarding the buffers.

8.1.2.2 ABAP Dump Analysis - ST22

By executing transaction ST22 you can check if ABAP program dumps occurred on the SAP system. You can

access detailed information that is related to the termination to analyze the cause of the ABAP program

dump.


© 2010 SAP AG page 54/74

ST22 Dump with Coding Detail Screen

You can get information for different views, such as User view, ABAP developer view, and Basis developer

view. In the System Environment area, you can get details on memory consumption. High memory

consumption could be caused, for example, by large internal tables, which could therefore lead to

performance problems.

8.1.2.3 System Log - SM21

In addition to ST22 (ABAP Dump Analysis), the SysLog gives you the ability to evaluate system messages

that are written to a protocol to perform a detailed analysis in case of errors. SysLog distinguishes between

messages, warnings, and errors. You can get detailed information about the user that has caused the error or

the erroneous transaction. Every instance has its own SysLog.


© 2010 SAP AG page 55/74

SysLog SM21

8.1.2.4 Computing Center Management System – CCMS/ RZ20

CCMS is another function to configure and monitor the technical status of an SAP system. The results of the

CCMS should be checked by the system administrators as part of their daily work. Along with some other

technical functions, the CCMS gives the system administrator central functions in regard to dynamic load

distribution, fine-tuning of the system, batch job processing, and system monitoring. Via the RFC connection,

you can also monitor other systems with different releases. You can monitor your chosen attributes by setting

thresholds. If a value of a monitored attribute is exceeded, the value will be displayed as yellow or red.

The following objects can be monitored:

Background Processing

Buffers

Communication


© 2010 SAP AG page 56/74

Database

Dialog Overview

Dialog per Application Server

Enqueue

Entire System

File systems

Operating System

Performance Overview

Spool System

Syslog

System Configuration

System Errors

To enable the auto-alert mechanism of CCMS, see SAP Note 617547.

8.1.2.5 Analyze Memory Consumption - S_MEMORY_INSPECTOR

You use the Memory Inspector if the programs can already access certain datasets. This is particularly the

case in the testing and production phases, where you want to check and optimize memory consumption for

the best system performance.

This tool (transaction S_MEMORY_INSPECTOR) is used to analyze memory snapshots. Therefore, dynamic

data objects, such as internal table, strings, objects, and anonymous data objects will be considered from the

Memory Inspector. You can create a memory snapshot by:

Use code /HMUSA in the command field. You will get confirmation with message “File

abDbgMemory_001_000x created.”

Out of the menu path on top of your local GUI, choose

/System /Utilities /Memory /Analysis /Create Memory Snapshot.

Call method CL_ABAP_MEMORY_UTILITIES => WRITE_MEMORY_CONSUPTION_FILE (…) out

of your individual ABAP program. You should use this option only for testing purposes; avoid

excessive or frequent use of this method out of an ABAP program.

After the memory snapshot is created, you can analyze the result using the Memory Inspector. In the upper

area of the screen, you find all available snapshots and you need to select your snapshot by choosing a user

and a relevant time stamp. It is also possible to compare two different snapshots to determine which internal

table will grow excessively.


© 2010 SAP AG page 57/74

You can also use the Memory Inspector during performance analysis for internal tables processing.

Memory Inspector

Also see SAP Documentation: Memory Inspector http://help.sap.com/saphelp_nw2004s/helpdata/en/a2/e5fc84cc87964cb2c29f584152d74e/frameset.htm

8.1.2.6 Transactional RFC – SM58

You should use transaction SM58 (transactional RFC) on a regular basis when there is RFC communication

between applications, especially when Loans on Platform is used to check whether all Billing Request Items

are sent over from the SAP Banking Services system to the SAP FI-CAx system for open item management.

If necessary, you can re-start the transfer from the SAP Banking Services system after the problem is solved

(it is also possible to perform it in debugging mode). For more information, please see chapter 2.6, Errors in

between Application Components, in the best-practice document Best Practices for End-of-Day Processing -

Exception Handling.

Also see RunSAP Document: RFC Monitoring https://websmp207.sap-ag.de/~sapidb/011000358700000491282008E

http://help.sap.com/saphelp_nw2004s/helpdata/en/a2/e5fc84cc87964cb2c29f584152d74e/frameset.htm



© 2010 SAP AG page 58/74

8.1.2.7 Message Monitoring- Integration Engine – SXMB_MONI

For message processed via the Process Integration Server (PI), you can use transaction SXMB_MONI for

monitoring and analyzing. Select the monitor for XML messages and specify the relevant time interval. If too

many messages come up, specify status group Errors and follow your guidelines for troubleshooting.

Message Monitoring via SXMB_MONI

You cannot execute options in the menu that have the locked symbol, because you do not have the required

authorization. The authorizations for the individual functions are tailored to requirements and are assigned as

derivations of the role SAP_XI_MONITOR. They are all based on the authorization object S_XMB_AUTH.

Authorization object S_XMB_DSP controls the display of the message content. Unless the user has the

authorization S_XMB_ADM (administrator), the system only displays XML messages for the current client.

For more information about the use case of SXMB_MONI, follow chapter 2.6, Errors in between Application

Components, in the best-practice document Best Practices for End-of-Day Processing - Exception Handling

(https://websmp207.sap-ag.de/solutionmanagerbp).

8.1.2.8 Snapshot Monitoring /SDF/MON

You can create SM50 snapshots within a predefined interval by using the Snapshot Monitoring /SDF/MON.

You can use this functionality for performance testing within a certain time frame or to analyze overall system

performance during an error behavior. Report /SDF/MON is included in the ST-PI package.

With this report, you can get details for:

Used work processes

CPU consumption

https://websmp207.sap-ag.de/solutionmanagerbp


© 2010 SAP AG page 59/74

Allocated and free space of the different memory areas

Before snapshots are taken, you need to schedule the monitoring.

To start the Snapshot Monitoring, you can define several details that will be stored during the snapshots. As a

first step, you should define a description of your monitoring session and set the time interval between two

snapshots. The default value is 10 seconds; for a longer monitoring session, it is recommended that you use

a higher value like 60 seconds, or even more.

Next, check and define intervals for the different values that are stored during the monitoring session.

Finally, define the start time and end time for the session. You can also schedule the monitoring session for

the next overnight processing to get details of your system performance during the EoD processing, or of a

certain report that needs to be analyzed regarding performance.


© 2010 SAP AG page 60/74

You can monitor and analyze the session immediately or later by selecting the relevant session in the

selection screen of the report.

Below is an example of a monitoring session with a snapshot every 60 seconds.


© 2010 SAP AG page 61/74

You can display details by double-clicking on the different values.

This monitoring functionality is not intended to be used 24 hours per day; use the report to solve an issue or

to get an impression of your system performance during testing or execution of mass runs.

8.1.3 Application-Oriented Monitoring

8.1.3.1 Parallel Processing Monitor - RBANK_PP_MONITOR

You can monitor reports developed based on the PPF (Parallel Processing Framework) by using the

RBANK_PP_MONITOR report started via SE38/SA38 or started via transaction BANK_PP_MONITOR.

RBANK_PP_MONITOR shows the status of the currently running jobs and how many packages are already

processed in percentage rate, along with other details. In parallel, you get an overview of the relevant active

processes shown by SM50 – Process overview.

The monitor is available in all systems using SAP Basis 620 or higher.


© 2010 SAP AG page 62/74

After the mass run has been successfully processed, no more run information can be found in the monitor. It

will show only currently running jobs or jobs processed with errors. If errors occurred, you will find the entries

marked in red after the processing of the mass run.

In the Processing Status field, the monitor shows how many packages, in %, are already processed. The

Table Data field shows the total number of packages and Packages Init shows the packages that are waiting

for processing. You can see currently processed packages in the monitor in the Packages Collected field.

Further details are provided in the document Best Practices for End-of-Day Processing – Exception Handling

in chapter 2.8, Mass Run Monitoring with Transaction BANK_PP_MONITOR.

Related to the RBANK_PP_MONITOR check, deletion report RBANK_DELETE_RUNS deletes process data

that was created to process the job within this framework. After a successful run, this data is not longer

needed and can be deleted using this report. Also see SAP Note 1418333 related to this topic.

8.1.3.2 Job Overview – SM37

You get the Job overview of all running, scheduled, released and finished batch jobs in your SAP

environment by using transaction SM37.

First you need to provide details on the selection screen.


© 2010 SAP AG page 63/74

To see the relevant details of the job, you usually select jobs by name of the job, name of the user, status of

the job, and often the time frame of the processed job or the planned start time. Press F8 or the

button to get a detailed list with your selection parameter in the header.

You use this tool to monitor batch jobs during processing to get details of their status, to ensure successful

processing, to check for runtime and related details of a job, or to schedule jobs for a certain time in the

future.


© 2010 SAP AG page 64/74

If a job is finished, you can see the duration of the job in seconds, job log details, and if a spool file has been

written. The screen only shows a snapshot with selected parameters; if you want to view the current situation,

press F8 to refresh.

Also see RunSAP Document: Job Scheduling Management


8.1.3.3 Display Application Log – SLG1

You can analyze the system application log via transaction SLG1. Application logs are generated for all

application processes based on SAP PPF. The system logs statistical information about the mass run

(number of processed and successful objects), error messages for all problems that occurred, and success

messages (if enabled).

Whether success messages are written to the application log depends on the settings in the selections

screen of the mass run.



© 2010 SAP AG page 65/74

For testing purposes, it is fine to choose all messages, but during production it is recommended that you have

only one success message per object (if at all). If you choose Log Off (no message), there will not only be no

success message, but also no error message in the log and no messages in the postprocessing orders (the

creation of orders is independent). This setting is not recommended.

There is an individual transaction to display the application log for each mass run in Banking Services, for

example, transaction BCA_ACBAL_MASS_LOG to display all application logs of the account settlement

mass run. You can find these transactions in the Easy Access menu by choosing Account Management

Logs. All log transactions have the same look and feel and are based on transaction SLG1, which is

described in detail below. The difference between the transactions is that some parameters, like Program and

External ID, are filled by default, which makes it easier to select only the logs you are interested in.

In this selection screen all settlement mass runs from 01.12.2009 of user C5128636 are selected. This is a

good way to start analyzing logs depending on date and application.

The log entries are ordered by date/time/user; all entries with the same external ID belong to one mass run.

At first glance, the log entry with sub-object Statistical Data is important. If you double-click on the line, you


© 2010 SAP AG page 66/74

receive details as displayed below. In statistical data, you can see all administrative data about the mass run

(job IDs, parameter values, and number of processed and successful objects).

Erroneous and successful objects are listed in the entries with sub-object Normal error and Success

message; you can find all additional messages for the objects under sub-object Information.


© 2010 SAP AG page 68/74

9 Housekeeping of the SAP Banking Services System

9.1.1 Cross-Application Housekeeping

Different kinds of files are created within a SAP system and its related database: working files, directories, log

files, application files, and so on. You need to perform housekeeping manually and automatically to remove

any of the files that are no longer required. Not performed housekeeping jobs could negatively influence

overall performance.

Most of these housekeeping jobs are not related to the banking solution and are also required in a non-

banking system on a regular basis.

You can delete some types of data from your system soon after creation. You should carry out reorganization

of the data discussed in this section at regular intervals. See SAP Note 16083 (release-independent) for

standard and reorganization jobs related to this topic. There you will find application-independent

reorganization jobs for jobs (RSBTCDEL2), spool entries (RSPO0041/1041), ABAP Dumps (RSSNAPDL),

and many more.

These jobs are processed automatically. In earlier releases, it is necessary to schedule these jobs manually.

With SAP Note 706478, you get an overview of the administrative basis tables that may become big. You

should regularly delete or archive data from, for example, application log tables, change pointer tables,

TemSe tables, or related to the CML loans solution “Change pointers for loans” with tables VDCHGPTR,

JBDCPHDR2, JBDCPPOS2.

Different applications, not only Banking, will write message items into the application log tables. Check the

affected tables BALDAT, BALHDR, BALHDRP, BALM, BALMP and BALC regarding their growth and

unnecessary entries. Especially during mass runs, these tables could get a huge number of warning and/or

error messages. In some applications, you can filter which message is stored and which message will be

avoided in the application log.

Check SAP Notes:

• 16083 (release-independent): Standard Jobs, Reorganization Jobs

• 706478 (release-independent): Preventing strong growth of basis tables

9.1.2 Banking Services System Housekeeping

9.1.2.1 Deletion Report for RBANK_PP_MONITOR Process Data

There are also some banking-specific housekeeping runs, like the deletion run of the PPF Monitor

(transaction BANK_PP_MONITOR or report RBANK_PP_MONITOR). For more information, also see chapter

3.3 in this document. With this functionality, you can monitor mass runs using the parallelization framework

(PPF). The objects to be processed by a mass run using this framework are split into several packages and

each package is processed within its own work process.


© 2010 SAP AG page 69/74

The process data is deleted if the mass run has been processed successfully. For mass runs with errors, the

process data is needed for analysis. If the data is no longer needed, it is deleted using the deletion report

RBANK_DELETE_RUNS. With changes by SAP Note 1439952, this report could also be processed in batch

(SAP NetWeaver 710 and 711).

9.1.2.2 Deletion Report for “Account Settlement” Simulation Data

A simulation run is available for the “Account Settlement” functionality. The results of the simulation run are

stored in table BKK92_SIM. You can delete the entries of table BKK92_SIM with report RFBDELSIM.

9.1.2.3 Adapt Product Pricing List to Related Contracts Report

If the functionality of pricing is used, every change of the product pricing list should be adapted to every

related contract by using report R_BCA_PRI_PP_PACKAGE_CN via transaction BCA_PRI_PPL_CN_M.

Some customers have already included this report in their end-of-day process. If this report is not included in

the EoD, it should be taken into account to run this report once per week to prevent possible errors or

incorrect calculations because of non-adapted contracts.

9.1.2.4 Check Financial Conditions Customizing

Use report RFICO_CUSTOMIZING_CHECK on a regular basis to check customizing of the financial

conditions. If an already created condition group type or condition type needs to be changed, you need first to

check if it has already been used in production. If it has already been used, do not change it.

NEVER CHANGE A USED CONDITION GROUP TYPE OR CONDITION TYPE!

9.1.2.5 Delete Reports in Account Management via Delete Objects

In the SAP-Menu, you can find several reports for deleting data via delete object. The following objects are

currently available:

Account Management Archiving Data Deletion

o SNITEM – Non-Balance-Changing postings

o GL_BALANCE – Financial account balances

o GL_BALPREP – Balance sheet preparation data

o GL_SUMS – FI totals records

o INVENTORY – Inventory data

o RECONC – Reconciliation data

o PRENOTE_T – Technical Prenotes

The delete programs delete the data records of the deletion object from the operational database. Data that is

no longer required in the operational system is deleted to improve performance in the operational database.


© 2010 SAP AG page 70/74

During the process, the delete program generates an application log containing statistical data and simultaneously

writes the current status in an activity log. You can use the archiving monitor to display both logs and monitor the

progress of the process flow.

Check prerequisites and customizing before running the delete programs for the first time.

Also check SAP Note 1312823 with the attached PDF document General Ledger Transfer with Sub ledger in

Account.

SAPEVENT:DOCU_LINK/DS:TRAN.AFX_MONITOR


© 2010 SAP AG page 71/74

10 Background Information and References

10.1 Overview of the Most Important Best Practice Documents

End of day/ Batch Processing Deposit Management https://websmp207.sap-ag.de/~sapidb/011000358700000671032009E Job Scheduling Management https://websmp207.sap-ag.de/~sapidb/011000358700001250602005E RFC Monitoring https://websmp207.sap-ag.de/~sapidb/011000358700000491282008E Manage Code Quality with Code Inspector https://websmp207.sap-ag.de/~sapidb/011000358700000486422009E Parallelization, Packaging, Monitoring for SAP Banking https://websmp207.sap-ag.de/~sapidb/011000358700001878872008E Business Process Performance Monitoring for Banking Solutions https://websmp207.sap-ag.de/~sapidb/011000358700001829372008E Exception Handling in Banking Services https://websmp207.sap-ag.de/~sapidb/011000358700000671072009E

10.2 Overview of the Most Important Transactions

The most important transactions for Operations and Monitoring on the Banking Services system are

summarized below.

Performance-Oriented Monitoring Transactions:

Transaction Description Page OS07 Operating System Monitor (server in-dependent) 45

SCI SAP Code Inspector 48

SE30 ABAP Trace Analysis 40, 41, 50

SM50 Workprocess Overview (instance/ server based) 46

SM66 Workprocess Overview 46

STAD Statistical Records 39

ST03 (N) Workload Monitor 38

ST04 Database Monitor 43

ST05 SQL Trace Analysis 40, 50

ST06 Operating System Monitor (server dependent) 45

ST12 Trace Analysis 40

ST13 -> MASS_MAN_MONITORING

Mass Man Monitor for Batch jobs based on PPF tool

37









© 2010 SAP AG page 72/74

Technical-Oriented Monitoring Transactions:

Transaction Description Page RZ20 Computing Center Management System 52

S_MEMORY_INSPECTOR Memory Inspector 53

SM21 System Log 52

SM58 Transactional RFC Monitor 54

ST02 SAP Memory Configuration Monitor 50

ST22 ABAP Dump Analysis 51

SXMB_MONI Message Monitoring – Integration Engine 55

/SDF/MON Snapshot Monitoring 55

Application-Oriented Monitoring Transactions:

Transaction Description Page BCA_PPOx (2,3) Post Processing Office Display/ Change for

Account Management 10, 11, 12, 18

MCM_PPOx (2,3) Post Processing Change/ Display for Master Contract Management

11, 18

PLM_PPOx (2,3) Post Processing Change/ Display for Posting Log Management

11

RBANK_PP_MONITOR Monitor for jobs based on PPF tool 7, 58, 59, 65

SLG1 Display Application Log 16, 61, 62

SM37 Job Overview 7, 38, 59

/n/SAPPO/PPOx (2,3) Post Processing Change/ Display application component independent

9, 11

10.3 Overview of the Most Important Regular Jobs

The most important jobs on the Banking Services system are summarized below.

Job Frequency Description Page

/SAPPO/RESUBMIT_ORDERS_2 multiple times a day

Automatic processing of PPO orders after errors has been solved or unlocks has been done

17

RSCOLL00 Every hour Collect statistical records automatically

39

System Log Daily (minimum) Evaluate system message for each instance

52

CCMS / RZ20 Daily (minimum) Monitor technical status of the system

52

SXMB_MONI Daily (minimum) Check erroneous PI messages 55

/SAPPO/DELETE_ORDERS Daily Closed PPO order will be deleted

17

RBCA_PAYMITEM_CLEARING_LIST Daily Check for open items not cleared

23

Posting Control Office Daily Check and process erroneous 25


© 2010 SAP AG page 73/74

payment items

MassMan Monitoring Daily For daily monitoring and performance testing

36

Postprocessing Office Daily, after EoD Post processing of errors occurred during the end-of-day processing via PPO orders

8

Transactional RFC Daily Check RFC communication errors

54

RBANK_DELETE_RUNS Monthly Delete administrative data of mass runs

20, 59, 66


© 2010 SAP AG page 74/74

© Copyright 2010 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z, System z10, System z9, z10, z9, iSeries, pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS, S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise Server, PowerVM, Power Architecture, POWER6+, POWER6, POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes, BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX, Intelligent Miner, WebSphere, Netfinity, Tivoli and Informix are trademarks or registered trademarks of IBM Corporation. Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, Clear Enterprise, SAP BusinessObjects Explorer and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries. Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP France in the United States and in other countries. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. The information in this document is proprietary to SAP. No part of this document may be reproduced, copied, or transmitted in any form or for any purpose without the express prior written permission of SAP AG. This document is a preliminary version and not subject to your license agreement or any other agreement with SAP. This document contains only intended strategies, developments, and functionalities of the SAP® product and is not intended to be binding upon SAP to any particular course of business, product strategy, and/or development. Please note that this document is subject to change and may be changed by SAP at any time without notice. SAP assumes no responsibility for errors or omissions in this document. SAP does not warrant the accuracy or completeness of the information, text, graphics, links, or other items contained within this material. This document is provided without a warranty of any kind, either express or implied, including but not limited to the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. SAP shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. This limitation shall not apply in cases of intent or gross negligence. The statutory liability for personal injury and defective products is not affected. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third-party Web pages nor provide any warranty whatsoever relating to third-party Web pages.