This is the third and final Blog in the series for a BW on HANA scaleout Migration PoC that I worked on. The links to Part one and two are below, part one covers Migration preparation checklist and Known issues and part two covers the DB Migration process itself and issues encountered:
Part 1:
Part 2
In General for the post migration activities you can follow the mandatory steps in the cook book at the link below:
https://cookbook.experiencesaphana.com/bw/deploying-bw-on-hana/post-installation/ Most of these steps are straightforward like described in the cookbook so in this blog I only provide additional information to supplement the information in the cookbook or when we ran into issues with the post migration steps. If pressed for time the "optional" steps in the cookbook may not need to be executed.
Step 6: Reconfigure change and transport system:
In transaction se06 complete post database migration options. Select “Database copy or Database migration" radio button and click on perform post Installation activities as shown below:
In this case there was already another BW SID (GBP) installed on the application server so it was necessary to configure a new domain for SBW in STMS transaction.
Click on the button other configuration:
On next screen click on configure new domain:
Accept the domain that is proposed:
On the next screen select the new standard password option:
Then you are logged into the new domain controller and you can check the connection from here:
Click on the import overview screen and on the next screen you can click on the check button to confirm that all is okay for the transport configuration.
10 Import SAP licenses
Logon with user DDIC to client 000:
You can generate a license key from here:
https://websmp207.sap-ag.de/licensekey
Click on submit and the license key will be generated and you can download it to your desktop, a copy will also be emailed to you. Before you can apply the new license key in the system you have to delete the old license keys from transaction slicense :
You also need to delete the valid temporary license key. Then click on the Install Button in transaction slicense and browse to where you saved the license key that you downloaded. New license key is successfully installed:
You then need to execute the following steps also in client 000. Go to transaction SECSTORE -> Execute and delete the following entry if marked red in color.
/HMAC_INDEP/RFC_INTERNAL_TICKET_4_TRUSTED_SYSTEM :
Go to se38 and execute the report RS_TT_CLEANUP_SECSTORE. After deleting the entry and executing the report you should see two Green entries in transaction secstore (you don't need to worry about the other red entries):
15 Check, repair or restore BW source systems :
Execute transaction RSA1. Normally for PoC we don't have any other connected source system apart from the Myself connection and flat files. It is very Important that the Myself connection works correctly. You can check the connection in RSA1 transaction under the Option source systems :
By default the RFC name of the myself connection is the same as the logical system name (In this case it is SBWCLNT200 as per screenshot above).You can check the Myself connection (BW connection to itself) in sm59.
For PoC purposes I removed hostname, user name and client and left all these fields blank as shown below with system set to Unicode, see SAP note https://service.sap.com/sap/support/notes/538052 for further information on maintaining the myself connection:
Technical Settings Tab:
Logon and Security Tab:
Unicode Tab:
17 Run BW post-migration reports
Run report RS_BW_POST_MIGRATION in background with variant SAP&POSTMGRHDB.
You may get an error message like this with the report:
The easiest way to fix this is to create a dummy destination in sm59 with the logical name (in this case Q96CLNT200), you don’t need to enter any other information on the sm59 screen. It should also be possible to delete the source system from RSA1 as long as you don't need it for the PoC.
Transforming InfoCubes & DataStore Objects to HANA-optimized objects
When executing the report RSDRI_CONVERT_CUBE_TO_INMEMORY to In memory optimize some of the DSO's I got the following error:
The reason for the error message was the following. DataStore Objects with 3.x dataflows can be converted only if the outbound dataflow is on SAP NetWeaver BW 7.x technology. The inbound dataflow can be on 3.x or 7.x technology. Therefore it was necessary to Migrate some of the 3.x data flows to 7.x data flows for the related DSO objects, this migration converts the transfer/update rules to transformations and infopackages To DTP’s.
HOW TO MIGRATE 3.X DATAFLOW:
I give an example here but an Important point to remember is that after Support package 10 for BW 730 you no longer need to In memory Optimize a DSO as the standard DSO has the same performance on HANA!!
Select the data flow you want to migrate:
Give a name for the Migration Project:
Flag all the data flow objects you want to migrate on the following screen and click on save:
Click on execute “Migration/ Recovery”:
Flag all required steps again and click on migrate/recovery:
Click on yes on the following screen:
The Migration was successful for all steps except for the data source conversion since the required source system is not connected to our PoC Environment:
After migration of 3.x data flow DSO can be HANA Optimized:
DATA STAGING ERRORS
We also encountered some issues when testing the data loading regarding the technical characteristic 0REQUID, see log from transaction sm21 below:
The problem was that an old version of the technical characteristic was installed that did not have the required master data read class. We reinstalled 0REQUID from the Business content to resolve the problem. You need to use the overwrite option and not merge and copy when installing from content. Overwriting should not be a problem for technical characteristics as they are SAP owned objects and should not be changed by customers.
This is a known issue that can happen when the master data read class is missing, you can find further information here:
https://service.sap.com/sap/support/notes/1695112
We also had some loads failing with the Duplicate Key error shown below:
The reason is that before the change in SAP note: https://service.sap.com/sap/support/notes/1645181 It was possible to have duplicate records with the same technical key in the one data package. To resolve the problem we added some coding to the end Routines as per SAP recommendation in the note https://service.sap.com/sap/support/notes/1223532.
Example of code change shown below:
This is the end of this BW on HANA scaleout Blog series. I hope you find the information useful. If you have any feedback/comments please let me know:-)