Al pasarlo a producción nos surgieron dos dudas, la primera es como manejar los cambios en la base de datos de negocio. Tenemos armado un DCA con toda la configuración inicial del requisito, tal cual está ejemplificado en la documentación. Hay alguna forma de incluir ese script para que al generar nuestra versión de 4 dígitos se ejecute directamente al correr el comando ./guarani migrar_base o algo similar?
La otra duda que nos surge es si hay alguna forma de activar un requisito solamente para una operación, o si esto mismo se puede hacer a través de un DCA para que el pasaje a producción sea más rápido. Actualmente lo que hacemos es desde la interfaz de gestión asociar el requisito creado a la acción y responsable académica correspondiente , pero por ejemplo al asociarlo a cursadas, nos queda por defecto activado para todas las operaciones asociadas con la acción y luego tenemos que ingresar una por una a desactivarlo.
Hola Diego,
respecto del primer tema, cómo manejar las personalizaciones de la base de negocios de Guaraní, lo que nosotros recomendamos es que mantengan una carpeta BD dentro de su carpeta personalización, donde vayan incluyendo los scripts, para catalogarlos y conservar esos cambios documentados, preferentemente también asociados a la versión sobre la cual aplicaron esos cambios. Tal vez durante el desarrollo pueden mantener un script por cada cambio que generan, luego les sugerimos armar un único script por versión de 4 dígitos que incluya todos los cambios propios aplicados a dicha versión, nomenclándolo de manera de distinguir a qué versión corresponde.
Incluir estos diferenciales en un comando no sería tan directo, ya que dependiendo de los requisitos de temporalidad de ejecución y del esquema que utilice cada institución, deberían verificarse distintas condiciones, y dado que es un único script que se corre sólo una vez, cuando se migra el servidor de producción, no tiene tanto sentido automatizarlo.
Respecto del segundo tema, la configuración de los nuevos requisitos agregados, mediante la operación de Requisitos por Acción se asocian los requisitos a la acción, afectando las tablas sga_requisitos_grupos, sga_requisitos_x_accion y el aplanado utilizado para distintos controles en el sistema sga_requisitos_aplanado. Lo que está sucediendo es que la tabla de requisitos por acción tiene un trigger after insert que, luego de asociar el requisito a la acción, también da de alta todos los registros que asocian dicho requisito a todas las operaciones de la acción como Activos. Para evitar entrar a la operación Configurar Requisitos por Operación por cada operación, lo que pueden hacer es, luego de haber asociado el Requisito a la Acción, ejecutar por base los UPDATES sobre la tabla sga_requisitos_conf_x_oper que modifiquen ese requisito para esas operaciones en que desean desactivarlo. Pueden armar un script con un update de la forma:
UPDATE sga_requisitos_conf_x_oper
SET activo = 'N'
WHERE operacion IN ('800SIUCUR001', '800SIUCUR002', ...) -- código de las operaciones para las cuales se quiere desactivar el requisito
AND requisito_accion = $id_del_requisito_accion -- correspondiente al requisito por acción que dieron de alta anteriormente
El id de ese requisito por acción lo pueden verificar en la base (tabla sga_requisitos_x_accion), luego de haber asociado el requisito a la acción en el sistema.