You should include only 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. Refer also to the hint in
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.
Using Contexts
Since the SUPPLY and DEMAND statements 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.
