Servicios - Blindas31/GRUPO5-2024-PROYINF GitHub Wiki

  • Externos:

Se priorizo el formato a la hora de guardar los requerimientos en la base de datos. Para esto se empleo la plataforma Make, la cual permitió manejar el flujo de datos y uso de mas de una API. En este caso se empleo la API de ChatGPT (gpt-4o-mini), la cual a partir de un prompt predeterminado y los datos que se buscan ingresar en la base de datos buscara crear un json en texto plano el cual posteriormente se formateara dentro del flujo, para posteriormente ser enviados al Back con el formato correspondiente. image La versión previa de la misma se subió a modo de registro de avance histórico (se puede revisar importando el archivo a la plataforma mencionada). Explicación de módulos:

  1. Webhooks: Recibe a través de una API la siguiente data (recogida previamente en el back):
{
"Regiones": Regiones ingresadas,
"Objetivo": Objetivo ingresado,
"Descripcion": Descripción ingresada,
"Url": Url donde se volverá a enviar la data a través de un método POST
}
  1. OpenAI(ChatGPT): La presente data se combina con el prompt y se envía a la API de chatGPT, la cual retorna un json en formato texto plano de la siguiente forma:
{
"Regiones-nuevo": Regiones ingresadas según un formato de fácil lectura,
"Objetivo-nuevo": Objetivo en un formato mas ordenado para ingresar a la BD,
"Descripción-nuevo": Descripción en un formato mas ordenado para ingresar a la BD
}

Lo que se espera en este paso es que si el usuario paso ciudades en especifico o zonas en formato numerado, pasarlas al formato por nombre y si es mas de una se separen por "-". En caso de la descripción y objetivos si se encuentran desordenados(Por ejemplo el objetivo esta mal puesto pero se menciona en la descripción este paso lo ordena y lo pone en su sitio priorizando el orden de la base de datos). En caso de que falte información o sea errada(Por ejemplo se pone una ciudad de otro país) se pondrá un flag indicado con un 0, lo que permitirá evitar la posterior inserción en la base de datos y notificarle la usuario de la FIA que vuelva a formular el requerimiento, mencionándole la componente errónea.

  1. Json: Recibirá el json en formato texto plano que retorna el paso anterior para convertirlo en un json "real", para posteriormente enviar dicha información al back.

  2. Http: Envía el json a la URL enviada inicialmente a partir de un método POST, lo cual permitirá recibir en el back los datos en el formato esperado.

  • Internos:

Es importante mencionar que lo expuesto no fue manejado de esa forma a nivel de código, siendo nuestro manejo mas bien monolítico, ya que no hay independencia de las partes a ningún nivel. Siendo la base de datos común para todas las funcionalidades del sistema, tanto boletines, como requerimientos y usuarios. El detalle mencionado tanto para requerimientos como boletines se estructuro en base a los principios REST.

  1. Servicio de requerimientos: Microservicio al cual se le asignan todas las tareas relacionadas al manejo requerimientos.
    1. Ingreso de requerimientos: En la historia de usuario de ingreso de requerimientos se realizara una interacción de tipo "CREATE", por lo que la información para el ingreso de dichos datos será enviada a través del método "POST".
    2. Modificación de requerimientos: En la historia de usuario de modificación de valores de requerimientos se realizara una interacción de tipo "UPDATE", por lo que la información para la modificación de dicho requerimiento será enviada a través del método "PUT".
    3. Eliminación de requerimientos: En la historia de usuario de eliminación de requerimientos se realizara una interacción de tipo "DELETE", por lo que la información para realizar la eliminación de dicho requerimiento será enviada a través del método "DELETE".
    4. Consulta de requerimientos: En la historia de usuario de consulta de requerimientos según su estado se realizara una interacción de tipo "READ", por lo que la información para mostrar los requerimientos será enviada a través del método "GET".
  2. Servicio de boletines: Microservicio al cual se le asignan todas las tareas relacionadas al manejo de boletines.
    1. Ingreso de boletines: En la historia de usuario de ingreso de un nuevo boletín se realizara una interacción de tipo "CREATE", por lo que la información para el ingreso de dichos datos será enviada a través del método "POST".
    2. Modificación de estado de los boletines: En la historia de usuario de modificación de estado del boletín, dejándolo publico o privado, se realizara una interacción de tipo "UPDATE", por lo que la información para la modificación de dicho requerimiento será enviada a través del método "PUT".
    3. Consulta de boletines: En la historia de usuario de consulta de información de boletines, se realizara una interacción de tipo "READ", por lo que la información para mostrar los requerimientos será enviada a través del método "GET". Lo mencionado también se hace presente en la historia de usuario que menciona la posibilidad de acceder a cada boletín, permitiendo descargar y visualizar.
  3. Servicio de credenciales usuarias: Se espera a posteriori modificar el sistema de forma tal que exista una sincronización entre la tabla de usuarios del sistema actual (la cual en caso de migrar a microservicios pasaría a tener una BD independiente, con ese único fin) y la base de datos de usuarios de la FIA (Para esto se necesitaría generar una conexión con la misma, vía API, la cual permita ir actualizando según corresponda). Lo mencionado seria esencial para el sistema, ya que permitiría al usuario manejar sus credenciales de forma unificada.