In Convergent Invoicing projects, I’ve previously seen custom code using Function Module FKK_BIX_BIT_SELECT instead of the generated CDS views for a BIT class. I believe this can be more efficient in mass processes. However, depending on the use of this Function Module, I’ve seen performance degradation as a system ages without enough archiving. I’m including an example and some guidance for avoiding this potential performance issue.
The setup and scenario:
Let’s assume BIT class TEST has at least 20 tables for BITs in the billed status, and each table has 100’s of millions of BITs. The BIT class storage configuration has been setup to move on to the next table every six months, so in any given month a maximum of 2 tables would be used for storage.
Within a mass process, a developer wants to read a corresponding billed TEST BIT using a custom attribute. They call FKK_BIX_BIT_SELECT with the following Exporting parameters:
CALL FUNCTION 'FKK_BIX_BIT_SELECT'
EXPORTING
irt_bitcat =
irt_bitstatus =
it_further_sel =
- IRT_BITCAT
- Contains the BIT class 'TEST'
- IRT_BITSTATUS
- IT_FURTHER_SEL
- Contains the custom attribute and value
The Concern:
This will cause the logic to read all 20 very large tables for the billed BITs in the TEST BIT class. The extra table reads can cause a performance issue depending on how many calls per hour are performed.
Avoiding the performance issue:
Here are some parameters to consider to help limit which of the 20 tables are read in this example.
- IRT_BITDATAPACKID
- These are mapped to the BITCRDATE (see below)
- IRT_INVDOCNO / IRT_BILLDOCNO
- These both lead to a specific BIT table for each billing document number or invoice
document number
- IRT_BITCRDATE / IRT_BILLCRDATE
- These both lead to a specific BIT table for each month/year of the chosen dates
In multiple cases I’ve seen, the TEST BIT is a successor of another BIT class. Therefore, I was able to use the predecessor BIT class BITCRDATE to restrict the reading of the TEST BIT class by using IRT_BITCRDATE. A 5 day buffer was added in case there was an extreme delay when creating the TEST BIT.
DATA(bitcrdates) = VALUE fkk_rt_bitcrdate( (
sign = 'I'
option = 'BT'
low = <predecessor_bit>-bitcrdate
high = <predecessor_bit>-bitcrdate + 5 ) ).
Planning for future data volumes by optimizing how billed BITs are read, especially when archiving is minimally used, can help prevent future performance issues.
