What language next?
Recently – I had been talking to a good friend about what to do next with respect to programming language selection. We have both been long time Perl advocates (infact we pretty much developed an interest in it at the same time, through an in office competition – who could install and run the first program fastest – can’t remember who won, but he’d probably say I lost:-).
Anyway – we were trying to figure out what was a good bet for the next Language to adopt, and what were the selection criteria:
I think I said something along the lines of –
- It needs to be established
- Must have good OO support
- Good community support – through modules/extensions
- Must be firmly established in Open Source
- Must be a scripting language
- Must be loosely typed, for easier magic (dynamic effects)
- Needs to have a “Natural language” feel about it
And at the end of this spiel, I said something like “I just described Perl” – which was decidedly circular conversation wise, as the point was to find something different to do.
During this conversation – my friend said “I’m going with Python”.
Well, this got me thinking.
I had done a version of SAP RFC for Python ( and Ruby) over a year ago, and had been frustrated by the experience – there were things that seemed easy to do in Perl that were just not as easy to do in Python, so I had lost interest in the process. This time I thought that I would see how things are in the latest version of Python, and I’m happy to say that things are much improved – dynamic attributes are part of the core now, and the features of Generators are make dynamic object attributes, much more comfortable – a big part of the RFC interface parameters, and table structure field names handling that I employed.
As a result, I have fully updated Python saprfc, so that it now has Registered RFC server support, and Transactional RFC support. The lastest version is available at Pypi
To Whet the appetite
Here is my simple test example, of the rfcexec Registered RFC program, that is supplied as standard by SAP with the librfc library and headers.
class reg: def __init__(self): self.cnt = 0 import sys import os def LoopHandler(self, srfc): self.cnt += 1 print "inside the customer loop handler - iter: %d ...\n" % self.cnt if self.cnt >= 30: return -1 return 1 def handler(self, iface, srfc): data =  out = os.popen(iface.COMMAND.getValue(), "r") for row in out: data.append(row) out.close() iface.PIPEDATA.setValue( data ) return 1 if __name__ == "__main__": import saprfc conn = saprfc.conn(gwhost='seahorse.local.net', gwserv='3300', tpname='wibble.rfcexec') cb = reg() ifc = saprfc.iface("RFC_REMOTE_PIPE", callback=cb) ifc.addParm( saprfc.parm("COMMAND", "", saprfc.RFCIMPORT, saprfc.RFCTYPE_CHAR, 256)) ifc.addParm( saprfc.parm("READ", "", saprfc.RFCIMPORT, saprfc.RFCTYPE_CHAR, 1)) ifc.addParm( saprfc.tab("PIPEDATA", "", 80)) conn.iface(ifc) conn.accept(callback=cb, wait=3) print "All finished (reg.py) \n"
What I like about the approach with Python (that could be emulated in Perl, or Ruby) is the encapsulation of all the callback methods in a single Object instance. This neatly allows for the sharing of data between all events in the accept() loop cycle.
A new beginning – again
So I am off on a new chapter of programming, AND I can do it hacking with SAP!