Considerations if using FKK_BIX_CIT_SELECT

[Dan_M]

In Convergent Invoicing projects, I’ve previously seen custom code using Function Module FKK_BIX_CIT_SELECT instead of the generated CDS views for a CIT 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 CIT class TEST has at least 20 tables for CITs in the rated status, and each table has 100’s of millions of CITs.  The CIT 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 rated TEST CIT using a custom attribute.  They call FKK_BIX_CIT_SELECT with the following Exporting parameters:

CALL FUNCTION 'FKK_BIX_CIT_SELECT'

  EXPORTING

    irt_citcat     =

    irt_citstatus  =

    it_further_sel =

• IRT_CITCAT
  
  
  
  • Contains the CIT class 'TEST'
  
  
  
  


• IRT_CITSTATUS
  
  
  
  • Contains ‘4’ for rated
  
  
  
  


• 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 rated CITs in the TEST CIT 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_CITDATAPACKID
  
  
  
  • These are mapped to the CITCRDATE (see below)
  
  
  
  


• IRT_CONSUMDATE / IRT_CITDATE / IRT_CITCRDATE / IRT_RATINGDATE
  
  
  
  • These all lead to a specific CIT table for each month/year of the chosen dates
  
  
  • Note, IRT_CONSUMDATE is not used to identify the CIT tables if IRT_CITDATE is also used
  
  
  
  

In multiple cases I’ve seen, the TEST CIT is a successor of another CIT class. Therefore, I was able to use the predecessor CIT class CITCRDATE to restrict the reading of the TEST CIT class by using IRT_CITCRDATE.  A 5 day buffer was added in case there was an extreme delay when creating the TEST CIT.

DATA(citcrdates) = VALUE fkk_rt_citcrdate( (

                     sign   = 'I'

                     option = 'BT'

                     low    = <predecessor_cit>-citcrdate

                     high   = <predecessor_cit>-citcrdate + 5 ) ).

Planning for future data volumes by optimizing how rated CITs are read, especially when archiving is minimally used, can help prevent future performance issues.