Inscrições para apps e escalonamento de app

Os aplicativos podem se inscrever em vários produtores de eventos, mas somente um aplicativo pode receber eventos de cada assinatura. Observe que as assinaturas podem afetar como um aplicativo é escalado. Por exemplo, se você espera que seu aplicativo receba muitos eventos ao mesmo tempo e que o processamento de cada evento leve vários minutos, talvez seja necessário um valor de escala máximo mais alto do que se cada evento puder ser processado rapidamente. Para obter mais informações, consulte Configurando o ajuste de escala do aplicativo.

Todos os eventos que são entregues aos aplicativos são recebidos como mensagens de HTTP. Os eventos contêm certos cabeçalhos de HTTP que o ajudam a determinar rapidamente os bits de chave de informações sobre os eventos sem olhar para o corpo (lógica de negócios) do evento. Para obter mais informações, consulte o Exemplo HTTP headers para um evento IBM Cloud Object Storage enviado a um aplicativo.

Inscrições para empregos e limitações de execução de tarefas

As assinaturas podem afetar o número de trabalhos iniciados. Por exemplo, se o seu job inscreve para excluir alterações em um balde Object Storage e esse balde for excluído, um job será executado para cada objeto que estava naquele balde e você pode atingir rapidamente a sua limitação de 100 execuções de tarefas. Adicionalmente, é necessário considerar o tempo de execução para cada execução de tarefa que é acionada por um evento. Por exemplo, se o seu produtor de eventos aciona 10 ou mais eventos por segundo e cada job percorre por cerca de 20 seconds minutos, seu limite de execução de tarefas de 100 é alcançado em cerca de 10 seconds e qualquer execução de tarefa subsequente será perdida até que as execuções de tarefas previamente iniciadas sejam concluídas. Escolha um trabalho como destino de assinante de eventos somente se o número de eventos recebidos for geralmente baixo e o número máximo de eventos esperados em um período específico for baixo o suficiente para manter o número de trabalhos em execução abaixo do limite da cota. Para obter mais informações, consulte Limites e cotas para o Code Engine.

Após 10 minutes, execuções de tarefas que são criadas por assinaturas são excluídas. Para mais informações, consulte Onde está o meu trabalho executado?.

Todos os eventos que são entregues aos trabalhos são recebidos como variáveis de ambiente. Para obter mais informações, consulte Exemplo de ambiente de variáveis para um evento IBM Cloud Object Storage que é enviado para um trabalho.

Metadados de eventos

Os eventos gerenciados por Code Engine quando você cria uma assinatura são modificados para que sigam o padrão CloudEvents especificação. Essa especificação define um conjunto de atributos comuns que podem ser incluídos com cada evento para fornecer um conjunto comum de metadados. Ao observar os metadados, será possível entender rapidamente as partes principais da mensagem sem analisar e entender a totalidade da carga útil do evento. Por exemplo, cada evento que é entregue a um aplicativo inclui um cabeçalho HTTP chamado ce-type, que indica o significado semântico (ou "motivo") do evento. Um evento de um banco de dados pode incluir um valor de ce-type de com.example.row.deleted, indicando que o evento foi gerado porque uma linha foi excluída no banco de dados.

A tabela a seguir lista alguns dos principais atributos comuns. Cada atributo indica se é um atributo obrigatório no evento de entrada ou se ele é opcional.

Para obter mais informações sobre a lista completa de atributos, consulte a especificação CloudEvents.

Em Code Engine, quando os eventos são entregues para aplicativos, os atributos CloudEvent aparecem como cabeçalhos de HTTP, prefixados com ce-. Quando os eventos são entregues a tarefas em lote, os atributos aparecem como variáveis de ambiente, prefixados com CE_ e todo o nome da variável fica em maiúsculas.

ce-id: 3fb2c04e-a660-4640-8899-b82efb8169b6
ce-source: https://cloud.ibm.com/catalog/services/cloud-object-storage/mybucket
ce-specversion: 1.0
ce-subject: object-69-144
ce-time: 2021-08-17T20:22:02.917Z
ce-type: com.ibm.cloud.cos.document.delete

CE_DATA={"bucket":"mybucket","endpoint":"","key":"Notes.rtf","notification":{"bucket_name":"mybucket","content_type":"text/rtf","event_type":"Object:Delete","format":"2.0","object_length":"4642","object_name":"Notes.rtf","request_id":"b59727ee-9c4e-446a-9261-5616f6d1283b","request_time":"2021-04-13T20:10:37.631Z"},"operation":"Object:Delete"}  
CE_ID=b59727ee-9c4e-446a-9261-5616f6d1283b  
CE_SOURCE=https://cloud.ibm.com/catalog/services/cloud-object-storage/mybucket  
CE_SPECVERSION=1.0  
CE_TIME=2021-08-17T20:22:02.917Z  
CE_TYPE=com.ibm.cloud.cos.document.delete  

O que acontece quando uma assinatura é criada?

Por padrão, o subscription cron create, subscription cos create e os comandos subscription kafka create primeiro verificam se o aplicativo de destino ou job existe. Se a verificação de destino falhar porque o aplicativo ou tarefa não existe em seu projeto, os comandos para a criação de assinatura retornam um erro. Para criar uma assinatura sem primeiro criar o aplicativo, use a opção --force. Ao usar a opção --force, o comando ignora a verificação de destino. Observe que o campo Ready da assinatura mostra false até que o aplicativo de destino ou a tarefa seja criada. Em seguida, a assinatura muda para um estado Ready: true automaticamente.

Depois que a assinatura é criada, ela é repetidamente pesquisada quanto ao status para verificar a sua prontidão. Essa pesquisa dura 15 segundos por padrão antes de atingir tempo limite. É possível mudar o período de tempo antes de o comando atingir o tempo limite usando a opção --wait-timeout. Também é possível ignorar a pesquisa de status, configurando a opção --no-wait para false.

Você pode exibir o status de sua assinatura usando o subscription cron get, subscription cos get ou os comandos CLI subscription kafka get.