Middleware xdhub

Unsere Middleware arbeitet im Hintergrund als zentrale Schnittstelle des xdhubs: Sie ruft Daten aus verschiedenen Quellsystemen ab, prüft und transformiert diese und überträgt sie anschließend an die angebundenen Zielsysteme. Probiert gerne unsere Demo und sprecht uns gerne an!
01
Quelle
 
02
Abholen
 
03
Prüfen
 
04
Transformieren
 
05
Übertragen
 
06
RIB 4.0
 

QUELLSYSTEME

xdhub

+

Materialkataloge

Testkatalog
3 Positionen
TEST-001 Stahl HEA 200 · 450,00 EUR

Kunden verbinden ihr xdhub-Konto einmal mit der Middleware.

Nach einem Kauf läuft die Übertragung automatisiert. Bleibt die Meldung aus, kann die Übertragung auch manuell gestartet werden.
Quellsystem A

+

Beispiel: Digitale Produktpässe

WC-230.351.00.0
Geberit ONE Wand-WC
Keramik 100 % · 1,25 kg CO₂eq/kg

In einem Produktpass steht, was ein Bauteil ist: Hersteller, Material, CO₂-Wert, Restwert, Wiederverwendbarkeit.

Beispiel: „Geberit ONE Wand-WC“, Kennung WC-230.351.00.0, Keramik, 1,25 kg CO₂eq/kg.

Weitere Quellen möglich

+

Weitere Konnektoren können hinzugefügt
werden

Weitere Quellsysteme können hinzugefügt werden. Diese Formate kann die Middleware bisher einlesen:
GAEB
DATANORM
JSON
XML
Excel / TSV

Sie möchten Ihre Daten ebenfalls automatisiert in RIB 4.0 einbinden lassen? Kommen Sie gerne auf uns zu und nutzen Sie unser Kontaktformular für eine Anfrage.

→

abrufen

Das ist die Middleware, die im Hintergrund der Kategorie „Content“ arbeitet. Der dargestellte Ablauf zeigt beispielhaft bereits, was passiert, sobald Daten übertragen werden. Klicke oben auf „Datenfluss abspielen“, um live zu verfolgen, wie Daten geholt, geprüft, transformiert und übertragen werden.

Middleware

1

Daten holen

+

Die Middleware holt die Daten oder wird benachrichtigt, sobald es neue gibt – zum Beispiel nach einem Kauf.

2

Daten prüfen

+

Die Middleware liest die verschiedenen Dateiformate und schaut, ob alle nötigen Pflichtfelder da sind. Fehlt bei einem Datensatz etwas, wird er übersprungen und notiert – der Rest läuft weiter.
3
Daten transformieren

+

 
Die Daten werden in das richtige Format übersetzt: aus „preis_netto 450,00“ wird bspw. „RetailPrice 450.0“.
4

Daten übertragen

+

 
Die Daten liegen zum Abruf bereit oder werden direkt übertragen. Geht etwas schief, versucht es die Middleware erneut, nimmt halbe Übertragungen zurück und zeigt den Fortschritt.
Läuft in allen Schritten mit
Zugang & Rollen
Zwischenspeicher
Wiederholung
Wiedervorlage fehlgeschlagener Übertragungen
Aktivitätsprotokoll
Alarme
Versionen & Updates

→

ausliefern
Zielsystem
RIB 4.0

+

Modul „Kalkulation“

Kalkulationspositionen

Modul „Material“

Materialkataloge

Übertragene Daten:

 
Daten können entweder direkt aus RIB 4.0 abgerufen oder über die Middleware an das System übertragen werden.
Betrieb · 5D‑Institut
Admin‑Dashboard

+

Admin Dashboard 5D Institut: Alle Datenflüsse, Fehlermeldungen und den Systemstatus zentral im Blick.

Kunden & Zugriff

Betrieb & Sicherheit

RIB‑Integration
Auswertung
Dokumentation

System‑Health & Alarme

Kunde · Self‑Service
Kundenportal

+

Für Kunden: Verbindungen, Projekte und API-Zugänge eigenständig verwalten.

RIB‑Mandant hinterlegen
Verbindung konfigurieren
API‑Keys / OAuth selbst anlegen
Projekte Datensätzen zuordnen
Onboarding‑Checkliste

Aktivitätslog & Benachrichtigungen

Beispiel-Datensatz

 
 
 
Middleware-Aufbau
1
Daten abholen
+

Für jedes Quellsystem gibt es ein eigenes Adapter-Modul. Es holt neue Daten ab oder nimmt eine Meldung entgegen und prüft laufend per Verbindungstest ob das Quellsystem erreichbar ist.

adapters.py · core/health.py · core/project_product_mapping.py

WAS DAS BEDEUTET
Adapter je Quellsystem (z. B. Quellsystem A)
Regelmäßiger Verbindungstest (Health-Check)
Projekt ↔ Bauteil-Zuordnung
Testdaten für neue Anbindungen
2
Daten prüfen

+

Bevor ein Datensatz weiterverarbeitet wird, läuft er durch eine automatische Prüfung: Sind Produktkennung, Bezeichnung und die anderen Pflichtfelder alle da? Fehlt etwas, wird der Datensatz übersprungen und die Lücke in einer Fehlerliste festgehalten – der Rest läuft weiter.
core/validate.py
WAS DAS BEDEUTET
Pflichtfeld-Prüfung pro Datensatz
Fehlerliste bei fehlenden Angaben
Restliche Datensätze laufen weiter
3
Daten einsortieren
+
Hier steht das eigentliche Regelwerk: Für jede Quelle ist hinterlegt, welches Feld zum Zielsystem gehört. Fertig zugeordnete Datensätze liegen kurz in einem Zwischenspeicher, damit bei einem erneuten Abruf nicht alles doppelt berechnet werden muss.
core/transform.py · core/cache.py
WAS DAS BEDEUTET
Feldmapping-Regeln je Quelle
Kurzzeit-Zwischenspeicher (Cache)
Änderungen ohne Programmieraufwand nachziehbar
4
Daten weitergeben
+
Am Ende stehen die Daten über eine Programmierschnittstelle bereit, aus der RIB 4.0 diese holt oder die Middleware überträgt diese direkt. Schlägt eine Übertragung fehl, wird sie automatisch wiederholt und der Fortschritt sichtbar gemacht.
routers/bauteile.py · routers/dpps.py
WAS DAS BEDEUTET
Programmierschnittstelle (API) je Datentyp
Fortschrittsanzeige
Automatische Wiederholung bei Fehlern
5
Datenschutz & Sicherheit (DSGVO)
+
Alle Verbindungen laufen verschlüsselt (TLS), unabhängig davon, welches Quell- oder Zielsystem angebunden ist. Durchlaufende Daten liegen dabei nur kurz – höchstens 60 Sekunden – im Arbeitsspeicher der Middleware und werden nie dauerhaft gespeichert; bei jedem Neustart ist dieser Zwischenspeicher leer. Von dem, was einmal im Zielsystem angekommen ist, behält die Middleware anschließend nur das Nötigste: einen erzeugten Verweis-Code, den Übertragungsstatus und Zähler – keine vollständigen Zieldaten. Dauerhaft in der Datenbank landen sonst nur die Daten, die für einen erneuten Abgleich gebraucht werden (z. B. welche Position zu welchem Projekt gehört). Passwörter und Zugangsdaten liegen verschlüsselt bzw. nur als Hash vor, nie im Klartext, und Fehlermeldungen aus dem Zielsystem werden vor dem Speichern gekürzt, damit keine sensiblen Freitexte in Protokollen landen.
Traefik + Let’s Encrypt (TLS) · core/cache.py (60s In-Memory) · core/estimate_push_store.py, core/material_push_store.py (nur Code/Status/Zähler) · core/katalog_store.py, core/project_product_mapping.py (PostgreSQL) · core/token_encryption.py, core/customer_store.py · core/data_export_service.py · core/lizenz_scheduler.py
WAS DAS BEDEUTET
Verschlüsselte Verbindung (TLS), systemunabhängig
Durchlaufende Daten nur 60 Sek. im Arbeitsspeicher
Nach der Übertragung: nur Code, Status & Zähler gespeichert – keine Kopie der Zieldaten
Nur Zuordnungsdaten dauerhaft in eigener Datenbank
Passwörter/Zugangsdaten verschlüsselt bzw. gehasht
Konto-Löschung entfernt verknüpfte Daten automatisch
Selbst-Export der eigenen Daten möglich
Läuft unter allen Schritten mit

Zugriffsschutz (API-Schlüssel, Login, Rollen)

Protokoll & Fehlermeldungen

Anmeldung fremder Systeme (OAuth)
Kundenportal & Admin-Bereich
Nutzungs-Statistiken
Grundeinstellungen

config/auth.py · config/logging_config.py · core/key_store.py · core/oauth_tokens.py · routers/metrics.py

Neu Entdecke unsere Webinare: RIB 4.0 · iTWO · digitale Bauprozesse