- What is the ODP Framework?
- It is a infrastructure to unify data exchange between provider and consumers
Enables extract once deploy many architectures for sources
Unified configuration and monitoring for all provider and subscriber types
Time stamp based recovery mechanism for all provider types with configurable data retention periods
Highly efficient compression enables data compression rates up to 90% in Operational Delta Queue (ODQ)
Quality of service: „Exactly Once in Order“ for all providers
Intelligent parallelization options for subscribers in high volume scenarios
- It is a infrastructure to unify data exchange between provider and consumers
- What are the major use cases with ODP and BW?
- Data transfer of extractors SAP ERP (ODQ) a SAP BW
- Real-time replication of tables and db-views via SAP SLT (ODQ) a SAP BW
- Data transfer between SAP BW (ODQ) a SAP BW
- Should we change to ODP based extraction with all existing extractors?
- No, but consider ODP as framework for all your future implementations of new data flows into you BW system for ECC and SLT extraction.
- ODP is the strategic relevant source system connection to SAP sources in SAP BW.
- Can ODP be deployed in parallel with the traditional delta queue approach?
- Yes it is possible, but multiplies the data. ODP is a new source system for BW and would add the DataSource in a new context to the system
- Is there a runtime advantage using ODP?
- ODP allows to skip the PSA layer and load directly with DTP from the source system into a DSO
- Runtime is reduced by more than 40% in lab results
- Scenario: loading from the Operational Delta Queue (TA ODQMON) in the source system via DTP into a DSO compared to loading from BW Service API Delta Queue (TA RSA7) via InfoPackage into a PSA and then via DTP into a DSO
- Throughput of > 35 Mio records per hour is achieved w/o tuning (three times parallel processing)
- If the extractor logic is the ‘bottle neck’ the throughput won’t change
- ODP allows to skip the PSA layer and load directly with DTP from the source system into a DSO
- Does ODP have an impact on how the extractor work?
- ODP doesn’t change the implementation of application extractors, all the features and capabilities (delta support, RDA-enablement) are the same.
- When is ODP available or supported?
- Provider (Source):
The ODP interface you must use one of the following releases of ERP and PI_BASIS (or higher) in your ODQ system (e.g. ERP system as source system):
- PI_BASIS 2005_1_700 SP 24 (part of SAP NetWeaver 7.00 SP 24)
- PI_BASIS 2006_1_700 SP 14
- PI_BASIS 701 SP 9 (part of SAP NetWeaver 7.01 SP 9)
- PI_BASIS 702 SP 8 (part of SAP NetWeaver 7.02 SP 8)
- PI_BASIS 730 SP 3 (part of SAP NetWeaver 7.30 SP 3)
- PI_BASIS 731 SP 1 (part of SAP NetWeaver 7.03 SP 1 and 7.31 SP 1)
See SAP Note 1521883 - ODP Data Replication API for further details.
- Consumer BW:
- Recommended starting release with BW 7.40
- Supported for all databases
- How can I enable standard or generic extractors using ODP?
- The SAP Note Releasing ERP Extractors for ODP API together with SAP Note 1558737 - Data Sources released for ODP data replication API describe which Data Sources have been released for usage with ODP Data Replication API:
- Examples: 0FI_GL_50‚ 0HR_PA_EC_03‚ 0MATERIAL_ATTR, 2LIS_11_V_ITM, '0BPARTNER_ATTR‚ '0CO_OM_CCA_1‚ 0EC_CS_3‚ 0CO_PC_ACT_1
- We are right now analyzing if further extractors can be ODP enabled by default. This will be updated here continously.
- To use the ODP data replication API for any generic DataSource (extraction methods view extraction or domain extraction) you need to implement SAP Note 1585204.
- The SAP Note Releasing ERP Extractors for ODP API together with SAP Note 1558737 - Data Sources released for ODP data replication API describe which Data Sources have been released for usage with ODP Data Replication API:
- Do I have to consider ODQ in my source system sizing?
- ODP stores the data-to-be transferred to BW, in the source system, within the ODQ. To be precise only for the active and enabled extractors. The data is stored there for a retention period of 24 hr (by default but adjustable) after all subscriber to a source system received the data. So it is only focusing of the data which fits in this timeframe and is new to be loaded into BW which in most cases is negligible.
- In case of a non-HANA ERP system a very high compression rate storing the data in OPQ can be expected. As a rule of thumb: for the overall data growth which is loaded to BW 10% of the size should be considered.
- In HANA based ERP systems we have already the HANA compression per default so you can take the overall data growth which should be loaded to BW 1:1.
- ODP stores the data-to-be transferred to BW, in the source system, within the ODQ. To be precise only for the active and enabled extractors. The data is stored there for a retention period of 24 hr (by default but adjustable) after all subscriber to a source system received the data. So it is only focusing of the data which fits in this timeframe and is new to be loaded into BW which in most cases is negligible.
- How can I monitor the data exchange via ODP framework?
- Please call transaction ODQMON in the provider system. Please note that in certain cases Provider and Consumer might be the same.
- Do I need a PSA for ODP based extraction?
- Since BW 7.4 the DTP can write for ODP based source systems directly into the target InfoProvider without using the PSA table.
- This can be achieved since the ODQ provides already a lot of the services of the PSA table.
- Can I change the data in the ODQ directly?
- No, this might be one use case where you would still use a PSA table in relation with ODP sources.
- No, this might be one use case where you would still use a PSA table in relation with ODP sources.