17 KiB
Komplette Erklärung: ESB Certificate Manager
Was passiert – einzeln, von oben nach unten.
Zertifikat prüfen · Ziele laden · Sonic-API · Container-Neustart.
Diese Datei ist zum Erklären (Präsentation, Kollegen, Übergabe).
Technischer Fokus: aktueller Stand mit MfApi-Neustart und lokaler Zertifikatserkennung.
Teil A – Was die Anwendung ist
A1. Zweck in einem Satz
Die WinForms-App hilft dabei,
- ein Zertifikat als Datei zu erkennen und lokal zu prüfen, und
- einen Sonic-/ESB-Container remote neu zu starten – so ähnlich wie der Restart-Button in der Sonic Management Console (SMC).
A2. Was sie bewusst nicht macht (aktuell)
| Nicht aktiv | Erklärung |
|---|---|
| Zertifikat auf den Server kopieren | Deploy-Button ist ausgeblendet |
| Nach dem Deploy TLS gegen den Endpoint prüfen | früher TLS-Probe – entfernt/deaktiviert |
| XApi importieren | nicht mehr im Pfad |
Neustart per stopcontainer.bat |
oft in SMC-only-Installationen nicht vorhanden |
| Neustart per WinRM / Windows-Login | SMC-User ≠ Windows-User |
| Eigene HTTP-REST-API der App | die App ist kein Server; sie ruft Sonic auf |
A3. Die wichtigsten Namen in eurer Umgebung
| Name | Typ | Beispiel |
|---|---|---|
| Verbindungs-Alias | Eintrag in appsettings |
DE-Test |
| Domain | Sonic-Domain | proalpha-test |
| Container (kurz) | Laufzeit-Container | ct-ZADBService |
| ObjectName (JMX) | vollständige Agent-Adresse | proalpha-test.ct-ZADBService:ID=AGENT |
| ConnectionUrl | Domain-Manager wie in SMC | tcp://dekun-painwbdet:13070 |
| Login | SMC-Credentials | Administrator / Administrator |
| Sonic-Libs | Client-JARs | C:\DEV\MQ10.0\lib |
| Java | Runtime für das Hilfstool | JRE 1.8+ |
Merksatz:
DE-Test = Verbindung. ct-ZADBService = Container. Nicht vertauschen.
Teil B – Programmstart (was zuerst passiert)
B1. Start der App
Program.csstartetForm1.AppSettingsLoaderliestappsettings.json(aus dem Output-Ordner der App).- Es werden gebaut:
DeploymentOrchestrator(Neustart-Orchestrierung)SonicContainerDiscovery(Container-Liste optional laden)
- Die UI (Dark-Design) wird aufgebaut.
- Beim ersten Anzeigen (
Shown) werden Ziele geladen.
B2. Ziele laden
- Ziele kommen aus
appsettings.json→SonicConnections[].KnownContainers(kein Offline-JSON). - Jede Zeile hat u. a.:
- Anzeigename (
DE-Test / ct-ZADBService) - Umgebung = Domain
- ContainerName (z. B.
ct-ZADBService) - SonicConnectionName (z. B.
DE-Test) - Status-Spalte
- Anzeigename (
Optional: Button „Container laden“ fragt Sonic live per API und merged mit KnownContainers.
Teil C – Zertifikat: Erkennen & Verifizieren (Schritt für Schritt)
Hier geht es nur um die lokale Datei. Es wird nichts auf den ESB geschrieben und kein TLS zum Server aufgebaut.
C1. Benutzer wählt Datei
- Klick auf Dateiauswahl in der UI.
OpenFileDialogfiltert:.cer,.crt,.pem,.pfx.- Abbruch → nichts ändert sich.
- Dateiendung wird geprüft (
IsSupportedCertificateFile). - Unbekanntes Format → Warnung, Ende.
C2. Datei lesen
- Aufruf
TryReadSelectedCertificate(pfad). - Intern:
X509Certificate2laden. - PFX-Sonderfall:
- Zuerst Versuch ohne Passwort.
- Bei
CryptographicException→ Passwort-Dialog. - Falsches Passwort → Fehlermeldung, kein Zertifikat geladen.
- Andere Fehler (Datei kaputt, kein X.509) → Fehlermeldung.
C3. Was aus dem Zertifikat extrahiert wird
| Feld | Quelle | Anzeige |
|---|---|---|
| Subject | GetNameInfo(SimpleName) bzw. Subject |
„Ausgestellt für“ |
| Issuer | Issuer-SimpleName bzw. Issuer |
„Ausgestellt von“ |
| Gültig von / bis | NotBefore / NotAfter |
Datum |
| Fingerprint | SHA-256 Hash, mit : formatiert |
z. B. AB:CD:… |
| Gültigkeitsstatus | now zwischen NotBefore und NotAfter? |
grün GÜLTIG / rot UNGÜLTIG |
C4. Was „Verifizierung“ hier genau heißt
| Prüfung | Passiert? | Bedeutung |
|---|---|---|
| Datei lesbar als X.509 | ja | Format/Inhalt ok |
| Zeitlich gültig | ja | nicht abgelaufen / noch nicht gültig |
| Fingerprint anzeigen | ja | manueller Abgleich möglich |
| Signaturkette gegen Windows-CA | nein | nicht implementiert |
| Datei auf ESB kopieren | nein | Deploy aus |
| TLS-Handshake zum Live-System + Fingerprint vergleichen | nein | TLS-Probe aus |
Erklärsatz:
Wir verifizieren das Zertifikat als Datei auf dem PC (lesbar + Gültigkeitszeitraum + Fingerprint).
Wir verifizieren nicht, dass genau dieses Zertifikat schon am laufenden ESB hängt.
Der Neustart ist davon getrennt.
C5. UI nach erfolgreichem Laden
- Pfad steht im Textfeld.
- Metadaten-Karte wird gefüllt.
- Statuszeile: „Zertifikat ausgewählt: …“.
- Sidebar-Schritt kann auf „Ziele“ springen.
- Neustart braucht das Zertifikat nicht zwingend – der Neustart hängt am Container, nicht an der Datei.
Teil D – Vor dem Neustart (Preflight)
D1. Benutzer hakt Ziel(e) an
Im Grid: Checkbox „Selected“ setzen.
D2. Button „ESB neu starten“
GetSelectedTargets()sammelt alle angehakten Zeilen.ValidateRestartOnlyprüft für jedes Ziel:ContainerNamenicht leerSonicConnectionNamenicht leer
- Fehler → Dialog „Neustart blockiert“ mit Liste der Probleme.
- OK → Bestätigungsdialog (Containername, Hinweis auf Management API).
- Nein → Abbruch. Ja → Neustart startet.
Teil E – Neustart Gesamtablauf (C#-Seite)
Alles von hier läuft ohne Zertifikatskopieren.
Form1.RunRestartOnlyAsync
→ DeploymentOrchestrator.RestartOnlyAsync
→ für jedes Ziel:
RestartExecutor.ExecuteAsync
→ SonicManagementClient.RestartContainerAsync
→ SonicMfApiExecutor.RestartAsync
→ java SonicMfContainerTool restart …
E1. Orchestrator
Pro Ziel:
- Status im Grid: „Neustart…“
RestartExecutor.ExecuteAsync(target)- Ergebnis + Detail in Logdatei unter
Logs\ - Status im Grid aktualisieren
- Am Ende: Erfolgs-/Fehlerdialog mit Tool-Ausgabe
E2. RestartExecutor
- Liest
target.ContainerName(z. B.ct-ZADBService). - Sucht in
appsettingsdieSonicConnectionmitName == SonicConnectionName(DE-Test). - Fehlt die Verbindung → Fehler „Sonic-Verbindung nicht gefunden“.
- Sonst:
new SonicManagementClient(connection)undRestartContainerAsync(containerName).
E3. SonicManagementClient
Schlanke Fassade, nur MfApi:
- Ruft
_mfApi.RestartAsync(containerName)auf. - Bei Erfolg: wartet
PostRestartDelaySeconds(z. B. 20 s), damit der Container Zeit zum Hochfahren hat. - Liefert Status-Text + komplette Java-Ausgabe zurück.
- Bei Fehler: Fehlermeldung + Output für den Dialog.
Teil F – SonicMfApiExecutor: Java vorbereiten und starten
Das ist die Brücke von .NET zu Sonic.
F1. Java finden
Reihenfolge grob:
JavaPathaus appsettings (bevorzugt)JavaHome- Umgebungsvariablen / PATH / Registry / unter SonicHome
Bedingung: Runtime muss Java 8+ können (Class-File major ≥ 52).
Zu alte Sonic-JREs (6/7) werden übersprungen.
F2. Classpath bauen (Sonic-JARs)
MfClientLibPath(z. B.C:\DEV\MQ10.0\lib) oder Suche unterSonicHome.- Es müssen echte Client-JARs da sein, u. a.:
mgmt_client.jarmfcontext.jarsonic_Client.jar
- Alle
*.jarim Lib-Ordner werden explizit in den Classpath geschrieben (kein fragileslib\*mit kaputten Quotes). - Das Tool-Verzeichnis
Tools\kommt vorne in den Classpath, damit die richtigeSonicMfContainerTool.classgeladen wird.
F3. Java-Tool laden
- Bevorzugt vorcompilierte
Tools\SonicMfContainerTool.class(Java 8, major 52). - Alte/zu kleine Class-Dateien werden verworfen.
- Temp-Cache alter Compilate wird gelöscht.
- Falls nötig: aus
.javamitjavac --release 8neu bauen.
F4. Prozess starten
Ungefähr:
"C:\...\java.exe"
-cp "C:\...\Tools;C:\DEV\MQ10.0\lib\mgmt_client.jar;...;C:\DEV\MQ10.0\lib\mfcontext.jar;..."
SonicMfContainerTool
restart
--domain proalpha-test
--url tcp://dekun-painwbdet:13070
--user Administrator
--container ct-ZADBService
--timeout 120
Wichtig:
- Argumente über
ProcessStartInfo.ArgumentList(keine doppelten Anführungszeichen). - Passwort über Umgebung
ESB_SONIC_PASSWORD, nicht in der sichtbaren Kommandozeile. - stdout/stderr werden gelesen und an die UI zurückgegeben.
F5. Erfolgsauswertung in C#
Neustart gilt nur als Erfolg, wenn die Ausgabe enthält:
OK:RestartInvoked
Sonst: Fehlerdialog mit kompletter Tool-Ausgabe.
Teil G – Die Sonic Management Application API (Java-Tool)
Hier passiert der eigentliche „API-Call“ – nicht REST, sondern JMS/JMX Management Framework.
Offizielle Produktwelt (Aurea CX Messenger / Sonic):
- Index:
doc-10.0.10/CXMessenger_2017_R3.htm - Eintrag: Management Application API Reference (
Docs2017/api/mgmt_api/)
Das ist dieselbe API-Familie, die die SMC für Restart nutzt.
G1. Warum „API“ hier kompliziert klingt
Die Sonic-Produkt-API enthält sehr viele Bereiche:
- Broker / Queues / Topics
- ESB-Services
- Metrics / Notifications
- Directory / Config
- Agent Lifecycle
Für unseren Neustart brauchen wir nur einen schmalen Teil:
- Verbinden zum Domain Manager
- Agent-ObjectName ansprechen
- Lifecycle: stop/restart
Der Rest der JARs ist Produktumfang – nicht „unsere App-API mit 100 Features“.
G2. Schritt 1 – Tool startet
Ausgabe:
INFO:ToolVersion=2026-07-24c-mbean-stop
Wenn diese Zeile fehlt → oft noch eine alte .class im Einsatz.
G3. Schritt 2 – Argumente parsen
Pflicht:
- Befehl:
ping|list|restart --domain--url--user- bei
restart:--container - Passwort:
--passwordoderESB_SONIC_PASSWORD
G4. Schritt 3 – Connect (der eigentliche API-Login)
Java (vereinfacht, per Reflection):
Hashtable env:
ConnectionURLs = tcp://dekun-painwbdet:13070
DefaultUser = Administrator
DefaultPassword = ***
JMSConnectorAddress address = new JMSConnectorAddress(env)
JMSConnectorClient connector = new JMSConnectorClient()
connector.connect(address, timeout)
Klassen kommen aus den Sonic-JARs:
com.sonicsw.mf.jmx.client.JMSConnectorAddresscom.sonicsw.mf.jmx.client.JMSConnectorClient
Ausgabe bei Erfolg:
INFO:Connected url=tcp://dekun-painwbdet:13070 user=Administrator
Das entspricht dem SMC-Login gegen denselben Domain Manager.
G5. Schritt 4 – Ziel-Agent bestimmen
ObjectName:
proalpha-test.ct-ZADBService:ID=AGENT
Muster:
{DomainName}.{ContainerName}:ID=AGENT
Optional: per queryNames nach vorhandenen Agenten suchen; wenn das scheitert, Preferred-Name verwenden.
G6. Schritt 5 – Lifecycle (Neustart) – drei Wege nacheinander
Weg 1 – MBean invoke (bevorzugt remote)
connector.invoke(objectName, "stop", [], [])
// oder "restart", "shutdown"
Warum zuerst stop?
- Remote-Clients sind oft „unbounded“.
IAgentProxy.restart()wirft dann häufig:
Operation unsupported for unbounded client connector- SMC-Restart wirkt für den Operator oft wie: Stop + automatischer Relaunch durch Launch Daemon / Host Manager.
Erfolg:
OK:RestartInvoked method=MBean.stop container=ct-ZADBService domain=proalpha-test
Weg 2 – Typisierter Proxy
IAgentProxy agent = MFProxyFactory.createAgentProxy(connector, objectName)
agent.stop() / agent.restart() / agent.shutdown()
Schön dokumentiert, remote oft eingeschränkt (unbounded).
Weg 3 – DomainManager / Manager-MBeans
Suche nach Operationen wie:
restartContainer(containerName)stopContainer(containerName)
Fallback, falls Agent-direkt nicht klappt.
G7. Schritt 6 – Disconnect
connector.disconnect() im finally.
G8. Befehle des Tools im Überblick
| Befehl | Zweck |
|---|---|
ping |
Verbindungstest + Agenten zählen |
list |
Containernamen der Domain ausgeben |
restart |
Lifecycle auf einem Container |
Teil H – Komplette Kette als nummerierte Liste
So kannst du es jemandem erzählen:
Zertifikat
- App starten
- Zertifikatsdatei wählen
- Datei als X.509 lesen (PFX ggf. mit Passwort)
- Subject, Issuer, Fingerprint, Gültigkeit anzeigen
- Lokal „verifiziert“ = lesbar + im Gültigkeitszeitraum
Neustart
- Ziel im Grid anhaken (
ct-ZADBService/ VerbindungDE-Test) - „ESB neu starten“ → Preflight → Bestätigung
- C# findet Sonic-Verbindung in appsettings
- C# findet Java 8+ und baut Classpath aus
C:\DEV\MQ10.0\lib - C# startet
SonicMfContainerTool restart … - Java verbindet per Management API an
tcp://…:13070 - Java adressiert
proalpha-test.ct-ZADBService:ID=AGENT - Java ruft Stop/Restart per MBean (Fallback Proxy/Manager)
- Java schreibt
OK:RestartInvoked - C# wartet
PostRestartDelaySeconds - UI zeigt Erfolg/Fehler + Logausgabe
- Optional in SMC prüfen: Uptime/Status des Containers
Teil I – Konfiguration im Detail
I1. appsettings.json (Sonic-Block)
| Feld | Rolle |
|---|---|
Name |
Alias, von Zielen referenziert (DE-Test) |
DomainName |
Sonic-Domain |
ConnectionUrl |
Domain-Manager-URL (wie SMC) |
Username / Password |
SMC-Login |
SonicHome |
Installationsroot |
MfClientLibPath |
Ordner mit Client-JARs |
JavaPath / JavaHome |
Java 8+ |
KnownContainers |
Fallback-Liste, z. B. ct-ZADBService |
TimeoutSeconds |
Timeout Java/API |
PostRestartDelaySeconds |
Wartezeit nach erfolgreichem Invoke |
Felder wie WinRm*, Container*Path, ManagementHttpPort können noch in der JSON stehen, werden vom schlanken MfApi-Client nicht mehr genutzt.
I2. Container-Liste
Kein separates Sample-JSON. Container stehen in:
"KnownContainers": [ "ct-ZADBService" ]
Live-Erweiterung über UI-Button „Container laden“.
Teil J – Dateien und Verantwortlichkeiten
| Datei | Verantwortung |
|---|---|
Form1.cs |
UI, Zertifikat lesen, Neustart-Button, Dialoge |
DeploymentOrchestrator.cs |
Neustart über alle gewählten Ziele |
PreflightValidator.cs |
Pflichtfelder prüfen |
RestartExecutor.cs |
Ziel → SonicConnection |
SonicManagementClient.cs |
Fassade MfApi |
SonicMfApiExecutor.cs |
Java/Classpath/Prozess |
Tools/SonicMfContainerTool.java |
Connect + Lifecycle über Sonic-API |
appsettings.json |
Laufzeitkonfiguration inkl. KnownContainers |
Logs\ |
Laufprotokolle |
Teil K – Erfolgs- und Fehlerbilder
K1. Gesunde Ausgabe (Auszug)
INFO:ToolVersion=2026-07-24c-mbean-stop
INFO:Connected url=tcp://dekun-painwbdet:13070 user=Administrator
INFO:PreferredObjectName=proalpha-test.ct-ZADBService:ID=AGENT
INFO:Trying MBean.invoke(stop) on …
OK:RestartInvoked method=MBean.stop container=ct-ZADBService domain=proalpha-test
K2. Häufige Fehler
| Meldung | Bedeutung | Typische Lösung |
|---|---|---|
ClassNotFoundException: JMSConnectorAddress |
JARs fehlen / Classpath kaputt | MfClientLibPath, neuer Build |
UnsupportedClassVersionError |
Java-Version mismatch | Tool als Java 8 + Runtime Java 8+ |
Operation unsupported for unbounded… |
Proxy-Restart remote gesperrt | MBean-stop-Pfad / aktuelles Tool |
Kein ToolVersion= |
Alte Class-Datei | Neu bauen, richtigen bin-Ordner starten |
Container DE-Test |
Alias statt Kurzname | ct-ZADBService |
stopcontainer.bat fehlt |
SMC-only | normal – MfApi nutzen |
Teil L – Wie man es jemandem erklärt (Kurzskript)
- UI: Zertifikat laden → wir sehen Subject/Fingerprint/Gültigkeit. Das ist lokale Dateiprüfung.
- Neustart: Wir starten denselben Management-Weg wie die SMC, nicht per Batch-Datei und nicht per FTP.
- Technik: C# orchestriert; ein kleines Java-Tool + Sonic-Client-JARs sprechen mit dem Domain Manager.
- API: Sonic Management Application API (JMS/JMX). Sehr große Produkt-API, wir nutzen nur Connect + Agent-Stop/Restart.
- Haken: Remote heißt „unbounded“ – deshalb oft
stopper MBean stattIAgentProxy.restart(). - Ergebnis: Container
ct-ZADBServicein Domainproalpha-testwird neu gestartet; danach in der SMC Status/Uptime prüfen.
Teil M – Abgrenzung: Was ist „unsere API“ vs. Sonic-API?
| Ebene | Beschreibung |
|---|---|
| Unsere App | WinForms + C#-Services. Kein öffentlicher REST-Endpoint. |
| Unser Java-Tool | Dünner Adapter (ping/list/restart) mit Fallbacks. |
| Sonic Management Application API | Produkt-API in den JARs; offiziell dokumentiert; SMC nutzt dieselbe Familie. |
| Unnötig für den Use-Case | MQ Messaging API, ESB API, Metrics, XApi, WinRM, Bat-Scripts, TLS-Probe – solange nur „Datei prüfen + Neustart“ gefragt ist. |
Ende der kompletten Erklärung. Bei Abweichungen gilt der Code im Projekt (Branch mit MfApi-Neustart).