New BW4HANA ODP extraction in parallel with existing traditional delta queues

[paulmitch25]

I am planning to deploy a new production BW4HANA 2.0 system. The first phase will involve extracting the usual sales master data customer test + attributes in delta and material text + attributes in delta plus a few more master data extractions, with the rest on full, alongside COPA transaction data and SD Order Item transaction data from an ECC 6.0 system

I have an existing legacy BW7.3 system extracting from the same ECC 6.0 system with the same extractors (and more).

Unfortunately, we are going to have to go in parallel for a while which the reporting estate is built out.

I have seen another question on this, but it lacks detail.

My main question is: Can I Initialize the delta for COPA, SD Order Item and sales master data deltas in the new BW4HANA system without doing any reinitializations in the existing legacy system, leaving the existing process chains running?

OR, will I have to run full ODP extractions for everything periodically while the reporting estate is built out and we can switch off the legacy system.

____________________________________

As far as I see, a test ODP COPA init in BW4HANA DEV initialized the data up to the existing delta pointer set by the existing legacy BW dev. The entry for the pointer in table ROOSGENDLM remained the same as what it was before the BW4HANA INIT.

A subsequent BW4HANA delta then (seemed to) incremented the delta pointer timestamp based upon it's load.

If both ODP and RSA7 delta share the same delta pointer for timestamp or numeric pointers, then won't the delta pointer cause issues? Surely the subsequent delta load above from BW4HANA has incremented the delta pointer beyond what the legacy BW system has loaded, causing missed data for the legacy system? This would mean that they couldn't operate in parallel.

If ODP and RSA7 extraction are meant to run independently, then how come they share a common delta pointer in ROOSGENDLM???? It seems to argue against this. Is the ODP delta pointer stored elsewhere?

I have limited opportunity to test in DEV/QAS, so I really need to understand this theoretically and plan the cutover.

In addition, I would like to understand what parallel deployment scenarios are possible with other types of extractors, like the master data extractors above, and the logistics extractors that use different delta methods.

I like to understand step-by-step what happens and what SE16 tables are updated and in what way. A lot of answers say the two systems can operate in parallel, but give no indication of how to prepare for that. I really want to avoid touching the existing BW system and process chains because refreshing data takes such a long time there, whereas in BW4HANA, staging seems to be much faster.

[k_chandra1]

Hello Paul,

Your approach looks to be okay, I don't see any hurdles.

Generally, the ODP mechanism will run independently with SAPI extractors.

You can see the lower limit and upper limit for everything in ODQMON tcode and also same time stamps will be available in the table: ODQSSN for each ODP subscription.

ROOSGENDLM will have a target system also so it should have 2 pointers if you have 2 different BW systems will different technical names.

If you want to run 2 parallel BW systems for one source system try to use different BW system names(or client numbers) and everything should be fine with data loads.

Thanks,

Chandra

[paulmitch25]

Hi Chandra,

Thanks, but I am not sure that it stores the remote system in this table. ROOSGENDLM only has a SLOGSYS field, which is the source logical system, not the target logical system. This means that there is only one record per extractor in this table. When I run the ODQ extractor in BW4HANA, it increments the delta timestamp and repeat timestamp in the single record in this table. This could cause data loss in the legacy system, because anything the legacy BW would assume it has already extracted records before this timestamp. [the timestamp does include a safety interval too]

Interestingly, ROOSPRMC does have a SLOGSYS (source) and RLOGSYS (remote), but for the BW4 system, the RLOGSYS value only seems to have a dummy value preceded by a dollar '$' symbol, so I am not sure if that is a config issue. This table only deals with initializations though.

Regarding Master data, the deltas are change pointers, which may have similar issues as far as I can see.

Logistics data is always complicated. I was wondering whether I could initially get people on production with monthly full loads initially. That would only involve running the setup job OLI7BW after clearing what was there before and then doing a full load with 2LIS_11_VAITM. In terms of deltas, I still need to see what issues might arise between the 2LIS_11_VAITM in the BW4HANA system and the 2LIS_11_VAITM in the legacy system when run in delta mode. Do you know what steps would be needed for periodic full loading and parallel delta loading for this extractor?

Generally, doing a full load won't increment the delta for the legacy system. This should allow a kind of parallel run and then full cutover would mean a switch to delta for the BW4HANA extractors. This is my backup plan.

Don't you mean the table ROOSPRMC which does indeed have 2 rows, one for the legacy BW remote system and the other for the new ODQ system (curiously marked 'dummy' with a dollar '$' prefix)?

I am confused about which table actually controls the process and which one records the process. Both systems are certainly altering the timestamp in ROOSGENDLM, but the timestamp doesn't look right for the ODQ delta in ROOSPRMC.

ODQMON looks right, but if the tables "controlling" the SAPI extraction are updated, then the ODQ extractions could cause data loss in the SAPI extractions and vice versa.

Thanks

Paul