Cómo funcionan las integraciones de sistemas

AtroCore Integrations sincroniza datos entre sus sistemas mediante configuración, cada una adaptada a sus necesidades y con funcionamiento garantizado.

Integraciones de sistemas de un vistazo

AtroCore Integrations conecta AtroPIM/AtroCore con cada sistema que almacena o necesita sus datos de producto, ya sea ERP, plataforma de marketplace y comercio electrónico, sistema multicanal y DAM, CMS y DXP, o PLM y PDM. Cada escenario se adapta a su panorama de sistemas. No se requiere programación, solo configuración. Cada integración se implementa de forma individual según sus requisitos específicos y se valida con sus propios datos antes de la puesta en marcha, razón por la cual podemos garantizar una solución que funcione en su entorno. Estos son los aspectos destacados de lo que obtiene:

Intercambio orquestado según su calendario

El intercambio de datos se organiza en Sincronizaciones que se ejecutan manualmente, según una programación basada en cron hasta intervalos de minutos, o de forma basada en eventos cuando un registro se crea, se actualiza o alcanza un estado definido. Cada tipo de dato mantiene su propia cadencia, de modo que los datos maestros se transfieren durante la noche mientras que los precios y el stock se actualizan cada hora.

Cualquier sistema, cualquier método de transporte

Las conexiones se establecen mediante servicios web REST y SOAP, acceso directo a la base de datos o intercambio de archivos a través de SFTP, FTPS, HTTP(S) y recursos compartidos de red, combinando varios métodos cuando resulta útil. Los mismos mecanismos se aplican on-premises, en la nube y en panoramas híbridos, iniciando AtroCore las conexiones salientes, de modo que no es necesario abrir ningún puerto entrante.

Bidireccional y completo en su alcance

Los datos se extraen y envían dentro del mismo escenario, abarcando cada entidad, atributo y relación del sistema, incluidas sus propias entidades y campos personalizados, los valores de atributo por idioma y canal, precios, información de stock y activos digitales con sus metadatos.

Mapeo y transformación sin desarrollo

El mapeo a nivel de campo, los ajustes de formato para CSV, Excel, JSON y XML, los filtros, los tipos de acción, las transformaciones de valores y los scripts opcionales para la preparación de datos son todos configuración en lugar de código, de modo que incluso las estructuras de origen inusuales se gestionan sin un proyecto de desarrollo a medida.

Totalmente transparente para su administración

Todas las configuraciones son visibles y editables en la interfaz de administración, desde la Sincronización hasta el mapeo de un solo campo. La configuración se almacena como datos en lugar de como código, lo que la mantiene a prueba de actualizaciones y permite a su administrador responder a una estructura de origen modificada sin necesidad de un despliegue ni de la intervención de un desarrollador.

Funcionamiento fiable con registro completo

Las cargas delta y la coincidencia de registros basada en claves mantienen las ejecuciones eficientes y repetibles, los Sub-Jobs paralelos mantienen la rapidez con grandes volúmenes de datos, y los reintentos automáticos junto con archivos de errores resuelven la mayoría de los problemas sin trabajo manual. Cada ejecución crea un Job con registro completo, supervisado mediante Widgets de Dashboard y notificaciones de fallos.

Las sincronizaciones orquestan el intercambio de datos

Una Sincronización es la unidad de orquestación de nivel superior. Define qué sistemas están conectados, en qué dirección fluyen los datos y cuándo se ejecuta cada transferencia. Cada Sincronización agrupa los parámetros de conexión, el método de transporte y la lógica de ejecución de un escenario de integración. Nada está codificado de forma rígida y no se requiere ningún producto de middleware independiente.
  • Configurada por nuestro equipo: durante el proyecto de implementación, analizamos las interfaces de sus sistemas, documentamos los endpoints, tablas y formatos de exportación disponibles, y acordamos con usted qué sistema es la fuente principal para cada entidad y cada campo antes de construir el primer Feed.
  • Todo es visible y editable en la administración: todas las configuraciones, desde la Sincronización y su programación hasta el mapeo de un campo individual, se almacenan como datos y se mantienen en la interfaz de administración, donde un administrador con los permisos correspondientes puede consultarlas, ajustarlas y ampliarlas en cualquier momento.
  • Sin middleware adicional: la capa de integración forma parte de la plataforma AtroCore y se ejecuta en el mismo servidor de aplicaciones, por lo que no hay ningún producto ETL o iPaaS independiente que licenciar, alojar y supervisar, ni un segundo lugar donde haya que mantener credenciales y mapeos.
  • Ejecución manual, programada o basada en eventos: una Sincronización se inicia manualmente desde la interfaz de usuario, se ejecuta según una programación basada en cron hasta intervalos de minutos, o se activa automáticamente cuando un registro se crea, se actualiza o alcanza un estado definido (los disparadores basados en eventos requieren el módulo Workflows).
  • Cadencia independiente por tipo de dato: cada Sincronización lleva su propia programación, de modo que los datos maestros de producto se transfieren durante la noche mientras que los precios y los niveles de stock se actualizan cada hora, y los nuevos activos se recogen a medida que llegan.
  • Bidireccional por diseño: los datos se extraen del sistema conectado y se envían a él dentro del mismo escenario de integración, incluidas las entidades personalizadas, los campos personalizados y las relaciones específicas de su negocio.
  • Ejecución basada en colas: cada ejecución se envía a la cola de trabajos y es procesada por workers en segundo plano, de modo que las transferencias nunca bloquean las sesiones interactivas de los usuarios; varias Sincronizaciones se ejecutan de forma concurrente y el rendimiento se escala añadiendo workers y recursos de CPU en lugar de rediseñar la interfaz.

Conectividad, autenticación y topología de red

La capa de transporte se configura por conexión y se adapta a lo que realmente ofrece el sistema del otro extremo, ya sea un servicio web moderno, una base de datos o una entrega de archivos nocturna. Los ajustes de conexión, los endpoints y los parámetros de transporte forman parte de la configuración en la interfaz de administración, de modo que su equipo siempre sabe qué sistema se contacta, cómo y con qué credenciales.
  • Múltiples métodos de transporte: servicios web REST y SOAP, acceso directo a la base de datos (normalmente a través de vistas de solo lectura o un esquema de staging dedicado) e intercambio de archivos por SFTP, FTPS, HTTP(S) o un recurso compartido de red montado. Los métodos se combinan dentro de una misma Sincronización cuando esta es la opción más fiable.
  • Autenticación y gestión de credenciales: se admiten los mecanismos de autenticación habituales de los sistemas empresariales, incluidos la clave API, HTTP Basic y el acceso basado en tokens, con la renovación automática de los tokens que caducan. Las credenciales pertenecen a la conexión y no al Feed individual, de modo que un secreto rotado se cambia en un único lugar.
  • Topología compatible con firewall: AtroCore normalmente inicia la conexión de forma saliente, lo que significa que no es necesario abrir ningún puerto entrante en su red. Cuando el sistema externo tiene que iniciar la conexión, se utiliza nuestra API REST, protegida por un usuario API dedicado, restricciones ACL y, opcionalmente, una lista de IP permitidas, una VPN o peering de red privada.
  • On-premises, en la nube o híbrido: se aplican los mismos mecanismos tanto si AtroCore se ejecuta en su propio centro de datos, en nuestro hosting o en un panorama híbrido con servicios en la nube por un lado y un ERP on-premises por el otro.
  • Resistente frente a los límites del sistema remoto: la paginación y el procesamiento de las respuestas devueltas se configuran por interfaz, junto con los tiempos de espera y los reintentos automáticos, de modo que los límites de frecuencia de la API, las ventanas de procesamiento por lotes y las breves interrupciones del otro lado se gestionan sin intervención manual.
  • Control de acceso y contexto de ejecución: la ejecución y la configuración se rigen por el sistema de roles y permisos, de modo que los operadores inician un Job mientras que solo los administradores designados modifican mapeos, filtros o credenciales. Cada Feed se ejecuta en nombre del sistema o en nombre del usuario que lo inicia, lo que determina los permisos aplicados durante el procesamiento.
  • Validado antes de la puesta en marcha: las Sincronizaciones se construyen y se prueban en una instancia de staging con extractos reales de sus datos y luego se trasladan a producción con los parámetros de conexión intercambiados, de modo que la primera ejecución productiva no es la primera ejecución.

Las sincronizaciones se componen de Feeds de importación y exportación

Los Feeds de importación/exportación son los bloques ejecutables de una Sincronización. Cada Feed define una dirección, un alcance de datos y un formato, y su configuración completa permanece visible y editable en la administración. Una Sincronización agrupa tantos Feeds como requiera el escenario, cada uno con una configuración individual y una posición definida en el orden de ejecución. Aquí es donde se hace visible cuánto de la integración controla su propio equipo.
  • Un Feed por alcance de datos y dirección: una única Sincronización puede contener un Feed de importación para clasificaciones de SAP Business One, un segundo para datos maestros de producto y un Feed de exportación que publica contenido de producto enriquecido en Microsoft Dynamics o en su tienda online.
  • Configuración individual por Feed: el origen y el destino, la definición de endpoint o de archivo, el mapeo, los filtros, el tipo de acción, la validación y la gestión de errores se establecen por Feed, de modo que un cambio en un Feed deja intactos todos los demás y puede probarse de forma aislada.
  • Orden de ejecución determinista: el orden de clasificación dentro de la Sincronización resuelve las dependencias de forma fiable, por ejemplo, importar clasificaciones y atributos antes que los valores de atributo correspondientes, o crear productos antes de que se escriban sus relaciones y asignaciones de activos.
  • Adaptadores con plantillas de configuración: para destinos de integración recurrentes, proporcionamos Adaptadores que encapsulan las definiciones de endpoint, las estructuras de datos y la lógica de procesamiento del sistema externo, añaden tipos de feed dedicados y ofrecen plantillas preconfiguradas para los ajustes de conexión y mapeo, lo que acorta la configuración y elimina una gran clase de errores manuales.
  • Reutilizable y duplicable: un Feed existente se duplica y se adapta en lugar de reconstruirse, lo que mantiene coherentes entre sí escenarios comparables como varios canales de venta, plantas o filiales por país.
  • La configuración es dato, no código: toda la configuración se almacena en la base de datos y se mantiene a través de la interfaz de administración. No hay ninguna interfaz compilada ni ningún core modificado, de modo que las actualizaciones de versión dejan intacta su integración y, cuando un sistema conectado incorpora un campo nuevo, su administrador lo añade al mapeo sin ningún despliegue y sin la intervención de un desarrollador.
  • Open source: al final del proyecto, la configuración se entrega con los mapeos y las programaciones. El código fuente de la plataforma es abierto, de modo que su equipo puede auditar exactamente qué ocurre con sus datos en lugar de confiar en una caja negra.

Cualquier estructura de datos, incluidas sus propias extensiones

Los Feeds no se limitan a un conjunto predefinido de campos. Cada entidad, atributo y relación del sistema puede formar parte de una transferencia, incluido todo lo que usted mismo haya añadido. El alcance de datos de cada Feed se define en la interfaz de administración y se ajusta cada vez que cambia su modelo de datos o un sistema conectado.
  • Cobertura completa de entidades: los Feeds abordan cualquier entidad del sistema, estándar o personalizada, incluidos productos, categorías, clasificaciones, atributos, proveedores y cualquier entidad adicional que requiera su escenario.
  • Valores específicos por idioma y canal: los valores de atributo se transfieren por idioma y por canal, de modo que un catálogo multilingüe y el contenido específico por canal se gestionan en el mismo Feed en lugar de requerir una interfaz independiente por mercado.
  • Relaciones, precios e información de stock: las relaciones de cualquier cardinalidad, los datos de precios y stock y las asignaciones de categoría o clasificación se transfieren junto con los datos maestros a los que pertenecen.
  • Transferencia de activos y binarios: las imágenes, los documentos y otros archivos se importan por URL o desde una ruta del sistema de archivos, procesando los metadatos, los tipos de activo y las asignaciones de producto en la misma ejecución.
  • Campos personalizados sin desarrollo: las entidades y los campos que usted mismo añade en el panel de administración quedan disponibles de inmediato como orígenes y destinos de mapeo en cada Feed, de modo que ampliar el modelo de datos no significa reescribir la interfaz.
  • Mapeo de datos a nivel de campo: las reglas de mapeo se definen por separado para cada campo de entidad y cada atributo, incluidos la columna de origen o ruta de API, el campo de destino, los valores predeterminados, los indicadores de obligatoriedad y el comportamiento ante valores vacíos.
  • El mapeo define el alcance de una escritura: solo se escriben los campos contenidos en el mapeo, de modo que los campos mantenidos en otro sistema o enriquecidos manualmente en AtroCore no se sobrescriben ni se vacían por una importación que no tiene por qué gestionarlos.

Formatos, lógica de transferencia y transformación de datos

Las interfaces reales rara vez entregan los datos en la estructura que espera el sistema de destino. La configuración de un Feed cierra esa brecha sin un proyecto de desarrollo a medida. Los ajustes de formato, el modo de transferencia, los filtros y las transformaciones se configuran por Feed y permanecen totalmente editables en la interfaz de administración.
  • Transferencias completas y delta: las cargas completas se utilizan para la migración inicial y los conjuntos pequeños de datos de referencia, y las cargas delta para la operación diaria, basadas en marcas de tiempo de modificación, indicadores de cambio o la cola de exportación del sistema de origen, lo que mantiene el volumen transferido proporcional a los cambios reales.
  • Coincidencia determinista de registros: los registros se identifican mediante una clave de negocio estable como el SKU, el número de artículo del ERP o un ID externo persistido en el registro de destino, de modo que las ejecuciones repetidas actualizan los datos existentes en lugar de crear duplicados, y una transferencia interrumpida simplemente se repite.
  • Configuración específica por formato: para CSV y Excel, esto abarca el delimitador, el carácter de encierro, la codificación de caracteres, la fila de encabezado, la hoja de cálculo, los separadores decimal y de miles, los formatos de fecha y hora y el delimitador para campos de varios valores. Para JSON y XML, se configuran en su lugar las rutas de nodo relevantes.
  • Conversión consciente del tipo: los valores entrantes se convierten al tipo de dato de destino, lo que abarca unidades de medida, monedas, notaciones booleanas, enumeraciones asignadas a opciones de atributo y formatos de número y fecha específicos de la configuración regional.
  • Tipos de acción flexibles: insertar nuevos registros, actualizar los existentes, insertar y actualizar en una sola pasada, eliminar registros o cualquier combinación de estas acciones, definida por Feed.
  • Filtros avanzados: el conjunto de datos transferido se restringe por valores de campo, por ejemplo, exportar solo productos con estado liberado, solo artículos asignados a un Marketing Channel específico o solo registros modificados desde la ejecución anterior.
  • Transformaciones: las transformaciones se ejecutan antes de que los datos se importen o exporten, y abarcan tablas de asignación de valores, como un código de color del ERP traducido a una opción de atributo, la conversión de unidades y monedas, operaciones de cadena y la concatenación o división de campos.

Procesamiento, gestión de errores y registro completo

Cada ejecución de un Feed crea un Job que documenta qué se transfirió, qué se omitió y qué falló, hasta el nivel del registro y del campo individual. Esta es la parte con la que trabaja su equipo en la operación diaria, y responde a la pregunta de qué ocurrió durante la ejecución de la noche anterior sin conjeturas.
  • Scripts para la preparación y el procesamiento de datos: cuando la configuración estándar no es suficiente, se adjuntan scripts a un Feed de importación o exportación para preparar o procesar los datos antes de importarlos o exportarlos, lo que mantiene la lógica específica de cada caso dentro de la configuración del Feed en lugar de repartirla entre los sistemas conectados.
  • Validación antes de escribir los datos: los campos obligatorios, los tipos de dato, las opciones permitidas y la integridad referencial se comprueban durante el procesamiento, de modo que un registro no válido se rechaza con un mensaje legible en lugar de degradar silenciosamente la calidad de sus datos.
  • Sub-Jobs paralelos: las cargas útiles grandes se dividen automáticamente en Sub-Jobs que los workers de la cola procesan en paralelo, lo que mantiene predecibles los tiempos de ejecución para conjuntos de datos como registros de producto con un elevado número de valores de atributo.
  • Procesamiento de errores optimizado: los fallos transitorios como los tiempos de espera de red o los bloqueos de registro se reintentan automáticamente, un registro con error se aísla en lugar de abortar toda la ejecución, y se puede exportar un archivo de errores que contiene solo las filas rechazadas junto con sus mensajes, corregirlo y volver a importarlo. Los reintentos manuales están disponibles para los Jobs principales y para los Sub-Jobs individuales.
  • Registro completo: cada Job almacena la hora de inicio y de fin, la duración, el usuario o disparador que lo inició, el número de registros creados, actualizados, eliminados, omitidos y fallidos, y entradas por registro con la carga útil de origen y el mensaje resultante.
  • Supervisión y notificación en el Dashboard: los Widgets del Dashboard muestran de un vistazo el estado y el historial de los Jobs recientes, y los fallos se comunican mediante notificación in-app o correo electrónico, de modo que una ejecución fallida se detecta el mismo día en que ocurre y no en la siguiente revisión de datos.
  • Housekeeping y retención: los Jobs, las entradas de registro y los archivos transferidos están sujetos a una retención configurable, lo que mantiene la base de datos compacta y da soporte a los requisitos de protección de datos cuando los datos transferidos contienen información personal.

Por favor, póngase en contacto con nosotros.

human test

FAQ

¿Cómo implementan una integración?

Empezamos analizando las interfaces de los sistemas implicados y documentando qué endpoints, tablas o formatos de exportación están realmente disponibles, y luego acordamos con usted qué sistema es la fuente principal para cada entidad y cada campo. Sobre esa base, configuramos una o varias Sincronizaciones con sus Feeds de importación/exportación, definimos el orden de ejecución, las reglas de mapeo, los filtros y la programación, y validamos todo en una instancia de staging con extractos reales de sus datos antes de trasladarlo a producción.

¿Qué datos se pueden sincronizar?

Cualquier dato que los sistemas implicados puedan proporcionar. Esto abarca datos maestros de producto con valores de atributo por idioma y canal, categorías y clasificaciones, precios y niveles de stock, activos digitales con sus metadatos, proveedores, clientes y pedidos, así como cada entidad y cada campo personalizados que usted mismo haya añadido. Los campos que crea en el panel de administración quedan disponibles de inmediato como orígenes y destinos de mapeo, de modo que ampliar su modelo de datos no significa reconstruir la interfaz.

¿Cómo se sincronizan los datos?

Mediante solicitudes a API REST, SOAP y GraphQL, consultas directas a la base de datos (normalmente contra vistas de solo lectura o un esquema de staging dedicado), o intercambio de archivos por SFTP, FTPS, HTTP(S) y recursos compartidos de red montados. El método más adecuado se selecciona de forma individual para cada caso, y se combinan varios métodos dentro de un mismo escenario cuando esa es la opción más fiable para los sistemas del otro extremo.

¿La sincronización es en tiempo real?

Puede ser casi en tiempo real. Cada Sincronización se ejecuta manualmente, según una programación basada en cron hasta intervalos de minutos, o de forma basada en eventos cuando un registro se crea, se actualiza o alcanza un estado definido, requiriendo los disparadores basados en eventos el módulo Workflows. La mayoría de los proyectos combinan los modos, por ejemplo, una exportación basada en eventos de los productos liberados a la tienda más una ejecución de conciliación nocturna.

¿Necesito middleware adicional para esto?

No. La capa de integración forma parte de la plataforma AtroCore y se ejecuta en el mismo servidor de aplicaciones, por lo que no hay ningún producto ETL o iPaaS independiente que licenciar, alojar y supervisar, ni un segundo lugar donde haya que mantener credenciales y reglas de mapeo.

¿Puedo cambiar las configuraciones más adelante?

Sí. Todas las configuraciones son visibles y editables en la interfaz de administración, desde la Sincronización y su programación hasta el mapeo de un campo individual, y no se requiere programación. Como la configuración se almacena como datos en lugar de en código, su administrador la adapta cuando un sistema conectado añade una columna o cambia un formato, sin ningún despliegue y sin la intervención de un desarrollador.

¿Es la autointegración una opción?

Técnicamente sí, ya que nada está oculto y la plataforma es open source, pero requiere un conocimiento sólido de las interfaces de ambos lados y de la propia configuración de los feeds. Recomendamos que seamos nosotros quienes construyamos y documentemos el escenario inicial y lo entreguemos a su equipo, que luego lo mantiene y lo amplía de forma independiente. Así es como trabaja la mayoría de nuestros clientes; por ejemplo, nosotros conectamos el ERP y ellos añaden por sí mismos más feeds para su tienda y sus marketplaces.

¿Una actualización de AtroCore/AtroPIM romperá mi integración?

No. Sus Sincronizaciones, feeds y reglas de mapeo residen en la base de datos, y no hay ningún core modificado de por medio, de modo que las actualizaciones de versión dejan intacta la configuración de la integración.

¿Funciona esto también si mi ERP está on-premises y AtroCore está alojado?

Sí. Los mismos mecanismos se aplican on-premises, en nuestro hosting y en panoramas híbridos. Qué lado inicia la conexión y qué método de transporte se utiliza son decisiones de configuración que tomamos junto con su equipo de TI durante el proyecto.

¿Cómo se gestionan las credenciales y el acceso a la red?

Las credenciales pertenecen a la conexión y no a un Feed individual, de modo que un secreto rotado se cambia en un único lugar y los tokens que caducan se renuevan automáticamente. AtroCore normalmente inicia las conexiones de forma saliente, lo que significa que no es necesario abrir ningún puerto entrante en su red. Cuando el sistema remoto tiene que iniciar la conexión, el acceso se realiza a través de nuestra API REST, restringida por un usuario API dedicado, reglas ACL y, opcionalmente, una lista de IP permitidas o una VPN. Los derechos de configuración y de ejecución están separados por rol, y cada Feed se ejecuta en nombre del sistema o del usuario que lo inicia.

¿Cuántos datos se pueden transferir y cuánto dura una ejecución?

Las ejecuciones las procesan workers en segundo plano en la cola de trabajos en lugar de en una sesión de usuario, y las cargas útiles grandes se dividen automáticamente en Sub-Jobs que se procesan en paralelo, lo que mantiene predecibles los tiempos de ejecución para catálogos con un elevado número de valores de atributo. El rendimiento escala con el número de workers y los recursos de CPU disponibles. Las transferencias delta basadas en marcas de tiempo de modificación o indicadores de cambio mantienen el volumen diario proporcional a los cambios reales en lugar de al tamaño de su catálogo.

¿Qué ocurre si una ejecución falla o el otro sistema no está disponible?

Los problemas transitorios como los tiempos de espera de red o los bloqueos de registro se reintentan automáticamente, y un registro con error se aísla en lugar de abortar toda la ejecución. Las filas rechazadas se exportan como un archivo de errores junto con sus mensajes, se corrigen y se vuelven a importar, y tanto los Jobs principales como los Sub-Jobs individuales pueden reintentarse manualmente. Como los registros se cotejan mediante una clave de negocio estable como el SKU o un número de artículo del ERP, repetir una ejecución actualiza los datos existentes en lugar de crear duplicados.

¿Puede una importación sobrescribir datos que mantenemos manualmente?

Solo se escriben los campos contenidos en el mapeo, de modo que los valores mantenidos en otro sistema o enriquecidos manualmente en AtroCore no se sobrescriben ni se vacían por una importación que no tiene por qué gestionarlos. Durante el proyecto, definimos por entidad y por campo qué sistema es la fuente principal, que es lo que evita que dos sistemas compitan por el mismo valor.

¿Obtengo registros?

Sí. Cada ejecución de un Feed crea un Job que registra la hora de inicio y de fin, la duración, el usuario o disparador que lo inició y el número de registros creados, actualizados, eliminados, omitidos y fallidos, hasta el nivel de entradas por registro con la carga útil de origen y el mensaje resultante. Los Widgets del Dashboard muestran de un vistazo el estado y el historial de los Jobs recientes, y los fallos se comunican mediante notificación in-app o correo electrónico.

¿Cómo se gestionan los datos personales en los archivos transferidos y en los registros?

Los Jobs, las entradas de registro y los archivos transferidos están sujetos a una retención configurable, de modo que los datos que contienen información personal no se conservan más tiempo del necesario para el análisis de errores y el reprocesamiento. Junto con el acceso basado en roles a los Jobs y las configuraciones, esto da soporte a los deberes de documentación y supresión que le corresponden en virtud del RGPD.

¿Tienes alguna pregunta o te
gustaría recibir una consulta gratuita?