Utiliser les packages de données data-packages

Commencer avec les packages gs-data-packages

Vous pouvez utiliser des packages de données pour exporter et importer les données et paramètres personnalisés de votre plateforme. Un package peut contenir différents types de configurations et de composants, filtrés ou non.

Dans les packages de données Campaign, les entités de la base de données Adobe Campaign doivent être affichées dans des fichiers XML. Dans un package, chaque entité est représentée avec toutes ses données.

Le principe des packages de données consiste à exporter une configuration de données puis l’intégrer à un autre environnement Adobe Campaign. Découvrez comment conserver un ensemble cohérent de packages de données dans cette section.

Types de packages types-of-packages

Vous pouvez travailler avec trois types de packages dans Adobe Campaign : les packages utilisateur, les packages plateforme et les packages admin.

Structure de 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, comme dans l’exemple ci-dessous :

<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 tableaux de 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 manuellement à partir de n’importe quel éditeur texte. Vous devez vous assurer que la structure du document XML soit conforme au schéma de données xtk:navtree. La console cliente est pourvue d’un module d’export et d’import de packages de données.

Exporter des packages export-packages

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 export-a-set-of-objects-in-a-package

Pour exporter un ensemble d’objets dans un package de données, procédez comme suit :

Gérer les dépendances manage-dependencies

Le processus d’export effectue le suivi des liens entre les différents éléments exportés. Deux règles définissent le mécanisme :

Exporter une campagne export-a-campaign

Vous trouverez ci-dessous un exemple de la manière d’exporter une campagne. La campagne marketing à exporter contient les éléments suivants :

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

Le contenu du package est le suivant :

<?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éfinie dans un schéma avec l’attribut @pkgAdmin and @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 les suivantes :

Gérer les définitions de packages manage-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.

Créer une définition de package create-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 add-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 bonnes 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 configure-package-definitions-generation

La génération de packages peut être paramétrée à partir de l'onglet Contenu de définition de package. Pour ce faire, cliquez sur le lien Paramètres de génération.

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

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

Importer des packages import-packages

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

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

Pour importer un package de données existant, procédez comme suit :

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 install-a-standard-package

Les packages intégrés (ou packages standard) sont installés lors de la configuration d’Adobe Campaign. Selon vos autorisations, votre modèle de déploiement et votre offre de produit, vous pouvez importer de nouveaux packages standard.

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

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.

Versions

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 suivi de la génération des schémas.

Types de packages package-types

Commencez par définir différents types de packages. Quatre types seulement sont 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.

Par exemple, vous pouvez utiliser la convention suivante :

Ordre des packages d’entités entity-packages-order

Pour faciliter l’import, les packages d’entités doivent être classés au fur et à mesure de leur import.

Par exemple :

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 »).

Les bonnes pratiques consistent également à indiquer la date de la mise à jour.