cancel
Showing results for 
Search instead for 
Did you mean: 

Shortcomings of CR4E

Former Member
0 Kudos

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

Accepted Solutions (0)

Answers (3)

Answers (3)

0 Kudos

Thank you Steve. As noted, CR4E is in it's infancy and will possibly catch up to the full power of the the full version. But may not, it is free after all. Look for Sizing Guides, they will give you a better description of the capabilities of current and future products.

Former Member
0 Kudos

Similar conclusions from my side.

The anaouncement that CRAX will not be supported any longer forced us to look for a different API from our thick client software to Crystal reports.

After using a lot of time developing the whole thing in CR4E we just see, that there is no chance to complete the interface.

Missing impmented functions ( XML export, printing a report on a thick client) and lots of unsolved error situations (reports cannot be freed after viewing them, PDF export gives unreliable results) we have to quit right now.

We are going to monitor CR4E for some time, but probably we will dismiss our Cystal interface and change to something like iReports.

Manfred

Former Member
0 Kudos

I'm guessing that the CR4E has been invented to try and keep Java developers inside the Crystal family as opposed to going with iReports.

I'm afraid that in our experience, it's having the opposite effect - such is our frustration with this product we're now looking to jump ship not just from CR4E, but from Crystal Reports in general.

iReports may not be as fully featured as Crystal Reports designer, but if there's ever a problem with it, you can get it fixed. If there's a feature missing, you can write it and add it yourself. Until CR4E becomes a community based development effort (not very likely), it's never going to compete with iReports in the minds of java developers.

By the way, we have solved our reporting issues for this particular project by doing the following;

We downloaded C# Express and wrote a COM Interop DLL that wraps all the Crystal .Net functions we needed.

We then used JAWIN to create stubs to be able to call that COM object from within java.

Steve

Former Member
0 Kudos

A follow up:-

It looks as though dynamic and cascading prompts are also missing from the .Net SDK too. However, the XML exporting is fully supported.

Steve