Show Menu
TEMAS×

Configuración general

Esta sección detalla la configuración que se realizará en Adobe Campaign v7 si va a realizar la migración desde una versión 5.11 o v6.02.
Además:
  • Si migra desde la versión 5.11, también debe completar la configuración detallada en la sección Configuraciones específicas de la versión 5.11 .
  • Si migra desde v6.02, también debe completar la configuración detallada en la sección Configuraciones específicas de v6.02 .

Husos horarios

Modo de zona horaria múltiple

En la versión 6.02, el modo "zona multihora" solo estaba disponible para los motores de base de datos PostgreSQL. Ahora se ofrece sin importar el tipo de motor de base de datos que se utilice. Le recomendamos encarecidamente que transforme su base en una base "multizona horaria".
Para utilizar el modo TIMESTAMP WITH TIMEZONE, también debe agregar la opción -userTimestamptz:1 a la línea de comandos posterior a la actualización.
Si se utiliza el parámetro -usetimestamptz:1 con un motor de base de datos incompatible, la base de datos estará dañada y tendrá que restaurar una copia de seguridad de la base de datos y volver a ejecutar el comando anterior.
Es posible modificar la zona horaria después de la migración a través de la consola ( Administration > Platform > Options > WdbcTimeZone nodo).
For more on time zone management, refer to this section .

Oracle

Si recibe un error ORA 01805 durante la postactualización, significa que los archivos de zona horaria de Oracle entre el servidor de aplicaciones y el servidor de base de datos no están sincronizados. Para volver a sincronizarlos, siga los pasos siguientes:
  1. Para identificar el archivo de zona horaria utilizado, ejecute el siguiente comando:
    select * from v$timezone_file
    
    
    Los archivos de zona horaria generalmente se encuentran en la carpeta ORACLE_HOME/oracore/zoneinfo/ .
  2. Asegúrese de que los archivos de zona horaria son idénticos en ambos servidores.
Un desajuste del huso horario entre el cliente y el servidor también puede provocar algunos retrasos. Por este motivo, recomendamos utilizar la misma versión de la biblioteca Oracle en el lado del cliente y del servidor; ambos husos horarios deben ser los mismos.
Para comprobar si ambos lados están en los mismos husos horarios:
  1. Compruebe la versión del archivo de zona horaria en el lado del cliente ejecutando el siguiente comando:
    genezi -v
    
    
    genezi es un binario encontrado en el repositorio $ORACLE_HOME/bin .
  2. Compruebe la versión del archivo de zona horaria en el servidor ejecutando el siguiente comando:
    select * from v$timezone_file
    
    
  3. Para cambiar el archivo de zona horaria en el lado del cliente, utilice la variable de entorno ORA_TZFILE .

Seguridad

Zonas de seguridad

Por motivos de seguridad, la plataforma Adobe Campaign ya no es accesible de forma predeterminada: debe configurar las zonas de seguridad y, por lo tanto, recopilar las direcciones IP del operador.
Adobe Campaign v7 incluye el concepto de zonas de seguridad. Cada usuario debe estar asociado con una zona para iniciar sesión en una instancia y la dirección IP del usuario debe incluirse en las direcciones o intervalos de direcciones definidos en la zona de seguridad. La configuración de las zonas de seguridad se puede realizar en el archivo de configuración del servidor de Adobe Campaign. La zona de seguridad a la que está asociado un usuario debe definirse en la consola ( Administration > Access management > Operators ).
Antes de la migración , pida al administrador de red que le ayude a definir las zonas de seguridad que se activarán después de la migración.
Después de la posactualización (antes de reiniciar el servidor), debe configurar las zonas de seguridad.
La configuración de la zona de seguridad se encuentra en esta sección .

Contraseñas de usuario

En v7, la conexión de operador interno y de administrador debe estar protegida con una contraseña. Se recomienda encarecidamente asignar contraseñas a estas cuentas y a todas las cuentas de operador antes de la migración . Si no ha especificado una contraseña para interno , no podrá conectarse. Para asignar una contraseña a interno , escriba el siguiente comando:
nlserver config -internalpassword

La contraseña interna debe ser idéntica para todos los servidores de seguimiento. Para obtener más información, consulte esta sección y esta sección .

Nuevas funciones de v7

  • Los usuarios sin permisos ya no pueden conectarse a Adobe Campaign. Sus permisos deben agregarse manualmente, por ejemplo, creando un permiso denominado connect .
    Los usuarios afectados por esta modificación se identifican y se enumeran durante la posactualización.
  • El seguimiento ya no funciona si la contraseña está vacía. Si este es el caso, un mensaje de error le informará y le pedirá que lo vuelva a configurar.
  • Las contraseñas de los usuarios ya no se almacenan en el esquema xtk:sessionInfo .
  • Los permisos de administración ahora son necesarios para utilizar las funciones xtk:builder:EvaluateJavaScript y xtk:builder:EvaluateJavaScriptTemplate .
Algunos esquemas listos para usar se han modificado y ahora solo se puede acceder a ellos de forma predeterminada con acceso de escritura para los operadores con permiso de administración :
  • ncm:publicación
  • nl:supervisión
  • nms:calendar
  • xtk:builder
  • xtk:conexiones
  • xtk:dbInit
  • xtk:entityBackupNew
  • xtk:entityBackupOriginal
  • xtk:entityOriginal
  • xtk:form
  • xtk:funcList
  • xtk:fusion
  • xtk:image
  • xtk:javascript
  • xtk:jssp
  • xtk:jst
  • xtk:navtree
  • xtk:operatorGroup
  • xtk:package
  • xtk:queryDef
  • xtk:resourceMenu
  • xtk:rights
  • xtk:esquema
  • xtk:scriptContext
  • xtk:especificaciónFile
  • xtk:sql
  • xtk:sqlSchema
  • xtk:srcSchema
  • xtk:cadenas
  • xtk:xslt

Parámetro Sessiontoken

En la versión 5, el parámetro sessiontoken funcionaba en ambos lados del cliente (lista de pantallas de tipo de información general, editor de vínculos, etc.) y del servidor (aplicaciones web, informes, jsp, jssp, etc.). En v7, solo funciona en el servidor. Si desea volver a la funcionalidad completa como en la versión 5, debe modificar los vínculos usando este parámetro y pasar a través de la página de conexión:
Ejemplo de vínculo:
/view/recipientOverview?__sessiontoken=<trusted login>

Nuevo vínculo mediante la página de conexión:
/nl/jsp/logon.jsp?login=<trusted login>&action=submit&target=/view/recipientOverview

Si utiliza un operador vinculado con una máscara IP de confianza, compruebe que tiene los derechos mínimos y que está en una zona de seguridad en el modo sessionTokenOnly .

Funciones SQL

Las llamadas a funciones SQL desconocidas ya no se envían de forma natural al servidor. Actualmente, todas las funciones SQL deben agregarse al esquema xtk:funcList (para obtener más información sobre esto, consulte esta sección ). Al migrar, se agrega una opción durante la postactualización que permite mantener la compatibilidad con las antiguas funciones SQL no declaradas. Si desea seguir utilizando estas funciones, compruebe que la opción XtkPassUnknownSQLFunctionsToRDBMS está definida en el nivel de Administration > Platform > Options nodo.
Recomendamos encarecidamente no utilizar esta opción debido a los riesgos de seguridad que presenta.

JSSP

Si desea autorizar el acceso a determinadas páginas mediante el protocolo HTTP (no HTTPS), en las aplicaciones web, por ejemplo, independientemente de la configuración realizada en las zonas de seguridad, debe especificar el parámetro httpAllowed="true" en la regla de retransmisión correspondiente.
Si utiliza JSSP anónimos, debe agregar el parámetro httpAllowed="true" en una regla de retransmisión para el JSSP ( serverConf.xml archivo):
Por ejemplo:
<url IPMask="" deny="" hostMask="" httpAllowed="true" relayHost="true" relayPath="true"
           status="blacklist" targetUrl="https://localhost:8080" timeout="" urlPath="*/cus/myPublicPage.jssp"/>

Sintaxis

JavaScript

Adobe Campaign v7 integra un intérprete de JavaScript más reciente. Sin embargo, esta actualización puede dar lugar a que ciertas secuencias de comandos no funcionen correctamente. Como el motor anterior era más permisivo, ciertas sintaxis funcionarían, lo que ya no es el caso con la nueva versión del motor.
La myObject.@attribute sintaxis solo es válida para objetos XML. Esta sintaxis se puede utilizar para personalizar envíos y gestoras de contenido. Si ha utilizado este tipo de sintaxis en un objeto que no es XML, las funciones de personalización ya no funcionarán.
Para todos los demás tipos de objetos, la sintaxis es ahora myObject [ "attribute" ] . Por ejemplo, un objeto que no es XML que utiliza la sintaxis siguiente: employee.@sn , ahora debe utilizar la siguiente sintaxis: employee [ "sn" ] .
  • Sintaxis anterior:
    employee.@sn
    
    
  • Nueva sintaxis:
    employee["sn"]
    
    
Para cambiar un valor en un objeto XML, ahora es necesario realizar un inicio actualizando el valor antes de agregar el nodo XML:
  • Código JavaScript antiguo:
    var cellStyle = node.style.copy();
    this.styles.appendChild(cellStyle);
    cellStyle.@width = column.@width;
    
    
  • Nuevo código JavaScript:
    var cellStyle = node.style.copy();
    cellStyle.@width = column.@width;
    this.styles.appendChild(cellStyle);
    
    
Ya no puede utilizar un atributo XML como clave de tabla.
  • Sintaxis anterior:
    if(serverForm.activities[ctx.activityHistory.activity[0].@name].type !="end")
    
    
  • Nueva sintaxis:
    if(serverForm.activities[String(ctx.activityHistory.activity[0].@name)].type !="end"
    
    

SQLData

Para reforzar la seguridad de la instancia, se ha introducido una nueva sintaxis en Adobe Campaign v7 para reemplazar la sintaxis basada en SQLData. Si utiliza estos elementos de código con esta sintaxis, deberá modificarlos. Los principales elementos en cuestión son:
  • Filtrado por subconsulta: la nueva sintaxis se basa en el <subQuery> elemento para definir una subconsulta
  • Agregados: la nueva sintaxis es "acumulada function(collection)"
  • Filtrado por unión: la nueva sintaxis es [schemaName:alias:xPath]
Se ha modificado el esquema queryDef (xtk:queryDef):
  • hay un nuevo <subQuery> elemento disponible para reemplazar el SELECT incluido en SQLData
  • se han introducido dos nuevos valores, "IN" y "NOT IN" para el atributo @setOperator
  • un nuevo <where> elemento, que es un elemento secundario del <node> elemento: esto le permite realizar "subselecciones" en SELECT
Cuando se utiliza un atributo "@expr", puede que SQLData esté presente. Se puede realizar una búsqueda de los siguientes términos: "SQLData", "aliasSqlTable", "sql".
Las instancias de Adobe Campaign v7 están seguras de forma predeterminada. La seguridad viene en términos de definiciones de zonas de seguridad en el serverConf.xml archivo: el atributo allowSQLInjection administra la seguridad de la sintaxis SQL.
Si se produce un error SQLData durante la ejecución posterior a la actualización, debe modificar este atributo para permitir temporalmente el uso de sintaxis basada en SQLData, permitiéndole reescribir el código. Para ello, se debe cambiar la siguiente opción en el archivo serverConf.xml :
allowSQLInjection="true"

Por lo tanto, vuelva a iniciar la posactualización con el siguiente comando:
nlserver config -postupgrade -instance:<instance_name> -force

Debe configurar las zonas de seguridad (consulte Seguridad ) y luego reactivar la seguridad cambiando la opción:
allowSQLInjection="false"

A continuación encontrará ejemplos comparativos entre la sintaxis antigua y la nueva.
Filtrado por subconsultas
  • Sintaxis anterior:
    <condition expr="@id NOT IN ([SQLDATA[SELECT iOperatorId FROM XtkOperatorGroup WHERE iGroupId = $(../@owner-id)]])" enabledIf="$(/ignored/@ownerType)=1"/>
    
    
  • Nueva sintaxis:
    <condition setOperator="NOT IN" expr="@id" enabledIf="$(/ignored/@ownerType)=1">
      <subQuery schema="xtk:operatorGroup">
         <select>
           <node expr="[@operator-id]" />
         </select>
         <where>
           <condition expr="[@group-id]=$long(../@owner-id)"/>
         </where>
       </subQuery>
    </condition>
    
    
  • Sintaxis anterior:
    <queryFilter name="dupEmail" label="Emails duplicated in the folder" schema="nms:recipient">
        <where>
          <condition sql="sEmail in (select sEmail from nmsRecipient where iFolderId=$(folderId) group by sEmail having count(sEmail)>1)" internalId="1"/>
        </where>
        <folder _operation="none" name="nmsSegment"/>
      </queryFilter>
    
    
  • Nueva sintaxis:
    <queryFilter name="dupEmail" label=" Emails duplicated in the folder " schema="nms:recipient">
        <where>
          <condition expr="@email" setOperator="IN" internalId="1">
            <subQuery schema="nms:recipient">
              <select><node expr="@email"/></select>
              <where><condition expr="[@folder-id]=$(folderId)"/></where>
              <groupBy><node expr="@email"/></groupBy>
              <having><condition expr="count(@email)>1"/></having>
            </subQuery>
          </condition>
        </where>
        <folder _operation="none" name="nmsSegment"/>
      </queryFilter>
    
    
El acumulado
Función acumulada (colección)
  • Sintaxis anterior:
    <node sql="(select count(*) from NmsNewsgroup WHERE O0.iOperationId=iOperationId)" alias="@nbMessages"/>
    
    
  • Nueva sintaxis:
    <node expr="count([newsgroup/@id])" alias="../@nbMessages"/>
    
    
    Las uniones se realizan automáticamente para las funciones acumuladas. Ya no es necesario especificar la condición WHERE O0.iOperationId=iOperationId.
    Ya no es posible utilizar la función "count(*)". Debe usar "counheight()".
  • Sintaxis anterior:
    <node sql="(select Sum(iToDeliver) from NmsDelivery WHERE O0.iOperationId=iOperationId AND iSandboxMode=0 AND iState>=45)" alias="@nbMessages"/>
    
    
  • Nueva sintaxis:
    <node expr="Sum([delivery-linkedDelivery/properties/@toDeliver])" alias= "../@sumToDeliver">
                      <where><condition expr="[validation/@sandboxMode]=0 AND @state>=45" /></where></node>
    
    
Filtros por uniones
[schemaName:alias:xPath]
El alias es opcional
  • Sintaxis anterior:
    <condition expr={"[" + joinPart.destination.nodePath + "] = [SQLDATA[W." + joinPart.source.SQLName + "]]"}
                                             aliasSqlTable={nodeSchemaRoot.SQLTable + " W"}/>
    
    
  • Nueva sintaxis:
    <condition expr={"[" + joinPart.destination.nodePath + "] = [" + nodeSchema.id + ":" + joinPart.source.nodePath + "]]"}/>
    
    
Sugerencias y trucos
En un <subQuery> elemento, para hacer referencia a un campo "field" del <queryDef> elemento principal, utilice la sintaxis siguiente: [../@field]
Ejemplo:
<queryDef operation="select" schema="xtk:jobLog" startPath="/" xtkschema="xtk:queryDef">
  <select>
    <node expr="[job/@pid]" alias="@pid"/>
    <node expr="@id" ordered="true"/>
    <node expr="@logType"/>
  </select>
  <where>
    <condition expr="[@job-id]=99"/>
    <condition expr="@logType" setOperator="IN">
      <subQuery schema="xtk:jobLog">
        <select><node expr="@logType"/></select>
        <where><condition expr="[@job-id]=[../job/@id]"/></where>
        <groupBy><node expr="@logType"/></groupBy>
        <having><condition expr="count(@logType)>1"/></having>
      </subQuery>
    </condition>
  </where>
</queryDef>

Conflictos

La migración se realiza a través de una actualización posterior y pueden aparecer conflictos en informes, formularios o aplicaciones Web. Estos conflictos se pueden resolver desde la consola.
Después de la sincronización de recursos, el comando postupgrade permite detectar si la sincronización genera errores o advertencias.

Vista del resultado de sincronización

El resultado de la sincronización se puede ver de dos maneras:
  • En la interfaz de la línea de comandos, los errores se materializan con un triple elemento >>> y la sincronización se detiene automáticamente. Las advertencias son materializadas por un doble chevron >> y deben resolverse una vez finalizada la sincronización. Al final de la posactualización, se muestra un resumen en el símbolo del sistema. Por ejemplo:
    2013-04-09 07:48:39.749Z        00002E7A          1     info    log     =========Summary of the update==========
    2013-04-09 07:48:39.749Z        00002E7A          1     info    log     test instance, 6 warning(s) and 0 error(s) during the update.
    2013-04-09 07:48:39.749Z        00002E7A          1     warning log     The document with identifier 'mobileAppDeliveryFeedback' and type 'xtk:report' is in conflict with the new version.
    2013-04-09 07:48:39.749Z        00002E7A          1     warning log     The document with identifier 'opensByUserAgent' and type 'xtk:report' is in conflict with the new version.
    2013-04-09 07:48:39.750Z        00002E7A          1     warning log     The document with identifier 'deliveryValidation' and type 'nms:webApp' is in conflict with the new version.
    2013-04-09 07:48:39.750Z        00002E7A          1     warning log     Document of identifier 'nms:includeView' and type 'xtk:srcSchema' updated in the database and found in the file system. You will have to merge the two versions manually.
    
    
    Si la advertencia se refiere a un conflicto de recursos, se requiere la atención del operador para resolverlo.
  • El archivo post-upgrade_ <server version number> _time de post-upgrade > .log contiene el resultado de la sincronización. Está disponible de forma predeterminada en el siguiente directorio: directorio de instalación/var/ <instance> postupgrade . Los errores y las advertencias se indican mediante los atributos de error y advertencia .

Resolver un conflicto

La resolución de conflictos solo debe ser realizada por operadores avanzados y aquellos a los que se les hayan otorgado derechos de administrador.
Para resolver un conflicto, aplique el siguiente proceso:
  1. En la estructura de árbol de Adobe Campaign, coloque el cursor sobre Administration > Configuration > Package management > Edit conflicts .
  2. Seleccione el conflicto que desea resolver en la lista.
Existen tres maneras posibles de resolver un conflicto:
  • Declared as resolved :: requiere la intervención previa del operador.
  • Accept the new version :: recomendado si el usuario no ha cambiado los recursos proporcionados con Adobe Campaign.
  • Keep the current version :: significa que se rechaza la actualización.
    Si selecciona este modo de resolución, corre el riesgo de perder parches en la nueva versión. Por lo tanto, se recomienda encarecidamente que esta opción no se utilice ni se reserve únicamente a los operadores expertos.
Si decide resolver manualmente el conflicto, siga este procedimiento:
  1. En la sección inferior de la ventana, busque las entidades _conflict_ string con conflictos. La entidad instalada con la nueva versión contiene el nuevo argumento; la entidad que coincide con la versión anterior contiene el argumento cus .
  2. Elimine la versión que no desee conservar. Elimine el valor _conflict_argument_ string de la entidad que mantiene.
  3. Ve al conflicto que habrías resuelto. Click the Actions icon and select Declare as resolved .
  4. Guarde los cambios: el conflicto ya está resuelto.

Tomcat

El servidor Tomcat integrado en Adobe Campaign v7 ha cambiado de versión (Tomcat 7). Su carpeta de instalación (tomcat-6) también ha cambiado (tomcat 7). Después de la actualización, asegúrese de comprobar que las rutas sí se vinculan a la carpeta actualizada (en el serverConf.xml archivo):
$(XTK_INSTALL_DIR)/tomcat-7/bin/bootstrap.jar 
$(XTK_INSTALL_DIR)/tomcat-7/bin/tomcat-juli.jar
$(XTK_INSTALL_DIR)/tomcat-7/lib/tomcat-util.jar
$(XTK_INSTALL_DIR)/tomcat-7/lib/tomcat-api.jar
$(XTK_INSTALL_DIR)/tomcat-7/lib/servlet-api.jar
$(XTK_INSTALL_DIR)/tomcat-7/lib/jsp-api.jar
$(XTK_INSTALL_DIR)/tomcat-7/lib/el-api.jar

Interacción

Requisitos previos

Antes de la posactualización , debe eliminar todas las referencias de esquema de 6.02 que ya no existan en v7.
  • nms:emailOfferView
  • nms:webOfferView
  • nms:callCenterOfferView
  • nms:mobileOfferView
  • nms:paperOfferView

Oferta de contenido

En v7, el contenido de la oferta se ha movido. En la versión 6.02, el contenido estaba en cada esquema de representación ( nms:emailOfferView ). En v7, el contenido ahora está en el esquema de oferta. Después de la actualización, el contenido no será visible en la interfaz. Después de la actualización, debe volver a crear el contenido de la oferta o desarrollar una secuencia de comandos que mueva automáticamente el contenido del esquema de representación al esquema de oferta.
Si algunos envíos que utilizan ofertas configuradas se enviarán después de la migración, debe eliminar y volver a crear todos estos envíos en v7. Si no puede hacerlo, se ofrece un "modo de compatibilidad". Este modo no se recomienda porque no se beneficiará de todas las nuevas funciones de Interacción v7. Este es un modo de transición que le permite completar campañas continuas antes de la migración real de 6.1. Para más información sobre este modo, por favor contacte con nosotros.
Hay un ejemplo de un script de movimiento ( interactiveTo610_full_XX.js ) disponible en la carpeta Migración de la carpeta Adobe Campaign v7. Este archivo muestra un ejemplo de una secuencia de comandos para un cliente que utiliza una sola representación por correo electrónico por oferta (los htmlSource campos y textSource ). El contenido que estaba en la tabla NmsEmailOfferView se ha movido a la tabla de oferta.
El uso de esta secuencia de comandos no le permite beneficiarse de las opciones "gestor de contenido" y "funciones de representación". Para beneficiarse de estas funciones, debe reconsiderar las ofertas del catálogo, especialmente el contenido de la oferta y los espacios de configuración.
loadLibrary("/nl/core/shared/nl.js");

NL.require("/nl/core/shared/xtk.js");

// 1. Restore old emailOfferView schema
logInfo("Restoring old emailOfferView schema");
var oldOfferViewSchemas = <entities schema="xtk:srcSchema"/>;

oldOfferViewSchemas.appendChild(
  <srcSchema img="nms:offerView.png"
             label="Email offer representations"
             labelSingular="Email offer representation"
             name="emailOfferView" namespace="nlmig"
             genAccessors="false" implements="xtk:persist">
    <element name="emailOfferView" template="nms:offerView" sqltable="NmsEmailOfferView">
      <element name="offer" revLabel="Email representation" revIntegrity="owncopy"/>
      <element   name="htmlSource"      type="html" label="HTML content"  xml="true"/>
      <element   name="textSource"      type="CDATA" label="Text content" xml="true"/>
      <element   name="htmlSource_jst"  type="CDATA" label="HTML script"  desc="HTML content calculation script."  xml="true" advanced="true"/>
      <element   name="textSource_jst"  type="CDATA" label="Text script" desc="Text content calculation script." xml="true" advanced="true"/>
    </element>
  </srcSchema>);

var oldOfferViewsPkg = <builder><package buildNumber="*">{oldOfferViewSchemas}</package></builder>;
xtk.builder.InstallPackage(oldOfferViewsPkg);

// 2. Migrate data from old emailOfferView table to nms:offer
logInfo("Moving data from old EmailOfferView table to NmsOffer");
var OFFER_STATUS_VALIDATED = 3;

var queryDef = xtk.queryDef.create(
  <queryDef operation="select" schema="nlmig:emailOfferView">
    <select>
      <node expr="[@offer-id]"/>
      <node expr="[@space-id]"/>
      <node expr="htmlSource_jst"/>
      <node expr="textSource_jst"/>
    </select>
  </queryDef>);
var res = queryDef.ExecuteQuery();

var processedOffers = {};
for each( var emailOfferView in res.emailOfferView )
{
  if( processedOffers[String(emailOfferView.@["offer-id"])] != undefined )
  {
    logWarning("Found 2 or more eff fffffmail representations for offer " + String(emailOfferView.@["offer-id"]) + ". Only keep the first one here.");
    continue;
  }
  xtk.session.Write(
    <offer id={emailOfferView.@["offer-id"]} status={OFFER_STATUS_VALIDATED} xtkschema="nms:offer">
      <view>
        {emailOfferView.mdSource_jst}
        {emailOfferView.textSource_jst}
      </view>
    </offer>
  );
  processedOffers[String(emailOfferView.@["offer-id"])] = 1;
}

// 3. Get rid of emailOfferView schema now that data has been moved.
logInfo("Deleting EmailOfferView schema");
xtk.session.Write(<srcSchema xtkschema="xtk:srcSchema" name="emailOfferView" namespace="nlmig" _operation="delete"/>);

logInfo("Done");

Pruebas y configuración

Este es el procedimiento a seguir después de mover el contenido de la oferta si solo tiene un entorno. En este caso tomemos "ENV" como ejemplo.
  1. En todos los espacios de ofertas de entorno "ENV", actualice la lista de los campos utilizados. Por ejemplo, para un espacio de ofertas que solo utiliza el htmlSource , debe agregar el view/htmlSource .
  2. En el Type of Environment campo de la General ficha, seleccione Live .
  3. Cree un entorno de diseño ("ENV_DESIGN", por ejemplo) y conéctelo al entorno en línea ENV.
  4. Implemente todos los espacios de ofertas de entorno "ENV" (haga clic con el botón derecho > Actions > Deploy ) y seleccione el entorno "ENV_DESIGN".
  5. Haga lo mismo con todas las ofertas de entorno "ENV".
  6. Active todas las ofertas de entorno "ENV_DESIGN" en los canales relevantes.
  7. Prueba para hacer que una oferta entre en funcionamiento. Si no encuentra ningún problema, ejecute tareas pendientes en la última tarea de flujo de trabajo Offer notification (offerMgt) para que todas las ofertas se activen.
  8. Realice pruebas exhaustivas.
    Los nombres de las categorías y ofertas en línea se modifican después de activarse. En el canal entrante, actualice todas las referencias a ofertas y categorías.

Informes

Informes estándar

Todos los informes estándar utilizan actualmente el motor de procesamiento v6.x. Si agregó JavaScript a estos informes, es posible que algunos elementos ya no funcionen. De hecho, la versión antigua de JavaScript no es compatible con el motor de procesamiento v6.x. Por lo tanto, debe comprobar el código JavaScript y luego adaptarlo. Debe probar cada informe, en particular la función de exportación.

Informes personalizados

Si desea que la pancarta azul de la versión 7 (que le permita acceder a los universos), debe volver a publicar los informes. Si tiene problemas, puede forzar el motor de procesamiento v6.0. Para ello, vaya a Properties dentro del informe, haga clic en Rendering y elija el motor Version 6.0 (Flash & OpenOffice) de procesamiento.
Si desea beneficiarse de las nuevas funcionalidades del informe, debe seleccionar el motor de procesamiento v.6.x. En este caso, compruebe todos los scripts y cámbielos si es necesario. En cuanto a la exportación a PDF, si ha agregado una secuencia de comandos específica para OpenOffice, ya no funcionará con el nuevo motor de exportación a PDF (PhantomJS).

Aplicaciones web

Existen dos familias de aplicaciones web:
  • aplicaciones web identificadas (vistas juntas, formularios de aprobación, desarrollos internos de extranet),
  • aplicaciones web anónimas (formularios web o de cuestionario).

Aplicaciones web identificadas

Al igual que para los informes (consulte Informes ), si ha agregado JavaScript, debe comprobar y adaptar si es necesario. Si desea beneficiarse de la pancarta azul v7 (que contiene los universos), debe volver a publicar la aplicación web. Si el código JavaScript funciona, puede seleccionar el motor de procesamiento v6.x. Si no es así, puede utilizar el motor de procesamiento v6.0 mientras adapta el código y, a continuación, utilizar el motor de procesamiento v6.x.
Los pasos para seleccionar el motor de procesamiento son los mismos que para seleccionar informes. Consulte Informes personalizados .
Los métodos de conexión de aplicación web han cambiado en v7. Si encuentra algún problema de conexión en las aplicaciones web identificadas, debe activar temporalmente las opciones allowUserPassword y sessionTokenOnly en el archivo serverConf.xml . Después de la actualización, modifique los siguientes valores de opción:
allowUserPassword="true"

sessionTokenOnly="true"

Por lo tanto, vuelva a iniciar la posactualización con el siguiente comando:
nlserver config -postupgrade -instance:<instance_name> -force

Pruebe las aplicaciones web en el motor de procesamiento v6.x antes de publicarlas. A continuación, desactive estas dos opciones.
allowUserPassword="false"

sessionTokenOnly="false"

Aplicaciones web anónimas

Si tiene algún problema, vuelva a publicar la aplicación web. Si el problema persiste, puede seleccionar el motor de procesamiento v6.0. Si no ha agregado JavaScript, puede seleccionar el motor de procesamiento v6.x y beneficiarse de sus nuevas funciones.
Los pasos para seleccionar el motor de procesamiento son los mismos que para seleccionar informes. Consulte Informes personalizados .

Red-Hat

Si los esquemas listos para usar se han eliminado en la versión 6.02 o 5.11, es posible que ya no pueda editar sus esquemas después de la actualización. Si esto sucede, ejecute el comando:
su - neolane
nlserver config -postupgrade -instance:<instance name> -force