Saturday, November 15, 2008

Lessons Learnt

I finished up yesterday with the Ministry of Justice in Wellington, NZ. I believe I finished on a high, and I'm very glad that I've been able to make a strong contribution to the IUP programme, and, I'd like to believe, have left behind something that has lasting value.

I believe my thoughts on what I've learnt thus far can be best categorised by the technology I've been using recently:

Oracle APEX
I'm an Enterprise Java person by training. I left university thinking: more layers and more compartmentalization are the only way to go. I'm thinking along the lines of the OSI model and MVC here, and this pattern of thought can be extended to all software development ad nauseum.

Over the last few years we've seen an attitude shift in the Java world, moving towards lighter frameworks and processes. So I really welcomed a chance to customise Oracle APEX, which is in some ways at the other extreme of the spectrum.

There are two layers (if you consider the database a layer)! No MVC. From one point of view, it's a Mickey-Mouse approach to software development harking back to the dark ages. Any level of complexity beyond "save the values in this page to this table in the database" would (probably) become quickly unmanageable. Thing is though, there are applications out there which don't need any more complexity than that! And that's where Oracle APEX really excells.

All developers to whom I showed the framework to were amazed at how quickly we could construct a fully-fledged application (a matter of hours) that would have taken weeks in a Java enterprise solution. And this was including all the mod cons like role-based authorization, disaster recovery and an extremely attractive exterior (I based the theme on the Ministry's very pretty intranet).

Of course, this still has to be dealt with by someone, somehow, but this can be done up-front just once for the entire organisation, and maintained centrally from then on. Most enterprise applications I've seen don't use organisation-wide components for authentication/authorization, look-and-feel etc, and some projects implement and maintain these items better than others.


Jasper Reports
One thing that APEX doesn't do well on its own is reporting. Oracle are pushing BI Publisher for an arm and a leg. Tomas Babic and I were searching for alternatives, and until about 2 days before we had to turn in our solution options report, the only real alternative about was my own XSLT-and-OpenOffice solution (which I had developed because of the prohibitive cost of BI Publisher). I was proud of it, but I knew it wasn't as easy to work with as I would have liked.

Then Tomas finds Jasper Reports, and I'm so glad he did. It turned out that Jasper Reports (and their design tool) was exactly what we were looking for, and it would be relatively easy to write an interface which would allow APEX to use Jasper templates, seemingly by magic. I threw my own solution out the window and wrote a tiny servlet which would act as the interface instead. I'm very proud of how small and graceful the implementation is, and how little it does to achieve a great deal by exploiting the work of others.

(Then I wrote a ton of documentation to ensure that others would know how to use and maintain what I left behind.)

I've learnt these lessons over my (still humbly short) career, which have materialized in my latest work:
  1. Don't over-engineer. Just do enough to manage the complexity you expect. This frees you up now and in the future to do the stuff that really matters.
  2. Always look hard for good 3rd party solutions and integrate these instead of writing your own.
  3. Where you have to write your own solution, code it once, code it well, and try and ensure it's used across the organisation.

Of course, it's laughable to claim that I've single-handedly come up with a revolutionary way of doing things. I'm merely riding the Zeitgeist, and have made full use of the hard work of others. Anything that I've written is as small as possible, which I feel is the way to ensure reliability and future maintainability.

4 comments:

Unknown said...

Hi,

Im also new in Apex. I want to use Jasper reports in Apex, but I cant find a way out to do that..
Can u plse share ur knowledge about that with me??
Thanks..

Nathanael Ng said...

Hello

I think the best place to start on that is looking at the Oracle APEX forums.

There's a thread there (http://forums.oracle.com/forums/thread.jspa?messageID=1989886&#1989886) which should give you a place to start.

We actually figured out how to do it independently, as it really isn't very difficult so long as you're a decent Java developer.

Any further questions would be best directed there, as others will find it useful too.

Good luck.

Drew said...

Are you going to publish/share the "tiny servlet" you created? It would be much appreciated. Perhaps you could add it to the jasperforge collection.

Nathanael Ng said...

Hello Drew

I wrote the servlet as part of my work as a contractor for the Ministry of Justice NZ, so unfortunately the code isn't mine to publish.

Here are a few pointers which I hope will help you write your own.

The thread I mentioned in my last comment gives an example of a servlet. It does the job; however I don't like the way the URL of the servlet would need to be hardcoded on the page. Nor do I like the idea that the servlet should need to make a separate call to the database.

Oracle APEX gives two ways of publishing a report: either use BI Publisher, which needs to be licensed, or use Oracle's customisation of Apache FOP (fop.war), which does not require an additional license.

The drawback of the latter option is that you're very restricted in the nature of report you can create.

Oracle APEX passes data to BI Publisher and fop.war in exactly the same manner: over HTTP, to a URL that must be specified in APEX administration.

There's nothing stopping you from replacing fop.war with your own custom implementation, and in fact Oracle allow this, but will not offer support should you choose to do this.

You'll find that Oracle APEX passes more than enough information that you can use to create a servlet which runs JasperReports, including:
- the desired output format
- the data which should be used in the report (in XML form)
- the report layout (which will have been uploaded in Shared Components -> Report Layouts; any UTF-8 file can be uploaded, including a JRXML)

Oracle APEX takes the response from the URL, which is expected to be a report in the appropriate format, and gives it to the user.

Good luck.