Skip to Content
0
Former Member
Jul 22, 2009 at 05:36 PM

Shortcomings of CR4E

35 Views

I thought I'd air some of our conclusions about using CR4E in our projects.

We wasted a lot of time in the early part of the development cycle trying to comprehend the progamming model for CR4E, thinking that it was an API when in fact it's a complete standalone product of course. Maybe we didn't pay enough attention to the detail but it wasn't obvious until we saw the size of the jar files ...

We then coded up some wrapping classes and hit some problems with the 2008 API not being fully implemented e.g. exporting to XML. We worked around this by using some pretty esoteric compromise involving calling the CRPE XI COM component through the rather clever JAWIN library.

However, once that problem was solved we then hit the buffers again, this time with the parameters API. Here again, bits are not implemented e.g. you can't find out which parameters are dynamic, which are cascading and if they are dynamic, which field they are looking up.

Our deployment scenario is that our super users have CR 2008 Designer on their desktops in which they design reports using a JDBC driver. The reports are then placed in our web application where they are run by lesser mortals using CR4E. We have realised that basically this approach is bound to fail given the current state of the CR4E project being way behind waht's available in CR2008.

So where do we go from here? We could wait for the CR4E to catch up, but it's not clear when that would be.

We have discovered that the .Net SDK does have a complete implementation of the API, including the latest fancy XML export.

So, in conclusion, we're ditching CR4E for the forseeable future and developing a .Net component that we can call from Java that will do all the stuff we need to do e.g. get/set paramters, export to XML etc. We're in the lucky position that our server is Windows of course.

I like the idea of CR4E and I understand that it's in a dog fight with iReports/JaspReports for this "free" space, but I'd rather pay SAP for a tool that is complete, rather than working with one that is free but half finished. As CR is mostly used in the Coporate development sphere, I suspect I'm not alone in that view.

I hope this doesn't come across as a rant, because that's not how I feel, but I do think it's worth pointing out the shortcomings of CR4E to others to save their time.

Cheers,

Steve