AE-REST-API - Allgemeine Informationen
Als Entwickler oder Systemadministrator können Sie über die REST-API mit dem Automation Engine-System über eine technologieunabhängige hochmoderne Schnittstelle kommunizieren.
Dieses Thema beinhaltet Folgendes:
Die AE-REST-API bietet eine Schnittstelle für Anwendungen von Drittanbietern, um mit der Automation Engine zu interagieren. Die AE-REST-API ermöglicht es dem Benutzer, Automation Engine nicht nur mit Java, sondern auch mit anderen Programmiersprachen anzusprechen.
Die REST-Anfragen und -Antworten enthalten JSON-strukturierte Daten:
Optionale Eigenschaften mit dem Wert Null werden in der Antwort-Payload unter Umständen weggelassen.
Die AE-REST-API unterstützt sowohl HTTP als auch HTTPS (empfohlen). HTTPS kann mit dem Parameter sslEnabled in der Automation Engine-Konfigurationsdatei (ucsrv.ini) eingestellt werden. Weitere Informationen finden Sie unter HTTPS/SSL eingerichtet für AE-REST-API.
Die aktuelle Version der AE-REST-API ist v1. Diese Informationen spiegeln sich in der URI wider und sind daher für den Zugriff auf Ihre AE-REST-API-Schnittstelle relevant.
Die AE-REST-API kann mehrfach installiert werden. Die Installation kann entweder mit unterschiedlichen Portnummern auf einem Knoten oder auf verschiedenen Knoten mit derselben Portnummer erfolgen.
Hinweise:
-
Alle Zeitstempelwerte werden als in der Datenbank gespeicherte Werte zurückgegeben und nicht von der Automation Engine konvertiert. Der REST-Mandant ist für die Konvertierung verantwortlich.
-
Die Automation Engine prüft nicht, ob bei der Ausführung eines Objekts ein Zeitzonenobjekt vorhanden ist. Auch die AE-REST-API überprüft dies nicht.
-
Wenn Sie die AE-Authentifizierung verwenden und ein Benutzerobjekt importieren, ist der Benutzer gesperrt. Es muss im Mandanten 0 entsperrt sein und ein neues Passwort gesetzt werden. Dieses Verhalten gilt nicht bei Verwendung der LDAP-Authentifizierung.
AE-REST-API und ILM
Beim täglichen Betrieb eines Automation Engine-Systems sammeln sich große Mengen an Report-, statistischen und Verlaufsdaten an. Eine Partitionierung der Datenbank mit ILM ist eine effiziente Methode, um mit diesen Mengen umzugehen und die Objektversion ebenso zu erhalten wie die gelöschten Objektdaten. ILM-Aktionen erfordern das Ausschalten von Teilen der Automation Engine-Datenbanktabellen; daher sollten während der Arbeit mit ILM keine Datenbankaktionen stattfinden.
Wichtig! Der AEREST-Webservice erkennt automatisch, ob es laufende ILM-Aktionen gibt und blockiert in diesem Fall bestimmte REST-Anfragen. In diesem Fall wird eine Fehlermeldung zurückgegeben, die anzeigt, dass die REST-API aufgrund von ILM-Aktionen vorübergehend nicht verfügbar ist.
REST-API-Meldungen sind standardmäßig auf Englisch. Die AE-REST-API unterstützt keine andere Sprache.
Mehrere REST-API-Prozesse einrichten
Die JCP-Installation ist sowohl für die AE-REST-API als auch für die erweiterte Objektsuche relevant. Sie können ein einzelnes JCP installieren. In diesem Fall werden alle REST-Anfragen an diese einzelne AE-REST-API-Instanz gesendet, und es ist keine REST-API verfügbar, wenn das JCP ausgefallen ist.
Sie können auch ein System mit mehreren JCPs einrichten. In diesem Fall werden zwei JCPs in einem Cluster verwendet, aber nur eines von beiden ist dann verfügbar.
Wichtig! Bei der Verwendung mehrerer JCPs ist es zwingend erforderlich, dass jedes JCP seine eigene Automation Engine-Konfigurationsdatei (ucsrv.ini) verwendet. Wenn nur eine INI-Datei für mehr als einen JCP verwendet wird, verbindet sich der erste erfolgreich, während die anderen beim Versuch, den gleichen REST-Port zu registrieren, abgebrochen werden, wenn beide auf demselben Knoten laufen. In die Logdatei des JCP wird eine Fehlermeldung unter Angabe des Abbruchgrundes geschrieben.
Die Einrichtung eines Systems mit mehreren JCPs kann für den Abgleich und die Bereitstellung von Ausfallsicherungen sinnvoll sein, da die REST-Anfragen gesendet und nur an verfügbare JCPs verteilt werden.
Um diese Konfiguration nutzen zu können, muss auf jedem Knoten ein JCP installiert sein. Port1 und Port2 können die gleiche Portnummer haben (z.B. 8088, der Standardwert in der Konfigurationsdatei), da die JCPs/REST-Webservice auf verschiedenen Hosts (Host1 und Host2) laufen. Host3:port3 muss als singulärer Kontaktpunkt für alle AE-REST-API-Anfragen öffentlich zugänglich sein. Host1:port1 und Host2:Port2 dürfen nur dem HTTP/HTTPS-Proxy bekannt sein.
Wenn eine virtuelle IP verwendet wird, können beide JCPs über die gleiche IP-Adresse erreicht werden, was bedeutet, dass die Endpunkte die gleiche Basis-URI haben: http(s)://{host}:{port}/AE/api/v1/{client}/....
Der REST-Client oder ein HTTP/HTTPS-Proxy sendet periodisch eine /ping-Anfrage, um die Verfügbarkeit des JCPs zu überprüfen. Abhängig vom Ergebnis weiß der HTTP/HTTPS-Proxy, welche JCPs derzeit verfügbar sind.
- In einer aktiv/aktiv Einstellung für hohe Verfügbarkeit sollen beide verfügbar sein.
- In einer aktiv/passiv Einstellung für hohe Verfügbarkeit soll nur einer verfügbar sein.
Der REST-Mandant oder HTTP/HTTPS entscheidet dann, wohin die REST-Anfragen gesendet werden, abhängig von der Auswahlstrategie des Proxy. Wenn der REST-Mandant Anfragen an den HTTP/HTTPS-Proxy (Host3:Port3) sendet, sendet der Proxy diese automatisch an einen JCP/REST-Webservice.
- Bei einer aktiv/aktiv Einstellung für hohe Verfügbarkeit sendet er sie an eine der beiden verfügbaren. Welche davon verwendet wird, hängt von der Auswahlstrategie des Proxy ab (z.B. niedrigste Last oder Verbindungen).
- Bei einer aktiv/passiv Einstellung für hohe Verfügbarkeit sendet er sie normalerweise an den verfügbaren.
Die AE-REST-API bietet zwei verschiedene Statusprüfungen:
-
eine schnelle / ping-Anfrage, die von HTTP/HTTPS-Proxys verwendet werden soll, um sicherzustellen, dass der JCP- und REST-Webservice verfügbar ist. Diese Statusprüfung liefert keine Details zu den benötigten Backend-Komponenten:
../ping
-
eine Systeminformations-Statusprüfung, die Details über den JCP- und REST-Webservice liefert. Diese Statusprüfung liefert auch Details zu den benötigten Backend-Komponenten:
../{client}/system/health
Die AE-REST-API unterstützt die Standardauthentifizierung. Die Benutzer-, Abteilungs- und Passwortinformationen sind Teil des HTTP(S)-Headers und werden daher für die Standardauthentifizierung verwendet. Die Automation Engine entscheidet, ob eine REST-Anforderung im Benutzerkontext erlaubt ist oder nicht und antwortet entsprechend.
Die AE-REST-API unterstützt keine Passwortverschlüsselung für das Passwort, das in der REST-Anfrage angegeben ist. Es wird empfohlen, HTTPS zu verwenden, um die Übertragung dieser Informationen zu sichern.
Berechtigungen
Ein effizientes und sicheres System zum Schutz des Datenzugriffs ist ein wesentlicher Bestandteil unseres Sicherheitskonzepts. Die Sicherheit auf Datenebene kann so umfassend sein wie der Administratorzugriff auf eine Rolle oder so hochdetailliert wie „Lesezugriff auf nur einen Job in einem bestimmten Ordner“.
Die AE-REST-API erfordert auch bestimmte Berechtigungen, um verschiedene Operationen durchzuführen, und prüft, ob sie bei der Ausführung vorhanden sind.
-
Um Variablen, Kommentare und Reports einer Ausführung (GET) abzurufen, benötigen Sie die Berechtigung S - Ausführungen.
-
Um einer Ausführung (POST) Kommentare hinzuzufügen, benötigen Sie die Berechtigung M - Modifizieren zur Laufzeit.
Weitere Informationen finden Sie unter Automation Engine-Berechtigungen gewähren.
Um Timeouts bei Anfragen zu vermeiden, müssen die auszuführenden Objekte die Eigenschaft Aufgabe zur Laufzeit generieren haben. Beim Ausführen eines Objekts prüft das System, ob diese Eigenschaft entsprechend gesetzt wurde. Wenn sie nicht gesetzt ist, wird die Ausführung nicht gestartet.
Durch das Setzen dieser Eigenschaft wird die RunID sofort zurückgegeben, so dass die REST-Antwort sofort der Anforderung folgt.
Wenn diese Eigenschaft auf Generiere Aufgabe zur Aktivierungszeit gesetzt ist, kann eine lange Verarbeitung die sofortige REST-Antwort verhindern, was zu einem Timeout führen kann.
Hinweis: Beim Neustart einer Ausführung ist die Eigenschaft Aufgabe zur Laufzeit generieren nicht gesetzt.
Sie können den Server abfragen, um den Status einer REST-Anforderungs-/Antwort-Sequenz zu überprüfen, falls das gewünschte Ergebnis noch nicht verfügbar ist. Beispielsweise können Sie den Server abfragen, nachdem Sie ein Objekt ausgeführt und die RunID erhalten haben, um zu überprüfen, ob die Ausführung beendet ist.
Das folgende Beispiel zeigt, wie die Abfrage des Ausführungsstatus über die AE-REST-API erfolgen kann:
PromptSet-Variablen können bei der Ausführung durch die AE-REST-API-Anforderung übergeben werden, da den auszuführenden Objekten mindestens ein PromptSet zugeordnet ist.
Beispiel für den Inhalt einer REST-Anfrage:
| PromptSet-Variable | Feldtyp | Empfehlungen |
|---|---|---|
| „&TEXT1#“ | Textfeld | K.A. |
| „&NUMBER1#“ | Zahlenfeld | K.A. |
| „&CHECKBOX_ARRAY#“ | Checkbox-Feld* | Array=true |
| &CHECKBOX_STRING# | Checkbox-Feld | Array = falsch, Trennzeichen = „;“ |
| „&MULTILINE1#“ | Mehrzeiliges Textfeld | Eigenschaft „Mehrzeilig“ aktiviert, \n für Zeilenumbrüche |
* Es wird empfohlen, ein Checkbox-Feld als Array zu definieren, wenn es verwendet wird, um Werte über die AE-REST-API zu übergeben.
Hinweise:
-
Die Eigenschaft „Array“ des PromptSet-Feldes CHECKBOX_ARRAY muss auf true gesetzt werden, da es von Automation Engine als Array behandelt werden muss.
-
Hier können keine Objektvariablen gesetzt werden.
-
Einige REST-Anfragen enthalten die Parametereingaben, die PromptSet-Variablen auflisten. Dieser Kontext impliziert, dass es sich bei allen um Variablen handelt und es besteht keine Notwendigkeit, explizit ein vorangestelltes „&“ anzugeben. Das nachgestellte „#“ hängt von der Variablendefinition ab.
Die Anfrage GET ../v1/{client}/executions liefert eine Liste aller Ausführungen. Sie können Abfrageparameter als Teil der URI hinzufügen, um sie zu filtern.
Hinweis: Die Automic Web Interface hat verschiedene Einstellungen für Listenansichten, die für die Anwendung von Filtern relevant sind. Die hierarchische Ansicht, die bei Verwendung von Filtern nur Parent-Aufgaben betrifft, und die Listenansicht, die sowohl Parent- als auch Child-Aufgaben betrifft. Die AE-REST-API unterstützt nur die Listenansicht.
Sie können Filter für die folgenden Ausführungsparameter anwenden:
-
Name
Geben Sie den Namen (..?name=[NAME]) oder einen Teil des Namens (..?name=[NAM]*) der gesuchten Ausführung ein.
Hinweis: Sie können den Abfrageparameter nur einmal verwenden.
-
Alias
Der Alias ist ein optionaler, zusätzlicher Name, der einer Aufgabe gegeben wird, wenn sie Teil eines Workflows ist. Ist ein Alias definiert, wird er anstelle des Namens angezeigt.
Geben Sie den Alias (..?alias=[NAME]) oder einen Teil des Alias (..?alias=[NAM]*) der gesuchten Ausführung ein.
Hinweis: Sie können den Abfrageparameter nur einmal verwenden.
Wenn Sie Sonderzeichen für den Ausführungsalias setzen möchten, müssen Sie den Parameter ALIAS_SPECIAL_CHARACTERS in UC_CLIENT_SETTINGS - Diverse Mandanten-Einstellungen im jeweiligen Mandanten definieren.
-
Type
Sie können Abfrageparameter zum Filtern für die folgenden Objekte hinzufügen: CALL, SCRI, JOBD, CPIT, JOBG, C_PERIOD, JOBF, REPORT (nur Job-Reports von Agenten), JSCH, JOBP, JOBS, JOBQ, EVNT, API, C_HOSTG.
Hinweis: Mit diesem Parameter können Sie mehrere Werte verwenden. Sie können den Parameter entweder einmal verwenden und die Werte durch Komma trennen (Typ=JOBS,JOBP), oder den Parameter mehrmals in einer Anfrage verwenden (type=JOBS&type=JOBP).
-
Zeitraum
Verwenden Sie eine Kombination der folgenden Parameter, um Ausführungen innerhalb eines bestimmten Zeitraums zu finden.
-
time_frame_option: Verwenden Sie diesen Parameter, um festzulegen, welche Art von Ausführungen Sie innerhalb eines bestimmten Zeitraums finden möchten. Die Werte, die erlaubt sind, sind:
-
all: alle Ausführungen, die innerhalb des angegebenen Zeitraums starten, enden oder ausgeführt werden
-
activation: alle Ausführungen, die innerhalb des angegebenen Zeitraums aktiviert wurden
-
start: alle Ausführungen, die innerhalb des angegebenen Zeitraums gestartet wurden
-
end: alle Ausführungen, die innerhalb des angegebenen Zeitraums beendet wurden
-
-
time_frame_from: Startdatum und Zeitraum
-
time_frame_to: Enddatum und Zeitraum
-
-
Status
Verwenden Sie diesen Parameter, um nach einem möglichen Status zu suchen, der von der Automation Engine aufgezeichnet wurden. Weitere Informationen finden Sie unter System-Rückgabewerte von ausführbaren Objekten.
Hinweis: Mit diesem Parameter können Sie mehrere Werte verwenden. Sie können den Parameter entweder einmal verwenden und die Werte durch Komma trennen (status=1900,1800), oder den Parameter mehrmals in einer Anfrage verwenden (status=1900&status=1800).
-
agent
Geben Sie den Agentennamen (..?agent=[NAME]) oder einen Teil des Agentennamens (..?agent=[NAM]*) der gesuchten Ausführung ein.
Hinweis: Sie können den Abfrageparameter nur einmal verwenden.
-
platform
Verwenden Sie diesen Parameter, um nach Ausführungen zu suchen, die von einem bestimmten Agententyp verarbeitet wurden, z.B. alle von Windows-Agenten verarbeiteten Ausführungen.
Hinweis: Mit diesem Parameter können Sie mehrere Werte verwenden. Sie können den Parameter entweder einmal verwenden und die Werte durch Komma trennen (platform=WIN,LINUX), oder den Parameter mehrmals in einer Anfrage verwenden (platform=WIN&platform=LINUX).
-
queue
Verwenden Sie diesen Parameter, um nach Ausführungsqueues zu suchen.
Hinweis: Mit diesem Parameter können Sie mehrere Werte verwenden. Sie können den Parameter entweder einmal verwenden und die Werte durch Komma trennen (queue=CLIENT_QUEUE,PRIO_QUEUE), oder den Parameter mehrmals in einer Anfrage verwenden (queue=CLIENT_QUEUE&queue=PRIO_QUEUE).
-
include_deactivated
Verwenden Sie include_deactivated, um deaktivierte Ausführungen bei der Anwendung von Filtern in die Suche einzubeziehen, da sie standardmäßig nicht berücksichtigt werden.
Dieser Parameter kann sich auf den Zeitraum auswirken:
-
Wenn der Parameter =false oder missing ist und kein Zeitraum definiert ist, ist der interne Standardwert für den Zeitraum unbegrenzt.
-
Wenn der Parameter =true ist und kein Zeitraum definiert ist, ist der interne Standardwert für den Zeitraum 12 Stunden.
-
Sie können die Abfrageparameter beliebig kombinieren, um einfache oder komplexe Filter zu erstellen. Zum Beispiel können Sie:
-
Nach einem bestimmten Ausführungsnamen mit Ausnahme deaktivierter Ausführungen suchen
../executions?name=JOBS.24
-
Nach einem bestimmten Ausführungsnamen inklusive deaktivierter Ausführungen suchen
../executions?name=JOBS.24&include_deactivated=true
-
Nach einem bestimmten Satz von Ausführungsarten suchen
../executions?type=JOBP&type=JOBS
../executions?type=JOBP,JOBS
-
Nach einem absoluten Zeitraum suchen
../executions?time_frame_option=all&time_frame_from=2017-07-04T12:43:45Z&time_frame_to=2017-07-04T06:23:12Z
-
Wildcards verwenden (unterstützt für name, alias, agent, user, und archive_key1&2)
Hinweis: Wenn Sie bei Ihrer Suche die Wildcard * verwenden, können Sie den jeweiligen Abfrageparameter nur einmal verwenden.
../executions?name=NAME
../executions?alias=NAM*
-
Komplexe Filter verwenden
../executions?name=OBJECT&type=JOBP&type=JOBS&queue=CLIENT_QUEUE&queue=PRIO_QUEUE&status=1900,1800&include_deactivated=true&time_frame_option=all&time_frame_from=2017-07-04T12:43:45Z&time_frame_to=2017-07-04T06:23:12Z
Nummerierung für Ausführungs-Children und -Listen
Eine Nummerierung kann nützlich sein, wenn eine Anfrage an die AE-REST-API zahlreiche Ergebnisse liefert, da die Ergebnismenge, die sich schnell und oft ändern kann, pro Anfrage/Antwort in Blöcke (Seiten) unterteilt wird. Wenn Sie beispielsweise eine Anforderung senden, um alle Children einer bestimmten Ausführung zu erhalten, können Tausende von Records abgerufen werden. In der AE-REST-API können Sie die Nummerierung verwenden, um die Ergebnisse einfach zu handhaben.
Grenzparameter
Die AE-REST-API ermöglicht es Ihnen, die folgenden Grenzparameter einzustellen:
-
max_results
Definiert die maximale Anzahl der Ergebnisse pro Seite.
Standardwert: 50
Wenn dieser Parameter weggelassen wird, wird der Standardwert verwendet.
-
start_at_run_id
Definiert die RunID des letzten Eintrags der vorherigen Seite.
Wenn dieser Parameter weggelassen wird, wird die erste Seite zurückgegeben.
URI-Struktur mit Nummerierungsparametern
Der URI einschließlich der Nummerierungsparameter besteht aus den folgenden Elementen:
http://{host}:{port}/AE/api/v1/{client}/executions/{runid}/children?max_results={number}&start_at_run_id={runid}
Zum Beispiel:
http://192.168.40.116:8088/AE/api/v1/100/executions/1003003/children?max_results=10&start_at_run_id=100301
In diesem Beispiel hat die angeforderte Parent-Ausführung 1003003 25 angeforderte Children-Ausführungen. Die nummerierte Antwort ist wie folgt verteilt:
| Seite | Anfrage-URI | Antwort-Payload | Kommentar |
|---|---|---|---|
| 1 | ../executions/1003003/children?max_results=10 |
Liste der ersten 10 Ausführungen RunID der letzten aufgelisteten Ausführung =1003045 "hasmore"=true(*) "total"=25(**) |
Wenn der Parameter start_at_run_id weggelassen wird, wird die erste Seite zurückgegeben. |
| 2 | ../executions/1003003/children?max_results=10&start_at_run_id=1003045 |
Liste der nächsten 10 Ausführungen RunID der ersten aufgelisteten Ausführung <1003045 RunID der letzten aufgelisteten Ausführung =1003034 "hasmore"=true(*) "total"=25(**) |
Die RunID der ersten Ausführung auf Seite 2 ist niedriger als die RunID der letzten Ausführung auf Seite 1, wodurch doppelte Einträge vermieden werden. |
| 3 | ../executions/1003003/children?max_results=10&start_at_run_id=1003034 |
Liste der nächsten 5 Ausführungen RunID der ersten aufgelisteten Ausführung <1003034 RunID der letzten aufgelisteten Ausführung =1003028 "hasmore"=false(*) "total"=25(**) |
"hasmore"=false bedeutet, dass dies die letzte Seite ist. |
-
* total: gibt die Gesamtzahl an Ressourcen in der Sammlung an und hilft zu bestimmen, wie viele Seiten das Ergebnis haben würde.
-
**hasmore: hat die folgenden möglichen Werte:
-
true = es sind mehr Seiten verfügbar
-
false = Sie haben die letzte Seite erreicht
-
Hinweise:
-
Die Ausführungen, die auf einer bestimmten Seite angezeigt werden, sind nach Aktivierungszeit und RunID absteigend geordnet.
-
Die Nummerierung kann eine unvollständige Liste von Ausführungs-Children liefern. Wenn beispielsweise eine angeforderte Seite P alle Ausführungen mit Aktivierungszeit >=T1 und RunID < R1 auflistet und zu einem späteren Zeitpunkt eine neue Ausführung E mit gleicher Aktivierungszeit, aber mit RunID < R1 erzeugt wird, ist die Ausführung E weder auf Seite P noch auf einer Folgeseite aufgeführt.
Die Seitenumbruch ist auch nützlich, wenn ein Bericht ziemlich groß ist und sein Inhalt in Reportseiten aufgeteilt ist. Die AE-REST-API blendet diese Reportseiten ein.
Grenzparameter
-
max_results
Definiert die maximale Anzahl der zurückgegebenen Einträge (Reportseiten).
Standardwert: 1
Wenn dieser Parameter auf Null (0) gesetzt ist, werden keine Einträge zurückgegeben.
-
start_at
Definiert die Nummer der zurückgegebenen Startseite (Eingabe-/Reportseite).
Standardwert: 1
Wenn dieser Parameter nicht definiert ist, beginnen die zurückgegebenen Einträge mit der ersten Reportseite. Wenn der definierte Wert größer ist als die Anzahl der verfügbaren Einträge, werden keine Informationen zurückgegeben, da die Anforderung den Bereich der verfügbaren Reportseiten überschreitet.
Zum Beispiel:
-
...exectutions/{run id}/reports/REP gibt den vollständigen Report (alle Reportseiten) zurück
-
...exectutions/{run id}/reports/REP?max_results=3 gibt den ersten Brocken von drei (3) Reportseiten zurück (Reportseiten 1, 2 und 3)
-
...exectutions/{run id}/reports/REP?max_results=3&start_at=4 gibt den zweiten Brocken von drei (3) zurück (Reportseiten 4, 5 und 6)
-
...exectutions/{run id}/reports/REP?start_at=2 gibt alle Reportseiten mit Ausnahme der ersten zurück
-
Wichtig! Die AE-REST-API kann nur den Inhalt von Reports anfordern, die in der AE-Datenbank verfügbar sind. Ein Job-Report wird nur dann in der Datenbank gespeichert, wenn die Option „Speichere in: Datenbank“ im Bereich „Job-Report“ der Seite „Jobdefinition“ ausgewählt wurde. Diese Option ist standardmäßig aktiviert.
Alle REST-Aktivitäten können zu Analysezwecken verfolgt werden. Wählen Sie dazu ein JCP aus und klicken Sie mit der rechten Maustaste darauf, um Erweiterte Optionen auszuwählen. Daraufhin erscheint ein Dialog, in dem Sie Trace Flags spezifizieren können.
Die Trace Flag kann auch in der Automation Engine-Konfigurationsdatei (INI) gesetzt werden. Setzen Sie dazu den JCL-Schlüssel im Abschnitt TRACE der INI-Datei. Die relevanten Werte für RA Web Service REST Agent sind:
- 0: Tracing deaktiviert
- 1: Verfolgt REST-Header und -Inhalte
- 2: Verfolgt auch Login-Informationen
Webserver-Konfiguration
Der Automation Engine-REST-Webservice verwendet einen Webserver, der weitgehend eine vordefinierte Konfiguration verwendet.. Als Systemadministrator können Sie die Parameter anpassen, die hier im Abschnitt [REST] der Konfigurationsdatei (ucsrv.ini) aufgeführt sind:
-
Cross-Origin Resource Sharing / Same Origin Policy (CORS/SOP)
-
corsSupportEnabled
-
corsAccessControlAllowOrigin
-
-
GZIP-Komprimierung
-
gzipSupportEnable
-
-
ThreadPool
-
minPoolSize
-
maxPoolSize
-
idleTimeout
-
CORS/SOP
Die Same Origin Policy (SOP) verhindert, dass Webclients Cross-Origin-Anfragen ausführen. Sie können diese Richtlinie mit Cross-Origin Resource Sharing (CORS) umgehen, um Ursprünge (Origins) explizit zu erlauben.
Zum Beispiel:
Host 3 fordert ein Webdokument vom Origin 1 (Host 1, Webserver) unter http://host1:80 (standardmäßiger http-Port) an. Host 3 fordert dann Informationen vom Origin 2 (Host 2, AE) unter http://host2:8080 (standardmäßiger AE-REST-Webservice-Port) an. Die gängigsten Webbrowser prüfen, ob domänenübergreifende Anfragen erlaubt sind oder nicht. Andernfalls ist der Antrag auf den zweiten Origin http://host2:8080 nicht zulässig.
Um solche Cross-Origin-Anfragen zuzulassen, muss der AE-REST-Webdienst dem Webbrowser explizit mitteilen, dass er die Anforderung zulassen soll. Sie können dies mit den folgenden CORS-Parametern im Abschnitt [REST] der Automation Engine-Konfigurationsdatei (ucsrv.ini) definieren:
- corsSupportEnabled=1
- corsAccessControlAllowOrigin=http://host1:80
Wenn der Webserver auf demselben lokalen Host läuft wie der Browser oder Webclient (Host1 = Host3), müssen Sie einen einfachen webbasierten REST-Client implementieren, indem Sie den Parameter corsAccessControlAllowOrigin auf http://localhost:80 setzen.
Komprimierung
Ein REST-Client kann in einer Anforderung angeben, dass die Antwort-Payload komprimiert werden soll, um die Performance zu verbessern. Wenn der REST-Webservice die Kompression unterstützt, sendet er die Payload im gzip-Format zurück.
Die Kompressionsunterstützung ist standardmäßig deaktiviert. Sie können sie mit dem Parameter gzipSupportEnabled im Abschnitt [REST] der Automation Engine-Konfigurationsdatei (ucsrv.ini) aktivieren.
Thread-Pooling
Der Webserver, der vom JCP/REST-Webservice verwendet wird, verarbeitet Anfragen mit Hilfe von Threads. Je mehr Threads verwendet werden, desto mehr REST-Anfragen können parallel verarbeitet werden.
Ein Thread-Pool hält mehrere Threads bereit, um REST-Anfragen zu verarbeiten. Je mehr Anfragen eingehen, desto mehr Threads stellt der Webserver automatisch innerhalb des Bereichs zur Verfügung, der in minPoolSize >= N <= maxPoolSize definiert ist. Wenn einige der N-Threads für einen längeren Zeitraum als den im Parameter idleTimeout definierten Timeout-Zeitraum ungenutzt bleiben, werden diese beendet, um Ressourcen auf dem JCP-Prozess freizugeben.
Siehe auch: