Mejoras de rendimiento para el carro de la compra muy extenso

Los siguientes mandatos del carro de la compra se han mejorado para el rendimiento: OrderItemAdd, OrderItemUpdate, OrderItemDisplay. Estos cambios optimizan los mandatos para que se puedan obtener mejoras del rendimiento, especialmente en aquellos casos en los que los carros de la compra suelen contener cientos de artículos de pedido.

Anteriormente, cada vez que se llamaba a estos mandatos, se efectuaba un cálculo de precios, se comprobaba el inventario y se actualizaba la asignación de inventario. Cuando el carro de la compra contiene muchos artículos, esto afecta de forma negativa al rendimiento. Ahora estos mandatos tienen dos parámetros nuevos, doPrice y doInventory, que actúan de conmutadores para activar o desactivar las subtareas de precio e inventario.

Si bien estas subtareas son muy importantes, pueden llamarse con menor frecuencia para obtener mejoras del rendimiento sin que esto afecte de forma negativa a la integridad del inventario o del pedido. Por ejemplo, podría dividir las llamadas en subtareas entre los mandatos de la forma siguiente:

Mandato de pedido Subtareas realizadas
OrderItemAdd Cálculo de precios
OrderItemUpdate Actualizar información de artículos de pedido
OrderPrepare Cálculo de precios, comprobación y asignación de inventario, cálculos de envío y de impuestos

Los mandatos siguientes solo dan soporte a la habilitación e inhabilitación de cálculo de precios.

  • OrderCalculate
  • QuoteItemAdd
  • QuoteItemUpdate

Límites a esta solución:

  1. Los clientes no obtendrán un reflejo inmediato de los cambios de precios, cambios de autorización para el producto o cambios de nivel de inventario cuando las subtareas de precio e inventario estén desactivadas en algunos URL.
  2. Si el cliente crea un carro de la compra, no lo envía pero vuelve más adelante, el precio caduca. En este caso, el precio siempre se renueva. Sin embargo, dado que esto no es común, afecta muy poco al rendimiento.
  3. Si QuoteGoodFor es pequeño, la eliminación de subtareas de cálculo de precios no mejora el rendimiento. El precio siempre se renueva cuando caduca el precio ofrecido.

El rendimiento de los mandatos OrderItemAdd, OrderItemUpdate, QuoteItemAdd y QuoteItemUpdate puede mejorarse todavía más eliminando algunos bucles ineficaces cuando llaman a los demás mandatos de tareas.

Invalidación de precios caducados

Si un cliente añade un artículo al carro de la compra, el precio se calcula. No obstante, si el pedido no se envía durante un largo período de tiempo, el precio de oferta puede haber cambiado, por lo que el precio calculado para el carro de la compra no será válido. En este caso, el precio debe volverse a calcular cuando el cliente vuelva a acceder al carro de la compra. Como soporte a esto, se introduce un nuevo distintivo en ORDERITEMS.PREPAREFLAGS denominado PREPAREFLAGS_PRICE_REFRESHED. Los mandatos OrderItemBaseCmdImpl y OrderCalculate llaman a un nuevo mandato de tarea,CheckAndResetOrderItemPriceFlagCmd, que comprueba si el precio caduca. Si el precio ha caducado, se vuelve a calcular el precio.

La implementación predeterminada de esta nueva tarea se define de la manera siguiente:

  1. Si STORE.PRICEREFFLAG es "8", la tarea agrupa todos los artículos del pedido con el mismo catentryId.
  2. Si uno de los artículos del pedido para un catentryId determinado ha caducado o el distintivo de precio binario (PREPAREFLAGS_PRICE_REFRESHED) es 0, la tarea restablece el distintivo de precio para todos los artículos del pedido con el mismo catentryId.
  3. Si STORE.PRICEREFFLAG no es "8", la tarea comprueba si cada artículo del pedido ha caducado. En este caso, restablece el distintivo de precio binario para el artículo del pedido.

Esto se expresa en la fórmula siguiente:

Si STORE.QUOTEGOODFOR (unidad: segundo) <= (CurrentTime - ORDERITEMS.LASTCREATE)/1000 (unidad de tiempo: milisegundo), se indica que el artículo de pedido ya ha caducado.

Si el recálculo de precios está desactivado al actualizar precios para artículos de pedido, los mandatos OrderItemAdd, OrderItemUpdate, OrderItemDisplay y OrderCalculate comprueban el distintivo de bit PREPAREFLAGS_PRICE_REFRESHED. Si el distintivo es 1, el precio del artículo de pedido no se renueva. Si el distintivo es 0, el precio se renueva y el distintivo se establece en 1.

Puede personalizar el mandato de tarea CheckAndResetOrderItemPriceFlag para que implemente su propia lógica para restablecer el distintivo PREPAREFLAGS_PRICE_REFRESHED.

Optimización del cálculo de envío e impuestos

Los impuestos y los costes de envío se evalúan de forma diferente. Esto provoca un incremento del rendimiento del mandato OrderPrepare, que llama a los cálculos de impuestos y de envío.

En la mayoría de las implementaciones de impuestos y envío, hay muchas normas configuradas para un código. En general, cada norma de cálculo de envío es específica para una sola combinación de un centro de despacho de pedidos, una modalidad de envío y una jurisdicción de envío. Del mismo modo, las normas de cálculo de impuestos son específicas para una sola combinación de un centro de despacho de pedidos y un grupo de jurisdicciones fiscales. Para cada una de estas normas, se llama a un determinado mandato para evaluar si la norma se aplica a un artículo en el carro de la compra.

Las implementaciones de mandatos, FastShippingRuleCombineCmdImpl y FastTaxRuleCombineCmdImpl, están pensadas para que las utilicen tiendas que tienen un gran número de normas de envío o de impuestos.

  • FastShippingRuleCombineCmdImpl agrupa artículos de pedido en función de su ShipMode, shipAddress y fulfillmentCenter, antes de determinar si una determinada norma de envío se aplica al grupo.
  • FastTaxRuleCombineCmdImpl agrupa artículos de pedido en función de su código de impuestos, centro de despacho de pedidos, dirección de envío (jurisdicción) y categoría de impuestos, antes de determinar si una determinada norma de envío se aplica al grupo.

La memoria caché también se amplía para mejorar la lógica de búsqueda de normas. Cada vez que el sistema busca las normas de envío para un código de envío, los datos se pueden obtener de la memoria caché en función del código de envío, modalidad de envío, centro de despacho de pedidos y dirección de envío (jurisdicción). Para cálculo de impuestos, las normas se pueden obtener de la memoria caché en función del código de impuestos, centro de despacho de pedidos, dirección de envío (jurisdicción) y categoría de impuestos.

Esta solución mejora el rendimiento en las siguientes situaciones:

  1. Existe un gran número de normas definidas para los costes de envío o impuestos y se presupone que cada artículo del pedido solo calificará a un pequeño subconjunto de dichas normas.
  2. En el caso de un carro de la compra muy extenso, si la mayoría de artículos del pedido se envían a la misma dirección, con la misma modalidad de envío (solo para el envío) y el inventario se asigna en el mismo centro de despacho de pedidos.

Optimización de los principales mandatos de flujo de envío

Los carros de la compra muy extensos tienen las siguientes características:

  • Al importar una configuración de artículos extensa en el carro de la compra, los parámetros de entrada son números de piezas en lugar de los ID de entrada de catálogo, dado que la configuración XML viene generada por una herramienta externa.
  • Muchos números de piezas están duplicados. Estos artículos con los mismos números de piezas se agrupan en diferentes configuraciones.
  • Al invocar el mandato OrderItemUpdate para actualizar el carro de la compra, las cantidades de la mayoría de artículos de pedido no cambian. En la mayoría de los casos, solo cambian las direcciones de envío y los métodos de envío.

Estas suposiciones eran la base de las optimizaciones de los mandatos OrderItemAdd y OrderItemUpdate.

El código predeterminado contiene un bucle que se repite para cada uno de los artículos por separado y se añaden o actualizan cada vez los artículos de pedido. En la actualidad, cuando se añaden varios artículos al carro de la compra, cada artículo del pedido individual se procesa mediante esta lógica:

  1. Si se ha pasado un ID de número de pieza, resuelva el número de pieza en un ID de entrada de catálogo.
  2. Llame al mandato de tarea ResolveSku para resolver el código de artículo.
  3. Compruebe la autorización para el producto.
  4. Compruebe si el producto se puede adquirir.
  5. Cree el artículo de pedido en la base de datos.
  6. Resuelva el número de pieza del ID de entrada de catálogo y actualice el número de pieza en orderitem.
  7. Actualice los demás campos del artículo de pedido.
La lógica del mandato se ha mejorado:
  1. Resuelva números de piezas en ID de entrada de catálogo para todos los artículos, omitiendo los números de piezas duplicados que ya se han resuelto.
  2. Resuelva los códigos de artículo para todos los artículos, omitiendo los códigos de artículo duplicados que ya se han resuelto.
  3. Compruebe la autorización para el producto de todos los artículos, omitiendo los artículos duplicados cuya autorización ya se ha determinado.
  4. Determine si el producto se puede adquirir para todos los artículos, omitiendo los artículos duplicados.
  5. Cree todos los artículos de pedido en la base de datos.
  6. A menos que el número de pieza se suministre como parámetro de entrada, resuelva el número de pieza del ID de entrada de catálogo y actualice el número de pieza en el artículo de pedido. Esto se suele suministrar mediante herramientas de configuración externas, de forma que en estos casos se puede omitir el paso.
  7. Actualice los demás campos para todos los artículos de pedido.

Además, estos cambios mejoran el rendimiento en el caso del carro de la compra muy extenso:

  1. Si los parámetros de dirección no se han pasado, se resuelven una vez y se aplican a todos los artículos del pedido.
  2. Si el parámetro de modalidad de envío no se ha pasado, se resuelve una vez y se aplica a todos los artículos del pedido.
  3. En el caso del mandato OrderItemUpdate, si todos los parámetros de cantidad que se han pasado coinciden con los de la base de datos- el precio y el inventario no tienen que cambiar. Esto sucede cuando se efectúan determinadas actualizaciones, tales como cambiar la dirección de envío o la modalidad de envío.