Das Fundament
Wasabi Works ist kein Monolith verkleidet als Microservices. Jedes Modul ist unabhängig — deshalb macht eine neue Anforderung nichts kaputt, deshalb vergisst das System keine Nuance, deshalb ist ein schneller Go-Live statt monatelangem Beraterprojekt kein Versprechen, sondern Realität.
Was das Fundament trägt
Kein Modul ruft ein anderes direkt auf. Jede Kommunikation läuft über Events. Das bedeutet: neue Funktionen kommen hinzu, ohne dass bestehende brechen — und jedes Modul kann einzeln weiterentwickelt werden.
Die BDE-Kernmaschine. Nimmt rohe Terminal-Events entgegen, löst Konflikte bi-temporal auf, berechnet Zeitscheiben (Slices) und materialisiert BookingFacts für ERP-Export. Event-Sourced, append-only.
Verwaltet Produktionsaufträge, Kundenaufträge und Projekte mit vollständigem Lifecycle (DRAFT → RELEASED → IN_PROGRESS → DONE). Nimmt Mengen und Status-Updates aus ESTS via Events entgegen. ERP-Bulk-Import via REST.
Advanced Planning & Scheduling auf Basis von Timefold Solver 1.31. 18 Constraints (10 Hard, 2 Medium, 6 Soft). Optimiert Reihenfolge, Ressourcenzuteilung und Startzeiten auf 15-Minuten-Raster. Gantt via Redis Cache.
CQRS Read-Side. Konsumiert Events aller 6 anderen Services via durable NATS Consumer, materialisiert 14 Faktentabellen (rpt_*), berechnet OEE/MTBF/MTTR/Termintreue on-read mit Redis Cache. Schreibt Zeitreihen in InfluxDB für Grafana.
Personalplanung (PEP): Schichtkalender, Wochenplanung, Qualifikationszuordnung. Der integrierte ArbZG-Validator prüft Ruhezeiten und Höchstarbeitszeiten. Timefold-Solver für automatische Optimierung.
BPMN-basierte Qualitätssicherung und Arbeitsanweisungen via Flowable 7.1. Prüfpläne werden als BPMN-Prozesse definiert, versioniert und am Terminal ausgeführt. Fotos, Messwerte, Checklisten – alles in einem Schritt.
Stammdatenverwaltung für Artikel, Maschinen, Arbeitspläne, Störgrundkatalog und Werker. Alle Änderungen werden als Events auf PX_MASTERDATA publiziert – alle anderen Services halten ihre eigene Read-Kopie.
Protokoll-Bridge zwischen Maschinenebene und der zentralen Plattform. Empfängt Rohdaten von Terminals, IoT-Sensoren und Maschinenschnittstellen, enriched und normalisiert Events, publiziert in den zentralen NATS Hub.
Admin-Portal für Systemkonfiguration, Tenant-Verwaltung, Benutzerrollen und Cross-Service-Auswertungen. Aggregiert Kennzahlen aus dem Reporting Service für Executive-Dashboards.
Maschinenanbindung & ERP
Wasabi Works verbindet die Produktionsebene (Terminals, Maschinen, IoT) mit der Planungsebene (ERP, APS) — kein Integrationsprojekt, kein manueller Datenabgleich, kein Datenverlust bei Netzwerkausfall.
ERP → Wasabi Works (INBOUND)
Produktionsaufträge und Arbeitspläne werden via REST Bulk-Import in den Order Service übertragen (/api/v1/import). Idempotenz über externalId-Feld. Masterdata-Sync über separate Endpoints. Kein direkter DB-Zugriff auf ERP-Seite.
Wasabi Works → ERP (OUTBOUND)
Der ESTS Service exportiert BookingFacts (Ist-Zeiten, Mengen, Maschinenstatus) über das Clear-on-ACK Pattern ans ERP. Export läuft idempotent: bei Fehler automatischer Retry, bei Erfolg ACK und Statuswechsel. Kein Datenverlust, kein Duplikat.
Warum Wasabi Works nicht vergisst
Jeder Fachbereich hat seinen eigenen Event-Stream. Kein Modul schreibt direkt in die Datenbank eines anderen. Jedes Ereignis wird persistent gespeichert — auch wenn ein Dienst kurzzeitig nicht erreichbar ist. Kein Datenverlust, keine manuelle Nacharbeit.
| Stream | Subject-Filter | Producer | Consumer (Services) | Retention |
|---|---|---|---|---|
| PX_BDE | ests.v1.> | Edge Service → ESTS | Reporting, Order, Planning | 7 Tage |
| PX_ORDER | order.v1.> | Order Service | Reporting, Planning, ESTS | 7 Tage |
| PX_PLANNING | planning.v1.> | Planning Service | Reporting, Order | 7 Tage |
| PX_PEP | pep.v1.> | PEP Service | Reporting, Planning | 7 Tage |
| PX_FLOW | flow.v1.> | Flow Service | Reporting, Order | 7 Tage |
| PX_MASTERDATA | masterdata.v1.> | Masterdata Service | Alle Services (Read-Kopie) | 7 Tage |
Neue Anforderungen machen nichts kaputt
Drei Muster garantieren, dass kein Event verloren geht, kein Modul seinen Nachbarn zum Ausfall bringt — und neue Anforderungen sicher integriert werden können, ohne bestehende Prozesse zu gefährden.
Transactional Outbox
Jede Datenbankschreiboperation und die dazugehörige Event-Veröffentlichung passieren atomar. Event wird zuerst in die *_outbox-Tabelle geschrieben, dann per Scheduler in NATS publiziert. Kein Event geht verloren, auch wenn NATS kurzzeitig nicht erreichbar ist.
Consumer Deduplication
NATS liefert at-least-once. Jeder Service-Consumer trackt verarbeitete Event-IDs in einer processed_events-Tabelle. Der Guard-Insert nutzt ON CONFLICT DO NOTHING – bei Duplikat kein Fehler, kein doppeltes Processing. Events sind idempotent verarbeitbar.
Resilience: Circuit Breaker + Fault Tolerance
Der NatsPublisher ist mit SmallRye Fault Tolerance abgesichert: CircuitBreaker öffnet nach N Fehlern, Retry mit Backoff, Timeout-Guard. Ein ausgefallener NATS-Server führt zum Outbox-Buffering, nicht zum Dienst-Ausfall. Alle FT-Annotationen greifen über CDI-Proxy.
Bi-Temporalität im ESTS (ESTS v1.5)
Der ESTS-Service speichert jeden Event mit zwei Zeitstempeln: occurredAt (wann es in der Realität passiert ist) und recordedAt (wann es im System ankam). Verspätete Korrekturbuchungen werden korrekt in die Vergangenheit eingespielt, ohne Zeitscheiben zu zerstören. DST-Behandlung über UTC-Speicherung + plantTimezone-Auflösung.
Infrastruktur-Stack
Der gesamte Stack läuft on-premise oder auf Ihrem Hetzner-Server — als Docker Compose, auf bewährter Open-Source-Technologie. Transparent, wartbar und auf Ihrer Infrastruktur.
Sicherheit & Mandantenfähigkeit
Jede API-Anfrage trägt ein JWT mit Tenant-ID und Rollen. Kein Service liefert Daten fremder Mandanten aus – auch nicht bei Implementierungsfehlern.
8 MES-Rollen
Authentik verwaltet 8 vordefinierte Rollen für typische Fertigungsorganisationen. Die Rollenzuordnung erfolgt per Blueprint automatisch beim ersten Start.
Tenant-Isolation
Jeder Request trägt die Tenant-ID im JWT. Der TenantFilter (JAX-RS, Priority AUTHORIZATION) injiziert den TenantContext. Alle DB-Queries fügen automatisch WHERE tenant_id = ? hinzu.
Fehlerformat: RFC 9457
Alle Services geben Fehler im standardisierten Problem Detail Format zurück (RFC 9457). Jeder Fehlercode folgt dem Schema PX-{SERVICE}-{HTTP}, z.B. PX-RPT-404. Maschinenlesbar, dokumentiert, konsistent.
Observability
Jeder Service emittiert OpenTelemetry Traces (Jäger), Prometheus Metrics und strukturierte JSON-Logs (Filebeat → Elasticsearch). Correlation-IDs durchziehen jeden Request von der Antwort bis in die Datenbank.
Vollständiger Tech-Stack
Open Source. Production-proven. Kein Vendor Lock-in. Alle Komponenten können einzeln ausgetauscht werden.
| Komponente | Technologie | Warum |
|---|---|---|
| Backend Runtime | Quarkus 3.32.1 · Java 25 | Sub-100ms Startzeit, reactive-first, native-fähig. Ideal für containerisierte Microservices mit geringem Memory-Footprint. |
| Frontend | Angular 21 · Nx Monorepo | Typsicher, component-basiert. Nx ermöglicht Code-Sharing zwischen 9 Modul-Apps ohne Duplikation. |
| Messaging | NATS JetStream 2.10 | Schnellstes persistentes Messaging-System. Native Leaf-Node-Unterstützung für Edge-Deployment. Einfacher als Kafka, mächtiger als RabbitMQ für diesen Use Case. |
| Datenbank | PostgreSQL 16 | JSONB für flexible Schemas (Constraints, Capabilities). Reaktiver PgPool für Non-blocking I/O. Schema-Trennung statt Multi-DB für operationale Einfachheit. |
| APS Solver | Timefold 1.31.0 | OptaPlanner-Nachfolger. HardMediumSoftScore, 18 Constraints. Einziges Open-Source APS-Framework für Java mit Produktionsreife. |
| Workflow Engine | Flowable 7.1 (BPMN 2.0) | Prüfpläne und Arbeitsanweisungen als versionierte BPMN-Prozesse. QA-Ingenieure gestalten Flows ohne Code. |
| Identity | Authentik 2024.12 | Self-hosted OIDC. Blueprint-Bootstrapping für Demo-User. Keine externe SaaS-Abhängigkeit für Kundendaten. |
| Zeitreihen | InfluxDB 2.7 + Telegraf | machine_state und machine_throughput als Zeitreihen für Grafana-Dashboards. Batch-Write reduziert DB-Last. |
| Tracing | Jäger 1.55 + OTLP | Distributed Tracing über alle Services. Badger-Backend für persistente Dev-Traces ohne Elasticsearch-Abhängigkeit. |
| ORM / Persistence | Hibernate Reactive Panache | Non-blocking DB-Zugriff auf dem Vert.x EventLoop. Panache reduziert Boilerplate für CRUD-Operationen um ~60%. |
| Mapping | MapStruct (CDI) | Compile-time Mapping ohne Reflection. Typsicher. Kein Runtime-Overhead. CDI Component Model für Quarkus native-kompatibel. |
| Resilience | SmallRye Fault Tolerance | @CircuitBreaker, @Retry, @Timeout auf NatsPublisher. Verhindert Kaskaden-Ausfälle bei NATS-Unterbrechungen. |
Wir zeigen Ihnen Wasabi Works live — mit echten Daten, echten Latenzen und echten Szenarien aus Ihrer Fertigung.
Demo anfragen Reporting-Modul ansehen