Open Source Document Management System | OpenKM

Estamos maravillados con lo que este software hace, enhorabuena y gracias por vuestro gran trabajo. Estamos muy ilusionados por empezar.

Nuestro equipo ha considerado empezar a adentrarse en su uso. Queremos añadirlo y ampliar Web y servicios que llevamos mucho tiempo ofreciendo. Hemos decidido antes empezar con la versión Open Source, ampliar experiencia, probar insitu y más adelante, en ampliaciones futuras de nuestros servicios también ampliar a OpenKM Profesional.

Surgen pues dudas sobre las posibilidades de la versión Open Source, ver si nos llegaría de entrada o empezar con otra:

1) ¿podríamos usar hibernate y conectarla a nuestra Base de Datos Oracle que ya tenemos o sólo es posible si se usa la versión Profesional de OpenKM?
2) ofrecer alta disponibilidad usando front-end en una estructura de varios servidores balanceados. Esto lo podríamos hacer o es necesario la versión profesional.

Gracias por vuestra ayuda.

Para el Oracle vas a necesitar la profesional, por desgracia el hibernate hace magia pero no tanta. En el caso de oracle internamente hay unas cuantas optimizaciones que permiten que funcione correctamente con esta base de datos. Con la versión community tendreis que modificar un par de cosas del código fuente seguro.

Relativo a utilizar al tema del balanceo, me imagino que hablais de un HAProxy. Esto os podemos confirmar que lo hemos probado. Ahora bien si quereis utilizar un clusters de OpenKM aquí en la community hay una limitación, que es el lucene ( no esta preparada para tener varios openkm pero solo un indexador, el problema que tendreis al meter 2 servidores de OpenKM es que los dos van a tener su propio lucene y uno de los dos indexará el documento o lo que sea. ). La base de datos maestro-esclavo con la community no tiene que tener problemas. Otra história la vais a tener con la ubicación del repositorio ( que necesitareis compartirla para los 2 openkm ). Ojo no se exactamente que quereis montar, pero he intuido - igual equivocadamente - que quereis montar el invento como un cluster de varios OpenKM ?

Os damos las gracias por vuestra ayuda e información.

hemos ido mirando más detalles de nos surjan sobre pros y contras de las versiones comunity y profesional y no hemos podido corroborar una duda:
Sobre el tema de OCR con que OCR's y softwares de ese tipo es compatible OpenKM comunity actualmente y más considerando principalmente los de software libre.

En cuanto al tema de cargas balanceadas, realmente lo que queremos es ofrecer la más alta disponibilidad, pues necesitaríamos ofrecer soporte a gran número de visitas y usuarios.
Estamos abierto a las alternativas posibles y en este caso nos hablas de HAProx ¿es esa la mejor opción que ves para el uso de específico de la versión comunity? ¿En la versión profesional ves alguna otra alternativa que mejore dicha disponibilidad?

Pensabamos que no queremos perder las sesiones de los usuarios y una idea que se nos ocurrió, que igual no es muy acertada en principio ya que aun estamos familiarizándonos con la plataforma y no conocemos bien sus posibilidades, que en el escenario de varios servidores balanceados, si OpenKM nos permitiría que las variables de sesión etc.. vayan en BD y no estén en los servidores frontend / backend.
Pero en realidad esta idea puede ser descabellada porque hablamos sin conocer aun bien la plataforma y esto requeriría cambiarla exesivamente y quizas sea mejor ceñirse a posibilidades de balanceo de cargas que están más probadas y requieren menos cambios y adaptación del código.

Una vez más gracias de veras porque vuestras respuestas nos ayudan mucho y nos vamos encauzando mejor.

Saludos

Necesitas utilizar la interfaz de usuario ? porque igual lo mejor es plantearse una interfaz a medida con el sdk4j por ejemplo y metiendo una capa superior ciertas cosas de estas que quieres hacer las vas a tener mas personalizadas, sin tocar el core ( cosa que no te interesa ).

Sobre los OCR, puedes integrar cualquier motor al que puedas llamar con un comando por el terminal. Implementar uno es bastante trivial.