Implementar un conector de bases de datos

Esta guía va dirigida a los administradores de bases de datos de Google Cloud Search, es decir, a cualquier persona responsable de obtener, implementar, configurar y mantener el conector de bases de datos.

En ella se proporcionan instrucciones para realizar tareas clave relacionadas con la implementación del conector:

  • Descargar el software Content Connector de Cloud Search para bases de datos.
  • Configurar el conector para que se pueda usar con una fuente de datos de SQL concreta.
  • Ejecutar el conector.

Para comprender los conceptos expuestos en este documento, deberás conocer los aspectos básicos de bases de datos, el lenguaje de consulta estructurada (SQL), algunas cuestiones básicas sobre las listas de control de acceso (LCA) y los sistemas operativos Windows o Linux.

En esta guía no se facilita información sobre las tareas que debe realizar el administrador de G Suite para asignar Google Cloud Search al conector de bases de datos. Si necesitas más información acerca de esas tareas, consulta las instrucciones sobre cómo gestionar fuentes de datos de terceros.

De forma predeterminada, Cloud Search puede localizar, indexar y servir contenido procedente de datos de G Suite, como documentos y hojas de cálculo. Sin embargo, con el conector de bases de datos de Cloud Search, también puedes localizar e indexar datos de tus propios repositorios de bases de datos.

El conector sube las solicitudes de indexación a la API Indexing de Cloud Search y mantiene el índice de Cloud Search sincronizado con el repositorio de la base de datos de terceros indexando periódicamente la base de datos completa.

El conector de bases de datos de Cloud Search permite controlar el acceso de los usuarios a los documentos de los resultados de búsqueda mediante el uso de LCAs. Para obtener más información sobre este tema, consulta el apartado Opciones de la Lista de control de acceso.

Comportamiento del conector

Como administrador del conector, puedes controlar el comportamiento del conector de bases de datos de Cloud Search creando su archivo de configuración. En este archivo, deberás definir los siguientes aspectos principales del comportamiento del conector:

  • Acceso a la base de datos de destino
  • Identificación del contenido disponible para búsquedas
  • Realización de barridos
  • Consulta de las programaciones de barridos
  • Envío de consultas SQL a la base de datos para obtener registros
  • Cumplimiento de las listas de control de acceso (LCA)

Si quieres definir un comportamiento específico del conector, incluye en el archivo de configuración pares clave-valor para cada parámetro de configuración que quieras personalizar. Para obtener información detallada sobre este proceso, consulta el apartado Configurar el conector de la base de datos.

Una vez que hayas rellenado por completo el archivo de configuración, tendrás los ajustes necesarios para implementar el conector.

Indexar el contenido de la base de datos

Una vez que hayas implementado el conector de bases de datos de Cloud Search, se comunicará con la fuente de datos que asociaste a tu cuenta de G Suite y localizará su contenido a través de un procedimiento denominado barrido. Durante el barrido, el conector envía consultas SQL Select al repositorio para obtener datos del documento. El conector obtiene los datos del documento y los sube a la API Indexing, donde se indexan y, finalmente, se sirven a los usuarios.

Inicialmente, el conector de bases de datos realiza un barrido completo, durante el cual lee e indexa todos los registros. Puedes programar la realización de barridos completos a intervalos de tiempo concretos. Además, si tu base de datos las admite, puedes programar barridos incrementales, en los que solo se leen y reindexan los registros que se hayan modificado.

Configuración del conector

Puedes instalar y ejecutar el conector de bases de datos de Cloud Search en prácticamente cualquier entorno que admita aplicaciones Java, aunque tendrás que permitirle acceder tanto a Internet como a la base de datos en cuestión. Como el conector de bases de datos se implementa en un host que es independiente de Google Cloud Search y del repositorio de datos, primero deberás asegurarte de que dispones de la información de G Suite y de la base de datos necesaria para poder asociar Google Cloud Search, el conector y el repositorio de datos. Para que el conector pueda acceder a la base de datos, deberás proporcionarle cierta información cuando lleves a cabo los pasos para configurarlo que se describen en este documento, en el apartado Comportamiento del conector.

Para configurar el acceso del conector a Cloud Search, necesitarás una cuenta de servicio, un ID de cuenta de servicio y un ID de fuente de datos. En la configuración, deberás añadir el ID de la fuente y la ruta al archivo de la clave privada de la cuenta de servicio, tal como se muestra en este ejemplo de archivo de configuración. Por lo general, el administrador de G Suite del dominio podrá proporcionarte estas credenciales.

Una vez que hayas comprobado que tu entorno está configurado correctamente, podrás llevar a cabo los pasos para implementarlo.

Bases de datos compatibles

El conector de bases de datos de Cloud Search funciona con cualquier base de datos SQL que incluya un controlador compatible con JDBC 4.0 o una versión posterior, como:

  • MS SQL Server (2008, 2012, 2014, 2016)
  • Oracle (11g, 12c)
  • Google Cloud SQL
  • MySQL

Debes proporcionar información que permita identificar la base de datos de destino durante el proceso de configuración del conector. Para obtener más información, consulta el apartado Acceso a la base de datos.

Antes de implementar el conector de bases de datos

Antes de implementar el conector de bases de datos de Cloud Search, asegúrate de que tu entorno dispone de lo siguiente:

  • Una clave privada de G Suite, que contiene el ID de la cuenta de servicio
  • Un ID de fuente de datos de G Suite
  • Archivo .jar del conector de bases de datos instalado en un equipo host
  • Base de datos de destino compatible
  • Controlador SQL utilizado para acceder a la base de datos

Pasos de la implementación

Para implementar el conector de bases de datos de Cloud Search, sigue estos pasos básicos:

  1. Descargar y guardar el software del conector de bases de datos de Cloud Search
  2. Configurar el conector de bases de datos de Cloud Search
  3. Ejecutar el conector de bases de datos de Cloud Search

Paso 1. Descargar y guardar el software del conector de bases de datos

Google proporciona el software de instalación del conector en este archivo:

    google-cloudsearch-database-connector-v1-0.0.2.zip

Descarga el conector de bases de datos y descomprímelo en un directorio de trabajo local donde se ejecute el conector. Este directorio también puede contener todos los archivos relevantes necesarios para la ejecución, incluido el archivo de configuración, el archivo de clave de la cuenta de servicio y, de forma opcional, el archivo .jar del controlador JDBC.

Paso 2. Configurar el conector de bases de datos

Para que el conector pueda acceder correctamente a una base de datos e indexar el contenido pertinente, primero es necesario crear su archivo de configuración.

Para crear un archivo de configuración:

  1. Abre el editor de texto que prefieras.
  2. Añade pares clave-valor al contenido del archivo. Para ver directrices, consulta el ejemplo de archivo de configuración.
  3. Dale un nombre al archivo de configuración.

    Puedes elegir el nombre que prefieras, por ejemplo, Mysql.properties. Te recomendamos que mantengas una coherencia en los nombres de las extensiones de archivos de configuración utilizando .config o .properties.

No hace falta que guardes el archivo de configuración en una ubicación estándar, ya que puedes especificar la ruta de acceso en la línea de comandos. Sin embargo, deberá estar en el mismo directorio que el conector para simplificar el control y la ejecución de este último.

Para asegurarte de que el conector reconozca el archivo de configuración, especifica su ruta en la línea de comandos. Si no lo haces, el conector utilizará el nombre de archivo predeterminado connector-config.properties del directorio local. Para obtener más información sobre cómo especificar la ruta de configuración en la línea de comandos, consulta el apartado Ejecutar el conector de bases de datos.

Ejemplo de archivo de configuración

En el siguiente archivo de configuración de ejemplo se muestran los pares clave-valor de los parámetros que definen el comportamiento de un conector de ejemplo. Muchos parámetros tienen valores predeterminados que se utilizan si no se define un valor en el archivo.

#
# data source access
api.sourceId=1234567890abcdef
api.identitySourceId=0987654321lmnopq
api.serviceAccountPrivateKeyFile=./PrivateKey.json
#
# database access
db.url=jdbc:mysql://localhost:3306/mysql_test
db.user=root
db.password=passw0rd
#
# traversal SQL statements
db.allRecordsSql=select customer_id, first_name, last_name, phone, change_timestamp from address_book
db.incrementalUpdateSql=select customer_id, first_name, last_name, phone, change_timestamp from address_book where change_timestamp > ?
#
# schedule traversals
schedule.traversalIntervalSecs=36000
schedule.performTraversalOnStart=true
schedule.incrementalTraversalIntervalSecs=3600
#
# column definitions
db.allColumns=customer_id, first_name, last_name, phone, change_timestamp
db.uniqueKeyColumns=customer_id
url.columns=customer_id
#
# content fields
contentTemplate.db.title=customer_id
db.contentColumns=customer_id, first_name, last_name, phone
#
# setting ACLs to "entire domain accessible"
defaultAcl.mode=fallback
defaultAcl.public=true

Para ver descripciones detalladas de cada parámetro, consulta el apartado Referencia de los parámetros de configuración.

Paso 3. Ejecutar el conector de bases de datos

En el siguiente ejemplo se asume que los componentes necesarios se ubican en el directorio local de un sistema Linux.

Para ejecutar el conector desde la línea de comandos, escribe el siguiente comando:

java -cp "google-cloud-search-database-connector-[version number]:mysql-connector-java-5.1.41-bin.jar"
com.google.enterprise.cloudsearch.database.DatabaseFullTraversalConnector -Dconfig=mysql.config

Detalles del comando:

  • google-cloud-search-database-connector-[version number].jar es el archivo .jar del conector de la base de datos.
  • mysql-connector-java-5.1.41-bin.jar es el controlador SQL utilizado para acceder a la base de datos.
  • mysql.config es el archivo de configuración.

El conector intenta detectar posibles errores de configuración lo antes posible. Por ejemplo, si una columna de la base de datos forma parte del contenido del registro, pero no aparece en la consulta SQL de la base de datos, cuando el conector se inicialice, se indicará que hay un error en esa columna.

Sin embargo, el conector solo detectará otros errores, como una sintaxis de declaración SQL no válida, cuando intente acceder a la base de datos para realizar el primer barrido.

Referencia de los parámetros de configuración

En las secciones siguientes se describen los parámetros de configuración en detalle. En estas secciones, los ejemplos en línea aparecen en este formato:

clave = valor

Donde "clave" (en negrita) es el nombre literal del parámetro específico y "valor" (en cursiva) es el valor específico del parámetro.

Acceso a la fuente de datos

Los primeros parámetros que se deben especificar en cualquier archivo de configuración son los necesarios para acceder a la fuente de datos de Cloud Search. En las instrucciones sobre cómo gestionar fuentes de datos de terceros se describen los pasos necesarios para configurar una fuente de datos.

Ajuste Parámetro
ID de fuente de datos api.sourceId = 1234567890abcdef

Obligatorio. El ID de la fuente de Cloud Search configurado por el administrador de G Suite.

ID de fuente de identidad api.identitySourceId = 0987654321lmnopq

Obligatorio si se utilizan usuarios y grupos externos. El ID de la fuente de identidad de Cloud Search configurado por el administrador de G Suite.

Cuenta de servicio api.serviceAccountPrivateKeyFile = ./PrivateKey.json

Obligatorio. El archivo de clave de la cuenta de servicio de Cloud Search creado por el administrador de G Suite para acceder al conector.

Acceso a la base de datos

Para que el conector pueda barrer una base de datos, primero debes indicar la ruta y las credenciales que permiten al conector iniciar sesión en ella. Utiliza los parámetros de acceso a la base de datos indicados a continuación para añadir información de acceso al archivo de configuración.

Ajuste Parámetro
URL de la base de datos db.url = jdbc:mysql://127.0.0.1/dbname

Obligatorio. La ruta completa de acceso a la base de datos.

Nombre de usuario y contraseña de la base de datos db.user = dbadmin
db.password = pas5w0rd

Obligatorio. Un nombre de usuario y una contraseña válidos con los que el conector accede a la base de datos. Este usuario debe tener acceso de lectura a los registros pertinentes de la base de datos en cuestión.

Controlador JDBC db.driverClass = oracle.jdbc.OracleDriver

Solo es necesario si no se ha especificado el controlador JDBC 4.0 en la ruta de la clase.

Configurar las declaraciones SQL del barrido

El conector realiza un procedimiento de barrido para acceder a los registros de la base de datos e indexarlos. Para que pueda barrer los registros de la base de datos, deberás proporcionar consultas SQL Select en el archivo de configuración. El conector admite dos métodos de barrido:

El conector ejecuta estos barridos conforme a la programación que se haya definido en el archivo de configuración, tal como se describe en el apartado Programar barridos de esta página.

Barrido completo

En un barrido completo se leen todos los registros de la base de datos que se hayan definido en la configuración para indexarse. Este tipo de barridos se deberán llevar a cabo cuando haya que indexar registros nuevos en Cloud Search o sea necesario volver a indexar todos los registros existentes.

Ajuste Parámetro
Barrido completo db.allRecordsSql = SELECT customer_id, first_name, last_name, employee_id, interesting_field FROM employee

O bien

db.allRecordsSql = SELECT customer_id, first_name, last_name, employee_id, interesting_field FROM employee ORDER BY key OFFSET ? ROWS FETCH FIRST 1000 ROWS ONLY

Obligatorio. Este ejemplo incluye una consulta SQL Select que lee todos los registros pertinentes en una base de datos de empleados para indexarlos.

Cuando se use paginación por desplazamiento, la consulta SQL deberá tener un marcador de posición ("?") para permitir un desplazamiento de fila, comenzando por el cero. La consulta se ejecutará varias veces en cada barrido completo, hasta que no se devuelva ningún resultado.

db.allRecordsSql.pagination = offset

Las opciones de paginación válidas son:

  • none: no usar paginación.
  • offset: usar paginación por desplazamiento de fila.

Todos los nombres de columna que el conector vaya a utilizar en cualquier capacidad (contenido, ID único, LCAs) deberán incluirse en esta consulta. El conector realiza algunas verificaciones preliminares durante el inicio para detectar posibles errores y omisiones. Por esta razón, no se debe usar una consulta general "SELECT * FROM…".

Ejemplos de paginación

Para especificar una paginación por desplazamiento y dividir un barrido completo en varias consultas:
# For SQL Server 2012 or Oracle 12c (standard SQL 2008 syntax)
db.allRecordsSql = SELECT customer_id, first_name, last_name, employee_id, interesting_field \
    FROM employee \
    ORDER BY key OFFSET ? ROWS FETCH FIRST 1000 ROWS ONLY
db.allRecordsSql.pagination = offset

o bien

# For MySQL or Google Cloud SQL
db.allRecordsSql = SELECT customer_id, first_name, last_name, employee_id, interesting_field \
    FROM employee \
    ORDER BY key LIMIT 1000 OFFSET ?
db.allRecordsSql.pagination = offset

Barrido incremental

De forma predeterminada, el conector no realiza barridos incrementales. Sin embargo, si tu base de datos contiene campos de marca de tiempo para indicar los registros modificados, puedes configurar el conector para que realice barridos incrementales, que lean y vuelvan a indexar solo los registros que se hayan modificado y las entradas que se hayan añadido recientemente a la base de datos. Como los barridos incrementales leen un conjunto de datos más reducido, pueden ser mucho más eficientes que los barridos completos.

Los parámetros de los barridos incrementales definen el ámbito del barrido e identifican la marca de tiempo utilizada para identificar los registros que se han añadido o modificado recientemente en la base de datos.

Ajuste Parámetro
Barrido incremental db.incrementalUpdateSql = select customer_id, first_name, last_name, employee_id, interesting_field, last_update_time from employee where last_update_time > ?

O bien

db.incrementalUpdateSql = select customer_id, first_name, last_name, employee_id, interesting_field, last_update_time as timestamp_column from employee where last_update_time > ?

Obligatorio cuando se usan barridos incrementales. Si quieres controlar la última actualización registrada en la columna de marca de tiempo de la base de datos, añade timestamp_column a la declaración SQL. En caso contrario, utiliza la marca de tiempo actual del barrido del conector.

Este ejemplo de consulta SQL Select lee todos los registros que se han modificado y, por lo tanto, se deben volver a indexar.

El signo "?", obligatorio en la consulta, es un marcador de posición que representa un valor de marca de tiempo que el conector rastrea y mantiene en las distintas consultas SQL del barrido incremental.

De forma predeterminada, el conector almacena la hora de inicio de la consulta incremental para usarla en el siguiente barrido incremental. Si aún no se ha realizado ningún barrido incremental, se usará la hora de inicio de la ejecución del conector.

Después del primer barrido incremental, Cloud Search almacena la marca de tiempo para que, cuando se reinicie el conector, este pueda acceder a la marca de tiempo del barrido incremental anterior.

Zona horaria de la base de datos db.timestamp.timezone = America/Los_Angeles

Especifica la zona horaria que se usará en las marcas de tiempo de la base de datos. El valor predeterminado es la zona horaria local donde se ejecuta el conector.

Programar barridos

Los parámetros de programación determinan el intervalo de tiempo entre un barrido y el siguiente.

Ajuste Parámetro
Barrido completo después de un intervalo especificado schedule.traversalIntervalSecs = 7200

Especifica el intervalo de tiempo en segundos entre los barridos. El valor predeterminado es 86400 (el número de segundos que tiene un día).

Barrido completo al iniciarse el conector schedule.performTraversalOnStart = false

Indica si el primer barrido completo debe efectuarse inmediatamente después de cada inicio del conector ("true") o no ("false"). El valor predeterminado es "true".

Barrido incremental después de un intervalo especificado schedule.incrementalTraversalIntervalSecs = 900

Especifica el intervalo de tiempo en segundos entre los barridos. El valor predeterminado es 300 (número de segundos equivalente a cinco minutos). Este parámetro no se utiliza si no se define el SQL de barrido incremental.

Definiciones de columna

Para que el conector pueda acceder a los registros de la base de datos e indexarlos, deberás proporcionar información sobre las definiciones de columna en el archivo de configuración. Estas definiciones de columna también permiten al conector detectar posibles errores de configuración cuando se inicia.

Ajuste Parámetro
Todas las columnas db.allColumns = customer_id, first_name, last_name, employee_id, interesting_field, last_update_time, linked_url

Obligatorio. Identifica todas las columnas que se requieren en una consulta SQL cuando se accede a la base de datos. En las consultas se debe hacer referencia de forma explícita a las columnas definidas con este parámetro. Todos los demás parámetros de definición de columna se compararán con este conjunto de columnas.

Columnas de clave única db.uniqueKeyColumns = customer_id
db.uniqueKeyColumns = last_name, first_name

Obligatorio. Indica una sola columna de la base de datos que contiene valores únicos o una combinación de columnas cuyos valores juntos definen un ID único.

Cloud Search requiere que cada documento disponible para búsquedas tenga un identificador único en una fuente de datos. Por este motivo, cada registro de la base de datos debe poder utilizar los valores de sus columnas para definir un ID único. Si ejecutas varios conectores en bases de datos independientes, pero realizas la indexación en un conjunto de datos común, es fundamental que proporciones un ID único en todos los documentos.

Columnas de URL url.format = https://www.example.com/{0}

Define el formato de la URL visible. Los parámetros con números se refieren a las columnas especificadas en db.columns, ordenadas a partir de cero.

Si no se especifica ningún valor, se utilizará el predeterminado: "{0}".

url.columns = customer_id

Obligatorio. Especifica el nombre válido de una o varias columnas incluido en la URL utilizada para obtener un resultado de búsqueda en el que se puede hacer clic. Cuando las bases de datos no tienen una URL pertinente asociada a cada registro, se puede utilizar un enlace estático en todos los registros.

Sin embargo, si los valores de la columna definen un enlace válido para cada registro, se deberán especificar las columnas de la URL de visualización y los valores de configuración de formato.

url.columnsToEscape = customer_id

Especifica columnas de db.columns cuyos valores se codificarán como porcentaje antes de incluirlos en la cadena de URL con formato.

Ejemplos de columnas de URL

Para especificar las columnas utilizadas y el formato de la URL de visualización:

# static URL not using any database record values
url.format = https://www.example.com
url.columns = customer_id

o

# single column value that is the view URL
url.format = {0}
url.columns = customer_url

o

# single column value that will be substituted into the view URL at position {0}
url.format = https://www.example.com/customer/id={0}
url.columns = customer_id
url.columnsToEscape = customer_id

o

# multiple column values used to build the view URL (columns are order dependent)
url.format = {1}/customer={0}
url.columns = customer_id, linked_url
url.columnsToEscape = customer_id

Parámetros de configuración de metadatos

Los parámetros de configuración de metadatos describen las columnas de la base de datos que se utilizan para rellenar los metadatos del elemento. Si el archivo de configuración no contiene estos parámetros, se utilizarán los valores predeterminados. En la tabla siguiente se muestran estos parámetros.
Ajuste Parámetro
Título itemMetadata.title.field=movieTitle
itemMetadata.title.defaultValue=Gone with the Wind
El atributo de metadatos que contiene el valor correspondiente al título del documento. El valor predeterminado es una cadena vacía.
Marca de tiempo de creación itemMetadata.createTime.field=releaseDate
itemMetadata.createTime.defaultValue=1940-01-17
El atributo de metadatos que contiene el valor de la marca de tiempo de creación del documento.
Hora de última modificación itemMetadata.updatetime.field=releaseDate
itemMetadata.updatetime.defaultValue=1940-01-17
El atributo de metadatos que contiene el valor de la marca de tiempo de la última modificación del documento.
Idioma del documento itemMetadata.contentLanguage.field=languageCode
itemMetadata.contentLanguage.defaultValue=en-US
El idioma del contenido de los documentos que se van a indexar.
Tipo de objeto de esquema itemMetadata.objectType=movie
El tipo de objeto utilizado por el conector, tal como se indica en las instrucciones sobre cómo crear y registrar un esquema. Si no se especifica esta propiedad, el conector no indexará ningún dato estructurado.

Si fuera necesario, las propiedades de este objeto de esquema deberán especificarse en las consultas SQL definidas en la configuración. Esto generalmente se consigue añadiendo alias a las declaraciones SQL. Por ejemplo, supongamos que en una base de datos de películas, el esquema de fuente de datos contiene una definición de propiedad llamada "ActorName". Una declaración SQL podría ser: select …, last_name as ActorName, … from … .

Cada columna que coincide con el nombre de una propiedad del objeto de esquema se pasa automáticamente con el registro de la base de datos indexada y se utiliza como datos estructurados en la fuente de datos.

Nota: Esta propiedad de la configuración dirige a un valor en lugar de a un atributo de metadatos, y los sufijos .field y .defaultValue no se admiten.

Formatos de fecha y hora

Los formatos de fecha y hora indican los formatos esperados en los atributos de metadatos. Si el archivo de configuración no contiene este parámetro, se utilizarán los valores predeterminados. En la tabla siguiente se muestra este parámetro.
Ajuste Parámetro
Formatos de fecha y hora adicionales structuredData.dateTimePatterns=MM/dd/uuuu HH:mm:ssXXX
Una lista separada por punto y coma de patrones java.time.formatDateTimeFormatter adicionales. Los patrones se utilizan para analizar valores de cadena de cualquier campo de fecha o fecha y hora en los metadatos o los esquemas. Aunque el valor predeterminado es una lista vacía, los formatos RFC 3339 y RFC 1123 son compatibles en todos los casos.

Campos de contenido

La ventaja de indexar los valores de registro de la base de datos en Cloud Search es que se pueden preparar para hacer búsquedas en ellos. Utiliza las opciones de contenido para definir qué valores de registro deben formar parte del contenido disponible para búsquedas.

Ajuste Parámetro
Columnas de datos de contenido db.contentColumns = customer_id, first_name, last_name

Especifica columnas de contenido en la base de datos. Cuando designas columnas de contenido, se les aplica formato y se suben a Cloud Search como contenido de documento disponible para búsquedas.

Si no especificas un valor, el valor predeterminado será "*", que indica que todas las columnas deben incluirse como contenido.

Columnas de la plantilla de contenido contentTemplate.db.title = customer_id

Obligatorio. El formato que se aplica a las columnas de datos de contenido para su indexación está basado en una plantilla de contenido. La plantilla define la prioridad de cada valor de la columna de datos para hacer las búsquedas. La definición de columna de mayor calidad es la columna obligatoria "title".

contentTemplate.db.quality.high = first_name, last_name
contentTemplate.db.quality.medium = interesting_field
contentTemplate.db.quality.low = employee_id

Puedes designar todas las demás columnas de contenido como campos de calidad de búsqueda alta, media o baja. Todas las columnas de contenido no definidas en una categoría específica tienen una calidad baja de forma predeterminada.

Columna de blob db.blobColumn = blob_data

Indica el nombre de una sola columna de blob que se usará en el contenido del documento en lugar de una combinación de columnas de contenido.

Si se especifica una columna de blob, pero también se definen columnas de contenido, se considerará un error. Sin embargo, sí se permiten definiciones de columnas de datos estructurados y metadatos junto con las columnas de blob.

Opciones de las listas de control de acceso

Hay varias formas de proteger el acceso de los usuarios a registros indexados con LCAs.

Ajuste Parámetro
Todo el dominio defaultAcl.mode = override
defaultAcl.public = true

Los modos válidos son:

  • none: no utilizar la LCA predeterminada.
  • fallback: usar la LCA predeterminada solo si no hay ya una.
  • append: añadir la LCA predeterminada a la actual.
  • override: sustituir la LCA actual por la predeterminada.

Si el valor asignado a defaultAcl.mode es "override" y el asignado a defaultAcl.public es "true", estos parámetros especificarán el acceso al dominio completo, donde los registros de la base de datos indexados estarán accesibles de forma pública para todos los usuarios del dominio. El valor de modo determina cuándo se aplicará la LCA pública.

Si el valor asignado a defaultAcl.mode es none, los registros no estarán disponibles para búsquedas sin LCA individuales definidas.

LCA definida común defaultAcl.mode = fallback
defaultAcl.public = false
defaultAcl.readers.users = user1, user2,
google:user3
defaultAcl.readers.groups = google: group1, group2
defaultAcl.denied.users = user4, user5
defaultAcl.denied.groups = group3

Si defines todos estos parámetros, el conjunto completo especificará una LCA "definida común" que se usará en cada registro de la base de datos que no contenga una definición de LCA individual. Esta LCA común se usa para controlar el acceso a la base de datos completa, según el modo que se haya seleccionado.

Se asumirá que cada usuario y grupo se ha definido en el dominio local a menos que tenga el prefijo "google:" (constante literal).

LCA individual Si los parámetros de configuración especifican LCA individuales, cada registro contendrá su propia información de LCA en sus valores de columna.

Si cada registro de la base de datos contiene información de LCA individual para definir su propio acceso, la consulta SQL deberá contener alias de columnas constantes literales reservadas para que el conector sepa cómo obtener los "lectores" y los usuarios "rechazados". Si las siguientes constantes literales reservadas están presentes en las consultas SQL, no hará falta ninguna configuración adicional.

readers_users

readers_groups

denied_users

denied_groups

Ejemplos de consultas SQL de LCA individuales

En los ejemplos siguientes se muestran consultas SQL Select que utilizan LCAs "individuales":

db.allRecordsSql = select customer_id, first_name, last_name,  employee_id, interesting_field, last_update_time, permitted_readers as readers_users, denied_readers as denied_users, permitted_groups as readers_groups, denied_groups as denied_groups from employee

db.incrementalUpdateSql = select customer_id, first_name, last_name,  employee_id, interesting_field, last_update_time, permitted_readers as readers_users, denied_readers as denied_users, permitted_groups as readers_groups, denied_groups as denied_groups from employee where last_update_time > ?

Referencia rápida

En la tabla siguiente se indican los parámetros obligatorios y opcionales más importantes que corresponden al conector de la base de datos, así como sus valores predeterminados.

Parámetro Descripción
db.driverClass Predeterminado: cadena vacía

El controlador JDBC que se usará con el conector:

db.driverClass = oracle.jdbc.OracleDriver

db.url Obligatorio

Define la URL de la base de datos:

db.url = jdbc:mysql://localhost:3306/dbname
db.user Predeterminado: cadena vacía

El usuario de la base de datos que el conector utiliza para consultarla:

db.user = dbadmin

db.password Predeterminado: cadena vacía

La contraseña del usuario de la base de datos que el conector utiliza para consultarla:

db.password = pas5w0rd
db.allRecordsSql Obligatorio

Define una consulta SQL para obtener todas las columnas relevantes del registro de la base de datos:

db.allRecordsSql = select customer_id, first_name, last_name, employee_id, interesting_field from employee
db.allRecordsSql.pagination Predeterminado = none

Especifica una de las siguientes opciones de paginación:

  • none: no usar paginación.
  • offset: usar paginación por desplazamiento de fila.

db.allRecordsSql.pagination = offset

db.incrementalUpdateSql Predeterminado: desactivado (cadena vacía)

Consulta de barrido incremental para obtener documentos que se han modificado recientemente, por lo general por su marca de tiempo:

db.incrementalUpdateSql = select customer_id, first_name, last_name, employee_id, interesting_field, last_update_time from employee where last_update_time > ?

db.timestamp.timezone Predeterminado: usar la misma zona horaria (cadena vacía)

Especifica la zona horaria del servidor de la base de datos cuando hay una diferencia entre las zonas horarias del servidor de la base de datos y del conector:

db.timestamp.timezone = America/Los_Angeles
schedule.
traversalIntervalSecs
Predeterminado: 86400 (segundos que hay en un día)

Intervalo de barrido completo: la llamada al método de barrido del conector se realiza en la programación siguiente:

schedule.traversalIntervalSecs = 7200
schedule.
performTraversalOnStart
Predeterminado: "true"

Invocar un barrido completo al inicio:

schedule.performTraversalOnStart = false
schedule.
incrementalTraversalIntervalSecs
Predeterminado: 300

Número de segundos que transcurren entre las invocaciones del barrido incremental para registros modificados (se requiere db.updataSql):

schedule.incrementalTraversalIntervalSecs = 900
db.allColumns Obligatorio

Todos los nombres y alias de columna en la consulta SQL principal que se utilizarán en la definición de cualquier otra columna:

db.allColumns = customer_id, first_name, last_name, employee_id, interesting_field, last_update_time, linked_url
db.uniqueKeyColumns Obligatorio

Uno o varios nombres de encabezados de columna (con el formato name:type) separados por comas que proporcionan un identificador único del resultado de una consulta de base de datos:

db.uniqueKeyColumns = customer_id
url.format Predeterminado: {0}

Especifica el formato de las columnas de URL:

url.format = https://www.example.com/employee/id={0}
url.columns Obligatorio

Especifica las columnas de una consulta SQL que se usarán para crear una URL visible que se utilizará en los resultados de búsqueda:

url.columns = customer_id
url.columnsToEscape Predeterminado: cadena vacía

Especifica columnas de db.columns cuyos valores se codificarán como porcentaje antes de incluirlos en la cadena de URL con formato:

url.columnsToEscape = customer_id
itemMetadata.title.field Predeterminado: cadena vacía

Especifica la columna del registro que se usará en los metadatos "title":

itemMetadata.title.field = customer_id
itemMetadata.createTime.field Predeterminado: cadena vacía

Especifica la columna del registro que se utilizará en los metadatos "fecha de creación":

itemMetadata.createTime.field = created_timestamp
itemMetadata.updatetime.field Predeterminado: cadena vacía

Especifica la columna del registro que se usará en los metadatos "fecha de modificación":

itemMetadata.updatetime.field = last_update_time
itemMetadata.contentLanguage.field Predeterminado: cadena vacía

Especifica la columna del registro que se utilizará en los metadatos "idioma":

itemMetadata.contentLanguage.field = language_used
itemMetadata.objectType Predeterminado: cadena vacía

Especifica la columna del registro que se usará en el esquema "object". Nota: Este es un nombre literal y no un valor de columna.

itemMetadata.objectType = schema_object_name
db.contentColumns Predeterminado: * (todas las columnas de db.allRecords.SQL)

Define las columnas de una consulta SQL que se usarán para obtener el contenido del registro de la base de datos:

db.contentColumns = customer_id, first_name, last_name
contentTemplate.db.title Obligatorio

Especifica el título del contenido HTML y el campo de mayor calidad de búsqueda:

contentTemplate.db.title = id
contentTemplate.db.quality.high Predeterminado: cadena vacía

Especifica los campos de contenido que tienen un valor de calidad de búsqueda alta:

contentTemplate.db.quality.high = first_name, last_name
contentTemplate.db.quality.medium Predeterminado: cadena vacía

Especifica los campos de contenido que tienen un valor de calidad de búsqueda media:

contentTemplate.db.quality.medium = interesting_field
contentTemplate.db.quality.low Predeterminado: todos los campos no especificados tienen de forma predeterminada un valor de calidad de búsqueda baja.

Especifica los campos de contenido que tienen un valor de calidad de búsqueda baja:

contentTemplate.db.quality.low = employee_id
db.blobColumn Predeterminado: cadena vacía

Especifica que la base de datos utilizará una única columna de blob para el contenido del registro:

db.blobColumn=blob_data
defaultAcl.mode Predeterminado = none

Especifica uno de los siguientes modos de LCA:

  • none: no utilizar la LCA predeterminada.
  • fallback: usar la LCA predeterminada solo si no hay ya una.
  • append: añadir la LCA predeterminada a la actual.
  • override: sustituir la LCA actual por la predeterminada.

defaultAcl.mode = override

defaultAcl.public Valor predeterminado: false

Especifica que la LCA predeterminada utilizada en todo el repositorio es pública:

defaultAcl.public=true
defaultAcl.readers.users Solo se utiliza si el valor asignado a defaultAcl.mode es "fallback" y el asignado a defaultAcl.public es "false".

Especifica los lectores de LCA comunes en una lista delimitada por comas:

defaultAcl.readers.users=user1,user2,user3
defaultAcl.readers.groups Solo se utiliza si el valor asignado a defaultAcl.mode es "fallback" y el asignado a defaultAcl.public es "false".

Especifica los lectores de LCA comunes en una lista delimitada por comas:

defaultAcl.readers.groups=group1,group2
defaultAcl.denied.users Solo se utiliza si el valor asignado a defaultAcl.mode es "fallback" y el asignado a defaultAcl.public es "false".

Especifica los usuarios rechazados en todo el repositorio:

defaultAcl.denied.users=user4,user5
defaultAcl.denied.groups Solo se utiliza si el valor asignado a defaultAcl.mode es "fallback" y el asignado a defaultAcl.public es "false".

Especifica los grupos permitidos en todo el repositorio:

defaultAcl.denied.groups=group3
defaultAcl.name Valor predeterminado: DEFAULT_ACL_VIRTUAL_CONTAINER

Especifica el nombre del contenedor virtual al que se aplica la LCA predeterminada:

defaultAcl.name = employee-db-default-acl
traverse.updateMode Predeterminado: SYNCHRONOUS

Especifica que los barridos utilizan el modo de actualización síncrono (frente a las actualizaciones asíncronas):

traverse.updateMode = ASYNCHRONOUS
traverse.exceptionHandler Predeterminado: 0

Especifica si el barrido debe ignorarse ("ignore"), anular en todos los casos ("0") o anular después de que se detecte un número específico de excepciones ("10"):

traverse.exceptionHandler = ignore