Magento Enterprise Edition y el cambio de modelo

Hace una semana se supo, vía webinar, que Varien iba a cambiar su modelo de negocios.

Previo al anuncio, se especulaba con cuál sería el cambio. Se esperaba ver cómo cambiaba el programa de Partners y qué más podía pasar.

Alguno especulaban con la convivencia de dos versiones, una paga y otra open source.

En lo personal, por un aviso previo que hubo sobre la interacción con la comunidad de desarrolladores, llegué a pensar que no iba a pasar. Creo que por eso peor me cayeron los anuncios que se hicieron posteriormente.

Básicamente, se planteó la convivencia de la versión Enterprise Edition y de la Community Edition. Además, se habló de los esperados cambios en el programa de Partners (y del aumento de tarifas que modifican incluso los programas que todavía podrían estar vigentes con el actual régimen).

En el día de ayer, hubo otro webinar, el cual no me perdí. Ahi se explicaron con mayor grado de detalle las diferencias que se presentaran entre ambas versiones (y por las preguntas del final, saltaron un par de datos adicionales).

La presentación empezó planteando seis temas a tratar.

  1. Ventas privadas (cerradas) y eventos (y algo más que ahora no recuerdo).
  2. Manejo avanzado de roles (ACL) y trackeo.
  3. Trackeo de actividades en el backend y content staging (no se me ocurre como traducirlo).
  4. Gifts certificates/cards (nuevo tipo de producto).
  5. Crédito para los clientes en la tienda.
  6. Cambios en la seguridad.

Estos nuevos temas o funcionalidades, sólo van a estar presentes en la versión Enterprise, así que para los que vayan a utilizar la versión Community, ya pueden ir borrando la sonrisa de satisfacción, dado que en el corto plazo no va a ser algo que se pueda disfrutar.

Vamos a recorrer los comentado sobre cada punto.

Ventas privadas y eventos

Las ventas privadas o cerradas, son ventas diferenciales a un grupo de clientes específicos durante una ventana de tiempo determinada. Esto puede aplicarse para un grupo específico o para un grupo de grupos.

Tiene un detalle estético en el frontend, que muestra (si es que el usuario del grupo en cuestión está logueado) un indicador que alerta sobre el tiempo que resta para que finalice esa promoción.

También va a ser posible que esos usuarios registrados, miembros del grupo que posee la promoción, puedan invitar a otros usuarios o clientes a disfrutar del beneficio.

Todo esto es configurable desde el backend, dentro de un nuevo set de opciones en la configuración, algunas dentro de las opciones de catálogo; otras tienen ítems específicos.

Esas opciones permiten parametrizar cuestiones como:

  • Imagen de la promoción (se llaman «catalog events»).
  • Lugar en el cual se muestra la imagen (categoría y/o detalle de producto).
  • Categorías sobre las cuales se aplica la promoción.
  • Control de las invitaciones, pudiéndose especificar si están habilitadas, número posible, vigencia, quiénes pueden invitar, etc.
  • Se especifica si la venta diferencial es para todos los grupos, o para uno o varios en particular.
  • Puede indicarse si una categoría es visible para todo el mundo o para un grupo en particular.

Manejo de roles

En éste tema se viene un cambio fuerte.

En ésta versión podrán manejarse los roles y acciones a nivel website y/o store view. Con esto se abre el capítulo multitenant para Magento (si bien se contemplan varios casos que incluso involucran B2B, aunque no entran todos los escenarios de multitenancy).

De ahora en más (siempre en la versión Enterprise, claro está), al crear un rol, tendremos la opción de elegir el scope del rol. Puede elegirse un website completo o un sotre view específico (o la combinación de esos dos elementos que se les ocurra si tienen múltiples websites con múltiples store views).

Lo que podremos separar para que sólo pueda gestionarse según el alcance de esos permisos son:

  • Catálogo (productos, categorías, etc).
  • Promociones.
  • Ordenes (acá se pone interesante).

Logs de actividades y content staging

Por un lado, una funcionalidad ultra requerida (y sólo ahora se entiende por qué no estaba disponible), es el log de actividades en el backend. Desde ahora, cada acción hecha por cualquier usuario que gestione las tiendas, quedan grabadas en un log por u período dado (configurable desde las nuevas opciones).

Por el otro lado, como funcionalidad nueva, tenemos el llamado content staging. ¿Qué es esto?.

Para simplificar el concepto, lo que obtenemos es un entorno de staging con nuestro catálogo y páginas (y otros elementos) corriendo sobre nuestra tienda en producción. En el ejemplo, existía un website productivo y un website de staging.

En el website de staging se prueban cambios, de diseño, de contenido, de precios, de orden de productos, etc, etc, etc. Luego de probar y validar los cambios, éstos se publican al site productivo.

Definitivamente, un gol desde mitad de cancha a nivel funcional.

Si el cambio es muy grande, puede configurarse la plataforma para que “cierre” la tienda durante el proceso de actualización y hasta indicar cuál será la página que se mostrará en lugar de la tienda.

Para correr el proceso de actualización, se seguirían más o menos estos pasos:

  • Se seleccionan qué elementos van a ser pasados de staging a producción.
  • Se mapea desde qué entorno de staging a qué entorno de producción se hará.
  • Selección optativa de backup previo al proceso.
  • Proceso bajo demanda o programado.
  • Una vez finalizo se genera un log mostrando quién hizo los cambios y qué se cambió.

Gifts certificates / cards

Se agrega un nuevo tipo de producto: los certificados (virtuales o físicos).

Seguramente la traducción suene rara, y el nombre en inglés suene a algo que no se ajusta del todo al castellano. Espero que la explicación sobre qué es ayude a entenderlo.

Un producto de éste tipo, habilita a comprar crédito para comprar en la tienda. El detalle de ser virtual o físico, se basa en que si es virtual, se asocia a un usuario registrado. Si es físico, se trataría de una tarjeta literalmente física, con un código a utilizar como cupón de descuento.

El producto puede configurarse para que al comprarlo, se ingrese la suma de crédito a comprar. Incluso pueden prefijarse valores.

Al ser un producto, puede comprarse y enviársele (regalarse) a otra persona para que pueda comprar en la tienda.

En el backend pueden configurarse las siguientes cuestiones para este tipo de producto:

  • Formato del código.
  • Longitud del código.
  • Prefijo.
  • Sufijo.
  • Uso de guiones medios.
  • Establecer si el certificado es redeemable (esto quiere decir si es pasible de ser devuelto a quien lo compró).
  • Fecha de expiración.
  • Notificaciones para quien lo regala.
  • Detalle en las órdenes del uso del certificado.

Crédito en las tiendas

Este punto tiene relación con el anterior.

A partir de ahora, podrá asignarse crédito a un cliente para que pueda comprar en la tienda (ya sea por la funcionalidad de los gifts certificates o por el crédito en si mismo).

Por ejemplo, si yo compro un certificado para regalar, y el destinatario lo devuelve (si es que está configurado como redeemable), el valor del certificado se me acredita en mi cuenta y puedo utilizarlo para comprar).

En la gestión de clientes, podrá verse el balance de crédito del cual dispone un cliente en particular.

El tema del crédito funciona también para los reembolsos.

Cambios en la seguridad

Todo lo descripto a continuación, tiene interfase en el backend para parametrizar los comportamientos. Los cambios que se verán son:

  • Posibilidad de bloquear intentos fallidos de login a una cantidad dada.
  • Duración de la sesión en el backend.
  • Tiempo durante el cual una cuenta queda bloqueada (por los intentos fallidos de ingreso).
  • Tiempo de vigencia de la contraseña del usuario.
  • Acción a tomar cuando vence dicho plazo.

Hasta acá lo presentado por la gente de Varien. También comentaron por ahí los precios de la licencia de la versión para un servidor productivo y para servidores no productivos… pero mejor no hablar de eso ahora, para no asustarse.

Otros temas

  • Dejaron claro que la versión Enterprise tendrá prioridad por sobre la Community en cuanto a la liberación de correcciones de código.
  • Según lo explicado, ambas versiones van a partir de la versión 1.3.x. Inicialmente podría considerarse a la versión Enterprise como la 1.3.x con ciertas extensiones (no termina acá, más adelante el speech fue otro).
  • La versión Community seguirá siendo de open source, mientras que la Enterprise tendrá licencia comercial.
  • Una de las preguntas que se hicieron, apuntaron a si se mantendrá un único core de la plataforma, que funcione para ambas versiones.  Acá es donde se desdibuja un poco lo dicho antes, ya que esperan poder mantener un único core, pero que utilice diferentes modelos (de datos y lógicas) para la versión paga.
  • Van a habilitar una demo online de la Enterprise Edition, la cual sólo será accesible pro invitación (sobre esto no me quedó claro si siempre lo piensan hacer así o sólo al comienzo).
  • Sobre la Community Edition no ampliaron nada. Sólo comentaron estar muy emocionados con los cambios que van a introducir.
  • Un participante preguntó sobre el impacto de trackear todas las actividades del backend en cuanto a la performance. La respuesta de Varien es que no han notado impacto negativo por el momento.
  • Existirá la posibilidad de completar una compra con dos medios de pago (Crédito y otro que se haya configurado).
  • La actualización de la CE a la EE será tan natural como los cambios de versión en la actualidad (elija cada uno qué significa natural).
  • La pregunta que más me interesó fue sobre el soporte a la comunidad de ahora en más. La respuesta fue que van a seguir trabajando con la comunidad, y que la versión 1.3.1 será una muestra de ello. Apuestan por la comunidad ya que gracias a ella Magento es un producto exitoso.

La versión Enterprise sería anunciada ésta semana y el webinar va a poder descargarse para que (supongo) todos puedan verlo.

Espero que les sirva como una introducción a la nueva etapa propuesta por Varien.