Tools for migrating to SAP BW/4HANA (B4H)

Today I post a similar blog as I did for BW to HANA (BoH). It is with regards to Tools for migrating BW to HANA (BoH) but this time for tools to migrating to SAP BW/4HANA (B4H).

There are few differences with regards to SAP BW/4HANA comparing to “regular” BW systems as we know them. SAP BW/4HANA is not delivered via the SAP NetWeaver stack. The underlying platform is SAP HANA DB and components like DW4CORE, SAP_BASIS, SAP_ABA, SAP_UI, SAP_GWFND of ABAP application server.

Other differences include: (this is not a list of all differences just few important ones)

·         A new request management for all staging/loading processes is in place. It is called transaction sequence numbers (TSN). The request looks like DTPR__request – it contains not of request itself, timestamp, time zone etc.

·         Changes to official interfaces to BW objects (e.g. RSNDI, RSDRI)

·         All “old” things like customer exits (CMOD) and BAdI methods for e.g. BEx/BW exit variables are replaced by corresponding enhancement spots.

·         SAP claims that more than 5 million lines of SAP BW’s ABAP code have been deleted. There is an impact on custom code where non-released ABAP interfaces/code is used. This may be tricky if your development includes non-released objects. Check your custom code first!

First of all there is a bunch of prerequisites for SAP BW/4HANA (B4H). Major one is that it can only be installed on top of SAP BW version 7.5 systems. In particular SAP BW 7.5 SP 5 powered by SAP HANA is needed. In case cases staring point also can be SAP BW 7.0 or higher on AnyDB.

Another important point is with regards to version of HANA DB. Minimum HANA DB version must be Revision 122 or higher in case of HANA 1.0 SPS 12 and Revision 1 or higher in case HANA 2.0 SPS 0.

Now in case existing BW system is going to be converted to the SAP BW/4HANA system following tools can be leveraged for this purpose (tools are not sorted in a sequence of how they shall be executed always refer to particular migration scenario!):

SAP BW Note Analyzer - This tools analyses status of implementation of SAP Notes in particular system and also installs other tools (like Transfer Toolbox) that are needed for migration to B4H. It can be started by report Z_SAP_BW_NOTE_ANALYZER. The SAP BW Note Analyzer can be installed via SAP Note 2383530

SAP BW/4HANA Transfer Toolbox - it converts SID of the SAP BW system either to new one (new system) or existing one. This can be done either via in-place conversion (full system is converted) or remote conversion (selected arts of system like data model will be converted to new system). The tool can be started by a call of t-code “STC01” and executed by task list “SAP_BW4_TRANSFER_INPLACE”

Precheck Tool – so called SAP Readiness Check - Simplification Item Check. The tool analyses the impact on system to be converted based on simplification items. There are two types of check integrated into the tool. Relevancy/Consistency checks.  It can be started by report /SDF/RC_START_CHECK. See Note 2399707.

SAP BW/4HANA Starter Add-On - formerly known as SAP BW, edition for SAP HANA. It needs to be installed on top of SAP BW 7.5 system to enable the conversion to SAP BW/4HANA.

Transfer Toolbox for BPC – similar tool as SAP BW/4HANA Transfer Toolbox but crafted specially for BPC add-on in BW.

Report RS_B4HANA_CONVERSION_CONTROL - it executes and realizes the phase of system conversion to B4H.

Useful information:

SAP BW/4HANA online docu

The Road to SAPBW/4HANA presentation

2383530 - Conversion from SAP BW to SAP BW/4HANA

2591784 - SAP Readiness Check for SAP BW/4HANA - Preparation

2575059 - (pilot) SAP Readiness Check for SAP BW/4HANA       

2567324 - SAP Readiness Check for SAP BW/4HANA - Object Compatibility

2421930 - Simplification List for SAP BW/4HANA

2513088 - SAP BW/4HANA Conversion Cockpit - System Setup & Pre-requisite

2399707 - SAP Readiness Check - Simplification Item Check

Something about conversion exits

I recently need to create a new conversion exit to perform additional data formatting on data that were given to my program on input. I learned few interesting things while working on it.

First of all the conversion exit can’t be just one. Is it is input/output type of thing a system forces you to create two function modules. One for input conversion and other one for output. There is function module called RS_CONVEXIT_EXISTS which existence of the two. Conversion exits can only be used in the ABAP code as long the two exits. If only one exists system will throw error message that conversion exits doesn’t exist.

Secondly there is a fixed naming conversion belonging to the names of the conversion exits. The input one must be called like: 'CONVERSION_EXIT_<>_INPUT' and output one 'CONVERSION_EXIT_<>_OUTPUT'. Prefix ('CONVERSION_EXIT_') and postfix ('_INPUT' and '_OUTPUT') must be given to the function module that will be performing the conversion.

Thirdly all the conversion exits are stored in table FUNCNAME among the rest of the function modules.

Fourthly to get a list of all of the existing conversion exits the module called 

RS_CONVEXIT_GETLIST can be used.

Fifthly name that you insert after the prefix and before the postfix can have up to 5 characters. E.g. CONVERSION_EXIT_MADJ1_INPUT.

Sixthly the conversion exits can be used in BW to populate a date for infoobjects. E.g. in case you need to prefill certain value as a constant while data is being loaded to PSA.

Function group is full?

There is actually a limit for number of function modules that can be included in one function group. I wasn’t aware of this until recently when I ran into the limit.

I was about to create a new function module into existing group and I got into this error message:

There are already 99 functions       Message No. FL030

Diagnosis

You attempted to add a function module to a function group that is already full. A function group can contain a maximum of 99 function modules.

Procedure

Create a new function group or reorganize the existing one.

Pretty much is says that there is a technical restriction of how many function modules can be stored in the group. There is no really solution just to use another function group.

Just last note in here the new function modules are created by another function module called RS_FUNCTIONMODULE_INSERT.

Security vulnerability – Meltdown and Spectre

Year 2018 started a bit crazy when it comes to computer security. Security researches published a huge security vulnerabilities related to CPUs – computer’s microprocessors. 

If you remember year 2015 and a bug called Heartbleed that was almost nothing comparing to these two. The two are considered as "catastrophic" by security analysts. In short the Meltdown allows a rogue process to read any kernel memory, also in case the process is not authorized to do so. The Spectre is abusing a branch prediction of microprocessor’s cache that affects microprocessors with speculative execution. This involves cashed data which may be read/modified by tricking the accept requests.

One of the issues related to these vulnerabilities is that the Spectre is not easy to be fixed. Also while employing the fixes it is causing CPU’s performance degradation.

The vulnerabilities are affecting wide variety of devices - almost every device using microprocessors especially made by Intel, ARM, possibly also AMD. As SAP systems are running on these processors as well the SAP is paying an attention to the vulnerabilities. There are special SAP Notes (see below) prepared and being updated that advise customers on what to do.

More information:

2585591 - How to protect against speculative execution vulnerabilities on Windows?

2586312 - Linux: How to protect against speculative execution vulnerabilities?

Meltdown attack

Wiki -Meltdown

Wiki - Spectre

More than one query with the same technical name?

In BW systems it is not a rare case when there can be multiple BW objects with same technical name. This is especially related to BEx Queries (plus other query components like (REP, CKF, RKF, STR, VAR and SOB can be similarly effected too). Normally one would expect that the technical name is unique identifier of the query. However it is not the case. The technical name (COMPID in table RSZCOMPDIR and others) is not unique similarly as a description of the BEx query is not unique. It just represents language-independent name for the query element. This is in contrary to other objects in SAP systems where the technical name is really unique.

Technically it is not a problem to have duplicate technical names because other field (COMPUID) is used to uniquely distinguish between them. But it may cause problems while using tools like BEx where user needs to specify the query name in OPEN/SAVE dialogs. Only one query will be processed in these tools – whichever is found first in the database.

There can be several cases which may lead to situation causing having more than one query with the same technical name. Some of them can be:

Transports: When one query is imported from system A to system B. Technical name is the same in both systems. Later the query is deleted in the system A and recreated with same name. In case deletion of the query wasn’t transported to system B there will be 2 queries with the same technical name in the B system once recreated query gets transported to system B.

Several dev/test systems used to import objects to one prod systems: of query with the same technical mane is created in both source systems and they are imported to target system the query in there will have the same technical name.

It is very advisable to prevent into running issues like this. However when they occurs there are some possibilities how to deal with this situation.

1. Situation first needs to be analyzed e.g. by ABAP report ANALYZE_RSZ_TABLES.

2. Query can be copied to completely new name with help of t-code RSZC and then re-transported. Query with old tech name shall be deleted (e.g. t-code RSZDELETE).

3. If query (or it parts) needs to be preserved a ABAP report RENAME_DUPLICATE_ELEMENTS can be used to rename the query and/or its components. 

4. While transporting the query a parameter of RSADMIN table called QDEF_NO_DUPLICATE can be defined in order to prevent a situation when query component with the same technical name and different UID that already exit in the target systems is written.

More information:

How to look up COMPID for BEx Query based on GENUNIID ?

Strange entries in table RSRREPDIR

907025 - Duplicated technical names (COMPID) for query components

1551586 - Duplicated technical names of query components

5541024 - Duplicate query names in the BW system (BW 3.x related Note)

1765828 - Unique technical names for SAP Business Content queries

2061998 - Deletion of a query during transport does not delete an entry in RSRREPDIR

How to check if queries were deleted by tcode RSZDELETE?

Tcode RSZDELETE was used in BW system to either copy or delete BEx Query. In case it latter one and query is needed afterwards usually people start to ask who deleted and why.

To find out this a t-code SLG1 can be used. Basically the RSZDELETE generates logs under object ID = 'RSZ'. Function module 'RSDG_WRITE_PROTOCOL' is used for that.

So a call of the t-code SLG1 looks like:

And here’s and output in case of copying the query, deleting it and using report ANALYZE_RSZ_TABLES.

Different version of BEx query in runtime vs design time?

After query changes done in BEx Query Designer it may happen then these changes are not reflected in the frontend tools like BEx Analyzer or Analysis for Office. Buffering of BW tables is to be blamed for these types of issues. In particular it is important that table RSRREPDIR - Directory of all reports is not buffered. In some BEx versions the table was setup in way that it was buffered. In case there are more application servers in the BW system landscape then the other server which wasn’t used by the BEx Query Designer is reading the query definition from buffer which is not up2date.

Either the table is or is not buffered it can be checked in tcode SE11 -> Technical Settings -> Buffering. Correct setting here is “Buffering not allowed”.

 

Similarly in case of running BI frontend tool like BEx Analyzer or Analysis for Office on server with more than one application server there can be different results provided by the frontend tool. Again this can be due to table buffering.

More information:

958250 - Query displayed according to obsolete query definition

964390 - Different application Server shows different query result.

Delete Overlapping Requests from cube: SAME OR MORE COMPREHENSIVE vs OVERLAPPING

Within process chains there a particular process that can delete overlapping request from cubes. It is useful to use it case of scenarios where same data is being reloaded and staying same request in the cube would cause double data in reports.

While adding this process into the chain couple of settings need to be specified. What is crucial is to provide selection criteria for the request(s) to be deleted. There are two options on how to setup the request deletion in this process based on selection.

1. SAME OR MORE COMPREHENSIVE

Extract from the documentation:

Only delete if same/comprehensive selection conditions apply.

If you set this indicator, requests are only deleted from the InfoCube if the selection conditions of the new request are the same as or more comprehensive than the selection conditions of the request to be deleted.

 

2. OVERLAPPING

Extract from the documentation:

Also delete if partially overlapping select. conditions apply

If you set this indicator, existing requests are also deleted from the InfoCube if the selection criteria of the new request partially or wholly overlap the selection criteria of the request to be deleted.

Basically difference between the two is 1^st case (SAME) the request that shall be deleted must be the same as the one loaded this is also with regards to number of loaded records. Whereas in 2^nd case not all criteria need to match; it is less restrictive than 1^st case.