Enrique Medina Montenegro

Twitter |  LinkedIn

Con más de 14 años de experiencia en el mundo de las TI, donde comenzó desarrollando aplicaciones de escritorio en Delphi o Visual Basic, este Ingeniero en Informática por la Universidad de Alicante (1991-1996) ha ido perfilando su actividad profesional hacia las arquitecturas J2EE, donde siempre ha seguido muy atento, e incluso colaborado en ocasiones, con proyectos open-source como MyFaces, Spring, Hibernate, Groovy o Grails. Ocupando puestos desde Programador Junior hasta Arquitecto Senior de Soluciones, Enrique ha sido testigo de cómo ha ido evolucionando la tecnología en torno al desarrollo de aplicaciones web, adquiriendo un conocimiento y experiencia que le permiten evaluar con detalle las necesidades de cada proyecto y aplicar las herramientas que maximizan su productividad. Actualmente, Enrique se ha especializado en el framework de desarrollo Grails, y ejerce la Dirección Técnica de proyectos basados, entre otras, en esta tecnología.

En uno de los proyectos que estamos desarrollando el equipo del Observatorio, como en muchos de los proyectos ahí fuera, necesitábamos generar una serie de informes en PDF para el usuario. Echando un rápido vistazo a la oferta de plugins de Grails, nos encontramos con 3 posibles candidatos (a nuestro entender, para nuestras necesidades):

• Jasper Plugin – http://grails.org/plugin/jasper
• DynamicJasper Plugin – http://grails.org/plugin/dynamic-jasper
• Export Plugin – http://grails.org/plugin/export

Tanto DynamicJasper como Export son plugins orientados a hacer un volcado, más o menos formateado, de las instancias de cualquiera de las clases de nuestro dominio, lo cual es de extrema utilidad cuando queremos hacer el típico volcado del listado de pantalla a un PDF. Sin embargo, en nuestro caso lo que estábamos buscando era algo más ‘profesional’, donde poder definir cabeceras, grupos, detalle, sub-detalle, etc.; en definitiva, una herramienta de creación de informes al estilo BIRT. Y como ya habréis adivinado, nuestra elección debía ser el plugin Jasper.

El Jasper Plugin básicamente integra la librería JasperReports en nuestra aplicación Grails; pero hay que ser un poco críticos en este punto y decir que la gestión de las versiones que realiza es bastante pobre, por no decir inútil, ya que, como os vamos a explicar en este artículo, hay que actualizarlas a mano en la mayoría de los casos (y si no, buscad por Google y los foros/listas de Grails los problemas que tiene la gente tratando de usar el plugin tal y como viene por defecto). Empecemos entonces por instalar el plugin de la forma ya conocida:

	grails install-plugin jasper

NOTA: Para este artículo hemos utilizado la versión 1.2.2 de Grails, pero los mismos pasos y conceptos se aplican para cualquier 1.2.x y las futuras 1.3.x.

Una vez instalado, échemos un vistazo al propio plugin y los ficheros y librerías que lo componen. En nuestro caso, como usuarios de Mac, la ruta donde buscar el plugin sería ‘~/.grails/1.2.2/projects/<NOMBRE_DE_NUESTRO_PROYECTO>/plugins/jasper-0.9.7/‘. Dentro de esta carpeta, veremos un directorio llamado ‘lib‘ y, a la vez dentro de este último, una serie de librerías JAR correspondientes a iText, JasperReports, JFreeChart y Apache POI (y algunas otras de utilidad general). Lamentablemente, las versiones distribuidas con el plugin no siempre son las correctas, sobre todo si queremos utilizar alguna herramienta externa para el diseño de nuestros informes, como es el caso de iReport. Veamos, pues, cómo configurar correctamente el plugin para utilizar la última versión disponible de iReport al momento de escribir este artículo: la 3.7.2.

NOTA: No confundir iReport con JasperReports. El primero es una herramienta Java (un IDE) que permite diseñar y crear informes compatibles con JasperReports, mientras que el último es la API que nos permite generar, entre otros, ficheros PDF a partir de definiciones de informes, que pueden haber sido creados con iReport, por ejemplo (o a mano si nos gusta escribir mucho XML).

Si nos bajamos la versión 3.7.2 de iReport para nuestro sistema, debemos comprobar que las versiones de las librerías mencionadas anteriormente para el plugin Jasper coinciden con las que el propio iReport utiliza, lo cual como os comentábamos al comienzo del artículo, nunca suele ser la regla, sino más bien la excepción. En cualquier caso, aquí os explicamos cómo asegurarnos de que las versiones de las librerías no nos van a dar quebraderos de cabeza, mediante los siguientes pasos y comprobaciones:

1. Localiza las versiones de las librerías distribuidas con iReport -> De nuevo, en el caso de Mac, las podemos encontrar en la siguiente ruta: /Applications/iReport.app/Contents/Resources/ireport/ireport/modules/ext/
2. Copia los siguientes ficheros JAR, independientemente de su versión (digamos que iReport es el que manda en cuestión de versiones aquí) –> iText-x.y.z-LICENSE.txt, iText-x.y.z.jar, jasperreports-x.y.z.jar, jasperreports-LICENSE.txt, jfreechart-x.y.z-LICENSE.txt, jfreechart-x.y.z.jar, poi-x.y-FINAL-yyyymmdd-LICENSE.txt, poi-x.y-FINAL-yyyymmdd-NOTICE.txt y poi-x.y-FINAL-yyyymmdd.jar
3. Elimina todas las librerías coincidentes con el paso 2 en la carpeta del plugin Jasper (sin preocuparse de qué versión son), que como hemos indicado más arriba, sería (para Mac) –> ~/.grails/1.2.2/projects/<NOMBRE_DE_NUESTRO_PROYECTO>/plugins/jasper-0.9.7/lib/
4. Pega los ficheros copiados en el paso 3 en la carpeta del plugin Jasper (para Mac) –> ~/.grails/1.2.2/projects/<NOMBRE_DE_NUESTRO_PROYECTO>/plugins/jasper-0.9.7/lib/

Ahora que ya tenemos configurado correctamente el plugin para trabajar con los informes creados en iReport 3.7.2, nuestro siguiente paso debería ser comenzar a diseñar nuestros informes. Sin embargo, debemos comprender algunos aspectos importantes de la forma en que el plugin Jasper integra la librería JasperReports en nuestra aplicación Grails para poder usarlo correctamente. Y es que al diseñar un informe con iReport, una pieza fundamental de configuración es indicarle el DataSource a usar, de forma que pueda consumir la información para la generación futura del informe, por lo que necesitamos, lo primero de todo, entender cómo gestiona esta fuente de datos nuestro plugin.

Al instalar el plugin Jasper, éste nos proporciona entre otros ficheros, un controlador y un servicio, denominados JasperController y JasperService, respectivamente. El controlador es el encargado de comprobar la ruta donde está definidos los informes .jasper (más detalle sobre .jrxml y .jasper en el Apéndice A), el tipo de informe a generar y si los datos a utilizar son del tipo ‘java.util.Collection‘ o no (a pesar de que la documentación del plugin claramente indica que se puede utilizar un mapa, pero no es posible). Una vez realizadas las comprobaciones, delega en la lógica de negocio definida en el servicio que, según el tipo de informe, invoca a la API de JasperReports, genera el informe y lo devuelve como un ‘java.io.ByteArrayOutputStream‘. Nada maravilloso aquí, ¿verdad? Pero, volviendo al tema del DataSource, ¿cómo se las arregla el plugin para proporcionar dicha fuente de datos a JasperReports? El truco está en que usa internamente un ‘net.sf.jasperreports.engine.data.JRBeanCollectionDataSource‘, que se alimenta de la colección de datos que le pasamos cómo modelo al controlador JasperController. Veamos un ejemplo:

def informe = {
	def listaDatos = // obtener la colección de datos que alimentarán al informe.

	chain(controller: "jasper", action: "index", model: [data: listaDatos], params: params)
}

Si analizamos el código de arriba, vemos la definición de una acción dentro de un controlador (este controlador pertenece a nuestra aplicación y es necesario para llamar al plugin para que genere el informe): informe. Dentro de esta acción, calculamos la colección de datos que será necesaria para alimentar al informe y, al final de la acción, encadenamos nuestra acción con una nueva acción: index dentro del controlador proporcionado por el plugin, pasándole la colección de datos y también los posibles parámetros (más sobre parámetros en un futuro artículo sobre sub-informes). Cuando el controlador del plugin recibe la petición, automáticamente invoca al servicio, como se ha explicado con anterioridad, generando el informe y mostrándolo por pantalla (en realidad, dependiendo del navegador, puede que lo guarde como un fichero y lo abra con la aplicación correspondiente, como Acrobat Reader).

Aunque aquí os aconsejamos utilizar una colección de datos como entrada a la fuente de datos del informe, es también posible no indicar dicha colección, en cuyo caso el servicio JasperService utilizará automáticamente el ‘dataSource‘ definido en nuestra aplicación (recordad, en /grails-app/conf/DataSource.groovy), obteniendo del mismo una conexión que pasará directamente al informe. Sin embargo, en nuestra modesta opinión y en la mayoría de los casos, esta última estrategia de fuente de datos no será la más adecuada, ya que nos obligará a definir todas las sentencias SQL necesarias para obtener los datos directamente en la definición del informe, lo cual resulta algo absurdo cuando tenemos todos los datos a nuestra disposición en el controlador, ¿no? Además, y todavía más importante, al desarrollar en Grails nos olvidamos bastante del SQL y, sobre todo, de la estructura de las tablas en base de datos, ya que trabajamos a nivel de objetos, por lo que tener que definir sentencias SQL que sólo son necesarias para obtener los datos del informe se nos antoja, definitivamente, una pérdida de nuestro preciado tiempo.

NOTA: Al pasar una colección de objetos a la acción encadenada del plugin Jasper hay que tener muy en cuenta la forma en que hemos mapeado las asociaciones de nuestros objetos, ya que una vez la colección se ha pasado a JasperReports, ya no existe ninguna sesión de Hibernate, con los consiguientes problemas de LazyInitializationException que todos hemos sufrido alguna vez en la vida. Para asegurarnos que no nos vamos a encontrar con estos problemas, entre otras razones porque Grails mapea las asociaciones entre objetos de forma perezosa (lazy) por defecto, lo mejor es materializar el objeto de forma completa, y para ello un truco muy sencillo es utilizar el método dinámico ‘findById‘ de la siguiente forma:

	// Forzamos la recuperación de la información sin carga perezosa.
	def objetoMaterializado = MiClase.findById(id, [fetch: [asociacion1: 'eager', asociacion2: 'eager']], [cache:true])

También podríamos conseguir el mismo objetivo con Criteria o con HQL, de forma muy similar, pero creemos que con el método dinámico es mucho más sencillo y simple de entender.

Volviendo, pues, a los pasos necesarios para generar nuestros informes, y una vez que hemos configurado nuestra acción en nuestro controlador para que encadene con la acción del controlador del plugin Jasper, ahora necesitaremos generar el enlace desde nuestra pantalla GSP a esta primera acción de nuestro controlador. Para ello, el plugin nos ofrece una pequeña librería de etiquetas (JasperTagLib) donde podemos utilizar la siguiente:

Esta etiqueta nos generará un enlace a nuestra acción dentro de nuestro controlador, pintando, además, un pequeño icono correspondiente al formato indicado, en este caso PDF, como se muestra en este ejemplo:

Y ya estamos concluyendo este artículo. Ahora, como paso final, sólo nos queda conocer cómo debemos definir cada uno de los campos en el informe para que JasperReports sea capaz de interpretar los datos y aplicarlos correctamente. Como estamos haciendo la suposición en todo momento de que usamos iReport, simplemente desde el IDE creamos un nuevo ‘Field‘ y, esto es muy importante, lo llamamos exactamente igual que el campo definido en la clase del dominio que corresponde a cada uno de los objetos pasados en nuestra colección como fuente de datos. Por ejemplo, si tenemos una clase del dominio como esta:

	class MiClase {
		String nombre
		String apellidos
		Date fechaNacimiento
	}

y le pasamos una colección de objetos del tipo ‘MiClase’ al informe, entonces este último debe tener definidos los siguientes ‘Fields’ (los indicamos directamente en XML para su mayor compresión):

Nótese que utilizamos exactamente el mismo nombre y el mismo tipo que en la propia definición de la clase del dominio. Esto es de vital importancia, ya que si no coinciden a la exactitud (también en mayúsculas y minúsculas), no os funcionará nada.

Y ya tenemos nuestro informe listo para trabajar. No ha sido un camino de rosas desde luego, pero una vez hemos creado el primer informe, el resto son coser y cantar o, al menos, trabajo puro y duro de diseño con nuestro IDE en iReport.

Si os ha gustado este artículo, no os perdáis el nuevo que estamos preparando sobre sub-informes. Y como siempre os decimos, por favor dejad vuestros comentarios y experiencias al aplicar en vuestro desarrollos los artículos aquí explicados. Nos encanta saber que la información que compartimos para todos vosotros realmente es de utilidad.

APÉNDICE A: .jrxml es la extensión de los ficheros de texto XML de definición de informes según la especificación de JasperReports, mientras que .jasper es la extensión de los ficheros binarios ya compilados por JasperReports, que son los que realmente se “ejecutan” al generar el informe.