Skip to Content

Of late – I have found a need to be able to write RFCs on the fly – partly to be able to deliver new functionality to my user base for my RFC implementations for Perl, Python, and Ruby.  Using transports is not an option because of potential licensing issues, and the practicalities of release support.  I started looking into how you can actually write Function Modules on the fly, and ended up with SAP::Tools which I have first released for Ruby.

Here is an example (albeit a pointless one) of how to build up an interface, and then insert the code into an RFC that is ready to run.

require "lib/SAP/Tools"

rfc = SAP::Tools.new(:ashost => "seahorse.local.net",
                   :sysnr  => 00,
                   :lang   => "EN",
                   :client => 000,
                   :user   => "DEVELOPER",
                   :passwd => "DEVELOPER",
                   :trace  => 1)

func_pool = "ZMYRFC1"
func = "ZTEST"
short_text = "Some function group - #{func_pool}"
func_desc = "description of #{func}"

# get the connection ID
print "[main] connect id: ", rfc.connection, "\n"

# test the connection
print "[main] is_connected: ", rfc.is_connected(), "\n"

if rfc.existsRFC(func)
  print "[main] deleting: #{func}\n"
  rfc.deleteRFC(func)
end

ztest = SAP::Iface.new(func)
ztest.addParm(SAP::Parm.new(:name => "PARMIMP", :type => RFCIMPORT, :like => "SY-REPID", :optional => true))
ztest.addParm(SAP::Parm.new(:name => "PARMEXP", :type => RFCEXPORT, :like => "TRDIR"))
ztest.addParm(SAP::Parm.new(:name => "SYSTEM", :type => RFCEXPORT, :like => "SY-SYSID"))
ztest.addParm(SAP::Tab.new(:name => "WAHOO", :like => "TAB512", :optional => true))

src =  [
      'TABLES: TRDIR.',
      'SELECT SINGLE * FROM TRDIR WHERE NAME = PARMIMP.',
      'SYSTEM = SY-SYSID.',
      'PARMEXP = TRDIR.',
     ]

test = rfc.makeRFC(:func => ztest,
                    :desc => func_desc,
                    :group => func_pool,
                    :grouptext => short_text,
                    :source => src)

# close the connection
print "[main] close connection: ", rfc.close(), "\n"

You may ask why would I bother to go to this trouble, and my reply is that I have been banging my head against SAP’s inertia, and internal politics for the last year, trying to get access to the new features for handling complex data types in RFC . As a result I have had to build a complex framework for automatically generating RFC to support my efforts for dynamically instantiating ABAP Objects, and calling methods etc. from Perl, Ruby etc.

However – a side effect is that this can open up the way for accessing lots of Function Modules that aren’t RFC enabled without having to go to the trouble of developing wrappers from within R/3 (these wrappers can be automatically created for you).

If you think this is a “Hack” then you’re right – but as I’ve eluded to before – this is a Hackers (an artistic programmer as opposed to an nefarious evil-doer) response to the reluctance I have experienced from SAP, in the pursuit of extending the sophistication of integration of R/3 with scripting programming languages from the Open Source world.  Further to this – I am noticing a worrying trend in Senior SAP Executive rhetoric with respect to Open Source, and am wondering if this is signalling a change in some of the founding principles that have carried SAP to such heights as it enjoys now.

To report this post you need to login first.

5 Comments

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

  1. Sharad Agrawal
    Hi Piers
    Are you suggesting that this approach can be or should be used with SAP production systems or it is just for academic interest? If I were the security manager, I would never allow this kind of development to take place. Since these function modules are created on the fly, therefore there will not be any transport track available and there would not be any opportunity for QA to check the quality of the code. Who will prevent somebody to write the statements like following.
    ‘ refresh r_matnr.
    Delete from mara where matnr in r_matnr’.

    On the other hand, the execution of this code depends on the mercy of inexperience of security team. Normally the right of RFC users are very restricted. They are just given the authorization of execute certain transactions and function modules of certain function group. They definitely don’t have any developer access in the system. If the security is properly configured, I don’t think that RFC users will be able to execute this code.

    What are your thoughts ?

    (0) 
    1. Piers Harding Post author
      Hi Sharad,

      If you read my blog, you will notice that I said “I have found a need to be able to write RFCs on the fly – partly to be able to deliver new functionality to my user base for my RFC implementations for Perl, Python, and Ruby. Using transports is not an option because of potential licensing issues, and the practicalities of release support.”
      The key thing here is that I am looking for a way to deliver (packaged or otherwise) functionality to my users (users of my RFC implementations for Perl, Pyhthon, Ruby).  You’ve made a rather large jump from that to “Hey – you want to run this in production!”.
      This functionality allows you (me or anyone else) to write an application in Ruby (for instance) that requires more in terms of RFC work, than standard RFCs supplied by SAP – it essentially allows you to distribute an install script with your software for missing functionality.  There is nothing stopping you from subsequently including them in a transport for other systems.
      Additionally – since you brought up the question of security – all of this IS controlled by  security – please download the software and look at how it works, and you will see that even the act of creating RFCs is controlled by standard authorisations.
      Weak or inexperienced security teams is not an excuse or reason (IMO) for objecting to an approach – what I’ve used here, any decent (in a negative way) Black-Hat will have found long ago, and exploited if it was sufficiently open (which it isnt considering the authorisations required).

      Cheers,
      Piers Harding.

      (0) 

Leave a Reply