Show Menu
TEMAS×

Configuración del servidor de Campaña

La sección siguiente detalla las configuraciones del lado del servidor que se pueden realizar para satisfacer sus necesidades y las características específicas de su entorno.
Estas configuraciones deben ser realizadas únicamente por administradores y para modelos de alojamiento in situ .
En implementaciones alojadas , solo Adobe puede configurar la configuración del lado del servidor. Sin embargo, algunos ajustes se pueden configurar dentro del Panel de control (por ejemplo, la lista blanca de IP o los permisos de URL).
Para obtener más información, consulte estas secciones:
Los archivos de configuración de Campaign Classic se almacenan en la carpeta conf de la carpeta de instalación de Adobe Campaign. La configuración se distribuye en dos archivos:
  • serverConf.xml : configuración general para todas las instancias. Este archivo combina los parámetros técnicos del servidor de Adobe Campaign: todas las instancias las comparten. La descripción de algunos de estos parámetros se detalla a continuación. Los diferentes nodos y parámetros que se enumeran en esta sección .
  • config- <instance> .xml (donde instancia es el nombre de la instancia): configuración específica de la instancia. Si comparte el servidor entre varias instancias, introduzca los parámetros específicos de cada instancia en el archivo correspondiente.

Definición de zonas de seguridad

Acerca de las zonas de seguridad

Cada operador debe estar vinculado a una zona para iniciar sesión en una instancia y la IP del operador debe incluirse en las direcciones o conjuntos de direcciones definidos en la zona de seguridad. La configuración de la zona de seguridad se realiza en el archivo de configuración del servidor de Adobe Campaign.
Los operadores están vinculados a una zona de seguridad desde su perfil en la consola ( Administration > Access management > Operators nodo). Descubra cómo vincular las zonas a los operadores de Campaña en esta sección .

Creación de zonas de seguridad

Una zona está definida por:
  • uno o más intervalos de direcciones IP (IPv4 e IPv6)
  • un nombre técnico vinculado a cada rango de direcciones IP
Las zonas de seguridad están interbloqueadas, lo que significa que la definición de una nueva zona dentro de otra zona reduce el número de operadores que pueden iniciar sesión en ella mientras aumentan los derechos asignados a cada operador.
Las zonas deben definirse durante la configuración del servidor, en el archivo serverConf.xml . Todos los parámetros disponibles en serverConf.xml se enumeran en esta sección .
Cada zona define derechos, como:
  • Conexión HTTP en lugar de HTTPS
  • Visualización de errores (errores de Java, JavaScript, C++, etc.)
  • previsualización de informes y aplicaciones web
  • Autenticación mediante inicio de sesión y contraseña
  • Modo de conexión no segura
Cada operador debe estar vinculado a una zona . Si la dirección IP del operador pertenece al rango definido por la zona, el operador puede iniciar sesión en la instancia. La dirección IP del operador puede definirse en varias zonas. En este caso, el operador recibe el conjunto de derechos disponibles para cada zona.
El archivo serverConf.xml integrado incluye tres zonas: pública, VPN y LAN .
La configuración predeterminada es segura . Sin embargo, antes de migrar desde una versión anterior de Adobe Campaign, puede que sea necesario reducir temporalmente la seguridad para migrar y aprobar las nuevas reglas.
Ejemplo de cómo definir una zona en el archivo 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>

Todos los derechos que definen una zona son los siguientes:
  • allowDebug : habilita la ejecución de una aplicación web en modo "debug"
  • allowEmptyPassword : autoriza una conexión a una instancia sin contraseña
  • allowHTTP : se puede crear una sesión sin utilizar el protocolo HTTPS
  • allowUserPassword : el token de sesión puede tener el siguiente formulario " <login>/<password> "
  • sessionTokenOnly : no se requiere el token de seguridad en la dirección URL de conexión
  • showErrors : los errores del lado del servidor se reenvían y muestran
En una definición de zona, cada atributo con el valor true reduce la seguridad.
Al utilizar el Centro de mensajes, si hay varias instancias de ejecución, debe crear una zona de seguridad adicional con el atributo sessionTokenOnly definido como true , donde solo se añadirán las direcciones IP necesarias. Para obtener más información sobre la configuración de instancias, consulte este documento .

Prácticas recomendadas para zonas de seguridad

En la definición de la zona de seguridad de lan , es posible agregar una máscara de dirección IP que defina el acceso técnico. Este complemento habilitará el acceso a todas las instancias alojadas en el servidor.
<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>

Se recomienda definir los intervalos de direcciones IP directamente en el archivo de configuración dedicado a la instancia para los operadores que acceden únicamente a una instancia específica.
En el config-<instance>.xml archivo:
  <securityZone name="public">
   ...
    <securityZone name="vpn">
      <subNetwork id="cus1" mask="a.b.c.d/xx"/>

Subredes y proxies en una zona de seguridad

El parámetro proxy se puede usar en un elemento subNetwork para especificar el uso proxy en una zona de seguridad.
Cuando se hace referencia a un proxy y se introduce una conexión mediante este proxy (visible mediante el encabezado HTTP X-Forwarded-For), la zona verificada es la de los clientes del proxy y no la del proxy.
Si se configura un proxy y es posible ignorarlo (o si no existe), la dirección IP que se probará será falsificada.
Además, los relés ahora se generan como proxies. Por lo tanto, puede agregar la dirección IP 127.0.0.1 a la lista de proxies en la configuración de la zona de seguridad.
Por ejemplo: " <subnetwork label="Lan 1" mask="192.168.0.0/16" name="lan1" proxy="127.0.0.1,10.100.2.135" /> ".
Pueden producirse varios casos:
  • En la zona de seguridad se hace referencia directa a una subred y no se configura ningún proxy: los usuarios de la subred pueden conectarse directamente al servidor de Adobe Campaign.
  • Se ha especificado un proxy para una subred en la zona de seguridad: los usuarios de esta subred pueden acceder al servidor de Adobe Campaign a través de este proxy.
  • Un proxy se incluye en una subred de zona de seguridad: los usuarios que tengan acceso a través de este proxy, independientemente de su origen, pueden acceder al servidor de Adobe Campaign.
Las direcciones IP de los proxies que probablemente accedan al servidor de Adobe Campaign deben introducirse tanto en la subred de nivel <subnetwork> afectado como en la de primer nivel <subnetwork name="all"/> . Por ejemplo, aquí para un proxy cuya dirección IP es 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>

Vinculación de una zona de seguridad a un operador

Una vez definidas las zonas, cada operador debe estar vinculado a uno de ellos para poder iniciar sesión en una instancia y la dirección IP del operador debe incluirse en las direcciones o el rango de direcciones a las que se hace referencia en la zona.
La configuración técnica de las zonas se realiza en el fichero de configuración del servidor de Campaña: serverConf.xml .
Antes de esto, debe realizar el inicio configurando la lista desglosada predeterminada Security zone para vincular una etiqueta al nombre interno de la zona definida en el archivo serverConf.xml .
Esta configuración se realiza en el explorador de Campañas:
  1. Haga clic en el Administration > Platform > Enumerations nodo.
  2. Seleccione la lista desglosada del Security zone (securityZone) sistema.
  3. Para cada zona de seguridad definida en el archivo de configuración del servidor, haga clic en el Add botón .
  4. En el Internal name campo, introduzca el nombre de la zona definida en el archivo serverConf.xml . Corresponde al atributo @name del <securityzone> elemento. Introduzca la etiqueta vinculada al nombre interno en el campo ​de trabajo.
  5. Haga clic en Aceptar y guarde las modificaciones.
Una vez definidas las zonas y configurada la Security zone lista desglosada, deberá vincular cada operador a una zona de seguridad:
  1. Haga clic en el Administration > Access management > Operators nodo.
  2. Seleccione el operador al que desea vincular una zona de seguridad y haga clic en la Edit ficha.
  3. Vaya a la Access rights ficha y haga clic en el Edit access parameters... vínculo.
  4. Seleccione una zona en la lista Authorized connection zone desplegable
  5. Haga clic en OK y guarde las modificaciones para aplicar estos cambios.

Configuración de Tomcat

Puerto predeterminado para Tomcat

Cuando el puerto de escucha 8080 del servidor Tomcat ya está ocupado con otra aplicación necesaria para la configuración, debe reemplazar el puerto 8080 por uno gratuito (por ejemplo, 8090). Para cambiarlo, edite el archivo server.xml guardado en el directorio /tomcat-7/conf de la carpeta de instalación de Adobe Campaign.
A continuación, modifique el puerto de las páginas de retransmisión JSP. Para ello, cambie el archivo serverConf.xml guardado en el directorio /conf del directorio de instalación de Adobe Campaign. Todos los parámetros disponibles en serverConf.xml se enumeran en esta sección .
<serverConf>
   ...
   <web controlPort="8005" httpPort="8090"...
   <url ... targetUrl="http://localhost:8090"...

Asignación de una carpeta en Tomcat

Para definir la configuración específica del cliente, puede crear un archivo user_contextos.xml en la carpeta /tomcat-7/conf , que también contiene el archivo contextos.xml .
Este archivo contendrá el siguiente tipo de información:
 <Context path='/foo' docBase='../customers/foo'   crossContext='true' debug='0' reloadable='true' trusted='false'/>

Si es necesario, esta operación se puede reproducir en el servidor.

Personalización de los parámetros de envío

Los parámetros de envío se definen en el archivo de configuración serverConf.xml . Todos los parámetros disponibles en serverConf.xml se enumeran en esta sección .
Los comandos y la configuración general del servidor se detallan en la configuración del servidor de Campaña.
También puede realizar las siguientes configuraciones en función de sus necesidades y configuración.

Relé SMTP

El módulo MTA actúa como agente de transferencia de correo nativo para la retransmisión SMTP (puerto 25).
Sin embargo, es posible reemplazarlo por un servidor de retransmisión si su política de seguridad lo requiere. En ese caso, el rendimiento global será el de transmisión (siempre que el rendimiento del servidor de transmisión sea inferior al del Adobe Campaign).
En este caso, estos parámetros se establecen configurando el servidor SMTP en la <relay> sección . Debe especificar la dirección IP (o el host) del servidor SMTP utilizado para transferir el correo y su puerto asociado (25 de forma predeterminada).
<relay address="192.0.0.3" port="25"/>

Este modo operativo implica serias limitaciones en los envíos, ya que puede reducir considerablemente el rendimiento debido a las prestaciones intrínsecas del servidor de transmisión (latencia, ancho de banda...). Además, la capacidad para calificar los errores de envío sincrónicos (detectados mediante el análisis del tráfico SMTP) será limitada y el envío no será posible si el servidor de retransmisión no está disponible.

Procesos secundarios de MTA

Es posible controlar la población de procesos secundarios (maxSpareServers de forma predeterminada 2) para optimizar el rendimiento de difusión según la potencia de CPU de los servidores y los recursos de red disponibles. Esta configuración se debe realizar en la <master> sección de configuración de MTA de cada equipo individual.
<master dataBasePoolPeriodSec="30" dataBaseRetryDelaySec="60" maxSpareServers="2" minSpareServers="0" startSpareServers="0">

Consulte también la optimización del envío de correo electrónico .

Administración del tráfico SMTP saliente con afinidades

La configuración de la afinidad debe ser coherente de un servidor a otro. Le recomendamos que se ponga en contacto con Adobe para la configuración de afinidad, ya que los cambios de configuración deben replicarse en todos los servidores de aplicaciones que ejecutan MTA.
Puede mejorar el tráfico SMTP saliente mediante afinidades con direcciones IP.
Para ello, siga los siguientes pasos:
  1. Introduzca las afinidades en la <ipaffinity> sección del archivo serverConf.xml .
    Una afinidad puede tener varios nombres diferentes: para separarlos, utilice el ; carácter.
    Ejemplo:
     IPAffinity name="mid.Server;WWserver;local.Server">
              <IP address="XX.XXX.XX.XX" heloHost="myserver.us.campaign.net" publicId="123" excludeDomains="neo.*" weight="5"/
    
    
    Para vista de los parámetros relevantes, consulte el archivo serverConf.xml .
  2. Para habilitar la selección de afinidades en las listas desplegables, debe agregar los nombres de afinidades en la lista desglosada IPAffinity .
    Las Listas desglosadas se detallan en este documento .
    A continuación, puede seleccionar la afinidad que se va a utilizar, como se muestra a continuación para las tipologías:
    También puede hacer referencia a la configuración del servidor de Envío.

Permisos de URL

La lista predeterminada de las direcciones URL a las que pueden llamar los códigos JavaScript (flujos de trabajo, etc.) las instancias de su Campaign Classic están limitadas. Son direcciones URL que permiten que las instancias funcionen correctamente.
De forma predeterminada, las instancias no pueden conectarse a direcciones URL externas. Sin embargo, es posible agregar algunas direcciones URL externas a la lista de direcciones URL autorizadas para que la instancia pueda conectarse a ellas. Esto le permite conectar las instancias de Campaña a sistemas externos como, por ejemplo, servidores SFTP o sitios web para habilitar la transferencia de datos o archivos.
Una vez que se agrega una URL, se hace referencia a ella en el archivo de configuración de la instancia (serverConf.xml).
La forma en que puede administrar los permisos de URL depende del modelo de alojamiento:
  • Híbrido o local : agregue las direcciones URL para permitir en el archivo serverConf.xml. La información detallada se encuentra disponible en la sección siguiente.
  • Alojado : agregue las direcciones URL para permitir mediante el Panel de control . For more information, refer to the dedicated documentation .
Con modelos de alojamiento híbridos y locales , el administrador debe hacer referencia a un nuevo urlPermission en el archivo serverConf.xml . Todos los parámetros disponibles en serverConf.xml se enumeran en esta sección .
Existen tres modos de protección de conexión:
  • Bloqueo : todas las direcciones URL que no pertenecen a la lista de direcciones permitidas se bloquean con un mensaje de error. Este es el modo predeterminado después de una actualización posterior.
  • Permiso : se permiten todas las direcciones URL que no pertenecen a la lista blanca.
  • Advertencia : se permiten todas las direcciones URL que no sean en blanco, pero el intérprete de JS emite una advertencia para que el administrador pueda recopilarlas. Este modo agrega mensajes de advertencia 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>

De forma predeterminada, el cliente de nuevos clientes utiliza el modo de bloqueo. Si necesitan permitir una nueva dirección URL, deben ponerse en contacto con el administrador para incluirla en la lista de direcciones permitidas.
Los clientes existentes procedentes de una migración pueden utilizar el modo de advertencia durante un tiempo. Mientras tanto, deben analizar el tráfico saliente antes de autorizar las direcciones URL. Una vez definida la lista de direcciones URL autorizadas, deben ponerse en contacto con el administrador para incluir en la lista blanca las direcciones URL y activar el modo de bloqueo.

Seguridad y relés de página dinámicos

De forma predeterminada, todas las páginas dinámicas se relacionan automáticamente con el servidor Tomcat local del equipo cuyo módulo Web se ha iniciado. Esta configuración se introduce en la <url> sección de la configuración del relé de consulta para el archivo ServerConf.xml . Todos los parámetros disponibles en serverConf.xml se enumeran en esta sección .
Retransmitir la ejecución de la página dinámica en un servidor remoto ; si el módulo Web no está activado en el equipo. Para ello, debe reemplazar el localhost por el nombre del equipo remoto para JSP y JSSP, Aplicaciones web, informes y cadenas.
Para obtener más información sobre los distintos parámetros disponibles, consulte el archivo de configuración serverConf.xml .
Para las páginas JSP, la configuración predeterminada es:
<url relayHost="true" relayPath="true" targetUrl="http://localhost:8080" urlPath="*.jsp"/>

Adobe Campaign utiliza las siguientes páginas JSP:
  • /nl/jsp/ soaprouter.jsp : conexiones de consola de cliente y servicios Web (API de SOAP),
  • /nl/jsp/ m.jsp : páginas espejo,
  • /nl/jsp/ Logon.jsp : Acceso basado en la Web a los informes y a la implementación de la consola del cliente,
  • /nl/jsp/ s.jsp : Usando mercadotecnia viral (patrocinio y redes sociales).
Los JSSP utilizados para el Canal de aplicaciones móviles son los siguientes:
  • nms/mobile/1/registerIOS.jssp
  • nms/mobile/1/registerAndroid.jssp
Ejemplo:
Es posible evitar las conexiones de equipos cliente desde el exterior. Para ello, simplemente restrinja la ejecución de soaprouter.jsp y autorice la ejecución de páginas espejo, enlaces virales, formularios web y recursos públicos.
Los parámetros son los siguientes:
<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"/>

En este ejemplo, el <IP_addresses> valor coincide con la lista de direcciones IP (separadas por comas) autorizadas para utilizar el módulo de relé para esta máscara.
Los valores se adaptarán según su configuración y sus limitaciones de red, especialmente si se han desarrollado configuraciones específicas para su instalación.

Restricción de comandos externos autorizados

La siguiente configuración sólo es necesaria para instalaciones in situ.
Desde la compilación 8780, los administradores técnicos pueden restringir la lista de comandos externos autorizados que se pueden utilizar en Adobe Campaign.
Para ello, debe crear un archivo de texto con la lista de comandos que desee evitar utilizar, por ejemplo:
ln
dd
openssl
curl
wget
python
python3
perl
ruby
sh

Esta lista no es exhaustiva.
En el nodo exec del archivo de configuración del servidor, debe hacer referencia al archivo creado anteriormente en el atributo blacklistFile .
Sólo para Linux: en el archivo de configuración del servidor, le recomendamos que especifique un usuario dedicado a ejecutar comandos externos para mejorar la configuración de seguridad. Este usuario se establece en el nodo exec del archivo de configuración. Todos los parámetros disponibles en serverConf.xml se enumeran en esta sección .
Si no se especifica ningún usuario, todos los comandos se ejecutan en el contexto de usuario de la instancia de Adobe Campaign. El usuario debe ser distinto del usuario que ejecuta Adobe Campaign.
Por ejemplo:
<serverConf>
 <exec user="theUnixUser" blacklistFile="/pathtothefile/blacklist"/>
</serverConf>

Este usuario debe agregarse a la lista de superusuario del operador de Adobe Campaign "neolano".
No debe usar un sudo personalizado. Es necesario instalar un sudo estándar en el sistema.

Administración de encabezados HTTP

De forma predeterminada, no se retransmiten todos los encabezados HTTP. Puede agregar encabezados específicos en las respuestas enviadas por retransmisión. Para ello:
  1. Vaya al archivo serverConf.xml . Todos los parámetros disponibles en serverConf.xml se enumeran en esta sección .
  2. En el <relay> nodo, vaya a la lista de encabezados HTTP reenviados.
  3. Añada un <responseheader> elemento con los atributos siguientes:
    • name : nombre del encabezado
    • value : nombre del valor.
    Por ejemplo:
    <responseHeader name="Strict-Transport-Security" value="max-age=16070400; includeSubDomains"/>
    
    

Seguimiento redundante

Cuando se utilizan varios servidores para la redirección, deben poder comunicarse entre sí a través de llamadas SOAP para compartir información de las direcciones URL que se van a redirigir. En el momento del inicio del envío, es posible que no todos los servidores de redirección estén disponibles; por lo tanto, es posible que no tengan el mismo nivel de información.
Cuando se utiliza la arquitectura estándar o empresarial, se debe autorizar al servidor de aplicaciones principal para que cargue información de seguimiento en cada equipo.
Las direcciones URL de los servidores redundantes deben especificarse en la configuración de redirección, a través del archivo serverConf.xml . Todos los parámetros disponibles en serverConf.xml se enumeran en esta sección .
Ejemplo:
<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 propiedad enableIf es opcional (está vacía de forma predeterminada) y permite habilitar la conexión solo si el resultado es true; Esto le permite obtener una configuración idéntica en todos los servidores de redirección.
Para obtener el nombre de host del equipo, ejecute el siguiente comando: hostname -s .

Administración de recursos públicos

Los Recursos públicos se presentan en Administración de recursos públicos .
Se almacenan en el directorio /var/res/instance del directorio de instalación de Adobe Campaign.
La dirección URL coincidente es: http://server/res/instance donde instancia es el nombre de la instancia de seguimiento.
Puede especificar otro directorio agregando un nodo al archivo conf- <instance> .xml para configurar el almacenamiento en el servidor. Esto significa agregar las siguientes líneas:
<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>

En este caso, la nueva dirección URL de los recursos públicos proporcionados en la parte superior de la ventana del asistente de implementación debe apuntar a esta carpeta.

flujos de trabajo y afinidades de alta disponibilidad

Puede configurar varios servidores de flujo de trabajo (wfserver) y distribuirlos en dos o más equipos. Si elige este tipo de arquitectura, configure el modo de conexión de los equilibradores de carga según el acceso de Adobe Campaign.
Para acceder desde la web, seleccione el modo de equilibrador de carga para limitar los tiempos de conexión.
Si accede a través de la consola de Adobe Campaign, elija el modo hash o fijo ip . Esto le permite mantener la conexión entre el cliente enriquecido y el servidor y evitar que una sesión de usuario se interrumpa durante una operación de importación o exportación, por ejemplo.
Puede elegir forzar la ejecución de un flujo de trabajo o una actividad de flujo de trabajo en un equipo concreto. Para ello, debe definir una o varias afinidades para el flujo de trabajo o la actividad correspondiente.
  1. Cree las afinidades del flujo de trabajo o la actividad introduciéndolas en el Affinity campo.
    Puede elegir libremente los nombres de las afinidades. Sin embargo, asegúrese de que no utiliza espacios ni signos de puntuación. Si utiliza diferentes servidores, especifique nombres diferentes.
    La lista desplegable contiene afinidades que antes se usaban. Se completa con el tiempo con los diferentes valores introducidos.
  2. Abra el archivo nl6/conf/config- <instance>.xml .
  3. Modifique la línea que coincide con el wfserver módulo de la siguiente manera:
    <wfserver autoStart="true" affinity="XXX,"/>
    
    
    Si define varias afinidades, deben separarse con comas sin espacios:
    <wfserver autoStart="true" affinity="XXX,YYY,"/>
    
    
    La coma que sigue al nombre de la afinidad es necesaria para la ejecución de flujos de trabajo para los que no se ha definido ninguna afinidad.
    Si desea ejecutar solo flujos de trabajo para los que se ha definido una afinidad, no agregue una coma al final de la lista de sus afinidades. Por ejemplo, modifique la línea de la siguiente manera:
    <wfserver autoStart="true" affinity="XXX"/>
    
    

Reinicio automático del proceso

De forma predeterminada, los diferentes procesos de Adobe Campaign se reinician automáticamente a las 6 de la mañana (hora del servidor) todos los días.
Sin embargo, puede cambiar esta configuración.
Para ello, vaya al archivo serverConf.xml , ubicado en el repositorio conf de su instalación. Todos los parámetros disponibles en serverConf.xml se enumeran en esta sección .
Cada proceso configurado en este archivo tiene un atributo processRestartTime . Puede modificar el valor de este atributo para adaptar el tiempo de reinicio de cada proceso según sus necesidades.
No elimine este atributo. Todos los procesos deben reiniciarse todos los días.

Limitación de archivos cargables

Un nuevo atributo uploadWhiteList permite restringir los tipos de archivo disponibles para la carga en el servidor de Adobe Campaign.
Este atributo está disponible en el elemento dataStore del archivo serverConf.xml . Todos los parámetros disponibles en serverConf.xml se enumeran en esta sección .
El valor predeterminado de este atributo es .+ y le permite cargar cualquier tipo de archivo.
Para limitar los posibles formatos, debe reemplazar el valor de atributo por una expresión regular de java válida. Puede introducir varios valores separándolos con una coma.
Por ejemplo: uploadWhiteList=". .png,. .jpg" le permitirá cargar formatos PNG y JPG en el servidor. No se aceptarán otros formatos.
En Internet Explorer, la ruta completa del archivo debe ser verificada por la expresión regular.

Configuración de conexión proxy

Si necesita conectar el servidor de Campaña al exterior mediante un proxy (por ejemplo, mediante una actividad de flujo de trabajo de transferencia de archivos), debe configurar la sección proxyConfig del serverConf mediante un comando. Las siguientes conexiones proxy son posibles: HTTP, HTTPS, FTP, SFTP. Todos los parámetros disponibles en serverConf.xml se enumeran en esta sección .
No se admiten los proxies SOCKS.
Utilice el siguiente comando:
nlserver config -setproxy:[protocol]/[serverIP]:[port]/[login][:‘https’|'http’]

los parámetros de protocolo pueden ser ‘http’, ‘https’ o ‘ftp’.
Si está configurando FTP en el mismo puerto que el tráfico HTTP/HTTPS, puede utilizar lo siguiente:
nlserver config -setproxy:http/198.51.100.0:8080/user

Las opciones ‘http’ y ‘https’ solo se utilizan cuando el parámetro de protocolo es ‘ftp’ e indican si la tunelización en el puerto especificado se realizará a través de HTTPS o HTTP.
Si utiliza diferentes puertos para el tráfico FTP/SFTP y HTTP/HTTPS a través del servidor proxy, debe establecer el parámetro de protocolo ‘ftp’.
Por ejemplo:
nlserver config -setproxy:ftp/198.51.100.0:8080/user:’http’

A continuación, introduzca la contraseña.
Las conexiones HTTP están definidas en el parámetro proxyHTTP:
<proxyConfig enabled=“1” override=“localhost*” useSingleProxy=“0”>
<proxyHTTP address=“198.51.100.0" login=“user” password=“*******” port=“8080”/>
</proxyConfig>

Las conexiones HTTPS se definen en el parámetro proxyHTTPS:
<proxyConfig enabled=“1" override=“localhost*” useSingleProxy=“0">
<proxyHTTPS address=“198.51.100.0” login=“user” password=“******” port=“8080"/>
</proxyConfig>

Las conexiones FTP/FTPS se definen en el parámetro proxyFTP:
<proxyConfig enabled=“1" override=“localhost*” useSingleProxy=“0">
<proxyFTP address=“198.51.100.0” login=“user” password=“******” port=“5555" https=”true”/>
</proxyConfig>

Si utiliza el mismo proxy para varios tipos de conexión, solo el proxyHTTP se definirá con useSingleProxy establecido en "1" o "true".
Si tiene conexiones internas que deben pasar por el proxy, agréguelas en el parámetro override.
Si desea deshabilitar temporalmente la conexión proxy, establezca el parámetro enabled en "false" o "0".