Skip to Content
In the Scripting Languages Forum, Piers Harding was kind enough to share what he’s already done in the SAP>Perl area via RFC, and after one post, the thread already started to show some back-and-forth on SOA vs RFC. Hey – I don’t think this needs to be a shoot-out at the OK corral. Even if a client wants eventually to be fully-SOA, I can see lots and lots of reasons for doing prototypes of the required services via RFC/Scripting Languages calls, e.g. get them right first without the overhead of the SOA learning/implementation curve. After some neat POP’s, clients might be more willing to make the big investment of time in SOA because the devil in the details has already been teased out of them. Of course, it would be a little embarassing for some folks if SAP<>RFC<>Perl<>DB2(UDB) turned out to be faster than SAP<>SOA<>DB2(UDB). PS: While we’re on that topic, does anyone know if DB2 Connect under AIX 5.2 has enough of a stack to talk to IBM’s Perl driver for DB2 UDB? Some clients have non-SAP data in DB2, but not necessarily in DB2 UDB, and it would be nice if clients who don’t want to mess with DB2 UDB could go SAP>RFC>PERL>DB2Connect>DB2(non-UDB). I’ve emailed Grant Hutchinson and Michael Hoy at IBM with this question, but I’m sure it will take a while to get a reply.
To report this post you need to login first.


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

  1. Former Member
    …that is, an invalid comparison.

    As I tried to point out in the thread mentioned SOA at first hand is not about actual technologies but rather about general principles.

    Only when it comes down to the actual implementation, RFC comes into play as maybe one option.

    Given that yo have libraries (connectors) for a great number of application platforms (programming languages) you could well think of setting up a SOA using RFC (though afaik it would be hard to set up a communication of two non-SAP apps using RFC; therefore my remark of the SAP-centric world in the thread).

    If you want to talk of a showdown you’ve got to compare RFC for instance with web services (that is commonly SOAP over HTTP).

    The performance comparison discussion might well fill hours. At least I wouldn’t take it for granted that RFC is faster.


    PS: For a good reading on SOA I recommend one of my favourites Understanding SOA with Web Services by Greg Lomow & Eric Newcomer

    1. David Halitsky
      one could argue that your reply here might be a little unintentionally disingenuous.

      Rarely are competitions between TECHNICAL approaches decided on the merits.  Just think for example of IBM’s decision to go with VTAM instead of TCAM, a decision which many thought technically unwarranted and which is rumored to have been made based on the fact that the NY VTAM development team was closer to the ears of HQ than the NC TCAM team (and I don’t mean only geographically.)

      I would be hard-pressed NOT to believe that there are those strategists inside SAP who would argue that the last thing SAP should do is try to try and promulgate two different technical protocols out to the customers – that this would result in a confusing message that would never wind up getting many more customers to adopt EITHER technical protocol.  And if I am correct that SAP has its share of such strategists, then I doubt very much they’ll alter their opinion no matter what the technical merits of the case.

      Additionally, if SOA (in the technical sense) is going to be the flavor of the decade or the century, then one can make a more subtle technical argument in favor of not bothering to support “out-of-flavor” protocols such as RFC. 

      This argument is again based on the TCAM vs VTAM case.  Because TCAM was delivered to customers in a form that allowed BAL user exits, a LOT of IBM customers made their TP systems scream by taking advantage of these exits.  Fifteen years later these systems were still just as fast – the problem was that all the TCAM and BAL folks were either dead or charging $250/hr.  And some would argue that SAP customers would run the same risk if SAP and its customers don’t jump on whatever bandwagon is currently rolling.  I mean, would YOU want to be the first one who ten years from now had to implement SAP’s “SOAP transparency for RFC, Release 1.0” (parallel to the VTAM transparency for TCAM which IBM was eventually forced to develop?:

      But as I said in my original post, I can imagine a Magic Quadrant in which 1000 flowers bloom because each flower does what it does best.  (Except, of course, the lilies of the field – can’t get them to work a lick at all!)

  2. Former Member
    I’d like to focus on where this all started.  The discussion started with “can you run Perl in SAP”, and then seemed to elaborate into “I want to be able to access significant chunks of Perl code from SAP”.  It also morphed into “I want to beable to access A-another DB”.
    To which I promptly pointed to an article written about integrating Perl code into ABAP (or Python, or Ruby) => .
    These scenarios described above, are what I’d consider to be tightly bound/coupled with SAP, and situations where you have good control over both ends of the “pipe” of communication – very similar to the IPC service for CRM (an RFC server application written in JAVA supplied by SAP).  In these kinds of situations you have the luxury to focus on performance, and thinning the layers of abstraction away from the problem – going for high performance/customisation.  This is in direct contrast to generic, and heavily abstracted communication architectures such as that given by the WS-* specifications, which are characterised by broad industry acceptance, and are therefore supposedly more applicable to loosely coupled scenarios.  Situations where you have little or no control over the partnering end of communication (eg: your supplier or vendor).
    However SOA ( – as Anton has quite rightly pointed out – does not preclude the use of alternative communication protocols/strategies BUT it is predominantly intended as a solution for loosely coupled systems communication – something that I do not think is applicable to where this all started from.

    RFC is by definition entirely SAP centric, it is still a corner stone technology, and is still being invested in today (so it is not going to disappear anytime soon).  If RFC is the most appropriate weapon, then considering that it has a lively future, why not run with it, and indeed why not utlise the Scripting Connectors, and leverage  that legacy code, third party code, or the entire contents of CPAN (

    Piers Harding.

    1. David Halitsky
      As I said down in the ScrLng Forum, you have been extremely kind and patient with this newbie to SAP RFC and the kinds of connectors it can support, and I therefore want to clarify that I was deliberately being a bit of a devil’s advocate in my reply to Anton.

      Reason I did this is to try to expose the political layer that is implicit in any discussion of any two distinct technical protocols whose domains of applicability overlap to a greater or lesser extent.  (This is also why I posted up here in the blogs – the blogs are the place, I think, to discuss the political aspects of this situation, while the Forums are the place to discuss its technical aspects.

      If one does not learn from the past, one is condemned to repeat it – hence my recollection of the now-somewhat-obscure TCAM/VTAM competition at IBM, which did not necessarily yield the best outcome from a technical point of view.

      A more recent illustration would be the a;most humorous way in which Software AG, CCA/Praxis, and ATT/NCR had to rush to wrap SQL shells around Adabas, Model 204 and Teradata simply because they could not afford to fight the public and private sector procurement officials who: a) became sold on the idea that SQL and the relational paradigm would reduce the need for expensive application and systems programmers and b) wanted software procurement decisions to be based on price-point considerations such as those that apply when purchasing any less esoteric commodity (bread, widgets, fluouescent light-bulbs, etc.), rather than on technical evaluations they couldn’t understand.

      So to sum up, my own personal position is that SAP is sufficiently strong and respected to say to its customer base: “Hey – if you want the flavor-of-the-month, we’ve got a great set of SOAP services for you, but if you also need to make frequent use of an “out-of-flavor” protocol because of its technical superiority in certain circumstances, we can give you that too.”

  3. David Halitsky
    If DB2 Connect under AIX 5.2 can be invoked in “batch mode” by a script or program, then one should be able to use Pier’s Perl connector running under SAP’s RFC to obtain non-SAP mainframe DB2 data as follows:

    1) an SAP program (ABAP/WD-ABAP) invokes a Perl program via Pier’s program and RFC and passes query parms to this Perl program;

    2) the Perl program invokes DB2 Connect in batch mode and passes it the query parms provided by the SAP program;

    3) DB2 Connect passes the query parms provided by the Perl program to mainframe DB2, receives the data back from DB2, and hands it back to the Perl program;

    4) the Perl program passes the data back to SAP.

    Under this scenario, there is no need for a version of IBM’s DB2 Perl driver that would talk to mainframe DB2 as well as DB2 UBD.

    Sorry to raise unnecessary dust.

  4. Former Member
    Thought Experiment:

    + I am working in a larger healthcare environment, say a University Hospital.

    + a large environment like this is built up from a numer of systems, a hospital information system (HIS), laboratory information system (LIS), radiology information system (RIS), enterprise ressource planning system (ERP), HR and FI systems, science and teaching systems, and much more; non of this systems necessarily is a lead system
    + we don’t have any politically coined system architect appointed but we’re a bunch of people each dedicated to find efficient and non-redundant solutions to given day to day challenges

    + we’re not biased towards anything but efficiency an non-rendundancy

    Now, one of or biomedical systems has a number of mission critcal programs implemented in Perl, producing data that _actually_ need to be accessed from our ERP system in a specific project.

    How are we gonna solve that task?
    Looking at Perl first we have libraries at hand for every possible kind of communication, starting from raw socket connections, HTTP connections, Web Services (via a broadly supported library SOAP::Light) and something SAP specific called RFC, where a library is maintained by a couragous individual. Not to mention all the asynchronous options like ftp, SMTP, telnet upload, whatever.
    Next we look at the SAP side: interestingly there are relatively few options, the mentionend RFC stuff, a kind of limited HTTP in ABAP, a little better one if we use BSP, something called BAPI (we got to ask the SAP people what that is) and in later releases Web Services (which SAP seems to target at a strategic level). Of course we have the asynchronous options.

    + we have done numerous integration projects integrating systems on a point-to-point basis and we are well experienced in the various technologies. Nevertheless this large number of individual ‘integrations’ exhibits a certain degree of redundancy an most of all challenges the limits of managability and documetation standards.

    + even before SOA became hip, we thought that there must be a new kind of architecture to better support distributed landscapes like ours. we watched CORBA and similar approaches, tried to get familiar with an Enterprise Service Bus (ESB) etc…
    One of our biggest problems often times was the fact, that even when we did an A-to-B integration very well, someone responsible for C came up and we had to start anew. Management did never understand that and so didn’t we, in turn blaming the industry for not coming up with certain new standards(superceding maybe EDI, which was kind of an early standard which unbelievably is still in place in its most archaic forms).

    So, our question now comes somehow down to: RFC or Web Services?
    + we have to install an extra library in each case
    + though our SAP people are not used to measure network traffic load exactly an we don’t know RFC protocol details we assume that the payload of a SOAP message is somewhat larger than that of the same message in RFC, probably up to a factor of 2-2.5; in real mass data situations we would have to consider that, but for average use cases our current network capacities are certainly able to cover that
    + processing overhead: I believe it’s a myth that serializing and deserializing XML is slower than the same actions for RFC. Maybe RFC is less generic but on the other hand there is so much more brain force invested in today’s XML parsers that my gut feeling seems not to be completely wrong that both perform at least equally good

    + reusability: what do we do with a nice RFC interface for our Perl service, if we need the same data to be available in another, non-SAP system? ABSOLUTELY NOTHING! We’ve simply got to to it anew. Maybe using Web Services.

    So, what will we do?`Wait, we seem to have suggestively come to a conclusion favouring Web Services. But what release is our SAP ERP & HR system? Lower than 6.40? Well, if this were the case, our system was generally only able to support a modern distributed environment in a quiet limited way and we are bound to more or less point-to-point integrations.
    But since we only recently upgraded our SAP systems to the Netweaver series we can confidently use the Web Service capabilities of it and therefore there is no reason to use limited RFC connections anymore and expose our Perl services as Web Services for future use by each and every other system in our landscape.

    Probably Web Services as we know them today won’t stay for ten years, but it’ll definitely be one generalized paradigm replacing the actual most prominent SOA implementation and it will not be a step back to many propriatary point-to-point-connections.

    I’ll be at A’dam and always be interested to discuss the political ‘implications’ as well.

    1. David Halitsky
      Anton –

      You must have studied Hegel somewhere in your schooling because you seem to view the evolution of IT as a thesis/antithesis cycle.

      What I mean here is that over the past 40 years, IT seems to have evolved by the replacement of one “dominant paradigm” with another.  Every few years, the whole IT profession seems to slap itself on its collective forehead and say: “How could we have been so stupid? HERE’s the right way to do it …” And after a few years have gone by, the IT profession stops, slaps itself again, and the cycle begins anew.

      The problem with this Hegelian process is that when a “dominant paradigm” arises, it forces the “best and the brightest” to turn their attention from serious problems to trivial problems that arise when anyone really tries to take the “dominant paradigm” seriously.  (See my comment elsewhere on this site about what Gio Wiederhold told folks about “extensions” to the SQL paradigm in the early 1990’s.)

      This is why I say that the only folks who really benefit from the IT profession’s apparent need for a “dominant paradigm” are those folks who make their money from telling the profession which paradigm is currently the “dominant paradigm”, i.e. which paradigm is in the “Magic Quadrant”, and those folks who make their money off getting smart on the “dominant paradigm” quickest (so they can bill out at “platinum”-level rates.)

      To put this point another way, EVERYONE is familiar with the horrendous decline of Bell Labs that started when management took Nobel Prize winning physicists and told them to work on cell-phones and other consumer-products instead of working on what they want.  (This despite Bell Lab’s history of originating successful mass-market products out of really abstruse “pure” research.

      But when really good programmers are forced to turn their attention to solving problems that result solely from obvious inadequacies in the currently “dominant” paradigm, the sad sad history of Bell Labs is simply repeating itself in a different guise.

      I had the privilege of going out to SAP Labs for the 2004 SDN/Labs Palo Alto meet, and who I met and what I learned there only re-inforced my opinion that SAP Labs is a group of people of the same caliber as those who once worked at Xerox Parc, IBM Watson, or ATT Bell Labs.  It would be a shame if all the talent of these SAP engineers always had to be directed toward bringing SAP into line with the “dominant paradigm”. 

      So this is the political reason I’d like to see SAP adopt a multi-pronged approach to customers with respect to SOA and RFC – I think IT will get better faster if at least two flowers are allowed to bloom in the Magic Quadrant, if not 1000.

      With respect to your observation about re-usability – it amazes me that each new generation thinks it has discovered the solution to the re-usability problem.  There is no “re-usability” problem and never has been – what there’s always been is lazy programmers and managers who don’t want to give creative programmers the time they need to do things right.  And because the field can’t solve the problem of lazy programmers and importune managers, it keeps on trying to come up with new technical solutions to what is essentially a non-technical problem.  To see what I mean here, simply ask yourself, for example, how many shops implemented COBOL copylibs religiously? How many shops take sufficient advantage of function modules today?

      With respect to your observation about point-to-point vs “published and subscribed to” SOAP services, I agree that this is the strongest technical argument for SOAP vs RFC UNDER THE ASSUMPTION that there are no real-world scenarios that are essentially point-to-point.  My own experience tells me that in the real-world, there are plenty of intrinsically “point-to-point” scenarios that can be gussied up into “loosely-coupled” scenarios – but that doesn’t change the fact that these scenarios are still intrinsically point-to-point.


Leave a Reply