Error de Jasper Server

Este error me lo encontré hace unos días ejecutando informes en Jasper Server.

 ERROR JSErrorPage_jsp,http-8080-Processor24:329 - 

java.lang.NullPointerException

at com.jaspersoft.jasperserver.war.action.ViewReportAction.checkForParams(ViewReportAction.java:143)

at sun.reflect.GeneratedMethodAccessor337.invoke(Unknown Source)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:585)

...

Un puntero nulo en un método que, si nos fiamos de su nombre, comprueba los parámetros del informe.

Aunque en principio supuse que el problema debería ser que el valor de alguno de los parámetros fuese nulo, lo que realmente ocurre cuando nos encontramos este error es que hemos definido un Input Control asociado al reporte en el servidor, y éste no encuentra correspondencia en el jrxml. Hay que tener en cuenta que la relación se establece entre el id del Input Control y el nombre del parámetro.

Uso de parámetros en Jasper

Cuando hacemos un informe con Jasper Reports, es muy normal que utilicemos parámetros. De esta forma podemos enviar datos al informe que serán utilizados a la hora de generarlo. Los casos más habituales quizá sean el mostrar directamente el valor del parámetro, o el usarlo a su vez como parámetro para la consulta SQL que ejecutamos dentro de report. En este caso sólo tenemos que definir el parámetro en la sección correspondiente de iReport, y hacer referencia a él con el formato $P{nombre_parametro}, como se muestra en la imagen.

Pero podemos ir más allá. Por ejemplo podríamos recibir como parámetro la sentencia SQL a ejecutar, o alguna de sus cláusulas. En este caso buscaríamos hacer algo como esto.

Pero si tratamos de ejecutar un informe con este formato no funcionará, y nos mostrará una excepción:

net.sf.jasperreports.engine.JRException: Error executing SQL statement for : report1

Para entender por qué pasa esto, tenemos que entrar en detalle y ver qué hace Jasper cuando procesa los parámetros.

Cuando en la definición de la consulta de un Jasper utilizamos un parámetro con el formato $P{nombre_parametro}, lo que la herramienta genera es realmente una consulta SQL con parámetros. Es decir, tendríamos una consulta tal que select * from tabla where campo = ?.

Ahora bien, si lo que vamos a recibir como parámetro es una sentencia que queremos inyectar directamente en la consulta SQL, esta forma de trabajo no funcionaría. En este caso tenemos que cambiar el formato con el que hacemos referencia al parámetro por $P!{nombre_parametro}. De esta forma le indicamos a la herramienta que no queremos pasar un parámetro a la consulta SQL, sino que queremos directamente incluir el valor textual del parámetro como parte de la consulta.

Jasper Server

En las últimas semanas he comenzado a trabajar en un nuevo proyecto que, además de demasiados cambios a nivel personal (como demuestra que me halle escribiendo aquí a estas horas), me ha proporcionado algunas interesantes novedades a nivel profesional.

Una de ellas es el haber comenzado a trabajar con Jasper Server. Ya había utilizado anteriormente la tecnología de JasperSoft para crear informes, siempre a través de la herramienta iReport, pero nunca había llegado a tocar el servidor.

En mi caso me lo encontré ya montado y funcionando, pero me tocó hacer algunas modificaciones a los informes que contenía. La gran duda me surgió nada más empezar. ¿Cómo me bajo un reporte para poder editarlo? Lo primero que me indicó mi instinto fue que bichease la interfaz Web buscando una opción que lo permitiese, pero para mi sorpresa no la había, o estaba muy bien escondida.

Así que tiré del plan B, y rebuscando por iReport encontré una vista hasta entonces desconocida: el repositorio JasperServer.

Cuando se activa, esta vista muestra un panel desde el que se pueden configurar conexiones a servidores Jasper simplemente dando los parámetros necesarios mediante un wizard.

Una vez establecida la conexión, es posible navegar por el contenido del servidor hasta localizar los ficheros jrxml en él publicados. Basta entonces con hacer clic derecho sobre ellos y seleccionar la opción 'Open in editor' para tener el informe en el editor, y en una carpeta temporal de nuestro ordenador. Desde ahí no tenemos más que guardarlo donde nos interese.

Si tras hacer modificaciones queremos realizar el proceso inverso, actualizando la versión del servidor a partir de nuestra copia local, no tenemos más que volver a hacer clic derecho, y seleccionar en este caso 'Replace with current document' (lógicamente con el informe modificado abierto y activo en el editor).

Todo esto dicho para la versión 3.7.0 de iReport.

iReport - java.lang.NoClassDefFoundError: org/codehaus/groovy/control/CompilationFailedException

Un error bastante habitual que se produce cuando trabajamos con la herramienta iReports, creo que a partir de la versión 3 (en mi caso concreto, la 3.7.0).

Cuando creamos un informe con esta herramienta, podemos encontrarnos con el siguiente error al compilar:

java.lang.NoClassDefFoundError: org/codehaus/groovy/control/CompilationFailedException

La causa es tan simple como que el lenguaje seleccionado para el informe es, por defecto, Groovy en lugar de Java. Para solucionarlo seleccionamos nuestro report (el elemento raíz de la vista Report Inspector), y entre las propiedades editamos el valor de Language.

Para evitar tener que realizar este cambio con todos los nuevos informes que generemos, lo suyo es elegir Java como lenguaje predeterminado para nuestro iReports. Esto podemos hacerlo a través del menú Herramientas - Opciones, en la pestaña iReport - General (la que veremos al acceder al menú).