- Erste Schritte
- Authentication
- Swagger-Definition
- Orchestrator-APIs
- Warnungsanforderungen
- Anfragen zu Assets
- Kalenderanforderungen
- Umgebungsabfragen
- Ordneranforderungen
- Anforderungen für generische Aufgaben
- Jobanfragen
- Bibliotheksabfragen
- Lizenzabfragen
- Paketanfragen
- Berechtigungsabfragen
- Anforderungen für persönliche Arbeitsbereiche
- Prozessabfragen
- Anforderungen von Warteschlangenelementen
- Queue retention policy requests
- Roboteranfragen
- Rollenanfragen
- Zeitplanabfragen
- Anfragen zu Einstellungen
- Anforderungen für Speicher-Buckets
- Aufgabenanforderungen
- Aufgabenkataloganforderungen
- Aufgabenformularanforderungen
- Mandantenabfragen
- Transaktionsanfragen
- Benutzerabfragen
- Webhook-Abfragen
- Plattformverwaltungs-APIs
Overview of the OData protocol and its role in the Orchestrator API
Die Orchestrator-API-Implementierung basiert auf dem OData-Protokoll. OData (Open Data Protocol) ist ein von ISO/IEC zugelassener OASIS-Standard, der einen Satz bester Praktiken zum Aufbauen und Verbrauchen von RESTful APIs definiert.
Das Open Data Protocol (OData) ermöglicht die Erstellung von REST-basierten Datendiensten, welche mit URLs identifizierten und in einem Datenmodell definierten Ressourcen ermöglichen, mit einfachen HTTP-Meldungen von Webclients veröffentlicht und bearbeitet zu werden. Diese Spezifikation definiert die Kernsemantik und die Verhaltensaspekte des Protokolls.
Das Standardformat für den Orchestrator OData-Metadatenendpunkt ist JSON und die Metadaten-URL ist https://{yourDomain}/odata. Um das Standardformat in XML zu ändern, hängen Sie /?$format=xml an diese URL an.
Weitere Informationen zu Protokollgrundsätzen und Definitionen finden Sie in der entsprechenden offiziellen OData- Dokumentation.
We aim at compliance with the OData standard, but cannot guarantee it.
While the standard mandates that the metadata endpoint should return XML format by default, we return JSON for historical compatibility.
Logische Ressourcen und Metadaten
Die Orchestrator-API bietet benutzerdefinierte Methoden für die Statusabfrage zu verschiedenen in Orchestrator registrierten Einheiten. Jede logische Ressource ist eine OData-Einheit. Alle Einheiten (wie Roboter, Prozess, Warteschlange) haben Eigenschaften, Beziehungen und Operationen.
Abbildung 1. Orchestrator Entity Framework-Datenmodell
Verfügbare Operationen
CRUD-Vorgänge
Diese Operationstypen stehen meistens in logischen Ressourcen zur Verfügung. Zu CRUD-Operationen gehören GET-, POST-, PUT- und DELETE-Anfragen, aber beachten Sie bitte, dass aus technischen und geschäftlichen Gründen nicht alle logischen Ressourcen diese Verben verwenden.
Anfordern von Daten
Es besteht die Möglichkeit, bestimmte Informationen in Verbindung mit GET-Operationen durch ODaTa-spezifische Parameter von einer bestimmten Ressource anzufordern.
Sie ermöglichen Ihnen, Informationen abzufragen, zu filtern, zu sortieren, auszuwählen und zu erweitern. Ausführliche Informationen finden Sie in der offiziellen OData-Dokumentation.
Benutzerdefinierte Aktionen
Die folgenden benutzerdefinierten Aktionen und Aktionen, die nicht an eine logische Ressource gebunden sind, stehen in der Orchestrator-API zur Verfügung:
- Statusmethoden bieten aggregierte Informationen zu verschiedenen Einheiten.
- Kontomethoden bieten Authentifizierungsmethoden für Orchestrator;
- Warteschlangenmethoden werden vom Roboter verwendet, um auf Warteschlangen zuzugreifen, während der
QueueDefinitions-Endpunkt anstatt für externe Systeme über API verwendet werden sollte; - Methoden für die Aufzeichnung der Warteschlangenverarbeitung bieten statistische und aggregrierte Informationen über Warteschlangen;
- Roboterdienst-Ressourcen können von Orchestrator verwendet werden, um mit dem Roboter zu kommunizieren.
Abbildung 2. Benutzerdefinierte Orchestrator-API-Methoden