Mejoras en la exportación de contratos

En Tractis todo el proceso de negociación y firma se realiza sobre contratos escritos en XHTML 1.0, un formato ideal para la manipulación y edición de documentos en entornos web. Sin embargo, mucha gente necesita disponer de sus contratos en una variedad de formatos (pdf, word, texto plano…) para impresión, distribución, back-up, generación de informes o, simplemente, porque prefieren editarlos en entornos offline. Tractis incorpora una funcionalidad de importación y exportación de documentos que permite convertir documentos desde una variedad de formatos a XHTML y viceversa, de XHTML a Word, OpenOffice, texto plano, pdf y html, entre otros.

Desde el lanzamiento de la importación y exportación de plantillas y contratos en Octubre 2007, hemos venido sufriendo problemas en la prestación de esta funcionalidad, desde exportaciones a pdf, word,… extremadamente lentas a caídas del servicio. Esta semana hemos añadido varias mejoras, tanto en software como en infraestructura, que confíamos mejorarán sensiblemente la calidez, rapidez y estabilidad de importaciones y exportaciones.

Este post explica el “Antes” y el “Ahora” de la importación y exportación de contratos en Tractis; todo ello aderezado con consejos, pistas y enlaces interesantes para aquellos que necesiten montar una funcionalidad similar.

Antes

La funcionalidad de importación y exportación no es algo sencillo de implementar ya que hay que lidiar con las particularidades de los distintos formatos y las transformaciones implicadas en estas conversiones no son algo a tomar a broma. Como se trataba de un proceso complejo optamos por examinar las herramientas disponibles en el mercado, tanto open source como de pago, y llegamos a la conclusión de que la herramienta que mejor se adaptaba a nuestras necesidades era OpenOffice.

Optamos por emplear OpenOffice 2.2 (que permite su uso en modo server para conversión sin usar su IGU) como servicio core de conversión y jod-converter como libreria de acceso al servicio para poder dar el servicio de conversión como un servicio web creando un nuevo componente dentro de nuestra arquitectura SOA.

El problema era que OpenOffice 2.2 en modo server es terriblemente inestable y presentaba una colección de bugs enormes en la conversión de documentos que hacian muy incomodo su uso. Todo ello nos obligó utilizar trucos poco elegantes pero necesarios para poder prestar el servicio.

Para evitar las caidas disponiamos de un complejo sistema de watchdogs que cada vez que la instancia de OpenOffice moría las resucitaba … pero eso no es vida . Y como la suerte del open source es que, si algo no te gusta lo puedes cambiar, optamos por liarnos la manta a la cabeza y tirar por el camino salvaje.

Ahora

La gente de OpenOffice ha liberado recientemente la versión 2.3, mucho más estable que la 2.2 en modo server pero no lo bastante como para dar un servicio en un entorno de producción con garantias suficientes. Así que aplicamos un axioma de mi cosecha: “si tus trabajadores se mueren con frecuencia… ponlos en cluster;) .

A partir de esta simple premisa desarrollamos una ampliación de JodConverter. Esta ampliación permite tener un conjunto de n trabajadores y un algoritmo de asignación de trabajo mediante un algoritmo de round robin que permite que si un trabajador cae otro ocupe su lugar inmediatamente, sin que se pierda ninguna transacción. Además el propio JodConverter gestiona el ciclo de vida de los trabajadores reiniciándolos si no responden o arrancándolos si su proceso muere. Esto evita la necesidad de disponer de un watchdog externo para garantizar la disponibilidad de trabajadores.

Disponer de herramientas como OpenOffice o JodConverter es un regalo y es justo contribuir nuestra ampliación sobre JodConverter con sus creadores por si les interesa usarla… a repartir buen karma :D .

Resumiendo, a todos los que hayáis padecido el problema de tener que implementar un sistema de conversión de documentos, espero que este post y el código compartido os sirva de ayuda. A nuestros clientes, esto es un pasito más para mejorar la calidad de Tractis. Ahora exportamos mejor, más rápido y con un servicio mucho más estable (congrats al creador del feed).

Y sin más demora, aquí os dejamos unos links de regalo: JodConverter como servicio web, Open Office como servidor y como instalar OpenOffice 2.3 en Ubuntu Feisty.

Por David García
Guardado en: Anuncios, Programación, Tractis | 2 comentarios » | 11 de Julio de 2008

2 Comentarios en “Mejoras en la exportación de contratos”

Gravatar de Pedro Perez

Pedro Perez
14 de Julio de 2008 a las 10:22 am    

Muy interesante esto que poneis

Un par de preguntas

-La pagina que hay en http://www.artofsolving.com/online-document-converter si parece que convierte perfectamente, por que decis que aun no es lo suficientemente estable?
-Como habeis resuelto la conversion cuando hay elementos que no se pueden convertir (fuentes,posiciones etc),mostrais la salida directa del conversor o tratais eso?
-Donde esta ese codigo modificado que comentais?

Gracias y seguir asiiiii.

Gravatar de David García

David García
14 de Julio de 2008 a las 11:14 am    

Hola Pedro, aqui van las respuestas a tus preguntas:
- En efecto el conversor JodConverter es perfectamente estable ya que no es “más” que un puente sobre las librerias UNO de OpenOffice.
Aquí quien no és estable es OpenOffice es modo servidor (sobretodo la versión 2.2) que revienta a las n invocaciones.
Además el acceso a estas librerias UNO ocurre dentro de un bloque sincronizado dentro de JodConverter, por lo que puedes tener como mucho 1 conversión concurrente a la vez.
Nosotros hemos añadido a los conversores de JodConverter la capacidad de poder controlar el ciclo de vida de los procesos OpenOffice además de tener n workers pudiendo tener n conversiones concurrentes por servidor.

-Respecto a lo de los elementos no convertibles no tengo respuesta dado que nosotros convertimos nuestros contratos en XHTML (WYSIWIM) con una estructura sin atributos de estilo asociados. Realizamos conversiones como las que comentas pero solo en procesos de importación. Ahí empleamos procesos de transformación sobre el arbol DOM generado con el XHTML en un conponemte externo al conversor.

-Lo del código modificado estamos maquillandolo para que quede bonito (Añadir Javadocs necesarios, paquetizado consistente con el resto de JODConverter) y lo submitaré a la gente de artofsolving por si lo quieren añadir. Si les gusta seguramente lo podras ver en proximos releases, si no les gusta… un zip y lo subo como attachment en próximos posts por si a alguien le es de utilidad.

Un saludo y gracias a ti por tu interes.

Dave

Más entradas en Negonation Blog