Verbesserung
Wichtig
Detail
Fehlerbehebung
Detail
#25612
Modell Editor zeigt bei Änderungen von Referenzen Verknüpfungsenden in der Attributtabelle an
#26484
In-App Template für Grid und Tabellen: Funktion "Prüfer für Benutzung als Listenelement" bekommt Komponentenmodell nicht
#26569
Fehlende Constraint-Violation beim Löschen von Objekten die von Pflichtfeldern referenziert werden
#26884
Deklarative Formulare: Fehlendes GUI update bei programmatischen Änderungen eines List-wertigen Property
#26885
Constraints an deklarativen Formularen mit Argumenten aus einer Container-Referenz führen bei neuen Elementen zu Fehlern
#26890
Überschriebene Eigenschaften werden beim Booten aus Modelldefinition nicht richtig initialisiert
#26922
Mit generierten Fachklassen erhält ein Default-Provider eines Attributs in einer Nicht-Struktur-Klasse keinen Create-Context
Verbesserung
Herausforderung
Die Systeme der DiFa innerhalb einer Netzwerkarchitektur machen regen Gebrauch von Kafkaschnittstellen, sei es mit TL-Sync oder selbst implementierten Protokollen (z.B. JSON).
Bei HTTP-Servern ist es üblich, dass jegliche Kommunikation serverseitig geloggt wird, z.B. request-logs die die Metainformationen jedweger Anfragen protokollieren. Durch diese Logs lässt sich die Kommunikation über Systeme und unterschiedliche Netzwerkkomponenten nachvollziehen. Im Fehlerfall ist auch ersichtlich, an welcher Stelle die Kommunikation abbricht oder welche Komponenten eine Weiterverarbeitung verweigern.
Die Kommunikation über Kafka hingegen ist in der aktuellen Situation nicht nachvollziehbar, aus mehreren Gründen:
- Producer protokollieren den Versand von Nachrichten nur unzureichend
- Empfänger protokollieren nicht den Empfang von Nachrichten
- Empfänger protokollieren die Verarbeitung von Nachrichten nur unzureichend
- Logdateien werden mit Nachrichteninhalten geflutet
- Loginformationen werden nur ca. 20 Minuten vorgehalten, danach werden Logeinträge aufgrund der schieren Menge überschrieben, Dateigröße und Rolling-File-Nummern nicht ausreichend
- Nachrichteninhalte sind verschlüsselt und dadurch durch Daimler-Tools wie Lenses nicht auffind- und inspizierbar.
Lösungsansatz
Unsere Kafkaimplementierung erzeugt ein Kommunikationsprotokoll. Der Versand und Empfang jeder einzelnen Nachricht wird vor weiterer fachlicher Verarbeitung und unabhängig vom Verarbeitungsergebnis protokolliert (exception save/finally). Die Protokolle enthalten die notwendigen Metainformationen, um den Weg einer Nachricht vom Producer bis zum Consumer nachvollziehen zu können.
Das Logformat ist standardisiert und weitestgehend symmetrisch zwischen Versandlog und Empfangslog zur leichteren Analyse.
Das Protokoll kennt zwei Loglevel:
- INFO: Metainformationen zu einer Nachricht pro Zeile
- DEBUG: Metainformationen + Inhalt einer Nachricht, ggf. mehrere Zeilen
Es gibt ein Versandprotokoll für alle Producer und ein Empfangsprotokoll für alle Consumer (unklar ob dies reicht, oder ob jeder Producer und Comsumer ein eigenes Protokoll erzeugt (eine eigene Datei)).
Die Metainformationen müssen enthalten (obda):
- Zeitstempel des Versands / Empfangs
- Topic
- Message-ID
- Chunk-Informationen (falls vorhanden)
- Offset (falls möglich)
- Anwendungsserver (IP, Hostname, ID des Clusterknotens, o.ä)
- Kafka-Server (IP, Hostname o.ä.)
- Name/ID/Klasse des Producers bzw. Consumers
- tbd...
Die Logeinstellungen sind ausreichend konfiguriert um im INFO-Level die Kommunikation für mind. 1 Woche nachzuhalten.
Der Lösungsansatz beschränkt sich nicht auf EPP, sondern gilt für alle ASCon-Systeme in der DiFa-Landschaft gleichermaßen.
Umsetzung
Ich würde nur darum bitten, dass wir vor der endgültigen Fertigstellung zusammen auf die Umsetzung schauen, insbesondere bei den Loginformationen.
Code Migration
- Kafka Sender und Empfänger haben eine neue verpflichtende Konfigurationsoption: CommonClientConfig.getLogWriter()
- Der tl:KafkaLogWriter dient dazu aus den Kafka Nachrichten die Meta-Daten und Inhalte in brauchbarer Form zu loggen.
- Als Vorlagen für eigene Implementierungen können der tl:TLSyncRecordLogWriter und der tl:KafkaStringLogWriter verwendet werden.
- Um alle Vorkommen zu finden bei denen ein tl:KafkaLogWriter eingetragen werden muss, in allen .config.xml Dateien nach KafkaProducerService und KafkaConsumerService suchen.
- Als Beispiel-Konfiguration kann die Datei com.top_logic.kafka/src/main/webapp/WEB-INF/conf/kafkaConf.config.xml verwendet werden, in der sowohl der tl:KafkaProducerService als auch der tl:KafkaConsumerService vorkommen.
- Der Konstruktor der Klasse tl:ProducerProxy benötigt jetzt als Argument einen tl:KafkaLogWriter.
- Die Klassen tl:CommonClientConfig und tl:KafkaCommonClient haben als zusätzlichen Typ-Parameter jetzt den Typ des Wertes der verschickt bzw. empfangen wird.
Test
Das Kafka Demo einmal mit Log Level DEBUG und einmal mit INFO starten. Jeweils mindestens ein Objekt anlegen. Anschließend prüfen, ob für die Kafka Nachrichten die erwartete Menge an Daten im Log stehen.
- INFO: Nur die Meta-Daten.
- DEBUG: Zusätzlich auch der gesamte Inhalt.
Die Daten müssen sowohl vom Sender als auch vom Empfänger geloggt werden.