# Endpoint-Katalog und Netzwerkprobe ## Automatischer Betrieb Der privilegierte Provider liest bei seiner bereits vorhandenen `MSBTS_SendPort`-/`MSBTS_ReceiveLocation`-Abfrage auch die dokumentierten Transportadressen. Fehlt die Datei ```text %ProgramData%\BizTalkCheckmkPulse\data\endpoints.xml ``` wird sie im ersten erfolgreichen Lauf erzeugt. Danach erfolgt der vollständige Abgleich alle `EndpointDiscoveryIntervalHours` (Default: 168 Stunden). Ein Fehler beim Abgleich ersetzt keinen letzten gültigen Katalog. Checkmk meldet den überfälligen/fehlgeschlagenen Abgleich trotzdem als `UNKNOWN`. Bei Installation oder Update ab Version 2.2.4 erzwingt ein einmaliger Provider-Abnahmelauf unabhängig vom Alter einen vollständigen Abgleich. Der Installer akzeptiert den Release erst, wenn der neue Synchronisationszeitpunkt nach dem Start dieses Laufs liegt. Gültige manuelle Overrides werden dabei erhalten; der Katalog wird nicht blind gelöscht. Ab Setup 2.2.6 blockiert ein technisch gültiger Abnahmelauf nicht mehr allein deshalb, weil `BizTalk Endpoint Reachability` fachlich `UNKNOWN` meldet. Die Installation wird mit einer sichtbaren Warnung abgeschlossen; Status, Metriken und Detailtext bleiben im Snapshot erhalten. Ein fehlender, ungültiger oder nicht in diesem Abnahmelauf synchronisierter Katalog bleibt dagegen ein harter Installationsfehler. Unabhängig vom Wochenabgleich wird bei jedem Minutenlauf gegen den aktuellen BizTalk-Runtimezustand gefiltert: - Receive Location nur bei `IsDisabled=false` - Send Port nur bei `Status=Started` - dynamischer Send Port nie als statisches Ziel - Scheduling-Komponente nie als Netzwerkziel Damit wird ein inzwischen gestopptes/deaktiviertes Artefakt sofort nicht mehr geprüft. Prüffähige aktuelle WMI-Adressen werden bei jedem Minutenlauf direkt verwendet; der Wochenabgleich pflegt nur den persistenten, geheimnisfreien Katalog. Dadurch wird weder ein neues Ziel verzögert noch eine bis zu sieben Tage alte Auto-Discovery-Adresse weiter geprüft. Manuelle Overrides gewinnen weiterhin anhand ihres stabilen Artefaktschlüssels. ## Laufzeitbudget Die Socket-Probes werden nach Protokoll, Host und Port dedupliziert und mit maximal `EndpointProbeMaxConcurrency=16` parallelen Verbindungen ausgeführt. Bei `EndpointProbeTimeoutMilliseconds=3000` benötigen 70 vollständig timeoutende eindeutige Ziele theoretisch etwa 15 Sekunden. Die Standardgrenze `EndpointMaxCount=100` begrenzt diesen Anteil eines Providerlaufs auf etwa 21 Sekunden. Die Grenze gilt für deduplizierte Host/Port/Protokoll-Ziele, nicht für die Anzahl der darauf abgebildeten BizTalk-Artefakte. Der Katalog ist separat über `EndpointCatalogMaxEntries=1000` begrenzt. Erwartbar nicht als Socket prüfbare Artefakte zählen nicht gegen das Laufzeitbudget; echte Auflösungslücken werden als `unresolved` mit einem geheimnisfreien Grund gemeldet. Checkmk selbst wartet nicht auf diese Verbindungen, sondern liest nur den zuletzt atomar geschriebenen Snapshot. Die reale ACC-Laufzeit ist nach dem Update an `biztalk_endpoint_probe_duration_ms` sowie an `endpoint_probe_ms` und `elapsed_ms` im Provider-Log zu kontrollieren. Der Scheduled Task verhindert mit `IgnoreNew` überlappende Providerläufe. ## Sicherheitsmodell Der Katalog speichert nicht die vollständige BizTalk-Adresse. Persistiert werden nur: - Artefakttyp, Anwendung, Name und Transportrolle - Adaptername - `TCP` oder `UDP` - Host und Port - `enabled`, `autoDiscovered` und die Best-Effort-Kennzeichnung URI-Benutzerinformationen, Kennwörter, Pfade und Querystrings werden nicht geschrieben. Der Katalog liegt im bereits ACL-geschützten `data`-Verzeichnis; nur Provider und Administratoren dürfen ihn ändern. `LocalSystem` liest nur den separaten, validierten Checkmk-Snapshot. Die automatische Auflösung akzeptiert neben absoluten URIs auch `host:port` und bei FTP/SFTP die schemafreie Form `[benutzer@]host[:port]/pfad`. Die Reihenfolge ist absichtlich eindeutig: `host:port` wird vor der allgemeinen .NET-URI-Auswertung erkannt, damit der Host nicht fälschlich als URI-Schema gedeutet wird. Benutzerinformationen und Pfad bleiben ausschließlich im flüchtigen WMI-Kandidaten und werden nicht persistiert. Eckige URI-Klammern um IPv6-Adressen werden vor der Socket-Probe entfernt. ## Manuelle Korrektur eines automatisch nicht auflösbaren Endpoints Vor einer manuellen Änderung den Scheduled Task kurz stoppen und die Datei sichern. Einen vorhandenen Eintrag auf den gewünschten Host/Port korrigieren und `autoDiscovered="false"` setzen. Der vorhandene `key` bleibt unverändert: ```xml ``` Manuelle Einträge werden beim Wochenabgleich erhalten. Stimmen Artefakttyp und `key` mit einem Send-/Receive-Artefakt überein, gilt weiterhin dessen Started-/Enabled-Filter. Ein zusätzliches, nicht an BizTalk gebundenes Ziel kann `artifactType="Manual"` verwenden; es wird bei `enabled="true"` immer geprüft. Nach dem Speichern Task wieder starten und prüfen: ```powershell Start-ScheduledTask -TaskName 'BizTalk Checkmk Pulse Provider' Get-Content "$env:ProgramData\BizTalkCheckmkPulse\logs\*.log" -Tail 100 & "$env:ProgramFiles\BizTalkCheckmkPulse\BizTalkCheckmkPulse.exe" --consume ``` Ungültiges XML, doppelte Keys, falsche Maschine/Umgebung, unbekannte Protokolle, ungültige Ports und übergroße Dateien werden verworfen. Der Provider kann bei vollständig verfügbarem BizTalk-Runtimezustand einen ungültigen rein automatisch erzeugten Katalog neu aufbauen. Deshalb muss ein manueller Eintrag vor dem produktiven Einsatz gesichert und im Provider-Log verifiziert werden. ## Protokollgrenzen TCP-Connect ist für HTTP(S), SFTP, FTP, SMB/UNC, WCF und `net.tcp` der passende nebenwirkungsfreie Netzwerktest. Er bestätigt DNS, Routing, Firewall und einen annehmenden TCP-Port, aber nicht die fachliche Antwort der Zielanwendung. Oracle-`DATABASE`-Adressen mit explizitem Anbietersegment `/Oracle` verwenden den angegebenen Port oder den Oracle-Standard TCP 1521. WCF-SAP-Adressen verwenden vorrangig den ersten `SAPROUTER=/H/host[/S/port]`-Hop, andernfalls `ListenerGwHost`/`ListenerGwServ` beziehungsweise `GwHost`/`GwServ`. `sapgwNN` wird als TCP `33NN` abgeleitet; der SAProuter-Standard ist TCP 3299. Diese automatisch erkannten Adapterziele sind `bestEffort="true"`: Die Probe wird ausgeführt und gemessen, ein Fehlschlag aber nur in `biztalk_endpoints_best_effort_ignored` gezählt. Nicht sicher ableitbare DATABASE-/WCF-SAP-Adressen werden erwartbar ausgenommen. Ein manueller Katalogeintrag bleibt standardmäßig streng alarmierend und ist die bewusste Option für verbindliche Überwachung. UDP ist verbindungslos. Bei `udp://host:port` bestätigt der Check nur DNS, Route und erfolgreichen lokalen Datagrammversand. Für einen belastbaren UDP-Dienstcheck wäre ein adapter-/protokollspezifisches Request/Response- Payload erforderlich; ein solches fachliches Paket wird bewusst nicht erfunden.