Solop
Diccionario Multi-Tenants #2510
Replies: 4 comments 2 replies
-
|
Los enlaces para las instancias son Diccionario
Instancia Custom con código de diccionario
|
Beta Was this translation helpful? Give feedback.
-
|
Hilo de la conversación en Discord https://discord.com/channels/954056226579308624/1253441922933194867 |
Beta Was this translation helpful? Give feedback.
-
Prueba.1.Diccionario.RS.mp4Agerego video con la primer prueba con algunas dudas |
Beta Was this translation helpful? Give feedback.
-
|
Según se entiende la funcionalidad actual presentada permite 2 escenarios:
En ese orden, se realiza una verificación de modificar diccionario en las instancias de manera independiente y se visualizan los cambios aplicados sólo en la instancia que se modificó. Por otro lado luego se acualizó el campo "Dictionary Code" en la compañía System y se generó cambios sólo en la instancia CUSTOM y se lograron visualizar correctamente en AMBAS instnacias de VUE replicados. De esta manera daría por validado la funcionalidad entregada. Diccionario híbrido (algunas Ventanas con diccionario personalizado)Por otro lado me surge el problema de que dificilmente esto pueda ser aplicable en clientes de producción, ya que si bien muchas ventanas ayudará para replicar definición de diccionario en común, siempre existen algunos casos de ventanas que se solicitan cambios puntuales del Cliente, ya sea Nombres, Campos u mismo un ordenamiento. En ese sentido, @yamelsenih se piensa menajar un siguente paso de permitir un híbrido entre diccionario COMUN que se pueda replicar masivamente de manera fácil pero también poder ir a una ventana en concreto y seleccionar que esta si se desea llevar un diccionario único de la instancia? En estos casos no se deberá tomar el diccionario comun de "CUSTOM" sino que se debería tomar la definición de diccionario exclusiva que tendrá la instancia definida. En caso de tenerlo planificado, cuando es la idea de poder contar con esto? Si bien puedo avanzar con varias instancias para ir avanzando ya con este código y asi ir probando más a fondo la funcionalidad, dentro de un mes debería de poder contar con una definición de ventana por instancia también. |
Beta Was this translation helpful? Give feedback.
-
|
Con respecto al punto
Ya lo tengo considerado dentro del Roadmap V
Esto es lo que metí como estabilización de servicios. |
Beta Was this translation helpful? Give feedback.
-
|
Bien bien perfecto. De ser así nosotros ya estaríamos para ir avanzando... Luego q se cuente con la personalización por Compañía de algunas ventanas avanzaremos con la personalización final. |
Beta Was this translation helpful? Give feedback.
-
Anteriormente la gestión del diccionario se hacía consultando desde la base de datos relacional PostgreSQL, y se procesaba con ADempiere-gRPC-Server en java, y se devolvía con el envoy-proxy las estructuras necesarias para cargar cada ventana, proceso/reporte, consulta inteligente, menú y formas; esto luego evoluciono migrándolo a Dictionary-RS con rust, OpenSeach como motor de búsquedas y almacenamiento no-sql, y kafka en las colas para el envío de modificaciones, logrando una mejora considerable en los tiempos de carga sobre todo en el menú y ventanas que son los que poseen más metadatos y donde era más evidente el retraso, sin embargo era necesario agregar por cada stack para clientes un servicio de kafka, OpenSearch y Dictionary-RS.
Con el nuevo diseño a nivel de servicios para el manejo del diccionario, ahora basta con un solo servicio de kafka, OpenSearch y Dictionary-RS que gestione el diccionario de todos los demás conjuntos de instancias de cada cliente. Esto tiene múltiples ventajas como la reducción de recursos a nivel de hardware en el mismo servidor.
Otra de las mejoras es el tiempo de exportación y hay cambios de los índices, ahora solo se exporta por instancia, ya que los metadatos siempre se almacenan en la compañía System, por lo que no es necesario que sea exportada por cada compañía.
Antes para las cada entidad de diccionario (exceptuando el menú), se creaba un índice de cada uno, por cada idioma, por cada compañía es decir creaba 4 índices en total:
Ahora por cada instancia solo exporta para cada entidad de diccionario, por cada idioma, creando 2 indices en total:
A nivel de menú también hubo cambios de índices y como se almacenan los documentos.
Anteriormente todo el árbol de menús se almacenaba por cada idioma, por cada compañía por cada rol, lo que era muy redundante en datos incluso en almacenamiento no relacional:
Ahora se separan los índices, menu_tree donde se almacena el árbol de nodos completo, menu_item donde se establece la información completa de cada elemento del menú, y role donde se almacenan los accesos, para devolver el menú se busca el árbol, se filtran los accesos del rol y se llenan los elementos del menú como nombre, secuencia, si es sumario, árbol; quedando la siguiente distribución de índices:
Cabe destacar que los accesos de rol usan en el nombre del índice el uuid de la compañía. También para los elementos del diccionario usan en el nombre el código de diccionario:
Pruebas
Se hicieron modificaciones en la ventana de
Socio de Negocioy luego se exportaron:Proveedorluego del campoNombre 2:Empleadosluego del campoNombre 2:Beta Was this translation helpful? Give feedback.
All reactions