Since being moved from marketing back to IT/SAP I've been working on a new, interesting and exciting project. We have a web enabled SAP process that uses the SAP Business Connector (BC) Server as it's middleware layer. While it's fair to say that we didn't use it in the best possible way, it's still a steaming pile of Java cow poo.
Basically I'm writing a simple application server in Perl, that uses the SAP::Rfc module to communicate with SAP at the backend, and some templating module (probably TT2) to generate xhtml pages at the front end. It uses configuration files to control behaviour, and has virtually no business logic in it. So far I've written about half of the core module, so I can now process input forms, deal with sessions, put things in the right SAP input structures, and call SAP. It's all nice OO stuff, with plenty of error handling and lots of tests.
It's not quite XP, but I'm doing my best to write documentation and tests as I go along. It's proving very easy to write. I start to add a new method, document it, write tests, make sure they are okay, amend other methods, add more tests, make sure that's okay, then add more code to my method, and add more tests and so on. Mostly it's been a dream, mostly tests pass first time, and even some of the hard bits pass first time.
Test driven development is one of the things I'm now a clear convert in favour of. I know it's not a panacea for all development, but it's a very powerful technique, and well worth thinking about.
Is there a possibility of open sourcing your work? It sounds really interesting. For a school project I developed a framework to integrate BAPI with JavaBeans and eventually Struts. It's much easier to use than what you get with NetWeaver, but I pobably missed at least 1 Million special cases
Re:Open Source
ajt on 2004-06-10T15:09:21
One never knows! Previous attempts to get the company to approve open sourcing code fell on deaf ears.
It's really DEAD simple. You have a global configuration file that tells the AppServer where SAP is, and basic stuff like that. Then for each RFC enabled BAPI you want to do something with, you create a BAPI config file, which tells the AppServer which fields to scrape via CGI and how to build up the SAP input structure. It then runs the RFC enabled BAPI via SAP::Rfc, and then using TT2, it merges the SAP
$ifaceobject with a template to generate xhtml. Simple really.It's not smart enough to do fancy automatic-interface discovery, and automatically build it's own input and output xhtml pages, but it's smart enough to mean that to use it, you don't need to know Perl, just fill out the config files, and line them up with your BAPIs and away you go - or that's the theory at least!
At the moment I've done the input side, and I'm adding test upon test to make sure it's robust enough to use as an actual application in a real production environment. Next week I'm going to start working TT2 into it, and then in the following weeks, start the config - which could be the long and tedious bit!
I gather Piers Harding, the brains behind SAP::Rfc has some AxKit based AppServer of his own.
Re:Open Source
malte on 2004-06-11T07:24:50
What I did is write a code generator for Java (in Perl, obviously
:) that gets a configuration file for each SAP-Table you want to deal with: COUNTER CHAR
WORKDATE DATSThe generator produces a java bean that holds the data and a decorator around the JCO.Table that comes out of SAP that converts between the bean and JCO on the fly. The interface is not bound to a technology, could be HTML or Swing, but you have to do it yourself.
We had a competition against 3 people who used the HTMLB implementation in SAP and 3 people who used the HTMLB implementation in Java (which is ultra buggy). In the end we came out fastest.
Re:Open Source
ajt on 2004-06-12T06:26:12
Interesting. I considered auto-discovery type stuff but went instead for a xhtml->config->sap->TT2->xhtml model. Making the input xhtml requires some knowledge of the SAP input structures, but you can't make a xhtml page without knowing what shape the data is when you put it in. The config stage does a screen scrape, and puts things in the correct tables and inputs. Calling SAP via the RFC module is the easy bit. Finally I plan to merge the config selected template with the SAP output structure to get the final xhtml.
To design the static input page you need to know the input requirements, the AppServer API and xhtml. Building the TT templates you need to know TT2 and xhtml, and where the data is in the output object. My AppServer approach does not separate code from mark-up, but it does separate out business logic from code/mark-up side.
Any TT fan boy that says TT is easy for HTML heads or that it separates code from HTML is talking rubbish, our HTML heads hate it, and the TT2 templates are littered with code. It is possible to separate much of the business logic and coding from the mark-up, but not as much as the TT fan-club would let you believe. That's the nature with all template engines, the less features they have the more the separation you get, and conversely the more features and abilities you get the more you blur code and mark-up.
Once it's done, I'll prod the project manager and see what he say... about releasing it.
