HCL Commerce Version 9.1.10.0 or later

Cambios de la versión en NiFi

Los cambios en los conectores NiFi se han realizado en tres versiones: en 9.1.7.0, 9.1.8.0, 9.1.9.0 y 9.1.11.1. Se describen en orden.

Cambios en la versión 9.1.7

i. El grupo de procesos Buscar artículos secundarios se ha eliminado de la etapa 1b del producto
El grupo de procesos Buscar artículos secundarios se ha eliminado de la etapa 1b del producto. La lógica de búsqueda artículos secundarios se mueve a una nueva etapa denominada Etapa de producto 1h.
ii. La etapa 1f del producto (atributos rollup) y sus WaitLink y RefreshLink se han eliminado
La lógica de acumulación se ha combinado en la etapa 1e del producto para obtener un mejor rendimiento.
iii. La etapa 2 del producto (pushdown) y sus WaitLink y RefreshLink se han eliminado
La lógica de atributo pushdown se ha combinado ahora en la etapa 1e del producto para obtener un mejor rendimiento. Otras áreas de lógica pushdown se han combinado con otras etapas.
iv. La etapa de producto 1c (anular temporalmente atributos secundarios) y sus WaitLink y RefreshLink se han eliminado
La lógica de atributo secundario de anulación de atributo secundario ya no es necesaria con la nueva lógica de la etapa de producto 1e.
v. La etapa de producto 1d (buscar adjunto de artículo) y sus WaitLink y RefreshLink se han eliminado
La lógica de búsqueda de adjunto de elemento ya no es necesaria con la nueva lógica en la etapa de producto 1b.
vi. NRT/Dataload ProductStage4, DatabaseProductStage1e-2 y DatabaseProductStage1f-2 se han eliminado
La lógica de estas etapas ya no es necesaria con la nueva lógica optimizada. ProductStage4 y ProductStage1e-2 también se han eliminado de la canalización de carga de datos.

Cambios en la versión 9.1.8

i. Se ha eliminado ProductStage 1f
Las etapas en sentido ascendente (1e) y descendente (1f) del conector de atributos de producto se han combinado en una etapa de mayor rendimiento, la etapa de producto 1e.
iii. CategoryStage2 se ha cambiado a la etapa de categoría 1d y se ha rediseñado
Anteriormente, CategoryStage2 creaba la jerarquía de categorías consultando Elasticsearch. En la versión 9.1.8, la jerarquía de categorías se crea leyendo de la base de datos para mejorar el rendimiento y la fiabilidad.

Cambios en la versión 9.1.9

i. URLStage2a y URLStage2b se han eliminado junto con sus Waitlinks
La etapa 1a de la URL se ha actualizado para escribir el índice de URL y el índice de categorías (añadir SEO) al mismo tiempo. Esto evita problemas en los que la etapa 2a de la URL consulta Elasticsearch antes de completar el documento de URL.
Dado que la etapa 1a de la URL (copiar en la categoría) ya añade SEO al índice de categorías, la etapa 2a de la URL ya no es necesaria y se ha eliminado. Lo mismo se aplica a la etapa 1b de la URL (copiar en el producto) y se ha eliminado.
ii. Se ha eliminado CategoryStage4 (supresión de categorías) en canalizaciones NRT y Live
CategoryStage4 (supresión de categorías) se ha eliminado antes de la etapa de categoría 1a (documento principal). Esta etapa se ha utilizado anteriormente para manejar casos Edge para su supresión. Dado que la jerarquía de catálogos se crea ahora directamente desde la base de datos, esta etapa ya no es necesaria y se puede eliminar. Este cambio mejora el tiempo de indexación general.

Cambios de release de 9.1.12

Los siguientes cambios se aplican a los esquemas de categoría, producto y atributo.

I. Se han añadido nuevos analizadores.
Estos analizadores utilizan distintos tokenizadores y filtros, que se aplican a diferentes campos de índice para realizar el proceso de análisis de texto en los términos durante la ingesta y en el momento de la indexación, y durante el proceso de consultas y el tiempo de ejecución de búsqueda.
custom_splitter
Tokenizador de palabras clave.
custom_shingle
Utiliza un tokenizador estándar.
custom_analyzer
Utiliza un tokenizador estándar.
Consulte la documentación de Elasticsearch para obtener detalles adicionales sobre el análisis de texto.
II. Se han añadido nuevos filtros.
Ahora se pueden utilizar los siguientes filtros de Elasticsearch dentro de los tokenizadores personalizados para convertir (normalizar, preprocesar, etc.) los valores de campo de índice y así poder utilizarlos en el índice de Elasticsearch
  • html_strip_filter

    Elimina elementos html del texto y sustituye entidades html por sus valores descodificados.

  • asciifolding

    Convierte caracteres alfabéticos, numéricos y simbólicos que no están en el bloque Basic Latin Unicode.

  • word_delimiter_filter

    Divide tokens con caracteres no alfanuméricos.

  • shingle_filter

    Añade tablillas o n-gramas de palabras a un flujo de tokens concadenando tokens adyacentes.

  • trim_filter

    Elimina los espacios en blanco iniciales y finales de cada señal de una secuencia.

III. La propiedad del normalizador ha cambiado
La propiedad normalizador ha cambiado de minúsculas a normalizada, porque no solo cambia la palabra a minúsculas, sino que también realiza el plegado ASCII. Este normalizador se utiliza en todos los campos de índice normalizados.