La función de búsqueda es una característica esencial de AEM Communities. Además de las capacidades AEM de búsqueda en la plataforma, AEM Communities proporciona la API de búsqueda UGC con el propósito de buscar contenido generado por el usuario (UGC). UGC tiene propiedades únicas, ya que se introducen y almacenan por separado de otros datos de usuario y de contenido de AEM.
En el caso de las comunidades, las dos cosas que generalmente se buscan 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 los métodos SocialResourceUtilities. Los métodos de utilidad que crean y buscan UGC establecerán los nodos de sombra necesarios y asegurarán 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 SRP y UGC Essentials para obtener información sobre los métodos de utilidad utilizados para acceder a nodos de sombra UGC y ACL.
El almacén común de UGC lo proporciona 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 UGC (com.adobe.cq.social.ugc.api) que invocarán el lenguaje de consulta apropiado para el SRP seleccionado.
Para ASRP, UGC se almacena en la nube de Adobe. Aunque UGC no está visible en CRX, moderación está disponible tanto en los entornos de autor como de publicación. El uso de la API de búsqueda UGC funciona para ASRP igual que para otros SRP.
Actualmente no existen herramientas para administrar las búsquedas ASRP.
Al crear propiedades personalizadas en las que se pueden realizar búsquedas, es necesario cumplir los requisitos de nomenclatura.
Para MSRP, UGC se almacena en MongoDB configurado para utilizar Solr para la búsqueda. UGC no estará visible en CRX, pero moderación está disponible desde los entornos de creación y publicación.
Respecto del MSRP y Solr:
Las características de búsqueda personalizada deben utilizar la API de búsqueda UGC.
Al crear propiedades personalizadas en las que se pueden realizar búsquedas, es necesario cumplir los requisitos de nomenclatura.
Para JSRP, UGC se almacena en Oak y solo se puede ver en el repositorio de la instancia de creación o publicación AEM en la que se introdujo.
Dado que UGC suele introducirse en el entorno de publicación, para los sistemas de producción de varios publicadores es necesario configurar un clúster de publicación, no un conjunto de servidores de publicación, de modo que el contenido introducido esté visible desde todos los editores.
Para JSRP, la UGC introducida en el entorno de publicación nunca estará visible en el entorno de creación. Por lo tanto, todas las tareas de moderación se producen en el entorno de publicación.
Las características de búsqueda personalizada deben utilizar la API de búsqueda UGC.
Aunque los índices Oak no se crean automáticamente para la búsqueda de la plataforma AEM, a partir de 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 aumentar su rendimiento. Para mantener la portabilidad, cumpla los 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 Oak e indización.
El Administrador de índices Oak está disponible en ACS AEM Commons. Proporciona:
Para vista de los índices Oak existentes en CRXDE Lite, la ubicación es:
/oak:index/socialLucene
A continuación se indican algunas de las propiedades que se pueden buscar y que se utilizan para diversas funciones de Comunidades:
Propiedad | Tipo de datos |
---|---|
isFlagged | Booleano |
isSpam | Booleano |
read | Booleano |
influir | Booleano |
adjuntos | Booleano |
opinión | Largo |
marcado | Booleano |
añadido | Fecha |
modifiedDate | Fecha |
estado | Cadena |
userIdentifier | Cadena |
respuestas | Largo |
jcr:title | Cadena |
jcr:description | Cadena |
sling:resourceType | Cadena |
allowThreadedReply | Booleano |
isDraft | Booleano |
publishDate | Fecha |
publishJobId | Cadena |
con respuesta | Booleano |
chosenanswer | Booleano |
tag | Cadena |
cq:Tag | Cadena |
author_display_name | Cadena |
location_t | Cadena |
parentPath | Cadena |
parentTitle | Cadena |
Al agregar propiedades personalizadas, para que esas propiedades sean visibles para ordenar y buscar creadas con la API de búsqueda UGC, es necesario 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 | Booleano |
_dt | Calendario |
_d | Doble |
_tl | Largo |
_s | Cadena |
_t | Texto |
Notas:
**Texto es una cadena con token, no ** Stringis. Use Texto para búsquedas borrosas (más o menos así).
Para tipos de varios valores, añada ‘s’ al sufijo, por ejemplo:
viewDate_dt
:: single date, propiedadviewDates_dts
:: lista de la propiedad dateLos componentes que incluyen el sistema de comentarios admiten la adición del parámetro de filtro a sus extremos.
La sintaxis del filtro para la lógica Y y O se expresa de la siguiente manera (se muestra antes de ser codificada con la dirección URL):
Para especificar O, 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 del 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 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 es igual a |
LT | menor que |
LTE | menor o igual que |
GE | bueno que |
GTE | mayor o igual que |
COMO | coincidencia confusa |
Es importante que la dirección 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 permite eliminar todo el UGC de cualquier SRP.
Por ejemplo, para eliminar todo el 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 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 parámetro q
es la consulta. Una vez descodificada la codificación de la URL, la consulta se puede pasar a la herramienta Consulta de administración de Solr para depurar más.