Transfert de journaux log-forwarding

Les clients disposant d’une licence auprès d’un fournisseur de journalisation ou qui hébergent un produit de journalisation peuvent transférer les journaux AEM (y compris Apache/Dispatcher) et les journaux CDN vers la destination de journalisation associée. AEM as a Cloud Service prend en charge les destinations de journalisation suivantes :

[1] le transfert des journaux CDN vers Amazon S3, Dynatrace et New Relic est en version bêta. Pour demander l’accès, envoyez un courrier électronique à l’adresse 🔗 avec votre ID de programme. Une fois l’accès activé, vous activez également les journaux CDN pour chaque destination avec cdn.enabled: true. Voir Journaux CDN pour Amazon S3, Dynatrace et New Relic (version bêta).

Le transfert du journal est configuré en libre-service en déclarant une configuration dans Git et peut être déployé via les pipelines de configuration de Cloud Manager vers les types d’environnements de développement, d’évaluation et de production. Le fichier de configuration peut être déployé dans des environnements de développement rapide (RDE) à l’aide de l’outil de ligne de commande.

Il existe une option pour que les journaux AEM et Apache/Dispatcher soient acheminés via l’infrastructure de réseau avancée d’AEM, telle que l’adresse IP de sortie dédiée. Les journaux CDN sont toujours envoyés directement à partir du CDN et n’utilisent pas la mise en réseau avancée. Voir ​ Transport et mise en réseau avancée ​.

Organisation de cet article how-organized

L’organisation de cet article est la suivante :

Configuration setup

Les jetons de la configuration (tels que ${{SPLUNK_TOKEN}}) représentent des secrets, qui ne doivent pas être stockés dans Git. Au lieu de cela, déclarez-les comme Cloud Manager Variables d’environnement secrètes. Veillez à sélectionner Tous comme valeur de liste déroulante pour le champ Service appliqué afin que les journaux puissent être transférés aux niveaux de création, de publication et de prévisualisation.

Il est possible de définir des valeurs différentes entre les journaux CDN et les journaux AEM (y compris Apache/Dispatcher), en incluant un bloc cdn et/ou aem supplémentaire après le bloc default, où les propriétés peuvent remplacer celles définies dans le bloc default ; seule la propriété enabled est requise. Un cas d’utilisation possible pourrait consister à utiliser un index Splunk différent pour les journaux CDN, comme illustré dans l’exemple ci-dessous.

   kind: "LogForwarding"
   version: "1"
   data:
     splunk:
       default:
         enabled: true
         host: "splunk-host.example.com"
         token: "${{SPLUNK_TOKEN}}"
         index: "AEMaaCS"
       cdn:
         enabled: true
         token: "${{SPLUNK_TOKEN_CDN}}"
         index: "AEMaaCS_CDN"

Un autre scénario consiste à désactiver le transfert des journaux CDN ou des journaux AEM (y compris Apache/Dispatcher). Par exemple, pour transférer uniquement les journaux du réseau CDN, vous pouvez configurer les éléments suivants :

   kind: "LogForwarding"
   version: "1"
   data:
     splunk:
       default:
         enabled: true
         host: "splunk-host.example.com"
         token: "${{SPLUNK_TOKEN}}"
         index: "AEMaaCS"
       aem:
         enabled: false

Transport et mise en réseau avancée transport-advancednetworking

Certaines organisations choisissent de limiter le trafic pouvant être reçu par les destinations de journalisation, d’autres peuvent nécessiter d’utiliser des ports autres que HTTPS (443). Si tel est le cas, Mise en réseau avancée doit être configuré avant le déploiement de la configuration de transfert de journal.

Utilisez le tableau ci-dessous pour connaître les exigences relatives à la configuration avancée de la mise en réseau et de la journalisation selon que vous utilisez le port 443 ou non et que vous avez besoin ou non que vos journaux apparaissent à partir d’une adresse IP fixe. Le tableau s’applique aux journaux AEM (y compris Apache/Dispatcher). Pour les journaux CDN, voir Journaux CDN et listes autorisées IP.

Pour les journaux AEM (y compris Apache/Dispatcher), si vous avez configuré Mise en réseau avancée, vous pouvez utiliser la propriété aem.advancedNetworking pour les transférer à partir d’une adresse IP sortante dédiée.

L’exemple ci-dessous montre comment configurer la journalisation sur un port HTTPS standard avec la mise en réseau avancée.

kind: "LogForwarding"
version: "1"
data:
  splunk:
    default:
      enabled: true
      host: "splunk-host.example.com"
      port: 443
      token: "${{SPLUNK_TOKEN}}"
      index: "aemaacs"
    aem:
      advancedNetworking: true

Journaux CDN et listes autorisées IP cdn-ip-allowlist

Les journaux CDN sont envoyés directement à partir du CDN (Fastly), et non à partir d’AEM as a Cloud Service. Cela s’applique à chaque destination de journalisation :

Si la liste des adresses IP partagées est trop volumineuse pour la liste autorisée, pensez à envoyer les journaux du réseau CDN à un serveur https ou à un magasin d’objets blob Azure (autre qu’Adobe) où une logique peut être écrite pour envoyer les journaux d’une adresse IP connue vers leur destination finale.

Authentification TLS mutuelle (mTLS) (version bêta) mtls

Les destinations Splunk, Elasticsearch/OpenSearch et HTTPS prennent en charge le protocole mTLS (Mutuel TLS). Avec mTLS, AEM as a Cloud Service présente un certificat client lorsqu’il se connecte à votre destination de journalisation, de sorte que la destination puisse vérifier que les journaux proviennent de votre environnement. mTLS s’applique aux journaux AEM (y compris Apache/Dispatcher) et aux journaux CDN.

mTLS fonctionne avec l’authentification existante de la destination. Conservez les propriétés d’authentification existantes de la destination, telles que token (Splunk) ou user et password (Elasticsearch/OpenSearch). Pour les destinations HTTPS qui transfèrent les journaux du réseau CDN, les authHeaderName et authHeaderValue sont obligatoires.

Configuration mtls-configuration

Ajoutez un bloc mtls avec les autres propriétés de la destination :

L’exemple suivant transfère les journaux AEM et CDN vers Splunk à l’aide de mTLS :

kind: "LogForwarding"
version: "1"
data:
  splunk:
    default:
      enabled: true
      host: "splunk-host.example.com"
      token: "${{SPLUNK_TOKEN}}"
      index: "aemaacs"
      mtls:
        cert: "${{SPLUNK_MTLS_CERT}}"
        key: "${{SPLUNK_MTLS_KEY}}"
        ca: "${{SPLUNK_MTLS_CA}}"

Les règles suivantes s’appliquent :

Formats de clés pris en charge mtls-key-formats

La première ligne du texte PEM de la clé affiche son format :

Pour une clé chiffrée, définissez également keyPasswd sur son mot de passe.

PKCS#8 chiffré est recommandé pour les clés chiffrées. Pour convertir une clé dans l’ancien format, utilisez la commande suivante, qui demande le mot de passe actuel, puis le mot de passe de la nouvelle clé :

openssl pkcs8 -topk8 -v2 aes-256-cbc -in client.key -out client-pkcs8.key

Stockez le contenu de client-pkcs8.key dans le secret référencé par key et son mot de passe dans le secret référencé par keyPasswd.

Journaux CDN mtls-cdn

Comme les autres propriétés, un bloc mtls sous default s’applique à la fois aux journaux AEM et aux journaux CDN. Pour utiliser un certificat différent pour les journaux CDN, définissez les propriétés mtls dans un bloc cdn. Pour utiliser le protocole mTLS uniquement pour les journaux AEM ou uniquement pour les journaux CDN, placez le bloc mtls dans le bloc aem ou cdn au lieu de default.

Après le déploiement d’une configuration qui active le transfert des journaux CDN vers une destination, il peut s’écouler plusieurs minutes avant l’arrivée des premiers journaux CDN. Pour les destinations HTTPS, la diffusion des journaux du réseau CDN ne démarre également qu’une fois que votre serveur a terminé le défi unique décrit dans HTTPS. La demande de défi est envoyée avec le même certificat client, de sorte que votre serveur doit également accepter ce certificat sur le chemin du défi.

Rotation et expiration du certificat mtls-rotation

Pour faire pivoter un certificat, mettez à jour les variables d’environnement secrètes Cloud Manager qui contiennent le certificat (et la clé, si elle a été modifiée), puis réexécutez le pipeline de configuration. Si le fichier de configuration de transfert du journal lui-même est inchangé, apportez-y également une modification afin que la configuration soit à nouveau appliquée. Par exemple, stockez les nouvelles valeurs dans de nouvelles variables d’environnement secrètes et référencez ces noms dans le bloc mtls .

Vous pouvez également recevoir une notification proactive Centre d’actions environ 21 jours avant l’expiration d’un certificat client. Suivez vous-même les dates d’expiration des certificats plutôt que de vous fier à cette notification.

Consignation de la configuration de destination logging-destinations

Les configurations des destinations de journalisation prises en charge sont répertoriées ci-dessous, avec des considérations spécifiques.

Amazon S3 amazons3

Les journaux CDN pour Amazon S3 sont en version bêta. Pour demander l’accès, envoyez un courrier électronique à l’adresse 🔗 avec votre ID de programme. Consultez Journaux CDN pour Amazon S3, Dynatrace et New Relic (version bêta) pour savoir comment les activer, et Journaux CDN Amazon S3 pour la disposition des fichiers et pour plus d’informations.

kind: "LogForwarding"
version: "1"
data:
  awsS3:
    default:
      enabled: true
      region: "your-bucket-region"
      bucket: "your-bucket-name"
      accessKey: "${{AWS_S3_ACCESS_KEY}}"
      secretAccessKey: "${{AWS_S3_SECRET_ACCESS_KEY}}"

Pour transférer les journaux AEM et les journaux CDN (journaux CDN en version bêta) :

kind: "LogForwarding"
version: "1"
data:
  awsS3:
    default:
      enabled: true
      region: "us-east-1"
      bucket: "your-bucket-name"
      accessKey: "${{AWS_S3_ACCESS_KEY}}"
      secretAccessKey: "${{AWS_S3_SECRET_ACCESS_KEY}}"
    cdn:
      enabled: true

Pour transférer uniquement les journaux CDN (en version bêta) :

kind: "LogForwarding"
version: "1"
data:
  awsS3:
    default:
      enabled: true
      region: "us-east-1"
      bucket: "your-bucket-name"
      accessKey: "${{AWS_S3_ACCESS_KEY}}"
      secretAccessKey: "${{AWS_S3_SECRET_ACCESS_KEY}}"
    aem:
      enabled: false
    cdn:
      enabled: true

Pour utiliser le redirecteur de journal S3, vous devez préconfigurer un utilisateur AWS IAM avec la politique appropriée pour accéder à votre compartiment S3. Consultez la Documentation de l’utilisateur AWS IAM pour savoir comment créer des informations d’identification d’utilisateur IAM.

La politique IAM doit permettre à l’utilisateur d’utiliser s3:PutObject. Pour transférer les journaux CDN (en version bêta), autorisez également s3:AbortMultipartUpload. Aucune autre autorisation n’est nécessaire : l’utilisateur n’a pas besoin de lire ou de répertorier le compartiment. Par exemple :

{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Action": [
            "s3:PutObject",
            "s3:AbortMultipartUpload"
        ],
        "Resource": "arn:aws:s3:::your-bucket-name/*"
    }]
}

Si le compartiment ne reçoit que des journaux CDN, vous pouvez limiter le Resource à arn:aws:s3:::your-bucket-name/aemcdn/*.

Consultez la documentation de la politique de compartiment ​ pour plus d’informations sur la mise en œuvre.

Journaux du réseau CDN Amazon S3 (version bêta) amazons3-cdn

Les journaux CDN pour Amazon S3 sont en version bêta. Ils ont besoin d’un accès à votre programme et à vos cdn.enabled: true. Voir Journaux CDN pour Amazon S3, Dynatrace et New Relic (version bêta).

Les journaux CDN sont écrits sous le dossier aemcdn/ de votre compartiment. Le format du nom de fichier est YYYY-MM-DDThh:mm:ss.000-<uniqueid>.log.gz. Par exemple :

aemcdn/
   2026-03-04T10:00:00.000-WnFWYN9BpOUs2aOVn4ee.log.gz
   2026-03-04T10:00:00.000-0pX8ub2yQcAmLs7rT1kd.log.gz
   2026-03-04T10:05:00.000-h3JkVv9ZqN2wE5sXyR0a.log.gz

Les clients sont chargés du traitement et de la gestion de ces fichiers, par exemple avec une règle de cycle de vie S3 sur le préfixe aemcdn/.

Considérations relatives aux journaux CDN (version bêta) :

Stockage d’objets blob Azure azureblob

kind: "LogForwarding"
version: "1"
data:
  azureBlob:
    default:
      enabled: true
      storageAccountName: "example_acc"
      container: "aem_logs"
      sasToken: "${{AZURE_BLOB_SAS_TOKEN}}

Un jeton SAS doit être utilisé pour l’authentification. Il doit être créé à partir de la page de signature d’accès partagé, plutôt que sur la page Jeton d’accès partagé , et doit être configuré avec les paramètres suivants :

Voici une capture d’écran d’un exemple de configuration de jeton SAS :

Si la diffusion des journaux a cessé après un fonctionnement correct, vérifiez si le jeton SAS que vous avez configuré est toujours valide, car il a peut-être expiré.

Journaux du réseau CDN de stockage Blob Azure azureblob-cdn

Chacun des serveurs de journalisation distribués globalement produira un nouveau fichier toutes les quelques secondes, sous le dossier aemcdn. Une fois créé, le fichier n’est plus ajouté à . Le format du nom de fichier est AAAA-MM-JJThhss.sss-uniqueid.log. Par ex., 2024-03-:00:00.000-WnFWYN9BpOUs2aOVn4ee.log.

Par exemple, à un moment donné :

aemcdn/
   2024-03-04T10:00:00.000-abc.log
   2024-03-04T10:00:00.000-def.log

Et puis 30 secondes plus tard :

aemcdn/
   2024-03-04T10:00:00.000-abc.log
   2024-03-04T10:00:00.000-def.log
   2024-03-04T10:00:30.000-ghi.log
   2024-03-04T10:00:30.000-jkl.log
   2024-03-04T10:00:30.000-mno.log

Chaque fichier contient plusieurs entrées de journal json, chacune sur une ligne distincte. Les formats d’entrée de journal sont décrits à la section Journalisation pour AEM as a Cloud Service et chaque entrée de journal inclut également les propriétés supplémentaires mentionnées dans la section Formats d’entrée de journal ci-dessous.

Journaux AEM du stockage Blob Azure azureblob-aem

Les journaux AEM (y compris Apache/Dispatcher) s’affichent sous un dossier avec la convention de nommage suivante :

Sous chaque dossier, un seul fichier est créé et ajouté. Les clients sont chargés de traiter et de gérer ce fichier afin qu’il ne s’étende pas trop.

Consultez les formats d’entrée de journal sous ​ Journalisation pour AEM as a Cloud Service ​. Les entrées de journal incluent également les propriétés supplémentaires mentionnées dans la section Formats d’entrée de journal ci-dessous.

Datadog datadog

kind: "LogForwarding"
version: "1"
data:
  datadog:
    default:
      enabled: true
      host: "http-intake.logs.datadoghq.eu"
      token: "${{DATADOG_API_KEY}}"
      tags:
         tag1: value1
         tag2: value2

Considérations

Elasticsearch et OpenSearch elastic

kind: "LogForwarding"
version: "1"
data:
  elasticsearch:
    default:
      enabled: true
      host: "example.com"
      user: "${{ELASTICSEARCH_USER}}"
      password: "${{ELASTICSEARCH_PASSWORD}}"
      pipeline: "ingest pipeline name"

Considérations

def envType = ctx.aem_env_type != null ? ctx.aem_env_type : 'unknown';
def sourceType = ctx._index;
def date = new SimpleDateFormat('dd_MM_yyyy').format(new Date());
ctx._index = sourceType + "_" + envType + "_" + date;

HTTPS https

kind: "LogForwarding"
version: "1"
data:
  https:
    default:
      enabled: true
      url: "https://example.com/aem_logs/aem"
      authHeaderName: "X-AEMaaCS-Log-Forwarding-Token"
      authHeaderValue: "${{HTTPS_LOG_FORWARDING_TOKEN}}"

Considérations

Journaux de réseau CDN HTTPS https-cdn

Les requêtes web (POST) seront envoyées en continu, avec une payload json qui est un tableau d’entrées de journal, avec le format d’entrée de journal décrit sous Journalisation pour AEM as a Cloud Service. Des propriétés supplémentaires sont mentionnées dans la section Formats d’entrée de journal ci-dessous.

Il existe également une propriété nommée sourcetype, qui est définie sur la valeur aemcdn.

Journaux HTTPS AEM https-aem

Pour les journaux AEM (y compris Apache/Dispatcher), les requêtes web (POST) sont envoyées en continu, avec une payload json qui est un tableau d’entrées de journal, avec les différents formats d’entrée de journal comme décrit dans Journalisation pour AEM as a Cloud Service. Des propriétés supplémentaires sont mentionnées dans la section Formats d’entrée de journal ci-dessous.

Il existe également une propriété nommée Source-Type, qui est définie sur l’une des valeurs suivantes :

API du journal New Relic newrelic-https

Le transfert de journal vers New Relic utilise l’API de journal HTTPS New Relic pour l’ingestion. Les journaux CDN vers New Relic sont en version bêta. Pour demander l’accès, envoyez un courrier électronique à l’adresse 🔗 avec votre ID de programme. Consultez Journaux CDN pour Amazon S3, Dynatrace et New Relic (version bêta) pour savoir comment les activer.

  kind: "LogForwarding"
  version: "1"
  data:
    newRelic:
      default:
        enabled: true
        uri: "https://log-api.newrelic.com/log/v1"
        apiKey: "${{NR_API_KEY}}"

Pour transférer les journaux AEM et les journaux CDN (journaux CDN en version bêta) :

  kind: "LogForwarding"
  version: "1"
  data:
    newRelic:
      default:
        enabled: true
        uri: "https://log-api.newrelic.com/log/v1"
        apiKey: "${{NR_API_KEY}}"
      cdn:
        enabled: true

Pour transférer uniquement les journaux CDN (en version bêta) :

  kind: "LogForwarding"
  version: "1"
  data:
    newRelic:
      default:
        enabled: true
        uri: "https://log-api.newrelic.com/log/v1"
        apiKey: "${{NR_API_KEY}}"
      aem:
        enabled: false
      cdn:
        enabled: true

Considérations

API du journal Dynatrace dynatrace-https

Le transfert du journal vers Dynatrace utilise l’API HTTPS Dynatrace pour l’ingestion. Les journaux CDN vers Dynatrace sont en version bêta. Pour demander l’accès, envoyez un courrier électronique à l’adresse 🔗 avec votre ID de programme. Consultez Journaux CDN pour Amazon S3, Dynatrace et New Relic (version bêta) pour savoir comment les activer.

Le jeton nécessite la portée Journaux d’ingestion (logs.ingest). Le même jeton est utilisé pour les journaux AEM et les journaux CDN.

  kind: "LogForwarding"
  version: "1"
  data:
    dynatrace:
      default:
        enabled: true
        environmentId: "${{DYNATRACE_ENVID}}"
        token: "${{DYNATRACE_TOKEN}}"

Pour transférer les journaux AEM et les journaux CDN (journaux CDN en version bêta) :

  kind: "LogForwarding"
  version: "1"
  data:
    dynatrace:
      default:
        enabled: true
        environmentId: "${{DYNATRACE_ENVID}}"
        token: "${{DYNATRACE_TOKEN}}"
      cdn:
        enabled: true

Pour transférer uniquement les journaux CDN (en version bêta) :

  kind: "LogForwarding"
  version: "1"
  data:
    dynatrace:
      default:
        enabled: true
        environmentId: "${{DYNATRACE_ENVID}}"
        token: "${{DYNATRACE_TOKEN}}"
      aem:
        enabled: false
      cdn:
        enabled: true

Considérations

Recherche de journaux CDN dans Dynatrace (version bêta) dynatrace-cdn

Dynatrace stocke chaque entrée de journal CDN, sous forme de texte JSON, dans le content d’un enregistrement de journal et utilise la timestamp de l’entrée comme heure d’enregistrement. Les propriétés du journal CDN, telles que source, url et status, ne sont pas des attributs de journal distincts. Il en va de même pour les journaux AEM transférés vers Dynatrace. Par conséquent :

Utilisez plutôt le mode avancé (DQL). Pour rechercher les journaux CDN de la dernière heure :

fetch logs, from: now() - 1h
| filter matchesPhrase(content, "aemcdn")

Pour analyser les propriétés du journal du réseau CDN et en afficher certaines :

fetch logs, from: now() - 1h
| parse content, "JSON:cdn"
| filter cdn[source] == "aemcdn"
| fields timestamp, cdn[url], cdn[status], cdn[pop], cdn[cache], cdn[aem_tier]

Splunk splunk

kind: "LogForwarding"
version: "1"
data:
  splunk:
    default:
      enabled: true
      host: "splunk-host.example.com"
      token: "${{SPLUNK_TOKEN}}"
      index: "aemaacs"

Considérations

Logique Sumo sumologic

Lors de la configuration de la logique Sumo pour l’ingestion de données, une « adresse HTTP Source » s’affiche, qui fournit l’hôte, l’URI du destinataire et la clé privée dans une seule chaîne. Par exemple :

https://collectors.de.sumologic.com/receiver/v1/http/ZaVnC...

Vous devez copier la dernière section de l’URL (sans la / précédente) et l’ajouter en tant que Variable d’environnement secrète Cloud Manager comme décrit dans la section Configuration ci-dessus, puis référencer cette variable dans votre configuration. Un exemple est fourni ci-dessous.

kind: "LogForwarding"
version: "1"
data:
  sumoLogic:
    default:
      enabled: true
      collectorURL: "https://collectors.de.sumologic.com/receiver/v1/http"
      privateKey: "${{SUMOLOGIC_PRIVATE_KEY}}"
      index: "aem-logs"

Journaux CDN pour Amazon S3, Dynatrace et New Relic (version bêta) cdn-opt-in

Le transfert des journaux CDN vers Amazon S3, Dynatrace et New Relic est en version bêta. Le transfert des journaux AEM (y compris Apache/Dispatcher) vers ces destinations n’est pas affecté et n’a pas besoin de requête.

Pour transférer les journaux CDN vers l’une de ces destinations, effectuez les deux étapes :

Les deux étapes sont nécessaires :

Le bloc cdn hérite de toutes les autres propriétés du bloc default, y compris les informations d’identification. enabled: true est donc la seule propriété que vous devez ajouter :

kind: "LogForwarding"
version: "1"
data:
  newRelic:
    default:
      enabled: true
      uri: "https://log-api.newrelic.com/log/v1"
      apiKey: "${{NR_API_KEY}}"
    cdn:
      enabled: true

Pour un programme disposant d’un accès, le paramétrage est le suivant :

Comme pour les autres destinations, les propriétés définies dans le bloc cdn remplacent les valeurs de default. Pour transférer uniquement les journaux CDN, définissez aem.enabled: false, comme dans la dernière ligne.

Pour arrêter le transfert des journaux CDN, définissez cdn.enabled: false et exécutez le pipeline de configuration. Le transfert du journal CDN vers cette destination s’arrête lorsque la configuration est déployée. Les journaux AEM ne sont pas affectés.

Avant d’activer les journaux du réseau CDN, évaluez le volume supplémentaire. Les fournisseurs de services de journalisation qui facturent en fonction du volume ingéré, tels que Dynatrace et New Relic, facturent les journaux CDN de la même manière que pour les journaux AEM.

Pour envoyer vos commentaires sur la version bêta, envoyez un e-mail à l’adresse 🔗.

Formats d’entrée de journal log-formats

Voir Journalisation pour AEM as a Cloud Service pour le format de chaque type de journal respectif (journaux CDN et journaux AEM, y compris Apache/Dispatcher). Certaines destinations de journalisation ajoutent ou modifient des propriétés dans les entrées de journal du réseau CDN, par exemple le format de timestamp pour New Relic. Voir Entrées du journal CDN en consignant la destination.

Étant donné que les journaux de plusieurs programmes et environnements peuvent être transférés vers la même destination de journalisation, en plus de la sortie décrite dans l’article de journalisation, les propriétés suivantes seront incluses dans chaque entrée de journal :

Par exemple, les propriétés peuvent avoir les valeurs suivantes :

aem_env_id: 1242
aem_env_type: dev
aem_program_id: 12314
aem_tier: author

Migration à partir du transfert de journal hérité legacy-migration

Avant que la configuration du transfert du journal ne soit réalisée via un modèle en libre-service, il était demandé aux clients d’ouvrir des tickets d’assistance, où Adobe lancerait l’intégration.

Les clients qui ont été configurés de cette manière par Adobe sont invités à s’adapter au modèle en libre-service à leur convenance. Il existe plusieurs raisons d’effectuer cette transition :

Une fois prêt à migrer, configurez simplement le fichier YAML comme décrit dans les sections précédentes. Utilisez le pipeline de configuration Cloud Manager pour effectuer un déploiement dans chacun des environnements où la configuration doit être appliquée.

Il est recommandé, mais pas obligatoire, de déployer une configuration sur tous les environnements afin qu’ils soient tous en libre-service. Dans le cas contraire, vous pouvez oublier les environnements qui ont été configurés par Adobe par rapport à ceux qui ont été configurés en libre-service.