Show Menu
SUJETS×

Configuration du serveur Campaign

La section ci-dessous décrit les configurations côté serveur qui peuvent être exécutées en fonction de vos besoins et des spécificités de votre environnement.
Ces configurations doivent être exécutées par les administrateurs et uniquement pour les modèles d’hébergement On-premise.
Pour les déploiements hébergés , les paramètres côté serveur peuvent uniquement être configurés par Adobe. Cependant, certains paramètres peuvent être configurés dans le Panneau de configuration (par exemple, la gestion des listes autorisées IP ou les autorisations d’URL).
Pour plus d’informations, consultez les sections suivantes :
Les fichiers de configuration de Campaign Classic sont stockés dans le dossier conf du dossier d’installation d’Adobe Campaign. La configuration est répartie sur deux fichiers :
  • serverConf.xml  : configuration générale pour toutes les instances. Ce fichier regroupe les paramètres techniques du serveur Adobe Campaign : ces paramètres sont communs à toutes les instances. Vous trouverez ci-après la description de certains de ces paramètres. Les différents nœuds et paramètres sont répertoriés dans cette section .
  • config- <instance> .xml (où instance est le nom de l’instance) : configuration spécifique de l’instance. Si vous partagez votre serveur entre plusieurs instances, entrez les paramètres propres à chaque instance dans le fichier correspondant.

Définition des zones de sécurité

A propos des zones de sécurité

Chaque opérateur doit être associé à une zone pour se connecter à une instance et l'adresse IP de l'opérateur doit faire partie des adresses ou des plages d'adresses définies dans la zone de sécurité. La configuration des zones de sécurité est effectuée dans le fichier de configuration du serveur Adobe Campaign.
Les opérateurs sont liés à une zone de sécurité depuis le profil dans la console (nœud Administration > Gestion des accès > Opérateurs ). Apprenez comment lier les zones aux opérateurs Campaign dans cette section .

Création des zones de sécurité

Une zone est définie par :
  • une ou plusieurs plages d'adresses IP (IPv4 et IPv6)
  • un nom technique associé à chaque plage d'adresses IP
Les zones de sécurité sont imbriquées. Chaque définition d'une nouvelle zone à l'intérieur d'une autre réduit donc le nombre d'opérateurs pouvant s'y connecter tout en augmentant les droits attribués à chaque opérateur.
Les zones peuvent être définies lors de la configuration du serveur dans le fichier serverConf.xml . Tous les paramètres disponibles dans serverConf.xml sont répertoriés dans cette section .
Chaque zone définit des droits, comme par exemple :
  • Connexion en HTTP plutôt qu'HTTPS
  • Affichage des erreurs (pile d'erreurs Java, JavaScript, C++...)
  • Prévisualisation des rapports et des webApps
  • Authentification par login / password
  • Connexion en mode non-sécurisé
Chaque opérateur doit être associé à une zone. Si l'adresse IP de l'opérateur appartient à la plage définie par la zone, l'opérateur peut donc se connecter à l'instance. Il se peut que l'adresse IP de l'opérateur soit définie dans plusieurs zones. Dans ce cas, l'opérateur reçoit l'union des droits disponibles pour chacune des zones.
Le fichier serverConf.xml livré d'usine contient trois zones : public, vpn et lan .
La configuration livrée d'usine est sécurisée. Cependant, avant une migration depuis une version antérieure d'Adobe Campaign, il peut être nécessaire de réduire temporairement la sécurité afin de migrer et de valider les nouvelles règles.
Exemple d'une définition de zone dans le fichier serverConf.xml  :
<securityZone allowDebug="false" allowHTTP="false" label="Public Network" name="public">
<subNetwork label="All addresses" mask="*" name="all"/>

<securityZone allowDebug="true" allowHTTP="false" label="Private Network (VPN)"
              name="vpn" showErrors="true">

  <securityZone allowDebug="true" allowEmptyPassword="true" allowHTTP="true"
                allowUserPassword="false" label="Private Network (LAN)" name="lan"
                sessionTokenOnly="true" showErrors="true">
    <subNetwork label="Lan 1" mask="192.168.0.0/16" name="lan1"/>
    <subNetwork label="Lan 2" mask="172.16.0.0/12" name="lan2"/>
    <subNetwork label="Lan 3" mask="10.0.0.0/8" name="lan3"/>
    <subNetwork label="Localhost" mask="127.0.0.1/16" name="locahost"/>
    <subNetwork label="Lan (IPv6)" mask="fc00::/7" name="lan6"/>
    <subNetwork label="Localhost (IPv6)" mask="::1/128" name="localhost6"/>
  </securityZone>

</securityZone>
</securityZone>

L'ensemble des droits définissant une zone sont les suivants :
  • allowDebug : permet à une webApp d'être exécutée en mode "debug"
  • allowEmptyPassword : autorise une connexion à une instance sans mot de passe
  • allowHTTP : une session peut être créée sans utiliser le protocole HTTPS
  • allowUserPassword  : le jeton de session peut être de la forme «  <login>/<password>  »
  • sessionTokenOnly : le jeton de sécurité n'est pas nécessaire dans l'URL de connexion
  • showErrors : les erreurs côté serveur sont remontées et affichées
Dans la définition d'une zone, chaque attribut recevant la valeur true réduit la sécurité.
Dans le cas de Message Center, quand il y a plusieurs instances d'exécution, vous devez créer une zone de sécurité supplémentaire avec l'attribut sessionTokenOnly défini sur true , dans laquelle seules les adresses IP nécessaires doivent être ajoutées. Le paramétrage des instances est présenté dans ce document .

Bonnes pratiques pour les zones de sécurité

Dans la définition de la zone de sécurité lan , il est possible de rajouter un masque d'adresse IP définissant un accès technique. Cet ajout permettra d'accéder à toutes les instances hébergées sur le serveur.
<securityZone allowDebug="true" allowEmptyPassword="false" allowHTTP="true"
                    allowUserPassword="false" label="Private Network (LAN)" name="lan"
                    sessionTokenOnly="true" showErrors="true">
        <subNetwork label="Lan 1" mask="192.168.0.0/16" name="lan1"/>
        <subNetwork label="Lan 2" mask="172.16.0.0/12" name="lan2"/>
        <subNetwork label="Lan 3" mask="10.0.0.0/8" name="lan3"/>
        <subNetwork label="Localhost" mask="127.0.0.1/16" name="locahost"/>
        <subNetwork label="Lan (IPv6)" mask="fc00::/7" name="lan6"/>
        <subNetwork label="Localhost (IPv6)" mask="::1/128" name="localhost6"/>
  
        <!-- Customer internal IPs -->
        <subNetwork id="internalNetwork" mask="a.b.c.d/xx"/>

      </securityZone>

Il est recommandé de définir des plages d'adresses IP directement dans le fichier de configuration dédié à l'instance pour les opérateurs accédant uniquement à une instance particulière.
Dans le fichier config-<instance>.xml  :
  <securityZone name="public">
   ...
    <securityZone name="vpn">
      <subNetwork id="cus1" mask="a.b.c.d/xx"/>

Sous-réseaux et proxys dans une zone de sécurité

Le paramètre proxy peut être utilisé dans un élément subNetwork afin de définir l'utilisation d'un proxy dans une zone de sécurité.
Lorsqu'un proxy est référencé et qu'une connexion entre via ce proxy (visible via l'entête HTTP X-Forwarded-For), la zone vérifiée est celle des clients du proxy et non celle du proxy.
Si un proxy est configuré et qu'il est possible de passer outre ce dernier (ou s'il n'existe pas), l'adresse IP qui sera testée pourra être falsifiée.
De plus, les relais sont désormais gérés comme des proxys. Vous devez donc ajouter l'adresse IP 127.0.0.1 à la liste des proxys dans votre paramétrage des zones de sécurité.
Par exemple: " <subnetwork label="Lan 1" mask="192.168.0.0/16" name="lan1" proxy="127.0.0.1,10.100.2.135" /> ".
Plusieurs cas peuvent exister :
  • Un sous-réseau est directement référencé dans la zone de sécurité et aucun proxy n'est configuré : les utilisateurs du sous-réseau peuvent se connecter directement au serveur Adobe Campaign.
  • Un proxy est défini pour un sous-réseau dans la zone de sécurité : les utilisateurs provenant de ce sous-réseau peuvent accéder au serveur Adobe Campaign en passant par ce proxy.
  • Un proxy est inclus dans un sous-réseau de la zone de sécurité : les utilisateurs passant par ce proxy, indépendamment de leur provenance, peuvent accéder au serveur Adobe Campaign.
Les adresses IP des serveurs proxy susceptibles d’accéder au serveur Adobe Campaign doivent être saisies dans le sous-réseau <subnetwork> concerné et le sous-réseau de premier niveau <subnetwork name="all"/> . Par exemple, ici pour un proxy dont l’adresse IP est 10.131.146.102 :
<securityZone allowDebug="false" allowHTTP="false" label="Public Network" 
                      name="public">
    <subNetwork label="All addresses" mask="*" name="all"
                      proxy="10.131.146.102,127.0.0.1, ::1"/>

    <securityZone allowDebug="true" allowHTTP="false" label="Private Network (VPN)" 
                      name="vpn" showErrors="true">
        <securityZone allowDebug="true" allowEmptyPassword="false" allowHTTP="true" 
                      allowUserPassword="false" label="Private Network (LAN)" 
                      name="lan" sessionTokenOnly="true" showErrors="true">
            <subNetwork label="Lan proxy" mask="10.131.193.182" name="lan3" 
                      proxy="10.131.146.102,127.0.0.1, ::1"/>
            <subNetwork label="Lan 1" mask="192.168.0.0/16" name="lan1" 
                      proxy="127.0.0.1, ::1"/>

        </securityZone>
    </securityZone>
</securityZone>

Liaison d’une zone de sécurité à un opérateur

Une fois les zones définies, chaque opérateur doit être associé à l'une d'entre elles pour pouvoir se connecter à une instance et l'adresse IP de l'opérateur doit faire partie des adresses ou des plages d'adresses référencées dans la zone.
La configuration technique des zones est effectuée dans le fichier de configuration du serveur Campaign : serverConf.xml .
Au préalable, vous devez configurer l'énumération d'usine Zone de sécurité pour associer un libellé au nom interne de la zone défini dans le fichier serverConf.xml .
Ce paramétrage est effectué dans l'explorateur Campaign :
  1. Cliquez sur le nœud Administration > Plate-Forme > Enumérations .
  2. Sélectionnez l'énumération système Zone de sécurité (securityZone) .
  3. Pour chaque zone de sécurité définie dans le fichier de configuration du serveur, cliquez sur le bouton Ajouter .
  4. Dans le champ Nom interne , saisissez le nom de la zone définie dans le fichier serverConf.xml . Il correspond à l’attribut @name de l’élément <securityzone> . Dans le champ Libellé , rentrez le libellé associé au nom interne.
  5. Cliquez sur OK et enregistrez les modifications.
Une fois les zones définies et l'énumération Zone de sécurité configurée, vous devez associer chaque opérateur à une zone :
  1. Cliquez sur le nœud Administration > Gestion des accès > Opérateurs .
  2. Sélectionnez l'opérateur auquel vous voulez associer une zone de sécurité et cliquez sur l'onglet Edition .
  3. Dans l'onglet Droits d&#39;accès , cliquez sur le lien Editer les paramètres d&#39;accès... .
  4. Sélectionnez une zone dans la liste déroulante Zone autorisée pour la connexion
  5. Cliquez sur OK et enregistrez les modifications pour appliquer ces modifications.

Configurer Tomcat

Port par défaut pour Tomcat

Lorsque le port d’écoute 8080 du serveur Tomcat est déjà occupé par une autre application requise pour votre configuration, vous devez remplacer le port 8080 par un port disponible (8090 par exemple). Pour le modifier, modifiez le fichier server.xml enregistré dans le répertoire /tomcat-7/conf du dossier d’installation d’Adobe Campaign.
Modifiez ensuite le port des pages de relais JSP. Pour ce faire, modifiez le fichier serverConf.xml enregistré dans le répertoire /conf du répertoire d’installation d’Adobe Campaign. Tous les paramètres disponibles dans le fichier serverConf.xml sont répertoriés dans cette section .
<serverConf>
   ...
   <web controlPort="8005" httpPort="8090"...
   <url ... targetUrl="http://localhost:8090"...

Mapping d'un dossier sous Tomcat

Afin de définir les paramètres propres aux clients, vous pouvez créer un fichier user_contexts.xml dans le dossier /tomcat-7/conf , qui contient également le fichier contexts.xml .
Ce fichier contiendra des informations du type :
 <Context path='/foo' docBase='../customers/foo'   crossContext='true' debug='0' reloadable='true' trusted='false'/>

Au besoin, cette opération doit être reproduite côté serveur.

Personnalisation des paramètres de diffusion

Les paramètres de diffusion sont définis dans le fichier de configuration serverConf.xml . Tous les paramètres disponibles dans serverConf.xml sont répertoriés dans cette section .
La configuration générale du serveur et les commandes sont détaillées dans la section Paramétrage du serveur Campaign .
En complément, vous pouvez procéder aux paramétrages suivants, selon vos besoins et votre configuration.

Relais SMTP

Le module MTA agit comme un agent de transfert de mails natif pour la diffusion par le protocole SMTP (port 25).
Il est cependant possible de le remplacer par un serveur de messagerie relais si la politique de sécurité l'impose. Le cas échéant, le débit global sera le relais (si le débit du serveur relais est inférieur à celui d'Adobe Campaign).
Dans ce cas, ces paramètres sont définis en configurant le serveur SMTP dans la section <relay> . Vous devez spécifier l’adresse IP (ou hôte) du serveur SMTP utilisé pour transférer l’email et son port associé (25 par défaut).
<relay address="192.0.0.3" port="25"/>

Ce mode de fonctionnement implique des limitations importantes sur les diffusions puisqu'il peut réduire considérablement le débit en raison des performances propres au serveur relais (latence, bande passante...). De plus, la capacité de qualifier les erreurs de diffusion synchrones (détectées par l'analyse du trafic SMTP) sera limitée et aucun envoi ne sera possible si le serveur relais n'est pas disponible.

Processus MTA child

Il est possible de contrôler la population de processus enfants (maxSpareServers par défaut 2) afin d’optimiser les performances de diffusion en fonction de la puissance CPU des serveurs et des ressources réseau disponibles. Cette configuration doit être effectuée dans la section <master> de la configuration MTA sur chaque ordinateur individuel.
<master dataBasePoolPeriodSec="30" dataBaseRetryDelaySec="60" maxSpareServers="2" minSpareServers="0" startSpareServers="0">

Voir également la section Optimisation de l’envoi d’emails .

Gérer le trafic SMTP sortant avec les affinités

La configuration des affinités doit être cohérente d’un serveur à l’autre. Nous vous recommandons de contacter Adobe pour obtenir une configuration d’affinité, car les modifications de configuration doivent être répliquées sur tous les serveurs d’applications qui exécutent la MTA.
Vous pouvez améliorer le trafic SMTP sortant grâce à des affinités avec les adresses IP.
Pour cela, les étapes sont les suivantes :
  1. Saisissez les affinités dans la section <ipaffinity> du fichier serverConf.xml .
    Vous pouvez définir plusieurs noms pour une même affinité : ces noms doivent être séparés les uns des autres par le caractère ; .
    Exemple:
     IPAffinity name="mid.Server;WWserver;local.Server">
              <IP address="XX.XXX.XX.XX" heloHost="myserver.us.campaign.net" publicId="123" excludeDomains="neo.*" weight="5"/
    
    
    Reportez-vous au fichier serverConf.xml pour consulter les paramètres à utiliser.
  2. Pour permettre la sélection de l'affinité dans les listes déroulantes, vous devez ajouter le ou les noms des affinités dans l'énumération IPAffinity .
    Les énumérations sont présentées dans ce document .
    Il est ensuite possible de sélectionner l'affinité à utiliser, comme ci-dessous au niveau des typologies :
    Vous pouvez également vous référer à la section Configuration des serveurs de diffusion .

Autorisations d’URL

La liste par défaut des URL pouvant être appelées par des codes JavaScript (workflows, etc.) de vos instances Campaign Classic est limitée. Il s’agit des URL qui permettent à vos instances de fonctionner correctement.
Par défaut, les instances ne sont pas autorisées à se connecter à des URL externes. Cependant, il est possible d’ajouter des URL externes à la liste des URL autorisées afin que votre instance puisse s’y connecter. Vous pouvez ainsi connecter vos instances Campaign à des systèmes externes, comme des serveurs SFTP ou des sites web, afin d’activer le transfert de fichiers et/ou de données.
Une fois qu’une URL est ajoutée, elle est référencée dans le fichier de configuration de l’instance (serverConf.xml).
Vous pouvez gérer les autorisations d’URL en fonction de votre modèle d’hébergement :
  • Hybride ou On-premise  : ajoutez les URL à autoriser dans le fichier serverConf.xml . Des informations détaillées sont disponibles dans la section ci-dessous.
  • Hébergé  : ajoutez les URL à autoriser via le Panneau de contrôle . Pour plus d’informations, consultez la documentation dédiée .
Avec les modèles d’hébergement Hybride et On-premise , l’administrateur doit référencer une nouvelle urlPermission dans le fichier serverConf.xml . Tous les paramètres disponibles dans le fichier serverConf.xml sont répertoriés dans cette section .
Il existe trois modes de protection des connexions :
  • Blocage : toutes les URL qui n’appartiennent pas à la liste autorisée sont bloquées, avec un message d’erreur. Il s’agit du mode par défaut après un postupgrade.
  • Permissive : toutes les URL qui n’appartiennent pas à la liste autorisée sont autorisées.
  • Avertissement : toutes les URL qui n’appartiennent pas à la liste autorisée sont autorisées, mais l’interprète JS émet un avertissement afin que l’administrateur puisse les collecter. Ce mode ajoute des messages d’avertissement JST-310027.
<urlPermission action="warn" debugTrace="true">
  <url dnsSuffix="abc.company1.com" urlRegEx=".*" />
  <url dnsSuffix="def.partnerA_company1.com" urlRegEx=".*" />
  <url dnsSuffix="xyz.partnerB_company1.com" urlRegEx=".*" />
</urlPermission>

Par défaut, le client des nouveaux clients utilise le mode de blocage. S’ils doivent autoriser une nouvelle URL, ils doivent contacter leur administrateur pour l’ajouter à la liste autorisée.
Existing customers coming from a migration can use the warning mode for a while. Meanwhile they need to analyze the outbound traffic before authorizing the URLs. Une fois la liste des URL autorisées définie, ils doivent contacter leur administrateur pour ajouter les URL à la liste autorisée et activer le mode de blocage.

Sécurité et relais des pages dynamiques

Par défaut, toutes les pages dynamiques sont automatiquement liées au serveur Tomcat local de la machine dont le module web a démarré. Cette configuration est saisie dans la section <url> de la configuration du relais de requête pour le fichier ServerConf.xml . Tous les paramètres disponibles dans le fichier serverConf.xml sont répertoriés dans cette section .
Vous pouvez également relayer l'exécution de la page dynamique sur un serveur distant , dans le cas où le module Web n'est pas activé sur la machine. Pour cela, vous devez remplacer la valeur localhost par le nom de la machine distante pour les pages JSP et JSSP, les applications Web, les rapports et les chaînes.
Pour plus d’informations sur les différents paramètres disponibles, consultez le fichier de configuration serverConf.xml .
Pour les pages JSP, le paramétrage par défaut est le suivant :
<url relayHost="true" relayPath="true" targetUrl="http://localhost:8080" urlPath="*.jsp"/>

Adobe Campaign utilise les pages JSP suivantes :
  • /nl/jsp/ soaprouter.jsp : connexion des consoles clientes et services Web (API SOAP),
  • /nl/jsp/ m.jsp : pages miroir,
  • /nl/jsp/ logon.jsp : accès aux rapports par le Web et au déploiement de la console cliente,
  • /nl/jsp/ s.jsp  : utilisation du marketing viral (parrainage et réseaux sociaux).
Les JSSP utilisées pour Mobile App Channel sont les suivantes :
  • nms/mobile/1/registerIOS.jssp
  • nms/mobile/1/registerAndroid.jssp
Exemple:
Vous pouvez empêcher la connexion des postes clients de l'extérieur. Pour cela, il suffit de restreindre l'exécution de soaprouter.jsp et de n'autoriser que l'exécution des pages miroirs, des liens viraux, des formulaires web et des ressources publiques.
Les paramètres sont les suivants :
<url IPMask="<IP_addresses>" deny=""     hostMask="" relayHost="true"  relayPath="true"  targetUrl="http://localhost:8080" timeout="" urlPath="*.jsp"/>
<url IPMask="<IP_addresses>" deny=""     hostMask="" relayHost="true"  relayPath="true"  targetUrl="http://localhost:8080" timeout="" urlPath="*.jssp"/> 
<url IPMask=""               deny=""     hostMask="" relayHost="true" relayPath="true" targetUrl="http://localhost:8080" timeout="" urlPath="m.jsp"/>
<url IPMask=""               deny=""     hostMask="" relayHost="true" relayPath="true" targetUrl="http://localhost:8080" timeout="" urlPath="s.jsp"/>
<url IPMask=""               deny=""     hostMask="" relayHost="true" relayPath="true" targetUrl="http://localhost:8080" timeout="" urlPath="webForm.jsp"/>
<url IPMask=""               deny=""     hostMask="" relayHost="true"  relayPath="true"  targetUrl="http://localhost:8080" timeout="" urlPath="/webApp/pub*"/>
<url IPMask=""               deny=""     hostMask="" relayHost="true"  relayPath="true"  targetUrl="http://localhost:8080" timeout="" urlPath="/jssp/pub*"/>
<url IPMask=""               deny=""     hostMask="" relayHost="true"  relayPath="true"  targetUrl="http://localhost:8080" timeout="" urlPath="/strings/pub*"/>
<url IPMask=""               deny=""     hostMask="" relayHost="true"  relayPath="true"  targetUrl="http://localhost:8080" timeout="" urlPath="/interaction/pub*"/>
<url IPMask=""               deny="true" hostMask="" relayHost="false" relayPath="false" targetUrl="http://localhost:8080" timeout="" urlPath="*.jsp"/>
<url IPMask=""               deny="true" hostMask="" relayHost="false" relayPath="false" targetUrl="http://localhost:8080" timeout="" urlPath="*.jssp"/>

Dans cet exemple, la valeur <IP_addresses> correspond à la liste des adresses IP (séparées par des virgules) ayant la permission d'utiliser le module de relais pour ce masque.
Les valeurs doivent être adaptées selon votre configuration et vos contraintes réseau, en particulier si des paramétrages spécifiques ont été développés pour votre installation.

Restreindre les commandes externes autorisées

La configuration ci-après est requise uniquement pour les installations on-premise.
A partir du build 8780, les administrateurs techniques peuvent restreindre la liste des commandes externes autorisées pouvant être utilisées dans Adobe Campaign.
Pour ce faire, vous devez créer un fichier texte contenant la liste des commandes dont vous souhaitez empêcher l'utilisation, par exemple :
ln
dd
openssl
curl
wget
python
python3
perl
ruby
sh

Cette liste n'est pas exhaustive.
In the exec node of the server configuration file, you need to reference the previously created file in the blocklistFile attribute.
Pour Linux uniquement  : dans le fichier de configuration du serveur, nous vous recommandons de spécifier un utilisateur dédié à l'exécution de commandes externes afin d'améliorer votre configuration de sécurité. Cet utilisateur est défini dans le nœud exec du fichier de configuration. Tous les paramètres disponibles dans le fichier serverConf.xml sont répertoriés dans cette section .
Si aucun utilisateur n’est spécifié, toutes les commandes sont exécutées dans le contexte utilisateur de l’instance Adobe Campaign. L’utilisateur doit être différent de celui qui exécute Adobe Campaign.
Par exemple :
<serverConf>
 <exec user="theUnixUser" blocklistFile="/pathtothefile/blocklist"/>
</serverConf>

Cet utilisateur doit être ajouté à la liste sudoer de l'opérateur 'neolane' Adobe Campaign.
Vous ne devez pas utiliser de sudo personnalisé. Un sudo standard doit être installé sur le système.

Gestion des en-têtes HTTP (HTTP Headers)

Par défaut, tous les en-têtes HTTP ne sont pas relayés. Vous pouvez ajouter des en-tête spécifiques dans les réponses transmises par le relais. Pour cela :
  1. Accédez au fichier serverConf.xml . Tous les paramètres disponibles dans serverConf.xml sont répertoriés dans cette section .
  2. Dans le nœud <relay> , accédez à la liste des en-têtes HTTP relayés.
  3. Ajoutez un élément <responseheader> comportant les attributs suivants :
    • name : nom de l'en-tête
    • value : valeur de l'en-tête.
    Par exemple :
    <responseHeader name="Strict-Transport-Security" value="max-age=16070400; includeSubDomains"/>
    
    

Tracking redondant

Lorsque plusieurs serveurs sont utilisés pour servir la redirection, ceux-ci devront pouvoir communiquer entre eux par des appels SOAP afin de partager les informations des URL à rediriger. Il se peut en effet qu'au moment du démarrage de la diffusion tous les serveurs de redirection ne soient pas disponibles, et qu'ils ne possèdent donc pas le même niveau d'information.
Dans le cas d'une architecture standard ou entreprise, le serveur applicatif principal doit être autorisé à télécharger des informations de tracking sur chaque machine.
Les URL des serveurs redondants doivent être renseignées dans la configuration de la redirection, via le fichier serverConf.xml . Tous les paramètres disponibles dans le fichier serverConf.xml sont répertoriés dans cette section .
Exemple:
<spareserver enabledIf="$(hostname)!='front_srv1'" id="1" url="http://front_srv1:8080" />
<spareserver enabledIf="$(hostname)!='front_srv2'" id="2" url="http://front_srv2:8080" />

La propriété enableIf est optionnelle (vide par défaut) et permet de n'activer la connexion que si le résultat est vrai ; ceci afin d'obtenir une configuration identique sur tous les serveurs de redirection.
Pour connaître le hostname de la machine, exécutez la commande suivante : hostname -s .

Gestion des ressources publiques

Les ressources publiques sont présentées dans la section Gestion des ressources publiques .
Elles sont stockées dans le répertoire /var/res/instance du répertoire d'installation d'Adobe Campaign.
L'URL correspondante est la suivante : http://serveur/res/instance instance est le nom de l'instance de tracking.
Vous pouvez spécifier un autre répertoire en ajoutant un nœud au fichier conf- <instance> .xml pour configurer le stockage sur le serveur. Cela signifie d’ajouter les lignes suivantes :
<serverconf>
  <shared>
    <dataStore hosts="media*" lang="fra">
      <virtualDir name="images" path="/var/www/images"/>
     <virtualDir name="publicFileRes" path="$(XTK_INSTALL_DIR)/var/res/$(INSTANCE_NAME)/"/>
    </dataStore>
  </shared>
</serverconf>

Dans ce cas, la nouvelle URL des ressources publiques indiquée dans la section supérieure de la fenêtre de l'assistant de déploiement doit pointer sur ce dossier.

Workflows en haute disponibilité et affinités

Vous pouvez configurer plusieurs serveurs de workflow (wfserver) et les répartir sur plusieurs machines. Si vous optez pour une architecture de ce type, paramétrez le mode de connexion des répartiteurs de charge en fonction de l'accès à Adobe Campaign.
Dans le cas d'un accès depuis le web, choisissez le mode load balancer afin de limiter les temps de connexion.
Si l'accès se fait depuis la console Adobe Campaign, préférez le mode hash ou sticky ip . Cela vous permet de maintenir la connexion entre le client riche et le serveur et d'éviter qu'une session utilisateur ne soit interrompue au cours d'une opération d'import ou d'export par exemple.
Vous pouvez choisir de forcer l'exécution d'un workflow ou d'une activité de workflow sur une machine particulière. Vous devez pour cela définir une ou plusieurs affinités au niveau du workflow ou de l'activité concernée.
  1. Créez la ou les affinités du workflow ou de l'activité en la tapant dans le champ Affinité .
    Vous pouvez choisir librement le nom des affinités. Cela dit, évitez les espaces ou les signes de ponctuation. Si vous utilisez des serveurs différents, indiquez des noms différents.
    La liste déroulante contient les affinités utilisées auparavant. La liste se complète au fur et à mesure avec les différentes valeurs saisies.
  2. Ouvrez le fichier nl6/conf/config- <instance>.xml .
  3. Modifiez la ligne correspondant au module wfserver de la façon suivante :
    <wfserver autoStart="true" affinity="XXX,"/>
    
    
    Si vous définissez plusieurs affinités, elles doivent être séparées par une virgule sans espace :
    <wfserver autoStart="true" affinity="XXX,YYY,"/>
    
    
    La virgule qui suit le nom de l'affinité est nécessaire afin que les workflows pour lesquels aucune affinité n'est définie puissent s'exécuter.
    Si vous souhaitez n'exécuter que les workflows pour lesquels une affinité est définie, n'ajoutez pas de virgule à la fin de la liste de vos affinités. Par exemple, modifiez la ligne de la façon suivante :
    <wfserver autoStart="true" affinity="XXX"/>
    
    

Redémarrage automatique des processus

Par défaut, les différents processus Adobe Campaign redémarrent automatiquement à 6h (matin, heure du serveur) chaque jour.
Il est néanmoins possible de modifier ce paramétrage.
Pour cela, accédez au fichier serverConf.xml dans le répertoire conf de votre installation. Tous les paramètres disponibles dans serverConf.xml sont répertoriés dans cette section .
Chaque processus paramétré dans ce fichier dispose d'un attribut processRestartTime . Vous pouvez modifier la valeur de cet attribut afin d'adapter l'heure de redémarrage de chaque processus à vos besoins.
Ne supprimez pas cet attribut. Tous les processus doivent être redémarrés chaque jour.

Limitation des fichiers téléchargeables

A new attribute uploadAllowList lets you restrict the file types available for upload on the Adobe Campaign server.
Cet attribut est disponible au niveau de l'élément dataStore du fichier serverConf.xml. Tous les paramètres disponibles dans le fichier serverConf.xml sont répertoriés dans cette section .
La valeur par défaut de cet attribut est .+ et permet de télécharger n'importe quel type de fichier.
Pour limiter les possibilités à certains formats, vous devez remplacer la valeur de l'attribut par une expression régulière java valide. Vous pouvez entrer plusieurs valeurs en les séparant par une virgule.
Par exemple : uploadAllowList=". .png,. .jpg" vous permet de télécharger des formats PNG et JPG sur le serveur. Aucun autre format ne sera accepté.
Sous Internet Explorer, le chemin complet des fichiers doit être vérifié par l'expression régulière.

Paramétrage de la connexion au proxy

Si vous devez connecter le serveur Campaign à l'extérieur par le biais d'un proxy (à l'aide d'une activité de workflow de transfert de fichier, par exemple), vous devez configurer la section proxyConfig de serverConf à l'aide d'une commande. Les connexions proxy suivantes sont possibles : HTTP, HTTPS, FTP, SFTP. Tous les paramètres disponibles dans le fichier serverConf.xml sont répertoriés dans cette section .
À compter de la version 20.2, les paramètres de protocole HTTP et HTTPS ne sont plus disponibles. Les informations ci-après continuent de mentionner ces paramètres car ils restent disponibles pour les builds précédents, y compris 9032.
Les proxys SOCKS ne sont pas pris en charge.
Utilisez la commande suivante :
nlserver config -setproxy:[protocol]/[serverIP]:[port]/[login][:‘https’|'http’]

les paramètres de protocole peuvent être "http", "https" ou "ftp".
Si vous définissez le protocole FTP sur le même port que le trafic HTTP/HTTPS, vous pouvez utiliser ce qui suit :
nlserver config -setproxy:http/198.51.100.0:8080/user

Les options "http" et "https" ne sont utilisées que lorsque le paramètre de protocole est "ftp" et indiquent si le tunneling sur le port spécifié sera effectué via HTTPS ou via HTTP.
Si vous utilisez des ports différents pour le trafic FTP/SFTP et HTTP/HTTPS sur le serveur proxy, vous devez définir le paramètre de protocole "ftp".
Par exemple :
nlserver config -setproxy:ftp/198.51.100.0:8080/user:’http’

Puis saisissez le mot de passe.
Les connexions HTTP sont définies dans le paramètre proxyHTTP :
<proxyConfig enabled=“1” override=“localhost*” useSingleProxy=“0”>
<proxyHTTP address=“198.51.100.0" login=“user” password=“*******” port=“8080”/>
</proxyConfig>

Les connexions HTTPS sont définies dans le paramètre proxyHTTPS :
<proxyConfig enabled=“1" override=“localhost*” useSingleProxy=“0">
<proxyHTTPS address=“198.51.100.0” login=“user” password=“******” port=“8080"/>
</proxyConfig>

Les connexions FTP/FTPS sont définies dans le paramètre proxyFTP :
<proxyConfig enabled=“1" override=“localhost*” useSingleProxy=“0">
<proxyFTP address=“198.51.100.0” login=“user” password=“******” port=“5555" https=”true”/>
</proxyConfig>

Si vous utilisez le même proxy pour plusieurs types de connexions, seul le paramètre proxyHTTP sera défini avec useSingleProxy défini sur "1" ou "true".
Si des connexions internes doivent passer à travers le proxy, ajoutez-les dans le paramètre override.
Si vous souhaitez désactiver temporairement la connexion au proxy, définissez le paramètre enabled sur "false" ou "0".