IMPORTANTE: esta documentação foi descontinuada. Leia a documentação RabbitMQ Trigger atualizada no nosso novo portal de documentação.

O RabbitMQ Trigger é responsável pelo consumo das mensagens de um broker RabbitMQ.

Esse trigger possui 2 estratégias de acknowledge (confirmação de recebimento) de mensagens:

1. Acknowledge automático

A confirmação de cada mensagem recebida pelo trigger acontece de forma automática e imediata no recebimento e o broker entende que ela foi entregue. Por um lado, o acknowledge automático garante um grande desempenho, mas por outro não impede a perda da mensagem caso o pipeline associado não a processe ou a processe com falha.

2. Acknowledge manual

Cada mensagem recebida pelo trigger permanece em "unacked", um estado de não confirmação, enquanto estiverem sendo processadas pelo pipeline. No acknowledge manual, o broker RabbitMQ entende que a mensagem está pendente e, caso haja qualquer problema na infraestrutura do trigger ou o pipeline responda com erro, a mensagem em questão pode ser reprocessada. O número de API Keys configurados para o pipeline dita quantas mensagens podem ser processadas ao mesmo tempo. Para isso, o tamanho de prefetch do RabbitMQ é configurado com o mesmo valor de API Keys do pipeline.

Dê uma olhada nos parâmetros de configuração desse trigger:

Account: nome da conta que será utilizada (a conta deve ser do tipo basic)

Hostname: endereço do host do RabbitMQ

Port: porta onde o RabbitMQ está escutando

Virtual Host: configuração de host virtual que define o tenant do RabbitMQ que se deseja acessar

Auto Acknowledge: se “true”, a mensagem será confirmada assim que chegar ao trigger e não esperará um retorno do pipeline associado; se "false", a mensagem ficará pendente enquanto o pipeline a estiver processando

Binary Message: se "true", define que a mensagem recebida será binária e, portanto, seu conteúdo será apresentado como base64; se "false", a mensagem será apresentada como texto

Maximum Timeout: por quanto tempo um pipeline pode ser executado (em milissegundos)

Expiration: tempo máximo de espera da mensagem numa fila de pipeline

Allow Redelivery of Messages: se "true", uma execução de pipeline será re-executada em caso de erro; se "false", não haverá re-execução em caso de erro

IMPORTANTE: o cliente RabbitMQ não permite a limitação do tamanho de mensagens. Caso mensagens muito grandes sejam enviadas, a infraestrutura de triggers da Digibee poderá recusá-las. Não aconselhamos o envio de mensagens grandes através de um barramento de mensagens.

API Keys

A configuração de API Keys feita no momento de implantação de um pipeline impacta diretamente no throughput de recebimento e saída de mensagens quando o RabbitMQ Trigger é ativado. Caso o auto acknowledge esteja desabilitado, a preocupação com o número de API Keys se torna ainda mais importante. Isso acontece porque o número de mensagens simultâneas sendo processadas é igual ao número de API Keys configuradas.

Declaração de filas, routing keys e exchanges

O RabbitMQ Trigger não declara parâmetros de configuração de filas, routing keys e exchanges no broker RabbitMQ. É esperado que toda a configuração já esteja feita para que o trigger possa consumir mensagens de filas.

Formato de mensagem na entrada do pipeline

Pipelines associados com o RabbitMQ Trigger recebem a seguinte mensagem como entrada:

{
  "body": <STRING message content; if binary, then Base64>,
  "properties": {
    "appId": <STRING application id>,
    "classId": <STRING class id>,
    "clusterId": <STRING cluster id>,
    "contentEncoding": <STRING content encoding>,
    "contentType": <STRING message content type>,
    "correlationId": <STRING correlation id>,
    "deliveryMode": <INT delivery mode>,
    "expiration": <STRING message expiration in ms>,
    "messageId": <STRING message id>,
    "priority": <INT message priority>,
    "replyTo": <STRING reply to queue>,
    "type": <STRING message type>,
    "userId": <STRING user id>,
    "timestamp": <LONG message timestamp>
  }
  "headers": {
    "header1": "value1", ...
  },
  "envelope": {
    "deliveryTag": <LONG message delivery tag>
    "exchange": <STRING exchange that processed the message>
    "routingKey": <STRING routing key used to route message>
  }
}