Eine Weboberfläche von Anfang bis Ende verwalten
Ein Dashboard einrichten, eine Ticketplattform über ihre eigene Verwaltungsoberfläche betreiben. Mehrstufige, angemeldete Arbeit – samt der Reibungen, die unterwegs auftraten.
Der schwerste der Vorführfälle, und der, der am meisten darüber sagt, was ein Agent tatsächlich tragen kann: eine Verwaltungsoberfläche so bedienen, wie es ein Mensch täte, über mehrere Schritte, hinter einer Anmeldung.
Nicht Konfigurationsdateien von Hand bearbeiten für Schritte, für die es die Oberfläche gerade gibt.
Ein selbst gehostetes Dashboard einrichten
Ein Betreiber installiert ein Monitoring- oder Webanalyse-Dashboard hinter einem Reverse Proxy: ein Dashboard anlegen, eine Datenquelle anbinden, eine Alarmregel setzen. Alles über die Oberfläche, gesteuert vom Agenten.
Das schließt Ziele hinter einer HTTP-Basic-Abfrage auf Netzwerkebene ein – der Art, die ein Reverse Proxy vor alles setzt:
{"http_credentials": true, "url": "https://target.local/admin", "actions": [...]}
Bestätigt an einer echten, per Proxy geschützten Oberfläche statt an einer
synthetischen Testseite: Die aus dem verschlüsselten Verzeichnis aufgelösten
Zugangsdaten beantworteten die Abfrage beim ersten Versuch. Das Szenario nennt
trotzdem kein Geheimnis – http_credentials weist Diwall an, sie aus diesem
Verzeichnis zu lesen, beschränkt auf diesen Ursprung.
Eine Ticketplattform betreiben
Über mehrere Sitzungen: Einrichtung der Veranstaltung, Ticketkategorien, eine eigene Domain und das Einlasswerkzeug für den Veranstaltungstag. Echte Konfigurationsarbeit, über dieselbe Weboberfläche, die ein menschlicher Administrator benutzen würde.
Es war keine reibungslose Erfolgsgeschichte, und gerade deshalb lohnt es sich, davon zu berichten.
Die Sitzungsbehandlung musste erst erarbeitet werden. Ein Auswahlmenü verhielt sich unerwartet. Eine Berechtigungsabfrage blockierte einen unbeaufsichtigten Schritt und musste ausdrücklich behandelt werden.
Nichts davon waren Probleme von Diwall. Es waren gewöhnliche Hindernisse der Web-Automatisierung – dieselben, auf die jeder stößt, der diese Oberfläche automatisiert. Eine Vorführung, die sie verschweigt, lehrt nichts darüber, was die Arbeit wirklich kostet.
Für jedes gibt es jetzt ein Rezept:
Was diesen Fall funktionieren lässt
Ein Aufruf für alles mit Zustand. Anmelden, handeln, bestätigen – in einem einzigen Aufruf. Auf mehrere Aufrufe verteilt, geht der DOM-Zustand still verloren.
Eine Prüfung am Anfang. Ist die Seite nicht die erwartete, anhalten, bevor irgendwo irgendetwas eingetippt wird.
Das verschlüsselte Verzeichnis für alle Zugangsdaten. Das Szenario bleibt committbar, weil es Schlüssel nennt, nie Werte.
Signale lesen, nicht nur das Urteil. Nach jedem Schritt: Wo bin ich wirklich, was hat der Server gesagt, hat die Sitzung gehalten?
Wo es aufhört
Operationen von mehreren Minuten passen schlecht – man sieht das Ende, nicht die Mitte, und ein Zeitlimit bedeutet keinen Fehlschlag. Massenänderungen laufen besser über eine API, wenn es eine gibt. Und nichts hier lässt sich rückgängig machen: Diwall führt die Liste aus, die Sie geschrieben haben.
Warum dafür kein Szenario mitgeliefert wird. Ein Dashboard-Layout, Namen von Datenquellen, eine Ticketkonfiguration – alles ist spezifisch für die Infrastruktur eines Betreibers. Ein synthetisches Gegenstück zu erfinden, würde nichts zeigen, was der ausführbare lokale Fall nicht schon abdeckt.