Contexts are obsolete and should not be used. Contexts were introduced for Release 4.0 for high performance access to frequently required data. Since the introduction of ABAP Objects for Release 4.5, contexts have not been developed further. Since Release 6.40, contexts can be replaced by shared objects.
· You should only include a small number of key fields in your contexts.
· The context graphic should not contain any isolated, unattached fields. In other words, all of the input parameters should be derived hierarchically from the key fields or output parameters of other modules. If this is not the case, you should split the context into two or more smaller contexts. See also the note on buffering contexts.
· You should restrict the number of derived fields to those you really need, because:
– Reading fewer fields reduces the load on the database
– Fewer fields means that the buffer requires less space
– The system can then read the buffer more quickly
– You can always add more fields later if required.
· If you use a table, a function module or a context more than once as a module within a context, the module name should be made up as follows:<object name>_<suffix>. When you test your context, the suffix is automatically displayed after the long text.
· Since the SUPPLY and DEMANDstatements are not runtime-intensive, using them repeatedly causes no problems. In particular,
– You should always use the SUPPLY command as soon as the key values are assigned. This reduces the risk of deriving obsolete values in the DEMAND statement. You do not need to make a preliminary query to see if the contents of the key fields have changed, since the system does this itself in the SUPPLY command.
– You should always use the DEMAND statement immediately before using the derived values. This is to ensure that you always use up-to-date values.
· You should use local data objects as target fields for the DEMAND statement. This reduces the risk of obsolete values being used in error.