Und wieder durch fünf Systeme klicken …

Vor jeder Lieferung derselbe Weg: Setup anlegen oder ein bestehendes nehmen, anmelden, Mail dorthin schicken, im nächsten System nachsehen. In Penguflow klickt man diesen Weg einmal zusammen und startet ihn danach per Knopfdruck, so oft man will.

Penguflow herunterladen Zugang anfragen

Weboberfläche · Station 1

Anmeldeformular

Formular ausfüllen, absenden. Die Mailadresse erzeugt der Lauf selbst; eine feste wäre beim zweiten Durchgang längst vergeben.

gibt weiter {{mailadresse}}

app.example.org/registrieren

Konto anlegen

E-Mail kunde-7f3@postfach.test

Passwort ••••••••••

Konto anlegen merkt sich → {{mailadresse}}

Postfach · Station 2 Treiber geplant

Bestätigungsmail

Ab hier ein anderes System. Die Mail braucht ein paar Sekunden, also wird gewartet, bis sie da ist. Aus ihr kommt der Bestätigungslink.

gibt weiter {{bestaetigungslink}}

postfach.test/kunde-7f3

Posteingang

app.example.org vor 3 s Bitte bestätige deine Adresse

https://app.example.org/bestaetigen?t=9f2a41c7 wartet · 7 Versuche, 3,1 s liest → {{bestaetigungslink}}

Weboberfläche · Station 3

Erste Anmeldung

Link öffnen, anmelden. Geht das durch, hat der Vorgang drei Systeme hinter sich.

Ende der Kette

Willkommen

Konto bestätigt

Angemeldet als kunde-7f3@postfach.test

prüft: Text „Konto bestätigt" erscheint

Ein Pinguin, drei Systeme — und trotzdem nur ein Testprozess.

Für wen

Alle, die denselben Ablauf immer wieder brauchen.

Es ist derselbe Ablauf, nur der Anlass ist jedes Mal ein anderer. Gemeint sind Teams, für die ein eigenes Testautomatisierungsteam nicht in Frage kommt: ein paar Systeme, ein Dutzend Lieferungen im Jahr — und davor jedes Mal jemand, der von Hand durchklickt.

Entwickler

Vor dem Einchecken, lokal

Gegen die eigene Maschine, mit den eigenen Zugangsdaten. Einmal zusammengeklickt, läuft er auf Knopfdruck — auch beim vierten Mal an diesem Vormittag.

Product Owner

Dauerhaft gegen die Testumgebung

Gegen eine Umgebung, die bestehen bleibt, und immer wieder statt einmal vor der Abnahme. Eine Verschiebung in der Landschaft fällt damit auf, solange sie noch billig zu beheben ist.

Tester

Das Ökosystem, nicht die Maske

Portal, ERP-Maske, Archiv: drei Anmeldungen, ein Vorgang, ein Protokoll. Was zwischen den Systemen passiert, deckt keine der einzelnen Testsuiten ab. Dort sitzen die Fehler, die niemandem gehören.

Key User

Abnahme mit Nachweis

Den Ablauf einmal zusammenklicken, bei jeder Lieferung wieder fahren. Zeiten, Werte und Wiederholungen stehen danach im Protokoll und gehen so in die Abnahme.

Support

Einen Fall nachstellen

Was im Ticket steht — Kundennummer, Artikel, Menge — geht als Eingabe in den Prozess, und der stellt den Fall selbst wieder her, quer über alle Systeme. Mit anderen Werten noch einmal. Von Hand klickt das jedes Mal jemand nach, und beim dritten Durchgang weiß niemand mehr, was im ersten drinstand.

Betrieb

Nach dem Wartungsfenster

Zertifikat erneuert, Schnittstelle umgestellt, Release eingespielt: einmal durch die Landschaft fahren und sehen, ob der Vorgang noch durchkommt. Meist weiß das sonst erst der erste Anrufer am Morgen.

Dazu kommt der Fall, an den zuletzt jemand denkt: eine Ablösung. Denselben Ablauf gegen Alt- und Neusystem fahren und die beiden Protokolle nebeneinanderlegen — das ist der ehrlichste Vergleich, den man bekommen kann.

Ein Ablauf, mehrere Umgebungen

Was sich unterscheidet, sind Werte

Der Entwickler fährt gegen die eigene Maschine, der Product Owner gegen Staging, der Key User gegen die Abnahme. Verschieden sind dabei eine Adresse, ein Benutzer, ein Passwort — nicht der Ablauf. Eine Umgebung ist genau das: ein benannter Satz Startwerte, der beim Start in den Lauf gelegt wird.

Zugangsdaten

Passwörter bleiben auf dem Rechner

Eine Umgebung lässt sich als privat anlegen. Die liegt dann in einem eigenen Ordner, der sich selbst aus der Versionsverwaltung heraushält — nicht als Bitte an den Nutzer, sondern als Tatsache. Dorthin gehört auch, was vor der Seite steht: Basic, ein Proxy, ein Client-Zertifikat. Und auf einem Rechner in der Domäne steht gar kein Passwort im Testfall — der Browser meldet sich mit dem Ticket an, das der angemeldete Benutzer ohnehin hat.

Die Lage

Das frische Backend ist die bequemste Annahme im Test.

Ein Lauf in der Pipeline fängt bei null an: leere Datenbank, Migrationen durch, ein paar Datensätze gesät, und was hinter der ersten Systemgrenze liegt, ist ohnehin ein Mock. Zwölf Minuten später ist alles wieder weg. Für die Anwendung selbst ist das genau richtig, und niemand sollte damit aufhören.

Nur ist das nicht die Lage, in der ein Geschäftsprozess stattfindet. Dort steht ein ERP mit vierhunderttausend Buchungen, ein Postfach mit Historie, ein Austauschordner, in dem noch die Dateien von gestern liegen. Nichts davon lässt sich zurücksetzen. Die Hälfte gehört einer anderen Abteilung. Und alles davon ist morgen noch da.

Merkmal	Im Pipeline-Lauf	In der Landschaft
Datenbestand	leer, dann gesät	gewachsen, fremd, nicht abzählbar
Nachbarsysteme	gemockt oder abgeschaltet	echt, und am Prozess beteiligt
Zurücksetzen	vor jedem Lauf	nie
Fremde Last	keine	Nachtimport, Fachabteilung, Schnittstellen
Ausgelöst durch	einen Commit	die Uhr — die Systeme ändern sich auch ohne Zutun

Die Bedingung

Alle Systeme müssen erreichbar sein

Das ist der Preis dafür, dass nichts gemockt wird: Steht eines der beteiligten Systeme, steht der Lauf. Penguflow kann nichts vortäuschen, was gerade nicht da ist. Im Protokoll steht dann, welches System nicht geantwortet hat.

Der naheliegende Einwand

Werkzeuge dafür gibt es

Tricentis Tosca, Worksoft Certify, UFT One und Leapwork fahren Prozesse über Web, SAP, Mainframe, Postfach und Datenbank — seit Jahren. Wer sie hat, braucht uns nicht. Nur: Keiner der vier veröffentlicht einen Preis, und keinen davon probiert man vor dem Vertriebsgespräch aus. Playwright und Cypress hat dagegen fast jeder — und die fahren einen Browser, das war es. Was dazwischen fehlt, ist der Grund für Penguflow.

Ihre Systeme, Ihr Netz

Nichts verlässt das Haus

Penguflow läuft als Anwendung auf dem Rechner, an dem Ihre Systeme hängen. Testprozesse, Protokolle, Bildschirmfotos, Mitschnitte und die Zugangsdaten der geprüften Systeme bleiben dort. Nach außen geht die Anmeldung und die Aktualisierung — kein Bildschirminhalt, keine Testdaten, nichts zur Auswertung. Werkzeuge, die Elemente über Bilderkennung finden, schicken dafür Bildmaterial an ihren Anbieter.

Kein Ersatz

Die Pipeline bleibt, wo sie ist

Unit-Tests, Komponententests, der schnelle E2E-Lauf beim Commit: alles behalten. Penguflow ist die Schicht darüber — die Frage, ob der Vorgang durch fünf Systeme kommt, stellt sich erst, wenn jedes davon für sich schon in Ordnung ist.

Die Rechnung

Jedes Feature prüft zweimal: das Neue und alles, was schon da war.

Das ist keine schlechte Angewohnheit, sondern die Definition. Der eine Teil gilt dem Neuen, der andere heißt Regression und gilt dem Rest. Beide gehören zusammen, weil nicht das Feature ausgeliefert wird, sondern der Stand: Der Nachweis, dass das Neue geht, ist ohne den Nachweis, dass das Alte noch geht, keiner.

Unten fällt das niemandem auf. Hunderte Unit-Tests laufen bei jedem Speichern durch, der nächste kostet Millisekunden. Nach oben kippt die Rechnung: Dort zahlt man nicht die Prüfung, sondern das, was vor ihr steht — Umgebung hochfahren, anmelden, Daten anlegen, warten, bis das Nachbarsystem so weit ist. Und zwar je Lauf, nicht je Prüfung.

Prüfung	Was sie über den Vorgang sagt	Was eine Wiederholung kostet
Unit-Test	nichts — er kennt eine Funktion	Millisekunden
Test einer Anwendung	ob sie für sich in Ordnung ist	Sekunden, in der Pipeline
E2E über eine Oberfläche	einen Ausschnitt, bis zur ersten Systemgrenze	Minuten — und unter Last wird er rot
Der Vorgang über fünf Systeme	alles, worauf es ankommt	in der Praxis: ein Mensch, ein Vormittag

Die letzte Zeile lässt sich automatisieren, und die Werkzeuge dafür gibt es. Bezahlt wird sie trotzdem meistens in Personenzeit — weil sie erst ab einer Größe angeboten wird, ab der ein eigenes Testautomatisierungsteam danebensteht. Zwanzig Vorgänge sind zwanzigmal so viel Arbeit wie einer, vor jeder Lieferung, und das ist die einzige Zeile, von der schnellere Rechner nichts abziehen. Sie sagt am meisten und wird am seltensten wiederholt — gestrichen wird zuerst, worauf es ankommt.

Pflege

Eine Änderung, zwanzig kaputte Abläufe

Ein Pflichtfeld mehr im Anmeldeformular ist im System eine Zeile. Für die Tests ist es jeder Ablauf, der sich anmeldet, und das sind fast alle. Steht das Anmelden als Kopie in jedem davon, sind es zwanzig Stellen zum Nachziehen. Deshalb ruft hier ein Prozess einen anderen auf: „Anmelden" gibt es einmal.

Wer prüft

Lesen können heißt ändern können

Was fachlich richtig ist, weiß der Fachbereich. Hinschreiben konnte es bisher nur, wer Skripte schreibt — und damit wartet die eine Seite auf die andere. Ein Ablauf, der als Satz dasteht, lässt sich von der Seite ändern, die den Fall kennt.

Der übliche Ausweg

Weniger prüfen, dafür schneller fertig

Nach Risiko auswählen, priorisieren, den Rest streichen. Das funktioniert, und es kostet jedes Mal dasselbe: Man weiß hinterher weniger. Die andere Richtung ist, die Wiederholung billig zu machen, statt sie zu kürzen.

Wiederholbar

Beim zweiten Mal ist der Kunde schon angelegt.

Das ist die eigentliche Arbeit beim Testen gegen Bestand. Ein Ablauf, der auf leerem Stand funktioniert, läuft genau einmal: Beim nächsten Durchgang ist die Adresse vergeben, die Nummer existiert, die Datei liegt schon im Ordner. Wiederholbarkeit heißt hier deshalb etwas anderes als in der Pipeline — nicht „vorher alles zurücksetzen", sondern „sich auf nichts verlassen, was der Lauf nicht selbst erzeugt hat".

Das ist keine Einstellung, die man anschaltet. Es sind drei Gewohnheiten, und für jede davon gibt es ein Feld im Formular.

Eigenes Kennzeichen

Jeder Lauf bringt sein eigenes mit

Startwerte gehören zum Testprozess: eine frische Mailadresse, ein Kennzeichen im Bestelltext. Damit stolpert der 200. Lauf nicht über das, was der 199. hinterlassen hat — und man erkennt hinterher, welche Daten aus einem Test stammen.

Korrelation

Der eigene Vorgang, nicht der erste Treffer

„Die oberste Zeile in der Liste" ist morgen eine andere Bestellung. Deshalb merkt sich der Lauf die Nummer, die er erzeugt hat, und sucht später genau die — auch noch drei Systeme weiter, wo sie unter anderem Namen auftaucht.

Warten

Andere arbeiten auch

In einer echten Landschaft ist man nicht allein: nachts der Import, tagsüber die Fachabteilung. Ein Schritt wartet deshalb, bis er durchgeht, statt eine feste Pause einzubauen. Im Protokoll steht danach, wie oft es gebraucht hat — und das ist die Zahl, an der man Ärger kommen sieht.

Die Kette

Ein Prozess läuft durch Systeme. Nicht in einem.

Weil die Systeme bleiben, hängen sie auch aneinander. Und darin liegt der Grund, warum man sie nicht einzeln prüfen und die Ergebnisse hinterher zusammenzählen kann: Die zweite Station lässt sich weder überspringen noch vorbereiten. Den Bestätigungslink gibt es nur, weil das Formular abgeschickt wurde. Die Bestellnummer entsteht im Portal und wird im ERP gebraucht.

Genau an dieser Stelle hört das Werkzeug auf, das im Team schon liegt: Playwright, Cypress und Selenium fahren einen Browser, und das war es. Für alles dahinter schreibt jemand ein Skript, das den Rest von Hand nachbaut und das nach einem halben Jahr niemand außer seinem Autor mehr anfasst. Wer die Kette zerschneidet, testet ab da nur noch Attrappen.

Daher der Name. Pinguine laufen in einer Kette hintereinander her — einer hinter dem anderen, und keiner überholt. Genauso läuft ein Geschäftsprozess durch seine Systeme.

Der Sprung

Von A nach B führt ein Klick

Ins nächste System kommt man über einen Knopf im vorigen: absenden, freigeben, buchen. Einfach die Adresse von B aufzurufen bringt nichts — dort steht dann noch gar nichts.

Kein Vorbereiten

Den Zustand kann man nicht hinstellen

Man kann das ERP nicht „in die Lage nach der Bestellung" versetzen und dort anfangen. Diese Lage entsteht ausschließlich dadurch, dass im Portal wirklich bestellt wurde — mit allem, was dazwischen schiefgehen kann.

Ein Lauf, ein Protokoll

Fünfmal grün ist nicht dasselbe

Fünf Systeme, die jedes für sich in Ordnung sind, ergeben noch keinen Vorgang, der durchkommt. Was zwischen ihnen passiert, sieht man nur an einem durchgehenden Lauf — und der schreibt ein Protokoll, das die Übergänge mitzählt.

In der Tiefe

Eine Bestellung, fünf Systeme, ein Testprozess.

Eine Bestellung geht im Portal ein, löst eine Mail aus, landet über einen Austauschordner im ERP, erzeugt dort eine Buchung, und irgendwann taucht ein Beleg im Archiv auf. Fünf Systeme, fünf Zugangsarten — und eine Bestellnummer, die durch alle hindurchgeht.

Weboberfläche Bestellportal Formular ausfüllen, absenden, Nummer vom Bildschirm ablesen. Treiber da
Postfach Eingangsbestätigung Warten, bis die Mail zur Bestellnummer eintrifft. geplant
Dateiablage Austauschordner Auf eingang/{{bestellnummer}}.json warten. geplant
Datenbank ERP-Buchung Prüfen, dass die Buchung zur Nummer entstanden ist. geplant
Weboberfläche Belegarchiv Der Beleg taucht auf. Damit ist die Bestellung durch. Treiber da

Die Marken an den Stationen zeigen, was heute schon geht: Ausgeliefert ist der Web-Treiber. Für die übrigen Stationen steht die Architektur, der Treiber selbst noch nicht. Der Stand weiter unten führt es auf.

Laufprotokoll — so liest sich eine Kette

0.6s  ▶ Bestellportal
0.8s    Fülle Feld "Artikel" mit "Dachziegel rot"
1.1s    Klicke button "Bestellung aufgeben"
1.4s    Test-Id "bestellnummer": "B-B477B577"
1.4s    bestellnummer = B-B477B577
1.4s  ✓ Bestellportal

1.4s  ▶ Eingangsbestätigung            ← Systemgrenze
1.5s    noch nicht so weit: keine Mail an kunde@example.org.
3.1s  ✓ Eingangsbestätigung   (5 Versuche, 1.7 s)

3.1s  ▶ Austauschordner                ← Systemgrenze
3.1s    noch nicht so weit: eingang/B-B477B577.json ist nicht da.
6.2s  ✓ Austauschordner       (7 Versuche, 3.1 s)

6.2s  ▶ ERP-Buchung                    ← Systemgrenze
6.9s  ✓ Buchung zu B-B477B577 gefunden

Genau diese Wiederholungen sind der Unterschied zwischen einem Test, der durchläuft, und einem, der unter Last rot wird. Sie stehen im Protokoll, statt in einer festen Pause versteckt zu sein — und eine Station, die gestern einen Versuch brauchte und heute sechs, ist ein Befund, auch wenn sie grün ist.

Aufbau

Zwei Begriffe, und einer davon ruft sich selbst auf.

Ein Prozess ist ein System oder ein Anwendungsfall, den man gekapselt testen will. „Bestätigungsmail abholen" ist technisch dreierlei — warten, öffnen, Link herauslesen — aber gedacht ist es eines. Wer nur Schritte aneinanderreiht, schreibt Abläufe, die niemand liest, und wiederholt dieselben fünf Klicks in jedem davon.

Tiefe entsteht dadurch, dass ein Prozess einen anderen aufruft. Es gibt keine dritte Ebene und keine vierte — „Bestellprozess" enthält „Anmelden" enthält „Formular ausfüllen", und es gab nie einen Grund, bei drei aufzuhören.

Prozess · Registrierung

Registrierung Prozess

└─ konten ← Konto anlegen ×5 Aufruf

├─ Fülle Feld „E-Mail" mit test-{{n}}@… Schritt

└─ Klicke button „Konto anlegen" Schritt

└─ mails ← Bestätigungsmail abholen je konten Aufruf

└─ Lies Link aus der Mail → {{link}} Schritt

Begriff	Was es ist
Prozess	Ein benannter Ablauf, streng nacheinander — Verzweigungen gibt es nicht. Seine erste Zeile ruft eine Seite auf oder einen anderen Prozess; in seinen Eingaben steht, was er von außen braucht. Für sich startbar und von anderen aufrufbar.
Schritt	Eine Aktion auf einem Element. Darf sich Werte merken — und das ist es, was über die Systemgrenze getragen wird.
Aufruf	Ein Prozess ruft einen anderen. Hier steht auch, wie oft: eine feste Zahl oder einmal je Eintrag einer Liste von vorher.
Bag	Was ein Prozess liefert: alles, was er sich gemerkt hat, samt den Ergebnissen seiner Aufrufe. Der Aufrufer legt es unter dem Namen ab, den er selbst vergeben hat.

Es gibt kein Schleifenkonstrukt. Wer fünf Konten anlegen will, ruft „Konto anlegen" fünfmal auf — Wiederholung ist keine Zeile im Ablauf, sondern eine Zahl an einer Kante, wie eine Menge in einer Stückliste. Der gerufene Prozess merkt davon nichts: Er bekommt seine Werte und tut sein Ding.

Und es gibt keine Verzweigung. Ein Prozess läuft von oben nach unten durch, ohne „wenn … dann". Das ist eine Entscheidung und keine fehlende Zeile: Ein Ablauf mit zwei Ausgängen liest sich beim dritten „wenn" nicht mehr wie ein Satz, und ein Testfall, der je nach Datenlage etwas anderes tut, prüft an manchen Tagen etwas, das niemand nachgesehen hat. Wer zwei Fälle hat, baut zwei Prozesse und ruft den passenden auf. Der Preis, damit er genannt ist: „wenn der Kunde schon existiert, überspringe das Anlegen" geht so nicht — dafür sorgt man dafür, dass er es nicht tut, und legt sich seinen eigenen an.

Der Name eines Prozesses darf Eingaben enthalten. Bestellung aufgeben: {{artikel}} × {{menge}} steht im Ablauf dann als Bestellung aufgeben: Dachziegel rot × 250 — die Kette liest sich wie ein Satz und nicht wie eine Aufrufliste.

Der Weg

Aufnehmen, durchgehen, starten.

Niemand baut einen Ablauf aus dem Kopf zusammen. Man macht ihn einmal von Hand — so wie sonst auch — und Penguflow schreibt mit. Die Arbeit danach ist eine einzige Runde, und die entscheidet, ob der Ablauf beim zweiten Mal noch funktioniert.

01

Adresse eintragen

Die erste Zeile ruft die Seite auf, bei der es losgeht. Das eingebaute Browserfenster öffnet genau diese Adresse — dieselbe, gegen die später gelaufen wird.
02

Aufnahme an, dann einfach arbeiten

Bedienen wie immer: klicken, tippen, absenden. Mitgeschrieben wird, was getan wurde. Wechselt der Vorgang das System, fängt dort automatisch ein neuer Prozess an — die Aufnahme teilt den Ablauf an genau den Systemgrenzen.
03

Einmal durchgehen

Für jeden getippten Wert entscheiden, woher er kommt. Ohne diese Runde bekommt man einen Ablauf, der genau einmal funktioniert: mit den Daten von damals.
04

Starten

Ab jetzt läuft der Ablauf auf Knopfdruck, gegen die Umgebung, die man auswählt. Das Protokoll zeigt jeden Schritt, jeden gemerkten Wert und jede Wiederholung.

Aufgenommen: Fülle Feld „E-Mail"

Getippt wurde kunde-7f3@postfach.test

fester Wert immer dieser Text

Parameter {{mailadresse}} — beim Einsetzen mitgegeben

aus dem Kontext was ein früherer Schritt gemerkt hat

Passwörter

Kommen ohne Wert an

Sie stehen fest auf „Parameter" und lassen sich nicht auf einen festen Wert stellen. Was hier einzutragen wäre, stünde im Klartext in einer Datei im Arbeitsbereich. Der Wert kommt aus einer privaten Umgebung, die auf dem Rechner bleibt.

Ohne KI

Was grün ist, ist auch passiert

Was einmal ausgewählt wurde, steht im Ablauf und wird beim nächsten Lauf nicht neu gedeutet. Findet ein Schritt sein Element nicht, wird er rot — er sucht sich kein ähnliches. Selbstheilung spart Pflege und kostet genau die Aussage, um die es bei einer Abnahme geht: Wo ein Modell zur Laufzeit entscheidet, was gemeint war, beweist ein grüner Lauf nicht mehr, dass das Aufgeschriebene passiert ist.

Und bevor der erste Klick fällt, wird gerechnet: Ein Schritt, der einen Wert benutzt, den keine frühere Station abgelegt hat, ist kaputt. Beim Laufen fiele das erst auf, wenn schon drei Systeme angefasst sind.

Befunde vor dem Lauf

FEHLER  steps[0].action.path
        {{bestellnummer}} ist hier noch nicht belegt —
        keine frühere Station legt den Wert ab.

Betrieb

Automatisch heißt nicht: beim Commit.

Ein Vorgang über mehrere Systeme lässt sich an keinen Commit hängen. Die Systeme gehören nicht dem Repository — sie ändern sich, weil jemand eine Schnittstelle umgestellt, ein Zertifikat erneuert oder ein Wartungsfenster genutzt hat. Der Anlass ist deshalb die Uhr und nicht der Commit: jede Nacht, vor der Abnahme, nach dem Wartungsfenster.

Gestartet wird heute von Hand. Zeitplan, Verlauf und Bescheid geben, wenn ein Lauf kippt, stehen im Stand unter „Als Nächstes“ — bis dahin drückt jemand den Knopf.

Ein roter Lauf heißt dann nicht „dein letzter Commit war falsch", sondern „in der Landschaft stimmt etwas nicht" — und meistens weiß das sonst noch niemand.

Dazu muss der Läufer dort stehen, wo die Systeme stehen. An einen Austauschordner hinter der Firmen-Firewall, an eine Datenbank ohne Zugang von außen, an ein internes Portal ohne Route aus dem Netz kommt ein Server im Rechenzentrum nie heran. Deshalb gibt es Penguflow auch als native Anwendung. Das ist kein Zugeständnis an Offline-Nutzer: ohne sie fehlt die halbe Kette.

Möglich ist das, weil es einen Server gibt, und zwar als Bibliothek statt als Programm. createApp(deps) liefert die fertige API; wer sie startet, ist eine andere Frage. Der Unterschied zwischen Webdienst und nativer Anwendung sind drei Schnittstellen für die Ablage. Darüber ist alles identisch — dieselben Routen, dieselbe Ausführung, dasselbe Studio.

Ein Weg nach draußen

Studio (Web-UI) ──HTTP──▶ Server ──▶ Runner ──▶ Treiber ──▶ die Kette

Webdienst:  Server im Container
Nativ:      Server + Runner + UI in einem Electron-Prozess

Kein zweiter Datenweg

Nichts, was nur in einer Welt geht

Das Studio spricht ausschließlich per fetch gegen dieselbe Herkunft — im Browser wie in Electron. Keine Electron-Brücke, kein window.electron. Damit gibt es auch nichts, was in einer der beiden Welten anders funktioniert.

Echte Engines

Chromium, Firefox, WebKit

Ein Firefox-Kennstring macht aus Chromium keinen Firefox. Wer Firefox testen will, wählt Firefox — und dazu Fenstergröße, Bildpunktdichte und Berührungseingabe, denn „iPhone" in einem 1280 Pixel breiten Fenster ist ein Layout, das kein Mensch je zu sehen bekommt.

Ein Download. Sonst nichts.

Penguflow für Windows

Herunterladen Noch kein Konto? Zugang anfragen

✓Studio, Server und Runner in einem Fenster
✓Chromium liegt daneben, wird nicht nachgeladen
✓Keine Abhängigkeiten, keine Laufzeitumgebung
✓Läuft dort, wo die Systeme stehen — auch ohne Zugang von außen

Stand

Was läuft — und was noch nicht.

Penguflow ist in Arbeit, und eine Marketingseite ohne diesen Abschnitt wäre unglaubwürdig. Wie weit die Kette reicht, entscheiden die Treiber: Modell, Ausführung und Studio tragen sie bereits über beliebig viele Stationen, ausgeliefert ist bisher die Station Weboberfläche. Die übrigen kommen als Nächstes — dafür ist die Architektur gebaut. Eine Station steht nicht in dieser Reihe, und sie steht unter der Liste.

Läuft

✓Modell — Prozess, Schritt, Aufruf als reine Daten
✓Kontextfluss über Stationsgrenzen, samt Prüfung vor dem Lauf
✓Warten, bis die nächste Station so weit ist
✓Server als Bibliothek, mit Live-Protokoll
✓Studio zum Zusammenklicken, mit eingebautem Browserfenster
✓Native Anwendung mit eingebettetem Server
✓Ein Paket für Windows — Chromium liegt darin, keine Abhängigkeiten
✓Station Weboberfläche — drei Engines, Geräte mit Größe, Dichte, Berührung
✓Aufzeichnen — mitschreiben, was jemand tut, und daraus Prozesse machen

Als Nächstes

→Station Postfach — Mails auffangen und auslesen
→Station Dateiablage und HTTP — die kurzen Wege zwischen Systemen
→Station Datenbank — die Buchung prüfen, statt sie auf einer Maske zu suchen
→Nach Plan fahren — Zeitplan, Verlauf, Bescheid geben, wenn ein Lauf kippt
→Pakete für macOS und Linux — gebaut wird bisher nur für Windows
→Als Webdienst — Datenbank-Ablage, Mandanten, Anmeldung

Richclients kann Penguflow nicht bedienen

Eine Windows-Anwendung — SAP GUI, ein ERP-Client, ein Fachverfahren mit eigener Oberfläche — liegt außerhalb dessen, was heute geht. Nicht in Teilen und nicht mit Einschränkungen: Es gibt keinen Treiber dafür. Wer einen solchen Schritt im Vorgang hat, macht genau diesen weiterhin von Hand.

Der Weg dahin ist bekannt und führt über die Bedienhilfen von Windows — dieselbe Schnittstelle, die ein Screenreader benutzt. Dort stehen Knopf, Feld und Beschriftung mit Namen und Rolle, statt als Bildpunkte auf einem Bildschirmfoto; ein Ablauf, der auf Koordinaten klickt, bricht bei der nächsten Auflösung. Dazu gehören ein Läufer, der auf dem Rechner mit der Anwendung steht, und ein eigenes Verfahren zum Aufzeichnen: In eine Webseite sieht Penguflow beim Mitschreiben hinein, in eine fremde Anwendung nicht.

Das ist Arbeit für eine zweite Hauptfassung und nicht für das nächste Vierteljahr. Bis dahin steht es hier, damit es niemand im Gespräch herausfinden muss.