Configurazione del server Campaign

La sezione seguente descrive le configurazioni lato server che possono essere eseguite in base alle esigenze e alle specifiche dell'ambiente.

IMPORTANTE

Queste configurazioni devono essere eseguite dagli amministratori e solo per i modelli di hosting locali .

Per le distribuzioni ospitate , le impostazioni lato server possono essere configurate solo Adobe. Tuttavia, alcune impostazioni possono essere configurate all'interno del Pannello di controllo Campaign (ad esempio, gestione dei inserire nell'elenco Consentiti di IP o autorizzazioni URL).

Per ulteriori informazioni, consultare le sezioni seguenti:

I file di configurazione Campaign Classic sono memorizzati nella cartella conf della cartella di installazione Adobe Campaign . La configurazione è suddivisa in due file:

  • serverConf.xml: configurazione generale per tutte le istanze. Questo file combina i parametri tecnici del server Adobe Campaign : vengono condivisi da tutte le istanze. La descrizione di alcuni di questi parametri è dettagliata di seguito. I diversi nodi e parametri ed elencati in questa sezione.
  • config-<instance>.xml (dove instance è il nome dell’istanza): specifica configurazione dell'istanza. Se condividete il server tra più istanze, inserite i parametri specifici per ciascuna istanza nel relativo file.

Definizione delle aree di protezione

Informazioni sulle aree di protezione

Ogni operatore deve essere collegato a una zona per accedere a un'istanza e l'IP dell'operatore deve essere incluso negli indirizzi o nei set di indirizzi definiti nella zona di sicurezza. La configurazione dell'area di protezione viene eseguita nel file di configurazione del server Adobe Campaign .

Gli operatori sono collegati a una zona di protezione dal relativo profilo nella console ( Administration > Access management > Operators nodo). Scopri come collegare le aree agli operatori della campagna in questa sezione.

Creazione di aree di protezione

Una zona è definita da:

  • uno o più intervalli di indirizzi IP (IPv4 e IPv6)
  • un nome tecnico collegato a ciascun intervallo di indirizzi IP

Le aree di sicurezza sono interbloccate, il che significa che la definizione di una nuova zona all'interno di un'altra area riduce il numero di operatori che possono accedervi aumentando al contempo i diritti assegnati a ciascun operatore.

Le aree devono essere definite durante la configurazione del server, nel file serverConf.xml . Tutti i parametri disponibili in serverConf.xml sono elencati in questa sezione.

Ogni area definisce i diritti, ad esempio:

  • Connessione HTTP anziché HTTPS
  • Visualizzazione degli errori (errori Java, JavaScript, C++, ecc.)
  • Report e anteprima webApp
  • Autenticazione tramite login/password
  • Modalità di connessione non sicura
Nota

Ogni operatore deve essere collegato a una zona. Se l'indirizzo IP dell'operatore appartiene all'intervallo definito dalla zona, l'operatore può accedere all'istanza.
L'indirizzo IP dell'operatore può essere definito in più zone. In questo caso, l'operatore riceve l' insieme di diritti disponibili per ogni area.

Il file serverConf.xml out-of-the-box include tre aree: public, VPN e LAN.

Nota

La configurazione out-of-the-box è sicura. Tuttavia, prima di eseguire la migrazione da una versione precedente di Adobe Campaign, potrebbe essere necessario ridurre temporaneamente la sicurezza per migrare e approvare le nuove regole.

Esempio di come definire una zona nel file 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>

Tutti i diritti che definiscono una zona sono i seguenti:

  • allowDebug: consente l'esecuzione di un'app Web in modalità "debug"
  • allowEmptyPassword: autorizza una connessione a un'istanza senza una password
  • allowHTTP: è possibile creare una sessione senza utilizzare il protocollo HTTPS
  • allowUserPassword: il token di sessione può avere il seguente modulo "<login>/<password>"
  • sessionTokenOnly: il token di protezione non è richiesto nell'URL di connessione
  • showErrors: gli errori sul lato server vengono inoltrati e visualizzati
IMPORTANTE

Nella definizione di un'area, ogni attributo con il valore true riduce la protezione.

Quando si utilizza Centro messaggi, se sono presenti più istanze di esecuzione, è necessario creare un'area di protezione aggiuntiva con l'attributo sessionTokenOnly definito come true, in cui devono essere aggiunti solo gli indirizzi IP necessari. Per ulteriori informazioni sulla configurazione delle istanze, consultare questo documento.

Best practice per le zone di sicurezza

Nella definizione della zona di sicurezza del piano , è possibile aggiungere una maschera di indirizzo IP che definisca l'accesso tecnico. Questo componente aggiuntivo consente l'accesso a tutte le istanze ospitate sul server.

<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>

È consigliabile definire gli intervalli di indirizzi IP direttamente nel file di configurazione dedicato all'istanza per gli operatori che accedono solo a un'istanza specifica.

Nel config-<instance>.xml file:

  <securityZone name="public">
   ...
    <securityZone name="vpn">
      <subNetwork id="cus1" mask="a.b.c.d/xx"/>

Reti secondarie e proxy in una zona di sicurezza

Il parametro proxy può essere utilizzato in un elemento subNetwork per specificare l'uso del proxy in una zona di sicurezza.

Quando si fa riferimento a un proxy e una connessione entra tramite questo proxy (visibile tramite l'intestazione HTTP X-Forwarded-For), la zona verificata è quella dei client del proxy e non quella del proxy.

IMPORTANTE

Se un proxy è configurato e può essere ignorato (o se non esiste), l'indirizzo IP che verrà testato sarà in grado di essere falsificato.

Inoltre, i relè ora vengono generati come proxy. È quindi possibile aggiungere l'indirizzo IP 127.0.0.1 all'elenco dei proxy nella configurazione della zona di sicurezza.

Ad esempio: " <subnetwork label="Lan 1" mask="192.168.0.0/16" name="lan1" proxy="127.0.0.1,10.100.2.135" />".

Possono verificarsi diversi casi:

  • Nella zona di protezione viene fatto riferimento direttamente a una sub-rete e non è configurato alcun proxy: gli utenti della rete secondaria possono connettersi direttamente al server Adobe Campaign .

  • È specificato un proxy per una rete secondaria nella zona di sicurezza: gli utenti di questa sub-rete possono accedere al server Adobe Campaign tramite questo proxy.

  • Un proxy è incluso in una rete secondaria della zona di sicurezza: gli utenti che hanno accesso tramite questo proxy, indipendentemente dalla loro origine, possono accedere al server Adobe Campaign .

Gli indirizzi IP dei proxy che possono accedere al server Adobe Campaign devono essere inseriti sia nella <subnetwork> relativa rete secondaria che nella sottorete di primo livello <subnetwork name="all"/>. Ad esempio, qui per un proxy il cui indirizzo IP è 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>

Collegamento di un’area di sicurezza a un operatore

Una volta definite le zone, ogni operatore deve essere collegato a uno di essi per poter accedere a un'istanza e l'indirizzo IP dell'operatore deve essere incluso negli indirizzi o nell'intervallo di indirizzi a cui si fa riferimento nella zona.

La configurazione tecnica delle zone viene eseguita nel file di configurazione del server Campaign: serverConf.xml.

Prima di questo, è necessario iniziare configurando l' Security zone enumerazione out-of-the-box per collegare un'etichetta al nome interno della zona definita nel file serverConf.xml .

Questa configurazione viene effettuata in Campaign Explorer:

  1. Fare clic sul Administration > Platform > Enumerations nodo.

  2. Selezionare l'enumerazione del Security zone (securityZone) sistema.

  3. Per ogni area di protezione definita nel file di configurazione del server, fare clic sul Add pulsante.

  4. Nel Internal name campo, immettere il nome della zona definita nel file serverConf.xml . Corrisponde all'attributo @name dell' <securityzone> elemento. Immettere l'etichetta collegata al nome interno nel campo ​Etichetta.

  5. Fate clic su OK e salvate le modifiche.

Una volta definite le zone e configurata l' Security zone enumerazione, è necessario collegare ogni operatore a un'area di protezione:

  1. Fare clic sul Administration > Access management > Operators nodo.

  2. Selezionare l'operatore a cui si desidera collegare un'area di protezione e fare clic sulla Edit scheda.

  3. Vai alla Access rights scheda e fai clic sul Edit access parameters… collegamento.

  4. Selezionare una zona dall'elenco a Authorized connection zone discesa

  5. Fate clic su OK e salvate le modifiche per applicare le modifiche.

Configurazione di Tomcat

Porta predefinita per Tomcat

Quando la porta di ascolto 8080 del server Tomcat è già occupata con un'altra applicazione necessaria per la configurazione, è necessario sostituire la porta 8080 con una gratuita (ad esempio 8090). Per modificarlo, modificate il file server.xml salvato nella directory /tomcat-8/conf della cartella di installazione di Adobe Campaign .

Quindi modificate la porta delle pagine dei relè JSP. A questo scopo, modificate il file serverConf.xml salvato nella directory /conf della directory di installazione di Adobe Campaign . Tutti i parametri disponibili in serverConf.xml sono elencati in questa sezione.

<serverConf>
   ...
   <web controlPort="8005" httpPort="8090"...
   <url ... targetUrl="http://localhost:8090"...

Mapping di una cartella in Tomcat

Per definire le impostazioni specifiche per il cliente, potete creare un file user_contexts.xml nella cartella /tomcat-8/conf , che contiene anche il file contexts.xml .

Questo file conterrà il seguente tipo di informazioni:

 <Context path='/foo' docBase='../customers/foo'   crossContext='true' debug='0' reloadable='true' trusted='false'/>

Se necessario, questa operazione può essere riprodotta sul lato server.

Personalizzazione dei parametri di consegna

I parametri di consegna sono definiti nel file di configurazione serverConf.xml . Tutti i parametri disponibili in serverConf.xml sono elencati in questa sezione.

La configurazione e i comandi generali del server sono descritti in dettaglio nella configurazione del serverCampaign.

Potete anche eseguire le seguenti configurazioni in base alle vostre esigenze e impostazioni.

Relè SMTP

Il modulo MTA agisce come agente nativo di trasferimento della posta per la trasmissione SMTP (porta 25).

È tuttavia possibile sostituirlo con un server di inoltro se richiesto dal criterio di protezione. In tal caso, il throughput globale sarà quello relay (a condizione che il throughput del server relay sia inferiore a quello dell'Adobe Campaign ).

In questo caso, questi parametri vengono impostati configurando il server SMTP nella <relay> sezione. È necessario specificare l'indirizzo IP (o l'host) del server SMTP utilizzato per trasferire la posta e la porta associata (per impostazione predefinita, 25).

<relay address="192.0.0.3" port="25"/>
IMPORTANTE

Questa modalità operativa comporta gravi limitazioni per le consegne, in quanto può ridurre notevolmente il throughput a causa delle prestazioni intrinseche del server relay (latenza, banner…). Inoltre, la capacità di qualificare gli errori di consegna sincroni (rilevati analizzando il traffico SMTP) sarà limitata e l'invio non sarà possibile se il server relay non è disponibile.

Processi figlio MTA

È possibile controllare la popolazione di processi secondari (maxSpareServers per impostazione predefinita 2) al fine di ottimizzare le prestazioni di trasmissione in base alla potenza della CPU dei server e alle risorse di rete disponibili. Questa configurazione deve essere realizzata nella <master> sezione della configurazione MTA su ogni singolo computer.

<master dataBasePoolPeriodSec="30" dataBaseRetryDelaySec="60" maxSpareServers="2" minSpareServers="0" startSpareServers="0">

Consultare anche Ottimizzazione dell’invio pere-mail.

Gestione del traffico SMTP in uscita con affinità

IMPORTANTE

La configurazione di affinità deve essere coerente da un server all'altro. È consigliabile contattare Adobe per la configurazione dell'affinità, in quanto le modifiche alla configurazione dovrebbero essere replicate su tutti i server applicazioni che eseguono l'MTA.

È possibile migliorare il traffico SMTP in uscita tramite affinità con indirizzi IP.

A questo scopo, eseguire i seguenti passaggi:

  1. Immettete le affinità nella <ipaffinity> sezione del file serverConf.xml .

    Un'affinità può avere diversi nomi diversi: per separarli, utilizzare il ; carattere.

    Esempio:

     IPAffinity name="mid.Server;WWserver;local.Server">
              <IP address="XX.XXX.XX.XX" heloHost="myserver.us.campaign.net" publicId="123" excludeDomains="neo.*" weight="5"/
    

    Per visualizzare i parametri pertinenti, fare riferimento al file serverConf.xml .

  2. Per abilitare la selezione di affinità negli elenchi a discesa, è necessario aggiungere i nomi di affinità nell'enumerazione IPAffinity .

    Nota

    Le enumerazioni sono dettagliate in questo documento.

    Potete quindi selezionare l'affinità da utilizzare, come illustrato di seguito per le tipologie:

    Nota

    Puoi anche fare riferimento alla configurazione del server diconsegna.

Autorizzazioni URL

L’elenco predefinito di URL che possono essere richiamati tramite codici JavaScript (flussi di lavoro, ecc.) dalle istanze Campaign Classic è limitato. Si tratta di URL che consentono il corretto funzionamento delle istanze.

Per impostazione predefinita, le istanze non possono connettersi a URL esterni. Tuttavia, è possibile aggiungere alcuni URL esterni all’elenco degli URL autorizzati, in modo che l’istanza possa connettersi a tali URL. Questo consente di connettere le istanze Campaign a sistemi esterni, ad esempio server SFTP o siti Web, per abilitare il trasferimento di file e/o dati.

Una volta aggiunto l’URL, viene inserito un suo riferimento nel file di configurazione dell’istanza (serverConf.xml).

I metodi utilizzati per gestire le autorizzazioni URL dipendono dal modello di hosting:

  • Ibrido o locale: aggiungete gli URL da consentire nel file ​serverConf.xml. Informazioni dettagliate sono disponibili nella sezione seguente.
  • Ospitato: aggiungete gli URL per consentire l’accesso tramite l’ Pannello di controllo Campaign. Per ulteriori informazioni, consulta la documentazione dedicata.

Con i modelli di hosting ibridi e locali , l'amministratore deve fare riferimento a un nuovo urlPermission nel file serverConf.xml . Tutti i parametri disponibili in serverConf.xml sono elencati in questa sezione.

Esistono tre modalità di protezione della connessione:

  • Blocco: tutti gli URL che non appartengono al inserire nell'elenco Consentiti vengono bloccati, con un messaggio di errore. Questa è la modalità predefinita dopo un post aggiornamento.
  • Autorizzazione: tutti gli URL che non appartengono al inserire nell'elenco Consentiti sono consentiti.
  • Avviso: tutti gli URL che non appartengono al inserire nell'elenco Consentiti sono consentiti, ma l'interprete JS invia un avviso in modo che l'amministratore possa raccogliere tali URL. Questa modalità aggiunge i messaggi di avviso 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>
IMPORTANTE

Per impostazione predefinita, il client dei nuovi clienti utilizza la modalità di blocco. Se devono consentire un nuovo URL, devono contattare l'amministratore per aggiungerlo al inserire nell'elenco Consentiti .

I clienti esistenti che provengono da una migrazione possono utilizzare la modalità di avviso per un certo periodo di tempo. Nel frattempo, devono analizzare il traffico in uscita prima di autorizzare gli URL. Una volta definito l’elenco degli URL autorizzati, questi devono contattare l’amministratore per aggiungere gli URL al inserire nell'elenco Consentiti e attivare la modalità di blocco.

Sicurezza e relè delle pagine dinamiche

Per impostazione predefinita, tutte le pagine dinamiche sono automaticamente correlate al server Tomcat locale del computer il cui modulo Web è stato avviato. Questa configurazione viene immessa nella <url> sezione della configurazione relay della query per il file ServerConf.xml . Tutti i parametri disponibili in serverConf.xml sono elencati in questa sezione.

Per trasmettere l'esecuzione della pagina dinamica su un server remoto ; se il modulo Web non è attivato sul computer. A tal fine, è necessario sostituire il localhost con il nome del computer remoto per JSP e JSSP, applicazioni Web, rapporti e stringhe.

Per ulteriori informazioni sui vari parametri disponibili, fare riferimento al file di configurazione serverConf.xml .

Per le pagine JSP, la configurazione predefinita è:

<url relayHost="true" relayPath="true" targetUrl="http://localhost:8080" urlPath="*.jsp"/>

Adobe Campaign utilizza le seguenti pagine JSP:

  • /nl/jsp/soaprouter.jsp: connessioni console client e servizi Web (API SOAP),
  • /nl/jsp/m.jsp: pagine mirror,
  • /nl/jsp/access.jsp: accesso basato su Web ai rapporti e alla distribuzione della console client,
  • /nl/jsp/s.jsp : Utilizzo del marketing virale (sponsorizzazione e social network).

Gli JSSP utilizzati per il canale app mobile sono i seguenti:

  • nms/mobile/1/registerIOS.jssp
  • nms/mobile/1/registerAndroid.jssp

Esempio:

È possibile impedire le connessioni dei computer client dall'esterno. A tal fine, è sufficiente limitare l'esecuzione di soaprouter.jsp e autorizzare solo l'esecuzione di pagine mirror, link virali, moduli Web e risorse pubbliche.

I parametri sono i seguenti:

<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"/>

In questo esempio, il <IP_addresses> valore coincide con l'elenco di indirizzi IP (separati da virgole) autorizzati a utilizzare il modulo relè per questa maschera.

Nota

I valori devono essere adattati in base alla configurazione e ai vincoli di rete, specialmente se sono state sviluppate configurazioni specifiche per l'installazione.

Limitazione dei comandi esterni autorizzati

Nota

La seguente configurazione è necessaria solo per le installazioni aziendali interne.

Dalla build 8780, gli amministratori tecnici possono limitare l'elenco dei comandi esterni autorizzati utilizzabili in Adobe Campaign.

A tal fine, è necessario creare un file di testo con l'elenco dei comandi che si desidera impedire l'utilizzo, ad esempio:

ln
dd
openssl
curl
wget
python
python3
perl
ruby
sh
IMPORTANTE

Questo elenco non è esaustivo.

Nel nodo exec del file di configurazione del server, è necessario fare riferimento al file creato in precedenza nell'attributo blacklistFile .

Solo per Linux: nel file di configurazione del server, si consiglia di specificare un utente dedicato all'esecuzione di comandi esterni per migliorare la configurazione di protezione. Questo utente è impostato nel nodo exec del file di configurazione. Tutti i parametri disponibili in serverConf.xml sono elencati in questa sezione.

Nota

Se non viene specificato alcun utente, tutti i comandi vengono eseguiti nel contesto utente dell'istanza Adobe Campaign . L'utente deve essere diverso dall'utente che esegue Adobe Campaign.

Ad esempio:

<serverConf>
 <exec user="theUnixUser" blacklistFile="/pathtothefile/blacklist"/>
</serverConf>

Questo utente deve essere aggiunto all'elenco secondario dell'operatore "neolane" Adobe Campaign.

IMPORTANTE

Non utilizzare un sudo personalizzato. Nel sistema deve essere installato un sudo standard.

Gestione delle intestazioni HTTP

Per impostazione predefinita, tutte le intestazioni HTTP non vengono trasmesse. È possibile aggiungere intestazioni specifiche nelle risposte inviate per inoltro. Per eseguire questa operazione:

  1. Andate al file serverConf.xml . Tutti i parametri disponibili in serverConf.xml sono elencati in questa sezione.

  2. Nel <relay> nodo, passare all'elenco delle intestazioni HTTP inoltrate.

  3. Aggiungete un <responseheader> elemento con i seguenti attributi:

    • name: nome intestazione
    • value: value name.

    Ad esempio:

    <responseHeader name="Strict-Transport-Security" value="max-age=16070400; includeSubDomains"/>
    

Tracciamento ridondante

Quando più server vengono utilizzati per il reindirizzamento, devono essere in grado di comunicare tra loro tramite chiamate SOAP per condividere informazioni dagli URL da reindirizzare. al momento dell'avvio della consegna, è possibile che non tutti i server di reindirizzamento siano disponibili; pertanto potrebbero non avere lo stesso livello di informazioni.

Nota

Quando si utilizza l'architettura standard o aziendale, il server applicazione principale deve essere autorizzato a caricare le informazioni di tracciamento su ogni computer.

Gli URL dei server ridondanti devono essere specificati nella configurazione di reindirizzamento tramite il file serverConf.xml . Tutti i parametri disponibili in serverConf.xml sono elencati in questa sezione.

Esempio:

<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 proprietà enableIf è facoltativa (vuota per impostazione predefinita) e consente di abilitare la connessione solo se il risultato è vero; Questo consente di ottenere una configurazione identica su tutti i server di reindirizzamento.

Per ottenere il nome host del computer, eseguire il comando seguente: hostname -s.

Gestione delle risorse pubbliche

Le risorse pubbliche sono presentate in Gestione delle risorsepubbliche.

Sono memorizzati nella directory /var/res/instance della directory di installazione di Adobe Campaign .

L’URL corrispondente è: http://server/res/instance dove istanza è il nome dell’istanza di tracciamento.

È possibile specificare un'altra directory aggiungendo un nodo al file conf-<instance>.xml per configurare la memorizzazione sul server. Questo significa aggiungere le seguenti righe:

<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>

In questo caso, il nuovo URL per le risorse pubbliche fornito nella parte superiore della finestra della procedura guidata di distribuzione dovrebbe puntare a questa cartella.

Flussi di lavoro e affinità ad alta disponibilità

Potete configurare diversi server di workflow (wfserver) e distribuirli su due o più computer. Se scegliete questo tipo di architettura, configurate la modalità di connessione dei bilanciatori di carico in base all'accesso Adobe Campaign.

Per accedere dal Web, selezionate la modalità di bilanciamento del carico per limitare i tempi di connessione.

Se accedete tramite la console Adobe Campaign, scegliete hash o ip . Questo consente di mantenere la connessione tra il client avanzato e il server e impedire che una sessione utente venga interrotta durante un'operazione di importazione o esportazione, ad esempio.

Potete scegliere di imporre l'esecuzione di un flusso di lavoro o di un'attività di workflow su un computer specifico. A tal fine, è necessario definire una o più affinità per il flusso di lavoro o l'attività interessati.

  1. Create le affinità del flusso di lavoro o dell'attività immettendole nel Affinity campo.

    Potete scegliere liberamente i nomi di affinità. Tuttavia, accertarsi di non utilizzare spazi o segni di punteggiatura. Se utilizzate server diversi, specificate nomi diversi.

    L'elenco a discesa contiene le affinità precedentemente utilizzate. Viene completato nel tempo con i diversi valori inseriti.

  2. Aprite il file nl6/conf/config-<instance>.xml .

  3. Modificate la linea che corrisponde al wfserver modulo come segue:

    <wfserver autoStart="true" affinity="XXX,"/>
    

    Se si definiscono più affinità, queste devono essere separate da virgole senza spazi:

    <wfserver autoStart="true" affinity="XXX,YYY,"/>
    

    La virgola che segue il nome dell'affinità è necessaria per l'esecuzione di flussi di lavoro per i quali non è definita alcuna affinità.

    Se desiderate eseguire solo flussi di lavoro per i quali è definita un'affinità, non aggiungete una virgola alla fine dell'elenco delle affinità. Ad esempio, modificare la linea come segue:

    <wfserver autoStart="true" affinity="XXX"/>
    

Riavvio automatico del processo

Per impostazione predefinita, i diversi processi Adobe Campaign si riavviano automaticamente alle 6 del mattino (ora del server) ogni giorno.

Tuttavia, potete modificare questa configurazione.

A questo scopo, andate al file serverConf.xml , che si trova nell'archivio conf dell'installazione. Tutti i parametri disponibili in serverConf.xml sono elencati in questa sezione.

Ogni processo configurato in questo file ha un attributo processRestartTime . Potete modificare il valore di questo attributo per adattare il tempo di riavvio di ogni processo in base alle vostre esigenze.

IMPORTANTE

Non eliminare questo attributo. Tutti i processi devono essere riavviati ogni giorno.

Limitazione dei file caricati

Un nuovo attributo uploadWhiteList consente di limitare i tipi di file disponibili per il caricamento sul server Adobe Campaign .

Questo attributo è disponibile nell'elemento dataStore del file serverConf.xml . Tutti i parametri disponibili in serverConf.xml sono elencati in questa sezione.

Il valore predefinito di questo attributo è .+ e consente di caricare qualsiasi tipo di file.

Per limitare i possibili formati, è necessario sostituire il valore dell'attributo con un'espressione regolare Java valida. È possibile immettere diversi valori separandoli con una virgola.

Ad esempio: uploadWhiteList="..png,..jpg" consente di caricare i formati PNG e JPG sul server. Non verranno accettati altri formati.

IMPORTANTE

In Internet Explorer, il percorso completo del file deve essere verificato dall'espressione regolare.

Configurazione connessione proxy

Se devi collegare il server Campaign all'esterno tramite un proxy (ad esempio, utilizzando un'attività del flusso di lavoro di trasferimento file), devi configurare la sezione proxyConfig del serverConf tramite un comando. Sono possibili le seguenti connessioni proxy: HTTP, HTTPS, FTP, SFTP. Tutti i parametri disponibili in serverConf.xml sono elencati in questa sezione.

Nota

A partire dalla versione 20.2, i parametri del protocollo HTTP e HTTPS non sono più disponibili. Le seguenti informazioni fanno ancora riferimento a questi parametri, poiché rimangono disponibili per le build precedenti, incluso 9032.

I proxy SOCKS non sono supportati.

Usa il comando seguente:

nlserver config -setproxy:[protocol]/[serverIP]:[port]/[login][:‘https’|'http’]

i parametri del protocollo possono essere "http", "https" o "ftp".

Se imposti FTP sulla stessa porta del traffico HTTP/HTTPS, puoi usare quanto segue:

nlserver config -setproxy:http/198.51.100.0:8080/user

Le opzioni "http" e "https" vengono utilizzate solo quando il parametro del protocollo è "ftp" e indicano se il tunneling sulla porta specificata verrà eseguito attraverso HTTPS o attraverso HTTP.

Se utilizzate porte diverse per il traffico FTP/SFTP e HTTP/HTTPS attraverso il server proxy, dovete impostare il parametro del protocollo ‘ftp’.

Ad esempio:

nlserver config -setproxy:ftp/198.51.100.0:8080/user:’http’

Quindi immettete la password.

Le connessioni HTTP sono definite nel parametro proxyHTTP:

<proxyConfig enabled=“1” override=“localhost*” useSingleProxy=“0”>
<proxyHTTP address=“198.51.100.0" login=“user” password=“*******” port=“8080”/>
</proxyConfig>

Le connessioni HTTPS sono definite nel parametro proxyHTTPS:

<proxyConfig enabled=“1" override=“localhost*” useSingleProxy=“0">
<proxyHTTPS address=“198.51.100.0” login=“user” password=“******” port=“8080"/>
</proxyConfig>

Le connessioni FTP/FTPS sono definite nel parametro proxyFTP:

<proxyConfig enabled=“1" override=“localhost*” useSingleProxy=“0">
<proxyFTP address=“198.51.100.0” login=“user” password=“******” port=“5555" https=”true”/>
</proxyConfig>

Se si utilizza lo stesso proxy per diversi tipi di connessione, verrà definito solo il proxyHTTP con useSingleProxy impostato su "1" o "true".

Se disponete di connessioni interne che dovrebbero passare attraverso il proxy, aggiungetele nel parametro override.

Se desiderate disattivare temporaneamente la connessione proxy, impostate il parametro enabled su "false" o "0".

In questa pagina