SAP Community - NW ABAP Remote Function Call (RFC)

From zero to hero security coverage with Microsoft Sentinel for your critical SAP security signals – Part 4

2023-07-06T10:42:19+02:00

👉🏿back to blog series or to GitHub repos with ready-to-run playbooks.

Dear community,

There are various problematic attack vectors for SAP backends, but only a few are as severe as losing access to the SAP audit log from your security tooling. In part 3 we discussed malicious deactivation of the SAP audit log. Now, what if the SAP RFC user to collect the audit log info gets locked, deleted, or disabled in any other way too?

At that point you are fully blind and might not even get the audit-log deactivation message anymore if the attacker is fast.

Today you will see an automated response flow to deal with that situation. But wait!

How about regular SAP or Sentinel Collector VM maintenance? How do we distinguish between normal operations and actual attacks?

Stay tuned – Azure Center for SAP solutions (ACSS) comes to the rescue🐕‍🦺⛑️ to wade through the false positives and emphasize the impactful true positives.

Fig.1 Overview remediation workflow for the Sentinel Collector attack scenario powered by ACSS

Cyber-attacks require the quickest possible reaction

The provided playbook posts an adaptive card to Microsoft Teams with a color-coded message scoring the likelihood of an attack based on the signals coming from the Sentinel Collector for SAP, and the SAP system state. The Azure Center for SAP Solutions provides a set of managed APIs to query such info in a scalable and secure way.

The playbook is wired to listen to the pre-built Sentinel alert “SAP - Data collection health check”. But you may customize yourself to whatever scenario you need.

In the scenario depicted in fig.1 the Sentinel Collector for SAP is healthy while SAP is running fine too.

That causes the playbook to raise the attack likelihood based on the alert “RFC LOGON FAILURE” to medium. After all there is still a little chance that someone unintentionally performed a breaking user setup change. Up to you to configure this as “high” or “OMG run for your lives” based on how likely you think that is in your landscape.

See here how to register your SAP system with ACSS and be ready for upcoming out of the box integrations.

In case the Collector or SAP would have been down, the likelihood of attack gets set to low with the suggestion to double check and investigate further through Sentinel, since this likely a planned maintenance or an outage.

See here how to communicate SAP maintenance via Microsoft Teams in an interactive way. Integration with the SharePoint list using the SID known to Sentinel enables you to enhance the presented flow further.

What else would you like to see here? Reach out or let me know in the comments.

Fig.2 Screenshot of adaptive card with Sentinel’s SAP incident in Microsoft Teams

As per the inferred info from the various sources, the playbook suggests a couple of options to remediate the situation. This is customizable according to your needs.

Let the community know what additional remediation paths you would like to see here. Happy to dive deeper.

The simplest option addresses the possible process glitch on the Collector VM. Hit the corresponding button (see lower section on above screenshot) to trigger an automatic restart of the VM.

Fig.3 Screenshot of Sentinel Collector VM restart logic

This suggested remediations (see fig.2) are a natural fit for the upcoming Microsoft Security Copilot. Will get into details once it gets more widely available.

The true power lies in the correlation of multiple signals in addition to the ACSS metadata leading to the event of the SAP Collector being "blinded"

Fig.4 Screenshot from Sentinel security video series about multi-staged attacks to SAP

In the above scenario you can see a sequence of alerts painting the larger picture of the attack from RDP activity to login attempts in various places leading to a successful data download from SAP sending the file to an unknown IP address. In addition to that Microsoft Defender already compiled which attacker group was responsible based on the attack footprint, techniques and tools used.

See the full video here.

Additional automation scenarios

Another popular RFC attack vector (Capture-Replay vulnerability in NetWeaver AS for ABAP; SAP security Note 3089413) can be addressed like this. How about blocking the user corresponding to that new SAP system connection? Have a look at part 1 of the series.

Last weeks publication in the German SAP security tech press re-inforces the need to deal with RFC vulnerabilites. Would you like to get the recommended security setting change for the function module "RFC_TRUSTED_SYSTEM_SECURITY" to be performed automatically from such a workflow? Or would you consider that too high a risk because it could be used to attack from a different angle?

Part 4 concludes the first wave of my blog series.

Looking to you now to request additional scenarios and share your own as Pull Requests on GitHub.

Final words

That’s a wrap 🌯today you saw another SAP security automation scenario in action. We deployed a playbook that scores potential attacks to the audit log ingestion pipeline of Microsoft Sentinel. The required signals to determine the severity of the alert are fed by Azure Center for SAP solutions to get reliable information about the operational state of SAP.

In case all involved systems are up and running while only audit log ingestion is impacted, there is a considerable chance for an ongoing attack. The playbook offers pre-configured actions to act immediately directly from Microsoft Teams.

That brings down the time to action while avoiding to “shoot” from the hip with security incidents when SAP is just down for maintenance. Whooza, whoooza Sentinel. Nothing to worry about 🧘🏻 ☮

This integration pattern overall is applicable to any SAP API. Got another SAP threat at your hands that needs automatic remediation? Let me know in the comments or reach out directly.

Cheers
Martin

Call Node.js or Python Functions from ABAP

2023-08-25T16:45:09+02:00

Node.js rich ecosystem offers plenty of functions and utilities. Using node-rfc server bindings, these assets can be consumed from ABAP, just like standard ABAP functions. SAP Open Source node-rfc connector and SAP NW RFC SDK Library make it possible.

For more info check the node-rfc server documentation and server examples. Example given here is for Node.js platform and it works the same way with Python, using PyRFC.

Background RFC protocol is currently supported for Python and work in progress for Node.js.

Node.js server source code: server-test-blog.mjs

ABAP client source code: zserver_stfc_struct.abap

How it works?

ABAP program can call an ABAP function in Node.js system, over SAP RFC protocol, just like when that function would be in ABAP system. The node-rfc server will route the ABAP RFC call to JavaScript function, registered for serving that ABAP function calls. ABAP function call parameters are automatically transformed to JavaScript and registered JavaScriot function is invoked. After JavaScript function is completed, result is automatically transformed to ABAP format and send back to ABAP client. All standard ABAP RFC call parameters can be used, like ABAP variable (JavaScript variable), ABAP structure (JavaScript "plain" object) or ABAP table (JavaScript array of "plain" objects).

Rather then manually defining ABAP interface the node-rfc server function, the node-rfc can re-use the signature of already existing ABAP function, or empty ABAP function can be created, just to define ABAP function interface for node-rfc server function..

Let try it in real systems, a notebook with Node.js supported LTS release and any new or old ABAP system.

ABAP function module signature for Node.js function

Let use the interface of ABAP function STFC_STRUCTURE, to call JavaScript function which we will create. The STFC_STRUCTURE expects one input structure, IMPORTSTRUCT and returns one variable, the RESPTEXT string and one structure, ECHOSTRUCT. There is also a table parameter RFCTABLE:

FUNCTION STFC_STRUCTURE.

*"----------------------------------------------------------------------

*"*"Lokale Schnittstelle:

*"       IMPORTING

*"             VALUE(IMPORTSTRUCT) LIKE  RFCTEST STRUCTURE  RFCTEST

*"       EXPORTING

*"             VALUE(ECHOSTRUCT) LIKE  RFCTEST STRUCTURE  RFCTEST

*"             VALUE(RESPTEXT) LIKE  SY-LISEL

*"       TABLES

*"              RFCTABLE STRUCTURE  RFCTEST

*"----------------------------------------------------------------------

Here is our Node.js function, to be called from ABAP using these parameters:

function my_stfc_structure(request_context, abap_input) {

  // inspect request context

  const attributes = request_context["connection_attributes"];

  console.log(

    "[js] my_stfc_structure context:",

    attributes["sysId"], attributes["client"], attributes["user"], attributes["progName"]);

  console.log("[js] my_stfc_structure input:", abap_input.IMPORTSTRUCT);

  

  // prepare response for ABAP client

  const echostruct = abap_input.IMPORTSTRUCT;

  echostruct.RFCINT1 = 2 * echostruct.RFCINT1;

  echostruct.RFCINT2 = 3 * echostruct.RFCINT2;

  echostruct.RFCINT4 = 4 * echostruct.RFCINT4;

  const abap_output = {

    ECHOSTRUCT: echostruct,

    RESPTEXT: `~~~ Node server here ~~~`,

  };

  console.log("[js] my_stfc_structure response:", abap_output);

  

  // return response data

  return abap_output;

}

Here is Node.js function call from ABAP client, from ABAP test report:

call function 'STFC_STRUCTURE' destination 'NWRFC_SERVER_OS'

  exporting

    importstruct          = ls_struct

  importing

    echostruct            = ls_struct

    resptext              = lv_resp

  tables

    rfctable              = lt_table

  exceptions

    communication_failure = 1 message lv_error_message

    system_failure        = 2 message lv_error_message.

To make this ABAP function call into Node.js work just like standard ABAP function call, following steps shall be done, covered in follow-up sections in detail

ABAP system: Configure RFC destination for node-rfc server

Node.js system: Configure node-rfc server connections to ABAP system

Node.js system: Create Node.js function to be called from ABAP and launch the server

ABAP system: Call Node.js function

Configure RFC destination for node-rfc server

Using transaction SM59 create RFC destination of type TCP/IP connection ("T"), like for example

RFC destination configuration - technical settings

If bgRFC protocol shall be supported by node-rfc server, configure the basXML serializer option here:

RFC destinatin configuration - bgRFC support

Configure node-rfc server connections for ABAP system

node-rfc server requires two RFC destinations for ABAP system, configured in sapnwrfc.ini file in Node.js system.

The first destination, "MME", is RFC client destination, the node-rfc can use to call ABAP functions. This client connection is used by node-rfc server to obtain ABAP STFC_STRUCTURE function definition, so that node-rfc server can automatically transform ABAP STFC_STRUCTURE call data to JavaScript and vice versa.

The second destination, "MME_GATEWAY", is RFC server destination, open after server is launched and used for listening on ABAP client requests.

sapnwrfc.ini

DEST=MME

USER=demo

PASSWD=welcome

ASHOST=system51

SYSNR=00

CLIENT=620

LANG=EN

TRACE=0



DEST=MME_GATEWAY

GWSERV=sapgw00

GWHOST=coevi51

PROGRAM_ID=RFCSERVER

REG_COUNT=1

Start node-rfc server

After SAP NW RFC SDK binaries are downloaded and installed on your Node.js system, you can create empty folder and install node-rfc

mkdir server

cd server

npm init -y

npm install node-rfc

Now the first server test can be done, to verify ABAP system connections. Create sapnwrfc.ini file in project root directory and create test script, like:

import {RfcLoggingLevel, Server} from "node-rfc";



// Create server instance, initially inactive

const server = new Server({

  serverConnection: { dest: "MME_GATEWAY" },

  clientConnection: { dest: "MME" },

  // Server options are optional

  serverOptions: {

    logLevel: RfcLoggingLevel.error,

    // authHandler: authHandler,

  },

});



(async () => {

  try {

    // Start the server

    await server.start();

    console.log(

      `[js] Server alive: ${server.alive} client handle: ${server.client_connection}`,

      `server handle: ${server.server_connection}`

    );

  } catch (ex) {

    // Catch errors, if any

    console.error(ex);

  }

})();



// Close the server after 10 seconds

let seconds = 10;



const tick = setInterval(() => {

  console.log("tick", --seconds);

  if (seconds <= 0) {

    server.stop(() => {

      clearInterval(tick);

      console.log("bye!");

    });

  }

}, 1000);

Now open again the NWRFC_SERVER_OS RFC destination using SM59 transaction and find "Connection Test" button

RFC destination - connection test

Start your test script in Node.js system and after server alive message press the "Connection Test" button. When RFC connection with ABAP system is working, the output looks like this:

RFC destination connection test output

Now when RFC connectivity is working let create Node.js function and call it from ABAP.

Create Node.js function to be called from ABAP and launch the server

Let add "my_stfc_structure" JavaScript server function, to receive ABAP calls of STFC_STRUCTURE function in Node.js system. Two additions are required in our test script, the server function implementation and registration.

Server function requires nothing special for node-rfc server, it shall implement only "plain" logic to calculate the response for ABAP client. Also promise can be returned.

The first parameter is request_context, just in case the function implementation shall consider it. The second parameter is JavaScript object with ABAP parameters, as defined by ABAP STFC_STRUCTURE function signature.

// Server function

function my_stfc_structure(request_context, abap_input) {

  const connection_attributes = request_context["connection_attributes"];

  console.log(

    "[js] my_stfc_structure context:",

    connection_attributes["sysId"],

    connection_attributes["client"],

    connection_attributes["user"],

    connection_attributes["progName"]

  );

  console.log("[js] my_stfc_structure input:", abap_input.IMPORTSTRUCT);

  const echostruct = abap_input.IMPORTSTRUCT;

  echostruct.RFCINT1 = 2 * echostruct.RFCINT1;

  echostruct.RFCINT2 = 3 * echostruct.RFCINT2;

  echostruct.RFCINT4 = 4 * echostruct.RFCINT4;

  const abap_output = {

    ECHOSTRUCT: echostruct,

    RESPTEXT: `~~~ Node server here ~~~`,

  };



  console.log("[js] my_stfc_structure response:", abap_output);

  return abap_output;

}

The server function is registered using node-rfc server "addFuncion" method, telling the server to route ABAP STFC_STRUCTURE function calls to JavaScript function "my_stfc_structure":

 server.addFunction("STFC_STRUCTURE", my_stfc_structure);

ABAP data transformations to/from JavaScript are done by node-rfc server automatically.

Our test script is now ready and the node-rfc server can be started, to serve ABAP client calls:

import { RfcLoggingLevel, Server } from "node-rfc";



// Create server instance, initially inactive

const server = new Server({

  serverConnection: { dest: "MME_GATEWAY" },

  clientConnection: { dest: "MME" },

  // Server options are optional

  serverOptions: {

    logLevel: RfcLoggingLevel.error,

    // authHandler: authHandler,

  },

});



// Server function

function my_stfc_structure(request_context, abap_input) {

  const connection_attributes = request_context["connection_attributes"];

  console.log(

    "[js] my_stfc_structure context:",

    connection_attributes["sysId"],

    connection_attributes["client"],

    connection_attributes["user"],

    connection_attributes["progName"]

  );

  console.log("[js] my_stfc_structure input:", abap_input.IMPORTSTRUCT);

  const echostruct = abap_input.IMPORTSTRUCT;

  echostruct.RFCINT1 = 2 * echostruct.RFCINT1;

  echostruct.RFCINT2 = 3 * echostruct.RFCINT2;

  echostruct.RFCINT4 = 4 * echostruct.RFCINT4;

  const abap_output = {

    ECHOSTRUCT: echostruct,

    RESPTEXT: `~~~ Node server here ~~~`,

  };



  console.log("[js] my_stfc_structure response:", abap_output);

  return abap_output;

}



(async () => {

  try {

    // Register server function

    server.addFunction("STFC_STRUCTURE", my_stfc_structure);

    console.log(

      `[js] Node.js function '${my_stfc_structure.name}'`,

      "registered as ABAP 'STFC_STRUCTURE' function"

    );

    // Start the server

    await server.start();

    console.log(

      `[js] Server alive: ${server.alive} client handle: ${server.client_connection}`,

      `server handle: ${server.server_connection}`

    );

  } catch (ex) {

    // Catch errors, if any

    console.error(ex);

  }

})();



// Close the server after 10 seconds

let seconds = 10;



const tick = setInterval(() => {

  console.log("tick", --seconds);

  if (seconds <= 0) {

    server.stop(() => {

      clearInterval(tick);

      console.log("bye!");

    });

  }

}, 1000);

When test script is started in Node.js system and ABAP test report calls STFC_STRUCTURE function in Node.js system, the test script output looks like:

ts-node ci/test/server-test.ts                                                                          (py3.11.4)  ✘ 1 main ◼

[js] Node.js function 'my_stfc_structure' registered as ABAP 'STFC_STRUCTURE' function

[js] Server alive: false client handle: 5554800128 server handle: 0

tick 9

tick 8

[js] my_stfc_structure context: MME 620 D037732 ZSERVER_STFC_STRUCT

[js] my_stfc_structure input: {

  RFCFLOAT: 0,

  RFCCHAR1: '',

  RFCINT2: 2,

  RFCINT1: 1,

  RFCCHAR4: '',

  RFCINT4: 4,

  RFCHEX3: <Buffer 00 00 00>,

  RFCCHAR2: '',

  RFCTIME: '000000',

  RFCDATE: '00000000',

  RFCDATA1: '',

  RFCDATA2: ''

}

[js] my_stfc_structure response: {

  ECHOSTRUCT: {

    RFCFLOAT: 0,

    RFCCHAR1: '',

    RFCINT2: 6,

    RFCINT1: 2,

    RFCCHAR4: '',

    RFCINT4: 16,

    RFCHEX3: <Buffer 00 00 00>,

    RFCCHAR2: '',

    RFCTIME: '000000',

    RFCDATE: '00000000',

    RFCDATA1: '',

    RFCDATA2: ''

  },

  RESPTEXT: '~~~ Node server here ~~~'

}

tick 7

tick 6

tick 5

^C

Calling Node.js function from ABAP

Here is ABAP test report for calling Node.js function, used in this example

*&---------------------------------------------------------------------*

*& Report ZSERVER_STFC_STRUCT

*&---------------------------------------------------------------------*

*&

*&---------------------------------------------------------------------*

report zserver_stfc_struct.



data lv_echo like sy-lisel.

data lv_resp like sy-lisel.



data ls_struct like  rfctest.

data lt_table like table of rfctest.



data lv_error_message type char512.



ls_struct-rfcint1 = 1.

ls_struct-rfcint2 = 2.

ls_struct-rfcint4 = 4.



insert ls_struct into table lt_table.

call function 'STFC_STRUCTURE' destination 'NWRFC_SERVER_OS'

  exporting

    importstruct          = ls_struct

  importing

    echostruct            = ls_struct

    resptext              = lv_resp

  tables

    rfctable              = lt_table

  exceptions

    communication_failure = 1 message lv_error_message

    system_failure        = 2 message lv_error_message.



if sy-subrc eq 0.

  write: / 'rfcint1:', ls_struct-rfcint1.

  write: / 'rfcint2:', ls_struct-rfcint2.

  write: / 'rfcint4:', ls_struct-rfcint4.

  write: / 'resptext:', lv_resp.

else.

  write:   'subrc  :', sy-subrc.

  write: / 'msgid  :', sy-msgid, sy-msgty, sy-msgno.

  write: / 'msgv1-4:', sy-msgv1, sy-msgv2, sy-msgv3, sy-msgv4.

  write: / 'message:', lv_error_message.

  exit.

endif.

When node-rfc server is running and this ABAP report started, the output looks like:

Node.js server call output

Error Handling

In case of error, the server function shall raise exception message and error message will be returned to ABAP, with RFC_EXTERNAL_FAILURE error code.

  throw new Error("my_stfc_function error");



  console.log("[js] my_stfc_structure response:", abap_output);

  return abap_output;

}

ABAP report output

ABAP test report - error

Logging

When activated, the log is saved in local file: _noderfc.log and above mentioned error looks like:

Error log

Enjoy calling Node.js function from ABAP 🙂

ABAP RFC connectivity from BTP Node.JS buildpack and Kyma

2023-10-26T16:14:54+02:00

ABAP RFC connectivity from BTP to ABAP systems is supported by SAP Cloud Connector, for Java runtime only. This blog describes the RFC connectivity configuration for BTP Node.JS runtime, so that Node.JS BTP applications can consume ABAP RFCs, as described in Deployment options section of Powerful web applications with old and new ABAP systems and related blogs.

Our "hello world" example is BTP Node.JS buildpack, with Express server, SAP/node-rfc and SAP NW RFC SDK.

The example source code: SAP-samples/node-rfc-samples//integration/noderfc_btp can be deployed on BTP or tested locally inside SAP/fundamental-tools/docker/btp_cflinuxfs4.Dockerfile docker container.

ABAP RFC connectivity from Node.JS on Kyma works practically out of the box, using SAP/node-rfc and SAP NW RFC SDK inside docker container. Try SAP/fundamental-tools/docker/cflinuxfs4.Dockerfile for example.

SAP NW RFC SDK on BTP

ABAP RFC connectivity from Node.JS is provided by SAP/node-rfc open source, which provides interface to SAP proprietary SAP NW RFC SDK

SAP NW RFC SDK

SAP NW RFC SDK is not included in SAP/node-rfc because of licensing and SAP Support Portal is the only allowed public distribution channel for SAP NW RFC SDK.

Shared SO libraries are required in runtime and must be registered at operating system level, using LD_LIBRARY_PATH env variable on Linux systems for example. Include files and shared libraries are both required for SAP/node-rfc build and re-build. The node-rfc rebuild can be triggered during BTP deployment, just like for other native Node.JS modules.

Express and SAP/node-rfc are standard NPM packages and BTP deployment is straightforward.

Preparation

We use this btp_cflinuxfs4 docker container and standard buildpack structure, with application in app folder. To make SAP NW RFC SDK available for SAP/node-rfc in cloud application, it shall be copied to app root folder for example:

Buildpack

During deployment, native NPM modules like node-rfc may be or must be rebuilt. The re-build process requires SAP NW RFC SDK includes and binaries and SAPNWRFC_HOME_CLOUD environment vaiable shell therefore point to SAP NW RFC SDK root folder, just like SAPNWRFC_HOME in on-premise case.

For run-time enablement, the LD_LIBRARY_PATH env variable shall point to RFC SDK "lib" folder, like in manifest.yaml:

---

applications:

  - name: rfcapp

    stack: cflinuxfs4

    env:

      SAPNWRFC_HOME_CLOUD: /tmp/app/nwrfcsdk

      LD_LIBRARY_PATH: /home/vcap/app/nwrfcsdk/lib

That's all, we are ready for testing.

Local test

$ cd buildpack/app

$ export SAPNWRFC_HOME=`pwd`/nwrfcsdk

$ export LD_LIBRARY_PATH=$SAPNWRFC_HOME/lib

$ npm install

$ node .



node .

HOME

/home/www-admin



SAPNWRFC_HOME

/home/www-admin/src/sap/node-rfc-samples/integration/noderfc_with_nwrfcsdk/buildpack/app/nwrfcsdk



SAPNWRFC_HOME files:

["include","lib","package.json"]



LD_LIBRARY_PATH





node-rfc

{

    "platform": {

        "name": "linux",

        "arch": "x64",

        "release": "6.4.16-linuxkit"

    },

    "env": {

        "SAPNWRFC_HOME": "/home/www-admin/src/sap/node-rfc-samples/integration/noderfc_with_nwrfcsdk/buildpack/app/nwrfcsdk",

        "RFC_INI": ""

    },

    "versions": {

        "node": "18.18.2",

        "acorn": "8.10.0",

        "ada": "2.6.0",

        "ares": "1.19.1",

        "brotli": "1.0.9",

        "cldr": "43.1",

        "icu": "73.2",

        "llhttp": "6.0.11",

        "modules": "108",

        "napi": "9",

        "nghttp2": "1.57.0",

        "nghttp3": "0.7.0",

        "ngtcp2": "0.8.1",

        "openssl": "3.0.10+quic",

        "simdutf": "3.2.14",

        "tz": "2023c",

        "undici": "5.26.3",

        "unicode": "15.0",

        "uv": "1.44.2",

        "uvwasi": "0.0.18",

        "v8": "10.2.154.26-node.26",

        "zlib": "1.2.13.1-motley"

    },

    "noderfc": {

        "version": "3.3.0",

        "nwrfcsdk": {

            "major": 7500,

            "minor": 0,

            "patchLevel": 12

        }

    }

}

BTP Deployment

When all works fine, let deploy

$ cd buildpack

$ cf push

Pushing app rfcapp to ...

Uploading files...

Instances starting....

Instances starting...



name:              rfcapp

requested state:   started

routes:            rfcapp.cfapps.eu10.hana.ondemand.com

last uploaded:     Thu 26 Oct 15:46:54 CEST 2023

stack:             cflinuxfs4

buildpacks:        

        name                                                       version   detect output   buildpack name

        https://github.com/cloudfoundry/nodejs-buildpack#v1.8.18   1.8.18    nodejs          nodejs



type:            web

sidecars:        

instances:       1/1

memory usage:    128M

start command:   npm run start:btp

     state     since                  cpu    memory          disk           logging            details

#0   running   2023-10-26T13:47:09Z   0.0%   54.9M of 128M   231.8M of 1G   0/s of unlimited

The app test route https://rfcapp.cfapps.eu10.hana.ondemand.com/ shows the same result as on premise test:

HOME /home/vcap/app SAPNWRFC_HOME /home/vcap/app/node_modules/nwrfcsdk

SAPNWRFC_HOME files: ["include","lib","package.json"]

LD_LIBRARY_PATH /home/vcap/app/node_modules/nwrfcsdk/lib

node-rfc { "platform": { "name": "linux", "arch": "x64", "release": "6.2.0-33-generic" }, "env": { "SAPNWRFC_HOME": "/home/vcap/app/node_modules/nwrfcsdk", "RFC_INI": "" }, "versions": { "node": "18.18.2", "acorn": "8.10.0", "ada": "2.6.0", "ares": "1.19.1", "brotli": "1.0.9", "cldr": "43.1", "icu": "73.2", "llhttp": "6.0.11", "modules": "108", "napi": "9", "nghttp2": "1.57.0", "nghttp3": "0.7.0", "ngtcp2": "0.8.1", "openssl": "3.0.10+quic", "simdutf": "3.2.14", "tz": "2023c", "undici": "5.26.3", "unicode": "15.0", "uv": "1.44.2", "uvwasi": "0.0.18", "v8": "10.2.154.26-node.26", "zlib": "1.2.13.1-motley" }, "noderfc": { "version": "3.3.0", "nwrfcsdk": { "major": 7500, "minor": 0, "patchLevel": 12 } } }

Connectivity

With RFC connectivity enabled in Node.JS on BTP, WS-RFC connection parameters and SAP Business Connector or Cloud Connector can be used for RFC connections to ABAP systems.

Securing external RFC connections, including certificate-based authentication

2023-12-07T09:18:50+01:00

In today's world of cyber-attacks and data leaks, security and encryption should be an absolute priority for any IT organisation. However, experience shows that this is not always the case. Mechanisms that bring security are still often seen as making work difficult and challenging to implement. The fact that a program was configured years before and there was never a problem is used as an excuse not to make changes. This is a very incorrect approach that can have serious consequences.

In this post, I will cover a topic perhaps quite niche for the SAP Basis administrator - securing connections from external non-SAP programs. An aspect that is often overlooked due to a gap in accountability. On the one hand, this is sometimes seen as outside the Basis scope. On the other hand, programs are sometimes configured by third party vendors not necessarily interested in the security of our system. I will try to show what we, as Basis administrators, can do to make the connection more secure.

Scope of consideration

In this post I will try to consider what mechanisms we can use to make an external connection secure. Of course, SNC/SSL-based encryption will be the focus as usual, but I will not limit myself to this technical aspect alone. As usual, I will also touch on topics that are on the borderline of responsibilities or even outside the typical scope of Basis, but important for understanding how the various mechanisms work.

I will discuss the topics of encryption, authentication using an SSL certificate, level of trust in a foreign CA, permissions, limiting network traffic. I will base my analysis on example programs from the SAP NetWeaver RFC SDK. I originally wanted to write my own simple program, but as Basis administrators we usually secure existing software and connections, so this is a more representative example.

Environment preparation

SAP server side

My test environment is ABAP Platform Trial 1909, based on S/4HANA 1909. The system is not the youngest, nor is it the oldest, but in the field of RFC connection security, not that much has changed over the years. So most of the insights will be valid for both older and younger systems.

The system has already been prepped for SNC and certificate-based authentication. I described this in my previous post "SAP-GUI Single Sign-On based on SSL certificates and SNC", so I won't repeat that part.

Client side

For the purpose of presenting the client program, I prepared a completely fresh Debian Linux system version 12. The rfcuser user was also created, in the context of which we will run the program that connects to the SAP server. Of course, you can use another Linux distribution as well, or even Windows, and the results will be similar.

SAP NetWeaver RFC SDK

SAP Note 2573790 describes where to get the library and briefly describes the installation process. I assume you can download it yourself from the Software Download Center, and I will describe the simplest installation method in a moment. I get two files, which I decompress in the rfcuser home directory.

rfcuser@sandboxn100:~$ unzip nwrfc750P_12-70002752.zip



Archive: nwrfc750P_12-70002752.zip



creating: nwrfcsdk/



creating: nwrfcsdk/bin/



inflating: nwrfcsdk/bin/rfcexec



inflating: nwrfcsdk/bin/startrfc

[...]

inflating: nwrfcsdk/lib/libsapnwrfc.so



inflating: nwrfcsdk/lib/libsapucum.so



inflating: SIGNATURE.SMF



rfcuser@sandboxn100:~$ unzip nwrfc750P12HF_2-70002752.zip



Archive: nwrfc750P12HF_2-70002752.zip



inflating: libsapnwrfc.so



rfcuser@sandboxn100:~$ mv libsapnwrfc.so nwrfcsdk/lib/

All files are located in nwrfcsdk folder. Next step is adding the folder to LD_LIBRARY_PATH environment variable. I can do this for current session, but to make this permanent, I add this to .profile file located in the user's home directory.

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:~/nwrfcsdk/lib

SAP user

I plan to establish a connection from an external program to my SAP system to perform some operations. It is easy to guess that I will need a user on the SAP system side to do this. So I'm creating an RFC user that the external program will use for operations on the system. I give it the top-secret password secure123, just for the purpose of this presentation, to keep things simple.

In addition to filling in basic user data, I set up the type to system or communication. In this case, it doesn't matter much. I leave the rest of the data default, including the lack of authorizations, because I'll come back to that in the next step.

The first, unsecured connection

Together with the SDK library, we get two sample programs - rfcexec and startrfc. Rfcexec connects to the SAP gateway and waits for incoming commands from the SAP system. I leave it for another occasion for now and will focus on startrfc.

The program connects to SAP and execute one of two function modules, related to EDI or display system information. In fact, I will focus on the last function today. The -i switch is responsible for calling it.

Let's call the program:

rfcuser@sandboxn100:~/nwrfcsdk/bin$ ./startrfc -h sandbox -s 00 -u rfcuser -p secure123 -c 001 -i

Error: No RFC authorization for function module RFCPING.

Sandbox is my SAP server hostname 00 is SAP instance number. 001 is a productive client.

Error is expected. In general connection is successful, because program reached checking authorization phase.

The principle of least privilege

Indisputably, the principle of least privilege is one of the most important elements of security and an absolute must when it comes to external connections. Keep in mind that a system is only as secure as its weakest component. Even if you secure your SAP system perfectly, an intrusion into a server independent of you that has rights to connect to SAP with a high level of privilege could result in data leakage or even damage to the system. So you should keep the level of RFC user privileges at the minimum level needed to operate. In fact, this should obviously apply to all users. However, for technical users, this rule is more often ignored for some reason. Do we trust programs more than people?

That's why I didn't give the RFCUSER any authorization at the beginning, and now I will build it from scratch. I check what the SU53 transaction reports for this user by selecting Authorization Values / Other User from the menu.

Apparently, the system first checked whether the user had access to the RFCPING function module. Since access was not explicitly granted, so the permissions for the entire SYST function group were also checked. Since I am very strict about permissions, I will build a role with minimal privileges in the PFCG tranaction.

I added this role to RFCUSER and repeated the connection test.

rfcuser@sandboxn100:~/nwrfcsdk/bin$ ./startrfc -h sandbox -s 00 -u rfcuser -p secure123 -c 001 -i

SAP System ID: A4H

SAP System Number: 00

Partner Host: vhcala4hci

Own Host: sandboxn100

Partner System Release: 754

Partner Kernel Release: 777

Own Release: 753

Partner Codepage: 4103

Own Codepage: 4103

User: RFCUSER

Client: 001

Language: E

This time the connection is fully successful and I get system information. Authorization is sufficient.

Certification authority

At this point it is worth saying a few words about how my system is configured. This is, in fact, already described in my previous post, but it doesn't do any harm to remind you of the basic information. The main certificate authority (OU=Security) signed the certificates of intermediate authorities - for servers (OU=Servers) and for users (OU=Users). The SAP server certificate was issued by the first one.

It's clear that the simplest solution would be to issue a certificate by an existing certification authority, but that would simplify our considerations a bit too much. Instead, I will assume that the certificate was issued by a completely independent group of certification authorities. So I will add three new to the existing ones, marked in blue in the diagram.

I won't focus on details, because you can go through this proces in my previous post, but let's go to the process of CAs creation and issuing RFCUSER's certificate. In practice, SAP administrators are usually not responsible for this part, so if you are not interested in issuing certificates, you can skip without hesitation to the next chapter.

Root CA key creation:

openssl genrsa -out AnotherRootCA/anotherca.key.pem 4096

Certificate generation:

openssl req -x509 -sha256 -new -nodes -key AnotherRootCA/anotherca.key.pem -days 3650 -out AnotherRootCA/anotherca.cert.pem

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Country Name (2 letter code) [AU]:PL

State or Province Name (full name) [Some-State]:kuj-pom

Locality Name (eg, city) []:

Organization Name (eg, company) [Internet Widgits Pty Ltd]:AnotherCompany

Organizational Unit Name (eg, section) []:Trustworthy

Common Name (e.g. server FQDN or YOUR name) []:Another Root CA

Email Address []:

Intermediate CA key:

openssl genrsa -out intermediateAppsCA/interApps.key.pem 4096

Certificate signing request:

openssl req -key intermediateAppsCA/interApps.key.pem -new -sha256 -out intermediateAppsCA/interApps.csr.pem

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Country Name (2 letter code) [AU]:PL

State or Province Name (full name) [Some-State]:kuj-pom

Locality Name (eg, city) []:

Organization Name (eg, company) [Internet Widgits Pty Ltd]:AnotherCompany

Organizational Unit Name (eg, section) []:Apps

Common Name (e.g. server FQDN or YOUR name) []:Intermediate Apps CA

Email Address []:



Please enter the following 'extra' attributes

to be sent with your certificate request

A challenge password []:*******

An optional company name []:

Certificate signature by the new root CA:

openssl x509 -req -in intermediateAppsCA/interApps.csr.pem -days 3650 -CA AnotherRootCA/anotherca.cert.pem -CAkey AnotherRootCA/anotherca.key.pem -CAcreateserial -out intermediateAppsCA/interApps.cert.pem

Certificate request self-signature ok

subject=C = PL, ST = kuj-pom, O = AnotherCompany, OU = Apps, CN = Intermediate Apps CA

RFCUSER key creation:

openssl genrsa -out intermediateAppsCA/rfcuser.key.pem 4096

Certificate signing request:

openssl req -key intermediateAppsCA/rfcuser.key.pem -new -sha256 -out intermediateAppsCA/rfcuser.csr.pem

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Country Name (2 letter code) [AU]:PL

State or Province Name (full name) [Some-State]:kuj-pom

Locality Name (eg, city) []:

Organization Name (eg, company) [Internet Widgits Pty Ltd]:AnotherCompany

Organizational Unit Name (eg, section) []:

Common Name (e.g. server FQDN or YOUR name) []:RFCUSER

Email Address []:



Please enter the following 'extra' attributes

to be sent with your certificate request

A challenge password []:********

An optional company name []:

Client.cnf for client certificates:

nsCertType = client

extendedKeyUsage = clientAuth

Certificate signing:

openssl x509 -req -days 365 -in intermediateAppsCA/rfcuser.csr.pem -sha256 -CA intermediateAppsCA/interApps.cert.pem -CAkey intermediateAppsCA/interApps.key.pem -CAcreateserial -out intermediateAppsCA/rfcuser.crt.pem -extfile intermediateAppsCA/client.cnf

Certificate request self-signature ok

subject=C = PL, ST = kuj-pom, O = AnotherCompany, CN = RFCUSER

Export certificate to PKCS12 format:

openssl pkcs12 -export -inkey intermediateAppsCA/rfcuser.key.pem -in intermediateAppsCA/rfcuser.crt.pem -certfile AnotherRootCA/anotherca.cert.pem -certfile intermediateAppsCA/interApps.cert.pem -out rfcuser.p12

Enter Export Password:

Verifying - Enter Export Password:

exportpassword123

As a result I got several keys and certificates, including the most important rfcuser.p12 file, which contains user's private key and certificate with the trust chain. The file is protected with exportpassword123 password. In real life scenarion this file you'll receive from your certification team.

Enforcing RFC encryption on system level

Ok, I know that forcing encrypted connections is not necessary for my connection to be encrypted. However, I will do it to show if the encryption works or not. Nevertheless, if you are ready to disable unsafe connections, I highly recommend making it permanent. In my case, the snc/only_encrypted_rfc parameter is sufficient, but you might consider setting a few others as well, such as snc/accept_insecure_cpic, snc/accept_insecure_gui, snc/accept_insecure_rfc, snc/only_encrypted_gui.

I can set the parameter to 1, which enforces encryprion for non-ABAP RFC connections. Higher levels enforces encryption for ABAP and intenal connections.

snc/only_encrypted_rfc = 1

Now the call should be rejected by the system.

rfcuser@sandboxn100:~/nwrfcsdk/bin$ ./startrfc -h sandbox -s 00 -u rfcuser -p secure123 -c 001 -t 3 -i

Error: Unencrypted communication is rejected by this system

It is no longer possible to establish an unencrypted connection.

SAP Cryptographic Library installation

To enable RFC connection encryption, it is necessary to install a cryptographic library. On SAP systems it is included along with the kernel, while here it must be installed separately. I go to the SAP Marketplace to see what the latest version is and download it. In addition, I need to get the SAPCAR program to decompress the archive. So in the end I choose 2 files and save them in a new cryptolib folder.

SAPCRYPTOLIBP_8553-20011697.SAR

SAPCAR_1200-70007716.EXE

It's time to unpack the library:

rfcuser@sandboxn100:~/cryptolib$ ./SAPCAR_1200-70007716.EXE -xf SAPCRYPTOLIBP_8553-20011697.SAR

SAPCAR: processing archive SAPCRYPTOLIBP_8553-20011697.SAR (version 2.01)

SAPCAR: 6 file(s) extracted

SAPCAR and the archive can be removed after extraction. Let's also start sapgenpse component to check if everything is fine.

rfcuser@sandboxn100:~/cryptolib$ ./sapgenpse | tail -10

Versions: SAPGENPSE 8.5.53 (Sep 22 2023)

CommonCryptoLib 8.5.53 (Sep 22 2023) [AES-NI,CLMUL,SSE3,SSSE3]

Build change list: 248172



USER="rfcuser"



Environment variable $SECUDIR is not defined!

Fallback selection of SECUDIR through HOME:

"/home/rfcuser/sec"

It would be good to set SECUDIR variable explicitly and add cryptolib folder to LD_LIBRARY_PATH variable. Let's edit .profile of the user.

rfcuser@sandboxn100:~$ cat .profile

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:~/nwrfcsdk/lib:~/secudir

export SECUDIR=/home/rfcuser/sec

Client PSE preparation

In the previous sections, I generated an SSL certificate for the RFCUSER. It was saved in the file rfcuser.p12. Even if you don't generate the certificates yourself, you will probably get a ready one from the certification authority in this format. In the SAP world we rather operate on PSE repositories, so with the help of sapgenpse I will convert PKCS#12 to PSE. I will perform all operations in the rfcuser user sec folder.

I prepared files, including certification authorities' certificates:

rfcuser@sandboxn100:~/sec$ ls -l

total 24

-rw-r--r-- 1 rfcuser rfcuser 2033 Nov 30 18:28 anotherca.cert.pem

-rw-r--r-- 1 rfcuser rfcuser 1911 Nov 30 18:29 interApps.cert.pem

-rw------- 1 rfcuser rfcuser 5875 Nov 30 18:28 rfcuser.p12

Let's import the p12 file into new repository and protect it with MyVerySecretPIN_1 secret PIN.

rfcuser@sandboxn100:~/sec$ ../cryptolib/sapgenpse import_p12 -x MyVerySecretPIN_1 -p SAPSNCS.pse -r anotherca.cert.pem -r interApps.cert.pem rfcuser.p12

Please enter PKCS#12 encryption password: *****************

Found key 'INDEX=0,SIG=YES,ENC=YES,MD5-FINGERPRINT=60A1 B7F2 4F30 C198 9457 D2C3 5FA4 7F8E,KEYID=57F11B35BBC963B83B3B65F2666726003D11A46F'

PSE "/home/rfcuser/sec/SAPSNCS.pse" was written

The PIN we can encrypt in cred_v2 file, which is kind of passwords repository. Later this can be used by tools to access the PSE file. I also update file permissions to more strict.

rfcuser@sandboxn100:~/sec$ ../cryptolib/sapgenpse seclogin -x MyVerySecretPIN_1 -p SAPSNCS.pse

running seclogin with USER="rfcuser"

Added SSO-credentials for PSE "/home/rfcuser/sec/SAPSNCS.pse"

rfcuser@sandboxn100:~/sec$ chmod go-rwx cred_v2

Finally I have below files with PSE and cred_v2.

rfcuser@sandboxn100:~/sec$ ls -l

total 28

-rw-r--r-- 1 rfcuser rfcuser 2033 Nov 30 18:28 anotherca.cert.pem

-rw------- 1 rfcuser rfcuser 114 Nov 30 18:37 cred_v2

-rw-r--r-- 1 rfcuser rfcuser 1911 Nov 30 18:29 interApps.cert.pem

-rw------- 1 rfcuser rfcuser 5875 Nov 30 18:28 rfcuser.p12

-rw------- 1 rfcuser rfcuser 5111 Nov 30 18:36 SAPSNCS.pse

Let's check what was saved in the PSE. I can see main certificate, signing CA and validity dates.

rfcuser@sandboxn100:~/sec$ ../cryptolib/sapgenpse get_my_name -p SAPSNCS.pse

SSO for USER "rfcuser"

with PSE file "/home/rfcuser/sec/SAPSNCS.pse"



Subject : CN=RFCUSER, O=AnotherCompany, SP=kuj-pom, C=PL

Issuer : CN=Intermediate Apps CA, OU=Apps, O=AnotherCompany, SP=kuj-pom, C=PL

Serialno : 72:7B:01:77:64:B6:60:0B:31:D7:6C:60:66:0A:B2:7E:AB:FD:77:B1

KeyInfo : RSA, 4096-bit

Validity - NotBefore: Thu Nov 30 17:54:25 2023 (231130165425Z)

NotAfter : Fri Nov 29 17:54:25 2024 (241129165425Z)

KeyUsage : none

ExtKeyUsage : ClientAuthentication

SubjectAltName : none

I can also confirm, that the trust list of the PSE is empty.

rfcuser@sandboxn100:~/sec$ ../cryptolib/sapgenpse maintain_pk -p SAPSNCS.pse -l

maintain_pk for PSE "/home/rfcuser/sec/SAPSNCS.pse"

PKList is empty.



Empty trusted list.

SAP user update

The next step is to prepare the RFCUSER user for SSO authentication. To do this, I update the SNC name field in the SNC tab in the SU01 transaction. At the same time, I can disable the option of logging in with a password.

sapnwrfc.ini

The sapnwrfc.ini file allows to configure connection parameters for RFC calls made with the SDK library. You can define parameters there, such as the details of the system you are connecting to, the method of authentication, or encryption. Of course, you can specify a username and password there, but I will be configuring a certificate-based SSO. So I create the sapnwrfc.ini file in the same directory as the startrfc program:

rfcuser@sandboxn100:~/nwrfcsdk/bin$ cat sapnwrfc.ini

DEST=a4htest

SNC_LIB=/home/rfcuser/cryptolib/libsapcrypto.so

SNC_MYNAME=p:CN=RFCUSER, O=AnotherCompany, SP=kuj-pom, C=PL

SNC_PARTNERNAME=p:CN=sandbox.mydomain.internal, OU=IT, O=MyCompany, C=PL

SNC_QOP=9

For readability, the file contains a minimum set of parameters. DEST defines the name of the connection, which must be referred to by the program making the connection. SNC_LIB defines which cryptographic library to use. SNC_MYNAME specifies the SNC name of the client. SNC_PARTNERNAME gives the SNC name of the SAP server to which we are connecting. SNC_QOP defines the scope of the SNC, where 9 defines the maximum available security level.

I can return to startrfc program and update required parameters. The most important one is -D, which defines connection name, consistent with sapnwrfc.ini definition.

rfcuser@sandboxn100:~/nwrfcsdk/bin$ ./startrfc -h sandbox -s 00 -D a4htest -i

You might notice that the parameters responsible for the username, password and client number have been removed. They are not required if the SNC string is unique, that is, only one user on one client in a given system has this specific SNC name assigned to it.

The connection name is essential when you are securing a application that you are not the author of. The most important thing is to find in the documentation or configuration options how to determine this parameter or how to define it. Once you know this you will most likely be able to enable secure connection and encryption, even if the documentation from the vendor does not mention anything about such feature.

Trust relationship

Ok, let's start the program to see what else is missing:

rfcuser@sandboxn100:~/nwrfcsdk/bin$ ./startrfc -h sandbox -s 00 -D a4htest -i

[Thr 139683030722496] Thu Nov 30 18:50:59:304 2023

[Thr 139683030722496] *** ERROR => SncPEstablishContext() failed for target='p:CN=sandbox.mydomain.internal, OU=IT, O=MyCompany, C=PL' [/bas/753_R 3638]

Error:

LOCATION CPIC (TCP/IP) with Unicode

ERROR GSS-API(maj): Miscellaneous failure

GSS-API(min): A2210223:Server does not trust my certificate

path

target="p:CN=sandbox.mydomain.internal, OU=IT, O=MyCompany,

C=PL"

TIME Thu Nov 30 18:50:59 2023

RELEASE 753

COMPONENT SNC (Secure Network Communication)

VERSION 6

RC -4

MODULE /bas/753_REL/src/krn/snc/sncxxall.c

LINE 3604

DETAIL SncPEstablishContext

SYSTEM CALL gss_i

The error message is clear - SAP server does not trust my certificate chain. What does it mean?

The situation is as follows - the client approaches the server with a certificate, which perhaps even matches the SNC name of some user in the system. But after all, such certificate can be issued by anyone and any subject can be defined. Therefore, it is very important that the certificate is known and accepted by the server. This can be a trust relationship defined directly - by adding this particular certificate to the list. However, it can also be defined at a higher level - by trusting the certification authority.

It is the administrator's decision, or more often security policies, at which level we establish the trust relationship. It is very convenient to add a specific CA to the trusted list and this is often the right way to go. However, be aware that this also has consequences. The organisation that issues the certificates receives the authority to authenticate users on our system.

When we are unable to trust the certificate authority, we are required to add the leaf certificate to the list. This usually brings with it quite an inconvenience - the need to renew each certificate as it approaches its expiration date. This requires coordination with the client and, with a larger number of certificates, can be very inconvenient, especially as end certificates usually have an expiry date of one year.

As I have full control over my certificate authorities, so I add Another Root CA to my trusted list in transaction STRUST.

Let's retry the connection.

rfcuser@sandboxn100:~/nwrfcsdk/bin$ ./startrfc -h sandbox -s 00 -D a4htest -i

[Thr 139834091542464] Thu Nov 30 18:58:31:277 2023

[Thr 139834091542464] *** ERROR => SncPEstablishContext() failed for target='p:CN=sandbox.mydomain.internal, OU=IT, O=MyCompany, C=PL' [/bas/753_R 3638]

Error:

LOCATION CPIC (TCP/IP) with Unicode

ERROR GSS-API(maj): Miscellaneous failure

GSS-API(min): A2200223:Peer certificate path not trusted

target="p:CN=sandbox.mydomain.internal, OU=IT, O=MyCompany,

C=PL"

TIME Thu Nov 30 18:58:31 2023

RELEASE 753

COMPONENT SNC (Secure Network Communication)

VERSION 6

RC -4

MODULE /bas/753_REL/src/krn/snc/sncxxall.c

LINE 3604

DETAIL SncPEstablishContext

SYSTEM CALL gss_init_sec_context

There is still an error, but different one. This is also related to trust, but in opposite direction. Now client doesn't trust server. I need to add SAP system certificate or better it's CA to the client's trusted list. Let's go to SECUDIR and add it to PSE.

rfcuser@sandboxn100:~/sec$ ../cryptolib/sapgenpse maintain_pk -a ca.cert.pem

Please enter PSE PIN/Passphrase: *****************

maintain_pk for PSE "/home/rfcuser/sec/SAPSNCS.pse"

----------------------------------------------------------------------------

Subject : OU=Security, O=MyCompany, SP=kuj-pom, C=PL



PKList updated (1 entries total, 1 newly added)



rfcuser@sandboxn100:~/sec$ ../cryptolib/sapgenpse maintain_pk -a interServers.cert.pem

Please enter PSE PIN/Passphrase: *****************

maintain_pk for PSE "/home/rfcuser/sec/SAPSNCS.pse"

----------------------------------------------------------------------------

Subject : OU=Servers, O=MyCompany, SP=kuj-pom, C=PL



PKList updated (2 entries total, 1 newly added)

I have to know PSE password to modify it.

You can always your trusted list with below command:

rfcuser@sandboxn100:~/sec$ ../cryptolib/sapgenpse maintain_pk -l

Now I can test the connection once more.

rfcuser@sandboxn100:~/nwrfcsdk/bin$ ./startrfc -h sandbox -s 00 -D a4htest -i

SAP System ID: A4H

SAP System Number: 00

Partner Host: vhcala4hci

Own Host: sandboxn100

Partner System Release: 754

Partner Kernel Release: 777

Own Release: 753

Partner Codepage: 4103

Own Codepage: 4103

User: RFCUSER

Client: 001

Language: E

Success. Connection is possible with SSL based authentication. Encryption is obviously enabled.

Firewall

When we consider how to secure RFC connections, it is impossible to ignore the question of the firewall. It is obvious that also at the network level, we should only allow traffic from addresses that are allowed to communicate with our server. One question to ask is which ports are needed. There are two ports that are used by the Gateway, which is responsible for RFC communication - 33<NN>/tcp and 48<NN>/tcp. NN is instance number, in my case 00. 3300/tcp is used for unencrypted communication, while 4800/tcp is the secure gateway, where communication is encrypted. In my case, after configuring a secure connection, only 4800/tcp is needed.

However, there is one more port to be considered. It is opened by the message server, which is part of the ASCS instance, that in my case is number 01. So I would also consider opening port 3601/tcp on the firewall to allow load balancing using login groups.

UCON

The final option I wanted to recommend to make RFC connections more secure is Unified Connectivity (UCON). This is a mechanism that provides the ability to define a list of allowed remote function modules. This is related to the idea of reducing the attack surface. It is clear that systems only use a very small proportion of functional modules. As the software may contain security vulnerabilities and somewhere in the system someone may have set too broad permissions, it is worth implementing protection at a higher level. UCON introduces an extra layer of protection - even before the user's permissions are checked, it is verified whether the call is on the allowed list. However, UCON is a rather broad topic for a separate article.

Conclusion

RFC connections from external non-ABAP programmes can be secured on very many levels. Security should be a priority these days and unencrypted connections forbidden by any security policy. Although we often have less control over external programs, as you can see, quite a lot can be done in this area too.

Handling RFC in SAP Build - Process Automation

2023-12-28T12:34:38+01:00

Introduction

Hello,

I will be showing you How to handle RFC in SAP Build - Process Automation .

Scenario

We will be using a RFC to get data that we need in our automation.

Prerequisites:

Basic Knowledge about RFC

Basic knowledge about SAP Build

Basic knowledge about SAP Process Automation.

Step-by-Step Procedure:

Creating the RFC .

Creating the Process Automation project.

Consuming RFC in our project

STEP 1 : Creating RFC

Firstly we need to create our RFC according to our needs. Go to ' SE37 ' transaction and create your RFC. Do not forget to select Remote-Enabled Module processing type.

Image 1 - RFC Attributes

In my case, what I needed was the mail addresses of customer numbers I already had. So created my RFC to get mail addresses using company codes and customer numbers. You should set your parameters according to your needs.
You can see my parameters below.

Image 2 - Import Parameters

Image 3 - Tables Parameters

Image 4 - T_CUSTOMER Components

In my coding part I am finding mail addresses using the customer numbers and company code provided in T_CUSTOMER and filling ' MAIL ' component according to ' IV_ CHECK ' import parameter.

STEP 2 : Creating Process Automation Project

Now we are going to create our project.

Go to SAP Build cockpit and click create.

Image 5 - SAP Build Create Project

After that click ' Build an Automated Process ' and ' Task Automation ' . Give your project a name and configure your agent and we are all set.

STEP 3 : Consuming RFC in Project

Firstly we need to add BAPI SDK to our project. To do that go to settings and then Dependencies section. After that click Add Dependency and search for BAPI SDK.

Image 6 - Add Dependency

Now we need to create our Data Types based on our RFC parameters. The important part here is that Data Types must be created as structures, for my case I will be creating two Data Types , one for Import Parameters of my RFC and one for Tables Parameters.

Go to your Project Content and click Create then click Data Type. After that give it a proper name and lets set the Data Type.

Image 7 - Creating Data Types

Create your Data Types based on your RFC parameters. Here are my Data Types

Image 8 - Data Types

Now we can call our RFC from our project. Lets start building our project. You can see the general overview of project, I will be explaining each step.

Image 9 - Overview of Project

Firstly we need to establish our connection to SAP server where RFC exist. For that we are using Set SAP Connection (Basic) activity and filling it as needed.

Image 10 - Set SAP Connection (Basic)

To be sure whether we were able to connect to SAP system or not we are using Is SAP Connection Alive activity.

Image 11 - Is SAP Connection Alive

For next step we are creating our variable using the Data Types that we created.

Image 12 - Creating the RFC Import Variable

Image 13 - Creating the RFC Tables Variable

Now that we created our variables , we are going to fill these variables. Firstly we are checking if the SAP Connection is alive or not after that we are filling our variables as we need.

Image 14 - Filling Variables

Now we can execute our RFC and get the desired data. To call our RFC we are using Execute BAPI activity. And to reach our desired data we are using output parameter of Execute BAPI in a Custom Script activity as you can see below.

Image 15 - Execute RFC

Image 16 - Desired Data From RFC

Here is our mail addresses corresponding to customer numbers and company codes.

Conclusion

If you read the blog well congratulations ! You learned How to create a new project in SAP Build, How to create custom Data Types in a SAP Process Automation, How to consume a RFC in SAP Process Automation and much more.

If this blog is a help to you please like and share 🙂

Also Please do not hesitate to ask any further questions and feel free to share your feedback on the content.

Thank you!

- Metehan Dülger

Created a program to fetch customer details from AS400 system to SAP S4HANA via RFC FM

2024-02-28T13:31:37.538000+01:00

Creating a program to fetch customer details from an AS400 system to SAP S/4HANA via RFC (Remote Function Call) involves several steps. Below is a simplified example to illustrate the process. Note that you need the appropriate authorization and system connectivity settings for RFC communication.

Using Transaction SM59:

Log in to SAP GUI:
- Log in to the SAP GUI using the appropriate credentials.
Open Transaction SM59:
- Enter transaction code SM59 in the command field and press Enter.
Choose RFC Connection:
- In the SM59 screen, navigate to the "RFC Connections" folder in the left-hand tree structure.
Create RFC Destination:
- Right-click on the "RFC Connections" folder, choose "Create," and select the appropriate connection type (for example, "TCP/IP Connections" for remote systems).
Enter Connection Details:
- Fill in the required details for the RFC destination, including the connection type, the target system's IP address or hostname, and the system number.
Configure Logon & Security:
- Configure the logon and security settings. This might include specifying the user credentials that will be used for communication.
Additional Parameters:
- Depending on your scenario, you may need to configure additional parameters, such as language, code page, or other connection-specific settings.
Test Connection:
- Before saving the RFC destination, you can use the "Connection Test" button to check if the connection to the target system is successful.
Save the RFC Destination:
- Once the connection test is successful, save the RFC destination.
Activate and register the RFC Destination:
- After saving the destination, you may need to activate and register it. The activation ensures that the settings take effect.
Use the RFC Destination in ABAP Programs:
- You can use the created RFC destination in ABAP programs by calling the remote function modules defined in the target system.
  Create RFC-Enabled Function Module in SAP S/4HANA:
  - Create an RFC-enabled function module in SAP S/4HANA that will call the RFC function module in the AS400 system. This function module should take any necessary parameters, call the RFC function module in the AS400 system, and return the customer details.

FUNCTION zhr_fm_knb1_fico.
*"----------------------------------------------------------------------
*"*"Local Interface:
*"  IMPORTING
*"     VALUE(IM_KUNNR) TYPE  ZHR_TTY_KNB1 OPTIONAL
*"  EXPORTING
*"     VALUE(GT_KNB2) TYPE  ZHR_TT_KNB1
*"     VALUE(EP_MSG) TYPE  STRING
*"  TABLES
*"      GT_KNB1 STRUCTURE  KNB1
*"----------------------------------------------------------------------

  IF  im_kunnr  IS NOT INITIAL.

    SELECT  FROM knb1 FIELDS kunnr,
                            bukrs,
                            erdat,
                            ernam
                             WHERE kunnr in _KUNNR INTO CORRESPONDING FIELDS OF TABLE  _knb2 .

    IF  gt_knb1 IS INITIAL.
      ep_msg = 'No record found'.

    ENDIF.



  ENDIF.


ENDFUNCTION.

Creating a report program in SAP S/4HANA using the ABAP Editor (SE38) involves defining a report using the Report statement, fetching data from the database, and displaying the results. Below is a simple example of a report program that retrieves and displays data from knb1 table.

*&---------------------------------------------------------------------*
*& Report ZHR_RP_FM
*&---------------------------------------------------------------------*
*&
*&---------------------------------------------------------------------*
REPORT ZHR_RP_FM.

DATA: lv_kunnr TYPE kunnr.
*
SELECT-OPTIONS: s_kunnr FOR lv_kunnr.

  DATA: lt_range type RANGE OF kunnr.
     lt_range = VALUE #( sign = 'I' option = 'BT'
                       ( low = s_kunnr-low )
                       ( high = s_kunnr-high )
                     ).

DATA: lt_knb1 TYPE TABLE OF knb1,
      gt_knb1 TYPE TABLE of knb1,
*      gs_knb1 TYPE knb1,
      lv_msg TYPE string.


START-OF-SELECTION.

*
CALL FUNCTION 'ZHR_FM_KNB1_FICO' DESTINATION 'zhr_a4hana_to_s4hana'
  EXPORTING
    im_kunnr       = lt_range
 IMPORTING
   GT_KNB2        =  gt_knb1               "gs_knb1
   EP_MSG         = lv_msg
  tables
    gt_knb1        = lt_knb1
          .
IF sy-subrc <> 0.
* Implement suitable error handling here
ENDIF.


IF  gt_knb1[] is NOT INITIAL.
  cl_demo_output=>display( gt_knb1 ).          

ENDIF.

output:

give the input and click on execute button.

provide your user-id for s4hana along with password and click on enter.

it will display the desired output.

Create trusted RFC with specific technical user

2024-05-08T17:46:41.940000+02:00

As the SAP Basis administrator, we know that we can establish the trusted RFC between ABAP systems in which we can connect to the target system with our current user without providing the credentials like in screenshot below.

But what if we want to use a specific technical user and still want to benefit from trusted RFC? Actually, we can do it with the same method and I will show you how in this blog post.

First of all, since we need to create the trusted RFC, we need to establish the trusted relationship between systems through transaction code SMT1. In the scope of this blog, I’ll assume that we need to define the trust between system AA and BB.

1. Go to SMT1 Tcode on AA, and click the “Create” button to start the process.

2. Click “Continue”.

3. On the next screen, we need to provide the information about the target server and login information. It'll create a new RFC on the target server called "TRUSTING@<SID>xxxxxxxx".

4. On the following screens, just click on “Continue” and “Finish” on the final screen.

5. Now, it’s finished on the first system AA and you need to do the same steps on the second system BB.

Next, we need to make sure that the technical user on the source system has enough authorizations to allow the trusted call from the source system.

For that purpose, the user role needs to have the authorization object S_RFCACL. Below is the description of its field.

ACTVT: always 16. It’s the only value we can specify.
RFC_CLIENT: In this field, we can specify which client we allow to make the trusted connection. For example: the AA system has 3 clients 001, 002, and 003, but if we want to grant the trusted connection from client 002 only, then we need to specify here the value 002. The connection from clients 001 and 003 will be rejected.
RFC_EQUSER: This is the important field for making trusted RFCs with another user. In this case, we want to connect with a specific technical user, therefore we set it to value “N”.
RFC_INFO: the installation number of the calling system. We can set it to ‘*’, then the role can be used by multiple source systems, or you can specify here the list of installation numbers that allow you to create a trusted connection.
RFC_SYSID: SID of the calling system.
RFC_TCODE: Calling transaction code.
RFC_USER: ID of the calling user.
After finishing the role creation, please make sure that the role will be assigned to the technical user on the called system.
We have come to the final step. For details on creating the RFC in SM59, please refer to the SAP help documentation. In this blog, I’ll focus only on trusted RFC settings.
After specifying the target hostname and SID, go to the Logon & Security tab and set the Trust Relationship to “Yes”.
Now, instead of setting the checkbox at “Current User”, we will leave it blank and give the information about the technical user from the called system. Of course, the password is no longer necessary because we’re creating a trusted connection.

Save the connection and execute “Authorization Check”.

At this point, if you log in to the called system and go to TCode SM59. Then you will see the connection from the calling system but from that technical user, not ours.

I hope that blog will find you well. If you have any questions or concerns so far, feel free to contact me.

Creating RFC function module , Its Web services in SAP & Testing using SOAPUI.

2024-05-18T14:25:20.820000+02:00

Introduction:

By leveraging RFC, organizations can enable robust data exchange and process integration across different SAP and non-SAP systems.

However, creating RFCs is only half the battle. To harness their full potential, these RFCs often need to be exposed as web services, providing a standardized way for external applications to interact with SAP functionalities. This is where the power of web services comes into play, bridging diverse systems and enabling seamless, real-time data transactions.

But how can you ensure that these web services are functioning correctly? This is where testing tools like SOAPUI become invaluable. SOAPUI allows developers and testers to validate the performance, security, and reliability of web services before they go live, ensuring smooth and error-free operations.

In this blog post, we will dive deep into the process of creating RFCs in SAP, transforming them into web services, and rigorously testing them using SOAPUI. Whether you are a seasoned SAP professional or a newcomer looking to enhance your integration skills, this guide will provide you with the insights and tools needed to master SAP web services and ensure their optimal performance.

STEPS

Create a function group in SE80.

2.Provide the package name & click on SAVE.

3.Activate the FUNCTION GROUP.

4.Execute the T-code SE37 & Create a FUNCTION MODULE.

Give the Function group name, short description & click on SAVE.

Click on the Radio button REMOTE ENABLED MODULE

Take some importing parameters in order to receive the values as per the requirement.

Take one exporting parameter to return the message if the value is not found.

Take internal tables in order to store multiple data. Here, Gt_mara is referring to mara structure having some fields like MATNR, ERSDA & Gt_marc is referring to marc structure having some fields like MATNR, PLIFZ.

You can write your own logic to test the RFC FM, whether it returns some value or not.

Now, check the result by providing input values from MARA & MARC

12.now, create its webservice from function module.

13. Provide the service definition & description.

14. Below we can see the service definition properties. And activate it.

Execute the T-code SOAMANAGER in S4HANA.

Click on to the Webpages.

16.Provide your Hana-user id & Password.

17.Click on web service configuration.

18.Choose the object type as Object Name and pass the correct service definition name. If the service definition exists, then we can be able to see ‘entry found’ otherwise not found.

19.Now, Click on Internal Name --->Click on Create service.

20.Fill up the details like service & binding name, Provide security, SOAP protocol & Operation settings.

21.Fill up the provide security

22.No need to fill out SOAP protocol details so, click on next. In operation settings click on finish.

23.Then Choose the service & activated--> below interface will open--> click on save .

24.Select the service & click on republish

Click on save

26. Don’t provide any details, click on OK.

27. Click on the below Execute button under the WSDL generation.

28. Press CTRL+S and save the file in WSDL format.

29. Now, we are ready to test the service in SOAPUI. So, let's download the SOAPUI.

Notes:

how to Download the SOAPUI software & implement it.

Go to SOAPUI.ORG website and download SOAPUI open source.

Below is the interface of how the SoapUI looks like. can start doing the API testcases.
Click on soap-->new soap project--> give a project name -->choose the WSDL which we have downloaded -->ok

Click upon request1 then we can see the details in XML file.

To access the data, provide the authorization. Click on add new authorization.

Finally, we can see the result as shown below. For success the status code will be 200.

Technical User Propagation from JCo towards On-Premises

2024-05-22T15:06:16.024000+02:00

This blog lays out how to use a technical user instead of basic authentication from JCo based on the SAP Java Buildpack in CF towards on-premises.

Background

JCo retrieves an access token representing the technical user which is then be sent to the Connectivity service. This is similar to principal propagation, but in this case, a technical user is propagated instead of a business user. The retrieval of the access token performs the OAuth 2.0 client credentials flow, according to the token service configurations in the destination. Currently for JCo the token service generation supports basic authentication only. The token service is called from the Internet, not from the Cloud Connector.

Configuration

Generally speaking, the setup as described in the documentation stays the same, only the destination configuration in the Destination Service needs to be adjusted.

In the UI select the authentication type TechnicalUserPropagation. You now need to enter three values for:

jco.client.tech_user_id - the technical user name (client ID) which is forwarded towards on-premises and used for token retrieval
jco.client.tech_user_secret - the secret for jco.client.tech_user_id used for token retrieval
jco.client.tech_user_service_url - the URL of the token service, against which the token exchange is performed

Example

We are going to use the token of the XSUAA service instance here. We specified for the instance in the configuration JSON the xsappname as jco-technicalProp.

After the application binding we can retrieve the relevant parameters from the CF environment variables VCAP_SERVICES:

"clientid": "sb-jco-technicalProp!t77058"
"clientsecret": "TMsePptYQLSRf6qUWWt+l1D0rUQ="
"url": "https://cf.authentication.hana.ondemand.com"

Entering it in the Destination Service:

The token will now be forwarded to the Cloud Connector. Assuming all necessary basic steps for principal propagation are configured, we can configure a pattern to extract its name for the short-lived certificate:

The ABAP backend needs to maintain a user mapping for this technical user, in this case mapping it to the ABAP user SKYWALKER:

That's it!

How to Call RESTful APIs from SAP ABAP: A Step-by-Step Guide

2024-11-08T09:53:20.246000+01:00

Introduction to RESTful APIs:

RESTful APIs provide a simple way to interact with web services, making them a powerful tool for SAP developers. In this blog post, we'll explore how to call RESTful APIs from SAP ABAP, covering everything from setup to practical examples.
Some basic terms while calling API.
⦁ API: API stands for Application Programming Interface. Are set of rules that allow programs to communicate with each other.
⦁ REST: REST stands for Representational State Transfer. It is an architectural style for providing standards between systems on web which makes easier for systems to communicate with each other.
⦁ REST API: The API’s which follows REST methodologies for the communication. In this, communication is done in form of Request and Response. Response is nothing but a request from server to the client.

⦁ Request is made up of mainly 4 things
1) Endpoint: It is the URL you request for, it contains the target host and the prefix path.
2) Methods: Rest API generally uses four methods to communicate with server.

Methods
a) Get - This method is used to get data from the server
b) Post - This method is used to create new data entry on the server
c) Put - This method is used to update any data on the server. It will replace the entire resources with provided data.
d) Patch - This method is also used to update any data on the server like put only difference is it allow you to update specific fields or properties that you want to change.
e) Delete - This method is used to delete data from the server

3) Headers: Headers are used to provide authentication and provide information of the body content.
4) The Body: The data you want to send to the server is sent through the request body. This data is sent either in JSON format or XML format.

Prerequisites:
Ensure you have the necessary authorizations to call HTTP requests. You might need the following:
⦁ HTTP Service: Ensure that the HTTP service is enabled in your SAP system. This can be checked and configured in transaction SICF (SAP Internet Communication Framework).
⦁ Authorization: Make sure your user has the necessary permissions to make HTTP calls and manage the HTTP destination.

Setting Up the Environment:

After executing SM59 below screen will be visible.

1) ABAP Connections: Type 3 means Connection to ABAP System.
2) HTTP connection to External Server: Type G means we will connect SAP system with Non - SAP system or third party system.
3) HTTP connection to ABAP System: Type H means HTTP Connection to ABAP System
4) Internal Connections: Type I means connection to Application Server with Same Database.
5) Logical Connections: Type L means Reference Entry (Refers to Other Destination)
6) TCP/IP Connections: Type T means start External Program Using TCP/IP.
7) Connection via ABAP Driver: Type X means RFC Using Special ABAP Driver Routines.

Connecting SAP with Non - SAP System
So, we are going to connect SAP with Non - SAP system. For that we need to create RFC connection of type G i.e. HTTP Connections to External Server. Below is the procedure for creating connection.

1) Firstly, we need to click on create button as below.

2) After clicking on create button below screen will be visible. We need to enter target host i.e. URL of third party.

⦁ For HTTP connection.
- Give Service number (Port number) : 80
- Select SSL as inactive in ‘Logon & Security’.

⦁ For HTTPS Connection.
- Give Service number (Port number): 443.
- Configure proxy settings with help of BASIS team.
- Configure SSL certificate in t-code ‘STRUST’ with help of BASIS team.
- Select SSL as active and select ‘ANONYM SSL’ as shown in picture below.

(Difference between HTTP & HTTPS is HTTPS provides a secure, encrypted connection that helps protect your data and privacy, whereas HTTP does not.).

3) Then click on ‘Connection Test’ button on upper left corner in order to test the connection we are trying to establish. If following screen appears we can assume that connection is established successfully.

4) And after that we need to upload that SSL certificates if necessary using Transaction Code ‘STRUST’ under ‘SSL client SSL Clent (Standard) ‘as maintain below.

Making HTTP Requests from ABAP:

There is special class in SAP called ‘CL_REST_HTTP_CLIENT’ which can be used to communicate with REST API. In this class there are 2 methods for calling API.

1) 1st Method is ‘CREATE_BY_DESTINATION’

⦁ Step 1: First we have to create HTTP object for the URL destination we want to access.

Code:

 DATA: LO_HTTP_CLIENT TYPE REF TO IF_HTTP_CLIENT.

                                                           
       CL_HTTP_CLIENT=>CREATE_BY_DESTINATION (
           EXPORTING
               DESTINATION = 'E-Invoicing' "Name of the RFC destination
           IMPORTING
               CLIENT = LO_HTTP_CLIENT " HTTP Client object
           EXCEPTIONS                                                                
                ARGUMENT_NOT_FOUND = 1
                DESTINATION_NOT_FOUND = 2
                DESTINATION_NO_AUTHORITY = 3
                PLUGIN_NOT_ACTIVE = 4
                INTERNAL_ERROR = 5
                OTHERS = 6
                                                                   ).

⦁ Step 2: Set the method and version you want to use for the communication, here we have used POST method. And HTTP version as 1.0.

Code:

lo_http_client->request->set_method(if_http_request=>co_request_method_post ).
lo_http_client->request->set_version(if_http_request=>co_protocol_version_1_1 ).

⦁ Step3: Set request parameters, if any.

Code:

   lv_url = /test.com/ewb/enc/v1.03/authentication'.

       CALL METHOD cl_http_utility=>set_request_uri
           EXPORTING
              request = lo_http_client->request
              uri = lv_url.

⦁ Step4: Set the request header if any.

Code:

 CALL METHOD lo_http_client->request->set_header_field   
    EXPORTING
        IV_NAME  = 'Authorization'
        IV_VALUE = ‘l7xxba7aa16e968646b993426bsd6734h:201806034242’.

⦁ Step5: Set the type of data you want to send to request body. Below are some examples.

⦁ If you are sending JSON pass ‘application/json’.
⦁ If you are sending XML data pass ‘application/xml’ or ‘text/xml’.
⦁ IF you are sending multipart data pass ‘multipart/form-data’.

Code: (Here I am sending JSON file)

 LO_HTTP_CLIENT->REQUEST->SET_CONTENT_TYPE( 'application/json' ).

⦁ Step6: Pass actual data to the request. In following example lv_string contains JSON string which is we are going to pass to request.

Code:

   DATA : lv_string type string.

   LO_HTTP_CLIENT->REQUEST->SET_CDATA( LV_STRING ).

⦁ Step7: Send request to the API and receive the response.

Code:

call method lo_http_client->send             “sending request to API
   exceptions
      http_communication_failure = 1
      http_invalid_state = 2.

call method lo_http_client->receive           “receiving response from API
   Exceptions
      http_communication_failure = 1
      http_invalid_state = 2
      http_processing_failed = 3.

⦁ Step8: Read HTTP return code and the response. Example if 200 is a success return code, 500 for internal server error, 400 for bad request. In the below example we get the response from the API in the string ‘response’.

Code:

 DATA: http_status type string,
       Reason type string,
       Response type string.

call method lo_http_client->response->get_status
   importing
       code = http_status
       reason = reason.

response = lo_http_client->response->get_cdata( ).

2) 2nd method is 'CREATE_BY_URL'

⦁ Step 1: First we have to create HTTP object for the URL destination we want to access.

Code:

 DATA: lo_http_client TYPE REF TO cl_http_client,
       lv_url TYPE string,
       lv_response TYPE string,
       lv_status TYPE i.

lv_url = 'https://api.example.com/data'.

   cl_http_client=>create_by_url(
      EXPORTING
         url = lv_url
      IMPORTING
         client = lo_http_client
      EXCEPTIONS
         argument_not_found = 1
         plugin_not_active = 2
         internal_error     = 3
         OTHERS             = 4 ).

⦁ Step 2: Set the method and version you want to use for the communication, here we have used POST method. And HTTP version as 1.0.

Code:

lo_http_client->request->set_method( 'POST' ).
lo_http_client->request->SET_VERSION(if_http_request=>co_protocol_version_1_1 ).

⦁ Step 3: Set the request header if any necessary.

Code:

lt_http = VALUE #( ( name = 'accesstoken'  value = ‘12344566743’ )
                    ( name = 'apiaccesskey'  value = ’ER452DD234’)                                ( name = 'Content-Type'  value = 'application/json' ) ).

lo_http_client->request->set_header_fields( fields = lt_http ).
lo_http_client->request->set_content_type( 'application/json' ).

⦁ Step 4: Pass actual data to the request. In following example lv_string contains JSON string which is we are going to pass to request.

Code:

 lo_http_client->request->set_data( lv_string).

⦁ Step 5: Send request to the API and receive the response.

Code:

lo_http_client->send(                              “Sending the request
  EXCEPTIONS
      http_communication_failure = 1
      http_invalid_state        = 2 ).

lo_http_client->receive(                             “Receiving the response
   EXCEPTIONS
      http_communication_failure = 1
      http_invalid_state        = 2
      http_processing_failed    = 3 ).

⦁ Step 6: Read HTTP return code and the response. Example if 200 is a success return code, 500 for internal server error, 400 for bad request. In the below example we get the response from the API in the string ‘response’.

Code:

  Data: lv_response    TYPE  string,
        lv_http_return_code TYPE I .

                                                  lv_response = lo_http_client->response->get_cdata( ).
lo_http_client->response->get_status(IMPORTING code   = lv_http_return_code ).

Conclusion:
Connecting RFCs in SAP is a powerful way to integrate different systems and enable seamless communication across your SAP landscape. By following above steps you can set up your RFC.
Feel free to reach out if you have any questions or run into issues during your implementation.

How to Save a Lot of Time With the ABAP Connector (Transaction ACO_PROXY)

2024-12-31T22:42:01.243000+01:00

Introduction and Overview

Are you tired of creating large numbers of data types in your client-system when you call a remote enabled function module (RFM) by RFC and the data types of its parameters do not exist on the client? Let transaction ACO_PROXY do it for you. In a fraction of the time you need to create all these data types yourself, this tool, also called ABAP connector (ACo) and available as of ABAP 7.40, generates:

All data types of an RFM’s parameters as well as the parameters themselves and
A static global proxy class with a method that encapsulates the call of this RFM by RFC.

Note: You can also generate one ACo proxy class for RFC calls of several RFMs, if calling each of them with a different method of the same proxy class makes sense from a design perspective. Since, in principle, it is irrelevant to the explanations in this weblog whether a proxy class covers calls to one or many RFMs and in order to keep things simple, I explain the concepts and features of transaction ACO_PROXY using the case of generating a proxy that calls one RFM.

Reading this weblog,

You get an idea of how much time you save with ACO_PROXY by looking at a real-world example with a BAPI that uses hundreds of elementary data types in its interface. (“BAPI” is short for Business Application Programming Interface. You find some more explanation of this concept in the next section below.)

Note: Transaction ACO_PROXY performs a recursive analysis of all complex data types used in the relevant RFM’s interface down to the elementary ones and recreates all of them in the client system. Since this tool creates global data types, you can use them not only in your caller program, but in any program in your client system.

Get to know the few simple steps it takes to have this transaction create these data types and a proxy class.
You learn about some more options this tool offers such as instantiating the proxy class via a constructor vs. using a factory class or directly calling the proxy class vs. calling it via an interface etc. (again, all additional entities such as a factory class or an interface will be generated by this tool).
You get to know why you always should choose RFC’s fast serialization for new scenarios when calling RFMs via ACo proxy.
You see how little code is needed in the client program to call an RFM via an ACo proxy class.
You understand why, in most cases, you are better off with a static proxy – generated by transaction ACO_PROXY – than with a dynamic proxy – generated by an ACo API – and also why in one specific case the dynamic ACo proxy is a better choice.

Note: Two other use cases of transaction ACO_PROXY are just mentioned in this introduction, because the first one needs little explanation, and the second one is treated in great detail in a weblog of an SAP colleague:

Obviously, an ACo proxy class supports you in writing completely object-oriented code, when you need to call an RFM via RFC, because the call itself is hidden in the generated proxy class.
In the weblog How to generate a wrapper for function modules (BAPIs) in tier 2 my SAP colleague Andre Fischer discusses how you profit from an ACo proxy when you want to call a local RFM which is not C1-released in a program compliant with Clean Core guidelines: In this case, transaction ACO_PROXY generates a C1-released factory class, a C1-released interface for the ACo proxy class, and the proxy class itself. For all further details you are recommended to read my SAP colleague’s weblog.

How ACo Saves You a Lot of Time – a Real-World Example

Let us now consider a real-world example of using transaction ACO_PROXY:

Imagine yourself writing a client program which calls the BAPI BAPI_BUPA_ADDRESS_CHANGE by RFC to change the address of a business partner. Its interface has 8 importing and 38 table parameters, which all have complex data types, and neither the BAPI nor any of its data types exist in your client system.

Note: “BAPI” is an Acronym for “Business Application Programming Interface”. From a technical perspective a BAPI is an RFM for which SAP guarantees a stable interface. From a business perspective BAPIs are interfaces to business objects, which are implemented as function modules.

If we break all these complex data types down into their components, we get almost 800 elementary data types, which you all have to recreate in the client system – and on top of them also the 46 complex data types. Assuming that you are a fast developer, let us estimate that, on average, in ABAP Dictionary (transaction SE11), it takes you one minute to define an elementary data type and another 20 seconds per component to define a complex data type. Based on this very optimistic estimate, you need about 17 hours for this job.

When you are facing such a repetitive task, transaction ACO_PROXY is a game changer: Just enter the name of the relevant RFM and of a suitable destination as well as some other values in the tool. This is all it takes to make this transaction generate all the almost 800 elementary and 46 complex data types used in this BAPI’s parameters and a proxy class for an RFC call to the BAPI BAPI_BUPA_ADDRESS_CHANGE.

With transaction “ACO_PROXY”, it takes a few minutes to generate the many hundred data types in our example, compared to about 17 hours you need for this task without tool support. In fact, 17 hours is an optimistic estimate for such a job, actually creating all data types used in the parameters of BAPI BAPI_BUPA_ADDRESS_CHANGE might take far longer.

Basic Steps to Create a Static ACo Proxy

Let us now dive into the details of how to use this transaction. Below, there is a screenshot of ACO_PROXY’s UI with a few numbered labels, which refer to relevant input fields to be explained in this section. You will get to know also some more details of the transaction’s UI in the section to follow.

Picture 1: Transaction ACO_PROXY and its input fields

ACo transaction needs to know where to get the called RFM’s metadata (cf. label 1):

You select the option “locally” if the respective RFM is available on your client system.
In case you choose “by RFC”, you need to input a destination pointing to your target system or to another system that contains the relevant RFM.
If the respective metadata are to be retrieved via file upload, first get them into the relevant file. To achieve this, you also use the ACo tool’s “Get Metadata” options and, again, you choose between the two options “locally” and “by RFC”. Next, select “File” (cf. label 2) in the line starting with the label “Create” and then press the execute button or F8. In the popup shown next you input file name plus location and confirm.

Note: The option to get the metadata by RFC – whether you retrieve them directly from the remote system or upload them from a file that in turn has got them from the remote system - is needed if, for example, you want to generate an ACo Proxy call to an RFM that, in your landscape, is not available on any system whose release supports transaction “ACO_PROXY”.

Enter the name(s) of the RFM(s) for which ACo should generate a proxy with the data types of the RFM’s parameters (cf. label 3). (Surely you remember that you can create a proxy class to encapsulate the connections to one or many RFM depending on what suits your design best.)
Enter name and package of your proxy class (cf. label 4).
Define whether to create a proxy class for (a) a synchronous RFC call, (b) an asynchronous one with or without response / result method or (c) a bgRFC call. (cf. label 5) While using the synchronous RFC proxy is the self-explanatory default option, options (b) and (c) need some more explanation: As for option (b), an ACo proxy for an asynchronous RFC call with response also has a result method, and you need a sync point in your client program where it waits until the asynchronous response is available and where it can process the result once it is provided. Option (c), creating an ACo proxy that encapsulates a bgRFC call, requires prior creation of a bgRFC unit, which needs to be passed to the relevant method of the ACo proxy class.

More Options in Transaction “ACO_PROXY”

You can also choose:

Whether you prefer to create the proxy instance using a constructor or a factory class.
Whether you want to create an interface, in which case you have to enter its name. Selection of this option is enforced by the tool, if “Create Factory Class” is chosen.
(a) Whether you want to create a public instance method of the proxy class to encapsulate the RFC call or (b) Whether you prefer to use a private instance method to achieve this, in which case – in addition to the private method - also a public method is generated that, in turn, calls this private method.
(a) Whether you want to pass the destination name to the relevant proxy method when calling an RFM – which is the default – or (b) whether you want to pass the destination via constructor, in which case you should select the respective option. Note that, in the latter case, usage of interface IF_RFC_DEST is mandatory in SAP BTP ABAP Environment and SAP S/4HANA Cloud Public Edition.
Whether you want the called RFM(s) to throw class-based, classic or BAPI exceptions.
Whether you want to generate the relevant objects so that they can be used system -internally, in which case you select “C1 Release”. In this case, you should also define if you want to create only C1-released data types that do not already exist in the system. This is what the option “Do not Create Shadows of C1-released Types” is for.

Normally, you are almost done now. Just press “Execute” or F8 to generate:

A persistent proxy class.
An instance method that encapsulates the call of the respective RFM for each RFM covered by this proxy class a method and a constructor.
All complex and elementary data types of the relevant RFMs’ parameters.
(If you have made the respective choice) an interface and a factory class.

Always Choose the Correct Serialization in Destinations Used in an RFC Call via ACo Proxy

In an SM59 destination that is used in an RFC call via an ACo proxy you should always select these options in the tab “Special Options”:

“Protocol -> Serializer -> Fast serializer” plus
“Interface Check for Fast Serialization -> Destination for new scenario“

With any other serialization or interface check, you might run the risk of data corruption due to incorrect data offset, which might happen to a parameter with a structured data type if this data type differs between client and server system. Though the probability that this might occur is small, once it happens, it might corrupt a large part of the data in the relevant table or structure and thereby cause big harm. Therefore, it is important to always choose fast serialization for new scenarios in destinations used by an ACo proxy.

The Code to Call an RFM with an ACo Proxy

Now, let us call an ACo proxy in a program. Suppose you have created a proxy class zcl_rfc_system_info, which calls RFM RFC_SYSTEM_INFO via RFC, which needs the destination name in the constructor, and which you want to call in the same system.

This is how you instantiate this class and pass destination SELF to the constructor:

And this is the code to call this RFM using the proxy class instance:

Obviously, this code is self-explaining and does not offer any surprise for you ABAP developers.

Note: The name of the public instance method to call an RFM always is the name of the respective RFM. But there is no need to choose a proxy class name that contains the respective RFM’s name – as we do it in the example above.

Static vs. Dynamic ACo Proxy

There is also the option to create a dynamic ACo proxy class, and certainly you want to know, if there are use cases, in which a dynamic proxy might be advantageous over the static proxy generated by transaction “ACO_PROXY”. So, let’s start with a short description how dynamic ACo proxy works:

Note: For a code example of how to create and use a dynamic ACo proxy, look at the program SAP_ACO_EXAMPLE_DYNAMIC_PROXY – also delivered with ABAP 7.40. Developers familiar with using SAP JAVA and SAP .NET Connector will see that, in many respects, creating and using a dynamic ACo proxy class is similar to how you things work with these other two connectors.

Each time a program runs that uses a dynamic ACo proxy to call an RFM, this proxy is created via API based on the respective RFMs metadata. The dynamic proxy class is not persisted. For this reason, the parameters of the proxy class are always up-to-date, even after an upgrade of the server side involving changes to the respective RFM’s interface, which would require recreation of a static proxy. This, at first sight, appears to be a big advantage of the dynamic proxy over the static one. But in this case, appearances are deceiving:

If, for example, after an upgrade, the relevant RFM has additional input or output parameters, a developer has to adapt the client program’s code – be it to process additional output values or to pass values to the additional input parameters. But if developer action is required in any case – to extend the client program accordingly -, then it makes little difference whether or not the ACo proxy class also needs to be re-created as in the case of a static proxy: Compared to the effort required to adapt the client program, the additional effort needed to recreate the proxy class is negligible. Therefore, as to the case of changes to the RFM’s interface, what, at first sight, may appear to be a big advantage of the dynamic over the static proxy, in fact, carries no weight.

In contrast, the advantages of the static proxy are weighty:

Working with a static proxy is faster at runtime because it is created at design time and it can be re-used.
All global data types generated by the ACo transaction are statically available and therefore easy to use in a program while, in contrast, all program code using elements of the dynamic proxy must be completely dynamic, which is why using the dynamic proxy requires significant experience in dynamic programming.

Therefore, we arrive at the conclusion that, in most cases, you are better off using the static proxy. But – and this is the relevant exception -, you should choose the dynamic ACo proxy, if it is used in a completely dynamic framework. In all other cases, you should prefer the static proxy over the dynamic one.

Note: As with all RFC calls and no matter which kind of ACo proxy you use, after an upgrade of the respective the server system, you should have a look into possible changes of the respective RFM’s interface and also test the relevant connections. If needed, just recreate your static ACo proxy and – as required or useful for your client-program - adapt or extend the program’s code no matter which flavor of ACo you use.

Summary

After all, transaction ACO_PROXY

First and foremost, saves you a lot of time,
If you call an RFM on a remote system and if neither this RFM nor its parameters’ data types exist in the client system,
By generating a static proxy class as well as all relevant data types and parameters.

Normally, you are better off with a static than with a dynamic proxy class to be created by an ACo API. Only if the ACo proxy should be part of a fully dynamic framework, you should use dynamic ACo. In all other cases the static proxy is not only fully sufficient but even the better choice.

Just try it out and you will see: Transaction ACO_PROXY really is a big time saver.

NetWeaver RFC SDK: moving from Python to C

2025-01-06T19:19:37+01:00

As several users of the PyRFC Python bindings might have noticed, SAP decided to discontinue the project due to lack of internal resources and the impossibility of finding a new maintainer who might have access to NetWeaver RFC SDK source code to keep the bindings up to date, mainly due to the fact the SDK itself is not free & open software like its bindings.

Needless to say this is a very sad news for me, who is an avid user of the PyRFC package, but also for the Free & Open Software community who recorded another casualty due to non permissive licenses despite SAP believes in Free & Open Source. I hope this paradox will become clear, one day.

Moving (back) to C/C++

Python bindings were not just the only affected project, also Node.js and other bindings were discontinued as well, leaving no other choice of moving to either C or C++ to get official support from SAP, so I decided to try to convert one of my sample PyRFC scripts into a C program to be executed either in Linux or Windows. This is the original script in Python, which queries RFC_GET_SYSTEM_INFO to get system details:

from pyrfc import Connection
from pyrfc._exception import LogonError


conn_params = {
    'user': '***',
    'passwd': '***',
    'mshost': '***',
    'msserv': '***',
    'r3name': '***',
    'group': '***',
    'client': '***',
    'lang': '***'
}

try:
    conn = Connection(**conn_params)
    result = conn.call('RFC_GET_SYSTEM_INFO')
except LogonError as e:
    print(e)
    exit(1)

rfcsi = result['RFCSI_EXPORT']
print(f'RFCDEST: {rfcsi['RFCDEST']}')
print(f'PFCSYSID: {rfcsi['RFCSYSID']}')
print(f'RFCDBSYS: {rfcsi['RFCDBSYS']}')

conn.close()

This is the equivalent written in C, which is significantly larger in size and much more complex to read and understand, although it's been a while since I last touched the language and it could be there are easier ways to achieve the same results:

#include <stdlib.h>
#include <stdio.h>
#include "sapnwrfc.h"

#define NUM_PARAMS 8


int main(int argc, SAP_UC** argv){

	RFC_CONNECTION_PARAMETER loginParams[NUM_PARAMS];
	loginParams[0].name	 = cU("MSHOST");
	loginParams[0].value = cU("***");
	loginParams[1].name	 = cU("MSSERV");
	loginParams[1].value = cU("***");
	loginParams[2].name	 = cU("R3NAME");
	loginParams[2].value = cU("***");
	loginParams[3].name	 = cU("GROUP");
	loginParams[3].value = cU("***");
	loginParams[4].name	 = cU("CLIENT");
	loginParams[4].value = cU("***");
	loginParams[5].name	 = cU("USER");
	loginParams[5].value = cU("***");
	loginParams[6].name	 = cU("PASSWD");
	loginParams[6].value = cU("***");
	loginParams[7].name	 = cU("LANG");
	loginParams[7].value = cU("***");

	RFC_ERROR_INFO errorInfo;
	RFC_CONNECTION_HANDLE conn;
	RFC_FUNCTION_HANDLE funcHandle;
	RFC_FUNCTION_DESC_HANDLE funcDescHandle;
	RFC_STRUCTURE_HANDLE sysInfoHandle;
	RFC_RC rc;
	SAP_UC buffer[100];

	conn = RfcOpenConnection(loginParams, NUM_PARAMS, &errorInfo);
	if (errorInfo.code != RFC_OK) {
		printfU(cU("Connection failed: %s\n"), errorInfo.key);
	}

	funcDescHandle = RfcGetFunctionDesc(conn, cU("RFC_GET_SYSTEM_INFO"), &errorInfo);
	if (funcDescHandle == NULL) {
		printfU(cU("Error getting function description: %s\n"), errorInfo.message);
		exit(1);
	}

	funcHandle = RfcCreateFunction(funcDescHandle, &errorInfo);
	if (funcHandle == NULL) {
		printfU(cU("Error creating function: %s\n"), errorInfo.message);
		exit(1);
	}

	rc = RfcInvoke(conn, funcHandle, &errorInfo);
	if (rc != RFC_OK) {
		printfU(cU("Error invoking function: %s\n"), errorInfo.message);
		exit(1);
	}

	rc = RfcGetStructure(funcHandle, cU("RFCSI_EXPORT"), &sysInfoHandle, &errorInfo);
	if (rc != RFC_OK) {
		printfU(cU("Error getting RFCSI_EXPORT: %s\n"), errorInfo.message);
		exit(1);
	}

	RfcGetString(sysInfoHandle, cU("RFCDEST"), buffer, sizeof(buffer), NULL, &errorInfo);
	printfU(cU("RFCDEST: %s\n"), &buffer);
	RfcGetString(sysInfoHandle, cU("RFCSYSID"), buffer, sizeof(buffer), NULL, &errorInfo);
	printfU(cU("RFCSYSID: %s\n"), &buffer);
	RfcGetString(sysInfoHandle, cU("RFCDBSYS"), buffer, sizeof(buffer), NULL, &errorInfo);
	printfU(cU("RFCDBSYS: %s\n"), &buffer);

	RfcDestroyFunction(funcHandle, &errorInfo);
	RfcCloseConnection(conn, &errorInfo);

	return 0;

}

Quite surprisingly, the execution time is taking longer for the ELF binary derived from the C source rather than the interpreted Python script (0,8 seconds on average for the ELF binary against 0,7 seconds for the Python script), while normally ELF binaries are orders of magnitude faster than their equivalent in Python. Trying to analyze where the biggest performance impact is located, it seems the Unicode functions are taking a big portion of the load, which surprises me even more...

Final considerations

Converting my scripts from Python to C seems feasible, there's a learning curve to master as I need to familiarize again with C after many years of Python, but little by little I should be able to get there.

I would like to hear from you whether there are solutions for the Unicode inefficiency, some linking parameters I somehow missed perhaps?

Getting Started with SAP SNC for RFC integrations

2025-01-12T17:20:02.514000+01:00

Dear community,

Many of you still rely heavily on the legacy SAP interface RFC. In my world that often means customers connecting their third-party services to SAP backends (AS ABAP). Securing a protocol such as SAP Remote Function Call (RFC) requires network layer protection.

Often Kerberos is discussed on this topic, because it allows the mapping of Windows-Known identities to SAP backend users. However, this post is about apps and technical connections using X.509 certs – not people. They complain less – and boringly but reliably behave the same way once configured properly😉 Meet SAP Secure Network Communications (SNC).

By the way: In case you want user-based flows and focus on SAP Principal Propagation have a look at this series by my beloved colleague Martin Raepple.

SAP SNC integration architecture overview

Welcome to the world of SAP Secure Network Communications (SNC) for trustworthy technical connections!

In light of zero-trust efforts customers want to secure their technical connections to SAP RFCs too. In that space certificate-based authentication mechanisms are king. SNC is a prominent choice.

There are libraries for languages like Java, DotNet, C/C++, Python, and NodeJS that support SNC for RFC. Python and NodeJS were recently archived and will no longer be maintained. In case you get stuck, consider generating SOAP services for your SAP RFCs to uplevel the communication stack to layer 7 for use with TLS instead.

Source: SAP Help

Below I will show a simple setup with self-signed certificates. This way you can get started with a working setup and elevate towards more sophisticated as you go. Troubleshooting SNC errors can be cumbersome, so starting small with less variables and less room for error is a good idea.

Be aware of latest crypto library guidance (SAPCryptoLib vs, CommonCryptoLib) published by @JoeGoerlich in this post. Verify your archive name starts with SAPCRYPTOLIB_*.sar (which refers to CCL 8.x).

First things first: reach your private RFC interface

SAP products like the SAP Cloud Connector support apps (and people) on the SAP Business Technology Platform to connect to private instances of AS ABAP systems (behind firewall, in RISE, on-premises, or on a protected hyperscaler environment) and bring the required RFC execution environment.

Third-party apps must overcome the same challenges. Typically, that means you will be provided with a piece of software to act as reverse invoke proxy (same as the SAP Cloud Connector) besides the “line of sight” through connected private networks from that proxy. See step 0 in the overview drawing for reference.

It establishes connection to your third-party app inside out, so that no inbound firewall rules or the likes need to be touched.

For instance, Microsoft apps like Azure Data Factory, Azure Synapse, Microsoft Purview, Microsoft Fabric, and Microsoft Power BI have dedicated means to connect. These components are called Self-hosted Integration Runtime (SHIR) or On-Premises Data Gateway. Find the downloads on the individual product pages.

Be aware that services like Azure Functions or Azure LogicApps have a second approach beyond the Microsoft On-premises Data Gateway. They can bring the means to execute RFC calls, provide SNC configuration, and create line-of-sight to the private network through injection capability in a single deployment. This way you don't need the reverse invoke proxy.

Each of the described solutions have individual guides on the SAP RFC setup and how to expose the configuration for SAP SNC.

Can highly recommend my colleague Taylor Brazelton’s blog for SNC from Power Platform and On-premises Data Gateway.

Find below an SAP SNC config sequence with self-signed certificates generated by OpenSSL. Through this setup AS ABAP accepts requests protected by SNC via the SHIR.

I assume you have already installed the SHIR on a suitable windows machine and taken care of required installations like SAP Java Connector (JCo), SAP Connector for Microsoft .NET (NCo), and .NET Framework. My samples and script commands are Windows specific. However, Linux works the same way with slightly different commands.

Download SAP SNC Crypto Lib to your SNC client machine

Search the latest “SAPCRYPTOLIB” on SAP’s software center (S-User with download rights required)
And extract the SAR file using SAPCAR. Command looks something like this:

.\SAPCAR_1200-70007719.EXE -xvf .\SAPCRYPTOLIBP_8553-20011729.SAR -R .\..\libs\sapcryptolib

Find the executable sapgenpse

Prepare your SNC client machine

Create a folder to hold your SAP PSE artifacts:

mkdir sapsecudir
cd .\sapsecudir

Permanently add environment variable to point at this folder

[Environment]::SetEnvironmentVariable("SECUDIR", "C:\sapsecudir", "Machine") # Sets the variable permentaly on the system.
$env:SECUDIR = "C:\sapsecudir" # Updates the current powershell session as there currently does not exist a function to reload.

Generate a certificate for your SNC client app

Create folders to hold your certificates: mkdir rootCA sncCert
Generate root CA certificate: Adjust the subject as needed

openssl genpkey -algorithm RSA -out rootCA/ca.key.pem -pkeyopt rsa_keygen_bits:2048 

openssl req -x509 -new -key rootCA/ca.key.pem -days 7305 -sha256 -extensions v3_ca -out rootCA/ca.cert.pem -subj "/O=Contoso/CN=Root CA"

Generate SNC client certificate and adjust subject as needed:

openssl genrsa -out sncCert/snc.key.pem 2048

openssl req -key sncCert/snc.key.pem -new -sha256 -out sncCert/snc.csr.pem -subj "/O=Contoso/CN=SNC"

Sign the SNC certificate with the root CA certificate:

openssl x509 -req -in sncCert/snc.csr.pem -days 3650 -CA rootCA/ca.cert.pem -CAkey rootCA/ca.key.pem -CAcreateserial -out sncCert/snc.cert.pem

Establish trust between SNC client and SAP

Add the SNC cert to a PKCS #12 archive file (.p12)

openssl pkcs12 -export -out snc.p12 -inkey sncCert\snc.key.pem -in sncCert\snc.cert.pem -certfile rootCA\ca.cert.pem

Create the SAP Personal Security Environment (PSE) using the container

.\sapgenpse.exe import_p12 -p SAPSNCSKERB.pse C:\Users\shir-admin\Documents\snc.p12

Verify SAP is configured for SNC yet

One way of doing that is using transaction RZ10 and browsing the parameters prefixed with SNC. See this SAP document on the required “SNC Parameters for X.509 Configuration” settings and their implications.

If there is no configuration yet execute the transaction SNCWIZARD and maintain settings for X.509 credentials. Take note of the SNC private key subject. The CN will be required later.

Add your SNC client (I named mine PRV for Microsoft Purview) to the SAP Access Control List (ACL) using transaction SNC0 and allow RFC and CPIC connections.

Import SNC client cert into SAP

Use transaction STRUST
Navigate to the instance below SNC SAPCryptolib (if crossed out with a red X, create one from right-click)
Scroll down below the certificate list pane, choose import certificate and supply your snc.cert.pem file.
Click “Add to Certificate List” button
Click “Save”.

Download SAP cert and import into SNC client PSE

From the same STRUST screen, double click the Subject line of “Own Certificate” and
Scroll down again to find the “Export Certificate” button at the bottom.
Move to your SNC client machine (where your SHIR runs), put the certificate in a secure place (in my sample it landed in a folder called sap) and run below command to import it into your PSE.

sapgenpse.exe maintain_pk -p SAPSNCSKERB.pse -v -a  C:\sap\contoso-public-key.crt

Now your SAP trusts connections coming from your SHIR.

Allow your SHIR process to use your SAP PSE

Verify which user or service is being used by your SNC client to obtain certificate to communicate with SAP. The Purview SHIR uses the service user “NT SERVICE\DIAHostService”.
Add a credential to allow the certificate retrieval request from the PSE.

.\sapgenpse.exe seclogin -p C:\sapsecudir\SAPSNCSKERB.pse -x your-pse-pin -O "NT SERVICE\DIAHostService"

Verify credentials like so

.\sapgenpse.exe seclogin -l -O "NT SERVICE\DIAHostService"

You can delete them like this:

.\sapgenpse.exe seclogin -d -O " NT SERVICE\DIAHostService "

Use the -h parameter to get help with the sapgenpse command line tool or check the command reference here.

Test communication using SAP SNC

Navigate to your client application and supply the SNC configuration you have prepared. Some apps require an SAP user and password in addition even though providing a client certificate would be enough for a technical connection (remember: no user mapping or SSO).

This gives you the option to further trim down access. Use transaction SU01 and the SNC tab or the maintenance view “VUSREXTID” from transaction SM30 to configure the SNC external ID (CN) to your SAP user name.

See below sample taken from the connection configuration fly-out pane on the Azure portal UI. It can be applied, however, to any SNC client configuration. See further samples here and here.

Trigger “Test connection” and marvel at the SNC secured communication test from Microsoft Purview to AS ABAP😊

Or go even a step further and call your first RFC. RFC_PING or STFC_CONNECTION might be a suitable one in case your target is not yet operational or not identified yet.

Hints on Troubleshooting

First, try to connect from your client to AS ABAP without SNC to ensure that networking is properly configured already. Be aware of SAP RFC ports (ZZ placeholder represents your SAP instance number, e.g. 00 or 01 often) and check firewall accordingly if needed.
- 32ZZ and 33ZZ for direct RFC connections
- 48ZZ for SNC secured RFC connections
Verify SNC status from transaction SM51 -> click “SNC Status” button to ensure it is fully configured
Consult the blog series from @Frank_Buchholz on more sophisticated approaches to verify individual SNC connections. For instance, report “ZSM04000_SNC” shows more details.
For those of you using SAP UCON may consult the SNC connectivity status there.
Closing above mentioned RFC ports (32ZZ, 33ZZ) on the proxy VM firewall does the trick to verify if SNC connection is opened. Intentionally “breaking” your SNC config by mistyping the SNC partner name for instance could give you another indication on a functional setup.

Final Words

That’s a wrap 🌯. You learned today how to secure your technical RFC connections from third party apps to AS ABAP systems using SNC. The guide keeps it simple so you can establish a stable setup base from which to iterate on more complex setups confidently 😊Generate SOAP services for your RFCs and use TLS in case SNC is not an option.

By the way: When introducing an API Management solution between your 3rd party app and the SOAP service on AS ABAP you may use OAuth2, or OpenID Connect on the client. You still need to translate on the API Management layer to an auth mechanism that AS ABAP supports. Either way a step forward in securing your SAP connections.

Happy integrating with SAP!

#Kudos again to Savas Akgol, @MartinRaepple, and @Frank_Buchholz for helping with some of the hard parts 🙏

Cheers

Martin

Communicate from a Java Application to ABAP via WebSocket RFC using JCo - Migration Guide

2025-01-21T19:20:20.825000+01:00

WebSocket RFC is available for a while now. Continue reading, if

you want to communicate from an external Java application to an ABAP-based system via this new protocol using the JCo library.
you have an existing JCo setup using classic CPIC-based RFC and want to migrate.

Adjusting the destination

For specifying the destination, instead of providing properties for application server logon (jco.client.ashost, jco.client.sysnr) or message server logon (jco.client.mshost, jco.client.msserv, jco.client.r3name), the following properties must be provided:

jco.client.wshost: the hostname of the target system
jco.client.wsport: the port for HTTPS/WSS (WebSocket Secure) of the target system

Optionally, you can also specify

jco.client.tls_client_certificate_logon: If set to 1 this property enables to logon at the backend via the X.509 client certificate that is used in the TLS handshake (mTLS). An associated user or mapping rule must be defined at the backend.

Extending the implementation

WebSocket RFC is based on TLS, thus a PKI infrastructure is required to be setup. To achieve that, following methods from the JCo interface DestinationDataProvider must be implemented:

SSLContext getSSLContext(String destinationName)

This method returns a javax.net.ssl.SSLContext instance to JCo, which is used to create the TLS session for a given destination. How such an instance is created is up to the application - we are going to describe a simple use case in which all keys and CAs are stored in a local p12 file (p12FilePath) and the password is read from a secured database.

SSLContext loadSSLContextFromFile() throws KeyStoreException, NoSuchAlgorithmException, CertificateException, IOException, UnrecoverableKeyException, KeyManagementException {
    File p12File = new File(p12FilePath);

    try (InputStream p12FileStream = new BufferedInputStream(new FileInputStream(p12File))) {
        KeyStore ks = KeyStore.getInstance("PKCS12");

        char[] pwd = SecuredDatabaseConnection.readPassword();

        ks.load(p12FileStream, pwd);
        KeyManagerFactory kmf = KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
        kmf.init(ks, pwd);

        // delete the plain text password from the heap memory as soon as possible
        Arrays.fill(pwd, (char) 0);
        pwd = null;

        TrustManagerFactory tmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
        tmf.init(ks);

        SSLContext sslContext = SSLContext.getInstance("TLS");
        sslContext.init(kmf.getKeyManagers(), tmf.getTrustManagers(), null);
        return sslContext;
    }

(Optionally) If jco.client.tls_client_certificate_logon is used, the API below must be implemented additionally:

X509Certificate getClientCertificate(String destinationName)

This method must return the java.security.cert.X509Certificate instance of the client certificate used for logon. It must be the one provided in the SSLContext, which is used during the TLS handshake.

Setting up Trust

Creating the p12 File

Create a p12 file with a private key using a tool like keytool or OpenSSL. Create a CSR and import the CA response. Furthermore, import the CA certificate from the ABAP system which has been exported (see next section).

Configuring trust in ABAP

Navigate to transaction STRUST and select "SSL-Server Standard". Select the own certificate and export it. For more information, see also here. Also, import the CA certificate from the p12 file and add it to the certificate list, so that mutual trust can be established.

Using WebSocket RFC in BTP

If you use JCo in BTP in conjunction with the Destination Service and you want to use WebSocket RFC to call publicly exposed endpoints, you can skip the above "Extending the implementation" part. This integration is already implemented by SAP in the supported environments. You can follow the steps in the BTP Connectivity Service documentation on how to configure the Destination Service accordingly.

ABAP Adaptation for Any Middleware to CPI/IS Migration ( RFC to Webservice )

2025-05-20T16:14:40.004000+02:00

1.Introduction:

This document provides an in-depth overview of the necessary changes in ABAP development when migrating from any middleware platform to SAP CPI. It particularly addresses the migration of RFC-based communication in middleware to SOAP-based web services in CPI.

2.Background:

The integration platform that enables communication between SAP and external systems. In any middleware, RFC adapters are commonly used to interact with remote systems through RFCs. However, with the shift to SAP CPI/IS, the integration landscape changes, and CPI/IS does not support sender RFCs, so it is necessary to refactor and convert these RFC calls into SOAP web services.

3.Transition to SAP CPI:

In CPI, communication is predominantly based on HTTP/SOAP or REST protocols. Therefore, the ABAP function modules that were exposed as RFCs in integration platform must now be exposed as SOAP web services to be compatible with CPI’s integration model.

4.Why Convert RFC to a SOAP Web Service Rather Than Using a Wrapper?

When a wrapper is created for a sender or receiver RFC, SAP automatically configures the service provider (inbound interface) in SOAMANAGER, thereby generating the web service from the scratch.

5.ABAP Development Steps - Replacing RFC with SOAP Web Services:

5.1. Obtain the WSDL file from the RFC in SAP or from Integration team.

5.1.1.In SE37, enter the RFC to convert to SOAP.

5.1.2.Go to Utilities -> More Utilities -> Create Web Service -> From Function Module.

5.1.3.Enter the RFC name and description, then click Next.

5.1.4.Fill in the details and click Finish.
The screen will appear as shown below.

5.1.5.Click on the WSDL tab to retrieve the WSDL file and modify the wsdl file.

5.2. Modify the WSDL to an asynchronous structure.
5.2.1. Why to modify the wsdl structure?

The WSDL structure used in PI/PO follows a synchronous pattern, with both request and response. When uploading the same file while creating a web service, SAP expects a response from the middleware. To convert it to asynchronous, the WSDL structure must be modified.

Before modification of WSDL : ( It has both input and output parameter )

After modification of WSDL : ( It has only input parameter )

5.2.2. How it can be modified?

At the end of </wsdl:types> tag, add the below template and update the required details:
Replace ZTEST in the template with the actual RFC name.

<wsdl:message name="ZTEST">

<wsdl:part name=" ZTEST " element="tns: ZTEST "/>

</wsdl:message>

<wsdl:portType name=" ZTEST">

<wsp:Policy>

<wsp:PolicyReference URI="#IF_IF_ ZTEST "/>

</wsp:Policy>

<wsdl:operation name=" ZTEST">

<wsp:Policy>

<wsp:PolicyReference URI="#OP_IF_OP_ ZTEST"/>

</wsp:Policy>

<wsdl:input message="tns: ZTEST"/>

</wsdl:operation>

</wsdl:portType>

</wsdl:definitions>

5.3. Upload the WSDL and create the web service in SE80.

5.3.1.Navigate to sproxy tcode and click on create button.

5.3.2.Click on service consumer radio button and then continue.

5.3.3.Click on service External WSDL/Schema and then continue.

5.3.4.Click on local file and then continue.

5.3.5.Upload the wsdl file and click on continue.

5.3.6.Provide the package name and then the TR details and then continue .

5.3.7.Click on complete and then save and activate the service.

5.4.Use the "Where Used" function to identify the related report, function module, or class of the RFC.

5.5.Replace the RFC code with the corresponding SOAP web service code,ensuring all required parameters are passed as in the original RFC.

RFC Code :

SOAP Code:

5.6.Configure the web service in SOAMANAGER.

5.6.1.Navigate to SOAMANAGER tcode and click on web service configuration.

5.6.2.Provide and select the web service name

5.6.3. Click on the create button manual configuration to create a logical port for the webservice. Provide the Port name and description.

5.6.4. In the consumer security tab, give the s-user ID and password and click next.

5.6.5. Provide the correct endpoint in the URL tab and click next.

5.6.6. In the Messaging tab, select suppress id transfer in Message ID Protocol and SAP RM in RM Protocol tab and click next.

5.6.7. Click on finish to complete the setting.

5.6.8: Click on ping test for the successful setup.

Function Expression in Business Rule Framework (BRF+)

2025-08-12T11:28:52.458000+02:00

Function in BRF+:

A function is the rule interface in BRF+ and acts as a link between the application code and the BRF+ code. A function carries a context and a result. It imports the context from the calling application and passes the context data to the assigned top expression or ruleset for further processing.

Create an BRF+ application or chose the application in which you wanted to add function Expression.

Right click on the application and select create > Function

Provide the function name, text and short text.

Click on create and navigate to object to save and activate the object.

Once clicked, it will navigate to the above screen. Here you have to assign the result data object based on the context data objects.

Types of Mode:

Function mode:

In functional mode, function execution starts with the assigned top expression. From this top expression, the processing may run through any number of nested subexpressions until a result is returned.

Event mode:

In event mode, the function is associated with a list of rulesets that are executed according to their execution priority and their position in the list.

Function and Event mode:

This mode is a combination of the modes mentioned above. At runtime, the function starts processing the assigned top expression. Once the expression evaluation is finished, function execution continues with the associated rulesets.

Analytical Mode:

It is mainly related to the Hana rules framework which is relevant to the runtime operations.

Signature

The function signature consists of two parts:

Context

The context is a container for data objects that you can assign as import parameters for the function. You choose the context data objects of a function according to the requirements of the calling application by which the BRF+ function is invoked. Also, the context data objects of a function define the scope of objects that can be accessed by the expressions that are evaluated during function execution.

Result

The result data object returns a result value that has been calculated by the expressions of which the function consists .

Note: For further in event mode, the result object is automatically set to the predefined actions table where the actions are recorded that have been triggered by the assigned rulesets.

Code Generation:

BRF+ provides a built-in code generation facility used to compile source code for as many rule constructs in a function as possible. With the help of generated code, BRF+ rules can be executed significantly faster than in interpretation mode.

Simulation:

You can simulate the function processing to test the function's behavior in a sandbox environment. Here, you can gain an in-depth insight into the system status for every single step the system takes during function processing.

Trace

In BRF+, you can request the system to create a processing log to keep track of all processing steps during function execution. The trace information is stored in the system and can be reviewed at any point in time.

Trace will be stored in Trace tables FDT_TRACE_*

Generation Services

For a BRF+ function, you can take advantage of different services that automatically generate code and other objects that are needed to bridge the gap between the ABAP backend system where a BRF+ function is hosted and other systems or environments that wish to access BRF+. The different services available address different usage scenarios. These can be categorized as follows:

Code Templates

A code template is a predefined snippet of ABAP code that you can use to call a BRF+ function from your application in the same system.

Generate

Function Module

You can use a generated RFC-enabled function module to call a BRF+ function that resides in a remote backend system. This is useful in cases where you cannot bring BRF+ and the calling application into the same system — be it for technical reasons (for example, different releases) or for organizational reasons (for example, missing authorization to develop in the remote system).

Web Service

You can use a generated web service to call a BRF+ function from a web application that is not ABAP-based, or that you can only integrate via its exposed services interface. From a technical point of view, web service generation is reusing the function module generation component of BRF+ and generates additional system objects needed for service enablement.

Here we will work on Function mode example:

Assign the top expression and in context add the required objects and finally assign result object suitable.

Top Expression:

Its is pre-condition of the function which will evaluate the number of nested expressions to find the result.

To execute the function click on simulation.

Click on continue

Select the input true or false and click on execute

Result :

Note : All the objects created will be stored in FDT_* tables

Conclusion:

Function provides a built-in code generation facility used to compile source code for as many rule constructs in a function as possible
Function is the most important BRF+ object and it represents a decision service , which is the element that is in fact invoked by the application and the entire application is invoked by function to stimulate and provide the output we can invoke using the code generation to create report program for executing in GUI.
we can perform pre-conditional and event of action related condition's like rules for executing in the based on the specified rule using the type of modes in the function expression.

ABAP's Parallel Processing Frameworks: Practical Guide to Performance Tuning of Mass Data Processing

2025-09-29T08:52:47.138000+02:00

While working on a project to optimize a standard SAP report that struggled with large data volumes, I took a deep dive into performance tuning in ABAP, specifically focusing on parallel processing. This journey led me to a comprehensive analysis of the various methods SAP provides for running processes in parallel.

I discovered that parallel processing in ABAP is achieved using one of two core technologies. The first is the Remote Function Call (RFC), where both asynchronous (aRFC) and background (bgRFC) variants can be used to run tasks in parallel. The second technology is based on background processes. To make implementation easier, several frameworks have been built on top of these technologies, simplifying the development process.

This blog post is a summary of the theoretical research I conducted for my bachelor's thesis. Its goal is to provide a comprehensive overview of the different technologies and the six key frameworks I identified. Think of it as a practical guide to help you choose the most suitable framework for your needs, with linked resources for anyone who wants to dive deeper into a specific topic.

The Landscape of Parallel Processing in ABAP

As mentioned in the introduction, parallel processing in ABAP is based on two core technologies. To simplify their use, multible frameworks have been developed for easier implementation. The following table provides an overview of these technologies and their corresponding frameworks:

Now, let's explore how each of these core technologies enables parallel processing.

Asynchronous Remote Function Call (aRFC)

The Asynchronous Remote Function Call is one of the older and established SAP technology for parallel processing in ABAP. It works by starting a session in a separate dialog work process, which then executes a function module in parallel with the main program. The calling program does not wait for the function to finish and continues its own processing immediately.

By starting multiple aRFCs in a row, you can achieve a significant parallelization effect, as each call runs simultaneously in its own process. This is implemented using the STARTING NEW TASK addition to the standard CALL FUNCTION statement. A example call could look like this:

CALL FUNCTION '<function_module_name>'
STARTING NEW TASK '<task_name>'
DESTINATION IN GROUP <server_group>
PERFORMING <callback_form> ON END OF TASK.

For a more detailed guide on aRFCs, check out these resources:

Book: Gahm, H. (2009): ABAP Performance Tuning
Jolfaei, M. A. and Neuwirt, E. (2006): Master the five remote function call (RFC) types in ABAP
SAP Help Portal: Asynchronous RFC (aRFC)
SAP Help Portal: Parallel Processing with Asynchronous RFC

Background Remote Function Call (bgRFC)

The Background Remote Function Call is a newer method for parallelization. While it also uses dialog work processes for execution like the aRFC, its operational logic is quite different.

Instead of executing immediately, a bgRFC call is first saved to a persistent queue in the database. The actual processing is only triggered by an explicit COMMIT WORK statement and is managed by a dedicated scheduler. This approach makes it possible to execute tasks with an "Exactly Once" or even an "Exactly Once in Order" guarantee, which provides a high degree of reliability.

The implementation is nearly identical to that of an aRFC. The key difference is the use of the IN BACKGROUND UNIT statement, which groups one or more function calls into a single, logical unit of work.

CALL FUNCTION '<function_module_name>'
IN BACKGROUND UNIT <unit_object>.

You can find more information about this technology here:

Background Processes

Using dedicated Background Processes is another established method for achieving parallelism in SAP Systems, especially suitable for long-running and resource-intensive tasks that can be clearly divided.

Parallelizing with background processes follows the same core principle as with aRFCs: multiple tasks are started to run simultaneously. This can be achieved in two main ways. The first approach is done purely through configuration. Here, an administrator can manually schedule the same ABAP program multiple times, where each parallel job uses a unique variant with a different dataset.

The second approach is to implement this parallelization within a single ABAP program. This is done using a set of function modules that control the job lifecycle:

JOB_OPEN creates a new job.
JOB_SUBMIT adds the program and its variant as a step.
JOB_CLOSE releases the job to the system for execution.

For more details on implementing parallel background jobs, check out these resources:

Frameworks for Easier Implementation

While the core technologies provide the fundamental mechanisms for parallel processing, implementing them directly requires handling details like load balancing, package creation and managing parallel tasks. To simplify this process, SAP provides several frameworks that build on these technologies. These frameworks offer a structured, reusable and often easier way to implement robust parallel processing.

To select the most suitable framework, the following decision matrix based on the Qualitative Weight and Summ (QWS) method provides a visual comparison. The darker the green shade, the better a framework fulfills a specific criterion. Please note that this matrix reflects my subjective evaluation for a specific use case. Your assessment will likely differ based on your project's unique requirements.

Evaluation Criteria Explained

Here is a brief summary of each criterion used in the matrix:

Platform Compatibility: Runs on both SAP ECC and S/4HANA systems.
Timeout Robustness: Handles long-running tasks without timing out.
Package Creation: Automatically divides data into work packages.
Configurable Package Size: Allows the developer to define the size of work packages.
Parallel Execution: Automatically starts and manages the execution of parallel tasks.
Result Aggregation: Helps collect and consolidate results from parallel tasks.
Multi-Server Function: Can distribute tasks across multiple application servers.
Processing Server Selection: Allows specifying a server or server group for execution.
Load Balancing: Automatically distributes tasks based on system load.
System Load Control: Allows setting limits on the maximum system resources used.
Implementation Effort: The complexity and time required to implement the framework.
Documentation Quality: The availability and quality of supporting documentation.

Now lets have a look at the individual Frameworks.

SPTA Framework

The SPTA Framework provides a straightforward, function-module-based approach to simplify parallel processing with aRFCs. Instead of requiring the developer to manage the aRFC calls manually, the framework encapsulates the entire parallelization logic within a single, reusable function module, SPTA_PARA_PROCESS_START_2.

To use the SPTA framework, a developer implements three specific form routines that serve as callbacks, filling them with the custom logic required for the application. The BEFORE_RFC_CALLBACK_FORM is responsible for preparing the data and creating the work packages. The core processing logic, which is to be executed in parallel, is placed within the IN_RFC_CALLBACK_FORM. After all the parallel tasks have been completed, the AFTER_RFC_CALLBACK_FORM is called to consolidate the results and make them available for further processing.

For more information on the SPTA Framework, see these resources:

SHDB Framework

The SHDB Framework is a more powerful and modern, object-oriented framework that also simplifies the use of aRFCs. It is structured into four main components that work together to provide a robust parallelization environment: the Package Provider, the Resource Provider, the Parallelizer and the Dispatcher.

The Package Provider is responsible for automatically dividing the total dataset into smaller, processable packages according to configurable rules. The Resource Provider actively monitors the system's memory and process utilization to determine the maximum allowed number of parallel tasks, thereby preventing system overloads. The Parallelizer then calls the application-specific logic for each package in a separate aRFC task, while the Dispatcher coordinates the entire process by requesting packages and resources and launching the asynchronous tasks.

Implementation is done in an object-oriented manner, starting with the factory class CL_SHDB_PFW_FACTORY and using configuration objects from CL_SHDB_PFW_CONFIG to define parameters like the number of parallel processes or package parameters.

While a complete guide for the SHDB Framework is not publicly available at this time, some information can be found on the SAP for Me portal. Relevant resources are available there using the search terms "SHDB Framework" or "SHDB PFW".

CL_ABAP_PARALLEL

The CL_ABAP_PARALLEL framework is another object-oriented solution for aRFC-based parallelization. Its name, while not official, comes from its original project folder. It is a lightweight solution centered around a main class and an interface that developers use to structure their parallel logic.

The implementation pattern requires the developer to create a processing class that implements the IF_ABAP_PARALLEL interface. All the custom logic intended to run in parallel is then placed within its DO method. Finally, the entire process is managed by an instance of the main CL_ABAP_PARALLEL class and the parallel execution is triggered by calling the RUN_INST method.

For more information on CL_ABAP_PARALLEL, see these resources:

Book: Schwarzmann, W. (2022): Parallel Processing with ABAP Objects: Implementation and Testing, isbn: 978-1-4932-2354-1
SAP Help Portal: Parallel Processing
SAP Community (2023): Using class CL_ABAP_PARALLEL for mass parallel dialog work processes

Background Processing Framework (bgPF)

The Background Processing Framework serves as the dedicated framework for the bgRFC technology.

The implementation pattern requires a developer to encapsulate the business logic in a dedicated class that implements a framework interface. For most use cases, IF_BGMC_OP_SINGLE is used to ensure the process follows strict transactional rules for data consistency.

Once this class with the business logic is ready, it is passed to the CL_BGMC_PROCESS_FACTORY. This is a helper class provided by the framework that constructs the main process object for the background task. The task is then registered by calling the save_for_execution() method and the entire process is finally triggered by a COMMIT WORK statement.

For more information on the bgPF, see these resources:

Parallel Processing Framework (PPF)

The Parallel Processing Framework, sometimes also referred to as the Framework for Parallel Processing (FPP), is a framework based on background processes used to structure and execute mass-data processing runs in parallel.

Its implementation requires both settings in Customizing and the development of custom ABAP function modules. A developer first defines an application type using transaction BANK_CUS_PPC. This application type links specific processing steps, such as data packaging or execution, to the custom-developed function modules that contain the business logic.

The entire process is then initiated from a report by calling the central function module BANK_MAP_PP_START, which uses the application type's configuration to manage the parallel jobs.

For more information on the PPF, see these resources:

Mass Data Framework

The Mass Data Framework is a comprehensive solution for structuring and controlling complex projects that involve large-scale data changes and is often used in migration scenarios.

The implementation requires just like the Parallel Processing Framework a combination of Customizing and development. In Customizing (via transaction SM30), a developer defines the entire project structure. This involves creating a Project Type (FINSV_MPROJ_TYP), which consists of a sequence of Activities (FINSV_MASSF_SET). Each activity is made up of one or more Steps (FINSV_MASSF_STEP), where the custom ABAP logic is assigned.

The developer's main task is to create an application class that contains the business logic for a step. This class must implement the interface IF_FINS_MASS_DATA, which includes three key methods. The GET_PACKAGES method is called to define the work packages. The PREPARE method can be used for any setup tasks before the parallel processing starts. Finally, the PROCESS method contains the core logic that is executed in parallel for each individual package.

As it is an older framework, further resources for the Mass Data Framework are primarily located on internal SAP platforms and are not publicly available.

I hope you found this overview informative and that it helps you tackle your own performance tuning challenges.

A special thanks to @ManuS for the help and guidance!

ABAP code to wait for the end of "inbound bgRFC type Q" units

2025-10-07T20:28:26.490000+02:00

I have a program which runs parallel tasks in the same system by using bgRFC and several qRFC queues: each queue runs tasks sequentially, but two queues run in parallel. With bgRFC, each task is called a unit. This scenario is called Inbound bgRFC type Q, see here for more information: bgRFC (Background Remote Function Call) | SAP Help Portal.

Once all units are started, I want the program to wait for all units to finish.

I propose a simple ABAP method which should work for most of situations.

There are really very few posts about bgRFC and the official documentation is missing information too, so I hope it can help some people. Note: I don't even know if the classes I use are supported by SAP and if it's the right way to do it, so all comments are welcome, thank you.

Here is the context how this method is used (WAIT_END_OF_QRFC_INBOUND_UNITS) :

DATA(inbound_destination) = cl_bgrfc_destination_inbound=>create( 'ZZZ' ).

LOOP AT any_table INTO line.
  DATA(unit) = inbound_destination->create_qrfc_unit( ).
  unit->add_queue_name_inbound( line-queue_name ).

  CALL FUNCTION '...' 
     IN BACKGROUND UNIT unit
     EXPORTING ...

  INSERT unit INTO TABLE units.
ENDLOOP.

COMMIT WORK.

DATA(wait_results) = zcl_bgrfc_helper=>wait_end_of_qrfc_inbound_units(
                       i_watch_delay_seconds = 5
                       i_units               = units ).

Little explanation: there's an internal table containing data which needs to be processed in parallel via a given RFC-enabled function module. The internal table assigns given queue names to each line of data in order to achieve the parallelization. For instance, one half of the table goes to the queue named Z1, all calls in Z1 will be executed sequentially, the other half goes to the queue named Z2, the calls in Z1 and Z2 will be executed in parallel).

CALL FUNCTION ... IN BACKGROUND UNIT unit ... registers a call in a given bgRFC unit. You may call several function modules in the same unit. The function modules are not called until COMMIT WORK is reached.

COMMIT WORK creates the inbound bgRFC units in the database (function module calls and parameters) and all the queues are started by the bgRFC scheduler. You can see the units via the transaction SBGRFCMON.

Prerequisite: the inbound destination ZZZ was created via the transaction SBGRFCCONF. Nothing else needed (no prefix, no RFC destination in SM59, queue names are assigned freely by the program, etc.)

Here's the code of the method WAIT_END_OF_QRFC_INBOUND_UNITS:

CLASS zcl_bgrfc_helper DEFINITION FINAL PUBLIC CREATE PRIVATE.
  PUBLIC SECTION.
    TYPES ty_qrfc_inbound_units TYPE STANDARD TABLE OF REF TO if_qrfc_unit_inbound WITH EMPTY KEY.
    TYPES:
      BEGIN OF ty_bgrfc_unit_state,
        unit         TYPE REF TO if_qrfc_unit_inbound,
        "! Time at which the information was collected
        timestamp    TYPE timestampl,
        unit_success TYPE abap_bool,
        unit_error   TYPE abap_bool,
        "! In case there's a unit error
        unit_state   TYPE bgrfc_unit_state,
        queue_error  TYPE abap_bool,
        "! In case there's a queue error
        queue_state  TYPE qrfc_queue_state,
      END OF ty_bgrfc_unit_state.
    TYPES ty_bgrfc_unit_states TYPE SORTED TABLE OF ty_bgrfc_unit_state WITH UNIQUE KEY unit.

    CLASS-METHODS wait_end_of_qrfc_inbound_units
      IMPORTING i_watch_delay_seconds      TYPE numeric DEFAULT 5
                i_units                    TYPE ty_qrfc_inbound_units
      RETURNING VALUE(r_bgrfc_unit_states) TYPE ty_bgrfc_unit_states.

    CLASS-METHODS get_timestamp
      RETURNING VALUE(r_result) TYPE timestampl.
ENDCLASS.

CLASS zcl_bgrfc_helper IMPLEMENTATION.
  METHOD wait_end_of_qrfc_inbound_units.
    TYPES:
      BEGIN OF ty_queue,
        queue_name TYPE qrfc_queue_name,
        dest_name  TYPE bgrfc_dest_name_inbound,
      END OF ty_queue.
    TYPES tt_queue TYPE SORTED TABLE OF ty_queue WITH UNIQUE KEY queue_name dest_name.
    TYPES:
      BEGIN OF ty_unit_and_queue,
        unit       TYPE REF TO if_qrfc_unit_inbound,
        queue_name TYPE qrfc_queue_name,
        dest_name  TYPE bgrfc_dest_name_inbound,
      END OF ty_unit_and_queue.
    TYPES tt_unit_and_queue TYPE SORTED TABLE OF ty_unit_and_queue WITH UNIQUE KEY unit
                            WITH NON-UNIQUE SORTED KEY by_inbound_queue COMPONENTS queue_name dest_name.

    DATA ls_unit_and_queue TYPE REF TO ty_unit_and_queue.

    DATA(lt_queue) = REDUCE #(
                    INIT lt_queue_2 = VALUE tt_queue( )
                    FOR <lv_unit> IN i_units
                    FOR <lv_queue_name> IN <lv_unit>->get_queue_names_inbound( )
                    NEXT lt_queue_2 = COND #(
                         WHEN NOT line_exists( lt_queue_2[ queue_name = <lv_queue_name>
                                                           dest_name  = <lv_unit>->destination->dest_name ] )
                         THEN VALUE #( BASE lt_queue_2
                                       ( queue_name = <lv_queue_name>
                                         dest_name  = <lv_unit>->destination->dest_name )  )
                         ELSE lt_queue_2 ) ).

    DATA(lt_unit_and_queue) = VALUE tt_unit_and_queue( FOR <lv_unit> IN i_units
                                                       FOR <lv_queue_name> IN <lv_unit>->get_queue_names_inbound( )
                                                       ( unit       = <lv_unit>
                                                         queue_name = <lv_queue_name>
                                                         dest_name  = <lv_unit>->destination->dest_name ) ).
    WHILE lt_unit_and_queue IS NOT INITIAL.

      WAIT UP TO i_watch_delay_seconds SECONDS.

      LOOP AT lt_unit_and_queue REFERENCE INTO ls_unit_and_queue.
        DATA(bgrfc_unit_state) = cl_qrfc_client_inbound=>get_unit_state( ls_unit_and_queue->unit->unit_id ).
        CASE bgrfc_unit_state.
          WHEN if_bgrfc_client=>unit_state_runnable
            OR if_bgrfc_client=>unit_state_in_execution
            OR if_bgrfc_client=>unit_state_blocked ##NO_HANDLER.
          WHEN if_bgrfc_client=>unit_state_executed.
            r_bgrfc_unit_states = VALUE #( BASE r_bgrfc_unit_states
                                           ( unit         = ls_unit_and_queue->unit
                                             timestamp    = get_timestamp( )
                                             unit_state   = bgrfc_unit_state
                                             unit_success = abap_true ) ).
            DELETE lt_unit_and_queue USING KEY loop_key.
          WHEN OTHERS.
            r_bgrfc_unit_states = VALUE #( BASE r_bgrfc_unit_states
                                           ( unit       = ls_unit_and_queue->unit
                                             timestamp  = get_timestamp( )
                                             unit_state = bgrfc_unit_state
                                             unit_error = abap_true ) ).
            DELETE lt_unit_and_queue USING KEY loop_key.
        ENDCASE.
      ENDLOOP.

      LOOP AT lt_queue REFERENCE INTO DATA(queue).
        DATA(bgrfc_queue_state) = cl_qrfc_client_inbound=>get_queue_state( queue_name = queue->queue_name
                                                                           dest_name  = queue->dest_name ).
        CASE bgrfc_queue_state.
          WHEN if_bgrfc_client=>queue_state_runnable
            OR if_bgrfc_client=>queue_state_in_execution
            OR if_bgrfc_client=>queue_state_empty ##NO_HANDLER.
          WHEN OTHERS.
            LOOP AT lt_unit_and_queue REFERENCE INTO ls_unit_and_queue
                 USING KEY by_inbound_queue
                 WHERE     queue_name = queue->queue_name
                       AND dest_name  = queue->dest_name.
              r_bgrfc_unit_states = VALUE #( BASE r_bgrfc_unit_states
                                             ( unit        = ls_unit_and_queue->unit
                                               timestamp   = get_timestamp( )
                                               queue_state = bgrfc_queue_state
                                               queue_error = bgrfc_queue_state ) ).
              DELETE lt_unit_and_queue WHERE unit = ls_unit_and_queue->unit.
            ENDLOOP.
            DELETE lt_queue USING KEY loop_key.
        ENDCASE.
      ENDLOOP.
    ENDWHILE.
  ENDMETHOD.

  METHOD get_timestamp.
    GET TIME STAMP FIELD r_result.
  ENDMETHOD.
ENDCLASS.

As I said, I don't know if these classes are released by SAP:

cl_qrfc_client_inbound=>get_unit_state
cl_qrfc_client_inbound=>get_queue_state

The method should support units which span other several inbound queues, but I didn't test it.

In my case, I could see that one unit has these states: runnable (briefly), in execution, executed. In a given queue, there's only one unit processed at a time. All the units instantiated after the one processed have the state blocked. Other states should be errors (e.g. short dump, uncaught exception, error message, etc.)

The queues have these states: empty if it doesn't contain any unit, runnable if it contains at least one unit to execute but it's not started yet, in execution when a unit is processed.

About the code, in case you want to ask: "DELETE itab USING KEY loop_key" is to delete the current line in the loop (LOOP AT itab), it corresponds to the old and less expressive syntax "DELETE itab". I used the pragma ##NO_HANDLER for CASE WHEN although it's not asked by the syntax check, the pragma is meant to be used for CATCH, when there's no code inside.

Any way, feel free to post any comment.

Thank you for reading.

Using Communication Targets for Outbound RFC Communication in ABAP

2025-11-10T04:12:55.469000+01:00

For those of you, who want to keep unwanted (you could even say badly dressed) destinations out of their HTTP(S) connections, check out this blog post:
Receiver Validation HTTP - Enhance Your Security by Controlling Destination Usage

In the world of SAP systems, remote-enabled function modules (RFMs) are essential for connecting different systems and running functions remotely.

In this article, you will be guided through the process of calling an RFM using communication targets. This ensures smooth integration between your SAP system and remote systems. There is even a song about this phenomenon called "Smooth Integrator" . You see what we did there?

Why should you use communication targets?
Well, imagine throwing a party and accidentally inviting your ex, your accountant, and that one neighbor who always complains about your music. Nobody wants unwanted guests crashing their (SAP system) party!
That's what happens when you don't have control over which applications can use which RFC destinations. It's a security and maintainability nightmare.

You might wonder how exactly communication target get to be the "life of the party".
Communication targets and application destinations provide a strong layer that simplifies complex processes. They define how your SAP system connects with external systems. For that we need to use specific configurations known as appplication destinations.

What is an application destination, you ask?
Imagine it as the ultimate party planner for your data!

It's the one responsible for making sure your data arrives at the right place, with the right credentials, and doesn't end up going to the wrong party. You know, like that one time you got invited to a LAN-Party, but showed up at a wild rave instead. Oops!

Let's dive into the technical details.

When you create a communication target, you need to carefully choose which of the following settings suit you best:

Enforce SAP GUI Support - it ensures application destinations allow GUIs and disallow WebSocket RFC.

Enforce Fast Serialization - mandates the use of Fast Serializer for application destinations, preventing issues by disallowing other serializers if the scenario was developed with Fast Serializer.

Default Compression Mode - allows predefined settings for higher compression in WAN scenarios or fast compression in LAN scenarios.

When using communication targets, you can create an application destination in the transaction APPLDEST. This process ensures you communicate only with the intended recipients.
You select your communication target and create a new application destination with a right-click:

Then you just need to name it, enter the client and select CPIC for the RFC Type.

Alright, now you have an application destination. You still need to enter some important details like the host name (it can be retrieved from transaction SM51), instance and which authentication method you want to use.
Application destinations are crucial component for managing external connections efficiently and securely. And now you have one too. Good for you!

If you use Cloud capabilities, communication targets are now available as well!
Instead of using the traditional APPLDEST transaction, the cloud environment introduces some differences regarding the application destination:

In the cloud, you start by creating a communication scenario for outbound RFC, which defines the interaction between your SAP system and external systems.
A corresponding runtime configuration, including a communication arrangement and communication system, must exist for your scenario.
When a communication arrangement is saved, the system automatically creates an application destination.

But wait, there's more!

Communication targets can generally have either multiple or exactly one assigned application destination. If you're calling an RFC service via communication targets in your ABAP code, you use the CALL FUNCTION (…) IN REMOTE SESSION method, it is essential for running the function remotely. It is basically like sending an RSVP to your guest, ensuring they got the invite (you get a response much faster though).

When a communication target has exactly one assigned application destination, the process is straightforward. In cases where a communication target has several assigned application destinations, a few additional steps are required.
When you have several assigned application destinations, one must pass the name of the relevant application destination to the parameter application_destination when creating the communication target instance. This ensures that the correct destination is used during the remote session. Check out how easy it is:

In this example we called the function RFC_SYSTEM_INFO and we wanted to find out the maximal resources. 45 is the result.
That´s a Bingo!

By following alle these steps, you can call RFMs using communication targets, improving the connectivity and functionality of your SAP system.

Just remember, the key is in the configuration. It should fit your specific needs, like making sure your party playlist has the right mix of songs to keep everyone dancing, and not just that one weird guy. We all know that one guy who just loooves to play the DJ, please don´t let him.

To summarize, communication targets and application destinations let you:

Control which applications can crash which parties (application destinations).
Restrict access to only those who need it.
Avoid runtime errors and security mishaps.

In case you are not a party animal, check out the step by step guide:
Calling a RFM via Communication Targets

Invoking Business Agent Foundation Agents from ABAP: A Step-by-Step Guide

2025-11-26T10:15:43.404000+01:00

With the rise of intelligent automation and AI-powered solutions in enterprise landscapes, integrating SAP Business Technology Platform (BTP) services with on-premise ABAP systems has become increasingly important. In this blog, I'll walk you through the process of invoking agents from the Business Agent Foundation service directly from an ABAP report—an integration that bridges the gap between traditional SAP systems and modern AI capabilities.

Whether you're looking to enhance your business processes with intelligent agents or simply exploring the possibilities of AI integration in your SAP landscape, this guide will provide you with a comprehensive, hands-on approach to achieve this integration.

Pre-requisites: Subaccount in BTP, subscription of Business Agent Framework service in the subaccount, a dedicated client profile with required configurations.

Step 1: Create Your Agent in Business Agent Framework

Setting up Business Agent Framework service in your subaccount: Setup - Project Agent Builder Documentation

After setting the service, go to Instances → Project Agent Builder → Service Keys → view. Copy the endpoint url (uaa → url) which is required in the OAuth 2.0 Client Profile Configuration.

Start by opening the Business Agent Framework application in your BTP subaccount. Create a test agent and initialize a new chat session. This agent's chat/thread will be the endpoint we'll communicate with from our ABAP system.

Note: If you already have a dedicated client profile with required configurations, directly go to "Step 2: Configure the RFC Destination".

OAuth 2.0 Client Profile Configuration

Proper authentication is crucial for secure integration. Here's how to set up your OAuth 2.0 client profile:

Part A: Creating the OAuth Client Profile

Navigate to transaction code SE80 (Object Navigator)
Select Development Object and choose your package
Right-click on the package and choose: Create → Others → OAuth 2.0 Client Profile and enter a meaningful name for your profile
Choose 'DEFAULT' as the service provider type
Save your profile
Assign the relevant scopes required for accessing the Business Agent Foundation service

Part B: Configuring the OAuth Client Profile

Start transaction code SOAUTH2_CLIENT (or OA2C_CONFIG for older versions)

Alternatively, access it via browser:

   https://<host_name>:<https_port>/sap/bc/webdynpro/sap/oa2c_config?sap-language=EN&sap-client=<client>

Click Create and select your previously created client profile
Enter Client Credentials:
- Navigate to your BTP subaccount
- Go to: Instances → <your_service_instance> → Service Keys
- Copy the Client ID from the service key and enter it in the configuration
Configure Token Endpoint:
- Under General Settings, enter the token endpoint URL without the `https://` prefix.
  Use the endpoint url which you copied in the Step 1.
Configure Grant Type:
- Select 'Client Credentials' as the grant type
- This is the standard grant type for server-to-server authentication
Verify Scopes:
- The associated scopes should automatically appear if they were properly configured in Part A
Test the configuration:
- Save your configuration
- Navigate to the Token tab
- Click Request New Token
- If successful, you'll receive an access token, confirming that your OAuth configuration is working correctly

Note: For comprehensive details on OAuth 2.0 configuration in ABAP, refer to the official SAP documentation on [OAuth 2.0 Client for ABAP].

Step 2: Configure the RFC Destination

The destination acts as a bridge between your ABAP system and the BTP service. Here's how to set it up:

2.1 Create the HTTP Destination

Navigate to transaction code SM59 in your ABAP system
Create a new RFC destination with the following settings:
- Connection Type: Select 'G' (HTTP connection to external server)

2.2 Technical Settings

Under the Technical Settings tab enter the host URL of your BTP service without the "https://" prefix

2.3 Authentication Configuration

Navigate to the Logon & Security tab:
- Under Logon Procedure, select 'Logon with User'
- Choose 'Basic Authentication' as the authentication method
Click on OAuth Settings:
- Select your previously configured OAuth client profile (see configuration details in the OAuth Client Configuration step above)

2.4 Test Your Connection

Click on Test Connection to verify connectivity to the host URL
Navigate to the Test OAuth Configuration tab to validate the OAuth setup
If you encounter SSL certificate issues, use transaction code STRUST to upload the required SSL certificate

Note: For more comprehensive information on calling RESTful APIs from ABAP, refer to the [Calling RESTful APIs from SAP ABAP].

Step 3: Implement the ABAP Report

Writing the ABAP code to invoke the agent.

3.1 Create Your ABAP Report

Go to transaction code SE38 and create a new report.

3.2 Understanding the CL_HTTP_CLIENT Class

ABAP provides a powerful class called CL_HTTP_CLIENT for making HTTP calls to REST APIs. This class offers two primary methods for creating HTTP client instances:

`CREATE_BY_DESTINATION` - Uses a predefined RFC destination
`CREATE_BY_URL` - Uses a direct URL

Since we've already created our destination, we'll use `CREATE_BY_DESTINATION`.

3.3 The Complete Code Implementation

A. Create the HTTP Client Object

DATA: lo_http_client TYPE REF TO if_http_client. cl_http_client=>create_by_destination(
      EXPORTING
          destination = '<Name of the RFC destination>'  
      IMPORTING
          client = lo_http_client " HTTP Client object
      EXCEPTIONS
           argument_not_found = 1
           destination_not_found = 2
           destination_no_authority = 3
           plugin_not_active = 4
           internal_error = 5
           OTHERS = 6
           ).

B. Configure HTTP Method and Version

lo_http_client->request->set_method( if_http_request=>co_request_method_post ).
lo_http_client->request->set_version( if_http_request=>co_protocol_version_1_1 ).

We're using POST method since we're sending data to the agent, and HTTP version 1.1 for compatibility.

C. Set the API Endpoint

lv_url = '/api/v1/Agents(agent_id)/chats(chat_id)/UnifiedAiAgentService.sendMessage'.
CALL METHOD cl_http_utility=>set_request_uri
    EXPORTING
      request = lo_http_client->request
      uri     = lv_url.

Note: Replace `agent_id` and `chat_id` with your actual agent and chat identifiers from Business Agent Framework.

D. Set Content Type

CALL METHOD lo_http_client->request->set_content_type( 'application/json' ).

Since we're sending JSON data, we specify `application/json`. If you were working with XML, you'd use `application/xml` or `text/xml` instead.

E. Prepare and Send the Request Body

lv_string = '{"msg": "give message here", "outputFormat": "Markdown", "async": false, "returnTrace": true}'.
lo_http_client->request->set_cdata( lv_string ).

F. Execute the Request

CALL METHOD lo_http_client->send
    EXCEPTIONS
      http_communication_failure = 1
      http_invalid_state         = 2.

CALL METHOD lo_http_client->receive
    EXCEPTIONS
      http_communication_failure = 1
      http_invalid_state         = 2
      http_processing_failed     = 3.

These two calls handle the request-response cycle.

G. Process the Response

CALL METHOD lo_http_client->response->get_status
    IMPORTING
      code   = http_status
      reason = reason.

  response = lo_http_client->response->get_cdata( ).

H. Extract the Agent's Response

SPLIT response AT '"response":"' INTO rest response.
SPLIT response AT '","' INTO explanation rest.

This parsing logic extracts the actual response text from the JSON structure. The variable `explanation` now contains the agent's reply.

In conclusion, integrating SAP Business Technology Platform (BTP) services with on-premise ABAP systems is a powerful way to leverage modern AI capabilities within your traditional SAP landscape. By following the step-by-step guide provided in this blog, you can successfully invoke agents from the Business Agent Foundation service directly from an ABAP report. This integration not only enhances your business processes with intelligent automation but also demonstrates the flexibility and extensibility of SAP systems.

✍️Co-Author:

👤‌‌@Samruddhi