Daten anderer Apps nutzen

Jede IronFlock-App erhält ein privates, isoliertes Daten-Backend: eigene Tabellen, eigene Live-Streams, ein eigener Realm. Diese Isolation macht Apps sicher installierbar — für sich genommen würde sie aber auch jede App zu einem Silo machen. Die Daten, die eine Collector-App von einer Maschine erfasst, sind weit über diese eine App hinaus wertvoll: Sie sind der Rohstoff für Dashboards, Analysen, Machine-Learning-Modelle und Berichte.

Der App-übergreifende Datenzugriff macht installierte Apps zu Bausteinen. Eine App kann deklarieren, dass sie die Daten einer anderen App im selben Projekt lesen möchte — deren Live-Event-Streams und deren aufgezeichnete Historie. Der Benutzer, dem das Projekt gehört, entscheidet pro App, ob er das erlaubt — mit einem Schalter, den er jederzeit umlegen kann. Den Rest setzt die Plattform durch: Der Zugriff ist strikt schreibgeschützt, auf die Tabellen beschränkt, die die bereitstellende App tatsächlich teilt, und überschreitet niemals Projektgrenzen.

Was dadurch möglich wird

• Fertige Analysen auf Basis von Collectoren. Installieren Sie einen Daten-Collector auf Ihren Maschinen und anschließend eine OEE-Dashboard-App, die die Messwerte des Collectors konsumiert — ohne Integrationsprojekt, ohne Datenexport, ohne Glue-Code.
• Machine Learning ohne Datenklempnerei. Eine Predictive-Maintenance-App kann auf Monaten von Vibrations- und Temperaturhistorie trainieren, die eine andere App bereits erfasst hat, und Live-Messwerte bewerten, während sie eintreffen.
• Spezialisierte Apps statt Monolithen. Teilen Sie Erfassung, Transformation, Visualisierung und Reporting in separate Apps auf, die jeweils eine Sache gut machen — und kombinieren Sie sie pro Projekt wie Lego-Steine.
• Ein Ökosystem statt Silos. Veröffentlichen Sie eine App, deren gesamter Wert darin liegt, was sie mit den Daten anderer Apps macht. Der Eintrag im App Store zeigt Benutzern, welche Daten eine App teilt und welche Daten sie anfordert.

Funktionsweise

Drei Parteien sind beteiligt, und jede behält die Kontrolle über das, was ihr gehört:

1. Die bereitstellende App („App B”) definiert Tabellen und Transformationen in ihrer data-template.yml, wie jede App. Standardmäßig ist alles teilbar; einzelne Tabellen können als private markiert werden.
2. Die konsumierende App („App A”) deklariert in ihrer data-template.yml, von welchen Apps sie lesen möchte — und warum.
3. Der Benutzer installiert beide Apps in einem Projekt und genehmigt den Zugriff — bei der Installation oder später über einen App-spezifischen Schalter in den App-Einstellungen des Projekts. Ohne Genehmigung kein Zugriff: Die Deklaration allein gewährt nichts.

Daten verlassen das Projekt nie. Der Entwickler der bereitstellenden App hat weiterhin keinen Zugriff auf die Daten des Benutzers — die Freigabe gilt zwischen installierten Apps innerhalb eines Projekts, unter der Kontrolle des Projekteigentümers.

Eine standardisierte Projektdatenbank, viele isolierte Backends

Unter der Haube stellt jedes IronFlock-Projekt dieselbe standardisierte Zeitserien-Datenbank bereit. Darin besitzt jede installierte App einen privaten, abgetrennten Backend-Bereich: Ihre Tabellen liegen in einem eigenen Datenbankschema, unsichtbar für jede andere App, solange der Benutzer keinen Lesezugriff gewährt. Dieses Design — eine Datenbank pro Projekt — macht das gesamte Modell erst möglich:

• Reproduzierbar über Projekte hinweg. Das Daten-Backend einer App wird in jedem Projekt, in dem sie installiert ist, identisch bereitgestellt — gleiche Tabellen, gleiche Typen, gleiches Abfrageverhalten, egal ob das Projekt in der Managed Cloud oder auf einer On-Premises-Appliance läuft. Entwickeln Sie einmal dagegen; es verhält sich überall gleich.
• Ein zentraler Sammel- und Prüfpunkt. Projekteigentümer sehen die Daten all ihrer Apps an einem Ort — eine Datenbank zum Inspizieren, Abfragen und Besitzen statt verstreuter Einzelspeicher pro App.
• Isolation als Standard, Teilen per Freigabe. Die Schema-Isolation hält den Bereich jeder App privat. Eine App-übergreifende Freigabe öffnet ein schreibgeschütztes Fenster in das Schema einer anderen App — innerhalb derselben Datenbank, sodass nichts kopiert, exportiert oder synchronisiert wird. Die Daten haben ein Zuhause; nur der Zugriff ändert sich.

Die Abhängigkeit deklarieren

Die konsumierende App kündigt die Apps, von denen sie liest, in ihrer .ironflock/data-template.yml an:

consumes:
  - app: machine-monitor
    reason: "Berechnet OEE aus den Maschinenzustands- und Zähler-Streams des Monitors"
 
data:
  tables:
    - tablename: oee_results
      columns:
        # ... die eigenen Tabellen Ihrer App, wie gewohnt

Das Feld app ist der technische App-Name der bereitstellenden App (zu sehen auf ihrer App-Store-Seite). Die reason wird dem Benutzer im Zustimmungsdialog angezeigt — schreiben Sie sie für einen Menschen, der entscheidet, ob er Ihrer App vertraut.

Die Daten lesen

Zur Laufzeit verbindet sich das SDK mit dem Daten-Backend der bereitstellenden App und stellt Ihnen dieselbe Lese-API zur Verfügung, die Sie bereits für Ihre eigenen Tabellen verwenden:

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

Wenn der Benutzer den Zugriff nicht gewährt hat (oder ihn später widerruft), schlägt connectToApp mit einem klaren, typisierten Fehler fehl — Ihre App sollte die Datenquelle als optional behandeln und ohne sie kontrolliert weiterlaufen.

Alle Projektdaten nutzen (Wildcard)

Manche Apps sind universelle Datenwerkbänke — eine Node-RED-Laufzeit, ein Notebook, ein Reporting-Tool —, deren gesamter Wert darin liegt, den Benutzer mit beliebigen Daten arbeiten zu lassen, die sich gerade im Projekt befinden. Eine solche App kann die bereitstellenden Apps nicht im Voraus benennen; sie weiß nicht, welche Collector- oder Analyse-Apps der Benutzer installieren wird. Für diese deklarieren Sie eine Wildcard: Lesezugriff auf die Daten jeder App im Projekt.

consumes:
  - app: "*"          # the quotes are REQUIRED — a bare * is a YAML alias
    reason: "Ermöglicht Ihnen, Flows auf den Live- und Verlaufsdaten jeder App in diesem Projekt zu erstellen"

Die "*"-Wildcard gewährt Lesezugriff auf alle Apps im Projekt — einschließlich der Apps, die der Benutzer später installiert, ohne erneute Zustimmung. Alles andere am Modell bleibt unverändert: Es ist weiterhin schreibgeschützt, private Tabellen und Transformationen werden weiterhin niemals geteilt, und Plattform-Apps sind ausgenommen. Der Benutzer genehmigt die Wildcard mit einem einzigen Alles-oder-nichts-Schalter (statt einer Liste pro App) und kann sie jederzeit widerrufen.

Da eine Wildcard-App die Namen der bereitstellenden Apps nicht im Voraus kennt, entdeckt sie diese zur Laufzeit:

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() ist die Basisoperation — ein Aufruf, öffnet keine Verbindungen, gibt den nicht privaten Katalog jeder bereitstellenden App zurück, damit Sie eine Auswahl rendern können. connectToAllApps() ist die bequeme Variante, die sie alle auf einmal öffnet. Neu installierte Apps erscheinen automatisch beim nächsten listConsumableApps()-Aufruf. Wenn der Benutzer die Wildcard nicht gewährt hat, schlagen beide mit einem typisierten NO_GRANT-Fehler fehl.

Schreibgeschützt per Konstruktion

Die Freigabe wird von der Messaging-Schicht der Plattform durchgesetzt, nicht durch Konvention. Eine konsumierende App kann:

Die Daten Ihrer App teilen — und manches zurückhalten

Wenn Sie eine App entwickeln, die wertvolle Daten erfasst, macht das Teilen dieser Daten Ihre App zum Fundament, auf dem andere aufbauen. Sie müssen nicht alles teilen: Markieren Sie interne Tabellen oder Transformationen als private, und sie verschwinden vollständig aus dem geteilten Katalog — nicht gelistet, nicht abfragbar, nicht gestreamt.

data:
  tables:
    - tablename: measurements        # geteilt (Standard)
      columns: [ ... ]
    - tablename: calibration_state   # intern — für andere Apps niemals sichtbar
      private: true
      columns: [ ... ]
  transforms:
    - tablename: hourly_aggregates   # geteilte Views funktionieren wie geteilte Tabellen
      sql: "SELECT ..."

Der Benutzer behält die Kontrolle

• Bei der Installation sieht der Benutzer genau, von welchen installierten Apps die neue App lesen möchte und warum — und kann jede einzelne Anfrage ablehnen. Eine Ablehnung blockiert die Installation nie; die App erhält die Daten einfach nicht.
• Jeder gewährte Zugriff erscheint als Schalter in den App-Einstellungen des Projekts, wo er jederzeit widerrufen (oder nachträglich gewährt, z. B. nach der Installation der bereitstellenden App) werden kann.
• Freigaben gelten pro Projekt. Wer dasselbe App-Paar in einem anderen Projekt installiert, beginnt bei null.

Eine typische Komposition

Das Muster, das dies konkret macht — Erfassung, Analytik und Visualisierung als separate, kombinierbare Apps — wird in Datenerfassung in der Fertigung von Anfang bis Ende beschrieben: Protokoll-Collectoren extrahieren Maschinendaten, und OEE-Dashboards, Predictive-Maintenance-Modelle oder Energieanalysen konsumieren sie — jeweils unabhängig installiert und berechtigt.