Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Redriving La mappa viene eseguita nelle esecuzioni Step Functions
È possibile riavviare le esecuzioni di workflow secondarie non riuscite in una mappa eseguita da redrivingil tuo flusso di lavoro principale. A redriven flusso di lavoro principale redrives tutti gli stati non riusciti, inclusa Distributed Map. Un flusso di lavoro principale rigenera gli stati non riusciti se non è presente alcun <stateType>Exited
evento corrispondente all'<stateType>Entered
evento per uno stato in cui il flusso di lavoro principale ha completato la sua esecuzione. Ad esempio, se la cronologia degli eventi non contiene l'MapStateExited
evento relativo a un MapStateEntered
evento, puoi redrive il flusso di lavoro principale per redrive tutte le esecuzioni di workflow secondarie non riuscite in Map Run.
Un Map Run non viene avviato o ha esito negativo nel tentativo di esecuzione originale quando la macchina a stati non dispone dell'autorizzazione richiesta per accedere a ItemReader (Mappa)ResultWriter (Mappa), o a entrambi. Se Map Run non è stato avviato nel tentativo di esecuzione originale del workflow principale, redriving il workflow principale avvia Map Run per la prima volta. Per risolvere il problema, aggiungi le autorizzazioni richieste al tuo ruolo di macchina a stati, quindi redrive il flusso di lavoro principale. Se tu redrive il flusso di lavoro principale senza aggiungere le autorizzazioni richieste, tenta di avviare una nuova esecuzione di Map Run che avrà nuovamente esito negativo. Per informazioni sulle autorizzazioni di cui potresti aver bisogno, consulta. IAMpolitiche per l'utilizzo degli stati della mappa distribuita
Argomenti
Redrive idoneità per i flussi di lavoro per bambini in un Map Run
È possibile redrive le esecuzioni non riuscite del workflow secondario in un Map Run se sono soddisfatte le seguenti condizioni:
-
Hai iniziato l'esecuzione del flusso di lavoro principale il o dopo il 15 novembre 2023. Le esecuzioni iniziate prima di questa data non sono idonee redrive.
-
Non hai superato il limite rigido di 1000 redrives di un determinato Map Run. Se hai superato questo limite, riceverai l'
States.Runtime
errore. -
Il flusso di lavoro principale è redrivable. Se il flusso di lavoro principale non lo è redrivable, non puoi redrive le esecuzioni dei flussi di lavoro secondari in un Map Run. Per ulteriori informazioni sull' redrive idoneità di un flusso di lavoro, vedi. Redrive idoneità per esecuzioni non riuscite
-
Le esecuzioni secondarie del flusso di lavoro di tipo Standard in Map Run non hanno superato il limite di 25.000 eventi di esecuzione cronologici. Le esecuzioni di workflow secondarie che hanno superato il limite della cronologia degli eventi vengono conteggiate ai fini della soglia di errore tollerata e considerate non riuscite. Per ulteriori informazioni su redrive idoneità di un'esecuzione, vedereRedrive idoneità per esecuzioni non riuscite.
Viene avviata una nuova Map Run e non la Map Run esistente redriven nei seguenti casi, anche se il Map Run non è riuscito nel tentativo di esecuzione originale:
-
Map Run non è riuscito a causa dell'
States.DataLimitExceeded
errore. -
Map Run non è riuscito a causa dell'errore di interpolazione JSON dei dati,.
States.Runtime
Ad esempio, è stato selezionato un nodo inesistente JSON in. Filtraggio dell'output dello stato utilizzando i flussi di OutputPath lavoro di Step Functions
Una Map Run può continuare a funzionare anche dopo l'arresto o il timeout del flusso di lavoro principale. In questi scenari, redrive non avviene immediatamente:
-
Map Run potrebbe ancora annullare le esecuzioni di workflow secondari in corso di tipo Standard o attendere che le esecuzioni di workflow secondarie di tipo Express completino le proprie esecuzioni.
-
Map Run potrebbe ancora scrivere risultati suResultWriter (Mappa), se l'hai configurato per esportare i risultati.
In questi casi, Map Run in esecuzione completa le sue operazioni prima di tentare di redrive.
Esecuzione del workflow secondario redrive comportamento
Il redriven le esecuzioni di workflow secondarie in un Map Run presentano il comportamento descritto nella tabella seguente.
Flusso di lavoro secondario Express | Flusso di lavoro standard per bambini |
---|---|
Tutte le esecuzioni di workflow secondarie che non sono riuscite o sono scadute nel tentativo di esecuzione originale vengono avviate utilizzando l'azione StartExecutionAPI. Il primo stato in ingresso ItemProcessor viene eseguito per primo. | Tutte le esecuzioni secondarie del flusso di lavoro che non sono riuscite, sono scadute o sono state annullate nel tentativo di esecuzione originale sono redriven utilizzando il RedriveExecutionAPIazione. Questi flussi di lavoro per bambini sono redriven dall'ultimo stato ItemProcessor che ha portato alla loro esecuzione non riuscita. |
Le esecuzioni non riuscite possono sempre essere redriven. Questo perché le esecuzioni del flusso di lavoro secondario di Express vengono sempre avviate come una nuova esecuzione utilizzando l' StartExecution APIazione. |
Le esecuzioni dei flussi di lavoro secondari standard non hanno sempre esito positivo redriven. Se un'esecuzione non lo è redrivable, non verrà tentato di nuovo. L'ultimo errore o output dell'esecuzione è permanente. Ciò è possibile quando un'esecuzione supera i 25.000 eventi della cronologia o redrivable il periodo di 14 giorni è scaduto. L'esecuzione di un workflow secondario standard potrebbe non essere redrivable se l'esecuzione del flusso di lavoro principale si è conclusa entro 14 giorni, ma l'esecuzione del flusso di lavoro secondario si è conclusa prima di 14 giorni. |
Le esecuzioni rapide dei flussi di lavoro secondari utilizzano la ARN stessa esecuzione del tentativo di esecuzione originale, ma non è possibile identificarne distintamente i singoli casi redrives. | Le esecuzioni di workflow secondarie standard utilizzano la stessa esecuzione del tentativo di esecuzione ARN originale. È possibile identificare distintamente l'individuo redrives nella console e in usoAPIs, ad esempio e. GetExecutionHistoryDescribeExecution Per ulteriori informazioni, consulta Esaminando redriven esecuzioni. |
Se hai redriven un Map Run, e ha raggiunto il limite di concorrenza, le esecuzioni del flusso di lavoro secondario in quel Map Run passano allo stato in sospeso. Anche lo stato di esecuzione di Map Run passa allo stato In sospeso redrivestato. Fino a quando il limite di concorrenza specificato non consente l'esecuzione di più esecuzioni di workflow secondari, l'esecuzione rimane in sospeso redrivestato.
Ad esempio, supponiamo che il limite di concorrenza della Mappa Distribuita nel flusso di lavoro sia 3000 e che il numero di flussi di lavoro secondari da eseguire nuovamente sia 6000. Ciò fa sì che 3000 flussi di lavoro secondari vengano eseguiti in parallelo mentre i restanti 3000 flussi di lavoro rimangano nello stato di redrive in sospeso. Una volta completata l'esecuzione del primo batch di 3000 flussi di lavoro secondari, vengono eseguiti i restanti 3000 flussi di lavoro secondari.
Quando una Map Run ha completato la sua esecuzione o viene interrotta, il numero di esecuzioni di workflow secondarie è in sospeso redrivelo stato viene ripristinato a 0.
Scenari di input utilizzati su Map Run redrive
A seconda di come hai fornito l'input alla Mappa Distribuita nel tentativo di esecuzione originale, a redriven Map Run utilizzerà l'input come descritto nella tabella seguente.
Inserimento nel tentativo di esecuzione originale | Input utilizzato su Map Run redrive |
---|---|
Input passato da uno stato precedente o dall'input di esecuzione. | Il redriven Map Run utilizza lo stesso input. |
L'input è passato utilizzando ItemReader (Mappa) e Map Run non ha avviato le esecuzioni dei flussi di lavoro secondari perché è vera una delle seguenti condizioni:
|
Il redriven Map Run utilizza l'input nel bucket Amazon S3. |
Input passato utilizzando. ItemReader Map Run non è riuscito dopo l'avvio o il tentativo di avviare esecuzioni secondarie di workflow. | Il redriven Map Run utilizza lo stesso input fornito nel tentativo di esecuzione originale. |
IAMautorizzazione a redrive a) Map Run
Step Functions necessita dell'autorizzazione appropriata per redrive a) Map Run. Il seguente esempio di IAM politica concede il minimo privilegio richiesto alla macchina a stati per redriving a Map Run. Ricordati di sostituire il italicized
testo con le informazioni specifiche della risorsa.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "states:RedriveExecution" ], "Resource": "arn:aws:states:us-east-2:
123456789012
:execution:myStateMachine
/myMapRunLabel
:*" } ] }
Redriving Map Run nella console
L'immagine seguente mostra il grafico di esecuzione di una macchina a stati che contiene una mappa distribuita. Questa esecuzione non è riuscita perché l'esecuzione della mappa non è riuscita. Per redrive il Map Run, devi redrive il flusso di lavoro principale.
Per redrive un Map Run dalla console
-
Apri la console Step Functions
, quindi scegli una macchina a stati esistente che contenga una mappa distribuita la cui esecuzione non è riuscita. -
Nella pagina dei dettagli della macchina a stati, in Esecuzioni, scegli un'istanza di esecuzione non riuscita di questa macchina a stati.
-
Scegliere Redrive.
-
Nella Redrivenella finestra di dialogo, scegliete Redrive esecuzione.
Suggerimento
Puoi anche redrive una Map Run dalla pagina Execution Details o Map Run Details.
Se ti trovi nella pagina Dettagli di esecuzione, esegui una delle seguenti operazioni per redrive l'esecuzione:
-
Scegli Recupera, quindi seleziona Redrive dal fallimento.
-
Scegli Azioni, quindi seleziona Redrive.
Se ti trovi nella pagina Dettagli di Map Run, scegli Recupera, quindi seleziona Redrive dal fallimento.
Notate che redrive utilizza la stessa definizione di macchina a stati eARN. Continua a eseguire l'esecuzione dal passaggio che non è riuscito nel tentativo di esecuzione originale. In questo esempio, si tratta del passaggio Distributed Map denominato Map e del passaggio di input Process al suo interno. Dopo aver riavviato le esecuzioni non riuscite del flusso di lavoro secondario di Map Run, redrive continuerà l'esecuzione per la fase Fine.
-
-
Dalla pagina Dettagli di esecuzione, scegli Map Run per visualizzare i dettagli di redriven Map Run.
In questa pagina, puoi visualizzare i risultati del redriven esecuzione. Ad esempio, nella Riepilogo dell'esecuzione di Map Run sezione, puoi vedere Redrive count, che rappresenta il numero di volte in cui è stata eseguita la Map Run redriven. Nella sezione Eventi, puoi vedere redrive eventi di esecuzione correlati aggiunti agli eventi del tentativo di esecuzione originale. Ad esempio, l'
MapRunRedriven
evento.
Dopo aver redriven un Map Run, puoi esaminarlo redrive dettagli nella console o utilizzando le DescribeExecutionAPIazioni GetExecutionHistoryand. Per ulteriori informazioni sull'esame di un redriven esecuzione, vedereEsaminando redriven esecuzioni.
Redriving Map Run usando API
Puoi redrive un Map Run idoneo utilizzando il RedriveExecutionAPIsul flusso di lavoro principale. Ciò API riavvia le esecuzioni di workflow secondarie non riuscite in un Map Run.
Nel AWS Command Line Interface
(AWS CLI), esegui il seguente comando per redrive un'esecuzione non riuscita di una macchina a stati. Ricordati di sostituire il italicized
testo con le informazioni specifiche della risorsa.
aws stepfunctions redrive-execution --execution-arn arn:aws:states:us-east-2:
123456789012
:execution:myStateMachine
:foo
Dopo aver redriven un Map Run, puoi esaminarlo redrive dettagli nella console o utilizzando l'DescribeMapRunAPIazione. Per esaminare il redrive dettagli sulle esecuzioni dei flussi di lavoro standard in una Map Run, è possibile utilizzare l'DescribeExecutionAPIazione GetExecutionHistoryo. Per ulteriori informazioni sull'esame di un redriven esecuzione, vedereEsaminando redriven esecuzioni.
È possibile esaminare il redrive dettagli sulle esecuzioni del flusso di lavoro Express in un Map Run sulla console Step Functions