Das HTTP-REST-Plug-In unterstützt zwei Typen von REST-Hosts, die Sie zum Senden von Anforderungen an REST-Endpoints verwenden können: persistente Hosts und transiente Hosts.
Unterschiede zwischen persistenten und transienten Hosts
Persistente Hosts | Transiente Hosts |
---|---|
Werden in der Automation Orchestrator-Datenbank gespeichert. | Werden nicht in der Automation Orchestrator-Datenbank gespeichert. Transiente Hosts sind virtuelle Objekte, die sich im Arbeitsspeicher befinden, während ein Skript ausgeführt wird. |
Werden in der Automation Orchestrator-Bestandsliste gespeichert. Persistente Hosts können auch in Form von Dropdown-Menüs vom Typ RESTHost angezeigt werden. |
Werden nicht in der Automation Orchestrator-Bestandsliste gespeichert. |
Verfügbar nach Neustart, Failover und Upgrade. Wenn ein Workflow-Token unterbrochen wird, kann er an der Stelle fortgesetzt werden, an der er unterbrochen wurde, wenn das Workflow-Element einen persistenten REST-Host als Eingabe verwendet. Verwenden Sie persistente Hosts als Eingaben/Ausgaben von Workflow-Elementen. Sie können sie zu Beginn der Skripterstellung erstellen und löschen, wenn Sie sie nicht mehr benötigen. |
Nicht verfügbar nach Neustart und Failover. Wenn ein Workflow unterbrochen wird, kann er eine Workflow-Eingabe, die einen transienten REST-Host enthält, nicht wiederherstellen. Verwenden Sie transiente Hosts in der Skripterstellung, wenn Sie isolierte Anforderungen an einen Server stellen, den Sie sonst nicht verwenden. |
Kann als Ressourcenelemente exportiert und importiert werden. | Können über verschiedene Automation Orchestrator-Instanzen übertragen werden, da sie vollständig über Skripts erstellt und verwaltet werden. Verwenden Sie transiente Hosts, wenn Sie in mehreren Umgebungen arbeiten, ohne dass Sie persistente Hosts migrieren müssen. |
Jeder persistente Host verfügt über einen dedizierten HTTP-Client, der für die Verwaltung von Anforderungen an den Endpoint verwendet wird. | Die Hosts verwenden dieselbe HTTP-Client-Instanz wieder. |
Parallele Anforderungen werden für persistente und transiente Hosts unterstützt.
|
Überlegungen zu transienten Hosts
- Transiente Hosts, die zwischen Workflow-Elementen als Eingabe/Ausgabe übergeben werden, funktionieren möglicherweise nicht in allen Fällen. Transiente Hosts sind auf den Workflow-Cache angewiesen, der nicht funktioniert, wenn z. B. asynchrone Workflows gestartet werden. Verschachtelte Workflows schlagen möglicherweise ebenfalls fehl.
- Nur GET- und HEAD-Anforderungen werden automatisch umgeleitet. Die URL-Umleitung verwendet die
default
-Strategie. - Die Verifizierung des Hostnamens wird nicht unterstützt.
- Die Authentifizierung von Client-Zertifikaten wird nicht unterstützt.
Fehlerbehebung
Wenn Sie transiente Hosts ohne Unterstützung für parallele Anforderungen verwenden, kann es nach einem Upgrade Ihrer Automation Orchestrator-Umgebung oder nach einem Upgrade des HTTP-REST-Plug-Ins auf Version 2.4.1.19272162 oder höherzu Skriptregressionen kommen. Die Verwendung verschiedener transienter Hostinstanzen zum Ausführen von Anforderungen, die in Bezug auf Cookies voneinander abhängig sind, wird nicht unterstützt.
- Verwenden Sie anstelle von transienten Hosts persistente Hosts und Vorgänge. Sie können persistente REST-Hosts auf zwei Arten erstellen.
- Erstellen Sie mithilfe des Workflows REST-Host hinzufügen einen REST-Host, der auf den Server verweist.
Verwenden Sie anstelle von transienten Hosts den REST-Host in allen Situationen als Eingabe, in denen Sie eine Anforderung dafür erstellen müssen.
- Erstellen Sie keine transienten Vorgänge, die auf diesen Host verweisen. Erstellen Sie stattdessen reguläre Vorgänge.
- Die Unterstützung für parallele Anforderungen muss deaktiviert werden. Andernfalls werden Cookies nicht beibehalten.
Dieser Ansatz wird nicht empfohlen, wenn Sie in Ihren Workflows mehrere parallele Anforderungen an diesen Host senden.
- Erstellen Sie einen REST-Host pro Workflow-Ausführung über das Skript und löschen Sie ihn dann.
Verwenden Sie diese Methode, wenn Sie parallele Anforderungen an den Server senden. Wenn Sie beispielsweise zwei parallele Anforderungen senden möchten, erstellen Sie zwei verschiedene Hosts.
- Klonen Sie einen Workflow.
- Fügen Sie ein Skriptelement hinzu, das den Host erstellt, den Sie für zukünftige Anforderungen verwenden möchten.
- Verwenden Sie den Host als Ausgabe des Workflows und als Eingabe für alle anderen Skripts, die Anforderungen an diesen Host senden.
- Fügen Sie zum Bereinigen des Status am Ende des Skripts ein Element hinzu, das den von Ihnen erstellten Host löscht.
- Erstellen Sie mithilfe des Workflows REST-Host hinzufügen einen REST-Host, der auf den Server verweist.
- Verwenden Sie einen transienten Host für alle abhängigen Anforderungen in einem bestimmten Workflow und geben Sie ihn je nach Bedarf als Eingabe/Ausgabe zwischen Workflow-Elementen weiter.
Die Weitergabe von transienten Hosts zwischen mehreren Workflow-Elementen wird offiziell nicht unterstützt, sollte aber funktionieren. Beachten Sie, dass der Workflow-Status während des Neustarts möglicherweise verloren geht und der Workflow nicht erfolgreich fortgesetzt werden kann.
Wenn Sie transiente Hosts verwenden und Anforderungen senden möchten, die in Bezug auf Cookies voneinander abhängig sind, müssen Sie für alle Anforderungen dieselbe transiente Hostinstanz verwenden. Wenn sich die Anforderungen über mehrere Workflow-Elemente erstrecken, erstellen Sie den Host im ersten Workflow-Element und geben Sie ihn dann als Eingabe an die anderen Elemente weiter.
- Verwenden Sie Ihre aktuellen transienten Hosts, ändern Sie jedoch die fehlgeschlagenen Anforderungen so, dass sie die erforderlichen Cookies enthalten, indem Sie die entsprechenden Kopfzeilen hinzufügen.
Möglicherweise müssen Sie die Cookies aus der vorherigen Antwort analysieren und in nachfolgenden Anforderungen verwenden.