Road to BW4/HANA – BW 7.5 on HANA to BW7.5 edition on HANA

[Former Member]

Introduction

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 were we are


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

1. System


2. NLS


3. SE38: RS_B4HANA_CHECK_ENABLE


4. SE38: RS_DELETE_D_VERSION_FOR_TLOGO


5. Tx: RSB4HTRF


6. SE38: RS_DELETE_TLOGO


7. SE38: RSO_CONVERT_IPRO_TO_HCPR


8. HANA Database Size

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

System

Notice we do not have any BI Content - BI_CONT installed.




RSD1 present ? - Yes



RSA1 Modelling present ? Yes BUT with a difference
Before Add-on
we have the ability to r/click and create the 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.

NLS

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

SE38: RS_B4HANA_CHECK_ENABLE

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



Immediately after Add-on


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.



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


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



If you run the check program again, it now says current mode is no longer compatible mode but 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...

SE38: RS_DELETE_D_VERSION_FOR_TLOGO

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


In 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 - RS_DELETE_D_VERSION_FOR_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.





A look at BI Content InfoAreas shows nothing exists


I could only find Roles remaining in BI Content

Tx: RSB4HTRF

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


with the Query ZMCTQ04/ZMCTQ04_Q01 on top


First example


and got this
I

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/'.


Now I could "Save" the definition


and "Execute Transfer"


after giving it a Transport, it succeeded without any errors


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


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


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


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

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"

and you want to return to the 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".

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


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

It is currently not supported

SE38: RS_DELETE_TLOGO

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 RS_DELETE_D_VERSION_FOR_TLOGO.

Having identified the objects that need deleting in RS_B4HANA_CHECK_ENABLE, after they have been converted using RSB4HTRF, we can use RS_DELETE_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. RS_DELETE_TLOGO 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


but to my disappointment, using InfoAreas returned the following message


I changed it to a specific InfoCube - 0TCT_VC32

and all continued fine, with dependent objects




Before and after the deletion - results from RS_B4HANA_CHECK_ENABLE


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

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


at the end, more messages for various dependency reasons, e.g. 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


Templates


InfoSource


Xcelsius Dashboards
Dashboards do not have a selection option in the program, so we found the program class method CL_RSXCLS_STATIC_DB_INTERFACE->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 RS_B4HANA_CHECK_ENABLE result list contains only the 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.

Therefore use function module RSAR_LOGICAL_SYSTEM_DELETE from within SE37

MYSELF BW Source System now gone


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


"Information" Button

Important information before you run migration

Message no. R7B381

Diagnosis

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

Procedure

Running the migration does also have an effect on the authorization check for InfoObjects. Once the system is migrated the old InfoObject authorization object S_RS_IOBJ becomes obsolete. A new authorization object S_RS_IOBJA 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 S_RS_ADMWB with field RSADMWBOBJ and value INFOOBJECT are not affected and do not change. No adjustments are required here.

continuing on



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

Finally RS_B4HANA_CHECK_ENABLE results

SE38: RSO_CONVERT_IPRO_TO_HCPR

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.

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



Query Copy: Namespace or Customer Prefix


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


Query 0TCT_MC01_Q503


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.



Choose Query to transfer


Proposes Query name with option to edit


Expected error because of the namespace I chose.


I edited the query name to accordingly


Lots of green, so success


Now to check

RSA1



RSRT

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




Now seems pointless to qualify the query name with the Provider

But it worked


Now happy with the copy, I can delete the original. One less object to worry about in the RS_B4HANA_CHECK_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.

What remains is the BASIS task of actually putting into B4H which can be viewed here in my colleagues blog, Running the conversion process to deliver a BW/4HANA