Host REST persistenti e temporanei

Il plug-in HTTP-REST supporta due tipi di host REST utilizzabili per creare richieste per gli endpoint REST, ovvero host persistenti e host temporanei.

Differenze tra host persistenti e temporanei

La tabella seguente confronta i due tipi di host REST.


Host persistenti	Host temporanei
Archiviati nel database di Automation Orchestrator.	Non archiviati nel database di Automation Orchestrator. Gli host temporanei sono oggetti virtuali che si trovano nella memoria durante l'esecuzione di uno script.
Archiviati nell'inventario di Automation Orchestrator. Gli host persistenti possono essere visualizzati anche nei menu a discesa del modulo del tipo RESTHost.	Non archiviati nell'inventario di Automation Orchestrator.
Disponibili dopo il riavvio, il failover e l'aggiornamento. Quando un token del workflow viene interrotto, può continuare da dove era rimasto se l'elemento del workflow acquisisce un host REST persistente come input. Utilizzare gli host persistenti come input/output degli elementi del workflow. È possibile crearli all'inizio degli script ed eliminarli quando non sono più necessari.	Non disponibili dopo il riavvio e il failover. Quando un workflow viene interrotto, non può ripristinare un input dell'elemento del workflow che include un host REST temporaneo. Utilizzare gli host temporanei negli script quando si effettuano richieste isolate in un server che altrimenti non viene utilizzato.
Possono essere esportati e importati come elementi delle risorse.	Trasferibili tra diverse istanze di Automation Orchestrator perché vengono creati e gestiti interamente tramite script. Utilizzare gli host temporanei quando si opera in più ambienti in cui non è necessario eseguire la migrazione degli host persistenti.
Ogni host persistente dispone di un client HTTP dedicato utilizzato per gestire le richieste all'endpoint.	Gli host riutilizzano la stessa istanza del client HTTP.
Le richieste parallele sono supportate per gli host persistenti e temporanei. Se si attivano le richieste parallele, ogni richiesta viene eseguita con un contesto separato e lo stato, inclusi i cookie, non viene conservato tra le richieste. Se il supporto per le richieste parallele è disattivato, le richieste consecutive condividono lo stesso contesto HTTP.

Considerazioni per gli host temporanei

Quando si creano host temporanei, si tenga presente quanto segue.

Gli host temporanei passati tra gli elementi del workflow come input/output potrebbero non funzionare in tutti i casi. Gli host temporanei si basano sulla cache dei workflow, che ad esempio non funziona quando vengono avviati workflow asincroni. È possibile che anche i workflow nidificati non vengano eseguiti correttamente.
Solo le richieste GET e HEAD vengono reindirizzate automaticamente. Il reindirizzamento dell'URL utilizza la strategia default.
La verifica del nome host non è supportata.
L'autenticazione del certificato client non è supportata.

Risoluzione dei problemi

Se si utilizzano host temporanei senza supporto per le richieste parallele, è possibile che si verifichino regressioni dello scripting in seguito all'aggiornamento dell'ambiente di Automation Orchestrator o all'aggiornamento del plug-in HTTP-REST alla versione 2.4.1.19272162 (o versioni successive). L'utilizzo di istanze di host temporanei diversi per l'esecuzione di richieste, che dipendono tra loro per i cookie, non è supportato.

Per evitare questo problema, utilizzare uno dei metodi seguenti.

Anziché gli host temporanei, utilizzare host e operazioni persistenti. È possibile creare host REST persistenti in due modi.
1. Creare un host REST che punti al server utilizzando il workflow Aggiungi host REST.
  Anziché utilizzare host temporanei, utilizzare l'host REST come input ovunque sia necessario creare una richiesta per tale host.
  - Non creare operazioni temporanee che puntino a questo host. Creare invece operazioni normali.
  - Il supporto per le richieste parallele deve essere disattivato. In caso contrario, i cookie non vengono conservati.
  Questo approccio non è consigliato se si effettuano più richieste in parallelo a questo host nei workflow.
2. Creare un host REST per l'esecuzione del workflow dallo scripting, quindi eliminarlo.
  Utilizzare questo metodo se si effettuano richieste parallele al server. Ad esempio, se si hanno due richieste parallele, creare due host diversi.
  1. Clonare un workflow.
  2. Aggiungere un elemento di scripting in grado di creare l'host che si desidera utilizzare per richieste future.
  3. Utilizzare l'host come output del workflow e come input per tutti gli altri script che inviano richieste a tale host.
  4. Per pulire lo stato, aggiungere un elemento alla fine dello script in grado di eliminare l'host creato.
Utilizzare un host temporaneo per tutte le richieste dipendenti in un determinato workflow e inoltrarlo tra gli elementi del workflow come input/output, secondo necessità.
Il passaggio di host temporanei tra più elementi del workflow non è ufficialmente supportato, ma ne è previsto il regolare funzionamento. Tenere presente che, durante il riavvio, lo stato del workflow potrebbe andare perso e il workflow potrebbe non riprendere correttamente.
Se si utilizzano host temporanei e si desidera creare richieste dipendenti l'una dall'altra per i cookie, è necessario utilizzare la stessa istanza dell'host temporaneo per tutte le richieste. Se le richieste si estendono su più elementi del workflow, creare l'host nel primo elemento del workflow, quindi inoltrarlo come input agli altri.
Utilizzare gli host temporanei correnti, ma modificare le richieste non riuscite in modo che includano i cookie necessari aggiungendo le rispettive intestazioni.
Potrebbe essere necessario analizzare i cookie della risposta precedente e utilizzarli nelle richieste successive.