Prueba

Existe un tutorial avanzado para crear la aplicación Bicycle Workshop paso a paso: https://github.com/cuba-platform/workshop/wiki. Este tutorial es mas extenso y tiene más detalles.

Voy a intentar hacer una ingeniería inversa de la BD de SICRE, para ello creo un nuevo proyecto:

Una vez creado el proyecto, voy a intentar importar algunas tablas de SICRE.

Dejo la BD del tipo HSQLDB (básica para desarrollo):

Voy a añadir un Data Store secundario que apunte a la BD de SICRE con SQL Server 2012+:

Una vez verificadas las conexiones, en la pestaña DATA MODEL seleccionamos la opción Generate model, que importa tablas existentes en modelos de CUBA. Elegimos el Data Store SICRE:

Aquí se nos pedirá que actualicemos la BD para poder trabajar con CUBA. Realmente se crean una serie de tablas con los prefijos 'SEC_' y 'SYS_'; por lo que habrá que tener cuidado de eliminarlas si sólo vamos a importar la estructura a una nueva BD. Si vamos a trabajar con la BD antigua desde CUBA, entonces si habrá que dejarlas.

Nos salen unas opciones de importación, pero no voy a entrar a valorarlas al ser una prueba:

Voy a seleccionar la tabla RECIBOS para la prueba (hay que tener en cuenta que la versión libre sólo permite 10 entidades, pero para probar basta):

Además, se seleccionarán tablas necesarias para la importación, normalmente con relaciones 1 a N (lookups), por lo que parece:

Aparecerá un resumen del estado de la importación. en verde y con OK salen las tablas que se pueden importar sin problemas, y en amarillo nos aparecen las tablas que tienen algún problema en la importación:

En este caso, los problemas son columnas que tienen valores asociados a reglas/dominios, como los campos 'S/N', o los estados de los recibos:

Estos errores se pueden subsanar añadiendo los campos como su tipo primitivo y usando Enumerators, como en el siguiente ejemplo que simula el campo 'S/N':

Como he mencionado antes, aunque he seleccionado una sóla tabla, al necesitar de tablas adicionales, superamos el límite de 10 entidades:

Por lo que voy a seleccionar sólo 2 tablas:

En caso de sólo que vayamos a importar la estructura de las tablas, podemos cambiar Data store de las entidades a la BD nueva:

De esta forma, posteriormente tendremos que diseñar lo procedimientos de migración de datos entre las BBDD.

Si vamos a hacer una actualización, sólo tendremos que cambiar algunos campos de la BD tal y como se está haciendo en la nueva aplicación iSICRE desarrollada con Serenity.

Aceptamos los errores y creamos las pantallas estándar:

Podemos añadir scripts adicionales al proceso de importación:

Y ya podemos ver todas las pantallas creadas (aparece la entidad Comuneros que se había importado previamente):

Para la pantalla de detalle, automáticamente se añaden los campos con layout vertical, aunque supongo que se podrá modificar a posteriori.

Y para la ventana de resumen, nos añade una banda de filtro y un grid:

Si compilamos la aplicación y la visualizamos, obtenemos lo siguiente:

Un problema que ocurre al visualizar los Comuneros, es que al usar el campo NUMEROSOCIO como clave, no lo visualiza. Con Serenity ocurría algo similar, y se pudo arreglar retocando el código.

Estos frameworks están pensados para usar cada tabla con un campo ID (generalmente un GUUID)), que es transparente al usuario y es usado por el ORM (o JPA en este caso). Este enfoque en el diseño de tablas en BD modernas es mas flexible, ya que permite cambiar fácilmente un identificador que no es clave primaria, aunque sí esté indexado.

El proceso ha sido bastante rápido, contando incluso con la instalación de Studio, que se encarga de instalar todas las herramientas adicionales, salvo el SDK de Java.