SAP for Banking Blogs
Read and write blog posts showcasing innovative banking solutions and success stories powered by SAP. Discover cutting-edge insights and practical tips.
cancel
Showing results for 
Search instead for 
Did you mean: 
former_member195421
Participant

Hi All,

In this blog, I am explaining about the mass run program based on parallel processing framework . To solve one of the customer issues , I have been asked to debug through the payment distribution program and started to debug the transaction with out the knowing the architecture of parallel processing framework .

After some point I learned about parallel processing framework and thought of sharing the leanings which may help others to create own programs based on parallel processing framework and debug the existing standard transactions .


Component : Banking services (FSAPPL 400)

Screen shots : Payment distribution .


Overview

In transaction banking Parallel processing framework implementation is in the function group BCA_AM_BASIS_PP_CB and is reused by all applications. For a new application type, these function modules are stored in the “interface” definition of the Parallel processing framework (transaction BANK_CUS_PP). This one-time implementation achieves standard, secure communication with the Parallel processing framework.

From this “Interface” (often abbreviated to “PP Interface”), communication with the actual application takes place through the interface IF_AM_PP_PACKAGE. All of the application coding is found in one class that implements the interface. This enables easy communication with parallel processing through different channels (report in dialog or batch modes, BAPI or MAPI). There is no coding in the report itself, only the interface definition. A field control class (CL_AM_PP_FIELD_CONTROL) transports the data to a parameter structure in accordance with the Customizing settings. The application only recognizes this parameter structure in the implementation. The central report control for the different channels transfers a job control class (CL_AM_PP_JOB_CONTROL).

Preparations for a New Application Type


The following shows the individual steps to an executable version.

  • Creation PP Framework Customizing (transaction BANK_CUS_PP)
  • Creation of PP-IF class (copy of template class CL_AM_PP_PACKAGE_TEMPLATE)

The customizing for the PP-IF in tables BCA_AM_BASIS_PPF and BCA_AM_BASIS_PPA must be created manually. Also you have to create your report manually.


  • Create the Parameter Structure


This step can be omitted if the data from the common parameter structure BCA_STR_AM_BASIS_PP_PARAM is sufficient for your application. If not, create your own parameter structure and always include the TECH area of the general structure. If required, you can also include other areas from the general structure. You then add your own areas (always as a substructure). You can use the parameter structure /FSPD/STR_IPD_PP_PARAM from payment distribution as an example.

Default Structure: BCA_STR_AM_BASIS_PP_PARAM

User defined structure: /FSPD/STR_IPD_PP_PARAM

  • Register the Application Type in the PPF


The new application type is defined (naming convention: BCA_...) in the PPF-IMG (transaction code BANK_CUS_PP). In the header, you store the parameter structure used, a name for the application, the log object FS_PROT, and the object status indicator if the application is to keep object lists for a reset.

You store the following modules as methods:

0100       Start of mass run                                                                      BCA_AM_BASIS_PP_CB_0100

0140       Compare parameter records                                                       BCA_AM_BASIS_PP_CB_0140

0160       Checks before the start of a mass run                                        BCA_AM_BASIS_PP_CB_0160

0205       Generate package templates                                                     BCA_AM_BASIS_PP_CB_0205

0300       At the end of the mass run                                                        BCA_AM_BASIS_PP_CB_0300

1000       Initialize a work package                                                           BCA_AM_BASIS_PP_CB_1000

1100       Select application data per interval                                             BCA_AM_BASIS_PP_CB_1100

1200       Re select application data at reset                                             BCA_AM_BASIS_PP_CB_1200

1260       Check if objects are locked                                                       BCA_AM_BASIS_PP_CB_1260

1270       Delete invalid objects from application data                                BCA_AM_BASIS_PP_CB_1270

1300       Process objects                                                                       BCA_AM_BASIS_PP_CB_1300

1350       End of task processing                                                             BCA_AM_BASIS_PP_CB_1350

1400       Start of processing in a parallel job                                            BCA_AM_BASIS_PP_CB_1400

1410       End of processing in a parallel job                                             BCA_AM_BASIS_PP_CB_1410

You need to enter the lock owner modes that are supported (if locks are supported).

(You can also copy an existing BCA application.)

  • Create Class for Interface Implementation


Here you copy the template class CL_AM_PP_PACKAGE_TEST to the class CL_AM_PP_PACKAGE_ApplicationType (with your own application type). The class must be in a package in the application.

If your class name doesn’t following the naming convention then you have to set the class name in the variable g_str_param-tech-classname in the report.

(If you have defined your own application structure, you add a static attribute to this structure (such as S_STR_PARAM) in the class, and remove the comment in the corresponding MOVE in the method SET_APPLICATION_DATA. The lines of the default application structure S_APPL_PARAM can have comments, and the alias for the structure can be removed for security, to avoid confusion.)

The comments in the methods can be removed at the end.

Example: /FSPD/CL_PDI_PP_PACKAGE_RUN (For Payment distribution), since in payment distribution we have own application structure added static attribute S_STR_PARAM

  • Create the Report


The report and the class are in the package of the application.

With the default application structure, the report appears as follows:

  • System Customizing Settings

(a) Include your own structure in the field catalog

For user defined parameter structure, the individual parts (that are not part of the default parameter structure) need to be included in the field catalog. To do this, enter all fields in table BCA_AM_BASIS_PPF using transaction SM30. You need to specify the subarea, each individual field (for deep structures with “-”), the application type, the tab page (such as DETA010), the parameter name on the screen, and a Modif ID. Ideally, each field on the parameter screen has its own Modif ID. This should begin with “X” to avoid conflicts with the default parameters. Finally, you need to restrict the selection options using parameters with the corresponding indicator. All other indicators are special cases and not usually required.

(b) Select fields required for the application (also for default parameter structure)

For each application (including those with default parameters) you need to store which fields are used and how they are handled. All fields required for an application can be included in the table BCA_AM_BASIS_PPA. These are then provided with the data from the screen and transported back if necessary. You can also specify:

Whether the field is a required entry field (the check is also made at batch and MAPI start)

Whether the field is included for display only and provided with info data from the application (such as last posting date)

Whether the field can be changed if a mass run is reset If not, the field is set to “cannot be changed” and automatically provided with data from the original run. (This setting is only necessary if the “reset mass run” function is used.)

Whether the field is ready for input in a separate start with an external package template If not, the field is set to “cannot be changed” and automatically provided with data from the package formation run. (This setting is only necessary if the system supports the separation of the package formation run and package start.)

Whether the field is to have a default value other than initial (for example, execution date TECH-EXECDATE)

Whether the field is ready for input when forming an external package administrator (only necessary if external package formation is supported)

If you have made all of these settings, the report can be run and you can start to implement the class. For testing and debugging, you can switch to dialog processing using OK code BCADEBUG.


Important Methods in PP interface 


  • Checks on the Selection Screen (CHECKS_AT_SELECTION_SCREEN):


You usually start by checking or adding to the data supplied (c_appl_param or c_str_gen_param) in the method CHECKS_AT_SELECTION_SCREEN. If there is incorrect data, a message is displayed with the affix ‘RAISING ERROR_IN_SEL_DATA’. A simple error message without an exception is not permitted. Information messages need to be omitted as much as possible, otherwise there might be problems in a later BAPI scenario. Note that warnings are handled as errors in batch mode, and force termination of the job.

The changed data is also shown on the screen if there are fields available for it.

If a run is reset, all non-changeable fields (system Customizing) are transferred from the old run. The user can no longer change this data on the screen. For a MAPI, entries in these fields are ignored (overridden).

  • Enrichment of the Selection Data (ADJUST_APPLICATION_DATA):


If you still want to add data for the parallel processes in the parameter structure that is not on the selection screen, you can do so in the method ADJUST_APPLICATION_DATA. The method is not called on the screen (using Enter), but directly at the start (F8). The method is processed once only.

  • Package Formation

1. Fixed Number of Packages (GUID Ranges)

Calculation of equally-spaced GUID ranges for a predefined number of packages. The method category here is 3 (con_packdefcatg_calc), but does not necessarily have to be returned, since this is the default case. No other methods are called in this package formation.

Return: C_PACKDEFCATG = con_packdefcatg_calc or default (space).

2. Fixed Package Size with Object Lists


The method GET_PACK_OBJECTS is used to determine all due objects. From this list, (n) object packages are formed with a predefined package size. The method category here is 2 (con_packdefcatg_obj). The following variants are supported here:

• Return the complete list in the table E_TAB_OBJNO. N objects are always removed from the table.

• Return of finished package lists in the table E_TAB_PACK_LIST. This can be used as an alternative or in addition to ensure that certain objects are kept together in one package.

• You can also set the return indicator E_FLG_FETCH_INCOMPLETE for both variants, if the list is not yet complete. In this case, the method is called more than once. An application example is a database fetch for large data volumes.

  • Data Selection (Load)

In parallel package processing, the due date is selected differently depending on the package formation category:

Intervals:

In the method LOAD_DATA_WITH_RANGE, the due data can be determined from the database using the interval limits (import parameters). The objects must be returned in the export table.

Object Lists:

The object list can be validated in the method LOAD_DATA_WITH_TAB. The method is also used to reset/repeat packages. The validity must also be checked here. Only valid objects are returned.

  • Single Process versus Mass Process


The interface provides two options for processing:

  • (a) Individual processing using PROCESS_DATA_SINGLE

In this method, the object loop for a package is in the PP interface and the application is called for each object. In the method, the object is processed and completed using Commit Work or Rollback Work.

In addition, an object is automatically held in a block delay here so that messages for an object are bundled together. (See the block delay section.)

  • (b) Mass processing of a package using PROCESS_DATA

If you process multiple objects for a package together or just want to have multiple objects in one LUW, you can use the mass process. In this case, the e_flg_active indicator must be set. You are provided with the analog interface for the single process in a table.

If you want to set your own Commits, ensure that you process the table in the predefined sorting sequence as far as possible. If you do not do this, the counter changes cannot be held in the same LUW (for more information, see the counters section).

A Commit is always set outside of the method. However, no Rollback is executed (not in a simulation run either).

Transaction Codes associated with PPF

Below table you can find the transactions, which might be useful during the execution/debugging of a program based on PPF, Personally i have used only BCADEBUG from the below list .

Transaction Code

Description

BCADEBUG

Parallel processing is deactivated and all packages are processed in a dialog work process.

BTCWAIT

If the run is scheduled in batch processing (F9, for example), this leads directly into an endless loop and can be caught in SM37 or SM50.

BTCDEBUG

A screen appears on which you enter a range for individual package numbers. Processing leads to an endless loop for these package numbers. You can use SM37 or SM50 to catch the parallel batch job (SM37: Ctrl+Shift+F7).

BCATRACE

If the application programs on the trace flag (logging) param-TECH-LOG_CTRL, it can be set using this code. The indicator is not included on the selection screen.

JOBD

You can enter a different number of parallel jobs (and optional servers) to that in the IMG for parallel processing (not more than physically available).

NOLOGDISPLAY

If a mass run is started in dialog mode, the log is always output at the end of package processing. You can use NOLOGDISPLAY to suppress the log display.

RESETDEBUG

If debugging with BCADEBUG, BTCWAIT, and BTCDEBUG is activated, it can be deactivated with RESETDEBUG.

RESETALL

Resets all hidden parameters to their initial values.

TRACEIF           

This code logs the interface methods calls in the job log (batch run only). This is not relevant for the error analysis. However, you can see “what runs in which batch job”.