Collective Run
Definition
In addition to V1 and V2 function modules, the system also supports collective run function modules. In contrast to the other modules, these are not updated until a special report (report
RSM13005 ) starts the update (in background mode); in other words, they are not updated automatically. All function module calls are then collected, aggregated (see example) and updated together. They are handled in the same way as V2 update modules.Use
When you program a transaction, you use collective runs if a function module is called up on a regular basis, and you want to avoid a situation whereby each individual call causes the database to be updated.
Time-critical updates must not be carried out using collective runs. In this case, the collective run is not carried out until (long after) the time-critical V1 updates have been completed.
One of the function modules increments a statistical entry by one. This is called up 10 times during the course of the transaction. If you implement this as a V2 function module, the function module is updated 10 times after the V1 has been completed; this means that the database is updated 10 times.
If you use classify this as a collective run, you can perform the update at any time in one single operation: the program establishes that the statistical entry has to incremented 10 units and carries this out in one database operation.
Integration
The collective run modules can be viewed in
Update Management until the report that triggers processing is started. Update records whose V1 and V2 modules have been processed correctly, but which still contain collective runs, are set to status V2 (see The Most Important Update Statuses).