4
• If the volume of data to be extracted and transferred cannot be reduced effectively
• If the data that the original DataSource provides is not saved in a database table
(e.g. calculated key figures).
2.1.3 Generic DataSource with Function Module
With this scenario it is possible to reproduce complex extraction logic so that the data
attained is suitable for the data reconciliation. You can also restrict the volume of data to
be transferred using data aggregation.
If the extraction logic of the original DataSource is highly complex, there is a danger that
errors can creep into the extraction logic, leading to incorrect results in the reconciliation
DataSource. Thus this scenario is only recommended for experienced developers. It is
not appropriate if no suitable data can be prepared for the data reconciliation due to
complex extraction logic in the original DataSource
.
2.1.4 Direct Access to the DataSource
If none of the scenarios mentioned above are applicable, data reconciliation can be
performed using direct access to the DataSource. Dependent on the design, not all
DataSources allow direct access. This property is stored in the ‘virtcube’ field in table
roosource. If 'D' is entered in this field direct access cannot be performed. Otherwise
direct access is possible, but the runtime depends on the volume of data that must be
read and transferred from the database.
In order for direct access to function properly, the technical design of the system
(processor, memory) must enable the user to make a meaningful selection.
Since the original DataSource is applied as the reconciliation DataSource in this
scenario, any inconsistencies in the administration of the delta queue can be identified.
On the other hand, there is also the danger that some system errors may not be
identified, so this scenario should only be applied for data reconciliation purposes on a
limited basis.