El infierno de CR4E.

Hace un año en la compañía donde trabajo, se mi pidió que integrara la generación de reportes de nuestro producto con reportes de Crystal Reports XI, como yo había leído muchas veces que Crystal Reports era la mejor herramienta de reporting que existía, asumí que la integración seria algo sencillo y sin complicaciones, que equivocado estaba.

• Mi primera sorpresa fue, el descubrir las diferencias que existen al ejecutar un reporte con el diseñador de Crystal Reports y con el API Java que suministran (CR4E). Una de las primeras diferencias que me encontré, era que cuando se ejecutaba un reporte con el API en java, todos los valores de la base de datos eran trimeados (se borraban los espacios en blanco de los extremos), esto trae como problema que si querías comparar valores entre tablas en alguna formula hecha en el reporte, se debía aplicar la función “Trim” sobre los valores a comparar. Muchos de Uds. Dirán que esto no es un problema serio, pues yo les digo que si lo es, la diferencia de ejecución de un reporte de Crystal Reports aplicando “Trim” a campos con otro que no lo haga es muy grande. Al parecer debido a las etapas de ejecución que se aplican antes de crear un reporte en Crystal Reports, al aplicar una función de tipo “Trim” en un campo hace que casi se duplique el tiempo de ejecución de un repote.

• La segunda sorpresa fue el saber que si se definían dos subreportes con el mismo nombre, pero diferenciado por el “case” (cosa que no te limita hacer el diseñador de reportes) de una letra (ejemplo “Reporte”, “reporte”), en el diseñador de Crystal Reports funcionaba perfectamente, sin embargo cuando se ejecutaba con el API de Crystal Reports en java (CR4E) el reporte fallaba con un mensaje de error poco explicativo (“Report error”).

• Mi tercera sorpresa y la más grande de todas fue, el tener que esperar casi un año (exactamente 10 meses) para que el equipo de soporte de “Bussines Objects” solventara este problema en su API de java.

Ahora se preguntaran ¿todo va bien?, pues no, ya salio la ultima versión de Crystal Reports, pero sorprendentemente el API de Cristal Reports para Java no soporta las ultimas novedades de la nueva versión…
En un mail que escribe a un responsable de Business Objects en España, en el que le comentaba todos los problemas que habíamos descubierto en el API de Cristal Reports en Java y además aproveche para preguntarle sobre el desarrollo del API en Java, este no supo contestar a mi última pregunta. Por lo que pensamos que este producto va a morir dentro de poco…

Conclusión

Debido a la diferencias al momento de ejecutar un reporte de Crystal Reports con el API de Windows y el API en Java, NO recomiendo que ningún desarrollo en java tome como solución de reporting al producto de Crystal Reports. Basándome en la respuesta obtenida por personal de Business Objects en España “creo” (no tengo información certera) que el desarrollo del API en Java será abandonado.