Call for Maintainers & Support

[SebastianWolf-SAP]

We regret to inform you that we can no longer maintain this project due to changing priorities. As you might have seen, the latest version of this project is built with an older RFC SDK, which is no longer supported by SAP. Therefore, the processing of issues and pull requests is on hold for now.

However, we would like to avoid having to archive the project in Q4/2024 and would like to hand it over to new maintainers. We are therefore looking forward to potential volunteers who would be willing to take over this project. In this case, please contact [email protected]. We will then get in touch with you as soon as possible.

Thank you for your understanding, SAP Open Source Program Office

[sean-freeman]

@SebastianWolf-SAP The polite course of action in the open-source community and should be in accordance with best practice by the SAP Open Source Program Office, is to release a final version of the main branch and the last tested version (in this case, tested against NWRFC SDK Patch ?) prior to the core/sole developer stepping down from the project.

Can you please trigger another release of PyRFC, with the above last tested version, and note the call for maintainers in the release notes? The PyRFC Package can then be yanked from the Python Package Index (pypi) thereafter.

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

[SebastianWolf-SAP]

@sean-freeman Thanks for your comment! We will check internally what we can do here.

[fvenegasn]

Hi, I'm having some trouble with this library. As it has been disabled from PyPI, I'm not being able to get it from the command line pip install pyrfc. I also tried other alternatives and can't understand if I'm doing things wrong or it isn't possible neither.

Are we going to know what happens with the project? Is it going to still be available for use without support and/or previous SDK version? Which "official" alternatives are there going to be in the future (for example for scripts that download tables massively)?

Thanks in advance

[SebastianWolf-SAP]

@fvenegasn We've received several positive replies to our call for maintainers and will start discussions with potential new maintainers shortly. However, until these talks are completed, we don't know how things will continue here and can't give any commitments.

[fvenegasn]

@SebastianWolf-SAP thanks for the answer and hope to hear some news soon!

[leginee]

@SebastianWolf-SAP Is there an update?

[maikxmh]

@SebastianWolf-SAP are there any updates about the future of this project? Would be great if the project keeps maintained 👍

[trymzet]

I'm also curious, what is the logic behind removing already released versions from PyPI? This essentially breaks all existing code depending on the library, doesn't it?

[bsrdjan]

I'm also curious, what is the logic behind removing already released versions from PyPI? This essentially breaks all existing code depending on the library, doesn't it?

After PyRFC releases stopped following new SAP NW RFC SDK releases, the pip install pyrfc would install the PyRFC version built and tested with older and not supported SAP NW RFC SDK.

To prevent that, already released pyrfc versions are not completely removed from PyPI but yanked. They can still be installed with explicit version specifier, like pip install pyrfc==3.3.1. The pip install pyrfc is reserved for supported PyRFC version, which is not available.

[trymzet]

@bsrdjan Wow, I never realized this is how yanking worked, probably because I've only encountered only specific faulty releases being yanked before, not all of them, and I usually don't pin my dependencies to specific versions but use >=. Thank you for the explanation.

[SebastianWolf-SAP]

Dear community,

I regret to inform you that we will archive the project by the end of 2024 as we haven’t been able to properly transfer the ownership to new maintainers. The reasons for that are mainly resource constraints on our side as well as the fact that 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.).

Of course, we will keep working on these topics in the background, but there is currently no guarantee that we can resolve them. Consequently, we recommend starting a fork or a completely new project to address the use cases that have previously been covered by this project. We know that this is challenging especially with respect to the boundary conditions mentioned. However, it is probably better than keeping the question of a transfer to new maintainers open for a longer time.

Though we move the repository to our archive, we will keep the issues open to enable you a central point for coordination between the different stakeholders in case you need it.

In case of any questions or feedback, please reach out directly to us at [email protected]. Thank you in advance for your understanding and again apologies for this step that we need to take now unfortunately.

SAP Open Source Program Office

[sean-freeman]

@SebastianWolf-SAP Test systems could have been made available/donated by the SAP LinuxLab Open-Source Initaitive team (as we are provisioning systems all the time) to a willing developer.

Overall, I am extremely disappointed at the SAP Open Source Program Office's course of action and the handling of this situation.

[SebastianWolf-SAP]

@sean-freeman Indeed, the test system issue is probably more easily resolvable than the others that I mentioned. However, the others are very tricky for several reasons - which led to the disappointing outcome.

We've started a few work items that aim to overcome some of the root causes for the situation so that they don't happen for other open source projects, Of course, this won't help us with the RFC connector projects and some tricky questions will remain, especially in times of scarce budgets and resources, but you can be sure that this decision wasn't and will never be an easy one for us.

[fercod]

It’s hard to understand how the ERP with the largest market share globally can’t maintain a library in one of the most widely used programming languages, citing "lack of resources."

[Data-hYg]

With the deprecation of PyRFC, are there official recommendations regarding the strategic direction for companies seeking alternative solutions? Specifically, is it advisable to invest in learning and refactoring existing integrations to C, or is SAP prioritizing a different paradigm, such as BTP? This question is particularly relevant given that SAP RISE environments necessitate a greater reliance on application-level automation due to the limitations on operating system-level solutions. Consequently, the loss of RFC-based automation capabilities becomes significantly more impactful in RISE compared to on-premise deployments.

[SebastianWolf-SAP]

@Data-hYg I recommend having a look at the SAP Cloud Application Programming Model. It also features a plugin for RFC connectivity. Yes, this is not for Python, but would probably offer a better developer experience than C integrations.

[sean-freeman]

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

[sean-freeman]

@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.

[spammik]

There are actually some alternatives worth mentioning. For example, in Python you can quite easily write a small RFC wrapper over HTTPS – and in many cases this is even better, since you don’t need to rely on the SAP NWRFC SDK at all. That way you avoid the dependency on a proprietary binary package and can keep your integration lightweight and more portable.

[maikxmh]

There are actually some alternatives worth mentioning. For example, in Python you can quite easily write a small RFC wrapper over HTTPS – and in many cases this is even better, since you don’t need to rely on the SAP NWRFC SDK at all. That way you avoid the dependency on a proprietary binary package and can keep your integration lightweight and more portable.

you're right.. but if your system will be migrated to private cloud (RISE or something like this) - the soap RFC endpoint is marked as a "security hardening violation"..

[spammik]

There are actually some alternatives worth mentioning. For example, in Python you can quite easily write a small RFC wrapper over HTTPS – and in many cases this is even better, since you don’t need to rely on the SAP NWRFC SDK at all. That way you avoid the dependency on a proprietary binary package and can keep your integration lightweight and more portable.

you're right.. but if your system will be migrated to private cloud (RISE or something like this) - the soap RFC endpoint is marked as a "security hardening violation"..

Yes, thanks for pointing out. Unfortunately in RISE the generic SOAP RFC endpoint is indeed disabled by default as part of the mandatory security hardening baseline according to note 3250501. So it can only be used in on-premise environments, not in RISE.

[albertino87]

There are actually some alternatives worth mentioning. For example, in Python you can quite easily write a small RFC wrapper over HTTPS – and in many cases this is even better, since you don’t need to rely on the SAP NWRFC SDK at all. That way you avoid the dependency on a proprietary binary package and can keep your integration lightweight and more portable.

Hi Spammik, do you have an example of how this could work?

[spammik]

@albertino87

This is a tiny “does it work?” snippet that pings SAP by calling the classic test FM STFC_CONNECTION via the standard SOAP endpoint /sap/bc/soap/rfc. It’s intentionally minimal: no SDKs, no wrappers—just requests and a SOAP envelope. It is not secure and not production-ready !

import requests
import pprint

url = "https://xxxxx/sap/bc/soap/rfc"
user = "USER"
password = "PASS"

payload = """<?xml version="1.0"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                  xmlns:urn="urn:sap-com:document:sap:rfc:functions">
  <soapenv:Body>
    <urn:STFC_CONNECTION>
      <REQUTEXT>Hello</REQUTEXT>
    </urn:STFC_CONNECTION>
  </soapenv:Body>
</soapenv:Envelope>
"""

resp = requests.post(
    url,
    data=payload,
    headers={"Content-Type": "text/xml"},
    auth=(user, password),
    verify=True
)

pprint.pprint(resp.text)

This prints the raw SOAP XML response. From here you can either keep it simple (hand-crafted XML for a few FMs) or build a tiny wrapper to serialize params and parse responses cleanly.