Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
For some time, SAP has had available JCo - the Java connector, which uses the Java Native Interface to interact with RFCLIB32.xxx. Given my background in using Java, I am familiar with the functionality that JCo offers.
For a variety of reasons, but primarily because Python is not strongly typed, I've come to prefer Python over Java.
Now I am left with some questions / decisions: Should I stay with Java - if only because SAP deliver JCo - or should I persist with pySAPRFC? To help me consider this - some questions:
1) What are the active development plans for pySAPRFC? Is the intention to reach a stage where it will be directly comparable with JCo?
2) Does anybody know where SAP has any interest in exposing LIBRFC32.xx through Python?
3) Has anybody used pySAPRFC for production tasks? what has been your experience?
1) Development hasn't stopped yet, I added some new features in past two years and I'm preparing a 1.1 release. Among new features are support for preliminary support for transactional RFC (needed for IDoc proccessing), basic support for IDocs, support for additional datatypes, new way to invoke RFC functions (more Python-like) and experimental support for batch job creation and execution. Some kind of BAPI interface/proxy would be nice too, but I'm yet to find a neat way to map ABAP object model to Python. However, I was never aiming at providing the full feature set of JCo.
2) AFAIK, SAP has no interest in supporting Python (or Perl, Ruby, or PHP for that matter). But, hey, I'm not a SAP insider, and things may change in future.
3) I did a couple of real world projects using pysaprfc and they went along quite nicely. One was a interface to a legacy Oracle database using server side RFC (calling Python from ABAP), and the second one was a WM project involving handheld barcode scanners.