Saltar al contenido principal

Desde la mirada de un cliente

Desde la mirada de un cliente

En el ejemplo a continuación se puede observar un circuito de Gateway en acción. En esta ejemplificación un Guaraní de una institución (uun1) requiere del Guaraní de otra institución (uunn2) la historia académica de una persona. Nótese como los módulos sólo interactúan con la API Interna de su Gateway.

Dos ecosistemas
Dos ecosistemas

Paso_1 Paso 1

Paso_2 Paso 2

Paso_3 Paso 3

Desde la mirada interna

Gateway puede operar en 2 roles distintos, puede ser origen o destino dependiendo si envía o recibe paquetes. Por ejemplo, cuando uunn1 pide la HA de una persona, el GW de uunn2 operará como destino. uunn2 luego de haber recibido el pedido ópera como origen enviando un paquete con la información requerida.

Origen

  • Crear paquete desde un módulo indicando la metadata.
    • POST /paquete
  • Cargar contenido al paquete.
    • PUT /paquete/ID/cargar-texto
  • Finalizar la creación del paquete.
    • PUT /paquete/ID/finalizar

Dispatcher Origen
Es el dispatcher que inicia el proceso de envío de los paquetes al Gateway destino, es quien envía al Worker Origen las novedades a notificar. Toma las novedades en estado OM_FINALIZADO y las encola en la fila QUEUE_NOTIFICAR de la cual el Worker Origen las levanta para iniciar el proceso. También aquellas en estado OG_ENVIANDO, OG_FALLO_ENVIO y OG_DESTINO_DESACTUALIZADO para reintentar el proceso de notificación.

Worker Origen
Levanta las novedades en QUEUE_NOTIFICAR enviadas por el Dispatcher Origen y le notifica al Gateway Destino que están disponibles. Utiliza el endpoint de la API externa del Gateway Destino “/paquetes/notificar” para notificar que tiene novedades con paquetes disponibles. Aquellas que son notificadas exitosamente junto con su paquete pasan al estado OG_ENVIADO, las que no, toman OG_DESTINO_DESACTUALIZADO o OG_FALLO_ENVIO según el fallo.

Dispatcher Sincronizador
Levanta paquetes/novedades con estados que indiquen que avanzaron más allá de Gateway Origen (OG_ENVIADO en adelante) y sirve para sincronizar los movimientos con los que suceden en el GW Destino. Además se chequea que haya pasado cierto tiempo (configurable) desde que el paquete fue actualizado por última vez. Las novedades que cumplen las condiciones son encoladas a la fila QUEUE_SINCRO_MOVIMIENTOS para que las levante el Worker Sincronizador.

Worker Sincronizador
Toma las novedades que son encoladas en QUEUE_SINCRO_MOVIMIENTOS y hace una llamada al endpoint “/movimientos-paquetes” del GW Destino indicando la institución y paquetes de los cuales quiere recuperar los movimientos. Los paquetes son actualizados y se les añaden los movimientos correspondientes al GW Destino.

Destino

Dispatcher Destino
Levanta novedades que fueron recibidas y se procesarán mediante alguna de las siguientes formas dependiendo de su estado:
-Se utilizan para encolar la descarga del paquete de la novedad a la fila QUEUE_DESCARGA_PKG: DG_NOTIFICADO.

-Se utilizan para encolar a la fila QUEUE_NOVEDADES_PROCESAR y realizar el callback (notificar del estado del paquete al Gateway Origen): DG_DESCARGADO, DG_ANULADO, DG_NOVEDAD_PARA_RECIBIR, DM_RECIBIDO y DM_ANULADO.

-Se utiliza para re-encolar una descarga de paquete que estuvo parada/colgada por X razón a la fila QUEUE_DESCARGA_PKG: DG_EN_DESCARGA.

Worker Destino
Poseé distintos procesos:
-Descarga de la metadata del paquete:
Toma la novedad recibida en la fila QUEUE_DESCARGA_PKG que poseé un uid de paquete del Gateway Origen y utiliza ese uid para descargar los datos del paquete. Realiza este proceso indicando el uid al endpoint “/descargas/UID/iniciar” de la API Externa del Gateway Origen. Cuando el proceso es exitoso se crea el paquete de manera local. Si poseé contenido y partes a descargar se encola en la fila QUEUE_DESCARGA_PARTE y avanza hacia el proceso de descarga del contenido.

-Descarga de contenido/partes del paquete:
Inicia o continua la descarga del contenido del paquete, aquellos que están en la fila QUEUE_DESCARGA_PARTE. Pega a la API Externa del Gateway Origen indicando uid del paquete y id de parte “'/descargas/UID/contenido?parte=ID_PARTE” para descargar el contenido. Si falla la descarga de la parte se verifica que no superé el umbral de reintentos (configurable) y reintentar la descarga. Si se supera dicho umbral falla la descarga del paquete completo (DG_FALLO_DESCARGA). Cuando se descarga la parte avanza hacia el proceso de cierre mediante la fila QUEUE_DESCARGA_CIERRE.

-Cierre de la descarga del paquete:
Toma los paquetes de la fila QUEUE_DESCARGA_CIERRE. Si posee estado DG_FALLO_DESCARGA los anula y pasan al estado DG_ANULADO ya que falló la descarga de alguna de sus partes.
Si el paquete está en estado DG_EN_DESCARGA se chequea que no posea partes pendientes de descarga y si su hash es correcto. Si poseé partes pendientes continuará en el circuito de descarga (QUEUE_DESCARGA_PARTE) y si falla su hash será anulado. Cuando las verificaciones son exitosas el paquete pasará al estado DG_DESCARGADO y su novedad al estado DG_NOVEDAD_PARA_RECIBIR indicando que está listo para iniciar el proceso de descarga por el Módulo Destino.

-Procesamiento de novedades (callback):
Toma los paquetes de la fila QUEUE_NOVEDADES_PROCESAR y utiliza distintos endpoints de la API Externa del GW Origen para notificar en qué estado se encuentra el paquete/novedad.
Si la novedad está en estado DG_NOVEDAD_PARA_RECIBIR o DG_DESCARGADO notifica que ya finalizó la descarga del paquete en el GW Destino con “/descargas/UID/finalizar”.
Si la novedad está en estado DM_RECIBIDO es que ya fue descargado por el Módulo Destino y notifica al GW Origen de tal cosa con “/descargas/UID/entregado”.
Si el estado de la novedad es DG_ANULADO o DM_ANULADO significa que el paquete se anuló durante la descarga desde el GW o Módulo Destino. Hace una llamada al endpoint “/descargas/UID/fallida”.
Una vez que el paquete/novedad pasa por este proceso se marca en el campo callback_procesado de la novedad que ya fue procesado para que no vuelvan a ser levantados por el Dispatcher Destino. IMPORTANTE: Si el procesamiento de la novedad falla, será marcada como “ya procesada” de igual manera.

  • El cliente descarga el paquete utilizando la API Interna.
  • El worker de procesamiento de novedades (callback) corriendo en el destino notifica al origen del estado de la descarga utilizando endpoints de la API Externa del origen.