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

Unified Connectivity (UCon) framework part 2

I wrote about the UCon already few years ago see here: NetWeaver Unified Connectivity (UCON).
This post has refreshed info on the topic.

I introduced whitening / blacking (list) features of SAP in my older blog spot: White / Black Lists. In SAP terminology a securing of some of SAP objects is also called in as Unified Connectivity (UCON). It was introduced on NetWeaver platform in version 74. Very high level speaking the UCON is all about logging and blocking. By using the UCON only those of remote enabled function modules (RFM or BAPI) that are used in deployed scenarios are allowed to be executed. Execution of rest of them is forbidden and thus the NetWeaver system is secured on server side because possible attack to the system is reduced. 

To identify which RFMs are to be exposed and which are to blocked there are three phase process and toolset provided by the UCON. 

First of all, a system parameter ucon/rfc/active needs to be set in tcode RZ11 – system profile parameters. 

In 1^st phase (Logging) you need to identify objects that ae accessed from outside systems. Here a tool called ”Phase Tool Unified Connectivity” (tcode UCONPHTL, prog UCON_PHASE_TOOL) is used. Also CCMS contains SAP Unified Connectivity Monitor Templates that are supporting the tool. 

Now in 2nd phase (Evaluation) it checks whether objects are not interrupting deployed business scenarios by being blocked.  Also tcode UCONPHTL is used in here.

And finally in 3^rd phase (Activation) it needs to be confirmed that UCON checks will become effective. 

There is also possibility to override blocking settings of some RFM delivered by SAP. This is of course at your own risk. The ABAP program RS_RFC_BLACKLIST_CUSTOM can be used for that. By giving the RFM name to the program you can see what were original settings of the RFM. No need to add that all changes to the settings are logged. So by this way blacklisted RFM can be unblocked. The settings done by the program are transportable.

More information:

UCON documentation

UCON wiki

White / Black Lists

In general similar to any other industry or area of people's interests also in terms of SAP we talk about white and black lists.

Basically anything which is on the white list is approved or recognized or just simply speaking it is considered to be safe. On other hand anything which is on the black list is forbidden, unknown or just not safe.

In terms of SAP we can talk similarly here in here about programming objects. It can be also an access to certain objects where there are some objects that can be accessed (while list) and objects to which an access is denied (black list).

Let focus on e.g. RFC function modules. Some of them can be protected by authorization and therefore are on the white list. Access to some other RFC FM can be forbidden and they are put to black list. Usually the RFC FM are protected by authorization object S_RFC.

last update: 07/08/2018

Related information:
Unified Connectivity Framework - UCON

1664340 - Documentation of authorization object S_RFC is unclear

Tracing incoming RFC or why SAP user is getting locked?

There are many discussion threads on SCN dealing with issue of SAP user which gets locked frequently and reason of this it not know. I recently faced same issue. My SAP user I’m regularly using in one of my SAP system was locked. As I’m using my cloud provider to host the SAP system for me and every time I needed to write an email to provider to unlock the user. After few times of bothering them I obtained new user which I was using to unlock my regular user. I started to use that new user instead of my regular one however from time to time I needed to use the regular user and it was still locked. I decided to invest some time to hunt a mystery of why my regular user was getting locked.

As mentioned I started with having a look at SCN and elsewhere to get an overview what I should do to get the mystery solved. I came a across posts like:

·         this – suggesting to use tcode STAD

·         this – suggesting to use ST03N tcode

·         this – suggesting to use tcode SM19/SM20 – Audit logs

·         this suggesting to use tcode ST01

·         this suggesting to use CCMS

·         this / this suggesting to use report ZRFC_STATRECS_SUMMARY (or tcode STRFCTRACE in newer versions of NetWeaver see Note 931251)

·         and many others.

I went through all of them however I was not able to figure out what was an issue.

One thing was obvious from reviewing all the posts was that it happens because of some RFC call. I checked with rest of developers who shares the same SAP system with me but none of them was using my regular SAP user to run their automated tests. Only thing which was for sure was that in tcode SM21 I was getting entries like following:

7.11.2015

00:51:32 DIA  008 800 MYUSER US  1 User MYUSER locked due to incorrect logon

02:16:58 DIA  001 800 MYUSER US  1 User MYUSER locked due to incorrect logon

17:06:42 DIA  000 800 MYUSER US  1 User MYUSER locked due to incorrect logon

I tried to setup few system profile parameters to increase level of logging. After every such an attempt I unlocked my regular SAP user and I waited to get user locked and I reviewed logs but not a chance to reveal the mystery.

Finally I ran to SCN post which suggested to setup following profile parameter:

rfc/signon_error_log to value 2

The parameter causes that when the RFC logon fails the SAP system create an ABAP dump with all the call’s detail. The ABAP dump is called “CALL_FUNCTION_SIGNON_REJECTED” and it basically provides all information that helps to identify the FCR call causing the issue:

Category               Installation Errors

Runtime Errors         CALL_FUNCTION_SIGNON_REJECTED

Date and Time          08.11.2015 18:11:32

 Short text

     You are not authorized to logon to the target system (error code 53).

Meaning:

53   PASSWORD_ATTEMPTS_LIMITED  Lock counter exceeded

Server-Side Connection Information

Client.............. 000

User................ "SAPSYS"

Transaction......... " "

Call Program........."CL_BGRFC_SUPERVISOR_START=====CP"

Function Module..... "BGRFC_CHECK_SCHEDULERS"

Call Destination.... "xxxx_RFC"

Source Server....... "abcserver_SID_sysno"

Source IP Address... "1.1.1.1"

Based on “Call Program” I was able to identify the thing which was causing the issue. Once I entered proper password to RFC destination actually used for bgRFC in tcode “SBGRFCCONF - bgRFC Configuration” issue disappeared and the mystery was solved!

Definition of BAPI

BAPI or Business Application Programming Interface is standardized programming interface that allows external access to business processes and data in SAP System. SAP defines it further object in Business Object Repository (BOR) as methods of SAP business objects or SAP interface types. The BAPIs offer an object-oriented view of business components in the SAP system. They are implemented and stored as RFC enabled function modules in the Function Builder of ABAP Workbench.

The BAPIs are here since 1996 (with R/3 release 4.5*) where the concept was introduced. Having said that BAPIs are RFC enabled function modules is not enough. There are further criteria that BAPI must fulfill. Let's have a look at them.

1. BAPI naming convention - technical name must start with BAPI_*.

2. The BAPI must implement method of an SAP Business Object (e.g. financial document, sales order, etc.)

3. The BAPI must maintain static interface through different version of SAP systems

4. It must be enabled for remote (RFC) execution.

5. It must run to completion without need for any secondary user interaction. There is no connection to SAP via SAP GUI. Therefore complete completion of data changes (if any) is required.

6. The BAPI must handle all errors by itself. If situation potentially may lead to inconsistent state of data an ABAP statement RAISE must not be used. Else it would terminate the function immediately leaving the data and the function processing in undefined state.

7. It must not cause ABAP session change. There must not be used any ABAP statement which may cause current Logical Unit of Work (LUW) within SAP User Roll Area to terminate.

According SAP all 7 criterions are adhered by SAP.  Criterions no 4 - 7 must be followed also by customer while developing custom BAPIs. Moreover only SAP objects can follow criterions 1 - 3.

In closing words I'd like to point out that BAPIs were are not designed to cover API as we traditionally know this term. Even they are very often referred as API they basically do not completely comply with the API definition. Usually SAP BAPIs are missing some of API paradigm (e.g. communication based on web protocols; abstracts consumer from the backend app; placed on wrong abstraction level; functionality is duplicated by several BAPIs doing the same; etc.). Therefore it is important that we look at the BAPI as evolution that happened in SAP while striving to enable external data access.

Useful information:

sap.com/bapi

BAPI User Guide (CA-BFA)

Programming Create() BAPIs 

Programming Change() BAPIs

Programming Delete()/Undelete() BAPIs 

Programming Cancel() BAPIs 

Possible issues in RFC call between (non)UniCode systems

We can assume that nowadays most of SAP systems are running as UniCode enabled systems. However this wasn’t the case in past. Unicode conversions of SAP systems started around year 2005. As of NetWeaver 70 all SAP systems are shipped as UniCode. 0And still you may experience SAP system running as none UniCode complaint. Whole point of having UniCode SAP system is to enable cross language character set for international data processing. Basically this was driven by companies going multinational and pursuing of globalization.

What are the things one can face in case there are interfaces running between systems which all are not Unicode? A case can be that there is a function module (RFC one - BAPI) placed in SAP system A. The function module is called remotely from another SAP system – B. Systems A and B are not both Unicode complaint. While RFC data transfer between the two a character data based on different code pages are damaged. This is caused because partners are not both UniCode. In case conversion of particular character didn't succeed then the character is replaced e.g. by #.  This basically means that data is not readable in target system; it is damaged and therefore not usable.

How to solve such a situation? The RFC data transfer converts data depending on the transport code page only. The transport code page is independent of the code page the data are encoded in. What is the transport code can be set up in TA SM59 -> particular RFC -> UniCode tab. So basically by specifying of what the transport code is and how character conversion is supposed to take place we can avoid such issues.

PS: If you ever wonder how System Status popup is build I have information for you. Whole dynpro is coded by FM STATUS_ANZEIGEN screen no 700.

Further info:

547444 - RFC Enhancement for Unicode ./. non-Unicode Connections

Limitations of BAPI RFC_READ_TABLE

While working with BAPI RFC_READ_TABLE I came across following issue. In case I called the BAPI with input parameters where I specified very large table (e.g. MARA) I got exception DATA_BUFFER_EXCEEDED thrown.

I checked the ABAP code and what it does is that in case of data extracted for a row of table is larger than 512 bytes then exception is raised. This means function call limits extracted data to 512 bytes per row and there is nothing you can do about it.

However there is a kind of workaround available. There is another BAPI Z_AW_RFC_READ_TABLE which doesn't have that limitation. I found the other BAPI working perfectly. All of cases I tested I never got the same issue as with 1^st BAPI.

However you need to notice that the 2^nd BAPI although it is delivered by SAP is included in Z* namespace. The BAPI is included in development package ZDAV which belongs to BusinessObjects Data Integrator (BODS) Development Class. It is not clear to me why it is in Z* namespace. There is already few years after SAP acquired BO so SAP had already enough time to migrate it.

However I must admit that at least the issue is correctly described and documented via SAP Note: 1752954 - DATA_BUFFER_EXCEEDED error - Data Services.

How to trace RFC calls

Integration projects where we deal with different systems communicating between each other are pretty challenging. Comparing to other projects where everything happens in one system there is a huge effort to check if integrated systems are communicating together. This can be sometimes really tricky. Sometimes one cannot even be sure about single BAPI whether its call properly reached the system or not.

One of the ways how to simple check if RFC function residing in SAP (e.g. BAPI) was called can be achieved in TA ST05. Here it is possible to set so called RFC Trace. This is functionality which listens on calls from remote systems and tracks it down.

All what needs to be done to set this trace on, perform the remote call to SAP, deactivate the trace and analyze the trace results:

Limitations of SAP RFC

As said in previous post an RFC technique is heavily used within SAP systems and while SAP systems are communicating with external systems as well. When it comes to RFC based communication it caused some problems. This is due to the fact that also RF as every other technology has its limits.

Below I list potential issues within RFC and things can be done to solve or to forego them:

1. Delays while processing RFC calls by Registered Server Program on Gateway (TA SMGW): It can be observed e.g. by huge amount of IDocs in yellow status (status 30: delays transferring outbound IDoc from the layer to RFC layer). This may be caused by not utilizing all max connections that can are available. Solution is to increase max connection setting for RFC queue. To be done in TA SMQS: menu Go to transaction SMQS: menu Edit -> Registration and on next pop-up increase the "Max. Conn." field. More details.

2. While calling RFC enabled FM there is a ABAP dump: OPEN_TASK_LIMIT_EXCEEDED: This is due to insufficient check on available resources. You may want to configure open task limit using profile parameter rdisp/task_limit. Moreover check configuration of quota for RFC resource check by parameter rdisp/rfc_max_open_tasks. More details.

3. Getting errors like: "No WP block received" or "No APPC block received" or "No free block found in the WP Communication Area" in system log (TA SM21): Maximum number of RFC connections by parameter rdisp/max_comm_entries needs to be reviewed. More details.

4. No resources made available for parallelization with asynchronous RFC (dump RESOURCE_FAILURE): Some of following system parameters needs to be reviewed: rdisp/rfc_min_wait_dia_wp, rdisp/rfc_max_own_used_wp, rdisp/wp_no_dia, rdisp/rfc_max_queue, disp/rfc_max_login, rdisp/rfc_max_own_login, rdisp/rfc_max_comm_entries. See more details at help.sap.com

5. Time limit for execution of RFC call: As RFC calls are executed through dialog work processes it depends on max runtime allocated to a dialog workprocess in system. Therefore check system parameter: rdisp/max_wprun_time.

6. Max limit of supported simultaneous RFC connection: Review system parameter rdisp/rfc_max_login. More details.

7. Limitation of data volume passed back to calling app by RFC enabled Function Module: There is no limitation from data volume point of view. But the RFC should not time out processing the particular data volume. See point no 5.

SAP RFC

A lot of data is moved within SAP systems or while SAP systems are interfaced to/from external systems by RFC. RFC stands for Remote Function Call. Basically it means that one systems calls particular function (Function Module) in other system remotely. Needless to say that this functionality is heavily used within SAP.

If the SAP ABAP based (NetWeaver) system is called from other SAP ABAP based system then the system where the call of Function Module is supposed to take place as recognized by destination.

If non SAP ABAP system is calling SAP ABAP system then instead of Function Module programmed function is called. This function is delivered within SAP connector. It does simulate a function module. Depending on platform from where calling app sits there are multiple connectors for SAP available: JAVA, .NET. By this several programming languages are supported: JAVA, C/C++, C#, Visual Basic, PHP, etc.

The RFCs calls can be:

·        Synchronous - Remote function call that waits for the processing of the remote function to be completed

·        Asynchronous - the calling systems is not aware of how processing of the remotely called function ended

·        Transactional – RFC call flags the remote function to be executed and starts it with a COMMIT WORK.

NetWeaver Unified Connectivity (UCON)

See also part two of UCon here: Unified Connectivity (UCon) framework part 2

UCON is new connection framework in SAP NetWeaver aiming to deal also with security aspects of RFC (Remote Function Calls) calls from outside systems into SAP NetWeaver systems. The UCON framework reduces no of Remote Function Modules (RFM) which can be accessed or let say called from outside systems.

SAP ERP solution contains approximately 38k of RFMs. By default one can call all of them without any issues. As typically in customers production systems only few of them are needed so by utilizing UCON one can limit those RFMs which are needed.

What needs to be done in order to deploy the UCON?

- NetWeaver system where UCON will be used must have following system profile parameter UCON/RFC/ACTIVE set to 1.

- Set up and generate communication assembly (CA) in TA UCONPHTL.

- Schedule batch job SAP_UCON_MANAGEMENT to collect RFC statistic recording.

Notice that UCON is only available as of SAP NetWeaver version 7.4.

Further information:

UCON online docu

How-to videos

SCN doc about UCON

UCON overview presentation

Where to download librfc32.dll RFC library?

The librfc32.dll library can cause a lot of troubles. Also there are some issues in BW area especially with conjunction to BEx. I was blogging about one issue e.g. here. Some other examples can be with different BEx tools like Web Application Designer (WAD), Query Designer (QD), etc. where those tools cannot connect to BW backend.

Here I’m providing information how to determine current version of this library available on SMP and where and how to download it.

First notice that there are two version of librfc32.dll:

·         Classic RFC library: comes with all major SAP Basis releases: 6.40, 7.00, 7.10, 7.11, and 7.20. After end of maintenance period for SAP Release 7.10 this classic RFC version will be discontinued.

·         SAP NetWeaver RFC Library: introduced as of Basis: SAP NetWeaver 7.10

To determine which version of library is involved in your issue depends on operating system that your SAP system does use.

To finally download library you need to go to SMP’s alias: 

http://service.sap.com/swdc -> SAP Support Packages and Patches -> Browse our Download Catalog -> Additional Components -> SAP Kernel  -> SAP KERNEL 32 or 64 /UNICODE -> SAP KERNEL 46D or 6.40 or 7.00 or 7.10 -> your operation system -> Database independent.

In the list of files choose librfc_XX-yyyyyyyy.SAR.

OSS Notes reference:

413708 - The current RFC library

825494 - Platforms supported by the RFC SDK

-      2020-Feb-10 Update:

The classic librfc32.dll is no more within SAP 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

librfc32.dll troubles

Once you are working with SAP BW BEx tool and accessing different version of SAP BW you might encounter an error in BEx Query Designer says: “"Run-time error '-2147417848 (800010108)': Automation error The object invoked has disconnected from its clients".” 

BEx Query Designer crashes afterwards.

Solution is to replace the RFC library librfc32.dll stored in your \WINDOWS\system32 on the client PC with a proper version depends on you SAP GUI version:

620: Version >= 6206.6.1938.4727 (620x.x.x.4727).
640: Version >= 6400.3.79.4740 (640x.x.x.4740).
710: check the newest patch of SAP GUI on SAP FTP server.

See  this post to find out where to download librfc32.dll library.