Debugging Operational Data Provisioning

Debug and Trace the ODP

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 additional subscriber, so it is not a simulation.

The queue entries in ODQMON for RODPS_REPL_TEST, are created and adjusted. The application data is written to the queue. The created requests are cleaned up after the retention time.

Caution:

Always reset the subscription which was created by your tests.

The reason is that the ODP source uses only one delta queue, which is shared between various subscribers.

The delta data is cleaned if all subscribers pick the delta. This does not happen for subscriber RODPS_REPL_TEST; therefore the delta table ODQDATA might grow big over time and have impact on general ODQ loading performance.

Selection fields for RODPS_REPL_TEST

ODP Context: 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

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. It is currently 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.

Activate Debugging/Tracing

● 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,
catching the process then via 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: This is a good entry point for debugging ODP-SAPI extraction FROM InfoPackage or DTP.

● Class CL_RSDS_ACCESS_ODP -> Method EXTRACT: This is a good entry point for debugging DTP (simulation).

Tracing

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 there are problems where it is unclear whether the problem is on the subscriber or provider side.

Problems can include the following:
Wrong data selection.
Processing mode.
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.

LESSON SUMMARY

You should now be able to:

Debug the ODP