Migration from POSDM to POSDTA
In my first blog I wrote about the key differences between POSDM and POSDTA (If you haven’t read it yet, here is the link https://blogs.sap.com/2019/03/03/posdm-vs-posdta/
In my second blog I talked about the journey from POSDM to POSDTA and the various approaches,here is the link https://blogs.sap.com/2019/03/04/journey-from-posdm-to-posdtacar/
In this blog lets focus on what are the 3 key elements of Migration from POSDM to POSDTA(CAR).
a)Current configuration needs to be recorded into a new transport
b)Config TR needs to be released and imported into CAR(POSDTA) with “Ignore component version” flag
a)Configuration should only be transported after the code
b)Additional configuration will have to be in place to accommodate new features in POSDTA such as order channel ,data status determination, loyalty distribution etc(depending on the customer’s business requirement)
c)SLT is enabled and master data is being replicated into CAR
a)PIPE(POS Inbound Processing Engine) related Custom BAdIs within POSDM can be transported across to POSDTA/CAR.
b)Required activation of BAdIs need to occur after import(step a above)
a) Standard tables such as /bi0/pplant, /bi0/pmaterial , /bi0prpa_mean and other such tables should be replaced with new ABAP tables(HANA views replicated from ECC into CAR as part of SLT)
b)BW objects that were part of POSDM needs to be replaced with the new ABAP objects.
3.Transactional data(TLOG data)
a)This is generally done using the POS Transaction Data Migration Report (T code – /POSDW/MIGR) from POSDM to POSDTA(CAR)
b)Range of stores, business days can be used as a filter criteria to migrate transactional data from POSDM to POSDTA(CAR).
a)Relevant sizing activity is done considering the current volume/size of the Transactional data in POSDM for the POSDTA(CAR) data storage.
b)Data in POSDTA will be stored in an uncompressed flat format(in /POSDW/TLOGF) compared to /POSDW/TLOGS in POSDM.Also there are some additional standard fields introduced in POSDTA when compared to POSDM. So due diligence is required before importing the transactional data into POSDTA.
1.Any custom extension segments that are part of POSDM structure will need to be analysed and agreed whether they need to be stored in /POSDW/TLOGF table or /POSDW/TLOGF_EXT tables depending on the usage of these fields and the configuration in POSDTA.
2.HANA sizing and SLT sizing are key activities that need to occur prior to data migration activities
3.BW transports are not relevant for CAR, hence no need to transport/import them across
4.Any SAP Notes etc and Basis transports specific to POSDM is not required to be imported/transported across POSDTA/CAR
5.When it comes to historical data migration, any data that’s already archived in POSDM can’t be migrated into POSDTA/CAR. The only way it can happen is through resend the TLOGs to POSDM and then migrate.
6.Make sure any tasks that are set to “immediate processing” are turned off during migration of transactional data to avoid unnecessary processing of data within POSDTA. These tasks can be turned later on when POSDTA is ready for sending the data to downstream systems.