Cette page a été traduite par l'API Cloud Translation.

Propriétés d'abonnement

Les propriétés d'abonnement Pub/Sub sont les caractéristiques d'un abonnement. Vous pouvez définir des propriétés d'abonnement lorsque vous créez ou mettez à jour un abonnement.

Ce document décrit les différentes propriétés d'abonnement que vous pouvez définir pour un abonnement.

Avant de commencer

En savoir plus sur les abonnements
Comprenez le workflow de l'abonnement que vous allez créer : pull, push ou BigQuery.

Propriétés d'abonnement courantes

Lorsque vous créez un abonnement, vous devez spécifier un certain nombre d'options pour le configurer. Certaines de ces propriétés sont communes à tous les types d'abonnements et sont abordées dans les sections suivantes.

Durée de conservation des messages

L'option Durée de conservation des messages spécifie la durée pendant laquelle Pub/Sub conserve les messages après publication. Une fois la durée de conservation des messages écoulée, Pub/Sub peut supprimer le message, quel que soit son état de confirmation. Pour conserver les messages confirmés pendant la durée de conservation définie, consultez Rouvrir et supprimer des messages.

Voici les valeurs de l'option Durée de conservation des messages :

Valeur par défaut = 7 jours
Valeur minimale : 10 minutes
Valeur maximale = 31 jours

Les messages non confirmés peuvent être dus à des abonnements inactifs, à des besoins de sauvegarde ou à un traitement lent. Si vous êtes en mesure de traiter les messages dans les 24 heures, vous n'aurez pas à payer de frais supplémentaires. Pour éviter de nouveaux frais, gérez ces scénarios comme suit :

Abonnements inactifs. Supprimez les abonnements inactifs pour éviter les frais de conservation des messages d'abonnement.
Stockage des sauvegardes : Si vous utilisez la conservation des abonnements comme stockage de sauvegarde, vous pouvez passer à une autre option de stockage, comme la conservation des messages de sujet ou la conservation des messages confirmés. La conservation des messages par sujet stocke les messages une seule fois au niveau du sujet. Ils restent disponibles pour tous les abonnements et peuvent être utilisés en cas de besoin.
Retards de traitement : Ajoutez des abonnés (si possible) pour traiter les messages dans la journée.

Conserver les messages confirmés

Si vous spécifiez une durée de conservation des messages, vous pouvez également indiquer si vous souhaitez conserver les messages confirmés.

L'option Conserver les messages confirmés vous permet de conserver les messages confirmés pendant la durée de conservation des messages spécifiée. Cette option augmente les frais de stockage des messages. Pour en savoir plus, consultez Coûts de stockage.

Délai d'expiration

L'option Période d'expiration vous permet de prolonger la période d'expiration de votre abonnement.

Les abonnements sans activité de la part des abonnés ni modification des propriétés de l'abonnement expirent. Si Pub/Sub détecte une activité d'abonné ou si vous mettez à jour l'une des propriétés de l'abonnement, l'horloge de suppression d'abonnement redémarre. Voici quelques exemples d'activités d'abonné : connexions ouvertes, pulls actifs ou push réussis.

Si vous spécifiez la période d'expiration, la valeur doit être au moins aussi longue que la durée de conservation des messages spécifiée dans l'option Durée de conservation des messages.

Voici les valeurs de l'option Période d'expiration :

Valeur par défaut : 31 jours
Valeur minimale : 1 jour

Pour empêcher l'expiration d'un abonnement, définissez le délai d'expiration sur never expire.

Délai de confirmation

L'option Délai d'accusé de réception spécifie le délai initial au-delà duquel un message non confirmé est renvoyé. Vous pouvez étendre le délai de confirmation pour chaque message en envoyant des requêtes ModifyAckDeadline ultérieures.

Voici les valeurs de l'option Délai d'accusé de réception :

Valeur par défaut : 10 secondes
Valeur minimale : 10 secondes
Valeur maximale : 600 secondes

Dans certains cas, les bibliothèques clientes Pub/Sub peuvent contrôler la fréquence de distribution et modifier dynamiquement le délai de confirmation. Dans ce cas, le message peut être renvoyé avant le délai de confirmation de réception que vous avez défini. Pour remplacer ce comportement, utilisez minDurationPerAckExtension et maxDurationPerAckExtension. Pour en savoir plus sur l'utilisation de ces valeurs, consultez Prise en charge de la diffusion exacte une seule fois dans les bibliothèques clientes.

Transformations de message unique

Les SMT permettent de modifier facilement les attributs et les données des messages directement dans Pub/Sub. Cette fonctionnalité permet de nettoyer, de filtrer ou de convertir le format des données avant que les messages ne soient envoyés à un client abonné.

Pour en savoir plus, consultez Présentation des SMT et Créer un abonnement avec des SMT.

Filtre d'abonnement

Utilisez l'option Filtre d'abonnement pour spécifier une chaîne avec une expression de filtrage. Si un abonnement comporte un filtre, il diffuse uniquement les messages correspondant à ce filtre. Le service Pub/Sub reconnaît automatiquement les messages qui ne correspondent pas au filtre.

Vous pouvez filtrer les messages en fonction de leurs attributs, mais pas en fonction des données qu'ils contiennent.
Si aucun attribut n'est spécifié, l'abonnement ne filtre pas les messages, et les abonnés reçoivent tous les messages.
Une fois appliqués, les filtres ne peuvent pas être modifiés ni supprimés.

Lorsque vous recevez des messages d'un abonnement avec un filtre, des frais de sortie ne vous sont pas facturés pour les messages reconnus par Pub/Sub. Des frais de distribution de messages et de stockage associé à Seek vous sont facturés pour ces messages.

Pour en savoir plus, consultez Filtrer les messages d'un abonnement.

Tri des messages

Lorsqu'une option Tri des messages est activée pour un abonnement, les clients abonnés reçoivent les messages publiés dans la même région avec la même clé de tri dans l'ordre dans lequel le service les a reçus.

Lorsque vous utilisez la diffusion ordonnée, les accusés de réception des messages ultérieurs ne sont traités qu'une fois ceux des messages précédents traités.

Les éditeurs doivent envoyer des messages avec une clé de tri pour que Pub/Sub puisse distribuer les messages dans l'ordre.

Si le tri n'est pas activé, Pub/Sub ne distribue pas les messages dans l'ordre, même s'ils ont une clé de tri.

Sujet des lettres mortes

Lorsqu'un message ne peut pas être distribué après un nombre défini de tentatives d'envoi ou qu'un abonné ne peut pas confirmer la réception du message, vous pouvez configurer un sujet de lettres mortes vers lequel ces messages peuvent être republiés.

Si vous définissez un sujet de lettres mortes, vous pouvez également spécifier le nombre maximal de tentatives de distribution. Voici les valeurs du nombre maximal de tentatives d'envoi pour le file d'attente de lettres mortes :

Valeur par défaut : 5 tentatives de distribution
Valeur minimale : 5 tentatives de livraison
Valeur maximale : 100 tentatives d'envoi

Si le file d'attente de lettres mortes se trouve dans un projet différent de celui de l'abonnement, vous devez également spécifier l'ID de projet avec le file d'attente de lettres mortes.

Pour en savoir plus, consultez Transfert vers des sujets de lettres mortes.

Stratégie de nouvelle tentative

Si le délai de confirmation arrive à expiration ou si un abonné répond avec un accusé de réception négatif, Pub/Sub peut renvoyer le message. Cette tentative de nouvelle distribution est appelée stratégie de nouvelle tentative de l'abonnement.

Par défaut, la stratégie de nouvelle tentative d'un abonnement est définie sur Réessayer immédiatement. Avec cette option, Pub/Sub renvoie le message lorsque le délai de confirmation expire ou si un abonné répond avec un accusé de réception négatif.

Vous pouvez également définir la valeur sur Réessayer après l'intervalle exponentiel entre les tentatives. Dans ce cas, vous devez spécifier les valeurs maximale et minimale de l'intervalle entre les tentatives.

Voici quelques consignes pour définir les valeurs de délai avant nouvelle tentative maximal et minimal :

Si vous définissez la valeur maximale de la durée de l'intervalle entre les tentatives, la valeur par défaut de la durée minimale de l'intervalle entre les tentatives est de 10 secondes.
Si vous définissez la valeur minimale de l'intervalle entre les tentatives, la valeur par défaut de l'intervalle maximal entre les tentatives est de 600 secondes.
L'intervalle maximal entre les tentatives que vous pouvez spécifier est 600 secondes.

Stratégie de nouvelle tentative et messages groupés

Si les messages se trouvent dans un lot, Pub/Sub démarre l'intervalle exponentiel entre les tentatives lorsque l'un des événements suivants se produit :

L'abonné envoie un accusé de réception négatif pour chaque message du lot.
Le délai de confirmation expire.

Stratégie de nouvelle tentative et abonnement push

Si vous recevez des messages provenant d'un abonnement push, Pub/Sub peut les renvoyer après l'intervalle entre les tentatives push plutôt que l'intervalle exponentiel entre les tentatives. Lorsque l'intervalle push est plus long que l'intervalle exponentiel, Pub/Sub distribue à nouveau les messages non confirmés après l'intervalle push.

Propriétés des abonnements pull

Lorsque vous configurez un abonnement par extraction, vous pouvez spécifier les propriétés suivantes.

Diffusion de type "exactement une fois"

Diffusion de type "exactement une fois". Si cette option est définie, Pub/Sub respecte les garanties de distribution exactement une fois. Si aucune valeur n'est spécifiée, l'abonnement accepte la distribution au moins une fois pour chaque message.

Propriétés des abonnements push

Lorsque vous configurez un abonnement push, vous pouvez spécifier les propriétés suivantes.

Points de terminaison

URL du point de terminaison (obligatoire) Une adresse HTTPS accessible au public. Le serveur associé au point de terminaison push doit disposer d'un certificat SSL valide signé par une autorité de certification. Le service Pub/Sub envoie les messages aux points de terminaison push situés dans la même région Google Cloud où le service Pub/Sub stocke les messages. Le service Pub/Sub distribue les messages provenant de la même région Google Cloud de la manière la plus optimale possible.

Si les abonnés utilisent un pare-feu, ils ne peuvent pas recevoir de requêtes push. Pour recevoir des requêtes push, vous devez désactiver le pare-feu et vérifier le jeton Web JSON (JWT) utilisé dans la requête. Si un abonné dispose d'un pare-feu, il est possible que vous receviez une erreur 403 permission denied.
Pub/Sub ne nécessite plus la preuve que vous êtes propriétaire pour les domaines d'URL d'un abonnement push. Si votre domaine reçoit des requêtes POST inattendues de la part de Pub/Sub, vous pouvez signaler un abus présumé.

Authentification

Activez l'authentification. Lorsqu'il est activé, les messages envoyés par Pub/Sub au point de terminaison push incluent un en-tête d'autorisation permettant au point de terminaison d'authentifier la requête. Les mécanismes d'authentification et d'autorisation automatiques sont disponibles pour les points de terminaison de l'environnement standard App Engine et de Cloud Run Functions hébergés dans le même projet que l'abonnement.

La configuration de l'authentification pour un abonnement push authentifié se compose d'un compte de service géré par l'utilisateur et des paramètres d'audience spécifiés dans un appel create, patch ou ModifyPushConfig. Vous devez également attribuer un rôle spécifique à un compte de service, comme indiqué dans la section suivante.

Audience Chaîne unique, ne respectant pas la casse, que le webhook utilise pour valider l'audience visée par un jeton spécifique.
Compte de service : Pub/Sub crée automatiquement un compte de service pour vous au format service-{PROJECT_NUMBER}@gcp-sa-pubsub.iam.gserviceaccount.com.

Conditions requises pour activer l'authentification

Le compte de service géré par l'utilisateur est le compte de service associé à l'abonnement push. Ce compte est utilisé comme revendication email du jeton Web JSON (JWT) généré. Voici la liste des exigences concernant le compte de service :

Ce compte de service géré par l'utilisateur doit se trouver dans le même projet que l'abonnement push.
Le compte principal qui crée ou modifie l'abonnement push doit disposer de l'autorisation iam.serviceAccounts.actAs sur le compte de service géré par l'utilisateur pour pouvoir associer le compte de service à l'abonnement push. Pour en savoir plus, consultez Rattacher des comptes de service à des ressources.
Autorisations requises : ce compte de service doit disposer de l'autorisation iam.serviceAccounts.getOpenIdToken (incluse dans le rôle roles/iam.serviceAccountTokenCreator) pour permettre à Pub/Sub de créer des jetons JWT pour le compte de service spécifié afin d'authentifier les requêtes push.

Désencapsulation de la charge utile

L'option Activer la désencapsulation de la charge utile supprime toutes les métadonnées des messages Pub/Sub, à l'exception des données de message. Avec le déballage de la charge utile, les données du message sont directement fournies en tant que corps HTTP.

Vous pouvez également activer l'option Écrire des métadonnées. L'option Écrire les métadonnées ajoute les métadonnées de message précédemment supprimées à l'en-tête de requête.

Propriétés BigQuery

Lorsque vous sélectionnez le type de diffusion d'un abonnement sur Écrire dans BigQuery, vous pouvez spécifier les propriétés supplémentaires suivantes.

Utiliser un schéma avec sujet

Cette option permet à Pub/Sub d'utiliser le schéma du sujet Pub/Sub auquel l'abonnement est associé. De plus, Pub/Sub écrit les champs des messages dans les colonnes correspondantes de la table BigQuery.

Lorsque vous utilisez cette option, n'oubliez pas de vérifier les exigences supplémentaires suivantes :

Les champs du schéma du sujet et du schéma BigQuery doivent avoir les mêmes noms et leurs types doivent être compatibles.
Tout champ facultatif du schéma du sujet doit également être facultatif dans le schéma BigQuery.
Les champs obligatoires dans le schéma du sujet ne doivent pas nécessairement l'être dans le schéma BigQuery.
Si des champs BigQuery ne sont pas présents dans le schéma du sujet, ils doivent être en mode NULLABLE.
Si le schéma du sujet comporte des champs supplémentaires qui ne sont pas présents dans le schéma BigQuery et que ces champs peuvent être supprimés, sélectionnez l'option Supprimer les champs inconnus.
Vous ne pouvez sélectionner qu'une seule des propriétés d'abonnement, Utiliser le schéma du sujet ou Utiliser le schéma de la table.

Si vous ne sélectionnez pas l'option Utiliser un schéma de sujet ou Utiliser un schéma de table, assurez-vous que la table BigQuery comporte une colonne data de type BYTES, STRING ou JSON. Pub/Sub écrit le message dans cette colonne BigQuery.

Il est possible que les modifications apportées au schéma des thèmes Pub/Sub ou au schéma de la table BigQuery ne prennent pas effet immédiatement avec les messages écrits dans la table BigQuery. Par exemple, si l'option Supprimer les champs inconnus est activée et qu'un champ est présent dans le schéma Pub/Sub, mais pas dans le schéma BigQuery, les messages écrits dans la table BigQuery peuvent toujours ne pas contenir le champ après l'avoir ajouté au schéma BigQuery. Les schémas finissent par se synchroniser et les messages suivants incluent le champ.

Lorsque vous utilisez l'option Utiliser le schéma du sujet pour votre abonnement BigQuery, vous pouvez également profiter de la capture des données modifiées (CDC, Change Data Capture) de BigQuery. La CDC met à jour vos tables BigQuery en traitant et en appliquant les modifications aux lignes existantes.

Pour en savoir plus sur cette fonctionnalité, consultez Diffuser les mises à jour des tables avec la capture des données modifiées.

Pour savoir comment utiliser cette fonctionnalité avec les abonnements BigQuery, consultez Capture de données modifiées BigQuery.

Utiliser un schéma de table

Cette option permet à Pub/Sub d'utiliser le schéma de la table BigQuery pour écrire les champs d'un message JSON dans les colonnes correspondantes. Lorsque vous utilisez cette option, n'oubliez pas de vérifier les exigences supplémentaires suivantes :

Les noms de chaque colonne du table BigQuery ne doivent contenir que des lettres (a-z, A-Z), des chiffres (0-9) ou des traits de soulignement (_).
Les messages publiés doivent être au format JSON.

Les conversions JSON suivantes sont acceptées :

Type JSON	Type de données BigQuery
`string`	`NUMERIC`, `BIGNUMERIC`, `DATE`, `TIME`, `DATETIME` ou `TIMESTAMP`
`number`	`NUMERIC`, `BIGNUMERIC`, `DATE`, `TIME`, `DATETIME` ou `TIMESTAMP`

Lorsque vous utilisez number pour les conversions DATE, DATETIME, TIME ou TIMESTAMP, le nombre doit respecter les représentations acceptées.
Lorsque vous utilisez number pour la conversion en NUMERIC ou BIGNUMERIC, la précision et la plage de valeurs sont limitées à celles acceptées par la norme IEEE 754 pour l'arithmétique à virgule flottante. Si vous avez besoin d'une grande précision ou d'une plage de valeurs plus large, utilisez plutôt les conversions string vers NUMERIC ou BIGNUMERIC.
Lorsque vous utilisez les conversions string vers NUMERIC ou BIGNUMERIC, Pub/Sub suppose que la chaîne est un nombre lisible par l'humain (par exemple, "123.124"). Si le traitement de la chaîne en tant que nombre lisible par l'humain échoue, Pub/Sub traite la chaîne comme des octets encodés avec BigDecimalByteStringEncoder.

Si le sujet de l'abonnement est associé à un schéma, la propriété d'encodage du message doit être définie sur JSON.
Si des champs BigQuery ne sont pas présents dans les messages, ils doivent être en mode NULLABLE.
Si les messages comportent des champs supplémentaires qui ne sont pas présents dans le schéma BigQuery et que ces champs peuvent être supprimés, sélectionnez l'option Supprimer les champs inconnus.
Vous ne pouvez sélectionner qu'une seule des propriétés d'abonnement, Utiliser le schéma du sujet ou Utiliser le schéma de la table.

Il est possible que les modifications apportées au schéma de la table BigQuery ne prennent pas effet immédiatement avec les messages écrits dans la table BigQuery. Par exemple, si l'option Supprimer les champs inconnus est activée et qu'un champ est présent dans les messages, mais pas dans le schéma BigQuery, les messages écrits dans la table BigQuery peuvent toujours ne pas contenir le champ après l'avoir ajouté au schéma BigQuery. Le schéma finit par se synchroniser et les messages suivants incluent le champ.

Lorsque vous utilisez l'option Utiliser le schéma de table pour votre abonnement BigQuery, vous pouvez également profiter de la capture des données modifiées (CDC, Change Data Capture) de BigQuery. La CDC met à jour vos tables BigQuery en traitant et en appliquant les modifications aux lignes existantes.

Pour en savoir plus sur cette fonctionnalité, consultez Diffuser les mises à jour des tables avec la capture des données modifiées.

Pour savoir comment utiliser cette fonctionnalité avec les abonnements BigQuery, consultez Capture de données modifiées BigQuery.

Supprimer les champs inconnus

Cette option est utilisée avec les options Utiliser un schéma avec sujet ou Utiliser un schéma de table. Lorsque cette option est activée, Pub/Sub peut supprimer tout champ présent dans le schéma ou le message du sujet, mais pas dans le schéma BigQuery. Les champs qui ne font pas partie du schéma BigQuery sont supprimés lors de l'écriture du message dans la table BigQuery.

Si l'option Supprimer les champs inconnus n'est pas définie, les messages comportant des champs supplémentaires ne sont pas écrits dans BigQuery et restent en attente dans les tâches d'abonnement, sauf si vous configurez un sujet de lettres mortes.

Le paramètre Supprimer les champs inconnus n'a aucune incidence sur les champs qui ne sont définis ni dans le schéma du sujet Pub/Sub, ni dans le schéma de la table BigQuery. Dans ce cas, un message Pub/Sub valide est remis à l'abonnement. Toutefois, comme BigQuery ne définit pas de colonnes pour ces champs supplémentaires, ils sont supprimés lors du processus d'écriture BigQuery. Pour éviter ce comportement, assurez-vous que tous les champs contenus dans le message Pub/Sub sont également contenus dans le schéma de la table BigQuery.

Le comportement concernant les champs supplémentaires peut également dépendre du type de schéma spécifique (Avro, tampon de protocole) et de l'encodage (JSON, binaire) utilisés. Pour savoir comment ces facteurs affectent le traitement des champs supplémentaires, consultez la documentation sur votre type de schéma et votre encodage spécifiques.

Écrire des métadonnées

Cette option permet à Pub/Sub d'écrire les métadonnées de chaque message dans des colonnes supplémentaires de la table BigQuery. Sinon, les métadonnées ne sont pas écrites dans la table BigQuery.

Si vous sélectionnez l'option Écrire les métadonnées, assurez-vous que la table BigQuery comporte les champs décrits dans le tableau suivant.

Si vous ne sélectionnez pas l'option Écrire les métadonnées, la table BigQuery de destination ne nécessite que le champ data, sauf si use_topic_schema est défini sur "true". Si vous sélectionnez les options Écrire les métadonnées et Utiliser le schéma du sujet, le schéma du sujet ne doit contenir aucun champ dont le nom correspond à celui des paramètres de métadonnées. Cette limitation inclut les versions camelcase de ces paramètres snake case.

Paramètres
`subscription_name`	STRING Nom d'un abonnement.
`message_id`	STRING ID d'un message
`publish_time`	TIMESTAMP Heure de publication d'un message.
`data`	BYTES, STRING ou JSON Corps du message. Le champ `data` est obligatoire pour toutes les tables BigQuery de destination pour lesquelles les options Utiliser un schéma avec sujet ou Utiliser un schéma de table ne sont pas sélectionnées. Si le champ est de type JSON, le corps du message doit être au format JSON valide.
`attributes`	STRING ou JSON Objet JSON contenant tous les attributs du message. Il contient également des champs supplémentaires qui font partie du message Pub/Sub, y compris la clé de tri, le cas échéant.

Propriétés Cloud Storage

Lorsque vous sélectionnez le type de distribution d'abonnement Écrire dans Cloud Storage, vous pouvez spécifier les propriétés supplémentaires suivantes.

Nom du bucket

Un bucket Cloud Storage doit déjà exister avant que vous ne créiez un abonnement Cloud Storage.

Les messages sont envoyés par lots et stockés dans le bucket Cloud Storage. Un seul lot ou fichier est stocké en tant qu'objet dans le bucket.

Le bucket Cloud Storage doit avoir l'option Paiements du demandeur désactivée.

Pour créer un bucket Cloud Storage, consultez Créer des buckets.

Préfixe, suffixe et date/heure du nom de fichier

Les fichiers Cloud Storage générés par l'abonnement Cloud Storage sont stockés en tant qu'objets dans le bucket Cloud Storage. Le nom de l'objet stocké dans le bucket Cloud Storage est au format suivant : <file-prefix><UTC-date-time>_<uuid><file-suffix>.

La liste suivante inclut des informations sur le format de fichier et les champs que vous pouvez personnaliser :

<file-prefix> est le préfixe de nom de fichier personnalisé. Ce champ est facultatif.
<UTC-date-time> est une chaîne générée automatiquement et personnalisable en fonction de l'heure de création de l'objet.
<uuid> est une chaîne aléatoire générée automatiquement pour l'objet.
<file-suffix> est le suffixe personnalisé du nom de fichier. Ce champ est facultatif. Le suffixe du nom de fichier ne peut pas se terminer par "/".
Vous pouvez modifier le préfixe et le suffixe du nom de fichier :
- Par exemple, si la valeur du préfixe du nom de fichier est prod_ et que la valeur du suffixe du nom de fichier est _archive, un exemple de nom d'objet est prod_2023-09-25T04:10:00+00:00_uN1QuE_archive.
- Si vous ne spécifiez pas le préfixe et le suffixe du nom de fichier, le nom de l'objet stocké dans le bucket Cloud Storage est au format suivant : <UTC-date-time>_<uuid>.
- Les exigences de dénomination des objets Cloud Storage s'appliquent également au préfixe et au suffixe du nom de fichier. Pour en savoir plus, consultez À propos des objets Cloud Storage.
Vous pouvez modifier la façon dont la date et l'heure s'affichent dans le nom du fichier :
- Les correspondances de date et heure obligatoires que vous ne pouvez utiliser qu'une seule fois : année (YYYY ou YY), mois (MM), jour (DD), heure (hh), minute (mm), seconde (ss). Par exemple, YY-YYYY ou MMM ne sont pas valides.
- Des éléments de correspondance facultatifs que vous ne pouvez utiliser qu'une seule fois : le séparateur de date et d'heure (T) et le décalage de fuseau horaire (Z ou +00:00).
- Éléments facultatifs que vous pouvez utiliser plusieurs fois : trait d'union (-), trait de soulignement (_), deux-points (:) et barre oblique (/).
- Par exemple, si la valeur du format de date et heure du nom de fichier est YYYY-MM-DD/hh_mm_ssZ, un exemple de nom d'objet est prod_2023-09-25/04_10_00Z_uNiQuE_archive.
- Si le format de date et d'heure du nom de fichier se termine par un caractère qui n'est pas un élément de correspondance, ce caractère remplacera le séparateur entre <UTC-date-time> et <uuid>. Par exemple, si la valeur du format de date et heure du nom de fichier est YYYY-MM-DDThh_mm_ss-, un exemple de nom d'objet est prod_2023-09-25T04_10_00-uNiQuE_archive.

Traitement des fichiers par lot

Les abonnements Cloud Storage vous permettent de décider quand vous souhaitez créer un fichier de sortie stocké en tant qu'objet dans le bucket Cloud Storage. Pub/Sub écrit un fichier de sortie lorsque l'une des conditions de traitement par lot spécifiées est remplie. Voici les conditions de traitement par lot de Cloud Storage :

Durée maximale des lots de stockage. Ce paramètre est obligatoire. L'abonnement Cloud Storage écrit un nouveau fichier de sortie si la valeur spécifiée de la durée maximale est dépassée. Si vous ne spécifiez pas de valeur, la valeur par défaut de cinq minutes est appliquée. Voici les valeurs applicables pour la durée maximale :
- Valeur minimale : 1 minute
- Valeur par défaut : 5 minutes
- Valeur maximale : 10 minutes
Nombre maximal d'octets par lot pour le stockage. Il s'agit d'un paramètre facultatif. L'abonnement Cloud Storage écrit un nouveau fichier de sortie si la valeur maximale d'octets spécifiée est dépassée. Voici les valeurs applicables pour le nombre maximal d'octets :
- Valeur minimale : 1 Ko
- Valeur maximale : 10 Gio
Nombre maximal de messages par lot pour le stockage Il s'agit d'un paramètre facultatif. L'abonnement Cloud Storage écrit un nouveau fichier de sortie si le nombre maximal de messages spécifié est dépassé. Voici les valeurs applicables pour le nombre maximal de messages :
- Valeur minimale = 1 000

Par exemple, vous pouvez configurer une durée maximale de 6 minutes et une taille maximale de 2 Go. Si, à la quatrième minute, le fichier de sortie atteint une taille de 2 Go, Pub/Sub finalise le fichier précédent et commence à écrire dans un nouveau fichier.

Un abonnement Cloud Storage peut écrire dans plusieurs fichiers d'un bucket Cloud Storage simultanément. Si vous avez configuré votre abonnement pour créer un fichier toutes les six minutes, vous pouvez observer la création de plusieurs fichiers Cloud Storage toutes les six minutes.

Dans certains cas, Pub/Sub peut commencer à écrire dans un nouveau fichier avant l'heure configurée par les conditions de regroupement des fichiers. Un fichier peut également dépasser la valeur "Nombre maximal d'octets" si l'abonnement reçoit des messages dont la taille est supérieure à cette valeur.

Format de fichier

Lorsque vous créez un abonnement Cloud Storage, vous pouvez spécifier le format des fichiers de sortie à stocker dans un bucket Cloud Storage (Texte ou Avro).

Texte : les messages sont stockés en texte brut. Un caractère de nouvelle ligne sépare un message du message précédent dans le fichier. Seules les charges utiles des messages sont stockées, et non les attributs ni les autres métadonnées.
Avro : les messages sont stockés au format binaire Apache Avro. Lorsque vous sélectionnez Avro, vous pouvez activer les propriétés supplémentaires suivantes :
- Écrire les métadonnées : cette option vous permet de stocker les métadonnées du message avec le message. Les métadonnées telles que les champs subscription_name, message_id, publish_time et attributes sont écrites dans les champs de premier niveau de l'objet Avro de sortie, tandis que toutes les autres propriétés du message autres que les données (par exemple, une ordering_key, si elle est présente) sont ajoutées en tant qu'entrées dans le mappage attributes.
  
  Si l'option Écrire les métadonnées est désactivée, seule la charge utile du message est écrite dans l'objet Avro de sortie. Voici le schéma Avro pour les messages de sortie avec les métadonnées d'écriture désactivées :
```
{
  "type": "record",
  "namespace": "com.google.pubsub",
  "name": "PubsubMessage",
  "fields": [
    { "name": "data", "type": "bytes" }
  ]
}
```
  Voici le schéma Avro pour les messages de sortie avec les métadonnées d'écriture activées :
```
{
  "type": "record",
  "namespace": "com.google.pubsub",
  "name": "PubsubMessageWithMetadata",
  "fields": [
    { "name": "subscription_name", "type": "string" },
    { "name": "message_id", "type": "string"  },
    { "name": "publish_time", "type": {
        "type": "long",
        "logicalType": "timestamp-micros"
      }
    },
    { "name": "attributes", "type": { "type": "map", "values": "string" } },
    { "name": "data", "type": "bytes" }
  ]
}
```
- Utiliser un schéma avec sujet : cette option permet à Pub/Sub d'utiliser le schéma du sujet Pub/Sub auquel l'abonnement est associé lors de l'écriture de fichiers Avro.
  
  Lorsque vous utilisez cette option, n'oubliez pas de vérifier les exigences supplémentaires suivantes :
  - Le schéma du sujet doit être au format Apache Avro.
  - Si les options Utiliser le schéma du sujet et Écrire des métadonnées sont activées, le schéma du sujet doit comporter un objet Record à sa racine. Pub/Sub développera la liste des champs de l'enregistrement pour inclure les champs de métadonnées. Par conséquent, l'enregistrement ne peut pas contenir de champs portant le même nom que les champs de métadonnées (subscription_name, message_id, publish_time ou attributes).

Compte de service

Vous disposez des options suivantes pour écrire des messages dans une table BigQuery ou un bucket Cloud Storage :

Configurez un compte de service personnalisé afin que seuls les utilisateurs disposant de l'autorisation iam.serviceAccounts.actAs sur le compte de service puissent créer un abonnement qui écrit dans la table ou le bucket. Le rôle Utilisateur du compte de service (roles/iam.serviceAccountUser) est un exemple de rôle qui inclut l'autorisation iam.serviceAccounts.actAs.
Utilisez l'agent de service Pub/Sub par défaut qui permet à tout utilisateur ayant la possibilité de créer des abonnements dans le projet de créer un abonnement qui écrit dans la table ou le bucket. L'agent de service Pub/Sub est le paramètre par défaut lorsque vous ne spécifiez pas de compte de service personnalisé.

Étapes suivantes

Créez un abonnement pull.
Créez un abonnement push.
Créez un abonnement BigQuery.
Créez un abonnement Cloud Storage.