Den Rettungsdienst aufbauen und betreuen
Dieselbe Sternwacht aus Sicht der Administration. Die Bäckerei zeigt die Grundlagen: Spaces, Workflows, Views und Rechte. Hier geht es um das, was ein Betrieb darüber hinaus braucht: Skripte, die Abläufe automatisieren und prüfen, besondere Felder, mehrere Benutzerkonten pro Person und die Möglichkeit, alles auszuprobieren, ohne Daten zu verändern. Die Bilder zeigen die Demo-Instanz mit dem Admin-Benutzer Kurt.
Ein Login, mehrere Konten
Die Demo zeigt es selbst: Ein einziges Login („Demo“) hat fünf Konten im Backend, die Benutzer Frank, Jean-Luc, Pria, Rita und Kurt, zwischen denen man umschaltet. Login und Backend-Konto sind getrennte Dinge. Man legt das eine oder das andere an oder verknüpft ein vorhandenes Backend-Konto mit einem Login.

Skripte am Workflow
Der Workflow „EinsatzWorkflow“ hat zwei Skripte: eines prüft, ob ein Einsatz starten darf, das andere legt bei einem Fehlschlag den Änderungsantrag an. Sie hängen am ganzen Workflow und laufen bei jedem Flow. Welcher es gerade ist, liest das Skript selbst aus. Die Priorität legt die Reihenfolge fest (die Prüfung hat 10), und jedes Skript lässt sich einzeln deaktivieren, entfernen oder durch ein weiteres ergänzen.

Skripte gefahrlos testen
Ein Skript hat Folgen: Es legt Datensätze an, ändert Felder, löst weitere Skripte aus. Deshalb gibt es im Skript den Bereich „Testen“. Hier ist es das Skript, das das Rezept „revisions“ mitbringt und das eine neue Revision samt Stückliste anlegt. Man wählt die Art (hier „RUNNABLE“), den Space und einen Datensatz, optional auch einen anderen Benutzer, und führt das Skript aus. Der Server rollt alles zurück. Das Ergebnis zeigt die Ausgabe, den Rückgabewert und die Ereignisse, die das Skript ausgelöst hätte, ohne dass sie ausgeführt werden. Eine Ausnahme nennt die Seite offen: Ein externer Aufruf wird wirklich abgeschickt.

Gruppen in einer Maske
Die Crew im Einsatz ist eine Gruppe: eine kleine Tabelle in der Maske des Einsatzes mit einer Zeile je Zuordnung. Im Group-Builder stellt man sie zusammen: welche Beziehung die Zeilen liefert, wie sie heißt und sortiert wird, ob Zeilen hinzugefügt oder entfernt werden dürfen und welche Spalten erscheinen, aus dem verknüpften Datensatz und aus dem Detail-Space der Beziehung. Unten zeigt der Builder den Befehl, der daraus entsteht.

Besondere Felder
Das Crewmitglied zeigt zwei Dinge, die über einfache Felder hinausgehen. Die Nummer ist ein automatischer Zähler mit Präfix und Länge („CM-“, drei Stellen): Der Server vergibt sie selbst, niemand tippt sie ein. Und die Beziehung zu den Einsätzen trägt einen Detail-Space: Zu jeder Zuordnung „Crewmitglied in Einsatz“ gehört ein eigener Datensatz, hier die Funktion im Einsatz. Er gehört der Zuordnung („OWNED“) und verschwindet mit ihr.

Menü und Rollen
Das Menü ist Daten wie alles andere: Jeder Eintrag hat ein Label, eine Sortierung, die View, die er öffnet, und die Rollen, die ihn sehen. Einträge ohne Rolle sehen alle. Einträge mit Rollen sehen nur diese, so bekommt der Disponent „Neue Notrufmeldung“, die Technikerin die Wartungsprotokolle und der Qualitätsmanager die Änderungsaufträge.

Alles als Befehle
Jede Seite hat den Link „Befehle anzeigen“. Er zeigt die Befehle, mit denen sich genau dieses Objekt neu erstellen lässt, hier den Space „Einsatz“ mit Feldern, Workflow, Label-Skript und Flow-Bedingung. Das ist praktisch zum Dokumentieren, für Kopien in andere Instanzen und zum Lernen, wie sich etwas im Browser Geklicktes in der Sprache des Servers ausdrückt.
