v7 On-premise et hybride

Principe de fonctionnement

La plateforme Adobe Campaign repose techniquement sur plusieurs modules.

Il existe de nombreux modules Adobe Campaign. Certains fonctionnent en continu, d'autres sont démarrés ponctuellement pour effectuer des actions d'administration (par exemple : configurer la connexion à la base de données) ou lancer une tâche récurrente (par exemple : consolider les informations de tracking).

On distingue trois types de modules Adobe Campaign :

• Modules multi-instances : un seul processus est exécuté pour toutes les instances. Cela s’applique aux modules suivants : web, syslogd, trackinglogd et watchdog (activités à partir du fichier config-default.xml).
• Modules mono-instances : un processus est exécuté par instance. Cela s’applique aux modules suivants : mta, wfserver, inMail, sms et stat (activités du fichier config-<instance>.xml).
• Les modules utilitaires : il s'agit de modules démarrés occasionnellement pour réaliser des opérations ponctuelles ou récurrentes (cleanup, config, remontée des logs de tracking, etc.).

L'administration de ces modules est assurée par l'outil ligne de commande nlserver installé dans le répertoire bin du dossier d'installation.

La syntaxe générale de l'outil nlserver est la suivante :

nlserver <command>``<command arguments>

Pour connaître la liste des modules disponibles, lancez la commande nlserver.

Les modules disponibles sont décrits dans le tableau suivant :

L'usage d'un module et la syntaxe de ses paramètres sont affichés à partir de la commande : nlserver.[module]-?

Exemple:

nlserver config -?

Usage: nlserver [-verbose:<verbose mode>] [-?|h|H] [-version] [-noconsole]
 [-tracefile:<file>] [-tracefilter:<[type|!type],...>]
 [-instance:<instance>] [-low] [-high] [-queryplans] [-detach]
 [-internalpassword:<[password/newpassword]>] [-postupgrade]
 [-nogenschema] [-force] [-allinstances]
 [-addinstance:<instance/DNS masks[/language]>]
 [-setdblogin:<[dbms:]account[:database][/password]@server>]
 [-monoinstance]
 [-addtrackinginstance:<instance/masks DNS[/databaseId/[/language[/password]]]>]
 [-trackingpassword:<[password][/newpassword]>]
 [-setproxy:<protocol/server:port[/login]>] [-reload]
 [-applyxsl:<schema/file.xsl>] [-filter:<file>]
 [-setactivationkey:<activation key>]
 [-getactivationkey:<client identifier>]
-verbose : verbose mode
-? : display this help message
-version : display version number
-noconsole : no longer display logs and traces on the console
-tracefile : name of trace file to be generated (without extension)
-tracefilter : filter for the traces to be generated e.g.: wdbc,soap,!xtkquery.
-instance : instance to be used (default instance if this option is not present).
-low : start up with low priority
-high : start up with high priority (not recommended)
-queryplans : generate traces with the execution plans of SQL queries.
-detach : detaches the process from its parent (internal option)
-internalpassword : changes the password of the server internal account.
-postupgrade : updates the database following upgrade to a higher version.
-nogenschema : does not recompute the schemas during database update
-force : updates the database even if this has already been done with the current build
-allinstances : updates the database over all configured instances
-addinstance : adds a new instance.
-setdblogin : sets the parameters for connection to the database of an instance. The DBMS can be 'oracle', 'postgresql', 'mssql' or 'odbc' (default=postgresql)
-monoinstance : initializes for a single instance ().
-addtrackinginstance : adds a new tracking instance.
-trackingpassword : changes the tracking password of an instance
-setproxy : sets the parameters for connection to a proxy server. The protocol can be 'http', 'https' or 'all'.
-reload : asks the server to reload the configuration of the instances.
-applyxsl : applies an XSL stylesheet to all entities of a schema.
-filter : applies the XTK filter contained in the file during loading of the schema entities.
-setactivationkey : sets the activation key