La funzione di ricerca è una caratteristica essenziale delle community Adobe Experience Manager (AEM). Oltre al Ricerca per piattaforma AEM funzionalità, AEM Communities fornisce API di ricerca UGC per la ricerca di contenuti generati dagli utenti (UGC, User-Generated Content). UGC ha proprietà univoche in quanto viene immesso e memorizzato separatamente dagli altri contenuti e dati utente dell’AEM.
Per le comunità, le due cose generalmente cercate sono:
Contenuto pubblicato dai membri della community
Utenti e gruppi di utenti (dati utente)
Questa sezione della documentazione è interessante per gli sviluppatori che creano componenti personalizzati per la creazione o la gestione di contenuti generati dagli utenti (UGC, User-Generated Content).
Per un componente personalizzato, è necessario utilizzare UtilitàRisorseSocial metodi. I metodi di utilità che creano e cercano UGC stabiliscono i nodi shadow e accertarsi che il membro disponga delle autorizzazioni corrette per la richiesta.
Ciò che non viene gestito tramite le utility SRP sono proprietà relative alla moderazione.
Consulta Nozioni di base su SRP e UGC per informazioni sui metodi di utilità utilizzati per accedere ai nodi ombra UGC e ACL.
Il Archivio comune UGC viene fornito da uno dei vari provider di risorse di archiviazione (SRP), ciascuno dei quali può avere una lingua di query nativa diversa. Pertanto, indipendentemente dall'SRP scelto, il codice personalizzato deve utilizzare i metodi dell' Pacchetto API UGC (com.adobe.cq.social.ugc.api) che richiama il linguaggio di query appropriato per l'SRP scelto.
Per ASRP, UGC è memorizzato nel cloud di Adobe. Mentre UGC non è visibile in CRX, moderazione è disponibile sia dall’ambiente di authoring che da quello di pubblicazione. L'uso del API di ricerca UGC funziona per ASRP allo stesso modo degli altri SRP.
Al momento non esistono strumenti per la gestione delle ricerche ASRP.
Quando si creano proprietà personalizzate ricercabili, è necessario aderire al requisiti di denominazione.
Per MSRP, UGC viene memorizzato in MongoDB configurato per l’utilizzo di Solr per la ricerca. UGC non è visibile in CRX, ma moderazione è disponibile sia dall’ambiente di authoring che da quello di pubblicazione.
Per quanto riguarda MSRP e Solr:
Le funzioni di ricerca personalizzate devono utilizzare API di ricerca UGC.
Quando si creano proprietà personalizzate ricercabili, è necessario aderire al requisiti di denominazione.
Per JSRP, UGC è memorizzato in Oak ed è visibile solo nell’archivio dell’istanza AEM Author o Publish in cui è stata immessa.
Poiché UGC viene in genere 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, le voci UGC immesse nell’ambiente di pubblicazione non sono mai visibili nell’ambiente di authoring. Pertanto, tutti moderazione Le attività si svolgono nell’ambiente di pubblicazione.
Le funzioni di ricerca personalizzate devono utilizzare API di ricerca UGC.
Anche se gli indici Oak non vengono creati automaticamente per la ricerca sulla piattaforma AEM, a partire da AEM 6.2 sono stati aggiunti per consentire ad AEM Communities di migliorare le prestazioni e supportare l’impaginazione durante la presentazione dei risultati della ricerca UGC.
Se le proprietà personalizzate sono in uso e le ricerche sono lente, è necessario creare indici aggiuntivi per le proprietà personalizzate per renderle più performanti. Per mantenere la portabilità, attieniti alla requisiti di denominazione durante la creazione di proprietà personalizzate ricercabili.
Per modificare gli indici esistenti o creare indici personalizzati, vedi Query e indicizzazione Oak.
Il Gestore indice Oak è disponibile da ACS AEM Commons. Esso prevede:
Per visualizzare gli indici Oak esistenti in CRXDE Liti, il percorso è:
/oak:index/socialLucene
Di seguito sono riportate alcune delle proprietà ricercabili utilizzate per varie funzioni di Communities:
Proprietà | Tipo di dati |
---|---|
isFlagged | Booleano |
isSpam | Booleano |
letto | Booleano |
influenza | Booleano |
allegati | Booleano |
sentiment | Lungo |
contrassegnato | Booleano |
aggiunto | Data |
modifiedDate | Data |
stadio | Stringa |
userIdentifier | Stringa |
risposte | Lungo |
jcr:title | Stringa |
jcr:descrizione | Stringa |
sling:resourceType | Stringa |
allowThreadedReply | Booleano |
isDraft | Booleano |
publishDate | Data |
publishJobId | Stringa |
ha risposto | Booleano |
chosenanswer | Booleano |
tag | Stringa |
cq:Tag | Stringa |
author_display_name | Stringa |
location_t | Stringa |
parentPath | Stringa |
parentTitle | Stringa |
Quando si aggiungono proprietà personalizzate, tali proprietà devono essere visibili agli ordinamenti e alle ricerche creati con API di ricerca UGC, è obbligatorio per 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:
Testo è una stringa tokenizzata, Stringa non lo è. Utilizzare Testo per ricerche fuzzy (più simili).
Per i tipi con più valori, aggiungi "s" al suffisso, ad esempio:
viewDate_dt
: proprietà data singolaviewDates_dts
: proprietà list of datesComponenti, che includono sistema di commenti, supportano il parametro di filtro oltre ai relativi endpoint.
La sintassi del filtro per la logica AND e OR è espressa come segue (visualizzata prima dell’URL codificato):
Per specificare OR, utilizza un parametro 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 mostrato nell’URL che apre la pagina Risultati ricerca in Guida ai componenti della community. Per fare delle prove, passa a http://localhost:4503/content/community-components/en/search.html.
Gli operatori filtro sono:
EQ | equals |
---|---|
NE | diverso da |
LT | minore di |
LTE | minore o uguale a |
GE | maggiore di |
GTE | maggiore o uguale a |
MI PIACE | corrispondenza sfocata |
È importante che l’URL faccia riferimento al componente Communities (risorsa) e non alla pagina in cui il componente viene inserito:
/content/community-components/en/forum/jcr:content/content/forum.social.json
/content/community-components/en/forum.social.json
Esiste un progetto GitHub Adobe Experience Cloud che contiene:
Questo archivio contiene strumenti per la gestione dei dati in SRP.
Attualmente, esiste un servlet che può eliminare tutti i contenuti UGC da qualsiasi SRP.
Ad esempio, per eliminare tutti i contenuti generati dagli utenti (UGC) in ASRP:
curl -X POST http://localhost:4502/services/social/srp/cleanup?path=/content/usergenerated/asi/cloud -uadmin:admin
Per facilitare la risoluzione dei problemi relativi a una query Solr, abilitare la registrazione DEBUG per
com.adobe.cq.social.srp.impl.SocialSolrConnector
.
La query Solr effettiva viene visualizzata con l’URL codificato nel registro di debug:
Query da avviare: 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 della proprietà q
Il parametro è la query. Una volta decodificata la codifica URL, la query può essere passata allo strumento Solr Admin Query per ulteriori operazioni di debug.