O blog da AWS

Integrando o IBM MQ com o Amazon SQS e o Amazon SNS usando o Apache Camel

Por Joaquin Rinaudo, consultor principal de segurança e Gezim Musliaj, consultor de DevOps 

O IBM MQ é um produto de middleware orientado a mensagens (MOM) usado por muitas organizações, incluindo bancos globais, companhias aéreas, companhias de saúde e seguros.

Os clientes geralmente nos pedem orientação sobre como integrar seus sistemas MOM locais existentes com novos aplicativos executados na nuvem. Eles estão procurando uma solução econômica, escalável e de baixo esforço que permita enviar e receber mensagens de seus aplicativos em nuvem para esses sistemas de mensagens.

Esta postagem do blog mostra como configurar uma ponte bidirecional do IBM MQ local para o Amazon MQ, o Amazon Simple Queue Service (Amazon SQS) e o Amazon Simple Notification Service (Amazon SNS).

Isso permite que seus aplicativos de produtores e consumidores se integrem usando os serviços de mensagens totalmente gerenciados da AWS e o Apache Camel. Saiba como implantar essa solução e como testar a integração em execução usando SNS, SQS e um ambiente de cluster IBM MQ de demonstração executado no Amazon Elastic Container Service (ECS) com o AWS Fargate.

Essa solução também pode ser usada como parte de uma migração passo a passo usando a abordagem descrita na postagem do blog Migrando do IBM MQ para o Amazon MQ usando uma abordagem em fases.

Visão geral da solução

A integração consiste em um cluster de agentes Apache Camel que integra bidirecionalmente um sistema IBM MQ e sistemas de destino, como o Amazon MQ executando o ActiveMQ, tópicos do SNS ou filas SQS.

No exemplo a seguir, os serviços da AWS, neste caso AWS Lambda e SQS, recebem mensagens publicadas no IBM MQ por meio de um tópico do SNS:

Solution architecture overview for sending messages

  1. Os consumidores de mensagens na nuvem (Lambda e SQS) assinam o tópico de SNS alvo da solução.
  2. O agente Apache Camel se conecta ao IBM MQ usando segredos armazenados no AWS Secrets Manager e lê novas mensagens da fila usando a biblioteca Java do IBM MQ. Somente mensagens do IBM MQ são suportadas como fonte.
  3. O broker Apache Camel publica essas novas mensagens no tópico do SNS de destino. Ele usa a Amazon SNS Extended Client Library for Java para armazenar qualquer mensagem maior que 256 KB em um bucket do Amazon Simple Storage Service (Amazon S3).
  4. O Apache Camel armazena qualquer mensagem que não possa ser entregue ao SNS após duas novas tentativas em um bucket de fila de letras mortas do S3.

O diagrama a seguir demonstra como a solução envia mensagens de volta de uma fila SQS para o IBM MQ:

Solution architecture overview for sending messages

  1. Um exemplo de produtor de mensagens usando o Lambda envia mensagens para uma fila SQS. Ele usa a Amazon SQS Extended Client Library for Java para enviar mensagens maiores que 256 KB.
  2. O agente Apache Camel recebe as mensagens publicadas no SQS, usando a SQS Extended Client Library, se necessário.
  3. O agente Apache Camel envia a mensagem para a fila de destino do IBM MQ.
  4. Como antes, o broker armazena mensagens que não podem ser entregues ao IBM MQ no bucket da fila de letras mortas do S3.

Uma migração dinâmica em fases consiste em duas etapas:

  1. Implemente o serviço de agente para permitir a leitura e gravação de mensagens nas filas existentes do IBM MQ.
  2. Depois que o consumidor ou produtor for migrado, migre sua contraparte para o serviço recém-selecionado (SNS ou SQS).

Em seguida, você aprenderá a configurar a solução usando o AWS Cloud Development Kit (AWS CDK).

Implantando a solução

Pré-requisitos

  • AWS CDK
  • TypeScript
  • Java
  • Docker
  • Git
  • Yarn

Etapa 1: clonar o repositório

Clone o repositório usando o git:

git clone https://github.com/aws-samples/aws-ibm-mq-adapter
Bash

Etapa 2: Configurando as credenciais de teste do IBM MQ

Esta demonstração usa a autenticação TLS mútua do IBM MQ. Para fazer isso, você deve gerar certificados X.509 e armazená-los no AWS Secrets Manager executando os seguintes comandos na pasta do aplicativo:

  1. Gere certificados X.509:
    ./deploy.sh generate_secrets
    Bash
  2. Configure os segredos necessários para o broker Apache Camel (<integration-name>substitua por, por exemplo, dev):
    ./deploy.sh create_secrets broker <integration-name>
    Bash
  3. Configure segredos para o sistema IBM MQ simulado:
    ./deploy.sh create_secrets mock
    Bash
  4. Atualize o arquivo cdk.json com a saída Secrets ARN dos comandos anteriores:
    • IBM_MOCK_PUBLIC_CERT_ARN
    • IBM_MOCK_PRIVATE_CERT_ARN
    • IBM_MOCK_CLIENT_PUBLIC_CERT_ARN
    • IBMMQ_TRUSTSTORE_ARN
    • IBMMQ_TRUSTSTORE_PASSWORD_ARN
    • IBMMQ_KEYSTORE_ARN
    • IBMMQ_KEYSTORE_PASSWORD_ARN

Se você estiver usando seu próprio sistema IBM MQ e já tiver certificados X.509 disponíveis, poderá usar o script para carregar esses certificados no AWS Secrets Manager depois de executar o script.

Etapa 3: Configurando o broker

A solução implementa dois brokers, um para ler mensagens do sistema IBM MQ de teste e outro para enviar mensagens de volta. Um cluster Apache Camel separado é usado por integração para suportar um melhor uso da funcionalidade de Auto Scaling e evitar problemas em diferentes operações de integração (consumo e leitura de mensagens).

Atualize o arquivo cdk.json com os seguintes valores:

  • AccountID: ID da conta da AWS na qual implantar a solução.
  • Region: nome da região da AWS na qual implantar a solução.
  • DefaultVpcID: especifique uma ID de VPC para uma VPC existente na conta da AWS em que o broker e o mock estão implantados.
  • AllowedPrincipals: adicione o ARN da sua conta (por exemplo, arn:aws:iam: :123456789012:root) para permitir que essa conta da AWS envie e receba mensagens do broker. Você pode usar esse parâmetro para configurar relacionamentos entre contas para integrações de SQS e SNS e oferecer suporte a vários consumidores e produtores.

Etapa 4: inicializar e implantar a solução

  1. Certifique-se de ter as variáveis de ambiente AWS_PROFILE e AWS_REGION corretas definidas para sua conta de desenvolvimento.
  2. Execute yarn cdk bootstrap –-qualifier mq <aws://<account-id>/<region>
  3. Execute yarn install para instalar as dependências do CDK.
  4. Por fim, execute yarn cdk deploy '*-dev' —-qualifier mq --require-approval never para implantar a solução no ambiente de desenvolvimento.
  1. Make sure you have the correct AWS_PROFILE and AWS_REGION environment variables set for your development account.
  2. Run yarn cdk bootstrap –-qualifier mq <aws://<account-id>/<region> to bootstrap CDK.
  3. Run yarn install to install CDK dependencies.
  4. Finally, execute yarn cdk deploy '*-dev' –-qualifier mq --require-approval never to deploy the solution to the dev environment.

Etapa 5: Testando as integrações

Use o AWS System Manager Session Manager e o encaminhamento de portas para estabelecer túneis para a instância de teste do IBM MQ para acessar o console web e enviar mensagens manualmente. Para obter mais informações sobre encaminhamento de portas, consulte Encaminhamento de portas de instâncias do Amazon EC2 com o AWS System Manager.

  1. Em um terminal de linha de comando, verifique se você tem as variáveis de ambiente AWS_PROFILE e AWS_REGION corretas definidas para sua conta de desenvolvimento.
  2. Além disso, defina as seguintes variáveis de ambiente:
    • IBM_ENDPOINT: endpoint para IBM MQ. Exemplo: balanceador de carga de rede para IBM mock mqmoc-mqada-1234567890. elb.eu-west-1.amazonaws.com.
    • BASTION_ID: ID da instância para o host bastion. Você pode recuperar essa saída na Etapa 4: Inicializando e implantando a solução listada após a implantação do MQBastionStack.

Use o comando a seguir para definir as variáveis de ambiente:

export IBM_ENDPOINT=mqmoc-mqada-1234567890.elb.eu-west-1.amazonaws.com
export BASTION_ID=i-0a1b2c3d4e5f67890
Bash
3. Execute o script test/connect.sh.
4. Faça login no console web da IBM via https://127.0.0.1:9443/admin usando o usuário IBM padrão ( admin) e a senha armazenada no AWS Secrets Manager como MQAdapterIBMMockAdminPassword

Enviando dados do IBM MQ e recebendo-os no SNS:

  1. No console IBM MQ, acesse o gerenciador de filas local QM1 e DEV.QUEUE.1.
  2. Envie uma mensagem com o conteúdo Hello AWS. Essa mensagem será processada pelo AWS Fargate e publicada no SNS.
  3. Acesse o console SQS e escolha a fila de prefixo SNSIntegrationStack-dev-2. Essa é uma fila SQS inscrita no tópico do SNS para testes.
  4. Selecione Enviar e receber mensagem.
  5. Selecione Enquete de mensagens para ver a mensagem Hello AWS enviada anteriormente ao IBM MQ.

Enviando dados de volta do Amazon SQS para o IBM MQ:

  1. Acesse o console SQS e escolha a fila com o prefixo SQSPublishIntegrationStack-dev-3-dev.
  2. Selecione Enviar e receber mensagens.
  3. Em Corpo da mensagem, adicione Hello from AWS.
  4. Escolha Enviar mensagem.
  5. No console IBM MQ, acesse o gerenciador de filas local QM1 e DEV.QUEUE.2 para encontrar sua mensagem listada nessa fila.

Etapa 6: Limpando / Apagando os recursos

Execute cdk destroy ‘*-dev’ para destruir os recursos implantados como parte deste passo a passo.

Conclusão

Neste blog, você aprendeu como trocar mensagens entre o IBM MQ e seus aplicativos em nuvem usando o Amazon SQS e o Amazon SNS.

Se você estiver interessado em começar com sua própria integração, siga o arquivo README no repositório do GitHub. Se você estiver migrando aplicativos existentes usando APIs e protocolos padrão do setor, como JMS, NMS ou AMQP 1.0, considere a integração com o Amazon MQ usando as etapas fornecidas no repositório.

Se você estiver interessado em executar o Apache Camel no Kubernetes, você também pode adaptar a arquitetura para usar o Apache Camel K.

Link do blog original: https://aws.amazon.com/blogs/compute/integrating-ibm-mq-with-amazon-sqs-and-amazon-sns-using-apache-camel/

Para obter mais recursos de aprendizado Serverless, visite Serverless Land.

Este artigo foi traduzido do Blog da AWS em Inglês.

 


Sobre o autor

Joaquin Rinaudo é consultor principal de segurança

 

 

 

 

Gezim Musliaj é consultor de DevOps

 

 

 

 

Tradutor

Daniel Abib é Enterprise Solution Architect na AWS, com mais de 25 anos trabalhando com gerenciamento de projetos, arquiteturas de soluções escaláveis, desenvolvimento de sistemas e CI/CD, microsserviços, arquitetura Serverless & Containers e segurança. Ele trabalha apoiando clientes corporativos, ajudando-os em sua jornada para a nuvem.

https://www.linkedin.com/in/danielabib/