Integraciones: Documento de Errores

“status500, errorteamplace error on “reports” API iInternal Server Error fafapp.base.exceptions.FuntionalException funcional genérica”

Solución: Javi envió mail a Finnegans.

Finnegans había aplicado corrección sobre sus instalaciones. Corrigieron ellos

Órdenes enviadas a Finnegans, llegan con cantidades de insumos en cero “0”

Se envió e-mail a Finnegans con error recibido.

Lo solucionó Finnegans

“{status500,errorteamplace error on 'reports/LABOREOEJECUTADOS' API Internal Server Error faf.app.base.exceptions.FunctionalException funcional genérica”

Se agregaron validaciones en formulario de edición de OTs para no permitir ingresar fechas de confirmaciones inválidas. A su vez, se debe correr un script para corregir las OTs con fechas mal formadas.

“El argumento 1 pasado a Sima/SimaMicoService/Service/Society/SocietyConfigurationServiceCheckSocietyConfigurationValue() debe ser del tipo cadena, nulo dado, invocado en /var/www/monitoreoagricola/src/Kodear/ApiBundle/Service/AplicationOrderService.php en la linea 1379”

Se solucionó con un HOTFIX (consultar a Javi cuál era el origen del problema) @Angel Javier Larrosa

“cURL error 18 transfer closed with outstanding read data remaining (see https//curl.haxx.se/libcurl/c/libcurl-errors.html)”

Fue resuelto del lado de Finnegans

No trae semillas en las ordenes de siembra

Revisando el caso, se verificó que el tipo de insumo para Semilla y otros en el codigo_sima viene null en consecuencia todos los insumos con este tipo no se importaban.

Se envió mail a Albor para resolver esta situación. Adicionalmente en el sistema Albor no hay lugar donde se visualiza el codigo sima asociado al tipo de insumo.

“errorInternal Server Error Error genérico del método prepareSaveFromSerialization de EntidadHLP. \tNo se encontró la Secondary Key asociada, con los valores Tabla BSALabor, campoPK LaborID, campoSk Codigo, valorSk Siembra Girasol Neumatica.,status500}

El cliente debe cambiar el “Tipo de Labor” ya que la actividad “(Siembra) Girasol Neumática”. No existe en Finnegans (probablemente haya sido eliminada previamente a la implementación del enpoint de eliminaciones).

{errors[{Code404,MessageElemento no encontrado,Detailnull}]}

Se envió consulta a ALBOR por parte de Javi, la respuesta: “No está bien configurado, el ambiente de vista alegre. Puntualmente, no tienen bien configurado el parámetro que especifica el tipo de ot que se usa para la integración

Entiendo que deberían verlo o con soporte de albor o su implementador de albor”

No se importan LABOREOS realizados en Finnegans

Respuesta de Gero que consultó a Finnegans: Acabo de reunirme con Finnegans y es una cuestión de configuraciones. En algún lado en configuraciones se definen 2 maneras de trabajar:

1. Con solapa de distribución: Este es el caso, se recomienda y se confirma una única dosis por insumo por lotes en la OT. Resulta que cuando viene a SIMA, no es compatible como lo esperamos en la sección de confirmaciones. SIMA espera confirmar una dosis por lotes haya en la OT. Nos llega 1 dosis para muchos lotes. Conclusión, no se importa.

2. Modo “permite distribución individual”. En este caso, cuando se genera el laboreo, se distribuye el insumo por cada lote que pertenece a la OT, tal como lo espera SIMA. De hecho, esta configuración la desarrollaron para la integración. Conclusión, con esta configuración se logra importar a SIMA.

Debemos hablar con el usuario e indicar que si quiere importar los laboreos a SIMA, debe indicar esta modalidad de trabajo en la configuración.

MENSAJE EN ALBOR: “Los datos no se actualizaron correctamente. Ocurrió un error al momento de sincronizar con SIMA….”

Solucinó ALBOR: Para entender, es un error de conexión de su sistema y no sucede siempre es de vez en cuando, por lo que están analizando de su lado que lo produce o bien cambiar el mensaje para que no nos venga en forma de issue.

“Error internal Sever Error Error genérico del método de preparateSaveFromSerialization de EntidadHLP /t No se encontró la secondary key asociada, con los valores tabla BSOganizacion, campoPK, organizacionID, campoSKcodigo, valor Sk 20 ……, status200”

Este caso, hicieron una edición sobre un código de aplicador. Cambiaron ‘20 20459527 6' por '20204595276’, supuestamente esta acción debería estar bloqueada (edición de código). A su vez, al no estar relacionado por id se pierde la referencia en SIMA.

Acción a realizar, voy a cambiar los ids de aplicadores en las OTs por el nuevo id generado. Eliminar el aplicador anterior y borrar referencia externa.

Nota: Identifiqué que existen aplicadores repetidos de “nombres“ lo que indica otros casos posibles de esta misma situación.

“error” “internal server error: cuando da error en el constructor de una entidadVO clase hijo /n/tjava.sql.SQL EXCEPTION: THE insert ESTATEMENT conflicted with the FOREIGN key constraint /”FKBSALaboreoItem_BSALaboreotrabajo/”. The conflict ocurred in database “/FAF12_EJEMPLAR”/, table, “dbo.BSALaboreoTrabajo”. “Colum laboreoTrabajoID” “satus 500”

Se envió email a Finnegans con el tema en cuestión. (seguimos a la espera de respuesta!)

“Error internal server error genérico del servicio de stock: No hay stock disponible a la fecha xx/xx/xx para el producto xxxx en el depósito xxxx para la partida xxxx. Status500”

En Finnegans hicieron una corrección de los stocks con lo cual se pudo enviar esta OT.

14. “Error internal server error Error Genéricode BSuite / Fecha no permitida.Status500”

Enviamos mail y Json de la OT.

Era una configuración en “Tipo de documento” en Finnegans. Estamos a la espera del instructivo.

👉 Se tuvo otro caso de este error con El Ganado” en donde la fecha estaba bien configurada en Finnegans. La repsuesta de Lorena fue: “Para este caso particular de Grupo El Ganado, se llegó a la conclusión de que es necesario cambiar el nombre de la transacción en SIMA a uno que aún no exista en Finnegans, esto solo en caso de presentar el inconveniente de "Fecha no permitida". De esta forma el sistema acepta la transacción proveniente de SIMA y ya no es necesario cambiar la "fecha de edición" en Finnegans”.

“Status500. errorteamplace error on “reports” API Internal Server Error faf.app.base.esceptions.funcionalException funcional Generica”

innegans hizo cambios sobre el enpoint de asignaciones. Se aplican cambios en SIMA.

Traíamos OTs con lotes/insumos duplicados

Se agregó código para aceptar ediciones sobre OTs que tengan repeticiones de confirmaciones, campañas, formulados.

Luego por sql acomodar ots con duplicados.

https://sima.atlassian.net/wiki/spaces/DEV/pages/2445049861

No tienes permiso para acceder a este elemento

No hubo respuesta, la OT pudo ser enviada, el cliente no volvió a responder.

“Error internal server error Se ha producido un error /t La identificación externa xxxx ya existe para otra transacción. Status500”

Se envio mail a Finnegans por un funcionamiento errático en los enpoints de listado de órdenes de laboreo con filtro de fecha.

Se realizó un fix momentaneo en api a la espera de resolución de finnegans de solución definitiva.

“Error internal Sever Error Error genérico del método de preparateSaveFromSerialization de EntidadHLP /t No se encontró la secondary key asociada, con los valores tabla BSProducto, campoPK, PorductoID, campoSKcodigo, valor Sk 20 “xxxxx” , status500”

No esta implementado el endpoint de eliminación de productos para Finnegans por lo que la eliminación se debe hacer desde base de datos. Eliminar un insumo en Finnegans actualmente no impacta en SIMA.

El insumo fue eliminado por base de datos.

“{errorInternal Server Error Error genérico del método prepareSaveFromSerialization de EntidadHLP. \tNo se encontró la Secondary Key asociada, con los valores Tabla BSALoteActividad, campoPK LoteActividadID, campoSk LoteActividadID, valorSk 394.,status500}”

Campañas duplicadas. Se cambió la campaña asiganada y envió la OT.

Posteriormente se limpiaron las campañas duplicadas.

Para el CS que intente corregir este error cambiando de campañas y asignar su duplicada. Pero le sigue dando error luego.

Tenes en cuenta este dato: no siempre la segunda campaña del listado desplegable es la más nueva y por ende la integrada. A veces no ocurre de esta forma.

La forma de saber cual es la correcta e integrada es consultando el listado de campañas.

Dejo un caso de ejemplo en el video:

“exceptions.internal_error”

“errorInternal Server Error Error generico de BSuite /tFecha no ermitida, status 500”

El cliente debe cambiar laa fecha indicada en un “Tipo de documento” dentro de las configuraciones de Finnegans, solo tiene acceso una persona que tenga un rol con permisos para acceder a esta parte de Finnegans. Estamos a la espera del instructivo.

“La cantidad de has sembradas supera a la cantidad de has asignadas para la asignación soja de primera"

Se corrigieron las hectáreas en la órden o en la campaña, según corresponde. Y se envió la OT.

POST https//go.finneg.com/api/1/teamplace/bridge/LaboreoOrden?access_token=41ea8049-b81d-40c2-b1d9-5e7661decb23` resulted in a `500 Internal Server Error` response {errorInternal Server Error Error genérico del método prepareSaveFromSerialization de EntidadHLP. \tNo se encon (truncated...)

Correr siguiente script en ambiente prod

SET FOREIGN_KEY_CHECKS=0;

UPDATE application_orders set warehouse_id = 3753, date_modified = NOw()
WHERE warehouse_id =1527;

UPDATE application_orders set warehouse_id = 3739, date_modified = NOw()
WHERE warehouse_id =1521;

UPDATE application_orders set warehouse_id = 3651, date_modified = NOw()
WHERE warehouse_id =2045;

UPDATE warehouses set modified_at = NOw(), deleted_at = NOw()
WHERE id IN (1527,1521,2045);

SET FOREIGN_KEY_CHECKS=1;

{errorInternal Server Error Uno de los campos excede el límite de contenido,status500}

Se resuelve el tema limitando a 500 caracteres las observaciones enviadas. Esto implica un recorte en las observaciones aunque al menos la Ot se enviará igualmente. En forma adicional, se envio mail a Finnegans solicitando ampliar el tamaño del campo observaciones.

{errors[{Code404,MessageElemento no encontrado,Detailnull}]}

Se envió consulta a ALBOR:

Respuesta Albor:

“No esta bien configurado, el ambiente de vista alegre. Puntualmente no tienen bien configurado el parámetro que especifica el tipo de ot que se usa para la integración

Entiendo que deberían verlo o con soporte de albor o su implementador de albor”

“errorInternal Server Error Error Partámetro Obligatorio/ Debe especificar el precio para el producto Pulverizaciones”

Resuelto cambiando la configuración desde Finnegans, por el cliente.

Orden de trabajo no configurada con actividad externa

Se debe a que la orden no tiene especificada una labor.

El problema viene por el nombre de la OT. Esta repetido. Se cambia el nombre y la misma se envia ok.

Notice indirect modification of overloaded element of Doctrine\Common\Collections\ArrayCollection has no efect

No se pudo reproducir. Más adelante la OT se envió a Sistema Externo sin inconvenientes.

“No se puede enviar Orden de Trabajo, el sistema externo no acepta área confirmada en con valor = 0”

Open

Sucedía con todos los valores que comienzan con 0. Ya cuando colocabas 1 hectárea, la orden viajaba perfecto. Se corrigió y ahora permite enviar OT cuando la superficie es 0,5, por ejemplo.

“Error en Finnegans - Internal Server Error cuando da un error en el constructor de una EntidadVO clase hijo java.sql.SQLException. The INSERT statement conflicted with the FOREIGN KEY constraint 'FKBSALaboreItem_BSALaboreInsumo'. The conflict occurred in database FAF12_DesarrolloSima, table dbo.BSALaboreInsumo, column 'LaboreInsumoID'.”

Open

Esta OT la creé en Finnegans (OT-DistINDI - 695), con 2 Lotes y 3 insumos. Importé en SIMA y:

• Eliminé uno de los Lotes y agregué otro

• Eliminé uno de los Insumos y agregué otro

• Cambié un insumo por otro

También hice modificaciones en las superficies y dosis en recomendaciones y confirmaciones. Guardé los cambios y envíe a sistema externo y saltó el error.

“Se encontraron cero o mas de un depósito.”

Open

Lo que sucedía en este caso es que el sistema integrado no nos estaba enviando la info cuando se eliminaba/archivaba un deposito, entonces el usuario seguía viendo depósitos que ya no estaban disponibles en el sistema externo. Para resolverlo se generaron los endpoints para consumir esta información de eliminación, y ahora no hay inconsistencias entre varios problemas, el detalle del proceso esta en la issue vinculada.

“{"errors":[{"Code":400,"Message":"Las órdenes de trabajo deben tener al menos un ítem de insumo","Detail":null}]}”

Open

El error descripto en la imagen se da al generar una Orden de Cosecha con un tipo de labor que no se encuentra dentro de los parámetros del Sistema de Albor que lo identifica como de tipo Cosecha. Desde Albor para nuestro ambiente lo resolvieron agregando el tipo de labor en esos parámetros. Sección no accesible por los usuarios en primera instancia. Es una configuración a nivel de entorno.

Desde Albor esta sería la respuesta: “Por lo general, tengo entendido, que los tipos de labores no suele crearlo el cliente, es un implementador de albor que sabe que también tiene que agregarlo en ese parámetro”.

“Cannot use object of type stdClass as array"

Open

Se genera fix en salida de configurations desde el api.

“Too few arguments to function Sima\IntegrationBundle\Service\BaseExternalService::__construct(), 4 passed in /var/www/monitoreoagricola/app/cache/prod/appProdProjectContainer.php on line 5914 and exactly 5 expected”

Open

Se agrega control de sistema de protocolo. En caso de no recibir en el header el parámetro requerido se genera una excepción del tipo EmptySystemHttpException.

“El tipo de labor seleccionada para enviar a Finnegans no se encuentra correctamente integrado. Es posible que no exista en Finnegans.”

Open

Probablemente hayan modificado el código, con lo cual al querer enviar la OT, no encontró la referencia que tenía previamente. No hay mucho para hacer en este caso (siempre quedamos a la espera que Finnegans integre las OTs a través de IDs y no de los códigos, pendiente de su lado)

{"error":"Internal Server Error: Error genérico de BSuiteAgricola \n\tLa fecha del laboreo debe estar comprendida entre las fechas del Lote y Actividad en los items de Distribución.","status":500}

Esto ocurre porque la OT tiene una Fecha de Confirmación posterior/anterior a la de Finalización/Comienzo de la Planificación