Skip to Content

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!

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Dale Phillips
    I would really like to be able to have a more elegant way in BW Process chains to call AND RETURN (no way to return to a calling process chain via “local”). The gui for process chains is fine for easy stuff but if you start getting complex it really sucks.

    Also if you are a good perl hack maybe you already know how to this … but how do you set up a schedule/job/process to check for things that “did not” run. BW PC’s show you sucess or failure. But if a trigger didnt kick off you are clueless as to its status.

    (0) 
    1. Piers Harding Post author
      If I follow you correctly – you can investigate the status of a batch job via RFC, by calling BP_REMOTE_JOB_SELECT.  There are a whole raft of associated RFCs for manipulating batch jobs remotely.

      Cheers.

      (0) 

Leave a Reply