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 .
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).
The following shows the individual steps to an executable version.
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.
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
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.)
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
The report and the class are in the package of the application.
With the default application structure, the report appears as follows:
(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.
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).
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.
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.
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.
The interface provides two options for processing:
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.)
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).
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”. |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.