Thursday, January 11, 2018

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 

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

Wednesday, January 10, 2018

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?

Sunday, January 7, 2018

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:
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

Friday, January 5, 2018

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.

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.

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 1st 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 2nd case not all criteria need to match is it is less restrictive than 1st case.


Thursday, December 14, 2017

Usage of BAPI GetMembers

There is an MDX Function Module (BAPI) available in BW systems for retrieving data. Its name is BAPI_MDPROVIDER_GET_MEMBERS and it is sometimes referred as “GetMembers” BAPI. Sometimes it is worth to use this BAPI as it is used by frontend tools like WebI. While investigating inconsistencies in data provided by the WebI vs e.g. tcode RSRT the BAPI might be good starting point.

In below example I use technical content InfoProvider - 0TCT_MC01 Front-End and OLAP Statistics (Aggregated). Below is example call of the BAPI. The data is returned in table parameter called MEMBERS.

Import parameters            Value
CAT_NAM                         0TCT_MC01
CUBE_NAM                       0TCT_MC01/0TCT_MC01_Q0121
DIM_UNAM                       [0TCTBISBOBJ]
HRY_UNAM                       [0TCTBISBOBJ]
LVL_UNAM                        [0TCTBISBOBJ]
LVL_NUMBER                    01

Wednesday, December 13, 2017

Trace files for BEx tools

Frontend (BEx) tools of SAP BW are supporting recording of traces. Such traces can be useful for providing detail information for SAP support team in case creating incident via SAP Support Site.
How to enable generation of BEx tools trace files? 

In case of the “BEx tools” like Bex Analyzer, Bex Query Designer or BEx Report Designer there is an menu "BEx/Tools" -> "Global Settings" -> “Trace” tab, where set trace level to shall be set to "Verbose" value. Trace files are stored in folder X:\Users\user_name\AppData\Local\Temp\

Example of the trace file name:

In case of Analysis Office for MS Excel/PowerPoint the trece function can be enable via Analysis menu -> "Settings" -> Support tab. Trace files are stored in folder X:\Users\user_name\AppData\Local\Temp\Sap\Cof\
Example of the trace file name:

More information:
948489 - Customer Message requirements for BEx Report Designer
948487 - Customer Message requirements for Web Application Designer
585643 - Extended BW Component Frontend DLL-Usage Analysis

Friday, December 1, 2017

Skip Process Chain’s process – some details

I mentioned possibility of skipping Process Chain’s (PC) process or step in my older posts related to PCs - Automatic restart of failed PChain step and other PC improvements. While using it I found it very useful as it is possible to prevent failure of the PC. 

It happened to me recently that within one PC I skip the process. The PC was successfully finished because the broken process wasn’t executed. However after some time I have set the process to be skipped it I saw that that my PC is failing. I went to the PC itself and I realized that the particular process is not set to skip. Someone simply went to the PC and “un-skip” it. I was curious to learn when and who did it.

I found a table that stores the processes that re to be skipped. It is table RSPCCHAIN_SKIP – “Skipped processes”. But it was my unpleasant surprise that information on who and when the particular process was set to skip is not there. Only information present there are like Process Type, Process Variant (Name), Sequence number, Skip Process. I found it strange to be honest. I tried to debug the particular functionality hoping there are some other tables logging on information I was looking for. I found methods _SET_SKIPPED of class CL_RSPC_FRONTEND. Here really only fields mentioned above are populated. Furthermore another method SET_SKIPPED of class CL_RSPC_CHAIN is called that updates the RSPCCHAIN_SKIP table.

Conclusion is that at the moment (speaking of BW version 74 SP 09) there is no possibility to find out who and when set/unset Skip of process with the PC.

I followed up and wanted to post this missing functionally to SAP idea place as suggestion for future product improvements. I learned that old site is now obsolete and content was moved to Customer Influence site. As per the Data Warehousing in General (CLOSED) suggestion page the SAP BW is “a stable and mature state now.” .. “we have come to the conclusion that there is no longer a need to keep this communication channel constantly open.” In other words do not dare to suggest any improvements to SAP BW – it is stable and matured enough :)