Introducción a ATG Web Commerce para un Java Developer.

En el mundo del comercio electrónico hay una cantidad abundante de opciones para llevar a cabo soluciones de eCommerce. En este post haremos una introducción a ATG Web Commerce intentando mostrar brevemente las características más interesantes para el desarrollador que se inicia en este framework “gigante” y valoraremos, desde un punto de vista personal, si vale la pena o no dicha herramienta.

¿Qué es ATG Web-Commerce?

Es un framework que salió al mercado en 1997 y que en 2010 fue comprado por Oracle. ATG Web Commerce cuenta con multitud de ventajas ya que consta de un gran número de herramientas para el cliente: permite personalizar el contenido, importar el catálogo de productos, búsquedas, promociones, multidioma, call center, SEO y ofrece flexibilidad a la hora de extender el comportamiento de los diferentes módulos.

Básicamente, para un desarrollador, ATG ofrece una arquitectura para la webshop que podemos ir personalizando en función de los requerimientos de negocio; un sistema de control de negocio, también denominado BCC (para promociones, sites, medios de pago, entregas, personalizaciones de usuario, reglas...); un motor de búsqueda (Endeca) etc...

Desde el punto de vista del desarrollo, ¿con qué desarrollamos en ATG?

Como ATG es una herramienta de enorme complejidad y profundidad, voy a centrarme en los conceptos más básicos, basados en la experiencia que he adquirido en los proyectos en los que he participado y que nos permitirán empezar a trabajar con este framework.

Conceptos básicos

Ya que que en ATG trabajamos con productos, vamos a describir qué es un producto y qué es un sku.

Por otro lado, también vamos a ver tres conceptos básicos en la cesta, como son los CommerceItem, los ShippingGroup y los PaymentGroup.

Producto

Un producto es el bien que queremos vender al cliente, por tanto debe ser una entidad bien definida y que contenga la información necesaria para que el cliente tenga conocimiento de lo que está comprando. Por ejemplo, un producto debería tener algunas de estas características:

• Nombre del producto.
• Descripción corta del producto.
• Foto.
• Precio.
• Stock disponible.
• Días para el envío.
• Descripción de las características del producto.
• Categoría dentro de la jerarquía (moda).
• Marca (Levi’s, por ejemplo).
• Opiniones.
• Productos recomendados.
• Vídeo.

Sku

Un SKU es lo que se conoce como Unidad de Mantenimiento en Almacén. Es usado para identificar el inventario. El SKU es un código único de carácter alfanumérico que identifica características de un producto como el color, la talla, marca, almacén, etc...

Commerceltem

Un CommerceItem, a nivel abstracto, es una estructura en el repositorio de órdenes o pedidos (más adelante veremos qué es un item-descriptor y los repositorios), que se utiliza para representar la información del producto que se ha añadido a la cesta de la compra junto con otras características como la cantidad, descuentos, etc.

Un ShippingGroup es la estructura que representa toda la información que designa un envío. Esto podría incluir el envío tradicional por un transportista o envío electrónico.

Por otra parte, un PaymentGroup es la estructura que representa toda la información que designa un medio de pago. Por ejemplo, una tarjeta de crédito, un cheque, cupones, etc.

Desarrollo

Arquitectura y diseño de la Webshop

El núcleo de la plataforma ATG es DAF, o Dynamo Application Framework, que implementa un modelo de desarrollo de componentes basado en Java Server Pages (JSP) y JavaBeans.

Una vez tenemos instalado el producto ATG en nuestro equipo (en nuestro caso lo tenemos en una máquina virtual que optimiza y estandariza el entorno), y teniendo un IDE de desarrollo, básicamente nos encontramos con una arquitectura “base” basada en MVC.

El framework ATG se compone de los llamados componentes Nucleus, que es el contenedor de componentes ATG. Algunos de estos componentes sirven para acceder a datos y otros para presentar información. Vamos a ver de forma rápida los dos más importantes:

Por un lado, la capa de control la ejercen los “FormHandler” de la aplicación, que separa las distintas fases de una compra. Todas ellas extienden del componente ATG “GenericService”. Destacamos los más importantes:

• CartModifierFormHandler. Operaciones relativas a la cesta de compra. Dicha clase contiene todos los métodos y fases necesarias para gestionar todos los ítems de la cesta (añadir, modificar cantidad, eliminar, etc.).
• ShippingGroupFormHandler. Operaciones relativas a las direcciones del cliente, de facturación y datos personales.
• PurchaseProcessFormHandler. Operaciones relativas a los pagos.

Teniendo en cuenta esto, ¿qué debemos hacer si nos piden un comportamiento “customizado” para cada uno de estos componentes? En nuestro caso lo que hacemos es extender esta clase “base” y sobreescribimos el comportamiento del mismo dependiendo de los requisitos de negocio.

Por otro lado, también están los denominados Droplet, que es básicamente un “servlet bean” y que puede resultarnos útil para mostrar cierta información.

Inyecciones de dependencia

¿Es práctica la IoC (Inversion of Control) de Spring, verdad? Pues decidle adiós porque en ATG no utilizamos un XML, ni anotaciones. En su lugar se utilizan unos ficheros **.**properties que definirán los componentes e inyectarán las dependencias necesarias.

Por cada componente, se define un property, es decir, no hay un punto común desde el cual definamos todos los componentes y veamos las dependencias de unos con otros.

De hecho, si no tienes un diseño bien definido es bastante fácil cometer el error de tener referencias cíclicas debido a esta falta de visión global.

Un ejemplo de cómo crear este fichero podría ser este:

$class=es.eci.commerce.stock.flow.manager.ProductFlowStatusManager
$scope=global

loggingIdentifier=/eci/commerce/stock/flow/manager/ProductFlowStatusManager

shippingMethodsUtils=/eci/services/utils/ShippingMethodsUtils

Como vemos, definimos la clase del componente, el scope (request, global, session,window) y sus dependencias con otros componente o clases que son necesarias. También podemos definir variables, mapas y propiedades derivadas.

Desde mi punto de vista, esto es muy arcaico y cuando tienes muchas capas que se sobreescriben unas a otras, pierdes totalmente el estado de cada componente, resulta confuso, engorroso y “feo”.

Repositorios

El “API Repository” de ATG también es bastante curioso. No funciona con un bean mapeado contra una tabla, con una simple anotación @Entity o @Repository como en JPA.

ATG utiliza una capa llamada **"**ATG Data Anywhere Architecture Repositories", que mapea todas las fuentes de datos contra beans. En este caso, tenemos tres conceptos para entender cómo trabaja el ORM de ATG:

RepositoryItems

**RepositoryItems es una colección de ítems del repositorio. En general, un ítem de repositorio (un componente JavaBean que implementa **atg.repository.RepositoryItem o una de sus subinterfaces) corresponde a la entidad identificable más pequeña en el almacén de datos subyacente.

En el repositorio de SQL, por ejemplo, un elemento de repositorio suele corresponder aproximadamente a una fila de una tabla. Cada “Repository Item” debe de tener un identificador llamado repositoryId.Cada elemento del repositorio está compuesto de propiedades.

Estas propiedades almacenan los datos que componen un elemento de repositorio. Cada propiedad tiene un nombre, como id, firstName o lastName.

En el repositorio de SQL, estas propiedades corresponden aproximadamente a las columnas de una tabla. Las propiedades disponibles para un tipo de elemento de repositorio se definen en los descriptores de elementos del repositorio.

Item Descriptors

Un ítem Descriptor define un ítem con nombre TYPE, por lo que se trata en realidad de una estructura de datos. Cada ítem del repositorio siempre tiene un tipo definido que define de nuevo la lista de propiedades disponibles para el ítem, los tipos de datos de estas propiedades, etc... Por ejemplo:

<item-descriptor name="order">
<table name="raul_order" id-column-name="order_id">
             <property name="idDocumentNumber" column-name="document_number" data-type="string" required="false"/>
      </table>
      <property name="employee" data-type="boolean" writable="true" display-name-resource="order.employee" category-resource="ECI" />
</item-descriptor>

Cuando acceda al ítem descriptor “order” vamos a ver tanto los datos relativos a la tabla “raul_order” y a propiedades que podemos tener en el repositorio ATG, pero que no están mapeadas contra una tabla.

Aquí también debemos destacar que existen las llamadas “propiedades derivas”, propiedades del repositorio que son calculadas por un componente. Por ejemplo:

       <property category-resource="basics" name="skuPorDefecto" item-type="sku" display-name-resource="product.defaultSku" property-type="es.eci.repository.CustomSkuPropertyDescriptor" queryable="false" readable="true" hidden="false">

• “CustomSkuPropertyDescriptor” es una clase que extiende de la clase ATG.
• “RepositoryPropertyDescriptor” recuperará información de forma dinámica.

Repository Queries

Se utiliza el llamado RQL (Repository Query Language). Podéis obtener más información en este link. Los repositorios se declaran y estructuran en ficheros xml de una forma parecida a esta:

<gsa-template xml-combine="append">
<item-descriptor name="order">
<table name="raul_order" id-column-name="order_id">
       <property name="idDocumentNumber" column-name="document_number" data-type="string" required="false"/>
</table>
       <property name="employee" data-type="boolean" writable="true" display-name-resource="order.employee" category-resource="ECI" />
</item-descriptor>
</gsa-template>

DYN ADMIN

En ATG hay una interfaz que nos ofrece un acceso rápido a una serie de características útiles. Dicha interfaz, denominada “ATG Dynamo Server Admin”, puede, por ejemplo, modificar la configuración de instancias de servidor ATG, explorar la jerarquía de componentes de Nucleus, examinar valores de un pedido o de un producto del catálogo, cambiar el valor de una propiedad o un mapa de forma dinámica, etc.

Por ejemplo, vamos a ver el “OrderRepository”, que nos permite ver el componente que gestiona el repositorio de pedidos y que nos permitirá examinar la jerarquía del componente, quién lo mapea e incluso explorar valores de un pedido que esté en nuestro repositorio.

En “View Service Configuration” podemos ver la jerarquía para ver qué capa es la que está instanciando el componente (puede haber varias capas que sobreescriben propiedades dependiendo del site).

Para los componentes que gestionan repositorios existe la característica “Examine Repository Template Definition”, donde podemos observar el mapeo de ficheros que constituyen el repositorio:

Podemos consultar valores en función de las propiedades del componente. Por ejemplo, vamos a añadir un producto a la cesta y vamos a ver el estado del pedido.

Endeca

Endeca es la herramienta que se integró en ATG a partir del año 2011 para las búsquedas. Básicamente lo que hace es definir el almacén de datos al cual debemos acceder (catálogo) e indexar las propiedades (dimensiones) dentro de vistas para un acceso rápido y funcional de los productos.

A partir de una búsqueda, y de un “EndecaRecord”, tenemos la información necesaria para mostrar el producto y la posibilidad de añadirlo a nuestra cesta.

ATG Business Control Center

El Centro de Control de Negocios ATG o BCC es una interfaz que permite tanto a desarrolladores para sus pruebas como a los Product Owner a definir reglas de negocio y crear estrategias de marketing para una mejor venta de su producto. El BCC tiene varias áreas de trabajo que se resumen en:

• Actividades de ATG Content Administration. ATG Business Control Center es la interfaz principal para realizar tareas de ATG Content Administration, incluyendo la creación y despliegue de contenido de sitios web. Básicamente consiste en la creación de proyectos dentro de esta herramienta para dar forma al negocio.
• Gestión de activos de ATG Personalización. Se utiliza para crear y administrar la personalización de los contenidos que se van a presentar dependiendo del tipo de usuario, grupos a los que pertenezca etc, de forma que la presentación de la información es dinámica. Esto proporciona una flexibilidad y capacidad de planificar una estrategia para determinadas campañas y para atraer a ciertos tipos de usuarios.
• Gestión de los perfiles, que son requeridos por parte de la herramienta. Esta parte nos da facilidades para gestión de perfiles, roles, permisos etc...

El ATG Business Control Center también se utiliza como punto de partida para el lanzamiento de varias aplicaciones ATG.

La que más se suele usar para negocio y para que un desarrollador pueda realizar un desarrollo acorde a los requerimientos es en la opción “Merchandising/Gestionar activos de Commerce”. Aquí podemos crear promociones, gestionar envíos, restricciones, destinos, etc...

Vamos a mostrar un ejemplo. Dentro de esta opción y vamos a crear, por ejemplo, una promoción de regalo.

Una vez creada y desplegada esta promoción, cada vez que añadamos un producto con el nombre “Camiseta de hombre Boomerang” nos aparecerá como regalo un “set de pulseras Sco Doo”.

¿Es esto el paraíso?

La foto tan idílica final puede llevar a engaños, evidentemente ATG tiene sus cosas buenas, pero dista mucho de ser cómodo. Después de casi tres años de experiencia con esta tecnología, os resumo las principales ventajas y desventajas que he ido experimentando en mis propias carnes.

Ventajas

El producto ATG, como ya hemos podido ver, es muy potente. Contiene un gran número de herramientas que nos permiten crear sites, gestionar el catálogo, gestionar el carrito de compra, personalización, búsquedas, atención al cliente.

Además ofrece capacidades de marketing, capacidades B2C, etc. Desde luego, a priori, para la gente de negocio ofrece una cantidad importante de soluciones, ventajas y posibilidades de personalización.

Desventajas

Elevado coste de solución (coste y licencias), complejidad de desarrollo, número de extensiones que hay que realizar en el caso de un desarrollo a medida, arquitectura monolítica y dependiente. Como vemos casi todo afecta al desarrollador.

Bajo mi punto de vista, el principal problema que presenta este framework es que se aleja de la actual tendencia de crear pequeñas aplicaciones muy livianas, con arquitecturas orientadas a microservicios y con contenedores que desplieguen de forma más o menos constante las posibles soluciones.

La arquitectura es un monolito, que además es bastante complejo, tanto a nivel funcional como a nivel de diseño de seguir, y en el que cuesta tener un Continous Delivery por el acoplamiento de las distintas capas.

Además la forma de aplicar la IoC, el manejo de transacciones, los repositorios… en general es bastante arcaico, incómodo para el programador, y complejo de entender. Desde luego no es el framework ideal para que alguien recién salido de la universidad o con poca experiencia.

Tampoco es un buen framework para compañías con un nivel de customización alto en el funcionamiento de la webshop o del backoffice, ya que el producto viene con soluciones muy concretas para cuestiones también muy concretas y cualquier cambio de requisitos cuesta bastante aplicarlo.

Conclusiones

¿Tiene cosas buenas? Como ya hemos visto, sí, las tiene, pero a mí, como desarrollador que vengo del mundo Spring, no me resulta muy útil.

Quizás por todo lo que he expuesto no hay muchos desarrolladores ATG. Eso sí, aunque no nos acabe de encajar (al menos a mí, seguro que hay gente a la que le encanta, o que lleva toda la vida trabajando con ello y le parecerá todo lo que comento como algo rutinario) es una plataforma con bastante éxito y muy extendida en el mundo E-commerce.

Espero que esta pequeña introducción os sirva de guía a los futuros afortunados que trabajen con ATG, os lo vais a pasar genial y, sobre todo, vais a coger muchas tablas.

Por último, os dejo un webinar que fue de lo poquito que encontré en Internet cuando supe que tenía que trabajar con este framework.