[S’applique également à la version 8]{class="badge positive" title="S’applique également à Campaign v8"}

Utiliser les packages de données working-with-data-packages

À propos des packages de données about-data-packages

Adobe Campaign vous permet d'exporter ou d'importer la configuration et les données de la plateforme grâce à un système de packages. Les packages peuvent contenir différents types de configurations et d'éléments, filtrés ou non.

Les packages de données permettent l'échange des entités de la base Adobe Campaign au travers de fichiers au format XML. Chaque entité contenue dans un package est représentée avec toutes ses données.

Le principe des packages de données ou data package consiste à exporter un paramétrage de données puis l’intégrer dans un autre système Adobe Campaign. Découvrez comment conserver un ensemble cohérent de packages de données dans cette section.

Types de packages types-of-packages

Il existe trois types de packages exportables : les packages utilisateur, les packages plateforme et les packages admin.

Structure des données data-structure

La description d'un package de données est un document XML structuré respectant la grammaire du schéma de données xrk:navtree.

Exemple de package de données :

<package>
  <entities schema="nms:recipient">
    <recipient email="john.smith@adobe.com" lastName="Smith" firstName="John">
      <folder _operation="none" name="nmsRootFolder"/>
      <company _operation="none" name="Adobe"/>
    </recipient>
  </entities>
  <entities schema="sfa:company">
    <company name="Adobe">
      location city="London" zipCode="W11 2BQ"/>
    </company>
  </entities>
</package>

Le document XML doit commencer et se terminer par l'élément <package>. Les éléments <entities> suivants répartissent les données par type de document.

Un élément <entities> contient les données du package au format du schéma de données renseigné dans l'attribut schema.

Les données d'un package ne doivent pas contenir de clés internes non compatibles entre les bases, comme les clés auto-générées (option autopk).

Dans notre exemple, les jointures sur les liens "folder" et "company" ont été remplacées par les clés dites de "haut niveau" sur les tables destinations :

<recipient>
  <folder _operation="none" name="nmsRootFolder"/>
  <company _operation="none" name="Adobe"/>
</recipient>

L'attribut operation avec la valeur "none" définit un lien de réconciliation.

Un package de données peut être construit à la main à partir de n'importe quel éditeur texte. Il suffit que la structure du document XML soit conforme au schéma de données "xtk:navtree". La console Adobe Campaign est pourvue d'un module d'export et d'import de package de données.

Export de packages exporting-packages

À propos de l'export de packages about-package-export

Les packages peuvent être exportés de trois manières différentes :

Une fois un package exporté, vous pourrez l'importer ainsi que toutes les entités ajoutées dans une autre instance Campaign.

Exporter un ensemble d'objets dans un package exporting-a-set-of-objects-in-a-package

L'assistant d'export de package est accessible à partir du menu principal Outils > Avancé > Export de package… de la console cliente Adobe Campaign.

Pour les trois types de package, l'assistant propose les étapes suivantes :

Gérer les dépendances managing-dependencies

Le mécanisme d'export permet à Adobe Campaign de suivre les liens entre les éléments exportés.

Deux règles définissent le mécanisme :

Exporter une campagne exporting-a-campaign

Voici un exemple d'export de campagne. La campagne marketing à exporter contient une tâche (libellé : "MyTask") et un workflow (libellé : "CampaignWorkflow") dans un dossier "MyWorkflow" (nœud : Administration / Exploitation / Workflows Techniques / Processus de campagne / MyWorkflow).

La tâche et le workflow sont exportés dans le même package que la campagne car les schémas correspondant sont reliés par des liens ayant une intégrité de type "own".

Contenu de package :

<?xml version='1.0'?>
<package author="Administrator (admin)" buildNumber="7974" buildVersion="7.1" img=""
label="" name="" namespace="" vendor="">
 <desc></desc>
 <version buildDate="2013-01-09 10:30:18.954Z"/>
 <entities schema="nms:operation">
  <operation duration="432000" end="2013-01-14" internalName="OP1" label="MyCampaign"
  modelName="opEmpty" start="2013-01-09">
   <controlGroup>
    <where filteringSchema=""/>
   </controlGroup>
   <seedList>
    <where filteringSchema="nms:seedMember"></where>
    <seedMember internalName="SDM1"></seedMember>
   </seedList>
   <parameter useAsset="1" useBudget="1" useControlGroup="1" useDeliveryOutline="1"
   useDocument="1" useFCPValidation="0" useSeedMember="1" useTask="1"
   useValidation="1" useWorkflow="1"></parameter>
   <fcpSeed>
    <where filteringSchema="nms:seedMember"></where>
   </fcpSeed>
   <owner _operation="none" name="admin" type="0"/>
   <program _operation="none" name="nmsOperations"/>
   <task end="2013-01-17 10:07:51.000Z" label="MyTask" name="TSK2" start="2013-01-16 10:07:51.000Z"
   status="1">
    <owner _operation="none" name="admin" type="0"/>
    <operation _operation="none" internalName="OP1"/>
    <folder _operation="none" name="nmsTask"/>
   </task>
   <workflow internalName="WKF12" label="CampaignWorkflow" modelName="newOpEmpty"
   order="8982" scenario-cs="Notification of the workflow supervisor (notifySupervisor)"
   schema="nms:recipient">
    <scenario internalName="notifySupervisor"/>
    <desc></desc>
    <folder _operation="none" name="Folder4"/>
    <operation _operation="none" internalName="OP1"/>
   </workflow>
  </operation>
 </entities>
</package>

L'appartenance à un type de package est défini dans un schéma avec l'attribut @pkgAdmin et @pkgPlatform. Ces deux attributs reçoivent une expression XTK définissant les conditions d'appartenance au package.

<element name="offerEnv" img="nms:offerEnv.png"
template="xtk:folder" pkgAdmin="@id != 0">

Enfin, l'attribut @pkgStatus permet de définir les règles d'export sur les éléments ou attributs. Selon la valeur de l'attribut, l'élément ou l'attribut sera présent dans le package exporté. Les trois valeurs possibles pour cet attribut sont :

Gérer les définitions de packages managing-package-definitions

Les définitions de packages vous permettent de créer une structure de package dans laquelle vous ajoutez les entités qui seront exportées ultérieurement dans un même package. Vous pourrez ensuite importer ce package et toutes les entités ajoutées dans une autre instance Campaign.

Rubriques connexes :

Créer une définition de package creating-a-package-definition

Les définitions de packages sont accessibles à partir du menu Administration > Paramétrage > Gestion des packages > Définitions de packages.

Pour créer une définition de package, cliquez sur le bouton Nouveau, puis remplissez les informations générales de la définition de package.

Vous pouvez ensuite ajouter des entités à la définition de package et l'exporter dans un package de fichier XML.

Rubriques connexes :

Ajouter des entités à une définition de package adding-entities-to-a-package-definition

Dans l'onglet Contenu, cliquez sur le bouton Ajouter pour sélectionner les entités à exporter avec le package. Les meilleures pratiques lors de la sélection des entités sont présentées dans cette section.

Les entités peuvent être ajoutées directement à une définition de package à partir de leur emplacement dans l'instance. Pour ce faire, suivez les étapes ci-dessous :

Paramétrer la génération des définitions de packages configuring-package-definitions-generation

La génération de package peut être configurée à partir de la définition de package Contenu . Pour ce faire, cliquez sur le bouton Paramètres de génération lien.

Exporter des packages à partir d'une définition de package exporting-packages-from-a-package-definition

Pour exporter un package à partir d'une définition de package, suivez les étapes ci-dessous :

Importer des packages importing-packages

L’assistant d’import de package est accessible à partir du menu principal Outils > Avancé > Import de package de la console client Adobe Campaign.

Vous pouvez importer le package d’un export réalisé antérieurement, par exemple à partir d’une autre instance Adobe Campaign, ou un package intégré, selon les conditions de votre licence.

Installer un package depuis un fichier installing-a-package-from-a-file

Pour importer un package de données existant, sélectionnez le fichier XML et cliquez sur Ouvrir.

Le contenu du package à importer est alors affiché dans la section centrale de l'éditeur.

Cliquez sur Suivant puis sur Démarrer pour lancer l'import.

Installer un package natif installing-a-standard-package

Les packages standard sont des packages natifs, installés lors de la configuration d’Adobe Campaign. Selon vos autorisations et votre modèle de déploiement, vous pouvez importer de nouveaux packages standard si vous acquérez de nouvelles options ou de nouveaux modules complémentaires ou si vous effectuez une mise à niveau vers une nouvelle offre.

Reportez-vous à votre contrat de licence pour savoir quels packages peuvent être installés.

Pour plus d'informations sur les packages natifs, consultez cette page.

Bonnes pratiques relatives aux packages de données data-package-best-practices

Cette section décrit comment organiser les packages de données de façon cohérente tout au long de la vie du projet.

Les packages peuvent contenir différents types de configurations et d'éléments, filtrés ou non. S'il manque certains éléments ou si vous n'importez pas les éléments/les packages dans l'ordre approprié, il est possible que la configuration de la plateforme soit interrompue.

De plus, si plusieurs personnes travaillent sur la même plateforme avec de nombreuses fonctionnalités différentes, le dossier contenant les spécifications des packages peut rapidement devenir complexe.

Bien que son utilisation ne soit pas obligatoire, cette section propose une solution afin de mieux organiser et utiliser des packages dans Adobe Campaign pour des projets de grande envergure.

Les principales contraintes sont les suivantes :

Recommandations data-package-recommendations

Effectuez toujours l'import dans la même version de la plateforme. Vous devez vérifier que vous déployez vos packages entre deux instances associées au même build. Ne forcez jamais l'import et mettez toujours la plateforme à jour en premier (si le build est différent).

Accordez de l'attention à la structure du schéma et de la base de données. L'import de packages avec schéma doit être suivie de la génération des schémas.

Solution data-package-solution

Types de packages package-types

Commencez par définir différents types de packages. Quatre types seulement seront utilisés :

Entités

Si vous devez déployer votre configuration sur une nouvelle instance, vous pouvez importer tous vos packages d'entités.

Fonctionnalités

Ce type de package a les avantages suivants :

Campagnes

Ce package n'est pas obligatoire. Il est parfois utile de créer un type spécifique pour toutes les campagnes, même si une campagne peut être considérée comme une fonctionnalité.

Mises à jour

Une fois configurée, une fonctionnalité peut être exportée dans un autre environnement. Par exemple, le package peut être exporté d'un environnement de développement vers un environnement de test. Dans ce test, un défaut est mis en évidence. Il doit être tout d'abord corrigé dans l'environnement de développement. Ensuite, le correctif doit être appliqué à la plateforme de test.

La première solution consisterait à réexporter l'ensemble de la fonctionnalité. Cependant, pour éviter tout risque (comme la mise à jour d'éléments indésirables), il est plus sûr d'avoir un package ne contenant que la correction.

Nous vous recommandons donc de créer un package de « mise à jour » contenant un seul type d'entité pour la fonctionnalité.

Une mise à jour peut non seulement être constituée d'un correctif, mais aussi d'un nouvel élément de votre package d'entité/de fonctionnalité/de campagne. Pour éviter de déployer l'ensemble du package, vous pouvez exporter un package de mise à jour.

Conventions de dénomination data-package-naming

Les types étant définis, nous devons spécifier une convention de dénomination. Adobe Campaign ne permettant pas de créer des sous-dossiers pour les spécifications de package, les nombres constituent la meilleure solution pour assurer l’organisation. Les nombres servent de préfixes pour les noms de packages. Vous pouvez utiliser la convention suivante :

Packages data-packages

Ordre des packages d'entité entity-packages-order

Pour faciliter l'import, les packages d'entités doivent être classés au fur et à mesure de leur importation. Par exemple :

Package 200 package-200

Le numéro de package « 200 » ne doit pas être utilisé pour une campagne spécifique : il sera utilisé pour mettre à jour une information qui concerne toutes les campagnes.

Mettre à jour le package update-package

Le dernier point concerne la numérotation des packages de mise à jour. Il s'agit du numéro de package (entité, fonctionnalité ou campagne) avec un préfixe « 5 ». Par exemple :

Le package de mise à jour ne doit contenir qu'une seule entité spécifique pour être facilement réutilisable. Pour le fractionner, ajoutez un nouveau nombre (en commençant par 1). Il n'existe pas de règles d'ordre spécifiques pour ces packages. Pour mieux comprendre, imaginez que nous ayons une fonctionnalité 101, pour une application de réseaux sociaux :

Documentation du package package-documentation

Lorsque vous mettez à jour un package, vous devez toujours insérer un commentaire dans le champ de description pour donner des informations détaillées sur les modifications et les motifs (par exemple, « ajouter un nouveau schéma » ou « corriger un défaut »).

Vous devez également dater le commentaire. Signalez toujours au « parent » le commentaire relatif à un package de mise à jour (package sans préfixe 5).