You have already learned about the Extractor Checker. If you only need to check if data has been successfully extracted from a specific DataSource, you can refer to the standard table RSDDSTATEXTRACT. The table is used to store extractor statistics, such as the time of last delta load. But how can you test if ODP behaves as you expect, without extracting data physically to SAP BW/4HANA?
Problems with the provider part (extraction and fetch of data) can be reproduced with the program RODPS_REPL_TEST.
RODPS_REPL_TEST acts as a separate extra subscriber, so it is not a simulation. The queue entries in ODQMON, with corresponding table entries for RODPS_REPL_TEST, are created and adjusted. The application data is physically written to the queue. The created requests are subject to the regular ODQ clean-up job and will disappear after the retention time.
Be careful when using RODPS_REPL_TEST and Init/Delta replication mode and reset the subscription that your tests created. The reason is that an ODP source uses only one delta queue, which is shared between the various subscribers. The delta data is only cleaned up if all subscribers picked the delta. This does not happen for subscriber RODPS_REPL_TEST; therefore the delta table ODQDATA can grow big over time and have an impact on general ODQ loading performance.
The report selection fields are as follows:
- ODP Context: Choose the provider context here, such as Server Application Programming Interface (SAPI) or SAP Landscape Transformation (SLT).
- ODP Name: Name of the ODP. In SAPI-context the DataSource name.
- Replication Mode (Full, Delta, or Recovery.)
- Selections: Optional parameter where you can enter selection criteria (current restriction: if the ODP has more than 75 selection fields, no selection is offered).
- Projections: Optional. Here, you can restrict the field list.
- Read Open Pointer: Here, you can enter a pointer to repeat a delta. This pointer relates to subscriber RODPS_REPL_TEST. Currently, it's not possible to enter a pointer of another subscriber, for example, SAP_BW or BOBJ_DS.
- Settings for execution: Choose the option that you want to test.
- Output: The application data is stored in the queue in a highly compressed format. With this option, you can simulate the output for different wrapping and unwrapping options.
It is possible to protocol how the RODPS_REPL_ODP_OPEN and RODPS_REPL_ODP_FETCH function modules are called. This is especially helpful if it is unclear whether problems are on the subscriber or provider side. Problems can include the following:
Wrong data selection. Which selection was passed from the subscriber, such as SAP Data Services?
Processing mode. A repeat was expected, but a delta was done. What was requested from the subscriber?
How to enable the trace is described in SAP Note 1580242 Point 4.
It requires the setting of RSADMIN-parameter RODPS_REPL_TRACE = X and a new extraction afterwards. Refer to SAP Note 2453327.
How to debug the ODP-extraction is described in SAP Note 1580242:
- Debugging the ODP-extraction works by forcing the program into an endless loop, then catching the process through SM50. Therefore, debugging an ODQ-extraction requires authorizations for debug and also the authorizations to catch a process in SM50 for debugging.
- The wait loop is activated for a specific user via a check-point group (transaction code SAAB).
- There are different checkpoints for the OPEN and FETCH part of the extraction in transaction code SAAB.
- Function Module RSDS_DATA_PULL is a good entry point for debugging ODP-SAPI extraction FROM InfoPackage or DTP.
- Class CL_RSDS_ACCESS_ODP (Method EXTRACT) is a good entry point for debugging DTP (simulation).