At Craig's suggestion: Why Invoke PERL functionality from WD-ABAP?

Question

Craig -
This is response to your suggestion that I post my own reasons for thinking that it would be useful to be able to invoke PERL functionality from WD-ABAP.
Please note at the outset that these reasons are based on my own personal belief that the relatively new vertical sectors of bioinformatics/biomed could produce reasonably significant income for SAP in a reasonably short time if SAP decided to create application-level functionalities in these areas. 
This belief is in turn based on a very significant new initiative which has been publicly announced by the university Medical Center recently voted "most-wired" (Vanderbilt) and equivalent initiatives at other university Medical Centers across the country.  (BTW, I've posted a meeting time (Tue 7pm) at Tech Ed for anyone who wants to learn more about these initiatives, the new vertical sectors they define, and how SAP could EASILY play in them.)
So, with this background established, assume that SAP does decide to play in the bioinformatic/biomed sector. 
SAP will rapidly find that a lot of biomed is based on the kind of bioinformatics that essentially does pattern-analysis on two kinds of strings: polynucleotide strings (DNA, mRNA, tRNA, etc.) and polypeptide strings (mainly the amino acid strings that form the "primary structures" of protiens.)  For example, biomed will soon include the ID of "at risk" markers for all patients in a university medical center, indicating what diseases patients may be genetically at risk for due to SNP's and other abnormalities in their inherited DNA.
Now when such analysis is not done by running "canned" versions of well-developed programs such as the ubiqitious BLAST program for "aligning" polynucleotide or polypeptide sequences, it is done by programs written in languages that offer superb capabilities for pattern-searching and manipulation of strings, e.g. PERL.
Additionally, I know from personal experience and the experience of my SigOther that even data obtained from well-known canned programs must be further massaged by non-canned techniques that again are readily implementable in PERL and other similar languages.
Finally, a lot of bioinformatic/biomed applications require iterative batch execution of canned stat routines such as t-tests or normality tests, which can be conveniently done via calls from languages such as PERL to canned products such as STATA.
So assume SAP wants to develop a biomed application that has:
back-end data containing the usual kinds of info med centers need to know about patients, plus the new kinds of scientific info about patients that med centers are creating
a presentation component that displays these two kinds of data for query, further elaboration/refinement, and subsquent update.
For example, there will be times when a doctor will want to take scientific data on a patient from the back-end (e.g. portions of a patient's DNA), subject it to pattern-analysis of the type described above, and then store the results of the analysis as additional new scientific info in the back-end databases.
And SAP can readily provide the doctor with this capability if it allows PERL functionality to be invoked from WD/WD-ABAP components.  In some cases, the PERL will simply invoke industry-standard canned programs such as BLAST and wrap the results in a way friendly to SAP.  In other cases, the PERL may do the analysis itself.  In other cases, the PERL may invoke stat programs.  Etc, etc. etc.
The point is that there is a vast inventory of bioinformatic/biomed PERL code out there, and if SAP wants to get serious about playing in the bioinformatics/biomed sector, it will be much easier to talk to this inventory of programs rather than recreate it in JAVA or SAP inside SAP. 
Anyway, please remember - this post was based on the  assumption that SAP may want to get serious about playing in the bioinformatic/biomed sector.
If not, then as Rosanne Rosanadanna used to say, "Never mind".

Answer 1

Hi David,
Where it can be used :-
Anywhere that you can insert ABAP code to run, you can integrate Perl in the manor that I laid out.  The only requirements are the ability to run registered RFC programs, and to execute ABAP code including RFC calls (which is anywhere inside of an R/3 system basically).
Comparison with other techniques :-
All communication from the ABAP stack with the J2EE stack is done via RFC - this is only faster than a registerd RFC Server if Fast RFC is used which means that the J2EE stack MUST reside on the same host as the R/3 instance.  Therefore there is no performance difference at that level and any performance differentiation is going to be in the programming language Perl vs Java, or payload encoding techniques (XML) at that level (not withstanding the consideration of development time).
There is also the HTTP Client communication facilities - with or without document encodings (the ICF + eg. SOAP).  Again - I'd take a long hard look at whether it is necessary to be encumbered with the data packet encoding/ecapsulation overhead.
What you gain :-
Once you are in the "land of Perl" you have access to essentially any module you can find on CPAN, so any data access you require whether it be some kind of application server technology, or DB, can be fullfilled by whats available there (unless you need to roll your own?).  And lets not forget algorythm implemented in Perl or Perl XS extensions - probably very important in the medical/scientifc field.
SOA (IMO) is a big ugly 4 letter word.  At the end of the day, you have to look where your time and money is best spent, and whether you can achieve the desired results using Scripting Language Connector technology, or whether you feel compelled to go down a WS-* style route.
However - I would like to say this - IMO it is totally unecessary to wrap up system integration in multiple (expensive both in money, and performance considerations) layers if you are confident that you have good control over both ends of the communication streams.  I believe that when your main objective is to utilise large chunks of code written in another language (rather than reimplement it in something closer to SAPs core interests), or communicate with inhouse data sources/systems (I've done this for MySQL before), then this is definitely one such case that opens the door for using my outlined approach (in the article).
Cheers,
Piers Harding.
Message was edited by: Piers Harding