Accidental deletion of INIT selection conditions on 2LIS_02_SGR Infopackage

[Former Member]

Hi BI experts,

We have got some difficult situation due to accidental deletion of Init and selection conditions on 2LIS_02_SGR datasource Infopackage..

We have been doing Init W/o datatransfer for range of periods and doing Repair full request for the respective periods so deltas have been getting accumulated in source system so far for the last 2 or 3 weeks

but unfortunately some one deleted Init selection conditions from Infopackage so due to that all respective delta que(RSA7 and SMQ1) has been empty so now all the delta changes for those periods during this 2 or 3 weeks lost ...

So as per my knowledge we can not really recover and need to do again setting up of tables for reinit and proceed BUT as user group is not willing to stop transactions for such a long time again...Trying to know from community whether can we have any other best alternative to handle this situation..

I really appreciate if some one gives a best advise on this ..

Thanks & Regards,

BRK

[Former Member · Accepted solution]

Hi,

If you are currently loading into an ODS with the key figures set to overwrite, you can reload the data and it will overwrite the key figure data (rather than add it like a cube).

If you are not currently loading into an ODS, you can create an ODS (key figures set to overwrite), load the ODS from your cube's datamart (update rules set to default/no transformations), then reload the last 2-3 weeks into the ODS. Check out the data in your ODS and make sure the new data and the old data (from the cube) matches R/3 and the cube (for the old data). Once everything is set, load your ODS data into the cube. You'll also need to reinit the datasource.

Since I am not familiar with your update rules or architecture, please understand that any master data lookups in your update rules may change that data (for example, if you are loading material type as an attribute of material and that material's type has changed, you will load the new type and not the old one).

So, it can be done without a reload from R/3//ECC, however you need to be careful and make sure whatever data you move or reload doesn't change.

Good Luck,

Brian

[Former Member · Accepted solution]

Hi Brian,

Thanks for your response. I have had problem in understanding the solution you recommended. I would want to re-frame the problem that I have so that you can suggest in a better way on the solution part.

1. We need to load historical PO ( 2years worth) into BW from R/3 and the data sources used are 2LIS_02_HDR, 2LIS_02_ITM and 2LIS_02_SGR. We are fine on this.

2. We have loaded about 15 months worth data to BW already, by filling the set up tables based on the 'Document Date' field and Initialising Delta for the same 15 periods and pulled the data via full repair loads. We are fine on this.

3. This above activity was happening for the last 3 weekends (system being taken down for filling set up tables etc.), and the delta records for this 15 periods was getting recorded in Delta Queue (RSA7). We are fine on this.

4. We didnt wanted to bring deltas to BW till we actually bring the whole 2 years data, so, didnt run the delta loads, meaning we have all the delta data sitting in RSA7.

5. Accidentally, recently, in the infopackage of 2LIS_02_SGR, the Delta initialisations selections (15 months, based on 'Document Date' field) were deleted. This in return deleted the whole delta from R/3 RSA7, which means we lost the delta records captured since our first delta initialisation, means 3 weeks. This is the problem we have at the moment.

6. Though we are ok on the PO Header (2LIS_02_HDR) and PO Item (2LIS_02_ITM), we have issues on delta records missing for PO Allocation (2LIS_02_SGR).

We had thought of couple of options.

a. Load the entire 15 months PO data, by filling set up tables etc. and redoing the entire thing, which is proving to be impossible from business acceptance point of view.

b. Identify the changed records via CDHDR/CDPOS tables and fill the set up table for those specific POs, which have been changed during this 3 weeks, which is again proving to be very tough as the volume the business expects is some hundreds of thousands of delta records (in just 3 weeks -- huge business) and its not viable to opt this solution.

c. Any other bespoke/custom solution --> this is where I'm looking for some expert advice from BI community with experts.

Look forward for some expertise advice.

Thanks in advance.

BRK

[Former Member · Accepted solution]

Hi BRK,

That is a great overview of what you are trying to accomplish in R/3//ECC. Just a few more questions:

1.) Is the business global? Meaning are they 24/7 with no real holiday for the entire company? What I am getting at is if there is any downtime ... even an hour, that you might be able to get the system with little to no user activity? Is it possible to extend the maintenance window on your maintenance weekend?

2.) How long does it take to fill the setup table for 1 month vs. 3 months vs. 6 months vs. 12 months vs. 2 years? There could be a significant difference in those times. For instance, I have seen situations where 12mos. will take 10 hours to load while 3 mos. takes 30 minutes .... 4 x 30 = 2hrs for that year vs. 10hrs.

Now on the backend .... what does your architecture look like? Are you loading into a cube or an ODS for each of the 3 datasources? If you are loading into an ODS and all of the key figures are set to overwrite, then your duplicate data will overwrite. Which is fine. You just need to finalize loading the ODS before you send the data further on to another ODS or Cube.

Now, if you are loading directly to a cube or your ODS has additive key figures, it gets complicated. You cannot load duplicates. If you have a quiet day (see 1 above), then you can load the data into the setup tables, initialize and bring your delta in also, then in the PSA, delete out your duplicates. You will know what your duplicates are because they will be in that first delta ... not all, but some. So, just go through the delta records and identify which records are already in the initialization.

Brian

[Former Member]

Hi, BRK.

It might be possible to do de delta inits in small packages e.g selection of months, year.

In that case the amount of records is not very big and the system can still be running.

After that change the month,year and so on.

The only thing that you should do is change for the original delta load the selection fields en fill them in accoording to the initialisation.

If done it with CO-PA and that was been very usefull.

Good luck,

Hans