SAP BW – Why You Should Consider Upgrading Before You Migrate.
Author – Mark de Graaff, Expert Professional Analytics Consulting, NTT DATA Business Solutions UK&I
This blog describes the technical challenges faced when migrating AND downgrading from SAP BW 7.5 (SP15) on Hana to SAP BW 7.4 (SP13) on Hana, with the focus on standard SAP BW Modelling Tools (version 1.21.22) and SAP Hana Studio Development tools (version 2.3.45) as well as the usage of BW Integrated Planning. Please note these are merely practical observations and is not intended to generalise nor criticise the usage of SAP BW.
Throughout the years SAP Business Warehouse has offered many functionalities and where old ones were replaced, new ones have been added. However, the core principles have always been pretty much the same: to provide a seamless user experience for functional and technical user alike, whichever end of the spectrum you’re positioned.
During one my recent projects I was faced with the challenge to downgrade to a lower SAP BW version due to a company acquisition.
Therefore, besides contemplating how to develop the best data model for my users, I’ve had to ask myself a different question this time round: What is the best option to migrate your existing BW solution to match (or even improve) the same functional and technical performance, whilst downgrading to a lower software release?
Although an upgrade had always been on the agenda it would not have been implemented before the migration project was completed. This placed me in an interesting position and posed some significant challenges. Soon however, I found out this question has two simple answers:
Hardware specification and software application version.
In the field of BW development this is no concept of ‘irrelevant twaddle’ so let’s explore the software side of this equation.
BW Roadmap
With SAP BW 7.4 now out of support, any businesses still using this version should upgrade to SAP BW 7.5 or SAP BW/4HANA, or consider other SAP alternatives like Data Warehouse Cloud or perhaps take a hybrid approach of On-Premise and Cloud. This may have obvious constraints around budget and planning, therefore it is strongly advised to examine the options carefully before transforming them into an actual project plan.
So what happens if you cannot yet make that decision but have to carry out a BW system migration and merge any other legacy system(s) into your system landscape? This propels release management right to the top of the list; what software version am I currently on, what version will I be migrating to and should I consider upgrading prior to migration? Let’s delve into these aspects in a bit more detail.
Release Management; the challenges
While some organisations use SAP Solution Manager to plan, manage and schedule their software release, others choose to review their application version on an annual basis instead and apply the latest applicable software version, and then there are some that commit to applying bug fixes ‘on the go’ and decide to upgrade when support (nearly) runs out. The latter is often due to a lack of time and planning and is, actually, an even more time consuming and potentially costly affair, so why not consider the first two options before a system migration?
SAP BW Product Features
Within 7.5 on Hana and BW/4HANA the modelling entities have been simplified to enable a more flexible and agile approach in data modelling.
The Advanced DataStore Object
Any BW developer who is familiar with the oldest and latest available modelling objects will advise you to use the newest objects for simple reasons: usability, flexibility and to make the road to SAP BW/4HANA as smooth as possible. This is where the classic BI artefact ‘Data Store Object’ (DSO) is not going to do the complete job for you. Yes, it will persist data as required, but it is not fully HANA optimised, and more importantly, your options are limited in terms of its modelling properties, data tiering properties and compression capabilities in comparison to an Advanced Data Store Object (ADSO). And not to forget, with an ADSO you are also able to create a field based database table without any reference to a BW Info object, which can enhance the flexibility, manageability and range of the data warehouse.
In an ideal BW environment we therefore replace/convert the classical DSO or BW Infocube to an ADSO, but unfortunately when on SAP BW 7.4 there are still reasons to justify the use of this particular object, for example; What do you do when you need a ‘Direct Update DSO’ in a ‘BW Integrated Planning’ scenario, and simultaneously, you would like to create and persist an initial data set loaded from any data source? In SAP BW 7.4 (SP13) you will not be able to create a source to target ETL transformation mapping into a ‘Direct Update DSO’, and certainly not when using an ADSO object (the ‘Direct Update ADSO’ is only available as of BW 7.5 SP1) so this forces us to use a BW Infocube nonetheless; far from ideal indeed.
Likewise, the creation of export data sources (8*) on an DSO or Infocube object is still possible in BW 7.4 and BW 7.5, but this is being replaced by the BW-ODP (Operational Data Provisioning) infrastructure and it’s therefore recommended to use the ODP mechanism instead, if possible. Because ODP was not yet implemented in the system environment whilst performing the migration we were again forced to use a DSO and replicate this old ‘3.x’ functionality. What made it even more disappointing is that the ODP framework was partly implemented after go-live, which means we should still replace the 8* export data source with the latest ODP version coming from the ADSO, once converted.
To conclude the DSO vs. ADSO debate; we were not particularly spoiled with options when downgrading to BW 7.4.
This makes it pretty clear the classical DSO object has had its best time, and we should move into the new BW development world where possible.
The Composite Provider
In the previous section I ‘championed’ the usage of an ADSO, but we haven’t reached the finish line just yet; The ADSO is the preferred modelling object, however what could possibly happen when using it in a Composite Provider? Surely you simply map/join the desired ADSO source-with target fields, check/activate the object and your Composite Provider is ready for further use?
Unfortunately, the game isn’t played just yet and we are now in ‘extra time’ (literally), depending on what Support Package you’re on; for example (fair warning, but the following section might be quite technical for some readers…), there could be the issue to map the ADSO source field navigational attribute to a Composite Provider target field.
This could cause a program error and will not be allowed unless you have applied the relevant SAP note correction instructions (see SAP notes 2213428 and 2359931 for a potential solution).
Solution/workaround? Create a Composite Provider with the relevant ADSO and use this within the main Composite Provider! This approach, although perfectly possible from a technical point of view, is not endorsed by everyone, and certainly not if the Composite Provider itself contains more than one source providers as that could be detrimental for performance, so be careful what approach to take here!
It will however resolve the issue described earlier therefore the usage of the ADSO is still very much alive and kicking so we have a clear winner, albeit in a slightly different shape due to the limitations in BW 7.4 (SP13) when working with Composite Provider functionality.
Now let’s shine another light on this; what if you want to use a HANA Calculation View within a Composite Provider, and the Calculation View contains input parameters? In any normal scenario you would simply create the field assignments and the Composite Provider object is ready to use? Well not quite yet, because there could be the issue of a ‘Move Cast Error’ (program related error – see SAP note 2302832), so this means some object types in BW 7.4 SP13 are not yet fully optimised to use on HANA after all which is another reason to (re-)consider the alternative support packages or overall release version of your BW product installation.
I could list various other SAP note resolutions around challenges faced when designing queries, for example on using characteristic hierarchies where maintenance/activation of the hierarchy was not possible (e.g. see SAP note 2336689), improving the query performance when applying a unit conversion (e.g. see SAP note 2120776) or having to use Query Designer instead of using HANA Studio/Eclipse to avoid a major critical error whilst creating inverse formulas for a BW input ready query.
But… …let’s not get bogged down into the world of SAP support notes; as we know there are quite a few of them out there but ultimately the message is clear: new or enhanced features improve functionality which will result in a more stable and reliable BW application, and this will ultimately strengthen the bridge between technical developer and functional user to improve overall operational delivery.
Conclusion
With my motto being ‘there is a solution for everything’ this particular downgrade migration project was successful, however the lessons learned are obvious and should not be taken lightly as they could ultimately save precious time and reduce expenditure.
The previous examples provide strong reasons to review and apply new SAP BW support Packages on a frequent basis. Getting the latest fixes and functionalities will not only ensure lesser technical issues/bugs and the time required to resolve. Moreover a solid release management is essential preventative maintenance that will ultimately pave the way to transition from a solid business warehouse information system to one of the most advanced and versatile warehouse solutions on the market; SAP BW/4HANA.
So, if you still have any of the ‘old’ BI artefacts in your Business Warehouse and you are considering patching up or upgrading then I would suggest reading the latest SAP Roadmap documentation carefully, as it contains various prerequisites and other SAP note references to start your data model object conversions on the road to SAP BW/4HANA (SAP note 2383530 ‘Conversion from SAP BW to SAP BW/4HANA’).
NTT DATA Business Solutions has some unique offerings to support you with the transition of your BW landscape to fully utilise the potential of SAP BW/4HANA; a next generation warehouse application that truly is a game changer.
To discover more about how we are helping organisations to gain business insights and see value in data from a variety of locations, you are welcome to join our interactive virtual conference, #TransformationNow2021 running in October. Find out more and register here.