Cube Remodelling - Customer Exit - Usage of internal table as lookup source

[axel_]

Hi Folks,

I need to remodel a cube dimension that has about 1 mio dimension entries.

Requirement is to lookup the new field in another DSO. In general the logic of the customer exit is clear. However, I was wondering if I can buffer the lookup DSO somehow as internal table? Because otherwise I will SQL query the DSO database table 1 mio times which I suppose is not ideal ....

Can I implement another method in my custom class that loads that internal table and then the remodeling method uses this table?

Thanks for all replies in advance,

Axel

[matt]

You can load all the relevant data into an internal table - preferably a HASHED one with a unique key - and then instead of reading the database, use

READ TABLE buffer ASSIGNING FIELD-SYMBOL(<record>) WITH TABLE KEY field1 = value1 field2 = value 2...

you should only selected the fields you use. It is possible to buffer one million records, so long as the records are not too wide.

How you implement it depends on the nature of your class.

[axel_]

Hello Matthew,

the concept of internal table and how to fill it is clear. Question relates to the remodelling customer exit. As far as I see it the customer exit is called for every entry of the dimension table that is remodelled. Hence having in there the internal table defined and filled wouldn't be good as this would then be done also for every dimension entry.

Best regards,

Axel

[matt]

The question is how the class instantiation is done.

If it a new instance is created for each dimension, then define the table as static and fill it in the class-constructor. Or create a new class with a singleton pattern.

If for some reason, each call per dimension is in a new ABAP session (can happen when some of the functionality is via RFCs), then a shared memory object would probably meet the objective.