La función de búsqueda es una función esencial de AEM Communities. Además del búsqueda en AEM plataforma , AEM Communities proporciona la variable API de búsqueda UGC para buscar contenido generado por el usuario (UGC). UGC tiene propiedades únicas, ya que se introducen y almacenan por separado de otros contenidos AEM y datos de usuario.
Para las comunidades, las dos cosas que se buscan generalmente son:
Contenido publicado por miembros de la comunidad
Usuarios y grupos de usuarios (datos de usuario)
Esta sección de la documentación es de interés para los desarrolladores que crean componentes personalizados que crean o administran UGC.
Para un componente personalizado, es necesario usar la variable SocialResourceUtilities métodos. Los métodos de utilidad que crean y buscan UGC establecerán los requisitos nodos de sombra y asegúrese de que el miembro tenga los permisos correctos para la solicitud.
Lo que no se administra mediante las utilidades de SRP son propiedades relacionadas con la moderación.
Consulte Elementos esenciales de SRP y UGC para obtener información sobre los métodos de utilidad utilizados para acceder a los nodos de sombra UGC y ACL.
La variable UGC common store es proporcionado por uno de una variedad de proveedores de recursos de almacenamiento (SRP), cada uno de los cuales posiblemente tenga un idioma de consulta nativo diferente. Por lo tanto, independientemente del SRP elegido, el código personalizado debe utilizar métodos del Paquete de API de UGC (com.adobe.cq.social.ugc.api) que invocará el idioma de consulta apropiado para el SRP elegido.
Para ASRP, UGC se almacena en la nube de Adobe. Aunque UGC no es visible en CRX, moderación está disponible en los entornos de autor y publicación. El uso de API de búsqueda UGC funciona para ASRP igual que para otros SRP.
Actualmente no existen herramientas para administrar búsquedas ASRP.
Al crear propiedades personalizadas en las que se pueden buscar, es necesario adherirse a la variable requisitos de nomenclatura.
Para MSRP, UGC se almacena en MongoDB configurado para utilizar Solr para la búsqueda. UGC no será visible en CRX, pero moderación está disponible en los entornos de autor y publicación.
En cuanto al MSRP y Solr:
Las características de búsqueda personalizadas deben usar la variable API de búsqueda UGC.
Al crear propiedades personalizadas en las que se pueden buscar, es necesario adherirse a la variable requisitos de nomenclatura.
Para JSRP, UGC se almacena en Oak y solo es visible en el repositorio de la instancia de autor o publicación AEM en la que se introdujo.
Dado que UGC se introduce generalmente en el entorno de publicación, para los sistemas de producción de varios publicadores, es necesario configurar un publicar clúster, no un conjunto de servidores de publicación, de modo que el contenido introducido sea visible desde todos los editores.
Para JSRP, el UGC introducido en el entorno de publicación nunca será visible en el entorno de creación. Así, todo moderación las tareas se realizan en el entorno de publicación.
Las características de búsqueda personalizadas deben usar la variable API de búsqueda UGC.
Aunque los índices Oak no se crean automáticamente para la búsqueda en la plataforma AEM, a partir de la AEM 6.2 se han agregado para AEM Communities para mejorar el rendimiento y proporcionar compatibilidad con la paginación al presentar los resultados de búsqueda UGC.
Si las propiedades personalizadas están en uso y las búsquedas son lentas, será necesario crear índices adicionales para las propiedades personalizadas a fin de que tengan un mayor rendimiento. Para mantener la portabilidad, siga los requisitos de nomenclatura al crear propiedades personalizadas que se pueden buscar.
Para modificar índices existentes o crear índices personalizados, consulte Consultas e indexación de Oak.
La variable Administrador de índices Oak está disponible en ACS AEM Commons. Proporciona:
Para ver los índices Oak existentes en CRXDE Lite, la ubicación es:
/oak:index/socialLucene
A continuación se presentan algunas de las propiedades de búsqueda utilizadas para varias funciones de Communities:
Propiedad | Tipo de datos |
---|---|
isFlagged | Booleana |
isSpam | Booleana |
read | Booleana |
influencia | Booleana |
archivos adjuntos | Booleana |
opinión | Largo |
marcado | Booleana |
añadido | Fecha |
modifiedDate | Fecha |
estado | Cadena |
userIdentifier | Cadena |
answers | Largo |
jcr:title | Cadena |
jcr:description | Cadena |
sling:resourceType | Cadena |
allowThreadedReply | Booleana |
isDraft | Booleana |
publishDate | Fecha |
publishJobId | Cadena |
con respuesta | Booleana |
chosenresponse | Booleana |
etiqueta | Cadena |
cq:Tag | Cadena |
author_display_name | Cadena |
location_t | Cadena |
parentPath | Cadena |
parentTitle | Cadena |
Al agregar propiedades personalizadas, para que estas propiedades puedan ser visibles para ordenar y buscar creadas con la variable API de búsqueda UGC, es obligatorio para agregar un sufijo al nombre de la propiedad.
El sufijo es para los idiomas de consulta que utilizan un esquema:
Solr es un ejemplo de lenguaje de consulta que utiliza un esquema.
Sufijo | Tipo de datos |
---|---|
_b | Booleana |
_dt | Calendario |
_d | Doble |
_tl | Largo |
_s | Cadena |
_t | Texto |
Notas:
Texto es una cadena con token, Cadena no. Uso Texto para búsquedas difusas (más como esta).
Para los tipos de varios valores, añada "s" al sufijo, por ejemplo:
viewDate_dt
: propiedad single dateviewDates_dts
: list of dates, propiedadLos componentes que incluyen la variable sistema de comentarios admiten el parámetro de filtro además de sus extremos.
La sintaxis del filtro para la lógica AND y OR se expresa de la siguiente manera (se muestra antes de ser codificada con la URL):
Para especificar O use un parámetro de filtro con valores separados por comas:
filter=name eq 'Jennifer',name eq 'Jen'
Para especificar Y usar varios parámetros de filtro:
filter = name eq 'Jackson'&filter=message eq 'testing'
La implementación predeterminada de la variable Componente de búsqueda utiliza esta sintaxis como se puede ver en la dirección URL que abre la página Resultados de la búsqueda en la Guía de componentes de comunidad. Para experimentar, vaya a http://localhost:4503/content/community-components/en/search.html.
Los operadores de filtro son:
EQ | igual a |
---|---|
NE | no es igual a |
LT | menor que |
LTE | menor o igual que |
GE | bueno que |
GTE | mayor o igual que |
LIKE | coincidencia confusa |
Es importante que la URL haga referencia al componente Comunidades (recurso) y no a la página en la que se coloca el componente:
/content/community-components/en/forum/jcr:content/content/forum.social.json
/content/community-components/en/forum.social.json
Hay un proyecto de Adobe Marketing Cloud GitHub que contiene:
Herramientas SRP de AEM Communities
Este repositorio contiene herramientas para administrar datos en SRP.
Actualmente, hay un servlet que proporciona la capacidad de eliminar todo UGC de cualquier SRP.
Por ejemplo, para eliminar todo UGC en ASRP:
curl -X POST http://localhost:4502/services/social/srp/cleanup?path=/content/usergenerated/asi/cloud -uadmin:admin
Para ayudar a solucionar problemas con una consulta Solr, habilite el registro de DEBUG para
com.adobe.cq.social.srp.impl.SocialSolrConnector
.
La consulta Solr real se mostrará como URL codificada en el registro de depuración:
La consulta a solr es: 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
El valor de la variable q
es la consulta. Una vez descodificada la codificación de la URL, la consulta se puede pasar a la herramienta Solr Admin Query para depurar más.