[Respondido] Integración Pilaga-SUDOCU no se ve documento autorizado en SUDOCU

Expediente Electrónico Integrado Integración con otros módulos
1

Hola,

estamos avanzando con la integración de sistemas.
Ahora estamos con pilaga. Para ellos configuramos todo según los instructivos.

En pilaga damos de alta un preventivo de compras, le ponemos el expediente digital que nos trae de sudocu lo mas bien, lo mandamos a autorizar a huarpe , autorizamos en huarpe , en pilaga se ve el documento autorizado correctamente.
El problema esta que en SUDOCU no vemos ese documento y tampoco queda asociado al expediente que se selecciono en el alta del mismo.

Nos pueden dar una mano en donde mirar a ver porque no queda asociado?

Viendo los logs en pilaga, el de queue.log, vemos esto:

[2022-10-27 13:07:28] REPLOG.INFO: [DocumentosProcessor] El documento fue enviado correctamente! returnData: array ( 'uri' => 'https://XXXXXXX/docs/rest/backend/documentos/f5e59899-1a05-4b89-aeba-ef8cacb60f13', 'uid_documento' => 'f5e59899-1a05-4b89-aeba-ef8cacb60f13', ) params: array ( 'uuid_interno' => 'b8d4cff8-e1c2-4207-bf9a-0dac7f2f73bc', ) [] [] [2022-10-27 13:07:38] REPLOG.INFO: [DocumentosActualizarEstadoProcessor] El estado del documento fue actualizado correctamente! returnData: array ( 'uri' => 'https://XXXXXXX/docs/rest/backend/documentos/f5e59899-1a05-4b89-aeba-ef8cacb60f13', 'uid_documento' => 'f5e59899-1a05-4b89-aeba-ef8cacb60f13', ) params: array ( 'uuid_interno' => 'b8d4cff8-e1c2-4207-bf9a-0dac7f2f73bc', ) [] [] [2022-10-27 13:08:46] REPLOG.INFO: [DocumentosNotificacionesProcessor] Se proceso correctamente la notificacion fdbe9d5e-a744-4762-9f1f-607a30419d12. Datos de notificacion: array ( 'notificacion' => 'fdbe9d5e-a744-4762-9f1f-607a30419d12', ) [] [] [2022-10-27 13:08:46] REPLOG.INFO: [DocumentosActualizarEstadoProcessor] Procesando notificaci�n: array ( 'nro' => array ( 'nro_visible' => NULL, 'tipo_visible' => NULL, 'metadata_tipo' => NULL, ), 'info_rechazo' => NULL, 'estado_codigo' => -60, 'uid_documento' => 'f5e59899-1a05-4b89-aeba-ef8cacb60f13', 'estado_descripcion' => 'Fallo el proceso de asociacion', 'referencia_interna' => '{"uuid_interno": "b8d4cff8-e1c2-4207-bf9a-0dac7f2f73bc"}', ) [] [] [2022-10-27 13:08:46] REPLOG.INFO: [DocumentosActualizarEstadoProcessor] El estado del documento fue actualizado correctamente! returnData: array ( ) params: array ( ) [] []

Tambien en el sistema, en “Estado de documentos electrónicos” veo con error pero no dice el porque (adjunto captura)

archivo.pdf (2.05 KB)

2

Hola Juan Pablo,

En este caso, tomo como testigo el NP50 : 3 / 2022, en ese caso el documento quedó en estado PROCESADO, el estado final debe ser AUTORIZADO, por tanto, se nota que hubo algún problema en el proceso.

Para detectar cuál es el problema, te recomiendo revisar el docs-worker de araí documentos.
Una vez que el documento es autorizado, el proceso sigue con el paso de asociación del mismo al expediente en sudocu, el componente que se encarga de esa acción es el worker de araí documentos.
Por otro lado, el componente que le contesta al docs-worker es el sudocu-api-server, así que también podés revisar ese log para ver si le llega alguna petición.

Si cuesta detectar el problema adjuntanos los logs y lo analizamos.

Saludos

3

Hola Facundo,

en los logs del supervisor que corre el worker de pilaga no hay nada relacionado a un error.

Mirando el log del doc-worker veo un error , pero nada que me de una pista:

================================================================================ [2022-10-27 15:58:13] MAIN.INFO: Corriendo Worker . . . [] []

[2022-10-27 15:58:18] RESTHOOKS.DEBUG: SET search_path TO public

[2022-10-27 15:58:18] RESTHOOKS.DEBUG: Conectado a pgsql:host=XXXXX;port=5432;dbname=arai_documentos_testing;client_encoding=utf-8

[2022-10-27 15:58:18] RESTHOOKS.DEBUG: SELECT topic FROM messages WHERE id=:message {“:message”:3131}

[2022-10-27 15:58:18] RESTHOOKS.DEBUG: Procesando endpoint sin autenticación

[2022-10-27 15:58:18] RESTHOOKS.DEBUG: Procesando retry de mensaje para el endpoint ‘http://api-server:8080/integracion/notificacion’

[2022-10-27 15:58:18] RESTHOOKS.DEBUG: SELECT payload FROM messages WHERE id=:message {“:message”:3131}

[2022-10-27 15:58:18] RESTHOOKS.INFO: Envío a http://api-server:8080/integracion/notificacion {“payload”:{“notificacion”:“6df07829-100d-426b-80b2-2c0a2e4f944f”},“user”:“_no_auth”}

[2022-10-27 15:58:18] RESTHOOKS.WARNING: Error en el envío de [3131] a [http://api-server:8080/integracion/notificacion] [“Server error: POST http://api-server:8080/integracion/notificacion resulted in a 500 Internal Server Error response:\n{"details":null,"stack":"Error: error_missing_evento_autorizacion\n Object.throw (/app/src/common/tools.js:431:13)\n (truncated…)\n”]

[2022-10-27 15:58:18] RESTHOOKS.DEBUG: SELECT count(*) AS c FROM requests WHERE message_id=:message AND state <> ‘ACK’ {“:message”:3131}

[2022-10-27 15:58:18] RESTHOOKS.DEBUG: SELECT topic FROM messages WHERE id=:message {“:message”:3131}

[2022-10-27 15:58:18] RESTHOOKS.DEBUG:
INSERT INTO
requests(listener, listener_name, message_id, response_status_code, state, error)
VALUES (:listener, :listener_name, :message_id, :response_status, :state, :error)
{“:listener”:“{"endpoint":"http:\/\/api-server:8080\/integracion\/notificacion"}”,“:listener_name”:“direct”,“:message_id”:3131,“:response_status”:500,“:state”:“FAIL”,“:error”:“[object] (GuzzleHttp\Psr7\Stream: {"details":null,"stack":"Error: error_missing_evento_autorizacion
Object.throw (/app/src/common/tools.js:431:13)
Object._actualizarAutorizacion [as actualizarAutorizacion] (/app/src/modules/gestion/fn_documento.js:498:22)
processTicksAndRejections (internal/process/task_queues.js:95:5)
async /app/src/modules/gestion/integracion.js:56:33","string":"error_missing_evento_autorizacion","clientmessage":"Existe un documento pendiente de autorización en arai-docs que no existe en sudocu | Falta limpiar base arai-docs","url":"/documentos/fecha_incorporacion/","msg":"error_catch","type":"error","id_err":"umo06"})”}

[2022-10-27 15:58:18] RESTHOOKS.DEBUG: SELECT payload FROM messages WHERE id=:message {“:message”:3131}

[2022-10-27 15:58:18] RESTHOOKS.DEBUG: SELECT context FROM messages WHERE id=:message {“:message”:3131}

[2022-10-27 15:58:18] RESTHOOKS.DEBUG: delivery failure

[2022-10-27 15:58:18] RESTHOOKS.DEBUG: SET search_path TO public

[2022-10-27 15:58:18] RESTHOOKS.DEBUG: Conectado a pgsql:host=XXXXX;port=5432;dbname=arai_documentos_testing;client_encoding=utf-8

[2022-10-27 15:58:18] RESTHOOKS.ERROR: No se pudo enviar la notificación {“arai-documentos-uid_notificacion”:“6df07829-100d-426b-80b2-2c0a2e4f944f”}

[2022-10-27 15:58:18] NUCLEO.DEBUG: SET search_path TO public

[2022-10-27 15:58:18] NUCLEO.DEBUG: Conectado a pgsql:host=XXXXXX;port=5432;dbname=arai_documentos_testing;client_encoding=UTF8

[2022-10-27 15:58:18] NUCLEO.DEBUG: UPDATE nc_notificacion
SET app_notificada = now()
WHERE uid = ‘6df07829-100d-426b-80b2-2c0a2e4f944f’;

Igual esa NP50 3/22 que indicas es vieja, de las primeras pruebas que hice cuando empezamos esta integración. Las que hice hoy fueron las otras 2 (NUP y NP50 4/22) que dice “ERROR” el sistema el modulo de “Estado de documentos electrónicos” de Pilaga.

Lo raro es que si consulto esos preventivos, veo el PDF correctamente autorizado y con el stamper.

4

Te cuento que me meti a la base arai-docs a ver q tablas habia y q contenian.
Encontre la tabla nc_proceso donde encuentro estas dos entradas que estan relacionadas a los dos preventivos que probe hoy y quedaron colgados:

---------------------------------------------------------------------------------- id_proceso | 3118 id_codigo_resultado | -60 id_documento | 3076 creacion | 2022-10-27 13:08:17.094366-03 param_id_tramite | 5ce220fa-82bb-4974-8152-bedf4525816a param_id_area | param_id_usuario | 1 app_url | https://XXXXXX.unlp.edu.ar/siu/pilaga/rest/v1/notificaciones/documento app_referencia_interna_json | {"uuid_interno": "b8d4cff8-e1c2-4207-bf9a-0dac7f2f73bc"} finalizacion | 2022-10-27 13:09:29.152775-03 sudocu_error_id | 500 sudocu_error_descripcion | Missing area destino expediente or expediente not found -[ RECORD 17 ]--------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- id_proceso | 3117 id_codigo_resultado | -60 id_documento | 3075 creacion | 2022-10-27 12:50:45.839491-03 param_id_tramite | 5ce220fa-82bb-4974-8152-bedf4525816a param_id_area | param_id_usuario | 1 app_url | https://XXXXXX.unlp.edu.ar/siu/pilaga/rest/v1/notificaciones/documento app_referencia_interna_json | {"uuid_interno": "d6d9552f-873d-4751-a180-c17efb20cec3"} finalizacion | 2022-10-27 12:57:26.065301-03 sudocu_error_id | 500 sudocu_error_descripcion | Missing area destino expediente or expediente not found -[ RECORD 18 ]--------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

La verdad que no se porque ese mensaje de error, porque el expediente en el alta de preventivo se selecciono bien de los que tenia en sudocu disponibles por mi area.

Aguardamos alguna pista para ver por donde viene el tema.

Gracias!!!

5

Agrego un comentario viendo esto ultimo que pase del nc_proceso.

Veo que el param_id_area esta vació, no se que debería ir , pero ademas veo que param_id_usuario es 1.¿ Que id de usuario deberia ir? porque mi usuario no es 1 en nuestro SAML , quiza es por eso que sudocu rechaza la incorportación, porque en sudocu yo no soy 1 y por ende no tengo ese expediente disponible.

Que opinan?

6

Hola Juan Pablo,

Ok, entonces estamos parados en un caso distinto, los logs a revisar sería el docs-apis (de araí documentos) y api-server (de sudocu).

Con respecto a la base de arai docs, seguro estás revisando la tabla nc_proceso_log, eso también ayuda.

Te paso algunas cosas que se me ocurren para probar:

[ol]- Revisar si el expediente al que se quiere incorporar el preventivo existe, se puede hacer con esta consulta en la base SUDOCU:[/ol]

select *
from sudocu.documentos
where id = '5ce220fa-82bb-4974-8152-bedf4525816a'
  • Revisar los logs docs-apis (de araí documentos) y api-server (de sudocu), seguramente encuentres lo mismo que en la tabla nc_proceso_log, quizá del lado del api-server haya mayor detalle
  • Te paso una query para ejecutar en la base de araí docs, a la tabla nc_proceso_log que consultaste, pero que nos puede dar mayor detalle (en el where, si no tenés el uid del documento, lo podés cambiar por el nd.titulo o nd.descripcion
select
	npl.id_proceso_log,
	npl.id_proceso,
	npl.creacion,
	npl.descripcion,
	npl.id_codigo_resultado,
	ncr.descripcion as detalle_codigo_error,
	np.param_id_tramite ,
	np.sudocu_error_id ,
	np.sudocu_error_descripcion ,

	nd.id_documento,
	nd.uid ,
	nd.titulo ,
	nd.descripcion
from
	public.nc_proceso_log npl
join nc_proceso np on
	np.id_proceso = npl.id_proceso
join nc_codigo_resultado ncr on
	ncr.id_codigo_resultado = npl.id_codigo_resultado
join nc_documento nd on
	nd.id_documento = np.id_documento
where
	nd.uid = '<ingresar uid del documento>'
order by
	npl.id_proceso desc ,
	npl.creacion desc
  • Prueba funcional, parece haber un problema con ese expediente, probaría lo siguiente:
    a. Crear un expediente nuevo en sudocu y asegurarse que quede en el Área del usuario que va a registrar el preventivo en pilaga
    b. Crear el preventivo incorporándolo al nuevo nuevo expediente del punto A
    c. Observar resultados

Saludos

7

Hola, en cuento pueda ejecuto eso q me indicas. Igual el expediente existe porque lo veo en sudocu y me lo dio a seleccionar en el alta del preventivo.

Justo le pregunte a Pablo de Gral. Sarmiento que me digo algo de ese error que le devuelve sudocu a arai, y me dice que en el usuario espera el username , y el area no es necesaria porque si no se envia busca el area activa del usuario (por el username).

Por lo que se ve en lo que pase antes, el usuario tiene el valor 1. En nuestro sso mi username no se corresponde con el ID 1 , para mi el 1 ese viene del id del usuario local de pilaga (ya que tengo asociado mi usuario SSO al usuario admin inicial del sistema).

Hay que tener en cuenta que nosotros en pilaga personalizamos la clase de usuario (que nos pasaron uds) para poder matchear usuario local pilaga con usuario saml por el email.

Seguimos

8

Hay que ver en cuanto influye la personalización, en general, la api de sudocu recibe dos usuarios, el de creación y el/los autorizantes, araí no manda el array de los autorizantes, hay que ver ese 1 en dónde lo está mandando.

Tener el resultado de la consulta nos va a ayudar a entenderlo y profundizar el tema, cuando lo tengas adjuntanos los resultados.

Por otro lado, si desde Diaguita la integración funcionó sin problemas, desde pilagá no debería haberlo, por lo menos desde el lado de la personalización de usuarios.

Para mi el tema puede venir por el lado del id del expediente (por eso la prueba con un expediente nuevo). Hemos visto errores de este tipo en entornos de pruebas, donde se cambian bases, restartean entornos y se hacen pruebas atípicas.

Comentanos cómo resulta.

Saludos

9

Facundo, como va!?

Bueno, te cuento que ejecute el primer query que pasaste y buscaba el expediente y no estaba en la base. Rarisimo porque el expediente q habia seleccionado en el preventivo me lo tiraba el sistema… mandinga. Ademas era raro, porque ese expediente que elegí ya tenia los docs que le habia enviado diaguita .

Al ver esto, me fui directamente a crear un nuevo exp en sudocu y un alta de preventivo a ese expediente y FUNCIONO!

Raro lo que sucedio, pero efectivamente algo quedo colgado en algun lugar.

Agradezco tu paciencia y me queda lo que vimos aca para rastrear un futuro error (que espero q no se de!)

Abrazo

10

Juan Pablo, que bueno que era eso.

En nuestra experiencia nos cruzamos con un caso como este en un ambiente de desarrollo, donde luego de levantar todo el ambiente, la base sudocu sufrió un “refresh”, se blanqueó o se tocaron datos a mano.
Entonces para poner un ejemplo, lo que pasé es que:

  • Sudocu tenía el expediente 1/2022
  • Pilaga lo consumió (se queda cacheado el uid del expediente)
  • Sudocu se “refresca/blanquea” la base y se crea de nuevo el expediente 1/2022, a la vista del usuario es el mismo, pero internamente tiene otro uid
  • Pilaga, sigue usando el uid original (porque lo tiene cacheado)

Este caso es muy particular y no debería ocurrir en producción, igual desde pilagá están al tanto de esto y seguramente llegue un fix en próximas versiones.

Si analizan el tema y les parece que tuvo un origen distinto al planteado, te pido nos lo hagan llegar así la analizamos.

Saludos

11

Clarisimo el escenario que indicas y seguro sufrimos lo mismo.
Nosotros hicimos en un momento una limpieza de documentos en sudocu pruebas porque había inconsistencias que causaban errores por todos lados y nadie podía probar.
De ahí debe venir esta situación del cacheo del expediente el pilaga.

Gracias por todo!!

12

Buenos días Juan Pablo,

Tengan en cuenta que si están realizando pruebas que incluyen modificar los datos de cualquiera de las bases de datos (SUDOCU o Pilagá), es necesario que ambas sean restauradas a su origen (estado inicial de prueba), porque el UID que se guardo sigue una trazabilidad, en donde si se renueva una sola de las partes presentará un corte.

Tal cual indico mi compañero es un caso muy particular que en producción no debería pasar.

Estamos a disposición.
Saludos!