Consumir datos de otras apps

Cada app de IronFlock obtiene un backend de datos privado y aislado: sus propias tablas, sus propios flujos en vivo, su propio realm. El aislamiento es lo que hace que las apps sean seguras de instalar — pero por sí solo también convertiría a cada app en un silo. Los datos que una app recopiladora obtiene de una máquina son valiosos mucho más allá de esa única app: son la materia prima para paneles, analítica, modelos de machine learning e informes.

El acceso a datos entre apps convierte las apps instaladas en bloques de construcción. Una app puede declarar que quiere leer los datos de otra app del mismo proyecto — sus flujos de eventos en vivo y su historial registrado. El usuario propietario del proyecto decide si lo permite, por app, con un interruptor que puede accionar en cualquier momento. La plataforma se encarga del resto: el acceso es estrictamente de solo lectura, está limitado a las tablas que la app proveedora realmente comparte y nunca cruza los límites del proyecto.

Qué hace posible

• Analítica lista para usar sobre los recopiladores. Instala un recopilador de datos en tus máquinas y luego instala una app de panel OEE que consuma las mediciones del recopilador — sin proyecto de integración, sin exportación de datos, sin código de pegamento.
• Machine learning sin fontanería. Una app de mantenimiento predictivo puede entrenarse con meses de historial de vibración y temperatura que otra app ya recopiló, y puntuar las lecturas en vivo a medida que llegan.
• Apps especializadas en lugar de monolitos. Divide la recopilación, la transformación, la visualización y los informes en apps separadas que hacen una sola cosa bien — y combínalas por proyecto como piezas de Lego.
• Un ecosistema, no silos. Publica una app cuyo valor completo sea lo que hace con los datos de otras apps. La ficha del App Store muestra a los usuarios qué datos comparte una app y qué datos solicita.

Cómo funciona

Hay tres partes implicadas, y cada una mantiene el control de lo que es suyo:

1. La app proveedora (“App B”) define tablas y transformaciones en su data-template.yml, como cualquier app. Todo es compartible por defecto; las tablas individuales pueden marcarse como private.
2. La app consumidora (“App A”) declara en su data-template.yml de qué apps quiere leer, y por qué.
3. El usuario instala ambas apps en un proyecto y aprueba el acceso — en el momento de la instalación, o más tarde con un interruptor por app en la configuración de apps del proyecto. Sin aprobación no hay acceso: la declaración por sí sola no otorga nada.

Los datos nunca salen del proyecto. El desarrollador de la app proveedora sigue sin tener acceso a los datos del usuario — la concesión es entre apps instaladas dentro de un mismo proyecto, bajo el control del propietario del proyecto.

Una base de datos de proyecto estandarizada, muchos backends aislados

Por debajo, cada proyecto de IronFlock aprovisiona la misma base de datos de series temporales estandarizada. Dentro de ella, cada app instalada posee un espacio de backend privado y separado: sus tablas viven en su propio esquema de base de datos, invisible para cualquier otra app a menos que el usuario conceda acceso de lectura. Este diseño de una base de datos por proyecto es lo que hace funcionar todo el modelo:

• Reproducible entre proyectos. El backend de datos de una app se aprovisiona de forma idéntica en cada proyecto donde se instala — mismas tablas, mismos tipos, mismo comportamiento de consulta, tanto si el proyecto se ejecuta en la nube gestionada como en un appliance on-premises. Desarrolla contra él una vez; se comporta igual en todas partes.
• Un punto central de recopilación e inspección. Los propietarios de proyectos ven los datos de todas sus apps en un solo lugar — una única base de datos que inspeccionar, consultar y poseer, en lugar de una dispersión de almacenes por app.
• Aislamiento por defecto, compartición mediante concesión. El aislamiento por esquemas mantiene privado el espacio de cada app. Una concesión entre apps abre una ventana de solo lectura al esquema de otra app — dentro de la misma base de datos, de modo que nada se copia, se exporta ni se sincroniza. Los datos tienen un único hogar; lo que cambia es el acceso.

Declarar la dependencia

La app consumidora anuncia las apps de las que lee en su .ironflock/data-template.yml:

consumes:
  - app: machine-monitor
    reason: "Calcula el OEE a partir de los flujos de estado de máquina y de contadores del monitor"
 
data:
  tables:
    - tablename: oee_results
      columns:
        # ... your app's own tables, as usual

El campo app es el nombre técnico de la app proveedora (se muestra en su página del App Store). El reason se muestra al usuario en el diálogo de consentimiento — escríbelo para una persona que está decidiendo si confiar en tu app.

Leer los datos

En tiempo de ejecución, el SDK se conecta al backend de datos de la app proveedora y te ofrece la misma API de lectura que ya usas para tus propias tablas:

from ironflock import IronFlock
 
flock = IronFlock()
 
# Connect to the providing app's data backend (requires the user's grant)
monitor = await flock.connect_to_app("machine-monitor")
 
# Discover what it shares
print(monitor.tables)      # shared tables with their columns
print(monitor.transforms)  # shared transforms (views)
 
# Query history
rows = await monitor.get_history("machinestate", {"limit": 1000})
 
# Down-sampled series for charts and models
series = await monitor.get_series_history("measurements", {
    "metrics": ["temperature"],
    "method": "AVG",
    "timeRange": ["2026-07-01T00:00:00Z", "2026-07-04T00:00:00Z"],
})
 
# Subscribe to live rows as they are collected
async def on_row(row):
    print("live reading:", row)
 
await monitor.subscribe_to_table("measurements", on_row)

import { IronFlock } from "ironflock";
 
const flock = new IronFlock();
await flock.start();
 
// Connect to the providing app's data backend (requires the user's grant)
const monitor = await flock.connectToApp("machine-monitor");
 
// Discover what it shares
console.log(monitor.tables);      // shared tables with their columns
console.log(monitor.transforms); // shared transforms (views)
 
// Query history
const rows = await monitor.getHistory("machinestate", { limit: 1000 });
 
// Down-sampled series for charts and models
const series = await monitor.getSeriesHistory("measurements", {
  metrics: ["temperature"],
  method: "AVG",
  timeRange: ["2026-07-01T00:00:00Z", "2026-07-04T00:00:00Z"],
});
 
// Subscribe to live rows as they are collected
await monitor.subscribeToTable("measurements", (row) => {
  console.log("live reading:", row);
});

Si el usuario no ha concedido el acceso (o lo revoca más tarde), connectToApp falla con un error claro y tipado — tu app debería tratar la fuente de datos como opcional y degradarse con elegancia.

Consumir todos los datos del proyecto (comodín)

Algunas apps son bancos de trabajo de datos de propósito general — un runtime de Node-RED, un notebook, una herramienta de informes — cuyo valor completo está en dejar que el usuario trabaje con cualesquiera datos que haya en el proyecto. Una app así no puede nombrar a los proveedores por adelantado; no sabe qué recopiladores o apps de analítica instalará el usuario. Para estas, declara un comodín: acceso de lectura a los datos de todas las apps del proyecto.

consumes:
  - app: "*"          # the quotes are REQUIRED — a bare * is a YAML alias
    reason: "Te permite crear flujos sobre los datos en vivo e históricos de cada app de este proyecto"

El comodín "*" concede acceso de lectura a todas las apps del proyecto — incluidas las apps que el usuario instale más tarde, sin volver a dar su consentimiento. Todo lo demás del modelo permanece igual: sigue siendo de solo lectura, las tablas y transformaciones privadas siguen sin compartirse nunca, y las apps de plataforma quedan fuera del alcance. El usuario aprueba el comodín con un único interruptor de todo o nada (en lugar de una lista por app), y puede revocarlo en cualquier momento.

Como una app consumidora con comodín no conoce de antemano los nombres de los proveedores, los descubre en tiempo de ejecución:

from ironflock import IronFlock
 
flock = IronFlock()
 
# Discover every app whose data you may read (name + shared-table catalog)
providers = await flock.list_consumable_apps()
for p in providers:
    print(p["app"], p["stages"])   # e.g. "energy-monitor", {"prod": {"tables": [...]}}
 
# Open one by name (works because you hold the wildcard grant)
energy = await flock.connect_to_app("energy-monitor")
rows = await energy.get_history("meterdata", {"limit": 1000})
 
# ...or open them all at once
all_apps = await flock.connect_to_all_apps()
for app in all_apps:
    await app.subscribe_to_table(app.tables[0]["tablename"], on_row)

import { IronFlock } from "ironflock";
 
const flock = new IronFlock();
await flock.start();
 
// Discover every app whose data you may read (name + shared-table catalog)
const providers = await flock.listConsumableApps();
for (const p of providers) {
  console.log(p.app, p.stages);   // e.g. "energy-monitor", { prod: { tables: [...] } }
}
 
// Open one by name (works because you hold the wildcard grant)
const energy = await flock.connectToApp("energy-monitor");
const rows = await energy.getHistory("meterdata", { limit: 1000 });
 
// ...or open them all at once
const all = await flock.connectToAllApps();
for (const app of all) {
  await app.subscribeToTable(app.tables[0].tablename, onRow);
}

listConsumableApps() es la primitiva — una sola llamada, no abre ninguna conexión, devuelve el catálogo no privado de cada proveedor para que puedas renderizar un selector. connectToAllApps() es la opción práctica que las abre todas de una vez. Las apps recién instaladas aparecen automáticamente en la siguiente llamada a listConsumableApps(). Si el usuario no ha concedido el comodín, ambas fallan con un error tipado NO_GRANT.

Solo lectura por construcción

La concesión la garantiza la capa de mensajería de la plataforma, no una convención. Una app consumidora puede:

Compartir los datos de tu app — y reservarte algunos

Si desarrollas una app que recopila datos valiosos, compartirlos es lo que convierte tu app en una base sobre la que otros construyen. No tienes que compartirlo todo: marca las tablas o transformaciones internas como private y desaparecerán por completo del catálogo compartido — no se listan, no se pueden consultar, no se transmiten.

data:
  tables:
    - tablename: measurements        # shared (default)
      columns: [ ... ]
    - tablename: calibration_state   # internal — never visible to other apps
      private: true
      columns: [ ... ]
  transforms:
    - tablename: hourly_aggregates   # shared views work like shared tables
      sql: "SELECT ..."

El usuario mantiene el control

• En el momento de la instalación, el usuario ve exactamente de qué apps instaladas quiere leer la nueva app, y por qué — y puede rechazar cualquiera de ellas. Rechazar nunca bloquea la instalación; la app simplemente no recibe los datos.
• Cada acceso concedido aparece como un interruptor en la configuración de apps del proyecto, donde puede revocarse (o concederse más tarde, por ejemplo después de instalar la app proveedora) en cualquier momento.
• Las concesiones son por proyecto. Instalar el mismo par de apps en otro proyecto empieza desde cero.

Una composición típica

El patrón que hace esto concreto — recopilación, analítica y visualización como apps separadas y componibles — se describe de principio a fin en Extracción de Datos de Fábrica: los recopiladores de protocolo extraen los datos de las máquinas, y los paneles OEE, los modelos de mantenimiento predictivo o la analítica energética los consumen, cada uno instalado y autorizado de forma independiente.