hi,
I have a question regarding Query Mode on BODS 4.0. with ECC on SP7 which means no CDC Capability
While running the extractor 2LIS_02_HDR in Query Mode, does it reads data from Setup Tables. If that is the case, the query mode becomes totally un-usable as filling setup tables is a big overhead.
Has anyone expereinced the same ? Specially where is the data read from ? based on what I tried it is definetly not the Base Tables.
Regards,
Arsa
asar (BOB member since 2012-07-09)
True. But how is it done in BW???
Werner Daehn 
(BOB member since 2004-12-17)
My ECC guys tell me the same issue arises in BW. They say to get a full load you need to run the setup process which is static, so will need to be re-run each time you wish to get a full/query load of this. I think its a limitation of all the 2LIS extractors. the same issue arises with 2LIS_11 extractors as well.
Leigh Kennedy 
(BOB member since 2012-01-17)
Exactly. But for the delta enabled once it is not that bad.
But frankly, if it is really the HDR Extractor and no delta, you could read the VBAK table with DS as well for this case. What do you think about that?
Werner Daehn (BOB member since 2004-12-17)
If it was just the header that wouldn’t be a big deal, but its the whole set of 2LIS_11* extractors that I have challenges with.
I have actually got one of our abap developers looking at the feasibility of re-writing the whole lot, but its looking like quite an expensive exercise…
I know there is better table support in 4.1 so it may be less of an issue then ?
Leigh Kennedy (BOB member since 2012-01-17)
If you have an alternative for reading tables instead of using an extractor, then 4.0 is more than capable of doing that for you. It is one of the major advantages against other competitors for years.
4.1 brings a big improvement in reading tables which makes live easier for the initial setup of a SAP system, but does not change functionality. At least that is what I understood from the release notes.
4.1 is rumoured to be released in December this year.
Johannes Vink 
(BOB member since 2012-03-20)
SAP tech support told us not to use tables outside of ABAP data flows as they are extremely unreliable. We used to use them but we stopped because of this.
Leigh Kennedy (BOB member since 2012-01-17)
I was talking about the R/3 dataflows. What is holding you back for using them?
Reading SAP tables directly in a DF is indeed a no-go for more than a thousand records (no hard limit, rule of thumb).
Johannes Vink (BOB member since 2012-03-20)
We have a global sap template with very strict change control, so we avoid doing anything that requres changes on the R3 side if at all possible.
Leigh Kennedy (BOB member since 2012-01-17)
With the R/3 df you are not changing anything.
Basically what you do is design a DF, but then on the R/3 level. BODS generates the abap code for you which can be uploaded in to the production systemen. Then the BODS user can trigger that job which will produce a flat file. That flat file is transferred to the BODS server (via share/ftp).
Performance? BSEG with 1 billion rows in an hour or so, if you use the right indexes.
The abap generated is only a read from table, and does not change anything in the SAP system itself.
In version 4.1 the big change is that you do not need a flat file and share/ftp anymore.
Johannes Vink (BOB member since 2012-03-20)
I understand, but to get the abap uploaded, requires going through change control which can take weeks…
Leigh Kennedy (BOB member since 2012-01-17)
But that’s normal, it should not hinder you going down that route. Better have a table based solution in weeks than no solution until ERP got upgraded.
I mean, we all concur it is the 2LIS_11* Extractors themselves you are not happy with, not DataServices reading them. Right?
Werner Daehn (BOB member since 2004-12-17)
Then get some fast track for BODS code. Every change control board will be unhappy with any fast track, but hey… this is BODS 
What we normally do is run in Acceptance, show that the performance is good and then get it promoted.
And beside the fact that the code is running on around 20 systemens without any performance problem. And even when you do something unforeseen (reading BSEG not via the index…) then it is only a background job that is running for ages. It is close to impossible to kill a SAP system with that.
Personally I consider using extractors as an immature product that is in its very early development that does not fulfill its promises and continues to do so for the next few versions.
It will probably not replace the R/3 flow and it introduces a lot more dependencies and complexity.
The only good advantage is when you have an extractor that has better change pointers than CDHDR or the change/update field in the table, is fully delta capable, is fast and delivers the correct information. Almost no extractor meets these requirements.
But you will not hear this from SAP.
Edit: okay this was a bit too harsh. I expect that using extractors will be more common place in the future, a few versions away, also when the source systems are on a higher patch level. And that the BODS community/wiki/developers have more experience with the standard extractors and their quircks. Then it will be easier to implement them.
Johannes Vink 
(BOB member since 2012-03-20)
Well its the combination really given the bug we have seems to be on the DS side, but the extractors themselves are poorly designed in my humble opinion !
Leigh Kennedy 
(BOB member since 2012-01-17)
Well from our point of view, we were sold and purchased data services based on the extractor support and as paying customers, its not unreasonable to expect it to work is it ?
Leigh Kennedy (BOB member since 2012-01-17)
What bug? I seemed to have missed something.
Werner Daehn 
(BOB member since 2004-12-17)
True. If BW has the same problem handling the extractor (and probably also when you access them manually in ECC) then it is not BODS to blame.
Extractors vary in quality, sadly enough. I’d rather have perfect delta extractor working at warp speed 10. And until we get that we need to work with the tools we have got. That means sometimes using extractors and sometimes using the proven way (R/3 DF) 
Johannes Vink (BOB member since 2012-03-20)
Its Covered in the other 2LIS thread !
Leigh Kennedy (BOB member since 2012-01-17)