# 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`. 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 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` und `autoDiscovered` 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. ## 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. 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.