This blog continues on from my previous blog “Road to BW4/HANA – BW 7.4 on HANA to BW7.5 on HANA”

In brief my colleague Claire Richards and I have embarked on a journey to upgrade BW7.4 to BW4/HANA. Claire is performing the BASIS tasks, whereas I am doing the BW tasks.

I am organizing the blogs using this familiar work flow, which also highlights where we are:

flow chart

I notice SAP are now blogging this On the Road to BW/4HANA – first stage accomplished.

and so to continue...

Stage 3. BW7.5 edition

Starter Add-on is now installed and so, on towards some exploration, in a similar manner as with my previous blog

  • System
  • NLS
  • Tx: RSB4HTRF
  • HANA Database Size

There a many screen shots and depending upon what you are doing, you do not need to read this chronologically.


Notice we do not have any BI Content – BI_CONT installed.
BI Content Installed product versions

RSD1 present? – Yes

RSD1 present

RSA1 Modelling present ? Yes BUT with a difference

Before Add-on

We have the ability to r/click and create the classic BW objects

Classic BW objects

After Add-on

We do not have the ability to create BW classic objects. Creation of the newer objects are performed using the eclipse modelling tool.

Eclipse modelling tool


I did my due diligence and checked my Data Archive Processes (DAPs) still worked, so all was good there. Nothing to report.


Note: This version does not have the “Check transport request” option, as I believe a later version may (BW7.51).

This process is important, as it determines if the system can be B4H enabled.

Having identified the objects that are not ready for B4H, we would then branch off and use the various tools/programs/transactions to either convert to B4H ready objects, or simply delete them.

I have identify the current tools, and give a flavour for their uses.

Before Add-on

SAP BW set

Immediately after Add-on

Compatibility mode

The system now shows “Current Mode” is in “Compatibility mode”. This occurred automatically by installing the Add-on.

In this BW7.5 Edition for HANA environment now, we can consider there are two modes:

  • “Compatibility mode”
  • “B4H”

“Compatibility mode” will stop BW’s older classic objects (e.g. Cubes, DSOs) from being created. But, the classic objects still can be used. As I have tested with my NLS tests above.

We now have the option “Save” into “B4H” mode using “Save new mode”. The only mode available is “B4H mode”. To be able to “Save” there must not be any errors (red objects). It is not necessary to “Save” to perform the remaining tasks to switch to B4H. If there are no errors, and no “Save new mode” execution, the B4H upgrade will still work. Once upgraded to B4H, the system cannot be returned to BW on HANA.

Performing a “Simulate new mode” gives the exactly the same error output as when the Add-on was not installed. No change there.

Simulate new mode

When the system is finally removed from all classic non-compatible B4H objects (see various sections below), running the RSB4HANACHECK_ENABLE once more, will return all green.

Non-compatible B4H objects

We can set the “Save new mode”, although this is not mandatory for switching to B4H mode, in the next coming stages.

Save new mode

Display logs

If you run the check program again, it now says current mode is no longer compatible mode but B4H mode.

B4H mode

At this stage, I can now give the system back to our BASIS team, to run the next B4H upgrade stage.

The sections coming next, show what to expect from the various methods of removing the non-compatible B4H B4H objects, e.g. DSOs, InfoCatalogs, etc…


After installing the SAP notes 2384088 and 2385887 the program RSDELETEDVERSIONFOR_TLOGO can now run.

After installing SAP notes

In Simulation mode (“SIM”)

Simulation Mode (SIM)

We can see it addresses the issues for all “D” versions

At the moment, I cannot see where Customer and Non-Customer objects are differentiated, if even, they need to be. Only there are two SAP notes 2384088 and 2385887 for SAP and Customer content respectively.

I looked into the contents of each note, and there seems to be the same program – RSDELETEDVERSIONFOR_TLOGO, for each.

I tried to run this in “EXE” mode, but it returned and message saying, I needed to be in “B4H” mode. So I think this is more of a clean-up program that deletes the old “D” version BI Conent from the database.

I returned to this program after the BW system was put into B4H mode.
I ran it, and it deleted all the ‘D’ (Delivered) versions of TLOGO objects. It DOES NOT prompt for specific objects on a selection screen or otherwise. It just goes off and deletes them.

BW system into B4H mode

Deletion screen

A look at BI Content InfoAreas shows nothing exists

BI Content InfoAreas

I could only find Roles remaining in BI Content


This transaction, now with the Starter Add-on installed, works.

At this time of writing (16/12/16) there are no notes on how this transaction works.
An important aspect of this transaction is that it DOES NOT transfer the data.

Here is my example:

transaction of BI Content

with the Query ZMCTQ04/ZMCTQ04_Q01 on top


First example

Dataflow Transfer

and got this

valid target provider

Then I found this SAP Note 2238220 and there are few SAP Notes to implement.

I went away and downloaded six notes, but none of them where reporting, from SNOTE, to be implementable.

So now I am investigating…
Update, my colleague Lee, found to be an issue with the code. In short, a bug, so this is how you get over it.
Naviage to SE06 – Post-Installation Actions for Transport Organizer -> System Change Option, Namespace/Name Range section of the screen and set to modifiable, not only /B4H/, but also /BA6/, see below.

I would not recommend doing the same, as you will see later, the conversion put the new objects into ‘/BA6/’.

Conversion into new objects

Now I could “Save” the definition

Save the definition

and “Execute Transfer”

Execute transfer

after giving it a Transport, it succeeded without any errors

Success after Transport

here is the result in RSA1, the new Dataflow on top, the old, at the bottom

The new dataflow

Interesting things to note, that can be also seen in the transfer definition.
my archive object (DAP) is not copied
the old MultiProvider ZMCTQ04 has been renamed to /B4H/BUZMCTQ0
and the new CompositeProvider is now ZMCTQ04

A diagram of the dataflow looks quite similar

Diagram of the dataflow

with the main differences being the CompositeProvider and the aDSO.
As mentioned in the beginning of this section, there is no data transfer into /B4H/ZDCTQ04

Composite Provider

To get data into the new aDSO, is easy enough to create a Transformation from the old DSO into the new aDSO, then a DTP, then run the DTP.

If you get an error like this when loading.

Error message

Increase the memory capacity of the HANA instance. We are using Cloud AWS for our instance, so this was not a problem.

My default settings for the DTP were Delta, but I changed that to Full so I could delete the Transformation and DTP, to the old DSO after the data was loaded.
1,000,000 records for Packet Size.
Trigger Database Merge was checked.
No Error handling.

RSRT I checked the Querys, and they worked just fine.

Reset Definition “Reset Definition” is useful if you have not yet executed the transfer, but have performed a “Save”.

Reset definition

and you want to return to the default

Return to default

In my example above, you can see I originally appended the text “Converted B4H”, and performed a “Save”. I then performed a “Reset Definition”, and once again “Definition of Target Objects”, to note the default values were put back (i.e. my appended text was gone).

Target InfoArea

Rather confusing, the “Target InfoArea” field location has nothing to do with the “Reset Definition”.

Target infoArea

In the example above, you can see that the Target converted object is saved under the InfoArea specified in this field, and not in the same InfoArea as the Source object, by default.

Watch out Earlier I mention we had to make the namespace ‘/BA6/’ modifiable to get the transaction to work. I checked some of the converted DSOs to aDSO, and found they were created under the ‘/BA6/’ namespace.

This is visible in eclipse.

Visible in eclipse

DAP When attempting to perform a load via a DTP with archive data

Perform a DTP load

It is currently not supported

This program is useful if you need to mass delete objects. Obviously, use with extreme caution. Use this to delete ‘A’ (Active) versions. If you wish to delete ‘D’ (Delivered) versions, you can do so with RSDELETEDVERSIONFOR_TLOGO.

Having identified the objects that need deleting in RSB4HANACHECKENABLE, after they have been converted using RSB4HTRF, we can use RSDELETE_TLOGO.

One thing to note, put thought into the sequence of objects to be deleted to prevent situations of being unable to delete other objects due to missing object dependencies.

Manually delete Process Chains containing objects to be deleted, before deleting info packages with this program. RSDELETETLOGO will not touch Process Chains

Don’t delete info sources or transfer structures before deleting data sources.

In the example below, I was hoping to delete an InfoArea and all below

Delete BW Metadata

but to my disappointment, using InfoAreas returned the following message


I changed it to a specific InfoCube – 0TCT_VC32

Changed to a specific InfoCube

and all continued fine, with dependent objects

Before and after the deletion – results from RSB4HANACHECK_ENABLE

Display logs

No VC32

So, to perform some mass deletions with some sense, we downloaded the results from RSB4HANACHECKENABLE as a text file, and cut and copied the object texts into the selection screen of RSDELETE_TLOGO.

Objects that cannot be deleted for one reason or another, returned a message, like this

Objects that cannot be deleted

at the end, more messages for various dependency reasons, e.g. Process Chains

Process chains

We got a short dump deleting a hybrid provider – 0TCTHP24, but the object appeared deleted, as it could no longer be seen in RSA1.

The delete program does not have an option to delete communication structures (ISCS). These are deleted when the transfer structures (ISTS) are deleted.

The does not work for 3.x data sources (ISFS), transfer rules (ISMP), or update rules (UPDR). As with InfoAreas (AREA) tried earlier. It says no objects selected.

The same message is received if the ‘only objects not being used’ checkbox is not set.

It does not work for 3.x data sources as they exist in a modified but not an active version. The deletion program worked on 3.x data sources after re-installing some from content.

It may be a good idea to make sure objects are active, before commencing deletions.

Here are some inconsistent errors we got due to deleting objects in the wrong order, with dependencies.

Transfer Structures

Transfer Structures





Xcelsius Dashboards

Dashboards do not have a selection option in the program, so we found the program class method CLRSXCLSSTATICDBINTERFACE->DELETE to delete them.

As you can see, it did get rather messy and cumbersome, but in the end, we managed to remove(delete) the necessary objects.

Source Systems

Now our RSB4HANACHECK_ENABLE result list contains only the Source Systems

Source systems

B4H uses ODP SourceSystems instead of the conventional Logical SourceSystems.

In our case, we simply deleted them, along with the PSAs.

MYSELF Source System

There is no option to delete the myself source system within RSA1.

Delete the myself source option

Therefore use function module RSARLOGICALSYSTEM_DELETE from within SE37

Function module

MYSELF BW Source System now gone

MYSELF BW Source System now gone


B4H no longer uses InfoCatalogs, so all our InfoObjects required moving to InfoAreas, which can be done with the program RSDGIOBJIOBJMIGRATETO_AREA “Migrate InfoObjects from InfoObject Catalogs to InfoAreas”

B4H no longer uses InfoCatalogs

“Information” Button

Important information before you run migration

Message no. R7B381


You are running the migration from InfoObject Catalogs to InfoAreas. Afterwards InfoObjects are assigned to InfoAreas directly and InfoObject Catalogs cannot be used anymore.


Running the migration does also have an effect on the authorization check for InfoObjects. Once the system is migrated the old InfoObject authorization object SRSIOBJ becomes obsolete. A new authorization object SRSIOBJA is then used instead. You probably have to maintain authorizations for your users using this authorization object to again provide access to the InfoObject’s metadata and data.

Please note that the general check for the authorization object SRSADMWB with field RSADMWBOBJ and value INFOOBJECT are not affected and do not change. No adjustments are required here.

Continuing on...


Migrate InfoObjects

The migration took a couple of seconds.
If you are using authorization objects,adapt to the new SRSIOBJA from the old SRSIOBJ


Finally B4HANA results


This is more of an FYI.

Transferring InfoProviders and Queries to new Composites do not error now, with the Starter Add-on. This only works for the InfoProvider and Query. The underlying persistent object remains.

I’m not suggesting you do this, but I will use Technical Content as an example, specifically 0TCT_MC01 MultiProvider, to perform some tasks and get a feeling for what is involved.

Technical content

InfoProvider Prefix will enable changes to the query copy name depending upon settings

InfoProvider Prefix


Query Copy: Namespace or Customer Prefix

Namespace or customer prefix

This will enable further changes to the query copy name, with what is entered

Further changes to query copy name

Query 0TCTMC01Q503


Transfer example for MultiProvider 0TCT_MC01

There is a lot of flexibility when choosing the options for the name of the Query that is going to be copied. You can see from my example below, albeit a bad example.

Flexibility for name choice

Choose Query to transfer

Choose query to transfer

Proposes Query name with option to edit

Proposes query name

Expected error because of the namespace I chose.

Expected error

I edited the query name to accordingly

query name edited

Lots of green, so success

Successful name change

Now to check




Original query still exists, as you would expect from a copy, along with the new copy

Original query

New copy

Now seems pointless to qualify the query name with the Provider

But it worked

Qualify query name with provider

Now happy with the copy, I can delete the original. One less object to worry about in the RSB4HANACHECK_ENABLE program

HANA Database Size

There’s no real change in the size, as can be seen here, from the current top 10 – Without BI_CONT

That about sums up the tasks for conversion into B4H mode.