Integrar sin API de origen: planificar una entrega CSV
Un archivo exportado puede ayudar si falta la API de origen necesaria. Un ejemplo define formato, relación de proyectos, repetición y confirmación.
Elegir una vía de entrega disponible
Compruebe primero si los datos necesarios pueden obtenerse mediante una exportación admitida. El middleware, software intermediario entre sistemas, procesa esas entradas; no crea un acceso que el origen no ofrece.
Entrada disponible | Capacidad del destino | Entrega posible |
|---|---|---|
Archivo de exportación estructurado | Importación de archivo adecuada | Generar un archivo de importación comprobado |
Archivo de exportación estructurado | API adecuada | Comprobar y relacionar los datos, después transferir por API |
Solo interfaz de usuario | Pantalla de entrada adecuada | Evaluar aparte el flujo en pantalla |
La última opción requiere reconocer con fiabilidad los elementos utilizados y el resultado. Microsoft describe para ello los selectores de interfaz. Tras cambios en la interfaz debe comprobarse su idoneidad; una secuencia de clics grabada no demuestra por sí sola que los datos se hayan aceptado.
Registrar un contrato de archivo con datos concretos
Una empresa de software ficticia elige la segunda opción. Su antiguo control horario no tiene API para los tiempos aprobados, pero ofrece una exportación diaria. Un procesamiento intermedio debe usar esos datos para añadir una línea a un borrador de facturación en el ERP. En este ejemplo propio se acuerdan UTF-8, la coma como separador y esta cabecera:
entryId,projectRef,approvedMinutes,approvalState
T-81,PR-42,90,approvedLa fila indica que el registro estable de origen T-81 contiene tiempo de trabajo aprobado en minutos para el proyecto PR-42. Este se relaciona expresamente con el proyecto ERP ERP-903. Solo pueden continuar las filas aprobadas. Campos e identificadores son un diseño propio, no un esquema de Odoo u otro proveedor. RFC 4180 describe convenciones CSV; el contrato de importación concreto debe encajar con el producto. La documentación de Odoo muestra, por ejemplo, cómo usar identificadores externos en importaciones y relaciones.
Separar los resultados confirmados de los inciertos
Para una transferencia confirmada, el procesamiento intermedio debe vincular el registro de origen con la referencia del destino. Una fila sin cambios cuya aceptación ya esté confirmada no debe crear otra línea de borrador. Si ese registro cambia después, es una corrección de negocio; el diseño elegido la retiene para aclaración.
Si se corta la conexión después del envío, el destino puede haber escrito ya los datos. Antes de reintentar debe aclararse el estado mediante una referencia de destino adecuada. Si el destino no permite comprobarlo, la operación sigue siendo incierta y requiere atención. El transporte correcto del archivo no confirma por sí solo un registro en el ERP.
Acordar los resultados esperados antes de implementar
Estos casos deberían validarse en un entorno de prueba adecuado:
La primera fila aprobada crea una línea de borrador de
90minutos en el proyecto relacionado.Una repetición idéntica tras confirmar el éxito no crea otra línea.
Una referencia de proyecto desconocida queda abierta con un motivo de aclaración.
El mismo registro con
120minutos se retiene como corrección, sin sobrescribir silenciosamente el valor confirmado.
En el ejemplo, el equipo acepta un procesamiento diario a las 18:00, en la zona horaria Europe/Berlin, para borradores de facturación posteriores. Si necesita valores actuales durante la jornada, debe reevaluarse la entrega. Por eso la responsabilidad de exportación, la gestión de errores y la confirmación forman parte del acuerdo.
Fuentes
Seguir leyendo
Todos los artículos
APIs e integración con ASES
ERP, CRM y tienda bien conectados