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

Issues while setting up SAP RFC Connector for NodeJS (node-rfc) connector

In one of my last posts I wrote about nodejs RFC Connector provided by SAP to connect SAP backend systems. The Connector works very well. However, while I was setting it up I faced few issues. I’m listing them here with solutions how to overcome them; perhaps it will be useful for someone else too.

1. Library MSVCP120.dll missing

One of prerequisites of nodejs RFC Connector is that SAP NW RFC SDK needs to be present on machine which will be used for making called to the SAP system. However sometimes SAP NW RFC SDK is not installed correctly on the machine. Basic check of the installation is to run command rfcexec. In case of issue there is an error like:

The program can’t start because MSVCP120.dll is missing...

Solution is to install Microsoft Visual C++ (2010, 2013, or newer depending on your OS platform) Redistributable component. Once installed there shall be following output of rfcexec:

2. NPM module xyz can’t be found

On attempt to run nodejs app using the Connector call there is a following error thrown:

Error: The specified module could not be found.

\\?\C:\nodejs\node_modules\node-rfc\build\rfc\rfc.node

Basically the node-rfc tries to find rfc.node in specific folder /build/rfc but it's not in there because by default when it is installed another subfolder is placed there. In my case on OS Windows it is the subfolder "win32_x64". Solution is to just move or copy the rfc.node file to one level up.

3. Issues related to path variable.

As mentioned in point no.1 SAP NW RFC SDK needs to be present on the machine where the calls will be performed from. The folder where the SDK is installed needs to be included in path variable e.g.:

How to call BAPI in SAP from nodejs app

Recently I used nodejs RFC Connector provided by SAP. The module called node-rfc provides bindings for SAP NetWeawer RFC Library. Via the library it is possible to call RFC enabled function modules residing in SAP NetWeaver based ABAP system from nodejs, leveraging SAP Remote Function Call (RFC) protocol. For installation of the module into your nodejs framework see here.

Below I provide two example nodejs apps showcasing possibilities to passing values to BAPI’s parameters like single values, structures and tables.

I think that the node-rfc module is great option how to interface with SAP systems from heavily used nodejs app like in case of web based apps.

You can find both examples on my github:

demo_BAPI_params1.js      usage of table and variable parameter

//demo prg to showcase usage of table and variable parameters of SAP's BAPI while called from nodejs app via SAP/node-rfc nodule

"use strict";

var rfc = require('node-rfc');

var abapSystem = {

    user: 'sap_user',

    passwd: 'sap_user_pwd',

    ashost: 'sap.nodomain',

    sysnr: '01',

    client: '800'

};

var client = new rfc.Client(abapSystem);

var MAX_ROWS = 3;

var SELECTION_RANGE_str = {

               PARAMETER: "USERNAME",

               SIGN:      "I",

               OPTION:    "CP",

               LOW:       "A*"

        };     

var SELECTION_RANGE_tab = [SELECTION_RANGE_str];

       

client.connect(function(err) {

    if (err) {

        return console.error('could not connect to server', err);

    }  

    client.invoke('BAPI_USER_GETLIST', {

                       MAX_ROWS: MAX_ROWS,

                       SELECTION_RANGE: SELECTION_RANGE_tab

        },

        function(err, res) {

            if (err) {

                return console.error('Error invoking BAPI_USER_GETLIST:', err);

            }

               console.log('Result BAPI_USER_GETLIST:', res);

        });   

});

demo_BAPI_params2.js      usage of structure parameter of SAP's BAPI

//demo prg to showcase usage of structure parameter of SAP's BAPI while called from nodejs app via SAP/node-rfc nodule

"use strict";

var rfc = require('node-rfc');

var abapSystem = {

    user: 'sap_user',

    passwd: 'sap_user_pwd',

    ashost: 'sap.nodomain',

    sysnr: '01',

    client: '800'

};

var client = new rfc.Client(abapSystem);

client.connect(function(err) {

  if (err) {

    return console.error('could not connect to server', err);

  }

  var IMPORTSTRUCT = {

    RFCDATA1: 'some value of structure field RFCDATA1',

    RFCDATA2: 'some value of structure field RFCDATA2'

  };

  client.invoke('STFC_STRUCTURE',

    { IMPORTSTRUCT: IMPORTSTRUCT },

    function(err, res) {

      if (err) {

        return console.error('Error invoking STFC_STRUCTURE:', err);

      }

      console.log('Result STFC_STRUCTURE:', res);

  });

});

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

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

Simple SAP related flow in MuleSoft application – BAPI based

Recently I worked for one integration focused assignment. We used integration platform from MuleSoft called Mule ESB (Enterprise Service Bus). The Mule ESB is a lightweight integration platform based in Java used to integrate different systems. As my background is mostly SAP and in this space the SAP has its own integration platform called SAP PI it was whole new world to me to work with the mule.

In next paragraphs I depict simple flow in the mule which calls a BAPI at the SAP side and shows the data returning by the BAPI. The application is started by triggering URL (http://localhost:8081/) on which HTTP Listener element listens. After that a call of the BAPI in the SAP is executed and returned data is written by Logger into the app’s web page where it was triggered from.

From configuration point of view there must be whole setup of ALE customizing done at the SAP side. At the mule’s side there is SAP Connector used in the flow. It is acting as trigger of the BAPI call. The BAPI name is specified in Object Name of the SAP Connector element’s properties. Along the Object Name also XML Definition (see below) needs to be provided. 

Here’s how the XML definition for BAPI looks like:

Here’s the mule app output:

Related post:
Simple SAP related flow in MuleSoft application – IDOC based

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 

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.

Sequencing of function modules execution

Recently I ran into the issue of having one standard SAP function module (FM) which needed to be followed by COMMIT. As you may know such FM do not create any data as the real date need to be posted by the COMMIT. My solution was to create custom ABAP report where I called standard FM first and then BAPI_TRANSACTION_COMMIT.

However later I realized that creation of ABAP report wasn’t necessary. There are feature of Tcode SE37 which allows to you execute several FMs in sequence. By this I can call standard SAP function module and then COMMIT one.

This feature is available on main screen of tcode SE37 under menu Function Module -> Execute -> Test Sequences. There is a pop-up window which allows you to specify the sequence of FMs:

More information:

Function Module Test Sequence SCN wiki

Online docu