Liferay Commerce - Personnalisation du Tunnel d'achat

Le tunnel d’achat ou checkout de Liferay est le processus qu'un client suit pour finaliser un achat sur une boutique en ligne Liferay Commerce. Il s'agit d'une série d'étapes distinctes que le client doit franchir pour passer sa commande. Elle commence une fois que l’utilisateur a validé le choix des produits et se termine avec la confirmation de l'achat.

Voici les étapes qui sont fournies de base dans Liferay :

• Informations de livraison et de facturation : Le client saisit ses informations de livraison et de facturation. Ces informations peuvent être pré-remplies si le client est déjà connecté à son compte.

• Méthode de paiement : Le client sélectionne sa méthode de paiement préférée parmi les options proposées. Liferay Commerce dispose nativement de plusieurs solutions de paiement ; il est également possible de développer un connecteur pour une autre solution de paiement (nous reviendrons dans le cadre d’un autre article sur la mise en oeuvre d’un nouveau connecteur).

• Récapitulatif de la commande : Le client passe en revue sa commande, confirme les informations saisies et soumet la commande.

• Confirmation de la commande et traitement : Une fois la commande confirmée, le client reçoit une confirmation par e-mail et la commande est traitée par le système. Cela peut inclure des actions telles que la vérification du stock, la génération de la facture ou l'expédition des produits.

Le principe de fonctionnement des étapes

Une étape est une page distincte du processus de commande que les clients doivent visiter pour finaliser leur achat. Chaque étape a un objectif spécifique, tel que la saisie des informations de facturation ou de livraison, la sélection d'une méthode de paiement ou la confirmation de la commande.

Liferay fournit un framework pour simplifier la personnalisation du tunnel d’achat. Cette méthode permet de concentrer ses efforts uniquement sur la réalisation du contenu de l'étape choisie.

Avec l’image suivante, vous pouvez visualiser les 3 zones principales d’une page du tunnel d’achat :

• La progression de l’utilisateur au sein du processus d’achat (1) est automatiquement générée en fonction des étapes existantes, et des informations déjà complétées par l’utilisateur.

• La barre d'actions (3) permet de naviguer au sein du processus d’achat avec la possibilité de passer à l'étape suivante ou précédente, si elles sont disponibles.

• Le contenu de l'étape courante (2) est ouvert à la personnalisation.

 

Déclarer une nouvelle étape

Pour déclarer une nouvelle étape, il est donc nécessaire de définir un nouveau composant. Ce composant doit être une implémentation de l’interface CommerceCheckoutStep. Liferay fournit également une classe abstraite qui peut servir de base BaseCommerceCheckoutStep, avec une implémentation classique des principales fonctions.

Voici la liste des fonctions disponibles :

Fonction	Description
getLabel	Permet de définir le libellé qui sera affiché dans la progression du tunnel d’achat
getName	Identifiant de l'étape, il doit être unique
isActive	Permet de définir si l'étape est active ou non
isSennaDisabled	Permet de désactiver SennaJS (le framework d'exécution SPA de Liferay) afin de forcer le chargement complet de la page lors du changement d'étape
isVisible	Permet d’afficher ou non l'étape dans la progression du tunnel d’achat
processAction	Permet de définir des contrôles / actions à réaliser à la validation de l'étape
render	Permet de charger le contexte avec les informations qui seront affichées sur la page de l'étape
showControls	Permet de contrôler l'affichage des boutons d’action du tunnel d’achat (Suivant et Précédent)

Astuce : Lors de l’ajout d’une nouvelle étape, il est possible que vous rencontriez des difficultés, en particulier si vous copiez l’une des étapes existantes. En effet, lors de l'intégration du contenu de la JSP associée à l'étape, il est nécessaire de préciser la référence du module où se trouve cette JSP. Cette opération n’est pas nécessaire pour l'étape native Liferay, car elle se trouve dans le même module que l’implémentation du tunnel d’achat. Pour y remédier, il suffit de fournir le paramètre servletContext lors de l’utilisation du renderJSP. Ce servletContext aura été initialisé au préalable avec le symbolic name du module courant (information disponible dans le fichier bnd.bnd).

Exemple:

Déclaration du servletContext propre à son module :

@Reference(target = "(osgi.web.symbolicname=blog.commerce.order.checkout)")
private ServletContext _servletContext;

Déclaration du renderJSP:

_jspRenderer.renderJSP(_servletContext, httpServletRequest, httpServletResponse,"/checkout_step/myStep.jsp");

Positionnement de la page

L’ordre des étapes est géré directement au niveau de l’implémentation de l'étape avec la propriété “commerce.checkout.step.order" du composant. Les étapes sont affichées par ordre croissant. L'étape de confirmation dispose de l’ordre maximum (Integer.MAX_VALUE).

Personnalisation de la confirmation

La mise en oeuvre de la page de confirmation reprend le principe vu précédemment de création d'une nouvelle étape avec deux points supplémentaires. Tout d’abord, la nécessité de désactiver la page existante de confirmation pour éviter tout conflit. Et ensuite, des spécificités liées au fait qu’il s’agisse de la dernière étape du tunnel d’achat.

Désactivation de l'étape native

Nous allons devoir re-définir l'étape fournie par Liferay. Pour cela il faut dans un premier temps désactiver l'étape existante, ici :  com.liferay.commerce.checkout.web.internal.util.OrderConfirmationCommerceCheckoutStep .

La désactivation se fait grâce à la fonctionnalité de blacklist de composants. Cette fonctionnalité est disponible via l'écran de configuration : Control Panel > Configuration > System Settings > Component Blacklist Configuration. Ou directement via un fichier de configuration com.liferay.portal.component.blacklist.internal.configuration.ComponentBlacklistConfiguration.config qui doit être positionné dans le répertoire "osgi/configs" de votre serveur Liferay. Le fichier peut également être positionné dans le répertoire "configs/common/osgi/configs" de votre workspace Liferay.

blacklistComponentNames=[ \
  "com.liferay.commerce.checkout.web.internal.util.OrderConfirmationCommerceCheckoutStep", \
  ]

Spécificités liées à la confirmation

Lors de cette étape, il est nécessaire procéder à quelques ajustements, notamment car il s’agit de la dernière étape, que la commande vient de changer de statut et qu'elle n’est plus modifiable par l’utilisateur.

• On commence par désactiver les boutons “Suivant” / ”Précédent” en implémentant la fonction showControls et en retournant false

• On désactive le chargement de page dynamique senna-js pour forcer le chargement complet de la page une fois que l’utilisateur aura quitté le tunnel d’achat.

Modification du Commerce Engine

Le Commerce Order Engine est un module qui gère le traitement des commandes. Il fournit un ensemble de fonctionnalités de base pour gérer le cycle de vie d'une commande. C’est dans ce composant que l’on va pouvoir définir les pré-requis et actions concernant les changements importants d'état. La définition détaillée des statuts est, quant à elle, gérée via les implémentations de l’interface CommerceOrderStatus. Il existe une implémentation pour chaque statut, avec, à chaque fois, les règles relatives au statut concerné (pré-requis pour changer d'étape…)

Désactivation de l'Engine de Liferay

L’implémentation fournie par Liferay est réalisée via la classe com.liferay.commerce.internal.order.engine.CommerceOrderEngineImpl. Cette classe doit être désactivée afin de proposer notre propre implémentation. Vous pouvez revenir sur la partie “Désactivation de l'étape native” pour avoir le détail de la procédure concernant la désactivation d’un composant.

Initier sa propre implémentation.

Copier la classe CommerceOrderEngineImpl dans votre module. Dans un premier temps, il est nécessaire de résoudre les dépendances internes au module commerce-service (notamment les trois classes com.liferay.commerce.internal.order.status.CompletedCommerceOrderStatusImpl / com.liferay.commerce.internal.order.status.PartiallyShippedCommerceOrderStatusImpl / com.liferay.commerce.inventory.model.CommerceInventoryBookedQuantity). Les constantes KEY de ces trois classes référencent des valeurs de la classe CommerceOrderConstants ; vous pourrez donc y faire directement référence.

Types de modification possibles

Voici différents exemples de cas d’utilisation qui ont nécessité la modification du Commerce Engine :

• Suite à la modification de certaines étapes natives, vous avez pu être amenés à un blocage au moment de la phase de validation, notamment si vous avez retiré l'étape de sélection de l'adresse de livraison et l’adresse de facturation. Dans ce cas, vérifiez au niveau des contrôles précédant le checkout que les contrôles sont toujours pertinents. Par exemple, si vous n’avez plus d’adresse de facturation, il faut retirer le contrôle associé (voir capture d'écran ci-dessous)

• Vous n’utilisez pas la gestion de stock intégrée à Liferay. Vous avez donc pu constater que la quantité disponible des articles est négative. En effet, Liferay comptabilise automatiquement les quantités commandées et les retire des stocks. Ce comportement est également géré via le Commerce Engine. Cette opération est disponible via la méthode _bookQuantities

Conclusion

Personnaliser le tunnel d'achat est une étape importante de la mise en oeuvre d'un projet e-commerce. On vient de voir que le framework mis en place par Liferay fournit les points d'intégration nécessaire pour créer rapidement de nouvelles étapes et personnaliser les étapes natives. Ceci permet d'ajuster le tunnel d'achat aux spécificités propres à votre projet et à celles de vos clients à moindre coût.

Nous venons de constater que le cadre proposé par Liferay facilite la création rapide de nouvelles étapes ainsi que la personnalisation des étapes existantes. Cela permet d'adapter le tunnel d'achat selon vos spécificités et les besoins des clients, et ce, à moindre coût. De plus, il propose des outils permettant d'approfondir davantage la personnalisation, avec par exemple le moteur de règles intégré à la fonctionnalité de commande.

Nous aurons l'occasion de revenir sur la partie tunnel d'achat dans le cadre de futurs articles notamment sur le module de paiement Authorize.net en mode intégré, et la synchronisation des paniers avec un ERP.