Data loading into *new* BW system

[Former Member]

Hi everyone,

Background: The client used to be a part of another company but they got sold off. So now there are two companies A (original) and B (new one). As part of the deal, company B wants their own BW system. Company A is helping with that by providing an empty shell BW system into which we will load relevant data only and deliver to company B. We have loaded data into the DEV environment and are currently testing with the users.

My questions are regarding QA and PROD and how to capture deltas after initialization. I have outlined some steps that I will be following for smooth processing of everything. The steps are for LIS related extractors. Just FYI, at the client, they use "direct" della as opposed to "queued" delta and so there is no extraction queue to manage.

• Delete setup tables
• Fill setup tables for selection up to 2013 (reason for this is because of the assumption that users will not be making changes to any documents from this year and in the past. This year could change based on what the users tell us)
• Init without data
• Full repair up to 2013
• Lock users on weekend in ECC
  • Delete setup tables
  • Fill setup tables from 2014 to 2015 (current date)
  • Full repair 2014 to 2015
  • Clear delta queue manually (this is where I'm confused)

So, if I run a full repair for 2014 to 2015 current date, that should include ALL the changes that the users have made till the current date. So what should I do with the delta records that have been accumulating in the delta queue (RSA7). According to how I understand it, these records will be included in the Full Repair.

Am I on the right track? If anyone has a better plan that what I have laid out above then please suggest. I am open to suggestions and revisions. By the way, I would use the same steps above (or any corrections you offer) with non-LIS related extractors, right?

I appreciate and look forward to your input.

Thanks.

[former_member186445]

So what should I do with the delta records that have been accumulating in the delta queue (RSA7). According to how I understand it, these records will be included in the Full Repair.

--> no, they will be transferred with the first delta, so no problem as long as your target is a standard DSO.

there is no need to clear the delta queue manually after the the full repair...

[Former Member]

Hi M Tibollo,

There is no guarantee that the target is a standard DSO in every case. The reason why I was suggesting clearing the delta queue was because if I did a full repair till current date then that will include all changes in the system and so the delta records sitting in RSA7 are redundant.

Any suggestions?

[former_member186445]

once you have locked the users, you should empty all delta queues by running the delta's twice.

then you should do the init without datatransfer

run the filling of the setup tables.

when this is done, check your delta queues. if everything has been locked, there should be 0 records in your delta queue. if this is not the case double check the records that have been changed

to speed up the filling of the setup tables, you can use multiple jobs in parallel by using the range selection criteria available.

[RamanKorrapati]

Hi,

Please check and follow below steps.

1. Lock ecc system on weekend.

2. Delete and refill set up tables till now.

3. Load set up tables data to bw PSA.

4. run init info pack with init without data transfer, so now delta pointer was set.

5. Schedule V3 job and un lock ecc system.

6. Continue with your delta loads.

Thanks

[Former Member]

Hi Raman,

Thanks for your reply. I mentioned in my question that the client is using "direct delta" and so there is no scheduling of V3 jobs.The reason for not filling the setup tables till "now" is because the data set will be too large and so filling of setup tables and extraction to BW will not finish in one weekend then.

Any other suggestions?

[RamanKorrapati]

Hi,

In such case you can continue with your steps.

Those are fine to go.

Delta queue need to clean as you said. Because thru repair full request you will get all data till today from second time(2014 to 2015/till today) load.

in future if you get any data mismatch issue then you can reload them thru repair full request with proper selections.

if you have DSO in your data flow then delete RSA7 is not required. DSO will overwrite the same records and won't lead duplication delta records.

Thanks

[Former Member]

Thanks Raman for the vote of confidence. Basically I want some expert opinions (such as yours) regarding the steps that I had outlined and if in fact they were ok.

I know that we have standard DSO's in some cases but I think there may be cubes being fed directly too (will have to check) and so that causes complications and leaving delta records in RSA7 might corrupt data in cubes, right?

[RamanKorrapati]

Hi,

Normally i never suggest to delete RSA7. But in your case there is no other way to handle.

Another work around:

As you said,  your client is using direct delta means delta volume will be less.

If delta data count for a day is below 100 then we can load RSA7 data to Cube.

Later cross check RSA7(100) data with existing data in cube.

if you find any duplicates then you can delete them thru selective deletion.

Delta data you can find easily at cube level based on changed/create date.

Thanks