# Programmiertechnik # 1 - Diagramme & Modelle für die IHK # Seite 1. Überblick – Welches Diagramm wofür? Ziel dieser Seite ist nicht, jedes Diagramm sofort vollständig zu können. Das Ziel ist zuerst: **schnell erkennen, welches Diagramm zu welcher Aufgabenstellung passt.** --- **Warum sind diese Diagramme wichtig?** In IHK-Aufgaben wird oft nicht direkt gefragt: „Erstelle ein UML-Aktivitätsdiagramm.“ Stattdessen steht dort eher eine Situation wie: - „Stellen Sie den Ablauf dar.“ - „Modellieren Sie die Datenstruktur.“ - „Zeigen Sie die Beziehungen zwischen Klassen.“ - „Entwerfen Sie eine Benutzeroberfläche.“ - „Stellen Sie die Kommunikation zwischen Objekten dar.“ Dann musst du erkennen, **welches Modell oder Diagramm gemeint ist**. --- **Die wichtigsten Diagrammarten im Überblick** | Diagramm / Modell | Wofür wird es benutzt? | Typische Signalwörter in Aufgaben | |---|---|---| | **ERM** | Daten, Entitäten und Beziehungen darstellen | Entität, Attribut, Beziehung, Kardinalität, Kunde, Bestellung, Produkt | | **Relationales Datenbankmodell** | ERM in Tabellen mit Schlüsseln umwandeln | Tabelle, Primärschlüssel, Fremdschlüssel, Datensatz, Normalisierung | | **UML-Klassendiagramm** | Klassen, Attribute, Methoden und Beziehungen planen | Klasse, Attribut, Methode, Vererbung, Objekt, Assoziation | | **Mock-up** | Benutzeroberfläche grob entwerfen | Oberfläche, Eingabemaske, Button, Formular, Benutzerführung | | **UML-Aktivitätsdiagramm** | Abläufe, Entscheidungen und Schleifen darstellen | Ablauf, Prozess, Entscheidung, wenn/dann, Reihenfolge, Bedingung | | **UML-Anwendungsfalldiagramm** | Benutzerrollen und Systemfunktionen darstellen | Akteur, Benutzer, System, Funktion, Use Case, Anwendungsfall | | **UML-Sequenzdiagramm** | Kommunikation zwischen Objekten zeitlich darstellen | Nachricht, Aufruf, Objekt, Reihenfolge, Rückgabe, Kommunikation | | **UML-Zustandsdiagramm** | Zustände und Zustandswechsel darstellen | Zustand, Ereignis, Übergang, Trigger, Statuswechsel | --- **Merksatz** Wenn du eine Aufgabe liest, frage dich zuerst: | Frage | Wahrscheinlich passendes Diagramm | |---|---| | Geht es um **Daten und Beziehungen**? | ERM | | Geht es um **Tabellen und Schlüssel**? | Relationales Datenbankmodell | | Geht es um **Klassen im Programmcode**? | UML-Klassendiagramm | | Geht es um **eine Benutzeroberfläche**? | Mock-up | | Geht es um **einen Ablauf mit Entscheidungen**? | UML-Aktivitätsdiagramm | | Geht es um **Benutzer und Funktionen**? | UML-Anwendungsfalldiagramm | | Geht es um **Nachrichten zwischen Objekten**? | UML-Sequenzdiagramm | | Geht es um **Zustände eines Objekts**? | UML-Zustandsdiagramm | --- **Schnellentscheidung für die Prüfung** **1. Aufgabe spricht von Daten?** Beispiele: - Kunde - Bestellung - Produkt - Rechnung - Kurs - Schüler - Beziehung - Kardinalität Dann denke zuerst an: **ERM** oder **relationales Datenbankmodell** Unterschied: | Wenn gefragt wird nach ... | Dann eher ... | |---|---| | Entitäten und Beziehungen | ERM | | Tabellen, Primärschlüssel, Fremdschlüssel | Relationales Datenbankmodell | --- **2. Aufgabe spricht von Programmstruktur?** Beispiele: - Klasse - Attribut - Methode - Objekt - Vererbung - Produktverwaltung - Java-Klassen Dann denke zuerst an: **UML-Klassendiagramm** Typisch für Java: ```text Produkt - marke - modell - preis + toString() # Seite 2. Gesamttrainer – Diagramm-Auswahl --- **Interaktiver Trainer** Mit diesem Trainer kannst du üben, welche Diagrammart zu welcher Aufgabenstellung passt.
Diagramm-Auswahl-Trainer im Vollbild öffnen
# Seite 3. ERM – Entity-Relationship-Modell **ERM – Entity-Relationship-Modell** Diese Seite erklärt das **ERM** so, dass du es schnell für IHK-Aufgaben anwenden kannst. ERM bedeutet: **Entity-Relationship-Modell** Auf Deutsch: **Entitäten-Beziehungs-Modell** Ein ERM wird benutzt, um **Daten und deren Beziehungen** zu planen, bevor daraus später Tabellen in einer Datenbank entstehen. --- **Grafik 1: ERM-Grundlagen im Überblick** ![ERM – Grundlagen](https://trainer.ulrich-wiki.com/assets/erm-grundlagen.svg) Diese Grafik zeigt dir die wichtigsten Bausteine des ERM auf einen Blick: - **Entität** - **Attribut** - **Beziehung** - **Kardinalität** - die wichtigsten **Kardinalitäten 1:1, 1:n und n:m** - typische **Signalwörter**, an denen du in einer IHK-Aufgabe erkennst, dass ein ERM gemeint ist --- **Wofür braucht man ein ERM?** Ein ERM hilft dir, aus einer fachlichen Beschreibung ein Datenmodell zu bauen. Beispiel: ```text Ein Kunde kann mehrere Bestellungen aufgeben. Eine Bestellung gehört immer zu genau einem Kunden. Eine Bestellung enthält mehrere Produkte. Ein Produkt kann in mehreren Bestellungen enthalten sein. ``` Daraus erkennt man: - Es gibt Datenobjekte. - Diese Datenobjekte haben Eigenschaften. - Diese Datenobjekte stehen miteinander in Beziehung. - Manche Beziehungen haben bestimmte Anzahlen, zum Beispiel **1:n** oder **n:m**. Genau dafür ist ein ERM da. --- **Woran erkenne ich in einer Aufgabe, dass ein ERM gemeint ist?** Typische Signalwörter: | Signalwort / Formulierung | Hinweis | |---|---| | Entität | Es geht um ein Datenobjekt | | Attribut | Es geht um Eigenschaften | | Beziehung | Es geht um Verknüpfungen zwischen Datenobjekten | | Kardinalität | Es geht um 1:1, 1:n oder n:m | | Kunde, Bestellung, Produkt | Typische Entitäten | | „kann mehrere haben“ | Hinweis auf 1:n oder n:m | | „gehört zu genau einem“ | Hinweis auf 1:n | | „Datenmodell erstellen“ | ERM oder relationales Modell | | „fachlich modellieren“ | Meist zuerst ERM | --- **Grundbausteine eines ERM** | Baustein | Bedeutung | Beispiel | |---|---|---| | **Entität** | Wichtiges Datenobjekt | Kunde, Produkt, Bestellung | | **Attribut** | Eigenschaft einer Entität | Name, Preis, Datum | | **Beziehung** | Verbindung zwischen Entitäten | Kunde gibt Bestellung auf | | **Kardinalität** | Anzahl-Beziehung | 1:1, 1:n, n:m | | **Primärschlüssel** | Eindeutige ID | kunden_id | | **Zwischentabelle** | Auflösung einer n:m-Beziehung | Bestellposition | --- **Entität** Eine **Entität** ist ein wichtiges Datenobjekt, über das Informationen gespeichert werden sollen. Beispiele: - Kunde - Bestellung - Produkt - Rechnung - Mitarbeiter - Kurs - Raum - Gerät Merksatz: **Entitäten sind meistens Hauptwörter.** Beispiel: ```text Ein Kunde bestellt ein Produkt. ``` Mögliche Entitäten: ```text Kunde Produkt Bestellung ``` --- **Attribut** Ein **Attribut** ist eine Eigenschaft einer Entität. Beispiel Entität **Kunde**: | Attribut | Bedeutung | |---|---| | kunden_id | eindeutige Kundennummer | | vorname | Vorname | | nachname | Nachname | | email | E-Mail-Adresse | | telefon | Telefonnummer | Beispiel Entität **Produkt**: | Attribut | Bedeutung | |---|---| | produkt_id | eindeutige Produktnummer | | bezeichnung | Name des Produkts | | preis | Preis | | lagerbestand | Anzahl im Lager | Merksatz: **Attribute beschreiben eine Entität genauer.** --- **Primärschlüssel** Ein **Primärschlüssel** identifiziert jeden Datensatz eindeutig. Beispiele: ```text kunden_id produkt_id bestellung_id ``` Warum braucht man Primärschlüssel? Weil Namen nicht eindeutig sein müssen. Beispiel: ```text Es kann mehrere Kunden mit dem Namen Müller geben. ``` Aber: ```text kunden_id = 1001 ``` ist eindeutig. Merksatz: **Jede Entität braucht einen eindeutigen Primärschlüssel.** --- **Beziehung** Eine Beziehung beschreibt, wie zwei Entitäten zusammenhängen. Beispiel: ```text Kunde gibt Bestellung auf ``` Entitäten: ```text Kunde Bestellung ``` Beziehung: ```text gibt auf ``` Darstellung als einfache Textform: ```text Kunde -- gibt auf -- Bestellung ``` Weitere Beispiele: | Beziehung | Bedeutung | |---|---| | Kunde gibt Bestellung auf | Kunde und Bestellung hängen zusammen | | Bestellung enthält Produkt | Eine Bestellung besteht aus Produkten | | Mitarbeiter arbeitet in Abteilung | Mitarbeiter ist einer Abteilung zugeordnet | | Schüler belegt Kurs | Schüler nimmt an einem Kurs teil | --- **Kardinalität** Die **Kardinalität** beschreibt, wie viele Datensätze miteinander verbunden sein können. Die wichtigsten Kardinalitäten: | Kardinalität | Bedeutung | Beispiel | |---|---|---| | **1:1** | Genau ein Datensatz gehört zu genau einem anderen | Person hat Personalausweis | | **1:n** | Ein Datensatz kann mehrere andere Datensätze haben | Kunde hat mehrere Bestellungen | | **n:m** | Viele Datensätze können mit vielen anderen verbunden sein | Schüler belegen Kurse | --- **Grafik 2: ERM-Beispiel mit Kunde, Bestellung, Produkt und Bestellposition** ![ERM – Kunde Bestellung Produkt](https://trainer.ulrich-wiki.com/assets/erm-beispiel-bestellung.svg) Diese Grafik zeigt ein typisches vollständiges ERM-Beispiel: - **Kunde** gibt **Bestellung** auf → **1:n** - **Bestellung** enthält **Produkt** → fachlich **n:m** - Die n:m-Beziehung wird durch **Bestellposition** aufgelöst - Dadurch entstehen später sauberere Tabellen für die Datenbank --- **1:1-Beziehung** Beispiel: ```text Eine Person hat genau einen Personalausweis. Ein Personalausweis gehört genau zu einer Person. ``` Darstellung: ```text Person 1 --- 1 Personalausweis ``` Das ist eine **1:1-Beziehung**. --- **1:n-Beziehung** Beispiel: ```text Ein Kunde kann mehrere Bestellungen haben. Eine Bestellung gehört genau zu einem Kunden. ``` Darstellung: ```text Kunde 1 --- n Bestellung ``` Das ist eine **1:n-Beziehung**. Merksatz: **Wenn ein Objekt mehrere andere haben kann, ist es meistens 1:n.** --- **n:m-Beziehung** Beispiel: ```text Eine Bestellung kann mehrere Produkte enthalten. Ein Produkt kann in mehreren Bestellungen vorkommen. ``` Darstellung: ```text Bestellung n --- m Produkt ``` Das ist eine **n:m-Beziehung**. Wichtig: Eine n:m-Beziehung kann man in einer relationalen Datenbank nicht direkt einfach speichern. Deshalb wird daraus später eine **Zwischentabelle**. Beispiel: ```text Bestellung Produkt Bestellposition ``` Die Zwischentabelle könnte heißen: ```text Bestellposition ``` Typische Attribute der Zwischentabelle: | Attribut | Bedeutung | |---|---| | bestellung_id | Verweis auf Bestellung | | produkt_id | Verweis auf Produkt | | menge | Wie oft wurde das Produkt bestellt? | | einzelpreis | Preis zum Zeitpunkt der Bestellung | --- **ERM-Beispiel: Kunde, Bestellung, Produkt** Fachliche Beschreibung: ```text Ein Kunde kann mehrere Bestellungen aufgeben. Eine Bestellung gehört immer zu genau einem Kunden. Eine Bestellung kann mehrere Produkte enthalten. Ein Produkt kann in mehreren Bestellungen enthalten sein. ``` Entitäten: | Entität | Mögliche Attribute | |---|---| | Kunde | kunden_id, name, email | | Bestellung | bestellung_id, bestelldatum | | Produkt | produkt_id, bezeichnung, preis | | Bestellposition | bestellung_id, produkt_id, menge | Beziehungen: | Beziehung | Kardinalität | |---|---| | Kunde zu Bestellung | 1:n | | Bestellung zu Produkt | n:m | | Bestellung zu Bestellposition | 1:n | | Produkt zu Bestellposition | 1:n | Das n:m zwischen Bestellung und Produkt wird durch **Bestellposition** aufgelöst. --- **ERM vs. relationales Datenbankmodell** | ERM | Relationales Datenbankmodell | |---|---| | Fachliches Modell | Technischeres Tabellenmodell | | Zeigt Entitäten | Zeigt Tabellen | | Zeigt Beziehungen | Zeigt Primär- und Fremdschlüssel | | Nutzt Kardinalitäten | Nutzt Schlüsselbeziehungen | | Vorstufe zur Datenbank | Grundlage für echte Tabellenstruktur | Merksatz: **ERM plant die Daten fachlich. Das relationale Modell macht daraus Tabellen.** --- **Vorgehensweise in der Prüfung** Wenn du eine ERM-Aufgabe bekommst, gehe so vor: | Schritt | Frage | |---|---| | 1 | Welche Hauptwörter sind wichtig? | | 2 | Welche davon sind Entitäten? | | 3 | Welche Eigenschaften haben diese Entitäten? | | 4 | Welche Entität braucht welchen Primärschlüssel? | | 5 | Welche Entitäten stehen in Beziehung? | | 6 | Welche Kardinalität hat die Beziehung? | | 7 | Gibt es eine n:m-Beziehung? | | 8 | Muss eine Zwischentabelle entstehen? | --- **Typische IHK-Fehler beim ERM** | Fehler | Warum falsch? | |---|---| | Attribute als Entität darstellen | Nicht jede Eigenschaft ist eine eigene Entität | | n:m nicht auflösen | In Tabellen braucht man später eine Zwischentabelle | | Primärschlüssel vergessen | Jeder Datensatz muss eindeutig identifizierbar sein | | Kardinalitäten vertauschen | Die Beziehung wird fachlich falsch | | Beziehung zu technisch denken | ERM ist zuerst fachlich, nicht direkt SQL | | Fremdschlüssel schon zu früh überbewerten | Im ERM geht es zuerst um Entitäten und Beziehungen | --- **Prüfungs-Merksätze** ```text Entität = wichtiges Datenobjekt Attribut = Eigenschaft einer Entität Beziehung = Verbindung zwischen Entitäten Kardinalität = Wie viele gehören zusammen? 1:n = einer zu vielen n:m = viele zu vielen n:m braucht später eine Zwischentabelle Primärschlüssel = eindeutig ERM = fachliches Datenmodell Relationales Modell = Tabellenmodell ``` --- **Mini-Testfragen**
1. Was bedeutet ERM? **Entity-Relationship-Modell** Auf Deutsch: Entitäten-Beziehungs-Modell.
2. Wofür wird ein ERM verwendet? Ein ERM wird verwendet, um Datenobjekte, deren Eigenschaften und deren Beziehungen fachlich zu modellieren.
3. Was ist eine Entität? Eine Entität ist ein wichtiges Datenobjekt, über das Informationen gespeichert werden sollen. Beispiele: - Kunde - Bestellung - Produkt - Mitarbeiter
4. Was ist ein Attribut? Ein Attribut ist eine Eigenschaft einer Entität. Beispiel: ```text Kunde - kunden_id - name - email ```
5. Was ist eine n:m-Beziehung? Viele Datensätze der einen Entität können mit vielen Datensätzen der anderen Entität verbunden sein. Beispiel: ```text Eine Bestellung kann mehrere Produkte enthalten. Ein Produkt kann in mehreren Bestellungen vorkommen. ```
6. Was muss man bei einer n:m-Beziehung später machen? Man löst sie meistens über eine Zwischentabelle auf. Beispiel: ```text Bestellung n:m Produkt ``` wird zu: ```text Bestellung 1:n Bestellposition n:1 Produkt ```
--- **Nächste Seite** Danach kommt die eigene Trainer-Seite: ```text ERM-Trainer ``` Dort bauen wir den interaktiven ERM-Trainer mit Aufgaben zu: ```text Entität erkennen Attribute zuordnen Beziehung bestimmen Kardinalität wählen n:m-Zwischentabelle erkennen ``` # Seite 4. ERM-Trainer **ERM-Trainer** Dieser interaktive Trainer gehört zur Theorie-Seite: ```text ERM – Entity-Relationship-Modell ``` Hier übst du, aus kurzen Aufgabenstellungen die wichtigsten Bestandteile eines ERM zu erkennen: ```text Entität 1 Entität 2 Beziehung Kardinalität Zwischentabelle bei n:m-Beziehungen ``` --- **Was wird trainiert?** | Bereich | Bedeutung | |---|---| | **Entität erkennen** | wichtige Datenobjekte aus dem Text finden | | **Beziehung erkennen** | passende Verbindung zwischen den Entitäten formulieren | | **Kardinalität bestimmen** | 1:1, 1:n, n:1 oder n:m auswählen | | **Zwischentabelle erkennen** | bei n:m-Beziehungen eine passende Zwischentabelle nennen | | **Typische IHK-Formulierungen verstehen** | aus Textaufgaben das Datenmodell ableiten | --- **Interaktiver ERM-Trainer**
ERM-Trainer im Vollbild öffnen
--- **Merksatz für den Trainer** ```text Entität = wichtiges Datenobjekt Beziehung = Verbindung zwischen Entitäten Kardinalität = Wie viele gehören zusammen? 1:n = einer zu vielen n:m = viele zu vielen n:m = meistens Zwischentabelle nötig ``` --- **Beispiel** Aufgabenstellung: ```text Ein Schüler kann mehrere Kurse belegen. Ein Kurs kann von mehreren Schülern belegt werden. ``` Lösung: | Feld | Lösung | |---|---| | Entität 1 | Schüler | | Entität 2 | Kurs | | Beziehung | belegt | | Kardinalität | n:m | | Zwischentabelle | Belegung | Warum? ```text Viele Schüler können viele Kurse belegen. Deshalb ist es eine n:m-Beziehung. Eine n:m-Beziehung braucht später meistens eine Zwischentabelle. ``` --- **Mini-Testfragen**
1. Was musst du im ERM-Trainer zuerst aus der Aufgabenstellung erkennen? Zuerst musst du die wichtigsten **Entitäten** erkennen. Entitäten sind meistens wichtige Hauptwörter aus der Aufgabenstellung. Beispiel: ```text Ein Kunde kann mehrere Bestellungen aufgeben. ``` Mögliche Entitäten: ```text Kunde Bestellung ```
2. Wann liegt meistens eine 1:n-Beziehung vor? Wenn ein Datensatz der einen Entität mit mehreren Datensätzen der anderen Entität verbunden sein kann. Beispiel: ```text Ein Kunde kann mehrere Bestellungen haben. Eine Bestellung gehört genau zu einem Kunden. ``` Das ist: ```text Kunde 1:n Bestellung ```
3. Wann liegt meistens eine n:m-Beziehung vor? Wenn viele Datensätze der einen Entität mit vielen Datensätzen der anderen Entität verbunden sein können. Beispiel: ```text Ein Schüler kann mehrere Kurse belegen. Ein Kurs kann von mehreren Schülern belegt werden. ``` Das ist: ```text Schüler n:m Kurs ```
4. Was passiert bei einer n:m-Beziehung später meistens? Die n:m-Beziehung wird durch eine **Zwischentabelle** aufgelöst. Beispiel: ```text Schüler n:m Kurs ``` wird zu: ```text Schüler 1:n Belegung n:1 Kurs ```
5. Warum ist die Zwischentabelle wichtig? Weil eine n:m-Beziehung in einer relationalen Datenbank nicht einfach direkt gespeichert wird. Die Zwischentabelle speichert die Verbindung zwischen beiden Entitäten. Beispiel: ```text Belegung - schueler_id - kurs_id - anmeldedatum ```
--- **Nächste Seite** Danach geht es weiter mit: ```text Relationales Datenbankmodell ``` # Seite 5. Relationales Datenbankmodell **Relationales Datenbankmodell** Diese Seite erklärt das **relationale Datenbankmodell** so, dass du es schnell für IHK-Aufgaben anwenden kannst. Das relationale Datenbankmodell beschreibt, wie Daten in **Tabellen** gespeichert werden. Dabei sind besonders wichtig: ```text Tabellen Datensätze Attribute / Spalten Primärschlüssel Fremdschlüssel Beziehungen zwischen Tabellen ``` --- **Grafik 1: Grundlagen des relationalen Datenbankmodells** ![Relationales Datenbankmodell – Grundlagen](https://trainer.ulrich-wiki.com/assets/relationales-modell-grundlagen.svg) Diese Grafik zeigt dir die wichtigsten Grundbegriffe: - **Tabelle** - **Datensatz** - **Primärschlüssel** - **Fremdschlüssel** - Zusammenhang zwischen Zeilen, Spalten und Schlüsseln --- **Wofür braucht man das relationale Datenbankmodell?** Das relationale Datenbankmodell wird benutzt, um ein fachliches Datenmodell technisch näher an eine echte Datenbank zu bringen. Ein ERM zeigt zuerst fachlich: ```text Kunde gibt Bestellung auf ``` Das relationale Modell macht daraus Tabellen: ```text Kunde Bestellung ``` Und legt fest: ```text Welche Spalten gibt es? Was ist der Primärschlüssel? Wo wird ein Fremdschlüssel benötigt? Wie hängen die Tabellen zusammen? ``` --- **Woran erkenne ich in einer Aufgabe, dass ein relationales Datenbankmodell gemeint ist?** Typische Signalwörter: | Signalwort / Formulierung | Hinweis | |---|---| | Tabelle | Daten sollen tabellarisch dargestellt werden | | Datensatz | Es geht um Zeilen in einer Tabelle | | Attribut / Spalte | Es geht um Felder einer Tabelle | | Primärschlüssel | Eindeutige Kennzeichnung eines Datensatzes | | Fremdschlüssel | Verweis auf eine andere Tabelle | | Relation | Tabelle oder Beziehung zwischen Tabellen | | Normalisierung | Tabellen sollen sauber strukturiert werden | | n:m auflösen | Zwischentabelle wird benötigt | | ERM in Tabellen überführen | Relationales Modell ist gemeint | --- **Grundbegriffe** | Begriff | Bedeutung | Beispiel | |---|---|---| | **Tabelle** | Sammlung gleichartiger Datensätze | Kunde, Bestellung, Produkt | | **Datensatz** | Eine Zeile in einer Tabelle | ein bestimmter Kunde | | **Attribut / Spalte** | Eigenschaft eines Datensatzes | name, email, preis | | **Primärschlüssel** | eindeutige ID einer Tabelle | kunden_id | | **Fremdschlüssel** | Verweis auf Primärschlüssel einer anderen Tabelle | kunden_id in Bestellung | | **Relation** | Tabelle oder Beziehung zwischen Tabellen | Kunde 1:n Bestellung | --- **Tabelle** Eine Tabelle speichert gleichartige Daten. Beispiel Tabelle **Kunde**: | kunden_id | name | email | |---|---|---| | 1 | Müller | mueller@example.de | | 2 | Schmidt | schmidt@example.de | Die Tabelle hat: - Spalten - Zeilen - Datensätze - einen Primärschlüssel --- **Datensatz** Ein Datensatz ist eine einzelne Zeile in einer Tabelle. Beispiel: | kunden_id | name | email | |---|---|---| | 1 | Müller | mueller@example.de | Dieser eine Kunde ist ein Datensatz. Merksatz: **Datensatz = eine vollständige Zeile einer Tabelle** --- **Attribut / Spalte** Ein Attribut ist im relationalen Modell eine Spalte. Beispiel Tabelle **Kunde**: ```text kunden_id name email telefon ``` Diese Spalten beschreiben den Kunden genauer. Merksatz: **Attribut im ERM wird meistens zur Spalte in der Tabelle.** --- **Primärschlüssel** Ein Primärschlüssel identifiziert jeden Datensatz eindeutig. Beispiel: ```text kunden_id produkt_id bestellung_id ``` Warum ist das wichtig? Namen sind nicht eindeutig. Beispiel: ```text Müller ``` kann mehrfach vorkommen. Aber: ```text kunden_id = 1 ``` ist eindeutig. Merksatz: **Jede Tabelle sollte einen Primärschlüssel haben.** --- **Fremdschlüssel** Ein Fremdschlüssel verweist auf den Primärschlüssel einer anderen Tabelle. Beispiel: Tabelle **Kunde**: | kunden_id | name | |---|---| | 1 | Müller | | 2 | Schmidt | Tabelle **Bestellung**: | bestellung_id | bestelldatum | kunden_id | |---|---|---| | 101 | 01.02.2026 | 1 | | 102 | 03.02.2026 | 1 | Hier ist: ```text kunden_id ``` in der Tabelle **Bestellung** ein Fremdschlüssel. Warum? Weil er auf die Tabelle **Kunde** verweist. ```text Bestellung.kunden_id → Kunde.kunden_id ``` --- **Grafik 2: Vom ERM zum relationalen Modell** ![Vom ERM zum relationalen Modell](https://trainer.ulrich-wiki.com/assets/relationales-modell-erm-zu-tabellen.svg) Diese Grafik zeigt: - Aus der Entität **Kunde** wird die Tabelle **Kunde** - Aus der Entität **Bestellung** wird die Tabelle **Bestellung** - Die 1:n-Beziehung wird durch einen **Fremdschlüssel** auf der n-Seite abgebildet - In der Tabelle **Bestellung** steht deshalb `kunden_id` als Fremdschlüssel --- **ERM vs. relationales Datenbankmodell** | ERM | Relationales Datenbankmodell | |---|---| | fachliches Modell | tabellarisches Modell | | zeigt Entitäten | zeigt Tabellen | | zeigt Attribute | zeigt Spalten | | zeigt Beziehungen | zeigt Fremdschlüssel | | zeigt Kardinalitäten | zeigt Schlüsselbeziehungen | | eher Planung | näher an Datenbank / SQL | Merksatz: ```text ERM = Was gibt es fachlich? Relationales Modell = Wie wird es tabellarisch gespeichert? ``` --- **Aus Entitäten werden Tabellen** Im ERM hast du zum Beispiel: ```text Kunde Bestellung Produkt ``` Im relationalen Modell werden daraus Tabellen: ```text Tabelle Kunde Tabelle Bestellung Tabelle Produkt ``` Beispiel: ```text Entität Kunde ``` wird zu: ```text Kunde(kunden_id, name, email) ``` --- **Aus Attributen werden Spalten** ERM: ```text Kunde - kunden_id - name - email ``` Relationales Modell: | kunden_id | name | email | |---|---|---| Merksatz: **Attribute werden im relationalen Modell zu Spalten.** --- **1:1-Beziehung im relationalen Modell** Beispiel: ```text Person 1 --- 1 Personalausweis ``` Mögliche Tabellen: ```text Person(person_id, name) Personalausweis(ausweis_id, ausweisnummer, person_id) ``` Hier kann `person_id` in **Personalausweis** als Fremdschlüssel gespeichert werden. Wichtig: Bei 1:1 ist fachlich zu prüfen, ob man beide Tabellen wirklich getrennt braucht. --- **1:n-Beziehung im relationalen Modell** Beispiel: ```text Kunde 1 --- n Bestellung ``` Das bedeutet: ```text Ein Kunde kann mehrere Bestellungen haben. Eine Bestellung gehört genau zu einem Kunden. ``` Tabellen: ```text Kunde(kunden_id, name, email) Bestellung(bestellung_id, bestelldatum, kunden_id) ``` Wichtig: Der Fremdschlüssel kommt auf die **n-Seite**. Also: ```text kunden_id ``` steht in: ```text Bestellung ``` Merksatz: **Bei 1:n steht der Fremdschlüssel auf der n-Seite.** --- **n:m-Beziehung im relationalen Modell** Beispiel: ```text Bestellung n --- m Produkt ``` Das bedeutet: ```text Eine Bestellung kann mehrere Produkte enthalten. Ein Produkt kann in mehreren Bestellungen vorkommen. ``` Eine n:m-Beziehung kann man nicht sauber direkt mit nur einem Fremdschlüssel abbilden. Deshalb braucht man eine Zwischentabelle. Aus: ```text Bestellung n:m Produkt ``` wird: ```text Bestellung 1:n Bestellposition n:1 Produkt ``` Tabellen: ```text Bestellung(bestellung_id, bestelldatum) Produkt(produkt_id, bezeichnung, preis) Bestellposition(bestellung_id, produkt_id, menge) ``` Die Tabelle **Bestellposition** enthält mindestens: | Spalte | Bedeutung | |---|---| | bestellung_id | Fremdschlüssel auf Bestellung | | produkt_id | Fremdschlüssel auf Produkt | | menge | Zusatzinformation zur Beziehung | --- **Warum braucht man bei n:m eine Zwischentabelle?** Beispiel: Eine Bestellung enthält mehrere Produkte. Ein Produkt kann in mehreren Bestellungen vorkommen. Zusätzlich muss man speichern: ```text Wie oft wurde ein Produkt bestellt? Welcher Preis galt zum Bestellzeitpunkt? Gab es Rabatt? ``` Diese Informationen gehören nicht nur zur Bestellung und nicht nur zum Produkt. Sie gehören zur Verbindung zwischen Bestellung und Produkt. Deshalb braucht man: ```text Bestellposition ``` --- **Typische Umwandlung von ERM zu relationalem Modell** | ERM | Relationales Modell | |---|---| | Entität | Tabelle | | Attribut | Spalte | | Primärschlüssel | Primärschlüssel | | 1:n-Beziehung | Fremdschlüssel auf n-Seite | | n:m-Beziehung | Zwischentabelle | | Kardinalität | Schlüsselbeziehung | --- **Beispiel: Kunde und Bestellung** Fachliche Beschreibung: ```text Ein Kunde kann mehrere Bestellungen aufgeben. Eine Bestellung gehört genau zu einem Kunden. ``` ERM: ```text Kunde 1 --- n Bestellung ``` Relationales Modell: ```text Kunde(kunden_id, name, email) Bestellung(bestellung_id, bestelldatum, kunden_id) ``` Erklärung: ```text kunden_id ist Primärschlüssel in Kunde. kunden_id ist Fremdschlüssel in Bestellung. ``` --- **Beispiel: Schüler und Kurs** Fachliche Beschreibung: ```text Ein Schüler kann mehrere Kurse belegen. Ein Kurs kann von mehreren Schülern belegt werden. ``` ERM: ```text Schüler n --- m Kurs ``` Relationales Modell: ```text Schüler(schueler_id, vorname, nachname) Kurs(kurs_id, kursname) Belegung(schueler_id, kurs_id, anmeldedatum) ``` Erklärung: ```text Belegung ist die Zwischentabelle. schueler_id ist Fremdschlüssel auf Schüler. kurs_id ist Fremdschlüssel auf Kurs. ``` --- **Primärschlüssel und Fremdschlüssel markieren** In der Prüfung kannst du Schlüssel zum Beispiel so kennzeichnen: ```text PK = Primary Key = Primärschlüssel FK = Foreign Key = Fremdschlüssel ``` Beispiel: ```text Kunde( kunden_id PK, name, email ) Bestellung( bestellung_id PK, bestelldatum, kunden_id FK ) ``` Oder kompakt: ```text Kunde(kunden_id PK, name, email) Bestellung(bestellung_id PK, bestelldatum, kunden_id FK) ``` --- **Zusammengesetzter Primärschlüssel** Bei Zwischentabellen kann der Primärschlüssel aus mehreren Spalten bestehen. Beispiel: ```text Belegung(schueler_id, kurs_id, anmeldedatum) ``` Hier könnten zusammen den Datensatz eindeutig machen: ```text schueler_id + kurs_id ``` Das nennt man einen **zusammengesetzten Primärschlüssel**. Alternative: Man kann auch eine eigene ID verwenden: ```text belegung_id ``` Dann sieht die Tabelle so aus: ```text Belegung(belegung_id PK, schueler_id FK, kurs_id FK, anmeldedatum) ``` Beides kann je nach Aufgabenstellung sinnvoll sein. --- **Normalisierung kurz erklärt** Normalisierung bedeutet: ```text Daten so strukturieren, dass Wiederholungen und Fehler vermieden werden. ``` Einfach gesagt: ```text Gleiche Informationen sollen nicht unnötig mehrfach gespeichert werden. ``` Schlechtes Beispiel: | bestellung_id | kundenname | kundenemail | produkt | |---|---|---|---| | 1 | Müller | mueller@example.de | Monitor | | 2 | Müller | mueller@example.de | Tastatur | Problem: ```text Kundendaten werden mehrfach gespeichert. ``` Besser: ```text Kunde(kunden_id, name, email) Bestellung(bestellung_id, kunden_id) ``` Dann stehen die Kundendaten nur einmal in der Tabelle **Kunde**. --- **Vorgehensweise in der Prüfung** Wenn du ein relationales Datenbankmodell erstellen sollst, gehe so vor: | Schritt | Frage | |---|---| | 1 | Welche Entitäten gibt es? | | 2 | Welche Tabellen entstehen daraus? | | 3 | Welche Attribute werden zu Spalten? | | 4 | Was ist der Primärschlüssel jeder Tabelle? | | 5 | Gibt es eine 1:n-Beziehung? | | 6 | Wo muss der Fremdschlüssel stehen? | | 7 | Gibt es eine n:m-Beziehung? | | 8 | Welche Zwischentabelle wird benötigt? | | 9 | Welche Zusatzattribute gehören in die Zwischentabelle? | --- **Typische IHK-Fehler** | Fehler | Warum problematisch? | |---|---| | Primärschlüssel vergessen | Datensätze sind nicht eindeutig erkennbar | | Fremdschlüssel auf falscher Seite | Beziehung wird falsch abgebildet | | n:m ohne Zwischentabelle | Relational unsauber | | Attribute doppelt speichern | führt zu Redundanz | | Entität und Attribut verwechseln | falsche Tabellenstruktur | | Zwischentabelle ohne Fremdschlüssel | Verbindung zwischen Tabellen fehlt | | Kardinalität nicht beachtet | falsche Modellierung | --- **Prüfungs-Merksätze** ```text Tabelle = Sammlung gleichartiger Datensätze Datensatz = eine Tabellenzeile Attribut = Spalte Primärschlüssel = eindeutige ID Fremdschlüssel = Verweis auf andere Tabelle 1:n = Fremdschlüssel auf der n-Seite n:m = Zwischentabelle nötig ERM = fachliche Sicht Relationales Modell = Tabellen- und Schlüssel-Sicht ``` --- **Mini-Beispiel 1** Aufgabe: ```text Ein Kunde kann mehrere Bestellungen haben. Eine Bestellung gehört genau zu einem Kunden. ``` Lösung: ```text Kunde(kunden_id PK, name, email) Bestellung(bestellung_id PK, bestelldatum, kunden_id FK) ``` Begründung: ```text 1:n-Beziehung. Der Fremdschlüssel kunden_id steht auf der n-Seite, also in Bestellung. ``` --- **Mini-Beispiel 2** Aufgabe: ```text Ein Schüler kann mehrere Kurse belegen. Ein Kurs kann von mehreren Schülern belegt werden. ``` Lösung: ```text Schüler(schueler_id PK, vorname, nachname) Kurs(kurs_id PK, kursname) Belegung(schueler_id FK, kurs_id FK, anmeldedatum) ``` Begründung: ```text n:m-Beziehung. Deshalb braucht man eine Zwischentabelle. ``` --- **Mini-Beispiel 3** Aufgabe: ```text Eine Bestellung kann mehrere Produkte enthalten. Ein Produkt kann in mehreren Bestellungen vorkommen. ``` Lösung: ```text Bestellung(bestellung_id PK, bestelldatum) Produkt(produkt_id PK, bezeichnung, preis) Bestellposition(bestellung_id FK, produkt_id FK, menge) ``` Begründung: ```text n:m-Beziehung. Bestellposition löst die Beziehung auf und speichert zusätzlich die Menge. ``` --- **Mini-Testfragen**
1. Was ist eine Tabelle? Eine Tabelle speichert gleichartige Datensätze. Beispiel: ```text Kunde Produkt Bestellung ```
2. Was ist ein Datensatz? Ein Datensatz ist eine einzelne Zeile in einer Tabelle. Beispiel: ```text kunden_id = 1, name = Müller, email = mueller@example.de ```
3. Was ist ein Primärschlüssel? Ein Primärschlüssel identifiziert jeden Datensatz eindeutig. Beispiel: ```text kunden_id produkt_id bestellung_id ```
4. Was ist ein Fremdschlüssel? Ein Fremdschlüssel verweist auf den Primärschlüssel einer anderen Tabelle. Beispiel: ```text Bestellung.kunden_id verweist auf Kunde.kunden_id ```
5. Wo steht der Fremdschlüssel bei einer 1:n-Beziehung? Der Fremdschlüssel steht auf der **n-Seite**. Beispiel: ```text Kunde 1:n Bestellung ``` Dann steht: ```text kunden_id ``` in der Tabelle: ```text Bestellung ```
6. Was braucht man bei einer n:m-Beziehung? Eine n:m-Beziehung braucht eine **Zwischentabelle**. Beispiel: ```text Schüler n:m Kurs ``` wird zu: ```text Schüler 1:n Belegung n:1 Kurs ```
7. Warum ist eine Zwischentabelle bei Bestellung und Produkt sinnvoll? Weil eine Bestellung mehrere Produkte enthalten kann und ein Produkt in mehreren Bestellungen vorkommen kann. Außerdem können Zusatzinformationen gespeichert werden: ```text menge einzelpreis rabatt ``` Diese gehören zur Verbindung zwischen Bestellung und Produkt.
8. Was bedeutet Normalisierung ganz einfach? Normalisierung bedeutet, Daten so zu strukturieren, dass unnötige Wiederholungen und Fehler vermieden werden. Merksatz: ```text Informationen möglichst nur einmal speichern. ```
--- **Nächste Seite** Danach kommt die eigene Trainer-Seite: ```text Relationales-Datenbankmodell-Trainer ``` Dort bauen wir den interaktiven Trainer mit Aufgaben zu: ```text Tabellen ableiten Primärschlüssel bestimmen Fremdschlüssel richtig platzieren 1:n-Beziehungen umsetzen n:m-Beziehungen mit Zwischentabelle auflösen ``` # Seite 6 Relationales-Datenbankmodell-Trainer Dieser interaktive Trainer gehört zur Theorie-Seite: ```text Relationales Datenbankmodell ``` Hier übst du, aus kurzen Aufgabenstellungen ein relationales Datenbankmodell abzuleiten. Im Fokus stehen: ```text Tabellen Primärschlüssel Fremdschlüssel 1:n-Beziehungen n:m-Beziehungen Zwischentabellen ``` --- **Was wird trainiert?** | Bereich | Bedeutung | |---|---| | **Tabellen ableiten** | Entitäten aus dem ERM werden Tabellen | | **Primärschlüssel bestimmen** | Jede Tabelle braucht eine eindeutige ID | | **Fremdschlüssel platzieren** | Bei 1:n steht der Fremdschlüssel auf der n-Seite | | **Beziehungen erkennen** | 1:1, 1:n, n:1 oder n:m | | **Zwischentabelle erkennen** | n:m-Beziehungen werden über eine Zwischentabelle gelöst | | **IHK-typische Aufgaben lösen** | Fachliche Beschreibung in Tabellenstruktur umwandeln | --- **Interaktiver Relationales-Datenbankmodell-Trainer**
Relationales-Datenbankmodell-Trainer im Vollbild öffnen
--- **Merksatz für den Trainer** ```text Entität im ERM → Tabelle im relationalen Modell Attribut im ERM → Spalte in der Tabelle Primärschlüssel → eindeutige ID einer Tabelle Fremdschlüssel → Verweis auf eine andere Tabelle 1:n-Beziehung → Fremdschlüssel auf der n-Seite n:m-Beziehung → Zwischentabelle mit Fremdschlüsseln ``` --- **Beispiel 1: 1:n-Beziehung** Aufgabenstellung: ```text Ein Kunde kann mehrere Bestellungen aufgeben. Eine Bestellung gehört genau zu einem Kunden. ``` Relationales Modell: ```text Kunde(kunden_id PK, name, email) Bestellung(bestellung_id PK, bestelldatum, kunden_id FK) ``` Warum? ```text Kunde 1:n Bestellung ``` Der Fremdschlüssel steht auf der n-Seite. Also steht: ```text kunden_id ``` in der Tabelle: ```text Bestellung ``` --- **Beispiel 2: n:m-Beziehung** Aufgabenstellung: ```text Ein Schüler kann mehrere Kurse belegen. Ein Kurs kann von mehreren Schülern belegt werden. ``` Relationales Modell: ```text Schüler(schueler_id PK, vorname, nachname) Kurs(kurs_id PK, kursname) Belegung(schueler_id FK, kurs_id FK, anmeldedatum) ``` Warum? ```text Schüler n:m Kurs ``` Eine n:m-Beziehung braucht eine Zwischentabelle. Hier heißt sie: ```text Belegung ``` --- **Beispiel 3: Bestellung und Produkt** Aufgabenstellung: ```text Eine Bestellung kann mehrere Produkte enthalten. Ein Produkt kann in mehreren Bestellungen vorkommen. ``` Relationales Modell: ```text Bestellung(bestellung_id PK, bestelldatum) Produkt(produkt_id PK, bezeichnung, preis) Bestellposition(bestellung_id FK, produkt_id FK, menge) ``` Warum? ```text Bestellung n:m Produkt ``` Die Zwischentabelle **Bestellposition** löst die n:m-Beziehung auf. Zusätzlich kann dort gespeichert werden: ```text menge einzelpreis rabatt ``` --- **Typische Fehler im Trainer** | Fehler | Warum falsch? | |---|---| | Fremdschlüssel auf der falschen Seite | Bei 1:n muss der FK auf die n-Seite | | n:m ohne Zwischentabelle | n:m braucht im relationalen Modell eine eigene Tabelle | | Primärschlüssel vergessen | Datensätze sind nicht eindeutig | | Zwischentabelle ohne beide Fremdschlüssel | Verbindung ist nicht vollständig | | Attribute doppelt speichern | führt zu Redundanz | | Tabelle und Entität verwechseln | ERM ist fachlich, relationales Modell ist tabellarisch | --- **Mini-Testfragen**
1. Was wird aus einer Entität im relationalen Modell? Aus einer Entität wird meistens eine **Tabelle**. Beispiel: ```text Entität Kunde ``` wird zu: ```text Tabelle Kunde ```
2. Was wird aus einem Attribut im relationalen Modell? Aus einem Attribut wird meistens eine **Spalte**. Beispiel: ```text Attribut name ``` wird zu: ```text Spalte name ```
3. Was ist ein Primärschlüssel? Ein Primärschlüssel identifiziert jeden Datensatz eindeutig. Beispiel: ```text kunden_id produkt_id bestellung_id ```
4. Was ist ein Fremdschlüssel? Ein Fremdschlüssel verweist auf den Primärschlüssel einer anderen Tabelle. Beispiel: ```text Bestellung.kunden_id verweist auf Kunde.kunden_id ```
5. Wo steht der Fremdschlüssel bei einer 1:n-Beziehung? Der Fremdschlüssel steht auf der **n-Seite**. Beispiel: ```text Kunde 1:n Bestellung ``` Dann steht: ```text kunden_id ``` in der Tabelle: ```text Bestellung ```
6. Was braucht man bei einer n:m-Beziehung? Eine n:m-Beziehung braucht eine **Zwischentabelle**. Beispiel: ```text Schüler n:m Kurs ``` wird zu: ```text Schüler 1:n Belegung n:1 Kurs ```
7. Welche Fremdschlüssel enthält die Zwischentabelle bei Schüler und Kurs? Die Zwischentabelle enthält mindestens: ```text schueler_id FK kurs_id FK ``` Beispiel: ```text Belegung(schueler_id FK, kurs_id FK, anmeldedatum) ```
8. Warum ist Bestellposition eine sinnvolle Zwischentabelle? Weil eine Bestellung mehrere Produkte enthalten kann und ein Produkt in mehreren Bestellungen vorkommen kann. Außerdem kann die Tabelle **Bestellposition** Zusatzinformationen speichern: ```text menge einzelpreis rabatt ```
9. Was ist ein zusammengesetzter Primärschlüssel? Ein zusammengesetzter Primärschlüssel besteht aus mehreren Spalten. Beispiel: ```text Belegung(schueler_id, kurs_id) ``` Zusammen können beide Werte einen Datensatz eindeutig machen.
10. Was ist der häufigste Fehler bei n:m-Beziehungen? Der häufigste Fehler ist, keine Zwischentabelle zu erstellen. Falsch: ```text Schüler n:m Kurs direkt speichern ``` Besser: ```text Schüler 1:n Belegung n:1 Kurs ```
--- **Nächste Seite** Danach geht es weiter mit: ```text UML-Klassendiagramm ``` # Seite 7. UML-Klassendiagramm **UML-Klassendiagramm** Diese Seite erklärt das **UML-Klassendiagramm** so, dass du es schnell für IHK-Aufgaben und Java/OOP-Aufgaben anwenden kannst. Ein UML-Klassendiagramm wird benutzt, um die **Struktur eines Programms** darzustellen. Es zeigt: ```text Klassen Attribute Methoden Sichtbarkeit Beziehungen zwischen Klassen Vererbung ``` --- **Grafik 1: UML-Klassendiagramm – Grundlagen** ![UML-Klassendiagramm – Grundlagen](https://trainer.ulrich-wiki.com/assets/uml-klassendiagramm-grundlagen.svg?v=3) Diese Grafik zeigt dir die wichtigsten Bausteine eines UML-Klassendiagramms: - Klassenname - Attribute - Methoden - Sichtbarkeit mit `+`, `-` und `#` - Assoziation - Vererbung --- **Wofür braucht man ein UML-Klassendiagramm?** Ein UML-Klassendiagramm hilft dir, die Struktur eines objektorientierten Programms zu planen. Beispiel: ```text Es soll eine Produktverwaltung erstellt werden. Ein Produkt hat eine Marke, ein Modell und einen Preis. Monitore und Tastaturen sind spezielle Produkte. ``` Daraus erkennt man: - Es gibt Klassen. - Klassen haben Attribute. - Klassen haben Methoden. - Manche Klassen hängen miteinander zusammen. - Manche Klassen können von anderen Klassen erben. --- **Woran erkenne ich in einer Aufgabe, dass ein UML-Klassendiagramm gemeint ist?** Typische Signalwörter: | Signalwort / Formulierung | Hinweis | |---|---| | Klasse | Es geht um OOP / Programmstruktur | | Attribut | Eigenschaft einer Klasse | | Methode | Funktion / Verhalten einer Klasse | | Objekt | konkrete Instanz einer Klasse | | Vererbung | Oberklasse / Unterklasse | | Assoziation | Beziehung zwischen Klassen | | Java-Klassen | meist UML-Klassendiagramm | | „modellieren Sie die Klassenstruktur“ | Klassendiagramm | | „stellen Sie Attribute und Methoden dar“ | Klassendiagramm | --- **Aufbau einer Klasse** Eine Klasse wird im UML-Klassendiagramm meistens als Rechteck mit drei Bereichen dargestellt: ```text ┌────────────────────────┐ │ Klassenname │ ├────────────────────────┤ │ Attribute │ ├────────────────────────┤ │ Methoden │ └────────────────────────┘ ``` Beispiel: ```text ┌────────────────────────┐ │ Produkt │ ├────────────────────────┤ │ - marke: String │ │ - modell: String │ │ - preis: double │ ├────────────────────────┤ │ + getPreis(): double │ │ + toString(): String │ └────────────────────────┘ ``` --- **Klassenname** Der Klassenname steht oben im Klassendiagramm. Beispiele: ```text Produkt Monitor Tastatur Kunde Bestellung Benutzer ``` Merksatz: **Klassennamen werden meistens großgeschrieben und stehen im Singular.** Also eher: ```text Produkt ``` nicht: ```text Produkte ``` --- **Attribute** Attribute beschreiben die Eigenschaften einer Klasse. Beispiel Klasse **Produkt**: ```text - marke: String - modell: String - preis: double ``` Das bedeutet: | Attribut | Datentyp | Bedeutung | |---|---|---| | marke | String | Marke des Produkts | | modell | String | Modellbezeichnung | | preis | double | Preis | Merksatz: **Attribute sind das, was ein Objekt speichert.** --- **Methoden** Methoden beschreiben, was ein Objekt tun kann. Beispiel: ```text + getPreis(): double + setPreis(preis: double): void + toString(): String ``` Aufbau einer Methode: ```text sichtbarkeit methodenname(parameter): rückgabetyp ``` Beispiel: ```text + setPreis(preis: double): void ``` Bedeutung: | Teil | Bedeutung | |---|---| | `+` | public | | `setPreis` | Methodenname | | `preis: double` | Parameter | | `void` | kein Rückgabewert | --- **Sichtbarkeit** Die Sichtbarkeit zeigt, von wo aus auf Attribute oder Methoden zugegriffen werden darf. | Zeichen | Bedeutung | Erklärung | |---|---|---| | `+` | public | öffentlich zugreifbar | | `-` | private | nur innerhalb der Klasse | | `#` | protected | Klasse und Unterklassen | | `~` | package | innerhalb des Pakets | Für IHK und Java-Grundlagen sind besonders wichtig: ```text + public - private # protected ``` Typisch in Java: ```text private String marke; public String toString() ``` UML: ```text - marke: String + toString(): String ``` --- **Attribute sind meistens private** In Java sind Attribute meistens private. Beispiel Java: ```java private String marke; private String modell; private double preis; ``` UML: ```text - marke: String - modell: String - preis: double ``` Warum? Damit nicht jeder direkt von außen auf die Daten zugreifen kann. Das nennt man **Kapselung**. --- **Methoden sind oft public** Methoden, die von außen genutzt werden sollen, sind meistens public. Beispiel Java: ```java public String toString() { return marke + " " + modell; } ``` UML: ```text + toString(): String ``` --- **Grafik 2: Beispiel Produktverwaltung** ![UML-Klassendiagramm – Beispiel Produktverwaltung](https://trainer.ulrich-wiki.com/assets/uml-klassendiagramm-beispiel-produktverwaltung.svg) Diese Grafik zeigt ein typisches UML-Klassendiagramm für eine Produktverwaltung: - **Produkt** ist die Oberklasse - **Monitor** ist eine spezielle Produktart - **Tastatur** ist eine spezielle Produktart - gemeinsame Attribute gehören in die Oberklasse - spezielle Attribute gehören in die Unterklassen --- **Beispiel: Produkt als Oberklasse** Wenn mehrere Produktarten gemeinsame Eigenschaften haben, kann man eine Oberklasse verwenden. Beispiel: ```text Produkt - marke - modell - preis ``` Diese Attribute können für viele Produktarten gelten: ```text Monitor Tastatur Maus CPU ``` Deshalb gehören sie in die gemeinsame Oberklasse **Produkt**. --- **Vererbung** Vererbung bedeutet: ```text Eine Unterklasse übernimmt Eigenschaften und Methoden einer Oberklasse. ``` Beispiel: ```text Monitor erbt von Produkt. Tastatur erbt von Produkt. ``` Das bedeutet: ```text Monitor ist ein Produkt. Tastatur ist ein Produkt. ``` UML-Darstellung: ```text Monitor ─────▷ Produkt Tastatur ────▷ Produkt ``` Der Pfeil zeigt zur **Oberklasse**. Merksatz: **Der Vererbungs-Pfeil zeigt immer zur allgemeineren Klasse.** --- **Oberklasse und Unterklasse** | Begriff | Bedeutung | Beispiel | |---|---|---| | Oberklasse | allgemeine Klasse | Produkt | | Unterklasse | spezielle Klasse | Monitor | | Vererbung | Unterklasse übernimmt von Oberklasse | Monitor erbt von Produkt | Beispiel: ```text Produkt - marke - modell - preis Monitor - groesseZoll - aufloesung ``` Der Monitor hat dann fachlich: ```text marke modell preis groesseZoll aufloesung ``` --- **Assoziation** Eine Assoziation ist eine normale Beziehung zwischen Klassen. Beispiel: ```text Kunde gibt Bestellung auf ``` Als Klassendiagramm: ```text Kunde ───────── Bestellung ``` Eine Assoziation bedeutet: ```text Diese Klassen stehen miteinander in Beziehung. ``` --- **Multiplizität** Die Multiplizität zeigt, wie viele Objekte miteinander verbunden sein können. | Multiplizität | Bedeutung | |---|---| | `1` | genau eins | | `0..1` | kein oder eins | | `*` | beliebig viele | | `1..*` | mindestens eins | | `0..*` | beliebig viele oder keine | Beispiel: ```text Kunde 1 ───── 0..* Bestellung ``` Bedeutung: ```text Ein Kunde kann keine, eine oder mehrere Bestellungen haben. Eine Bestellung gehört zu genau einem Kunden. ``` --- **Unterschied Kardinalität und Multiplizität** In ERM sagt man oft: ```text 1:n n:m ``` Im UML-Klassendiagramm sieht man eher: ```text 1 0..* 1..* * ``` Beispiel: ```text Kunde 1 ───── 0..* Bestellung ``` entspricht ungefähr: ```text Kunde 1:n Bestellung ``` --- **Aggregation und Komposition kurz erklärt** Diese beiden Beziehungen können in UML vorkommen, sind aber für den schnellen IHK-Einstieg nicht immer der Schwerpunkt. | Beziehung | Symbol | Bedeutung | |---|---|---| | Aggregation | leere Raute | Teil-Ganzes-Beziehung, Teil kann auch ohne Ganzes existieren | | Komposition | gefüllte Raute | starke Teil-Ganzes-Beziehung, Teil gehört fest zum Ganzen | Einfacher Merksatz: ```text Aggregation = hat-Beziehung, Teil kann unabhängig existieren Komposition = besteht-aus-Beziehung, Teil ist stark abhängig ``` Beispiel Aggregation: ```text Team hat Mitarbeiter ``` Ein Mitarbeiter kann auch ohne dieses Team existieren. Beispiel Komposition: ```text Rechnung besteht aus Rechnungspositionen ``` Eine Rechnungsposition ergibt ohne Rechnung meist keinen Sinn. --- **Unterschied Klasse und Objekt** | Begriff | Bedeutung | Beispiel | |---|---|---| | Klasse | Bauplan | Produkt | | Objekt | konkrete Ausprägung | Produkt p1 = neuer Monitor | Beispiel: ```text Klasse: Produkt Objekt: monitor1 ``` Java: ```java Produkt monitor1 = new Produkt("Dell", "U2723QE", 499.99); ``` Die Klasse beschreibt, welche Attribute und Methoden ein Objekt haben kann. Das Objekt ist eine konkrete Instanz dieser Klasse. --- **UML-Klassendiagramm vs. ERM** | UML-Klassendiagramm | ERM | |---|---| | zeigt Programmstruktur | zeigt Datenmodell | | Klassen | Entitäten | | Attribute | Attribute | | Methoden | keine Methoden | | Vererbung möglich | normalerweise keine Methoden/Vererbung | | wichtig für OOP / Java | wichtig für Datenbanken | Merksatz: ```text ERM = Daten fachlich modellieren UML-Klassendiagramm = Programmklassen modellieren ``` --- **Vorgehensweise in der Prüfung** Wenn du ein UML-Klassendiagramm erstellen sollst, gehe so vor: | Schritt | Frage | |---|---| | 1 | Welche Klassen gibt es? | | 2 | Welche Attribute gehören zu welcher Klasse? | | 3 | Welche Methoden sind sinnvoll oder vorgegeben? | | 4 | Gibt es gemeinsame Eigenschaften? | | 5 | Kann man eine Oberklasse bilden? | | 6 | Gibt es Vererbung? | | 7 | Gibt es Beziehungen zwischen Klassen? | | 8 | Welche Multiplizitäten sind sinnvoll? | | 9 | Welche Sichtbarkeit brauchen Attribute und Methoden? | --- **Beispiel: Produktverwaltung** Fachliche Beschreibung: ```text Es soll eine Produktverwaltung erstellt werden. Jedes Produkt hat eine Marke, ein Modell und einen Preis. Ein Monitor hat zusätzlich eine Größe in Zoll und eine Auflösung. Eine Tastatur hat zusätzlich ein Layout und die Information, ob sie mechanisch ist. ``` Mögliche Klassen: ```text Produkt Monitor Tastatur ``` Oberklasse: ```text Produkt ``` Unterklassen: ```text Monitor Tastatur ``` Warum? ```text Monitor ist ein Produkt. Tastatur ist ein Produkt. ``` --- **Mögliches Klassendiagramm als Text** ```text Produkt -------------------------------- - marke: String - modell: String - preis: double -------------------------------- + toString(): String Monitor extends Produkt -------------------------------- - groesseZoll: double - aufloesung: String -------------------------------- + toString(): String Tastatur extends Produkt -------------------------------- - layout: String - mechanisch: boolean -------------------------------- + toString(): String ``` --- **Typische IHK-Fehler beim UML-Klassendiagramm** | Fehler | Warum problematisch? | |---|---| | Attribute und Methoden vermischen | Attribut speichert Daten, Methode führt Verhalten aus | | Sichtbarkeit vergessen | `+`, `-`, `#` sind wichtige UML-Informationen | | Attribute öffentlich machen | In Java sind Attribute meist private | | Vererbung falsch herum zeichnen | Pfeil zeigt zur Oberklasse | | Klassen im Plural schreiben | Klassennamen meist Singular | | ERM und Klassendiagramm verwechseln | ERM hat keine Methoden | | Methoden ohne Rückgabetyp schreiben | Rückgabetyp gehört häufig dazu | | Unterklasse enthält alle Oberklassenattribute doppelt | Gemeinsames gehört in die Oberklasse | --- **Prüfungs-Merksätze** ```text Klasse = Bauplan für Objekte Objekt = konkrete Instanz einer Klasse Attribut = gespeicherte Eigenschaft Methode = Verhalten / Funktion + = public - = private # = protected Vererbungspfeil zeigt zur Oberklasse Gemeinsame Attribute gehören in die Oberklasse Spezielle Attribute gehören in die Unterklasse ERM zeigt Daten, Klassendiagramm zeigt Programmstruktur ``` --- **Mini-Beispiel 1** Aufgabe: ```text Ein Produkt hat eine Marke, ein Modell und einen Preis. ``` Lösung: ```text Produkt -------------------------------- - marke: String - modell: String - preis: double ``` Begründung: ```text marke, modell und preis sind Eigenschaften eines Produkts. Deshalb sind sie Attribute. ``` --- **Mini-Beispiel 2** Aufgabe: ```text Ein Monitor ist ein Produkt und hat zusätzlich eine Größe in Zoll. ``` Lösung: ```text Monitor erbt von Produkt. Monitor -------------------------------- - groesseZoll: double ``` Begründung: ```text Monitor ist eine spezielle Produktart. Deshalb ist Vererbung sinnvoll. ``` --- **Mini-Beispiel 3** Aufgabe: ```text Ein Kunde kann mehrere Bestellungen haben. ``` Mögliches UML-Klassendiagramm: ```text Kunde 1 ───── 0..* Bestellung ``` Begründung: ```text Ein Kunde kann mehrere Bestellungen haben. Eine Bestellung gehört zu einem Kunden. ``` --- **Mini-Testfragen**
1. Wofür wird ein UML-Klassendiagramm verwendet? Ein UML-Klassendiagramm wird verwendet, um die Struktur eines objektorientierten Programms darzustellen. Es zeigt: ```text Klassen Attribute Methoden Beziehungen Vererbung ```
2. Was ist eine Klasse? Eine Klasse ist ein Bauplan für Objekte. Beispiel: ```text Produkt Monitor Tastatur ```
3. Was ist ein Attribut? Ein Attribut ist eine gespeicherte Eigenschaft einer Klasse. Beispiel: ```text - marke: String - preis: double ```
4. Was ist eine Methode? Eine Methode beschreibt ein Verhalten oder eine Funktion einer Klasse. Beispiel: ```text + toString(): String + getPreis(): double ```
5. Was bedeutet `+` im UML-Klassendiagramm? `+` bedeutet: ```text public / öffentlich ``` Das Element ist von außen zugreifbar.
6. Was bedeutet `-` im UML-Klassendiagramm? `-` bedeutet: ```text private / privat ``` Das Element ist nur innerhalb der Klasse direkt zugreifbar.
7. In welche Richtung zeigt der Vererbungspfeil? Der Vererbungspfeil zeigt zur **Oberklasse**. Beispiel: ```text Monitor ───▷ Produkt ```
8. Warum gehören marke, modell und preis in die Klasse Produkt? Weil diese Attribute für mehrere Produktarten gemeinsam gelten können. Beispiele: ```text Monitor Tastatur Maus CPU ``` Alle können Marke, Modell und Preis haben.
9. Was ist der Unterschied zwischen Klasse und Objekt? Eine Klasse ist der Bauplan. Ein Objekt ist eine konkrete Instanz dieser Klasse. Beispiel: ```text Klasse: Produkt Objekt: monitor1 ```
10. Was ist der Unterschied zwischen ERM und UML-Klassendiagramm? ERM modelliert Daten fachlich. UML-Klassendiagramm modelliert die Programmstruktur. Wichtig: ```text Ein Klassendiagramm kann Methoden und Vererbung enthalten. Ein ERM normalerweise nicht. ```
--- **Nächste Seite** Danach kommt die eigene Trainer-Seite: ```text UML-Klassendiagramm-Trainer ``` Dort bauen wir den interaktiven Trainer mit Aufgaben zu: ```text Klassen erkennen Attribute zuordnen Methoden eintragen Sichtbarkeit bestimmen Vererbung erkennen Beziehungen zwischen Klassen darstellen ``` # Seite 8. UML-Klassendiagramm-Trainer **UML-Klassendiagramm-Trainer** Dieser interaktive Trainer gehört zur Theorie-Seite: ```text UML-Klassendiagramm ``` Hier übst du, UML-Klassendiagramme richtig zu lesen und aus Aufgabenstellungen abzuleiten. Im Fokus stehen: ```text Klassen Attribute Methoden Sichtbarkeit Assoziation Vererbung Aggregation Komposition korrekte UML-Linienenden ``` --- **Was wird trainiert?** | Bereich | Bedeutung | |---|---| | **Klassen erkennen** | wichtige Programmobjekte aus der Aufgabe ableiten | | **Attribute zuordnen** | gespeicherte Eigenschaften in die richtige Klasse schreiben | | **Methoden eintragen** | Verhalten/Funktionen einer Klasse ergänzen | | **Sichtbarkeit beachten** | `+`, `-`, `#` korrekt selbst eintragen | | **Vererbung erkennen** | hohles Dreieck zeigt zur Oberklasse | | **Aggregation erkennen** | leere Raute steht am Ganzen | | **Komposition erkennen** | gefüllte Raute steht am Ganzen | | **Assoziation erkennen** | einfache Linie zwischen Klassen | --- **Interaktiver UML-Klassendiagramm-Trainer**
UML-Klassendiagramm-Trainer im Vollbild öffnen
--- **Merksatz für den Trainer** ```text Einfache Linie = Assoziation Hohles Dreieck = Vererbung / Generalisierung Leere Raute = Aggregation Gefüllte Raute = Komposition Raute steht am Ganzen Vererbungsdreieck zeigt zur Oberklasse - bedeutet private + bedeutet public ``` --- **Beispiel: Assoziation** Aufgabe: ```text Ein Kunde kann mehrere Bestellungen haben. Eine Bestellung gehört zu genau einem Kunden. ``` UML-Bedeutung: ```text Kunde ist mit Bestellung verbunden. ``` Darstellung: ```text Kunde ───── Bestellung ``` Wichtig: ```text Eine Assoziation ist eine normale Beziehung zwischen Klassen. Sie wird als einfache Linie dargestellt. ``` --- **Beispiel: Vererbung** Aufgabe: ```text Ein Monitor ist ein Produkt. ``` UML-Bedeutung: ```text Monitor erbt von Produkt. ``` Darstellung: ```text Monitor ─────▷ Produkt ``` Wichtig: ```text Das hohle Dreieck zeigt zur Oberklasse Produkt. ``` --- **Beispiel: Aggregation** Aufgabe: ```text Ein Team hat mehrere Mitarbeiter. Ein Mitarbeiter kann aber auch unabhängig vom Team existieren. ``` UML-Bedeutung: ```text Team aggregiert Mitarbeiter. ``` Darstellung: ```text Team ◇──── Mitarbeiter ``` Wichtig: ```text Die leere Raute steht am Ganzen, also bei Team. Aggregation ist eine schwächere Teil-Ganzes-Beziehung. Der Teil kann unabhängig vom Ganzen existieren. ``` --- **Beispiel: Komposition** Aufgabe: ```text Eine Rechnung besteht aus Rechnungspositionen. Eine Rechnungsposition gehört fest zu genau einer Rechnung. ``` UML-Bedeutung: ```text Rechnung besteht aus Rechnungspositionen. ``` Darstellung: ```text Rechnung ◆──── Rechnungsposition ``` Wichtig: ```text Die gefüllte Raute steht am Ganzen, also bei Rechnung. Komposition ist eine starke Teil-Ganzes-Beziehung. Der Teil ist fest vom Ganzen abhängig. ``` --- **Wichtiger Unterschied: Aggregation vs. Komposition** | Beziehung | Symbol | Bedeutung | Beispiel | |---|---|---|---| | **Aggregation** | leere Raute | schwache Teil-Ganzes-Beziehung | Team hat Mitarbeiter | | **Komposition** | gefüllte Raute | starke Teil-Ganzes-Beziehung | Rechnung besteht aus Positionen | Merksatz: ```text Leere Raute = Teil kann unabhängig existieren. Gefüllte Raute = Teil gehört fest zum Ganzen. ``` --- **Wichtiger Unterschied: Assoziation vs. Vererbung** | Beziehung | Symbol | Bedeutung | |---|---|---| | **Assoziation** | einfache Linie | Klassen stehen miteinander in Beziehung | | **Vererbung** | hohles Dreieck | Unterklasse erbt von Oberklasse | Beispiel Assoziation: ```text Kunde ───── Bestellung ``` Bedeutung: ```text Kunde und Bestellung hängen fachlich zusammen. ``` Beispiel Vererbung: ```text Monitor ─────▷ Produkt ``` Bedeutung: ```text Monitor ist ein spezielles Produkt. ``` --- **Sichtbarkeit im Trainer** Im Trainer musst du Sichtbarkeiten selbst eintragen. | Zeichen | Bedeutung | Typisch für | |---|---|---| | `+` | public / öffentlich | Methoden | | `-` | private / privat | Attribute | | `#` | protected / geschützt | Vererbung / Unterklassen | Beispiel: ```text - marke: String + toString(): String ``` Wichtig: ```text Das + oder - soll nicht schon im Feld stehen. Du sollst es selbst erkennen und eintragen. ``` --- **Typische Aufgaben im Trainer** Der Trainer enthält Aufgaben zu: ```text Vererbung: Monitor ist ein Produkt. Assoziation: Kunde hat Bestellungen. Aggregation: Team hat Mitarbeiter. Komposition: Rechnung besteht aus Rechnungspositionen. ``` --- **Typische Fehler** | Fehler | Warum falsch? | |---|---| | Raute auf der falschen Seite | Die Raute steht immer am Ganzen | | Vererbungsdreieck zeigt zur Unterklasse | Das Dreieck muss zur Oberklasse zeigen | | Aggregation und Komposition verwechseln | Leere Raute und gefüllte Raute haben unterschiedliche Bedeutung | | `+` und `-` vergessen | Sichtbarkeit ist Teil der UML-Notation | | Attribute und Methoden vermischen | Attribute speichern Daten, Methoden beschreiben Verhalten | | Oberklasse und Unterklasse vertauschen | Gemeinsame Eigenschaften gehören in die Oberklasse | --- **Mini-Testfragen**
1. Welche Linie zeigt eine normale Assoziation? Eine normale Assoziation wird durch eine einfache durchgezogene Linie dargestellt. Beispiel: ```text Kunde ───── Bestellung ```
2. Welche Pfeilspitze zeigt Vererbung? Vererbung wird mit einem **hohlen Dreieck** dargestellt. Wichtig: ```text Das hohle Dreieck zeigt zur Oberklasse. ``` Beispiel: ```text Monitor ─────▷ Produkt ```
3. Was bedeutet eine leere Raute? Eine leere Raute bedeutet **Aggregation**. Das ist eine schwächere Teil-Ganzes-Beziehung. Beispiel: ```text Team ◇──── Mitarbeiter ``` Der Mitarbeiter kann unabhängig vom Team existieren.
4. Was bedeutet eine gefüllte Raute? Eine gefüllte Raute bedeutet **Komposition**. Das ist eine starke Teil-Ganzes-Beziehung. Beispiel: ```text Rechnung ◆──── Rechnungsposition ``` Die Rechnungsposition gehört fest zur Rechnung.
5. Wo steht die Raute bei Aggregation oder Komposition? Die Raute steht am **Ganzen**. Beispiele: ```text Team ◇──── Mitarbeiter Rechnung ◆──── Rechnungsposition ```
6. Warum soll `+` oder `-` nicht schon im Eingabefeld stehen? Weil du selbst erkennen und eintragen sollst, ob ein Attribut oder eine Methode öffentlich oder privat ist. Typisch: ```text - attribut: Typ + methode(): Typ ```
7. Was bedeutet `- marke: String`? Das bedeutet: ```text private Attribut marke vom Typ String ``` In Java wäre das zum Beispiel: ```java private String marke; ```
8. Was bedeutet `+ toString(): String`? Das bedeutet: ```text public Methode toString mit Rückgabewert String ``` In Java wäre das zum Beispiel: ```java public String toString() ```
9. Was ist der wichtigste Unterschied zwischen Aggregation und Komposition? Aggregation: ```text Teil kann unabhängig existieren. ``` Komposition: ```text Teil gehört fest zum Ganzen. ```
10. Wohin zeigt der Vererbungspfeil? Der Vererbungspfeil zeigt immer zur **Oberklasse**. Beispiel: ```text Monitor ─────▷ Produkt ``` Produkt ist die Oberklasse.
--- **Nächste Seite** Danach geht es weiter mit: ```text UML-Aktivitätsdiagramm ``` # Seite 9. UML-Aktivitätsdiagramm Diese Seite erklärt das **UML-Aktivitätsdiagramm** so, dass du es schnell für IHK-Aufgaben und Programmierlogik anwenden kannst. Ein UML-Aktivitätsdiagramm wird benutzt, um **Abläufe** darzustellen. Es zeigt: ```text Start Aktionen Entscheidungen Bedingungen Kontrollflüsse Merge-Knoten Ende ``` --- **Grafik 1: UML-Aktivitätsdiagramm – Grundlagen** ![UML-Aktivitätsdiagramm – Grundlagen](https://trainer.ulrich-wiki.com/assets/uml-aktivitaetsdiagramm-grundlagen.svg?v=1) Diese Grafik zeigt dir die wichtigsten Symbole: - **Startknoten** - **Aktion / Aktivität** - **Entscheidung** - **Merge-Knoten** - **Kontrollfluss** - **Endknoten** Wichtig für die Prüfung: ```text Eine Entscheidung hat meistens einen Eingang und mehrere Ausgänge. Ein Merge-Knoten führt mehrere alternative Wege wieder zusammen. ``` --- **Wofür braucht man ein UML-Aktivitätsdiagramm?** Ein Aktivitätsdiagramm zeigt einen Ablauf Schritt für Schritt. Typische Beispiele: ```text Login prüfen Bestellung bearbeiten Produktdaten speichern Eingabe validieren Fehler anzeigen Zurück ins Menü ``` Es ist besonders hilfreich, wenn ein Ablauf Entscheidungen enthält. Beispiel: ```text Wenn die Eingabe gültig ist, wird gespeichert. Wenn die Eingabe ungültig ist, wird eine Fehlermeldung angezeigt. ``` --- **Woran erkenne ich in einer Aufgabe, dass ein UML-Aktivitätsdiagramm gemeint ist?** Typische Signalwörter: | Signalwort / Formulierung | Hinweis | |---|---| | Ablauf | Schritte sollen dargestellt werden | | Prozess | Reihenfolge von Tätigkeiten | | Entscheidung | meistens Raute | | wenn / sonst | Verzweigung im Ablauf | | prüfen | häufig Entscheidung danach | | gültig / ungültig | typische Guard-Bedingungen | | ja / nein | Entscheidungsausgänge | | Schleife | Rücksprung im Ablauf | | Kontrollfluss | Pfeile zwischen Aktionen | | „stellen Sie den Ablauf dar“ | oft Aktivitätsdiagramm | --- **Grundsymbole** | Symbol | Bedeutung | Darstellung | |---|---|---| | **Startknoten** | Beginn des Ablaufs | gefüllter Kreis | | **Aktion / Aktivität** | auszuführender Schritt | abgerundetes Rechteck | | **Entscheidung** | Verzweigung im Ablauf | Raute | | **Merge-Knoten** | Zusammenführung alternativer Pfade | Raute | | **Kontrollfluss** | Ablaufreihenfolge | Pfeil | | **Endknoten** | Ende des Ablaufs | Kreis mit gefülltem Punkt | --- **Startknoten** Der Startknoten zeigt, wo der Ablauf beginnt. Darstellung: ```text ● ``` Merksatz: ```text Start = gefüllter Kreis ``` Ein Aktivitätsdiagramm hat meistens genau einen klaren Startpunkt. --- **Aktion / Aktivität** Eine Aktion ist ein konkreter Arbeitsschritt. Beispiele: ```text Produktdaten eingeben Eingabe prüfen Produkt speichern Fehler anzeigen Zurück ins Menü ``` Darstellung: ```text ( Produktdaten eingeben ) ``` Im Diagramm wird dafür normalerweise ein **abgerundetes Rechteck** verwendet. --- **Kontrollfluss** Ein Kontrollfluss zeigt die Reihenfolge der Schritte. Darstellung: ```text Aktion 1 → Aktion 2 ``` Wichtig: ```text Der Pfeil zeigt, welcher Schritt als Nächstes kommt. ``` --- **Entscheidung** Eine Entscheidung wird verwendet, wenn der Ablauf in verschiedene Richtungen gehen kann. Darstellung: ```text ◇ ``` Beispiel: ```text Eingabe gültig? ``` Danach gibt es meistens zwei Wege: ```text [ja] [nein] ``` Wichtig: ```text Die Bedingungen an den ausgehenden Pfeilen heißen Guards. ``` --- **Guards** Guards sind Bedingungen an Kontrollflüssen. Typische Schreibweise: ```text [ja] [nein] [gültig] [ungültig] [preis > 0] [eingabe leer] ``` Beispiel: ```text Eingabe gültig? [ja] → Produkt speichern [nein] → Fehler anzeigen ``` Für Prüfungen ist wichtig: ```text Bedingungen sollten an den Pfeilen stehen, nicht nur irgendwo im Diagramm. ``` --- **Merge-Knoten** Ein Merge-Knoten führt alternative Wege wieder zusammen. Darstellung: ```text ◇ ``` Wichtig: ```text Entscheidung und Merge benutzen beide eine Raute. ``` Der Unterschied: | Element | Bedeutung | |---|---| | **Entscheidung** | ein Eingang, mehrere Ausgänge | | **Merge-Knoten** | mehrere Eingänge, ein Ausgang | Beispiel: ```text [ja] → Produkt speichern ┐ ◇ → Zurück ins Menü [nein] → Fehler anzeigen ┘ ``` --- **Endknoten** Der Endknoten zeigt das Ende des Ablaufs. Darstellung: ```text ◎ ``` Merksatz: ```text Ende = Kreis mit gefülltem Punkt ``` --- **Grafik 2: Beispiel – Produkt speichern** ![UML-Aktivitätsdiagramm – Produkt speichern](https://trainer.ulrich-wiki.com/assets/uml-aktivitaetsdiagramm-beispiel-produkt-speichern.svg?v=1) Diese Grafik zeigt einen typischen Ablauf: ```text Produktdaten eingeben Eingabe prüfen Entscheidung: Eingabe gültig? [ja] → Produkt speichern [nein] → Fehler anzeigen Merge-Knoten Zurück ins Menü Ende ``` Wichtig: ```text Die Verzweigung wird mit einer Entscheidungsraute dargestellt. Die Zusammenführung wird mit einem Merge-Knoten dargestellt. Die Bedingungen stehen als [ja] und [nein] an den Kontrollflüssen. ``` --- **Beispiel als Textablauf** Aufgabe: ```text Ein Benutzer gibt Produktdaten ein. Das System prüft die Eingabe. Wenn die Eingabe gültig ist, wird das Produkt gespeichert. Wenn die Eingabe ungültig ist, wird eine Fehlermeldung angezeigt. Danach kehrt das System ins Menü zurück. ``` Daraus entsteht: ```text Start ↓ Produktdaten eingeben ↓ Eingabe prüfen ↓ Eingabe gültig? ├─ [ja] → Produkt speichern └─ [nein] → Fehler anzeigen ↓ Merge ↓ Zurück ins Menü ↓ Ende ``` --- **Entscheidung vs. Merge** | Merkmal | Entscheidung | Merge | |---|---|---| | Symbol | Raute | Raute | | Eingänge | meistens 1 | mehrere | | Ausgänge | mehrere | meistens 1 | | Zweck | Ablauf verzweigt sich | alternative Wege kommen zusammen | | Beispiel | Eingabe gültig? | nach Speichern oder Fehleranzeige weiter | Merksatz: ```text Entscheidung teilt den Ablauf. Merge führt alternative Wege wieder zusammen. ``` --- **Aktivitätsdiagramm vs. Programmcode** Ein Aktivitätsdiagramm passt gut zu `if`-Anweisungen. Beispiel Code-Logik: ```java if (eingabeGueltig) { produktSpeichern(); } else { fehlerAnzeigen(); } zurueckInsMenue(); ``` Passendes Aktivitätsdiagramm: ```text Eingabe prüfen ↓ Eingabe gültig? ├─ [ja] → Produkt speichern └─ [nein] → Fehler anzeigen ↓ Merge ↓ Zurück ins Menü ``` --- **Typische Kontrollstrukturen** | Kontrollstruktur | Darstellung im Aktivitätsdiagramm | |---|---| | Sequenz | Aktionen nacheinander | | Entscheidung | Raute mit Guards | | Alternative | [ja] / [nein] | | Schleife | Rückpfeil zu früherer Aktion | | Zusammenführung | Merge-Knoten | | Ende | Endknoten | --- **Schleifen im Aktivitätsdiagramm** Eine Schleife entsteht, wenn ein Ablauf zu einem früheren Schritt zurückführt. Beispiel: ```text Eingabe prüfen ↓ Eingabe gültig? ├─ [ja] → Speichern └─ [nein] → Fehler anzeigen → Eingabe erneut bearbeiten ``` Merksatz: ```text Schleifen erkennt man an einem Rückpfeil im Ablauf. ``` --- **Vorgehensweise in der Prüfung** Wenn du ein UML-Aktivitätsdiagramm erstellen sollst, gehe so vor: | Schritt | Frage | |---|---| | 1 | Wo beginnt der Ablauf? | | 2 | Welche Aktionen passieren nacheinander? | | 3 | Gibt es eine Entscheidung? | | 4 | Welche Bedingungen stehen an den Ausgängen? | | 5 | Gibt es alternative Wege? | | 6 | Müssen Wege wieder zusammengeführt werden? | | 7 | Gibt es eine Schleife oder einen Rücksprung? | | 8 | Wo endet der Ablauf? | --- **Typische IHK-Fehler** | Fehler | Warum problematisch? | |---|---| | Startknoten vergessen | Ablauf hat keinen klaren Beginn | | Endknoten vergessen | Ablauf wirkt unvollständig | | Entscheidung ohne Bedingungen | nicht klar, welcher Weg wann gilt | | Guards nicht in eckigen Klammern | weniger UML-sauber | | Merge fehlt | alternative Wege werden unsauber zusammengeführt | | Aktion als Raute gezeichnet | Aktion ist keine Entscheidung | | Entscheidung als Rechteck gezeichnet | Verzweigung wird falsch dargestellt | | Pfeilrichtung falsch | Ablaufreihenfolge ist unklar | | Zu viel Text in einer Aktion | Aktionen sollten kurz und eindeutig sein | --- **Prüfungs-Merksätze** ```text Start = gefüllter Kreis Aktion = abgerundetes Rechteck Entscheidung = Raute Merge = Raute zum Zusammenführen Ende = Kreis mit gefülltem Punkt Kontrollfluss = Pfeil Guards stehen an Pfeilen Guards schreibt man oft in eckigen Klammern [ja] und [nein] sind typische Guards Entscheidung teilt Wege Merge führt Wege zusammen ``` --- **Mini-Beispiel 1** Aufgabe: ```text Wenn ein Passwort korrekt ist, wird der Benutzer angemeldet. Sonst wird eine Fehlermeldung angezeigt. ``` Lösungsidee: ```text Start ↓ Passwort prüfen ↓ Passwort korrekt? ├─ [ja] → Benutzer anmelden └─ [nein] → Fehlermeldung anzeigen ↓ Ende ``` --- **Mini-Beispiel 2** Aufgabe: ```text Ein Preis wird eingegeben. Wenn der Preis größer als 0 ist, wird das Produkt gespeichert. Sonst wird eine Fehlermeldung angezeigt. ``` Lösungsidee: ```text Start ↓ Preis eingeben ↓ Preis > 0? ├─ [ja] → Produkt speichern └─ [nein] → Fehler anzeigen ↓ Ende ``` --- **Mini-Beispiel 3** Aufgabe: ```text Ein Benutzer gibt Daten ein. Wenn die Daten ungültig sind, soll er sie erneut eingeben. Wenn sie gültig sind, werden sie gespeichert. ``` Lösungsidee: ```text Start ↓ Daten eingeben ↓ Daten gültig? ├─ [ja] → Speichern → Ende └─ [nein] → Fehler anzeigen → Daten eingeben ``` Hier entsteht eine Schleife, weil der Ablauf bei ungültigen Daten zurück zur Eingabe geht. --- **Mini-Testfragen**
1. Wofür verwendet man ein UML-Aktivitätsdiagramm? Ein UML-Aktivitätsdiagramm verwendet man, um Abläufe, Prozesse und Entscheidungen darzustellen. Beispiele: ```text Login prüfen Produkt speichern Bestellung bearbeiten ```
2. Wie wird der Startknoten dargestellt? Der Startknoten wird als gefüllter Kreis dargestellt. ```text ● ```
3. Wie wird eine Aktion dargestellt? Eine Aktion wird als abgerundetes Rechteck dargestellt. Beispiel: ```text Produkt speichern ```
4. Wie wird eine Entscheidung dargestellt? Eine Entscheidung wird als Raute dargestellt. Beispiel: ```text Eingabe gültig? ```
5. Was sind Guards? Guards sind Bedingungen an Kontrollflüssen. Beispiele: ```text [ja] [nein] [gültig] [ungültig] [preis > 0] ```
6. Was ist der Unterschied zwischen Entscheidung und Merge? Eine Entscheidung teilt den Ablauf in mehrere Wege. Ein Merge führt alternative Wege wieder zusammen. ```text Entscheidung = 1 Eingang, mehrere Ausgänge Merge = mehrere Eingänge, 1 Ausgang ```
7. Wie wird der Endknoten dargestellt? Der Endknoten wird als Kreis mit gefülltem Punkt dargestellt. ```text ◎ ```
8. Was zeigt ein Kontrollfluss? Ein Kontrollfluss zeigt die Reihenfolge der Aktionen. Er wird als Pfeil dargestellt.
9. Woran erkennt man eine Schleife? Eine Schleife erkennt man daran, dass ein Pfeil zu einem früheren Schritt zurückführt. Beispiel: ```text Fehler anzeigen → Daten erneut eingeben ```
10. Welcher häufige Fehler passiert bei Entscheidungen? Ein häufiger Fehler ist, die Bedingungen an den Ausgängen nicht zu beschriften. Besser: ```text [ja] [nein] ```
--- **Nächste Seite** Danach kommt die eigene Trainer-Seite: ```text UML-Aktivitätsdiagramm-Trainer ``` Dort bauen wir den interaktiven Trainer mit Aufgaben zu: ```text Startknoten erkennen Aktionen eintragen Entscheidungen setzen Guards [ja]/[nein] ergänzen Merge-Knoten verwenden Endknoten korrekt platzieren ``` # Seite 10. UML-Aktivitätsdiagramm-Trainer **UML-Aktivitätsdiagramm-Trainer** Dieser interaktive Trainer gehört zur Theorie-Seite: ```text UML-Aktivitätsdiagramm ``` Hier übst du, aus einer Aufgabenbeschreibung ein korrektes UML-Aktivitätsdiagramm abzuleiten. Im Fokus stehen: ```text Startknoten Aktionen Entscheidungsraute Guards Kontrollflüsse Merge-Knoten Endknoten ``` --- **Was wird trainiert?** | Bereich | Bedeutung | |---|---| | **Start erkennen** | Der Ablauf beginnt mit einem gefüllten Kreis | | **Aktionen eintragen** | Arbeitsschritte als abgerundete Rechtecke | | **Entscheidung erkennen** | Verzweigung als Raute | | **Guards eintragen** | Bedingungen wie `[ja]` und `[nein]` an den Pfeilen | | **Merge-Knoten erkennen** | Alternative Wege werden wieder zusammengeführt | | **Ende erkennen** | Kreis mit gefülltem Punkt | | **Ablaufreihenfolge verstehen** | Pfeile zeigen den Kontrollfluss | --- **Interaktiver UML-Aktivitätsdiagramm-Trainer**
UML-Aktivitätsdiagramm-Trainer im Vollbild öffnen
--- **Merksatz für den Trainer** ```text Startknoten = gefüllter Kreis Aktion = abgerundetes Rechteck Entscheidung = Raute Guard = Bedingung am Pfeil Merge = Raute zur Zusammenführung Endknoten = Kreis mit gefülltem Punkt Kontrollfluss = Pfeilrichtung im Ablauf ``` --- **Beispiel: Produkt speichern** Aufgabenstellung: ```text Ein Benutzer gibt Produktdaten ein. Das System prüft die Eingabe. Wenn die Eingabe gültig ist, wird das Produkt gespeichert. Wenn die Eingabe ungültig ist, wird eine Fehlermeldung angezeigt. Danach kehrt das System ins Menü zurück. ``` Mögliche Lösung: ```text Start ↓ Produktdaten eingeben ↓ Eingabe prüfen ↓ Eingabe gültig? ├─ [ja] → Produkt speichern └─ [nein] → Fehler anzeigen ↓ Merge ↓ Zurück ins Menü ↓ Ende ``` --- **Warum ist die Raute wichtig?** Eine Entscheidung wird im UML-Aktivitätsdiagramm als **Raute** dargestellt. Nicht als Rechteck. ```text Aktion = abgerundetes Rechteck Entscheidung = Raute Merge = Raute ``` Der Unterschied liegt im Ablauf: | Symbol | Bedeutung | |---|---| | **Entscheidung** | ein Eingang, mehrere Ausgänge | | **Merge** | mehrere Eingänge, ein Ausgang | --- **Warum stehen `[ja]` und `[nein]` an den Pfeilen?** Die Bedingungen heißen **Guards**. Sie beschreiben, wann ein bestimmter Weg genommen wird. Beispiel: ```text Eingabe gültig? ├─ [ja] → Produkt speichern └─ [nein] → Fehler anzeigen ``` Wichtig: ```text [ja] und [nein] gehören an die ausgehenden Kontrollflüsse der Entscheidung. ``` --- **Typische Aufgaben im Trainer** Der Trainer enthält Aufgaben zu: ```text Produkt speichern Login prüfen Preis prüfen ``` Dabei musst du jeweils erkennen: ```text Welche Aktion kommt zuerst? Welche Prüfung folgt? Wie lautet die Entscheidungsfrage? Welche Guards gehören an die Pfeile? Welche Aktion gehört zum Ja-Zweig? Welche Aktion gehört zum Nein-Zweig? Wo werden die Wege wieder zusammengeführt? ``` --- **Typische Fehler** | Fehler | Warum falsch? | |---|---| | Entscheidung als Rechteck | Eine Entscheidung muss als Raute dargestellt werden | | Guards fehlen | Es ist nicht klar, welcher Pfad wann gilt | | `[ja]` und `[nein]` stehen an falscher Stelle | Guards gehören an die Kontrollflüsse | | Merge-Knoten fehlt | Alternative Wege werden unsauber zusammengeführt | | Pfeile zeigen in falsche Richtung | Ablaufreihenfolge wird falsch | | Aktion zu lang formuliert | Aktionen sollten kurz und eindeutig sein | | Start- oder Endknoten fehlt | Ablauf wirkt unvollständig | --- **Mini-Testfragen**
1. Wie wird der Startknoten dargestellt? Der Startknoten wird als gefüllter Kreis dargestellt. ```text ● ```
2. Wie wird eine Aktion dargestellt? Eine Aktion wird als abgerundetes Rechteck dargestellt. Beispiel: ```text Produkt speichern ```
3. Wie wird eine Entscheidung dargestellt? Eine Entscheidung wird als Raute dargestellt. Beispiel: ```text Eingabe gültig? ```
4. Was sind Guards? Guards sind Bedingungen an den Kontrollflüssen. Beispiele: ```text [ja] [nein] [gültig] [ungültig] ```
5. Was ist ein Merge-Knoten? Ein Merge-Knoten führt alternative Ablaufwege wieder zusammen. Er wird ebenfalls als Raute dargestellt. ```text mehrere Eingänge → Merge → ein Ausgang ```
6. Was ist der Unterschied zwischen Entscheidung und Merge? Eine Entscheidung teilt den Ablauf. Ein Merge führt alternative Wege wieder zusammen. ```text Entscheidung = ein Eingang, mehrere Ausgänge Merge = mehrere Eingänge, ein Ausgang ```
7. Wie wird der Endknoten dargestellt? Der Endknoten wird als Kreis mit gefülltem Punkt dargestellt. ```text ◎ ```
8. Wo gehören `[ja]` und `[nein]` hin? Sie gehören an die ausgehenden Pfeile der Entscheidungsraute. ```text Eingabe gültig? ├─ [ja] → Speichern └─ [nein] → Fehler anzeigen ```
9. Warum ist ein Merge nach einer Entscheidung sinnvoll? Wenn beide alternativen Wege danach wieder gemeinsam weiterlaufen, führt ein Merge-Knoten diese Wege sauber zusammen. Beispiel: ```text [ja] → Speichern ┐ Merge → Zurück ins Menü [nein] → Fehler ┘ ```
10. Was zeigt der Kontrollfluss? Der Kontrollfluss zeigt die Reihenfolge der Aktionen. Er wird als Pfeil dargestellt.
--- **Nächste Seite** Danach geht es weiter mit: ```text UML-Anwendungsfalldiagramm ``` # Seite 11. UML-Anwendungsfalldiagramm **UML-Anwendungsfalldiagramm** Diese Seite erklärt das **UML-Anwendungsfalldiagramm** so, dass du es schnell für IHK-Aufgaben und Software-Analyse anwenden kannst. Ein UML-Anwendungsfalldiagramm zeigt: ```text Wer benutzt ein System? Welche Funktionen bietet das System? Welche Akteure stehen mit welchen Anwendungsfällen in Verbindung? Welche Anwendungsfälle hängen voneinander ab? ``` Wichtig: ```text Ein Anwendungsfalldiagramm zeigt nicht den inneren Programmablauf. Es zeigt die Sicht von außen auf das System. ``` --- **Grafik 1: UML-Anwendungsfalldiagramm – Grundlagen** ![UML-Anwendungsfalldiagramm – Grundlagen](https://trainer.ulrich-wiki.com/assets/uml-anwendungsfalldiagramm-grundlagen.svg?v=1) Diese Grafik zeigt die wichtigsten Bestandteile: - **Akteur** - **Systemgrenze** - **Anwendungsfall / Use Case** - **Assoziation** - **«include»** - **«extend»** - **Generalisierung** --- **Wofür braucht man ein UML-Anwendungsfalldiagramm?** Ein UML-Anwendungsfalldiagramm wird verwendet, um die **Anforderungen an ein System aus Benutzersicht** darzustellen. Es beantwortet Fragen wie: ```text Wer nutzt das System? Welche Funktionen braucht der Benutzer? Welche Systemfunktionen gehören zusammen? Welche Funktion ist Pflichtbestandteil einer anderen Funktion? Welche Funktion ist nur eine optionale Erweiterung? ``` Beispiel: ```text Ein Kunde kann Artikel suchen. Ein Kunde kann eine Bestellung aufgeben. Beim Aufgeben einer Bestellung muss eine Zahlung durchgeführt werden. Optional kann ein Rabatt geprüft werden. ``` Daraus entstehen: ```text Akteur: Kunde Use Case: Artikel suchen Use Case: Bestellung aufgeben Use Case: Zahlung durchführen Use Case: Rabatt prüfen ``` --- **Woran erkenne ich in einer Aufgabe, dass ein Anwendungsfalldiagramm gemeint ist?** Typische Signalwörter: | Signalwort / Formulierung | Hinweis | |---|---| | Akteur | externe Rolle oder Person | | Benutzer | jemand nutzt das System | | System | Systemgrenze ist wahrscheinlich wichtig | | Funktion | Anwendungsfall / Use Case | | Anwendungsfall | Use Case direkt gemeint | | Anforderungen | oft Use-Case-Sicht | | Benutzer kann ... | Akteur + Use Case | | System soll ... ermöglichen | Use Case | | Kunde, Admin, Mitarbeiter | typische Akteure | | „stellen Sie die Nutzung des Systems dar“ | Anwendungsfalldiagramm | --- **Grundidee** Ein Anwendungsfalldiagramm zeigt die **Außensicht** auf ein System. Es zeigt nicht: ```text Welche Klasse welche Methode hat. Wie der Ablauf Schritt für Schritt funktioniert. Welche Datenbanktabellen entstehen. ``` Sondern es zeigt: ```text Welche Akteure gibt es? Welche Funktionen stellt das System bereit? Welche Akteure nutzen welche Funktionen? ``` Merksatz: ```text Anwendungsfalldiagramm = Wer nutzt welche Funktion des Systems? ``` --- **Akteur** Ein Akteur ist eine Rolle außerhalb des Systems. Beispiele: ```text Kunde Admin Mitarbeiter Lehrer Schüler Zahlungsdienst E-Mail-System ``` Wichtig: ```text Ein Akteur muss nicht immer ein Mensch sein. Auch ein externes System kann ein Akteur sein. ``` Beispiel: ```text Zahlungsdienst E-Mail-Server Versanddienstleister ``` Ein Akteur steht normalerweise **außerhalb der Systemgrenze**. --- **Systemgrenze** Die Systemgrenze wird als Rechteck dargestellt. Innerhalb der Systemgrenze stehen die Anwendungsfälle. Außerhalb der Systemgrenze stehen die Akteure. Merksatz: ```text Akteure außen. Use Cases innen. Systemgrenze als Rechteck. ``` Beispiel: ```text Kunde [ Shop-System ] (Artikel suchen) (Bestellung aufgeben) ``` --- **Anwendungsfall / Use Case** Ein Anwendungsfall beschreibt eine Funktion des Systems aus Sicht eines Akteurs. Darstellung: ```text ( Bestellung aufgeben ) ``` Also als **Ellipse**. Gute Use-Case-Namen sind meistens kurze Tätigkeiten: ```text Artikel suchen Bestellung aufgeben Zahlung durchführen Benutzer anmelden Artikel verwalten Passwort zurücksetzen ``` Wichtig: ```text Use Cases sollten einen Nutzen für einen Akteur haben. ``` Nicht ideal: ```text Datenbank speichern Methode ausführen SQL ausführen ``` Besser: ```text Bestellung speichern Kundendaten verwalten Rechnung erstellen ``` --- **Assoziation** Eine Assoziation verbindet einen Akteur mit einem Anwendungsfall. Darstellung: ```text Kunde ───── (Artikel suchen) ``` Bedeutung: ```text Der Akteur nutzt diesen Anwendungsfall. ``` Wichtig: ```text Eine Assoziation ist normalerweise eine einfache Linie. ``` --- **«include»** `«include»` bedeutet: ```text Ein Anwendungsfall enthält einen anderen Anwendungsfall immer als Pflichtbestandteil. ``` Beispiel: ```text Bestellung aufgeben «include» Zahlung durchführen ``` Bedeutung: ```text Wenn eine Bestellung aufgegeben wird, muss die Zahlung durchgeführt werden. ``` Typische Fälle für `«include»`: ```text Anmelden Zahlung durchführen Berechtigung prüfen Daten validieren ``` Wichtig: ```text «include» zeigt auf den eingebundenen Pflicht-Anwendungsfall. ``` Beispiel: ```text (Bestellung aufgeben) - - -«include»- - -> (Zahlung durchführen) ``` --- **«extend»** `«extend»` bedeutet: ```text Ein Anwendungsfall erweitert einen anderen Anwendungsfall optional. ``` Beispiel: ```text Rabatt prüfen «extend» Bestellung aufgeben ``` Bedeutung: ```text Rabatt prüfen passiert nur unter bestimmten Bedingungen. ``` Zum Beispiel: ```text wenn ein Rabattcode eingegeben wurde wenn der Kunde berechtigt ist wenn eine Sonderaktion aktiv ist ``` Wichtig: ```text «extend» zeigt vom optionalen Erweiterungsfall auf den Basis-Anwendungsfall. ``` Beispiel: ```text (Rabatt prüfen) - - -«extend»- - -> (Bestellung aufgeben) ``` --- **Unterschied «include» und «extend»** | Beziehung | Bedeutung | Beispiel | Merksatz | |---|---|---|---| | **«include»** | Pflichtbestandteil | Bestellung aufgeben enthält Zahlung durchführen | muss immer passieren | | **«extend»** | optionale Erweiterung | Rabatt prüfen erweitert Bestellung aufgeben | passiert nur manchmal | Merksatz: ```text include = immer dabei extend = optional / nur bei Bedingung ``` --- **Generalisierung** Generalisierung bedeutet: ```text Ein spezieller Akteur oder Use Case erbt von einem allgemeineren Akteur oder Use Case. ``` Beispiel bei Akteuren: ```text Admin ist ein spezieller Benutzer. ``` Darstellung: ```text Admin ─────▷ Benutzer ``` Wichtig: ```text Das hohle Dreieck zeigt zur allgemeineren Rolle. ``` Also: ```text Admin → Benutzer ``` nicht umgekehrt. --- **Grafik 2: Beispiel – Shop-System** ![UML-Anwendungsfalldiagramm – Beispiel Shop-System](https://trainer.ulrich-wiki.com/assets/uml-anwendungsfalldiagramm-beispiel-shop.svg?v=1) Diese Grafik zeigt ein Beispiel für ein Shop-System. Es enthält: ```text Akteure: Kunde Admin Use Cases: Anmelden Artikel suchen Bestellung aufgeben Zahlung durchführen Rabatt prüfen Artikel verwalten ``` Wichtig: ```text Kunde und Admin stehen außerhalb der Systemgrenze. Die Anwendungsfälle stehen innerhalb der Systemgrenze. ``` --- **Beispiel als Textbeschreibung** Aufgabe: ```text Ein Kunde kann Artikel suchen und eine Bestellung aufgeben. Beim Aufgeben einer Bestellung muss eine Zahlung durchgeführt werden. Vor der Bestellung kann optional ein Rabatt geprüft werden. Ein Admin kann Artikel verwalten. ``` Daraus entsteht: ```text Akteur Kunde Akteur Admin Kunde ─ Artikel suchen Kunde ─ Bestellung aufgeben Admin ─ Artikel verwalten Bestellung aufgeben «include» Zahlung durchführen Rabatt prüfen «extend» Bestellung aufgeben ``` --- **Akteure im Beispiel** | Akteur | Rolle | |---|---| | **Kunde** | nutzt den Shop, sucht Artikel, gibt Bestellungen auf | | **Admin** | verwaltet Artikel im Shop-System | Wichtig: ```text Akteure sind Rollen. Nicht jede konkrete Person wird einzeln gezeichnet. ``` Also: ```text Kunde ``` nicht: ```text Max Müller ``` --- **Use Cases im Beispiel** | Use Case | Bedeutung | |---|---| | **Anmelden** | Benutzer meldet sich im System an | | **Artikel suchen** | Kunde sucht Produkte | | **Bestellung aufgeben** | Kunde erstellt eine Bestellung | | **Zahlung durchführen** | Zahlung wird abgewickelt | | **Rabatt prüfen** | Rabattcode oder Rabattbedingung wird geprüft | | **Artikel verwalten** | Admin erstellt, ändert oder löscht Artikel | --- **Warum ist „Zahlung durchführen“ ein «include»?** Weil die Zahlung beim Aufgeben einer Bestellung ein notwendiger Bestandteil ist. ```text Bestellung aufgeben ``` enthält immer: ```text Zahlung durchführen ``` Darum: ```text Bestellung aufgeben «include» Zahlung durchführen ``` --- **Warum ist „Rabatt prüfen“ ein «extend»?** Weil ein Rabatt nicht immer geprüft werden muss. Nur wenn zum Beispiel ein Rabattcode vorhanden ist, wird dieser zusätzliche Fall relevant. Darum: ```text Rabatt prüfen «extend» Bestellung aufgeben ``` Merksatz: ```text Rabatt = optional Zahlung = Pflicht ``` --- **Anwendungsfalldiagramm vs. Aktivitätsdiagramm** | Anwendungsfalldiagramm | Aktivitätsdiagramm | |---|---| | zeigt Funktionen aus Benutzersicht | zeigt Ablauf Schritt für Schritt | | Akteure außen | Start, Aktionen, Entscheidungen | | Use Cases als Ellipsen | Aktionen als abgerundete Rechtecke | | keine genaue Reihenfolge | genaue Ablaufreihenfolge | | gut für Anforderungen | gut für Prozesslogik | Merksatz: ```text Anwendungsfalldiagramm = Wer nutzt was? Aktivitätsdiagramm = Was passiert danach? ``` --- **Anwendungsfalldiagramm vs. Klassendiagramm** | Anwendungsfalldiagramm | Klassendiagramm | |---|---| | zeigt Systemfunktionen | zeigt Programmstruktur | | Akteure und Use Cases | Klassen, Attribute, Methoden | | Sicht von außen | technische Struktur | | Anforderungen | OOP-Modellierung | Merksatz: ```text Use Case = Funktion aus Nutzersicht Klasse = Bauplan im Programm ``` --- **Vorgehensweise in der Prüfung** Wenn du ein UML-Anwendungsfalldiagramm erstellen sollst, gehe so vor: | Schritt | Frage | |---|---| | 1 | Was ist das System? | | 2 | Wo liegt die Systemgrenze? | | 3 | Welche Akteure gibt es? | | 4 | Welche Funktionen nutzt jeder Akteur? | | 5 | Welche Use Cases gehören in das System? | | 6 | Welche Assoziationen gibt es? | | 7 | Gibt es Pflichtbestandteile? | | 8 | Gibt es optionale Erweiterungen? | | 9 | Gibt es allgemeinere und speziellere Akteure? | --- **Typische IHK-Fehler** | Fehler | Warum problematisch? | |---|---| | Akteur innerhalb der Systemgrenze | Akteure stehen außerhalb | | Use Case außerhalb der Systemgrenze | Use Cases gehören ins System | | technische Methoden als Use Cases | Use Cases sollen Nutzersicht zeigen | | `include` und `extend` verwechselt | Pflicht und Option werden falsch dargestellt | | Pfeilrichtung bei `include` falsch | `include` zeigt auf den eingebundenen Use Case | | Pfeilrichtung bei `extend` falsch | `extend` zeigt vom Erweiterungsfall zum Basisfall | | Systemgrenze vergessen | unklar, was zum System gehört | | Akteure als konkrete Personen benannt | Akteure sind Rollen | --- **Prüfungs-Merksätze** ```text Akteur = externe Rolle Use Case = Funktion des Systems Systemgrenze = Rechteck um die Use Cases Akteure stehen außerhalb Use Cases stehen innerhalb Use Cases werden als Ellipsen gezeichnet Assoziation = einfache Linie include = Pflichtbestandteil extend = optionale Erweiterung include zeigt auf den eingebundenen Use Case extend zeigt auf den Basis-Use-Case ``` --- **Mini-Beispiel 1** Aufgabe: ```text Ein Benutzer kann sich anmelden. ``` Lösung: ```text Akteur: Benutzer Use Case: Anmelden Benutzer ─ (Anmelden) ``` --- **Mini-Beispiel 2** Aufgabe: ```text Ein Kunde kann eine Bestellung aufgeben. Dabei muss eine Zahlung durchgeführt werden. ``` Lösung: ```text Kunde ─ (Bestellung aufgeben) (Bestellung aufgeben) «include» (Zahlung durchführen) ``` Begründung: ```text Zahlung durchführen ist ein Pflichtbestandteil der Bestellung. ``` --- **Mini-Beispiel 3** Aufgabe: ```text Ein Kunde kann bei einer Bestellung optional einen Rabattcode verwenden. ``` Lösung: ```text (Rabatt prüfen) «extend» (Bestellung aufgeben) ``` Begründung: ```text Rabatt prüfen ist optional. Es passiert nur, wenn ein Rabattcode vorhanden ist. ``` --- **Mini-Testfragen**
1. Wofür verwendet man ein UML-Anwendungsfalldiagramm? Man verwendet es, um darzustellen: ```text Welche Akteure ein System nutzen und welche Funktionen das System anbietet. ``` Merksatz: ```text Wer nutzt was? ```
2. Wo stehen Akteure im Anwendungsfalldiagramm? Akteure stehen außerhalb der Systemgrenze. Sie gehören nicht zum System selbst.
3. Wie werden Use Cases dargestellt? Use Cases werden als Ellipsen dargestellt. Beispiel: ```text ( Bestellung aufgeben ) ```
4. Was zeigt die Systemgrenze? Die Systemgrenze zeigt, welche Anwendungsfälle zum betrachteten System gehören. Sie wird als Rechteck um die Use Cases dargestellt.
5. Was bedeutet «include»? `«include»` bedeutet: ```text Ein Use Case enthält einen anderen Use Case verpflichtend. ``` Beispiel: ```text Bestellung aufgeben «include» Zahlung durchführen ```
6. Was bedeutet «extend»? `«extend»` bedeutet: ```text Ein Use Case erweitert einen anderen Use Case optional. ``` Beispiel: ```text Rabatt prüfen «extend» Bestellung aufgeben ```
7. Was ist der wichtigste Unterschied zwischen include und extend? ```text include = Pflichtbestandteil extend = optionale Erweiterung ```
8. In welche Richtung zeigt «include»? `«include»` zeigt auf den eingebundenen Pflicht-Use-Case. Beispiel: ```text Bestellung aufgeben → Zahlung durchführen ```
9. In welche Richtung zeigt «extend»? `«extend»` zeigt vom optionalen Erweiterungsfall zum Basis-Use-Case. Beispiel: ```text Rabatt prüfen → Bestellung aufgeben ```
10. Was ist ein typischer Fehler bei Anwendungsfalldiagrammen? Ein typischer Fehler ist, technische Methoden als Use Cases zu zeichnen. Nicht gut: ```text saveOrder() ``` Besser: ```text Bestellung aufgeben ```
--- **Nächste Seite** Danach kommt die eigene Trainer-Seite: ```text UML-Anwendungsfalldiagramm-Trainer ``` Dort bauen wir den interaktiven Trainer mit Aufgaben zu: ```text Akteure erkennen Use Cases benennen Systemgrenze verstehen Assoziationen eintragen include und extend unterscheiden Pfeilrichtung prüfen ``` # Seite 12. UML-Anwendungsfalldiagramm-Trainer **UML-Anwendungsfalldiagramm-Trainer** Dieser interaktive Trainer gehört zur Theorie-Seite: ```text UML-Anwendungsfalldiagramm ``` Hier übst du, aus einer Aufgabenbeschreibung ein korrektes UML-Anwendungsfalldiagramm abzuleiten. Im Fokus stehen: ```text Akteure Systemgrenze Use Cases Assoziationen <> <> Pfeilrichtung Pflichtbestandteil vs. optionale Erweiterung ``` --- **Was wird trainiert?** | Bereich | Bedeutung | |---|---| | **Akteure erkennen** | externe Rollen außerhalb des Systems | | **Systemgrenze verstehen** | Rechteck um die Use Cases | | **Use Cases benennen** | Funktionen des Systems als Ellipsen | | **Assoziationen erkennen** | einfache Linien zwischen Akteur und Use Case | | **<> erkennen** | Pflichtbestandteil eines Use Cases | | **<> erkennen** | optionale Erweiterung eines Use Cases | | **Pfeilrichtung prüfen** | include und extend zeigen in unterschiedliche fachliche Richtungen | --- **Interaktiver UML-Anwendungsfalldiagramm-Trainer**
UML-Anwendungsfalldiagramm-Trainer im Vollbild öffnen
--- **Merksatz für den Trainer** ```text Akteur = externe Rolle außerhalb des Systems Use Case = Funktion des Systems Systemgrenze = Rechteck um die Use Cases Akteur–Use Case = einfache Linie ohne Pfeil <> = Pflichtbestandteil <> = optionale Erweiterung include zeigt zum eingebundenen Pflicht-Use-Case extend zeigt zum Basis-Use-Case ``` --- **Beispiel: Shop-System** Aufgabenstellung: ```text Ein Kunde kann Artikel suchen und eine Bestellung aufgeben. Beim Aufgeben einer Bestellung muss eine Zahlung durchgeführt werden. Vor der Bestellung kann optional ein Rabatt geprüft werden. Ein Admin kann Artikel verwalten. ``` Mögliche Lösung: ```text System: Shop-System Akteure: Kunde Admin Use Cases: Artikel suchen Bestellung aufgeben Zahlung durchführen Rabatt prüfen Artikel verwalten Beziehungen: Kunde — Artikel suchen Kunde — Bestellung aufgeben Admin — Artikel verwalten Bestellung aufgeben <> Zahlung durchführen Rabatt prüfen <> Bestellung aufgeben ``` --- **Warum ist „Zahlung durchführen“ ein <>?** ```text Bestellung aufgeben <> Zahlung durchführen ``` Das bedeutet: ```text Wenn eine Bestellung aufgegeben wird, muss die Zahlung durchgeführt werden. ``` Also ist die Zahlung ein **Pflichtbestandteil**. --- **Warum ist „Rabatt prüfen“ ein <>?** ```text Rabatt prüfen <> Bestellung aufgeben ``` Das bedeutet: ```text Rabatt prüfen erweitert Bestellung aufgeben nur optional. ``` Zum Beispiel: ```text nur wenn ein Rabattcode vorhanden ist nur wenn eine Aktion aktiv ist nur wenn der Kunde berechtigt ist ``` --- **Richtige Pfeilrichtung** | Beziehung | Richtung | |---|---| | **<>** | vom Basis-Use-Case zum eingebundenen Pflicht-Use-Case | | **<>** | vom optionalen Erweiterungs-Use-Case zum Basis-Use-Case | Merksatz: ```text include zeigt auf das, was immer gebraucht wird. extend zeigt auf das, was optional erweitert wird. ``` --- **Typische Fehler** | Fehler | Warum falsch? | |---|---| | Akteur innerhalb der Systemgrenze | Akteure stehen außerhalb | | Use Case außerhalb der Systemgrenze | Use Cases gehören ins System | | Pfeile bei Akteur-Verbindung | Akteur–Use Case ist normalerweise einfache Linie | | include und extend vertauscht | Pflicht und Option werden falsch dargestellt | | include-Pfeil falsch herum | include zeigt auf den Pflicht-Use-Case | | extend-Pfeil falsch herum | extend zeigt auf den Basis-Use-Case | | technische Methoden als Use Cases | Use Cases sollen Nutzersicht zeigen | --- **Mini-Testfragen**
1. Wo stehen Akteure im Anwendungsfalldiagramm? Akteure stehen außerhalb der Systemgrenze.
2. Wie werden Use Cases dargestellt? Use Cases werden als Ellipsen dargestellt. Beispiel: ```text ( Bestellung aufgeben ) ```
3. Wie wird eine Akteur–Use-Case-Beziehung dargestellt? Als einfache durchgezogene Linie ohne Pfeilspitze. Beispiel: ```text Kunde — Bestellung aufgeben ```
4. Was bedeutet <>? `<>` bedeutet Pflichtbestandteil. Beispiel: ```text Bestellung aufgeben <> Zahlung durchführen ```
5. Was bedeutet <>? `<>` bedeutet optionale Erweiterung. Beispiel: ```text Rabatt prüfen <> Bestellung aufgeben ```
6. In welche Richtung zeigt include? `<>` zeigt vom Basis-Use-Case zum eingebundenen Pflicht-Use-Case. ```text Bestellung aufgeben → Zahlung durchführen ```
7. In welche Richtung zeigt extend? `<>` zeigt vom optionalen Erweiterungs-Use-Case zum Basis-Use-Case. ```text Rabatt prüfen → Bestellung aufgeben ```
8. Warum ist Zahlung durchführen im Shop-Beispiel include? Weil die Zahlung ein notwendiger Bestandteil der Bestellung ist. ```text Ohne Zahlung ist die Bestellung nicht vollständig. ```
9. Warum ist Rabatt prüfen im Shop-Beispiel extend? Weil der Rabatt nur optional geprüft wird. ```text Nur wenn ein Rabattcode oder eine Rabattbedingung vorhanden ist. ```
10. Was zeigt ein Anwendungsfalldiagramm nicht? Es zeigt nicht den inneren Programmablauf. Nicht dargestellt werden: ```text if-Anweisungen Schleifen Methodenaufrufe Datenbanktabellen ``` Dafür wären andere Diagramme besser geeignet.
--- **Nächste Seite** Danach geht es weiter mit: ```text UML-Sequenzdiagramm ``` # Seite 13. UML-Sequenzdiagramm **UML-Sequenzdiagramm** Diese Seite erklärt das **UML-Sequenzdiagramm** so, dass du es schnell für IHK-Aufgaben und Programmierlogik anwenden kannst. Ein UML-Sequenzdiagramm zeigt: ```text Welche Objekte oder Teilnehmer beteiligt sind welche Nachrichten zwischen ihnen ausgetauscht werden in welcher zeitlichen Reihenfolge die Kommunikation abläuft welche Rückgaben erfolgen welche Prozesse nacheinander oder parallel ablaufen ``` Wichtig: ```text Ein Sequenzdiagramm zeigt einen konkreten Ablauf. Der Ablauf wird von oben nach unten gelesen. ``` --- **Grafik 1: UML-Sequenzdiagramm – Grundlagen** ![UML-Sequenzdiagramm – Grundlagen](https://trainer.ulrich-wiki.com/assets/uml-sequenzdiagramm-grundlagen.svg?v=1) Diese Grafik zeigt die wichtigsten Bestandteile: ```text Teilnehmer / Objekte Lebenslinien Aktivierungsbalken Nachrichten Rückgaben Zeitachse ``` --- **Wofür braucht man ein UML-Sequenzdiagramm?** Ein Sequenzdiagramm wird verwendet, um die Kommunikation zwischen Objekten oder Systemteilen darzustellen. Typische Beispiele: ```text Login prüfen Bestellung aufgeben Produkt speichern Datenbankabfrage ausführen Benutzeroberfläche ruft Service auf Service ruft Datenbank auf ``` Es zeigt also nicht nur, **was** passiert, sondern vor allem: ```text wer mit wem spricht in welcher Reihenfolge welche Antwort zurückkommt ``` --- **Woran erkenne ich in einer Aufgabe, dass ein Sequenzdiagramm gemeint ist?** Typische Signalwörter: | Signalwort / Formulierung | Hinweis | |---|---| | Ablauf zwischen Objekten | Sequenzdiagramm wahrscheinlich | | Nachricht | Kommunikation zwischen Teilnehmern | | Aufruf | Methodenaufruf / Nachricht | | Rückgabe | gestrichelte Antwortlinie | | zeitliche Reihenfolge | von oben nach unten | | Benutzer klickt ... | Start eines Ablaufs | | GUI ruft Service auf | typische Sequenz | | Service fragt Datenbank ab | typische Objektkommunikation | | „stellen Sie den Nachrichtenaustausch dar“ | Sequenzdiagramm | --- **Grundidee** Ein Sequenzdiagramm zeigt einen konkreten Ablauf als Szenario. Beispiel: ```text Benutzer gibt Login-Daten ein. Die Oberfläche sendet die Daten an den LoginService. Der LoginService fragt die Datenbank ab. Die Datenbank gibt einen Benutzer zurück. Der Service gibt den Loginstatus zurück. Die Oberfläche zeigt eine Meldung an. ``` Daraus entsteht ein zeitlicher Ablauf zwischen: ```text Benutzer loginGUI:LoginGUI loginService:LoginService userRepository:UserRepository ``` --- **Teilnehmer / Objekte** Teilnehmer stehen im Sequenzdiagramm oben. Beispiele: ```text Benutzer loginGUI:LoginGUI loginService:LoginService userRepository:UserRepository ``` Wichtig: ```text Ein echter Benutzer kann als Akteur dargestellt werden. Objekte werden häufig als instanz:Klasse geschrieben. ``` Beispiele: ```text loginGUI:LoginGUI loginService:LoginService userRepository:UserRepository ``` --- **Lebenslinie** Unter jedem Teilnehmer verläuft eine Lebenslinie nach unten. Darstellung: ```text Teilnehmer | | | ``` In UML wird die Lebenslinie meistens gestrichelt dargestellt. Merksatz: ```text Lebenslinie = zeigt, dass ein Teilnehmer während des Ablaufs existiert. ``` --- **Zeitliche Reihenfolge** Ein Sequenzdiagramm wird von oben nach unten gelesen. ```text oben = früher unten = später ``` Merksatz: ```text Die Reihenfolge der Nachrichten ergibt sich aus ihrer Höhe im Diagramm. ``` --- **Nachricht / Methodenaufruf** Eine Nachricht zeigt, dass ein Teilnehmer einen anderen Teilnehmer aufruft. Beispiel: ```text loginGUI → loginService: pruefeLogin(name, passwort) ``` Typisch im Diagramm: ```text durchgezogene Linie mit Pfeilspitze ``` Beispiele: ```text loginDatenEingeben(name, passwort) pruefeLogin(name, passwort) findeBenutzer(name) ``` --- **Rückgabe** Eine Rückgabe zeigt das Ergebnis eines Aufrufs. Beispiel: ```text userRepository --> loginService: benutzer ``` Typisch: ```text gestrichelte Linie zurück ``` Beispiele: ```text benutzer loginStatus dashboardDaten benutzerKontext ``` Wichtig: ```text Rückgaben sind oft optional, aber in Lern- und Prüfungsdiagrammen sehr hilfreich. ``` --- **Aktivierungsbalken** Ein Aktivierungsbalken zeigt, dass ein Teilnehmer gerade aktiv ist. Beispiel: ```text loginService prüft gerade die Login-Daten. userRepository sucht gerade den Benutzer. ``` Darstellung: ```text schmaler senkrechter Balken auf der Lebenslinie ``` Merksatz: ```text Aktivierungsbalken = Teilnehmer verarbeitet gerade etwas. ``` --- **Grafik 2: Beispiel – Login prüfen** ![UML-Sequenzdiagramm – Beispiel Login prüfen](https://trainer.ulrich-wiki.com/assets/uml-sequenzdiagramm-beispiel-login.svg?v=5) Diese Grafik zeigt einen Login-Ablauf. Beteiligte Teilnehmer: ```text Benutzer loginGUI:LoginGUI loginService:LoginService userRepository:UserRepository dashboard:Dashboard ``` Ablauf: ```text 1. Benutzer gibt Login-Daten ein. 2. LoginGUI ruft den LoginService auf. 3. LoginService fragt UserRepository ab. 4. UserRepository gibt Benutzer zurück. 5. LoginService gibt Loginstatus zurück. 6. Danach laufen zwei Prozesse parallel: Prozess A: Dashboard laden Prozess B: Benutzerkontext laden 7. Danach wird die Startseite angezeigt. ``` --- **Parallele Prozesse** In der IHK-nahen Darstellung können parallele Abläufe durch **zwei parallele Linien** markiert werden. In unserem Beispiel: ```text Prozess A: Dashboard laden Prozess B: Benutzerkontext laden ``` Wichtig: ```text Parallel bedeutet: Die Prozesse müssen nicht streng nacheinander ablaufen. Sie können gleichzeitig oder unabhängig voneinander gestartet werden. ``` Merksatz: ```text Parallele Linien = paralleler Ablaufbereich ``` --- **Beispiel als Textablauf** Aufgabe: ```text Ein Benutzer gibt seine Login-Daten ein. Die Oberfläche sendet Name und Passwort an den LoginService. Der LoginService sucht den Benutzer über das UserRepository. Das UserRepository gibt den Benutzer zurück. Der LoginService gibt den Loginstatus zurück. Nach erfolgreichem Login werden Dashboarddaten und Benutzerkontext geladen. Danach wird die Startseite angezeigt. ``` Daraus entsteht: ```text Benutzer → loginGUI: loginDatenEingeben(name, passwort) loginGUI → loginService: pruefeLogin(name, passwort) loginService → userRepository: findeBenutzer(name) userRepository --> loginService: benutzer loginService --> loginGUI: loginStatus parallel: loginGUI → dashboard: ladeDashboard() dashboard --> loginGUI: dashboardDaten loginGUI → loginService: ladeBenutzerKontext() loginService --> loginGUI: benutzerKontext loginGUI → Benutzer: startseiteAnzeigen() ``` --- **Sequenzdiagramm vs. Aktivitätsdiagramm** | Sequenzdiagramm | Aktivitätsdiagramm | |---|---| | zeigt Kommunikation zwischen Teilnehmern | zeigt Ablauf von Aktionen | | Teilnehmer oben | Start/Aktion/Entscheidung | | Lebenslinien | Kontrollfluss-Pfeile | | Nachrichten zwischen Objekten | Prozessschritte | | gut für Methodenaufrufe | gut für Geschäftsabläufe | | Zeit von oben nach unten | Ablauf meist entlang der Pfeile | Merksatz: ```text Sequenzdiagramm = Wer ruft wen wann auf? Aktivitätsdiagramm = Was passiert als nächstes? ``` --- **Sequenzdiagramm vs. Klassendiagramm** | Sequenzdiagramm | Klassendiagramm | |---|---| | dynamischer Ablauf | statische Struktur | | zeigt Nachrichten | zeigt Klassen | | zeigt Reihenfolge | zeigt Attribute und Methoden | | konkretes Szenario | allgemeines Modell | Merksatz: ```text Klassendiagramm = Bauplan Sequenzdiagramm = Ablauf zwischen den Bauteilen ``` --- **Typische IHK-Fehler** | Fehler | Warum problematisch? | |---|---| | Lebenslinien vergessen | Teilnehmer existieren im Ablauf nicht sichtbar | | Pfeile in falscher Reihenfolge | Ablauf wird falsch gelesen | | Rückgaben als normale Aufrufe gezeichnet | Ergebnis wirkt wie neuer Methodenaufruf | | Teilnehmer und Klassen verwechselt | Sequenzdiagramm zeigt konkrete Beteiligte | | zu viele technische Details | Diagramm wird unübersichtlich | | Zeitachse falsch verstanden | oben passiert vor unten | | parallele Prozesse nicht markiert | Gleichzeitigkeit wird nicht sichtbar | | Pfeile überlagern sich | Diagramm wird schlecht lesbar | --- **Vorgehensweise in der Prüfung** Wenn du ein Sequenzdiagramm erstellen sollst, gehe so vor: | Schritt | Frage | |---|---| | 1 | Welcher konkrete Ablauf wird beschrieben? | | 2 | Welche Teilnehmer oder Objekte sind beteiligt? | | 3 | Wer startet den Ablauf? | | 4 | Welche Nachricht kommt zuerst? | | 5 | Wer ruft wen auf? | | 6 | Welche Rückgaben gibt es? | | 7 | Gibt es parallele Abläufe? | | 8 | Ist die Reihenfolge von oben nach unten korrekt? | | 9 | Sind die Pfeile und Beschriftungen lesbar? | --- **Prüfungs-Merksätze** ```text Teilnehmer stehen oben. Lebenslinien laufen nach unten. Zeit läuft von oben nach unten. Nachrichten sind horizontale Pfeile. Synchrone Aufrufe werden durchgezogen gezeichnet. Rückgaben werden gestrichelt gezeichnet. Aktivierungsbalken zeigen Verarbeitung. Parallele Prozesse müssen erkennbar markiert werden. Ein Sequenzdiagramm zeigt ein konkretes Szenario. ``` --- **Mini-Beispiel 1** Aufgabe: ```text Ein Benutzer klickt auf Speichern. Die Oberfläche sendet die Daten an den Controller. Der Controller speichert die Daten in der Datenbank. Die Datenbank gibt eine Bestätigung zurück. ``` Lösungsidee: ```text Benutzer → GUI: speichernKlicken() GUI → Controller: speichern(daten) Controller → Datenbank: insert(daten) Datenbank --> Controller: ok Controller --> GUI: gespeichert GUI → Benutzer: bestätigungAnzeigen() ``` --- **Mini-Beispiel 2** Aufgabe: ```text Ein Kunde gibt eine Bestellung auf. Die Oberfläche sendet die Bestellung an den BestellService. Der BestellService prüft den Lagerbestand. Danach wird die Bestellung gespeichert. ``` Lösungsidee: ```text Kunde → ShopGUI: bestellungAufgeben() ShopGUI → BestellService: bestellungPruefen() BestellService → LagerService: bestandPruefen() LagerService --> BestellService: bestandOK BestellService → BestellungRepository: speichern() BestellungRepository --> BestellService: gespeichert BestellService --> ShopGUI: bestellungOK ``` --- **Mini-Beispiel 3: Paralleler Ablauf** Aufgabe: ```text Nach dem Login werden Dashboarddaten und Benutzerdaten parallel geladen. ``` Lösungsidee: ```text parallel: GUI → DashboardService: ladeDashboard() DashboardService --> GUI: dashboardDaten GUI → BenutzerService: ladeBenutzerDaten() BenutzerService --> GUI: benutzerDaten ``` Merksatz: ```text Wenn zwei Abläufe unabhängig voneinander starten können, kann ein paralleler Bereich sinnvoll sein. ``` --- **Mini-Testfragen**
1. Wofür verwendet man ein UML-Sequenzdiagramm? Man verwendet es, um den zeitlichen Nachrichtenaustausch zwischen Teilnehmern oder Objekten darzustellen. Merksatz: ```text Wer ruft wen wann auf? ```
2. Wie liest man ein Sequenzdiagramm? Von oben nach unten. ```text oben = früher unten = später ```
3. Was ist eine Lebenslinie? Eine Lebenslinie ist die gestrichelte Linie unter einem Teilnehmer. Sie zeigt, dass der Teilnehmer während des Ablaufs existiert.
4. Was zeigt ein Aktivierungsbalken? Ein Aktivierungsbalken zeigt, dass ein Teilnehmer gerade aktiv ist oder etwas verarbeitet.
5. Wie werden Rückgaben typischerweise dargestellt? Rückgaben werden meistens als gestrichelte Pfeile zurück dargestellt. Beispiel: ```text userRepository --> loginService: benutzer ```
6. Was ist der Unterschied zwischen Nachricht und Rückgabe? Eine Nachricht ruft eine Aktion oder Methode auf. Eine Rückgabe liefert ein Ergebnis zurück. ```text Nachricht = Aufruf Rückgabe = Ergebnis ```
7. Was bedeutet „Zeit läuft von oben nach unten“? Nachrichten weiter oben passieren früher. Nachrichten weiter unten passieren später.
8. Was zeigt ein paralleler Bereich? Ein paralleler Bereich zeigt, dass mehrere Prozesse unabhängig oder gleichzeitig ablaufen können. Beispiel: ```text Dashboard laden Benutzerkontext laden ```
9. Warum sollte man Pfeile nicht überlagern? Weil das Diagramm sonst schwer lesbar wird und die Reihenfolge oder Zuordnung der Nachrichten unklar werden kann.
10. Was ist ein typischer Fehler im Sequenzdiagramm? Ein typischer Fehler ist, die zeitliche Reihenfolge falsch darzustellen. Wichtig: ```text Der Ablauf wird von oben nach unten gelesen. ```
--- **Nächste Seite** Danach kommt die eigene Trainer-Seite: ```text UML-Sequenzdiagramm-Trainer ``` Dort übst du: ```text Teilnehmer erkennen Nachrichten richtig beschriften Rückgaben unterscheiden Reihenfolge beachten parallele Prozesse erkennen Sequenzdiagramme aus Textaufgaben ableiten ``` # Seite 14. UML-Sequenzdiagramm-Trainer Dieser interaktive Trainer gehört zur Theorie-Seite: ```text UML-Sequenzdiagramm ``` Hier übst du, aus einer Aufgabenbeschreibung ein korrektes UML-Sequenzdiagramm abzuleiten. Im Fokus stehen: ```text Teilnehmer Lebenslinien Nachrichten Rückgaben Reihenfolge Aktivierungsbalken parallele Prozessbereiche ``` --- **Was wird trainiert?** | Bereich | Bedeutung | |---|---| | **Teilnehmer erkennen** | beteiligte Akteure, Objekte oder Systemteile | | **Lebenslinien verstehen** | gestrichelte Linien unter den Teilnehmern | | **Nachrichten eintragen** | durchgezogene Pfeile als Aufrufe | | **Rückgaben unterscheiden** | gestrichelte Pfeile als Antworten | | **Reihenfolge prüfen** | Ablauf wird von oben nach unten gelesen | | **Parallelbereich erkennen** | zwei parallele Linien markieren parallele Abläufe | | **Beschriftungen sauber setzen** | Methodenaufrufe und Rückgaben eindeutig benennen | --- **Interaktiver UML-Sequenzdiagramm-Trainer** --- **Merksatz für den Trainer** ```text Teilnehmer stehen oben. Lebenslinien laufen nach unten. Zeit läuft von oben nach unten. Nachrichten sind durchgezogene Pfeile. Rückgaben sind gestrichelte Pfeile. Aktivierungsbalken zeigen Verarbeitung. Parallele Abläufe müssen sichtbar markiert werden. ``` --- **Wichtige fachliche Einordnung** Im Trainer verwenden wir für den parallelen Bereich eine **IHK-nahe vereinfachte Darstellung mit zwei parallelen Linien**. Das bedeutet: ```text zwei parallele Linien = paralleler Ablaufbereich ``` Streng nach UML kann Parallelität auch als `par`-Combined-Fragment mit Rahmen dargestellt werden. Für dein IHK-Lernen ist wichtig: ```text Du sollst erkennen: Hier laufen zwei Prozesse parallel oder unabhängig voneinander ab. ``` --- **Beispiel: Login prüfen** Aufgabenstellung: ```text Ein Benutzer gibt Login-Daten ein. Die LoginGUI ruft den LoginService auf. Der LoginService fragt das UserRepository ab. Danach werden Dashboarddaten und Benutzerkontext parallel geladen. Zum Schluss wird die Startseite angezeigt. ``` Mögliche Lösung: ```text Teilnehmer: Benutzer loginGUI:LoginGUI loginService:LoginService userRepository:UserRepository dashboard:Dashboard ``` Ablauf: ```text Benutzer → loginGUI: loginDatenEingeben(name, passwort) loginGUI → loginService: pruefeLogin(name, passwort) loginService → userRepository: findeBenutzer(name) userRepository --> loginService: benutzer loginService --> loginGUI: loginStatus ``` Parallelbereich: ```text Prozess A: loginGUI → dashboard: ladeDashboard() dashboard --> loginGUI: dashboardDaten Prozess B: loginGUI → loginService: ladeBenutzerKontext() loginService --> loginGUI: benutzerKontext ``` Abschluss: ```text loginGUI → Benutzer: startseiteAnzeigen() ``` --- **Nachricht oder Rückgabe?** | Darstellung | Bedeutung | |---|---| | **durchgezogener Pfeil** | Aufruf / Nachricht | | **gestrichelter Pfeil** | Rückgabe / Antwort | | **senkrechte gestrichelte Linie** | Lebenslinie | | **schmaler Balken auf Lebenslinie** | Aktivierungsbalken | | **zwei parallele Linien** | paralleler Ablaufbereich | --- **Teilnehmer richtig benennen** Ein Teilnehmer kann ein Akteur oder ein Objekt sein. Beispiele: ```text Benutzer loginGUI:LoginGUI loginService:LoginService userRepository:UserRepository dashboard:Dashboard ``` Wichtig: ```text Benutzer = Akteur loginGUI:LoginGUI = Objekt / Instanz mit Klasse ``` --- **Warum steht die Zeit von oben nach unten?** Ein Sequenzdiagramm wird vertikal gelesen. ```text oben = früher unten = später ``` Das bedeutet: ```text Die erste Nachricht steht oben. Spätere Nachrichten stehen weiter unten. ``` --- **Typische Fehler im Sequenzdiagramm** | Fehler | Warum falsch? | |---|---| | Teilnehmer fehlen | unklar, wer beteiligt ist | | Lebenslinien fehlen | Ablauf ist nicht als Sequenzdiagramm erkennbar | | Rückgaben als normale Nachrichten gezeichnet | Antwort wirkt wie neuer Aufruf | | Nachrichten in falscher Reihenfolge | Ablauf wird fachlich falsch | | Pfeile überlagern sich | Diagramm ist schlecht lesbar | | paralleler Bereich nicht markiert | Gleichzeitigkeit wird nicht sichtbar | | zu lange Texte auf Pfeilen | Diagramm wird unübersichtlich | | Klassen statt konkreter Teilnehmer falsch verwendet | Sequenzdiagramm zeigt konkrete Kommunikation | --- **Mini-Testfragen**
1. Wofür verwendet man ein UML-Sequenzdiagramm? Ein Sequenzdiagramm zeigt den zeitlichen Nachrichtenaustausch zwischen Teilnehmern oder Objekten. Merksatz: ```text Wer ruft wen wann auf? ```
2. Wie liest man ein Sequenzdiagramm? Von oben nach unten. ```text oben = früher unten = später ```
3. Was ist eine Lebenslinie? Eine Lebenslinie ist die gestrichelte senkrechte Linie unter einem Teilnehmer. Sie zeigt, dass der Teilnehmer während des Ablaufs existiert.
4. Wie wird eine normale Nachricht dargestellt? Als durchgezogener Pfeil zwischen zwei Teilnehmern. Beispiel: ```text loginGUI → loginService: pruefeLogin() ```
5. Wie wird eine Rückgabe dargestellt? Als gestrichelter Pfeil zurück. Beispiel: ```text loginService --> loginGUI: loginStatus ```
6. Was zeigt ein Aktivierungsbalken? Ein Aktivierungsbalken zeigt, dass ein Teilnehmer gerade aktiv ist oder etwas verarbeitet.
7. Was bedeuten zwei parallele Linien in unserem Trainer? Sie markieren einen parallelen Ablaufbereich. Das bedeutet: ```text Mehrere Prozesse können parallel oder unabhängig voneinander ablaufen. ```
8. Was ist der Unterschied zwischen Nachricht und Rückgabe? Eine Nachricht ruft etwas auf. Eine Rückgabe liefert ein Ergebnis zurück. ```text Nachricht = Aufruf Rückgabe = Antwort / Ergebnis ```
9. Warum dürfen Pfeile und Texte nicht überlappen? Weil sonst unklar wird, welcher Pfeil zu welcher Nachricht gehört. Ein Sequenzdiagramm muss sauber lesbar bleiben.
10. Was ist ein typischer IHK-Fehler? Ein häufiger Fehler ist, die zeitliche Reihenfolge falsch darzustellen. Wichtig: ```text Die Reihenfolge ergibt sich von oben nach unten. ```
--- **Nächste Seite** Danach geht es weiter mit: ```text Mock-up / Benutzeroberflächen-Entwurf ``` # Seite 15: Mock-up / Benutzeroberflächen-Entwurf Diese Seite erklärt den **Mock-up / Benutzeroberflächen-Entwurf** so, dass du ihn schnell für IHK-Aufgaben anwenden kannst. Ein Mock-up zeigt: ```text Wie eine Benutzeroberfläche aussehen soll welche Felder und Buttons vorhanden sind wie die Navigation aufgebaut ist wo Fehlermeldungen erscheinen wie der Benutzer durch die Oberfläche geführt wird ``` Wichtig: ```text Ein Mock-up ist kein UML-Diagramm. Ein Mock-up zeigt keine Programmlogik. Ein Mock-up zeigt die geplante Bedienoberfläche. ``` --- **Grafik 1: Mock-up – Grundlagen** ![Mock-up – Grundlagen](https://trainer.ulrich-wiki.com/assets/mockup-grundlagen.svg?v=1) Diese Grafik zeigt die wichtigsten Bestandteile eines Mock-ups: ```text Fenster / App-Rahmen Titelbereich Navigation Inhaltsbereich Formularfelder Buttons Fehlermeldung Benutzerführung ``` --- **Wofür braucht man ein Mock-up?** Ein Mock-up wird benutzt, um eine Oberfläche vor der Programmierung zu planen. Typische Ziele: ```text Benutzeroberfläche sichtbar machen Bedienung planen Felder und Buttons festlegen Fehler- und Erfolgsmeldungen berücksichtigen Benutzerführung prüfen Missverständnisse vor der Programmierung vermeiden ``` Ein Mock-up beantwortet also Fragen wie: ```text Welche Eingabefelder braucht der Benutzer? Welche Buttons sind notwendig? Wo steht die Fehlermeldung? Wie kommt der Benutzer zurück? Was passiert nach dem Speichern? ``` --- **Woran erkenne ich in einer Aufgabe, dass ein Mock-up gemeint ist?** Typische Signalwörter: | Signalwort / Formulierung | Hinweis | |---|---| | Benutzeroberfläche | Mock-up wahrscheinlich | | Oberfläche entwerfen | visuelle Darstellung gefragt | | Formular | Eingabefelder und Buttons | | Eingabemaske | UI-Entwurf | | Dialogfenster | Mock-up / GUI-Skizze | | Benutzerführung | Bedienlogik der Oberfläche | | Wireframe | einfache Mock-up-Form | | Entwurf | noch keine fertige Anwendung | | Skizzieren Sie die Maske | Mock-up-Aufgabe | | Fehlermeldung anzeigen | UI-Element berücksichtigen | --- **Grundidee** Ein Mock-up ist ein visueller Entwurf. Es zeigt nicht: ```text Java-Code SQL-Code Methodenaufrufe Datenbankstruktur UML-Beziehungen ``` Sondern es zeigt: ```text Oberflächenaufbau Felder Buttons Navigation Meldungen Anordnung Bedienbarkeit ``` Merksatz: ```text Mock-up = Wie sieht die Oberfläche für den Benutzer aus? ``` --- **Grafik 2: Beispiel – Produktformular** ![Mock-up – Beispiel Produktformular](https://trainer.ulrich-wiki.com/assets/mockup-beispiel-produktformular.svg?v=1) Diese Grafik zeigt ein typisches Mock-up für eine Produktverwaltung. Enthalten sind: ```text Toolbar Formularbereich Produktname Kategorie Preis Lagerbestand Aktiv-Checkbox Speichern-Button Abbrechen-Button Zurück-zur-Liste-Button Fehlermeldung am Preisfeld ``` --- **Wichtige Bestandteile eines guten Mock-ups** | Bestandteil | Bedeutung | |---|---| | **Titel** | zeigt, worum es in der Oberfläche geht | | **Navigation** | Benutzer findet wichtige Bereiche | | **Eingabefelder** | Benutzer kann Daten eingeben | | **Pflichtfelder** | wichtige Eingaben werden markiert | | **Buttons** | Benutzer kann Aktionen auslösen | | **Fehlermeldungen** | Benutzer erkennt Probleme | | **Rückmeldung** | Benutzer sieht, ob etwas geklappt hat | | **Abbrechen / Zurück** | Benutzer kann die Aktion verlassen | | **klare Beschriftungen** | Benutzer versteht die Oberfläche | --- **Pflichtfelder** Pflichtfelder sind Felder, die ausgefüllt werden müssen. Typische Markierung: ```text Produktname * Preis * Kategorie * ``` Das `*` bedeutet: ```text Dieses Feld muss ausgefüllt werden. ``` Wichtig: ```text Pflichtfelder sollten klar erkennbar sein. ``` --- **Validierung und Fehlermeldungen** Validierung bedeutet: ```text Das System prüft, ob die Eingabe gültig ist. ``` Beispiele: ```text Preis muss größer als 0 sein. Produktname darf nicht leer sein. Kategorie muss ausgewählt werden. E-Mail-Adresse muss gültig sein. Passwort muss lang genug sein. ``` Gute Fehlermeldungen stehen möglichst nah am betroffenen Feld. Beispiel: ```text Preis * [ 0,00 € ] Preis muss größer als 0 sein. ``` Merksatz: ```text Fehlermeldung direkt dort anzeigen, wo der Fehler entsteht. ``` --- **Buttons** Buttons lösen Aktionen aus. Typische Buttons: | Button | Bedeutung | |---|---| | **Speichern** | Eingaben übernehmen | | **Abbrechen** | Vorgang verlassen | | **Zurück zur Liste** | zur Übersicht zurückkehren | | **Neu** | neuen Datensatz anlegen | | **Bearbeiten** | vorhandenen Datensatz ändern | | **Löschen** | Datensatz entfernen | Wichtig: ```text Buttons sollten eindeutig beschriftet sein. ``` Nicht ideal: ```text OK Weiter Klick Button 1 ``` Besser: ```text Speichern Abbrechen Zurück zur Liste Produkt löschen ``` --- **Benutzerführung** Benutzerführung bedeutet: ```text Der Benutzer erkennt, was er tun soll. ``` Eine gute Oberfläche hilft dem Benutzer durch: ```text klare Überschriften verständliche Feldnamen sinnvolle Reihenfolge der Felder sichtbare Pflichtfelder verständliche Fehlertexte logische Buttons Rückweg zur Übersicht ``` Merksatz: ```text Der Benutzer soll nicht raten müssen. ``` --- **Mock-up vs. UML-Diagramme** | Mock-up | UML-Diagramm | |---|---| | zeigt Oberfläche | zeigt Struktur oder Ablauf | | visuelle UI-Planung | Modellierung | | Felder, Buttons, Navigation | Klassen, Objekte, Prozesse | | Benutzerbedienung | Systemlogik | | nicht zwingend formal | UML hat festere Notation | Merksatz: ```text Mock-up = Oberfläche UML = Modell ``` --- **Mock-up vs. ERM** | Mock-up | ERM | |---|---| | zeigt Eingabemaske | zeigt Datenmodell | | Benutzer sieht Felder | Entwickler sieht Entitäten | | Beispiel: Produktformular | Beispiel: Produkt-Entität | | Oberfläche | Datenstruktur | Beispiel: ```text Mock-up-Feld: Produktname ERM-Attribut: produktname ``` --- **Mock-up vs. Aktivitätsdiagramm** | Mock-up | Aktivitätsdiagramm | |---|---| | zeigt Oberfläche | zeigt Ablauf | | Benutzer klickt Speichern | Ablauf nach dem Klick | | Felder und Buttons | Aktionen und Entscheidungen | | statische Ansicht | Prozesslogik | Beispiel: ```text Mock-up: Button „Speichern“ Aktivitätsdiagramm: Eingabe prüfen → gültig? → speichern oder Fehler anzeigen ``` --- **Vorgehensweise in der Prüfung** Wenn du ein Mock-up erstellen sollst, gehe so vor: | Schritt | Frage | |---|---| | 1 | Welche Aufgabe soll die Oberfläche erfüllen? | | 2 | Wer benutzt die Oberfläche? | | 3 | Welche Daten müssen eingegeben werden? | | 4 | Welche Felder sind Pflichtfelder? | | 5 | Welche Buttons braucht der Benutzer? | | 6 | Welche Fehlermeldungen können auftreten? | | 7 | Wie kommt der Benutzer zurück oder weiter? | | 8 | Ist die Oberfläche übersichtlich? | | 9 | Sind Beschriftungen eindeutig? | --- **Typische IHK-Fehler** | Fehler | Warum problematisch? | |---|---| | Pflichtfelder nicht markiert | Benutzer weiß nicht, was nötig ist | | Fehlermeldung fehlt | Benutzer versteht den Fehler nicht | | Fehlermeldung an falscher Stelle | Fehler ist schwer zuzuordnen | | Buttons unklar beschriftet | Benutzer weiß nicht, was passiert | | kein Abbrechen / Zurück | Benutzer steckt fest | | zu viele Elemente auf einmal | Oberfläche wirkt unübersichtlich | | Felder ohne Beschriftung | Bedeutung ist unklar | | Oberfläche passt nicht zur Aufgabe | Anforderungen werden nicht erfüllt | --- **Prüfungs-Merksätze** ```text Mock-up = visueller Oberflächenentwurf Mock-up ist kein UML-Diagramm Mock-up muss nicht funktionieren Mock-up zeigt Felder, Buttons und Benutzerführung Pflichtfelder klar markieren Fehlermeldungen direkt am Feld anzeigen Buttons eindeutig benennen Benutzer soll die Oberfläche ohne Raten verstehen ``` --- **Mini-Beispiel 1** Aufgabe: ```text Entwerfen Sie eine Eingabemaske zum Anlegen eines Produkts. ``` Wichtige Elemente: ```text Produktname * Kategorie * Preis * Lagerbestand Aktiv-Checkbox Speichern Abbrechen Fehlermeldung bei ungültigem Preis ``` --- **Mini-Beispiel 2** Aufgabe: ```text Ein Benutzer soll sich anmelden können. ``` Wichtige Elemente: ```text Benutzername / E-Mail Passwort Anmelden-Button Passwort vergessen Fehlermeldung bei falschen Zugangsdaten ``` --- **Mini-Beispiel 3** Aufgabe: ```text Ein Kunde soll eine Bestellung abschließen können. ``` Wichtige Elemente: ```text Warenkorbübersicht Lieferadresse Zahlungsart AGB-Checkbox Bestellung abschließen Zurück zum Warenkorb Fehlermeldung bei fehlender Zahlungsart ``` --- **Mini-Testfragen**
1. Was ist ein Mock-up? Ein Mock-up ist ein visueller Entwurf einer Benutzeroberfläche. Es zeigt, wie die Oberfläche aussehen und bedient werden soll.
2. Ist ein Mock-up ein UML-Diagramm? Nein. Ein Mock-up ist kein UML-Diagramm. Es ist ein Oberflächenentwurf.
3. Was zeigt ein Mock-up typischerweise? Ein Mock-up zeigt zum Beispiel: ```text Felder Buttons Navigation Fehlermeldungen Layout Benutzerführung ```
4. Was bedeutet ein Sternchen `*` an einem Feld? Das Sternchen zeigt ein Pflichtfeld. Beispiel: ```text Preis * ``` Der Preis muss eingegeben werden.
5. Wo sollte eine Fehlermeldung stehen? Möglichst nah am betroffenen Feld. Beispiel: ```text Preis muss größer als 0 sein. ``` direkt unter dem Preisfeld.
6. Warum sind eindeutige Buttons wichtig? Weil der Benutzer erkennen muss, welche Aktion ausgelöst wird. Besser: ```text Speichern Abbrechen Zurück zur Liste ``` statt: ```text OK Weiter Button 1 ```
7. Was ist Benutzerführung? Benutzerführung bedeutet, dass die Oberfläche dem Benutzer klar zeigt, was er tun soll. Dazu gehören: ```text klare Beschriftungen sinnvolle Reihenfolge Fehlermeldungen Rückwege ```
8. Was ist der Unterschied zwischen Mock-up und Aktivitätsdiagramm? Ein Mock-up zeigt die Oberfläche. Ein Aktivitätsdiagramm zeigt den Ablauf. Beispiel: ```text Mock-up: Speichern-Button Aktivitätsdiagramm: Eingabe prüfen → speichern ```
9. Muss ein Mock-up programmierbar oder funktionsfähig sein? Nein. Ein Mock-up muss nicht funktionieren. Es zeigt die geplante Oberfläche.
10. Was ist ein häufiger Fehler bei Mock-ups? Ein häufiger Fehler ist, dass Pflichtfelder, Fehlermeldungen oder wichtige Buttons fehlen. Dadurch versteht der Benutzer die Oberfläche schlechter.
--- **Nächste Seite** Danach kommt die eigene Trainer-Seite: ```text Mock-up-Trainer ``` Dort übst du: ```text Pflichtfelder erkennen Fehlermeldungen richtig platzieren notwendige Buttons auswählen Benutzerführung bewerten Mock-up-Elemente aus einer Aufgabenstellung ableiten ``` # Seite 16: Mock-up-Trainer Dieser interaktive Trainer gehört zur Theorie-Seite: ```text Mock-up / Benutzeroberflächen-Entwurf ``` Hier übst du, aus einer Aufgabenbeschreibung die wichtigsten Elemente einer Benutzeroberfläche abzuleiten. Im Fokus stehen: ```text Pflichtfelder Fehlermeldungen Validierung Buttons Hauptaktion Nebenaktion Benutzerführung Mock-up ≠ UML-Diagramm ``` --- **Was wird trainiert?** | Bereich | Bedeutung | |---|---| | **Pflichtfelder erkennen** | wichtige Felder mit `*` markieren | | **Fehlermeldungen platzieren** | Fehler direkt am betroffenen Feld anzeigen | | **Validierung verstehen** | Eingaben fachlich prüfen | | **Hauptaktion erkennen** | wichtigste Aktion, z. B. Speichern oder Anmelden | | **Nebenaktionen erkennen** | Abbrechen, Zurück, Zurück zur Liste | | **Benutzerführung bewerten** | Oberfläche soll verständlich und logisch sein | | **Mock-up einordnen** | Mock-up ist kein UML-Diagramm | --- **Interaktiver Mock-up-Trainer** --- **Merksatz für den Trainer** ```text Mock-up = geplanter Oberflächenentwurf Mock-up ist kein UML-Diagramm Pflichtfelder müssen erkennbar sein Fehlermeldungen gehören nah an das betroffene Feld Buttons müssen eindeutig beschriftet sein Benutzerführung muss logisch und verständlich sein ``` --- **Beispiel: Produktformular** Aufgabenstellung: ```text Ein Produkt soll angelegt werden. Produktname, Kategorie und Preis sind Pflichtfelder. Der Preis muss größer als 0 sein. Der Benutzer soll speichern, abbrechen oder zurück zur Liste gehen können. ``` Mögliche Lösung: ```text Pflichtfelder: Produktname Kategorie Preis Fehlermeldung: Direkt am Preisfeld Hauptaktion: Speichern Sinnvolle Nebenaktionen: Abbrechen Zurück zur Liste Validierung: Preis muss größer als 0 sein Einordnung: Mock-up ist kein UML-Diagramm ``` --- **Warum ist das fachlich richtig?** Ein Mock-up soll zeigen, wie eine Oberfläche aufgebaut ist und wie der Benutzer sie bedient. Bei einem Produktformular muss der Benutzer erkennen: ```text Welche Daten muss ich eingeben? Welche Felder sind Pflicht? Was ist falsch, wenn eine Eingabe ungültig ist? Wie speichere ich? Wie breche ich ab? Wie komme ich zurück? ``` --- **Pflichtfelder** Pflichtfelder sind Felder, die ausgefüllt werden müssen. Typische Darstellung: ```text Produktname * Kategorie * Preis * ``` Das Sternchen `*` zeigt: ```text Dieses Feld ist erforderlich. ``` --- **Fehlermeldungen** Fehlermeldungen sollten möglichst direkt beim betroffenen Feld stehen. Gut: ```text Preis * [ 0,00 € ] Preis muss größer als 0 sein. ``` Schlecht: ```text Irgendwo oben steht nur: Fehler. ``` Merksatz: ```text Der Benutzer muss sofort erkennen, was falsch ist und wo er es korrigieren muss. ``` --- **Validierung** Validierung bedeutet: ```text Das System prüft, ob die Eingabe gültig ist. ``` Beispiele: ```text Preis muss größer als 0 sein E-Mail-Adresse muss gültig sein Passwort darf nicht leer sein Produktname muss ausgefüllt sein Kategorie muss ausgewählt werden ``` --- **Hauptaktion** Die Hauptaktion ist die wichtigste Aktion im Formular. Beispiele: ```text Speichern Anmelden Bestellung abschließen Absenden ``` Im Produktformular ist die Hauptaktion: ```text Speichern ``` --- **Nebenaktionen** Nebenaktionen helfen dem Benutzer, den Vorgang zu verlassen oder zurückzugehen. Beispiele: ```text Abbrechen Zurück zur Liste Zurück zum Warenkorb Schließen ``` Wichtig: ```text Der Benutzer soll nicht in der Oberfläche feststecken. ``` --- **Mock-up ist kein UML-Diagramm** Ein Mock-up zeigt eine Benutzeroberfläche. Es zeigt nicht: ```text Klassen Methoden Kardinalitäten Sequenzen Kontrollflüsse Datenbankbeziehungen ``` Dafür gibt es andere Diagramme. Merksatz: ```text Mock-up = Oberfläche UML = Modellierung ``` --- **Typische Fehler im Mock-up** | Fehler | Warum problematisch? | |---|---| | Pflichtfelder fehlen | Benutzer weiß nicht, was zwingend ist | | Fehlermeldung fehlt | Benutzer versteht den Fehler nicht | | Fehlermeldung steht zu weit weg | Fehler ist schwer zuzuordnen | | Button heißt nur „OK“ | Aktion ist nicht eindeutig | | Kein Abbrechen-Button | Benutzer kann Vorgang schlecht verlassen | | Kein Rückweg | Benutzerführung ist unvollständig | | Zu viele Elemente | Oberfläche wird unübersichtlich | | Technische Begriffe | Benutzer versteht die Oberfläche schlechter | --- **Mini-Testfragen**
1. Was trainiert dieser Mock-up-Trainer? Er trainiert das Erkennen wichtiger UI-Elemente: ```text Pflichtfelder Fehlermeldungen Validierung Buttons Benutzerführung ```
2. Was bedeutet ein Sternchen `*` an einem Feld? Das Sternchen bedeutet: ```text Pflichtfeld ``` Das Feld muss ausgefüllt werden.
3. Wo sollte eine Fehlermeldung stehen? Möglichst direkt am betroffenen Feld. Beispiel: ```text Preis muss größer als 0 sein. ``` direkt beim Preisfeld.
4. Was ist die Hauptaktion im Produktformular? Die Hauptaktion ist: ```text Speichern ```
5. Welche Nebenaktionen sind sinnvoll? Zum Beispiel: ```text Abbrechen Zurück zur Liste ```
6. Was bedeutet Validierung? Validierung bedeutet: ```text Das System prüft, ob eine Eingabe gültig ist. ``` Beispiel: ```text Preis muss größer als 0 sein. ```
7. Ist ein Mock-up ein UML-Diagramm? Nein. Ein Mock-up ist ein Oberflächenentwurf und kein UML-Diagramm.
8. Was zeigt ein Mock-up nicht? Ein Mock-up zeigt nicht: ```text Programmcode Datenbankbeziehungen Klassendiagramme Sequenzdiagramme Kontrollflüsse ```
9. Warum sind eindeutige Buttons wichtig? Weil der Benutzer erkennen muss, welche Aktion passiert. Besser: ```text Speichern Abbrechen Zurück zur Liste ``` statt: ```text OK Weiter Button 1 ```
10. Was ist Benutzerführung? Benutzerführung bedeutet: ```text Die Oberfläche zeigt dem Benutzer klar, was er tun soll. ``` Dazu gehören: ```text verständliche Feldnamen sichtbare Pflichtfelder klare Buttons Fehlermeldungen Rückwege ```
--- **Nächste Seite** Danach geht es weiter mit: ```text UML-Zustandsdiagramm ``` # 2 – APIs, SaaS-Systeme und Prozessautomatisierung # 2.1 Überblick – SaaS-Systeme, APIs und Prozessautomatisierung Unternehmen nutzen häufig mehrere unterschiedliche Anwendungen, zum Beispiel: - Google Workspace für E-Mail, Kalender und Dateien - Slack für die interne Kommunikation - Zoho CRM für Kunden und Vertriebsprozesse - Asana oder Zoho Projects für Aufgaben und Projekte - n8n für automatisierte Abläufe Damit Daten nicht immer manuell zwischen diesen Systemen übertragen werden müssen, können sie über APIs, Webhooks und Automatisierungsplattformen miteinander verbunden werden. --- **Lernziele** Nach dieser Seite solltest du erklären können: - was SaaS, CRM und Projektmanagement-Systeme sind - was eine API ist - was Request und Response bedeuten - wofür JSON verwendet wird - was Webhooks und Polling sind - wie ein automatisierter Workflow aufgebaut ist --- **SaaS-System** SaaS bedeutet: > Software as a Service Die Software wird als Onlinedienst bereitgestellt und meistens über einen Browser oder eine App verwendet. Beispiele: - Google Workspace - Slack - Microsoft 365 - Zoho - Asana Der Anbieter übernimmt normalerweise den Betrieb und die Aktualisierung der Plattform. Das Unternehmen bleibt unter anderem verantwortlich für: - Benutzerkonten - Gruppen und Rollen - Zugriffsrechte - Multi-Faktor-Authentifizierung - Datenschutz - Onboarding und Offboarding > SaaS beschreibt, wie eine Software bereitgestellt wird. --- **CRM-System** CRM bedeutet: > Customer Relationship Management Ein CRM-System verwaltet Informationen über: - Kunden und Interessenten - Ansprechpartner - Gespräche - Angebote - Verträge - Verkaufschancen - offene Aufgaben und Termine Beispiel: | Information | Inhalt | |---|---| | Kunde | Beispiel Logistik GmbH | | Ansprechpartner | Anna Müller | | Projektstatus | technische Prüfung | | nächste Aufgabe | Beratungstermin planen | > Ein CRM-System ist eine zentrale digitale Kunden- und Vertriebsakte. --- **Projektmanagement-System** Ein Projektmanagement-System organisiert: - Projekte - Aufgaben - Verantwortliche - Termine - Prioritäten - Bearbeitungsstände - Dokumente - Abhängigkeiten Beispiel: | Aufgabe | Verantwortlich | Status | |---|---|---| | Anforderungen aufnehmen | Projektleitung | abgeschlossen | | Benutzerkonten anlegen | IT | offen | | Dokumentation erstellen | IT | offen | > Ein Projektmanagement-System organisiert Aufgaben, Zuständigkeiten und Termine. --- **Unterschied der Begriffe** | Begriff | Bedeutung | |---|---| | SaaS | Bereitstellungsform einer Software | | CRM | Software für Kunden- und Vertriebsprozesse | | Projektmanagement-System | Software für Aufgaben und Projekte | Ein CRM- oder Projektmanagement-System kann gleichzeitig ein SaaS-System sein. --- **API** API bedeutet: > Application Programming Interface Auf Deutsch: > Programmierschnittstelle Eine API ermöglicht es unterschiedlichen Programmen, Daten auszutauschen oder Funktionen eines anderen Systems aufzurufen. Beispiel: n8n | | API-Anfrage v Google Workspace | | API-Antwort v n8n Eine API legt unter anderem fest: - welche Funktionen verfügbar sind - welche Daten gesendet werden müssen - welche Berechtigungen benötigt werden - welches Ergebnis zurückgegeben wird > Eine Benutzeroberfläche ist für Menschen gedacht. Eine API ist für die Kommunikation zwischen Programmen gedacht. --- **Request und Response** Ein Request ist eine Anfrage. Beispiel: > Lege einen neuen Benutzer an. Eine Response ist die Antwort des Systems. Beispiel: > Benutzer wurde erfolgreich angelegt. Grundablauf: Client | | Request v Server | | Response v Client > Request bedeutet Anfrage. Response bedeutet Antwort. --- **Endpoint** Ein Endpoint ist eine konkrete Adresse innerhalb einer API. Beispiele: https://api.example.com/users https://api.example.com/projects Die Adresse `/users` könnte Benutzer verwalten. Die Adresse `/projects` könnte Projekte verwalten. > Ein Endpoint ist eine konkrete API-Adresse für eine Ressource oder Funktion. --- **JSON** JSON bedeutet: > JavaScript Object Notation JSON ist ein textbasiertes Format für strukturierte Daten. Beispiel: { "name": "Max Mustermann", "department": "IT", "active": true } | Schlüssel | Wert | |---|---| | name | Felix Ulrich | | department | IT | | active | true | APIs verwenden JSON häufig für Requests und Responses. > JSON überträgt strukturierte Daten zwischen Anwendungen. --- **Webhook und Polling** Ein Webhook meldet automatisch ein Ereignis. Beispiel: > Ein neuer Mitarbeiter wurde angelegt. Das System sendet die Information sofort an n8n und startet dadurch einen Workflow. Beim Polling fragt n8n dagegen regelmäßig: > Gibt es neue Daten? | Verfahren | Funktionsweise | |---|---| | Webhook | Das Quellsystem meldet ein Ereignis | | Polling | Das Zielsystem fragt regelmäßig nach | > Beim Webhook wird ein Ereignis gemeldet. Beim Polling wird regelmäßig danach gefragt. --- **Automatisierter Workflow** Ein Workflow ist eine festgelegte Folge von Schritten. Beispiel: Neuer Mitarbeiter | v Daten prüfen | v Benutzerkonto anlegen | v Gruppen zuweisen | v IT-Aufgabe erstellen | v Ergebnis protokollieren Typische Bestandteile: | Bestandteil | Bedeutung | |---|---| | Trigger | startet den Workflow | | Eingabedaten | werden verarbeitet | | Bedingung | entscheidet über den Ablauf | | Aktion | führt eine Aufgabe aus | | API-Aufruf | kommuniziert mit einem System | | Logging | protokolliert den Ablauf | | Fehlerpfad | behandelt Probleme | --- **Praxisbeispiel: Mitarbeiter-Onboarding** Ein neuer Mitarbeiter wird im Personalsystem freigegeben. 1. Das Personalsystem sendet einen Webhook. 2. n8n empfängt die Mitarbeiterdaten. 3. Die Daten werden geprüft. 4. Über eine API wird ein Benutzerkonto angelegt. 5. Gruppen und Rollen werden zugewiesen. 6. Eine Aufgabe für die Laptop-Einrichtung wird erstellt. 7. Die IT erhält eine Slack-Nachricht. 8. Das Ergebnis wird protokolliert. Beteiligte Systeme könnten sein: - Personalsystem - n8n - Google Workspace - Slack - Projektmanagement-System - Ticketsystem --- **Vorteile der Automatisierung** - Zeitersparnis - weniger manuelle Übertragungsfehler - einheitliche Abläufe - bessere Dokumentation - schnellere Reaktion - bessere Skalierbarkeit --- **Risiken der Automatisierung** - falsche Eingabedaten - fehlende Berechtigungen - abgelaufene Zugangstoken - nicht erreichbare Systeme - doppelte Ausführung - unvollständige Prozesse - Datenschutzprobleme - fehlende Fehlerbehandlung > Eine Automatisierung ist erst professionell, wenn auch Fehler und Ausnahmefälle behandelt werden. --- **Aufgaben der internen IT** - Benutzer und Gruppen verwalten - Rollen und Rechte vergeben - MFA konfigurieren - SaaS-Systeme administrieren - API-Zugänge absichern - Workflows überwachen - Logs kontrollieren - Fehler analysieren - Onboarding und Offboarding durchführen - technische Abläufe dokumentieren --- **Systematische Fehlersuche** Wenn ein Workflow nicht funktioniert: 1. Wurde der Workflow ausgelöst? 2. Sind die Eingabedaten vollständig? 3. Ist das Zielsystem erreichbar? 4. Ist der Endpoint korrekt? 5. Ist die Authentifizierung gültig? 6. Sind ausreichende Berechtigungen vorhanden? 7. Welche Fehlermeldung oder welcher Statuscode wurde zurückgegeben? 8. Welcher Schritt ist fehlgeschlagen? 9. Kann der Schritt sicher erneut ausgeführt werden? 10. Muss ein Administrator informiert werden? --- **Wichtige Begriffe** | Begriff | Bedeutung | |---|---| | SaaS | online bereitgestellte Software | | CRM | System für Kunden und Vertriebsprozesse | | API | Schnittstelle zwischen Programmen | | Client | sendet eine Anfrage | | Server | verarbeitet die Anfrage | | Request | Anfrage | | Response | Antwort | | Endpoint | konkrete API-Adresse | | JSON | Format für strukturierte Daten | | Webhook | automatische Ereignismeldung | | Polling | regelmäßige Abfrage | | Trigger | startet einen Workflow | | Workflow | festgelegte Folge von Schritten | | Logging | Protokollierung des Ablaufs | --- **Gesamtmerksatz** > SaaS-Systeme stellen Anwendungen als Onlinedienst bereit. APIs verbinden unterschiedliche Systeme. JSON überträgt strukturierte Daten. Webhooks melden Ereignisse und Automatisierungsplattformen wie n8n führen daraus festgelegte Workflows aus. --- **Kontrollfragen** **Was beschreibt SaaS?** SaaS beschreibt die Bereitstellung einer Software als Onlinedienst. **Was ist ein CRM-System?** Ein System zur Verwaltung von Kunden, Kontakten und Vertriebsprozessen. **Was ermöglicht eine API?** Sie ermöglicht die Kommunikation und den Datenaustausch zwischen Programmen. **Was ist der Unterschied zwischen Request und Response?** Der Request ist die Anfrage. Die Response ist die Antwort. **Was ist JSON?** Ein textbasiertes Format für strukturierte Daten. **Was ist der Unterschied zwischen Webhook und Polling?** Ein Webhook meldet ein Ereignis aktiv. Beim Polling wird regelmäßig nach Änderungen gefragt. **Was startet einen Workflow?** Ein Trigger, beispielsweise ein Webhook, Zeitplan oder manueller Start. --- **Quellen** - [NIST – The Definition of Cloud Computing](https://csrc.nist.gov/pubs/sp/800/145/final) - [IETF – HTTP Semantics](https://datatracker.ietf.org/doc/html/rfc9110) - [IETF – JSON Data Interchange Format](https://datatracker.ietf.org/doc/html/rfc8259) - [n8n-Dokumentation – Workflows](https://docs.n8n.io/build/understand-workflows/create-and-run-workflows/) - [n8n-Dokumentation – Webhook Node](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.webhook/) ``` # 2.2 SaaS-, CRM-, Projektmanagement- und Kollaborationssysteme Unternehmen verwenden verschiedene Softwarearten für unterschiedliche Aufgaben. Typische Systeme sind: - SaaS-Systeme für online bereitgestellte Anwendungen - CRM-Systeme für Kunden und Vertriebsprozesse - Projektmanagement-Systeme für Aufgaben und Termine - Kollaborationssysteme für Kommunikation und Zusammenarbeit Eine Anwendung kann mehreren Kategorien gleichzeitig angehören. --- **Lernziele** Nach dieser Seite solltest du erklären können: - was SaaS bedeutet - was CRM-, Projektmanagement- und Kollaborationssysteme unterscheiden - welche Aufgaben die interne IT übernimmt - wie Benutzer, Rollen und Lizenzen verwaltet werden - welche Vorteile und Risiken Cloud-Anwendungen besitzen - warum verschiedene Systeme über APIs verbunden werden --- **Software as a Service** SaaS bedeutet: > Software as a Service Eine Software wird vom Anbieter betrieben und über das Internet bereitgestellt. Die Nutzung erfolgt meistens über: - Webbrowser - Desktop-Anwendung - Smartphone-App - API Typische SaaS-Beispiele: - Google Workspace - Microsoft 365 - Slack - Asana - Zoho CRM - Salesforce - Dropbox Das Unternehmen muss normalerweise keine eigenen Anwendungsserver betreiben. --- **Aufgaben des SaaS-Anbieters** Der Anbieter übernimmt typischerweise: - Betrieb der Plattform - Wartung der Server - Softwareaktualisierungen - technische Verfügbarkeit - Absicherung der Anbieterinfrastruktur - Fehlerbehebung innerhalb der Plattform --- **Aufgaben des verwendenden Unternehmens** Die interne IT bleibt unter anderem verantwortlich für: - Benutzerkonten - Gruppen - Rollen und Berechtigungen - Multi-Faktor-Authentifizierung - Lizenzen - sichere Konfiguration - Freigaben - Datenschutz - Onboarding und Offboarding - Kontrolle der Zugriffsprotokolle - Integration mit anderen Systemen > Der Anbieter betreibt die Plattform. Das Unternehmen verwaltet seine Benutzer, Daten und Zugriffsrechte. --- **CRM-System** CRM bedeutet: > Customer Relationship Management Ein CRM-System verwaltet Kundenbeziehungen und Vertriebsprozesse. Typische Inhalte: - Unternehmen - Ansprechpartner - Kontaktdaten - Gespräche - Angebote - Verträge - Verkaufschancen - Aufgaben - Termine - Projektstatus Beispiel: | Information | Inhalt | |---|---| | Kunde | Musterfirma GmbH | | Ansprechpartner | Max Mustermann | | Status | Angebot wird erstellt | | zuständige Person | Vertriebsmitarbeiter | | nächste Aufgabe | Rückruf vereinbaren | | Termin | 20. Juli 2026 | > Ein CRM-System ist eine zentrale Kunden- und Vertriebsakte. --- **Typischer CRM-Ablauf** Neuer Interessent | v Kontaktdaten erfassen | v Beratungsgespräch dokumentieren | v Angebot erstellen | v Auftrag gewinnen oder ablehnen | v Kundenbeziehung weiter betreuen CRM-Systeme helfen dabei, dass Informationen nicht nur in persönlichen E-Mails oder einzelnen Dateien gespeichert werden. --- **Projektmanagement-System** Ein Projektmanagement-System organisiert Projekte und Aufgaben. Typische Funktionen: - Projekte anlegen - Aufgaben erstellen - Verantwortliche zuweisen - Termine festlegen - Prioritäten vergeben - Bearbeitungsstände anzeigen - Abhängigkeiten verwalten - Kommentare erfassen - Dokumente verknüpfen - Fortschritt überwachen Beispiel: | Aufgabe | Verantwortlich | Frist | Status | |---|---|---|---| | Anforderungen aufnehmen | Projektleitung | 20.07.2026 | abgeschlossen | | Benutzerkonten anlegen | IT | 22.07.2026 | offen | | Hardware vorbereiten | IT-Support | 23.07.2026 | in Bearbeitung | | Dokumentation erstellen | Administration | 24.07.2026 | offen | > Ein Projektmanagement-System organisiert Aufgaben, Zuständigkeiten, Fristen und Fortschritte. --- **Kollaborationssystem** Kollaboration bedeutet Zusammenarbeit. Ein Kollaborationssystem unterstützt Mitarbeiter bei: - Nachrichten - Gruppenchats - Videokonferenzen - gemeinsamer Dateibearbeitung - Kommentaren - Kalendern - Benachrichtigungen - Informationsaustausch Typische Beispiele: | System | Hauptfunktion | |---|---| | Slack | Teamkommunikation | | Microsoft Teams | Chat, Besprechungen und Dateien | | Google Workspace | E-Mail, Kalender und Dokumente | | Miro | gemeinsame digitale Arbeitsfläche | | Confluence | Dokumentation und Wissensaustausch | --- **Slack als Beispiel** Slack ist eine Kommunikationsplattform für Unternehmen. Die Kommunikation erfolgt unter anderem über: - Direktnachrichten - Gruppennachrichten - öffentliche Kanäle - private Kanäle - Threads - Sprach- und Videoanrufe Beispiele für Kanäle: #it-support #projekt-solar #allgemein #vertrieb #product-tech Ein Kanal bündelt Nachrichten zu einem bestimmten Team oder Thema. Slack kann außerdem Benachrichtigungen anderer Systeme anzeigen. Beispiel: > Ein n8n-Workflow sendet eine Nachricht an den Kanal `#it-support`, wenn ein automatisierter Prozess fehlschlägt. --- **Unterschied der Systemarten** | Systemart | Hauptaufgabe | |---|---| | SaaS-System | beschreibt die Bereitstellung als Onlinedienst | | CRM-System | verwaltet Kunden und Vertriebsprozesse | | Projektmanagement-System | verwaltet Projekte, Aufgaben und Termine | | Kollaborationssystem | unterstützt Kommunikation und Zusammenarbeit | Eine Anwendung kann mehrere Funktionen besitzen. Beispiele: | Anwendung | Einordnung | |---|---| | Zoho CRM | CRM und SaaS | | Asana | Projektmanagement und SaaS | | Slack | Kollaboration und SaaS | | Google Workspace | Kollaboration, Kommunikation und SaaS | | Microsoft Teams | Kollaboration und SaaS | > SaaS beschreibt die Bereitstellung. Die anderen Begriffe beschreiben den Einsatzzweck. --- **Benutzerkonten** Für jeden Mitarbeiter wird normalerweise ein persönliches Benutzerkonto angelegt. Ein Benutzerkonto kann enthalten: - Name - E-Mail-Adresse - Abteilung - Rolle - Gruppenmitgliedschaften - Lizenzen - Zugriffsrechte - Spracheinstellungen - Sicherheitsinformationen Gemeinsam verwendete Benutzerkonten sollten möglichst vermieden werden. Nachteile gemeinsamer Konten: - Aktionen sind nicht eindeutig zuordenbar - Passwörter müssen geteilt werden - Zugriffe lassen sich schwer entziehen - Protokolle verlieren ihre Aussagekraft - Sicherheitsvorfälle sind schwerer nachzuvollziehen --- **Gruppen und Rollen** Benutzer werden häufig anhand ihrer Aufgaben in Gruppen oder Rollen eingeordnet. Beispiele: | Gruppe oder Rolle | Mögliche Berechtigung | |---|---| | Vertrieb | Zugriff auf CRM-Kundendaten | | IT-Support | Benutzerkonten bearbeiten | | Buchhaltung | Zugriff auf Finanzsysteme | | Projektleitung | Projekte und Aufgaben verwalten | | Mitarbeiter | allgemeine Standardzugriffe | | Administrator | technische Systeme verwalten | Rollenbasierte Rechtevergabe wird auch als RBAC bezeichnet. RBAC bedeutet: > Role-Based Access Control Dabei werden Rechte anhand einer Rolle vergeben und nicht für jeden Benutzer einzeln zusammengestellt. --- **Least Privilege** Least Privilege bedeutet: > Jeder Benutzer erhält nur die Rechte, die er für seine Aufgaben benötigt. Beispiele: - Ein Vertriebsmitarbeiter benötigt keinen vollständigen Administratorzugriff. - Ein Praktikant benötigt nicht automatisch Zugriff auf alle Kundendaten. - Ein Automatisierungsworkflow sollte nur die benötigten API-Rechte besitzen. - Ein ausgeschiedener Mitarbeiter darf keine aktiven Zugänge behalten. Vorteile: - geringeres Sicherheitsrisiko - weniger versehentliche Änderungen - bessere Nachvollziehbarkeit - einfachere Rechtekontrolle --- **Lizenzen** Viele SaaS-Systeme werden pro Benutzer und Monat bezahlt. Die interne IT muss daher prüfen: - Wer benötigt eine Lizenz? - Welche Lizenzstufe wird benötigt? - Welche Konten werden nicht mehr verwendet? - Wurden Konten ausgeschiedener Mitarbeiter deaktiviert? - Werden unnötige Kosten verursacht? Beispiel: Ein Mitarbeiter verlässt das Unternehmen. Die IT sollte: 1. den Zugang sperren 2. aktive Sitzungen beenden 3. Daten sichern oder übertragen 4. Gruppenmitgliedschaften entfernen 5. Lizenzen freigeben 6. den Vorgang dokumentieren --- **Onboarding** Onboarding bezeichnet die technische Einrichtung eines neuen Mitarbeiters. Typische Aufgaben: - Benutzerkonto anlegen - E-Mail-Adresse erstellen - Gruppen zuweisen - Rollen vergeben - Lizenzen aktivieren - MFA einrichten - Laptop vorbereiten - benötigte Software installieren - Zugänge dokumentieren - Einführung bereitstellen Ein standardisierter Ablauf verhindert, dass wichtige Schritte vergessen werden. --- **Offboarding** Offboarding bezeichnet die technische Bearbeitung eines Mitarbeiteraustritts. Typische Aufgaben: - Benutzerkonto deaktivieren - aktive Sitzungen beenden - Passwörter oder Tokens widerrufen - Zugriffsrechte entfernen - Daten an zuständige Personen übertragen - Geräte zurücknehmen - Lizenzen freigeben - automatische Weiterleitungen prüfen - Vorgang dokumentieren > Ein nicht vollständig durchgeführtes Offboarding kann ein erhebliches Sicherheitsrisiko darstellen. --- **Multi-Faktor-Authentifizierung** Bei der Multi-Faktor-Authentifizierung werden mindestens zwei unterschiedliche Faktoren benötigt. Mögliche Faktoren: - Wissen: Passwort oder PIN - Besitz: Smartphone oder Sicherheitsschlüssel - biometrisches Merkmal: Fingerabdruck oder Gesichtserkennung Beispiel: Passwort + Bestätigung über eine Authenticator-App MFA schützt Konten zusätzlich, wenn ein Passwort gestohlen wurde. --- **Single Sign-on** SSO bedeutet: > Single Sign-on Ein Benutzer meldet sich zentral an und kann anschließend mehrere verbundene Anwendungen verwenden. Beispiel: Zentrale Anmeldung | v Google Workspace / | \ v v v Slack CRM Projektmanagement Vorteile: - weniger separate Passwörter - zentrale Benutzerverwaltung - schnellere Sperrung von Zugängen - vereinfachtes Onboarding und Offboarding Risiko: Fällt das zentrale Konto aus oder wird es übernommen, können mehrere Systeme betroffen sein. --- **Audit-Logs** Audit-Logs protokollieren sicherheitsrelevante Aktionen. Beispiele: - Benutzer wurde angelegt - Rolle wurde geändert - Anmeldung ist fehlgeschlagen - MFA wurde deaktiviert - Datei wurde freigegeben - API-Token wurde erstellt - Administratorrechte wurden vergeben Audit-Logs helfen bei: - Fehlersuche - Sicherheitsanalysen - Nachvollziehbarkeit - Datenschutzprüfungen - internen Kontrollen --- **Vorteile von SaaS-Systemen** - schnelle Bereitstellung - Zugriff über verschiedene Geräte - automatische Aktualisierungen - geringe eigene Serververwaltung - einfache Erweiterbarkeit - häufig gute Integrationsmöglichkeiten - flexible Lizenzmodelle - zentrale Zusammenarbeit --- **Risiken von SaaS-Systemen** - Abhängigkeit vom Anbieter - mögliche Ausfälle - laufende Lizenzkosten - Datenschutzanforderungen - falsche Freigaben - zu umfangreiche Berechtigungen - unvollständiges Offboarding - unkontrollierte Schatten-IT - eingeschränkte Kontrolle über die Infrastruktur - Änderungen an Funktionen oder Schnittstellen --- **Schatten-IT** Schatten-IT bezeichnet Software oder Dienste, die ohne Freigabe der IT verwendet werden. Beispiel: Ein Mitarbeiter erstellt selbstständig ein Konto bei einem Onlinedienst und lädt dort Unternehmensdaten hoch. Mögliche Risiken: - unbekannte Datenspeicherung - fehlende Sicherheitsprüfung - keine zentrale Benutzerverwaltung - fehlendes Offboarding - zusätzliche Kosten - Datenschutzverletzungen Die IT sollte deshalb klare Prozesse für die Auswahl und Freigabe neuer SaaS-Anwendungen besitzen. --- **Verbindung verschiedener Systeme** SaaS-Systeme können über APIs miteinander verbunden werden. Beispiel: Zoho CRM | | neuer Kunde v n8n / \ v v Asana Slack Möglicher Ablauf: 1. Im CRM wird ein neuer Kunde angelegt. 2. Das CRM startet einen Webhook. 3. n8n empfängt die Kundendaten. 4. In Asana wird ein Projekt erstellt. 5. In Slack wird das zuständige Team informiert. 6. Das Ergebnis wird protokolliert. --- **Aufgaben der internen IT** Die interne IT übernimmt bei SaaS-Systemen unter anderem: - Benutzerverwaltung - Gruppenverwaltung - Rollen- und Rechtevergabe - Lizenzverwaltung - Onboarding und Offboarding - MFA und SSO - Integration verschiedener Systeme - API-Zugänge - Überwachung von Audit-Logs - Support - Dokumentation - Datenschutz und Sicherheit - Kontrolle von Schatten-IT --- **Systematische Fehlersuche** Wenn ein Benutzer keinen Zugriff auf ein SaaS-System besitzt: 1. Ist das Benutzerkonto aktiv? 2. Ist die richtige Lizenz zugewiesen? 3. Ist der Benutzer in der richtigen Gruppe? 4. Besitzt die Rolle ausreichende Rechte? 5. Funktioniert die zentrale Anmeldung? 6. Ist MFA korrekt eingerichtet? 7. Wurde das Passwort oder Token geändert? 8. Ist nur ein Benutzer oder das gesamte System betroffen? 9. Gibt es eine bekannte Störung beim Anbieter? 10. Welche Meldung steht im Audit-Log? --- **Wichtige Begriffe** | Begriff | Bedeutung | |---|---| | SaaS | online bereitgestellte Software | | CRM | Verwaltung von Kundenbeziehungen | | Kollaboration | digitale Zusammenarbeit | | Benutzerkonto | persönliche Identität in einem System | | Gruppe | Zusammenfassung mehrerer Benutzer | | Rolle | Bündel bestimmter Berechtigungen | | RBAC | rollenbasierte Zugriffskontrolle | | Least Privilege | nur notwendige Rechte vergeben | | Lizenz | Nutzungsberechtigung für eine Software | | Onboarding | technische Einrichtung eines Mitarbeiters | | Offboarding | Entzug und Sicherung von Zugängen | | MFA | Anmeldung mit mehreren Faktoren | | SSO | zentrale Anmeldung für mehrere Systeme | | Audit-Log | Protokoll sicherheitsrelevanter Aktionen | | Schatten-IT | nicht freigegebene Software oder Dienste | --- **Gesamtmerksatz** > SaaS beschreibt die Bereitstellung einer Anwendung als Onlinedienst. CRM-Systeme verwalten Kunden, Projektmanagement-Systeme organisieren Aufgaben und Kollaborationssysteme unterstützen die Zusammenarbeit. Die interne IT bleibt für Benutzer, Rollen, Lizenzen, Sicherheit und Integrationen verantwortlich. --- **Kontrollfragen** **Was bedeutet SaaS?** Software as a Service. Die Software wird als Onlinedienst bereitgestellt. **Was ist die Hauptaufgabe eines CRM-Systems?** Die Verwaltung von Kunden, Interessenten und Vertriebsprozessen. **Was verwaltet ein Projektmanagement-System?** Projekte, Aufgaben, Zuständigkeiten, Termine und Bearbeitungsstände. **Was ist ein Kollaborationssystem?** Eine Anwendung für Kommunikation und digitale Zusammenarbeit. **Was bedeutet RBAC?** Berechtigungen werden anhand einer Rolle vergeben. **Was bedeutet Least Privilege?** Benutzer und Anwendungen erhalten nur die tatsächlich benötigten Rechte. **Was ist Onboarding?** Die technische Einrichtung eines neuen Mitarbeiters. **Was ist Offboarding?** Das kontrollierte Entfernen von Zugängen und Berechtigungen beim Austritt. **Warum sind Audit-Logs wichtig?** Sie machen Änderungen, Zugriffe und sicherheitsrelevante Ereignisse nachvollziehbar. **Was ist Schatten-IT?** Software oder Dienste, die ohne Freigabe und Kontrolle der IT verwendet werden. --- **Quellen** - [NIST – The Definition of Cloud Computing](https://csrc.nist.gov/pubs/sp/800/145/final) - [NIST – Software as a Service](https://csrc.nist.gov/glossary/term/software_as_a_service) - [Google Workspace Admin Help](https://support.google.com/a/) - [Slack Help Center](https://slack.com/help) - [Zoho CRM Help](https://help.zoho.com/portal/en/kb/crm) - [Asana Guide](https://asana.com/guide) ``` # 2.3 API-Grundlagen – Client, Server, Endpoint, Request und Response Eine API ermöglicht es verschiedenen Programmen, Daten auszutauschen oder Funktionen eines anderen Systems aufzurufen. API bedeutet: > Application Programming Interface Auf Deutsch: > Programmierschnittstelle APIs werden beispielsweise verwendet, um: - Benutzerkonten anzulegen - Kundendaten abzurufen - Aufgaben zu erstellen - Nachrichten zu versenden - Dateien hochzuladen - Statusinformationen auszulesen - automatisierte Workflows auszuführen --- **Lernziele** Nach dieser Seite solltest du erklären können: - was eine API ist - was Client und Server bedeuten - was ein Endpoint ist - wie Request und Response zusammenhängen - wozu Header und Body verwendet werden - was Path- und Query-Parameter sind - wie eine typische API-Kommunikation abläuft - wie API-Fehler systematisch eingegrenzt werden --- **Benutzeroberfläche und API** Ein Mensch verwendet meistens eine grafische Benutzeroberfläche. Beispiel: Benutzer | v Webbrowser | v Schaltfläche „Benutzer anlegen“ Ein Programm verwendet dagegen häufig eine API. Beispiel: n8n | | API-Anfrage v Google Workspace | | API-Antwort v n8n Die API ermöglicht den Zugriff auf bestimmte Funktionen, ohne dass ein Mensch jede Aktion manuell über die Benutzeroberfläche ausführen muss. > Eine Benutzeroberfläche ist für Menschen gedacht. Eine API ist für die Kommunikation zwischen Programmen gedacht. --- **Client und Server** Bei einer API-Kommunikation gibt es normalerweise einen Client und einen Server. **Client** Der Client sendet eine Anfrage. Beispiele: - n8n - Webbrowser - Smartphone-App - PowerShell-Skript - Verwaltungssoftware - anderes SaaS-System **Server** Der Server verarbeitet die Anfrage und sendet eine Antwort zurück. Beispiele: - CRM-System - Google Workspace - Slack - Projektmanagement-System - Webserver - Datenbankdienst Grundablauf: Client | | Request v Server | | Response v Client > Der Client stellt eine Anfrage. Der Server verarbeitet sie und antwortet. --- **Request** Ein Request ist eine Anfrage an einen Server. Ein Request kann beispielsweise bedeuten: - Daten abrufen - neue Daten anlegen - vorhandene Daten ändern - Daten löschen - eine bestimmte Aktion ausführen Beispiel: > Rufe den Benutzer mit der ID 15 ab. Ein Request enthält häufig: - HTTP-Methode - URL beziehungsweise Endpoint - Header - Parameter - Body - Authentifizierungsinformationen --- **Response** Eine Response ist die Antwort des Servers. Sie enthält häufig: - HTTP-Statuscode - Header - Daten - Erfolgsbestätigung - Fehlermeldung Beispiel: > Benutzer wurde gefunden. Oder: > Benutzer wurde nicht gefunden. Grundprinzip: | Bestandteil | Bedeutung | |---|---| | Request | Anfrage des Clients | | Response | Antwort des Servers | | Client | sendet den Request | | Server | verarbeitet den Request | --- **Endpoint** Ein Endpoint ist eine konkrete Adresse innerhalb einer API. Beispiel: https://api.example.com/users Dieser Endpoint könnte für Benutzer zuständig sein. Weitere Beispiele: https://api.example.com/projects https://api.example.com/customers https://api.example.com/messages Ein einzelner Benutzer könnte über seine ID angesprochen werden: https://api.example.com/users/15 > Ein Endpoint ist eine konkrete API-Adresse für eine Ressource oder Funktion. --- **Ressource** Eine Ressource ist ein Objekt oder Datentyp, der über eine API verwaltet wird. Beispiele: - Benutzer - Kunde - Projekt - Aufgabe - Nachricht - Datei - Rechnung Typische Zuordnung: | Ressource | Endpoint | |---|---| | Benutzer | `/users` | | Projekte | `/projects` | | Kunden | `/customers` | | Aufgaben | `/tasks` | | Dateien | `/files` | --- **Aufbau einer API-Adresse** Beispiel: https://api.example.com/v1/users/15 Die Adresse besteht aus mehreren Teilen: | Teil | Bedeutung | |---|---| | `https://` | verwendetes Protokoll | | `api.example.com` | Server beziehungsweise Host | | `/v1` | API-Version | | `/users` | Ressource | | `/15` | ID eines bestimmten Benutzers | Die API-Version ist wichtig, weil Anbieter ihre Schnittstellen weiterentwickeln können. Beispiel: /v1/users /v2/users Eine neue Version kann andere Funktionen oder Datenstrukturen besitzen. --- **HTTP-Methode** Die HTTP-Methode beschreibt, welche Aktion ausgeführt werden soll. Typische Methoden: | Methode | Aufgabe | |---|---| | GET | Daten abrufen | | POST | neue Daten anlegen | | PUT | Daten vollständig ersetzen | | PATCH | einzelne Daten ändern | | DELETE | Daten löschen | Beispiel: GET /users/15 Bedeutung: > Rufe den Benutzer mit der ID 15 ab. Beispiel: DELETE /users/15 Bedeutung: > Lösche den Benutzer mit der ID 15. Die Methoden werden auf der nächsten Seite genauer behandelt. --- **Header** Header enthalten zusätzliche Informationen über den Request oder die Response. Typische Header: | Header | Bedeutung | |---|---| | `Authorization` | enthält Zugangstoken | | `Content-Type` | beschreibt das Datenformat | | `Accept` | beschreibt das gewünschte Antwortformat | | `User-Agent` | beschreibt den Client | Beispiel: Authorization: Bearer abc123 Content-Type: application/json Der erste Header übermittelt ein Zugangstoken. Der zweite Header teilt dem Server mit, dass die gesendeten Daten im JSON-Format vorliegen. > Header enthalten Steuerungs- und Zusatzinformationen. --- **Body** Der Body enthält die eigentlichen Nutzdaten eines Requests oder einer Response. Beispiel für einen Request-Body: { "name": "Max Mustermann", "department": "IT", "active": true } Diese Daten könnten verwendet werden, um einen Benutzer anzulegen. Nicht jeder Request benötigt einen Body. Beispiele: - Ein GET-Request besitzt häufig keinen Body. - Ein POST-Request enthält häufig neue Daten. - Ein PATCH-Request enthält häufig die zu ändernden Werte. > Der Header beschreibt die Anfrage. Der Body enthält häufig die eigentlichen Daten. --- **Path-Parameter** Ein Path-Parameter ist direkt Bestandteil des Endpoints. Beispiel: /users/15 Die Zahl `15` ist die ID eines bestimmten Benutzers. Allgemeine Schreibweise: /users/{id} Weitere Beispiele: /projects/25 /customers/107 /tasks/42 Path-Parameter werden häufig verwendet, um eine bestimmte Ressource eindeutig anzusprechen. --- **Query-Parameter** Query-Parameter stehen hinter einem Fragezeichen in der URL. Beispiel: /users?department=IT Bedeutung: > Rufe alle Benutzer aus der Abteilung IT ab. Mehrere Query-Parameter werden häufig mit `&` getrennt. Beispiel: /users?department=IT&active=true Bedeutung: > Rufe alle aktiven Benutzer aus der Abteilung IT ab. Typische Anwendungen: - Filtern - Sortieren - Suchen - Seitennavigation - Begrenzen der Ergebnisse --- **Path- und Query-Parameter im Vergleich** | Parameterart | Beispiel | Aufgabe | |---|---|---| | Path-Parameter | `/users/15` | bestimmte Ressource auswählen | | Query-Parameter | `/users?active=true` | Ergebnisse filtern oder sortieren | Merksatz: > Path-Parameter bestimmen häufig, welche Ressource gemeint ist. Query-Parameter verändern oder begrenzen die Abfrage. --- **Beispiel eines vollständigen Requests** GET https://api.example.com/v1/users/15 Authorization: Bearer abc123 Accept: application/json Bedeutung: - `GET` ruft Daten ab. - Der Endpoint verweist auf Benutzer 15. - Das Token authentifiziert den Client. - Die Antwort soll im JSON-Format zurückgegeben werden. --- **Beispiel einer erfolgreichen Response** Status: 200 OK { "id": 15, "name": "Max Mustermann", "department": "IT", "active": true } Die Response enthält: - Statuscode `200` - Erfolgsstatus `OK` - Benutzerdaten im JSON-Format --- **Beispiel einer fehlerhaften Response** Status: 404 Not Found { "error": "User not found" } Bedeutung: - Der Server wurde erreicht. - Die Anfrage wurde verarbeitet. - Der Benutzer wurde jedoch nicht gefunden. --- **Typischer API-Ablauf** 1. Der Client erstellt einen Request. 2. Der Request wird an einen Endpoint gesendet. 3. Der Server prüft die Anfrage. 4. Die Authentifizierung wird kontrolliert. 5. Die Berechtigungen werden geprüft. 6. Der Server führt die gewünschte Aktion aus. 7. Der Server erstellt eine Response. 8. Der Client wertet Statuscode und Daten aus. 9. Das Ergebnis wird weiterverarbeitet oder protokolliert. Darstellung: Client | | Request v API-Endpoint | v Authentifizierung prüfen | v Berechtigung prüfen | v Aktion ausführen | v Response erstellen | v Client --- **API-Dokumentation** Eine API-Dokumentation beschreibt, wie eine Schnittstelle verwendet wird. Sie enthält normalerweise: - verfügbare Endpoints - erlaubte HTTP-Methoden - benötigte Parameter - Datenformate - Authentifizierungsverfahren - Beispiel-Requests - Beispiel-Responses - Statuscodes - Fehlermeldungen - Rate Limits - API-Versionen Vor der Nutzung einer API sollte zuerst die offizielle Dokumentation geprüft werden. > Eine API sollte nicht durch Vermutungen verwendet werden, sondern anhand ihrer Dokumentation. --- **Authentifizierung und Autorisierung** Authentifizierung beantwortet die Frage: > Wer greift auf das System zu? Beispiele: - API-Key - Bearer-Token - OAuth 2.0 - Benutzername und Passwort Autorisierung beantwortet die Frage: > Was darf dieser Client tun? Beispiel: Ein API-Token darf Benutzer lesen, aber keine Benutzer löschen. | Begriff | Frage | |---|---| | Authentifizierung | Wer bist du? | | Autorisierung | Was darfst du? | --- **API-Schlüssel und Tokens** API-Zugangsdaten müssen sicher behandelt werden. Sie dürfen nicht: - öffentlich veröffentlicht werden - direkt in Dokumentationen stehen - unverschlüsselt weitergegeben werden - in öffentlich zugänglichen Git-Repositories gespeichert werden - in Screenshots sichtbar sein Sicherer sind: - geschützte Credential-Speicher - Umgebungsvariablen - Secret-Management-Systeme - eingeschränkte Berechtigungen - regelmäßiger Austausch der Tokens --- **Praxisbeispiel mit n8n** Ein n8n-Workflow soll einen Benutzer aus einem CRM-System abrufen. Ablauf: n8n | | GET /users/15 v CRM-API | | Response mit Benutzerdaten v n8n | v Daten prüfen und weiterverarbeiten n8n benötigt dafür: - Endpoint - HTTP-Methode - Authentifizierung - mögliche Parameter - erwartetes Antwortformat - Fehlerbehandlung --- **Mögliche Fehlerquellen** Eine API-Anfrage kann aus verschiedenen Gründen fehlschlagen. Typische Ursachen: - falscher Endpoint - falsche HTTP-Methode - ungültiges Token - fehlende Berechtigung - falscher Header - fehlerhafter JSON-Body - fehlender Pflichtparameter - falsche Benutzer-ID - nicht erreichbarer Server - veraltete API-Version - Rate Limit erreicht --- **Systematische Fehlersuche** Wenn ein API-Aufruf nicht funktioniert: 1. Ist die URL korrekt? 2. Ist der Endpoint noch gültig? 3. Wird die richtige HTTP-Methode verwendet? 4. Ist das Token gültig? 5. Sind die benötigten Berechtigungen vorhanden? 6. Sind alle Pflichtparameter enthalten? 7. Ist der `Content-Type` korrekt? 8. Ist der JSON-Body gültig? 9. Welcher Statuscode wird zurückgegeben? 10. Welche Fehlermeldung enthält die Response? 11. Funktioniert die Anfrage mit Testdaten? 12. Wurde die API-Dokumentation geprüft? --- **Wichtige Begriffe** | Begriff | Bedeutung | |---|---| | API | Schnittstelle zwischen Programmen | | Client | sendet eine Anfrage | | Server | verarbeitet die Anfrage | | Request | Anfrage | | Response | Antwort | | Endpoint | konkrete API-Adresse | | Ressource | verwaltetes Objekt, zum Beispiel Benutzer | | HTTP-Methode | beschreibt die gewünschte Aktion | | Header | zusätzliche Steuerungsinformationen | | Body | eigentliche Nutzdaten | | Path-Parameter | Teil des Endpoints | | Query-Parameter | Filter oder Zusatzangabe in der URL | | Token | Zugangsnachweis für eine API | | API-Version | Entwicklungsstand einer Schnittstelle | | API-Dokumentation | technische Beschreibung der Schnittstelle | --- **Gesamtmerksatz** > Der Client sendet einen Request an einen API-Endpoint. Der Server prüft Authentifizierung, Berechtigungen und Daten, führt die gewünschte Aktion aus und sendet anschließend eine Response zurück. --- **Kontrollfragen** **Was ist eine API?** Eine Programmierschnittstelle, über die Anwendungen Daten austauschen oder Funktionen aufrufen können. **Was ist ein Client?** Ein Programm oder System, das eine Anfrage sendet. **Was ist ein Server?** Ein System, das eine Anfrage verarbeitet und eine Antwort zurücksendet. **Was ist ein Endpoint?** Eine konkrete Adresse innerhalb einer API. **Was ist eine Ressource?** Ein Objekt, das über eine API verwaltet wird, beispielsweise ein Benutzer oder Projekt. **Was enthält ein Header?** Zusätzliche Informationen wie Datenformat, Authentifizierung oder gewünschtes Antwortformat. **Was enthält ein Body?** Die eigentlichen Nutzdaten eines Requests oder einer Response. **Was ist der Unterschied zwischen Path- und Query-Parameter?** Ein Path-Parameter identifiziert häufig eine bestimmte Ressource. Ein Query-Parameter filtert oder verändert die Abfrage. **Was ist der Unterschied zwischen Authentifizierung und Autorisierung?** Authentifizierung prüft die Identität. Autorisierung prüft die erlaubten Aktionen. --- **Quellen** - [IETF – RFC 9110: HTTP Semantics](https://datatracker.ietf.org/doc/html/rfc9110) - [MDN Web Docs – HTTP](https://developer.mozilla.org/de/docs/Web/HTTP) - [MDN Web Docs – HTTP Headers](https://developer.mozilla.org/de/docs/Web/HTTP/Headers) - [MDN Web Docs – URL Search Parameters](https://developer.mozilla.org/de/docs/Web/API/URLSearchParams) - [n8n-Dokumentation – HTTP Request Node](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.httprequest/) ``` # 2.4 REST-APIs, HTTP-Methoden und CRUD REST ist ein häufig verwendetes Prinzip für Web-APIs. REST bedeutet: > Representational State Transfer REST-APIs stellen Ressourcen über eindeutige Adressen bereit und verwenden HTTP-Methoden, um Daten zu lesen, anzulegen, zu verändern oder zu löschen. Typische Ressourcen sind: - Benutzer - Kunden - Projekte - Aufgaben - Nachrichten - Dateien --- **Lernziele** Nach dieser Seite solltest du erklären können: - was eine REST-API ist - was eine Ressource ist - welche Aufgaben GET, POST, PUT, PATCH und DELETE besitzen - was CRUD bedeutet - wie HTTP-Methoden und CRUD zusammenhängen - warum PUT und PATCH nicht dasselbe sind - was Idempotenz bedeutet - wie REST-Anfragen aufgebaut werden --- **Ressourcen in einer REST-API** Eine Ressource ist ein Objekt, das über die API verwaltet wird. Beispiele: | Ressource | Endpoint | |---|---| | Benutzer | `/users` | | Kunden | `/customers` | | Projekte | `/projects` | | Aufgaben | `/tasks` | | Dateien | `/files` | Eine einzelne Ressource wird häufig über eine ID angesprochen. Beispiel: /users/15 Bedeutung: > Benutzer mit der ID 15 --- **HTTP-Methoden** Die HTTP-Methode beschreibt, welche Aktion mit einer Ressource ausgeführt werden soll. | Methode | Aufgabe | |---|---| | GET | Daten abrufen | | POST | neue Daten anlegen | | PUT | Datensatz vollständig ersetzen | | PATCH | einzelne Werte ändern | | DELETE | Daten löschen | Die Kombination aus Methode und Endpoint bestimmt die gewünschte Aktion. Beispiel: GET /users/15 Bedeutung: > Benutzer 15 abrufen Beispiel: DELETE /users/15 Bedeutung: > Benutzer 15 löschen --- **GET – Daten lesen** GET wird verwendet, um Daten abzurufen. Beispiele: GET /users Alle Benutzer abrufen. GET /users/15 Benutzer 15 abrufen. GET /users?department=IT Alle Benutzer aus der Abteilung IT abrufen. Eine GET-Anfrage besitzt normalerweise keinen Request-Body. Mögliche Antwort: { "id": 15, "name": "Max Mustermann", "department": "IT", "active": true } > GET liest Daten und sollte keine Ressource verändern. --- **POST – Daten anlegen** POST wird häufig verwendet, um eine neue Ressource zu erstellen. Beispiel: POST /users Request-Body: { "name": "Max Mustermann", "department": "IT", "active": true } Mögliche Antwort: Status: 201 Created { "id": 15, "name": "Max Mustermann", "department": "IT", "active": true } Die ID wird häufig vom Server erzeugt. > POST erstellt normalerweise eine neue Ressource. --- **PUT – vollständig ersetzen** PUT wird verwendet, um eine bestehende Ressource vollständig zu ersetzen. Beispiel: PUT /users/15 Request-Body: { "name": "Max Mustermann", "department": "Support", "active": true } Bei PUT erwartet die API häufig den vollständigen Datensatz. Wird ein vorhandenes Feld nicht übertragen, kann es abhängig von der API entfernt oder auf einen Standardwert gesetzt werden. Beispiel: Der bisherige Benutzer besitzt zusätzlich eine Telefonnummer. Wenn diese im PUT-Request fehlt, könnte sie verloren gehen. > PUT ersetzt normalerweise die vollständige Ressource. --- **PATCH – einzelne Werte ändern** PATCH wird verwendet, um nur bestimmte Felder einer Ressource zu verändern. Beispiel: PATCH /users/15 Request-Body: { "department": "Support" } Nur die Abteilung wird geändert. Andere Werte wie Name oder Aktivstatus bleiben erhalten. > PATCH verändert einzelne Teile einer Ressource. --- **PUT und PATCH im Vergleich** | Merkmal | PUT | PATCH | |---|---|---| | Änderung | vollständiger Datensatz | einzelne Felder | | benötigte Daten | häufig alle Werte | nur geänderte Werte | | Risiko | fehlende Werte können überschrieben werden | übrige Werte bleiben erhalten | | Beispiel | komplettes Benutzerprofil ersetzen | nur Abteilung ändern | Merksatz: > PUT ersetzt vollständig. PATCH ändert teilweise. --- **DELETE – Daten löschen** DELETE wird verwendet, um eine Ressource zu entfernen. Beispiel: DELETE /users/15 Mögliche Antwort: Status: 204 No Content Der Statuscode `204` bedeutet, dass die Anfrage erfolgreich war, aber kein zusätzlicher Inhalt zurückgegeben wird. In Unternehmenssystemen werden Benutzer häufig nicht endgültig gelöscht, sondern deaktiviert. Beispiel: PATCH /users/15 { "active": false } Das kann sinnvoll sein, wenn Daten oder Protokolle erhalten bleiben müssen. > DELETE entfernt eine Ressource. In der Praxis kann eine Deaktivierung sicherer sein. --- **CRUD** CRUD beschreibt vier grundlegende Datenoperationen. CRUD bedeutet: | Buchstabe | Bedeutung | Aufgabe | |---|---|---| | C | Create | erstellen | | R | Read | lesen | | U | Update | ändern | | D | Delete | löschen | Zuordnung zu HTTP-Methoden: | CRUD | HTTP-Methode | |---|---| | Create | POST | | Read | GET | | Update | PUT oder PATCH | | Delete | DELETE | Merksatz: > CRUD beschreibt die Datenoperation. Die HTTP-Methode beschreibt die technische Anfrage. --- **Beispiel: Benutzerverwaltung** | Aufgabe | Methode | Endpoint | |---|---|---| | alle Benutzer abrufen | GET | `/users` | | bestimmten Benutzer abrufen | GET | `/users/15` | | neuen Benutzer anlegen | POST | `/users` | | Benutzer vollständig ersetzen | PUT | `/users/15` | | Benutzer teilweise ändern | PATCH | `/users/15` | | Benutzer löschen | DELETE | `/users/15` | --- **Sammlungen und einzelne Ressourcen** Ein Endpoint ohne ID bezeichnet häufig eine Sammlung. Beispiel: /users Bedeutung: > Sammlung aller Benutzer Ein Endpoint mit ID bezeichnet eine einzelne Ressource. Beispiel: /users/15 Bedeutung: > einzelner Benutzer mit der ID 15 Typische Verwendung: | Anfrage | Bedeutung | |---|---| | `GET /users` | Sammlung abrufen | | `POST /users` | neue Ressource zur Sammlung hinzufügen | | `GET /users/15` | einzelne Ressource abrufen | | `PATCH /users/15` | einzelne Ressource ändern | | `DELETE /users/15` | einzelne Ressource löschen | --- **Untergeordnete Ressourcen** Ressourcen können miteinander verbunden sein. Beispiel: GET /projects/20/tasks Bedeutung: > Alle Aufgaben des Projekts 20 abrufen Einzelne Aufgabe: GET /projects/20/tasks/5 Bedeutung: > Aufgabe 5 aus Projekt 20 abrufen Solche verschachtelten Endpoints sollten übersichtlich bleiben. --- **Filter, Sortierung und Begrenzung** Query-Parameter können eine GET-Abfrage genauer bestimmen. Filtern: GET /users?active=true Sortieren: GET /users?sort=name Begrenzen: GET /users?limit=20 Mehrere Parameter: GET /users?department=IT&active=true&limit=20 Typische Query-Parameter: | Parameter | Aufgabe | |---|---| | `active=true` | aktive Benutzer filtern | | `department=IT` | nach Abteilung filtern | | `sort=name` | Ergebnisse sortieren | | `limit=20` | Anzahl begrenzen | | `page=2` | Ergebnisseite auswählen | --- **Idempotenz** Idempotenz bedeutet: > Eine Anfrage kann mehrfach ausgeführt werden, ohne dass sich das Ergebnis nach der ersten erfolgreichen Ausführung weiter verändert. Beispiel: DELETE /users/15 Nach dem ersten erfolgreichen Löschen ist der Benutzer entfernt. Eine erneute identische Anfrage löscht nicht noch einen weiteren Benutzer. Typische Einordnung: | Methode | Normalerweise idempotent | |---|---| | GET | ja | | PUT | ja | | DELETE | ja | | POST | nein | | PATCH | abhängig von der Umsetzung | POST ist normalerweise nicht idempotent. Wird derselbe POST-Request mehrfach ausgeführt, könnten mehrere Benutzerkonten entstehen. Beispiel: POST /users Bei zweimaliger Ausführung könnten zwei Datensätze angelegt werden. --- **Doppelte Ausführungen verhindern** Automatisierte Workflows können versehentlich mehrfach gestartet werden. Mögliche Ursachen: - Webhook wird erneut gesendet - Netzwerkfehler verursacht einen Wiederholungsversuch - Benutzer startet den Workflow mehrfach - Zeitplan überschneidet sich - Antwort des Zielsystems kommt zu spät Mögliche Schutzmaßnahmen: - eindeutige Mitarbeiter- oder Vorgangs-ID prüfen - vor dem Erstellen nach vorhandenen Daten suchen - Idempotency-Key verwenden - Workflow-Ausführungen protokollieren - doppelte Trigger erkennen - POST-Anfragen nicht unkontrolliert wiederholen Beispiel: Prüfen, ob E-Mail-Adresse bereits vorhanden ist | Benutzer vorhanden? / \ ja nein | | v v abbrechen Benutzer anlegen --- **Typischer REST-Request** POST https://api.example.com/v1/users Authorization: Bearer abc123 Content-Type: application/json { "name": "Max Mustermann", "department": "IT" } Bestandteile: | Bestandteil | Inhalt | |---|---| | Methode | POST | | Endpoint | `/v1/users` | | Authentifizierung | Bearer-Token | | Datenformat | JSON | | Body | neue Benutzerdaten | --- **Typische Response** Status: 201 Created { "id": 15, "name": "Max Mustermann", "department": "IT" } Der Server bestätigt, dass die Ressource erstellt wurde. --- **REST und Zustandslosigkeit** REST-APIs sind normalerweise zustandslos. Das bedeutet: > Jede Anfrage enthält alle Informationen, die der Server für ihre Verarbeitung benötigt. Der Server sollte nicht darauf angewiesen sein, dass eine vorherige Anfrage bestimmte Informationen gespeichert hat. Beispiel: Jeder Request übermittelt erneut das benötigte Zugangstoken. Authorization: Bearer abc123 Vorteile: - Anfragen können unabhängig verarbeitet werden - Systeme lassen sich leichter skalieren - Fehler lassen sich besser eingrenzen - mehrere Server können Anfragen bearbeiten --- **Sicherheit** Besonders verändernde Methoden müssen geschützt werden. Kritische Methoden: - POST - PUT - PATCH - DELETE Wichtige Maßnahmen: - HTTPS verwenden - Benutzer authentifizieren - Berechtigungen prüfen - Eingabedaten validieren - Least Privilege verwenden - Änderungen protokollieren - Löschvorgänge absichern - Tokens nicht im Klartext speichern - Test- und Produktivsystem trennen Ein gültiges Token bedeutet nicht automatisch, dass jede Aktion erlaubt sein darf. --- **Praxisbeispiel mit n8n** Ein neuer Mitarbeiter soll im SaaS-System angelegt werden. Ablauf: 1. n8n erhält die Mitarbeiterdaten. 2. Die Daten werden geprüft. 3. Mit GET wird nach der E-Mail-Adresse gesucht. 4. Ist kein Benutzer vorhanden, wird POST verwendet. 5. Die Response wird geprüft. 6. Die neue Benutzer-ID wird gespeichert. 7. Mit PATCH können weitere Eigenschaften ergänzt werden. 8. Das Ergebnis wird protokolliert. Darstellung: Trigger | v GET /users?email=... | v Benutzer vorhanden? / \ ja nein | | v v stoppen POST /users | v Response prüfen | v Ergebnis speichern --- **Systematische Fehlersuche** Wenn eine REST-Anfrage fehlschlägt: 1. Ist die HTTP-Methode korrekt? 2. Ist der Endpoint korrekt? 3. Wird eine Sammlung oder einzelne Ressource angesprochen? 4. Sind Path- und Query-Parameter korrekt? 5. Ist der JSON-Body vollständig? 6. Wird PUT oder PATCH richtig verwendet? 7. Ist die Ressource bereits vorhanden? 8. Ist die Authentifizierung gültig? 9. Sind ausreichende Berechtigungen vorhanden? 10. Welcher HTTP-Statuscode wird zurückgegeben? 11. Enthält die Response eine Fehlermeldung? 12. Kann die Anfrage gefahrlos erneut ausgeführt werden? --- **Wichtige Begriffe** | Begriff | Bedeutung | |---|---| | REST | Prinzip zur Gestaltung von Web-APIs | | Ressource | verwaltetes Objekt | | Sammlung | Gruppe mehrerer Ressourcen | | GET | Daten abrufen | | POST | Daten erstellen | | PUT | Ressource vollständig ersetzen | | PATCH | einzelne Werte ändern | | DELETE | Ressource löschen | | CRUD | Create, Read, Update und Delete | | Idempotenz | wiederholte Anfrage verändert das Ergebnis nicht weiter | | Query-Parameter | filtern oder verändern eine Abfrage | | Zustandslosigkeit | jeder Request enthält alle benötigten Informationen | --- **Gesamtmerksatz** > REST-APIs verwalten Ressourcen über Endpoints. GET liest Daten, POST erstellt neue Daten, PUT ersetzt vollständige Datensätze, PATCH verändert einzelne Werte und DELETE entfernt Ressourcen. CRUD fasst diese grundlegenden Datenoperationen zusammen. --- **Kontrollfragen** **Was bedeutet REST?** Representational State Transfer. **Was ist eine Ressource?** Ein Objekt, das über eine API verwaltet wird, beispielsweise ein Benutzer oder Projekt. **Welche Aufgabe besitzt GET?** Daten abrufen. **Welche Aufgabe besitzt POST?** Neue Daten beziehungsweise Ressourcen erstellen. **Was ist der Unterschied zwischen PUT und PATCH?** PUT ersetzt normalerweise die vollständige Ressource. PATCH verändert nur einzelne Werte. **Was bedeutet CRUD?** Create, Read, Update und Delete. **Welche HTTP-Methode ist normalerweise nicht idempotent?** POST. **Warum können doppelte POST-Anfragen problematisch sein?** Weil dadurch mehrere identische Ressourcen erstellt werden können. **Warum sollte vor dem Anlegen eines Benutzers zunächst gesucht werden?** Damit kein doppeltes Benutzerkonto entsteht. --- **Quellen** - [IETF – RFC 9110: HTTP Semantics](https://datatracker.ietf.org/doc/html/rfc9110) - [MDN Web Docs – HTTP Request Methods](https://developer.mozilla.org/de/docs/Web/HTTP/Methods) - [MDN Web Docs – GET](https://developer.mozilla.org/de/docs/Web/HTTP/Methods/GET) - [MDN Web Docs – POST](https://developer.mozilla.org/de/docs/Web/HTTP/Methods/POST) - [MDN Web Docs – PUT](https://developer.mozilla.org/de/docs/Web/HTTP/Methods/PUT) - [MDN Web Docs – PATCH](https://developer.mozilla.org/de/docs/Web/HTTP/Methods/PATCH) - [MDN Web Docs – DELETE](https://developer.mozilla.org/de/docs/Web/HTTP/Methods/DELETE) ``` # 2.5 HTTP-Statuscodes und Fehlermeldungen HTTP-Statuscodes zeigen an, wie ein Server eine Anfrage verarbeitet hat. Der Statuscode besteht aus drei Ziffern. Beispiele: - `200` – Anfrage erfolgreich - `404` – Ressource nicht gefunden - `500` – interner Serverfehler Der Statuscode wird in der Response des Servers übertragen. Beispiel: HTTP/1.1 200 OK { "id": 15, "name": "Max Mustermann" } > Der Statuscode beschreibt das Ergebnis einer HTTP-Anfrage. --- **Lernziele** Nach dieser Seite solltest du erklären können: - wie HTTP-Statuscodes aufgebaut sind - was die Klassen 1xx bis 5xx bedeuten - was wichtige Statuscodes aussagen - wie sich 401 und 403 unterscheiden - wie Fehler in API-Workflows behandelt werden - wie HTTP-Fehler systematisch eingegrenzt werden --- **Statuscode-Klassen** Die erste Ziffer bestimmt die Statusklasse. | Klasse | Bedeutung | |---|---| | 1xx | Information | | 2xx | Anfrage erfolgreich | | 3xx | Weiterleitung | | 4xx | Fehler in der Anfrage | | 5xx | Fehler auf der Serverseite | Merksatz: > 2xx bedeutet Erfolg, 4xx bedeutet meistens Clientfehler und 5xx bedeutet Serverfehler. --- **1xx – Information** Statuscodes der Klasse 1xx zeigen an, dass die Anfrage empfangen wurde und die Verarbeitung fortgesetzt wird. Beispiele: | Code | Bedeutung | |---:|---| | 100 | Continue | | 101 | Switching Protocols | Diese Codes sind bei normalen API-Aufrufen weniger häufig sichtbar. --- **2xx – Erfolgreiche Anfrage** Statuscodes der Klasse 2xx zeigen an, dass eine Anfrage erfolgreich verarbeitet wurde. | Code | Bedeutung | Typisches Beispiel | |---:|---|---| | 200 | OK | Daten erfolgreich abgerufen | | 201 | Created | neue Ressource erstellt | | 202 | Accepted | Anfrage angenommen, Verarbeitung folgt später | | 204 | No Content | erfolgreich, aber keine Antwortdaten | --- **200 OK** `200 OK` ist ein allgemeiner Erfolgsstatus. Beispiel: GET /users/15 Mögliche Response: Status: 200 OK { "id": 15, "name": "Max Mustermann", "active": true } > Die Anfrage wurde erfolgreich verarbeitet. --- **201 Created** `201 Created` wird häufig nach dem erfolgreichen Erstellen einer Ressource zurückgegeben. Beispiel: POST /users Mögliche Response: Status: 201 Created { "id": 15, "name": "Max Mustermann" } > Eine neue Ressource wurde erfolgreich erstellt. --- **202 Accepted** `202 Accepted` bedeutet: > Die Anfrage wurde angenommen, aber noch nicht vollständig verarbeitet. Beispiel: Ein umfangreicher Datenimport wird gestartet. POST /imports Status: 202 Accepted Die Verarbeitung kann anschließend im Hintergrund des Zielsystems weiterlaufen. Der Client sollte später prüfen, ob der Vorgang abgeschlossen wurde. --- **204 No Content** `204 No Content` bedeutet: > Die Anfrage war erfolgreich, aber die Response enthält keinen Body. Typisches Beispiel: DELETE /users/15 Status: 204 No Content Der Client darf nicht automatisch erwarten, dass JSON-Daten zurückgegeben werden. --- **3xx – Weiterleitungen** Statuscodes der Klasse 3xx zeigen an, dass eine Ressource unter einer anderen Adresse erreichbar ist oder eine Weiterleitung erforderlich ist. | Code | Bedeutung | |---:|---| | 301 | Moved Permanently | | 302 | Found | | 304 | Not Modified | | 307 | Temporary Redirect | | 308 | Permanent Redirect | Bei APIs können Weiterleitungen problematisch sein, wenn der Client sie nicht unterstützt oder dabei Authentifizierungsdaten verloren gehen. --- **4xx – Fehler in der Anfrage** Statuscodes der Klasse 4xx zeigen normalerweise an, dass die Anfrage fehlerhaft ist oder nicht ausgeführt werden darf. Häufige Ursachen: - falsche Daten - fehlende Authentifizierung - fehlende Berechtigung - ungültiger Endpoint - falsche HTTP-Methode - ungültiges Datenformat - zu viele Anfragen --- **400 Bad Request** `400 Bad Request` bedeutet: > Die Anfrage ist fehlerhaft und kann nicht verarbeitet werden. Mögliche Ursachen: - ungültiges JSON - fehlender Pflichtwert - falscher Datentyp - fehlerhafte Syntax - ungültiger Parameter Beispiel: { "name": "Max Mustermann", "active": } Der Wert für `active` fehlt. Mögliche Response: Status: 400 Bad Request { "error": "Invalid request body" } --- **401 Unauthorized** `401 Unauthorized` bedeutet meistens: > Die Authentifizierung fehlt oder ist ungültig. Mögliche Ursachen: - Token fehlt - Token ist abgelaufen - API-Key ist ungültig - Zugangsdaten sind falsch - Authentifizierungsheader ist fehlerhaft Beispiel: Authorization: Bearer ungültiges-token Mögliche Response: Status: 401 Unauthorized > Der Server weiß nicht sicher, wer der Client ist. --- **403 Forbidden** `403 Forbidden` bedeutet: > Die Identität ist bekannt, aber die Aktion ist nicht erlaubt. Beispiel: Ein Token darf Benutzer lesen, aber keine Benutzer löschen. DELETE /users/15 Mögliche Response: Status: 403 Forbidden > Der Client ist authentifiziert, besitzt aber nicht die benötigte Berechtigung. --- **401 und 403 im Vergleich** | Statuscode | Bedeutung | |---:|---| | 401 | Identität fehlt oder konnte nicht bestätigt werden | | 403 | Identität ist bekannt, aber die Berechtigung fehlt | Merksatz: > 401 bedeutet: Wer bist du? > 403 bedeutet: Du bist bekannt, darfst das aber nicht. --- **404 Not Found** `404 Not Found` bedeutet: > Die angeforderte Ressource wurde nicht gefunden. Mögliche Ursachen: - falscher Endpoint - falsche ID - Ressource wurde gelöscht - API-Version ist falsch - Schreibfehler in der URL Beispiel: GET /users/99999 Mögliche Response: Status: 404 Not Found { "error": "User not found" } --- **405 Method Not Allowed** `405 Method Not Allowed` bedeutet: > Der Endpoint existiert, aber die verwendete HTTP-Methode ist dort nicht erlaubt. Beispiel: DELETE /reports Der Endpoint erlaubt möglicherweise nur GET. Mögliche Response: Status: 405 Method Not Allowed --- **409 Conflict** `409 Conflict` bedeutet: > Die Anfrage steht im Konflikt mit dem aktuellen Zustand des Systems. Beispiele: - E-Mail-Adresse existiert bereits - Benutzername ist schon vergeben - Ressource wurde zwischenzeitlich geändert - doppelter Datensatz soll erstellt werden Beispiel: POST /users { "email": "max.mustermann@example.com" } Mögliche Response: Status: 409 Conflict { "error": "Email already exists" } --- **415 Unsupported Media Type** `415 Unsupported Media Type` bedeutet: > Das übertragene Datenformat wird nicht unterstützt. Mögliche Ursache: Der Body enthält JSON, aber der Header fehlt oder ist falsch. Falsch: Content-Type: text/plain Richtig: Content-Type: application/json --- **422 Unprocessable Content** `422 Unprocessable Content` bedeutet: > Die Anfrage ist technisch lesbar, enthält aber fachlich ungültige Daten. Beispiele: - E-Mail-Adresse besitzt ein ungültiges Format - Startdatum liegt vor dem Geburtsdatum - Pflichtwert ist leer - Wert liegt außerhalb des erlaubten Bereichs Beispiel: { "email": "keine-gueltige-email" } --- **429 Too Many Requests** `429 Too Many Requests` bedeutet: > Der Client hat in kurzer Zeit zu viele Anfragen gesendet. Dies wird als Rate Limit bezeichnet. Mögliche Maßnahmen: - Wartezeit einbauen - Anzahl der Anfragen reduzieren - mehrere Datensätze gesammelt übertragen - Retry-Mechanismus verwenden - `Retry-After`-Header auswerten Beispiel: Status: 429 Too Many Requests Retry-After: 60 Bedeutung: > Vor einem neuen Versuch 60 Sekunden warten. --- **5xx – Serverfehler** Statuscodes der Klasse 5xx zeigen an, dass die Anfrage grundsätzlich empfangen wurde, aber der Server sie nicht erfolgreich verarbeiten konnte. Mögliche Ursachen: - interner Softwarefehler - Datenbank nicht erreichbar - überlasteter Server - abhängiger Dienst ausgefallen - Wartungsarbeiten - Gateway- oder Proxyfehler --- **500 Internal Server Error** `500 Internal Server Error` ist ein allgemeiner Serverfehler. Mögliche Ursachen: - Programmfehler - fehlerhafte Serverkonfiguration - Datenbankfehler - nicht behandelter Ausnahmefall Der Client kann die Ursache meistens nicht direkt beheben. --- **502 Bad Gateway** `502 Bad Gateway` bedeutet: > Ein Gateway oder Proxy hat von einem nachgelagerten System eine ungültige Antwort erhalten. Beispiel: Client | v Reverse Proxy | v Anwendung nicht erreichbar Mögliche Ursachen: - Zielcontainer ist gestoppt - falscher interner Port - falscher DNS-Name - Anwendung antwortet fehlerhaft - Proxy-Konfiguration ist falsch --- **503 Service Unavailable** `503 Service Unavailable` bedeutet: > Der Dienst ist vorübergehend nicht verfügbar. Mögliche Ursachen: - Wartung - Überlastung - Serverstart - abhängiger Dienst nicht verfügbar - zu wenige Ressourcen Ein späterer erneuter Versuch kann erfolgreich sein. --- **504 Gateway Timeout** `504 Gateway Timeout` bedeutet: > Ein Gateway oder Proxy hat nicht rechtzeitig eine Antwort vom Zielsystem erhalten. Mögliche Ursachen: - Zielsystem reagiert zu langsam - Datenbankabfrage dauert zu lange - Netzwerkproblem - Timeout-Wert ist zu niedrig - Anwendung hängt --- **Wichtige Statuscodes im Überblick** | Code | Bedeutung | Typische Ursache | |---:|---|---| | 200 | OK | Anfrage erfolgreich | | 201 | Created | Ressource erstellt | | 202 | Accepted | Verarbeitung erfolgt später | | 204 | No Content | erfolgreich ohne Body | | 400 | Bad Request | fehlerhafte Anfrage | | 401 | Unauthorized | Authentifizierung fehlt | | 403 | Forbidden | Berechtigung fehlt | | 404 | Not Found | Ressource nicht gefunden | | 405 | Method Not Allowed | falsche HTTP-Methode | | 409 | Conflict | Datensatzkonflikt | | 415 | Unsupported Media Type | falsches Datenformat | | 422 | Unprocessable Content | fachlich ungültige Daten | | 429 | Too Many Requests | Rate Limit erreicht | | 500 | Internal Server Error | allgemeiner Serverfehler | | 502 | Bad Gateway | nachgelagerter Dienst fehlerhaft | | 503 | Service Unavailable | Dienst vorübergehend nicht verfügbar | | 504 | Gateway Timeout | Zielsystem antwortet zu langsam | --- **HTTP-Fehler und Netzwerkfehler** Nicht jeder Fehler besitzt einen HTTP-Statuscode. Ein HTTP-Statuscode kann nur empfangen werden, wenn der Client den Server erreicht und eine HTTP-Response zurückkommt. Beispiele ohne HTTP-Statuscode: - DNS-Auflösung schlägt fehl - Netzwerkverbindung besteht nicht - Port ist geschlossen - TLS-Zertifikat ist ungültig - Verbindung wird zurückgesetzt - Timeout ohne Serverantwort Unterschied: | Fehlerart | Beispiel | |---|---| | HTTP-Fehler | Server antwortet mit `404` | | Netzwerkfehler | Server ist nicht erreichbar | | DNS-Fehler | Hostname kann nicht aufgelöst werden | | TLS-Fehler | Zertifikat wird nicht akzeptiert | > Keine Response bedeutet auch keinen HTTP-Statuscode. --- **Response-Body auswerten** Der Statuscode zeigt nur die allgemeine Fehlerklasse. Der Response-Body enthält häufig genauere Informationen. Beispiel: Status: 400 Bad Request { "error": "Missing required field", "field": "email" } Für die Fehlersuche sollten geprüft werden: - Statuscode - Fehlermeldung - betroffenes Feld - Zeitpunkt - Request-ID - Endpoint - verwendete Methode --- **Fehlerbehandlung in n8n** Ein Workflow sollte nicht nur prüfen, ob eine Node ausgeführt wurde. Er sollte auch bewerten: - welcher Statuscode zurückgegeben wurde - ob erwartete Daten vorhanden sind - ob ein erneuter Versuch sinnvoll ist - ob der Fehler dauerhaft oder vorübergehend ist - ob ein Administrator informiert werden muss Beispiel: API-Anfrage | v Statuscode prüfen / | \ 2xx 4xx 5xx | | | v v v weiter Fehler Retry melden und melden --- **Dauerhafte und vorübergehende Fehler** | Fehler | Typische Behandlung | |---|---| | 400 | Request korrigieren | | 401 | Token oder Anmeldung prüfen | | 403 | Berechtigungen prüfen | | 404 | Endpoint oder ID prüfen | | 409 | vorhandene Ressource prüfen | | 429 | warten und erneut versuchen | | 500 | Fehler protokollieren und melden | | 503 | später erneut versuchen | | 504 | Timeout und Zielsystem prüfen | Nicht jeder Fehler sollte automatisch wiederholt werden. Beispiel: Ein `400 Bad Request` wird durch denselben unveränderten Request nicht behoben. Ein `503 Service Unavailable` kann nach einer Wartezeit verschwinden. --- **Retry** Retry bedeutet: > Eine fehlgeschlagene Anfrage wird erneut ausgeführt. Retry ist sinnvoll bei vorübergehenden Fehlern: - `429 Too Many Requests` - `502 Bad Gateway` - `503 Service Unavailable` - `504 Gateway Timeout` - kurzfristigem Netzwerkfehler Retry ist normalerweise nicht sinnvoll bei: - `400 Bad Request` - `401 Unauthorized` - `403 Forbidden` - `404 Not Found` Diese Fehler benötigen zuerst eine Änderung an Anfrage, Zugang oder Berechtigung. --- **Wartezeit zwischen Wiederholungen** Anfragen sollten nicht sofort unbegrenzt wiederholt werden. Beispiel: 1. Versuch sofort 2. Versuch nach 5 Sekunden 3. Versuch nach 15 Sekunden 4. Versuch nach 30 Sekunden 5. anschließend Administrator informieren Eine schrittweise steigende Wartezeit wird als Backoff bezeichnet. Vorteile: - Zielsystem wird nicht zusätzlich überlastet - Rate Limits werden berücksichtigt - kurzfristige Störungen können sich beheben - Endlosschleifen werden vermieden --- **Logging** Bei einem Fehler sollten mindestens folgende Informationen protokolliert werden: - Zeitpunkt - Workflow - betroffener Schritt - HTTP-Methode - Endpoint - Statuscode - Fehlermeldung - betroffene Ressource - Anzahl der Versuche - Ergebnis der Fehlerbehandlung Geheime Daten dürfen nicht vollständig im Log gespeichert werden. Nicht protokollieren: - Passwörter - vollständige API-Keys - vollständige Bearer-Tokens - vertrauliche personenbezogene Daten --- **Praxisbeispiel: Benutzer anlegen** Ein n8n-Workflow sendet: POST /users Mögliche Ergebnisse: | Status | Bedeutung | Reaktion | |---:|---|---| | 201 | Benutzer erstellt | Workflow fortsetzen | | 400 | Daten fehlerhaft | Eingabedaten prüfen | | 401 | Token ungültig | Zugangsdaten prüfen | | 403 | keine Berechtigung | API-Rechte prüfen | | 409 | Benutzer existiert bereits | vorhandenen Benutzer suchen | | 429 | zu viele Anfragen | warten und erneut versuchen | | 503 | Dienst nicht verfügbar | später erneut versuchen | --- **Systematische Fehlersuche** Wenn eine API-Anfrage fehlschlägt: 1. Wurde überhaupt eine HTTP-Response empfangen? 2. Welcher Statuscode wurde zurückgegeben? 3. Welche Fehlermeldung steht im Response-Body? 4. Ist der Endpoint korrekt? 5. Ist die HTTP-Methode korrekt? 6. Ist der Request-Body gültig? 7. Ist der `Content-Type` korrekt? 8. Ist das Token vorhanden und gültig? 9. Besitzt das Konto ausreichende Rechte? 10. Existiert die angeforderte Ressource? 11. Wurde ein Rate Limit erreicht? 12. Ist der Fehler dauerhaft oder vorübergehend? 13. Kann der Request sicher erneut ausgeführt werden? 14. Muss ein Administrator informiert werden? --- **Wichtige Begriffe** | Begriff | Bedeutung | |---|---| | Statuscode | Ergebnis einer HTTP-Anfrage | | 2xx | erfolgreiche Verarbeitung | | 3xx | Weiterleitung | | 4xx | Fehler in der Anfrage | | 5xx | Fehler auf der Serverseite | | Rate Limit | Begrenzung der Anzahl von Anfragen | | Retry | erneuter Ausführungsversuch | | Backoff | steigende Wartezeit zwischen Versuchen | | Response-Body | zusätzliche Antwort- oder Fehlerdaten | | Timeout | Antwort wurde nicht rechtzeitig empfangen | | Gateway | vermittelndes System zwischen Client und Server | --- **Gesamtmerksatz** > HTTP-Statuscodes zeigen das Ergebnis einer Anfrage. 2xx steht für Erfolg, 4xx für Fehler in Anfrage, Authentifizierung oder Berechtigung und 5xx für Fehler auf der Serverseite. Für eine saubere Fehlerbehandlung müssen Statuscode, Response-Body, Wiederholbarkeit und Logs gemeinsam ausgewertet werden. --- **Kontrollfragen** **Was bedeutet ein Statuscode der Klasse 2xx?** Die Anfrage wurde erfolgreich verarbeitet. **Was ist der Unterschied zwischen 401 und 403?** Bei 401 fehlt eine gültige Authentifizierung. Bei 403 ist der Client bekannt, besitzt aber nicht die benötigte Berechtigung. **Was bedeutet 404?** Die angeforderte Ressource wurde nicht gefunden. **Was bedeutet 409?** Die Anfrage steht im Konflikt mit dem aktuellen Zustand des Systems. **Was bedeutet 429?** Der Client hat zu viele Anfragen gesendet und ein Rate Limit erreicht. **Was bedeutet 500?** Auf dem Server ist ein interner Fehler aufgetreten. **Was bedeutet 503?** Der Dienst ist vorübergehend nicht verfügbar. **Wann ist ein Retry sinnvoll?** Bei vorübergehenden Fehlern wie 429, 502, 503, 504 oder kurzfristigen Netzwerkproblemen. **Warum sollte ein 400-Fehler nicht unverändert wiederholt werden?** Weil die Anfrage selbst fehlerhaft ist und zuerst korrigiert werden muss. **Warum muss zusätzlich zum Statuscode der Response-Body geprüft werden?** Weil er häufig genauere Informationen über Ursache und betroffenes Feld enthält. --- **Quellen** - [IETF – RFC 9110: HTTP Semantics](https://datatracker.ietf.org/doc/html/rfc9110) - [MDN Web Docs – HTTP-Statuscodes](https://developer.mozilla.org/de/docs/Web/HTTP/Status) - [MDN Web Docs – 401 Unauthorized](https://developer.mozilla.org/de/docs/Web/HTTP/Status/401) - [MDN Web Docs – 403 Forbidden](https://developer.mozilla.org/de/docs/Web/HTTP/Status/403) - [MDN Web Docs – 429 Too Many Requests](https://developer.mozilla.org/de/docs/Web/HTTP/Status/429) - [n8n-Dokumentation – Error Handling](https://docs.n8n.io/flow-logic/error-handling/) ``` # 2.6 JSON – Aufbau und Verarbeitung strukturierter Daten JSON ist ein häufig verwendetes Datenformat für APIs und Automatisierungen. JSON bedeutet: > JavaScript Object Notation JSON ist textbasiert und kann von Menschen gelesen sowie von Programmen verarbeitet werden. Typische Einsatzbereiche: - API-Requests und Responses - Webhooks - n8n-Workflows - Konfigurationsdateien - Datenaustausch zwischen SaaS-Systemen - Speicherung strukturierter Informationen --- **Lernziele** Nach dieser Seite solltest du erklären können: - was JSON ist - wie Objekte und Arrays aufgebaut sind - welche Datentypen JSON unterstützt - was Schlüssel-Wert-Paare sind - wie verschachtelte Daten gelesen werden - worin sich `null`, leere Werte und fehlende Felder unterscheiden - wie JSON in APIs und n8n verwendet wird - wie JSON-Fehler erkannt werden --- **Grundaufbau** JSON speichert Daten als Schlüssel-Wert-Paare. Beispiel: { "name": "Max Mustermann", "department": "IT", "active": true } Die Schlüssel sind: - `name` - `department` - `active` Die zugehörigen Werte sind: - `"Max Mustermann"` - `"IT"` - `true` > Ein Schlüssel beschreibt eine Information. Der Wert enthält die dazugehörigen Daten. --- **JSON-Objekt** Ein JSON-Objekt wird mit geschweiften Klammern dargestellt: { "name": "Max Mustermann", "email": "max.mustermann@example.com" } Ein Objekt enthält: - Schlüssel - Doppelpunkt - Wert - Komma zwischen mehreren Einträgen Grundaufbau: { "schluessel": "wert" } Mehrere Werte: { "name": "Max Mustermann", "department": "IT", "active": true } --- **Schlüssel** JSON-Schlüssel müssen in doppelten Anführungszeichen stehen. Richtig: { "name": "Max Mustermann" } Falsch: { name: "Max Mustermann" } Falsch: { 'name': 'Max Mustermann' } JSON verwendet doppelte Anführungszeichen. > Schlüssel und Textwerte stehen in JSON in doppelten Anführungszeichen. --- **Unterstützte Datentypen** JSON unterstützt folgende Datentypen: | Datentyp | Beispiel | |---|---| | String | `"Max Mustermann"` | | Zahl | `25` | | Boolean | `true` oder `false` | | Objekt | `{ "department": "IT" }` | | Array | `["Slack", "Zoho", "Asana"]` | | Null | `null` | JSON besitzt keinen eigenen Datentyp für: - Datum - Uhrzeit - Datei - Kommentar - Funktion - undefinierten Wert Solche Werte werden meistens als Text übertragen. Beispiel für ein Datum: { "startDate": "2026-08-03" } --- **String** Ein String ist ein Textwert. Beispiel: { "name": "Max Mustermann" } Auch Zahlen können als Text gespeichert werden: { "employeeNumber": "0015" } Die Anführungszeichen sind wichtig. Unterschied: { "value": 15 } `15` ist eine Zahl. { "value": "15" } `"15"` ist Text. --- **Zahl** Zahlen stehen ohne Anführungszeichen. Beispiel: { "age": 30, "licenseCount": 25, "price": 19.99 } Mit Zahlen können Programme Berechnungen durchführen. Eine als String gespeicherte Zahl muss möglicherweise zuerst umgewandelt werden. --- **Boolean** Ein Boolean besitzt nur zwei mögliche Werte: - `true` - `false` Beispiel: { "active": true, "administrator": false } Boolean-Werte stehen ohne Anführungszeichen. Richtig: { "active": true } Falsch: { "active": "true" } `"true"` wäre ein Textwert und kein Boolean. --- **Null** `null` bedeutet: > Für dieses Feld ist aktuell kein Wert vorhanden. Beispiel: { "phone": null } `null` ist nicht dasselbe wie ein leerer String. | Wert | Bedeutung | |---|---| | `null` | kein Wert vorhanden | | `""` | leerer Text | | `0` | Zahlenwert null | | `false` | Boolean-Wert falsch | | Feld fehlt | Information wurde nicht übertragen | Beispiel: { "phone": null } Das Feld ist vorhanden, besitzt aber keinen Wert. Beispiel: { "phone": "" } Das Feld enthält einen leeren Text. --- **JSON-Array** Ein Array ist eine geordnete Liste von Werten. Arrays werden mit eckigen Klammern dargestellt. Beispiel: { "systems": [ "Google Workspace", "Slack", "Zoho CRM" ] } Ein Array kann enthalten: - Texte - Zahlen - Boolean-Werte - Objekte - weitere Arrays > Ein Objekt enthält benannte Eigenschaften. Ein Array enthält eine Liste von Elementen. --- **Array mit Objekten** APIs übertragen häufig mehrere Datensätze als Array. Beispiel: { "users": [ { "id": 15, "name": "Max Mustermann" }, { "id": 16, "name": "Anna Beispiel" } ] } Das Array `users` enthält zwei Benutzerobjekte. --- **Verschachtelte Objekte** Ein JSON-Objekt kann weitere Objekte enthalten. Beispiel: { "name": "Max Mustermann", "department": { "id": 3, "name": "IT" } } Das Objekt `department` enthält: - `id` - `name` Zugriffspfad: department.name Ergebnis: IT --- **Objekte und Arrays kombiniert** JSON-Daten können komplex verschachtelt sein. Beispiel: { "name": "Max Mustermann", "department": "IT", "roles": [ "support", "user" ], "devices": [ { "type": "Laptop", "status": "assigned" }, { "type": "Smartphone", "status": "ordered" } ] } Enthalten sind: - Strings - ein Array mit Rollen - ein Array mit Geräteobjekten --- **Kommas und Klammern** Mehrere Einträge werden durch Kommas getrennt. Richtig: { "name": "Max Mustermann", "active": true } Falsch: { "name": "Max Mustermann" "active": true } Nach dem letzten Eintrag darf in strengem JSON kein Komma stehen. Falsch: { "name": "Max Mustermann", "active": true, } Klammern müssen korrekt geschlossen werden: - `{ }` für Objekte - `[ ]` für Arrays --- **Kommentare** JSON unterstützt keine Kommentare. Falsch: { "active": true, // Benutzer ist aktiviert "department": "IT" } Zusätzliche Hinweise müssen als eigenes Feld gespeichert werden: { "active": true, "comment": "Benutzer ist aktiviert", "department": "IT" } --- **Sonderzeichen** Sonderzeichen können mit einem Backslash maskiert werden. Beispiele: | Zeichen | Schreibweise | |---|---| | Anführungszeichen | `\"` | | Backslash | `\\` | | Zeilenumbruch | `\n` | | Tabulator | `\t` | Beispiel: { "message": "Der Benutzer \"Max Mustermann\" wurde angelegt." } --- **JSON in einem API-Request** Ein neuer Benutzer soll angelegt werden. Request: POST /users Content-Type: application/json { "name": "Max Mustermann", "email": "max.mustermann@example.com", "department": "IT", "active": true } Der Header teilt dem Server mit: > Der Request-Body enthält JSON-Daten. --- **JSON in einer API-Response** Mögliche Antwort: Status: 201 Created { "id": 15, "name": "Max Mustermann", "email": "max.mustermann@example.com", "department": "IT", "active": true } Die API ergänzt hier die neue Benutzer-ID. --- **Erfolgs- und Fehlerantwort** Erfolgreiche Response: { "success": true, "userId": 15 } Fehlerhafte Response: { "success": false, "error": { "code": "EMAIL_ALREADY_EXISTS", "message": "Die E-Mail-Adresse ist bereits vorhanden." } } Ein Workflow sollte nicht nur den Statuscode, sondern auch die enthaltenen Daten auswerten. --- **Datenmapping** Datenmapping bedeutet: > Ein Wert aus einem System wird einem passenden Feld in einem anderen System zugeordnet. Beispiel: | Personalsystem | Google Workspace | |---|---| | `firstName` | `givenName` | | `lastName` | `familyName` | | `mail` | `primaryEmail` | | `department` | `organization.department` | Beispieldaten aus dem Quellsystem: { "firstName": "Max", "lastName": "Mustermann", "mail": "max.mustermann@example.com" } Benötigte Struktur im Zielsystem: { "givenName": "Max", "familyName": "Mustermann", "primaryEmail": "max.mustermann@example.com" } Die Werte bleiben gleich, aber die Feldnamen unterscheiden sich. --- **JSON in n8n** In n8n werden Daten zwischen Nodes meistens als JSON-Objekte übertragen. Beispiel: { "name": "Max Mustermann", "department": "IT", "active": true } Auf einzelne Werte kann über Ausdrücke zugegriffen werden. Beispiel: {{$json.name}} Ergebnis: Max Mustermann Beispiel: {{$json.department}} Ergebnis: IT Bei verschachtelten Daten: {{$json.department.name}} --- **Mehrere Datensätze in n8n** n8n verarbeitet häufig mehrere Items. Beispiel: [ { "name": "Max Mustermann", "department": "IT" }, { "name": "Anna Beispiel", "department": "Vertrieb" } ] Jedes Objekt kann als eigenes Workflow-Item verarbeitet werden. Beispiel: - für jeden Benutzer ein Konto anlegen - für jeden Kunden ein Projekt erstellen - für jede Rechnung einen Prüfprozess starten --- **Datenvalidierung** Vor der Verarbeitung sollten JSON-Daten geprüft werden. Beispiel für Pflichtfelder: - Name vorhanden - E-Mail-Adresse vorhanden - Abteilung vorhanden - Startdatum gültig - Aktivstatus besitzt Boolean-Wert Beispielablauf: JSON empfangen | v Pflichtfelder prüfen | v Datentypen prüfen | v Daten gültig? / \ ja nein | | v v weiter Fehler melden --- **Schema** Ein JSON-Schema kann beschreiben: - welche Felder erlaubt sind - welche Felder verpflichtend sind - welche Datentypen erwartet werden - welche Werte zulässig sind - wie Objekte verschachtelt sind Beispielanforderung: | Feld | Datentyp | Pflichtfeld | |---|---|---| | `name` | String | ja | | `email` | String | ja | | `department` | String | ja | | `active` | Boolean | nein | Ein Schema hilft dabei, fehlerhafte Daten frühzeitig zu erkennen. --- **Typische JSON-Fehler** Häufige Fehler: - einfache statt doppelte Anführungszeichen - fehlendes Komma - zusätzliches Komma am Ende - nicht geschlossene Klammer - Schlüssel ohne Anführungszeichen - ungültiger Boolean-Wert - Kommentar im JSON - falscher Datentyp - ungültiges Sonderzeichen - falsche Verschachtelung --- **Fehlerbeispiel** Ungültig: { name: 'Max Mustermann', "active": "true", } Fehler: - Schlüssel `name` besitzt keine Anführungszeichen - einfache Anführungszeichen werden verwendet - Boolean wurde als String gespeichert - zusätzliches Komma am Ende Korrekt: { "name": "Max Mustermann", "active": true } --- **Falscher Datentyp** Eine API erwartet: { "licenseCount": 15 } Gesendet wird: { "licenseCount": "fünfzehn" } Die JSON-Syntax ist gültig, aber der Inhalt besitzt den falschen Datentyp. Mögliche Response: Status: 422 Unprocessable Content > Gültiges JSON bedeutet nicht automatisch gültige Fachdaten. --- **Fehlendes und leeres Feld** Beispiel mit leerem Wert: { "email": "" } Beispiel mit `null`: { "email": null } Beispiel ohne Feld: { "name": "Max Mustermann" } Diese Varianten können von einer API unterschiedlich behandelt werden. Die API-Dokumentation muss deshalb geprüft werden. --- **Sicherheit und Datenschutz** JSON kann vertrauliche Daten enthalten. Beispiele: - personenbezogene Daten - Kundendaten - Zugangstoken - interne IDs - Zahlungsinformationen JSON-Daten sollten daher: - nur verschlüsselt übertragen werden - nur benötigte Felder enthalten - nicht unkontrolliert protokolliert werden - nicht öffentlich gespeichert werden - nach dem Least-Privilege-Prinzip verarbeitet werden Nicht vollständig protokollieren: { "password": "geheimes-passwort", "accessToken": "vollstaendiges-token" } Geheimnisse sollten maskiert werden: { "accessToken": "***" } --- **Systematische Fehlersuche** Wenn JSON nicht verarbeitet wird: 1. Sind alle Klammern korrekt geschlossen? 2. Werden doppelte Anführungszeichen verwendet? 3. Sind alle Einträge durch Kommas getrennt? 4. Befindet sich nach dem letzten Eintrag ein zusätzliches Komma? 5. Sind die Datentypen korrekt? 6. Sind alle Pflichtfelder vorhanden? 7. Entspricht die Verschachtelung der API-Dokumentation? 8. Ist der Header `Content-Type: application/json` gesetzt? 9. Enthält die Response eine genaue Fehlermeldung? 10. Ist das JSON syntaktisch gültig, aber fachlich falsch? --- **Wichtige Begriffe** | Begriff | Bedeutung | |---|---| | JSON | textbasiertes Format für strukturierte Daten | | Objekt | Sammlung von Schlüssel-Wert-Paaren | | Array | geordnete Liste von Werten | | Schlüssel | Name einer Information | | Wert | Inhalt eines Feldes | | String | Textwert | | Boolean | `true` oder `false` | | Null | kein vorhandener Wert | | Verschachtelung | Objekt oder Array innerhalb eines anderen Objekts | | Datenmapping | Zuordnung von Feldern zwischen Systemen | | Validierung | Prüfung von Struktur und Inhalt | | JSON-Schema | Beschreibung der erwarteten Datenstruktur | --- **Gesamtmerksatz** > JSON überträgt strukturierte Daten als Objekte, Arrays und Schlüssel-Wert-Paare. APIs und Automatisierungsplattformen verwenden JSON für Requests, Responses und Webhooks. Neben der korrekten Syntax müssen auch Datentypen, Pflichtfelder, Verschachtelung und Datenschutz geprüft werden. --- **Kontrollfragen** **Was bedeutet JSON?** JavaScript Object Notation. **Wie wird ein JSON-Objekt dargestellt?** Mit geschweiften Klammern. **Wie wird ein JSON-Array dargestellt?** Mit eckigen Klammern. **Welche Anführungszeichen verwendet JSON?** Doppelte Anführungszeichen. **Was ist ein Schlüssel-Wert-Paar?** Ein Schlüssel beschreibt eine Information und der Wert enthält die dazugehörigen Daten. **Was ist der Unterschied zwischen `true` und `"true"`?** `true` ist ein Boolean. `"true"` ist ein String. **Was bedeutet `null`?** Für das Feld ist aktuell kein Wert vorhanden. **Was bedeutet Datenmapping?** Felder eines Quellsystems werden passenden Feldern eines Zielsystems zugeordnet. **Warum kann syntaktisch gültiges JSON trotzdem abgelehnt werden?** Weil Pflichtfelder, Datentypen oder fachliche Werte falsch sein können. **Warum sollten Tokens nicht vollständig protokolliert werden?** Weil sie vertrauliche Zugangsdaten darstellen. --- **Quellen** - [IETF – RFC 8259: The JavaScript Object Notation Data Interchange Format](https://datatracker.ietf.org/doc/html/rfc8259) - [MDN Web Docs – JSON](https://developer.mozilla.org/de/docs/Learn_web_development/Core/Scripting/JSON) - [JSON Schema](https://json-schema.org/) - [n8n-Dokumentation – Data Structure](https://docs.n8n.io/data/data-structure/) - [n8n-Dokumentation – Expressions](https://docs.n8n.io/code/expressions/) ``` # 2.7 API-Authentifizierung – API-Key, Bearer-Token und OAuth 2.0 APIs dürfen häufig nicht ohne Zugangskontrolle verwendet werden. Die API muss prüfen: - wer die Anfrage sendet - ob der Zugang gültig ist - welche Aktionen erlaubt sind - auf welche Daten zugegriffen werden darf Dafür werden unter anderem API-Keys, Bearer-Tokens und OAuth 2.0 verwendet. --- **Lernziele** Nach dieser Seite solltest du erklären können: - was Authentifizierung und Autorisierung unterscheiden - wie ein API-Key funktioniert - was ein Bearer-Token ist - wie OAuth 2.0 grundsätzlich arbeitet - was Access Token, Refresh Token und Scope bedeuten - warum API-Zugangsdaten geschützt werden müssen - wie typische Authentifizierungsfehler erkannt werden --- **Authentifizierung und Autorisierung** Authentifizierung beantwortet die Frage: > Wer greift auf das System zu? Autorisierung beantwortet die Frage: > Was darf dieser Benutzer oder dieses Programm tun? | Begriff | Bedeutung | |---|---| | Authentifizierung | Identität überprüfen | | Autorisierung | erlaubte Aktionen und Zugriffe prüfen | Beispiel: Ein n8n-Workflow besitzt ein gültiges Token und ist damit authentifiziert. Das Token darf Benutzer lesen, aber keine Benutzer löschen. Der Workflow ist für das Lesen autorisiert, aber nicht für das Löschen. --- **API-Key** Ein API-Key ist ein geheimer Schlüssel, der einem Benutzer, Programm oder Projekt zugeordnet wird. Beispiel: X-API-Key: abc123 Der Server prüft, ob der Schlüssel gültig ist. Möglicher Ablauf: Client | | Request mit API-Key v API | v API-Key prüfen | v Anfrage erlauben oder ablehnen API-Keys werden häufig verwendet für: - einfache Systemintegrationen - interne Anwendungen - technische Dienste - automatisierte Workflows - begrenzte API-Zugriffe --- **Übertragung eines API-Keys** Ein API-Key kann abhängig von der API unterschiedlich übertragen werden. Als Header: X-API-Key: abc123 Als Authorization-Header: Authorization: ApiKey abc123 Manche APIs erlauben den Schlüssel als Query-Parameter: https://api.example.com/users?api_key=abc123 Diese Variante sollte möglichst vermieden werden, da URLs beispielsweise in Logs oder Browser-Verläufen gespeichert werden können. > Zugangsdaten sollten bevorzugt in einem geschützten HTTP-Header übertragen werden. --- **Vorteile und Nachteile von API-Keys** | Vorteile | Nachteile | |---|---| | einfach einzurichten | Schlüssel kann kopiert werden | | gut für technische Dienste | häufig keine Benutzeranmeldung | | leicht in Automatisierungen nutzbar | teilweise grobe Berechtigungen | | geringer technischer Aufwand | muss manuell ausgetauscht werden | Ein API-Key sollte nur die tatsächlich benötigten Rechte besitzen. --- **Bearer-Token** Ein Bearer-Token ist ein Zugangstoken, das im Authorization-Header übertragen wird. Beispiel: Authorization: Bearer eyJhbGciOi... `Bearer` bedeutet sinngemäß: > Der Besitzer dieses Tokens darf es verwenden. Wer das Token besitzt, kann damit normalerweise die zugehörigen Berechtigungen nutzen. Deshalb muss es wie ein Passwort geschützt werden. --- **Beispiel mit Bearer-Token** Request: GET /users/15 Authorization: Bearer abc123 Accept: application/json Der Server prüft: 1. Ist das Token vorhanden? 2. Ist das Token gültig? 3. Ist es noch nicht abgelaufen? 4. Besitzt es den benötigten Scope? 5. Darf es Benutzerinformationen lesen? --- **Token und API-Key im Vergleich** | Merkmal | API-Key | Bearer-Token | |---|---|---| | Zweck | Anwendung oder Projekt identifizieren | Zugriff auf geschützte Ressourcen erlauben | | Ablaufzeit | häufig langfristig | häufig zeitlich begrenzt | | Berechtigungen | teilweise allgemein | häufig über Scopes begrenzt | | Ausstellung | meist manuell | häufig über einen Anmeldeprozess | | Verwendung | technische Integrationen | Benutzer- und Anwendungszugriffe | Die genaue Umsetzung hängt von der jeweiligen API ab. --- **OAuth 2.0** OAuth 2.0 ist ein Verfahren zur kontrollierten Zugriffsfreigabe. Eine Anwendung kann damit Zugriff auf ein anderes System erhalten, ohne das Passwort des Benutzers dauerhaft zu speichern. Beispiel: > n8n darf auf ausgewählte Funktionen von Google Workspace zugreifen. Dabei wird festgelegt: - welche Anwendung zugreifen darf - welcher Benutzer oder Administrator zustimmt - welche Berechtigungen erlaubt sind - wie lange der Zugriff gültig ist --- **Beteiligte Rollen bei OAuth 2.0** | Rolle | Aufgabe | |---|---| | Resource Owner | besitzt die Daten oder erteilt die Freigabe | | Client | Anwendung, die Zugriff erhalten möchte | | Authorization Server | prüft Anmeldung und erteilt Tokens | | Resource Server | stellt die geschützte API bereit | Beispiel: | OAuth-Rolle | Mögliches System | |---|---| | Resource Owner | Benutzer oder Administrator | | Client | n8n | | Authorization Server | Google-Anmeldedienst | | Resource Server | Google-Workspace-API | --- **Vereinfachter OAuth-Ablauf** n8n fordert Zugriff an | v Benutzer meldet sich an | v Berechtigungen werden angezeigt | v Benutzer oder Administrator stimmt zu | v Authorization Server erstellt Token | v n8n verwendet Token für API-Anfragen Das Passwort wird nicht direkt an n8n übergeben. --- **Access Token** Ein Access Token erlaubt den Zugriff auf eine API. Beispiel: Authorization: Bearer ACCESS_TOKEN Access Tokens sind häufig nur begrenzte Zeit gültig. Mögliche Gültigkeit: - wenige Minuten - eine Stunde - mehrere Stunden Nach Ablauf wird das Token abgelehnt. Mögliche Response: Status: 401 Unauthorized --- **Refresh Token** Ein Refresh Token kann verwendet werden, um ein neues Access Token anzufordern. Ablauf: Access Token abgelaufen | v Refresh Token verwenden | v neues Access Token erhalten | v API-Anfrage erneut senden Refresh Tokens sind besonders schützenswert, weil sie längerfristigen Zugang ermöglichen können. > Access Tokens werden für API-Aufrufe verwendet. Refresh Tokens können neue Access Tokens anfordern. --- **Scopes** Ein Scope legt fest, welche Berechtigungen ein Token besitzt. Beispiele: | Scope | Bedeutung | |---|---| | `users.read` | Benutzer lesen | | `users.write` | Benutzer erstellen oder ändern | | `projects.read` | Projekte lesen | | `messages.send` | Nachrichten senden | Ein Token mit: users.read darf möglicherweise Benutzer abrufen, aber nicht löschen oder verändern. Scopes unterstützen das Least-Privilege-Prinzip. > Ein Token sollte nur die Scopes erhalten, die für seine Aufgabe erforderlich sind. --- **Client ID und Client Secret** Bei OAuth erhält eine Anwendung häufig: - Client ID - Client Secret **Client ID** Identifiziert die Anwendung. **Client Secret** Dient als geheimer Nachweis der Anwendung. Das Client Secret darf nicht öffentlich gespeichert werden. Beispiel: Client ID: workflow-application-123 Client Secret: *** --- **OAuth ist keine Anmeldungsmethode allein** OAuth 2.0 regelt hauptsächlich die Zugriffsfreigabe. Für eine vollständige Benutzeranmeldung wird häufig OpenID Connect zusätzlich verwendet. Vereinfacht: | Verfahren | Hauptaufgabe | |---|---| | OAuth 2.0 | Zugriff auf Ressourcen erlauben | | OpenID Connect | Benutzeridentität für eine Anmeldung bestätigen | Für einfache API-Grundlagen reicht zunächst: > OAuth 2.0 vergibt begrenzte Zugriffsrechte über Tokens. --- **Sichere Speicherung von Zugangsdaten** API-Keys und Tokens dürfen nicht direkt in öffentlich zugänglichen Dateien stehen. Unsicher: const token = "abc123"; Ebenfalls unsicher: - öffentliches Git-Repository - Wiki-Seite - Chatnachricht - Screenshot - unverschlüsselte Textdatei - Workflow-Beschreibung Sicherer sind: - Credential-Speicher von n8n - Umgebungsvariablen - Secret-Management-Systeme - verschlüsselte Konfigurationen - eingeschränkte Dateiberechtigungen --- **Zugangsdaten in n8n** n8n besitzt eine eigene Credential-Verwaltung. Dort können beispielsweise gespeichert werden: - API-Keys - Bearer-Tokens - OAuth-Verbindungen - Benutzername und Passwort - Client ID und Client Secret Der Workflow verwendet die gespeicherten Credentials, ohne dass das Geheimnis direkt in jeder Node eingetragen werden muss. Vorteile: - zentrale Verwaltung - einfacherer Austausch - geringeres Risiko sichtbarer Tokens - wiederverwendbare Verbindungen - bessere Trennung von Logik und Zugangsdaten --- **Rotation** Rotation bedeutet: > Ein Schlüssel oder Token wird regelmäßig durch einen neuen ersetzt. Eine Rotation ist sinnvoll: - in regelmäßigen Abständen - nach einem Mitarbeiterwechsel - bei Verdacht auf Missbrauch - nach einer versehentlichen Veröffentlichung - nach einem Sicherheitsvorfall - wenn ein Dienst nicht mehr verwendet wird Ablauf: 1. neuen Schlüssel erzeugen 2. Integration auf neuen Schlüssel umstellen 3. Funktion testen 4. alten Schlüssel deaktivieren 5. Änderung dokumentieren --- **Widerruf** Ein Token oder API-Key sollte widerrufen werden, wenn: - er nicht mehr benötigt wird - er möglicherweise bekannt geworden ist - ein Mitarbeiter das Unternehmen verlässt - eine Anwendung abgeschaltet wird - verdächtige Zugriffe erkannt werden Widerruf bedeutet: > Die Zugangsdaten werden ungültig und dürfen nicht mehr verwendet werden. --- **Typische Fehler** | Statuscode | Mögliche Ursache | |---:|---| | 400 | Authentifizierungsdaten falsch aufgebaut | | 401 | Token fehlt, ist ungültig oder abgelaufen | | 403 | Token ist gültig, aber Berechtigung fehlt | | 429 | zu viele API-Anfragen | | 500 | Fehler im Zielsystem | --- **401 Unauthorized** Mögliche Ursachen: - Authorization-Header fehlt - `Bearer` wurde falsch geschrieben - Token ist abgelaufen - API-Key ist ungültig - falsche Zugangsdaten wurden verwendet Beispiel: Authorization: abc123 Möglicherweise erwartet die API: Authorization: Bearer abc123 --- **403 Forbidden** Mögliche Ursachen: - Scope fehlt - Rolle besitzt zu wenige Rechte - Zugriff auf die Ressource ist nicht erlaubt - Administratorfreigabe fehlt - Anwendung wurde für diese Funktion gesperrt Merksatz: > 401 bedeutet fehlende oder ungültige Authentifizierung. > 403 bedeutet gültige Identität, aber fehlende Berechtigung. --- **Praxisbeispiel: n8n und SaaS-API** Ein n8n-Workflow soll eine Nachricht versenden. Ablauf: 1. n8n lädt die gespeicherten Credentials. 2. Das Access Token wird in den Request eingefügt. 3. Die API prüft das Token. 4. Die API kontrolliert den Scope `messages.send`. 5. Die Nachricht wird versendet. 6. Die Response wird ausgewertet. 7. Erfolg oder Fehler wird protokolliert. Request: POST /messages Authorization: Bearer abc123 Content-Type: application/json { "channel": "it-support", "text": "Der Workflow wurde erfolgreich ausgeführt." } --- **Least Privilege** Ein Workflow sollte nicht automatisch Administratorrechte erhalten. Beispiel: Ein Workflow soll nur Nachrichten senden. Benötigter Scope: messages.send Unnötige Scopes: users.delete billing.manage administrators.write Je weniger Rechte ein Zugang besitzt, desto geringer ist der mögliche Schaden bei Missbrauch. --- **Protokollierung** Bei API-Zugriffen sollten protokolliert werden: - Zeitpunkt - verwendete Anwendung - Endpoint - ausgeführte Aktion - Ergebnis - Statuscode - betroffene Ressource Nicht vollständig protokollieren: - Access Token - Refresh Token - API-Key - Client Secret - Passwort Geheimnisse können maskiert werden: Authorization: Bearer *** --- **Systematische Fehlersuche** Wenn die API-Authentifizierung fehlschlägt: 1. Wird das richtige Authentifizierungsverfahren verwendet? 2. Ist der Authorization-Header korrekt aufgebaut? 3. Ist der API-Key oder das Token vorhanden? 4. Ist das Token noch gültig? 5. Wurde das Token widerrufen? 6. Ist der richtige Credential-Eintrag ausgewählt? 7. Besitzt das Token die benötigten Scopes? 8. Wurde eine Administratorfreigabe erteilt? 9. Stimmen Client ID und Client Secret? 10. Welcher Statuscode wird zurückgegeben? 11. Enthält die Response eine genauere Fehlermeldung? 12. Wurde das Geheimnis möglicherweise verändert oder offengelegt? --- **Wichtige Begriffe** | Begriff | Bedeutung | |---|---| | Authentifizierung | Identität überprüfen | | Autorisierung | Berechtigungen überprüfen | | API-Key | geheimer Schlüssel für einen API-Zugang | | Bearer-Token | Zugangstoken im Authorization-Header | | OAuth 2.0 | Verfahren zur kontrollierten Zugriffsfreigabe | | Access Token | Token für API-Anfragen | | Refresh Token | fordert ein neues Access Token an | | Scope | begrenzt die erlaubten Aktionen | | Client ID | identifiziert eine Anwendung | | Client Secret | geheimer Nachweis einer Anwendung | | Rotation | Zugangsdaten regelmäßig ersetzen | | Widerruf | Zugangsdaten ungültig machen | | Credential | gespeicherte Zugangsinformation | --- **Gesamtmerksatz** > API-Keys und Bearer-Tokens weisen einen API-Zugang nach. OAuth 2.0 ermöglicht einer Anwendung einen kontrollierten Zugriff über zeitlich und funktional begrenzte Tokens. Zugangsdaten müssen sicher gespeichert, auf notwendige Rechte begrenzt und bei Bedarf ausgetauscht oder widerrufen werden. --- **Kontrollfragen** **Was ist der Unterschied zwischen Authentifizierung und Autorisierung?** Authentifizierung prüft die Identität. Autorisierung prüft die erlaubten Aktionen. **Was ist ein API-Key?** Ein geheimer Schlüssel, der einen API-Zugang identifiziert. **Was ist ein Bearer-Token?** Ein Zugangstoken, das normalerweise im Authorization-Header übertragen wird. **Was ermöglicht OAuth 2.0?** Eine Anwendung erhält begrenzten Zugriff auf geschützte Ressourcen, ohne dauerhaft das Benutzerpasswort zu speichern. **Was ist ein Access Token?** Ein zeitlich begrenztes Token für API-Anfragen. **Was ist ein Refresh Token?** Ein Token, mit dem ein neues Access Token angefordert werden kann. **Was ist ein Scope?** Eine festgelegte Berechtigung eines Tokens. **Warum müssen Bearer-Tokens besonders geschützt werden?** Weil normalerweise jeder Besitzer des Tokens dessen Berechtigungen verwenden kann. **Was bedeutet Rotation?** Ein API-Key oder Token wird durch neue Zugangsdaten ersetzt. **Was ist der Unterschied zwischen 401 und 403?** 401 weist auf fehlende oder ungültige Authentifizierung hin. Bei 403 fehlt die Berechtigung für die gewünschte Aktion. --- **Quellen** - [IETF – RFC 6749: OAuth 2.0 Authorization Framework](https://datatracker.ietf.org/doc/html/rfc6749) - [IETF – RFC 6750: Bearer Token Usage](https://datatracker.ietf.org/doc/html/rfc6750) - [OAuth 2.0](https://oauth.net/2/) - [OpenID Connect](https://openid.net/developers/how-connect-works/) - [n8n-Dokumentation – Credentials](https://docs.n8n.io/credentials/) - [OWASP – Secrets Management](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html) ``` # 2.8 Webhooks, Polling, Trigger und Zeitpläne Automatisierte Workflows benötigen einen Auslöser. Dieser Auslöser wird als Trigger bezeichnet. Typische Trigger sind: - eingehender Webhook - regelmäßige Abfrage - festgelegter Zeitplan - Änderung in einem System - neuer Datensatz - neue E-Mail - manuelle Ausführung > Ein Trigger bestimmt, wann ein Workflow gestartet wird. --- **Lernziele** Nach dieser Seite solltest du erklären können: - was ein Trigger ist - wie ein Webhook funktioniert - was Polling bedeutet - wie sich Webhook und Polling unterscheiden - was ein Zeitplan-Trigger ist - welche Sicherheitsmaßnahmen bei Webhooks notwendig sind - wie doppelte oder fehlende Ausführungen verhindert werden --- **Trigger** Ein Trigger ist ein Ereignis, das einen automatisierten Workflow startet. Beispiele: | Trigger | Mögliche Aktion | |---|---| | neuer Mitarbeiter | Benutzerkonto anlegen | | neuer CRM-Kunde | Projekt erstellen | | neue Supportanfrage | IT benachrichtigen | | fehlgeschlagener Dienst | Alarm senden | | täglicher Zeitpunkt | Bericht erzeugen | | manuelle Ausführung | Testworkflow starten | Grundablauf: Trigger | v Daten prüfen | v Aktionen ausführen | v Ergebnis protokollieren --- **Webhook** Ein Webhook ist eine automatische Nachricht, die beim Eintritt eines Ereignisses an ein anderes System gesendet wird. Beispiel: > Im CRM wurde ein neuer Kunde angelegt. Das CRM sendet die Kundendaten direkt an n8n. CRM | | Webhook v n8n | v Workflow startet Der Webhook enthält häufig JSON-Daten. Beispiel: { "event": "customer.created", "customerId": 125, "company": "Musterfirma GmbH" } --- **Webhook-Endpoint** Damit ein System einen Webhook senden kann, benötigt es eine Zieladresse. Beispiel: https://automation.example.com/webhook/new-customer Diese Adresse wird als Webhook-Endpoint oder Webhook-URL bezeichnet. Ablauf: 1. n8n stellt einen Webhook-Endpoint bereit. 2. Die Webhook-URL wird im Quellsystem eingetragen. 3. Im Quellsystem tritt ein Ereignis ein. 4. Das Quellsystem sendet einen HTTP-Request. 5. n8n empfängt die Daten. 6. Der Workflow wird gestartet. --- **Webhook als HTTP-Request** Ein Webhook verwendet häufig die HTTP-Methode POST. Beispiel: POST /webhook/new-employee Content-Type: application/json { "name": "Max Mustermann", "department": "IT", "startDate": "2026-08-03" } Der Empfänger antwortet beispielsweise mit: Status: 200 OK Oder: Status: 202 Accepted --- **Vorteile von Webhooks** - Ereignisse werden sofort übertragen - kein regelmäßiges Nachfragen notwendig - geringere Anzahl von API-Anfragen - schnelle Reaktion - gut für ereignisgesteuerte Workflows - effizienter als häufiges Polling --- **Nachteile von Webhooks** - Quellsystem muss Webhooks unterstützen - Zielsystem muss erreichbar sein - verlorene Webhooks können unbemerkt bleiben - doppelte Übertragungen sind möglich - öffentliche Endpoints müssen abgesichert werden - Fehlerbehandlung ist notwendig > Ein Webhook kann mehrfach eintreffen oder vollständig ausbleiben. Der Workflow muss darauf vorbereitet sein. --- **Polling** Polling bedeutet: > Ein System fragt regelmäßig bei einem anderen System nach neuen Daten. Beispiel: n8n fragt alle fünf Minuten beim CRM: > Gibt es neue Kunden? Ablauf: n8n | | API-Abfrage v CRM | | neue Daten vorhanden? v Antwort an n8n Beispiel: GET /customers?createdAfter=2026-07-17T10:00:00 --- **Polling-Intervall** Das Polling-Intervall legt fest, wie häufig eine Abfrage ausgeführt wird. Beispiele: - jede Minute - alle fünf Minuten - jede Stunde - einmal täglich Ein sehr kurzes Intervall sorgt für schnelle Reaktionen, erzeugt aber viele API-Anfragen. Ein langes Intervall reduziert die Last, kann aber zu Verzögerungen führen. --- **Webhook und Polling im Vergleich** | Merkmal | Webhook | Polling | |---|---|---| | Auslösung | Quellsystem sendet aktiv | Zielsystem fragt regelmäßig | | Geschwindigkeit | meistens sofort | abhängig vom Intervall | | API-Anfragen | nur bei Ereignissen | auch ohne neue Daten | | Einrichtung | Webhook-Unterstützung notwendig | API-Abfrage ausreichend | | Fehlerfall | Nachricht kann verloren gehen | nächster Abruf kann Daten finden | | Rate Limits | meist geringer belastet | können schneller erreicht werden | Merksatz: > Beim Webhook meldet das Quellsystem ein Ereignis. Beim Polling fragt das Zielsystem regelmäßig danach. --- **Wann ist ein Webhook sinnvoll?** Ein Webhook eignet sich besonders: - bei zeitkritischen Ereignissen - bei häufigen Änderungen - wenn das Quellsystem Webhooks unterstützt - wenn der Ziel-Endpoint zuverlässig erreichbar ist - wenn sofort reagiert werden soll Beispiele: - neue Supportanfrage - neuer Mitarbeiter - eingegangene Zahlung - geänderter Projektstatus - fehlgeschlagener Prozess --- **Wann ist Polling sinnvoll?** Polling eignet sich besonders: - wenn keine Webhooks unterstützt werden - wenn Änderungen nicht sofort verarbeitet werden müssen - wenn Daten regelmäßig gesammelt werden sollen - wenn verlorene Ereignisse vermieden werden sollen - wenn eine API nach Änderungszeitpunkt filtern kann Beispiele: - stündlicher Abruf neuer Rechnungen - täglicher Statusabgleich - regelmäßige Kontrolle von Benutzerkonten - Synchronisierung von Projektdaten --- **Zeitplan-Trigger** Ein Zeitplan-Trigger startet einen Workflow zu einem festgelegten Zeitpunkt oder Intervall. Beispiele: - täglich um 08:00 Uhr - montags um 09:00 Uhr - alle 30 Minuten - am ersten Tag jedes Monats - einmal pro Nacht Mögliche Aufgaben: - Berichte erstellen - Lizenzen kontrollieren - Backups prüfen - Benutzerkonten synchronisieren - abgelaufene Zugänge erkennen - Erinnerungen senden --- **Cron-Ausdruck** Zeitpläne können mit Cron-Ausdrücken beschrieben werden. Beispiel: 0 8 * * 1-5 Bedeutung: > Montag bis Freitag um 08:00 Uhr Grundaufbau: | Stelle | Bedeutung | |---|---| | 1 | Minute | | 2 | Stunde | | 3 | Tag des Monats | | 4 | Monat | | 5 | Wochentag | Weitere Beispiele: | Cron-Ausdruck | Bedeutung | |---|---| | `0 8 * * *` | täglich um 08:00 Uhr | | `0 9 * * 1` | montags um 09:00 Uhr | | `*/15 * * * *` | alle 15 Minuten | | `0 0 1 * *` | am ersten Tag des Monats | Die genaue Cron-Unterstützung kann je nach System unterschiedlich sein. --- **Manueller Trigger** Ein Workflow kann auch manuell gestartet werden. Dies ist sinnvoll für: - Tests - einmalige Aufgaben - kontrollierte Ausführungen - Fehleranalysen - administrative Tätigkeiten Ein manueller Trigger sollte nicht unkontrolliert auf Produktivdaten angewendet werden. Vorher sollten geprüft werden: - Eingabedaten - Berechtigungen - Zielsystem - mögliche Änderungen - Wiederholbarkeit --- **Ereignisgesteuerter Workflow** Ein ereignisgesteuerter Workflow reagiert auf ein bestimmtes Ereignis. Beispiel: Mitarbeiter im Personalsystem freigegeben | v Webhook an n8n | v Daten prüfen | v Benutzerkonto vorbereiten | v IT benachrichtigen Das Ereignis ist in diesem Fall: > Mitarbeiter wurde freigegeben. --- **Webhook-Sicherheit** Webhook-Endpunkte können über das Internet erreichbar sein. Deshalb müssen sie geschützt werden. Mögliche Maßnahmen: - geheime Webhook-URL - API-Key - Bearer-Token - Signaturprüfung - IP-Filter - HTTPS - Eingabedaten validieren - Rate Limit - Zeitstempel prüfen - Ereignis-ID prüfen Ein öffentlicher Webhook darf eingehende Daten niemals automatisch als vertrauenswürdig behandeln. --- **Webhook-Signatur** Ein Quellsystem kann eine Signatur mitsenden. Beispiel: X-Webhook-Signature: abc123 Der Empfänger berechnet selbst eine Signatur aus: - Webhook-Inhalt - gemeinsamem Geheimnis - festgelegtem Verfahren Stimmen beide Signaturen überein, wurde die Nachricht wahrscheinlich nicht verändert und stammt vom erwarteten Absender. --- **Replay-Angriff** Bei einem Replay-Angriff wird ein gültiger Webhook erneut gesendet. Mögliche Folgen: - Benutzer wird doppelt angelegt - Zahlung wird doppelt verarbeitet - Nachricht wird mehrfach versendet - Aufgabe wird mehrfach erstellt Schutzmaßnahmen: - eindeutige Event-ID speichern - Zeitstempel prüfen - doppelte Ereignisse erkennen - Idempotency-Key verwenden - bereits verarbeitete Vorgänge ablehnen Beispiel: { "eventId": "evt-98452", "event": "employee.created" } Vor der Verarbeitung wird geprüft, ob `evt-98452` bereits verarbeitet wurde. --- **Doppelte Webhooks** Webhooks können mehrfach gesendet werden, wenn das Quellsystem keine erfolgreiche Antwort erhält. Beispiel: 1. Quellsystem sendet Webhook. 2. n8n verarbeitet den Vorgang. 3. Die Antwort an das Quellsystem erreicht den Absender nicht. 4. Das Quellsystem sendet den Webhook erneut. Der Workflow muss deshalb idempotent aufgebaut sein. Möglicher Ablauf: Webhook empfangen | v Event-ID prüfen | v bereits verarbeitet? / \ ja nein | | v v stoppen verarbeiten --- **Verlorene Webhooks** Ein Webhook kann verloren gehen, wenn: - der Zielserver nicht erreichbar ist - DNS nicht funktioniert - ein Timeout auftritt - der Workflow deaktiviert ist - der Endpoint falsch ist - eine Firewall blockiert - das Quellsystem keine Wiederholung durchführt Mögliche Schutzmaßnahmen: - Retry durch das Quellsystem - Fehlerprotokolle - Monitoring - zusätzliche regelmäßige Synchronisierung - fehlende Datensätze über Polling nachladen Eine Kombination aus Webhook und gelegentlichem Polling kann besonders zuverlässig sein. --- **Webhook-Antwort** Der Empfänger sollte schnell eine passende HTTP-Response senden. Beispiele: | Statuscode | Bedeutung | |---:|---| | 200 | Webhook erfolgreich verarbeitet | | 202 | Webhook angenommen, Verarbeitung folgt | | 400 | Daten fehlerhaft | | 401 | Authentifizierung fehlt | | 403 | Zugriff nicht erlaubt | | 500 | interner Fehler | Bei umfangreichen Workflows kann zuerst `202 Accepted` zurückgegeben und die eigentliche Verarbeitung anschließend durchgeführt werden. --- **Praxisbeispiel: IT-Onboarding** Ein Personalsystem sendet einen Webhook: { "eventId": "evt-10025", "event": "employee.approved", "employee": { "name": "Max Mustermann", "department": "IT", "startDate": "2026-08-03" } } Möglicher Workflow: 1. Signatur prüfen 2. Event-ID prüfen 3. Pflichtfelder validieren 4. Startdatum kontrollieren 5. Benutzerkonto vorbereiten 6. Projektaufgabe erstellen 7. Slack-Nachricht senden 8. Ergebnis protokollieren 9. Event-ID als verarbeitet speichern --- **Praxisbeispiel: Polling** Ein SaaS-System unterstützt keine Webhooks. n8n fragt alle 15 Minuten: GET /employees?modifiedAfter=2026-07-17T12:00:00 Möglicher Ablauf: 1. letzten erfolgreichen Abrufzeitpunkt laden 2. neue oder geänderte Datensätze abrufen 3. Datensätze prüfen 4. jeden Datensatz verarbeiten 5. Ergebnisse protokollieren 6. neuen Abrufzeitpunkt speichern Der letzte Abrufzeitpunkt darf erst gespeichert werden, wenn die Verarbeitung erfolgreich abgeschlossen wurde. --- **Zeitzonen** Zeitplan-Trigger müssen die richtige Zeitzone verwenden. Beispiel: Europe/Berlin Probleme können entstehen durch: - Sommerzeit - Winterzeit - unterschiedliche Serverzeitzonen - UTC-Zeit - internationale Standorte Ein Workflow um 08:00 Uhr sollte eindeutig festlegen, welche Zeitzone gemeint ist. --- **Monitoring** Trigger und Workflows sollten überwacht werden. Wichtige Kontrollen: - letzter erfolgreicher Lauf - letzte fehlgeschlagene Ausführung - Anzahl empfangener Webhooks - Dauer des Workflows - wiederholte Ereignisse - fehlende Daten - Rate Limits - ungewöhnlich viele Fehler Beispiel: > Wenn seit 24 Stunden kein erwarteter Webhook empfangen wurde, wird die IT informiert. --- **Systematische Fehlersuche** Wenn ein Workflow nicht startet: 1. Ist der Workflow aktiviert? 2. Ist der richtige Trigger konfiguriert? 3. Ist die Webhook-URL korrekt? 4. Ist der Endpoint erreichbar? 5. Wird die richtige HTTP-Methode verwendet? 6. Wird der Webhook im Quellsystem ausgelöst? 7. Sind Authentifizierung oder Signatur gültig? 8. Ist der Zeitplan korrekt? 9. Ist die richtige Zeitzone eingestellt? 10. Wurde ein Rate Limit erreicht? 11. Gibt es einen Fehler im Trigger-Log? 12. Wurde das Ereignis möglicherweise als Duplikat erkannt? --- **Wichtige Begriffe** | Begriff | Bedeutung | |---|---| | Trigger | startet einen Workflow | | Webhook | aktive Ereignismeldung eines Systems | | Polling | regelmäßige Abfrage nach Änderungen | | Zeitplan | festgelegter Ausführungszeitpunkt | | Cron | Schreibweise für wiederkehrende Zeitpläne | | Event-ID | eindeutige Kennung eines Ereignisses | | Idempotenz | doppelte Ausführung erzeugt keine zusätzlichen Änderungen | | Replay-Angriff | erneutes Senden einer gültigen Nachricht | | Signatur | Nachweis von Herkunft und Unverändertheit | | Retry | erneuter Übertragungsversuch | | Zeitzone | regionale Grundlage einer Zeitangabe | --- **Gesamtmerksatz** > Trigger starten automatisierte Workflows. Webhooks melden Ereignisse aktiv und meist sofort, während Polling regelmäßig nach neuen Daten fragt. Zeitplan-Trigger starten Workflows zu festgelegten Zeiten. Sichere und zuverlässige Automatisierungen müssen doppelte, verlorene und manipulierte Ereignisse berücksichtigen. --- **Kontrollfragen** **Was ist ein Trigger?** Ein Ereignis oder Zeitpunkt, der einen Workflow startet. **Was ist ein Webhook?** Eine automatische HTTP-Nachricht, die beim Eintritt eines Ereignisses an ein anderes System gesendet wird. **Was bedeutet Polling?** Ein System fragt regelmäßig nach neuen oder geänderten Daten. **Was ist der wichtigste Unterschied zwischen Webhook und Polling?** Beim Webhook sendet das Quellsystem aktiv. Beim Polling fragt das Zielsystem regelmäßig nach. **Was ist ein Zeitplan-Trigger?** Ein Trigger, der einen Workflow zu einer festgelegten Zeit oder in einem bestimmten Intervall startet. **Warum muss eine Event-ID geprüft werden?** Damit ein Ereignis nicht mehrfach verarbeitet wird. **Warum müssen Webhook-Daten validiert werden?** Weil ein öffentlich erreichbarer Endpoint manipulierte oder fehlerhafte Daten empfangen kann. **Was ist ein Replay-Angriff?** Eine bereits gültige Nachricht wird erneut gesendet. **Warum ist die Zeitzone bei Zeitplänen wichtig?** Weil der Workflow sonst zu einer falschen Uhrzeit ausgeführt werden kann. **Wann kann eine Kombination aus Webhook und Polling sinnvoll sein?** Wenn Ereignisse sofort verarbeitet und möglicherweise verlorene Webhooks später durch eine Kontrollabfrage erkannt werden sollen. --- **Quellen** - [MDN Web Docs – HTTP](https://developer.mozilla.org/de/docs/Web/HTTP) - [n8n-Dokumentation – Webhook Node](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.webhook/) - [n8n-Dokumentation – Schedule Trigger](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.scheduletrigger/) - [n8n-Dokumentation – Trigger Nodes](https://docs.n8n.io/integrations/builtin/trigger-nodes/) - [OWASP – Webhook Security Guidelines](https://cheatsheetseries.owasp.org/) ``` # 2.9 Prozessautomatisierung mit n8n n8n ist eine Plattform zur Automatisierung von Arbeitsabläufen. Ein n8n-Workflow verbindet verschiedene Systeme und führt festgelegte Schritte automatisch aus. Typische Einsatzbereiche: - Daten zwischen SaaS-Systemen übertragen - Benutzer-Onboarding vorbereiten - API-Anfragen ausführen - Dateien verarbeiten - Benachrichtigungen senden - Daten prüfen und umwandeln - regelmäßige Berichte erstellen - Fehler erkennen und melden > n8n verbindet Trigger, Daten, Bedingungen und Aktionen zu einem automatisierten Workflow. --- **Lernziele** Nach dieser Seite solltest du erklären können: - wie ein n8n-Workflow aufgebaut ist - was Nodes, Trigger und Verbindungen sind - wie Daten zwischen Nodes übertragen werden - wie Expressions verwendet werden - wie Credentials geschützt gespeichert werden - wie man Workflows testet und veröffentlicht - wie Fehler behandelt und Ausführungen geprüft werden --- **Grundaufbau eines Workflows** Ein Workflow besteht aus mehreren miteinander verbundenen Nodes. Beispiel: Webhook Trigger | v Eingabedaten prüfen | v Benutzer vorhanden? / \ ja nein | | v v stoppen Benutzer anlegen | v Slack-Nachricht senden | v Ergebnis protokollieren Jede Node übernimmt eine bestimmte Aufgabe. --- **Node** Eine Node ist ein einzelner Verarbeitungsschritt. Typische Nodes: | Node-Art | Aufgabe | |---|---| | Trigger Node | startet den Workflow | | Action Node | führt eine Aktion aus | | HTTP Request | ruft eine API auf | | Edit Fields | erstellt oder verändert Felder | | If | prüft eine Bedingung | | Switch | unterscheidet mehrere Fälle | | Code | verarbeitet Daten mit JavaScript | | Webhook | empfängt HTTP-Anfragen | | Schedule Trigger | startet nach Zeitplan | > Eine Node erhält Daten, verarbeitet sie und gibt ein Ergebnis an die nächste Node weiter. --- **Trigger Node** Jeder automatisierte Workflow benötigt einen Startpunkt. Mögliche Trigger: - Webhook - Zeitplan - neue E-Mail - neuer CRM-Datensatz - geänderte Datei - manuelle Ausführung - Ereignis aus einer anderen Anwendung Beispiel: Neuer Mitarbeiter wird freigegeben | v Workflow startet Ohne Trigger wird ein Workflow nicht automatisch ausgeführt. --- **Action Node** Eine Action Node führt eine konkrete Aktion aus. Beispiele: - Benutzerkonto erstellen - Nachricht an Slack senden - Asana-Aufgabe anlegen - Datenbankeintrag speichern - Datei verschieben - API-Daten abrufen - E-Mail versenden Ein Workflow kann mehrere Action Nodes nacheinander verwenden. --- **Verbindungen zwischen Nodes** Verbindungen bestimmen die Reihenfolge der Verarbeitung. Beispiel: Trigger | v Daten prüfen | v API aufrufen | v Antwort auswerten Die Ausgabe einer Node wird normalerweise zur Eingabe der nächsten Node. --- **Datenstruktur in n8n** n8n verarbeitet Daten meistens als JSON. Beispiel: { "name": "Max Mustermann", "department": "IT", "active": true } Die nächste Node kann auf diese Werte zugreifen. Beispiel: {{$json.name}} Ergebnis: Max Mustermann Weiteres Beispiel: {{$json.department}} Ergebnis: IT --- **Expressions** Expressions ermöglichen dynamische Werte. Sie beginnen häufig mit: {{ ... }} Beispiel: {{$json.email}} Der Wert wird aus den Eingangsdaten übernommen. Eine Nachricht könnte so aufgebaut werden: Benutzer {{$json.name}} wurde angelegt. Bei den Eingangsdaten: { "name": "Max Mustermann" } entsteht: Benutzer Max Mustermann wurde angelegt. --- **Datenmapping** Datenmapping ordnet Felder eines Quellsystems den Feldern eines Zielsystems zu. Beispiel: | Quellsystem | Zielsystem | |---|---| | `firstName` | `givenName` | | `lastName` | `familyName` | | `mail` | `primaryEmail` | | `department` | `organization.department` | Quellsystem: { "firstName": "Max", "lastName": "Mustermann", "mail": "max.mustermann@example.com" } Zielsystem: { "givenName": "Max", "familyName": "Mustermann", "primaryEmail": "max.mustermann@example.com" } > Beim Datenmapping werden Werte übernommen, obwohl die Systeme unterschiedliche Feldnamen verwenden. --- **Edit Fields Node** Mit der Edit Fields Node können Daten: - ausgewählt - umbenannt - ergänzt - entfernt - neu aufgebaut werden. Beispiel: Eingangsdaten: { "firstName": "Max", "lastName": "Mustermann", "department": "IT", "internalNote": "nicht übertragen" } Ausgangsdaten: { "fullName": "Max Mustermann", "department": "IT" } Damit werden nur die benötigten Daten an das Zielsystem übertragen. --- **If Node** Eine If Node prüft eine Bedingung. Beispiel: > Ist der Benutzer aktiv? active = true? / \ ja nein | | v v weiter Workflow beenden Mögliche Prüfungen: - Wert ist gleich - Wert ist ungleich - Text enthält Zeichenfolge - Zahl ist größer oder kleiner - Feld ist vorhanden - Datum liegt vor oder nach einem Zeitpunkt - Boolean ist `true` oder `false` --- **Switch Node** Eine Switch Node eignet sich für mehrere mögliche Fälle. Beispiel: Abteilung prüfen / | \ v v v IT Vertrieb Buchhaltung | | | v v v IT-Gruppe CRM Finanzsystem Die Switch Node ist übersichtlicher als viele verschachtelte If-Nodes. --- **HTTP Request Node** Die HTTP Request Node kann APIs aufrufen. Benötigte Angaben: - HTTP-Methode - Endpoint - Authentifizierung - Header - Query-Parameter - Request-Body - erwartetes Antwortformat Beispiel: POST https://api.example.com/users Content-Type: application/json { "name": "Max Mustermann", "department": "IT" } Die Response kann anschließend von weiteren Nodes verarbeitet werden. --- **Credentials** Credentials enthalten Zugangsdaten für externe Systeme. Beispiele: - API-Key - Bearer-Token - OAuth-Verbindung - Benutzername und Passwort - Client ID und Client Secret Credentials sollten in der n8n-Credential-Verwaltung gespeichert werden. Sie sollten nicht direkt stehen in: - Workflow-Namen - Beschreibungen - Code-Nodes - öffentlichen Dateien - Screenshots - Wiki-Seiten - Git-Repositories > Workflow-Logik und geheime Zugangsdaten sollten voneinander getrennt werden. --- **Manuelle Ausführung** Ein Workflow kann manuell gestartet werden. Das ist besonders geeignet für: - Aufbau eines neuen Workflows - Tests - Fehlersuche - Prüfung von Daten - einmalige administrative Aufgaben Beim Testen sollte möglichst mit ungefährlichen Testdaten gearbeitet werden. --- **Veröffentlichter Workflow** Damit ein Workflow automatisch auf Trigger reagieren kann, muss er entsprechend aktiviert beziehungsweise veröffentlicht sein. Vorher sollten geprüft werden: - funktionieren alle Nodes? - sind die Credentials korrekt? - stimmen die Endpoints? - werden Produktivdaten verändert? - existiert eine Fehlerbehandlung? - können doppelte Datensätze entstehen? - ist die Protokollierung ausreichend? > Ein getesteter Workflow ist nicht automatisch ein sicherer Produktivworkflow. --- **Test- und Produktivdaten** Testdaten sollten klar von Produktivdaten getrennt werden. Mögliche Maßnahmen: - Testkonten verwenden - eigene Testprojekte anlegen - Test-Endpoints verwenden - Benachrichtigungen an Testkanäle senden - Löschaktionen deaktivieren - Änderungen zuerst manuell freigeben Beispiel: Testworkflow | v Slack-Kanal #it-test Statt: Produktivworkflow | v Slack-Kanal #allgemein --- **Workflow-Ausführung** Jeder Workflow-Lauf wird als Execution bezeichnet. Eine Ausführung kann sein: - erfolgreich - fehlgeschlagen - manuell gestartet - automatisch gestartet - noch in Bearbeitung - abgebrochen Die Ausführungsdaten helfen bei der Fehlersuche. Geprüft werden können: - verwendete Eingangsdaten - Ausgabe jeder Node - fehlgeschlagener Schritt - Fehlermeldung - Dauer - Startzeit - Status --- **Fehlerbehandlung** Ein professioneller Workflow benötigt einen Fehlerpfad. Beispiel: API-Anfrage | v Anfrage erfolgreich? / \ ja nein | | v v weiter Fehler protokollieren | v IT benachrichtigen Mögliche Fehler: - API nicht erreichbar - Token abgelaufen - Berechtigung fehlt - JSON ungültig - Pflichtfeld fehlt - Rate Limit erreicht - Zielsystem antwortet zu langsam - Datensatz existiert bereits --- **Error Workflow** Ein separater Error Workflow kann auf fehlgeschlagene Ausführungen reagieren. Mögliche Aktionen: - Fehlermeldung an Slack senden - E-Mail an die IT senden - Ticket erstellen - Fehlerdaten speichern - zuständige Person informieren Beispielmeldung: Workflow: Mitarbeiter-Onboarding Status: fehlgeschlagen Node: Benutzer anlegen Fehler: 403 Forbidden Zeitpunkt: 18.07.2026 10:15 Uhr Geheime Zugangsdaten dürfen dabei nicht mitgesendet werden. --- **Stop And Error** Ein Workflow sollte gezielt abgebrochen werden, wenn wichtige Bedingungen nicht erfüllt sind. Beispiele: - E-Mail-Adresse fehlt - Mitarbeiter-ID ist ungültig - Abteilung ist unbekannt - Benutzer existiert bereits - notwendige Freigabe fehlt Beispiel: Pflichtfelder prüfen | v E-Mail vorhanden? / \ ja nein | | v v weiter Stop And Error Dadurch wird verhindert, dass fehlerhafte Daten weiterverarbeitet werden. --- **Retry** Vorübergehende Fehler können einen erneuten Versuch erlauben. Geeignet für Retry: - `429 Too Many Requests` - `502 Bad Gateway` - `503 Service Unavailable` - `504 Gateway Timeout` - kurzfristiger Netzwerkfehler Nicht unverändert wiederholen: - `400 Bad Request` - `401 Unauthorized` - `403 Forbidden` - ungültige Pflichtfelder Ein Retry sollte: - begrenzt sein - eine Wartezeit verwenden - protokolliert werden - keine doppelten Datensätze erzeugen --- **Doppelte Ausführungen verhindern** Ein Workflow kann versehentlich mehrfach gestartet werden. Mögliche Schutzmaßnahmen: - eindeutige Mitarbeiter-ID prüfen - E-Mail-Adresse vor dem Anlegen suchen - Event-ID speichern - Idempotency-Key verwenden - bereits verarbeitete Vorgänge markieren Beispiel: Benutzer suchen | v bereits vorhanden? / \ ja nein | | v v stoppen anlegen --- **Teilweise erfolgreiche Workflows** Ein Workflow kann teilweise erfolgreich sein. Beispiel: | Schritt | Ergebnis | |---|---| | Google-Konto anlegen | erfolgreich | | Gruppe zuweisen | erfolgreich | | Slack-Zugang anlegen | fehlgeschlagen | | IT-Aufgabe erstellen | nicht ausgeführt | Der Workflow darf dann nicht melden: > Alles erfolgreich. Stattdessen sollte er melden: > Das Benutzerkonto wurde angelegt. Die Slack-Einrichtung ist fehlgeschlagen und muss geprüft werden. --- **Praxisbeispiel: Mitarbeiter-Onboarding** Eingangsdaten: { "employeeId": "EMP-105", "name": "Max Mustermann", "email": "max.mustermann@example.com", "department": "IT", "startDate": "2026-08-03" } Möglicher Workflow: 1. Webhook empfängt die Daten. 2. Pflichtfelder werden geprüft. 3. Mitarbeiter-ID wird auf doppelte Verarbeitung geprüft. 4. Benutzer wird über eine API gesucht. 5. Ist kein Benutzer vorhanden, wird ein Konto erstellt. 6. Passende Gruppen werden anhand der Abteilung gewählt. 7. Eine Aufgabe für die Hardware wird erstellt. 8. Die IT erhält eine Slack-Nachricht. 9. Das Ergebnis wird protokolliert. 10. Bei einem Fehler wird der Error Workflow gestartet. --- **Dokumentation** Ein Workflow sollte dokumentiert werden. Wichtige Angaben: - Name und Zweck - verantwortliche Person - verwendeter Trigger - beteiligte Systeme - benötigte Credentials - Eingabedaten - Verarbeitungsschritte - Ausgabedaten - Fehlerbehandlung - Zeitplan - Abhängigkeiten - Testverfahren - Wiederherstellungsverfahren Ein verständlicher Workflow-Name wäre: Mitarbeiter-Onboarding – Google Workspace und Slack Weniger verständlich wäre: Workflow 17 Kopie Neu Final 2 --- **Gute Workflow-Regeln** - eindeutige Node-Namen verwenden - nur benötigte Daten übertragen - Credentials sicher speichern - Eingabedaten validieren - Fehlerpfade einbauen - doppelte Ausführungen verhindern - kritische Aktionen absichern - Ergebnisse protokollieren - Workflows vor Änderungen sichern - Änderungen zuerst testen - verantwortliche Person dokumentieren --- **Systematische Fehlersuche** Wenn ein n8n-Workflow fehlschlägt: 1. Wurde der richtige Trigger ausgelöst? 2. Ist der Workflow veröffentlicht beziehungsweise aktiv? 3. Welche Eingangsdaten wurden empfangen? 4. Sind alle Pflichtfelder vorhanden? 5. In welcher Node trat der Fehler auf? 6. Welche Fehlermeldung wird angezeigt? 7. Sind die Credentials gültig? 8. Ist der API-Endpoint erreichbar? 9. Welcher HTTP-Statuscode wurde zurückgegeben? 10. Entspricht die JSON-Struktur der API-Dokumentation? 11. Sind Expressions und Feldpfade korrekt? 12. Wurde der Workflow möglicherweise doppelt ausgeführt? 13. Kann der fehlgeschlagene Schritt sicher wiederholt werden? 14. Muss ein teilweise erfolgreicher Vorgang manuell korrigiert werden? --- **Wichtige Begriffe** | Begriff | Bedeutung | |---|---| | Workflow | automatisierter Ablauf aus mehreren Schritten | | Node | einzelner Verarbeitungsschritt | | Trigger | startet den Workflow | | Action | führt eine konkrete Aktion aus | | Expression | verwendet dynamische Werte | | Datenmapping | ordnet Felder verschiedener Systeme zu | | Credential | sicher gespeicherte Zugangsdaten | | Execution | einzelne Workflow-Ausführung | | Error Workflow | verarbeitet fehlgeschlagene Ausführungen | | Retry | erneuter Ausführungsversuch | | Testdaten | ungefährliche Daten für die Prüfung | | Produktivdaten | echte Unternehmensdaten | --- **Gesamtmerksatz** > Ein n8n-Workflow beginnt mit einem Trigger und verarbeitet Daten über verbundene Nodes. Expressions und Datenmapping übertragen Werte zwischen den Schritten. Credentials schützen API-Zugänge. Professionelle Workflows benötigen Validierung, Fehlerbehandlung, Protokollierung, sichere Tests und Schutz vor doppelten Ausführungen. --- **Kontrollfragen** **Was ist eine Node?** Ein einzelner Verarbeitungsschritt innerhalb eines Workflows. **Was ist eine Trigger Node?** Eine Node, die einen Workflow durch ein Ereignis oder einen Zeitplan startet. **Was ist eine Expression?** Ein dynamischer Ausdruck, der Daten aus vorherigen Nodes verwendet. **Was bedeutet Datenmapping?** Felder eines Quellsystems werden passenden Feldern eines Zielsystems zugeordnet. **Was sind Credentials?** Geschützt gespeicherte Zugangsdaten für externe Systeme. **Was ist eine Execution?** Eine einzelne Ausführung eines Workflows. **Warum sollte ein Error Workflow verwendet werden?** Damit Fehler automatisch protokolliert und zuständige Personen informiert werden. **Warum müssen doppelte Ausführungen verhindert werden?** Damit beispielsweise Benutzer, Aufgaben oder Nachrichten nicht mehrfach erstellt werden. **Warum sollten Test- und Produktivdaten getrennt werden?** Damit Tests keine unbeabsichtigten Änderungen an echten Unternehmensdaten verursachen. **Was sollte bei einer teilweise erfolgreichen Ausführung passieren?** Erfolgreiche und fehlgeschlagene Schritte müssen getrennt dokumentiert und gegebenenfalls manuell korrigiert werden. --- **Quellen** - n8n-Dokumentation – Workflows und Workflow-Komponenten - n8n-Dokumentation – Nodes - n8n-Dokumentation – Expressions - n8n-Dokumentation – Credentials - n8n-Dokumentation – Executions - n8n-Dokumentation – Error Handling ``` # 2.10 Bedingungen, Datenmapping und Verzweigungen* Automatisierte Workflows müssen Daten prüfen, verändern und abhängig vom Ergebnis unterschiedliche Wege ausführen. Dafür werden verwendet: - Bedingungen - Datenmapping - Verzweigungen - Filter - Standardwerte - Schleifen - Zusammenführungen > Bedingungen entscheiden über den Ablauf. Datenmapping passt Informationen an das Zielsystem an. --- **Lernziele** Nach dieser Seite solltest du erklären können: - wie Bedingungen in Workflows funktionieren - was If- und Switch-Verzweigungen unterscheiden - was Datenmapping bedeutet - wie Felder umbenannt und neu aufgebaut werden - wie fehlende Werte behandelt werden - wie mehrere Datensätze verarbeitet werden - wie Fehler durch falsche Datentypen vermieden werden --- **Bedingung** Eine Bedingung prüft, ob eine Aussage wahr oder falsch ist. Beispiel: > Ist der Benutzer aktiv? active = true? / \ ja nein | | v v weiter Workflow beenden Eine Bedingung besitzt meistens zwei mögliche Ergebnisse: - wahr - falsch --- **Typische Prüfungen** | Prüfung | Beispiel | |---|---| | gleich | Abteilung ist `IT` | | ungleich | Status ist nicht `inaktiv` | | größer | Anzahl ist größer als 10 | | kleiner | Preis ist kleiner als 100 | | enthält | Text enthält `Fehler` | | beginnt mit | E-Mail beginnt mit `support` | | Feld vorhanden | E-Mail-Adresse existiert | | Feld leer | Telefonnummer ist leer | | Boolean | `active` ist `true` | | Datum | Startdatum liegt in der Zukunft | --- **If-Verzweigung** Eine If-Verzweigung eignet sich für eine Entscheidung mit zwei möglichen Wegen. Beispiel: E-Mail-Adresse vorhanden? / \ ja nein | | v v Benutzer suchen Fehler melden Weitere Beispiele: - Benutzer aktiv oder inaktiv - Pflichtfeld vorhanden oder nicht vorhanden - Statuscode erfolgreich oder fehlerhaft - Datei größer oder kleiner als Grenzwert > Eine If-Verzweigung unterscheidet normalerweise zwischen wahr und falsch. --- **Switch-Verzweigung** Eine Switch-Verzweigung eignet sich für mehrere mögliche Fälle. Beispiel: Abteilung prüfen / | \ v v v IT Vertrieb Buchhaltung | | | v v v IT-Gruppe CRM-Gruppe Finanz-Gruppe Typische Anwendungen: - verschiedene Abteilungen - mehrere Statuswerte - unterschiedliche Prioritäten - verschiedene Dateitypen - unterschiedliche Fehlercodes --- **If und Switch im Vergleich** | Merkmal | If | Switch | |---|---|---| | Anzahl der Wege | meistens zwei | mehrere | | typische Prüfung | wahr oder falsch | mehrere mögliche Werte | | Beispiel | Benutzer aktiv? | Welche Abteilung? | | Übersichtlichkeit | gut bei einfachen Prüfungen | gut bei vielen Fällen | Merksatz: > If eignet sich für Ja-Nein-Entscheidungen. Switch eignet sich für mehrere feste Fälle. --- **Mehrere Bedingungen** Mehrere Bedingungen können miteinander verbunden werden. **UND-Bedingung** Alle Bedingungen müssen erfüllt sein. Beispiel: - Abteilung ist IT - Benutzer ist aktiv - E-Mail-Adresse ist vorhanden Darstellung: department = IT UND active = true UND email vorhanden Nur wenn alle Bedingungen erfüllt sind, wird der gewünschte Weg ausgeführt. --- **ODER-Bedingung** Mindestens eine Bedingung muss erfüllt sein. Beispiel: - Status ist `fehlerhaft` - oder Status ist `abgebrochen` Darstellung: status = fehlerhaft ODER status = abgebrochen --- **UND und ODER** | Verknüpfung | Bedeutung | |---|---| | UND | alle Bedingungen müssen wahr sein | | ODER | mindestens eine Bedingung muss wahr sein | Beispiel: > Benutzer ist aktiv UND gehört zur Abteilung IT. Beispiel: > Fehlercode ist 500 ODER 503. --- **Datenmapping** Datenmapping bedeutet: > Felder eines Quellsystems werden passenden Feldern eines Zielsystems zugeordnet. Beispiel: | Quellsystem | Zielsystem | |---|---| | `firstName` | `givenName` | | `lastName` | `familyName` | | `mail` | `primaryEmail` | | `department` | `organization.department` | Quellsystem: { "firstName": "Max", "lastName": "Mustermann", "mail": "max.mustermann@example.com" } Zielsystem: { "givenName": "Max", "familyName": "Mustermann", "primaryEmail": "max.mustermann@example.com" } Die Werte bleiben gleich, aber die Feldnamen werden angepasst. --- **Felder umbenennen** Eingangsdaten: { "mail": "max.mustermann@example.com" } Ausgangsdaten: { "primaryEmail": "max.mustermann@example.com" } Der Inhalt bleibt gleich. Nur der Schlüssel wird verändert. --- **Felder zusammenführen** Mehrere Werte können zu einem neuen Feld kombiniert werden. Eingangsdaten: { "firstName": "Max", "lastName": "Mustermann" } Ausgangsdaten: { "fullName": "Max Mustermann" } In n8n kann dafür beispielsweise eine Expression verwendet werden: {{$json.firstName + " " + $json.lastName}} --- **Felder aufteilen** Ein bestehender Wert kann in mehrere Felder getrennt werden. Eingangsdaten: { "fullName": "Max Mustermann" } Mögliche Ausgangsdaten: { "firstName": "Max", "lastName": "Mustermann" } Diese Aufteilung ist nur zuverlässig, wenn das Format eindeutig ist. Bei mehrteiligen Namen können zusätzliche Regeln notwendig sein. --- **Standardwerte** Ein Standardwert wird verwendet, wenn kein Wert vorhanden ist. Beispiel: department = nicht vorhanden Standardwert: "Allgemein" Mögliche Expression: {{$json.department || "Allgemein"}} Ergebnis: - vorhandene Abteilung wird übernommen - fehlende Abteilung wird durch `Allgemein` ersetzt Standardwerte dürfen Pflichtprüfungen nicht unkontrolliert ersetzen. --- **Fehlendes Feld** Beispiel: { "name": "Max Mustermann" } Das Feld `department` fehlt vollständig. Ein Workflow sollte entscheiden: - Standardwert verwenden - Verarbeitung stoppen - Fehler melden - manuelle Prüfung anfordern --- **Leerer Wert** Beispiel: { "department": "" } Das Feld ist vorhanden, enthält aber keinen Text. Ein leerer Wert ist nicht automatisch dasselbe wie ein fehlendes Feld. --- **Null-Wert** Beispiel: { "department": null } `null` bedeutet: > Für dieses Feld ist kein Wert vorhanden. Unterschied: | Zustand | Beispiel | |---|---| | Feld fehlt | kein Schlüssel vorhanden | | leerer Text | `""` | | Null-Wert | `null` | | Zahl null | `0` | | falsch | `false` | Diese Werte dürfen nicht miteinander verwechselt werden. --- **Datentypen prüfen** Ein Zielsystem kann bestimmte Datentypen erwarten. Beispiel: Erwartet: { "active": true } Falsch: { "active": "true" } `true` ist ein Boolean. `"true"` ist ein String. Weitere Beispiele: | Erwartet | Falsch | |---|---| | Zahl `15` | Text `"15"` | | Boolean `false` | Text `"false"` | | Array `["IT"]` | Text `"IT"` | | Objekt `{}` | Array `[]` | --- **Datentypen umwandeln** Ein Wert kann vor der Verarbeitung umgewandelt werden. Beispiele: | Ausgangswert | Zielwert | |---|---| | `"15"` | `15` | | `"true"` | `true` | | `"2026-08-03"` | Datumswert | | `15` | `"15"` | Eine Umwandlung sollte nur erfolgen, wenn das Eingabeformat eindeutig ist. --- **Filter** Ein Filter lässt nur Datensätze weiter, die bestimmte Bedingungen erfüllen. Beispiel: Eingangsdaten: [ { "name": "Max Mustermann", "active": true }, { "name": "Anna Beispiel", "active": false } ] Filter: > Nur aktive Benutzer weiterverarbeiten. Ergebnis: [ { "name": "Max Mustermann", "active": true } ] --- **Mehrere Datensätze** n8n verarbeitet häufig mehrere Datensätze als einzelne Items. Beispiel: [ { "id": 1, "name": "Max Mustermann" }, { "id": 2, "name": "Anna Beispiel" } ] Jeder Datensatz kann einzeln verarbeitet werden. Mögliche Aktionen: - für jeden Benutzer ein Konto prüfen - für jeden Kunden eine Aufgabe erstellen - für jede Datei einen Speicherprozess starten --- **Schleife** Eine Schleife wiederholt eine Verarbeitung für mehrere Datensätze. Beispiel: Benutzerliste | v Benutzer 1 verarbeiten | v Benutzer 2 verarbeiten | v Benutzer 3 verarbeiten n8n verarbeitet viele Items automatisch nacheinander oder gesammelt. Bei großen Datenmengen können Teilmengen sinnvoll sein. --- **Batch-Verarbeitung** Batch bedeutet: > Mehrere Datensätze werden in begrenzten Gruppen verarbeitet. Beispiel: - 1.000 Benutzer vorhanden - Verarbeitung in Gruppen zu je 50 Benutzern Vorteile: - geringere Systemlast - weniger Speicherverbrauch - Rate Limits können besser eingehalten werden - Fehler lassen sich leichter eingrenzen --- **Zusammenführen von Daten** Daten aus mehreren Workflow-Zweigen können wieder zusammengeführt werden. Beispiel: Benutzerdaten | v Prüfen / \ v v CRM Gerätedaten \ / \ / v v zusammenführen Mögliche Kriterien: - gleiche Benutzer-ID - gleiche E-Mail-Adresse - gleiche Projekt-ID - gleiche Vorgangsnummer --- **Beispiel: Abteilungsabhängige Rechte** Eingangsdaten: { "name": "Max Mustermann", "department": "IT" } Verzweigung: department prüfen / | \ IT Vertrieb Sonstige | | | v v v IT-Gruppe CRM-Gruppe Standardgruppe Mögliche Ausgabe: { "name": "Max Mustermann", "groups": [ "employees", "it-support" ] } --- **Beispiel: Pflichtfeldprüfung** Ein Benutzer soll nur angelegt werden, wenn alle Pflichtfelder vorhanden sind. Pflichtfelder: - Name - E-Mail-Adresse - Abteilung - Startdatum Ablauf: Daten empfangen | v Pflichtfelder prüfen | v vollständig? / \ ja nein | | v v weiter Fehler melden Fehlermeldung: { "success": false, "error": "Pflichtfeld email fehlt" } --- **Beispiel: Statuscode auswerten** Nach einem API-Aufruf: Statuscode prüfen / | \ 2xx 4xx 5xx | | | v v v Erfolg Request Retry oder prüfen Fehler melden Mögliche Behandlung: | Status | Reaktion | |---|---| | 200 | Daten weiterverarbeiten | | 201 | Erstellung bestätigen | | 400 | Eingabedaten prüfen | | 401 | Token prüfen | | 403 | Berechtigung prüfen | | 404 | Ressource oder Endpoint prüfen | | 429 | Wartezeit und Retry | | 500 | Fehler protokollieren | | 503 | später erneut versuchen | --- **Expressions in n8n** Expressions lesen oder verändern dynamische Werte. Beispiele: Wert auslesen: {{$json.name}} Text zusammensetzen: {{$json.firstName + " " + $json.lastName}} Standardwert: {{$json.department || "Allgemein"}} Boolean prüfen: {{$json.active === true}} Zahl umwandeln: {{Number($json.licenseCount)}} --- **Code Node** Für komplexere Datenverarbeitung kann eine Code Node verwendet werden. Beispiel: return items.map(item => { return { json: { fullName: `${item.json.firstName} ${item.json.lastName}`, department: item.json.department || "Allgemein" } }; }); Die Code Node: - liest alle Items - erstellt `fullName` - setzt einen Standardwert für `department` - gibt neue JSON-Daten zurück Für einfache Aufgaben sollten möglichst Standard-Nodes verwendet werden. --- **Validierung vor Veränderung** Vor dem Mapping sollten Daten geprüft werden. Empfohlene Reihenfolge: 1. Daten empfangen 2. Pflichtfelder prüfen 3. Datentypen prüfen 4. Werte validieren 5. Daten umwandeln 6. Zielstruktur erzeugen 7. API aufrufen 8. Response prüfen > Erst prüfen, dann verändern und übertragen. --- **Unbekannte Werte** Eine Switch-Verzweigung sollte einen Standardpfad besitzen. Beispiel: Abteilung prüfen / | \ IT Vertrieb Standard | | | v v v IT-Gruppe CRM manuelle Prüfung Ohne Standardpfad könnten unbekannte Werte unbemerkt verloren gehen. --- **Groß- und Kleinschreibung** Systeme können Werte unterschiedlich schreiben. Beispiele: IT it It information technology Vor einem Vergleich kann eine Vereinheitlichung notwendig sein. Beispiel: {{$json.department.toLowerCase()}} Ergebnis: it Danach kann zuverlässig mit `it` verglichen werden. --- **Leerzeichen entfernen** Eingabedaten können unbeabsichtigte Leerzeichen enthalten. Beispiel: " IT " Bereinigung: {{$json.department.trim()}} Ergebnis: "IT" Diese Normalisierung verhindert fehlerhafte Vergleiche. --- **Sicherheitsaspekte** Beim Datenmapping sollten nur benötigte Felder übertragen werden. Nicht unnötig übertragen: - Passwörter - Zugangstoken - private Notizen - vertrauliche Personaldaten - vollständige Kundendatensätze Beispiel: Quellsystem enthält: { "name": "Max Mustermann", "email": "max.mustermann@example.com", "salary": 50000, "password": "geheim" } Das Zielsystem benötigt nur: { "name": "Max Mustermann", "email": "max.mustermann@example.com" } > Nur notwendige Daten sollten ein System verlassen. --- **Typische Fehler** - falscher Feldpfad - leeres Pflichtfeld - String statt Zahl - String statt Boolean - fehlender Standardpfad - Groß- und Kleinschreibung nicht berücksichtigt - doppelte Datensätze - falsche Zuordnung von Quell- und Zielfeld - sensible Daten werden unnötig übertragen - Verzweigungen enden ohne Fehlerbehandlung --- **Systematische Fehlersuche** Wenn eine Verzweigung oder ein Mapping nicht funktioniert: 1. Welche Eingangsdaten erhält die Node? 2. Ist der Feldname korrekt geschrieben? 3. Ist der JSON-Pfad korrekt? 4. Ist das Feld vorhanden? 5. Ist der Wert leer oder `null`? 6. Besitzt der Wert den erwarteten Datentyp? 7. Stimmt die Groß- und Kleinschreibung? 8. Werden Leerzeichen berücksichtigt? 9. Ist die Bedingung mit UND oder ODER korrekt aufgebaut? 10. Existiert ein Standardpfad? 11. Entspricht die Zielstruktur der API-Dokumentation? 12. Werden mehrere Items korrekt verarbeitet? 13. Enthält die Ausgabe nur die benötigten Daten? --- **Wichtige Begriffe** | Begriff | Bedeutung | |---|---| | Bedingung | prüft, ob eine Aussage wahr oder falsch ist | | If | Verzweigung mit zwei Wegen | | Switch | Verzweigung mit mehreren Fällen | | UND | alle Bedingungen müssen erfüllt sein | | ODER | mindestens eine Bedingung muss erfüllt sein | | Datenmapping | Zuordnung von Quell- und Zielfeldern | | Standardwert | Ersatzwert bei fehlenden Daten | | Filter | lässt nur passende Datensätze weiter | | Schleife | wiederholt eine Verarbeitung | | Batch | begrenzte Gruppe von Datensätzen | | Normalisierung | vereinheitlicht Eingabewerte | | Validierung | prüft Struktur, Datentyp und Inhalt | --- **Gesamtmerksatz** > Bedingungen und Verzweigungen steuern den Ablauf eines Workflows. Datenmapping passt Feldnamen, Werte und Strukturen an das Zielsystem an. Vor der Verarbeitung müssen Pflichtfelder, Datentypen und Eingabewerte geprüft werden. Unbekannte Fälle benötigen einen sicheren Standard- oder Fehlerpfad. --- **Kontrollfragen** **Was ist eine Bedingung?** Eine Prüfung, die ein wahres oder falsches Ergebnis liefert. **Wann wird eine If-Verzweigung verwendet?** Bei einer Entscheidung mit meistens zwei möglichen Wegen. **Wann wird eine Switch-Verzweigung verwendet?** Wenn mehrere unterschiedliche Werte oder Fälle behandelt werden müssen. **Was bedeutet Datenmapping?** Felder eines Quellsystems werden passenden Feldern eines Zielsystems zugeordnet. **Was ist der Unterschied zwischen UND und ODER?** Bei UND müssen alle Bedingungen erfüllt sein. Bei ODER genügt mindestens eine. **Was ist ein Standardwert?** Ein Ersatzwert, der verwendet wird, wenn ein benötigter Wert fehlt. **Warum müssen Datentypen geprüft werden?** Weil beispielsweise `true` und `"true"` unterschiedliche Werte darstellen. **Was ist ein Filter?** Eine Prüfung, die nur passende Datensätze weiterverarbeitet. **Warum sollte eine Switch-Verzweigung einen Standardpfad besitzen?** Damit unbekannte Werte nicht unbemerkt verloren gehen. **Warum sollten nur notwendige Felder übertragen werden?** Um Datenschutz- und Sicherheitsrisiken zu reduzieren. --- **Quellen** - [n8n-Dokumentation – If Node](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.if/) - [n8n-Dokumentation – Switch Node](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.switch/) - [n8n-Dokumentation – Edit Fields Node](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.set/) - [n8n-Dokumentation – Expressions](https://docs.n8n.io/code/expressions/) - [n8n-Dokumentation – Data Structure](https://docs.n8n.io/data/data-structure/) ``` # 2.11 Fehlerbehandlung, Logging, Retry und Rate Limits Automatisierte Workflows müssen auch dann kontrolliert reagieren, wenn ein Schritt fehlschlägt. Mögliche Fehlerquellen: - Zielsystem nicht erreichbar - ungültige Zugangsdaten - fehlende Berechtigung - falsche Eingabedaten - abgelaufenes Token - Rate Limit erreicht - Timeout - fehlerhafte API-Response - unbekannter Systemfehler > Ein professioneller Workflow behandelt nicht nur den Erfolgsfall, sondern auch Fehler, Ausnahmen und Teilerfolge. --- **Lernziele** Nach dieser Seite solltest du erklären können: - was Fehlerbehandlung bedeutet - welche Fehlerarten unterschieden werden - was Logging ist - wann ein Retry sinnvoll ist - was Backoff bedeutet - wie Rate Limits behandelt werden - wie teilweise erfolgreiche Abläufe dokumentiert werden - wann eine manuelle Bearbeitung notwendig ist --- **Fehlerbehandlung** Fehlerbehandlung bedeutet: > Ein System erkennt einen Fehler und führt daraufhin einen festgelegten Ablauf aus. Beispiel: API-Anfrage | v erfolgreich? / \ ja nein | | v v weiter Fehler prüfen | v Retry möglich? / \ ja nein | | v v erneut IT informieren Ohne Fehlerbehandlung kann ein Workflow unbemerkt abbrechen oder falsche Ergebnisse erzeugen. --- **Fehlerarten** Fehler können in verschiedene Gruppen eingeteilt werden. | Fehlerart | Beispiel | |---|---| | Eingabefehler | Pflichtfeld fehlt | | Authentifizierungsfehler | Token ungültig | | Berechtigungsfehler | Aktion nicht erlaubt | | Netzwerkfehler | Server nicht erreichbar | | Serverfehler | Zielsystem meldet 500 | | Logikfehler | falsche Bedingung | | Datenfehler | falscher Datentyp | | Zeitüberschreitung | API antwortet zu langsam | | Rate Limit | zu viele Anfragen | | Teilfehler | einige Schritte erfolgreich, andere nicht | --- **Eingabefehler** Ein Eingabefehler entsteht, wenn Daten fehlen oder ungültig sind. Beispiele: - E-Mail-Adresse fehlt - Datum besitzt falsches Format - Zahl wird als Text übertragen - Abteilung ist unbekannt - Pflichtfeld ist leer Beispiel: { "name": "Max Mustermann", "email": "" } Mögliche Behandlung: 1. Verarbeitung stoppen 2. fehlerhaftes Feld dokumentieren 3. zuständige Person informieren 4. keine API-Anfrage senden > Ungültige Eingabedaten sollten möglichst vor dem API-Aufruf erkannt werden. --- **Authentifizierungsfehler** Typische Statuscodes: | Code | Bedeutung | |---:|---| | 401 | Authentifizierung fehlt oder ist ungültig | | 403 | Authentifizierung gültig, aber Berechtigung fehlt | Mögliche Ursachen: - Token abgelaufen - API-Key falsch - Authorization-Header fehlt - Scope fehlt - Rolle besitzt zu wenige Rechte - Credential wurde widerrufen Diese Fehler sollten normalerweise nicht unverändert wiederholt werden. --- **Netzwerk- und Serverfehler** Mögliche Fehler: - DNS-Auflösung schlägt fehl - Verbindung wird abgelehnt - Timeout - Server antwortet mit 500 - Gateway meldet 502 - Dienst ist mit 503 nicht verfügbar - Gateway meldet 504 Diese Fehler können vorübergehend sein. Ein begrenzter Retry kann daher sinnvoll sein. --- **Dauerhafte und vorübergehende Fehler** | Fehler | Typische Einordnung | |---|---| | 400 Bad Request | dauerhaft, Request korrigieren | | 401 Unauthorized | dauerhaft, Zugangsdaten prüfen | | 403 Forbidden | dauerhaft, Berechtigung prüfen | | 404 Not Found | meistens dauerhaft, Endpoint oder ID prüfen | | 409 Conflict | Zustand oder vorhandenen Datensatz prüfen | | 429 Too Many Requests | vorübergehend | | 500 Internal Server Error | möglicherweise vorübergehend | | 502 Bad Gateway | häufig vorübergehend | | 503 Service Unavailable | häufig vorübergehend | | 504 Gateway Timeout | häufig vorübergehend | Merksatz: > Fehlerhafte Daten müssen korrigiert werden. Vorübergehende Systemfehler können erneut versucht werden. --- **Retry** Retry bedeutet: > Eine fehlgeschlagene Aktion wird erneut ausgeführt. Retry ist sinnvoll bei: - kurzfristigem Netzwerkfehler - `429 Too Many Requests` - `502 Bad Gateway` - `503 Service Unavailable` - `504 Gateway Timeout` Retry ist normalerweise nicht sinnvoll bei: - ungültigem JSON - fehlendem Pflichtfeld - falschem Token - fehlender Berechtigung - falschem Endpoint --- **Begrenzte Wiederholungen** Ein Workflow darf eine fehlgeschlagene Aktion nicht unbegrenzt wiederholen. Beispiel: 1. erster Versuch sofort 2. zweiter Versuch nach 5 Sekunden 3. dritter Versuch nach 15 Sekunden 4. vierter Versuch nach 30 Sekunden 5. anschließend Fehler melden Vorteile: - keine Endlosschleife - Zielsystem wird nicht zusätzlich überlastet - Fehler bleibt nachvollziehbar - manuelle Bearbeitung kann beginnen --- **Backoff** Backoff bedeutet: > Die Wartezeit zwischen Wiederholungen wird schrittweise erhöht. Beispiel: | Versuch | Wartezeit | |---:|---:| | 1 | sofort | | 2 | 5 Sekunden | | 3 | 15 Sekunden | | 4 | 30 Sekunden | | 5 | 60 Sekunden | Ein exponentieller Backoff erhöht die Wartezeit besonders deutlich. Beispiel: 2 Sekunden 4 Sekunden 8 Sekunden 16 Sekunden 32 Sekunden --- **Rate Limit** Ein Rate Limit begrenzt die Anzahl erlaubter API-Anfragen. Beispiel: > Maximal 100 Anfragen pro Minute. Wird das Limit überschritten, antwortet die API häufig mit: Status: 429 Too Many Requests Mögliche Response: Retry-After: 60 Bedeutung: > Vor dem nächsten Versuch 60 Sekunden warten. --- **Rate Limits vermeiden** Mögliche Maßnahmen: - Anfragen zeitlich verteilen - mehrere Datensätze gesammelt übertragen - nur notwendige Daten abrufen - Ergebnisse zwischenspeichern - Polling-Intervall vergrößern - Wiederholungen begrenzen - `Retry-After` auswerten - Batch-Verarbeitung verwenden Beispiel: Statt 1.000 Einzelanfragen: GET /users/1 GET /users/2 GET /users/3 besser, wenn unterstützt: GET /users?limit=100 --- **Timeout** Ein Timeout tritt auf, wenn eine Antwort nicht rechtzeitig empfangen wird. Mögliche Ursachen: - Zielsystem reagiert langsam - Netzwerk ist gestört - Datenbankabfrage dauert zu lange - Workflow verarbeitet zu viele Daten - Timeout-Wert ist zu niedrig Bei einem Timeout ist nicht immer klar, ob die Aktion im Zielsystem bereits ausgeführt wurde. Beispiel: 1. n8n sendet `POST /users` 2. Zielsystem legt den Benutzer an 3. Response erreicht n8n nicht rechtzeitig 4. n8n meldet Timeout 5. Workflow wiederholt den POST-Request 6. Benutzer könnte doppelt angelegt werden Vor einem Retry sollte daher geprüft werden, ob die Ressource bereits existiert. --- **Idempotenz bei Retry** Ein Retry darf keine doppelten Ressourcen erzeugen. Mögliche Schutzmaßnahmen: - eindeutige Vorgangs-ID verwenden - vor POST zunächst mit GET suchen - Idempotency-Key verwenden - Event-ID speichern - bereits verarbeitete Datensätze markieren Beispiel: Request-ID: EMP-105 Vor dem Anlegen: GET /users?employeeId=EMP-105 Nur wenn kein Benutzer vorhanden ist: POST /users --- **Logging** Logging bedeutet: > Ereignisse, Ergebnisse und Fehler werden protokolliert. Ein Log sollte beantworten: - Was ist passiert? - Wann ist es passiert? - Welcher Workflow war betroffen? - Welche Node ist fehlgeschlagen? - Welcher Statuscode wurde empfangen? - Welche Ressource war betroffen? - Welche Gegenmaßnahme wurde ausgeführt? --- **Sinnvolle Log-Daten** | Information | Beispiel | |---|---| | Zeitpunkt | 18.07.2026 10:15 Uhr | | Workflow | Mitarbeiter-Onboarding | | Node | Google-Benutzer anlegen | | Aktion | `POST /users` | | Statuscode | 403 | | Fehlermeldung | fehlende Berechtigung | | Vorgangs-ID | EMP-105 | | Versuch | 1 von 3 | | Ergebnis | Administrator informiert | --- **Sensible Daten im Log** Nicht vollständig protokollieren: - Passwörter - API-Keys - Bearer-Tokens - Refresh Tokens - Client Secrets - vertrauliche Personaldaten - vollständige Zahlungsdaten Unsicher: Authorization: Bearer abc123vollstaendig Sicherer: Authorization: Bearer *** Oder: Token-Ende: ...7F3A > Logs müssen bei der Fehlersuche helfen, ohne neue Sicherheitsrisiken zu erzeugen. --- **Log-Level** Logs können nach Wichtigkeit eingeteilt werden. | Level | Bedeutung | |---|---| | Debug | detaillierte technische Informationen | | Info | normaler Ablauf | | Warning | ungewöhnliches, aber noch beherrschbares Ereignis | | Error | Aktion ist fehlgeschlagen | | Critical | schwerwiegender Ausfall oder Sicherheitsvorfall | Beispiele: INFO: Benutzerprüfung gestartet WARNING: API-Antwort dauerte länger als erwartet ERROR: Benutzer konnte nicht angelegt werden CRITICAL: mehrere zentrale Workflows ausgefallen --- **Error Workflow in n8n** Ein Error Workflow kann bei einer fehlgeschlagenen Ausführung automatisch gestartet werden. Mögliche Aktionen: - Slack-Nachricht senden - E-Mail versenden - Ticket erstellen - Fehler in Datenbank speichern - verantwortliche Person informieren - Vorgang zur manuellen Bearbeitung markieren Beispielmeldung: Workflow: Mitarbeiter-Onboarding Node: Benutzer anlegen Status: fehlgeschlagen Fehler: 403 Forbidden Vorgangs-ID: EMP-105 Zeitpunkt: 18.07.2026 10:15 Uhr --- **Teilerfolg** Ein Workflow kann teilweise erfolgreich sein. Beispiel: | Schritt | Ergebnis | |---|---| | Benutzerkonto anlegen | erfolgreich | | Google-Gruppe zuweisen | erfolgreich | | Slack-Zugang erstellen | fehlgeschlagen | | Asana-Aufgabe erstellen | nicht ausgeführt | Der Workflow darf nicht melden: > Vorgang vollständig erfolgreich. Besser: > Benutzerkonto und Gruppe wurden eingerichtet. Die Slack-Einrichtung ist fehlgeschlagen. Die Asana-Aufgabe wurde nicht erstellt. --- **Rollback** Rollback bedeutet: > Bereits ausgeführte Änderungen werden bei einem Fehler zurückgenommen. Beispiel: 1. Benutzerkonto wird angelegt. 2. wichtige Gruppenzuweisung schlägt fehl. 3. Workflow deaktiviert das neu angelegte Konto wieder. Ein Rollback ist nicht immer sinnvoll oder technisch möglich. Alternativen: - Vorgang pausieren - Teilerfolg dokumentieren - manuelle Prüfung anfordern - fehlgeschlagenen Schritt gezielt erneut ausführen --- **Manuelle Bearbeitung** Eine manuelle Bearbeitung ist sinnvoll, wenn: - der Fehler nicht automatisch lösbar ist - eine Entscheidung erforderlich ist - Berechtigungen fehlen - Daten widersprüchlich sind - ein Sicherheitsvorfall möglich ist - mehrere Systeme unterschiedliche Zustände besitzen - ein Rollback riskant wäre Der Workflow sollte dafür alle notwendigen Informationen bereitstellen. --- **Alerting** Alerting bedeutet: > Zuständige Personen werden bei wichtigen Fehlern automatisch benachrichtigt. Mögliche Kanäle: - Slack - E-Mail - Ticketsystem - Monitoring-System - SMS oder Bereitschaftsdienst Nicht jeder kleine Fehler benötigt sofort einen Alarm. Sinnvolle Priorisierung: | Priorität | Beispiel | |---|---| | niedrig | einzelner unkritischer Datensatz fehlerhaft | | mittel | wiederholter Workflow-Fehler | | hoch | kompletter Onboarding-Prozess ausgefallen | | kritisch | Sicherheitsvorfall oder zentraler Systemausfall | --- **Fehler nicht verschlucken** Ein Workflow darf einen Fehler nicht einfach ignorieren und trotzdem Erfolg melden. Schlechtes Verhalten: API-Fehler | v Workflow läuft ohne Prüfung weiter | v Meldung „erfolgreich“ Besser: API-Fehler | v Status prüfen | v Fehler dokumentieren | v abhängige Schritte stoppen | v IT informieren --- **Praxisbeispiel: Benutzer-Onboarding** Möglicher Ablauf: Webhook empfangen | v Daten validieren | v Benutzer suchen | v Benutzer anlegen | v Statuscode prüfen / \ 201 Fehler | | v v weiter Fehlerart prüfen | ┌─────────┼─────────┐ v v v 400 429 503 | | | v v v Daten warten Retry melden und Retry --- **Behandlung nach Statuscode** | Status | Reaktion | |---:|---| | 200 | Daten weiterverarbeiten | | 201 | Erstellung bestätigen | | 400 | Eingabedaten korrigieren | | 401 | Credential prüfen | | 403 | Rollen und Scopes prüfen | | 404 | Endpoint oder ID prüfen | | 409 | vorhandenen Datensatz prüfen | | 429 | `Retry-After` beachten | | 500 | Fehler protokollieren und begrenzt wiederholen | | 503 | warten und erneut versuchen | | 504 | Timeout und Zielsystem prüfen | --- **Monitoring wichtiger Workflows** Neben einzelnen Fehlern sollte auch der Gesamtzustand überwacht werden. Mögliche Prüfungen: - letzter erfolgreicher Lauf - Anzahl fehlgeschlagener Ausführungen - durchschnittliche Laufzeit - Anzahl der Retries - ungewöhnlich viele Statuscodes 401 oder 403 - ungewöhnlich viele Rate-Limit-Fehler - seit langer Zeit kein Trigger empfangen - Workflow deaktiviert - Credential läuft bald ab --- **Gute Fehlerbehandlung** Eine gute Fehlerbehandlung besitzt: - klare Validierung - eindeutige Fehlermeldungen - begrenzte Retries - passende Wartezeiten - Schutz vor Doppelverarbeitung - sichere Logs - Benachrichtigung nach Priorität - Behandlung von Teilerfolgen - dokumentierte manuelle Schritte - regelmäßiges Monitoring --- **Systematische Fehlersuche** Wenn ein Workflow fehlschlägt: 1. Wurde der Workflow gestartet? 2. Welche Node ist fehlgeschlagen? 3. Welche Eingangsdaten wurden verwendet? 4. Welcher Statuscode wurde empfangen? 5. Welche Fehlermeldung enthält die Response? 6. Ist der Fehler dauerhaft oder vorübergehend? 7. Ist ein Retry sinnvoll? 8. Wurde ein Rate Limit erreicht? 9. Besteht das Risiko einer doppelten Ausführung? 10. Welche Schritte waren bereits erfolgreich? 11. Muss ein Rollback erfolgen? 12. Wurde der Fehler korrekt protokolliert? 13. Wurde die zuständige Person informiert? 14. Kann der Vorgang manuell fortgesetzt werden? --- **Wichtige Begriffe** | Begriff | Bedeutung | |---|---| | Fehlerbehandlung | festgelegter Umgang mit Fehlern | | Retry | erneuter Ausführungsversuch | | Backoff | steigende Wartezeit zwischen Versuchen | | Rate Limit | Begrenzung der API-Anfragen | | Timeout | Antwortzeit wurde überschritten | | Logging | Protokollierung von Ereignissen | | Log-Level | Einordnung der Wichtigkeit | | Alerting | automatische Benachrichtigung | | Teilerfolg | nur ein Teil des Ablaufs war erfolgreich | | Rollback | Änderungen werden zurückgenommen | | Idempotenz | Wiederholung erzeugt keine zusätzlichen Änderungen | | Error Workflow | separater Ablauf für Fehler | --- **Gesamtmerksatz** > Fehlerbehandlung erkennt Probleme und führt einen kontrollierten Fehlerpfad aus. Vorübergehende Fehler können mit begrenzten Retries und Backoff behandelt werden. Rate Limits müssen berücksichtigt und Logs sicher gespeichert werden. Teilerfolge, doppelte Ausführungen und manuelle Nacharbeiten müssen eindeutig dokumentiert werden. --- **Kontrollfragen** **Was bedeutet Fehlerbehandlung?** Ein Fehler wird erkannt und nach festgelegten Regeln verarbeitet. **Wann ist ein Retry sinnvoll?** Bei vorübergehenden Netzwerk-, Gateway-, Server- oder Rate-Limit-Fehlern. **Wann ist ein Retry nicht sinnvoll?** Wenn Eingabedaten, Credentials, Berechtigungen oder Endpoints falsch sind. **Was bedeutet Backoff?** Die Wartezeit zwischen Wiederholungen wird schrittweise erhöht. **Was ist ein Rate Limit?** Eine Begrenzung der erlaubten API-Anfragen innerhalb eines Zeitraums. **Was bedeutet Logging?** Ereignisse, Abläufe und Fehler werden protokolliert. **Warum dürfen Tokens nicht vollständig im Log erscheinen?** Weil sie geheime Zugangsdaten darstellen. **Was ist ein Teilerfolg?** Ein Teil des Workflows war erfolgreich, während andere Schritte fehlgeschlagen sind. **Was bedeutet Rollback?** Bereits durchgeführte Änderungen werden zurückgenommen. **Warum muss vor einem Retry geprüft werden, ob eine Ressource bereits erstellt wurde?** Damit durch die Wiederholung keine doppelten Datensätze entstehen. --- **Quellen** - [n8n-Dokumentation – Error Handling](https://docs.n8n.io/flow-logic/error-handling/) - [n8n-Dokumentation – Error Trigger](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.errortrigger/) - [n8n-Dokumentation – Executions](https://docs.n8n.io/workflows/executions/) - [MDN Web Docs – HTTP-Statuscodes](https://developer.mozilla.org/de/docs/Web/HTTP/Status) - [MDN Web Docs – 429 Too Many Requests](https://developer.mozilla.org/de/docs/Web/HTTP/Status/429) - [OWASP – Logging Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html) ``` # 2.12 Sicherheit, Datenschutz und Least Privilege Automatisierungen verbinden häufig mehrere Systeme und verarbeiten dabei Benutzer-, Kunden- oder Unternehmensdaten. Deshalb müssen Zugriffe, Datenübertragungen und Berechtigungen besonders geschützt werden. Wichtige Grundprinzipien: - nur notwendige Daten verarbeiten - nur notwendige Rechte vergeben - Zugangsdaten sicher speichern - Änderungen protokollieren - kritische Aktionen kontrollieren - Datenschutzvorgaben beachten - Zugänge regelmäßig überprüfen > Eine Automatisierung sollte nur auf die Daten und Funktionen zugreifen, die sie tatsächlich benötigt. --- **Lernziele** Nach dieser Seite solltest du erklären können: - was Least Privilege bedeutet - wie Rollen und Scopes Zugriffe begrenzen - warum Secrets geschützt werden müssen - welche Daten eine Automatisierung verarbeiten darf - was Datenminimierung bedeutet - wie Test- und Produktivsysteme getrennt werden - welche Sicherheitsrisiken APIs und Webhooks besitzen - wie sichere Automatisierungen aufgebaut werden --- **Least Privilege** Least Privilege bedeutet: > Benutzer, Anwendungen und Workflows erhalten nur die Rechte, die sie für ihre Aufgabe benötigen. Beispiel: Ein Workflow soll Slack-Nachrichten senden. Benötigte Berechtigung: messages.send Nicht benötigte Berechtigungen: users.delete billing.manage administrators.write Je weniger Rechte ein Zugang besitzt, desto geringer ist der mögliche Schaden bei: - Fehlkonfiguration - Programmierfehler - gestohlenem Token - kompromittiertem Benutzerkonto - versehentlicher Ausführung --- **Rollenbasierte Zugriffskontrolle** RBAC bedeutet: > Role-Based Access Control Berechtigungen werden über Rollen vergeben. Beispiele: | Rolle | Mögliche Rechte | |---|---| | Mitarbeiter | eigene Daten lesen | | IT-Support | Benutzerkonten bearbeiten | | Projektleitung | Projekte verwalten | | Buchhaltung | Finanzdaten verwenden | | Administrator | Systeme konfigurieren | | Automatisierungsdienst | bestimmte API-Funktionen ausführen | Vorteile: - einheitliche Rechtevergabe - einfacheres Onboarding - schnelleres Offboarding - bessere Kontrolle - geringere Fehlkonfiguration --- **Scopes** Scopes begrenzen die Rechte eines API-Tokens. Beispiele: | Scope | Berechtigung | |---|---| | `users.read` | Benutzer lesen | | `users.write` | Benutzer erstellen oder ändern | | `projects.read` | Projekte lesen | | `messages.send` | Nachrichten senden | Ein Workflow sollte nur die benötigten Scopes erhalten. Beispiel: Ein Workflow liest Benutzerinformationen. Ausreichend: users.read Nicht erforderlich: users.delete --- **Service Account** Ein Service Account ist ein technisches Benutzerkonto für Anwendungen oder automatisierte Prozesse. Typische Verwendung: - API-Zugriffe - Hintergrundprozesse - Datenübertragungen - automatisierte Berichte - Systemintegrationen Ein Service Account sollte: - einen eindeutigen Namen besitzen - nur für einen bestimmten Zweck verwendet werden - keine interaktive Anmeldung benötigen - nur notwendige Rechte erhalten - regelmäßig geprüft werden - deaktiviert werden, wenn er nicht mehr benötigt wird Beispiel: svc-n8n-onboarding Besser als: admin2 --- **Keine persönlichen Administratorkonten verwenden** Ein Workflow sollte möglichst nicht dauerhaft mit dem persönlichen Administratorkonto eines Mitarbeiters arbeiten. Nachteile: - Workflow fällt beim Mitarbeiteraustritt aus - Aktionen sind schwerer zuzuordnen - Rechte sind häufig zu umfangreich - Passwortänderungen können Integrationen unterbrechen - private und technische Zugriffe werden vermischt Besser: > Für die Integration wird ein eigener technischer Zugang mit begrenzten Rechten verwendet. --- **Secrets** Secrets sind vertrauliche Zugangsdaten. Beispiele: - Passwörter - API-Keys - Bearer-Tokens - Refresh Tokens - Client Secrets - private Schlüssel - Datenbankkennwörter - Webhook-Geheimnisse Secrets dürfen nicht offen gespeichert werden in: - Wiki-Seiten - Workflow-Beschreibungen - Code - Screenshots - E-Mails - öffentlichen Git-Repositories - unverschlüsselten Textdateien --- **Sichere Speicherung von Secrets** Geeignete Speicherorte: - n8n-Credential-Verwaltung - Umgebungsvariablen - Secret-Management-System - verschlüsselte Konfigurationsdatei - geschützter Passwortmanager Unsicher: const token = "abc123"; Sicherer: API_TOKEN wird aus einem geschützten Credential geladen > Workflow-Logik und Zugangsdaten müssen getrennt gespeichert werden. --- **Secret Rotation** Secret Rotation bedeutet: > Ein Passwort, Token oder Schlüssel wird durch einen neuen ersetzt. Rotation ist sinnvoll: - regelmäßig - nach einem Sicherheitsvorfall - bei Verdacht auf Veröffentlichung - nach einem Mitarbeiterwechsel - nach Abschluss eines Projekts - wenn ein Dienst nicht mehr benötigt wird Ablauf: 1. neues Secret erzeugen 2. Integration aktualisieren 3. Funktion prüfen 4. altes Secret widerrufen 5. Änderung dokumentieren --- **Datenminimierung** Datenminimierung bedeutet: > Es werden nur die Daten verarbeitet, die für den Zweck notwendig sind. Beispiel: Ein Workflow soll einen Slack-Zugang vorbereiten. Benötigte Daten: - Name - dienstliche E-Mail-Adresse - Abteilung Nicht notwendig: - private Adresse - Gehalt - Bankverbindung - Gesundheitsdaten - private Telefonnummer Beispiel: Quellsystem: { "name": "Max Mustermann", "email": "max.mustermann@example.com", "department": "IT", "salary": 50000, "privateAddress": "Musterstraße 1" } Übertragung an Slack: { "name": "Max Mustermann", "email": "max.mustermann@example.com", "department": "IT" } --- **Zweckbindung** Daten dürfen nur für den festgelegten Zweck verarbeitet werden. Beispiel: Mitarbeiterdaten werden für das technische Onboarding verwendet. Sie dürfen nicht automatisch für andere Auswertungen verwendet werden, wenn dafür keine Freigabe oder rechtliche Grundlage besteht. > Daten sollten nicht nur gesammelt werden, weil sie verfügbar sind. --- **Personenbezogene Daten** Personenbezogene Daten sind Informationen, die sich auf eine bestimmte oder bestimmbare Person beziehen. Beispiele: - Name - E-Mail-Adresse - Mitarbeiter-ID - IP-Adresse - Benutzerkonto - Telefonnummer - Standortdaten - Zugriffsprotokolle Besonders sensible Daten benötigen einen erhöhten Schutz. --- **Datenschutz bei Logs** Logs können personenbezogene oder vertrauliche Daten enthalten. Deshalb sollte geprüft werden: - Welche Daten werden protokolliert? - Wer darf die Logs lesen? - Wie lange werden Logs gespeichert? - Werden Tokens oder Passwörter maskiert? - Sind vollständige Nutzdaten wirklich notwendig? Unsicher: Passwort: GeheimesPasswort123 Sicherer: Passwort: *** Unsicher: Authorization: Bearer vollständiges-token Sicherer: Authorization: Bearer *** --- **Datenaufbewahrung** Daten und Logs sollten nicht unbegrenzt gespeichert werden. Mögliche Regeln: - erfolgreiche Testausführungen nach kurzer Zeit löschen - Fehlerlogs für einen festgelegten Zeitraum speichern - personenbezogene Daten nach Zweckfortfall entfernen - alte Workflow-Daten regelmäßig prüfen - Aufbewahrungsfristen dokumentieren > Daten sollten nur so lange gespeichert werden, wie sie benötigt werden. --- **Transportverschlüsselung** API- und Webhook-Daten sollten verschlüsselt übertragen werden. Verwendet wird normalerweise: HTTPS HTTPS schützt vor: - Mitlesen - Manipulation - unbemerkter Veränderung - Übertragung von Zugangsdaten im Klartext Unsicher: http://api.example.com Sicherer: https://api.example.com --- **Zertifikate** Bei HTTPS prüft der Client das TLS-Zertifikat des Servers. Zu prüfen sind: - Zertifikat gültig - Hostname stimmt - Zertifikat nicht abgelaufen - vertrauenswürdige Zertifizierungsstelle - vollständige Zertifikatskette Zertifikatsprüfungen sollten nicht dauerhaft deaktiviert werden. --- **Webhook-Sicherheit** Ein Webhook-Endpoint kann öffentlich erreichbar sein. Mögliche Schutzmaßnahmen: - HTTPS - geheime Webhook-URL - API-Key - Bearer-Token - Signaturprüfung - Zeitstempel - Event-ID - Rate Limit - IP-Filter - Datenvalidierung Ablauf: Webhook empfangen | v Signatur prüfen | v Zeitstempel prüfen | v Event-ID prüfen | v Daten validieren | v Workflow ausführen --- **Eingabevalidierung** Daten aus APIs und Webhooks dürfen nicht automatisch als vertrauenswürdig behandelt werden. Zu prüfen sind: - Pflichtfelder - Datentypen - erlaubte Werte - Textlänge - Datum - E-Mail-Format - IDs - Dateitypen - Dateigröße Beispiel: Erlaubte Abteilungen: IT Vertrieb Buchhaltung Unbekannter Wert: Administrator Dieser Wert sollte nicht automatisch Administratorrechte auslösen. --- **Test- und Produktivsysteme** Test- und Produktivsysteme sollten getrennt werden. | Testsystem | Produktivsystem | |---|---| | Testdaten | echte Unternehmensdaten | | Testkonten | reale Benutzer | | ungefährliche Aktionen | betriebliche Auswirkungen | | Entwicklung und Prüfung | täglicher Betrieb | Mögliche Trennung: - eigene Credentials - eigene API-Endpunkte - getrennte Datenbanken - getrennte Slack-Kanäle - getrennte Projekte - getrennte Workflows --- **Produktivänderungen absichern** Besonders kritische Aktionen: - Benutzer löschen - Administratorrechte vergeben - Kundendaten verändern - Zahlungen auslösen - Dateien endgültig löschen - große Datenmengen ändern Mögliche Schutzmaßnahmen: - manuelle Freigabe - Vier-Augen-Prinzip - Testlauf - Vorschau - Backup - Rollback-Möglichkeit - zusätzliche Bestätigung --- **Vier-Augen-Prinzip** Beim Vier-Augen-Prinzip prüft eine zweite Person eine kritische Aktion. Beispiele: - Administratorrolle vergeben - größeren Benutzerimport starten - Produktivdaten löschen - API-Scopes erweitern - neue SaaS-Integration aktivieren > Kritische Änderungen sollten nicht immer vollständig automatisch ausgeführt werden. --- **Onboarding und Offboarding** Beim Onboarding: - nur notwendige Zugänge anlegen - passende Rollen vergeben - MFA aktivieren - Lizenzen zuweisen - Rechte dokumentieren Beim Offboarding: - Konten deaktivieren - aktive Sitzungen beenden - Tokens widerrufen - Gruppen entfernen - Daten übertragen - Lizenzen freigeben - technische Zugänge prüfen Ein unvollständiges Offboarding kann ein erhebliches Sicherheitsrisiko darstellen. --- **Berechtigungen regelmäßig prüfen** Berechtigungen verändern sich im Laufe der Zeit. Mögliche Ursachen: - Mitarbeiter wechselt Abteilung - Projekt endet - Aufgabe ändert sich - Integration wird ersetzt - temporäre Rechte werden vergessen Deshalb sollten regelmäßig geprüft werden: - Benutzerrollen - Gruppenmitgliedschaften - API-Scopes - Service Accounts - aktive Tokens - Administratorrechte - ungenutzte Konten --- **Audit-Logs** Audit-Logs dokumentieren sicherheitsrelevante Aktionen. Beispiele: - Benutzer angelegt - Rolle geändert - Token erzeugt - MFA deaktiviert - Datei freigegeben - Administratorrecht vergeben - Workflow geändert - Credential aktualisiert Audit-Logs helfen bei: - Fehlersuche - Sicherheitsanalyse - Nachvollziehbarkeit - internen Kontrollen - Datenschutzprüfungen --- **Schatten-IT** Schatten-IT bezeichnet nicht genehmigte Anwendungen oder Dienste. Beispiel: Ein Mitarbeiter verbindet ohne Freigabe einen externen Onlinedienst mit Unternehmensdaten. Risiken: - unbekannter Speicherort - fehlende Sicherheitsprüfung - unkontrollierte API-Tokens - fehlendes Offboarding - Datenschutzverletzung - zusätzliche Kosten Neue SaaS- und API-Verbindungen sollten deshalb freigegeben und dokumentiert werden. --- **Typische Sicherheitsfehler** - Token besitzt Administratorrechte - API-Key steht direkt im Workflow - Testworkflow verwendet Produktivdaten - Webhook besitzt keine Authentifizierung - Logs enthalten Passwörter - ausgeschiedener Mitarbeiter besitzt noch Zugänge - Integration verwendet persönliches Konto - nicht benötigte Daten werden übertragen - alte Tokens bleiben aktiv - Fehlerpfade geben vertrauliche Daten aus --- **Praxisbeispiel: Sicheres Onboarding** Möglicher Ablauf: 1. Webhook-Signatur prüfen 2. Event-ID auf Duplikat prüfen 3. Pflichtfelder validieren 4. nur benötigte Mitarbeiterdaten übernehmen 5. Service Account mit begrenzten Scopes verwenden 6. Benutzerkonto ohne Administratorrechte anlegen 7. Gruppen anhand der Abteilung zuweisen 8. MFA-Einrichtung anfordern 9. Ergebnis ohne Secrets protokollieren 10. bei kritischem Fehler IT informieren --- **Sicherheitsprüfung vor Veröffentlichung** Vor der Aktivierung eines Workflows sollte geprüft werden: - Welche Daten werden verarbeitet? - Werden nur notwendige Daten verwendet? - Welche Systeme sind verbunden? - Welche Rechte besitzen die Credentials? - Sind Secrets geschützt gespeichert? - Wird HTTPS verwendet? - Sind Webhooks abgesichert? - Werden Eingabedaten validiert? - Können doppelte Ausführungen entstehen? - Enthalten Logs vertrauliche Daten? - Existiert eine Fehlerbehandlung? - Sind Test- und Produktivsystem getrennt? - Gibt es einen verantwortlichen Ansprechpartner? --- **Systematische Fehlersuche** Bei einem Sicherheits- oder Berechtigungsproblem: 1. Welches Konto oder Token wird verwendet? 2. Welche Rolle besitzt der Zugang? 3. Welche Scopes wurden vergeben? 4. Ist der Zugang noch erforderlich? 5. Ist das Secret gültig? 6. Wurde das Secret möglicherweise veröffentlicht? 7. Wird HTTPS verwendet? 8. Welche Daten werden übertragen? 9. Enthalten Logs vertrauliche Informationen? 10. Ist der Webhook authentifiziert? 11. Wurden Test- und Produktivzugänge verwechselt? 12. Welche Aktion zeigt das Audit-Log? 13. Muss ein Token sofort widerrufen werden? 14. Müssen betroffene Personen informiert werden? --- **Wichtige Begriffe** | Begriff | Bedeutung | |---|---| | Least Privilege | nur notwendige Rechte vergeben | | RBAC | rollenbasierte Zugriffskontrolle | | Scope | begrenzte API-Berechtigung | | Service Account | technisches Benutzerkonto | | Secret | vertrauliche Zugangsinformation | | Rotation | Secret durch neues Secret ersetzen | | Datenminimierung | nur notwendige Daten verarbeiten | | Zweckbindung | Daten nur für festgelegten Zweck verwenden | | Audit-Log | Protokoll sicherheitsrelevanter Aktionen | | Vier-Augen-Prinzip | zweite Person prüft kritische Aktion | | Schatten-IT | nicht freigegebene Software oder Dienste | | TLS | verschlüsselte Netzwerkübertragung | --- **Gesamtmerksatz** > Sichere Automatisierungen verwenden begrenzte Rollen und Scopes, geschützte Secrets, verschlüsselte Verbindungen und geprüfte Eingangsdaten. Sie verarbeiten nur notwendige Informationen, protokollieren keine Geheimnisse und trennen Test- von Produktivsystemen. --- **Kontrollfragen** **Was bedeutet Least Privilege?** Benutzer, Anwendungen und Workflows erhalten nur die Rechte, die sie tatsächlich benötigen. **Was ist RBAC?** Berechtigungen werden anhand festgelegter Rollen vergeben. **Was ist ein Service Account?** Ein technisches Benutzerkonto für Anwendungen und automatisierte Prozesse. **Was ist ein Secret?** Eine vertrauliche Zugangsinformation wie Passwort, API-Key oder Token. **Was bedeutet Datenminimierung?** Es werden nur die für den Zweck notwendigen Daten verarbeitet. **Warum sollten persönliche Administratorkonten nicht für Workflows verwendet werden?** Weil Rechte häufig zu umfangreich sind und die Integration vom einzelnen Mitarbeiter abhängig wird. **Warum müssen Test- und Produktivsysteme getrennt werden?** Damit Tests keine unbeabsichtigten Änderungen an echten Unternehmensdaten verursachen. **Was ist ein Audit-Log?** Ein Protokoll sicherheitsrelevanter Änderungen und Zugriffe. **Was bedeutet Secret Rotation?** Ein Schlüssel, Token oder Passwort wird durch ein neues Secret ersetzt. **Warum sollte ein Webhook eine Signaturprüfung besitzen?** Damit Herkunft und Unverändertheit der Nachricht überprüft werden können. --- **Quellen** - [BSI – IT-Grundschutz](https://www.bsi.bund.de/grundschutz) - [OWASP – Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) - [OWASP – Secrets Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html) - [OWASP – Logging Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html) - [NIST – Least Privilege](https://csrc.nist.gov/glossary/term/least_privilege) - [n8n-Dokumentation – Credentials](https://docs.n8n.io/credentials/) ``` # 2.13 Praxisprojekt – Automatisiertes Onboarding und Offboarding Beim Onboarding erhält ein neuer Mitarbeiter die benötigten Benutzerkonten, Geräte, Rollen und Zugriffsrechte. Beim Offboarding werden diese Zugänge kontrolliert entzogen, Daten gesichert und Lizenzen freigegeben. Beide Prozesse eignen sich gut für eine teilweise Automatisierung. > Onboarding richtet Zugänge ein. Offboarding entfernt oder überträgt sie kontrolliert. --- **Lernziele** Nach dieser Seite solltest du erklären können: - wie ein automatisiertes Onboarding aufgebaut ist - welche Schritte beim Offboarding notwendig sind - welche Systeme beteiligt sein können - welche Daten benötigt werden - welche Schritte automatisiert werden dürfen - wo Freigaben notwendig sind - wie Fehler und Teilerfolge behandelt werden - welche Sicherheitsregeln gelten --- **Beteiligte Systeme** Ein Onboarding- oder Offboarding-Prozess kann mehrere Systeme verbinden. Beispiele: | System | Aufgabe | |---|---| | Personalsystem | liefert Mitarbeiterdaten | | n8n | steuert den Workflow | | Google Workspace | E-Mail, Kalender und Benutzerkonto | | Slack | interne Kommunikation | | Projektmanagement-System | Aufgaben und Projekte | | Ticketsystem | Hardware- und Supportaufgaben | | Geräteverwaltung | Laptop und Smartphone | | CRM-System | Zugriff für Vertrieb oder Kundenbetreuung | | Dokumentation | Protokoll und Anleitungen | --- **Benötigte Eingangsdaten** Typische Onboarding-Daten: { "employeeId": "EMP-105", "firstName": "Max", "lastName": "Mustermann", "email": "max.mustermann@example.com", "department": "IT", "role": "IT Support", "startDate": "2026-08-03", "manager": "Teamleitung IT" } Wichtige Pflichtfelder: - eindeutige Mitarbeiter-ID - Vorname - Nachname - dienstliche E-Mail-Adresse - Abteilung - Rolle - Startdatum - zuständige Führungskraft --- **Onboarding-Ablauf** Ein möglicher automatisierter Ablauf: Mitarbeiter freigegeben | v Webhook an n8n | v Daten validieren | v doppelte Verarbeitung prüfen | v Freigabe vorhanden? / \ nein ja | | v v stoppen Konto anlegen | v Gruppen zuweisen | v Lizenzen vergeben | v IT-Aufgabe erstellen | v Slack informieren | v Ergebnis protokollieren --- **Schritt 1: Trigger** Der Workflow startet beispielsweise durch: - Webhook aus dem Personalsystem - neue Zeile in einer Datenquelle - freigegebenes Formular - manuelle Ausführung - festgelegten Zeitplan Beispielereignis: { "eventId": "evt-20015", "event": "employee.approved" } Die Event-ID verhindert eine doppelte Verarbeitung. --- **Schritt 2: Daten validieren** Vor der Verarbeitung werden geprüft: - Pflichtfelder vorhanden - E-Mail-Adresse gültig - Startdatum plausibel - Abteilung bekannt - Rolle erlaubt - Mitarbeiter-ID eindeutig - keine unerlaubten Sonderzeichen - keine unnötigen Daten enthalten Fehlerhafte Daten dürfen nicht automatisch weiterverarbeitet werden. --- **Schritt 3: Vorhandene Konten prüfen** Vor dem Anlegen sollte geprüft werden, ob bereits ein Konto existiert. Beispiel: GET /users?email=max.mustermann@example.com Mögliche Ergebnisse: | Ergebnis | Reaktion | |---|---| | kein Konto vorhanden | Benutzer anlegen | | Konto vorhanden | Workflow stoppen oder prüfen | | mehrere Treffer | manuelle Bearbeitung | | API-Fehler | Fehlerpfad starten | Dadurch werden doppelte Benutzerkonten vermieden. --- **Schritt 4: Benutzerkonto anlegen** Beispiel: POST /users { "name": "Max Mustermann", "email": "max.mustermann@example.com", "department": "IT", "active": true } Mögliche Response: Status: 201 Created { "id": 105, "email": "max.mustermann@example.com" } Die neue Benutzer-ID sollte gespeichert werden. --- **Schritt 5: Gruppen und Rollen zuweisen** Die Abteilung kann bestimmen, welche Gruppen benötigt werden. Beispiel: | Abteilung | Gruppen | |---|---| | IT | Mitarbeitende, IT-Support | | Vertrieb | Mitarbeitende, CRM | | Buchhaltung | Mitarbeitende, Finance | | Projektmanagement | Mitarbeitende, Projekte | Beispielablauf: Abteilung prüfen / | \ IT Vertrieb Buchhaltung | | | v v v IT-Gruppe CRM Finance Berechtigungen müssen nach dem Least-Privilege-Prinzip vergeben werden. --- **Schritt 6: Lizenzen vergeben** Mögliche Lizenzen: - Google Workspace - Slack - Projektmanagement-System - CRM-System - Office-Anwendungen - VPN - weitere Fachsoftware Vor der Vergabe sollte geprüft werden: - Wird die Lizenz wirklich benötigt? - Welche Lizenzstufe ist erforderlich? - Sind noch freie Lizenzen vorhanden? - Ist die Lizenz kostenpflichtig? - Muss eine Freigabe erfolgen? --- **Schritt 7: Hardware-Aufgabe erstellen** Eine Aufgabe kann automatisch im Ticketsystem angelegt werden. Beispiel: { "title": "Laptop für Max Mustermann vorbereiten", "department": "IT", "startDate": "2026-08-03", "priority": "normal" } Mögliche Teilaufgaben: - Laptop auswählen - Betriebssystem aktualisieren - Software installieren - Festplattenverschlüsselung prüfen - Geräteeigentümer eintragen - MFA vorbereiten - Übergabe dokumentieren --- **Schritt 8: Benachrichtigung senden** Nach erfolgreicher Vorbereitung kann eine Nachricht gesendet werden. Beispiel: Onboarding für Max Mustermann wurde vorbereitet. Konto: erstellt Gruppen: zugewiesen Hardware-Aufgabe: erstellt Startdatum: 03.08.2026 Die Nachricht darf keine Passwörter, Tokens oder vertraulichen Personaldaten enthalten. --- **Schritt 9: Ergebnis protokollieren** Protokolliert werden sollten: - Mitarbeiter-ID - Zeitpunkt - ausgeführte Schritte - erstellte Konten - zugewiesene Gruppen - vergebene Lizenzen - fehlgeschlagene Schritte - zuständige Person - Workflow-Ausführung Beispiel: | Schritt | Ergebnis | |---|---| | Benutzerkonto | erfolgreich | | IT-Gruppe | erfolgreich | | Slack-Zugang | erfolgreich | | Hardware-Ticket | erfolgreich | | MFA | noch offen | --- **Manuelle Freigaben** Nicht jeder Schritt sollte vollständig automatisch erfolgen. Freigaben können sinnvoll sein bei: - Administratorrechten - Zugriff auf Finanzsysteme - Zugriff auf sensible Kundendaten - teuren Softwarelizenzen - besonderen Sicherheitsrollen - externen Benutzerkonten - privilegierten VPN-Zugängen Beispiel: Rolle "Administrator" angefordert | v Freigabe notwendig / \ nein ja | | v v ablehnen zuweisen --- **Offboarding** Ein Offboarding beginnt, wenn ein Mitarbeiter das Unternehmen verlässt oder keinen Zugriff mehr benötigt. Typische Eingangsdaten: { "employeeId": "EMP-105", "email": "max.mustermann@example.com", "endDate": "2027-01-22", "manager": "Teamleitung IT" } --- **Offboarding-Ablauf** Austritt freigegeben | v Identität prüfen | v Zeitpunkt festlegen | v aktive Sitzungen beenden | v Benutzerkonto sperren | v Tokens widerrufen | v Gruppen entfernen | v Daten übertragen | v Lizenzen freigeben | v Geräte zurückfordern | v Vorgang dokumentieren --- **Konto deaktivieren statt sofort löschen** Benutzerkonten sollten häufig zuerst deaktiviert werden. Vorteile: - Daten bleiben erhalten - E-Mails können übertragen werden - Audit-Logs bleiben nachvollziehbar - Konto kann bei Fehlern wieder aktiviert werden - Abhängigkeiten können geprüft werden Beispiel: PATCH /users/105 { "active": false } Eine endgültige Löschung kann später nach internen Regeln erfolgen. --- **Aktive Sitzungen beenden** Beim Offboarding sollten aktive Sitzungen beendet werden. Dazu gehören: - Browser-Sitzungen - mobile Apps - Desktop-Anwendungen - VPN-Verbindungen - gespeicherte Anmeldungen - OAuth-Verbindungen Nur das Passwort zu ändern reicht möglicherweise nicht aus. --- **Tokens und API-Zugänge widerrufen** Zu prüfen sind: - API-Keys - Bearer-Tokens - Refresh Tokens - persönliche Zugriffstokens - SSH-Schlüssel - VPN-Zertifikate - App-Passwörter Persönliche Tokens dürfen nach dem Austritt nicht aktiv bleiben. --- **Datenübertragung** Vor der Sperrung oder Löschung können Daten übertragen werden. Beispiele: - E-Mails an Führungskraft übertragen - Dateien einem Team zuweisen - Kalendertermine übergeben - Projekte neu zuordnen - offene Aufgaben übertragen - persönliche Freigaben entfernen Der Verantwortliche für die Datenübernahme muss festgelegt sein. --- **Lizenzen freigeben** Nach dem Offboarding können Lizenzen entfernt und erneut vergeben werden. Beispiele: - Google Workspace - CRM - Projektmanagement - Office - VPN - Fachsoftware Dadurch werden unnötige Kosten vermieden. --- **Geräte und Hardware** Zu prüfen sind: - Laptop zurückgegeben - Smartphone zurückgegeben - Sicherheitsschlüssel zurückgegeben - Zugangskarte deaktiviert - lokale Daten gesichert - Gerät zurückgesetzt - Inventarsystem aktualisiert Der Workflow kann dafür automatisch Aufgaben erstellen, die eigentliche Übergabe erfolgt jedoch manuell. --- **Zeitgesteuertes Offboarding** Ein Offboarding kann für einen bestimmten Zeitpunkt vorbereitet werden. Beispiel: > Konto am letzten Arbeitstag um 18:00 Uhr deaktivieren. Dabei müssen Zeitzone und Austrittszeitpunkt eindeutig sein. Kritische Zugänge können auch sofort gesperrt werden, wenn: - ein Sicherheitsvorfall besteht - der Austritt kurzfristig erfolgt - Missbrauch vermutet wird - eine ausdrückliche Anweisung vorliegt --- **Teilerfolge behandeln** Beispiel: | Schritt | Ergebnis | |---|---| | Konto deaktiviert | erfolgreich | | Sitzungen beendet | erfolgreich | | Slack-Zugang entfernt | fehlgeschlagen | | Datenübertragung | noch offen | | Lizenz entfernt | nicht ausgeführt | Der Vorgang ist nicht vollständig abgeschlossen. Der Workflow sollte: - fehlgeschlagene Schritte markieren - abhängige Aktionen prüfen - IT benachrichtigen - manuelle Aufgabe erstellen - Teilerfolg dokumentieren --- **Fehlerbehandlung** Mögliche Fehler: - Benutzer nicht gefunden - mehrere Benutzer mit gleicher E-Mail - fehlende Berechtigung - API nicht erreichbar - Konto bereits deaktiviert - Datenübertragung nicht möglich - zuständige Führungskraft fehlt - Lizenzsystem antwortet nicht Behandlung: Fehler erkannt | v sicherheitskritisch? / \ ja nein | | v v sofort Retry oder eskalieren Aufgabe erstellen --- **Rollback** Beim Onboarding kann ein Rollback sinnvoll sein. Beispiel: 1. Konto wurde angelegt. 2. erforderliche Sicherheitsgruppe konnte nicht zugewiesen werden. 3. Konto wird vorsorglich deaktiviert. 4. IT erhält eine Fehlermeldung. Beim Offboarding ist ein vollständiger Rollback häufig schwieriger. Deshalb sollten kritische Schritte gut dokumentiert und möglichst reversibel sein. --- **Sicherheitsregeln** - Service Account verwenden - nur notwendige Scopes vergeben - keine Passwörter in Logs speichern - Webhook authentifizieren - Event-ID prüfen - Eingabedaten validieren - Administratorrechte nur nach Freigabe - Test- und Produktivsysteme trennen - sensible Daten minimieren - alle wichtigen Änderungen protokollieren --- **Praxisablauf Onboarding** 1. Personalsystem sendet Webhook. 2. Signatur und Event-ID werden geprüft. 3. Pflichtfelder werden validiert. 4. Vorhandenes Konto wird gesucht. 5. Benutzerkonto wird angelegt. 6. Gruppen werden anhand der Abteilung zugewiesen. 7. notwendige Lizenzen werden vergeben. 8. Hardware-Ticket wird erstellt. 9. IT wird benachrichtigt. 10. Ergebnis wird protokolliert. 11. offene Schritte werden markiert. --- **Praxisablauf Offboarding** 1. Austritt wird freigegeben. 2. Benutzerkonto wird eindeutig identifiziert. 3. Zeitpunkt der Sperrung wird geprüft. 4. Sitzungen und Tokens werden widerrufen. 5. Konto wird deaktiviert. 6. Gruppen und Rollen werden entfernt. 7. Daten und Aufgaben werden übertragen. 8. Lizenzen werden freigegeben. 9. Geräteaufgabe wird erstellt. 10. Abschluss wird dokumentiert. 11. offene Punkte werden eskaliert. --- **Systematische Fehlersuche** Wenn ein Onboarding oder Offboarding fehlschlägt: 1. Wurde der richtige Trigger ausgelöst? 2. Ist die Event-ID eindeutig? 3. Sind alle Pflichtfelder vorhanden? 4. Ist der Benutzer eindeutig identifizierbar? 5. Existiert bereits ein Konto? 6. Sind die Credentials gültig? 7. Besitzt der Service Account ausreichende Rechte? 8. Welche Node ist fehlgeschlagen? 9. Welcher Statuscode wurde zurückgegeben? 10. Welche Schritte waren bereits erfolgreich? 11. Besteht ein Sicherheitsrisiko? 12. Ist ein Retry gefahrlos möglich? 13. Muss das Konto vorsorglich deaktiviert werden? 14. Welche manuelle Aufgabe muss erstellt werden? --- **Wichtige Begriffe** | Begriff | Bedeutung | |---|---| | Onboarding | technische Einrichtung eines Mitarbeiters | | Offboarding | kontrollierter Entzug von Zugängen | | Event-ID | eindeutige Kennung eines Ereignisses | | Service Account | technischer Benutzer für Automatisierungen | | Freigabe | bestätigte Erlaubnis für eine Aktion | | Deaktivierung | Zugang sperren, Daten zunächst erhalten | | Datenübertragung | Übergabe von Dateien, E-Mails oder Aufgaben | | Teilerfolg | nur ein Teil des Prozesses war erfolgreich | | Rollback | bereits ausgeführte Änderungen zurücknehmen | | Inventarsystem | verwaltet Geräte und Eigentümer | --- **Gesamtmerksatz** > Ein automatisiertes Onboarding legt Benutzerkonten, Gruppen, Lizenzen und Aufgaben nach festgelegten Regeln an. Beim Offboarding werden Sitzungen, Tokens, Rollen und Zugänge kontrolliert entfernt, Daten übertragen und Lizenzen freigegeben. Kritische Rechte benötigen Freigaben und jeder Schritt muss nachvollziehbar protokolliert werden. --- **Kontrollfragen** **Was ist Onboarding?** Die technische Einrichtung eines neuen Mitarbeiters. **Was ist Offboarding?** Der kontrollierte Entzug von Konten, Rechten und Zugängen beim Austritt. **Warum sollte vor dem Anlegen eines Kontos gesucht werden?** Damit kein doppeltes Benutzerkonto entsteht. **Warum wird ein Konto häufig zunächst deaktiviert statt gelöscht?** Damit Daten, Protokolle und Abhängigkeiten erhalten bleiben. **Welche Schritte benötigen häufig eine manuelle Freigabe?** Administratorrechte, sensible Datenzugriffe und kostenintensive Lizenzen. **Warum müssen aktive Sitzungen beendet werden?** Weil ein Benutzer trotz Passwortänderung noch angemeldet sein könnte. **Was muss mit persönlichen API-Tokens geschehen?** Sie müssen widerrufen werden. **Was ist ein Teilerfolg?** Einige Schritte wurden erfolgreich ausgeführt, andere sind fehlgeschlagen. **Warum ist die Event-ID wichtig?** Sie verhindert eine doppelte Verarbeitung desselben Vorgangs. **Warum dürfen Passwörter nicht im Workflow-Log stehen?** Weil Logs sonst selbst zu einem Sicherheitsrisiko werden. --- **Quellen** - [NIST – Least Privilege](https://csrc.nist.gov/glossary/term/least_privilege) - [OWASP – Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) - [OWASP – Secrets Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html) - [n8n-Dokumentation – Workflows](https://docs.n8n.io/workflows/) - [n8n-Dokumentation – Error Handling](https://docs.n8n.io/flow-logic/error-handling/) ``` # 2.14 Fehlersuche und Dokumentation von Schnittstellen APIs und automatisierte Workflows verbinden mehrere technische Systeme miteinander. Tritt ein Fehler auf, muss geprüft werden: - welches System betroffen ist - an welcher Stelle der Fehler sichtbar wird - wo die eigentliche Ursache liegt - welche Daten übertragen wurden - welcher Statuscode zurückgegeben wurde - ob Authentifizierung und Berechtigungen stimmen - welche Änderungen zuletzt durchgeführt wurden - ob mehrere Teilsysteme gemeinsam den Fehler erzeugen > Eine Fehlermeldung zeigt häufig nur, wo ein Problem sichtbar wird – nicht zwingend, wo seine Ursache liegt. --- **Lernziele** Nach dieser Seite solltest du erklären können: - wie Schnittstellenfehler systematisch untersucht werden - warum Fehler häufig erst im Zusammenspiel entstehen - wie Anforderungen, Datenformate und Abhängigkeiten Fehler verursachen - wie Komponenten-, Integrations- und Systemtests unterschieden werden - wie Logs und Statuscodes ausgewertet werden - was eine Schnittstellendokumentation enthalten sollte - wie Störungen nachvollziehbar dokumentiert und übergeben werden --- **Fehler zuerst eingrenzen** Vor der technischen Analyse sollte geklärt werden: - Was funktioniert nicht? - Was sollte stattdessen passieren? - Seit wann besteht der Fehler? - Wer oder was ist betroffen? - Tritt der Fehler immer oder nur gelegentlich auf? - Funktionieren die einzelnen Teilsysteme? - Wurde vorher etwas verändert? - Welche Fehlermeldung wird angezeigt? Genaue Beschreibung: > Der Workflow startet, aber die Gruppenzuweisung schlägt nach der erfolgreichen Benutzeranlage fehl. Ungenaue Beschreibung: > Die API funktioniert nicht. --- **Fehlerkategorien** | Fehlerbereich | Beispiel | |---|---| | Anforderung | gewünschtes Verhalten wurde unterschiedlich verstanden | | Trigger | Webhook startet den Workflow nicht | | Software | fehlerhafte Logik oder Konfiguration | | Elektronik | Sensor-, Signal- oder Spannungsproblem | | Mechanik | Verschleiß, Blockierung oder falsche Ausrichtung | | Netzwerk | DNS-Fehler, geschlossener Port oder Paketverlust | | TLS | Zertifikat wird nicht akzeptiert | | Authentifizierung | Token fehlt oder ist abgelaufen | | Autorisierung | Rolle oder Scope fehlt | | Request | Methode, Endpoint oder Body ist falsch | | Daten | Pflichtfeld oder Datentyp ist falsch | | Timing | Folgeschritt wird zu früh ausgeführt | | Zielsystem | API antwortet mit einem Serverfehler | | Workflow-Logik | Bedingung oder Datenmapping ist falsch | | Rate Limit | zu viele Anfragen wurden gesendet | | Abhängigkeit | nachgelagerter Dienst ist ausgefallen | --- **Fehler entstehen häufig im Zusammenspiel** Theoretisch kann die Ursache eines technischen Problems in einem einzelnen Bereich liegen: - Software - Elektronik - Mechanik - Netzwerk - Konfiguration - Bedienung In der Praxis entstehen viele Fehler jedoch erst durch das Zusammenspiel mehrerer Komponenten. Einzelne Teilsysteme können für sich betrachtet korrekt funktionieren. Sobald sie miteinander verbunden werden, können dennoch unerwartete Probleme auftreten. > Ein funktionierendes Einzelteil garantiert noch kein funktionierendes Gesamtsystem. Häufige Ursachen: - unterschiedliche Interpretation von Anforderungen - fehlerhafte Schnittstellen - unterschiedliche Datenformate - falsche Einheiten - zeitliche Abhängigkeiten - falsche Reihenfolge - versteckte Systemabhängigkeiten - gegenseitige Beeinflussung mehrerer Workflows - nicht berücksichtigte Systemzustände --- **Fehlerstelle und Fehlerursache** Die sichtbare Fehlermeldung muss nicht aus dem Bereich stammen, in dem die eigentliche Ursache liegt. Beispiel aus einem technischen System: 1. Ein mechanisches Bauteil bewegt sich schwergängig. 2. Der Motor benötigt dadurch mehr Strom. 3. Die Elektronik erkennt eine Überlastung. 4. Die Steuerungssoftware schaltet das System ab. 5. Die Software zeigt eine Fehlermeldung an. Die Meldung erscheint in der Software. Die eigentliche Ursache liegt jedoch in der Mechanik. Beispiel aus der IT: 1. Eine Datenbank ist nicht erreichbar. 2. Die Anwendung kann keine Benutzerdaten laden. 3. Die API antwortet mit `500 Internal Server Error`. 4. Der n8n-Workflow meldet einen fehlgeschlagenen API-Aufruf. Der Fehler wird in n8n sichtbar. Die Ursache liegt jedoch bei der Datenbank. > Die Stelle, an der ein Fehler sichtbar wird, ist nicht zwingend die Stelle seiner Ursache. --- **Unterschiedliche Interpretation von Anforderungen** Anforderungen müssen eindeutig und überprüfbar formuliert sein. Unklare Anforderung: > Ein Benutzer soll beim Austritt automatisch deaktiviert werden. Mögliche Interpretationen: - sofort nach der Mitteilung - am letzten Arbeitstag - am Ende des letzten Arbeitstags - erst nach der Datenübertragung - nur im Hauptsystem - gleichzeitig in allen verbundenen Systemen Alle beteiligten Systeme könnten technisch korrekt funktionieren. Der Gesamtprozess wäre trotzdem falsch, wenn die Anforderung unterschiedlich verstanden wurde. Mögliche Folgen: - Konto wird zu früh gesperrt - Konto bleibt zu lange aktiv - Daten können nicht mehr übertragen werden - einzelne Zugänge bleiben bestehen - Lizenzen werden nicht freigegeben > Unklare Anforderungen führen häufig zu technisch korrekten, aber fachlich falschen Lösungen. --- **Fehler an Schnittstellen** Eine Schnittstelle verbindet zwei Systeme oder Komponenten miteinander. An einer Schnittstelle müssen beide Seiten dieselben Vereinbarungen verwenden. Dazu gehören: - Datenformat - Feldnamen - Datentypen - Einheiten - Protokoll - Zeichencodierung - Zeitformat - Zeitzone - Reihenfolge - Authentifizierung - erwartete Response - Fehlerbehandlung --- **Beispiel: Unterschiedliche Datentypen** Quellsystem: { "active": "true" } Zielsystem erwartet: { "active": true } Unterschied: - `"true"` ist ein String - `true` ist ein Boolean Beide Systeme können einzeln korrekt arbeiten. Der Fehler entsteht durch unterschiedliche Erwartungen an der Schnittstelle. --- **Beispiel: Unterschiedliche Feldnamen** Quellsystem: { "mail": "max.mustermann@example.com" } Zielsystem erwartet: { "primaryEmail": "max.mustermann@example.com" } Ohne korrektes Datenmapping kann das Zielsystem die E-Mail-Adresse nicht zuordnen. --- **Beispiel: Unterschiedliche Einheiten** Ein Sensor überträgt: 1500 Millivolt Die Software interpretiert den Wert als: 1500 Volt Der Messwert wurde korrekt übertragen, aber falsch interpretiert. Weitere mögliche Verwechslungen: - Millimeter und Zentimeter - Byte und Bit - Kilobyte und Kibibyte - Sekunden und Millisekunden - Celsius und Fahrenheit - UTC und lokale Zeit --- **Fehler durch Reihenfolge und Timing** Manche Fehler entstehen nur, weil Schritte zu früh, zu spät oder in der falschen Reihenfolge ausgeführt werden. Beispiel: 1. Ein Benutzerkonto wird angelegt. 2. Das Zielsystem benötigt einige Sekunden für die Bereitstellung. 3. Der Workflow versucht sofort, den Benutzer einer Gruppe hinzuzufügen. 4. Das Zielsystem kennt den neuen Benutzer noch nicht vollständig. 5. Die Gruppenzuweisung schlägt fehl. Die einzelnen Funktionen arbeiten korrekt. Das Problem entsteht durch das Timing zwischen den Schritten. Mögliche Lösungen: - Verfügbarkeit abfragen - Status des Vorgangs prüfen - auf ein Folgeereignis warten - begrenzten Retry verwenden - Backoff einsetzen - notwendige Wartezeit einbauen > Ein erfolgreicher API-Request bedeutet nicht immer, dass das Ergebnis sofort in allen Teilsystemen verfügbar ist. --- **Abhängigkeiten zwischen Systemen** Ein System kann von mehreren weiteren Diensten abhängig sein. Beispiel: n8n | v API | v Benutzerverwaltung | v Datenbank Fällt die Datenbank aus, meldet möglicherweise die API einen Fehler. n8n zeigt dann einen fehlgeschlagenen API-Aufruf an, obwohl die Ursache in der Datenbank liegt. Mögliche Abhängigkeiten: - DNS - Datenbank - Authentifizierungsdienst - Reverse Proxy - Firewall - TLS-Zertifikat - Cloud-Dienst - Speicher - Warteschlange - externer Anbieter --- **Verkettete Fehler** Ein einzelner Fehler kann mehrere Folgefehler auslösen. Beispiel: 1. DNS-Auflösung schlägt fehl. 2. API ist nicht erreichbar. 3. Benutzerkonto wird nicht angelegt. 4. Gruppenzuweisung kann nicht stattfinden. 5. Hardware-Aufgabe wird nicht erstellt. 6. Mehrere Workflow-Schritte melden Fehler. Die gemeinsame Ursache ist der DNS-Fehler. > Mehrere Fehlermeldungen können dieselbe gemeinsame Ursache besitzen. Deshalb sollte zuerst der früheste fehlgeschlagene Schritt untersucht werden. --- **Emergentes Verhalten** Emergentes Verhalten bedeutet: > Das Gesamtsystem zeigt ein Verhalten, das bei der getrennten Betrachtung der Einzelteile nicht erkennbar war. Beispiele: - zwei funktionierende Dienste erzeugen gemeinsam eine Endlosschleife - mehrere automatische Retries überlasten das Zielsystem - zwei Synchronisierungen überschreiben gegenseitig Änderungen - mehrere Zeitpläne starten denselben Prozess gleichzeitig - einzeln korrekte Regeln erzeugen gemeinsam falsche Berechtigungen Emergentes Verhalten entsteht nicht zwingend durch eine defekte Komponente. Es kann durch die Verbindung, Reihenfolge oder gegenseitige Beeinflussung entstehen. --- **Beispiel: Gegenseitige Synchronisierung** System A synchronisiert Daten zu System B. System B synchronisiert dieselben Daten zurück zu System A. System A ändert Datensatz | v System B übernimmt Änderung | v System B meldet Änderung zurück | v System A verarbeitet sie erneut Mögliche Folgen: - Endlosschleife - unnötige API-Anfragen - Rate Limit - doppelte Benachrichtigungen - widersprüchliche Daten Mögliche Schutzmaßnahmen: - führendes Quellsystem festlegen - eindeutige Änderungs-ID verwenden - Herkunft der Änderung speichern - eigene Änderungen nicht erneut verarbeiten - Zeitstempel oder Versionen vergleichen --- **Komponententest** Ein Komponententest prüft eine einzelne Funktion oder Komponente. Beispiele: - API-Endpoint einzeln testen - JSON-Validierung prüfen - einzelne n8n-Node ausführen - Datenbankverbindung testen - Sensor einzeln prüfen Ziel: > Funktioniert die einzelne Komponente für sich? --- **Integrationstest** Ein Integrationstest prüft das Zusammenspiel mehrerer Komponenten. Beispiele: - n8n überträgt Daten an eine API - ein Personalsystem sendet einen Webhook - die Benutzerverwaltung weist eine Gruppe zu - eine Anwendung speichert Daten in einer Datenbank Ziel: > Funktionieren die Schnittstellen zwischen den Komponenten? --- **Systemtest** Ein Systemtest prüft den vollständigen Ablauf unter realistischen Bedingungen. Beispiel: Mitarbeiter wird freigegeben | v Webhook wird gesendet | v Benutzerkonto wird angelegt | v Gruppen werden zugewiesen | v Hardware-Aufgabe wird erstellt | v Ergebnis wird protokolliert Ziel: > Funktioniert das vollständige Gesamtsystem? --- **Abnahmetest** Ein Abnahmetest prüft, ob die tatsächlichen fachlichen Anforderungen erfüllt werden. Beispiele: - Konto wird zum richtigen Zeitpunkt aktiviert - notwendige Rechte werden vergeben - unnötige Rechte werden nicht vergeben - Fehler werden korrekt gemeldet - Datenschutzanforderungen werden eingehalten - zuständige Personen erhalten die benötigten Informationen Ziel: > Erfüllt die Lösung den vorgesehenen Zweck? --- **Testebenen im Überblick** | Testart | Geprüfter Bereich | |---|---| | Komponententest | einzelne Funktion oder Komponente | | Integrationstest | Verbindung zwischen Komponenten | | Systemtest | vollständiges Gesamtsystem | | Abnahmetest | fachliche Anforderungen | > Ein erfolgreicher Komponententest ersetzt keinen Integrationstest. --- **Grundregel der Fehlersuche** Empfohlene Reihenfolge: 1. fachliche Erwartung klären 2. Fehlerbild genau beschreiben 3. Trigger prüfen 4. Eingangsdaten prüfen 5. Netzwerk und Erreichbarkeit prüfen 6. Endpoint und HTTP-Methode prüfen 7. Authentifizierung prüfen 8. Berechtigungen prüfen 9. Header und Request-Body prüfen 10. Statuscode und Response auswerten 11. Reihenfolge und Timing prüfen 12. Systemabhängigkeiten untersuchen 13. letzte Änderungen kontrollieren 14. Integration und Gesamtsystem testen > Von außen nach innen prüfen: Erwartung, Auslösung, Verbindung, Zugang, Daten und Verarbeitung. --- **Trigger prüfen** Zu prüfen sind: - Ist der Workflow aktiv? - Wurde das Ereignis ausgelöst? - Ist die Webhook-URL korrekt? - Wird die richtige HTTP-Methode verwendet? - Ist der Zeitplan korrekt? - Ist die richtige Zeitzone eingestellt? - Wurde das Ereignis als Duplikat abgelehnt? - Wurde die Test- oder Produktiv-URL verwendet? --- **Eingangsdaten prüfen** Zu prüfen sind: - Sind alle Pflichtfelder vorhanden? - Sind Felder leer oder `null`? - Stimmen die Datentypen? - Ist die JSON-Struktur korrekt? - Stimmen die Feldnamen? - Enthalten Werte unerwartete Leerzeichen? - Entsprechen die Daten der Dokumentation? Beispiel: Erwartet: { "active": true } Empfangen: { "active": "true" } --- **Erreichbarkeit prüfen** Mögliche Probleme: - DNS-Auflösung fehlerhaft - Port geschlossen - Firewall blockiert - Proxy falsch konfiguriert - Container oder Dienst gestoppt - Zielsystem in Wartung - TLS-Zertifikat ungültig - Netzwerkroute fehlerhaft Wichtig: > Wird keine HTTP-Response empfangen, existiert auch kein HTTP-Statuscode. Dann liegt möglicherweise ein Netzwerk-, DNS-, TLS- oder Verbindungsfehler vor. --- **Endpoint und HTTP-Methode prüfen** Beispiele: GET /users/15 ruft einen Benutzer ab. POST /users legt einen neuen Benutzer an. Typische Fehler: - falsche API-Version - falscher Ressourcenname - Schreibfehler in der URL - falsche Benutzer-ID - GET statt POST - PUT statt PATCH - nicht unterstützte HTTP-Methode --- **Authentifizierung prüfen** Zu prüfen sind: - Ist das Credential vorhanden? - Ist das richtige Credential ausgewählt? - Ist das Token gültig? - Ist das Token abgelaufen? - Wurde es widerrufen? - Ist der Authorization-Header korrekt? - Stimmen Client ID und Client Secret? Falsch: Authorization: abc123 Möglicherweise erforderlich: Authorization: Bearer abc123 Typischer Statuscode: 401 Unauthorized --- **Autorisierung prüfen** Die Identität kann gültig sein, obwohl eine Aktion nicht erlaubt ist. Zu prüfen sind: - Benutzerrolle - Gruppenmitgliedschaft - API-Scopes - Administratorfreigabe - Zugriff auf die konkrete Ressource - Least-Privilege-Konfiguration Typischer Statuscode: 403 Forbidden Merksatz: > 401 bedeutet: Identität nicht bestätigt. > 403 bedeutet: Identität bestätigt, aber Zugriff nicht erlaubt. --- **Header und Request-Body prüfen** Typische Header: Authorization: Bearer *** Content-Type: application/json Accept: application/json Typische Fehler: - `Content-Type` fehlt - falsches Datenformat - JSON syntaktisch ungültig - Pflichtfeld fehlt - Feldname ist falsch - falscher Datentyp - Body besitzt falsche Verschachtelung Beispiel: Gesendet: { "name": "Max Mustermann", "department": "IT" } Erwartet: { "user": { "name": "Max Mustermann", "department": "IT" } } --- **Statuscode auswerten** | Code | Typische Prüfung | |---:|---| | 200 | erwartete Daten vorhanden? | | 201 | Ressource tatsächlich erstellt? | | 400 | Request und Pflichtfelder prüfen | | 401 | Token und Authentifizierung prüfen | | 403 | Rolle und Scopes prüfen | | 404 | Endpoint und ID prüfen | | 409 | vorhandene Ressource prüfen | | 415 | `Content-Type` prüfen | | 422 | fachliche Daten prüfen | | 429 | Rate Limit und Wartezeit prüfen | | 500 | Zielsystem und Logs prüfen | | 502 | Proxy oder nachgelagerten Dienst prüfen | | 503 | Verfügbarkeit des Dienstes prüfen | | 504 | Timeout und Antwortzeit prüfen | Der Statuscode sollte immer gemeinsam mit dem Response-Body ausgewertet werden. --- **Response-Body prüfen** Beispiel: Status: 400 Bad Request { "error": "Missing required field", "field": "email" } Der Statuscode zeigt die allgemeine Fehlerklasse. Der Response-Body nennt häufig: - genaue Ursache - betroffenes Feld - interne Fehlerkennung - Request-ID - empfohlene Maßnahme --- **Logs verwenden** Logs können zeigen: - Zeitpunkt - Workflow-Ausführung - betroffene Node - Eingangsdaten - Ausgangsdaten - Statuscode - Fehlermeldung - Anzahl der Versuche - Ausführungsdauer Nicht vollständig protokollieren: - Passwörter - API-Keys - Bearer-Tokens - Refresh Tokens - Client Secrets - vertrauliche personenbezogene Daten --- **Fehler reproduzieren** Ein reproduzierbarer Fehler kann gezielt untersucht werden. Festgehalten werden sollten: - genaue Eingabedaten - verwendeter Endpoint - HTTP-Methode - relevante Header - Zeitpunkt - Statuscode - Response - betroffene API-Version - vorherige Änderungen - Reihenfolge der Schritte Ein Test sollte möglichst erfolgen mit: - Testkonto - Testdaten - Test-Endpoint - ungefährlicher Ressource - deaktivierten Löschaktionen --- **Einzelne Schritte testen** Ein komplexer Workflow sollte in kleinere Teile zerlegt werden. Empfohlene Vorgehensweise: 1. Trigger allein testen 2. Eingangsdaten prüfen 3. JSON validieren 4. Authentifizierung testen 5. GET-Anfrage ausführen 6. POST oder PATCH mit Testdaten ausführen 7. Response auswerten 8. Folgeschritte einzeln ergänzen 9. vollständigen Integrationstest durchführen 10. Gesamtsystem testen > Erst den kleinsten fehlerhaften Schritt finden, danach den vollständigen Ablauf prüfen. --- **Letzte Änderungen prüfen** Viele Fehler entstehen nach einer Änderung. Mögliche Änderungen: - neues Token - neue API-Version - geänderter Endpoint - neue Benutzerrolle - verändertes Datenmapping - aktualisierte n8n-Node - geänderte Firewall-Regel - neuer Proxy - neue Umgebungsvariable - Softwareupdate Zu dokumentieren sind: - Was wurde geändert? - Wann wurde es geändert? - Wer hat es geändert? - Warum wurde es geändert? - Wie wurde es getestet? - Wie kann die Änderung zurückgenommen werden? --- **Änderungen ganzheitlich prüfen** Eine kleine Änderung kann mehrere Systeme beeinflussen. Beispiel: Ein Feld wird von: department zu: departmentName umbenannt. Möglicherweise betroffen: - Webhook - Datenmapping - If-Node - Switch-Node - API-Request - Logging - Dokumentation - weitere Workflows Vor einer Änderung sollte deshalb geprüft werden: - Welche Systeme verwenden das Feld? - Welche Workflows sind abhängig? - Gibt es Testdaten? - Ist ein Rollback möglich? - Muss die Dokumentation angepasst werden? --- **Schnittstellendokumentation** Eine Schnittstellendokumentation beschreibt, wie zwei Systeme miteinander kommunizieren. Sie sollte enthalten: - Zweck der Schnittstelle - Quell- und Zielsystem - verantwortliche Personen - Trigger - Endpoints - HTTP-Methoden - Authentifizierungsverfahren - benötigte Scopes - Datenformat - Feldnamen - Datentypen - Einheiten - Zeitformat und Zeitzone - Datenmapping - Statuscodes - Fehlerbehandlung - Retry-Verhalten - Rate Limits - Logging - Datenschutz - Testverfahren - Wiederherstellungsverfahren --- **Beispiel einer Kurzdokumentation** | Bereich | Inhalt | |---|---| | Name | Mitarbeiter-Onboarding | | Zweck | Benutzerkonto automatisiert vorbereiten | | Quellsystem | Personalsystem | | Zielsystem | Benutzerverwaltung | | Automatisierung | n8n | | Trigger | Webhook | | Methode | POST | | Ressource | `/users` | | Datenformat | JSON | | Zeitformat | ISO 8601 | | Zeitzone | Europe/Berlin | | Authentifizierung | OAuth 2.0 | | Fehleralarm | Kanal `#it-support` | | Verantwortlich | interne IT | | Testsystem | separates Testkonto | --- **Datenmapping dokumentieren** | Quellfeld | Zielfeld | Datentyp | Pflicht | Beispiel | |---|---|---|---:|---| | `firstName` | `givenName` | String | ja | Max | | `lastName` | `familyName` | String | ja | Mustermann | | `mail` | `primaryEmail` | String | ja | max.mustermann@example.com | | `department` | `organization.department` | String | ja | IT | | `active` | `isActive` | Boolean | ja | `true` | | `startDate` | `custom.startDate` | Datum | nein | 2026-08-03 | --- **Workflow dokumentieren** Ein Workflow sollte folgende Angaben besitzen: - eindeutiger Name - kurze Beschreibung - verantwortliche Person - verwendete Credentials - Trigger - Eingaben - Verarbeitung - Ausgaben - Bedingungen - Fehlerpfad - Abhängigkeiten - letzte Änderung Guter Name: Mitarbeiter-Onboarding – Benutzerverwaltung Ungünstiger Name: Workflow Kopie Neu Final 3 --- **Node-Namen** Nodes sollten nach ihrer Funktion benannt werden. Gut: - `Webhook – Mitarbeiter empfangen` - `Pflichtfelder prüfen` - `Benutzer nach E-Mail suchen` - `Benutzerkonto anlegen` - `Gruppenzuweisung prüfen` - `Fehler an IT melden` Ungünstig: - `HTTP Request 4` - `If 2` - `Node Neu` - `Test Final` --- **Änderungsprotokoll** | Datum | Änderung | Verantwortlich | Ergebnis | |---|---|---|---| | 18.07.2026 | API-Endpoint aktualisiert | interne IT | erfolgreich getestet | | 19.07.2026 | neues Scope ergänzt | Administration | Freigabe dokumentiert | | 20.07.2026 | Fehlerpfad erweitert | interne IT | Test erfolgreich | Ein Änderungsprotokoll erleichtert die Fehlersuche nach Anpassungen. --- **Störungsdokumentation** Eine gute Störungsmeldung enthält: - kurze Fehlerbeschreibung - betroffene Systeme - Beginn der Störung - Auswirkung - Statuscode oder Fehlermeldung - bereits geprüfte Schritte - vorläufige Ursache - aktuelle Gegenmaßnahme - zuständige Person - nächster Schritt Beispiel: Fehler: Benutzer-Onboarding schlägt bei der Gruppenzuweisung fehl. Auswirkung: Benutzerkonto wird erstellt, Gruppe jedoch nicht zugewiesen. Statuscode: 403 Forbidden Bereits geprüft: Token gültig, Endpoint erreichbar, Benutzer vorhanden. Vermutete Ursache: benötigter Scope für Gruppenverwaltung fehlt. --- **Priorisierung von Störungen** | Priorität | Beispiel | |---|---| | niedrig | einzelner unkritischer Datensatz | | mittel | mehrere Benutzer betroffen | | hoch | wichtiger Geschäftsprozess ausgefallen | | kritisch | Sicherheitsvorfall oder Datenverlust | Zu berücksichtigen sind: - Anzahl betroffener Benutzer - betriebliche Auswirkung - Sicherheitsrisiko - möglicher Datenverlust - vorhandener Workaround - zeitliche Dringlichkeit --- **Übergabe an andere Mitarbeiter** Eine Übergabe sollte enthalten: - aktueller Stand - Fehlerursache, falls bekannt - bereits getestete Maßnahmen - offene Fragen - relevante Logs - betroffene Systeme - sichere Wiederholungsmöglichkeit - nächster empfohlener Schritt Schlechte Übergabe: > Funktioniert nicht. Bitte prüfen. Bessere Übergabe: > Der POST-Request an `/users` ist erfolgreich. Die anschließende Gruppenzuweisung antwortet mit 403. Token, Benutzer-ID und Endpoint wurden geprüft. Vermutlich fehlt der Scope für Gruppenänderungen. --- **Wiederherstellung** Vor größeren Änderungen sollte bekannt sein: - Gibt es ein Backup? - Kann der Workflow exportiert werden? - Kann eine alte Version wiederhergestellt werden? - Können Credentials zurückgesetzt werden? - Können Änderungen rückgängig gemacht werden? - Welche manuellen Schritte sind notwendig? Mögliche Maßnahmen: - Workflow-Version sichern - Konfiguration exportieren - Testlauf durchführen - Rollback dokumentieren - Änderungen schrittweise veröffentlichen --- **Praxisbeispiel: Fehlerhafte Benutzeranlage** Fehler: POST /users Status: 409 Conflict { "error": "Email already exists" } Systematische Prüfung: 1. Response wurde empfangen. 2. Endpoint und Methode sind korrekt. 3. Authentifizierung ist gültig. 4. E-Mail-Adresse existiert bereits. 5. vorhandenes Konto wird mit GET gesucht. 6. Datensatz wird nicht erneut angelegt. 7. Workflow erstellt eine manuelle Prüfaufgabe. 8. Ergebnis wird protokolliert. --- **Praxisbeispiel: Workflow startet nicht** Prüfung: 1. Workflow aktiv? 2. Webhook-URL korrekt? 3. Test- oder Produktiv-URL verwendet? 4. Quellsystem hat tatsächlich gesendet? 5. Firewall oder Proxy blockiert? 6. richtige HTTP-Methode? 7. Authentifizierung gültig? 8. Trigger-Log vorhanden? Mögliche Ursache: > Im Quellsystem wurde noch die Test-Webhook-URL verwendet. --- **Praxisbeispiel: Zusammenspiel mehrerer Workflows** Folgende Regeln gelten: - Workflow A deaktiviert Benutzer ohne Abteilung. - Workflow B entfernt beim Offboarding die Abteilung. - Workflow C reaktiviert Benutzer mit offenen Aufgaben. Möglicher Ablauf: 1. Workflow B entfernt die Abteilung. 2. Workflow A deaktiviert den Benutzer. 3. Workflow C erkennt offene Aufgaben. 4. Workflow C aktiviert den Benutzer erneut. Jeder Workflow arbeitet nach seiner eigenen Regel korrekt. Das Gesamtergebnis ist dennoch falsch. Mögliche Lösung: - gemeinsame Prozesslogik definieren - eindeutigen Mitarbeiterstatus verwenden - Prioritäten festlegen - gegenseitige Abhängigkeiten dokumentieren - vollständigen Systemtest durchführen --- **Systematische Fehlersuche** Bei einer gestörten Schnittstelle: 1. fachliche Anforderung klären 2. Problem genau beschreiben 3. betroffene Systeme bestimmen 4. Trigger prüfen 5. Eingangsdaten prüfen 6. Erreichbarkeit prüfen 7. Endpoint und Methode kontrollieren 8. Authentifizierung prüfen 9. Autorisierung prüfen 10. Header und Body prüfen 11. Statuscode auswerten 12. Response-Body lesen 13. Reihenfolge und Timing untersuchen 14. Abhängigkeiten prüfen 15. Logs kontrollieren 16. letzte Änderungen prüfen 17. Komponenten einzeln testen 18. Integrationstest durchführen 19. Gesamtsystem testen 20. Ursache und Lösung dokumentieren --- **Wichtige Begriffe** | Begriff | Bedeutung | |---|---| | Fehlerursache | tatsächlicher Auslöser eines Problems | | Fehlerstelle | Stelle, an der ein Problem sichtbar wird | | Fehlereingrenzung | Problem Schritt für Schritt lokalisieren | | Schnittstellenfehler | Fehler bei Übergabe oder Interpretation | | Abhängigkeit | ein System benötigt ein anderes System | | emergentes Verhalten | unerwartetes Verhalten des Gesamtsystems | | Komponententest | einzelne Komponente prüfen | | Integrationstest | Zusammenspiel mehrerer Komponenten prüfen | | Systemtest | vollständiges Gesamtsystem prüfen | | Abnahmetest | fachliche Anforderungen prüfen | | Reproduktion | Fehler unter gleichen Bedingungen erneut auslösen | | Änderungsprotokoll | technische Änderungen dokumentieren | | Rollback | Änderung auf vorherigen Stand zurücksetzen | | Workaround | vorläufige Umgehung eines Fehlers | --- **Gesamtmerksatz** > Technische Fehler liegen nicht immer eindeutig in Software, Elektronik oder Mechanik. Viele Probleme entstehen erst durch unklare Anforderungen, fehlerhafte Schnittstellen, falsche Datentypen, unterschiedliches Timing, versteckte Abhängigkeiten oder das Zusammenspiel mehrerer Teilsysteme. Deshalb müssen neben den einzelnen Komponenten auch ihre Integrationen und das vollständige Gesamtsystem geprüft werden. --- **Kontrollfragen** **Warum zeigt eine Fehlermeldung nicht immer die eigentliche Ursache?** Weil ein Fehler in einem anderen Teilsystem entstehen und erst später sichtbar werden kann. **Warum können funktionierende Komponenten gemeinsam einen Fehler erzeugen?** Weil Schnittstellen, Datenformate, Reihenfolge, Timing oder Abhängigkeiten nicht zusammenpassen. **Was ist ein Schnittstellenfehler?** Ein Fehler bei der Übergabe oder Interpretation von Daten, Signalen oder Befehlen zwischen Systemen. **Was bedeutet emergentes Verhalten?** Das Gesamtsystem zeigt ein Verhalten, das bei der getrennten Betrachtung der Einzelteile nicht erkennbar war. **Was prüft ein Komponententest?** Eine einzelne Funktion oder Komponente. **Was prüft ein Integrationstest?** Das Zusammenspiel und die Schnittstellen zwischen mehreren Komponenten. **Was prüft ein Systemtest?** Den vollständigen Ablauf des Gesamtsystems. **Was prüft ein Abnahmetest?** Ob das System die tatsächlichen fachlichen Anforderungen erfüllt. **Warum müssen Statuscode und Response-Body gemeinsam geprüft werden?** Der Statuscode zeigt die allgemeine Fehlerklasse. Der Response-Body enthält häufig die genaue Ursache. **Warum ist ein Änderungsprotokoll wichtig?** Damit Fehler mit vorherigen technischen Änderungen in Verbindung gebracht werden können. **Warum sollte der früheste Fehler eines Ablaufs zuerst untersucht werden?** Weil spätere Fehlermeldungen häufig nur Folgefehler derselben Ursache sind. --- **Quellen** - [IETF – HTTP Semantics](https://datatracker.ietf.org/doc/html/rfc9110) - [MDN Web Docs – HTTP-Statuscodes](https://developer.mozilla.org/de/docs/Web/HTTP/Status) - [n8n-Dokumentation – Executions](https://docs.n8n.io/workflows/executions/) - [n8n-Dokumentation – Error Handling](https://docs.n8n.io/flow-logic/error-handling/) - [OWASP – Logging Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html) - [BSI – IT-Grundschutz](https://www.bsi.bund.de/grundschutz) ``` # 2.15 Prüfungsvorbereitung Diese Seite fasst die wichtigsten Inhalte zu SaaS-Systemen, APIs und Prozessautomatisierung prüfungsorientiert zusammen. Im Mittelpunkt stehen: - zentrale Fachbegriffe - typische Prüfungsfragen - praktische Fehlersuche - sichere Automatisierung - kurze Fallbeispiele - wichtige Merksätze --- **Lernziele** Nach dieser Seite solltest du: - SaaS-, CRM- und Projektmanagement-Systeme unterscheiden - eine API verständlich erklären - Request und Response beschreiben - REST-Methoden und CRUD zuordnen - wichtige HTTP-Statuscodes erkennen - JSON lesen und Fehler finden - Authentifizierung und Autorisierung unterscheiden - Webhooks und Polling vergleichen - einen n8n-Workflow erklären - Sicherheits- und Datenschutzregeln anwenden - Schnittstellenfehler systematisch eingrenzen --- **Wichtige Grundbegriffe** | Begriff | Bedeutung | |---|---| | SaaS | Software wird als Onlinedienst bereitgestellt | | CRM | Verwaltung von Kunden und Vertriebsprozessen | | Projektmanagement-System | Verwaltung von Aufgaben, Terminen und Projekten | | Kollaborationssystem | digitale Kommunikation und Zusammenarbeit | | API | Schnittstelle für die Kommunikation zwischen Programmen | | Endpoint | konkrete Adresse einer API-Funktion | | Request | Anfrage des Clients | | Response | Antwort des Servers | | JSON | textbasiertes Format für strukturierte Daten | | Webhook | aktive Meldung eines Ereignisses | | Polling | regelmäßige Abfrage nach Änderungen | | Workflow | festgelegte Folge automatisierter Schritte | | Trigger | startet einen Workflow | | Credential | gespeicherte Zugangsdaten | | Logging | Protokollierung von Ereignissen und Fehlern | --- **SaaS, CRM und Projektmanagement** **Was beschreibt SaaS?** SaaS beschreibt die Bereitstellungsform einer Software. Die Anwendung läuft normalerweise beim Anbieter und wird über das Internet verwendet. Beispiele: - Google Workspace - Slack - Asana - Zoho CRM - Microsoft 365 **Was beschreibt CRM?** CRM beschreibt den Einsatzzweck einer Software. Ein CRM-System verwaltet: - Kunden - Interessenten - Ansprechpartner - Gespräche - Angebote - Verträge - Verkaufschancen **Was beschreibt ein Projektmanagement-System?** Es verwaltet: - Projekte - Aufgaben - Zuständigkeiten - Termine - Prioritäten - Bearbeitungsstände Merksatz: > SaaS beschreibt die Bereitstellung. CRM und Projektmanagement beschreiben den Einsatzzweck. --- **API-Grundlagen** API bedeutet: > Application Programming Interface Auf Deutsch: > Programmierschnittstelle Eine API ermöglicht es verschiedenen Programmen, Daten auszutauschen oder Funktionen aufzurufen. Grundablauf: Client | | Request v Server | | Response v Client Beispiel: n8n | | Benutzer anlegen v SaaS-System | | Benutzer wurde erstellt v n8n --- **Bestandteile eines Requests** Ein Request kann enthalten: - HTTP-Methode - Endpoint - Header - Query-Parameter - Path-Parameter - Request-Body - Authentifizierungsdaten Beispiel: POST https://api.example.com/users Authorization: Bearer *** Content-Type: application/json { "name": "Max Mustermann", "department": "IT" } --- **HTTP-Methoden und CRUD** | HTTP-Methode | Aufgabe | CRUD | |---|---|---| | GET | Daten lesen | Read | | POST | Daten erstellen | Create | | PUT | Ressource vollständig ersetzen | Update | | PATCH | einzelne Werte ändern | Update | | DELETE | Ressource löschen | Delete | Merksatz: > GET liest, POST erstellt, PUT ersetzt, PATCH ändert teilweise und DELETE löscht. --- **PUT und PATCH** **PUT** Ersetzt normalerweise den vollständigen Datensatz. PUT /users/15 { "name": "Max Mustermann", "department": "IT", "active": true } **PATCH** Verändert nur einzelne Felder. PATCH /users/15 { "department": "Support" } Merksatz: > PUT ersetzt vollständig. PATCH ändert teilweise. --- **Wichtige HTTP-Statuscodes** | Code | Bedeutung | |---:|---| | 200 | Anfrage erfolgreich | | 201 | Ressource erstellt | | 204 | erfolgreich ohne Response-Body | | 400 | fehlerhafte Anfrage | | 401 | Authentifizierung fehlt oder ist ungültig | | 403 | Berechtigung fehlt | | 404 | Ressource nicht gefunden | | 409 | Konflikt mit vorhandenem Zustand | | 415 | falsches Datenformat | | 422 | fachlich ungültige Daten | | 429 | zu viele Anfragen | | 500 | interner Serverfehler | | 502 | fehlerhafte Antwort eines nachgelagerten Dienstes | | 503 | Dienst vorübergehend nicht verfügbar | | 504 | Zeitüberschreitung am Gateway | --- **401 und 403** | Statuscode | Bedeutung | |---:|---| | 401 | Identität konnte nicht bestätigt werden | | 403 | Identität ist bekannt, aber die Aktion ist nicht erlaubt | Merksatz: > 401 fragt: Wer bist du? > 403 sagt: Du bist bekannt, darfst das aber nicht. --- **JSON-Grundlagen** JSON speichert Daten als Schlüssel-Wert-Paare. Beispiel: { "name": "Max Mustermann", "department": "IT", "active": true, "roles": [ "support", "user" ] } Wichtige Regeln: - Objekte verwenden `{ }` - Arrays verwenden `[ ]` - Schlüssel stehen in doppelten Anführungszeichen - Textwerte stehen in doppelten Anführungszeichen - Boolean-Werte sind `true` oder `false` - mehrere Einträge werden durch Kommas getrennt - nach dem letzten Eintrag steht kein Komma --- **JSON-Datentypen** | Datentyp | Beispiel | |---|---| | String | `"Max Mustermann"` | | Zahl | `15` | | Boolean | `true` | | Objekt | `{ "name": "Max" }` | | Array | `["IT", "Support"]` | | Null | `null` | Unterschied: true ist ein Boolean. "true" ist ein String. --- **JSON-Fehler erkennen** Fehlerhaft: { name: 'Max Mustermann', "active": "true", } Fehler: - Schlüssel ohne doppelte Anführungszeichen - einfache Anführungszeichen - Boolean als String - zusätzliches Komma Korrekt: { "name": "Max Mustermann", "active": true } --- **Authentifizierung und Autorisierung** | Begriff | Frage | |---|---| | Authentifizierung | Wer greift zu? | | Autorisierung | Was darf der Zugriff ausführen? | Mögliche Verfahren: - API-Key - Bearer-Token - OAuth 2.0 - Benutzername und Passwort Beispiel: Authorization: Bearer *** --- **OAuth 2.0** OAuth 2.0 ermöglicht einer Anwendung einen begrenzten Zugriff auf ein anderes System. Wichtige Begriffe: | Begriff | Bedeutung | |---|---| | Access Token | wird für API-Anfragen verwendet | | Refresh Token | fordert ein neues Access Token an | | Scope | begrenzt die erlaubten Aktionen | | Client ID | identifiziert die Anwendung | | Client Secret | geheimer Nachweis der Anwendung | Merksatz: > OAuth 2.0 ermöglicht kontrollierten Zugriff, ohne dauerhaft das Benutzerpasswort zu speichern. --- **Webhook und Polling** | Verfahren | Funktionsweise | |---|---| | Webhook | Quellsystem meldet ein Ereignis aktiv | | Polling | Zielsystem fragt regelmäßig nach Änderungen | Webhook: CRM | | neuer Kunde v n8n Polling: n8n | | Gibt es neue Kunden? v CRM Merksatz: > Beim Webhook wird gesendet. Beim Polling wird nachgefragt. --- **n8n-Grundaufbau** Ein n8n-Workflow besteht aus Nodes. Beispiel: Webhook Trigger | v Daten prüfen | v Benutzer suchen | v Benutzer vorhanden? / \ ja nein | | v v stoppen Benutzer anlegen | v Nachricht senden | v Ergebnis protokollieren --- **Typische n8n-Nodes** | Node | Aufgabe | |---|---| | Webhook | empfängt HTTP-Anfragen | | Schedule Trigger | startet nach Zeitplan | | HTTP Request | ruft eine API auf | | Edit Fields | verändert Datenfelder | | If | prüft eine Ja-Nein-Bedingung | | Switch | unterscheidet mehrere Fälle | | Code | verarbeitet Daten mit JavaScript | | Error Trigger | startet einen Fehlerworkflow | --- **Expressions in n8n** Wert auslesen: {{$json.name}} Text zusammensetzen: {{$json.firstName + " " + $json.lastName}} Standardwert verwenden: {{$json.department || "Allgemein"}} Zahl umwandeln: {{Number($json.licenseCount)}} --- **Datenmapping** Quellsystem: { "firstName": "Max", "lastName": "Mustermann", "mail": "max.mustermann@example.com" } Zielsystem: { "givenName": "Max", "familyName": "Mustermann", "primaryEmail": "max.mustermann@example.com" } | Quellfeld | Zielfeld | |---|---| | `firstName` | `givenName` | | `lastName` | `familyName` | | `mail` | `primaryEmail` | > Beim Datenmapping werden Felder unterschiedlicher Systeme einander zugeordnet. --- **Bedingungen** **If** Geeignet für zwei Wege: Benutzer aktiv? / \ ja nein | | v v weiter stoppen **Switch** Geeignet für mehrere Fälle: Abteilung / | \ IT CRM Finance --- **Fehlerbehandlung** Ein Workflow sollte Fehler erkennen und kontrolliert behandeln. Beispiel: API-Anfrage | v erfolgreich? / \ ja nein | | v v weiter Fehler prüfen | v Retry möglich? / \ ja nein | | v v warten IT informieren --- **Retry** Retry bedeutet: > Eine fehlgeschlagene Aktion wird erneut versucht. Sinnvoll bei: - 429 - 502 - 503 - 504 - kurzfristigem Netzwerkfehler Nicht unverändert sinnvoll bei: - 400 - 401 - 403 - ungültigem JSON - fehlenden Pflichtfeldern --- **Backoff** Backoff bedeutet: > Die Wartezeit zwischen Wiederholungen wird erhöht. Beispiel: | Versuch | Wartezeit | |---:|---:| | 1 | sofort | | 2 | 5 Sekunden | | 3 | 15 Sekunden | | 4 | 30 Sekunden | --- **Rate Limit** Ein Rate Limit begrenzt die Anzahl erlaubter API-Anfragen. Beispiel: Status: 429 Too Many Requests Retry-After: 60 Bedeutung: > Vor dem nächsten Versuch 60 Sekunden warten. --- **Least Privilege** Least Privilege bedeutet: > Benutzer, Anwendungen und Workflows erhalten nur die Rechte, die sie tatsächlich benötigen. Beispiel: Ein Workflow soll Nachrichten senden. Benötigt: messages.send Nicht benötigt: users.delete administrators.write --- **Sicherheitsregeln** - HTTPS verwenden - Secrets geschützt speichern - keine Tokens in Logs schreiben - nur notwendige Scopes vergeben - Webhooks authentifizieren - Eingabedaten validieren - Test- und Produktivsysteme trennen - kritische Aktionen freigeben lassen - Service Accounts verwenden - Audit-Logs kontrollieren --- **Onboarding und Offboarding** **Onboarding** - Benutzerkonto anlegen - Gruppen zuweisen - Rollen vergeben - Lizenzen aktivieren - MFA vorbereiten - Hardware-Aufgabe erstellen - Ergebnis dokumentieren **Offboarding** - Sitzungen beenden - Konto deaktivieren - Tokens widerrufen - Gruppen entfernen - Daten übertragen - Lizenzen freigeben - Geräte zurückfordern - Vorgang dokumentieren --- **Typische Prüfungsaufgabe 1** Ein n8n-Workflow sendet folgende Anfrage: POST /users { "name": "Max Mustermann" } Die API antwortet: Status: 400 Bad Request { "error": "Missing required field", "field": "email" } **Lösung** Das Pflichtfeld `email` fehlt. Der Request muss ergänzt werden: { "name": "Max Mustermann", "email": "max.mustermann@example.com" } --- **Typische Prüfungsaufgabe 2** Eine API antwortet mit: Status: 403 Forbidden **Lösung** Die Authentifizierung war wahrscheinlich erfolgreich, aber die benötigte Berechtigung oder der Scope fehlt. Zu prüfen sind: - Rolle - Gruppenmitgliedschaft - API-Scope - Administratorfreigabe - Zugriff auf die Ressource --- **Typische Prüfungsaufgabe 3** Ein Webhook wird zweimal gesendet und zwei Benutzerkonten werden erstellt. **Ursache** Der Workflow besitzt keinen Schutz vor doppelter Verarbeitung. **Lösung** - Event-ID speichern - Benutzer vor dem Anlegen suchen - eindeutige Mitarbeiter-ID verwenden - Idempotency-Key einsetzen --- **Typische Prüfungsaufgabe 4** Ein Workflow erhält: { "active": "true" } Die API erwartet: { "active": true } **Lösung** Der empfangene Wert ist ein String. Die API erwartet einen Boolean. --- **Typische Prüfungsaufgabe 5** Eine API antwortet mit: Status: 429 Too Many Requests **Lösung** Das Rate Limit wurde erreicht. Mögliche Maßnahmen: - `Retry-After` beachten - Wartezeit einbauen - Anfragen begrenzen - Batch-Verarbeitung verwenden - Polling-Intervall erhöhen --- **Typische Prüfungsaufgabe 6** Der Workflow meldet einen Timeout nach einer POST-Anfrage. **Problem** Die Ressource könnte im Zielsystem trotzdem erstellt worden sein. **Lösung** Vor einem erneuten POST-Request prüfen, ob die Ressource bereits existiert. Dadurch werden doppelte Datensätze vermieden. --- **Typische Prüfungsaufgabe 7** Ein Benutzer kann sich anmelden, aber keine Projekte verändern. **Lösung** Die Authentifizierung funktioniert. Wahrscheinlich fehlt die Autorisierung für die gewünschte Aktion. Zu prüfen sind: - Rolle - Projektberechtigung - Gruppenmitgliedschaft - API-Scope --- **Typische Prüfungsaufgabe 8** Ein Workflow startet nicht. **Prüfreihenfolge** 1. Workflow aktiv? 2. richtiger Trigger? 3. Webhook-URL korrekt? 4. richtige HTTP-Methode? 5. Quellsystem hat gesendet? 6. Endpoint erreichbar? 7. Authentifizierung gültig? 8. Trigger-Log vorhanden? 9. Test- oder Produktiv-URL verwechselt? --- **Typische Prüfungsaufgabe 9** Ein API-Token steht direkt in einer Code Node. **Bewertung** Das ist unsicher. **Bessere Lösung** Das Token wird in der Credential-Verwaltung oder einem Secret-Management-System gespeichert. --- **Typische Prüfungsaufgabe 10** Ein Workflow überträgt neben Name und E-Mail auch Gehalt und private Adresse an Slack. **Bewertung** Die Datenübertragung verstößt gegen das Prinzip der Datenminimierung. Nur die benötigten Daten sollten übertragen werden. --- **Systematische Fehlersuche** Empfohlene Reihenfolge: 1. Problem genau beschreiben 2. Trigger prüfen 3. Eingangsdaten prüfen 4. Netzwerk und Erreichbarkeit prüfen 5. Endpoint prüfen 6. HTTP-Methode prüfen 7. Authentifizierung prüfen 8. Autorisierung prüfen 9. Header kontrollieren 10. JSON-Body prüfen 11. Statuscode auswerten 12. Response-Body lesen 13. Logs prüfen 14. letzte Änderungen kontrollieren 15. Lösung mit Testdaten prüfen 16. Ergebnis dokumentieren --- **Prüfungsmerksätze** > SaaS beschreibt die Bereitstellung, nicht den Einsatzzweck. > Der Client sendet einen Request, der Server liefert eine Response. > GET liest, POST erstellt, PUT ersetzt, PATCH ändert und DELETE löscht. > 401 bedeutet fehlende Authentifizierung, 403 bedeutet fehlende Berechtigung. > JSON verwendet doppelte Anführungszeichen. > Beim Webhook wird gesendet, beim Polling wird regelmäßig abgefragt. > Erst Daten validieren, danach übertragen. > Secrets gehören nicht in Code, Logs oder Dokumentationen. > Ein Retry muss begrenzt und vor Doppelverarbeitung geschützt sein. > Jede Automatisierung benötigt Fehlerbehandlung und Logging. --- **Selbstkontrolle** Du solltest ohne Hilfsmittel erklären können: - Unterschied zwischen SaaS und CRM - Aufbau eines API-Requests - Bedeutung von Endpoint - Unterschied zwischen PUT und PATCH - Unterschied zwischen 401 und 403 - Aufbau eines JSON-Objekts - Unterschied zwischen Webhook und Polling - Aufgabe eines Triggers - Nutzen einer If- und Switch-Node - Bedeutung von Retry und Backoff - Zweck von Least Privilege - Ablauf eines sicheren Onboardings - systematische Fehlersuche bei API-Fehlern --- **Gesamtmerksatz** > APIs verbinden Systeme über Requests und Responses. REST verwendet HTTP-Methoden zur Verarbeitung von Ressourcen. JSON überträgt strukturierte Daten. Webhooks und Trigger starten Workflows, während n8n Bedingungen, Datenmapping und Aktionen verbindet. Sichere Automatisierungen benötigen begrenzte Rechte, geschützte Secrets, Validierung, Logging und Fehlerbehandlung. --- **Quellen** - [IETF – HTTP Semantics](https://datatracker.ietf.org/doc/html/rfc9110) - [IETF – JSON Data Interchange Format](https://datatracker.ietf.org/doc/html/rfc8259) - [IETF – OAuth 2.0](https://datatracker.ietf.org/doc/html/rfc6749) - [MDN Web Docs – HTTP](https://developer.mozilla.org/de/docs/Web/HTTP) - [n8n-Dokumentation](https://docs.n8n.io/) - [OWASP – Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) - [OWASP – Secrets Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html) ``` # 2.16 Gesamttrainer – APIs, SaaS und Automatisierung Dieser Gesamttrainer wiederholt die wichtigsten Inhalte des Kapitels: - SaaS-, CRM- und Projektmanagement-Systeme - API-Grundlagen - REST und HTTP-Methoden - HTTP-Statuscodes - JSON - Authentifizierung und OAuth 2.0 - Webhooks und Polling - n8n-Workflows - Fehlerbehandlung - Sicherheit und Datenschutz - Onboarding und Offboarding Die Lösungen befinden sich jeweils unterhalb der Aufgabe und können aufgeklappt werden. --- **Teil 1 – Grundbegriffe** **Aufgabe 1** Wofür steht die Abkürzung SaaS? - A: System as a Server - B: Software as a Service - C: Security as a System - D: Software and Server
Lösung anzeigen **Richtige Antwort: B** SaaS bedeutet Software as a Service. Eine Software wird als Dienst über ein Netzwerk beziehungsweise das Internet bereitgestellt.
--- **Aufgabe 2** Welche Aussage beschreibt ein CRM-System am besten? - A: Es verwaltet ausschließlich Netzwerkgeräte. - B: Es speichert Kunden-, Kontakt- und Vertriebsinformationen. - C: Es ersetzt jedes Projektmanagement-System. - D: Es verwaltet nur Benutzerpasswörter.
Lösung anzeigen **Richtige Antwort: B** CRM bedeutet Customer Relationship Management. Ein CRM-System verwaltet Kunden, Interessenten, Kontakte, Angebote und Vertriebsprozesse.
--- **Aufgabe 3** Welche Anwendung ist hauptsächlich ein Kollaborationssystem? - A: Slack - B: DHCP - C: PostgreSQL - D: RAID
Lösung anzeigen **Richtige Antwort: A** Slack unterstützt Kommunikation, Kanäle, Nachrichten und Zusammenarbeit innerhalb eines Unternehmens.
--- **Aufgabe 4** Was ist eine API?
Lösung anzeigen Eine API ist eine Programmierschnittstelle. Sie ermöglicht es unterschiedlichen Programmen, Daten auszutauschen oder Funktionen eines anderen Systems aufzurufen.
--- **Aufgabe 5** Ordne die Begriffe richtig zu. | Begriff | Bedeutung | |---|---| | Client | ? | | Server | ? | | Request | ? | | Response | ? | | Endpoint | ? |
Lösung anzeigen | Begriff | Bedeutung | |---|---| | Client | sendet eine Anfrage | | Server | verarbeitet die Anfrage | | Request | Anfrage an ein System | | Response | Antwort eines Systems | | Endpoint | konkrete Adresse innerhalb einer API |
--- **Teil 2 – REST, HTTP und CRUD** **Aufgabe 6** Ordne die HTTP-Methoden zu. | Methode | Aufgabe | |---|---| | GET | ? | | POST | ? | | PUT | ? | | PATCH | ? | | DELETE | ? |
Lösung anzeigen | Methode | Aufgabe | |---|---| | GET | Daten lesen | | POST | neue Daten erstellen | | PUT | Ressource vollständig ersetzen | | PATCH | einzelne Werte ändern | | DELETE | Ressource löschen |
--- **Aufgabe 7** Was bedeutet CRUD?
Lösung anzeigen CRUD bedeutet: - Create - Read - Update - Delete Es beschreibt die grundlegenden Operationen zum Erstellen, Lesen, Ändern und Löschen von Daten.
--- **Aufgabe 8** Welche Anfrage ruft den Benutzer mit der ID 15 ab? - A: `POST /users/15` - B: `GET /users/15` - C: `PATCH /users` - D: `DELETE /users/15`
Lösung anzeigen **Richtige Antwort: B** GET /users/15 GET ruft Daten ab. `/users/15` bezeichnet den Benutzer mit der ID 15.
--- **Aufgabe 9** Welche Anfrage ändert nur die Abteilung eines Benutzers? - A: `GET /users/15` - B: `POST /users/15` - C: `PATCH /users/15` - D: `DELETE /users/15`
Lösung anzeigen **Richtige Antwort: C** PATCH /users/15 Request-Body: { "department": "IT" } PATCH verändert einzelne Felder einer Ressource.
--- **Aufgabe 10** Was ist der Unterschied zwischen PUT und PATCH?
Lösung anzeigen PUT ersetzt normalerweise eine vollständige Ressource. PATCH verändert nur einzelne Felder. Merksatz: > PUT ersetzt vollständig. PATCH ändert teilweise.
--- **Aufgabe 11** Was bedeutet Idempotenz?
Lösung anzeigen Idempotenz bedeutet, dass eine Anfrage mehrfach ausgeführt werden kann, ohne dass sich das Ergebnis nach der ersten erfolgreichen Ausführung weiter verändert. GET, PUT und DELETE sind normalerweise idempotent. POST ist normalerweise nicht idempotent.
--- **Teil 3 – HTTP-Statuscodes** **Aufgabe 12** Ordne die Statuscodes zu. | Code | Bedeutung | |---:|---| | 200 | ? | | 201 | ? | | 400 | ? | | 401 | ? | | 403 | ? | | 404 | ? | | 409 | ? | | 429 | ? | | 500 | ? | | 503 | ? |
Lösung anzeigen | Code | Bedeutung | |---:|---| | 200 | Anfrage erfolgreich | | 201 | Ressource erstellt | | 400 | fehlerhafte Anfrage | | 401 | Authentifizierung fehlt oder ist ungültig | | 403 | Berechtigung fehlt | | 404 | Ressource nicht gefunden | | 409 | Konflikt mit vorhandenem Zustand | | 429 | zu viele Anfragen | | 500 | interner Serverfehler | | 503 | Dienst vorübergehend nicht verfügbar |
--- **Aufgabe 13** Was ist der Unterschied zwischen 401 und 403?
Lösung anzeigen `401 Unauthorized` bedeutet, dass die Authentifizierung fehlt oder ungültig ist. `403 Forbidden` bedeutet, dass die Identität bekannt ist, aber die benötigte Berechtigung fehlt. Merksatz: > 401: Wer bist du? > 403: Du bist bekannt, darfst das aber nicht.
--- **Aufgabe 14** Eine API antwortet mit: Status: 409 Conflict { "error": "Email already exists" } Was ist die wahrscheinlichste Ursache?
Lösung anzeigen Die E-Mail-Adresse ist bereits einem vorhandenen Benutzerkonto zugeordnet. Vor einem erneuten POST-Request sollte der bestehende Benutzer gesucht werden.
--- **Aufgabe 15** Eine API antwortet mit: Status: 429 Too Many Requests Retry-After: 60 Was sollte der Workflow tun?
Lösung anzeigen Der Workflow sollte mindestens 60 Sekunden warten und die Anfrage anschließend begrenzt erneut versuchen. Zusätzlich sollten Rate Limit, Batch-Verarbeitung und Anzahl der Anfragen geprüft werden.
--- **Teil 4 – JSON** **Aufgabe 16** Welche JSON-Struktur ist korrekt? **A** { name: 'Max Mustermann', active: true, } **B** { "name": "Max Mustermann", "active": true } **C** [ "name": "Max Mustermann" ]
Lösung anzeigen **Richtige Antwort: B** JSON verwendet: - doppelte Anführungszeichen - geschweifte Klammern für Objekte - kein zusätzliches Komma nach dem letzten Feld
--- **Aufgabe 17** Welche Datentypen besitzen die folgenden Werte? | Wert | Datentyp | |---|---| | `"15"` | ? | | `15` | ? | | `true` | ? | | `"true"` | ? | | `null` | ? | | `["IT", "Support"]` | ? |
Lösung anzeigen | Wert | Datentyp | |---|---| | `"15"` | String | | `15` | Zahl | | `true` | Boolean | | `"true"` | String | | `null` | Null-Wert | | `["IT", "Support"]` | Array |
--- **Aufgabe 18** Welche Ausgabe liefert der Zugriffspfad `department.name`? { "name": "Max Mustermann", "department": { "id": 3, "name": "IT" } }
Lösung anzeigen Die Ausgabe lautet: IT `department` ist ein verschachteltes Objekt. Das Feld `name` enthält den Wert `IT`.
--- **Aufgabe 19** Was bedeutet Datenmapping?
Lösung anzeigen Datenmapping bedeutet, dass Felder eines Quellsystems passenden Feldern eines Zielsystems zugeordnet werden. Beispiel: | Quellsystem | Zielsystem | |---|---| | `firstName` | `givenName` | | `lastName` | `familyName` | | `mail` | `primaryEmail` |
--- **Teil 5 – Authentifizierung und Berechtigungen** **Aufgabe 20** Was ist ein API-Key?
Lösung anzeigen Ein API-Key ist ein geheimer Schlüssel, der einem Benutzer, Programm oder Projekt zugeordnet wird und den Zugriff auf eine API ermöglicht. Er sollte geschützt gespeichert und nur mit den notwendigen Rechten ausgestattet werden.
--- **Aufgabe 21** Wie wird ein Bearer-Token normalerweise übertragen?
Lösung anzeigen Im Authorization-Header: Authorization: Bearer *** Das Token muss wie ein Passwort geschützt werden.
--- **Aufgabe 22** Ordne die OAuth-Begriffe zu. | Begriff | Bedeutung | |---|---| | Access Token | ? | | Refresh Token | ? | | Scope | ? | | Client ID | ? | | Client Secret | ? |
Lösung anzeigen | Begriff | Bedeutung | |---|---| | Access Token | wird für API-Anfragen verwendet | | Refresh Token | fordert ein neues Access Token an | | Scope | begrenzt die erlaubten Aktionen | | Client ID | identifiziert eine Anwendung | | Client Secret | geheimer Nachweis einer Anwendung |
--- **Aufgabe 23** Was bedeutet Least Privilege?
Lösung anzeigen Benutzer, Anwendungen und Workflows erhalten nur die Rechte, die sie für ihre Aufgabe tatsächlich benötigen. Ein Workflow zum Senden von Nachrichten benötigt beispielsweise keinen Zugriff zum Löschen von Benutzern.
--- **Aufgabe 24** Warum sollte ein Workflow nicht mit dem persönlichen Administratorkonto eines Mitarbeiters ausgeführt werden?
Lösung anzeigen Mögliche Probleme: - zu umfangreiche Rechte - Abhängigkeit von einer einzelnen Person - Ausfall beim Mitarbeiterwechsel - schlechte Nachvollziehbarkeit - Vermischung persönlicher und technischer Zugriffe Besser ist ein eigener Service Account mit begrenzten Rechten.
--- **Teil 6 – Webhooks und Polling** **Aufgabe 25** Was ist der Unterschied zwischen Webhook und Polling?
Lösung anzeigen Beim Webhook meldet das Quellsystem ein Ereignis aktiv. Beim Polling fragt das Zielsystem regelmäßig nach neuen oder geänderten Daten. Merksatz: > Beim Webhook wird gesendet. Beim Polling wird nachgefragt.
--- **Aufgabe 26** Welche Vorteile besitzt ein Webhook? - A: Ereignisse können sofort verarbeitet werden. - B: Es müssen ständig unnötige API-Abfragen durchgeführt werden. - C: Die Anzahl der API-Anfragen kann reduziert werden. - D: Ein Webhook benötigt niemals Sicherheitsmaßnahmen.
Lösung anzeigen **Richtige Antworten: A und C** Webhooks reagieren meist sofort und verursachen nur bei einem tatsächlichen Ereignis eine Übertragung. Webhook-Endpunkte müssen trotzdem abgesichert werden.
--- **Aufgabe 27** Ein Webhook wird zweimal empfangen und legt zwei identische Aufgaben an. Welche Schutzmaßnahmen wären sinnvoll?
Lösung anzeigen - Event-ID prüfen - bereits verarbeitete Ereignisse speichern - vorhandene Ressource suchen - Idempotency-Key verwenden - doppelte Trigger erkennen
--- **Aufgabe 28** Was ist ein Replay-Angriff?
Lösung anzeigen Bei einem Replay-Angriff wird eine bereits gültige Nachricht erneut gesendet. Dadurch könnten Aktionen wie Benutzeranlage, Zahlung oder Aufgabenerstellung mehrfach ausgeführt werden. Schutz bieten Event-ID, Zeitstempel und Signaturprüfung.
--- **Teil 7 – n8n und Workflow-Logik** **Aufgabe 29** Ordne die n8n-Nodes zu. | Node | Aufgabe | |---|---| | Webhook | ? | | HTTP Request | ? | | If | ? | | Switch | ? | | Edit Fields | ? | | Error Trigger | ? |
Lösung anzeigen | Node | Aufgabe | |---|---| | Webhook | empfängt HTTP-Anfragen | | HTTP Request | ruft eine API auf | | If | prüft eine Ja-Nein-Bedingung | | Switch | unterscheidet mehrere Fälle | | Edit Fields | verändert oder erstellt Datenfelder | | Error Trigger | startet einen Fehlerworkflow |
--- **Aufgabe 30** Welche Expression liest das Feld `email` aus? - A: `{{$json.email}}` - B: `{{email.json}}` - C: `{{$email.json}}` - D: `{json.email}`
Lösung anzeigen **Richtige Antwort: A** {{$json.email}}
--- **Aufgabe 31** Welche Expression erstellt einen vollständigen Namen? Eingangsdaten: { "firstName": "Max", "lastName": "Mustermann" }
Lösung anzeigen {{$json.firstName + " " + $json.lastName}} Ergebnis: Max Mustermann
--- **Aufgabe 32** Wann sollte eine If-Node und wann eine Switch-Node verwendet werden?
Lösung anzeigen Eine If-Node eignet sich für zwei Wege, beispielsweise wahr oder falsch. Eine Switch-Node eignet sich für mehrere mögliche Werte, beispielsweise verschiedene Abteilungen.
--- **Aufgabe 33** Ergänze den Workflow. Webhook | v Pflichtfelder prüfen | v Benutzer vorhanden? / \ ja nein | | v v ? Benutzer anlegen
Lösung anzeigen Im Ja-Pfad sollte der Workflow beispielsweise: - stoppen - vorhandenen Benutzer aktualisieren - oder eine manuelle Prüfung starten Ein doppeltes Benutzerkonto darf nicht erstellt werden.
--- **Teil 8 – Fehlerbehandlung** **Aufgabe 34** Bei welchen Fehlern ist ein Retry meistens sinnvoll? - A: 400 Bad Request - B: 403 Forbidden - C: 429 Too Many Requests - D: 503 Service Unavailable - E: 504 Gateway Timeout
Lösung anzeigen **Richtige Antworten: C, D und E** Diese Fehler können vorübergehend sein. 400 und 403 benötigen zunächst eine Korrektur der Anfrage beziehungsweise der Berechtigungen.
--- **Aufgabe 35** Was bedeutet Backoff?
Lösung anzeigen Backoff bedeutet, dass die Wartezeit zwischen mehreren Wiederholungsversuchen schrittweise erhöht wird. Beispiel: - 5 Sekunden - 15 Sekunden - 30 Sekunden - 60 Sekunden
--- **Aufgabe 36** Warum ist ein Retry nach einem Timeout bei einer POST-Anfrage gefährlich?
Lösung anzeigen Die Ressource könnte im Zielsystem bereits erstellt worden sein, obwohl n8n keine Antwort empfangen hat. Ein erneuter POST-Request könnte dadurch eine doppelte Ressource erzeugen. Vor dem Retry sollte geprüft werden, ob der Datensatz bereits existiert.
--- **Aufgabe 37** Welche Daten dürfen nicht vollständig in Logs gespeichert werden?
Lösung anzeigen - Passwörter - API-Keys - Bearer-Tokens - Refresh Tokens - Client Secrets - private Schlüssel - besonders vertrauliche personenbezogene Daten
--- **Aufgabe 38** Ein Workflow hat folgende Ergebnisse: | Schritt | Ergebnis | |---|---| | Benutzerkonto erstellt | erfolgreich | | Gruppe zugewiesen | erfolgreich | | Slack-Zugang erstellt | fehlgeschlagen | | Hardware-Ticket erstellt | nicht ausgeführt | Darf der Workflow den Vorgang als vollständig erfolgreich markieren?
Lösung anzeigen Nein. Es handelt sich um einen Teilerfolg. Erfolgreiche und fehlgeschlagene Schritte müssen getrennt dokumentiert werden. Zusätzlich sollte eine manuelle Aufgabe oder Fehlermeldung erstellt werden.
--- **Teil 9 – Sicherheit und Datenschutz** **Aufgabe 39** Ein Workflow überträgt folgende Daten an ein Kommunikationssystem: { "name": "Max Mustermann", "email": "max.mustermann@example.com", "department": "IT", "salary": 50000, "privateAddress": "Musterstraße 1" } Benötigt werden nur Name, E-Mail und Abteilung. Welches Prinzip wird verletzt?
Lösung anzeigen Das Prinzip der Datenminimierung wird verletzt. Es dürfen nur die Daten übertragen werden, die für den festgelegten Zweck benötigt werden.
--- **Aufgabe 40** Welche Maßnahmen schützen einen öffentlichen Webhook?
Lösung anzeigen - HTTPS - Signaturprüfung - API-Key oder Bearer-Token - Event-ID - Zeitstempel - IP-Filter - Rate Limit - Eingabevalidierung - Schutz vor Replay-Angriffen
--- **Aufgabe 41** Warum sollten Test- und Produktivsysteme getrennt werden?
Lösung anzeigen Damit Tests keine unbeabsichtigten Änderungen an echten Daten, Benutzern, Projekten oder Kommunikationskanälen verursachen. Testsysteme sollten eigene Daten, Credentials und Endpoints verwenden.
--- **Aufgabe 42** Was ist ein Audit-Log?
Lösung anzeigen Ein Audit-Log protokolliert sicherheitsrelevante Aktionen. Beispiele: - Benutzer angelegt - Rolle geändert - Token erzeugt - MFA deaktiviert - Administratorrecht vergeben - Workflow verändert
--- **Teil 10 – Onboarding und Offboarding** **Aufgabe 43** Bringe die Onboarding-Schritte in eine sinnvolle Reihenfolge. - Benutzerkonto anlegen - Eingangsdaten validieren - Gruppen zuweisen - vorhandenes Konto suchen - Ergebnis dokumentieren - Hardware-Aufgabe erstellen
Lösung anzeigen 1. Eingangsdaten validieren 2. vorhandenes Konto suchen 3. Benutzerkonto anlegen 4. Gruppen zuweisen 5. Hardware-Aufgabe erstellen 6. Ergebnis dokumentieren
--- **Aufgabe 44** Warum sollte ein Benutzerkonto beim Offboarding häufig zuerst deaktiviert und nicht sofort gelöscht werden?
Lösung anzeigen - Daten bleiben zunächst erhalten. - Audit-Logs bleiben nachvollziehbar. - E-Mails und Dateien können übertragen werden. - Abhängigkeiten können geprüft werden. - Das Konto kann bei einem Fehler wieder aktiviert werden.
--- **Aufgabe 45** Welche Maßnahmen gehören zum Offboarding? - A: aktive Sitzungen beenden - B: Tokens widerrufen - C: Administratorrechte erweitern - D: Gruppen entfernen - E: Lizenzen freigeben - F: Geräte zurückfordern
Lösung anzeigen **Richtige Antworten: A, B, D, E und F** Administratorrechte dürfen beim Offboarding nicht erweitert werden.
--- **Aufgabe 46** Warum reicht eine Passwortänderung beim Offboarding möglicherweise nicht aus?
Lösung anzeigen Bereits aktive Sitzungen, App-Passwörter, OAuth-Verbindungen, API-Tokens oder VPN-Zertifikate könnten weiterhin gültig sein. Diese Zugänge müssen zusätzlich beendet oder widerrufen werden.
--- **Teil 11 – Systematische Fehlersuche** **Aufgabe 47** Ein Workflow startet nicht. Welche Prüfreihenfolge ist sinnvoll?
Lösung anzeigen 1. Ist der Workflow aktiv? 2. Ist der richtige Trigger eingerichtet? 3. Wurde das Ereignis im Quellsystem ausgelöst? 4. Ist die Webhook-URL korrekt? 5. Wird die richtige HTTP-Methode verwendet? 6. Ist der Endpoint erreichbar? 7. Ist die Authentifizierung gültig? 8. Gibt es einen Eintrag im Trigger-Log? 9. Wurde eine Test- mit einer Produktiv-URL verwechselt?
--- **Aufgabe 48** Eine API antwortet mit `403 Forbidden`. Welche Punkte sollten geprüft werden?
Lösung anzeigen - Rolle des Benutzers oder Service Accounts - Gruppenmitgliedschaften - API-Scopes - Administratorfreigabe - Berechtigung für die konkrete Ressource - verwendetes Credential
--- **Aufgabe 49** Eine API-Anfrage liefert keinen HTTP-Statuscode. Welche Fehlerarten kommen infrage?
Lösung anzeigen - DNS-Fehler - Netzwerkverbindung unterbrochen - Port geschlossen - Firewall blockiert - TLS-Zertifikatsfehler - Verbindung zurückgesetzt - Timeout ohne Serverantwort Ein HTTP-Statuscode kann nur empfangen werden, wenn der Server eine HTTP-Response zurücksendet.
--- **Aufgabe 50** Bringe die Fehlersuche in eine sinnvolle Reihenfolge. - Statuscode auswerten - Trigger prüfen - Authentifizierung prüfen - Eingangsdaten prüfen - Berechtigungen prüfen - Netzwerk prüfen - Endpoint und Methode prüfen - Response-Body lesen - Ergebnis dokumentieren
Lösung anzeigen 1. Trigger prüfen 2. Eingangsdaten prüfen 3. Netzwerk prüfen 4. Endpoint und Methode prüfen 5. Authentifizierung prüfen 6. Berechtigungen prüfen 7. Statuscode auswerten 8. Response-Body lesen 9. Ergebnis dokumentieren
--- **Abschlussaufgabe – Vollständiger Workflow** Ein neuer Mitarbeiter wird im Personalsystem freigegeben. Entwirf einen sicheren Ablauf mit folgenden Systemen: - Personalsystem - n8n - Benutzerverwaltung - Slack - Ticketsystem Berücksichtige: - Trigger - Validierung - Prüfung auf Duplikate - API-Aufrufe - Rollen und Gruppen - Fehlerbehandlung - Logging - Datenschutz
Musterlösung anzeigen 1. Das Personalsystem sendet einen signierten Webhook. 2. n8n prüft Signatur, Event-ID und Zeitstempel. 3. Pflichtfelder und Datentypen werden validiert. 4. Nur notwendige Mitarbeiterdaten werden übernommen. 5. Der vorhandene Benutzer wird über seine E-Mail-Adresse oder Mitarbeiter-ID gesucht. 6. Ist kein Benutzer vorhanden, wird das Konto über POST angelegt. 7. Gruppen und Rollen werden nach dem Least-Privilege-Prinzip zugewiesen. 8. Das Ticketsystem erhält eine Aufgabe zur Hardwarebereitstellung. 9. Slack erhält eine Nachricht ohne Passwörter oder vertrauliche Daten. 10. Jede API-Response wird auf Statuscode und Inhalt geprüft. 11. Vorübergehende Fehler erhalten einen begrenzten Retry mit Backoff. 12. Dauerhafte Fehler werden protokolliert und an die IT gemeldet. 13. Teilerfolge werden eindeutig dokumentiert. 14. Secrets werden ausschließlich über geschützte Credentials verwendet. 15. Die Event-ID wird als verarbeitet gespeichert. Vereinfachte Darstellung: Personalsystem | | signierter Webhook v n8n | v Daten validieren | v Event-ID prüfen | v Benutzer suchen / \ gefunden nicht gefunden | | v v prüfen Konto anlegen | v Gruppen zuweisen | v Hardware-Ticket | v Slack informieren | v Ergebnis protokollieren
--- **Bewertung** | Richtige Antworten | Einschätzung | |---:|---| | 45–50 | sehr sicher | | 38–44 | guter Stand | | 30–37 | Grundlagen vorhanden | | 20–29 | wichtige Bereiche wiederholen | | unter 20 | Kapitel systematisch erneut bearbeiten | --- **Abschlussmerksätze** > SaaS beschreibt die Bereitstellung einer Software als Onlinedienst. > Eine API ermöglicht die Kommunikation zwischen Programmen. > Der Client sendet einen Request und der Server liefert eine Response. > GET liest, POST erstellt, PUT ersetzt, PATCH ändert und DELETE löscht. > 401 bedeutet fehlende Authentifizierung, 403 bedeutet fehlende Berechtigung. > JSON verwendet Schlüssel-Wert-Paare und doppelte Anführungszeichen. > Beim Webhook wird ein Ereignis aktiv gemeldet, beim Polling wird regelmäßig nachgefragt. > n8n verbindet Trigger, Daten, Bedingungen und Aktionen. > Retries müssen begrenzt und gegen Doppelverarbeitung geschützt sein. > Secrets gehören nicht in Code, Logs oder Dokumentationen. > Least Privilege bedeutet, nur notwendige Rechte zu vergeben. > Eine sichere Automatisierung benötigt Validierung, Logging und Fehlerbehandlung. --- **Quellen** - [IETF – HTTP Semantics](https://datatracker.ietf.org/doc/html/rfc9110) - [IETF – JSON Data Interchange Format](https://datatracker.ietf.org/doc/html/rfc8259) - [IETF – OAuth 2.0](https://datatracker.ietf.org/doc/html/rfc6749) - [MDN Web Docs – HTTP](https://developer.mozilla.org/de/docs/Web/HTTP) - [n8n-Dokumentation](https://docs.n8n.io/) - [OWASP – Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) - [OWASP – Secrets Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html) ```