La funzione di ricerca è una caratteristica essenziale di AEM Communities. Oltre alle funzionalità di AEM piattaforma di ricerca, AEM Communities fornisce l'API di ricerca UGC allo scopo di ricercare contenuti generati dall'utente (UGC). UGC ha proprietà univoche in quanto viene immesso e memorizzato separatamente da altri contenuti AEM e dati utente.
Per Community, le due operazioni generalmente ricercate sono:
Contenuto pubblicato dai membri della community
Utenti e gruppi di utenti (dati utente)
Questa sezione della documentazione interessa gli sviluppatori che creano componenti personalizzati per la creazione o la gestione di UGC.
Per un componente personalizzato, è necessario utilizzare i metodi SocialResourceUtilities. I metodi di utilità che creano e ricercano UGC stabiliranno i nodi shadow richiesti e si assicureranno che il membro disponga delle autorizzazioni corrette per la richiesta.
Ciò che non viene gestito tramite le utility SRP sono proprietà correlate alla moderazione.
Per informazioni sui metodi di utilità utilizzati per accedere ai nodi ombra UGC e ACL, vedere SRP e UGC Essentials.
L' archivio comune UGC è fornito da uno dei vari provider di risorse di storage (SRP), ognuno dei quali può avere una lingua di query nativa diversa. Pertanto, indipendentemente dall'SRP scelto, il codice personalizzato deve utilizzare i metodi del pacchetto API UGC (com.adobe.cq.social.ugc.api) che richiameranno il linguaggio di query appropriato per l'SRP scelto.
Per ASRP, UGC è memorizzato nel cloud di Adobi . Sebbene l'UGC non sia visibile in CRX, moderazione è disponibile sia dall'ambiente di creazione che da quello di pubblicazione. L'utilizzo dell'API di ricerca UGC funziona per ASRP come per altri SRP.
Al momento non esistono strumenti per gestire le ricerche ASRP.
Quando si creano proprietà personalizzate ricercabili, è necessario aderire ai requisiti di denominazione.
Per MSRP, UGC viene memorizzato in MongoDB configurato per utilizzare Solr per la ricerca. UGC non sarà visibile in CRX, ma moderation è disponibile sia dall'ambiente di creazione che da quello di pubblicazione.
Per quanto riguarda MSRP e Solr:
Le funzionalità di ricerca personalizzate devono utilizzare l'API di ricerca UGC.
Quando si creano proprietà personalizzate ricercabili, è necessario aderire ai requisiti di denominazione.
Per JSRP, UGC è memorizzato in Oak ed è visibile solo nella directory archivio dell'istanza di creazione o di pubblicazione AEM in cui è stato immesso.
Poiché UGC viene generalmente immesso nell'ambiente di pubblicazione, per i sistemi di produzione con più editori è necessario configurare un cluster di pubblicazione, non una farm di pubblicazione, in modo che il contenuto immesso sia visibile da tutti gli editori.
Per JSRP, l’UGC immesso nell’ambiente di pubblicazione non sarà mai visibile nell’ambiente di authoring. Di conseguenza, tutte le attività moderazione vengono eseguite nell'ambiente di pubblicazione.
Le funzionalità di ricerca personalizzate devono utilizzare l'API di ricerca UGC.
Sebbene gli indici Oak non vengano creati automaticamente per la ricerca della piattaforma AEM, a partire da AEM 6.2 sono stati aggiunti per AEM Communities per migliorare le prestazioni e fornire supporto per l’impaginazione quando si presentano i risultati di ricerca UGC.
Se le proprietà personalizzate sono in uso e le ricerche sono lente, è necessario creare ulteriori indici per rendere più efficaci le proprietà personalizzate. Per mantenere la portabilità, rispettare i requisiti di denominazione durante la creazione di proprietà personalizzate ricercabili.
Per modificare gli indici esistenti o creare indici personalizzati, fare riferimento a Query e indicizzazione Oak.
La Oak Index Manager è disponibile da ACS AEM Commons. Fornisce:
Per visualizzare gli indici Oak esistenti in CRXDE Lite, il percorso è:
/oak:index/socialLucene
Di seguito sono riportate alcune delle proprietà ricercabili utilizzate per le varie funzioni di Communities:
Proprietà | Tipo di dati |
---|---|
isFlagged | Booleano |
isSpam | Booleano |
read | Booleano |
influenza | Booleano |
allegati | Booleano |
sentimento | Lungo |
contrassegnato | Booleano |
aggiunto | Data |
modifiedDate | Data |
stadio | Stringa |
userIdentifier | Stringa |
response | Lungo |
jcr:title | Stringa |
jcr:description | Stringa |
sling:resourceType | Stringa |
allowThreadedReply | Booleano |
isDraft | Booleano |
publishDate | Data |
publishJobId | Stringa |
ha risposto | Booleano |
discordante | Booleano |
tag | Stringa |
cq:Tag | Stringa |
author_display_name | Stringa |
location_t | Stringa |
parentPath | Stringa |
parentTitle | Stringa |
Quando si aggiungono proprietà personalizzate, affinché tali proprietà siano visibili per l'ordinamento e le ricerche create con l'API di ricerca UGC, è richiesto aggiungere un suffisso al nome della proprietà.
Il suffisso è per i linguaggi di query che utilizzano uno schema:
Solr è un esempio di linguaggio di query che utilizza uno schema.
Suffisso | Tipo di dati |
---|---|
_b | Booleano |
_dt | Calendario |
_d | Doppio |
_tl | Lungo |
_s | Stringa |
_t | Testo |
Note:
Text è una stringa token, ** Stringis no. Utilizzate Text per eseguire ricerche sfocate (più simili).
Per i tipi con più valori, aggiungete ‘s’ al suffisso, ad esempio:
viewDate_dt
: single date, proprietàviewDates_dts
: list date, proprietàI componenti che includono il sistema di commenti supportano il parametro del filtro oltre ai relativi endpoint.
La sintassi del filtro per la logica AND e OR è espressa come segue (visualizzata prima della codifica URL):
Per specificare O utilizzare un param di filtro con valori separati da virgola:
filter=name eq 'Jennifer',name eq 'Jen'
Per specificare e utilizzare più parametri di filtro:
filter = name eq 'Jackson'&filter=message eq 'testing'
L'implementazione predefinita del componente di ricerca utilizza questa sintassi, come illustrato nell'URL che apre la pagina Risultati ricerca nella Guida dei componenti della community. Per provare, individuare http://localhost:4503/content/community-components/en/search.html.
Gli operatori filtro sono:
EQ | è uguale a |
---|---|
NE | not equals |
LT | minore di |
LTE | minore o uguale a |
GE | maggiore di |
GTE | maggiore o uguale a |
SIMILE | sfocato |
È importante che l’URL faccia riferimento al componente Community (risorsa) e non alla pagina in cui il componente è posizionato:
/content/community-components/en/forum/jcr:content/content/forum.social.json
/content/community-components/en/forum.social.json
Esiste un progetto Adobe Marketing Cloud GitHub che contiene:
Questo archivio contiene strumenti per la gestione dei dati in SRP.
Attualmente, esiste un servlet che consente di eliminare tutti gli UGC da qualsiasi SRP.
Ad esempio, per eliminare tutti gli UGC nell’ASRP:
curl -X POST http://localhost:4502/services/social/srp/cleanup?path=/content/usergenerated/asi/cloud -uadmin:admin
Per risolvere i problemi relativi a una query Solr, abilita la registrazione DEBUG per
com.adobe.cq.social.srp.impl.SocialSolrConnector
.
La query Solr effettiva verrà visualizzata URL codificati nel registro di debug:
La query su solr è: sort=timestamp+desc&bl=en&pl=en&start=0&rows=10 &q=%2Btitle_t:(hello)+%2Bprovider_id:\/content/usergenerated/asi/mongo/content/+%2Bresource_type_s:&df=provider_id&trf=verbatim&fq={!cost%3D100}report_suite:mongo
Il valore del parametro q
è la query. Una volta decodificata la codifica URL, la query può essere passata allo strumento Solr Admin Query per ulteriori attività di debug.