Diaguita-Sudocu - No autoriza convocatoria (SOLUCIONADO)

Hola, seguimos con las pruebas de integración.

Cree una SBS, la autorice en huarpe y se autorizo en diaguita.
Luego cree una convocatoria (TS) , le asocie un expediente que cree en sudocu. Cargue todos los datos.
Asocie la SBS al expediente (con el botón correspondiente) y se incorporo correctamente en SUDOCU.
Luego mande a finalizar la convocatoria, genero el documento y lo envio a huarpe para la autorización
En huarpe lo autorice, lo veo en sudocu correctamente autorizado y tb. dentro del expediente correspondiente.

El problema esta que en diaguita, el documento de la convocatoria sigue en estado “Pendiente de Firma” y por ende la convocatoria sigue en pendiente de autorización.

Por lo que parece, la autorización del documento en huarpe no hizo que se actualice el estado de la convocatoria.

Donde puede estar el problema ? Si no se autoriza no puedo continuar con la prueba completa del flujo.

Gracias!

Hola Juan Pablo,

Seguramente el problema está en la notificación que araí documentos le da a Diaguita para avisar que el doc fue autorizado, podés revisar el log del docs-worker para ver si hay algún detalle del problema.

Saludos

Facundo,
Efectivamente en el worker de stack de sudocu se ven errores. los pego a continuación.
No estoy muy empapado en como funciona ese tema , veo que hay errores de “llave duplicada” en documentos_uniq_nro.

[2022-08-03 16:23:47] MAIN.INFO: Corriendo Worker . . . [] []

[2022-08-03 16:23:51] RESTHOOKS.DEBUG: SET search_path TO public

[2022-08-03 16:23:51] RESTHOOKS.DEBUG: Conectado a pgsql:host=XXXXX;port=5432;dbname=arai_documentos_testing;client_encoding=utf-8

[2022-08-03 16:23:51] RESTHOOKS.DEBUG: SELECT topic FROM messages WHERE id=:message {“:message”:226}

[2022-08-03 16:23:51] RESTHOOKS.DEBUG: Procesando endpoint autenticado

[2022-08-03 16:23:51] RESTHOOKS.DEBUG: Procesando retry de mensaje para el endpoint ‘http://api-server:8080/integracion/documentos’

[2022-08-03 16:23:51] RESTHOOKS.DEBUG: SELECT payload FROM messages WHERE id=:message {“:message”:226}

[2022-08-03 16:23:51] RESTHOOKS.INFO: Envío a http://api-server:8080/integracion/documentos {“payload”:{“documento”:{“nro”:{“nro”:124,“anio”:2022,“tipo”:“TSI”},“titulo”:“Convocatoria - TSI:124/2022 - Pliego de condiciones particulares”,“atributos”:,“firmantes”:,“visibilidad”:“privado”,“fecha_cierre”:“2022-08-03 09:48:36.034528-03”,“id_documento”:“f5ddc9e8-7803-4219-9cf9-815d3ba3e1d6”,“id_tipo_uunn”:10103,“palabras_clave”:},“id_usuario”:“juan.pablo.perez”,“id_expediente”:“6d4a2777-1a9c-4839-9168-f5539a560a97”},“user”:“integracion”}

[2022-08-03 16:23:51] RESTHOOKS.WARNING: Error en el envío de [226] a [http://api-server:8080/integracion/documentos] [“Server error: POST http://api-server:8080/integracion/documentos resulted in a 500 Internal Server Error response:\n{"details":null,"stack":"error: llave duplicada viola restricción de unicidad «documentos_uniq_nro»\n Parser.pars (truncated…)\n”]

[2022-08-03 16:23:51] RESTHOOKS.DEBUG: SELECT count(*) AS c FROM requests WHERE message_id=:message AND state <> ‘ACK’ {“:message”:226}

[2022-08-03 16:23:51] RESTHOOKS.DEBUG: SELECT topic FROM messages WHERE id=:message {“:message”:226}

[2022-08-03 16:23:51] 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":"sudocu_asociar"}”,“:listener_name”:“direct”,“:message_id”:226,“:response_status”:500,“:state”:“FAIL”,“:error”:“[object] (GuzzleHttp\Psr7\Stream: {"details":null,"stack":"error: llave duplicada viola restricción de unicidad «documentos_uniq_nro»
Parser.parseErrorMessage (/app/node_modules/pg-protocol/dist/parser.js:287:98)
Parser.handlePacket (/app/node_modules/pg-protocol/dist/parser.js:126:29)
Parser.parse (/app/node_modules/pg-protocol/dist/parser.js:39:38)
Socket. (/app/node_modules/pg-protocol/dist/index.js:11:42)
Socket.emit (events.js:400:28)
","string":"llave duplicada viola restricción de unicidad «documentos_uniq_nro»","clientmessage":"llave duplicada viola restricción de unicidad «documentos_uniq_nro»","url":"/mpc/numeradores/?dir=ASC&offset=0&orden=id_numerador","msg":"error_catch","type":"error","id_err":"9xcz7"})”}

[2022-08-03 16:23:51] RESTHOOKS.DEBUG: SELECT payload FROM messages WHERE id=:message {“:message”:226}

[2022-08-03 16:23:51] RESTHOOKS.DEBUG: SELECT context FROM messages WHERE id=:message {“:message”:226}

[2022-08-03 16:23:51] RESTHOOKS.DEBUG: delivery failure

[2022-08-03 16:23:51] RESTHOOKS.DEBUG: SET search_path TO public

[2022-08-03 16:23:51] RESTHOOKS.DEBUG: Conectado a pgsql:host=XXXXX;port=5432;dbname=arai_documentos_testing;client_encoding=utf-8

[2022-08-03 16:23:51] RESTHOOKS.DEBUG: No se pudo asociar el documento: llave duplicada viola restricción de unicidad «documentos_uniq_nro» [{“tipo”:“sudocu_asociar”,“infoProceso”:{“app_url”:“https://XXXXXX.presi.unlp.edu.ar/SIU-Diaguita/diaguita/rest/v1/notificaciones/documento",“creacion”:"2022-08-03 09:48:36.034528-03”,“id_proceso”:221,“finalizacion”:null,“id_documento”:220,“param_id_area”:null,“sudocu_error_id”:null,“codigo_resultado”:4,“id_proceso_firma”:null,“param_id_tramite”:“6d4a2777-1a9c-4839-9168-f5539a560a97”,“param_id_usuario”:1,“id_proceso_autorizacion”:220,“sudocu_error_descripcion”:null,“app_referencia_interna_json”:“"{\"id\": 5, \"nuevo_estado\": \"AU\", \"id_convocatoria\": 5211}"”},“tipo_notificacion”:“VINCULADO”}]

[2022-08-03 16:23:51] NUCLEO.DEBUG: SET search_path TO public

[2022-08-03 16:23:51] NUCLEO.DEBUG: Conectado a pgsql:host=XXXXXX;port=5432;dbname=arai_documentos_testing;client_encoding=UTF8

[2022-08-03 16:23:51] NUCLEO.DEBUG: UPDATE nc_proceso
SET id_codigo_resultado = ‘-60’
WHERE id_proceso = ‘221’

[2022-08-03 16:23:51] NUCLEO.DEBUG: Query en SIU\DocsNucleo\Dao\ProcesoDao::registrarLogProceso

[2022-08-03 16:23:51] NUCLEO.DEBUG: INSERT INTO nc_proceso_log (id_proceso, id_codigo_resultado, descripcion, creacion, detalle)
VALUES (‘221’,‘-60’, ‘Fallo en proceso de asociación. 500’, NOW(), ‘llave duplicada viola restricción de unicidad «documentos_uniq_nro»’)
RETURNING id_proceso_log;

[2022-08-03 16:23:51] NUCLEO.DEBUG: Query en SIU\DocsNucleo\Dao\ProcesoDao::updateErrorProceso

[2022-08-03 16:23:51] NUCLEO.DEBUG: UPDATE nc_proceso
SET id_proceso=id_proceso, sudocu_error_id = ‘500’, sudocu_error_descripcion = ‘llave duplicada viola restricción de unicidad «documentos_uniq_nro»’
WHERE id_proceso = ‘221’

[2022-08-03 16:23:51] MAIN.ERROR: Error asociando un documento a un tramite {“arai-documentos-id”:220,“arai-documentos-id-proceso”:221,“tramite”:“6d4a2777-1a9c-4839-9168-f5539a560a97”,“error”:“llave duplicada viola restricción de unicidad «documentos_uniq_nro»”}

[2022-08-03 16:23:51] MAIN.DEBUG: Evaluando finalizacion del proceso {“arai-documentos-id”:220,“arai-documentos-id-proceso”:221}

[2022-08-03 16:23:51] NUCLEO.DEBUG: Query en SIU\DocsNucleo\Dao\ProcesoAutorizacionDao::findProcesoAutorizacionByIdProceso

[2022-08-03 16:23:51] NUCLEO.DEBUG: SELECT apa.id_proceso_autorizacion,
apa.id_documento,
apa.parametros_json,
apa.id_estado_proceso_autorizacion,
aepa.descripcion as estado_proceso_autorizacion,
apa.id_modelo_autorizacion,
ama.descripcion as modelo_autorizacion
FROM au_proceso_autorizacion apa
INNER JOIN au_estado_proceso_autorizacion aepa ON apa.id_estado_proceso_autorizacion = aepa.id_estado_proceso_autorizacion
INNER JOIN au_modelo_autorizacion ama ON apa.id_modelo_autorizacion = ama.id_modelo_autorizacion
WHERE apa.id_proceso = ‘221’
ORDER BY 1 DESC
LIMIT 1

[2022-08-03 16:23:51] MAIN.INFO: Finalizando proceso: {“arai-documentos-id-proceso”:221}

[2022-08-03 16:23:51] NUCLEO.DEBUG: UPDATE nc_proceso
SET id_codigo_resultado = ‘-60’,
finalizacion = now()
WHERE id_proceso = ‘221’

[2022-08-03 16:23:51] NUCLEO.DEBUG: Query en SIU\DocsNucleo\Dao\ProcesoDao::registrarLogProceso

[2022-08-03 16:23:51] NUCLEO.DEBUG: INSERT INTO nc_proceso_log (id_proceso, id_codigo_resultado, descripcion, creacion, detalle)
VALUES (‘221’,‘-60’, ‘Se finaliza el proceso: 221’, NOW(), ‘llave duplicada viola restricción de unicidad «documentos_uniq_nro»’)
RETURNING id_proceso_log;

[2022-08-03 16:23:51] NUCLEO.DEBUG: Query en SIU\DocsNucleo\Dao\ProcesoDao::getDescripcionCodigo

[2022-08-03 16:23:51] NUCLEO.DEBUG: SELECT descripcion
FROM nc_codigo_resultado
WHERE id_codigo_resultado = ‘-60’
LIMIT 1

[2022-08-03 16:23:51] NUCLEO.DEBUG: Query en SIU\DocsNucleo\Dao\DocumentoDao::findById

[2022-08-03 16:23:51] NUCLEO.DEBUG: SELECT ncd.id_documento,
ncd.uid,
ncd.app_identificacion_json,
ncd.creacion,
ncd.titulo,
ncd.descripcion,
ncd.id_usuario_sso,
nus.usuario_sso,
ncd.id_instalacion,
ncd.origen_numeracion,
ncd.id_repositorio,
ncd.repositorio,
ncd.autorizado,
ncd.metadata_repositorio_json,
ncd.metadata_tipo,
ncd.tipo_visible,
ncd.nro_visible,
ntd.id_tipo_documento,
ntd.id_nivel_autorizacion,
ntd.descripcion as tipo_documento
FROM nc_documento ncd
INNER JOIN nc_tipo_documento ntd ON (ncd.id_tipo_documento = ntd.id_tipo_documento)
INNER JOIN nc_usuario_sso nus ON (ncd.id_usuario_sso = nus.id_usuario_sso)
WHERE ncd.id_documento = ‘220’
LIMIT 1

[2022-08-03 16:23:51] NUCLEO.DEBUG: Query en SIU\DocsNucleo\Dao\ProcesoAutorizacionDao::getInfoRechazoProcesoAutorizacion

[2022-08-03 16:23:51] NUCLEO.DEBUG: SELECT nus.usuario_sso, nus.cache_email AS email, cambio_estado AS fecha_rechazo, asale.nota_rechazo
FROM au_solicitud_autorizacion asa
INNER JOIN au_solicitud_autorizacion_log_estado asale
ON asa.id_solicitud_autorizacion = asale.id_solicitud_autorizacion
INNER JOIN nc_usuario_sso nus ON asa.id_usuario_sso = nus.id_usuario_sso
INNER JOIN au_proceso_autorizacion apa ON asa.id_proceso_autorizacion = apa.id_proceso_autorizacion
INNER JOIN nc_documento nd ON apa.id_documento = nd.id_documento
WHERE asale.id_estado_solicitud_autorizacion = 3
AND nd.id_documento = ‘220’;

[2022-08-03 16:23:51] NUCLEO.DEBUG: INSERT INTO nc_notificacion (id_proceso, respuesta)
VALUES (‘221’, ‘{“estado_codigo”:-60,“estado_descripcion”:“Fallo el proceso de asociacion”,“referencia_interna”:“{"id": 5, "nuevo_estado": "AU", "id_convocatoria": 5211}”,“nro”:{“tipo_visible”:null,“nro_visible”:null,“metadata_tipo”:null},“uid_documento”:“f5ddc9e8-7803-4219-9cf9-815d3ba3e1d6”,“info_rechazo”:null}’)
RETURNING uid;

[2022-08-03 16:23:51] NUCLEO.ERROR: Error al crear notificacion: SQL ERROR: SQLSTATE[22P02]: Invalid text representation: 7 ERROR: sintaxis de entrada no válida para tipo json
LINE 2: VALUES (‘221’, ‘{“estado_cod…
^
DETAIL: El elemento «id» no es válido.
CONTEXT: Datos JSON, línea 1: …proceso de asociacion”,“referencia_interna”:“{“id…
INSERT INTO nc_notificacion (id_proceso, respuesta)
VALUES (‘221’, '{“estado_codigo”:-60,“estado_descripcion”:“Fallo el proceso de asociacion”,“referencia_interna”:”{"id": 5, "nuevo_estado": "AU", "id_convocatoria": 5211}”,“nro”:{“tipo_visible”:null,“nro_visible”:null,“metadata_tipo”:null},“uid_documento”:“f5ddc9e8-7803-4219-9cf9-815d3ba3e1d6”,“info_rechazo”:null}’)
RETURNING uid; {“error-class”:“SIU\TobaDb\ErrorDb”}

string(45) “SIU\DocsNucleo\Exceptions\DocsNucleoException”
[2022-08-03 16:23:51] MAIN.ERROR: Exception Class: SIU\DocsNucleo\Exceptions\DocsNucleoException - Message: Error al crear notificacion

PHP Fatal error: Uncaught SIU\DocsNucleo\Exceptions\DocsNucleoException: Error al crear notificacion in /usr/local/app/src/SIU/DocsNucleo/DocsNucleo.php:414
Stack trace:
#0 /usr/local/app/src/SIU/DocsApi/Controladores/NotificacionesController.php(109): SIU\DocsNucleo\DocsNucleo->crearNotificacion(Array, 221)
#1 /usr/local/app/src/SIU/DocsApi/Service/Proceso.php(239): SIU\DocsApi\Controladores\NotificacionesController->enviar(Object(SIU\DocsNucleo\Entities\Proceso), ‘ERROR’)
#2 /usr/local/app/src/SIU/DocsApi/Service/Proceso.php(103): SIU\DocsApi\Service\Proceso->notificarAplicacionOrigen(Object(SIU\DocsNucleo\Entities\Proceso), ‘ERROR’)
#3 /usr/local/app/src/SIU/DocsApi/Service/Proceso.php(231): SIU\DocsApi\Service\Proceso->finalizar(Object(SIU\DocsNucleo\Entities\Proceso), ‘ERROR’)
#4 /usr/local/app/src/SIU/DocsApi/Service/Proceso.php(167): SIU\DocsApi\Service\Proceso->registrarFinProcesoAsociacion(Object(SIU\DocsNucleo\Entities\Proceso))
#5 /usr/local/app/src/SIU/DocsApi/Factory.php(298): SIU\DocsApi\Service\Proceso->avanzar in /usr/local/app/src/SIU/DocsNucleo/DocsNucleo.php on line 414

Hola Juan Pablo,

Si efectivamente como se puede ver en el log, hubo un error al intentar asociar el documento a un expediente de sudocu.
Desde Diaguita se esta enviando un documento de la convocatoria TSI:124/2022, y por lo visto en Sudocu ya existe un documento del tipo TSI con número 124/2022.
Esto puede deberse a que esa base de datos de sudocu ya tenia datos de pruebas anteriores.
A raiz de este problema es que finalmente falló el envío de la notificación de Arai-Documentos a Diaguita, y por lo tanto en Diaguita no cambio de estado ni el documento ni el tramite.

Para continuar con las pruebas podrían verificar los datos que hay en esa instalación de Sudocu para evitar estos problemas de nros duplicados.

Saludos.

Hola!
Hace poco limpiamos todo sudocu y arai-docs que usamos para las pruebas. No hay documentos del tipo TSI porque soy el único que esta probando este tema.
El tema es que si se envió la TSI a sudocu y si se asocio correctamente al expediente que se le puso a la convocatoria, los puedo ver aprobados en SUDOCU y metido al expediente (junto a la SBS). Eso es lo raro.

Juan Pablo,

Si no existieran documentos en sudocu es raro tener ese error.
Podes verla la fecha y hora de asociación en sudocu para saber en que momento fue la vinculación exitosa?

En el log del worker podrías ver hacia atrás para intentar encontrar el pto donde se lo pudo vincular? se deberían ver los mensajes de asociación exitosa en sudocu.

En sudocu, el detalle de los docs del expediente:

03-08-2022 09:49 Trámite Simplificado 124 / 2022 Convocatoria - TSI:124/2022 - Pliego de condiciones particulares
03-08-2022 09:46 Solicitud de Bienes y Servicios 517 / 2022 Solicitud de bienes y servicios - SBS:517/2022 - Solicitud

En los logs de los workes solo veo cosas de hoy. Voy a ver si con otro técnico que la tiene clara con docker es posible ver logs de ayer

Finalmente no pudimos obtener los logs del dia anterior, asi que arranque de nuevo.

Cree una SBS nueva (518) y la autorice.
Cree un TS nuevo (125) , le asocie la SBS 518 con la opción correspondiente y mande a autorizar el TS (quedo en estado Firmado y publicado )
Autorizo en huarpe, el doc del TS queda aprobado y se asocia al expediente en sudocu (al igual que la sbs) pero la convocatoria queda pendiente de firma nuevamente.
Ahora saque los logs inmediatamente del worker de documentos de arai y lo adjunto.

En sudocu, la info de los docs asociados al expediente es:

06-08-2022 17:45 Trámite Simplificado 125 / 2022 Convocatoria - TSI:125/2022 - Pliego de condiciones particulares
06-08-2022 17:43 Solicitud de Bienes y Servicios 518 / 2022 Solicitud de bienes y servicios - SBS:518/2022 - Solicitud

log-docs-workers-error-diaguita.txt (113 KB)

Agrego que me meti por base a SUDOCU y borre las relaciones de los TSI a sus expedientes , a ver si los intentaba meter nuevamente y se destrababa esos errores de los workers , pero tampoco se acomoda y siguen los mismos errores en los workers de docs.

Bueno, segui haciendo pruebas para ver de donde puede venir lo que sucede.
Lo que hice fue ver en sudocu que TSI habia:

sudocu_testing=# select id, titulo, nro, numero_asignado from sudocu.documentos where id_tipo = 10103; -[ RECORD 1 ]---+------------------------------------------------------------------------------ id | 6a3c87d9-5012-4db4-8f92-ac0efdf20df1 titulo | Convocatoria - TSI:125/2022 - Pliego de condiciones particulares nro | {"nro": 125, "anio": 2022, "tipo": "TSI", "numero_asignado": " 125 / 2022 "} numero_asignado | -[ RECORD 2 ]---+------------------------------------------------------------------------------ id | 4b7d1ab2-44de-4589-9af3-131ed8e2973d titulo | Convocatoria - TSI:124/2022 - Pliego de condiciones particulares nro | {"nro": 124, "anio": 2022, "tipo": "TSI", "numero_asignado": " 124 / 2022 "} numero_asignado |

Me llamo que la columna numero_asignado estuviera vacia, asi que le puse el valor que tenia nro->numero_asignado . Y tampoco destraba.

Luego probe cambiando directamente ese numero asiganado (en ambos lugares) agregandole “TSI” al inicio:

sudocu_testing=# select id, titulo, nro, numero_asignado from sudocu.documentos where id_tipo = 10103; -[ RECORD 1 ]---+---------------------------------------------------------------------------------- id | 6a3c87d9-5012-4db4-8f92-ac0efdf20df1 titulo | Convocatoria - TSI:125/2022 - Pliego de condiciones particulares nro | {"nro": 125, "anio": 2022, "tipo": "TSI", "numero_asignado": " TSI 125 / 2022 "} numero_asignado | TSI - 125 / 2022 -[ RECORD 2 ]---+---------------------------------------------------------------------------------- id | 4b7d1ab2-44de-4589-9af3-131ed8e2973d titulo | Convocatoria - TSI:124/2022 - Pliego de condiciones particulares nro | {"nro": 124, "anio": 2022, "tipo": "TSI", "numero_asignado": "TSI - 124 / 2022"} numero_asignado | TSI - 124 / 2022

y ahi parecia que los workers esos que tiraban errores hicieron algo y me volvio a crear 2 documentos TSI (124 y 125) y que ademas los metió en los expedientes correspondientes:

sudocu_testing=# select id, titulo, nro, numero_asignado from sudocu.documentos where id_tipo = 10103; -[ RECORD 1 ]---+---------------------------------------------------------------------------------- id | 6a3c87d9-5012-4db4-8f92-ac0efdf20df1 titulo | Convocatoria - TSI:125/2022 - Pliego de condiciones particulares nro | {"nro": 125, "anio": 2022, "tipo": "TSI", "numero_asignado": "TSI - 125 / 2022"} numero_asignado | TSI - 125 / 2022 -[ RECORD 2 ]---+---------------------------------------------------------------------------------- id | 4b7d1ab2-44de-4589-9af3-131ed8e2973d titulo | Convocatoria - TSI:124/2022 - Pliego de condiciones particulares nro | {"nro": 124, "anio": 2022, "tipo": "TSI", "numero_asignado": "TSI - 124 / 2022"} numero_asignado | TSI - 124 / 2022 -[ RECORD 3 ]---+---------------------------------------------------------------------------------- id | f96eaffe-04fe-4df0-8e87-da0f25b734e5 titulo | Convocatoria - TSI:124/2022 - Pliego de condiciones particulares nro | {"nro": 124, "anio": 2022, "tipo": "TSI", "numero_asignado": " 124 / 2022 "} numero_asignado | -[ RECORD 4 ]---+---------------------------------------------------------------------------------- id | 207a7cc3-04b5-4223-841b-1bc156f1e38f titulo | Convocatoria - TSI:125/2022 - Pliego de condiciones particulares nro | {"nro": 125, "anio": 2022, "tipo": "TSI", "numero_asignado": " 125 / 2022 "} numero_asignado |

Aún así, las convocatorias no se autorizaron y siguen en “Pendiente de firma” los documentos de las TSI (aunque en sudocu veo todo autorizado) y vuelvo a mirar los logs de los workers y siguen saltando los mismos errores.

No se donde puede venir el tema

Hola Juan Pablo,

Estuve revisando toda la información que pasaste.
Nuevamente en los logs se ven errores que el nro de documento ya existe en sudocu, pero también veo un error en arai-documentos al intentar almacenar el registro de la notificación que se enviaría a Diaguita.
El error por lo que se puede ver es por la sintaxis de un json.
La query por lo que veo seria valida, pero estimo que podría dar un error por la configuración del standard_conforming_strings de postgres.

Podrías ejecutar sobre el postgres donde se encuentra la base de Arai Documentos esta query: SHOW standard_conforming_strings;
Si el resultado es OFF, podrías ponerlo en ON con la query: SET standard_conforming_strings = on;
Luego de esto podrías volver a realizar una prueba?

Si el valor del standard_conforming_strings estaba en OFF y tienen otras bases de datos en ese mismo cluster postgres, creo que se debería evaluar si podría tener impacto el cambio de config en esas otras bases y deberían aplicarlo solo sobre la DB que corresponde.
Si efectivamente el valor estaba en OFF, creo que el problema que ocurre es que esta fallando el registro en arai-docs de la vinculación exitosa en sudocu y se intenta volver a vincular por 2da vez, generando el error de numero duplicado. También por este motivo, falla la notificación que se debería enviar a Diaguita para informar el cambio de estado.

Saludos.

Pablo, efectivamente esta en OFF. Tanto en el cluster de testing como en el de producción.
Ahí hablaba con el DBA y tenemos otras bases en ese testing (y prod tb) como la de G3 ,etc.
No se el impacto que puede tener con otros sistemas, porque me dicen que esta en OFF explicitamente.
Sabes de otras solucioens SIU que lo requieran? Sino vamos a tener que ver de levantar cluster nuevo para esto

Gracias!

Hola,

estaba haciendo memoria y eso está en off porque en alguna versión de G3 lo requería. Googleando y mirando el sitio, llegué a esto:

https://documentacion.siu.edu.ar/wiki/SIU-Guarani/version3.18.0/instalacion_desde_cero/requisitos_previos/linux

Entiendo que la versión 3.20 no lo requiere más según la documentación. Puede ser? Si es así, lo pasamos a on y reiniciamos el servicio en algún momento que se pueda.

Saludos
Alejandro

Juan Pablo / Alejando

Si, hay otros módulos SIU que en algún momento lo requerían en OFF. Como por ejemplo Guarani y Pilaga.
Desconozco si aun lo requieren obligatoriamente en OFF o no, voy a realizar la consulta a los equipos para tener mas información.

Saludos.

Pablo,

Te cuento que lo que hice fue borrar las entradas de la tabla queue (de arai-documentos) que estaban referidas a estas notificaciones colgadas, porque se estaba trabando la prueba de sudocu y no se podia autorizar desde sudocu que es lo que necesitan otros usuarios que prueban para incorporarse.

Cuando tengamos una prueba con el cambio de ese parametro al PG intentare de nuevo la integración con diaguita.

Gracias!

Pablo,

cuando puedas confirmarnos que ninguna aplicación SIU requiere el valor standard_conforming_strings en off confirmanos! Yo estuve Googleando y browseando los sitios de SIU y no parece ser necesario ahora.

saludos
Alejandro

Pablo,

Te cuento que el DBA puso el parámetro en ON en el pg (solo para la base de datos, no para todo el motor) y realice la prueba nuevamente (antes chequeamos que al conectarnos no de ON al consultar dicho parámetro).

Cree otra SBS y autorice (519).
Cree la convocatoria (TSI 126) , le asocie la SBS. Mande la SBS al expediente (uno nuevo) y se asocio bien.
Mande a autorizar el TSI, lo hice en huarpe. Me la asocio al expediente pero en diaguita siguió en “Pendiente de firma” y la convocatoria en “Pendiente de autorización”.

En el expediente los docs asociados:
09-08-2022 11:22 Trámite Simplificado 126 / 2022 Convocatoria - TSI:126/2022 - Pliego de condiciones particulares
09-08-2022 11:21 Trámite Simplificado - Anexo 126 / 2022 Convocatoria - TSI:126/2022 - Anexo convocatoria
09-08-2022 11:20 Solicitud de Bienes y Servicios 519 / 2022 Solicitud de bienes y servicios - SBS:519/2022 - Solicitud
09-08-2022 11:20 Solicitud de Bienes y Servicios - Anexo - Anexo 519 / 2022 Solicitud de bienes y servicios - SBS:519/2022 - Anexo

En los logs parece haber desaparecido el error que marcabas en relación al parámetro que cambiamos, pero sigue saliendo el error de que esta duplicado (ajunto archivo de log nuevamente).

Lo que si me llama la atención en esta oportunidad es que en la tabla queue (arai-docs) no quedaron entradas colgadas como había pasado antes y que nos bloqueaban luego las notificaciones de autorización de sudocu a otros documentos.

Aguardamos mas instrucciones a ver como seguir con este tema.

Abrazo

log-docs-workers-error-diaguita-2.txt (168 KB)

Segui chusmenado un poco la base de ara-docs y encontré esto:

En la tabla nc_notificacion veo lo siguiente:

403 | 41aa4e42-8fe1-4331-bd8c-1e9751df1249 | 414 | {"nro": {"nro_visible": null, "tipo_visible": null, "metadata_tipo": null }, "autorizado": true, "autorizacion": [{"tipo": "basica", "usuario_sso": "juan.pablo.perez", "fecha_autorizado": "2022-08-09 11:09:51.228981-03 "}], "estado_codigo": 22, "uid_documento": "82d87b24-4d9b-4850-b3dd-ac6bf030e606", "tramite_asociado": "91572061-30b7-4cdf-aac0-296cbef5fd4e", " estado_descripcion": "El documento fue Autorizado y Asociado", "referencia_interna": {"id": 8}} | 2022-08-09 11:20:19.725255-03 | 2022-08-09 11: 20:19.713039-03 402 | 3c276e1a-22fd-4ca8-850a-566d2958735d | 413 | {"nro": {"nro_visible": null, "tipo_visible": null, "metadata_tipo": null }, "autorizado": true, "autorizacion": [{"tipo": "basica", "usuario_sso": "juan.pablo.perez", "fecha_autorizado": "2022-08-09 11:10:02.993854-03 "}], "estado_codigo": 22, "uid_documento": "29d87258-4e47-4253-b8d4-b3631de55a19", "tramite_asociado": "91572061-30b7-4cdf-aac0-296cbef5fd4e", " estado_descripcion": "El documento fue Autorizado y Asociado", "referencia_interna": {"id": 9}} | 2022-08-09 11:20:19.426635-03 | 2022-08-09 11: 20:19.46167-03

Que dice que se autorizo y asocio. El tramite_asociado = “91572061-30b7-4cdf-aac0-296cbef5fd4e” si corresponde al expediente en cuestión en sudocu, pero “uid_documento” = “29d87258-4e47-4253-b8d4-b3631de55a19” no corresponde a algun documento en sudocu.

Hola Alejandro / Juan Pablo,

Despues de consultar a los distintos equipos, les confirmo que si bien Guaraní lo requería en OFF, desde la versión 3.19.0 ya no lo requiere mas y se puede utilizar en ON.
Sin embargo Pilaga aun solicita que el valor se encuentre en OFF.

Saludos.

Genial,
gracias por confirmar.

Por suerte PILAGA si esta en otra instalación de PG por lo que no nos afectaria.
Saludos!