TechNote: DeltaQ to ODP Migration
// Good Practices / Tech Note, Microsoft-BI, TechNotes
At noventum, we very often deal with the connection of SAP systems to Microsoft-based data platforms. Both on Azure with ADF and Azure SSIS or locally with SSIS and often with XtractIS from Theobald.
The supreme discipline of data extraction from SAP is the connection of data via SAP BI Content Datasources. Here, one does not access simple tables, but via predefined interfaces that offer two essential added values:
- In some cases, many different technical tables are combined and are already grouped into logical interfaces, so that it is decoupled from sometimes complex relationships in the SAP data model. Especially in the HR area, there are many internal tables that would otherwise have to be combined. SAP also keeps these interfaces constant across different releases.
- On the other hand, SAP offers automatic delta procedures, so that a source system only receives the data records since the last retrieval or the corresponding entries and withdrawals. In SD, for example, this leads to the possibility of receiving the complete history for many tables in the first place.
Until now, these datasources were connected with the SAP Service API or the Theobald component DeltaQ, but SAP has now switched to ODP (Operational Data Provisioning). More information on ODP was described in Anatomy of the Operational Delta Queues in SAP ODP Extractors | SAP Blogs. The interface provider Theobald advises the use of ODP. In our view, ODP offers some advantages over DeltaQs:
- latest SAP interface technology,
- Parallelism is possible with fewer restrictions on extraction,
- there is no need to set up logical destinations and therefore no configuration is necessary on the SAP side,
- SAP has corrected some extractors during the changeover.
With HR Analytics, noventum offers a product in which SAP systems are a very frequently used source. Among other things, we access over 50 SAP datasources for this purpose. We have converted all these data sources to ODP in order to further reduce the implementation effort for our customers in the future. We have learned a lot in the process: Hierarchy extractors, which now have a different structure (e.g. 0COSTCENTER_H). 0COSTCENTER_HIER, 0PROFIT_CTR_0106_HIER, 0ORGUNIT_HIER), datasources that have been split in their structure (0HRPOSITION_ATTR) or others that are not offered via ODP (0HR_PA_OS_2) and finally dozens of datasources that previously incorrectly delivered DateFrom and DateTo although the source data are not historically available (e.g. 0GL_ACCOUNT_TEE). 0GL_ACCOUNT_TEXT) and finally DataSources that did not offer all options of short/long/medium text (e.g. 0JOB_TEXT) and now only deliver the texts that actually exist.
We have learned a lot during the conversion and are looking forward to supporting you in the area of data extraction from SAP or even converting existing extractions from DeltaQ to ODP.