Telar DataFabric: el tejido que une todos tus sistemas
ERP, e-commerce, WMS y CRM dejan de ser islas: Telar los extrae, los normaliza en entidades tipadas y los deja disponibles —en un mismo lugar, aislados por organización— para todo lo que corre encima. Es la capa de integración de la que se alimenta el resto del ecosistema: las fuentes de datos de Luma, y la vía por la que los agentes de Senda ejecutan tareas y obtienen datos.
Parte de Telar Suite — junto a Senda, Tramia, Runa, Signa y Luma.
Se apoya y se integra con
Tecnologías y estándares sobre los que corre o con los que se integra la plataforma. No son logos de clientes.
Por qué existe Telar
El problema nunca es que falten datos: es que viven en seis sistemas que no se hablan, y cada integración nueva se cotiza como un proyecto. Telar convierte esa fricción en configuración.
Integrar sin desplegar código
Un conector es un contrato JSON: origen, autenticación, parámetros y destino. Sumar un sistema nuevo no abre un ciclo de desarrollo, deploy y regresión — se configura, se prueba y se activa.
Estructura de datos sin migraciones
Las entidades dinámicas crean la tabla que falta al momento, con campos tipados, claves y relaciones. La estructura del dato deja de depender de la próxima ventana de release.
Flujos que se auditan solos
Cada flujo se programa por CRON y deja registro de cada ejecución y de cada paso: qué corrió, cuánto tardó, con qué conector y con qué resultado. Cuando algo falla, no hay que reconstruir la historia a mano.
Credenciales fuera del alcance
Ninguna clave vive en la configuración: el conector guarda el nombre del secreto y su proveedor, y el valor se resuelve contra la bóveda en tiempo de ejecución. Rotar un token no toca el conector.
Datos que la IA entiende
Cada entidad, cada campo y cada relación llevan descripción semántica. Cuando un agente de Senda consulta el tejido de datos, no recibe columnas anónimas: recibe significado, y con eso puede accionar sobre tu operación.
Aislamiento por organización
Conectores, entidades, flujos, secretos y base de conocimiento están vinculados a una organización y a un contexto. El aislamiento multi-tenant es parte del modelo de datos, no una capa de permisos agregada después.
De sistema aislado a dato disponible, en cuatro pasos
Modelás el destino
Se crea la entidad dinámica que va a recibir los datos: nombre, carpeta, campos tipados, clave primaria, relaciones y permisos de lectura/escritura. Sin migraciones ni despliegue.
Configurás el conector
Se declara el origen (URL, método, headers, parámetros, autenticación) y el destino (entidad y política de carga: incremental o purga previa). Las credenciales se referencian por nombre de secreto, nunca por valor.
Armás el flujo y lo programás
Los conectores se encadenan como pasos ordenados de un flujo —primero el token, después el maestro, después el movimiento— y el flujo se programa con una expresión CRON y un rango de vigencia.
Operás y consumís
Cada corrida queda registrada paso a paso; una falla emite un evento que avisa a los administradores. Desde ahí, el dato queda disponible por API, para los informes de Luma y para los agentes de Senda que necesiten leerlo o accionar sobre él.
La capa de la que se alimenta todo el ecosistema
Telar no es una herramienta más al costado de las otras: es el piso sobre el que corren. Cada plataforma de Telar Suite toma de acá los datos que necesita, y ninguna vuelve a integrarse contra tus sistemas por su cuenta.
Senda · agentes que ejecutan
Telar le da a los agentes de Senda la capa de integración con la que ejecutan tareas contra los sistemas de la organización y obtienen los datos para decidir. El razonamiento y la conversación viven en Senda; la ejecución y el dato, acá.
Luma · fuentes siempre frescas
Los informes y tableros de Luma se alimentan de las entidades de Telar: cada flujo programado que corre actualiza la fuente de datos detrás de la visualización, sin cargas manuales ni planillas intermedias.
Tramia · catálogo y stock
El maestro de productos, el stock y las ventas que Tramia necesita para pronosticar y reponer entran por Telar desde el ERP, el e-commerce y el WMS, ya normalizados en entidades tipadas.
Runa · la misma capa, en el Edge
Runa es la versión Edge de este mismo tejido: cuando la operación tiene plantas, sucursales o centros de distribución, procesa cerca de donde se genera el dato y con la misma lógica de integración.
Signa · identidad sobre el tejido
El aislamiento por organización y contexto de Telar es la contracara del modelo de identidad del ecosistema: quién sos determina qué entidades, conectores y flujos podés ver y ejecutar.
Integrás una vez contra tus sistemas. Lo consume todo el ecosistema — ver Telar Suite.
Cinco motores, una sola plataforma
Integración, modelado, orquestación, interfaz generativa y gobierno. Abajo, el catálogo completo con su estado real.
Conectores
APIs REST con OAuth, headers resueltos dinámicamente contra la base, secretos en bóveda, alta masiva en lote y kill-switch por integración.
8 capacidadesEntidades dinámicas
Tablas creadas al momento, campos con tipo fuerte, claves foráneas con descripción semántica y permisos por entidad.
6 capacidadesFlujos de trabajo
Plantillas reutilizables con pasos ordenados, programación CRON, ejecución con estado y trazabilidad completa por paso.
6 capacidadesUI generativa
El backend devuelve componentes, no solo texto: tarjetas, formularios y reportes que el frontend renderiza en tiempo real.
3 capacidadesSeguridad y operación
Multi-organización, autenticación JWT, secretos en bóveda, webhooks, salud del servicio, logs, exportación y avisos por correo.
7 capacidadesCatálogo completo: 30 capacidades
Integración de datos · Conectores
8 capacidades- Conectores definidos por configuración JSON, sin desplegar código
- Origen API REST (GET, POST, PUT) con headers, parámetros y OAuth client credentials
- Resolución dinámica de tokens: el header lee el token vigente desde la base destino
- Credenciales resueltas desde bóveda (Azure Key Vault / AWS Secrets Manager)
- Destino base de datos con carga incremental o purga previa a la sincronización
- Alta masiva de conectores en lote, validada uno por uno sin frenar el resto
- Interruptor de activación por conector y borrado lógico que preserva el historial
- Catálogo de conectores armado por un agente de IA a partir de un relevamiento estructurado
Modelado de datos · Entidades dinámicas
6 capacidades- Creación de tablas al momento, sin migraciones en el código
- Campos con tipo fuerte: texto, entero, entero largo, booleano, GUID y fecha/hora
- Claves primarias y foráneas, con descripción semántica de cada relación
- Permisos por entidad: lectura, escritura, actualización y borrado
- Agrupación por carpetas lógicas y control de visibilidad en el panel
- API de registros para consultar y actualizar los datos de cada entidad
Orquestación · Flujos de trabajo
6 capacidades- Flujo como plantilla reutilizable, compuesta por pasos con orden de ejecución
- Programación por expresión CRON, con rango de vigencia y zona horaria de la organización
- Ejecución con estado: pausar, reanudar y auditar procesos de larga duración
- Trazabilidad por ejecución y por paso: estado, tiempos y conector utilizado
- Evento de dominio ante falla de conector, con aviso automático a administradores
- Procesos de negocio empaquetados sobre el motor genérico (hoy, RRHH)
Interfaz generativa
3 capacidades- Tarjetas dinámicas: el backend devuelve componentes visuales, no solo datos crudos
- Formularios y reportes renderizados en tiempo real desde el backend
- Menús y paneles definidos por configuración, por organización
Gobierno, seguridad y operación
7 capacidades- Multi-organización: datos, credenciales y conocimiento aislados por organización y contexto
- Autenticación JWT y gestión de usuarios
- Gestión de secretos delegada en bóveda, fuera de la base y del repositorio
- Webhooks y disparo de sincronizaciones desde sistemas externos
- Endpoint de salud del servicio y bitácora de logs consultable
- Exportación de datos de la plataforma
- Notificaciones por correo ante eventos operativos
Cómo se accede a Telar
Cinco vías reales de uso, según quién esté del otro lado: tu equipo de IT, otra plataforma del ecosistema o un agente de IA.
API REST
Toda la plataforma se opera por API versionada: conectores, entidades, registros, flujos y ejecuciones. Un conector nuevo es un POST.
# Alta de un conector POST /api/v1/Connectors { "name": "erp_facturas", "organizationId": 12, "jsonValue": { "dynamicEntityName": "ErpInvoices", "origin": { "type": "api", "service": "finance/v2/invoices", "httpmethod": "get" }, "destination": { "type": "db" } } }
Capa de ejecución y datos
Los agentes de IA de Senda no hablan directamente con tu ERP: hablan con Telar. Desde acá ejecutan tareas contra los sistemas integrados y obtienen los datos que necesitan para decidir, con el mismo aislamiento por organización que el resto de la plataforma.
- Ejecución de tareas sobre sistemas integrados
- Lectura de entidades con significado semántico
- Aislado por organización y contexto
Componentes generativos
El backend puede devolver estructuras que el frontend renderiza como tarjetas, formularios o reportes. La interfaz se arma según la respuesta, en vez de estar cableada de antemano.
Webhooks y ejecución programada
Los flujos corren solos por CRON, y un sistema externo puede además disparar una sincronización puntual por webhook cuando su propio evento lo amerita.
Configuración asistida por agentes
Telar está pensado para que su propia configuración pueda ser construida por un agente de IA: a partir de un relevamiento estructurado, el agente arma las entidades y da de alta el catálogo de conectores en lote.
Dónde encaja
Cuatro escenarios típicos de adopción. Son descripciones de uso, no casos de cliente con resultados auditados — esos viven en Casos de Éxito.
Retail multi-tienda
Antes: el maestro de tiendas, el catálogo y el stock viven en APIs distintas, con
tokens que expiran y planillas que alguien baja a mano.
Con Telar: un flujo encadena la renovación del token, la carga del maestro y la
sincronización de stock; el dato queda disponible para reposición, tableros y agentes.
Utilities y servicios regulados
Antes: el sistema técnico, el comercial y el de campo reportan cada uno lo suyo, y
el informe regulatorio se arma a mano cruzando planillas.
Con Telar: los tres quedan integrados en entidades tipadas y el informe se
alimenta de una sola fuente, actualizada por el flujo programado.
Procesos internos de RRHH
Antes: altas, legajos y aprobaciones repartidos entre mail, planillas y el sistema
de nómina.
Con Telar: un proceso empaquetado corre sobre el motor de flujos, con estado
auditable en cada paso. Es el primer proceso de negocio empaquetado de la plataforma y se sigue
ampliando.
Base para el resto de la suite
Antes: cada herramienta nueva vuelve a integrarse contra el ERP desde cero.
Con Telar: la integración se hace una vez y el tejido de datos queda disponible
para todo el ecosistema — los informes de Luma se actualizan solos y los agentes de
Senda ejecutan tareas sobre esos mismos
sistemas.
Para evaluarlo en serio
Arquitectura y seguridad
Dónde viven los datos, cómo se aísla cada cliente y qué controles de identidad aplicamos. La página que suele pedir el área de IT.
Ver arquitecturaEl resto de la suite
Qué resuelve cada plataforma del ecosistema y cómo se apoyan entre sí sobre el mismo tejido de datos.
Ver Telar SuiteDocumentación técnica
Especificación de conectores, esquema de entidades dinámicas y modelo de flujos: se comparte bajo pedido con el equipo que va a evaluar la integración.
Pedir documentaciónPreguntas frecuentes
¿Telar DataFabric reemplaza a mi ERP o a mi data warehouse?
No. Telar no reemplaza tus sistemas de registro: los conecta. El ERP sigue siendo la fuente de verdad de sus datos; Telar los extrae, los normaliza en entidades tipadas y los deja disponibles para procesos, agentes de IA y visualizaciones del resto de Telar Suite.
¿Cuánto tarda conectar un sistema nuevo?
Un conector es un JSON de configuración, no un desarrollo: se define el origen (API, método, headers, parámetros, credenciales desde bóveda) y el destino (entidad y política de carga). No requiere desplegar código nuevo. El tiempo real depende de la documentación y del acceso que provea el sistema de origen — por eso la primera conversación siempre empieza por ahí.
¿Cómo se relaciona con Senda, Runa y el resto de la suite?
Telar DataFabric es la capa de orquestación central, sobre Azure. Runa es su versión Edge, para procesar cerca de donde se generan los datos. Luma toma de Telar las fuentes que alimentan sus informes; los agentes de Senda lo usan como capa de integración para ejecutar tareas contra los sistemas y traer datos; Tramia también consume ese mismo tejido.
¿Y la parte conversacional y de conocimiento?
Vive en Senda, la capa agéntica del ecosistema: ahí están los asistentes, la base de conocimiento y el razonamiento. Telar aporta lo de abajo — los datos integrados y la capa de ejecución con la que esos agentes accionan sobre los sistemas de la organización.
¿Dónde quedan guardadas las credenciales de mis sistemas?
En una bóveda de secretos (Azure Key Vault o AWS Secrets Manager). El conector guarda únicamente el nombre del secreto y su proveedor; el valor se resuelve en tiempo de ejecución y nunca queda escrito en la configuración ni en el repositorio. Rotar una clave no obliga a tocar el conector.
¿Cómo se aíslan los datos de cada empresa?
Toda la plataforma es multi-organización: conectores, entidades, flujos, base de conocimiento y credenciales están vinculados a una organización y a un contexto. Una organización no puede leer ni ejecutar lo de otra.
¿Qué pasa si una integración falla de madrugada?
El motor registra el estado de cada ejecución paso por paso y emite un evento de dominio ante una falla de conector, que dispara el aviso a los administradores. La ejecución queda auditable: qué paso corrió, cuánto tardó y con qué conector.
¿Cuánto puede tardar un flujo de integración?
La plataforma fija como regla que ningún flujo supere los 30 minutos de punta a punta. Es un límite de diseño —condiciona cómo se optimizan las consultas y los conectores— y no un promedio medido de tu operación.
¿Puedo empezar con un solo proceso en vez de integrar todo?
Sí, y es lo que recomendamos. Un flujo con dos o tres conectores sobre un proceso que hoy duele alcanza para validar la arquitectura, medir el esfuerzo real de integración y decidir con datos si escalar al resto de los sistemas.
¿Puedo desactivar una integración sin borrarla?
Sí. Cada conector tiene un interruptor de activación y el borrado es lógico, no físico: se puede apagar una integración problemática sin perder su configuración ni su historial de ejecuciones.
Traé el sistema más difícil de integrar
En una sesión de diagnóstico revisamos ese caso concreto —el que siempre queda para después— y te mostramos cómo se resuelve con conectores, entidades y un flujo programado.
30 capacidades · 5 motores · 31 grupos de endpoints REST · multi-organización por diseño
