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.

Per ulteriori informazioni, consultare le sezioni seguenti:

• Documentazione del Pannello di controllo Campaign
• Modelli di hosting
• Matrice di funzionalità Campaign Classic locale e ospitata
• Passaggi di configurazione per modelli ibridi ed ospitati

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

Il file serverConf.xml predefinito include tre aree: public, VPN e LAN.

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

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, fare riferimento a questo documento.

Procedure ottimali per le aree di protezione

Nella definizione della zona di sicurezza lan, è possibile aggiungere una maschera 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 file config-<instance>.xml:

  <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'utilizzo 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.

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 immessi sia nella <subnetwork> in questione che nella rete secondaria 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'enumerazione Security zone 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 nodo Administration > Platform > Enumerations.

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

   

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

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

   

5. Fate clic su OK e salvate le modifiche.

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

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

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

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

   

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

   

5. Fare clic su OK e salvare 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 Adobe Campaign.

Quindi modificate la porta delle pagine dei relè JSP. A tal fine, 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 Configurazione del server delle campagne.

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 sezione <relay>. È 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"/>

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 effettuata nella sezione <master> della configurazione MTA su ogni singolo computer.

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

Fare riferimento anche a Ottimizzazione invio e-mail.

Gestione del traffico SMTP in uscita con affinità

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

A questo scopo, eseguire i seguenti passaggi:

1. Immettere le affinità nella sezione <ipaffinity> 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

   È inoltre possibile fare riferimento alla Configurazione server di consegna.

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:

• ​​Hybridor in sede: 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 Hybrid e On-premise, 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>

Sicurezza delle pagine dinamiche e relè

Per impostazione predefinita, tutte le pagine dinamiche sono automaticamente correlate al server locale Tomcat del computer il cui modulo Web è stato avviato. Questa configurazione viene immessa nella sezione <url> della configurazione del relay 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, collegamenti 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 valore <IP_addresses> coincide con l'elenco di indirizzi IP (separati da virgole) autorizzati a utilizzare il modulo relè per questa maschera.

Limitazione dei comandi esterni autorizzati

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

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.

Ad esempio:

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

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

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 nodo <relay>, andate all'elenco delle intestazioni HTTP inoltrate.

3. Aggiungete un elemento <responseheader> 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.

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: nomehost -s.

Gestione delle risorse pubbliche

Le risorse pubbliche sono presentate in Gestione delle risorse pubbliche.

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

L’URL corrispondente è: http://server/res/instance dove instance è 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à bilanciamento del carico per limitare i tempi di connessione.

Se accedete tramite la console Adobe Campaign, scegliete la modalità 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 campo Affinity.

   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. Modificare la riga che corrisponde al modulo wfserver 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 tal fine, 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.

Limitazione dei file caricabili

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

Questo attributo è disponibile all'interno dell'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.

Configurazione connessione proxy

Puoi collegare il server Campaign a un sistema esterno tramite un proxy, utilizzando ad esempio un'attività del flusso di lavoro Trasferimento file. A tal fine, è necessario configurare la sezione proxyConfig del file serverConf.xml tramite un comando specifico. Tutti i parametri disponibili in serverConf.xml sono elencati in questa sezione.

Sono possibili le seguenti connessioni proxy: HTTP, HTTPS, FTP, SFTP. A partire dalla release 20.2 Campaign, i parametri del protocollo HTTP e HTTPS non sono più disponibili. Tali parametri sono ancora indicati di seguito, in quanto rimangono disponibili nelle build precedenti - compreso 9032.

È possibile utilizzare 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".