framework for parallel processing for customer reports

Best_Practice_FPP_for_Customer_Reports_V21.doc – 11.11.2008

Best Practice

Framework for Parallel Processing forCustomer Reports

Dietmar-Hopp-Allee 16D-69190 Walldorf

CS STATUScustomer published

DATE VERSION

Nov-11 2008 2.1

SOLUTION MANAGEMENT PHASE SAP SOLUTION

Operations Implementation SAP Banking

TOPIC AREA SOLUTION MANAGER AREA

Application and Integration Management Capacity Management

Best PracticeFramework for Parallel Processing for Customer Reports

© 2008 SAP AG - Best_Practice_FPP_for_Customer_Reports_V21.doc page 2/34

Table of Contents1 Management Summary 4

1.1 Goal of Using This Service 41.2 Staff and Skills Requirements 41.3 System Requirements 51.4 Duration and Timing 51.5 Examples 5

2 Best Practice – Implementation Guide 62.1 Design of Framework for Parallel Processing 6

2.1.1 Architectural Context 72.1.2 Events 7

2.2 Step-by-Step Instructions 92.2.1 Application Type and Object Type 92.2.2 Logical Definitions 9

2.2.2.1 Package Formation Category 92.2.2.2 Restart Procedure 11

2.2.3 Global Application Parameter 122.2.4 Events and Callback Modules 12

2.2.4.1 Event 0205 – Create Package Templates 122.2.4.2 Event 1000 – Initialize Package 132.2.4.3 Event 1100 – Selection per Range 152.2.4.4 Event 1200 – Selection for Known Object List 152.2.4.5 Event 1300 – Edit Objects 16

2.2.5 Start Report 172.2.6 Application Log Handling 172.2.7 Job Log Message Handling 182.2.8 Collection of Statistical Information at the End of a Mass Run 19

2.3 Configuration (Customizing) 202.4 Enhancement Options 222.5 Complex Scenarios 22

2.5.1 Multi-Step Processing 222.5.2 Special Parameters for Package Formation 222.5.3 Object Locks – Dependencies Between Application Types 23

2.5.3.1 Set Locks – BANK_MAP_PP_LOCKS_SET 232.5.3.2 Read Locks – BANK_MAP_PP_LOCKS_GET_MLT 242.5.3.3 Delete Locks – BANK_MAP_PP_LOCKS_RELEASE 25

2.6 Job Distribution 252.6.1 Degree of Parallelization 252.6.2 Distribution 26

2.7 Monitoring of FPP Enabled Reports 262.7.1 MassMan in Satellite System and Central System 262.7.2 MassMan – Start Screen 272.7.3 MassMan – Displayed Information 27

3 Further Information 293.1 Documentation of Central Interfaces 293.2 Debugging 31



3.2.1 Synchronous Start in Dialog Mode 313.2.2 Parameters BANK_JC_DBG_MODE in the User Data (from release 6.40) 31

3.3 BANK_PP_SETTINGS 313.4 Repeat – Retry – Restart 32

3.4.1 Repeat – Repetition of a Package 323.4.2 Retry – Repetition of Whole Step 323.4.3 Restart 32

3.5 Tools for Developer Support 323.6 Glossary 33

Index of Figures 34



1 Management Summary

In the Banking Services environment, Framework for Parallel Processing (FPP) enables applications toprocess mass data efficiently. Very often customer-developed reports are poor in scalability and memoryallocation, which also has a tremendous impact on the general performance of the report and sometimes onthe project success.

This document describes how to set up a parallelization and package size for performance-critical customer-developed mass processes as part of the Banking Services solution, by using the existing infrastructure andlogic of FPP, which has already proven its robustness in the SAP standard processes. The tool enablesparallel execution (several application servers) of runtime-intensive mass processing. The applicationallocates the data to be processed to packages that are transferred to the tool. The tool administers thesepackages and controls their processing in parallel background jobs. The execution of these jobs is controlledby basis job scheduling functionality.

The performance improves when data is processed in many batch processes with a specified package size.The split into packaged processing increases the scalability of the customer reports as well because itprevents huge internal tables and memory overflow by design.

Better maintainability and hence lower TCO costs because of scalability and optimal usage of CPU resourcescan be reached by enabling mass data processing customer reports on FPP in a banking environment.

The document provides guidance on how IT departments can take advantage of FPP for a banking solution.

1.1 Goal of Using This Service

Implementing Run SAP recommendations means implementing SAP Best Practices of how IT can moreefficiently run their Banking solution. This paper focuses on best practices for processing mass volumes andcan be used as a developer handbook to enable customer reports to run with the optimal performance. FPPenables applications to process mass data very efficiently.

Performance improves by processing the data in several processes and packages. The scalability of themass processing is ensured by the package processing of FPP, which reduces the likelihood of memorydumps and huge internal tables. Depending on the package size, the same number of objects will be pickedup from the work list and will be processed in an equal manner. The framework provides all control functionsbut the application must prepare the business logic.

This document describes in detail the design of FPP and explains the adjustments that are necessary toincorporate a customer program on the framework. Using FPP for customer reports will provide you theadvantage to make use of the monitoring capabilities of SAP Solution Manager and FPP which are already inplace to monitor SAP standard reports.

1.2 Staff and Skills Requirements

To implement FPP in customer reports you need one experienced consultant with developer skills.



1.3 System Requirements

FPP is part of the SAP application basis SAP_ABA as of SAP NetWeaver release 620 or higher and cantherefore also be used for banking and non-banking applications.

The parallel processing tool is already incorporated in all mass processing reports of the Banking Servicesenvironment.

1.4 Duration and Timing

Duration and timing depend on the experience of the developer. For the first implementation, the effort will bea bit higher. After the first development was successfully done, you can implement the FPP in less than tendays per report, depending on the complexity of the report.

1.5 Examples

A demo application is delivered with FPP. It displays an example of an FPP implementation and the functionsof the callback modules. It is a fictitious application that shows the integration of FPP. It consists of thefollowing elements: Function group BANK_API_PP_DEMO contains the callback modules for the FPP events RBANK_PP_DEMO_START – Report for starting the demo application RBANK_PP_DEMO_RESTART – Report for restarting a canceled run of the demo application RBANK_PP_DEMO_GENERATE_DATA – Report for generating test data RBANK_P_DEMO_CREATE_PACKMAN – Report for creating a package administrator



2 Best Practice – Implementation Guide

This chapter provides a description of how to integrate and use the tool.

2.1 Design of Framework for Parallel Processing

The basic principle of Framework for Parallel Processing is to split up processing into individual processingsteps or events in which business or application-specific logic is run. The application prepares this logic infunction modules (“callback modules”).

From a technical point of view, each event is optional. The absence of an event does not lead to an error.Section 2.1.2 describes a suggested combination of events.

The prerequisite for the implementation of FPP is that the data to be processed is stored in the database.This does not apply for application processes that create data.

The application is identified by FPP using a unique application type, which must be entered in Customizingand transferred when the framework is started. You have to enter the relevant callback modules for theapplication type in Customizing.

To start FPP from the application, call up the function module BANK_MAP_PP_START.

You can divide processing into three areas: Preparation Parallel processes (threads / jobs) End processing

From the point of view of the main process, the parallel process runs asynchronously in batch jobs. Thismeans that: It is usually possible to transfer data to this process using database tables or persistent saves only. The callback functions assigned to this area cannot access any data that the application stored previously

in global areas.



2.1.1 Architectural Context

The following graphic shows an overview of the structure of FPP and its integration in the application.

Figure 1 Architecture

2.1.2 Events

The following overview shows the assignment of events to the three processing areas. Event 205 (in boldtype) is compulsory. The events in the middle section are executed in a loop for each package of a parallelprocess.

Preparation0205: Create Package Templates

0206: Save Param. for Packages

0100: Start Mass Run

0120: Set Appl. Parameters

0160: Checks Before Start

FPP

Application

Appl. Data

Appl.Cat.

Customizing

Process Layer

Start Report

CallbackFunction ModulesBasis Job Control

Mass Run Layer

ProcessEvents

Process Layer

ProcessData

WorklistData

Run Data



Figure 2 Events

As mentioned above, the only compulsory event is event 0205. However, parallel processing is of very littleuse without processing (event 1300 “Process Objects”). For an implementation to serve any purpose, itshould contain at least the following events: Event 0205 – Create Package Templates Event 1000 – Initialize Package Event 1100 – Selection per Range or Event 1200 – Selection for Known Object List Event 1300 – Edit Objects

Events 1100 or 1200 (selection) could also be completed at the start of event 1300. However, we recommendthat you execute them separately, so that the events can be maintained and monitored. If an application doesnot require data selection, you can leave out those events as well.

End Processing0300: End of Mass Run

0207: Delete Package Parameters

0130: Delete Appl. Parameters

Parallel Process(Jobs) 0110: Get Appl. Parameters

1400: Start Parallel Process

1000: Initialize Package

1100: Selection per Range

1200: Selection for Obj.List

1260: Check Object Locks

1270: Delete Obj. from Appl. Data

0140: Compare Parameters

1300: Process Objects

1410: End of Parallel Process

1350: End of Package



2.2 Step-by-Step Instructions

The procedure for integrating FPP consists of four steps:1. Preparation

a) Application typeb) Object typec) Package formation categoryd) Resubmission: yes / noe) (Lock procedure; see section 2.5.3 Object Locks)

2. Definition of structure for global application parameters3. Implementation of callback modules4. Implementation of start report by calling the module BANK_MAP_PP_START5. Application log handling

2.2.1 Application Type and Object Type

The definition of the application type in Customizing for FPP is an organizational activity. You have to enterthe application type, as the callback functions for the applications are created under this key (as describedabove).

You only need to assign the object type if you want to enable object list management (package formation) orresubmission.

2.2.2 Logical Definitions

The definitions described below affect the design of some callback modules. They do not necessarily containor require technical transactions; they are rather a note to the application developer to clarify the requiredprocedure before the corresponding modules are implemented.

2.2.2.1 Package Formation Category

The package formation category determines the procedure used to divide the objects to be processed intopackages.

Affected events: 0205 – Create package templates (poss. 206, 207) 1000 – Initialization of package 1100 – Selection per range 1200 – Selection for object list / resubmission

The following options exist for package formation: Range formation

- Specification of range limits from DB- Calculation of range limits

Object list

You can also use special attributes like: Specification of Range Limits from DB



If the objects cannot be divided into ranges using the calculation described above, you can divide them usingthe objects in the database or using business criteria. In this case, the range limits are specified for each casein the callback module at event 0205. The tool stores them for each package. The application module atevent 1000 then transfers the specified ranges for each package from FPP and stores them in globalvariables.

As before, the objects are retrieved from the database in the callback module at event 1100.

Calculation of range limits

In this procedure, the callback module only returns the number of packages at event 205. The range limits foreach package are defined in the callback module at event 1000, and the values are stored in the globalvariables of the application.

At event 1100, the relevant application module can then get the objects that belong to the range from thedatabase and store them in a global data area.

This procedure is used if the objects to be processed are subdivided into ranges using an algorithm.

Example: The unique key of the objects is a GUID. You can distribute the existing object keys equally acrossthe complete GUID area from 0000000000000000 to FFFFFFFFFFFFFFFF to calculate correspondingranges.

Object list

In this procedure, the objects are selected for each package according to business criteria. However, thecallback module does not transfer a range with upper and lower limits to FPP at event 0205, rather it transfersa list of specific objects. FPP stores these objects for every package in a DB table.

For this procedure, no object selection is necessary at initialization event 000.

Event 1200 is the selection event in this case. The relevant callback module of the application receives theobject list that is valid for the current package. It can then get the relevant data from the database and store itin a global data area.

This procedure is used automatically for restarted runs, as the objects are from the worklist of the first run andare already known.

Special attributes

The application may want to use attributes in addition to those described in the procedure above to constructthe worklist, i.e. to select the objects for each package.

You can do this using the export parameter E_STR_PACKPARAM in the callback module at event 0205. Theattributes are then returned to the application at event 1000.

For example, you can use a list of bank posting areas or products to further restrict a range of accounts.

For more information, see section 2.5.2.



2.2.2.2 Restart Procedure

The application must decide whether it is possible to restart canceled runs. To restart a canceled run, theapplication must flag the relevant packages, and thus the whole run, by confirming the objects to FPP withthe status “RESTART” at event 1300. Depending on how the application processes the objects, theapplication must either confirm the status of each object or flag the package by confirming a dummy objectwith the status “RESTART”. To help with the decision, you can use the following rule of thumb for therollback: The application itself executes the rollback if the package has errors, which means either all or no objects

in a package are processed No status for object The application does not execute a rollback if the package has errors, which means that the “good”

objects are in the database Individual status must be confirmed to enable restart of incorrect objects Application wants to restart the exact package (for example, with exactly the same range limits), but does

not want to confirm individual objects Confirm a dummy object

To manage the status of individual objects, you have to activate this option in Customizing for FPP.

The possible scenarios are described below:

No restart

Canceled runs are not restarted. A new start is made. The application does not need to manage any status information about the processed objects and

packages.

Normal restart

Canceled runs can be restarted. The application returns status information about each object to FPP. FPP flags individual packages that have incorrect objects as being incorrect. For restarted runs, the list of objects to be processed in each package is transferred to the application.

Restart without object status

Canceled runs can be restarted. The application returns a dummy object with the status “incorrect” for each incorrect package, so that the

package is flagged for restart. Incorrect packages can be reprocessed using your selection values, for example range limits, without

having to enter a status for each individual object. After the successful run, the dummy object must be returned with the status “completed“.

If status values are saved for each object, the change to the status of the objects should be made in the samelogical unit of work as the change to the object itself. If the application does not execute its own commits, theyare executed by FPP. This is the recommended method.

An application that needs to trigger a commit in a package first has to use the module BANK_MAP_PP_CON-FIRM_OBJECTS to confirm the status of the objects that have been processed already to FPP.



2.2.3 Global Application Parameter

If you want the application to transfer data from your start report to your callback modules using FPP withoutgoing via a database table, you can use a global application parameter. This is a data structure that istransferred to FPP when you call the FPP start module BANK_MAP_PP_START. FPP then transfers the datato the application at certain events.

Usually, the data from the selection screen of the start report is transferred in a certain structure to theapplication. Data can be criteria for package creation, such as posting area, product, or number of packages.

Below is an example of a structure for the parameters of the application Account Settlement.

Field Category Description

MASSRUN_ID BANK_DTE_MR_MASSRUN_ID Internal identification for mass runs –technical ID

SELECT_PARAMS IBKKM10 BCA: Additional parameter for callingAccount Settlement

RNG_SETTLEMENT_TYPE BCA_RNG_SETTLEMENT_TYPE Range table type for settlement type

TAB_BPARE BCA_TAB_BPARE Table type for bank posting area

TAB_PRODINT BCA_TAB_ACBAL_PROD_SEL_OPTION

Selection table for settlement ofseveral products

PRODTYPE FIPR_PRODTYPE Product category

CNT_GUID_RANGES BCA_DTE_ACBAL_CNT_GUID_RANGES

Number of packages for parallelprocessing

2.2.4 Events and Callback Modules

The following describes the five most important obligatory events. The application must provide modules forthese events.

2.2.4.1 Event 0205 – Create Package Templates

At this event, the application must specify the method for package creation (the "package template“).

Parameter Type Meaning

I_APPLCATG BANK_DTE_PP_PAAPPLCATG Application type

I_STR_PARAM Global application parameter

I_STR_PACKAGE_KEY BANK_STR_PP_PACKAGEKEY Key for package template

E_LIMIT_HIGH BANK_DTE_PP_OBJNO Upper limit for package

E_LIMIT_LOW BANK_DTE_PP_OBJNO Lower limit for package




E_TAB_OBJKEY BANK_TAB_OBJKEY Object list

E_CNT_PACKAGES BANK_DTE_PP_CNT_PACKAGES Number of packages

E_STR_PACKPARAM Special application parameters for package

E_FLG_NO_PACKAGE XFELD

E_PACKDEFCATG BANK_DTE_PP_PACKDEFCATG

NOT_FOUND Exception Package no longer exists (obsolete)

FAILED Exception Error

Implementation notes

This event is not executed for a restart. FPP calls up the module in a loop until the export parameter e_flg_no_package is set or the exception

FAILED is triggered. An exception is made for package formation category 3 (calculation of range limits),for which the module returns the number of packages and is called only once.

If the flag e_flg_no_package is set, no more packages exist. It replaces the exception NOT_FOUND,which still exists in the module interface for compatibility reasons.

The exception FAILED indicates that an error occurred during formation of the package template. You can define a package template by specifying a range, a list of correct objects, or the number of

packages (see 2.2.2.1). The relevant range limits E_LIMIT_LOW or E_LIMIT_HIGH, the object listE_TAB_OBJKEY, or the number of packages E_CNT_PACKAGES must be returned.

Enhancements

If the application requires parameters for each package template in addition to the global parameterI_STR_PARAM, they can be returned in the structure E_STR_PACKPARAM. The structure of this exportparameter must be exactly the same as the row structure of the table type in the Data Dictionary, which isdefined in Customizing for package-related application data. The structure must contain the packagetemplate key, so that it is possible to use this key to access the parameters for the package during laterprocessing. The current values for each package are contained in parameter I_STR_PACKAGE_KEY.

2.2.4.2 Event 1000 – Initialize Package

This event is the first step in processing a package of work. The application gets all the parameters that arerequired for the following processing steps – selecting, checking and processing application data.



I_PROGN BANK_DTE_PP_PROGN Name of program/report for applicationprocess

I_PROGDATE BANK_DTE_PP_PROGDATE Date of program run




I_PROGNO BANK_DTE_PP_PROGNO Sequential number of program run

I_CURRSTARTNO BANK_DTE_PP_RUNSTARTNO Current start number of mass run = number ofstarts

I_XSIMULATION BANK_DTE_PP_XSIMULRUN Simulation indicator

I_CURRSTEPNO BANK_DTE_PP_STEPNO Current step number

I_STR_PARAM Global application parameter

I_STR_PACKAGE_KEY BANK_STR_PP_PACKAGEKEY Key of package template

I_STR_PACKATTR

I_LIMIT_LOW BANK_DTE_PP_OBJNO Lower limit

I_LIMIT_HIGH BANK_DTE_PP_OBJNO Upper limit

I_XRESTART XFELD Restart run

I_FLG_ABORTED XFELD Cancellation in this package in previous start


The transferred parameters need to be stored in global data areas of the application for use at laterevents.

The indicator I_XRESTART means that the current package has been already processed once. Objectdata already exists in the application tables in the database

You can use the key I_STR_PACKAGE_KEY to access application-specific data for the package templatewhich was stored at the event Event 0205 – Create Package Templates.

The parameter I_STR_PACKATTR contains a reference to application-specific data about the packagetemplate that was stored later by FPP rather than at event 0205.

At this event, you should delete the buffers of the application that contain the data for the objects of a workpackage.

Enhancements

If there are dependencies between the objects being processed (for example, settlement of subordinateaccounts for reference accounts), processing may be executed in several steps. Each step is processed inparallel. The step number I_CURRSTEPNO is required if the processing step is to be used to select theprocessing step.

Example: Only subordinate accounts are selected from a package template in step 1, only the referenceaccounts are selected in step 2.



2.2.4.3 Event 1100 – Selection per Range

Reading data for a work package.


E_TAB_OBJKEY BANK_TAB_OBJKEY Selected objects

NOT_FOUND Exception No objects found

Implementation Notes

The selection criteria were transferred when the work package was started (event 1000) and should beavailable in the global database for the application.

The objects selected must be buffered in global data areas of the application for later processing. The selected objects can be returned in the table E_TAB_OBJKEY. They must be converted from the

application format to the format required for parallel processing. You can use the function moduleBANK_API_PPOBJ_CONV for the conversion.

2.2.4.4 Event 1200 – Selection for Known Object List

This event is run instead of event 1100 if the objects to be processed are already known. This is the case if itis a restart run, or if the objects were already specified in a previous selection, such as event 0205.


I_TAB_OBJKEY BANK_TAB_OBJKEY Selected objects

E_TAB_OBJKEY_NOT_VALID BANK_TAB_OBJKEY Invalid objects

E_TAB_OBJKEY_NEW BANK_TAB_OBJKEY New objects


The objects transferred in the table I_TAB_OBJKEY are in the format valid for FPP. They must be convertedinto the correct format if they are to be processed by the application. You can do this the function moduleBANK_API_PPOBJ_CONV.

In case of a restart, the worklist of objects to be processed may have changed. The changes must becommunicated to FPP by making entries in the two export tables. Use module BANK_API_PPOBJ_CONV toconvert the objects into FPP format. The following two changes are possible: Some of the objects selected for the first start are no longer valid and cannot or should not be processed.

The invalid objects must be returned to FPP in table E_TAB_OBJKEY_NOT_VALID. New objects have been added. Parallel processing control must be notified of the new objects using

export parameter E_TAB_OBJKEY_NEW.



2.2.4.5 Event 1300 – Edit Objects

Processing of objects specified in previous events for the current package.


E_TAB_STATUS_CHANGE BANK_TAB_PP_STATUS_CHANGE Selected objects


The processing status of the objects can be returned in export table E_TAB_STATUS_CHANGE. If you wantto run a restart, return is obligatory. The following table shows all possible status values and effects.

Value Meaning Effect

0 Selected

1 Flagged for restart Object no longer processed in this run, packageflagged for restart

2 Processing running in background

3 Processing completed successfully Object deleted from the restart worklist

4 Reset Object is reprocessed if the whole step is repeated

5 Invalid Object deleted from the restart worklist

6 Processing repeated directly The current package is repeated immediately

Note the following when setting the status values: Objects that have status “4” may sometimes lead to the whole level being reprocessed (see section 2.5.1).

The success of a restart also depends on the settings in Customizing (see below), where you can set thenumber of repeat runs that are allowed.

Objects that have status “6” lead to direct reprocessing of the whole package. You cannot enter an upperlimit for the number of runs in Customizing, which means that the package is reprocessed until no objectswith status “6” exist.

You must also set the status for successfully processed objects, else it may lead to problems whenrepeating or restarting a run.

During processing of this event, some applications must trigger Commit Work commands. To avoid inconsis-tencies in the status update, you must first confirm the status of the objects processed up to the CommitWork. To do so, call module BANK_MAP_PP_CONFIRM_OBJECTS.



2.2.5 Start Report

From the application’s point of view, the start report is the starting point of a parallel mass run. You have thefollowing options on the selection screen: Business criteria for package formation and data selection Technical information for control of FPP

Start FPP by calling function module BANK_MAP_PP_START (for interface, see section 0).

Important: The current version of FPP predefines that an application log object is opened in the start reportwith the functions of the message class EMSG (package BMESSAGE). Also, the error messages that weretriggered before the start of parallel processing are output directly or written to the job log, which can lead toimmediate cancellation without the application retaking control. FPP opens a log object in each of the parallelprocesses.

2.2.6 Application Log Handling

FPP uses the standard application log to log errors by message class. The components are found in thefunction group EMSG of package BMESSAGE. The log must differentiate between the areas of preparationand parallel processes.

The parallel processes are run in batch jobs started by FPP. FPP serves as a channel and creates logobjects at this event. When BANK_MAP_PP_START is called, the application can transfer one or more logobjects, which can be opened in the corresponding sequence. If nothing is transferred, FPP opens log objectsFS_EXC and FS_PROT. This means that there are two logs for each parallel process in the application log.

The system writes any error messages that were issued before parallel processing to the application log withthe functions of the message class. This also triggers a MESSAGE … RAISING command. As FPP does notserve as a channel at this point, it does not open a log but waits for the application to do so. If no open logexists, the messages are output. If processing runs in the background, then the job is canceled.

Important: The application must open at least one log object using the message class (function groupEMSG) before the start module BANK_MAP_PP_START is called. Therefore, in order to save messages atthe end of the process in event 1410, you need to create one log object in event 1400 before calling moduleBANK_MAP_PP_START since there is no input parameter for class CL_BANK_PP_STANDARD_LOGGERavailable.

For an example of the creation of log objects, see the routine init_messages in the start reportRBANK_PP_DEMO_START, in which the module MSG_OPEN creates two logs.

From the FPP perspective it is natural and wanted to create as many logs as there are processes so that anyprocess can be identified and analyzed in detail.

You can write application log records with the following function modules:APPL_LOG_WRITE_HEADER: With this function module, you write the log header data in local memory.APPL_LOG_WRITE_LOG_PARAMETERS: With this function module, you write the name of the logparameters and the associated values for the specified object or sub-object in local memory. If thisfunction module is called repeatedly for the same object or sub-object, the existing parameters areupdated accordingly. If you do not specify an object or sub-object with the call, the most recently used isassumed.



APPL_LOG_WRITE_MESSAGES: With this function module, you write one or more messages, withoutparameters, in local memory.APPL_LOG_WRITE_SINGLE_MESSAGE: With this function module you write a single message, withoutparameters, in local memory. If no header entry has yet been written for the object or sub-object, it iscreated. If you do not specify an object or sub-object with the call, the most recently used is assumed.APPL_LOG_WRITE_MESSAGE_PARAMS: With this function module you write a single message, withparameters, in local memory. Besides this it works like APPL_LOG_WRITE_SINGLE_MESSAGE.APPL_LOG_SET_OBJECT: With this function module, you create a new object or sub-object for writing inlocal memory. With a flag you can control whether the APPL_LOG_WRITE_... messages are written inlocal memory or are output on the screen.APPL_LOG_INIT: This function module checks whether the specified object or sub-object exists, anddeletes all existing associated data in local memory.APPL_LOG_WRITE_DB: With this function module, you write all data for the specified object or sub-object in local memory to the database. If the log for the object or sub-object in question is new, the lognumber is returned to the calling program.

2.2.7 Job Log Message Handling

For optimal performance of the mass processing reports, ensure that the same information is not written tothe job log and the application log. The following chapter describes in detail how you can suppress job logmessages if the same information is already available in the application log or if it is unnecessary.

Use function BP_SET_MSG_HANDLING to suppress writing all application log messages to the job log andavoid unnecessary performance overhead, since the data is already contained in the application logs. Thefunction should be called twice, once before the main processing to set the flag for suppressing job log writingand then one more time after the main processing to set it back.

Before main processing in event 1400 – Start of Processing in a Parallel Job:

CALL FUNCTION 'BP_SET_MSG_HANDLING' EXPORTING HANDLINGTYPE = BTC_SUPPRESS_MSGS_ON_HANDLER EXCEPTIONS INVALID_HANDLINGTYPE = 1 SETTING_FAILED = 2 OTHERS = 3.

After main processing in event 1410 – End of Processing in a Parallel Job:

CALL FUNCTION 'BP_SET_MSG_HANDLING' EXPORTING HANDLINGTYPE = BTC_SHOW_MSGS_ON_HANDLER EXCEPTIONS INVALID_HANDLINGTYPE = 1 SETTING_FAILED = 2 OTHERS = 3.



2.2.8 Collection of Statistical Information at the End of a Mass Run

All processes within FPP run in independent roll areas and do not share any memory. Therefore the resultsand other statistical information received from every executed process cannot be stored in the buffer. Theresults of the mass run should be stored on DB level and then collected after the mass run.

Here are just a few examples of the information that may need to be accumulated in the buffer/memory whileexecuting the multiple processors. Record count: Number of records processed within the file or process Average balance/total balance – for the accounts within the process Write-off amount: If an account contains a write-off amount, this value is summarized and at the end of the

program, posted to a relevant account. The reason for excluding the account from the processing needs to be stored on a custom table or in the

application log to produce a further report.

Statistical information of the mass run like counters for number of processed objects or number of objectsprocessed successfully must be recorded in DB table BANK_MR_LINE_CNT with the following structure:

massrun_id: Identifiercounter_catg: Counter categories like ACCSUCC (accounts processed successfully) or ACCDUE (totalnumber of accounts due), etc.addkey: Additional identifier, for instance, the job numbercounter: Number of objects

Note: To avoid waiting situations in parallel processing there is an additional key ADDKEY in tableBANK_MR_LINE_CNT, which is filled with the number that is assigned to the ABAP work process. If the jobnumber is used as an additional key, either a new entry for the first package of that job should be inserted, orthe existing entry should be updated by adding the counter values to the previous ones. This data must berecorded at the end of each package, so a good place to insert the counters would be the end of the 1300function module.

Note: The counter information will also be shown in the mass activity monitor (MassMan) and can be used forbusiness process monitoring in SAP Solution Manager (accounts processed successfully)

Implementation

First, the external ID of the run is needed. It can be found in DB table BANK_PP_PARUNHD, using the fieldsPROGN, PROGNO and PROGDATE variables as keys (provided in the function module 1000).

Then, the massrun_id that corresponds to the actual run needs to be determined. To do that, the functionmodule BANK_OBJ_MR_START needs to be called before parallelization. Function module 100 might be agood place. This function module needs three parameters: i_application_identification: Application type i_runid_ext: External ID that is mentioned above i_vb_mode: Must be ' ' (space)

The module will return the massrun_id needed to record the counters. It should be stored somewhere in theglobal memory (not in method 100 since it is not part of the parallel process, so the massrun_id will not bevisible in other jobs (and other application servers) because each job has its own global memory), so that it isavailable in the 1300 function.



The massrun_id should be stored in the global parameter structure (e_str_newparam), and then moved backto the global memory in method 1000 or any method triggered by a parallel job.

To declare new counters, with the appropriate description text, transaction BANK_CUS_MR_CNTCG shouldbe used. The assignment of new counters to the appropriate application type will be done in transactionBANK_CUS_MR_APCNT. New counter categories are not mandatory; the existing counters can be used.

In event 1300, the counters should be inserted in the database at the end of the package processing.

Another example is the program RBCA_BSPRPR_RUN_PP where the results are stored at event 1300 (EditObjects) to the table BCA_GLARCH_LOV, and at event 0300 (End of the Mass Run) the data is read fromthis table to be printed. So the abortions and restart information can be handled.

Event 0300 - End of the Mass Run does not have an importing parameter for the package ID (typeBANK_STR_PP_PACKAGEKEY). To get the package ID, function module BANK_MAP_PP_GET_STATUSshould be called in event 0300 with import parameters: I_PROGN = BANK_DTE_PP_PROGN

I_PROGDATE = BANK_DTE_PP_PROGNO I_PROGNO = BANK_DTE_PP_PROGDATE

I_FLG_CHECK_ACTIVE_RUNS X Delete X (Set to FALSE)

In export parameter E_STR_DETAILS, click on BANK_STR_PP_RUNDETAILS in structure STR_RUNDATA.The field CURRPACKMANID is equal to the package ID (type BANK_STR_PP_PACKAGEKEY).

2.3 Configuration (Customizing)

Customizing for FPP consists of three parts: System settings – Events and interfaces (can be changed only by those responsible for FPP) Application developers – Event modules and technical settings for application type User – Customer settings for FPP behavior

Application for customers

For customizing settings use transaction BANK_CUS_PPC, where customers can enter their own applicationtypes and relevant methods.

You can make the following entries:Application type and dependent entries- Callback modules for the events- Reason for lock (should not be used anymore)- Technical settings- Supported lock owner sessionsObject type with conversion modules

The technical settings have the following meanings:“All objects persistent” forces the save of all selected objects to the DB, including those that have “initial”status.

The value entered for “% postponed” defines the highest permitted share of objects that can be postponedin relation to the total number of objects still to be processed.

The “number of repeat runs” defines how many times a step can be repeated for postponed objects



“Application for BTE” – FPP enables you to use business transaction event 0BANK010 to control packageformation. You must enter the application that is entered for the business transaction event into tableTPS34.

The value entered for the “number of sequential repeat runs” defines whether additional runs are to bemade in a sequential session once the “number of repeat runs” has been reached. If so, a batch job iscreated for processing.

Customers can make settings for their own applications as well as for SAP applications. If both, SAP andcustomer settings are made for a value, FPP decides which setting has precedence as follows:- “All objects persistent” – Set indicator has precedence- “% postponed” – Minimum has precedence- “Number of repeat runs” – Maximum has precedence- “Application for BTE” – Only customer setting is relevant- “Number of sequential repeat runs” – Maximum has precedence

IMG or SM30/V_TBANK_PP_DISTR – define job distribution for each application You can define the level of parallelization (the number of parallel jobs per run) for each application. The

default value is one job per run.

Supported lock owner sessions are used to define the lock procedure. You can enter the following values foreach application: Lock by application only – the owner of the locked object is the application (type), other runs of the same

application can process the objects. This is the recommended procedure. Lock by mass run only – the owner of the locked objects is the relevant run, only this run can process the

objects No locks

Relevant locks for other application types For each application type, the customer can define which other application types can prevent the start if

canceled or active runs exist.

The first two points are described in detail in the previous section. Note the following when entering relevantlocks for other application types: If nothing is entered for an application, all applications are relevant. The setting only affects applications that call these other application types during the start checks.

Unfortunately, it is currently not possible to identify these applications in Customizing.

This transaction is also used to maintain the entries for the events and the relevant interface parameters. Thisis done by the developers responsible for FPP.

A similar transaction BANK_CUS_PP exists for SAP standard application types.



2.4 Enhancement Options

Business transaction events (BTE)

0BANK010 – Create Work Packages- Customers can implement this BTE to replace the standard routine for forming work packages with

their own logic. This is useful if the customer wants to divide objects into packages using criteria notcontained in the SAP standard.

0BANK011 – Specify Job Distribution- Customers can implement this BTE to overwrite the parallel job distribution executed by FPP and to

specify the server and server groups for scheduling the jobs.

2.5 Complex Scenarios

2.5.1 Multi-Step Processing

Some applications need to process their objects in two or three steps. In Account Settlement for banking, forexample, the subordinate accounts are processed in the first step. The settlement results from this first stepare then accessible for the settlement of the higher-level accounts, which is executed in a second step.

The application uses parameter I_MAX_STEPNO when calling the start module BANK_MAP_PP_START tonotify FPP of the number of steps that are to be processed.

As it is not possible to define a callback module for every step, multi-step processing is a repeat call of theapplication by specifying the current step number. The application must then separate the processing of eachstep in its modules.

Processing of a new step is essentially the same as starting a new run, as new parallel processes are formedand executed in relevant batch jobs.

Event 100 and the final processing events 300, 130 and 207 are run once per run only, rather than once perstep.

2.5.2 Special Parameters for Package Formation

In addition to normal package formation, it is also possible to use additional parameters to define specialattribute values for each package. You can save these parameters either in your own database table or usingFPP.

The procedure is as follows: Create a structure in DDIC that contains the additional attributes. The key of the structure must contain the

package key to make it possible to read the attributes of each package later. To do this, you can includethe structure BANK_STR_PP_PACKAGEKEY.

Create a relevant table type in DDIC. Enter the table type in FPP Customizing for the application type: BANK_CUS_PPC Application Type

Parameter Type. At event 0205, transfer the created structure with the relevant attribute values in export parameter

E_STR_PACKPARAM to FPP for each package. At event 1000, FPP transfers the relevant parameters for each package to the application.



2.5.3 Object Locks – Dependencies Between Application Types

This topic deals with the interaction of different mass runs when errors and cancellations occur for both,different runs of the same application type and different runs of different application types.

The use of object locks should ensure that the processing of objects by one run must be completed beforethey can be processed by subsequent or dependent runs. To make this possible for several runs or differentapplication types, you must make some cross-application settings: Which application types depend on each other?

- Which application type sets locks?- Which application type reads locks?

Which objects are locked?

You can define the application types on which each application type depends either in Customizing or intransaction BANK_PP_APPLREL (maintenance view V_TBANK_APPLREL).

Note: If you enter the dependencies in Customizing, it does not mean that the check is saved automatically.You must do this for each application type.

See the following scenario for an example: A banking component has three applications: Mass run accountsettlement, bank statement and account closure. The master object for account settlement and bankstatement is the account. The corresponding order is the master object for account closure, but it alsoprocesses accounts. Both, the bank statement and the account closure cannot process the account untilaccount settlement has been completed successfully. Account settlement must set locks, lock object is the account. Bank statement and account closure must read locks. Enter account settlement as relevant for statement and closure in the V_TBANK_PP_APPLREL view.

Note: Interaction only works if the application types refer to the same lock object.

In the above example, settlement sets account locks, so the account closure must read account locks eventhough its master object is the order.

The locks are set and deleted in the logical unit of work in which the relevant objects are processed, in thecallback module of event 1300.

2.5.3.1 Set Locks – BANK_MAP_PP_LOCKS_SET

Name Type Meaning Opt.

I_PROGN BANK_DTE_PP_PROGN Mass run key, field 1 X

I_PROGDATE BANK_DTE_PP_PROGDATE Mass run key, field 2 X

I_PROGNO BANK_DTE_PP_PROGNO Mass run key, field 3 X

I_APPLCATG BANK_DTE_PP_PAAPPLCATG Force new run X

I_TAB_LOCKS BANK_TAB_PP_LOCK Object list

INTERNAL_ERROR Exception



2.5.3.2 Read Locks – BANK_MAP_PP_LOCKS_GET_MLT

This module gets locks for the relevant application types.


I_OBJCATG BANK_DTE_PP_OBJCATG Object type in parallelprocessing (key)

X

I_OBJNO BANK_DTE_PP_OBJNO Number of object inparallel processing(key)

X

I_TAB_OBJECTS BANK_TAB_OBJKEY Object key X

I_TAB_RNG_RELEV_APPL BANK_TAB_RNG_APPLCATG Area of applicationtypes to be checked

X

I_FLG_EXCL_CURR_RUN XFELD Indicator: Ignore entriesfor current run

X

I_STR_CURR_RUN BANK_STR_RUNKEY ID of current mass run X

I_CURR_APPLCATG BANK_DTE_PP_PAAPPLCATG Application type inparallel processing

X

I_FLG_IGNORE_SUCCEEDING_LOCKS

XFELD Indicator: Ignoresubsequent locks

X

I_MAXCOUNT BANK_DTE_PP_MAXCOUNT Maximum number ofdata records to be read

X

I_FLG_IGNORE_LOCKEDBY

XFELD No check of lock owner X

E_TAB_LOCKED BANK_TAB_PP_LOCK Object locks

E_TAB_LOCKING_RUNS BANK_TAB_PP_RUNKEY_APPL Runs that cause locks

E_TAB_OWN_LOCKS BANK_TAB_PP_LOCK Object locks

E_RCD SY-SUBRC =1: Selection limitreached

CURR_RUN_NOT_QUALIFIED

Exception


The parameter I_FLG_EXCL_CURR_RUN defines that the locks set by own runs or application types are tobe ignored. They are returned in E_TAB_LOCKED rather than in E_TAB_OWN_LOCKS.

The parameter I_FLG_IGNORE_SUCCEEDING_LOCKS defines whether locks from other runs are to betaken into account if they were set after the last lock set by your own run.



2.5.3.3 Delete Locks – BANK_MAP_PP_LOCKS_RELEASE




I_PROGNO BANK_DTE_PP_PROGNO Mass run key, field 3 X

I_APPLCATG BANK_DTE_PP_PAAPPLCATG Force new run X

I_TAB_TO_RELEASE BANK_TAB_OBJKEY Object key

I_TAB_LOCKS_TO_REL BANK_TAB_PP_LOCK Object locks


Table I_TAB_LOCKS_TO_REL contains locked objects whose locks are to be deleted. Table I_TAB_TO_RELEASE can contain locking objects. If table I_TAB_LOCKS_TO_REL does not

contain entries, then all the locks that were caused by the objects contained are deleted. If no table contains entries, all locks of the specified mass run are deleted.

2.6 Job Distribution

Job distribution groups together two connected issues or processes in FPP: Degree of parallelization (number of parallel processes to be created) Distribution of processes to batch jobs/server

2.6.1 Degree of Parallelization

FPP creates a process for every application type. To define the degree of parallelization for each applicationtype or run, you have the following options: Entry in Customizing or maintenance view (see section Fehler! Verweisquelle konnte nicht gefunden

werden. ) Transfer as parameter at start Implementation of BTE 0BANK011 (see section )

To transfer the desired job distribution when you call FPP, specify the parameter I_TAB_JOBDIST of typeBANK_TAB_GRP_SRV. The fields of the corresponding structure type are shown in the following table.

Field Type Description

SERVERGROUP RZLLI_APCL Name of logon/server group

SERVER BANK_DTE_JC_SERVERNAME Name of application server

CNT_JOBS BANK_DTE_CNTJOBS Number of background jobs

See the next section for a description of the fields and the distribution procedure.



2.6.2 Distribution

The distribution of the required jobs is executed in several steps. Internal distribution is executed using atable that has the format described above, irrespective of the definition method. Entries exist with server name Desired number of jobs scheduled on this server Entries with server group Distribution of corresponding number of jobs to server in this group Entries with number only Distribution to desired number of available servers

During distribution, the system checks whether the server is active, whether batch processes exist on therelevant server, and whether free processes exist.

Job distribution in the current system

FPP cannot hand over job distribution (also known as load balancing) to SAP Job Control at the start event ofthe processes but it must execute job distribution itself at an earlier stage. This is necessary for the initialassignment of work packages to specific servers – when the packages are created, the servers for eachprocess must already be known. Sometimes this means that no free batch processes are available on one ormore of the planned servers when the processes are due to start.

In any case, you must check whether parallel processes can be corrected if necessary.

2.7 Monitoring of FPP Enabled Reports

To monitor all FPP-enabled reports, the MassMan monitor would be the most suitable solution.

Figure 3 MassMan monitor

2.7.1 MassMan in Satellite System and Central System

In satellite system and central system, MassMan can be started in transaction code ST13. ST13 is acollection of different SAP analysis and service tools that are delivered by the ST/API add-on. From the list ofavailable tools choose MASS_MAN_MONITORING and execute. MassMan can either be executed on thebanking system or can use preconfigured RFC connections to load mass runs from target systems into acentral monitoring system like SAP Solution Manager.



2.7.2 MassMan – Start Screen

The next figure shows the start screen of MassMan. On top of the screen are command buttons, lower part isselection conditions.

Figure 4 MassMan – Start screen

Different conditions can be set to choose the relevant mass runs. With the selection criteria Appl. Catg. on theselection screen the customer can especially search for the customer defined application category possiblystarting with Z*.

2.7.3 MassMan – Displayed Information

Choose the Execute button from the MassMan start screen and all mass runs that satisfy the selectionconditions are listed.

Figure 5 MassMan – Mass run detail view



See the following table for the meaning of the columns of the mass run detail view.

Columns Description

Sys/Clt System ID and client where the mass run is executed

Hist If selected, the mass run is stored in MassMan history table, otherwise from FPP table.

Jobname If field is empty, it is started in dialog mode, otherwise as background job.

Application SAP-predefined application type for the mass run.

Description Job description

Ext. Runid External run ID, can be specified by the customer to identify different mass runs

Status Different status of the mass run (R: Running, F: Finished, A: Aborted, P: Processing)

Startdate,Starttime,Endtime

These three fields are the time stamp to specify when the mass run is started and finished. It isthe time window that FPP is called. It is a subset of job start time and finish time from SM37.

%ready Percentage of the progress

est. remDuration

Estimated remaining time that the mass run still needs to run before it finishes

est. Durat. Estimated total run time for the mass run. When the mass run is finished, it is set to 0.

Duration Real run time that the mass run needs

Counter Number of selected objects for the mass run, if available

Throughput Estimated number of processed objects per hour

Jobs Total number of started jobs for the mass run (parent job + child jobs)

Act Number of currently active jobs

Compl. Number of currently completed jobs

Can. Number of canceled jobs

APPL Average CPU usage (per hour) from the time the mass run is running

DB Average DB usage (per hour) from the time the mass run is running



3 Further Information

3.1 Documentation of Central Interfaces

BANK_MAP_PP_START




I_RUNID_EXT BANK_DTE_PP_RUNID_EXT External ID of mass run X

I_FLG_FORCE_NEW_RUN XFELD Force new run X

I_FLG_UNIQUE_EXTID XFELD Check external ID is unique X


I_PACKMAN_ID BANK_DTE_PP_PMID_EXT Key of (standard) packageformation to be used

X

I_TAS_PACKCR_PARAM BKPP_TAS_PP_PACKCR_PARAM_EXT

Parameters for packageformation

I_XSIMULRUN BANK_DTE_PP_XSIMULRUN Indicator: Simulation run X

I_MAXSTEPNO BANK_DTE_PP_STEPNO Maximum number of parallelprocessing steps

X

I_STR_APPL_PARAM Application parameters X

I_STR_PRINT PRI_PARAMS Print parameters X

I_XLOG XFELD Indicator: Do not createapplication log

X

I_LOGEXTNUMBER BALNREXT External ID for application log X

I_TAB_LOG BANK_TAB_JC_APPL_LOG_DATA

Data for opening messageobjects in a process

X

I_X_SYNC XFELD Indicator: Synchronous call up X

I_X_USE_DIALOG_WP XFELD Indicator: No backgroundprocessing

X

I_X_TRIGGER_START_BY_COMMIT

XFELD Indicator: Trigger start of PPby COMMIT WORK

X

I_TAB_JOBDIST BANK_TAB_GRP_SRV Jobs per server group andserver

X




E_STR_RUNKEY BANK_STR_RUNKEY Key of mass run

E_RUNSTATUS BANK_DTE_PP_RUNSTATUS Status of mass run

E_RCD_APPL SY-SUBRC Return code of application

E_TAB_LOGH BAL_T_LOGH List of handles for applicationlogs

E_LOGEXTNUM BALNREXT External ID of application logs

E_TAB_JOBS BANK_TAB_JC_JOBKEY List of generated backgroundjobs

NO_OUT_OF_SYNC Exception

NO_EXPORT_ALLOWED Exception

PACKMAN_INVALID Exception

PREPARE_FAILED Exception

START_FAILED Exception

Information on individual parameters: The parameters I_PROGN, I_PROGDATE are obsolete.

I_RUNID_EXTI_FLG_FORCE_NEW_RUNI_FLG_UNIQUE_EXTIDI_APPLCATG: Application typeI_PACKMAN_ID: ID of existing package division to be used by the new mass run that is to be started.I_XSIMULRUN: Mass run executed as simulation. It is not possible to restart runs that are started in thismode.I_MAXSTEPNO: Number of parallel processing stepsI_STR_APPLPARAM: This parameter contains the global application parameters.I_STR_PRINT: Print parameters. If no parameters are entered, then the system applies the print settingsof the user who called up the function module.I_XLOG: Indicator that FPP should create an application log (for each parallel job). You must specify theobject and sub-object of the application log in Customizing of the application type, or enter the settings forthe creation of message object in table I_TAB_LOG.I_LOGEXTNUMBER: You can enter an external ID for the application log generated by the FPP tool. Thisparameter is obsolete. You should enter the log data in table I_TAB_LOG.I_TAB_LOG: List of message objects to be created.I_X_SYNC: If the Start function module is run from a report that is part of a job net in the area IBSFinancial Services, you must set this indicator, because the feedback is run synchronously.I_X_USE_DIALOG_WP: If you set this parameter, no background jobs are started, rather processing iscarried out in a sequential dialog work process. This mode should only be used for debugging.



I_X_TRIGGER_START_BY_COMMIT: Use this indicator to control whether parallel processing is to betriggered by a Commit Work (’X’) or not (SPACE). If you call a function module using a BAPI, then aCommit Work is used. Parallel processing is not started by the BAPI, rather all database entries forprocessing control are marked in the update task. Call function module API_TRANSACTION_COMMIT totrigger the writing of data to the database. To start the run, call the BANK_MAP_PP_START_TRIGGERMAPI module.I_TAB_JOBDISTE_STR_RUNKEY: Key used to identify the new mass run.E_RUNSTATUS, E_RCD_APPL: (Technical) run status and return code of the application at the end ofparallel processing. You cannot request these parameters for asynchronous runs (I_X_SYNC=’X’)(Exception: O_EXPORT_ALLOWED).

3.2 Debugging

As FPP uses batch jobs for the processing of parallel processes, debugging is possible at the start of this jobonly. If you want to analyze processing for each process, there are two possible options.

3.2.1 Synchronous Start in Dialog Mode

Procedure: Set the flags I_X_SYNC and I_X_USE_DIALOG_WP when you call BANK_MAP_PP_START. FPP does not create jobs. The processes/packages are processed sequentially in dialog mode.

3.2.2 Parameters BANK_JC_DBG_MODE in the User Data (from release 6.40)

Possible values: DBG_OFF DBG_DIA DBG_BTC DBG_BTC_DIA

Prerequisites: DEBUG authorization and change authorization in debugger

If DBG_BTC is set, an endless loop is run in the reports RBANK_PROC_START and RBANK_PROC_END(start of parallel job), which makes it possible to capture each job or process in the process overview SM50.You can then set extra stop points in the debugger.

To end the endless loop and run the report as “normal”, you must set the l_flg_exit flag to ‘X’ in the debugger.

Warning about debug mode: If the flag is set, an endless loop is run in every parallel job and in everyrelated end job and must be ended by setting the flag in the debugger. Therefore, you must ensure that youdo not set a high degree of parallelization in job distribution.

3.3 BANK_PP_SETTINGS

Transaction BANK_PP_SETTINGS is used to set special parameters for FPP. At the moment, one parameteris available: Indicator whether the process data is to be deleted automatically after the current process.



3.4 Repeat – Retry – Restart

This section defines the terms Repeat, Retry and Restart.

3.4.1 Repeat – Repetition of a Package

This term refers to an immediate repetition of a package in the processing loop for the packages. As soon asthe package is finished, it is reprocessed by the application in the parallel job.

One possible use is for a temporary lock of one or more objects, by dialog locks for example. It is hoped thatthe lock will be set for a short time only and that the package will be reprocessed immediately. From method1300, the application returns the affected objects (with status “6”) to FPP. As described above, the applicationmust cancel the repeat runs. The next package can be processed as soon as no object has status “6”. Theapplication can incorporate this function using a repeat loop in the module for event 1300.

3.4.2 Retry – Repetition of Whole Step

This term refers to a repetition of a whole step in the current mass run. The objectives are the same as beforebut note that you can remove all the object locks in the time required to stop and restart the whole step.

The application triggers the repeat by returning objects with status “4”. The exact procedure of FPP isaffected by the settings made in Customizing (see section 2.3).

You must note the following when using this procedure: Reprocessing the whole step can lead to a lot of lost time because all parallel processes must be

restarted, starting from the original job distribution. As it is not possible at the moment to form packages of objects that are still open, it can occur that more

parallel processes are run than are required. This can block other applications. If you enter the maximum number of repeats in Customizing and the number is too high, it can lead to

extremely long runtimes.

3.4.3 Restart

This term refers to restart of a canceled mass run. The procedure is not described here.

3.5 Tools for Developer Support

Generation of module holders

You can use the report RBANK_PP_GENERATE_APPL to generate the relevant callback modules for allevents. Create interfaces using the information in Developer Customizing.

Note the following: Before you start the report, you must create a function group for storage of the generated modules. You

must specify this group on the selection screen of the report. The report generates modules for all existing events. You must delete all the modules that are not

required by the relevant application and remove the corresponding entry in Developer Customizing. The Customer Application flag defines whether the application type and modules are to be entered in the

table of customer application types.



3.6 Glossary

English Term EnglishAbbrev.

GermanTerm

GermanAbbrev.

Definition

Application Anwendung In this document, it means the user of FPP.

Application type Anwendungs-art

The application type identifies an applicationthat is using FPP

End-of-Dayprocessing

Tagesende-verarbeitung

TEV Identifies programs or processes that:

Process mass data Run in batches Run at the end of a posting day

Framework forParallelProcessing

FPP Parallelisie-rungsframe-work

Name of the tool described here; synonymsare parallelization or parallel processing

Resub-mission

Restart of a mass run that was canceled orhad individual (business) errors



Index of FiguresFigure 1 Architecture 7Figure 2 Events 8Figure 3 MassMan monitor 26Figure 4 MassMan – Start screen 27Figure 5 MassMan – Mass run detail view 27

© Copyright 2007 SAP AG. All Rights ReservedNo 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, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries,zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, and Informix are trademarks or registered trademarks of IBMCorporation.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 CitrixSystems, Inc.HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, MassachusettsInstitute 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 byNetscape.MaxDB is a trademark of MySQL AB, Sweden.SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as theirrespective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. Allother product and service names mentioned are the trademarks of their respective companies. Data contained in this document servesinformational 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 formor 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 documentcontains only intended strategies, developments, and functionalities of the SAP® product and is not intended to be binding upon SAP toany particular course of business, product strategy, and/or development. Please note that this document is subject to change and maybe 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 theinformation, 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 thatmay 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 mayaccess through the use of hot links contained in these materials and does not endorse your use of third-party Web pages nor provide anywarranty whatsoever relating to third-party Web pages.

framework for parallel processing for customer reports

Documents