Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

ajt (2546)

ajt
  (email not shown publicly)
http://www.iredale.net/

UK based. Perl, XML/HTTP, SAP, Debian hacker.

  • CPAN: ATRICKETT [cpan.org]
  • PerlMonks: ajt [perlmonks.org]
  • Local LUG: AdamTrickett [lug.org.uk]
  • Debian Administration: ajt [debian-adm...ration.org]
  • LinkedIn: drajt [linkedin.com]

Journal of ajt (2546)

Monday December 15, 2003
09:34 AM

Replacing Java with Perl

[ #16343 ]

There is an interesting thread on Perlmonks discussing the problems that J2EE developers feel that they are having, asking is Perl a viable alternative for light weight applications.

There are lots of comments and ideas, including one from me. I don't dislike Java, XML or XSLT, and while I know XML/XSLT, I don't know much about Java or J2EE. I use XML and XSLT with LibXML2 and LibXSLT from Perl, and I can usually get the technology to work, and work reliably. I can't say the same about Java which I usually find doesn't work.

We use a Java middleware thing made by webMethods called the Business Connector (BC), to interface with our backend AIX/SAP system. The idea is that you send it a piece of XML over HTTP, it maps that into an appropriate structure to make a SAP Remote Function Call (RFC), does the call, and maps the result back to XML, which it returns over HTTP to the calling client. While I accept that we made a number of mistakes in using this product, it's still fair to say that it's a very poor piece of technology.

It's pig slow. It takes for ever to parse and return XML. Generating input XML and doing the XSLT on the output XML in the Perl layer is much faster. In this case I even know it's not a problem of hardware, I've testing things on the same box. The problem here is that BC is just very slow.

It's a swine to develop with. All you get is a visual GUI developer tool, which is good in a demo, but a nightmare to actually use. Debugging is a joke, and you have no idea what the thing is doing underneath. I think it's converting it's visual drawings into a sequence of XML transformations, I don't know if it's SAX or some proprietary thing.

So because we had problems we tried Piers Hardings SAP::Rfc module. Basically this is a OO Perl interface to the same SAP provided c library that the BC uses.

I installed it on the DEV box, and after some stupid problem (probably operator error) it started to work. Basically you point the tool at a SAP system, give it the name of an RFC and ask SAP for the interface. SAP does it's stuff, and you get either an error, or a large Perl structure back with the detail of the input and output structures. You then set the parameters you want, and the run the RFC, again you get an error or a Perl structure. You disconnect from SAP and you are done.

It's so simple to use that as I say in my Perlmonks comment I had it running on the command line in less than 15 minutes, and a working HTML in/out page the following day.

Our SAP BASIS team are very opposed to bespoke code, as they think it's wasted development, so they like to stick with standards when ever possible. I can see their point, but with my approach there is less code in total, and thus less bespoke code too. Less code as a general rule means less bugs, and it runs faster. In my (simple) tests Perl+XSLT+SAP::Rfc+SAP is nearly 10 times faster than Perl+XSLT+BC+SAP, I think with the XSLT stage removed I can get my speed up over 10 times faster!

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Our SAP BASIS team are very opposed to bespoke code, as they think it's wasted development.

    Sometimes this attitude is appropriate. However, my personal experience suggests that more often than not this is a sign of timidity and it does not bode well for an IT department.

    Nice writeup, by the way.

    • I can understand their fears. Who hasn't inherited a job that was easier to scrap and start from scratch than to continue with?

      However like you say favouring a known buggy, slow and expensive solution in favour of a smaller well written bespoke one is a false economy.

      --
      -- "It's not magic, it's work..."
  • Perl -> SAP glue module -> SAP

    is almost certainly the right way to go.

    I've seen the "layers of Java(tm) and XML crap" approach in action myself, and it wasn't pretty then, either.
    • The sad thing is that Perl is faster at the XML stuff than the damn Java layer! So much for Java and XML being the natural choice!

      By removing the XML/XSLT which becomes redundant once you migrate to native data structures, I think I can achieve a better than 10x speed improvement.

      At the end of the day the front end of this application is Perl on Apache, and by removing the webMethods BC Server, we remove a whole tier of code, and simplify the existing Perl front end. While the BASIS team don't like besp

      --
      -- "It's not magic, it's work..."