ABAP_to_the_Future

The Historic Location of Rules 9.1
get a unique record back, then you need one record for each possible percentage
value, multiplied by one record for each possible monster usage, multiplied by
one record for each possible scariness va lue, and so on. You can see how such a
customizing table can quickly have a gigantic number of records. In some standard
SAP tables, you have two keys, like transportation planning point and shipment
costs type. If you have 300 transportation planning points and 10 shipment
cost types, then you have to enter 3,000 records, and you can only cut and paste
26 records at a time from a spreadsheet into the standard IMG screen; there is no
facility to upload an entire spreadsheet at once.
Figure 9.5 Monster Rules as a Customizing Table
If you do not want such a large number of entries, then there are naturally ways
you can work around this. For example, instead of having one column for the sanity
percentage, you could have two columns: from and to. Then, as in Figure 9.5,
you can have blank values for the wild card values, those for which the actual
value of the field can be anything and the record is still valid. Finally, you would
have to retrieve a whole bunch of rows—for example, all the rows in which sanity
is below 15%—into an internal table, and then loop through that table with your
own ABAP logic to try and see which one is best.
The problem is that the more records you need to retrieve, the less efficient the
process is, and the less you can take advantage of buffering. You cannot have single-record
buffering if you are going to say SELECT where X < 15 . Standard SAP
tables often get around this by having a view cluster in which there are several
different tables, each with a different number of keys, and you try them in
sequence until you get a result. (The co ndition technique in pricing works like
this.) However, with all these workarounds, you are spreading the complexity all
around—both in the Z table and in the ABAP coding.
If the analyst decides this is really too complicated to maintain in a Z table, then
the next option is to farm the rules coding out to ABAP.
363