You go through a rigorous schedule to analyze, fulfill the business requirement and scrutinize the existing system to see if you can satisfy the requirement with standard SAP Extractors. After a long haul of extraordinary effort you decide to go for generic extraction. It might be a simple table join or complex function module. We wish it to be a simple scenario but life is never fair, is it? After you brainstorm and put in the best effort to complete the generic extractor you run into errors. You corroborate the logic and the code but like I said life isn’t always fair.
There can be different reasons as to why you run into errors, like, per say, inconsistent customizing for one.
Whatever the reason here are some of the steps/solution we can follow to avert the situation or more likely find the root cause and eliminate the error.
I) Extraction via Data Processing Framework(DPF)
First check Selection ID via Generic Ad Hoc Reporting
- if Selection ID fails then check the protocol (SLG1 or run administration)
- if Primary Datasources (PDS) work list fails then fix the PDS issue
- if PDS work list does not fail then check module editor etc.
- if Selection ID does not fail then check RSA3
- if RSA3 fails then check the protocols (SLG1) or open an OSS-ticket
- if RSA3 does not fail then check authorization issues
II) Extraction via Calculation and Valuation Process Manager(CVPM)
First check Calculation and Valuation Process Manager (CVPM) (to get to CVPM: SAP Easy Access à Infrastructure àCalculation and Valuation Process Manager or /BA1/FW_PROCMON) -reports via respective transactions
- if CVPM-reporting fails then check the protocol (SLG1 or run administration)
- if PDS work list fails then fix the PDS issue
- if PDS worklist does not fail then check module editor etc.
- if CVPM-reporting does not fail then check RSA3
- if RSA3 fails then check the protocols (SLG1) or if you feel it is out of your hands open an OSS-ticket
- if RSA3 does not fail then check authorization issues
III) Check in the BI “Call Monitor for BI objects” Bank Analyzer (BA) error messages in the infopackage errors log (mainly /BA1/R6* or /BA1/R7*).
a) If your datasource has been set to be linked to the run administration in the customizing you can look as well for the application logs in Run Administration of the relevant extraction run.
b) If it is not linked to the run administration then you can check the protocols via transaction SLG1, object /BA1/R6_LOGS.
c) Error analysis of a BI extraction can be cumbersome. Therefore SAP recommends a step-by-step-analysis that is mainly done in the respective Bank Analyzer source system (but not in the BI system).This approach reduces complexity and shall allow easier error detection.
IV). Try to reproduce the issue with Adhoc reporting (transaction /BA1/R7_GEN_ADHOC - Ad-hoc-Reporting in the BA-source system) with the following parameters:
a) DPF Appl. 'BW' for Generic BI Extraction
b) Selection Group ID and Selection ID: You can find them from the datasource in Generic BI Data Extraction customizing
c) Key Date Use the same as in the Infopackage
d) Parallel Processing 'X' or Space depending on the customizing of the Generic BI datasource
V). Once you are able to reproduce the errors via Adhoc reporting you have to analyze the origin of these errors:
a) Roles and authorizations errors. It can happen that you get the following error messages:
- No authorization for checking extractors (error) Message no."RJ018" error.
- No authorization for activity "read" for Result Database (RDB) client 55 Error in source system
Check that the remote user (e.g. 'ALEREMOTE') has the required roles and authorizations 'SAP_BA1_EXPERT_DR'.
b) PDS errors
You can use /BA1/R7_PDS_WL_DISPL - Display Worklist PDS to check the PDS or /BA1/R6_CHECK_PDS (in a non productive system), it can happen that the PDS is inactive or inconsistent.
c) Module editor module errors
The module itself can be inactive or inconsistent
