Risoluzione dei problemi di integrazione

Suggerimenti generali per la risoluzione dei problemi

Verificare che non siano presenti errori JavaScript

Verificate se la console JavaScript del browser presenta errori. Errori non gestiti potrebbero impedire che il codice successivo venga eseguito correttamente. In caso di errori, verificare lo script che causa l'errore e in quale area. Il percorso dello script potrebbe fornire un'indicazione delle funzionalità a cui appartiene lo script.

Registrazione a livello di componente

In alcuni casi, potrebbe essere utile aggiungere istruzioni aggiuntive a livello di componente. Dal momento che è stato eseguito il rendering del componente, è possibile aggiungere una marcatura temporanea per visualizzare i valori variabili che possono facilitare l'identificazione di potenziali problemi. Esempio:

<%
log.info("myVariable={}", myVariable);
%>

<!--
<%= myJspVariable %>
-->

<!--
${ myHtlVariable }
-->

Per ulteriori dettagli sulla registrazione, vedere le pagine Logging e Utilizzo dei record di controllo e dei file di registro.

Problemi di integrazione di Analytics

Importazione report causa un utilizzo elevato di CPU/memoria

Importazione report causa un utilizzo elevato di CPU/memoria o causa OutOfMemoryError eccezioni.

Soluzione

Per risolvere questo problema, potete provare quanto segue:

Verificare che non ci sia una grande quantità di PollingImporter registrati (vedere la sezione "Shutdown impiega molto tempo a causa di PollingImporter" di seguito).
Eseguire gli importatori di report in un determinato momento della giornata utilizzando le espressioni CRON per le configurazioni ManagedPollingImporter nella console OSGi.

Per ulteriori dettagli sulla creazione di servizi di importazione dati personalizzati in AEM, consultare il seguente articolo https://helpx.adobe.com/experience-manager/using/polling.html.

L'arresto richiede molto tempo a causa di PollingImporter

Analytics è stato progettato pensando a un meccanismo di ereditarietà. Solitamente, per abilitare Analytics per un sito è necessario aggiungere un riferimento a una configurazione Analytics all'interno delle proprietà della pagina Cloud Services scheda. La configurazione viene quindi ereditata automaticamente a tutte le sottopagine senza la necessità di farvi nuovamente riferimento, a meno che una pagina non richieda una configurazione diversa. Se si aggiunge un riferimento a un sito, vengono automaticamente creati diversi nodi (12 per AEM 6.3 e versioni precedenti o 6 per AEM 6.4) e versioni successive) del tipo cq;PollConfig che crea un'istanza PollingImporter utilizzata per importare i dati di Analytics in AEM. Di conseguenza:

La presenza di molte pagine che fanno riferimento ad Analytics porta a un elevato numero di Importazione polling.
Inoltre, copiando e incollando pagine con un riferimento a una configurazione di Analytics si crea una duplicazione dei relativi PollingImporter.

Soluzione

In primo luogo, l'analisi di error.log potrebbe fornire informazioni sulla quantità di PollingImporter attivi o registrati. Esempio:

# Count PollingImporter entries
$ sed -n "s/.*(aem-analytics-integration-.*).*target=\(.*\),interval.*/\1/p" error.log | wc -l
86415
# Count PollingImporter entries for last30days
$ sed -n "s/.*(aem-analytics-integration-last30Days).*target=\(.*\),interval.*/\1/p" error.log | wc -l
14531
# Count unique paths of PollingImporter registrations
sed -n "s/.*(aem-analytics-integration-.*).*target=\(.*\)\/jcr:content.*/\1/p" error.log | sort | uniq -c
28115

In secondo luogo, accertatevi che solo le pagine principali (in alto nella gerarchia) abbiano un riferimento alla configurazione di Analytics.

Per ulteriori dettagli sulla creazione di servizi di importazione dati personalizzati in AEM, consultare il seguente articolo https://helpx.adobe.com/experience-manager/using/polling.html.

Problemi relativi a Gestione dinamica dei tag

Il tag script DTM non viene rappresentato nell'origine pagina

Il tag di script DTM non viene incluso correttamente nella pagina anche se alla configurazione è stato fatto riferimento nelle proprietà della pagina Cloud Services.

Soluzione

Per risolvere il problema, potete provare quanto segue:

Verificare che le proprietà crittografate possano essere decrittografate (notare che la cifratura potrebbe utilizzare una chiave generata automaticamente diversa in ogni istanza di AEM). Per ulteriori informazioni, consultare anche Supporto della crittografia per le proprietà di configurazione.
Ripubblica le configurazioni trovate in /etc/cloudservices/dynamictagmanagement
Selezionare ACL su /etc/cloudservices. Gli ACL devono essere:
- allow; jcr:read; webservice-support-servicelibfinder
- allow; jcr:read; tutti; rep:idspn:&ast;/default/&ast;
- allow; jcr:read; tutti; rep:idspn:&ast;/defas
- allow; jcr:read; tutti; rep:idspn:&ast;/public/&ast;
- allow; jcr:read; tutti; rep:idspn:&ast;/public

Per ulteriori informazioni sulla gestione degli ACL, consultare la pagina Amministrazione utente e sicurezza.

Problemi di integrazione di Target

Contenuto di destinazione non visibile in modalità Anteprima quando si utilizzano componenti di pagina personalizzati

Questo problema si verifica perché i componenti della pagina personalizzata non includono le librerie JSP o client corrette per la gestione delle integrazioni DTM di Target.

Soluzione

Potete provare le soluzioni seguenti:

Assicuratevi che la headlibs.jsp personalizzata (se presente /apps/<CUSTOM-COMPONENTS-PATH>/headlibs.jsp) includa quanto segue:

<%@include file="/libs/cq/cloudserviceconfigs/components/servicelibs/servicelibs.jsp?lang=it" %>
<sly data-sly-resource="${'contexthub' @ resourceType='granite/contexthub/components/contexthub'}"/>

Assicuratevi che la head.html personalizzata (se presente /apps/<CUSTOM-COMPONENTS-PATH>/head.html) non contenga selettivamente delle cuffie di integrazione specifiche, come nell'esempio seguente:

<!-- DO NOT MANUALLY INCLUDE SPECIFIC CLOUD SERVICE HEADLIBS LIKE THIS -->
<meta data-sly-include="/libs/cq/dtm/components/dynamictagmanagement/headlibs.jsp?lang=it" data-sly-unwrap/>

servicelibs.jsp aggiunge gli oggetti JavaScript di analisi richiesti e carica le librerie dei servizi cloud associate al sito Web. Per il servizio Target, le librerie vengono caricate tramite la variabile /libs/cq/analytics/components/testandtarget/headlibs.jsp

Il set di librerie che vengono caricate dipende dal tipo di libreria client di destinazione ( mbox.js o at.js) utilizzato nella configurazione di Target.

Quando utilizzate Gestione dinamica dei tag per distribuire mbox.js o at.js, accertatevi che le librerie siano caricate prima del rendering del contenuto. L'utilizzo di sistemi di gestione dei tag che caricano queste librerie in modo asincrono potrebbe causare problemi durante l'esecuzione del codice JavaScript specifico di destinazione.

Per ulteriori informazioni, consultate la pagina Sviluppo per contenuti mirati.

L'errore "ID suite di rapporti mancante nell'inizializzazione AppMeasurement" viene visualizzato nella console del browser

Questo problema potrebbe verificarsi quando Adobe Analytics viene implementato sul sito Web utilizzando DTM e utilizza il codice personalizzato. La causa è l'utilizzo di s = new AppMeasurement() per creare un'istanza dell'oggetto s.

Soluzione

Utilizzare s_gi invece del metodo di creazione dell'istanza new AppMeasurement. Esempio:

var s_account="INSERT-RSID-HERE"
var s=s_gi(s_account)

Un'offerta predefinita viene visualizzata in modo casuale al posto dell'offerta corretta

Questo problema può essere dovuto a più cause:

Il caricamento delle librerie client Target ( mbox.js o at.js) in modo asincrono tramite sistemi di gestione tag di terze parti potrebbe interrompere il targeting in modo casuale. Le librerie Target devono essere caricate in modo sincrono nell'intestazione della pagina. Questo è sempre vero quando le librerie vengono distribuite da AEM.
Caricamento simultaneo di due librerie client Target ( at.js), ad esempio una con Gestione dinamica dei tag e una con la configurazione di Target in AEM. Ciò può causare conflitti per la definizione adobe.target se le versioni at.js sono diverse.

Soluzione

Potete provare le soluzioni seguenti:

Assicurati che il codice cliente che carica le librerie simili a Gestione dinamica dei tag (che a sua volta carica le librerie Target) sia eseguito in modo sincrono nell' intestazione di pagina.
se il sito è configurato per utilizzare DTM per distribuire le librerie Target, assicurati che l'opzione Clientlib consegnata da DTM sia selezionata nella configurazione Target del sito.

Quando si utilizza AT.js 1.3+, viene sempre visualizzata un'offerta predefinita al posto dell'offerta corretta

Le AEM 6.2 e 6.3 non sono compatibili con AT.js versione 1.3.0+. Con AT.js versione 1.3.0 che introduce la convalida dei parametri per le sue API, adobe.target.applyOffer() richiede un parametro "mbox" che non è fornito dal codice atjs-itegration.js.

Soluzione

Per risolvere questo problema, modificare atjs-itegration.js e aggiungere il campo "mbox": mboxName nell’oggetto parametro per adobe.target.applyOffer() come segue:

adobe.target.getOffer({
    "mbox": mboxName,
    "params": params,
    "success": function (response) {
        adobe.target.applyOffer({
            "mbox": mboxName, //<--- ADDED PARAM
            "selector": "#" + mboxName,
            "offer": response
        })
    },

La pagina Goals & Settings (Obiettivi e impostazioni) non mostra la sezione Origini di reporting

Questo problema è probabilmente dovuto a un problema di A4T configurazione Analytics Cloud provisioning.

Soluzione

È necessario verificare che A4T sia abilitato correttamente per l'account Target emettendo la seguente richiesta di verifica per AEM:

http://localhost:4502/etc/cloudservices/testandtarget/<YOUR-CONFIG>/jcr:content.a4t.json

{
    "a4tEnabled": true,
    "sharedsecret": "SECRET",
    "proxyUrl": "/libs/cq/contentinsight/content/proxy.reportingservices.json",
    "active": "true",
    "pageName": "",
    "url": "https://api5.omniture.com/rs/0.5/",
    "username": "USER@DOMAIN"
}

Se la risposta contiene la riga a4tEnabled:false, contatta l'Assistenza clienti Adobe per ottenere il provisioning corretto dell'account.

API Target utili

Di seguito sono riportate due API Target che potrebbero essere utili per risolvere i problemi di Target:

Recuperare l'endpoint Target per un codice cliente specificato

https://admin.testandtarget.omniture.com/rest/v1/endpoint/<CLIENTCODE>.json

{"api":"https://admin<N>.testandtarget.omniture.com/admin/rest/v1"}

Recuperare il profilo di un client

https://admin<N>.testandtarget.omniture.com/admin/rest/v1/clients/<CLIENT>?email=<EMAIL>&password=<PASSWORD>

Response for N=4, CLIENT-dayintegrationintern
{
    "clientCode": "dayintegrationintern",
    "companyName": "Day Integration - Internal",
    "omnitureCompanyId": "Day Integration Internal",
    "softTraxId": -1,
    "address1": "XYZ",
    "city": "San Francisco",
    "state": "ca",
    "zip": "94107",
    "country": "UNITED STATES",
    "locale": "de_DE",
    "timeZone": "Europe/Berlin",
    "phone": "XX-XX-XXXX",
    "serviceLevel": "Up to 100,000",
    "privileges": [
        "a4t",
        "hosts",
        "TnT-SC-integration",
        "mvt",
        "steps",
        "testing-campaigns",
        "view-snapshot",
        "on-site-editor",
        "optimizing-campaign",
        "third-party-id-support",
        "landing-page-campaigns",
        "segment",
        "rest-create-user",
        "advanced-targeting",
        "mobile-device-targeting",
        "beta",
        "geolocation"
    ]
}