Question:
Hello,
I need to extract data from 8 coustom tables from R/3 to BW. Which the way recommanded to pull the data from R/3 to BW.
Thanks in Advance for u r suggestions.
Regards,
Sri
Answer:
For table 1, try to use business content but enhance it to fit your needs.
Table 2, I suggest to use a generic extractor based on a view.
Table 3, try to use a flat file export that you import in BW.
Table 4, use XI connector to send it to BW as an idoc.
Table 5, use RSO2 based on a function module.
Table 6, create an abap query on source system that you use for generic extraction.
Table 7, maybe create a LIS structure, feed it and extract from there.
I have no clue for table 8, maybe a report in R3, then export to xls, save as flat file and import ?
Answer:
I am aware of all the methods that you have mentioned below. But I would like to know which is the best , as all the 8 tables from which I need to extract data are Z* or custom tables.
Regards,
Sri
Answer:
CHC is very humorous and informative. I did not think about it.
To answer the question, use RS02 and if you have a date which is being modified by the transaction, then create a delta and load it to ODS and to Cube.
This would be the fastest and inexpensive.
Answer:
Do u mean to say , I need to create 8 diff data sources....no I think it would be easier to load or maintain if I have just one data source
Thanks
Sri
Answer:
You are completely right.
Only one datasource means only one central place to maintain, and you only need to launch one infopackage to load everything at a time, so you should definitely go this way.
In fact, I always combine everything at the maximum into a minimum of datasources, infosources and cubes.
Would you have imagine that the whole business of my billion dollar company fits into only one cube ?! Ok, it was not easy to design at first glance, but now with my single query I can answer all the reporting needs of the company, you just have to wait 3 hours for it to run. Peanuts for such a powerful one.
Centralization, that's the key word !!
Seriously, Sri, if you are even not clever or modest enough to try to read and understand the answer that some people really more patient than me are providing to you, then you should even not consider asking the question here !!
Of course, it maybe that your 8 ztables are combinable into one single datasource if they are linked together with keys or if they have the same layout or ...
But you didn't gave us any information that would help us understand that this is actually the case.
Ch
Answer:
Hello CHC,
Thanks for responding . all the tables have a primary and foregin key relation ship atleast 3 keys are present in each table which can connect them to the other tables.
Kamala
Answer:
Hi
I wonder which data modelling course SAP developers attend. It seems that the practive of implementing very loosely defined E/R models having many alternative schemas build in using alternative PK/FK relationships is very common. This is not good practice and definitely not consistent with theoretical datamodelling.
Any way, my contribution to this topic would be:
You could join them up on whatever keys You may find fun to use (just use random selection or spend some time analyzing what the actual purpose of the "datamodel" really is) and use a generic extractor.
Problem: How do You manage delta?
Well, it may be just impossible to manage, when You join tables that are updated, deleted and inserted independently, because its usually difficult to find a common timestamp that ensures true delta across all involved tables. If delta across the join is not possible You may consider defining datasources on smaller joins (fewer tables) or even each table seperately. Afterwards you can integrate the datasources on the BW side after they passed the individual delta process.
Answer:
For table 1, try to use business content but enhance it to fit your needs.
Table 2, I suggest to use a generic extractor based on a view.
Table 3, try to use a flat file export that you import in BW.
Table 4, use XI connector to send it to BW as an idoc.
Table 5, use RSO2 based on a function module.
Table 6, create an abap query on source system that you use for generic extraction.
Table 7, maybe create a LIS structure, feed it and extract from there.
I have no clue for table 8, maybe a report in R3, then export to xls, save as flat file and import ?
Hello CHC,
can you elaborate a little about the XI connector? Since is a new tool, what are the advantages comparing to the R/3 extraction?
_________________
SemWave
FI/CO/SEM Consultant
Answer:
Hi
Problem: How do You manage delta?
Well, it may be just impossible to manage, when You join tables that are updated, deleted and inserted independently, because its usually difficult to find a common timestamp that ensures true delta across all involved tables. If delta across the join is not possible You may consider defining datasources on smaller joins (fewer tables) or even each table seperately. Afterwards you can integrate the datasources on the BW side after they passed the individual delta process.
I agree! very good answer! To the point!
Sri will need to do some homework, but Riisberg answer shoul be a good orientation for him...
The resulting data model in BW could be several ODS (that can get full or deltas uploading, depending on the datasource definition). Then sri could consolidate this information into just one cube!
Good Luck Sri...
_________________
SemWave
FI/CO/SEM Consultant
Answer:
Hello CHC,
can you elaborate a little about the XI connector? Since is a new tool, what are the advantages comparing to the R/3 extraction?
Let's be clear, I never said it had any advantages (if you read the other options, why would you use LIS for such a demand ?).
It's one of the options that are available.
To my knowledge, there is NO advantage vs the usual extractors.
BUT if the data in one of the tables is also used to update other systems in the landscape (such as a CRM machine, for instance), then there is the possibility to reuse an extraction done for this CRM machine via XI, in order to feed BW as well.
Ch