SAP BW/4HANA Migration - Explore / Realization Phase – Part 2
This article along with the first article (part 1) covers the conversion (In Place) of a standard BW data flow to a BW/4HANA compliant data flow using SAP’s transfer toolbox (transaction RSB4HTRF) for the Explore / Realization Phase for the migration to SAP BW/4HANA on a SAP BW 7.5 (SP 11) system.
Explanation of the SAP transfer toolbox (RSB4HTRF) – continued
Step 6: Checklist for Usage of Involved Objects
This conversion task shows a list of objects or findings, which should be checked or resolved provided by the execution of the previous step.
This includes a review of generated objects and of InfoProviders that are not there anymore after the transfer.
Customer code also needs to be checked for changes that occur during the transfer, for example where InfoObjects are exchanged, or queries running on a CompositeProvider after the conversion instead of a DSO /InfoCube.
The findings are not necessarily complete, with respect to dynamic coding. At the same time, not all findings indicate actual issues. The findings are intended merely as an indication that coding should be revised.
The objects mentioned in table RSB4HSEARCHBL ('black list') are considered critical, so their occurrence is searched for in the source code (including comments).
For example, the 0REQUID from InfoCubes will not be in the target data provider anymore so referencing 0REQUID or REQUID is a potential source of problems and consequently appears in the black list.
Findings in commented coding are also shown in the findings, as these comments might refer to dynamic coding that should be double-checked.
For my conversion task, there was no issues with the coding, so I just ticked the “Resolved” checkboxes for BADI and Auth and clicked save click the start/resume task list run (f8)
Step 7: Delete unsupported objects
This conversion task deletes objects that are in scope but cannot be transferred to a new object.
This is the case for the following TLOGO types (BEx objects):
ITEM (Web Item (SAP BW 3.x))
TMPL (Web template (format SAP BW 3.x))
XCLS (Xcelsius Dashboard)
BRSE (Broadcast setting)
CRWB (Crystal Report)
WWIB (Web design time item metadata)
WWPA - Web design time parameter metadata)
ERPT - Enterprise report)
EREL - Enterprise report: reusable element)
XLWB (Workbook)
THEM (Theme)
For my conversion task, none of the objects collected in my task was linked to any of the object types above so the transfer toolbox marked this step as green and moved automatically to the next step.
Step 8: Copy delta queues from SAPI to ODP technology
This conversion task clones the delta queues in the connected BW source systems to switch to ODP (Operational Data Provisioning) technology for data extraction.
Only the cloning of SAPI to ODP queues is technically executed in this task. The reason is, that cloning of ODP queues is much simpler and hence can be done also later in the task Synchronize Delta Queues between SAPI and ODP (step 10).
The benefit of this step is that the cloning of the queues can happen without any implication to the operational processes in ECC (i.e. you do not have to lock the ECC against data changes (ECC outage)).
There are several different cases for the cloning of the delta queue:
Original Object is an InfoPackage for a SAPI (Service API) Source System: The SAPI Delta Queue is copied into an ODP Subscription with the same subscriber (i.e BW system).
Original Object is an InfoPackage for an ODP Source System: The ODP-subscription for the target process "DataSource/Logsys" is copied into an ODP-Subscription for the target Process "DTP" with the same subscriber (i.e BW system).
The following is a list of checks that is executed:
The existing delta queues are checked in the source system.
The amount of data contained in a single queue and the total quantity of data in all the queues is calculated. If there is too much data, a warning is displayed. In this case, we recommend reducing the amount of data before the execution of this task by requesting delta.
A check is performed to determine whether the delta initialization requests have been completed successfully. If any of the delta initialization requests have not been completed for a source system, an error occurs, and task processing is stopped. In this case, you must complete these requests, for example by executing the QM action in the InfoPackage.
It will be checked that the last delta is not too old, and you will get advised to load once so that eventual delta loading errors are removed before the cloning is done.
It will check to ensure all relevant SAP notes is implemented in the source system.
Make sure that for all datasources in the tasks scope, that the delta loading is working properly.
The following happens on execution of this step
The task locks the creation of new delta initialization requests until the task list has been completed. In other words, the BW system will not be able to create a delta initialization request until the task “Unlock Loading and Data Target Changes” (last step) has been executed.
Finally, the delta queues are cloned in the selected source systems.
The most frequent errors are issues with old data loads. Repair them like you would repair them in normal operations. Ultimately, you can also delete eventually unnecessary delta initializations.
For my conversion task, we have data source 0BBP_TD_SC_APPR_1 from SRM source system in our conversion task list. After execution of this step the delta queue for this datasource was cloned and the transfer toolbox marked this step as green and moved automatically to the next step.
Step 9: Confirm that delta was loaded for the cloned DataSources
This conversion task is a placeholder to trigger delta requests for all cloned delta queues in the previous step. The delta requests can be triggered by manually executing the InfoPackage for example, or by using process chains.
This task is not automated by the conversion toolbox (RSB4HTRF). You can wait until the regularly scheduled process chains are executed or schedule process chains or InfoPackages manually.
It is not necessary to block bookings in the source systems or to empty the delta queues completely.
However, the deltas recorded before cloning the delta queues must be replicated before the next task can be completed.
Once a new delta request has been created for all cloned delta queues, you can confirm this task.
For my conversion task, we executed the infopackage linked to data source 0BBP_TD_SC_APPR_1 manually. After execution of this infopackage I clicked the start/resume task list run (f8).
Step 10: Synchronize Delta Queues between SAPI and ODP
Before executing this conversion task, you must clone the delta queues in the connected BW source systems using the task “Copy delta queues from SAPI to ODP technology” (step 8). You also need to manually execute a delta request for all the DataSources with delta queues that have been cloned (step 9).
The creation of delta and repeat requests is locked. This means that then you cannot extract deltas anymore for the DataSources in the task list scope until the task “Unlock Loading and Data Target Changes” (last step) is executed – especially note this point when execution of the conversion in production.
Next, a check is performed to determine whether delta requests have been triggered and completed (step 9). If this is not the case, the creation of delta and repeat requests is unlocked again, and an error is raised. In this case, you need to check the request status in transaction RSRQ and create additional delta requests where necessary (or repeat requests) for the DataSources mentioned in the error message.
Finally, the queues of the original and new delta queues and subscriptions are synchronized (for SAPI to ODP cloning), which means that that data which has been loaded into the old DataSource after the cloning is marked as read for the new DataSource and discarded so that it is not loaded twice via the new DataSource. This is necessary to determine between data loaded and data not yet loaded into the target.
For my conversion task, we have data source 0BBP_TD_SC_APPR_1 from SRM source system in our conversion task list. After execution of this step a new ODP delta queue has been created. The transfer toolbox marked this step as green and moved automatically to the next step.
Step 11: Extract from PSAs of DataSources and Error Stacks
This conversion task is a manual task to clear any PSA’s and error DTP’s that are in the conversion task list.
If the PSA’s are not being converted to an ADSO then all pending delta requests need to be cleared out of the PSA by manually executing the necessary delta DTP’s.
For error DTP’s, create if necessary and execute error DTPs manually for all non-empty error stacks. Even if the error DTP requests fail, the error stack will be emptied. The error stacks must be empty, as they are not transferred.
For my conversion task, this step cleared the PSA for data source 0BBP_TD_SC_APPR_1 by executing the delta DTP that was linked to this datasource, so the transfer toolbox marked this step as green and moved automatically to the next step. No manual activities are required to be carried
Step 12: Preparation of Old InfoProviders
This conversion task will activate all requests in DSO objects to empty the activation queues, because they are not transferred.
For my conversion task, this step activated any requests in DSO objects that where on the task list, so the transfer toolbox marked this step as green and moved automatically to the next step.
Step 13: Lock All Data Changes
This conversion task locks all InfoProvider in scope against all data changes. From this step on, the data in the Infoproviders is ready for copy into the new ADSO objects.
The preparation tasks have been completed in previous steps:
Loading all deltas into the InfoProviders which was extracted to PSA (step 11)
Clearing Error DTP’s (step 11)
Activating all loaded data in DSO objects (step 12)
The request mapping from RSSM to RSPM request management requires that no data and request operations are performed anymore, which is enforced by this conversion task. Also, For ADSOs, data changes are locked via the RSPM-Framework (new request management).
On execution of this step, the following checks are done
Data of all InfoObjects in scope is activated.
All DataStore objects is activated
No InfoCube in scope is in planning mode
All archiving runs in scope are finished
For all other objects (including DataSources), the locking is realized by entering corresponding entries in table RSMIGROBJ
It might happen that the lock could not be retrieved because other processes are currently active. In this case wait till the other process is finished, and make sure that the data is activated in the corresponding InfoProviders. Then resume this task.
For my conversion task, all pre-requisite and checks was completed successfully so the transfer toolbox marked this step as green and moved automatically to the next step.
Step 14: Prepare Request Mapping for Transfer
This conversion task fills the mapping table RSB4HPREQUESTMAP between Request GUID, Request SID and TSN for all request types of an InfoProvider.
The InfoProviders in scope are locked against all request changes.
The request mapping table is used later for data moving as well as for creating the new TSN requests in the RSPM request management.
For each InfoProvider and DataSource in scope, a parallel process is started, which determines all requests of this object, and creates a dummy TSN for it. This mapping between old and new request is stored in table RSB4HPREQUESTMAP.
For my conversion task, all table entries were populated successfully so the transfer toolbox marked this step as green and moved automatically to the next step.
Step 15: Save Data
This conversion task will save the data of old InfoProviders by renaming the corresponding database tables so the data will not be lost due to the following deletion of the InfoProviders.
For my conversion task, this step saved data for old infoprovider objects that where on the task list and the transfer toolbox marked this step as green and moved automatically to the next step.
Step 16: Transfer Metadata
This task transfers the metadata of BW/4HANA incompatible InfoProviders to compatible InfoProviders and adapts all dependent objects (for example Transformation/DTP etc.).
For my conversion task, this step transferred all BW/4HANA incompatible InfoProviders to compatible InfoProviders and adapted all dependent objects that where on the task list and the transfer toolbox marked this step as green and moved automatically to the next step.
Step 17: Transferring the request info to the new status management
This conversion task will transfer the information from the old status management into the new one. This information is needed in all subsequent processes and enables the administration of the InfoProviders and Info Objects.
For my conversion task, all table entries were populated successfully so the transfer toolbox marked this step as green and moved automatically to the next step.
Step 18: Retrieve Data
This conversion task will retrieve the data of the old InfoProviders (that have been saved by renaming the corresponding database tables) into the newly created ADSO’s.
For my conversion task, all table entries were populated successfully so the transfer toolbox marked this step as green and moved automatically to the next step.
Step 19: Unlock Loading and Data Target Changes
This is the final task of the BW/4HANA transfer task list. It removes all locks on DataSources and InfoProviders in scope and allows that operations on the new objects is resumed. The persistent locks on RSMIGROBJ resp. the RSPM framework are removed.
For my conversion task, all locks were successfully removed so the transfer toolbox marked this step as green and moved automatically to the next step.
The conversion of a BW data flow to a BW/4HANA compliant data flow has been successfully finished!!
Conclusion
This article (part 2) along with the previous article (part 1) provides a detailed explanation of the steps involved with the conversion (In Place) of a standard BW dataflow to a BW/4HANA compliant data flow using SAP’s transfer toolbox (transaction RSB4HTRF).
Even if you’re not considering migrating to BW/4HANA now, it’s extremely important to start to review this conversion now due to the following factors
Simplification: Two objects (ADSO & Composite provider) for all LSA++ layers. Number of Modelling object types reduced from 10 to 4 (60% less)
Performance: ODP extraction performance benefits – for example the extraction reduction of a delta execution of the 0FI_GL_14 ODP is from 74% to 86% in PRD - (ODP---Performance-improvements-and-benefits)
BI Schedule: Parallel data loads to and from an ADSO is possible without any locking restrictions which will reduce the overall execution time of the BI schedules.
Innovations: All future SAP development innovations will take place on SAP BW/4HANA compatible objects.
BW/4HANA: The BW/4HANA is a new solution, it’s not an upgrade of BW 7.5.
BW 7.6: There is no BW 7.6. The last version of BW is 7.5.
Future Innovations: All future SAP development innovations will take place on SAP BW/4HANA.
BW 7.5 Support: The support maintenance on BW 7.5 will end on 31.12.2024.
BW/4HANA Ready: Getting ready for the actual migration to BW/4HANA in a controlled and organised approach. This phase of work is a substantial piece of work and needs to be completed in full before the actual migration of the system to BW/4HANA can happen.
Reporting: Report at any layer of the Data Warehouse with speed and flexibility including virtually combining data across layers.
Flexibility: Composite providers allow Info Providers to be combined using the JOIN operation allowing us to create new scenarios not possible before or if possible in the past would have very poor performance with standard techniques via Multiprovider or InfoSet
LSA++: Transition your LSA (Layered Scalable Architecture) to LSA++.
Reduce LSA/LSA++ Layer: Potentially remove the reporting layer and the existing transformation layer becomes the reporting Layer.
Reduction of objects and DB Size: By removing the reporting layer, the number of objects to support is reduced along with DB storage size.
Finally, it’s extremely important to understand that the conversion process of the objects does not mean that you must transition the BW system onto BW/4HANA. The conversion process can be executed on a standard BW system (For example BW 7.5 SP 11) without committing to move to BW/4HANA but must be executed in each BW system!!
BW/4HANA compliance assessment For a BW/4HANA compliance assessment please contact us @ services@seaparkconsultancy.com.
