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

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.

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