Something really critical for performance is the number of determinations you define in the BO model.
As a wise man said:
For one node at one (BOPF-) time there shall be only one determination!
E.g. everything that should happen after an item has been modified (be it in the cargo or resource or whatever section) should be handled within one item after modify determination.
Within this determination:
- read at the beginning
- determine what needs to be done at all and return if there is nothing to do! There is nothing bad in doing nothing if there is nothing to be done!
- all submethods are only working on local tables
- at the end one modify is performed for the complete table.
The helper method /SCMTMS/CL_MOD_HELPER=>MOD_UPDATE_MULTI is very helpful here to get the lt_mod out of the new table.
The recommendet way of calling this method is like this
CALL METHOD /scmtms/cl_mod_helper=>mod_update_multi EXPORTING iv_node = /scmtms/if_tor_c=>sc_node-item_tr it_data = lt_d_item_all it_changed_fields = lt_changed_fields iv_autofill_fields = abap_false CHANGING ct_mod = lt_mod.
Of course it often makes sense to check for the changes of the note at the very beginning to determine which data is really needed here.
So, what does BOPF-Time mean here:
Basically this refers to when a certain determination is executed. which is defined here:
So in this example all changes to a certain node are processed within the determination when the endmodify is triggered.
Why this rule:
The performance impact of one vs. multiple determinations is mainly, that every determination would read the same data, does it´s own modify which then triggeres it´s own change notifications and buffer updates etc. And all this sums up significantly. Believe me, we saw it…
Also BOPF needs more time to determine the relevance of the determinations, if there are too many determinations to be checked.