This website is not affiliated with, sponsored by, or approved by SAP AG.

RSA3 extract zero record

Business Warehouse

Moderators: Snowy, thx4allthefish

RSA3 extract zero record

Postby krishna2011 » Sun Jul 17, 2011 6:16 pm

CRM extractor (0crm_sales_act_1, 0crm_complaints_I and 0crm_order_sales_1) are extract zero record in RSA3 in quality system but it is running working in Dev and production

How ever Full load and Delta load is working fine when I run from Infopackage. Checked trace on my id when RSA3 ,there is no trace found and everything looks ok.

I am curious it will reproduce the same issue or more if the changes goes to P. Not user this is Auth issue or something else?
Any advise will be approciated.

Thanks
Kuamr
krishna2011
 
Posts: 1
Joined: Fri Jul 15, 2011 8:10 pm

Re: RSA3 extract zero record

Postby JohnLang » Thu Jul 28, 2011 12:00 am

Hi Kuamr,

Short Answer is to always change the 2 options for “Data Records / Calls” from “100” to “999999” and “Display Extra Calls” from “10” to “9999” to ensure you give the extractor a chance to check all records on all source tables.

Long answer is that I’m not 100% sure what the exact solution is but can you try the following to make sure it is not one of these common issues related to the use of transaction RSA3.

(1) The RSA3 selection filters do not use conversion exits. You have to enter the selection values in internal format, not external format. Like 99991231 is the internal date format while 31.12.9999 is the external format. Also keep in mind that ALPHA converted fields will require the leading zeros to work properly. Like the KUNNR field (0CUSTOMER) is a CHAR 10 ALPHA so you will need to enter “0000250034” not “250034”. Try both the internal and external values on the 0CUSTOMER_ATTR extractor for a quick test to prove to yourself the external format (no leading zeros) will always return no records.

(2) Some of the business content extractors that use the F1 or F2 type of extraction method are not written to optimise the output of DataPackets. Have you ever noticed when some DataPackets are created with a different number of records? This is a result of a particular way of writing the extractor code functionality. In most cases this is not a problem. To ensure you are not looking at a premature termination of data gathering in RSA3, please always change the 2 options for “Data Records / Calls” from “100” to “999999” and “Display Extra Calls” from “10” to “9999” to ensure you give the extractor a chance to check all records in all source tables. It is possible a source table has 64,000,000 records but the extractor only processes the first 100x10 (default) records and determines that none of those 100x10 records match your selection filters so it terminates giving you no data in RSA3 even though there really is data to be extracted, as you have seen when you run the InfoPackage. So you need the largest processing numbers allowed to ensure the extractor has a chance to evaluate all records in all source tables.

(3) Review the selection criteria of the InfoPackage. Do these extractors insist on having a value in a field which is passed to the source system to allow it to work but when you run it manually in the source system using RSA3 you are missing this value. Like the Asset (FI-AA) and Controlling Orders (OPA) extractors will change their behaviour specifically because of a value being passed or not.

My guess is option 2 is the real cause of the discrepancy you are noticing.

If all else fails run the RSA3 extractor in debug mode and trace through the executing code using the F5 key (Step into) looking specifically for SQL “SELECT” statements. When you find one, evaluate the runtime variable values and review the tables matching content in a second SAP GUI session. This will highlight features of the extractor and possible differences in the SQL “WHERE” conditions.

Hope this helps,
John.
JohnLang
 
Posts: 16
Joined: Wed Jul 20, 2011 3:56 am
Location: Australia


Return to Business Warehouse

Who is online

Users browsing this forum: No registered users and 2 guests





loading...


This website is not affiliated with, sponsored by, or approved by SAP AG.