I wanted to share some lessons that we learned while we implemented HANA i.e SAP BW on HANA in a SAP Greenfield implementation project recently. These may or may not be applicable to your project.
1. Architecture design issues: There were initial architectural issues like whether BW on HANA or HANA as a sidecar should be implemented. Early systems were installed on oracle as database then midway it was decided that BW on HANA would be implemented resulting in a migration of sandbox & development from oracle to HANA hence loss of time & effort and additional time on migration. Other architectural issues were regarding late decision on multiple schemas on one database or separating out them in multiple databases. The BW schema( SAPSR3) , the BOBJ reporting schema (Data via SLT from ERP) & HANA live schema should exist in one database or 3 databases each hosting one schema. Due to resource constraints and cost of HANA licenses and since in production HANA , SAP doesnot support multiple databases the decision was taken to put everything in to one schema. This decision resulted in dismantling of multiple database on one HANA appliance and putting all schemas on one database which also resulting in loss of time & effort and additional work. An SAP Architect is required.
2. Late identification of Requirements: There were constant new requirements identified which caused delay in the project. Some of them are like single signon between BW – BOBJ, BOBJ (WEBI) – HANA and BOBJ(Analysisoffice) – HANA. Some of these requirements were even not supported by SAP . They are only supported now. But even now no proper documentation exists. We had to work with SAP to create them. For example – SCN Setting up SAML SSO between Analysis Office 2.x to HANA SP9. Lesson here is that proper requirements analysis should be done.
3. HANA constant upgrades: Many functionalities or Bugs are supported in Higher releases so there is a need to constantly upgrade HANA. Initially we had HANA on Rev 78 which was upgraded to Rev 82. Now the plan is to upgrade t Rev 92.02. Some examples
- SAP XS engine doesnot run scheduled Jobs when they are rescheduled. Bug in Rev 82 -> Solved in Rev 84. We had to change our plan to upgrade to Rev 96 (instead of Rev 84) due to some new functionalities required by BW/BOBJ Development
- HANA Security issue (https://threatpost.com/static-encryption-key-found-in-sap-hana-database/113393). SAP note 2183624 - Potential information leakage using default SSFS master key in HANAon this issue. It is supported in Rev 97.1 forcing us to change our upgrade plan from Rev 82 – Rev 96 to Rev 82 – Rev 97.1
- Embedded Statistics sever created huge logs making the tables so large that HANA used to hang in Rev 96. We worked with SAP & SAP released the note 2170779 - SAP HANA DB: Big statistics server table leads to performance impact on the system . The issue is solved in Rev 97.2 again forcing us to revise our upgrade target from Rev 97.1 to Rev 97.2
Any Customer should be ready to upgrade its HANA box all the time as new version of HANA are released in short timeframes.
4. SAP Security Issues : HANA security has many new concepts. There were lot of authorization issues due to incorrect assignments & misunderstanding. This caused delay in the implementation , testing & support. Customer had to bring in a SAP AG consultant to fix current issues and train customer`s security team. The SAP AG consultant also designed & created many security procedures for automating the security tasks. The lesson here is to properly train the SAP security team or hire an experienced external consultant.
5. SAP HANA Transports Management: Here is an area where constant changes were requested & implemented resulting in loss of time & effort. The transport were done via
- At first via Export – Import of Deployment units or Packages
- Then it was changed in the middle to HANA Native transports
- Then it was changed to HANA – CTS+ without Change recording
- Then it was changed to HANA-CTS+ with Change recording.
All these changes cause a lot of change in the transport management strategy and deletion/creation of transport objects, functions resulting in the loss of data, transport sequencing. This should be planned ahead of time
6. Hardware support vs Software support : Hardware vendors provide their own monitoring solutions and support. If the customer already has a support team there should be proper separation of support duties like
- Does the hardware vendor monitor the OS level only or also the HANA appliance/ Software
- Who handles the appliance related alerts? Vendor or Customer support Team?
- Who handles the upgrade of the HANA appliance?
- Since the support team will be tasked to refresh SAP system (BW on HANA) or create Test systems who should create the new Database instance?
- Does the customer’s UNIX team provide support to SUSE Linux or they should contact the vendor for OS patching/Support?
- If there is a security patch released for SUSE/RHEL but not yet tested by SAP for HANA what should be the approach?
7. Communication issues regarding SAP support Tickets : Project Stakeholders require constant updates on an issue which is not possible if an OSS ticket is with SAP. SAP needs to be proactive in keeping the customer updated on the ticket.
Though these lessons learned are not comprehensive in nature but it provides some insights on what to do and what not to do in an SAP HANA project from a Basis point view.