Jedes iFlow macht das nächste besser.

iFlow-Flywheel – Jedes iFlow macht das nächste besser – weil Regeln, Snippets, Tests und Doku aus dieser Runde in der nächsten schon da sind.

1. Bauen (XML-Werkstatt · Snippets, Community, im Produkt): Du baust im SAP-Editor wie gewohnt. Daneben liegen XSD-Editor, XSLT-Mapping als Grafik, XPath per Klick und Groovy-Snippets – ohne zweiten Tab. In der nächsten Runde: Was du letzte Runde als Snippet oder Sample gespeichert hast, ist jetzt Vorlage. Mit Pro entwirft Ask Tailor das nächste iFlow aus deiner Anforderung.
2. Prüfen (Quick Review, Community, im Produkt): Ein Klick: Health Score von 0 bis 100, Findings nach Schwere mit Begründung, Fundstelle und Fix. Ein Klick auf das Finding springt zum Step im Editor. In der nächsten Runde: Akzeptierte Risiken stehen mit Begründung da, die Team-Regeln prüfen mit. Der Score von heute ist die Messlatte für morgen.
3. Testen (Test Studio · Groovy Runner, Community, im Produkt): REST, OData und SOAP mit Environments und Assertions, auf Wunsch über den Cloud Connector. Mit Pro läuft das Groovy-Script im Runner gegen eine Beispiel-Payload, ohne Deploy. In der nächsten Runde: Collections und Test-Suites aus der letzten Runde laufen vor und nach dem Deploy noch einmal.
4. Vergleichen (Version Diff · Tenant Compare, Pro, im Produkt): Vor dem Transport: Version gegen Version, DEV gegen PRD. Der Changelog-Vorschlag landet im SAP-Dialog „Als Version speichern“. In der nächsten Runde: Die Versionshistorie zeigt, was seit deinem letzten Besuch neu ist – und wer es geändert hat.
5. Betreiben (Monitor · Fehleranalyse, Community, im Produkt): Fehlgeschlagene Nachrichten nach Ursache gruppiert statt einzeln, mit Lösungsvorschlag. Dazu Deployments mit Drift und Zertifikate mit Ablaufdatum. In der nächsten Runde: Die Ursache ist bekannt, der Fix auch. Mit Pro verfolgen Trace Explorer und Message Journey die Nachricht über mehrere iFlows.
6. Verstehen (Prognose · Heatmap, Pro, im Produkt): Wann kommt die Last, welcher Step ist der langsamste, welches iFlow ist geändert und nicht deployt? In der nächsten Runde: Mehr Historie, genauere Prognose – die Ansicht misst ihre Güte selbst und zeigt sie an.
7. Dokumentieren (Doku-Generator, Pro, im Produkt): Schnittstellen-Doku aus dem Tenant als Markdown, PDF oder direkt nach Confluence. In der nächsten Runde: Die Doku stimmt, weil sie aus dem Tenant kommt. Wer das nächste iFlow baut, beginnt mit ihr – zurück zu Station 1.

Betriebs-Flywheel – Jeder Fehler macht den nächsten seltener – weil aus der Ursache eine Regel wird, die vor dem Deploy prüft.

1. Fehler (Message Monitor, Community, im Produkt): Eine Nachricht scheitert. Der Monitor zeigt sie mit Filter nach iFlow, Status, Zeitraum, Correlation- und Application-ID. In der nächsten Runde: Mit Pro zeigt die Prognose die Fehlerquote neben der Vorperiode – du siehst, ob der Fix gewirkt hat.
2. Ursache (Fehleranalyse, Community, im Produkt): Hunderte Nachrichten, eine Ursache: Die Fehleranalyse gruppiert nach Fehlersignatur und schlägt aus der Wissensbasis eine Lösung vor. In der nächsten Runde: Dieselbe Signatur erkennt sie sofort wieder – mit dem Fix von letztem Mal.
3. Erklärung (Ask Tailor, Pro, im Produkt): Ask Tailor erklärt den Fehler in Klartext, sucht die Ursache eines Runs und sagt den Weg einer Beispiel-Payload durchs iFlow vorher – maskiert, mit deinem Modell. In der nächsten Runde: Bekannte Fehlermuster verweisen auf das passende Buch unserer Autoren.
4. Fix (Groovy Runner · Test Studio, Pro, im Produkt): Den Fix im Runner gegen die echte CPI-Laufzeit prüfen, mit Trace-Daten als Beispiel. Danach die Anfrage im Test Studio noch einmal. In der nächsten Runde: Das Sample des Fehlerfalls bleibt gespeichert und läuft beim nächsten Fix mit.
5. Regel (Quick Review · eigene Regeln, Community, im Produkt): Die 40 Regeln von Quick Review prüfen Fehlerbehandlung, Retries, Timeouts und Logging vor dem Deploy. Im Team kommen eigene Regeln dazu. In der nächsten Runde: Was einmal schiefging, prüft jetzt jedes iFlow mit – auch die der neuen Kollegen.
6. Vorbeugen (Zertifikate · Prognose, Community, im Produkt): Ablaufende Zertifikate mit Kalenderexport, Deployments mit Drift. Mit Pro: Lastspitzen der nächsten Tage und Stunden. In der nächsten Runde: Die nächste Störung kündigt sich an, bevor sie im Monitor steht – zurück zu Station 1, nur seltener.

Team-Flywheel – Jede Person im Team macht den Tenant besser – weil Standards, Regeln und Kennzahlen bei allen ankommen, nicht nur bei denen, die sie kennen.

1. Installieren (Community, Community, im Produkt): Eine Person installiert die Extension, ohne Konto und ohne Lizenzschlüssel. Sie nutzt die bestehende SAP-Session. In der nächsten Runde: Die nächste Person bekommt Extension, Lizenz und Policy über die Browser-Richtlinie der IT.
2. Teilen (Review-Report · Doku, Community, im Produkt): Der Review-Report geht als Markdown in den Pull Request oder das Ticket, mit Pro die Doku nach Confluence. In der nächsten Runde: Reviews sehen bei allen gleich aus – man vergleicht Scores, nicht Meinungen.
3. Festlegen (Policy Studio, Team, im Produkt): Naming-Standard, Regeln, gesperrte Schreibaktionen und erlaubte KI-Endpunkte als eine Team-Policy – zusammengestellt und getestet im Policy Studio. In der nächsten Runde: Eigene Review-Regeln wachsen mit jedem Befund. Die Policy kann ein Ablaufdatum tragen und wird dann bewusst erneuert.
4. Verteilen (Browser-Richtlinie, Enterprise, im Produkt): Die IT verteilt Extension, Lizenz und Policy per Intune, GPO oder Google Admin. Nutzer können die Policy nicht ändern. In der nächsten Runde: Neue im Team haben am ersten Tag dieselben Regeln wie alle.
5. Messen (Tenant Health · Risk Radar, Team, im Produkt): Kennzahlen und Trend des Tenants, dazu die Sicherheitslage in acht Dimensionen mit Drilldown bis zur Fundstelle. In der nächsten Runde: Der Verlauf zeigt, ob die Standards wirken – als Zahl für die Leitung, nicht als Gefühl.
6. Aufräumen (Landscape & Cleanup, Team, im Produkt): Systemlandkarte des Tenants und Kandidaten zum Aufräumen: ohne Nachrichten, nie deployt, leere Pakete, ungenutzte Script Collections – mit Begründung, nie automatisch gelöscht. In der nächsten Runde: Weniger Altlasten, schnellerer Index, klarere Landkarte – das nächste Mitglied findet sich schneller zurecht. Zurück zu Station 1.

Lern-Flywheel – Jedes iFlow macht dich besser – weil der Coach sich merkt, wo du stehst, und die nächste Runde genau dort ansetzt.

1. Planen (Implementation Coach, Coach, im Produkt): Du beschreibst das Szenario in zwei Sätzen. Der Coach legt einen Bauplan an – Sender, Validierung, Mapping, Fehlerbehandlung, Wiederanlauf, Monitoring, Doku –, jeder Schritt mit Warum und typischen Fehlern. In der nächsten Runde: Der Bauplan beginnt mit den Themen, die bei dir zuletzt offen geblieben sind. Mit Ask Tailor ist er auf dein Szenario zugeschnitten.
2. Bauen (Live-Abgleich, Coach, im Produkt): Du baust im SAP-Editor. Der Coach gleicht das offene iFlow mit dem Plan ab: erledigt, offen, problematisch – der nächste Schritt steht oben. In der nächsten Runde: Was du letzte Runde gelernt hast, ist diesmal schon erledigt, bevor der Coach fragt.
3. Prüfen (Quick Review, Community, im Produkt): Health Score, Findings mit Begründung und Fix. Für Einsteiger zählt nicht die Zahl, sondern das Warum hinter jedem Finding. In der nächsten Runde: Der Score von heute steht im Lernpfad neben dem von letzter Woche.
4. Wiederanlauf (Wiederanlauf-Guide, Coach, im Produkt): Kann das iFlow nach einem Fehler gefahrlos neu laufen? Urteil mit Score, nummerierter Bauplan mit Sprung in den Editor und Ablaufgrafik. In der nächsten Runde: Idempotenz, Dead-Letter-Queue und Exception Subprocess sind beim nächsten iFlow von Anfang an drin.
5. Versionieren (Versionierungs-Berater, Coach, im Produkt): Lohnt sich jetzt eine neue Version? Vergleich mit der letzten, Vorschlag Major, Minor oder Patch mit Begründung und Changelog. In der nächsten Runde: Die Versionshistorie liest sich wie ein Logbuch – auch für die Kollegin, die das iFlow nächstes Jahr übernimmt.
6. Lernen (Lernpfad · Lernkarten, Coach, im Produkt): Deine häufigsten Lücken, der Trend deiner Scores und kurze Lektionen mit Beispiel. Gespeichert werden nur Regel-IDs, Themen und Scores – lokal. In der nächsten Runde: Der Lernpfad schiebt die nächste Lücke nach vorn. Zurück zu Station 1, mit einem Thema weniger.

Debug-Flywheel – Jeder Fehler, den du einmal gefunden hast, wird zum Test – und der nächste Fix wird gegen alle bisherigen Läufe geprüft.

1. Sehen (Inline-Debugger, Pro, in Arbeit): Der Lauf liegt auf dem Diagramm: grün, rot, grau, der genommene Router-Zweig, die Dauer an jedem Step. Ein Klick zeigt Body, Header und Properties vorher und nachher. In der nächsten Runde: Die Live-Leiste zeigt neue Fehler, sobald sie auftreten – du öffnest den Lauf, bevor jemand anruft.
2. Vergleichen (Gut gegen schlecht, Pro, in Arbeit): Der fehlgeschlagene Lauf neben einem erfolgreichen: der erste Unterschied mit Grund – anderer Router-Zweig, fehlender Header, anderes Format. In der nächsten Runde: Beobachtete Werte sind schon eingerichtet: Die Spalte zeigt sofort, wo das Feld leer wird.
3. Ursache (Ursachensuche, Pro, in Arbeit): Kandidaten mit Belegen: „Fehler seit dem Deploy von Version 1.4.2 um 14:02“, gleicher Fehler in drei anderen iFlows, Zertifikat abgelaufen. In der nächsten Runde: Der Störungsbericht steht schon da: Zeitleiste, Auswirkung, Ursache – als Markdown oder für Jira.
4. Fix (Fix mit Gegenprobe, Pro, in Arbeit): Ask Tailor schlägt eine minimale Änderung vor. iFlowTailor prüft sie auf einer Kopie mit Groovy Lint, Review-Regeln und Simulator, bevor du sie siehst. In der nächsten Runde: Die Gegenprobe läuft gegen alle Regressionstests, die frühere Runden hinterlassen haben.
5. Test (Trace als Regressionstest, Pro, in Arbeit): Der Lauf, der gescheitert ist, wird mit einem Klick zum Test – maskiert, nur lokal. Der Simulator spielt ihn ohne Deploy durch. In der nächsten Runde: Die Pfadabdeckung zeigt, welche Zweige noch nie gelaufen sind – dort fehlt der nächste Test.
6. Gate (Test-Gate, Pro, in Arbeit): Am Deploy-Knopf stehen Score, letzter Suite-Lauf und kritische Findings. Auf Wunsch fragt das Gate vorher nach. In der nächsten Runde: Mit jedem Test aus einem echten Lauf wird das Gate genauer. Zurück zu Station 1, mit einem Fehler weniger.