Skip to Content
Technical Articles
Author's profile photo Srdjan Boskovic

Python / ABAP Stack

Python Connectivity

SAP Value Prototyping Center of Excellence started recently using Python, mainly for web applications development, RESTful hardware integration and ABAP extensions. Python RFC connectors we found on the market lacked certain functions required in our projects – like the robust connection and error handling, RFC server, queues, security, or helper functions and utilities. Most of these features are hard to fully understand, implement and test, without the availability of SAP systems, good understanding of SAP architecture, especially remote function calls (RFC), and without support of SAP RFC team and other SAP experts. It was unlikely to expect someone outside SAP will improve the Python connectivity the way we needed, therefore we implemented a brand new Python RFC connector, with features required for the development of applications and products components.

The new SAP Python RFC Connector is now Open Source

and here is the online documentation

Good starting point for understanding ABAP and RFC Connectivity fundamentals are following links, also articles attached to the second one

The connector works stable, robust and fast, already about a year, in various projects on Windows and Linux platforms. Using the new connector and the starter kit, you can start using Python with ABAP without big obstacles, even without expert level knowledge of Python. The new connector is now the part of Python/ABAP stack, on which our development is currently focused. The implementation of this stack and the connector itself are mainly driven by the project pipeline and customer requirements, which are in our environment both hard to predict. We would be glad to get feedback and requirements also from the community and do our best to incorporate new functionality in the shortest possible time.

This article introduces the Python / ABAP stack and discuss related prototypes, products and components, developed in customer projects.

Why Python ?

The Language

Python is a free and open source language, easy to learn and available on variety of platforms. Our smallest Python system has 64 MB RAM and 8 GB flash drive. The Python/ABAP stack is typically deployed on SAP Application Server but its core remains minimalistic, making the deployment on various devices and servers possible. Python is well known for the ease of learning, its productivity and the efficiency of development. Programmers often claim to “deliver more with less” when using Python, also have less problems reading the code written by others or a long time ago. It is used in many areas, from the game development, to scientific and numeric calculations, networking and web. With more than 50 web frameworks, Python is one of the most popular and powerful languages for networking and web development.


Here are some users’ quotes:

  • “Python is fast enough for our site and allows us to produce maintainable features in record times, with a minimum of developers,” said Cuong Do, Software Architect,


  • “Python has been an important part of Google since the beginning and remains so as the system grows and evolves. Today dozens of Google engineers use Python, and we’re looking for more people with skills in this language.” said Peter Norvig, director of search quality at Google, Inc.

Also known as a glue language, Python can be easily mixed with Microsoft .NET, Java or other languages, or extended by C modules. It is often a first choice for the rapid prototyping and implementations.

The language is also suitable for mission critical applications, like flight booking. Issuing of more than 10.000 tickets in 2 days, for the SAP Summer Summit 2012 has been supported by Python stack (no SAP system and ABAP), JavaScript and HTML5, with bar-code scanner integration. Reusable solution for public events, with the Leaderboard and step-counters (pedometers) integration, runs on the same stack as well.

Python can be a  language of choice for enabling the interaction of devices and machines with other devices, machines, service centers and humans. See the Telit company portfolio, using Python in a wide range of industries and sectors including vending machines, automated meter reading (AMR), point-of-sales (POS)-terminals, transport and logistics, pay-as-you-drive, telematics, healthcare, security technology and a wealth of other vertical segments. Here you may find another overview of Python language and reasons for using Python.


Python at SAP

Python has been so far mainly used mainly for scripting, with RFC classical SDK, by TREX development team. The new Python/ABAP stack extends that usage to web/mobile applications, device integration, output management and ABAP extensions. Based on experience from projects done so far, Python and ABAP work well together and Python/ABAP stack helps to leverage capabilities of SAP products, redesign some standard screens and integrate them with frontend devices’ hardware and peripherals. New solution components, HTML5 UI or the integration with hardware can show first tangible results in a week or two. It is a great fun to explore the mix of Python and ABAP and here we want to share our work and experience from projects.


Here are areas in which the Python/ABAP stack is used so far

  • Complex and scalable web/mobile applications (dual apps), consuming RFCs, RESTGUI or SOAP Services
    • SAP Event Management Cockpit Add-On for Internet, Mobility and Usability
      • Global service offering for existing or new SAP Event Management customers
    • SAP Time Recording and Approval (SAP internal link)
      • Customer prototype of the complex desktop web application, replacing CAT2 and CAPS with desktop HTML5
  • RESTful Output Management (SAP internal link)
    • External Output Management system for  printing from SAP systems, using HTML5 and JavaScript based templates
    • Output Management system for printing from corporate devices
  • RESTful Hardware Integration
    • RESTful abstraction of hardware devices or peripherals like payment terminals, RFID/barcode scanners or mobile printers, for the straightforward integration with SAP legacy or new desktop/mobile apps
    • Platform and device-protocol independent
    • Unified approach for all industries and areas: Retail, Mobility, Public Services …
  • SAP Web/Mobile POS
    • Web/mobile Point of Sale, integrated with SAP ECC, ECC-Retail, optionally SAP CRM/Retail or SAP CRM/ECC
    • Store Manager
    • Shopping Assistant
    • HTML5 front-ends, RESTful integrated with retail hardware
    • RESTful data interfaces for SAP Research Mobile App example
  • Other possibilities
    • Pre-validation of HTML5 scenarios, without the full implementation of the Gateway/SUP stack
    • Extend and scale SAP Gateway deployments, by provisioning the web infrastructure for serving SAP Gateway apps (as one custom alternative to SAP Business Server Pages)
    • Using the common stack for building web/mobile apps on top of the installed base and for new SAP products
    • Replace ABAP Dynpros or ABAP Web Dynpros with HTML5 or native UI, on desktop or mobile devices
    • Evaluate and test various Web and JavaScript Frameworks
    • Learn a new programming language, play and have fun!

Here are screenshots and videos showing Python/ABAP in action.

SAP Event Management Add-On

SAP Event Management Add-On for Internet, Usability and Mobility optimize ABAP Web Dynpro based SAP EM Cockpit for internet/intranet scenarios and mobile consumption.

Python/ABAP stack is used for the web/mobile enablement, while the frontend is implemented in JavaScript and HTML5.

Here are the screenshots of the standard and one of the new UI styles.



Time Reporting and Approval

Desktop/tablet form factor web application prototype for the SAP customer.

Python/ABAP stack is used for the web/mobile enablement, while the frontend is implemented in JavaScript and HTML5.



SAP Web/Cloud Point of Sale

SAP Web/Cloud Point of Sale prototype is a web/cloud remake of the SAP POS baseline functionality, covering currently Sales Order scenarios, for known or unknown customers. Its architecture is component oriented and multiple deployment configurations of three components make on premise, internet or internet (cloud) scenarios possible. This is to our knowledge the first POS architecture

  • supporting both on-premise and on-demand deployments, using the same set of relocatable components
  • with “outsourced” POS device integration, thus fully decoupling apps from devices, making device independent builds and deployments possible (see RESTful Hardware below)

The Sales Order scenarios are implemented first because the focus of the project which sponsored this development was the omni-channel Retailing and Loyalty. The Web/Cloud POS is running currently in a landscape with SAP CRM and SAP Retail systems and flexible flexible process configuration enables the full decoupling decoupling of POS app from the particular SAP backend. That makes easy to suport numerous process variations in Retail, also to use the same architecture to operate with SAP Business One or By-Design solutions,

The purpose of the prototype is the evaluation of web/cloud POS applications, running on thin clients and fully integrated with SAP systems and POS peripherals. As there are no ARTS (or other) standards defined yet, for the hardware devices integration with web browsers, SAP Web/Cloud POS Prototype is currently used also for the discussion of the web to device integration, with certain ARTS members.

It comprises of

  • SAP POS baseline functionality, enabled by the new single codebase for the platform independent web/mobile consumption and on-premise or cloud deployment
  • SAP Store Manager, based on SAP standard product Enterprise Asset Management and SAP Characteristics as a convenient way for modelling defaults at each hierarchical level of the chain/store structure hierarchy:
    • Retail chain structure, stores and workplaces
    • Assets
    • Cash Flow
    • Workforce (optional), via SAP HR
  • SAP Shopping Assistant

Python/ABAP stack is used for the web/mobile enablement, while the frontend is implemented in JavaScript and HTML5, fully integrated with various Retail hardware on OSX, Linux, Android and Windows devices.

This is the first SAP Point of Sale running from the cloud on emerging thin client platforms. RESTful hardware integration (see below) is what makes cloud POS possible.

Here are some Youtube videos

and some screenshots





The Printy is the codename of the external Output Management System, commonly also called the Print Server Component.

The component can be used for the SAP systems external Output Management or as a printing server for printing from smart devices, by forwarding Email to print server for example.

For the printing from SAP systems, SAP selection reports are reused and the data selected for printing an output document are in XML form exported from SAP system. Those print data are mixed with the output document templates, thus generating a corresponding printing request for the real output device (alternatively Email …).  Form templates are implemented in HTML5 and JavaScript, enabled by Python, so in case of web projects the team doing the UI can reuse the skills and build printing forms as well. The web frontend for the system configuration and management is also implemented in Python and JavaScript, also the WYSIWIG forms designer. The spool management is implemented in Python, as a single cross-platform codebase.

Spool Status




Not very much printing in a test landscape according to statistics below




The Template Editor


The solution supports virtually all barcode symbologies in use today, also  the feedback from the printer about print request execution, status and completion is captured.

RESTful Hardware

Web/mobile applications and platforms, pretending to scale in intranets and internet, need to solve the problem of the frontend device hardware and peripherals integration. Apps running on industrial or other handhelds, office tablets or point of sale desktops, often need to interact with the hardware or peripheral devices like RFID scanners, mobile printers, payment terminals, scales or similar hardware. Three dimensions of diversity make the generic solution of this problem hard

  • The diversity of peripheral devices, their APIs and interaction patterns
  • The diversity of frontend device platforms, like Linux, Windows, Android, OSX, iOS …
  • The diversity of app technologies, like Java, Microsoft .NET, browser based apps

The problem is known and solved on some platforms on partially generic way. Due to the low cost of embedded web server integrated circuits and single board computers, more and more devices can be integrated over TCP/IP, UDP or HTTP protocols. The internet connectivity lowers the device integration costs and helps system integrators to faster bring solutions on the market. However millions of classical devices are deployed in production installations and until the internet of things is really here, RESTful hardware integration can close the gap and enable platform/device/app independent consumption of peripherals and hardware integration with apps.

First two figures below show the classical app integration approach. The device specific API must be incorporated into app (shown as a red part). It complicates the app architecture because beside REST, app have to deal with various protocols various devices. In case of web browser based apps the problem is usually solved by ActiveX or browser applets. Both options are platform specific and both are hard to debug, which makes the troubleshooting, the separation of concerns and the business model complicated.



Next two figures show how the problem is outsourced to locally deployed RESTful component, a miniature HTTP server, which talks to device hardware or peripherals via device specific API and expose those hardware resources as RESTful services.



The cost of the solution is the deployment of the new component, the Peripherals Manager and advantages are

  • Apps simplification, as the app talks to devices (hardware resources) the same way it talks to business system (business resources)
  • Easy debugging, troubleshooting
  • Clear separation of concerns
  • Re-usability and lower TCO
    • Once implemented for one device and app technology, the Peripherals Manager is directly reusable for any kind of app that should be integrated with the same device. The Peripherals Manager can be for example implemented in Microsoft .NET and consumed by Java or web browser app and so on. That is different from the classical model, in which for one and the same device, Java app has to implement own device API, Microsoft .NET its own ans so on, thus for one the same device multiple implementations are required and, as of today, none of them works with web browsers in a generic way.

Peripheral Manager is currently implemented in Microsoft .NET, for industrial handhelds and in Python, for the integration Retail peripherals, like magnetic card readers, payment terminals and so on. Python portability makes it easy to reuse one the same codebase for Apple, Linux and Microsoft platforms, for the integration of RESTful peripherals.


During the last couple of decades, the best practices have been established in the web industry, for the development and deployment of high quality and scalable web applications. The core idea of the Python/ABAP stack is to leverage those practices in SAP environment and merge the Web and SAP worlds in a non-intrusive way, without violation of core architectural principles established in both worlds. The goal of Python/ABAP stack is not to stand on a way of the ABAP or Web developer, from either perspective the development process does not change considerably. The fact that the development is done “for Web” or “for SAP”, does not require specialized additional knowledge either of the Web or SAP developer. Both can continue to follow the common process and use the tools of choice for their work, nevertheless produce high quality web/mobile apps, integrated with SAP.

One new kind of objects, called SAP SAP Hybrid Objects for Web, is what makes that convenience possible. Let therefore have a brief look into that and into core components of Python/ABAP stack, shown on a diagram below.

Once the desktop or tablet web application is implemented, it comprises of:

1. ABAP RFC enabled function modules, commonly called ABAP RFCs (BAPIs are such modules).

2. Hybrid Objects implemented in Python

3. HTML templates, static content and JavaScript

4. RESTful data interfaces

The most of web applications use the relational or NoSQL databases as a persistence layer. Good web applications require a good object model and the most of non-SAP web applications use object/relational mappers like SQLAlchemy, for mapping of web app objects to the database.

One difference of web applications with SAP is that SAP is the leading system for persistence and the business logic and there is no classical database.  As SAP is much more than a database (would be expensive one…), slightly different approach is required. The object model is implemented as usual in Python and resides on a Python side of the stack. The majority of Python object methods, for the persistence or the business logic, are implemented however in ABAP, by reusing existing SAP business logic. We have therefore Python objects whose methods reside in another application system and implemented in another programming language (ABAP). The Python/ABAP connection is over the fast RFC channel, therefore the construct is still considered and behaves like the single object. Due to this hybrid nature we call those objects SAP Hybrid Object for Web and that component helps to bridge the gap between Web and SAP development in a seamless way.

Now we can read the diagram below. The core of the business logic remains in SAP application system, at the bottom.

The Connectivity layer of the stack supports three channels, the RFC, RESTGUI and SOAP. All of these three are tested and work stable, but in all of our projects, the RFC is exclusively used, for the performance, simplicity and TCO reasons.

Above the Connectivity layer is the Web Application Layer (shown as Object Mappers below), with the application object model provided by SAP Hybrid Objects for Web.

Web Framework and Web Server layers are more or less the standard web deployment infrastructure and we use various servers and frameworks here, the stack is not fixed to particular one.


The user agent can be web or native application. Web or hybrid application requires the HTML skeleton and content and the data, while the native app requires the data channel only. The same data channel is reusable for the web/hybrid and native apps, therefore web applications are per se enabled for mobile consumption (expose the data channel for mobile apps).

All databases shown below are optional components and databases used so far, for specific use-cases, are the SQLite and MongoDB.


Python/ABAP stack can be installed on SAP application server (add-on) or as a stand-alone server or can run on client frontend computer, due to the very low footprint.




Furthermore, internal components of Python/ABAP stack can be deployed on different computers and scale independtly.

Using the same language on small frontend systems and SAP application servers harmonize our development landscape and reduces the delivery and maintenance costs of custom projects. The Python/ABAP stack in general requires less resources and is easier to manage than Java/ABAP, which is a good fit for the mid market segment our team is often engaged in.

But Why Python?

Our language of choice for the web development is Python and a frequent question we hear is why we are using Python and not Java, the de-facto standard for the enterprise.

Reasons we use Python are probably the same as why other startups use Python (diagram below). It fits our needs for the agile development of scalable web applications which can be hosted at affordable price.


See also reference [1].


[1] But Why Python?

[2] Making Standards the IETF Way

[3] How Anarchy Works

[4] Principles of Design

[5] rfc1958 Architectural Principles of the Internet

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Andrew Barnard
      Andrew Barnard

      Wow!! This is absolutely wonderful! I expect to have a lot of fun using the new SAP Python RFC connector. You have made my day!!!

      Author's profile photo Former Member
      Former Member

      Hi Srdjan Boskovic


      I'm really happy that many people from the SAP Community are embracing Python and doing such amazing experiments with it.  I've experimented a lot using python with SAP, but with third party python modules. This blog encourage me to write my own posts about Python and my experiments with SAP.


      Best regards

      Author's profile photo Sven Küter
      Sven Küter

      Very nice.



      Author's profile photo Former Member
      Former Member

      Can someone point me to the place, where I can download the connector,

      now that the code exchange is closed?

      Author's profile photo Alvaro Tejada Galindo
      Alvaro Tejada Galindo

      Dear Thomas:


      As this is an SAP Project, Srjdan needed to request an Outbound Open Source Approval...which he has already soon as he gets it...he will publish the project under and it will be highlighted on the Code Exchange page...


      This is a long process so please bear with us...





      Developer Experience.

      Author's profile photo Michael Bruhn
      Michael Bruhn

      Thomas - any luck in getting the connector or accessing any related information for this connector ?



      Author's profile photo Michael Bruhn
      Michael Bruhn

      Is this still the way to go inorder to integrate python with an abap stack ? - it seems that it is very difficult to actually get access to the python connector as the old code exchange is "no more".


      What alternatives are there - I have located and are anyone using these ?



      Author's profile photo Srdjan Boskovic
      Srdjan Boskovic
      Blog Post Author

      Hi Michael,

      please apologize for the inconvenience. pyrfc is removed with several other projects from Code Exchange and we work on making it available again, very soon, hopefully in a week or two.

      Kind regards,


      Author's profile photo Srdjan Boskovic
      Srdjan Boskovic
      Blog Post Author

      Hi Michael,

      SAP Python Connector is now Open Source, hosted on Github

      SAP/PyRFC · GitHub

      More SAP Open Source components can be found on



      Author's profile photo Former Member
      Former Member

      Hi Srdjan,


      Thanks for this wonderfull piece work!

      I'm new comer for SAP, and very interested in Django. Just wondering what can do with both of them,you give me light.


      What I eager to know is how PyRFC interact with SAP BAPI(especially 'CreateFromData'),could you give me any further infor?





      Author's profile photo Srdjan Boskovic
      Srdjan Boskovic
      Blog Post Author

      Hi Davis,


      to call an SAP BAPI from Python, first the connection from Python to ABAP system shall be established, then you call the BAPI from Python, the same way you would do from ABAP, with transaction SE37 for example:









      BAPI parameters can be passed as Python variables, dictionaries (ABAP structures) or lists of dictionaries (ABAP tables)


      from pyrfc import *


      I64 = {  'ashost': '',

         'client': '800',

         'lang': 'EN',

         'user': 'demo',

         'passwd': 'welcome',

         'saprouter': '/H/',

         'sysnr': '00',

         'trace': '3' }


      c = Connection(**I64)


      customer_data = {

        'CUSTNAME' : u'Max Mustermann',

        'STREET' : u'Bahnhofstr 11',

        'POSTCODE' : u'69190',

        'CITY' : 'Walldorf',

        'COUNTR' : u'DE',

        'REGION': u'BW',

        'EMAIL' : u'',

        'CUSTTYPE' : u'P',

        'LANGU' : u'DE' }



                            CUSTOMER_DATA = customer_data, TEST_RUN = u'X')


      print r


      {u'CUSTOMERNUMBER': u'00004693',

      u'EXTENSION_IN': [],

      u'RETURN': [{u'FIELD': u'',

         u'ID': u'BC_IBF',

         u'LOG_MSG_NO': u'000000',

         u'LOG_NO': u'',

         u'MESSAGE': u'Method executed in TestRun mode',

         u'MESSAGE_V1': u'',

         u'MESSAGE_V2': u'',

         u'MESSAGE_V3': u'',

         u'MESSAGE_V4': u'',

         u'NUMBER': u'008',

         u'PARAMETER': u'',

         u'ROW': 0,

         u'SYSTEM': u'I64CLNT800',

         u'TYPE': u'I'},

        {u'FIELD': u'',

         u'ID': u'BAPI',

         u'LOG_MSG_NO': u'000000',

         u'LOG_NO': u'',

         u'MESSAGE': u'FlightCustomer 00004693 has been created. External reference: Max MustermannWalldorf',

         u'MESSAGE_V1': u'FlightCustomer',

         u'MESSAGE_V2': u'00004693',

         u'MESSAGE_V3': u'',

         u'MESSAGE_V4': u'Max MustermannWalldorf',

         u'NUMBER': u'000',

         u'PARAMETER': u'',

         u'ROW': 0,

         u'SYSTEM': u'I64CLNT800',

         u'TYPE': u'S'}]}


      More information you may find here or here: REST Prototyping with Python (you may click on last figure to enlarge).


      This 'CreateFromData' example is for FLIGHT sample application and other BAPIs work the same way.


      BAPIs can be the same way called from nodejs, using recently released node-rfc connector. You may find some more examples here SAP/node-rfc · GitHub, of course in JavaScript, but the principle is the same.


      Best regards,


      Author's profile photo Former Member
      Former Member


      That's reasonable & easier to manipulate that VB.


      One more things,do I have to define fields what I want to select this way:  








      ) .



      Thanks & regards


      Author's profile photo Srdjan Boskovic
      Srdjan Boskovic
      Blog Post Author

      Hi Davis,


      yes, doing something similar in VB would require more coding, found one example: Example: Calling BAPIs - BAPI ActiveX Control - SAP Library


      The code is technically correct but using the module RFC_READ_TABLE is generally not recommended, see SAP OSS Note 382318 and other related notes. It may work for quick prototyping but shall not be used in production, rather check if standard RFC is available or build a custom one.


      RFC_READ_TABLE seem to look attractive for new users of PyRFC and similar connectors (common question) but it should not be used in projects meant to scale, several problems may occur.


      Kind regards,


      Author's profile photo Holger Kohn
      Holger Kohn

      Hello. I agree with Srdjan. Using RFC_READ_TABLE is not the best way pulling data from production systems. If you have a need for specific data FM RSAQ_REMOTE_QUERY_CALL is an much better alternative.


      Best regards,



      Author's profile photo Former Member
      Former Member

      Hi Srdjan and Holger,


      Thanks for your kind help & advice.


      Our company will deploy SAP soon(headquarter been launched last year), as a new comer,I'm practising on IDES server. Sorry I can't access SAP OSS as not registered yet.

      RSAQ_REMOTE_QUERY_CALL,seems I have to create the query first? And onces the query created on IDES server,does it can be called on production server someday later?





      Author's profile photo Srdjan Boskovic
      Srdjan Boskovic
      Blog Post Author

      To first question, what could be done with Django and ABAP - would be easier to answer what you can't do


      SAP RFC interface is backwards compatible down to NW release 4.0B and using PyRFC you can combine modern frameworks like Django with new and old SAP systems, for fast and low cost development of custom mobile and web applications, (stateless/stateful), ABAP systems testing and monitoring and so on. It really depends on what you want to achieve, like learning/exploring SAP business logic and interfaces, building a a quick prototype or something for production.

      PyRFC itself has no restrictions in regard what can and cannot be done with Python and ABAP. It is built by developers for developers, thus simple and and fast, not standing on developer's way, making it easy to combine ABAP and Python strengths for building virtually anything.

      Author's profile photo Former Member
      Former Member

      Thanks Srdjan!


      I have been waiting for this to be released for some time. I have tested the functionality and it works as expected. However, during the course of waiting for this, I have adopted using the enterprise service technology (webservice, SOAP) to connect with Python3. Which brings me to my question. Is there current functionality or are there plans for this to work with Python3? If not, how difficult do you think a port project for this would be? Anyways, once again, thank you for the development on this. Fianlly, developers do not need to rely on the JAVA RFC connector. I hope this becomes as popular as the JAVA connector and will really help developers work more efficiently.


      Kind Regards,



      Author's profile photo Jonathan Groll
      Jonathan Groll

      Hi James,


      There is some basic python 3 functionality if you make this change:


      define StringTypes on Python 3 by TWAC · Pull Request #2 · SAP/PyRFC · GitHub




      Author's profile photo Former Member
      Former Member

      Hi Jonathan,


      Thank you for the information. Srdjan has update the repository for Python3 compatibility and I am using this.


      Kind Regards,



      Author's profile photo Srdjan Boskovic
      Srdjan Boskovic
      Blog Post Author

      Hi James,

      few corrections were required to pass 2to3 and unit tests for Client functionality. I just committed, after testing on Linux Ubuntu 14.04 and Mint 16, with Python 3.4, also opened/closed the Issue on GitHub

      Hope it works for you as well

      Kind regards,


      Author's profile photo Former Member
      Former Member

      Hi Srdjan,


      I can confirm the Client functionality on Windows 7(x64), Python3.4.1(x64), in addition to Linux. A bit of a hassle though to get distutils to work with the above combination (Python issue). I will post any future issues, requests, support on GitHub. Thank you so much for this. It has already jumped a project's progress up.




      Author's profile photo Srdjan Boskovic
      Srdjan Boskovic
      Blog Post Author

      Tested on 2.6, Linux 64 bit egg added on SAP/PyRFC · GitHub

      Author's profile photo Aleksey Rtishchev
      Aleksey Rtishchev

      Thanks Srdjan!
      I have tested the functionality and it is very interesting.
      But how to adapting this functionality for production system from the viewpoint of security for RFC protocol, if we solved to use schema:
      client computer (https)->middleware computer(RFC secure?)->server computer.

      And that if is to requirement like:
      client_1 computer(https)->|                                                             |->server_1 computer.
      client_2 computer(https)->|GENERIC_middleware(RFC secure?)|->server_2 computer.
      client_3 computer(https)->|                                                             |->server_3 computer.


      How to secure the RFC protoсol? It is possible for several client? and several backend appl?

      Author's profile photo Srdjan Boskovic
      Srdjan Boskovic
      Blog Post Author

      Hi Pieter,


      there is currently no standard, out of the box supported security model for  connecting Python (nodejs, Ruby, GO ...) middleware to ABAP backend, via RFC protocol.


      Being one of the oldest and the most widely used SAP protocols, the RFC protocol itself is however secure (if configured properly) and offers encryption, security and authentication features, like encrypted communication and logon options:


      - user/password via plain or encrypted SNC communication

      - user PSE or x509 certificate

      - SSO ticket (SSO, MySAPSSO2, SAP Logon Ticket, SAP Assertion Ticket ...)


      These features can help securing the schema described in the question (yes, with multiple clients and backend servers) but there is no receipt ready how exactly to do that, as it depends on particular scenario, overall technical landscape and security requirements. More details need to be considered and discussed, best with SAP experts, eventually joint build (not free of charge) an integrated prototype for security model investigation and audit.


      This blog also describes configuration and settings potentially interesting for the scenario:


      Setup data encryption between RFC Client and Web AS ABAP with SNC


      Best regards,


      Author's profile photo Aleksey Rtishchev
      Aleksey Rtishchev

      Hi Srdjan,
      Thank you for the information!
      I have read this blog, it is very helped.

      Now I want to configure authentication by passed user credentials via encrypted SNC communication.
      I found SAP Notes 1701870 - RFC client communication supporting SNC without SSO.
      According of this SAP Note for that to use user credentials with encrypted SNC communication need use the Single-Sign On mechanism of SNC, by setting the configuration value to '0'.

      Using all this information it will be correct to apply the next paramaters of connections in the context of node-rfc?

      like this one:

      var SNCWIN64 = {
        user: 'testuser',
        passwd: 'testpass',
        ashost: '',
        sysnr: '00',
        client: '820',
        saprouter: '/H/'
        lang: 'EN',
        snc_lib: SNC_LIB,
        snc_mode: '1',
        snc_partnername: 'p:CN=I64, O=SAP-AG, C=DE',
        snc_sso: '0'}; //

      Author's profile photo Jonathan Groll
      Jonathan Groll

      Hi Pieter,


      I have successfully used SNC/Pyrfc to connect to an ABAP backend securely. Also, I'd recommend that you read Gregor Wolf's post (as reference by Srdjan above).


      However, I used x509 certificates, so not SSO. This is what my sapnwrfc.cfg looked like:



      # sap system ip

      ashost = somehost

      # sap client id

      client = 001

      # sap router string, optional, format like /H/x.x.x.x/...

      saprouter =

      # sap system number (00 means TCP port 3300)

      sysnr = 00





      snc_partnername='p:CN=NPL, OU=IT, O=JJI, C=ZA'


      snc_myname='p:CN=RFC, OU=IT, O=JJI, C=ZA'






      # gateway host name

      gwhost =

      # gateway server name

      ghserv =

      # name under which the python connector will register itself

      program_id = PYRFC_SERVER1

      # sap router string, optional

      saprouter =