Purpose
The purpose of this page is to clarify the understanding of the system logic and requirements in relation to ODP-SAPI.
Overview
SAPI vs. ODP
- Service API (S-API) interface is the old option which is there since the beginning. This interface is used by SAP BW and the Data Source transfers data via RFC and RSA7. Data Services cannot use this technology.
- Operational Delta Queue (ODQ) is a newer development, which was originally especially developed for Data Services. With this you can use some DataSources (not all) with the ODQ-interface and extract via this ODQ-interface to Data Services. The relevant delta data is written in this case to ODQMON. For further info for released DataSources for ODQ/Data Services, please see e.g. SAP Note 2232584 .
Useful transactions and tables for specific provider or subscriber scenarios
- RSA3: Classic extractor checker. For pure DataSource data problems (independent from ODP). Easier to debug than RODPS_REPL_TEST.
- ROOSATTR: Table which contains all DataSources released for ODP. All officially released SAP standard extractors are mentioned in note 2232584 .
- RODPS_OS_EXPOSE: Report to release customer-defined extractors for ODP.
- RSDS_DATA_PULL: Function Module which is called by InfoPackage/DTP. Inside the module, ODP-extraction is triggered.
Changes in comparison to classic SAPI
- Export DataSources 8* were with 7.3 in ODP supported, with 7.4 they are sorted out. Instead of that BW-context can be used.
- Additional fields to quite old DataSources based on ROTEXTSTR* structures (usually based on Views) are not replicated to ODQ. Solution: Use own extractor based on the view you can identify from table ROOSOURCE (see note 2321909 ).