Introdução
O produtor envia um evento de pedido completo, mas o consumidor precisa apenas do ID do pedido e da quantidade. Você transformará dois eventos em mensagens compactas de fila, preservando o filtro de roteamento.
Conclua primeiro Encaminhe Eventos de Pedidos com EventBridge. Construa este fluxo em sua VM independente; nenhum barramento, regra ou fila anterior é reutilizado.
Relação com as certificações
Este laboratório oferece prática nos seguintes tópicos de exame.
- Solutions Architect – Associate (SAA-C03) · Tarefa 2.1: Transformação de entrada EventBridge para payloads de consumidores.
- Developer – Associate (DVA-C02) · Tarefa 1.1: Transformação de entrada EventBridge para payloads de consumidores.
- CloudOps Engineer – Associate (SOA-C03) · Tarefa 1.2: Transformação de entrada EventBridge para payloads de consumidores.
- DevOps Engineer – Professional (DOP-C02) · Tarefa 4.3: Prática dos fundamentos: Transformação de entrada EventBridge para payloads de consumidores.
- Data Engineer – Associate (DEA-C01) · Tarefa 1.2: Prática dos fundamentos: Transformação de entrada EventBridge para payloads de consumidores.
Prepare Recursos de Roteamento Independentes
Nesta etapa, crie um barramento personalizado e uma fila vazia para tarefas de atendimento de pedidos.
Use AWS View ao lado do Terminal para comparar as consultas da CLI com os recursos e resultados reais deste laboratório. Preserve os dados de referência fornecidos.
O evento do produtor contém metadados de roteamento, informações do cliente e um pedido aninhado. O consumidor da fila precisa apenas do ID do pedido e da quantidade. A transformação de entrada escolhe campos do evento e constrói o corpo no destino, reduzindo a dependência do consumidor em relação ao envelope do produtor.
Este novo ambiente de trabalho contém acesso configurado à CLI e dados de referência não relacionados. Ele não reutiliza recursos de EV01. Comece no diretório do projeto. Atribuições no shell salvam identificadores retornados; --query seleciona um campo da resposta e --output text torna esse campo reutilizável no próximo comando.
cd /home/labex/project
BUS_NAME=labex-ev02-bus
RULE_NAME=labex-ev02-orders
aws events create-event-bus --name "$BUS_NAME"
QUEUE_URL=$(aws sqs create-queue \
--queue-name labex-ev02-jobs \
--query QueueUrl \
--output text)
QUEUE_ARN=$(aws sqs get-queue-attributes \
--queue-url "$QUEUE_URL" \
--attribute-names QueueArn \
--query Attributes.QueueArn \
--output text)
O ARN do barramento identifica o destino do evento; a URL da fila é usada para operações de mensagens, enquanto seu ARN identifica um destino de regra. Confirme o estado inicial:
aws events list-rules --event-bus-name "$BUS_NAME"
aws sqs get-queue-attributes \
--queue-url "$QUEUE_URL" \
--attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible
Não há regras ou mensagens. Clique em AWS View ao lado do Terminal para inspecionar o mesmo barramento personalizado e a fila vazia. Execute a verificação da preparação.
Conecte um Destino com um Transformador de Entrada
Nesta etapa, identifique pedidos feitos correspondentes, autorize a regra e defina o conteúdo compacto para o consumidor.
Selecione os campos aninhados do pedido e construa o corpo id/quantity do consumidor; mantenha o filtro de roteamento.
O padrão de uma regra identifica correspondências no produtor e na categoria do evento. Um here-document com marcador entre aspas grava JSON literal sem expansão pelo shell; file:// lê esse arquivo na solicitação da CLI.
cat > order-pattern.json <<'JSON'
{"source":["labex.orders"],"detail-type":["OrderPlaced"]}
JSON
RULE_ARN=$(aws events put-rule \
--name "$RULE_NAME" \
--event-bus-name "$BUS_NAME" \
--event-pattern file://order-pattern.json \
--state ENABLED \
--query RuleArn \
--output text)
A fila precisa de uma permissão exata para a regra de origem. Escreva uma política JSON comum usando os ARNs de sua fila e regra. Depois, --rawfile a codifica como o atributo Policy do SQS, cujo valor é uma string.
cat > queue-policy.json <<EOF
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "events.amazonaws.com"
},
"Action": "sqs:SendMessage",
"Resource": "$QUEUE_ARN",
"Condition": {
"ArnEquals": {
"aws:SourceArn": "$RULE_ARN"
}
}
}
]
}
EOF
jq -n --rawfile policy queue-policy.json '{Policy:$policy}' > queue-attributes.json
aws sqs set-queue-attributes \
--queue-url "$QUEUE_URL" \
--attributes file://queue-attributes.json
Um InputPathsMap nomeia campos selecionados por JSONPath. $ significa a raiz do evento; $.detail.order.id seleciona o ID aninhado do pedido. Um InputTemplate usa marcadores entre sinais de menor e maior para construir a mensagem. O marcador de ID fica dentro das aspas de uma string JSON; a quantidade é um número JSON e não tem aspas. O exemplo usa IDs simples e quantidades inteiras positivas.
cat > targets.json <<EOF
[
{
"Id": "order-queue",
"Arn": "$QUEUE_ARN",
"InputTransformer": {
"InputPathsMap": {
"id": "\$.detail.order.id",
"quantity": "\$.detail.order.quantity"
},
"InputTemplate": "{\"id\":\"<id>\",\"quantity\":<quantity>}"
}
}
]
EOF
aws events put-targets \
--rule "$RULE_NAME" \
--event-bus-name "$BUS_NAME" \
--targets file://targets.json
aws events list-targets-by-rule --rule "$RULE_NAME" --event-bus-name "$BUS_NAME"
FailedEntryCount é zero. O destino listado inclui o ARN de sua fila e os dois caminhos de mapeamento e o template. O sucesso da configuração ainda precisa de um teste real de entrega. AWS View mostra a regra habilitada e o transformador; a fila permanece vazia. Execute a verificação da conexão.
Compare Dois Conteúdos Reais para o Consumidor
Nesta etapa, publique dois pedidos feitos distintos e inspecione as mensagens resultantes na fila.
Escreva os detalhes dos eventos como objetos JSON comuns. PutEvents exige que cada Detail seja uma string codificada em JSON; o comando curto de jq abaixo converte apenas esse campo. Cada evento também contém informações sintéticas de cliente de que o consumidor de atendimento de pedidos não precisa. Um terceiro evento de cancelamento testa que o filtro de roteamento continua sendo aplicado.
cat > event-inputs.json <<EOF
[
{
"EventBusName": "$BUS_NAME",
"Source": "labex.orders",
"DetailType": "OrderPlaced",
"Detail": {
"order": {
"id": "transform-order-a",
"quantity": 2
},
"customer": {
"email": "synthetic-a@example.test"
}
}
},
{
"EventBusName": "$BUS_NAME",
"Source": "labex.orders",
"DetailType": "OrderPlaced",
"Detail": {
"order": {
"id": "transform-order-b",
"quantity": 4
},
"customer": {
"email": "synthetic-b@example.test"
}
}
},
{
"EventBusName": "$BUS_NAME",
"Source": "labex.orders",
"DetailType": "OrderCancelled",
"Detail": {
"order": {
"id": "cancelled-order",
"quantity": 9
}
}
}
]
EOF
jq 'map(.Detail |= tojson)' event-inputs.json > events.json
aws events put-events --entries file://events.json
aws sqs get-queue-attributes \
--queue-url "$QUEUE_URL" \
--attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible
Os três eventos são aceitos, mas apenas os dois pedidos feitos correspondem ao filtro. A fila tem duas mensagens disponíveis. Receber com visibilidade zero deixa as mensagens disponíveis imediatamente após a inspeção. A consulta exibe apenas IDs e corpos de mensagens, mantendo os identificadores de recebimento privados.
fromjson torna cada corpo JSON legível, mantendo seu ID de mensagem SQS. Ele altera apenas a saída exibida.
aws sqs receive-message \
--queue-url "$QUEUE_URL" \
--max-number-of-messages 10 \
--visibility-timeout 0 \
--output json | jq '[.Messages[] | {MessageId, Body: (.Body | fromjson)}]'
Os corpos são {"id":"transform-order-a","quantity":2} e {"id":"transform-order-b","quantity":4}; sua ordem não é avaliada. Eles têm IDs de mensagem distintos e valores derivados dos eventos correspondentes. Nenhum contém o email do cliente, metadados de roteamento ou um objeto order aninhado. O pedido cancelado está ausente. Isso comprova a transformação e a entrega, não o atendimento concluído ou a confirmação das mensagens.
AWS View mostra os mapeamentos do destino ao lado dos corpos compactos reais das mensagens na fila.
O exemplo abaixo mostra os dois mapeamentos de campos aninhados e as duas mensagens compactas reais para o consumidor.
Execute a verificação do conteúdo.
Remova o Fluxo Descartável
Nesta etapa, remova seus recursos de roteamento e preserve o estado não relacionado.
Remova o destino antes de sua regra e, depois, exclua o barramento personalizado e a fila. A fila contém apenas mensagens sintéticas de inspeção; excluí-la as descarta sem alegar processamento de negócio.
aws events remove-targets \
--rule "$RULE_NAME" \
--event-bus-name "$BUS_NAME" \
--ids order-queue
aws events delete-rule --name "$RULE_NAME" --event-bus-name "$BUS_NAME"
aws events delete-event-bus --name "$BUS_NAME"
aws sqs delete-queue --queue-url "$QUEUE_URL"
Consultas nativas de inventário bem-sucedidas comprovam a exclusão:
aws events list-event-buses
aws events list-rules --event-bus-name default
aws sqs list-queues
aws dynamodb scan --table-name labex-ev02-reference --query Items
Apenas o barramento padrão permanece, sem regras; as URLs de fila estão ausentes. O item de referência ainda diz keep unchanged. Erros de rede ou de autenticação não comprovam a exclusão. AWS View mostra os recursos personalizados vazios e a referência preservada.
Remova os arquivos comuns criados neste laboratório:
rm -f event-inputs.json order-pattern.json queue-policy.json queue-attributes.json targets.json events.json
Execute a verificação da limpeza antes de encerrar a VM.
Resumo
Você mapeou campos aninhados de pedidos para um contrato compacto de consumidor SQS, verificou valores distintos de dois eventos reais e manteve a filtragem de eventos e as permissões da regra de origem. Você removeu o fluxo descartável, preservando os dados de referência.
A próxima unidade conecta tarefas reais de negócio em um fluxo de pedidos.
