As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Use etapas personalizadas de processamento de arquivos
Ao usar uma etapa personalizada de processamento de arquivos, você pode trazer sua própria lógica de processamento de arquivos usando AWS Lambda. Na chegada do arquivo, um servidor Transfer Family invoca uma função do Lambda que contém uma lógica de processamento de arquivos personalizada, como criptografia de arquivos, verificação de malware ou verificação de tipos de arquivo incorretos. No exemplo a seguir, a função de destino AWS Lambda é usada para processar o arquivo de saída da etapa anterior.
nota
Para obter um exemplo de função do Lambda, consulte Exemplo de função do Lambda para uma etapa de fluxo de trabalho personalizada. Para eventos de exemplo (incluindo a localização dos arquivos passados para o Lambda), consulte Exemplos de eventos enviados para AWS Lambda após o upload do arquivo.
Com uma etapa de fluxo de trabalho personalizada, você deve configurar a função Lambda para chamar a operação da SendWorkflowStepStateAPI. SendWorkflowStepStatenotifica a execução do fluxo de trabalho de que a etapa foi concluída com status de sucesso ou falha. O status da operação da API SendWorkflowStepState invoca uma etapa do manipulador de exceções ou uma etapa nominal na sequência linear, com base no resultado da função do Lambda.
Se a função Lambda falhar ou atingir o tempo limite, a etapa falhará e você verá StepErrored nos seus CloudWatch registros. Se a função do Lambda fizer parte da etapa nominal e a função responder SendWorkflowStepState com Status="FAILURE" ou expirar, o fluxo continuará com as etapas do manipulador de exceções. Nesse caso, o fluxo de trabalho não continua executando as etapas nominais restantes (se houver). Consulte mais detalhes em Tratamento de exceções para um fluxo de trabalho.
Ao chamar a operação da API SendWorkflowStepState, você deve enviar os seguintes parâmetros:
{ "ExecutionId": "string", "Status": "string", "Token": "string", "WorkflowId": "string" }
Você pode extrair ExecutionId, Token, e WorkflowId do evento de entrada que é passado quando a função do Lambda é executada (exemplos são mostrados nas seções a seguir). O valor de Status pode ser SUCCESS ou FAILURE.
Para poder chamar a operação da SendWorkflowStepState API a partir da sua função Lambda, você deve usar uma versão do AWS SDK que foi publicada após a introdução dos fluxos de trabalho gerenciados.
Usando várias funções do Lambda consecutivamente
Quando você usa várias etapas personalizadas uma após a outra, a opção Local do arquivo funciona de forma diferente do que se você usasse apenas uma única etapa personalizada. O Transfer Family não suporta a devolução do arquivo processado pelo Lambda para ser usado como entrada na próxima etapa. Portanto, se você tiver várias etapas personalizadas configuradas para usar a opção previous.file, todas usarão o mesmo local de arquivo (o local do arquivo de entrada da primeira etapa personalizada).
nota
A configuração previous.file também funciona de forma diferente se você tiver uma etapa predefinida (marcar, copiar, descriptografar ou excluir) após uma etapa personalizada. Se a etapa predefinida estiver configurada para usar a configuração previous.file, a etapa predefinida usará o mesmo arquivo de entrada usado pela etapa personalizada. O arquivo processado da etapa personalizada não é passado para a etapa predefinida.
Acessar um arquivo após o processamento personalizado
Se você estiver usando o Amazon S3 como armazenamento e se seu fluxo de trabalho incluir uma etapa personalizada que executa ações no arquivo originalmente carregado, as etapas subsequentes não poderão acessar esse arquivo processado. Ou seja, qualquer etapa após a etapa personalizada não pode referenciar o arquivo atualizado a partir da saída da etapa personalizada.
Por exemplo, digamos que você tenha as três etapas a seguir no fluxo de trabalho.
-
Etapa 1 — Faça o upload de um arquivo chamado
example-file.txt. -
Etapa 2 — Invoque uma função do Lambda que muda o
example-file.txtde alguma forma. -
Etapa 3 — Tente realizar um processamento adicional na versão atualizada do
example-file.txt.
Se você configurar o sourceFileLocation da Etapa 3 para ser ${original.file}, a Etapa 3 usará o local do arquivo original de quando o servidor carregou o arquivo para o armazenamento na Etapa 1. Se você estiver usando o ${previous.file} na Etapa 3, a Etapa 3 reutiliza o local do arquivo que a Etapa 2 usou como entrada.
Portanto, a Etapa 3 causa um erro. Por exemplo, se a Etapa 3 tentar copiar o example-file.txt atualizado, você receberá o seguinte erro:
{ "type": "StepErrored", "details": { "errorType": "NOT_FOUND", "errorMessage": "ETag constraint not met (Service: null; Status Code: 412; Error Code: null; Request ID: null; S3 Extended Request ID: null; Proxy: null)", "stepType": "COPY", "stepName": "CopyFile" },
Esse erro ocorre porque a etapa personalizada modifica a tag da entidade (ETag) para example-file.txt que ela não corresponda ao arquivo original.
nota
Esse comportamento não ocorre se você estiver usando o Amazon EFS porque o Amazon EFS não usa tags de entidade para identificar arquivos.
Exemplos de eventos enviados para AWS Lambda após o upload do arquivo
Os exemplos a seguir mostram os eventos que são enviados AWS Lambda quando o upload de um arquivo é concluído. Um exemplo usa um servidor Transfer Family em que o domínio é configurado com o Amazon S3. O outro exemplo usa um servidor Transfer Family em que o domínio usa o Amazon EFS.
Exemplo de função do Lambda para uma etapa de fluxo de trabalho personalizada
A função Lambda a seguir extrai as informações sobre o status de execução e, em seguida, chama a operação da SendWorkflowStepStateAPI para retornar o status ao fluxo de trabalho da etapa: ou. SUCCESS FAILURE Antes de sua função chamar a operação da API SendWorkflowStepState, você pode configurar o Lambda para realizar uma ação com base na lógica do seu fluxo de trabalho.
import json import boto3 transfer = boto3.client('transfer') def lambda_handler(event, context): print(json.dumps(event)) # call the SendWorkflowStepState API to notify the workflow about the step's SUCCESS or FAILURE status response = transfer.send_workflow_step_state( WorkflowId=event['serviceMetadata']['executionDetails']['workflowId'], ExecutionId=event['serviceMetadata']['executionDetails']['executionId'], Token=event['token'], Status='SUCCESS|FAILURE' ) print(json.dumps(response)) return { 'statusCode': 200, 'body': json.dumps(response) }
Permissões do IAM para a etapa de personalizar
Para permitir que uma etapa que chama o Lambda seja bem-sucedida, certifique-se de que a função de execução do seu fluxo de trabalho contenha as seguintes permissões.
{ "Sid": "Custom", "Effect": "Allow", "Action": [ "lambda:InvokeFunction" ], "Resource": [ "arn:aws:lambda:region:account-id:function:function-name" ] }