biztalk-checkmk-pulse/docs/RTM-Endpoint-Adapterregeln-2026-08-11.md

RTM-Adapterregeln für Endpoint Reachability

Anlass

Die ACC-Ausgabe vom 11.08.2026 zeigte BizTalk Endpoint Reachability = UNKNOWN, obwohl die eigentlichen Socket-Probes in wenigen Millisekunden abgeschlossen waren. Die Detailausgabe bestand überwiegend aus drei Adapterklassen, die der generische URI-Parser nicht fachgerecht einordnen konnte:

• Scheduling-Komponenten ohne externes Netzwerkziel,
• kundenspezifische DATABASE-Adressen, nahezu ausschließlich Oracle,
• WCF-SAP-Verbindungs-URIs mit Gateway- und SAProuter-Parametern.

Diese Fälle dürfen den RTM-Service weder mit Auflösungslücken noch mit Fehlalarmen belasten.

Verbindliche Klassifizierung ab Version 2.2.7

Scheduling

Adaptername oder Adresse mit Schedule/Scheduler wird vollständig als erwartbar ausgenommen. Es erfolgt keine Netzwerkprobe und kein UNKNOWN.

DATABASE / Oracle

Nur die eindeutig erkennbare Form

Database://host[:port]/.../Oracle

wird automatisch aufgelöst. Ein expliziter Port gewinnt; andernfalls wird TCP 1521 verwendet. Andere DATABASE-Anbieter oder nicht eindeutig lesbare Adressen werden erwartbar ausgenommen. Es wird kein UDP-Test erzeugt.

Oracle dokumentiert TCP 1521 als Standardadresse des Listeners und nimmt bei fehlender Portangabe im Easy-Connect-Format ebenfalls 1521 an:

• Oracle: Configuring the Network Environment
• Oracle: Configuring and Administering Oracle Net Listener

WCF-SAP

Microsoft dokumentiert ListenerGwHost, ListenerGwServ und SAPROUTER als Bestandteile der SAP-Verbindungs-URI. Der Parser verwendet in dieser Reihenfolge:

1. erster SAProuter-Hop aus /H/host/S/port,
2. ListenerGwHost und ListenerGwServ,
3. GwHost und GwServ als Fallback.

Numerische Dienste werden direkt übernommen. sapgwNN wird auf TCP 33NN abgebildet. Fehlt bei einem SAProuter-Hop /S/, gilt der dokumentierte Standard TCP 3299. URI-Escapes werden vor der Auswertung dekodiert; Kennwörter, Program-ID, Pfade und Querystrings gelangen weiterhin nicht in Katalog, Log oder Checkmk-Ausgabe.

Quellen:

• Microsoft Learn: Create the SAP system connection URI
• SAP Help: Entries in the Services File
• SAP Help: SAProuter Host and Port

Best-Effort statt Alarm

Automatisch abgeleitete DATABASE-/WCF-SAP-Ziele erhalten im lokalen Katalog bestEffort="true". Sie werden normal dedupliziert und per TCP verbunden.

• Erfolg erhöht die getesteten und verfügbaren Zähler.
• Timeout, DNS- oder Verbindungsfehler erhöht biztalk_endpoints_best_effort_ignored.
• Der Fehler erscheint nicht als unavailable=, erzeugt keinen Warn-Logeintrag pro Minute und ändert den Checkmk-Status nicht.
• Eine nicht ableitbare Adapteradresse zählt zu biztalk_endpoints_expected_non_socket, nicht zu unresolved.

Damit erfüllt der Check die gewünschte „versuchen, sonst ignorieren“-Semantik. Soll ein solches Ziel später verbindlich alarmieren, wird ein manueller Katalogeintrag mit autoDiscovered="false" und ohne bestEffort="true" hinterlegt. Reguläre automatisch erkannte Ziele bleiben ebenfalls streng: Ihre Nichterreichbarkeit ist weiterhin CRIT.

Regression und Abnahme

Die automatisierten Tests decken Scheduler-Ausschluss, Oracle-Standard- und Explizitport, nicht unterstützte DATABASE-Anbieter, WCF-SAP-Gateway, URI-kodierten SAProuter, zielbasierte SAP-Konfiguration ohne ableitbaren Host, Geheimnisschutz und die nicht alarmierende Best-Effort-Ausgabe ab.

Für die Windows-/ACC-Abnahme nach Installation von 2.2.7:

1. Im Provider-Log muss der erzwungene Katalogabgleich erfolgreich sein.
2. BizTalk Endpoint Reachability darf wegen Schedule, DATABASE oder WCF-SAP nicht mehr UNKNOWN werden.
3. biztalk_endpoints_unresolved darf diese drei Klassen nicht enthalten.
4. biztalk_endpoints_best_effort zeigt die tatsächlich abgeleiteten Oracle- und SAP-Ziele; nicht erreichbare davon erscheinen nur in biztalk_endpoints_best_effort_ignored.
5. Ein absichtlich nicht erreichbares reguläres Testziel muss weiterhin CRIT auslösen, damit die strenge Standardalarmierung belegt bleibt.