Abonnements pour les applications et mise à l'échelle des applications

Les applications peuvent s'abonner à plusieurs producteurs d'événements, mais une seule application peut recevoir des événements de chaque abonnement. Notez que les abonnements peuvent affecter la manière dont une application est mise à l'échelle. Par exemple, si vous prévoyez que votre application recevra de nombreux événements en même temps et que le traitement de chaque événement prend plusieurs minutes, vous aurez peut-être besoin d'une valeur d'échelle maximale plus élevée que si chaque événement peut être traité rapidement. Pour plus d'informations, voir Configuration de la mise à l'échelle d'application.

Tous les événements distribués aux applications sont reçus en tant que messages HTTP. Les événements contiennent des en-têtes HTTP qui vous aident à déterminer rapidement des informations clés sur les événements sans examiner le corps (logique métier) de l'événement. Pour plus d'informations, voir l'exemple HTTP- En-têtes d'un événement IBM Cloud Object Storage envoyé à une application.

Abonnements pour les travaux et limitations d'exécution de travail

Les abonnements peuvent influer sur le nombre de travaux lancés. Par exemple, si votre travail s'abonne pour supprimer des modifications sur un compartiment Object Storage et que ce compartiment est supprimé, un travail est exécuté pour chaque objet qui se trouvait dans ce compartiment et vous pouvez atteindre rapidement votre limite de 100 exécutions de travail. En outre, vous devez prendre en compte l'environnement d'exécution pour chaque exécution de travail déclenchée par un événement. Par exemple, si votre producteur d'événements déclenche 10 événements ou plus par seconde et que chaque travail s'exécute pendant environ 20 secondes, votre limite d'exécution de travail de 100 est atteinte en environ 10 secondes et toutes les exécutions de travail suivantes sont perdues jusqu'à ce que les exécutions de travail précédemment démarrées soient terminées. Ne choisissez un travail comme destination d'abonnement aux événements que si le nombre d'événements entrants est généralement faible et que le nombre maximal d'événements attendus dans un délai donné est suffisamment bas pour que le nombre de travaux en cours reste inférieur au quota. Pour plus d'informations, voir Limites et quotas pour Code Engine.

Au bout de 10 minutes, les exécutions de travail créées par des abonnements sont supprimées. Pour plus d'informations, voir Où est l'exécution de mon travail?.

Tous les événements transmis aux travaux sont reçus sous forme de variables d'environnement. Pour plus d'informations, voir Exemple de variables d'environnement pour un événement IBM Cloud Object Storage envoyé à un travail.

Métadonnées d'événements

Les événements gérés par Code Engine lors de la création d'un abonnement sont modifiés de manière à ce qu'ils respectent la norme Spécification CloudEvents. Cette spécification définit un ensemble d'attributs communs pouvant être inclus dans chaque événement pour fournir un ensemble commun de métadonnées. En examinant les métadonnées, vous pouvez rapidement comprendre les éléments clés du message sans avoir à analyser et comprendre l'intégralité du contenu de l'événement. Par exemple, chaque événement transmis à une application comprend un en-tête HTTP appelé ce-type, qui indique la signification sémantique (ou "raison") de l'événement. Un événement d'une base de données peut inclure une valeur ce-type de com.example.row.deleted, indiquant qu'il a été généré car une ligne a été supprimée dans la base de données.

Le tableau suivant répertorie certains attributs communs clés. Il indique pour chacun d'eux si l'attribut est obligatoire dans l'événement entrant ou s'il est facultatif.

Pour plus d'informations sur la liste complète des attributs, voir la spécification CloudEvents.

Lorsque des événements sont livrés à des applications dans Code Engine, les attributs CloudEvent apparaissent en tant qu'en-têtes HTTP avec le préfixe ce-. Lorsque des évènements sont livrés à des travaux par lots, les attributs apparaissent en tant que variables d'environnement, préfixés avec CE_ alors que l'ensemble du nom de la variable est en lettres majuscules.

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  

Que se passe-t-il lorsque je crée un abonnement ?

Par défaut, les commandes subscription cron create, subscription cos create et subscription kafka create vérifient d'abord si l'application ou le travail de destination existe. Si la vérification de destination échoue car l'application ou le travail n'existe pas dans votre projet, les commandes de l'abonnement créent une erreur en retour. Si vous voulez créer un abonnement sans créer d'abord l'application, utilisez l'option --force. Avec l'option --force, la commande ignore l'étape de vérification de la destination. Notez que le champ Ready de l'abonnement indique false jusqu'à ce que l'application ou le travail de destination soit créé. Ensuite, l'abonnement passe automatiquement à l'état Ready: true.

Une fois l'abonnement créé, celui-ci fait l'objet d'une interrogation répétée sur son état afin de vérifier qu'il est prêt. Cette interrogation dure par défaut 15 secondes avant d'arriver à expiration. Vous pouvez modifier le délai d'attente de la commande avant le dépassement de délai avec l'option --wait-timeout. Vous pouvez également ignorer l'étape d'interrogation de l'état en définissant l'option --no-wait sur false.

Vous pouvez afficher le statut de votre abonnement à l'aide des commandes de l'interface de ligne de commande subscription cron get, subscription cos get ou subscription kafka get.