Thanks for your feedback!
EDIT
Policies
As políticas (policies) são uma ferramenta para gerenciar dois aspectos do processo de recebimento e distribuição de eventos:
-
a implementação de validações de segurança na autorização de publicadores que enviam eventos para o Events Hub;
-
as configurações de entrega, referentes às tentativas automáticas de envio de eventos aos subscritores caso o primeiro envio falhe.
As políticas são criadas na tela Policies e são aplicadas a handlers no processo de criação ou edição de um handler. Só é possível aplicar uma política por handler, mas a mesma política pode ser usada por múltiplos handlers.
|
É possível criar um handler e não aplicar uma política a ele? Sim, você pode criar um handler sem política aplicada e os tópicos poderão ser usados normalmente como canal de envio de eventos por publicadores. Nesse caso, além de não incluir interceptores de segurança no fluxo das requisições vindas dos publicadores, o Events Hub não fará tentativas automáticas de envio caso a primeira entrega de evento a um subscritor falhe. |
Listagem de políticas
A tela Policies exibe todas as políticas já criadas, listadas em ordem alfabética:
É possível pesquisar políticas pelo nome através do campo Name.
A lista de políticas exibe o nome e descrição (se houver) de cada política.
A coluna DETAILS contém o ícone 
, que exibe as configurações da política selecionada:
A coluna ACTIONS contém ícones para editar (
) e excluir (
) políticas.
Criando uma política
Para criar uma nova política, clique no botão flutuante +, que levará a uma tela única de configuração:
Os dados básicos a serem informados são nome (campo Name, obrigatório) e descrição (campo Description, opcional). O nome deve ser único; ou seja, não é possível criar duas políticas com o mesmo nome. As outras duas seções dizem respeito às configurações de segurança e entrega de eventos.
Segurança
A seção HANDLER PUBLISHER SECURITY FLOW inclui os interceptores de segurança que podem ser adicionados ao fluxo. Pelo menos uma das opções deve ser selecionada, mas é possível adicionar mais de um interceptor.
| Veja nosso tutorial sobre como utilizar a Sensedia API Platform para prover autorização para publicadores e mais detalhes sobre os diferentes fluxos de validação de client ID/access token. |
Para incluir um interceptor, clique no ícone 
ao lado de seu nome, o que abrirá uma tela de configuração.
Estas são as opções:
-
Access Token Validation: valida um access token passado na requisição. A configuração contém os seguintes campos:
-
Location, para selecionar onde o access token será passado, com as opções: any (qualquer uma das opções, então todas serão checadas); cookie; header; header ou cookie; ou query param.
-
Name, para informar o nome com o qual o valor do access token será passado.
-
-
Client ID Validation: valida um client ID passado na requisição. A configuração contém os seguintes campos:
-
Location, para selecionar onde o client ID será passado, com as opções: any (qualquer uma das opções, então todas serão checadas); cookie; header; header ou cookie; ou query param.
-
Name, para informar o nome com o qual o valor do client ID será passado.
-
-
IP Filtering Validation: inclui uma lista de IPs como base para a permissão de envio de requisições, com a possibilidade de Block List (lista de IPs que terão suas requisições bloqueadas) ou Allow List (lista dos únicos IPs que poderão enviar requisições). A configuração contém os seguintes campos:
-
List Type, para selecionar o tipo da lista, se Block List ou Allow List.
-
IP List, para incluir os IPs, que devem ser separados por vírgula.
-
-
OAuth Validation: valida
client_ideaccess_token_passados no header das requisições. A URL que provê validação deve ser incluída na página Authorizations e não há campos para cadastro.
-
JWT Validation: valida token JWT (que deve ser enviado no padrão Bearer) passado na requisição. A URL que provê validação deve ser incluída na página Authorizations. A configuração contém os seguintes campos:
-
Location, para selecionar onde o token será passado, com as opções: header; default JWT header (header JWT padrão); ou query param.
-
Name, para informar o nome com o qual o valor do token será passado.
-
| Após as publicações serem recebidas pelo Events Hub, o publisher é exibido na listagem de eventos da tela Event Status. Mas, para que essa identificação ocorra, é necessário que exista um interceptor que valide client ID como parte da política aplicada ao handler (seja OAuth Validation ou Client ID Validation). |
Após incluídos os interceptores, eles serão listados na sub-seção Execution Flow:
É possível editar, apagar e reordenar os itens:
-
O ícone
é usado para editar as configurações de cada interceptor. -
O ícone
é usado para remover o interceptor do fluxo. -
É possível reordenar os interceptors clicando sobre cada um e arrastando. Cada item será executado na ordem exibida na tela e, caso a validação de um deles falhe, a requisição será abortada durante a execução.
Configurações de entrega
A seção Delivery Settings configura a distribuição de eventos para subscritores (veja mais sobre o funcionamento das tentativas automáticas abaixo).
Estes são os campos para configuração, todos obrigatórios:
-
Automatic Retry Quantity: campo para definir a quantidade de tentativas automáticas que serão realizadas caso o primeiro envio falhe. É possível configurar até 10 tentativas automáticas.
-
Requisition Timeout: tempo limite de espera pelo retorno da URL do subscritor a cada tentativa de entrega.
-
Status Code For Automatic Retry: códigos de estado HTTP de retorno que devem disparar uma tentativa automática. Múltiplos códigos devem ser separados por vírgula e, para declarar a família, usamos "xx". Ex.:
400, 5xx(o último contendo todos os códigos de status da familia 500).
Edição e exclusão de políticas
Todas as configurações de uma política podem ser editadas por meio do ícone na coluna ACTIONS da tela Policies.
Na mesma coluna está o ícone para exclusão de políticas ().
Note que não será possível excluir políticas que estejam em uso em um handler.
Funcionamento das tentativas automáticas de envio
Caso a primeira tentativa de entrega do evento a um subscritor falhe, o Events Hub tentará o envio novamente, repetindo a requisição até que a entrega seja bem sucedida ou que o número de tentativas automáticas cadastrado no campo Automatic Retry Quantity (descrito acima) seja atingido.
Para aumentar as chances de sucesso no envio, aplicamos o algoritmo exponential backoff (ou recuo exponencial) para disparar as tentativas sucessivas. Esse algoritmo aumenta progressivamente o tempo de atraso entre as tentativas até um limite de atraso ser atingido (no nosso caso, 10 segundos). Dessa forma, é possível evitar falhas por causa de muitas tentativas subsequentes em um contexto de tráfego de rede congestionado.
Se todas as tentativas automáticas falharem, será possível tentar envio manual na tela Delivery Retry.