# 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. Neue Artefakte werden spätestens beim nächsten Wochenabgleich
aufgenommen.

## 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. Nicht prüfbare aktive BizTalk-Artefakte zählen nicht gegen diese
Grenze; sie werden separat als `unsupported` 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
<Endpoint
  key="SENDPORT|ORDERS|SP ORDER OUT|PRIMARY"
  artifactType="SendPort"
  application="Orders"
  artifact="SP Order Out"
  transportRole="Primary"
  adapter="Custom Adapter"
  protocol="TCP"
  host="gateway.example.internal"
  port="7443"
  enabled="true"
  autoDiscovered="false" />
```

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.