Diese Referenz erklaert die wichtigsten Request-Muster fuer Fernzugriffsablaeufe mit externen Serviceplattformen. Der Fokus ist bewusst praktisch: authentifizieren, Sitzung oeffnen, Status pruefen und sauber beenden.
Authentifizierungsmodell
Verwenden Sie fuer jede Integrationsumgebung eine eigene Service-Identitaet. Fordern Sie das Bearer-Token am Identitaetsendpunkt an und speichern Sie es ausschliesslich im freigegebenen Geheimnisspeicher.
- Betten Sie API-Credentials niemals in Browser-Code oder Geraeteskripte ein.
- Rotieren Sie Client-Secrets nach festem Plan und nach dem Ausscheiden externer Partner.
- Protokollieren Sie die Token-Ausgabe, damit Audits spaeter nachvollziehbar bleiben.
Empfohlener Session-Lebenszyklus
- Erstellen oder erneuern Sie das Zugriffstoken, bevor Sie Session-Aufrufe ausfuehren.
- Pruefen Sie das Zielobjekt auf Online-Status, Zuweisung und erlaubten Wartungszustand.
- Fordern Sie die Fernzugriffssitzung an mit minimaler Rolle und moeglichst kurzer Laufzeit.
- Warten Sie auf Bereitschaft, bis Tunnel oder Broker-Sitzung als aktiv gemeldet werden.
- Starten Sie den Folgeablauf wie Supportwerkzeug, Rueckruf oder Service-Automatisierung.
- Beenden Sie die Sitzung explizit, statt sich auf Zeitlimits zu verlassen.
Hinweise zur Endpunktgestaltung
- Trennen Sie Asset-Aufloesung, Sitzungserstellung und Statusabfrage in eigene Client-Funktionen.
- Behandeln Sie wiederholbare HTTP-Fehler mit begrenztem exponentiellem Backoff.
- Speichern Sie Korrelations-IDs fuer jede Request-Kette, damit Support Fehler schnell nachvollziehen kann.
Warnung
Eine erfolgreiche Sitzungsantwort ist kein Beweis fuer tatsaechliche Fernverbindung. Warten Sie immer auf den Bereitschaftsstatus oder einen Status-Callback.
Minimale Beobachtbarkeit
Pro Ablauf sollten Asset-ID, Anfragezeitpunkt, Operator oder Automationsidentitaet, Sitzungs-ID und Endergebnis protokolliert werden. Diese fuenf Felder reichen in der Praxis fuer die meisten Fehlerbilder aus.