Debug a CPI invoked SAP Extractor

When we extract data from SAP ECC system through CPI-DS, we often find that the count of the output record set from transaction RSA3 or the report: RODPS_REPL_TEST is different from the output record set pushed to CPI. This happens because the parameters passed to the SAP extractor when triggered from CPI could be different from that we use to test through transaction RSA3.

The parameters passed to the SAP extractor when triggered from CPI is based on how the interface is designed in CPI like the fields mapped to the target system, the filters set, etc.

Wouldn’t it be nice if we could actually debug the extractor that is invoked from CPI? Here you find a simple 3 step process that would actually do that.

Step 1: Place a break-point in ECC system

Set a break point in the method /IBP/CL_ETS_RSAX_BIW_GET_DATA=>RUN_GET_DATA as shown here –

BreakPoint in ECC

Step 2: Run the task in CPI

Select the task and click on “Run Now”.

Run task in CPI

Step 3: Go to transaction SM37

When the task is still in the “Released” state, say JDBG on the command line and press F8. The control would stop at the place where the break-point is placed.

SM37 – Job Overview

The debugger stops at the place where the break-point is positioned. From here on, we could proceed to check the extractor code and also the BADI implementations.

Debugger

The generic extractors can also be debugged the same way as explained above.

Thus, we have learned how to debug an SAP extractor job triggered from CPI. I’m sure this would make our life simple and would help us to discover more interesting facts about SAP extractors.

Note: As soon as we get into the debug mode, there would be an entry in CPI’s error log which says, “Object requested is currently locked by user” and the job log in SM37 would not show the output record count.