Monday, February 10, 2020

SAP GUI 76

As of 25th of February 2019 a successor to GUI 7.5 (for Windows) was introduced. Following features are counted as a major or new enhancements:
As it is built on, Visual Studio 2017 that is supported by Microsoft until April 2022.

From user interface point of view:
It further supports Belize theme that can be used for all SAP products, which are presently supported by SAP.

Various improvements implemented for the support of SAP Screen Personas in SAP GUI. SAP Business Client Integration.

End user help for the SAP GUI is no longer delivered as .chm documents; instead, it is a collection of HTML documents.

Themes like Enjoy / Streamline / Tradeshow / System Dependent were removed from the delivery of SAP GU.

SAP UI Landscape is available as a replacement of saplogon.ini file as a contained for all SAP GUI related settings.

Restore & Clean-up” option available in Options of the GUI to allow restoring SAP GUI default settings and delete locally stored files.

Also in the options dialog and Import and Export of SAP GUI settings is now available.

Grid View (ALV) Control now offers an input history like edit fields or table control cells. The history persists per column and allows an easy re-use of values which are frequently entered by the user.

SAPPDFPrint is now integrated into the SAP GUI installation.


From GUI installation point of view:
Introduction of SAP GUI for Windows "core" patches and "delta patches". The core ones are now full installations of the SAP GUI and delta ones only contain those files which have been changed since the initial delivery. Notice that in this case you always need installation media called "Compilation" to install SAP GUI afterwards you can do deltas.

More information:
2600384 - New and changed features in SAP GUI for Windows 7.60

SAP GUI 75

As of 14th of August 2017 a successor to GUI 7.4 (for Windows) was introduced. Following features are counted as a major or new enhancements:
As it is built on, Visual Studio 2013 that is supported by Microsoft until April 2019 the SAP GUI 74 lifetime will be longer comparing to SAP GUI 7.40 (built on Visual Studio 2012).

From user interface point of view: It supports SAP Screen Personas 3.0. There are a "Fiori visual theme" introduced much for S/4HANA 1610 Feature Package. There is a new theme called Blue Crystal Theme as default available. SAP UI Landscape format is enabled by default as of SAP GUI for Windows 7.50.

Old and famous librfc32.dll is removed now in GUI 75. Due to architecture change within SAP GUI 75 all BEx tool are now using .Net Connector of version (NCo) 3 whereas in lower versions of the BEx tools the NCo version 2 was used. Thus, the RFC library has changed as well. See below SAP Notes for details:

2602275 - Where is librfc32.dll in SAPGUI 7.5?
2256415 - Adaptation of RFC controls (Logon, Function, Table and BAPI) to use SAP NetWeaver RFC Library

Support of HTTPS protocol to access GUI Security rule file saprules.xml SAP UI Landscape file.

More information:
2417687 - New features in SAP GUI 75

Sunday, February 9, 2020

How to find out who ran PC?

Today another blog post regarding process chains. It is about how to find out who ran the process chain (PC). There is a very useful t-code RSM37 that provides many useful information about BW workloads like jobs. The PCs are nothing else just a jobs from SAP basis point of view. Thus by a quick look into the RSM37 it is easy to find out who ran the PC.

Here how to do it:

RSM37 -> first search for all BW jobs -> find particular PC name by placing a filter at 2nd “Selection value” column -> if there are still many entries (because all steps in the PC are listed here) filter also process type column normally called “Value” e.g. filter as TRIGGER.


Similarly, one can go to PC log from t-codes like RSPC or RSPC1 and look at start variant of the PC. Then double click on corresponding basis job log and on that screen, again user who ran the PC is available at column called “Job Created by”.



Friday, February 7, 2020

BW jobs/work processes hanging within program SAPLSENA

BW system may face a strange situation where there are many jobs or work processes hanging and obviously doing nothing. They are called zombie processes and then hanging with ABAP programs like SAPLSENA, SAPLRSSM, SAPLRSSM_LOAD, SAPLRS_G or SAPLRS_GENERAL etc. During situations like this the BW systems gets slower, loads are not being finished etc. In addition, an unusual number of locks may be observed in t-codes like SM12. Issue is that the system entered into dead lock. One may try to kill those work processes manually in t-codes like SM66, SM50 or killing jobs in SM37. However, it will not help as they start to pile up again quite soon.

Generally speaking; a reason why the system entered into such a state is that massive run of parallel delta loads caused a long wait time of locks. This can be also observer in table RSREQDONE field LOCKWAIT and in tables RSREQDONE or RSICCONT. Other symptom can be that infoproviders involved within the data loads are carrying heavy numbers of requests. Consequently, an enqueue management of the load request administration is not up to date.

To prevent such a situation the key is to have the enqueue management of the BW system always up to date. There are many points to be considered in order to achieve this. They mostly vary on BW version. But generally speaking parallel delta loads need to be kept on reasonable level same as the number of requests in the administration of the infoproviders are to be kept reasonable.
For details per particular BW version see SAP Note 1827854.


More information:
1827854 - Enqueue/Lock during parallel data loads
653996 - Analysis of lock situations

Deleting overlapping requests

A process available in process chain called "Delete Overlapping Requests" is very useful feature within the administration of data targets. I blogged about it already here. This time I want to point to few situations that may occur while using the process mentioned.

First of all the "Delete Overlapping Requests" process in case of DTPs with respect type of the DTP. It is a common misunderstanding that only DTPs type of FULL load are supported. That would mean that in case the DTP is type of DELTA the deletion of overlapping request will not work even the deletion conditions are met. However, there is a way how to make it work. Depending on BW version a Notes like 1336410 (70SP22: Enhancements to CL_RSBK_DTP=>GET_ALL_BY_PROPERTY) and 1359397 (P22:PC:REQUDEL:Switching full variant to deleting delta DTPs) need to be implemented. Once it is the case, the "Delete Overlapping Requests" process works with delta enabled DTPs. Only drawback is that the DTPS must be set with indicator specifying that delta data is to be transferred only once. Also another option to try out is to first set the DTP to full mode in that way specify the DTP into the "Delete Overlapping Requests" process and afterward to set the DTP into delta mode.

Another interesting case can be; when "Delete Overlapping Requests" process works with DTP, which has Routines on its filter. Depending on filter’s field (infoobject) one needs to be careful while carrying out ABAP coding. Especially during populating range low/high value by using variables that are of different type as the field/infoobject. Because of ABAP nature while converting between different data types a value can be aligned to LEFT instead to RIGHT. Thus value that is aligned to other side is not recognized as correct value. See Note 2392079 ("Delete overlapping request" variant does not work properly if DTP has a filter routine) for specific example.


More information:
2753683 - "Delete overlapping requests" variant does not delete expected requests

Monday, February 3, 2020

BEx QD errors "BI system has version; 70000 is required" or "System is not a BI system"

After update of SAP GUI to version 75 there are below error popping up during startup of BEx Query Designer:

"BI system has version; 70000 is required"
or
"System is not a BI system"


This is caused by an architecture change within SAP GUI 75 where BEx tool are now using .Net Connector of version (NCo) 3 whereas in lower versions of the BEx tools the NCo version 2 was used. The SAP standard function modules like RFC_METADATA_GET / RFC_METADATA are used for data exchange between the BEx Query Designer and the SAP BW backend. To run the FMs user needs must have an authorization object S_RFC assigned.  Only this grants the user possibility to run the FMs.

To solve this the roles of the BW developers need to be extended with the mentioned authorization objects.

More information:
2577916 - Error "BI system has version; 70000 is required" or "System is not a BI system" occurs in Bex Analyzer after update to SAP GUI 750
Wiki - Checking Tx RRMX with SAP GUI 750/760

Sunday, February 2, 2020

BEx QD error: Hierarchy does not exist for InfoObject

BEx Query Designer may show a below error related to in consistent data in SAP BW hierarchy tables.

037(BRAIN) "The hierarchy &2 &3 &4 does not exist for InfoObject &1"

Issue typically lies within table RSRHIEDIR_OLAP. There might be an inconsistent entries in the table exit. Those entries can be fixed with a help of ABAP program RRHI_CORRECT_OSID_KTAB. 

In addition, depending on particular BW version root cause can be completely different. In case there is a hierarchy node variable that is used in the BEx Query and which is bound into hierarchy that does exist in development BW system but it doesn’t exit in target BW system (Q or P) the error may appear. Tricky part here is that simple re-assignment of the variable definition from non existing to existing hierarchy doesn’t help. Only way that solves the issue is to deletion of such hierarchy node variable and its recreation again from the scratch.



More information:

1900360 - BRAIN037 during query execution using a hierarchy with THJ
2177061 - Runtime Error RAISE_EXCEPTION in CL_RRHI_VIRT_HIER_SINGLETON - exception HIERARCHY_NOT_FOUND
2754938 - Enhancement of hierarchy correction report (rsrhiedir_olap)
2433852 - How to repair inconsistent Hierarchies

Thursday, January 30, 2020

Authorization relevant t-codes in SAP BW

Here’s a brief overview of BW authorization / security relevant t-codes.

Transaction Code     Short text
RSECADMIN            Manage Analysis Authorizations
RSECAUTH               Maintenance of Analysis Auth.
RSECAUTH02           Mass Maintenance - Analysis Auths
RSECENVI                Assignment Environment Authorization
RSECPROT               Maintenance of Analysis Auth.
RSECSY                   Mass Maintenance - Analysis Auths
RSU01                     User Maint. BI Analysis Auth.
RSUDO                    Execution as Other User
RSUDU                    Execution as Other User

More information:
2182164 - RSECADMIN Overview [VIDEO]
1234567 - The authorization log RSECADMIN
2552884 - HowTo: Bex query authorization analysis - decision tree
177875 - Authorizations for investigation of OLAP problems
2044628 - How to record and save an OLAP authorization trace using transaction RSECADMIN

Wednesday, January 29, 2020

Few remarks on usage of RSUDO / RSECADMIN t-codes

Suite of t-codes like RSECADMIN (central t-code Analysis Authorization management) and RSUDO (Execution as Other User) are very important while analyzing issues of production queries. Very important is feature of the RSUDO (btw it is very smart name of the t-code, similarly like on OS level – execute something on behalf of other user) which simply executes the BW report on behalf of other user.

Normally we can expect that while user A executes particular query on behalf of other user (let’s say user B) the query result should be the same as the same query is executed by user B directly.

However, such an assumption might be wrong. Especially it can be wrong on cases in where customer exit variable is used in the query definition or in user's authorization definition. Other case can be while a system variable sy-uname is used in customer exit variable coding.

Reason is that value of variable sy-uname can’t be converted in case one user executes the query on behalf of other. The system cannot change the sy-uname variable. Thus the A value of the sy-uname is in place for user A and B value for the same is in place for user B.

One of the solution how to avoid such a situation is to avoid usage of sy-uname in the customer exit coding. This can be done at least for cases when variable is used in the query definition or in user's authorization definition. By leveraging function module  RSEC_GET_USERNAME in coding a proper user name (the one of which analysis authorization should be evaluated ) can be retrieved.

See also help pop-up in t-code RSUDO available under button “How does this work”.



More information:

1914703 - Transaction RSECADMIN "Execute as User" has different BW query result compared to direct BW query execution result by this user