Korzystanie z danych innych aplikacji

Każda aplikacja IronFlock otrzymuje prywatny, izolowany backend danych: własne tabele, własne strumienie na żywo, własny realm. Izolacja sprawia, że aplikacje można bezpiecznie instalować — ale sama w sobie uczyniłaby też z każdej aplikacji silos. Dane, które aplikacja kolektora zbiera z maszyny, mają wartość daleko wykraczającą poza tę jedną aplikację: są surowcem dla paneli, analityki, modeli uczenia maszynowego i raportów.

Dostęp do danych między aplikacjami zamienia zainstalowane aplikacje w klocki do budowania. Aplikacja może zadeklarować, że chce odczytywać dane innej aplikacji w tym samym projekcie — jej strumienie zdarzeń na żywo i zarejestrowaną historię. Użytkownik będący właścicielem projektu decyduje, czy na to pozwolić, dla każdej aplikacji osobno, przełącznikiem, który może przestawić w dowolnym momencie. Resztę egzekwuje platforma: dostęp jest ściśle tylko do odczytu, ograniczony do tabel, które aplikacja dostarczająca faktycznie udostępnia, i nigdy nie przekracza granic projektu.

Co to umożliwia

• Gotowa analityka na bazie kolektorów. Zainstaluj kolektor danych na swoich maszynach, a następnie zainstaluj aplikację panelu OEE, która konsumuje pomiary kolektora — bez projektu integracyjnego, bez eksportu danych, bez kodu sklejającego.
• Uczenie maszynowe bez hydrauliki. Aplikacja predykcyjnego utrzymania ruchu może trenować na miesiącach historii wibracji i temperatur zebranej już przez inną aplikację i oceniać odczyty na żywo w miarę ich napływania.
• Wyspecjalizowane aplikacje zamiast monolitów. Rozdziel zbieranie, transformację, wizualizację i raportowanie na osobne aplikacje, z których każda robi dobrze jedną rzecz — i łącz je w każdym projekcie jak klocki Lego.
• Ekosystem, a nie silosy. Opublikuj aplikację, której cała wartość polega na tym, co robi z danymi innych aplikacji. Strona w App Store pokazuje użytkownikom, które dane aplikacja udostępnia, a o które dane prosi.

Jak to działa

Zaangażowane są trzy strony, a każda zachowuje kontrolę nad tym, co do niej należy:

1. Aplikacja dostarczająca („App B”) definiuje tabele i transformacje w swoim data-template.yml, jak każda aplikacja. Domyślnie wszystko można udostępniać; poszczególne tabele można oznaczyć jako private.
2. Aplikacja konsumująca („App A”) deklaruje w swoim data-template.yml, z których aplikacji chce czytać i dlaczego.
3. Użytkownik instaluje obie aplikacje w projekcie i zatwierdza dostęp — w momencie instalacji lub później, przełącznikiem per aplikacja w ustawieniach aplikacji projektu. Bez zatwierdzenia nie ma dostępu: sama deklaracja niczego nie przyznaje.

Dane nigdy nie opuszczają projektu. Deweloper aplikacji dostarczającej nadal nie ma dostępu do danych użytkownika — uprawnienie obowiązuje między zainstalowanymi aplikacjami wewnątrz jednego projektu, pod kontrolą właściciela projektu.

Jedna ustandaryzowana baza danych projektu, wiele izolowanych backendów

Pod maską każdy projekt IronFlock otrzymuje tę samą ustandaryzowaną bazę danych szeregów czasowych. Wewnątrz niej każda zainstalowana aplikacja posiada prywatną, wydzieloną przestrzeń backendu: jej tabele żyją we własnym schemacie bazy danych, niewidocznym dla każdej innej aplikacji, dopóki użytkownik nie przyzna dostępu do odczytu. Ta konstrukcja — jedna baza danych na projekt — sprawia, że cały model działa:

• Odtwarzalność między projektami. Backend danych aplikacji jest tworzony identycznie w każdym projekcie, w którym aplikacja jest zainstalowana — te same tabele, te same typy, to samo zachowanie zapytań, niezależnie od tego, czy projekt działa w zarządzanej chmurze, czy na urządzeniu on-premises. Zbuduj raz; wszędzie zachowuje się tak samo.
• Centralny punkt zbierania i wglądu. Właściciele projektów widzą dane wszystkich swoich aplikacji w jednym miejscu — jedna baza danych do inspekcji, odpytywania i posiadania, zamiast rozproszenia magazynów per aplikacja.
• Izolacja domyślnie, udostępnianie za zgodą. Izolacja schematów utrzymuje przestrzeń każdej aplikacji jako prywatną. Uprawnienie między aplikacjami otwiera okno tylko do odczytu do schematu innej aplikacji — wewnątrz tej samej bazy danych, więc nic nie jest kopiowane, eksportowane ani synchronizowane. Dane mają jeden dom; zmienia się tylko dostęp.

Deklarowanie zależności

Aplikacja konsumująca ogłasza aplikacje, z których czyta, w swoim .ironflock/data-template.yml:

consumes:
  - app: machine-monitor
    reason: "Oblicza OEE ze strumieni stanu maszyny i liczników monitora"
 
data:
  tables:
    - tablename: oee_results
      columns:
        # ... your app's own tables, as usual

Pole app to techniczna nazwa aplikacji dostarczającej (widoczna na jej stronie w App Store). Wartość reason jest wyświetlana użytkownikowi w oknie zgody — napisz ją dla człowieka, który decyduje, czy zaufać twojej aplikacji.

Odczytywanie danych

W czasie działania SDK łączy się z backendem danych aplikacji dostarczającej i daje ci to samo API odczytu, którego już używasz dla własnych tabel:

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

Jeśli użytkownik nie przyznał dostępu (lub później go cofnie), connectToApp kończy się jasnym, typowanym błędem — twoja aplikacja powinna traktować to źródło danych jako opcjonalne i płynnie ograniczać swoją funkcjonalność.

Korzystanie ze wszystkich danych projektu (symbol wieloznaczny)

Niektóre aplikacje to uniwersalne warsztaty danych — środowisko Node-RED, notatnik, narzędzie raportowe — których cała wartość polega na umożliwieniu użytkownikowi pracy z dowolnymi danymi, jakie akurat znajdują się w projekcie. Taka aplikacja nie może z góry wskazać aplikacji dostarczających; nie wie, które kolektory ani aplikacje analityczne zainstaluje użytkownik. Dla nich zadeklaruj symbol wieloznaczny: dostęp do odczytu danych każdej aplikacji w projekcie.

consumes:
  - app: "*"          # the quotes are REQUIRED — a bare * is a YAML alias
    reason: "Pozwala budować przepływy na danych na żywo i historycznych każdej aplikacji w tym projekcie"

Symbol wieloznaczny "*" przyznaje dostęp do odczytu wszystkim aplikacjom w projekcie — w tym aplikacjom, które użytkownik zainstaluje później, bez ponownej zgody. Cała reszta modelu pozostaje bez zmian: nadal jest to tylko odczyt, prywatne tabele i transformacje nadal nigdy nie są udostępniane, a aplikacje platformy są poza zakresem. Użytkownik zatwierdza symbol wieloznaczny jednym przełącznikiem „wszystko albo nic” (zamiast listy per aplikacja) i może go cofnąć w dowolnym momencie.

Ponieważ aplikacja konsumująca z symbolem wieloznacznym nie zna z góry nazw aplikacji dostarczających, wykrywa je w czasie działania:

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() to prymityw — jedno wywołanie, nie otwiera żadnych połączeń, zwraca nieprywatny katalog każdej aplikacji dostarczającej, abyś mógł wyrenderować selektor. connectToAllApps() to wygodny skrót, który otwiera je wszystkie naraz. Nowo zainstalowane aplikacje pojawiają się automatycznie przy następnym wywołaniu listConsumableApps(). Jeśli użytkownik nie przyznał symbolu wieloznacznego, oba kończą się typowanym błędem NO_GRANT.

Tylko do odczytu z założenia

Uprawnienie jest egzekwowane przez system komunikatów platformy, a nie przez konwencję. Aplikacja konsumująca może:

Udostępnianie danych twojej aplikacji — i zachowanie części dla siebie

Jeśli budujesz aplikację, która zbiera wartościowe dane, ich udostępnienie sprawia, że twoja aplikacja staje się fundamentem, na którym budują inni. Nie musisz udostępniać wszystkiego: oznacz wewnętrzne tabele lub transformacje jako private, a znikną całkowicie z udostępnianego katalogu — nie są wymieniane, nie można ich odpytywać, nie są strumieniowane.

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

Użytkownik zachowuje kontrolę

• W momencie instalacji użytkownik widzi dokładnie, z których zainstalowanych aplikacji nowa aplikacja chce czytać i dlaczego — i może odmówić każdej z nich. Odmowa nigdy nie blokuje instalacji; aplikacja po prostu nie otrzymuje danych.
• Każdy przyznany dostęp pojawia się jako przełącznik w ustawieniach aplikacji projektu, gdzie można go w dowolnym momencie cofnąć (lub przyznać później, np. po zainstalowaniu aplikacji dostarczającej).
• Uprawnienia obowiązują per projekt. Instalacja tej samej pary aplikacji w innym projekcie zaczyna od zera.

Typowa kompozycja

Wzorzec, który czyni to konkretnym — zbieranie, analityka i wizualizacja jako osobne, komponowalne aplikacje — jest opisany od początku do końca w Pozyskiwaniu danych z fabryki: kolektory protokołów pozyskują dane maszyn, a panele OEE, modele predykcyjnego utrzymania ruchu czy analityka energii je konsumują — każde z nich instalowane i autoryzowane niezależnie.