- Erste Schritte
- Swagger-Definition
- Orchestrator-APIs
- Warnungsanforderungen
- Anfragen zu Assets
- Kalenderanforderungen
- Umgebungsabfragen
- Ordneranforderungen
- Generische Aufgabenanforderungen
- Jobanfragen
- Bibliotheksabfragen
- Lizenzabfragen
- Paketanfragen
- Berechtigungsabfragen
- Prozessabfragen
- Roboteranfragen
- Rollenanfragen
- Zeitplanabfragen
- Anfragen zu Einstellungen
- Aufgabenanforderungen
- Aufgabenkataloganforderungen
- Aufgabenformularanforderungen
- Mandantenabfragen
- Transaktionsanfragen
- Benutzerabfragen
- Webhook-Abfragen
Endpunkte zur Zustandsprüfung
Stellen Sie sicher, dass alle Ihre Dienste betriebsbereit sind, indem Sie API-Aufrufe an spezielle Endpunkte, sogenannte Zustandsprüfungsendpunkte, senden.
Diese Endpunkte führen Systemdiagnosen aus und geben einen Status zurück, der Ihnen mitteilt, ob der Dienst, den Sie überprüfen, funktionsfähig ist oder nicht.
Um die Verfügbarkeit Ihrer Orchestrator-Instanz und ihrer Abhängigkeiten zu überprüfen, verwenden Sie die folgenden Endpunkte:
-
Abrufen
https://{yourDomain}/api/health
—überprüft nur kritische Abhängigkeiten -
Abrufen
https://{yourDomain}/api/health/startup
—überprüft jede Abhängigkeit
Standardmäßig geben die obigen Endpunkte der Zustandsprüfung einen leeren Antworttext zurück.
So sehen Sie, welche Systemdiagnosen durchgeführt wurden und welchen Status sie haben:
- In der Konfigurationszuordnung
orchestrator-customconfig
(konfiguriert überorchestrator-configurator.sh
) undFügen Sie<add key="HealthCheck.DetailsKey" value="12345" />
im Abschnitt<appsettings>
hinzu.12345
dient als Kennwort, mit dem Sie auf die Zustandsprüfungen zugreifen können, also vergessen Sie nicht, es durch einen eigenen Wert zu ändern. - Starten Sie IIS neu, um sicherzustellen, dass die Änderung wirksam wird.
- Verwenden Sie das zuvor festgelegte Kennwort als Abfrageparameter im API-Aufruf zur Zustandsprüfung (z. B.
/api/health?detailsKey=password
). Wenn erfolgreich, gibt der Aufruf einen Antworttext mit Details zu den Zustandsprüfungen und deren Status zurück.
Sobald Sie diese Schritte ausgeführt haben, ist die Zustandsprüfung auch von einer anderen Maschine als dem Orchestrator-Server aus zugänglich.
Um zu überprüfen, ob der Identity Server funktioniert, verwenden Sie den folgenden Endpunkt:
-
GET
https://{yourDomain}/identity/health
Der Antworttext dieses Endpunkts fasst die Identity Server-Konfiguration zusammen.
{
"status": "Healthy",
"results": {
"ApplicationDbContext": {
"status": "Healthy",
"description": null,
"data": {}
},
"AuditDbContext": {
"status": "Healthy",
"description": null,
"data": {}
},
"PersistedGrantDbContext": {
"status": "Healthy",
"description": null,
"data": {}
},
"IdentityServerConfigurationDbContext": {
"status": "Healthy",
"description": null,
"data": {}
}
}
}
{
"status": "Healthy",
"results": {
"ApplicationDbContext": {
"status": "Healthy",
"description": null,
"data": {}
},
"AuditDbContext": {
"status": "Healthy",
"description": null,
"data": {}
},
"PersistedGrantDbContext": {
"status": "Healthy",
"description": null,
"data": {}
},
"IdentityServerConfigurationDbContext": {
"status": "Healthy",
"description": null,
"data": {}
}
}
}
Ein 500-Fehlercode signalisiert einen fehlerhaften Status, kann jedoch immer noch einen Antworttext zurückgeben. Überprüfen Sie den Inhalt des Antworttexts, um die Gründe herauszufinden.
Um die Verfügbarkeit Ihres Webhooks-Dienstes zu überprüfen, verwenden Sie den folgenden Endpunkt:
-
GET
https://{yourDomain}/webhooks/api/status
Interpretieren Sie den Antwortcode wie folgt:
200 OK
– Ihr Dienst ist in Betrieb5xx
Fehler – Ihr Dienst ist ausgefallen
200 OK
-Antwortcode und einen Degraded
-Status zurück, was bedeutet, dass sich die überprüfte Komponente in einem herabgesetzten Zustand befindet.