When you have to set the customizing of the Aggregation task in /POSDW/IMG transaction, you have to take into account the "Processing and Performance" configuration of this task. For that, you should know how this parameter works, so I am going to explain you how this parameter works.
The aggregation task has two steps: one to generate the aggregation itself and another one to send or work with the aggregated data. In Both of these steps you can configure the parameter.
Aggregation Task (STEP 1)
At this first step, this parameter represents the number of transactions that you are going to tend into account for each LUW.
If you don't know how a LUW is, you can use the F1 help of this field:
Badi /POSDW/BADI_AGGR_TRANSACTION (The badi where the aggregation is done) works only with one transaction per iteration, it means that the badi receives one transaction and makes the agregation of its information (retail information for example). When the Badi finishes the treatment of all the relevant transactions, the result is an internal table which contains the aggregation data of all the processed transactions and this information has to be updated in the Aggregation database.
At this point you can think that the parameter are not going to have any effect on this task, but when the aggregation data is going to be updated in the database, the parameter is very important because the method ( of the /POSDW/CL_AGGREGATED_DATA class ) COPY_AGGREGATED_DATA_REC receives the entries of the aggregation internal table and depending on the value of the parameter "Number of items", this method is going to be executed one o more times.
The entries of the internal table are going to be processed for updating the aggregation database in packages. Each package contains a number of entries which are the result of the aggregation data of some transactions. How many entries we are going to have in each package? It depends on the value of the "Number of items" that we chose in the customizing, but this parameter don't represents the number of aggregation internal table entries that we have to take. Instead of that, it represents the number of transactions that we have to take into account to produce the aggregation internal table entries, so in each package there are going to be "X" entries which have been produced by the treatment of the number of transactions that we chose before. A transaction might produce one or more aggregation internal table entries.
An example of this:
- We configure the parameter in the customizing as 5 ( 5 transactions).
- We execute the aggregation task for 10 transactions (They produce an aggregation internal table with 50 entries).
3. When the information is going to be updated in the database, the information will be splitted in packages. The first package has 30 entries that have been produced by the first block of 5 transactions. These entries are treated and their information is updated in the database. The task status of these 5 transactions is "PROCESSED". But we still have more entries in another package. These 20 entries are from the last 5 transactions, and they are procesed and updated in the database. The task status will change to "PROCESSED".
If the "Number of items" parameter is configured as '0' or INITIAL, it produces that all transactions have to be processed at the same LUW and the package will contain all the entries of the aggregation internal table.
Aggregation Task (STEP 2)
The second Step is responsible for processing the information of the aggregation database (OUTBOUND task), so for example we can send it by an ABAP_PROXY or we can do what we want with it. At this second step, we have to configure the parameter like the first step:
As you can notice, the value of this parameter can be different to the value of the first step because in this second step we aren't going to work with transactions, instead of that we are going to work with entries of the aggregation database. In the aggregation database there are entries produced by the aggregation task so when we execute the OUTBOUND task for processing these entries, the package size is very important because we are going to treat in each LUW an specific number of database entries. Actually, if we configure the parameter as 20 and we have 50 entries in the database, 3 packages will be created: the first package will have 20 entries, the second will have 20 entries and the last package will have 10 entries.
The badi for the OUTPUT task is /POSDW/BADI_PROCESS_PACKAGE and we select the database entries using the method GET_PACKAGE_DATA. For the example of 50 entries, we would have to call the method 3 times.
Like the first step, if we configure the parameter as '0' or INITIAL, all entries will be processed at the same LUW.
In summary, the package size is very important for processing and performance, so you should choose the best option to your purpose.
- SAP Managed Tags:
2 Comments
