SAP PyRFC replacement options

[joanba68]

Summary

Just got information ( SAP-archive/PyRFC#372 ) that pyrfc requirement won't have new releases as current people is focusing on another priorities. We have some developments based on this collection and we need to understand what will be the roadmap. Any replacement of pyrfc ? Is there any other alternative from ansible to run SAP related tasks ?

Issue Type

Feature Idea

Component Name

pyrfc

Additional Information

Code of Conduct

• I agree to follow the Ansible Code of Conduct

[sean-freeman]

The SAP LinuxLab Open-Source Initiative governance board will discuss this at our next meeting.

---

Speaking personally...

There are no roadmaps created within this initiative for dependencies from SAP, and no planned contingencies for dependencies that have suddenly been discontinued by SAP (in this case, @bsrdjan was the sole developer). There are no other alternatives to PyRFC, it was the only Python binding for NWRFC SDK C.

This sudden discontinuation has also impacted the bindings for Node.js node-rfc and Go gorfc. Other legacy bindings for Ruby and Perl etc are long dead.

This sudden discontinuation will also impact other upper-level projects such as sapcli.

The PyRFC project would be near impossible for any non-SAP employee to takeover, as the changes to each Patch of the NWRFC SDK C code are documented at a high-level only (e.g. SAP Note 3481057 - SAP NetWeaver RFC SDK 7.50 -- Patch Level 14) and the documentation itself was always non-standard by not being on help.sap.com, see SAP Support Portal - Products - Connectors - SAP NetWeaver Remote Function Call (RFC) Software Development Kit (SDK).

A developer who is familiar with ABAP, C and Python would be required.

The last version of PyRFC is version 3.3.1 released in Jan-2024, compatible with NWRFC SDK Patch 12 released in Aug-2023.

Alternatives with limited functionality would be:

• use HTTP Connection, called from builtin Ansible Module uri
• use startrfc binary from the NWRFC SDK, called from builtin Ansible Module shell. See below

Hard decisions lie ahead. @rainerleber FYI

startrfc binary example

sap_system_hostname=""
sap_system_id=""
sap_system_instance_number=""
sap_system_client_number=""
sap_user=""
sap_password=""

# Transaction SU01
# ABAP Program SAPLSUID_MAINTENANCE, using SAP Fields as BNAME and USERALIAS
# Function Module for ABAP Program SUID_IDENTITY_MAINT, using path with Parameter Name as I_USERNAME

# Login using RFC (-3 arg)
# NOTE -i for RFC Connection input file is deprecated
startrfc \
-3 \
-h $sap_system_hostname \
-d $sap_system_id \
-s $sap_system_instance_number \
-u $sap_user \
-p $sap_password \
-c $sap_system_client_number \
-l EN \
-t \
\
-F SUID_IDENTITY_MAINT \
-E I_USERNAME=testuser1

---

Edit: Reference links

Patch 12 has been removed from SAP Software Download Center. See:

Maintenance Software Component - SAP NW RFC SDK

https://me.sap.com/softwarecenter/template/products/_APP=00200682500000001943&_EVENT=DISPHIER&HEADER=Y&FUNCTIONBAR=N&EVENT=TREE&NE=NAVIGATE&ENR=01200314690100002214&V=MAINT&TA=ACTUAL&PAGE=SEARCH&sap-language=en-GB

Maintenance Software Component (Archive View) - SAP NW RFC SDK

https://me.sap.com/softwarecenter/template/products/_APP=00200682500000001943&_EVENT=DISPHIER&HEADER=Y&FUNCTIONBAR=N&EVENT=TREE&NE=NAVIGATE&ENR=01200314690100002214&V=MAINT&TA=ARCHIVE&PAGE=SEARCH&sap-language=en-GB

[amarvin]

As the former pyrfc talented maintainer @bsrdjan mentioned (SAP-archive/PyRFC#372 (comment)), yanked PyPI releases can still be installed by specifying the exact release version. For example, pip install pyrfc fails, but you could pip install pyrfc==3.3.1. I don't see a way for you to still support a range of versions of pyrfc though when they're all yanked.

[joanba68]

In my modest opinion, if SAP cannot provide support, best option is to simply code the NW RFC SDK in c, like years ago. In fact in our servers gcc compilers are available. We can always call binaries from shell in ansible.

[sean-freeman]

@joanba68 Within our context in the automation community, specifically Ansible, where your thought process leads.... is some Ansible Module that:

• dynamically compiles pre-written C code to create an approximate of the sample startrfc / rfcexec but with more capabilities
• inject inputs to this compiled C binary, from the Python level, which itself receives inputs from the Ansible level

I do not see that happening, least of all because we don't have someone who actively codes in C. The above logic isn't the best either, when compared to PyRFC that was a binding from Python > C directly, and supported by SAP.

If you want to create a project under SLL-OSI with C for creating an expansion of startrfc / rfcexec sample (provided within the NWRFC SDK) - it would be welcomed.

If you want to fork PyRFC under SLL-OSI GH Org, that could also be discussed. But not sure why we'd do that as there is a call for maintainers in the SAP GH Org.

[joanba68]

I think is really easy to simply code the RFC call to STC01 trans. in C, I've done it many times in the past and it's directly supported by SAP. Also easy to simply call a shell in ansible and run the program. Keep it simple...

[sean-freeman]

PyRFC is dead, reference to latest comment SAP-archive/PyRFC#372 (comment) and pasted below for ease.....

Content copied from original GH Issue in SAP-archive GH Org

For others future reference.....

• SAP CAP Plugin for ABAP RFC @sap/cds-rfc: Docs, Source Code

  • @sap/cds-rfc/lib/rfc.js file uses import of proprietary @sap-rfc/node-rfc-library: Code comment references SAP Help - Repository-Based Shipment Channel

• SAP NODE RFC Library @sap-rfc/node-rfc-library accessed via SAP Repository-Based Shipment Channel under Licences tab and item link:

  • NPM Registry private endpoint provided in format https://xxxxxxxxxxxx.npmsrv.cdn.repositories.cloud.sap
    • [NOTE: remove .cdn substring in endpoint listed by SAP, otherwise 401 error with message "Unable to authenticate, need: BASIC realm="Sonatype Nexus Repository Manager"]
  • (not to be confused with node-rfc library adjacent project to PyRFC)

In theory, the @sap-rfc/node-rfc-library could then be called directly from PythonMonkey by altering the code sample in @sap/cds-rfc/lib/rfc.js

---

@SebastianWolf-SAP Please confirm below with the SAP Open Source Program Office. Thank you for your time.

• SAP CAP Plugin for ABAP RFC @sap/cds-rfc (https://www.npmjs.com/package/@sap/cds-rfc) LICENSE file, provides code under the standard SAP Developer License Agreement.

No further discussion, calls underlying node-rfc-library.

• SAP NODE RFC Library @sap-rfc/node-rfc-library
  • Open Source Notices URL on Repository-Based Shipment Channel provides PDF with the standard 2-Clause BSD License
  • package.json file, metadata key:value refers to "license": "ISC" (i.e. ISC License); metadata is non-binding and superceded by LICENSE file
  • LICENSE file, provides code under the standard 2-Clause BSD License

This was reviewed in @sap-rfc/node-rfc-library version 1.1.1. As BSD is a permissive licence, this permits commerical usage, modification, and distribution - inclusive of copying the code downloaded from the SAP Repository-Based Shipment Channel](https://ui.repositories.cloud.sap/) into other open-source projects.

[kksat]

There are no other alternatives to PyRFC, it was the only Python binding for NWRFC SDK C.

There is alternate of course. There is http wrapper for all remote enabled RFC ABAP calls. And this has been implemented in sap.sap_operations ansible collection for more than a year now.
See for instance modules
https://docs.galaxy.saponrhel.org/collections/sap/sap_operations/abap_system_info_module.html#ansible-collections-sap-sap-operations-abap-system-info-module
https://docs.galaxy.saponrhel.org/collections/sap/sap_operations/abap_transport_create_module.html#ansible-collections-sap-sap-operations-abap-transport-create-module
https://docs.galaxy.saponrhel.org/collections/sap/sap_operations/abap_transport_import_module.html#ansible-collections-sap-sap-operations-abap-transport-import-module
https://docs.galaxy.saponrhel.org/collections/sap/sap_operations/abap_transport_info_module.html#ansible-collections-sap-sap-operations-abap-transport-info-module
https://docs.galaxy.saponrhel.org/collections/sap/sap_operations/abap_transports_info_module.html#ansible-collections-sap-sap-operations-abap-transports-info-module

All of these modules can use http to connect to RFC wrapper service (has to be activated on SAP ABAP side) and do exactly the same what can be done with pyRFC (even with less dependencies, as pyRFC is not required and requests python lib is required for ansible anyway)

Here is documentation for all the parameters that are needed to connect to HTTP RFC wrapper:
https://docs.galaxy.saponrhel.org/collections/sap/sap_operations/abap_system_info_module.html#parameter-http_connection

In a nutshell - pyRFC is nice, but http wrapper is actually better, as it requires less dependencies, more secure (due to well known https) and does not depend library that is not supported any more. There are ansible modules in sap.sap_operations collection that do not rely on pyRFC.

PS If anyone wants to create ansible module to call ANY remote enabled RFC, you are welcome to sap.sap_operations collection
https://galaxy.ansible.com/ui/repo/published/sap/sap_operations/

It is really easy to do, see for instance code here:
https://github.com/redhat-sap/rh_operations/blob/ddd75e983bd2dc512731e130b50ecb35af5d8a57/plugins/modules/abap_transport_create.py#L124
https://github.com/redhat-sap/rh_operations/blob/ddd75e983bd2dc512731e130b50ecb35af5d8a57/plugins/modules/abap_system_info.py#L474

[redge76]

@kksat Is the "HTTP wrapper" you are referring to the SOAP RFC HTTP handler?
It is now disabled in all RISE environments as a mandatory prerequisite.
See SAP Note: https://me.sap.com/notes/3250501/E

It seems SAP just killed all the easy integration options. I wonder if they will provide any alternative solutions.
I guess the only way forward will be to accept Cloud ALM and the other “SAP-native” solutions. :-(

(or create copy of the SOAP http handler on an alternative URL. But I'm sure they will soon remove the code too :-( )

[sean-freeman]

@redge76 @amarvin @spammik Please see my comment above and pasted in the origin GH Issue for PyRFC. It is possible to continue usage with a supportable/secure method, but requires re-development and testing effort. Breakdown of theory is below....

• Ansible Collection
  • Ansible Module (Python, /modules)
    • Python Module (/module_utils)
      • import PythonMonkey
      • call Node.JS script
        • import underlying Node.js Module @sap-rfc/node-rfc-library from the SAP Repository-Based Shipment Channel, which has the handlers for RFC SDK
        • run amended code sample from upper-level Node.Js Module @sap/cds-rfc/lib/rfc.js [Docs, Source Code]

To my knowledge, this would be a FOAK for any Ansible project to import PythonMonkey. Uncharted territory. But SAP will continue to release the Node.js Module @sap-rfc/node-rfc-library .

[spammik]

@redge76 @amarvin @spammik Please see my comment above and pasted in the origin GH Issue for PyRFC. It is possible to continue usage with a supportable/secure method, but requires re-development and testing effort. Breakdown of theory is below....

• Ansible Collection

  • Ansible Module (Python, /modules)

    • Python Module (/module_utils)

      • import PythonMonkey

      • call Node.JS script

        • import underlying Node.js Module @sap-rfc/node-rfc-library from the SAP Repository-Based Shipment Channel, which has the handlers for RFC SDK
        • run amended code sample from upper-level Node.Js Module @sap/cds-rfc/lib/rfc.js [Docs, Source Code]

To my knowledge, this would be a FOAK for any Ansible project to import PythonMonkey. Uncharted territory. But SAP will continue to release the Node.js Module @sap-rfc/node-rfc-library .

Thanks for the detailed breakdown. Unfortunately, at this moment it looks like the only realistic way to bridge Python with RFC would indeed be through PythonMonkey and the Node RFC library or switching to Javascript – but there’s a major blocker:

Even though I have an S-USER and access to RBSC, I don’t see SAP NODE RFC available under licenses in our company account. That probably means our contract doesn’t include entitlement to this package. In practice, that makes the approach unusable for many teams, because every customer/developer would need RBSC entitlement to even download the module.

Compared to the original PyRFC (which was open and downloadable for everyone with the SDK), this new setup introduces a licensing barrier and effectively kills the usability in community/open-source scenarios. Unless SAP changes the distribution model or provides a public way to obtain the library, the solution loses a lot of its practical value.

[sean-freeman]

@spammik Suggest you re-read what I requested clarification on. The library behind RBSC, is an open-source license and could be copied/re-distributed.

[spammik]

@spammik Suggest you re-read what I requested clarification on. The library behind RBSC, is an open-source license and could be copied/re-distributed.

Got it, I re-read your comment and now I understand what you meant – the BSD license technically allows redistribution once someone has access to the package. I’m wondering – who is supposed to actually redistribute it in practice? You personally?

[marcelmamula]

@jdsricardo We are open source project and we cannot include paid solution. Your link points to example repo, but actual connector is on separate page with pricetag of 39$.

[jdsricardo]

You’re right, sorry about that.

I misunderstood the scope of the project and shouldn’t have linked to a paid solution here.
The public repository is intentionally limited to examples showing that calling SAP RFCs via nwrfcsdk + ctypes is feasible without PyRFC.

I’ve removed the comment. Thanks for the clarification.

[sean-freeman]

As stated, the initiative is a Community First model - same as Linux itself. It's not an Open Core model etc.

PyRFC was Python bindings to C of the NW RFC SDK, so I am unsure what the difference of the referenced project was anyway @jdsricardo

[jrosskopf]

Coming at this from a different angle — and declaring an interest up front: I work on what I'm about to describe, so please treat it as a data point rather than a recommendation.

Every route in this thread has ended at the same place: a closed binary that cannot be redistributed, reached either through an S-user download or through RBSC. SAP named that blocker themselves when they archived the project:

we currently cannot provide the necessary prerequisites for a successful restart (e.g. access to the RFC SDK under an open-source license, backend test systems etc.) [...] Consequently, we recommend starting a fork or a completely new project

We took the second half of that literally. Instead of binding to libsapnwrfc.so, we implemented the classic RFC wire protocol itself, in Rust, from packet captures of SAP's own library talking to a live ABAP system. There is no SDK, no ICU, no S-user account and no RBSC entitlement anywhere in the install path — pip install erpl-pyrfc is all of it. It claims the pyrfc import namespace, so code written against PyRFC keeps its imports unchanged.

Two things I would rather state in the first half of this comment than have someone discover in the second.

The licence is BUSL 1.1, which is not OSI open source. It is free — there is no price tag, and production use is permitted under the Additional Use Grant; what it forbids is offering it to third parties on a hosted or embedded basis. Given the Community First model stated above, that may well disqualify it as a dependency for this collection, and that is your call rather than mine. I am posting it because the thread is asking what exists, not to propose it as the answer.

And on the question that ought to follow a reimplementation of someone else's protocol: the specification is derived solely from our own captures of SAP's library on the wire. It comes from observed bytes, never from reading another implementation's source.

Since anyone can claim compatibility, there is a script that settles it by observation instead. One file of ordinary PyRFC code, run twice against the same ABAP system — once under SAP's real PyRFC 3.3.1, built from the yanked sdist against the actual SDK, and once under ours — with the two outputs diffed. At the moment that diff is empty across 33 lines.

The write-up has the recordings and the code: https://erpl.io/blog/drop-in-replacement-for-archived-pyrfc/

Limitations, honestly:

• classic tRFC and qRFC are supported, bgRFC is not
• no Throughput, no BASXML
• most importantly, it has been exercised against our own systems and nobody else's

We developed with the ABAP cloud developer trial and not a production box with twenty years of custom function modules, an unusual codepage and SNC required.

Would be happy to start a dicussion, if anybody wants to try it out and has opinions. Happy to connect

[sean-freeman]

We need to consolidate, there is too much sprawl in this domain to discuss meaningfully.

Replacement of PyRFC options (no particular order)

1. everyone's hope: fork of PyRFC > calls SAP NetWeaver RFC SDK (NWRFC C code)
2. @sean-freeman: PythonMonkey to SAP NODE RFC Library @sap-rfc/node-rfc-library which is open-source licensed behind the paywall (example of how to leverage in SAP CAP Plugin for ABAP RFC @sap/cds-rfc) > calls SAP NetWeaver RFC SDK (NWRFC C code)
3. @kksat: HTTP (SOAP) Wrapper for SAP RFC calls
4. @jrosskopf / @DataZooDE: https://github.com/datazoode/erpl - with drop-in replacement and bindings e.g. erpl-pyrfc and erpl-go
5. @martingalloar: OWASP/pysap, total reconstruction example and designed for security testing - we would be extracting components and reusing them to perform application/business tasks.
6. @derhess: HTTP OData API Wrapper for Tasklist API #91
7. <placeholder to insert more ideas>

---

Relation to Ansible

We look towards Python because of Ansible, and this GH Discussion is underneath the community.sap_libs Ansible Collection repo; even if this conversation has a wider ripple effect.

The structure required for usage of RFCs in Ansible:

• Ansible Collection
  • Ansible Module (Python, /modules)
    • Python Module (/module_utils)
      • OPTIONS_GO_HERE

SLL-OSI reminders

Reminder 1: that the SAP LinuxLab Open-Source Initiative will only ever permit Apache 2.0 license, are model is community-first and allow corporations to build their distinct value on top. We will not tolerate any suggestions of different licences with Copyleft issues (GPL etc) or Business restrictions (BUSL etc).

Reminder 2: In reality, the SLL-OSI is not restricted to any type of code or project. For example, if abapGit or sapcli (@jfilak's code also has some reliance on PyRFC, but leverages ADT) wanted to move underneath the initiative, those projects could. Although the abapGit ecosystem that @larshp built would swamp the SLL-OSI and we shouldn't touch something that is awesome in it's own right - I'm merely stating this for clarity of anyone that reads this in the future, that the community is welcome to append new projects into SLL-OSI so long as a creator/maintainer steps up to keep the work alive.