Zum Hauptinhalt springen

App-Datenquellen

Eine Datenquelle verbindet eine App mit einer eigenen Tabelle. Dieselben Datensätze können als Karten, Liste, einzelner Datensatz, Diagramm oder in einem eigenen Blueprint erscheinen. Die Tabelle stellt Speicher und Felder bereit; du bestimmst die Darstellung.

Eine Tabelle verbinden​

  1. Öffne deine App in Operations Studio und wähle Daten in der Editor-Werkzeugleiste.
  2. Wähle Tabelle verbinden, wähle eine vorhandene Tabelle und benenne die Datenquelle. Hier kannst du auch eine Tabelle erstellen und ihre Felder bearbeiten.
  3. Wähle die benötigten Vorgänge: Datensätze lesen, erstellen, bearbeiten oder löschen. Neue Datenquellen beginnen mit Lesezugriff.
  4. Lege fest, ob Benutzer nur selbst erstellte Datensätze sehen. Diese Einstellung ist anfangs aktiv. Shop-Floor-Konten arbeiten immer mit ihren eigenen Datensätzen.

Datenquellen gehören zur App und können in mehreren Tabs und Blueprints verwendet werden. Änderungen oder entfernte Verbindungen gelten für die nächste veröffentlichte App-Version. Beim Trennen einer Datenquelle bleiben die Tabelle und ihre Datensätze erhalten.

Die Darstellung wählen​

Gestalte in einer neuen React-App Karten, Listen, Datensatzdetails oder Diagramme im Quellcode. Nutze das unten beschriebene SDK mit benannten Quellen; eine sichtbare Schaltfläche verleiht keine Schreibberechtigung. Bitte Konnie um die tatsächlichen Spalten, Filter, Seiten sowie Leer-/Fehlerzustände der Aufgabe.

Vorhandene komponentenbasierte Apps können eine Datenansicht mit Karten, Liste, Einzeldatensatz oder Diagramm und Aktionen zum Hinzufügen/Bearbeiten/Löschen anbieten. Diese Ansichten verwenden dieselben Quellrechte und das typisierte Schema. Ihre Konfiguration ist ein Kompatibilitätsweg; neue Apps besitzen ihre Oberfläche direkt.

Eigene Oberflächen verwenden​

Bitte Konnie, eine vorhandene Tabelle zu verbinden und die Oberfläche passend zur Arbeit zu gestalten: eine Anfragekarte, eine gefilterte Warteschlange, ein Diagramm neben einem Eingabeformular oder ein anderes Layout. Blueprints verwenden dieselben benannten Datenquellen direkt. Sie können Datensätze abfragen, einen einzelnen Datensatz lesen, Benutzereingaben speichern, Datensätze ändern oder löschen, ohne eine sichtbare Tabellenkomponente hinzuzufügen.

Für eigenen Code bietet ennea.dataSources die Methoden query, get, aggregate, create, update und delete. Verwende die logische ID der Quelle statt ihrer Tabellen-ID. Feldnamen sind die echten Spaltenschlüssel aus dem Schema der verbundenen Tabelle. Dieses Beispiel setzt eine Quelle requests mit der Spalte status und dem erlaubten Auswahlwert open voraus:

const response = await ennea.dataSources.query("requests", {
  filter: {
    logic: "and",
    rules: [{ columnId: "status", operator: "equals", value: "open" }],
  },
  select: ["status"],
  sort: [{ columnId: "status", direction: "asc" }],
  offset: 0,
  limit: 20,
});
const { rows, total, table } = response.data;

Datensätze besitzen _id, values und version; ein Feld liest du als row.values.status. total beschreibt die passenden Datensätze, rows enthält die angeforderte Seite. get(sourceId, rowId) liefert response.data.row und das aktuelle Tabellenschema. Erfolgreiche SDK-Aufrufe liefern { ok: true, data: ... }; fehlgeschlagene Aufrufe lösen einen Fehler aus. Zeige ihn an, statt ihn als leeres erfolgreiches Ergebnis zu behandeln.

Erstelle die ausstehende Eingabe einmal je beabsichtigtem Datensatz und behalte sie für eine Wiederholung bei unklarem Ausgang:

const pending = {
  invocationId: ennea.dataSources.createInvocationId(),
  values: { status: "open" },
  tableVersion: table.version,
  expectedTableId: table._id,
};
const created = await ennea.dataSources.create("requests", pending);
const row = created.data.row;

Übergebe alle Pflichtfelder oder passende Schemastandards. Behalte dieselbe Aufruf-ID und unveränderte Werte, bis der Ausgang bekannt ist; geänderte Daten unter derselben ID werden abgewiesen. Verwende eine neue ID erst für einen anderen Datensatz. Eine frühere Wiederholung kann einen gelöschten Datensatz nicht neu anlegen. Starte nach unklarer Antwort nicht automatisch eine neue Erstellung.

Änderungen und Löschungen verwenden die Version des Datensatzes, den der Benutzer geprüft hat:

const updated = await ennea.dataSources.update("requests", {
  rowId: row._id,
  expectedVersion: row.version,
  values: { status: "done" },
});
const latestRow = updated.data.row;
// Nur ausführen, wenn der Benutzer diesen Datensatz gesondert löschen möchte:
await ennea.dataSources.delete("requests", {
  rowId: latestRow._id,
  expectedVersion: latestRow.version,
});

Das Beispiel setzt außerdem den erlaubten Auswahlwert done voraus. Änderungen ergänzen die übergebenen Felder in den bestehenden Werten. Behalte bei einem Versionskonflikt die Benutzereingabe, lade den Datensatz neu, vergleiche die Änderungen und lass den Benutzer vor erneutem Speichern entscheiden. Das optionale tableVersion erkennt zusätzlich ein geändertes Schema.

aggregate verwendet alle gefilterten Datensätze statt der aktuellen Seite:

const summary = await ennea.dataSources.aggregate("requests", {
  groupBy: ["status"],
  metrics: [{ id: "count", op: "count" }],
  limit: 100,
});
const { groups, totalGroups } = summary.data;
// Jede Gruppe besitzt key.status und values.count.

Eine App kann bis zu 30 Datenquellen verbinden. Abfragen liefern höchstens 200 Datensätze je Seite mit bis zu 20 Filterregeln und drei Sortierspalten. Zusammenfassungen unterstützen höchstens drei Gruppierungsspalten und zehn Kennzahlen (count, sum, avg, min, max); Berechnungen außer Zählungen benötigen Zahlenspalten. Mehrfachauswahlspalten können weder sortiert noch gruppiert werden. Zusammenfassungen verarbeiten höchstens 10.000 passende Datensätze und liefern bis zu 200 Gruppen. Prüfe totalGroups, bevor du ein vollständiges Diagramm anzeigst, und grenze bei Bedarf den Filter ein; stelle keine unvollständige Auswahl stillschweigend als Ganzes dar.

Starte SDK-Schreibvorgänge über einen ausdrücklichen Button-Klick (type="button"). Prüfe Eingaben mit form.reportValidity() und behandle die Eingabetaste bei Bedarf direkt. Die App-Sandbox blockiert das native Absenden von Formularen; ein Submit-Button oder der onSubmit-Handler eines Formulars kann deshalb keine Datensätze speichern.

Lade Datensätze in einem Effekt, der Antworten zu einer früheren Auswahl oder einem früheren App-Kontext verwirft. Frage nach bestätigten Änderungen und bei benötigten aktuellen Daten erneut ab; ein eigener Blueprint übernimmt nicht automatisch die regelmäßige Aktualisierung einer nativen Ansicht. Zeige Lade-, Leer-, Berechtigungs-, Validierungs-, Konflikt- und Wiederholungszustände und behalte Eingaben nach Fehlern. Verbinde eine separate App-Automatisierungsaktion, wenn eine Benutzerinteraktion zusätzlich einen Workflow starten soll.

Speichere expectedTableId vor dem Senden zusammen mit der offenen Eingabe. Damit bleibt eine fortgesetzte Anfrage auch nach App-Veröffentlichung an die geprüfte Tabelle gebunden. Zeigt der Alias auf eine andere Tabelle, erfordert app_data_source_changed einen Abgleich am ursprünglichen Ziel; erzeuge die Anfrage nicht automatisch in der neuen Tabelle.

Prüfen und veröffentlichen​

Speichere den Entwurf, teste ihn mit vereinbarten Testdatensätzen und veröffentliche ihn über den normalen App-Ablauf. Prüfe als vorgesehener Benutzer das Erstellen, erneute Öffnen, Filtern, Bearbeiten und Löschen. Datensätze bleiben auch nach einer neuen App-Veröffentlichung gespeichert.

Eine Datenquelle erweitert keinen Zugriff über Mandant, Standort, Umgebung, App-Zielgruppe oder Benutzerberechtigungen hinaus. Gleichzeitige Änderungen führen zu einem Konflikthinweis statt zum unbemerkten Überschreiben. Fehlgeschlagene Speichervorgänge behalten Eingaben; unsichere Erstellungsvorgänge lassen sich sicher wiederholen. Berechtigungen sowie gesperrte oder gelöschte Datensätze bleiben durch die Plattform geschützt.