Plataforma de observabilidad BAM multi-tenant para integraciones empresariales. Centraliza el monitoreo de todas las interfaces en un único dashboard operacional, sin importar el middleware que se use.
Vista consolidada de todas las interfaces, filtro de errores y el detalle de un mensaje con su diagnóstico con IA: causa raíz, acción recomendada y los incidentes similares en que se basa. Grabado sobre la plataforma real, con datos de demostración.
Si un sistema puede hacer una llamada a una API, puede enviar telemetría a NCS TelemetryHub. Sin agentes, sin instalaciones complejas.
El modelo es simple: los sistemas envían eventos al hub central. TelemetryHub los recibe, normaliza y distribuye al dashboard de cada tenant de forma aislada y segura.
Diseñado para que el equipo de integración tenga visibilidad completa sin depender del área de infraestructura.
Vista centralizada de todas las interfaces con KPIs de estado, tendencias y detalle de cada transacción. Actualización continua sin intervención.
Detección de anomalías y errores antes de que el negocio lo note. Notificaciones configurables por tenant y por tipo de interfaz.
Seguimiento completo del ciclo de vida de una transacción: desde el sistema origen hasta el sistema destino, con timestamps y estado en cada paso.
Búsqueda por interfaz, estado, rango de fechas, sistema origen/destino y unidad de negocio. Paginación eficiente para volúmenes altos.
Cada cliente opera en un silo completamente aislado. Roles diferenciados que determinan qué puede ver y hacer cada usuario dentro de su tenant.
Protocolo estándar de la industria (OpenTelemetry) para máxima compatibilidad. Onboarding guiado incluido en todos los planes.
Hoy, diagnosticar una interfaz caída depende de que alguien recuerde un caso parecido. TelemetryHub hace esa búsqueda apenas entra el error: lo compara con incidentes ya resueltos y propone causa raíz, severidad y acción recomendada, en español, indicando en qué casos se basa.
Errores de integración SAP documentados con causa y solución —CPI, PI/PO, IDoc, Cloud Connector, certificados, conectividad—, escritos y versionados por NCS en Obsidian. Encima, patrones expertos por familia de error, cada uno con pruebas automáticas.
El error nuevo se compara por significado, no por palabra exacta, contra esa base y contra los incidentes que su equipo ya resolvió. Los casos más parecidos pasan como evidencia; los de otra familia de error se descartan.
Un modelo de lenguaje redacta el diagnóstico a partir de esa evidencia. Si cita una referencia SAP que la evidencia no respalda, queda marcada. Si el modelo no responde, el patrón experto entrega un diagnóstico de respaldo, con confianza reducida.
Cada diagnóstico se marca como reconocido, resuelto o descartado, y el tablero mide el acierto. Lo resuelto, con su nota, entra a la base de su tenant: el próximo error parecido se diagnostica con la solución que se aplicó en su operación.
Es una propuesta para verificar, no una orden: la decisión sigue siendo de su equipo. Los errores críticos pueden avisar por Teams, Slack, correo o webhook.
Operamos la plataforma y el modelo de lenguaje en infraestructura que controlamos, y respondemos por su funcionamiento. El diagnóstico no pasa por APIs públicas de IA de terceros.
Si sus datos no pueden salir de su red, desplegamos la plataforma y el modelo dentro de su arquitectura, sobre la especificación técnica que le entregamos, bajo NDA y sus políticas de confidencialidad. Condiciones a convenir.
Qué se captura y qué nunca, dónde viven los datos, y qué pasa si el servicio no responde. Todo publicado, incluido lo que todavía no tenemos.
Ver la ficha de seguridad completa
Cada usuario y cada integración se autentica con credenciales únicas. El acceso se concede mediante tokens firmados con tiempo de expiración controlado.
El aislamiento entre clientes se aplica en todas las capas del sistema. Ningún usuario puede acceder, ver ni inferir información de otro tenant, sin excepción.
Permisos diferenciados según responsabilidad: quién puede solo consultar, quién puede insertar y quién administra el tenant completo. Principio de mínimo privilegio.
Contraseñas almacenadas con hash seguro, validación estricta de entradas y comunicación cifrada en tránsito. Sin datos sensibles en logs ni respuestas de error.
Construido sobre estándares de la industria para garantizar rendimiento, escala y longevidad.
Evolucionando activamente con base en el feedback de los primeros clientes en Early Access.
Las mismas que haríamos nosotros si nos vinieran a vender esto. Van respondidas antes de la reunión.
No uno por uno. La emisión se resuelve con un grupo de pasos reutilizable que se agrega al flujo, y en CPI se engancha además al subproceso de excepción para que un error reporte solo. Lo que sí hay que hacer es una pasada de instrumentación por interfaz: es trabajo acotado y forma parte del onboarding, no una reescritura.
El envío es asíncrono y queda fuera del camino crítico del mensaje: si la API de ingesta no responde a tiempo, la traza se descarta antes de afectar el mensaje de negocio. La mediana, el p95 y el tope de espera exactos se miden en el entorno de cada cliente durante el onboarding — no se publica una cifra genérica que no represente su volumen real.
No. TelemetryHub falla abierto: si la API de ingesta no contesta, la interfaz sigue procesando y entregando el mensaje. Se pierde la traza, nunca la transacción de negocio. Un componente de observabilidad que puede detener una interfaz productiva no es observabilidad, es un punto único de falla nuevo.
Por defecto no. TelemetryHub trabaja con metadatos: identificadores, tiempos, estado, sistema origen y destino. La captura de contenido existe porque hay incidentes que no se diagnostican sin ella, pero está desactivada, se activa por interfaz, admite enmascaramiento de campos y tiene retención más corta. Está todo detallado en la ficha de seguridad.
No. El diagnóstico no usa APIs públicas de IA: el modelo de lenguaje corre en infraestructura que controlamos o, si elige el despliegue privado, dentro de su red. Trabaja con los mismos datos del error que ya ve el tablero. Tampoco se entrena un modelo con su información: lo que se aprende es una base de casos resueltos que queda dentro de su tenant y no se consulta para diagnosticar a otro cliente.
Es la pregunta correcta, y la respuesta empieza reconociendo dónde las otras herramientas son mejores.
| Herramienta | Dónde es mejor | Dónde deja hueco |
|---|---|---|
| SAP Cloud ALM | Viene incluido con las licencias SAP, sin costo adicional. Cobertura nativa y profunda del mundo SAP. | Configuración exigente, y no ve lo que pasa fuera de SAP: MuleSoft, Boomi o una API propia quedan fuera del tablero. |
| SAP Focused Run | Monitoreo técnico profundo a escala de paisaje grande, híbrido y on-premise. | Dimensionado y licenciado para grandes corporaciones. Sobra y cuesta caro para una operación mediana. |
| Monitor nativo de Integration Suite | Trazabilidad de mensajes en el propio CPI, incluida, inmediata. | Vista técnica cruda y acotada a un tenant. No consolida PI/PO ni terceros ni da lectura de negocio. |
| Datadog, Dynatrace | Observabilidad general excelente, multi-cloud, con enorme ecosistema. | No entienden la semántica SAP: un IDoc, un mensaje CPI o una replicación PTP son texto sin significado propio. |
| NCS TelemetryHub | Una sola vista de PI/PO, CPI, MuleSoft, Boomi y APIs propias, con semántica de integración SAP y alertas legibles por el negocio. | Producto joven, de un equipo pequeño, sin certificación formal todavía. No reemplaza al monitor nativo: lo consolida. |
Si todas las integraciones viven dentro de SAP y Cloud ALM resulta suficiente, es la opción recomendada: es gratis y está bien hecho. TelemetryHub tiene sentido cuando el tablero debe cruzar plataformas y alguien del negocio necesita entenderlo.
Conversemos sobre cómo conectar las integraciones actuales a TelemetryHub, sin importar el middleware que use hoy.
Sin cookies ni analítica de terceros. Estas preferencias quedan en su navegador. Las visitas se cuentan de forma anónima en nuestro propio servidor, sin guardar su dirección IP.