Seminar Tines – Story-Architektur, Sub-Stories und Templates

Dreitägiges Praxisseminar zur Automatisierungsplattform Tines. Der Schwerpunkt „Story-Architektur, Sub-Stories und Templates“ wird anhand von Architekturtreiber und Zerlegung, Ein- und Ausgabeverträge, Send to Story und Einstieg, Output Values und Rückgabe systematisch erschlossen. Im Mittelpunkt stehen praktische Konfiguration, kontrollierte Tests, Fehlerfälle, Sicherheitsaspekte und eine nachvollziehbare Betriebsübergabe.

Inhaltsübersicht

1. Seminarprofil
2. Zielgruppe
3. Voraussetzungen
4. Lernziele
5. Seminarinhalte
6. Praxisprojekt
7. Einordnung in den Lernpfad

Seminarprofil

Drei Tage sind erforderlich, um Zerlegung, Send to Story, Output Values, Fehlergrenzen, Templates, Versionierung, Tests und Architekturreview an einer realistischen Lösung zu beherrschen. Der Schwerpunkt liegt auf nachvollziehbaren Entscheidungen, praktischer Konfiguration, kontrollierten Fehlerszenarien und wiederholbaren Betriebsverfahren.

Zielgruppe

Fortgeschrittene Automation Engineers, technische Leads, Integrationsarchitekten und Plattformteams.

Voraussetzungen

Sichere Kenntnisse zu Stories, Events, Formeln und API-Integrationen. Für die Übungen wird eine vorbereitete Laborumgebung mit Testdaten und ausschließlich dafür vorgesehenen Zugangsdaten verwendet.

Lernziele

• Architekturtreiber und Zerlegung fachlich einordnen, in Tines umsetzen, mit positiven und negativen Fällen prüfen und betriebsfähig dokumentieren.
• Ein- und Ausgabeverträge fachlich einordnen, in Tines umsetzen, mit positiven und negativen Fällen prüfen und betriebsfähig dokumentieren.
• Send to Story und Einstieg fachlich einordnen, in Tines umsetzen, mit positiven und negativen Fällen prüfen und betriebsfähig dokumentieren.
• Output Values und Rückgabe fachlich einordnen, in Tines umsetzen, mit positiven und negativen Fällen prüfen und betriebsfähig dokumentieren.
• Fehlergrenzen und Resilienz fachlich einordnen, in Tines umsetzen, mit positiven und negativen Fällen prüfen und betriebsfähig dokumentieren.
• Templates und Story Library fachlich einordnen, in Tines umsetzen, mit positiven und negativen Fällen prüfen und betriebsfähig dokumentieren.

Seminarinhalte

1. Architekturtreiber und Zerlegung

1. Schritt 1 – Analyse: fachliche Fähigkeiten, Datenflüsse und Änderungsgründe identifizieren. Zweck, Eingaben, Ausgaben, Datenklasse und verantwortliche Rolle werden dabei eindeutig festgehalten.
2. Schritt 2 – Entwurf: Module nach Kohäsion, Kopplung und Verantwortung schneiden. Die beteiligten Tines-Objekte erhalten konsistente Namen, Notes, Sections und klar erkennbare Verbindungen.
3. Schritt 3 – Umsetzung: monolithische Beispielstory in Architekturabschnitte zerlegen. Die Konfiguration wird mit realistischen Beispieldaten ausgeführt; Events, Status und Seiteneffekte werden unmittelbar kontrolliert.
4. Schritt 4 – Prüfung: zu kleine Bausteine und versteckte gemeinsame Zustände erkennen. Normalfall, fehlende Eingabe, unerwarteter Datentyp, Berechtigungsfehler und technische Störung werden getrennt bewertet.
5. Schritt 5 – Übergabe: Architekturübersicht und Entscheidungsregeln dokumentieren. Abnahmekriterien, Monitoring, Wiederanlauf, Änderungsweg und Zuständigkeit werden in einer kompakten Betriebsnotiz gesichert.

2. Ein- und Ausgabeverträge

1. Schritt 1 – Analyse: Pflichtwerte, optionale Werte, Ergebnis und Fehler definieren. Zweck, Eingaben, Ausgaben, Datenklasse und verantwortliche Rolle werden dabei eindeutig festgehalten.
2. Schritt 2 – Entwurf: stabiles Schema und Versionsstrategie entwerfen. Die beteiligten Tines-Objekte erhalten konsistente Namen, Notes, Sections und klar erkennbare Verbindungen.
3. Schritt 3 – Umsetzung: Vertrag mit Beispieldaten und Validierung umsetzen. Die Konfiguration wird mit realistischen Beispieldaten ausgeführt; Events, Status und Seiteneffekte werden unmittelbar kontrolliert.
4. Schritt 4 – Prüfung: fehlende Felder und inkompatible Version prüfen. Normalfall, fehlende Eingabe, unerwarteter Datentyp, Berechtigungsfehler und technische Störung werden getrennt bewertet.
5. Schritt 5 – Übergabe: Schnittstellenkatalog und Kompatibilitätsregel festhalten. Abnahmekriterien, Monitoring, Wiederanlauf, Änderungsweg und Zuständigkeit werden in einer kompakten Betriebsnotiz gesichert.

3. Send to Story und Einstieg

1. Schritt 1 – Analyse: Aufrufart, Datenübergabe und Zielstory bestimmen. Zweck, Eingaben, Ausgaben, Datenklasse und verantwortliche Rolle werden dabei eindeutig festgehalten.
2. Schritt 2 – Entwurf: Send-to-Story-Aktion und Eingangspfad strukturieren. Die beteiligten Tines-Objekte erhalten konsistente Namen, Notes, Sections und klar erkennbare Verbindungen.
3. Schritt 3 – Umsetzung: Hauptstory mit einer Sub-Story verbinden. Die Konfiguration wird mit realistischen Beispieldaten ausgeführt; Events, Status und Seiteneffekte werden unmittelbar kontrolliert.
4. Schritt 4 – Prüfung: falsche Zielstory und unvollständigen Input behandeln. Normalfall, fehlende Eingabe, unerwarteter Datentyp, Berechtigungsfehler und technische Störung werden getrennt bewertet.
5. Schritt 5 – Übergabe: Aufrufbeziehung und Owner dokumentieren. Abnahmekriterien, Monitoring, Wiederanlauf, Änderungsweg und Zuständigkeit werden in einer kompakten Betriebsnotiz gesichert.

4. Output Values und Rückgabe

1. Schritt 1 – Analyse: benötigte Ergebnisdaten und mehrere Ausgänge bestimmen. Zweck, Eingaben, Ausgaben, Datenklasse und verantwortliche Rolle werden dabei eindeutig festgehalten.
2. Schritt 2 – Entwurf: Output-Aktionen und eindeutige Rückgabestruktur planen. Die beteiligten Tines-Objekte erhalten konsistente Namen, Notes, Sections und klar erkennbare Verbindungen.
3. Schritt 3 – Umsetzung: Ergebnis an die aufrufende Story zurückgeben. Die Konfiguration wird mit realistischen Beispieldaten ausgeführt; Events, Status und Seiteneffekte werden unmittelbar kontrolliert.
4. Schritt 4 – Prüfung: fehlenden Output und konkurrierende Ausgänge prüfen. Normalfall, fehlende Eingabe, unerwarteter Datentyp, Berechtigungsfehler und technische Störung werden getrennt bewertet.
5. Schritt 5 – Übergabe: Rückgabevertrag und Fehlercode dokumentieren. Abnahmekriterien, Monitoring, Wiederanlauf, Änderungsweg und Zuständigkeit werden in einer kompakten Betriebsnotiz gesichert.

5. Fehlergrenzen und Resilienz

1. Schritt 1 – Analyse: lokal behandelbare und nach außen zu meldende Fehler trennen. Zweck, Eingaben, Ausgaben, Datenklasse und verantwortliche Rolle werden dabei eindeutig festgehalten.
2. Schritt 2 – Entwurf: Timeout, Retry und Kompensation je Modul definieren. Die beteiligten Tines-Objekte erhalten konsistente Namen, Notes, Sections und klar erkennbare Verbindungen.
3. Schritt 3 – Umsetzung: Sub-Story-Fehler kontrolliert an Hauptstory übergeben. Die Konfiguration wird mit realistischen Beispieldaten ausgeführt; Events, Status und Seiteneffekte werden unmittelbar kontrolliert.
4. Schritt 4 – Prüfung: Teilerfolg und wiederholten Aufruf simulieren. Normalfall, fehlende Eingabe, unerwarteter Datentyp, Berechtigungsfehler und technische Störung werden getrennt bewertet.
5. Schritt 5 – Übergabe: Wiederanlauf- und Eskalationsregel festhalten. Abnahmekriterien, Monitoring, Wiederanlauf, Änderungsweg und Zuständigkeit werden in einer kompakten Betriebsnotiz gesichert.

6. Templates und Story Library

1. Schritt 1 – Analyse: wiederverwendbare Actions und Stories anhand von Reife bewerten. Zweck, Eingaben, Ausgaben, Datenklasse und verantwortliche Rolle werden dabei eindeutig festgehalten.
2. Schritt 2 – Entwurf: öffentliche, private und interne Vorlagen einordnen. Die beteiligten Tines-Objekte erhalten konsistente Namen, Notes, Sections und klar erkennbare Verbindungen.
3. Schritt 3 – Umsetzung: Baustein parametrisieren und als Vorlage bereitstellen. Die Konfiguration wird mit realistischen Beispieldaten ausgeführt; Events, Status und Seiteneffekte werden unmittelbar kontrolliert.
4. Schritt 4 – Prüfung: Credential-Abhängigkeit und veraltete Annahme prüfen. Normalfall, fehlende Eingabe, unerwarteter Datentyp, Berechtigungsfehler und technische Störung werden getrennt bewertet.
5. Schritt 5 – Übergabe: Katalog, Status, Owner und Reviewintervall dokumentieren. Abnahmekriterien, Monitoring, Wiederanlauf, Änderungsweg und Zuständigkeit werden in einer kompakten Betriebsnotiz gesichert.

7. Tests und Architekturreview

1. Schritt 1 – Analyse: Unit-, Vertrags-, Integrations- und Regressionstests definieren. Zweck, Eingaben, Ausgaben, Datenklasse und verantwortliche Rolle werden dabei eindeutig festgehalten.
2. Schritt 2 – Entwurf: Testevents und Abnahmekriterien pro Modul vorbereiten. Die beteiligten Tines-Objekte erhalten konsistente Namen, Notes, Sections und klar erkennbare Verbindungen.
3. Schritt 3 – Umsetzung: Module einzeln und im Verbund ausführen. Die Konfiguration wird mit realistischen Beispieldaten ausgeführt; Events, Status und Seiteneffekte werden unmittelbar kontrolliert.
4. Schritt 4 – Prüfung: inkompatible Änderung und nicht deterministischen Fehler erkennen. Normalfall, fehlende Eingabe, unerwarteter Datentyp, Berechtigungsfehler und technische Störung werden getrennt bewertet.
5. Schritt 5 – Übergabe: Reviewprotokoll und Freigabeentscheidung erstellen. Abnahmekriterien, Monitoring, Wiederanlauf, Änderungsweg und Zuständigkeit werden in einer kompakten Betriebsnotiz gesichert.

8. Lifecycle und Weiterentwicklung

1. Schritt 1 – Analyse: Version, Abhängigkeit und Verbraucher je Baustein erfassen. Zweck, Eingaben, Ausgaben, Datenklasse und verantwortliche Rolle werden dabei eindeutig festgehalten.
2. Schritt 2 – Entwurf: Änderungs- und Deprecation-Prozess planen. Die beteiligten Tines-Objekte erhalten konsistente Namen, Notes, Sections und klar erkennbare Verbindungen.
3. Schritt 3 – Umsetzung: kompatible Erweiterung und kontrollierte Migration durchführen. Die Konfiguration wird mit realistischen Beispieldaten ausgeführt; Events, Status und Seiteneffekte werden unmittelbar kontrolliert.
4. Schritt 4 – Prüfung: verwaisten Verbraucher und ungenutzte Vorlage identifizieren. Normalfall, fehlende Eingabe, unerwarteter Datentyp, Berechtigungsfehler und technische Störung werden getrennt bewertet.
5. Schritt 5 – Übergabe: Roadmap und Stilllegungsplan übergeben. Abnahmekriterien, Monitoring, Wiederanlauf, Änderungsweg und Zuständigkeit werden in einer kompakten Betriebsnotiz gesichert.

Praxisprojekt

Eine monolithische Integrationsstory wird in klar vertraglich definierte Sub-Stories zerlegt, mit Output Values gekoppelt, durch Tests abgesichert und als wiederverwendbarer Bausteinkatalog organisiert.

1. Schritt 1 – Ausgangslage: Systeme, Testdaten, Rollen, Credentials und fachliche Abnahmekriterien werden vor Beginn festgelegt.
2. Schritt 2 – Aufbau: Die benötigten Actions, Tools, Pages, Records oder Sub-Stories werden nach dem behandelten Architekturstandard erstellt.
3. Schritt 3 – Normalbetrieb: Ein vollständiger Durchlauf wird ausgelöst; Eventpfad, Ausgaben und beabsichtigte Seiteneffekte werden geprüft.
4. Schritt 4 – Störung und Sicherheit: Mindestens ein Datenfehler, ein technischer Fehler und ein unzulässiger Zugriff werden simuliert und kontrolliert behandelt.
5. Schritt 5 – Abnahme: Testergebnisse, offene Risiken, Monitoring, Wiederanlauf und Betriebszuständigkeit werden in einer Übergabecheckliste dokumentiert.

Einordnung in den Lernpfad

Nach Datenmodell und API-Integration; vor Change Control, Workflow-APIs oder dem Automation-Engineering-Intensivseminar. Die Auswahl der Vertiefung richtet sich anschließend nach Builder-, Administrations-, App-, KI-, Governance- oder Security-Operations-Verantwortung.