Configurazioni generali

Questa sezione descrive la configurazione da eseguire in Adobe Campaign v7 se state eseguendo la migrazione da una v5.11 o una v6.02.

Inoltre:

• Se effettui la migrazione dalla v5.11, devi anche completare la configurazione dettagliata nelle configurazioni Specifiche nella sezione v5.11.
• Se effettui la migrazione dalla v6.02, devi anche completare la configurazione dettagliata nelle configurazioni Specifiche nella sezione v6.02.

Fusi orari

Modalità fuso orario multiplo

Nella release v6.02, la modalità "fuso orario multiplo" era disponibile solo per i motori di database PostSQL. Ora è disponibile indipendentemente dal tipo di motore di database utilizzato. Consigliamo vivamente di trasformare la base in una base "multi-timezone".

Per utilizzare la modalità TIMESTAMP WITH TIMEZONE, è inoltre necessario aggiungere l'opzione -userTimestamptz:1 alla riga di comando postupgrade.

Oracle

Se durante il post-aggiornamento viene visualizzato un errore ORA 01805, significa che i file del fuso orario Oracle tra il server dell'applicazione e il server del database non sono sincronizzati. Per sincronizzarli nuovamente, effettuate le seguenti operazioni:

1. Per identificare il file del fuso orario utilizzato, eseguire il comando seguente:

   select * from v$timezone_file
   

   I file del fuso orario si trovano in genere nella cartella ORACLE_HOME/oracore/zoneinfo/.

2. Verificate che i file del fuso orario siano identici su entrambi i server.

Per maggiori informazioni, visita: https://docs.oracle.com/cd/E11882_01/server.112/e10729/ch4datetime.htm#NLSPG004.

Un disallineamento del fuso orario tra client e server può anche causare dei ritardi. È per questo che consigliamo di utilizzare la stessa versione della libreria Oracle lato client e lato server, entrambi i fusi orari devono essere identici.

Per verificare se entrambi i lati si trovano negli stessi fusi orari:

1. Controllare la versione del file del fuso orario sul lato client eseguendo il comando seguente:

   genezi -v
   

   genezi è un file binario che si trova nel repository $ ORACLE_HOME/bin.

2. Controllare la versione del file del fuso orario sul lato server eseguendo il comando seguente:

   select * from v$timezone_file
   

3. Per modificare il file del fuso orario sul lato client, utilizzare la variabile di ambiente ORA_TZFILE.

Protezione

Zone di protezione

Adobe Campaign v7 prevede il concetto di zone di protezione. Ogni utente deve essere associato a una zona per accedere a un'istanza e l'indirizzo IP dell'utente deve essere incluso negli indirizzi o negli intervalli di indirizzi definiti nella zona di protezione. È possibile configurare le aree di protezione nel file di configurazione server Adobe Campaign. La zona di protezione a cui è associato un utente deve essere definita nella console (Administration > Access management > Operators).

Prima della migrazione, chiedi all’amministratore di rete di aiutarti a definire le zone di sicurezza da attivare dopo la migrazione.

Dopo l'aggiornamento successivo (prima del riavvio del server), è necessario configurare le aree di protezione.

La configurazione dell'area di sicurezza si trova in questa sezione.

Password utente

In v7, la connessione dell'operatore internal e admin deve essere protetta da una password. Si consiglia vivamente di assegnare password a questi account e a tutti gli account dell'operatore, prima della migrazione. Se non hai specificato una password per internal, non potrai più effettuare la connessione. Per assegnare una password a internal, immettere il comando seguente:

nlserver config -internalpassword

Nuove funzioni in v7

• Gli utenti senza autorizzazioni non possono più connettersi a Adobe Campaign. Le autorizzazioni devono essere aggiunte manualmente, ad esempio creando un'autorizzazione denominata connect.

  Gli utenti interessati da questa modifica vengono identificati ed elencati durante il post aggiornamento.

• Il tracciamento non funziona più se la password è vuota. In questo caso, un messaggio di errore vi consentirà di saperlo e vi chiederà di riconfigurarlo.

• Le password utente non sono più memorizzate nello schema xtk:sessionInfo.

• Le autorizzazioni di amministrazione sono ora necessarie per utilizzare le funzioni xtk:builder:ValuteJavaScript e xtk:builder:ValuteJavaScriptTemplate.

Alcuni schemi out-of-the-box sono stati modificati e ora sono accessibili solo per impostazione predefinita con accesso in scrittura per gli operatori con l'autorizzazione admin:

• ncm:pubblicare
• nl:monitoraggio
• nms:calendario
• xtk:builder
• xtk:connessioni
• xtk:dbInit
• xtk:entityBackupNew
• xtk:entityBackupOriginal
• xtk:entityOriginal
• xtk:form
• xtk:funcList
• xtk:fusione
• xtk:image
• xtk:javascript
• xtk:jssp
• xtk:jst
• xtk:navtree
• xtk:operatorGroup
• xtk:package
• xtk:queryDef
• xtk:resourceMenu
• xtk:rights
• xtk:schema
• xtk:scriptContext
• xtk:specFile
• xtk:sql
• xtk:sqlSchema
• xtk:srcSchema
• xtk:stringhe
• xtk:xslt

Parametro sessionToken

In v5, il parametro session token funzionava su entrambi i lati client (elenco di schermate tipo panoramica, editor collegamenti, ecc.) e lato server (applicazioni Web, rapporti, jsp, jssp, ecc.). In v7, funziona solo sul lato server. Se desiderate tornare alla funzionalità completa come in v5, dovete modificare i collegamenti utilizzando questo parametro e passare tramite la pagina di connessione:

Esempio di collegamento:

/view/recipientOverview?__sessiontoken=<trusted login>

Nuovo collegamento mediante la pagina di connessione:

/nl/jsp/logon.jsp?login=<trusted login>&action=submit&target=/view/recipientOverview

Funzioni SQL

Le chiamate di funzione SQL sconosciute non vengono più inviate naturalmente al server. Attualmente, tutte le funzioni SQL devono essere aggiunte allo schema xtk:funcList (per ulteriori informazioni, fare riferimento a questa sezione). Durante la migrazione, durante l'aggiornamento successivo viene aggiunta un'opzione che consente di mantenere la compatibilità con le vecchie funzioni SQL non dichiarate. Se si desidera continuare a utilizzare queste funzioni, verificare che l'opzione XtkPassUnknownSQLFunctionsToRDBMS sia effettivamente definita a livello di nodo Administration > Platform > Options.

JSSP

Se si desidera autorizzare l'accesso a determinate pagine tramite il protocollo HTTP (non HTTPS), ad esempio nelle app Web, indipendentemente dalla configurazione eseguita nelle aree di protezione, è necessario specificare il parametro httpAllowed="true" nella regola relay corrispondente.

Se utilizzate JSSP anonimi, dovete aggiungere il parametro httpAllowed="true" in una regola relay per il file JSSP (serverConf.xml):

Ad esempio:

<url IPMask="" deny="" hostMask="" httpAllowed="true" relayHost="true" relayPath="true"
           status="blacklist" targetUrl="https://localhost:8080" timeout="" urlPath="*/cus/myPublicPage.jssp"/>

Sintassi

JavaScript

Adobe Campaign v7 integra un interprete JavaScript più recente. Tuttavia, questo aggiornamento potrebbe causare il malfunzionamento di alcuni script. Poiché il motore precedente era più permissivo, alcune sintassi funzionerebbe, che non è più il caso con la nuova versione del motore.

La sintassi myObject.@attribute è ora valida solo per gli oggetti XML. Questa sintassi può essere utilizzata per personalizzare le consegne e la gestione dei contenuti. Se avete utilizzato questo tipo di sintassi su un oggetto non XML, le funzioni di personalizzazione non funzioneranno più.

Per tutti gli altri tipi di oggetto, la sintassi è ora myObject["attribute"]. Ad esempio, un oggetto non XML che utilizzava la sintassi seguente: employee.@sn, ora deve utilizzare la sintassi seguente: [!UICONTROL employee["sn"]].

• Sintassi precedente:

  employee.@sn
  

• Nuova sintassi:

  employee["sn"]
  

Per modificare un valore in un oggetto XML, è ora necessario iniziare aggiornando il valore prima di aggiungere il nodo XML:

• Codice JavaScript precedente:

  var cellStyle = node.style.copy();
  this.styles.appendChild(cellStyle);
  cellStyle.@width = column.@width;
  

• Nuovo codice JavaScript:

  var cellStyle = node.style.copy();
  cellStyle.@width = column.@width;
  this.styles.appendChild(cellStyle);
  

Non è più possibile utilizzare un attributo XML come chiave di tabella.

• Sintassi precedente:

  if(serverForm.activities[ctx.activityHistory.activity[0].@name].type !="end")
  

• Nuova sintassi:

  if(serverForm.activities[String(ctx.activityHistory.activity[0].@name)].type !="end"
  

SQLData

Per rafforzare la sicurezza dell’istanza, in Adobe Campaign v7 è stata introdotta una nuova sintassi che sostituisce la sintassi basata su SQLData. Se utilizzate questi elementi di codice con questa sintassi, dovete modificarli. I principali elementi in questione sono:

• Filtraggio per sottoquery: la nuova sintassi si basa sull'elemento <subQuery> per definire una sottoquery
• Aggregati: la nuova sintassi è "funzione di aggregazione(raccolta)"
• Filtraggio per join: la nuova sintassi è [schemaName:alias:xPath]

Lo schema queryDef (xtk:queryDef) è stato modificato:

• è disponibile un nuovo elemento <subQuery> per sostituire SELECT incluso in SQLData
• per l'attributo @setOperator vengono introdotti due nuovi valori, "IN" e "NOT IN"
• un nuovo elemento <where>, secondario dell'elemento <node>: questo consente di effettuare "sottoselezioni" in SELECT

Quando si utilizza un attributo "@expr", è possibile che sia presente SQLData. È possibile eseguire una ricerca per i seguenti termini: "SQLData", "aliasSqlTable", "sql".

le istanze di Adobe Campaign v7 sono protette per impostazione predefinita. La protezione viene fornita in termini di definizioni delle zone di protezione nel file serverConf.xml: l'attributo allowSQLInjection gestisce la protezione della sintassi SQL.

Se si verifica un errore SQLData durante l'esecuzione post-aggiornamento, è necessario modificare questo attributo per consentire temporaneamente l'utilizzo di sintassi basate su SQLData, consentendo di riscrivere il codice. A questo scopo, nel file serverConf.xml deve essere modificata l'opzione seguente:

allowSQLInjection="true"

Quindi, riavviate il postaggiornamento con il seguente comando:

nlserver config -postupgrade -instance:<instance_name> -force

È necessario configurare le aree di protezione (fare riferimento a Protezione), quindi riattivare la protezione modificando l'opzione:

allowSQLInjection="false"

Di seguito sono riportati alcuni esempi comparativi tra la vecchia e la nuova sintassi.

Filtraggio per sottoquery

• Sintassi precedente:

  <condition expr="@id NOT IN ([SQLDATA[SELECT iOperatorId FROM XtkOperatorGroup WHERE iGroupId = $(../@owner-id)]])" enabledIf="$(/ignored/@ownerType)=1"/>
  

• Nuova sintassi:

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

• Sintassi precedente:

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

• Nuova sintassi:

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

L'aggregato

Aggregate, funzione (raccolta)

• Sintassi precedente:

  <node sql="(select count(*) from NmsNewsgroup WHERE O0.iOperationId=iOperationId)" alias="@nbMessages"/>
  

• Nuova sintassi:

  <node expr="count([newsgroup/@id])" alias="../@nbMessages"/>
  

  NOTA

  I giunti vengono eseguiti automaticamente per le funzioni aggregate. Non è più necessario specificare la condizione WHERE O0.iOperationId=iOperationId.

  Non è più possibile utilizzare la funzione "count(*)". È necessario utilizzare "countall()".

• Sintassi precedente:

  <node sql="(select Sum(iToDeliver) from NmsDelivery WHERE O0.iOperationId=iOperationId AND iSandboxMode=0 AND iState>=45)" alias="@nbMessages"/>
  

• Nuova sintassi:

  <node expr="Sum([delivery-linkedDelivery/properties/@toDeliver])" alias= "../@sumToDeliver">
                    <where><condition expr="[validation/@sandboxMode]=0 AND @state>=45" /></where></node>
  

Filtri per giunzioni

[schemaName:alias:xPath]

L'alias è facoltativo

• Sintassi precedente:

  <condition expr={"[" + joinPart.destination.nodePath + "] = [SQLDATA[W." + joinPart.source.SQLName + "]]"}
                                           aliasSqlTable={nodeSchemaRoot.SQLTable + " W"}/>
  

• Nuova sintassi:

  <condition expr={"[" + joinPart.destination.nodePath + "] = [" + nodeSchema.id + ":" + joinPart.source.nodePath + "]]"}/>
  

Suggerimenti e trucchi

In un elemento <subQuery>, per fare riferimento a un campo "field" della <queryDef> principale utilizzate la sintassi seguente: [../@field]

Esempio:

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

Conflitti

La migrazione viene eseguita tramite un post-aggiornamento e possono verificarsi conflitti in rapporti, moduli o applicazioni Web. Questi conflitti possono essere risolti dalla console.

Dopo la sincronizzazione delle risorse, il comando postupgrade consente di rilevare se la sincronizzazione genera errori o avvisi.

Visualizzare il risultato della sincronizzazione

Il risultato della sincronizzazione può essere visualizzato in due modi:

• Nell'interfaccia della riga di comando, gli errori vengono generati da una tripla freccia >>> e la sincronizzazione viene arrestata automaticamente. Le avvertenze vengono materializzate da una doppia freccia > e devono essere risolte una volta completata la sincronizzazione. Alla fine del post aggiornamento, nel prompt dei comandi viene visualizzato un riepilogo. Ad esempio:

  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.
  

  Se l'avviso riguarda un conflitto di risorse, l'operatore deve prestare attenzione a risolverlo.

• Il postupgrade_<server version number>_time del file postupgrade>.log contiene il risultato della sincronizzazione. È disponibile per impostazione predefinita nella seguente directory: directory di installazione/var/<instance>postupgrade. Gli errori e le avvertenze sono indicati dagli attributi error e warning.

Risolvere un conflitto

La risoluzione dei conflitti deve essere eseguita solo dagli operatori avanzati e da quelli ai quali sono stati concessi diritti di amministratore.

Per risolvere un conflitto, eseguire il seguente processo:

1. Nella struttura ad albero Adobe Campaign, posizionare il cursore su Administration > Configuration > Package management > Edit conflicts.
2. Selezionare il conflitto da risolvere nell'elenco.

Esistono tre modi possibili per risolvere un conflitto:

• Declared as resolved: richiede l'intervento preventivo dell'operatore.

• Accept the new version: consigliato se le risorse fornite con Adobe Campaign non sono state modificate dall'utente.

• Keep the current version: indica che l'aggiornamento viene rifiutato.

  IMPORTANTE

  Se si seleziona questa modalità di risoluzione, si rischia di perdere le patch nella nuova versione. Si raccomanda pertanto vivamente che tale opzione non sia utilizzata o riservata solo agli operatori esperti.

Se scegliete di risolvere manualmente il conflitto, procedete come segue:

1. Nella sezione inferiore della finestra, cercate la _conflict_ string per individuare le entità con conflitti. L'entità installata con la nuova versione contiene l'argomento new, l'entità che corrisponde alla versione precedente contiene l'argomento cus.

   

2. Eliminate la versione che non desiderate mantenere. Eliminare la _conflict_argument_ string dell'entità che si sta tenendo.

   

3. Vai al conflitto che avresti risolto. Fare clic sull'icona Actions e selezionare Declare as resolved.

4. Salvare le modifiche: il conflitto ora è risolto.

Tomcat

Il server Tomcat integrato in Adobe Campaign v7 ha modificato la versione (Tomcat 7). Anche la sua cartella di installazione (tomcat-6) è cambiata (tomcat 7). Dopo l'aggiornamento, verificare che i percorsi siano collegati alla cartella aggiornata (nel file serverConf.xml):

$(XTK_INSTALL_DIR)/tomcat-8/bin/bootstrap.jar 
$(XTK_INSTALL_DIR)/tomcat-8/bin/tomcat-juli.jar
$(XTK_INSTALL_DIR)/tomcat-8/lib/tomcat-util.jar
$(XTK_INSTALL_DIR)/tomcat-8/lib/tomcat-api.jar
$(XTK_INSTALL_DIR)/tomcat-8/lib/servlet-api.jar
$(XTK_INSTALL_DIR)/tomcat-8/lib/jsp-api.jar
$(XTK_INSTALL_DIR)/tomcat-8/lib/el-api.jar

Interazione

Prerequisiti

Prima dell'aggiornamento successivo, è necessario eliminare tutti i riferimenti allo schema dalla versione 6.02 che non saranno più presenti nella versione v7.

• nms:emailOfferView
• nms:webOfferView
• nms:callCenterOfferView
• nms:mobileOfferView
• nms:paperOfferView

Contenuto offerta

In v7, il contenuto dell’offerta è stato spostato. In v6.02 il contenuto era in ogni schema di rappresentazione (nms:emailOfferView). In v7, il contenuto è ora nello schema delle offerte. Dopo l'aggiornamento successivo, il contenuto non sarà quindi visibile nell'interfaccia. Dopo l'aggiornamento, è necessario ricreare il contenuto dell'offerta o sviluppare uno script che sposta automaticamente il contenuto dallo schema di rappresentazione allo schema dell'offerta.

Un esempio di script di movimento (interactiveTo610_full_XX.js) è disponibile nella cartella Migration all'interno della cartella Adobe Campaign v7. Questo file mostra un esempio di script per un client che utilizza una singola rappresentazione e-mail per offerta (i campi htmlSource e textSource). Il contenuto presente nella tabella NmsEmailOfferView è stato spostato nella tabella delle offerte.

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");

Test e configurazione

Di seguito viene illustrata la procedura da seguire dopo aver spostato il contenuto dell'offerta se disponete di un solo ambiente. In questo caso prendiamo ad esempio "ENV".

1. In tutti gli spazi di ambiente "ENV", aggiornate l'elenco dei campi utilizzati. Ad esempio, per uno spazio delle offerte che utilizza solo il simbolo htmlSource, è necessario aggiungere il simbolo view/htmlSource.

   

2. Nel campo Type of Environment all'interno della scheda General, selezionare Live.

   

3. Create un ambiente di progettazione ("ENV_DESIGN", ad esempio) e collegatelo all’ambiente online ENV.

   

4. Distribuire tutti gli spazi di offerta dell'ambiente ENV (fare clic con il pulsante destro del mouse > Actions > Deploy) e selezionare l'ambiente "ENV_DESIGN".

   

5. Esegue le stesse operazioni per tutte le offerte di ambiente "ENV".

6. Attiva tutte le offerte di ambiente "ENV_DESIGN" sui canali pertinenti.

7. Test per rendere disponibile un'offerta. Se non si verificano problemi, eseguite le attività in sospeso sull'attività del flusso di lavoro più recente Offer notification (offerMgt) per rendere attive tutte le offerte.

   

8. Eseguire test completi.

   NOTA

   I nomi delle categorie e delle offerte online vengono modificati dopo essere andati in diretta. Sul canale in entrata, aggiornate tutti i riferimenti a offerte e categorie.

Rapporti

Rapporti standard

Tutti i report standard attualmente utilizzano il motore di rendering v6.x. Se avevate aggiunto JavaScript in questi rapporti, alcuni elementi potrebbero non funzionare più. In effetti, la vecchia versione di JavaScript non è compatibile con il motore di rendering v6.x. È quindi necessario controllare il codice JavaScript e adattarlo in un secondo momento. È necessario verificare ogni rapporto, in particolare la funzione di esportazione.

Rapporti personalizzati

Se desiderate avere il banner blu dalla release v7 (che consenta di accedere agli universi), dovete ripubblicare i rapporti. In caso di problemi, potete forzare il motore di rendering v6.0. A questo scopo, andate a Properties all'interno del rapporto, fate clic su Rendering e scegliete il motore di rendering Version 6.0 (Flash & OpenOffice).

Se desiderate beneficiare delle nuove funzionalità del rapporto, dovete selezionare il motore di rendering v.6.x. In questo caso, controllare tutti gli script e modificarli se necessario. Per quanto riguarda l'esportazione PDF, se avevate aggiunto script specifici per OpenOffice, questo non funzionerà più con il nuovo motore di esportazione PDF (PhantomJS).

Applicazioni web

Esistono due famiglie di applicazioni Web:

• applicazioni web identificate (viste insieme, moduli di approvazione, sviluppi interni extranet),
• applicazioni Web anonime (moduli Web o per questionari).

Applicazioni Web identificate

Come per i report (vedere Reports), se è stato aggiunto JavaScript, è necessario controllare e adattare se necessario. Se desiderate usufruire del banner blu v7 (contenente gli universi), dovete ripubblicare l’applicazione Web. Se il codice JavaScript funziona correttamente, potete selezionare il motore di rendering v6.x. In caso contrario, potete utilizzare il motore di rendering v6.0 mentre adattate il codice, quindi utilizzare il motore di rendering v6.x.

I metodi di connessione dell’applicazione Web sono stati modificati in v7. Se si verificano problemi di connessione nelle applicazioni Web identificate, è necessario attivare temporaneamente le opzioni allowUserPassword e sessionTokenOnly nel file serverConf.xml. Dopo l’aggiornamento, modificate i seguenti valori di opzione:

allowUserPassword="true"

sessionTokenOnly="true"

Quindi, riavviate il postaggiornamento con il seguente comando:

nlserver config -postupgrade -instance:<instance_name> -force

Verificate le applicazioni Web nel motore di rendering v6.x prima di pubblicarle. Quindi disattivate queste due opzioni.

allowUserPassword="false"

sessionTokenOnly="false"

Applicazioni Web anonime

In caso di problemi, ripubblicate l’applicazione Web. Se il problema persiste, potete selezionare il motore di rendering v6.0. Se non avete aggiunto JavaScript, potete selezionare il motore di rendering v6.x e trarre vantaggio dalle sue nuove funzioni.

Red Hat

Se gli schemi out-of-the-box sono stati eliminati in v6.02 o v5.11, dopo l’aggiornamento potrebbe non essere più possibile modificare gli schemi. In questo caso, eseguite il comando:

su - neolane
nlserver config -postupgrade -instance:<instance name> -force