Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 
Former Member
     As customers have started to embark on BW on HANA projects we see there are several decisions to be made with multiple questions on the table.  This gets even tougher when customers have multiple BW production systems in their landscape (and corresponding Development + Quality systems under each Production box).
     With several benefits offered by BW on HANA, customers are looking to consolidate these huge landscapes into one Production box.  In this regard, I’ve been asked several questions and a few of them multiple times, hence posting this article.
     What has already been available and I will not cover are the 3 different approaches for getting to BW on HANA.
          • Upgrade and migrate your existing BW system
          • Make a homogeneous copy and then upgrade & migrate the copy system
          • Install a brand new BW on HANA system
     These approaches have been documented & discussed in detail.  Please refer to 2012 TechEd sessions EIM300, EIM205l, Easier Migration to SAP NetWeaver BW powered by SAP HANA..., System Landscape Optimization, Rapid database migration of SAP NetWeaver BW to SAP HANA and Project Approaches.  Customers who choose the first or second option need not worry about things mentioned below, but those who choose option three and would like to get their metadata, data and other things into a new system can use this document.
Below is a matrix of landscape scenarios I will elaborate on:
Single Production LandscapeMultiple Production Landscape
Single SAP Source System
Scenario 1
Scenario 2
Single non-SAP Source System
Multiple SAP Source System
Scenario 3
Multiple non-SAP Source System

     Let’s say for the purposes of this document, BW on RDBMS systems are BWR, BR1, BR2… and BW on HANA systems are BWH, BH1, and BH2…  I will mostly be referring to Scenario 2 & Scenario 3 below.
I will break this down into topics that need to be considered:
  1. Add-on’s
  2. Master data objects
  3. Transactional data objects
  4. Reporting objects
  5. Security objects
  6. Data
1.  Add-on’s
     It’s pretty simple; ensure you download the latest version of the add-on that is compatible with BW 7.3 + SP you plan to install.  Import transports to bring any add-on specific objects to BWH.  Any necessary BW specific object that is needed by the add-on will be covered by the topics below.
2. Master data objects
     In case of ‘Scenario 2’ or ‘Scenario 3’ where multiple BW systems are involved (BWR, BR1, BR2, …) and the plan is to consolidate them into one BW on HANA system (BWH), you will need to transport infoobjects from BR* systems to BWH.  And there is no way to change the technical names of infoobjects during a transport.  So before you start to transport infoobjects look into the following:
  1. Create a unique infoobject catalogue in all BR* systems, that way when objects are transported to the BWH system the catalogue will also be imported, allowing you to identify the source of the object.
  2. If you are using standard infoobjects like 0COMP_CODE, 0PLANT, 0COSTCENTER, etc… ensure their attributes are identical in all BW systems (BR1, BR2…).  If they are not:
    • Check to see if there is a system which can be considered as a superset (meaning a system that has all the attributes used across all  BR* systems)
    • If not, transport objects from one of the BR* systems to the BWH system and then add all the other necessary attributes that are missing from the other BR* systems.
    • Or activate the standard content in the BWH system and modify to introduce necessary / missing attributes.
  3. If you have created any custom infoobjects ensure there is no overlap in the naming convention used across BR* systems.
    • If there is overlap, change the naming convention in one of the systems before you start to transport.
  4. Check to ensure critical properties of the objects like ‘Authorization Relevant’ flag are consistent (as in either turned on in all the systems or turned off in all the system).  If not:
    • In BWH system import the infoobject flag turned on as authorization relevant and identify the users who will need access to all values and grant them necessary roles.
3. Transactional data objects
     Similar to master data objects, you can transport these objects from BR* systems to the BWH system.  Also, consider the following:
  1. Create a unique infoarea in each of the BR* systems, when objects are transported to BWH you can identify their origin.
  2. You will need connections from BWH to all the SAP source systems of BR* in order to replicate / transport ‘Data Sources’.
  3. Next you have to ensure their technical names do not overlap from one BR* system to another BR* system.  If they do:
    • Especially if you have activated standard content in each of the BR* systems, then you will have to create copy objects with a unique technical name that can be used to transport.
    • In case of custom objects check to see if the fields in the data targets are an exact match (including navigational attributes).
      • If they’re an exact match,  you can transport the object from one of the BR* systems
      • If they don’t match, you have to identify which of the systems is the super-set that can cover the fields of the other BW* system.
        Also you can then transport ‘Transformations’, ‘InfoPackages’, ‘DTP’s, ‘Process Chains’, etc…
  4. If the object is purely built for aggregation of data during data load or very minimal transformation is involved during data load (like currency / UOM conversion, calculating higher level KPI like price * quantity, etc…) you can eliminate these types of targets and push this logic down to the lower level object in the data flow.  Basically shrinking your data flow and eliminating some steps in the process chain.
4. Reporting objects
     Once master data & transactional data objects are taken care off, it’s a bit easier to deal with reporting objects.  It mainly involves queries which are directly tied to a data provider; you can’t completely ignore but keep in mind the following:
  1. You have to ensure technical names do not overlap across BW* systems.
  2. Similar to query technical names, ‘Global Calculated Key-figures’ & ‘Global Restricted Key-figures’ follow a similar naming convention to avoid any overlap across BW* systems.
  3. Finally don’t forget variables:
    • Ensure their technical names do not overlap
    • Ensure they have the same properties (type: User input, SAP Exit, Authorization, etc…, single value, multiple single, selection option, etc…)
5. Security objects
     First, ensure you have the new ‘Analysis Authorization’ being used in each of the BR* systems, if not, consider creating the new authorization objects in the BWH system once the above objects are transported.  If you are using analysis authorization in BR* systems then you have to ensure the following:
  1. As mentioned multiple times, ensure the technical names do not overlap.  If you had to rename any of the infoobjects or transactional objects they were recorded appropriately in this security object.
  2. Any specific value or range of values using in this security object has the same meaning across all BR* data.  For example, if value 10 for info-object ‘Type’ means ‘Actuals’ in BR1, then it has to mean the same in BR2, BR3,…
6. Data
     You will need to create connections from BWH to all the BR* systems to perform a onetime load to get all historical data, basically eliminating having to re-initialize from the source system.  Next, using the connections from BWH to all the source systems of BR* systems (mentioned in 3.2) you can get delta loads.  This has to be done in the right order to ensure you don’t miss any records.

     Yes, objects can be transported from BW 7.x systems to BW 7.3 system as long as it’s not a depreciated functionality.  Once the objects are transported from BR* to BWH they cannot be re-transported if they have been modified within BWH using a new functionality that is not backward compatible.  For example if you convert a cube to HANA optimized Cube, you cannot transport that objects again from BR* to BWH.  Please refer to notes ‘1808450 - Homogenous system landscape for on BW-HANA’ and ‘1090842 - Composite note: Transports across several releases’ for further clarification.

     Choosing the approach to install a brand new BW on HANA system gives the customer opportunity to redesign / clean up the existing data models.  And since the system will run in parallel they will be able to compare the new design against the existing one.  Opportunity to introduce new modeling capabilities based on in-memory technology in selected subject areas.

     Consolidating system is not an easy task, but the points mentioned above will cut down on any technical caveats.  When the new data model and systems are ready you can switch your users to the new BW on HANA system with no disruption to your business process.  Additionally, reduction in TCO is another great factor in such projects.