EAI verbindet eigenständige Anwendungen so, dass ein durchgängiger Geschäftsprozess entsteht. Nicht die Anzahl Schnittstellen ist entscheidend, sondern klare Verantwortungen und ein kontrollierbarer Datenfluss.
2. System of Record
Für jedes wichtige Objekt braucht es ein führendes System. Im Fallbeispiel führt Odoo Produkte und Aufträge, WooCommerce besitzt Warenkorb und Checkout. Andere Systeme halten höchstens Kopien oder Referenzen.
3. REST, HTTP und Ressourcen
REST nutzt eindeutige Ressourcen und HTTP-Methoden: GET liest, POST erstellt, PUT/PATCH ändert und DELETE entfernt. Statuscodes beschreiben das Ergebnis.
4. JSON und Mapping
Zwei Systeme benennen und strukturieren dieselbe Information unterschiedlich. Mapping übersetzt nicht nur Feldnamen, sondern auch IDs, Datentypen, Pflichtfelder und fachliche Bedeutung.
5. Punkt-zu-Punkt oder Integrationsschicht?
Eine direkte Verbindung ist einfach, skaliert aber schlecht. Eine Integrationsschicht bündelt Security, Transformation, Monitoring und Fehlerbehandlung – verursacht aber zusätzlichen Betrieb.
Praxis
Übungslabor
🟢 Pflicht · 🔵 Plus · 🟣 Challenge
Pflicht20 min
1. System-Safari
Öffne WooCommerce und Odoo. Finde in beiden Systemen Kunde, Produkt und Auftrag.
Notiere je Objekt die interne ID.
Finde mindestens drei unterschiedlich benannte Felder.
Bestimme, welches System die Daten führen soll.
Orientierung: Checkout und externe Bestellnummer entstehen im Shop; Produktstamm, Verfügbarkeit und interner Auftrag gehören ins ERP.
Pflicht20 min
2. Bestellung manuell übertragen
Erstelle im Shop eine Testbestellung und übertrage sie von Hand als Angebotsentwurf nach Odoo.
Abnahmekriterium
Kunde, externe Bestellnummer, Artikel, Menge und Preis sind nachvollziehbar übertragen.
Lernpunkt: Der manuelle Aufwand und mögliche Übertragungsfehler liefern den Business Case für die Integration.
Pflicht25 min
3. Mappingtabelle erstellen
Ordne mindestens acht Shop-Felder den Odoo-Feldern zu. Ergänze Datentyp, Pflichtfeld, Beispiel und Transformation.
WooCommerce Odoo Regel
billing.email → partner.email lowercase
line_items.sku → product.default_code Lookup
order.id → client_order_ref "WC-" + id
Pflicht25 min
4. Erster echter API-Aufruf
Rufe den mitgelieferten synthetischen Spitalendpunkt mit Bruno, Postman oder curl auf und untersuche URL, Header, Body und Statuscode.
curl -i \
"https://teko.algorithma.app/lab/api/v1/hospitals/spital-bern/capacity?department=allgemein"
# Lokal mit Docker: gleiche Route, andere Basis-URL
curl -i \
"http://localhost:3190/lab/api/v1/hospitals/spital-bern/capacity?department=allgemein"
Fragen
Welche Information steckt in URL, Header und Body?
Woran erkennst du Erfolg oder Fehler?
Plus20 min
5. JSON-Reparatur
Korrigiere Syntax und Pflichtfelder. Der Validator erwartet externalId, customerEmail und items.
Bereit für die Prüfung.
Challenge30 min
6. Architektur unter Störung
Zeichne den aktuellen Datenfluss. Ergänze danach drei Ausfälle und markiere, wo Daten verloren oder doppelt verarbeitet werden könnten.
Mögliche Ausfälle: Odoo nicht erreichbar, Netzwerk-Timeout nach erfolgreichem POST, unbekannte SKU, widersprüchliche Kundendaten.
i
Systemzugänge: WooCommerce und Odoo bleiben das Handels-Fallbeispiel und benötigen eine bereitgestellte Schul-/Testinstanz. Die mitgelieferte Docker-API ist die ohne Fremdzugang reproduzierbare Referenz für HTTP, Verträge und Fehler.
Diskussion
Wer besitzt die Wahrheit?
Warum greifen wir nicht direkt auf die Odoo-Datenbank zu?
Welche Daten müssen sofort aktuell sein – welche nicht?
Was soll mit einer Bestellung passieren, wenn Odoo ausfällt?
Wann ist eine Integrationsplattform unnötiger Ballast?
Moderationsziel: Die Studierenden sollen Datenhoheit, Kopien und Prozessverantwortung unterscheiden.
Mini-Quiz
Eine Entscheidung zum Schluss
Wo sollte die fachliche Produktverfügbarkeit geführt werden?
✓
Ergebnis des Tages Systemdiagramm, Datenverantwortung, Mappingtabelle und erster erfolgreicher API-Aufruf.
EAI IntegrationslaborUnterricht 1 von 4