La función de búsqueda es una función esencial de AEM Communities. Además de las AEM búsqueda de plataforma de funciones, AEM Communities proporciona el API de búsqueda UGC con el fin de buscar contenido generado por el usuario (UGC). AEM UGC tiene propiedades únicas, ya que se introduce y almacena por separado de otros datos de usuario y de contenido de la.
Para Communities, 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 utilizar la variable SocialResourceUtilities métodos. Los métodos de utilidad que crean y buscan UGC establecerán el requerido nodos en la sombra y asegúrese de que el miembro tenga los permisos correctos para la solicitud.
Lo que no se administra mediante las utilidades SRP son propiedades relacionadas con la moderación.
Consulte SRP y UGC Essentials para obtener información sobre los métodos de utilidad utilizados para acceder a los nodos centrales UGC y ACL.
El Almacén común de UGC es proporcionada por uno de los diversos 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 adecuado 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 creación y publicación. El uso del 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 realizar búsquedas, es necesario adherirse a 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 creación y publicación.
Con respecto al MSRP y Solr:
Las funciones de búsqueda personalizadas deben utilizar la variable API de búsqueda UGC.
Al crear propiedades personalizadas en las que se pueden realizar búsquedas, es necesario adherirse a requisitos de nomenclatura.
Para JSRP, UGC se almacena en Oak AEM y solo es visible en el repositorio de la instancia de autor o publicación de la en la que se introdujo.
Dado que UGC se introduce normalmente en el entorno de publicación, para sistemas de producción de varios editores 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, los UGC introducidos en el entorno de publicación nunca serán visibles en el entorno de creación. Así todos moderación las tareas se realizan en el entorno de publicación.
Las funciones de búsqueda personalizadas deben utilizar la variable API de búsqueda UGC.
AEM AEM Aunque los índices Oak no se crean automáticamente para la búsqueda en la plataforma de, a partir de la versión 6.2 se han agregado para AEM Communities a fin de mejorar el rendimiento y proporcionar compatibilidad con la paginación al presentar resultados de búsqueda UGC.
Si las propiedades personalizadas están en uso y las búsquedas son lentas, deberían crearse índices adicionales para las propiedades personalizadas para que tengan un mejor rendimiento. Para mantener la portabilidad, siga el requisitos de nomenclatura al crear propiedades personalizadas en las que se pueden realizar búsquedas.
Para modificar índices existentes o crear índices personalizados, consulte Consultas e indexación de Oak.
El Administrador de índices Oak AEM está disponible en ACS Commons. Proporciona lo siguiente:
Para ver los índices Oak existentes en CRXDE Lite, la ubicación es:
/oak:index/socialLucene
A continuación se muestran algunas de las propiedades en las que se pueden buscar utilizadas para diversas funciones de Communities:
Propiedad | Tipo de datos |
---|---|
isFlagged | Booleana |
isSpam | Booleana |
leer | Booleana |
influenciar | Booleana |
attachments | Booleana |
opinión | Largo |
marcado | Booleana |
añadido | Fecha |
modifiedDate | Fecha |
estado | Cadena |
userIdentifier | Cadena |
respuestas | Largo |
jcr:title | Cadena |
jcr:description | Cadena |
sling:resourceType | Cadena |
allowThreadedReply | Booleana |
isDraft | Booleana |
publishDate | Fecha |
publishJobId | Cadena |
con respuesta | Booleana |
chosenanswer | Booleana |
etiqueta | Cadena |
cq:Etiqueta | Cadena |
author_display_name | Cadena |
location_t | Cadena |
parentPath | Cadena |
parentTitle | Cadena |
Al agregar propiedades personalizadas, para que esas propiedades sean visibles para las ordenaciones y búsquedas creadas con API de búsqueda UGC, lo es obligatorio para agregar un sufijo al nombre de la propiedad.
El sufijo es para 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 es. 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 de fecha únicaviewDates_dts
: lista de propiedades de fechasComponentes que incluyen sistema de comentarios admiten la adición del parámetro de filtro a sus extremos.
La sintaxis del filtro para la lógica AND y OR se expresa de la siguiente manera (se muestra antes de codificarse con URL):
Para especificar OR, utilice un parámetro de filtro con valores separados por comas:
filter=name eq 'Jennifer',name eq 'Jen'
Para especificar AND, utilice varios parámetros de filtro:
filter = name eq 'Jackson'&filter=message eq 'testing'
La implementación predeterminada de Componente de búsqueda utiliza esta sintaxis, como se puede ver en la dirección URL que abre la página Resultados de búsqueda en la Guía de componentes de la comunidad. Para experimentar, vaya a http://localhost:4503/content/community-components/en/search.html.
Los operadores de filtro son:
EQ | igual a |
---|---|
NE | no igual a |
LT | menor que |
LTE | menor que o igual a |
GE | bueno que |
GTE | bueno que o igual a |
LIKE | coincidencia aproximada |
Es importante que la dirección URL haga referencia al componente (recurso) de Communities 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 permite eliminar todos los UGC de cualquier SRP.
Por ejemplo, para eliminar todos los UGC en ASRP:
curl -X POST http://localhost:4502/services/social/srp/cleanup?path=/content/usergenerated/asi/cloud -uadmin:admin
Para solucionar problemas con una consulta Solr, habilite el registro DEBUG para
com.adobe.cq.social.srp.impl.SocialSolrConnector
.
La consulta Solr real se mostrará con la dirección 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 del q
parámetro es la consulta. Una vez descodificada la codificación de la URL, la consulta se puede pasar a la herramienta Solr Admin Query para una depuración posterior.