When presenting the scope of services of the ADWEKO FSDM2OneSumX Adapter as a bidirectional interface between SAP FSDP and Wolters Kluwer OneSumX, a distinction is made between inbound and outbound functionality. The two terms were coined because OneSumX takes the role of the presentation layer in the scenario. The inbound functionality is based on read-only accesses to the SAP FSDP, which serve to provide input data for risk calculation and reporting in OneSumX. Outbound functionality, on the other hand, refers to the functionality to persist results data from calculations originating from OneSumX on SAP FSDP. In the following, the concept of result data processing in the ADWEKO FSDM2OneSumX Adapter is explained with a focus on data quality.
As part of the inbound functionality, the required data is selected from SAP FSDM and, in the course of this, transferred into a form that can be read by OneSumX. The provision of the data is immediate. In this context, low access times favor ad-hoc reporting of the presentation layer.
When processing result data, however the aim is to manipulate the data basis. This is an extremely sensitive topic, as incorrect data can have serious consequences for the entire reporting process. Therefore, a multi-level processing logic is provided, which leads to a traceability of the result data processing and data quality through high transparency.
After the calculation in OneSumX, all relevant result data is written by OneSumX to a staging layer on the FSDP, which is deployed with the OneSumX Adapter. This is an image of the OneSumX data model, where only the tables relevant for result data are considered. In the staging layer, the result data is stored almost in its original form, which has two main reasons:
First it keeps track of what the data from the calculations looks like at the beginning of the processing. Second, this allows OneSumX specific dimension information that cannot be considered for mapping into SAP FSDP to continue to be used for reporting.
Mappings are required to transfer the result data from the staging layer to the data model on the SAP FSDP, since the data models from SAP and Wolters Kluwer are not congruent. Table functions are used for this purpose, which act similar to classic views and output result data in the required formats of the target entities. Table Functions can be used independently. This provides the ability to obtain result data in the appropriate FSDM target formats without actually persisting them. These are ideal conditions for establishing data quality checks.
Processing and use of SAP FSDM Load Procedures
During the design phase, some recurring processing steps could be identified for the respective result data types.
Therefore, the choice fell on a program architecture that on the one hand favors the reusability of certain logic building blocks and on the other hand facilitates the extensibility of the FSDM2OneSumX adapter with new result data types. The latter can result, for example, from an increase in the scope of risk analysis.
A logic is responsible for the active processing, which iteratively processes the result data types according to corresponding control parameters. The processing parameters required in each case come from a table-based configuration created specifically for this purpose.
The final write access is done by calling corresponding load procedures, which are provided by the SAP FSDM core as part of the write interfaces. In this context, the Table Functions already mentioned for mapping serve as input.
To ensure complete traceability, the entire processing is supported by logging.
The following graphic shows the facts in a highly simplified way (yellow = ADWEKO; blue = components from our partners).
Prospect of additional data quality layer
As mentioned earlier, data quality plays a crucial role in manipulation.
The implementation of an additional layer for data quality checks, opens the possibility to optimally avoid data quality problems before they arise.
Since the output of the Mapping Table Functions mimics the formats of the SAP FSDM target entities, it makes sense to use this data as the basis for quality measurements. Relational and structural dependencies can be easily derived from the definitions of the physical data model. Consideration of business dependencies and semantic correctness can again be achieved by extracting the project information of the conceptual data model.
For the purpose of data quality overview in the system, a simple UI would be required. The fact that result data generation is driven by OneSumX as the presentation layer eliminates the need for result data manipulation in the staging layer and other data quality functions.
Thus, a correction of the result data could already be achieved by re-running the calculations taking into account any adjustments after the data quality deficiencies have been detected.
Overall, these are requirements that were all considered in the development of the loading control system as part of the ADWEKO data platform manager, (DPM). An integration of the DPM as a quality instance in the ADWEKO FSDM2OneSumX Adapter therefore represents a sensible combination of both products, which complement each other perfectly.
Damian Seehrich has more than 10 years of experience in software engineering. His main focus is on the design and development of applications and interfaces using SAPUI5, SAP HANA and ABAP Objects. But technical consulting is also part of his job. Currently, Damian Seehrich is responsible for the technical implementation of a standardized interface between SAP FSDM and Wolters Kluwer’s OneSumX in the role of development manager.