Consumare Dati da Altre App

Ogni app IronFlock riceve un data backend privato e isolato: le proprie tabelle, i propri stream live, il proprio realm. L’isolamento è ciò che rende le app sicure da installare — ma da solo trasformerebbe anche ogni app in un silo. I dati che un’app collector raccoglie da una macchina hanno un valore che va ben oltre quella singola app: sono la materia prima per dashboard, analisi, modelli di machine learning e report.

L’accesso ai dati tra app trasforma le app installate in mattoncini componibili. Un’app può dichiarare di voler leggere i dati di un’altra app nello stesso progetto — i suoi stream di eventi live e la sua cronologia registrata. L’utente proprietario del progetto decide se consentirlo, app per app, con un interruttore che può azionare in qualsiasi momento. Al resto pensa la piattaforma: l’accesso è rigorosamente in sola lettura, limitato alle tabelle che l’app fornitrice condivide effettivamente, e non oltrepassa mai i confini del progetto.

Cosa Rende Possibile

• Analisi pronte all’uso sopra i collector. Installa un collector di dati sulle tue macchine, poi installa un’app di dashboard OEE che consuma le misurazioni del collector — nessun progetto di integrazione, nessuna esportazione di dati, nessun codice collante.
• Machine learning senza tubature. Un’app di manutenzione predittiva può addestrarsi su mesi di cronologia di vibrazioni e temperature già raccolta da un’altra app, e valutare le letture live man mano che arrivano.
• App specializzate invece di monoliti. Suddividi raccolta, trasformazione, visualizzazione e reportistica in app separate che fanno ognuna una cosa sola, e bene — e combinale per progetto come mattoncini Lego.
• Un ecosistema, non silos. Pubblica un’app il cui intero valore sta in ciò che fa con i dati di altre app. La pagina dell’App Store mostra agli utenti quali dati un’app condivide e quali dati richiede.

Come Funziona

Le parti coinvolte sono tre, e ognuna mantiene il controllo di ciò che è suo:

1. L’app fornitrice (“App B”) definisce tabelle e trasformazioni nel suo data-template.yml, come fa ogni app. Tutto è condivisibile per impostazione predefinita; le singole tabelle possono essere marcate private.
2. L’app consumatrice (“App A”) dichiara nel suo data-template.yml da quali app vuole leggere, e perché.
3. L’utente installa entrambe le app in un progetto e approva l’accesso — al momento dell’installazione, o in seguito con un interruttore per app nelle impostazioni delle app del progetto. Nessuna approvazione, nessun accesso: la dichiarazione da sola non concede nulla.

I dati non lasciano mai il progetto. Lo sviluppatore dell’app fornitrice continua a non avere accesso ai dati dell’utente — la concessione avviene tra app installate all’interno di un unico progetto, sotto il controllo del proprietario del progetto.

Un Unico Database di Progetto Standardizzato, Tanti Backend Isolati

Sotto il cofano, ogni progetto IronFlock effettua il provisioning dello stesso database di serie temporali standardizzato. Al suo interno, ogni app installata possiede uno spazio backend privato e separato: le sue tabelle vivono in un proprio schema di database, invisibile a ogni altra app a meno che l’utente non conceda l’accesso in lettura. Questo design a un-database-per-progetto è ciò che fa funzionare l’intero modello:

• Riproducibile tra progetti. Il data backend di un’app viene creato in modo identico in ogni progetto in cui l’app è installata — stesse tabelle, stessi tipi, stesso comportamento delle query, sia che il progetto giri nel cloud gestito sia su un’appliance on-premises. Sviluppa contro di esso una volta sola; si comporta allo stesso modo ovunque.
• Un punto centrale di raccolta e ispezione. I proprietari dei progetti vedono i dati di tutte le loro app in un unico posto — un solo database da ispezionare, interrogare e possedere, invece di una dispersione di archivi per app.
• Isolamento per impostazione predefinita, condivisione su concessione. L’isolamento a livello di schema mantiene privato lo spazio di ogni app. Una concessione tra app apre una finestra in sola lettura sullo schema di un’altra app — all’interno dello stesso database, così nulla viene copiato, esportato o sincronizzato. I dati hanno una sola casa; ciò che cambia è l’accesso.

Dichiarare la Dipendenza

L’app consumatrice annuncia le app da cui legge nel suo .ironflock/data-template.yml:

consumes:
  - app: machine-monitor
    reason: "Calcola l'OEE dagli stream di stato macchina e dei contatori del monitor"
 
data:
  tables:
    - tablename: oee_results
      columns:
        # ... your app's own tables, as usual

Il campo app è il nome tecnico dell’app fornitrice (mostrato sulla sua pagina dell’App Store). Il reason viene mostrato all’utente nella finestra di consenso — scrivilo per una persona che sta decidendo se fidarsi della tua app.

Leggere i Dati

A runtime, l’SDK si connette al data backend dell’app fornitrice e ti offre la stessa API di lettura che già usi per le tue tabelle:

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);
});

Se l’utente non ha concesso l’accesso (o lo revoca in seguito), connectToApp fallisce con un errore chiaro e tipizzato — la tua app dovrebbe trattare la sorgente dati come opzionale e degradare in modo controllato.

Consumare Tutti i Dati del Progetto (Wildcard)

Alcune app sono banchi di lavoro dati generici — un runtime Node-RED, un notebook, uno strumento di reportistica — il cui intero valore sta nel lasciare che l’utente lavori con qualsiasi dato si trovi nel progetto. Un’app del genere non può nominare in anticipo le app fornitrici; non sa quali collector o app di analisi installerà l’utente. Per queste, dichiara una wildcard: accesso in lettura ai dati di ogni app del progetto.

consumes:
  - app: "*"          # the quotes are REQUIRED — a bare * is a YAML alias
    reason: "Ti permette di creare flussi sui dati live e storici di ogni app di questo progetto"

La wildcard "*" concede l’accesso in lettura a tutte le app del progetto — comprese le app che l’utente installa in seguito, senza un nuovo consenso. Tutto il resto del modello resta invariato: è ancora in sola lettura, le tabelle e le trasformazioni private continuano a non essere mai condivise, e le app di piattaforma sono fuori ambito. L’utente approva la wildcard con un unico interruttore tutto-o-niente (invece di un elenco per app), e può revocarla in qualsiasi momento.

Poiché un’app consumatrice con wildcard non conosce in anticipo i nomi delle app fornitrici, le scopre a runtime:

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() è la primitiva — una sola chiamata, non apre alcuna connessione, restituisce il catalogo non privato di ogni app fornitrice così da poter renderizzare un selettore. connectToAllApps() è la comoda scorciatoia che le apre tutte in una volta. Le app appena installate compaiono automaticamente alla successiva chiamata a listConsumableApps(). Se l’utente non ha concesso la wildcard, entrambe falliscono con un errore tipizzato NO_GRANT.

Sola Lettura per Costruzione

La concessione è applicata dal sistema di messaggistica della piattaforma, non da una convenzione. Un’app consumatrice può:

Condividere i Dati della Tua App — e Tenerne una Parte per Te

Se costruisci un’app che raccoglie dati di valore, condividerli è ciò che rende la tua app una base su cui altri costruiscono. Non devi condividere tutto: marca le tabelle o le trasformazioni interne come private e spariranno completamente dal catalogo condiviso — non elencate, non interrogabili, non trasmesse in streaming.

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 ..."

L’Utente Mantiene il Controllo

• Al momento dell’installazione, l’utente vede esattamente da quali app installate la nuova app vuole leggere, e perché — e può rifiutarne qualunque. Rifiutare non blocca mai l’installazione; semplicemente l’app non riceve i dati.
• Ogni accesso concesso appare come un interruttore nelle impostazioni delle app del progetto, dove può essere revocato (o concesso in seguito, ad esempio dopo l’installazione dell’app fornitrice) in qualsiasi momento.
• Le concessioni valgono per progetto. Installare la stessa coppia di app in un altro progetto riparte da zero.

Una Composizione Tipica

Il pattern che rende tutto questo concreto — raccolta, analisi e visualizzazione come app separate e componibili — è descritto da cima a fondo in Estrazione di Dati di Fabbrica: i collector di protocollo estraggono i dati macchina, e dashboard OEE, modelli di manutenzione predittiva o analisi energetiche li consumano, ognuno installato e autorizzato in modo indipendente.