Réservation de place de parkings en Drupal Commerce

Besoin client

Réservation de places de parkings en ligne

Le besoin principal est de pouvoir réserver une place de parking depuis le site internet :

• A l’heure et forfaits

Pour cela, nous avons mis en place un mécanisme permettant de trouver le meilleur tarif de réservation, et donc de n'afficher que ce tarif lors de la recherche d'une place pour un lieu et une période données parmi les options sélectionnées :

• A l’heure
• Forfait
• Forfait + à l’heure

Le prix doit également pour prendre en compte des frais de réservation (fees) ainsi que des remises automatiques ou manuelles (discount / coupons).

Enfin, en plus de réservation ponctuelle, il doit être possible pour l'internaute de souscrire à l’abonnement d’un parking.

Une fois connecté, depuis son espace, un client peut :

• Gérer plusieurs conducteurs.
• Gérer plusieurs véhicules.
• Voir l’historique de ses réservations :
  • En cours, passées et à venir.
  • Passées depuis la plateforme, sur site ou via un partenaire.

Reprise des données

Auparavant, ces services étaient fournis par plusieurs sites. L'un des objectifs de cette refonte est de pouvoir regrouper les différents services au sein d'un même site. Le client souhaite alors pouvoir récupérer l'ensemble des données pour assurer une continuité de service, soit effectuer une migration et reprise des données :

• des utilisateurs
• de l'istorique des commandes
• des commandes à venir

Besoin métier

Non seulement les tarifs, mais les disponibilités doivent systématiquement être calculés suivant différents critères, ce qui implique un nombre considérable d'options possibles :

• Options
• Ouverture
• Période
• Délai de stationnement
• Remises
• Règles de yield

Le client souhaite pouvoir réutiliser les calculs de tarifs et de disponibilité pour les proposer en tant que services a des prestataires partenaires. Des webservices sont donc accessibles pour des partenaires, ce qui leur permet de consulter le site pour connaitre les disponibilités des places ainsi que leurs tarifs.

Enfin, de nombreux types de données doivent être synchronisées avec d'autres plateforme du client (CRM, facture, clients etc). Selon la capacité de traitement des systèmes, les synchronisations sont réalisées via des webservices, des traitements par queue et/ou des fichiers plats en import et export.

Synchronisation avec différents ERP/CRM

Une synchronisation de données en import et/ou export doit pouvoir se faire de manière synchrone et asynchrone suivant les besoins et les possibilités des plateformes cibles :

• Commandes
• Utilisateurs
• Conducteurs
• Véhicules

Accès webservices

Plusieurs webservices sont mis à disposition de partenaires et briques internes pour leur permettre d'échanger avec la plateforme. Celle-ci devient donc la référence des données statiques et calculées :

• Service de calcul mis à disposition de partenaires.
• Service de disponibilité d’une place de parking.
• Service de recherche de parking à proximité.
• Service de création de commandes par partenaires.
• Service de création et mise à jour de :
  • Commandes.
  • Utilisateurs.
  • Conducteurs.
  • Véhicules.

Image

Étude de cas commerce métier

Rappel des besoins

Les besoins pour le site sont les suivants :

• Le site doit être disponible en plusieurs langues.
• La partie éditoriale est importante et doit permettre une liberté de structure des contenus avec du contenu riche.
• Le back-office doit être personnalisable pour correspondre au besoin métier du client.
• Le site doit permettre la réservation en ligne.
• 2 différents processus d’achat doivent être possibles suivant l'acte d'achat souhaité : réservation ou abonnement.
• Suivant les demandes, le site doit permettre des processus de traitement personnalisés.
• Les produits ne sont pas des produits physiques et ont une combinaison de possibilité trop importante pour stocker un produit par cas possibles.
• La gestion des disponibilités est spécifique.
• Il n'y a pas de tarif fixe pour un produit mais des prix dynamiques :
  • Calcul de prix spécifique.
  • Une infinie de possibilités.
• Plusieurs webservices doivent être mis à disposition et des import/export de données doivent être possibles.

Site multilingue

Drupal est multilingue. Il est traductible dans toutes les langues.

La partie commerce peut être segmentée suivant une langue, un pays.

Partie éditoriale forte

Drupal est avant tout un CMS (Content Management System). Le contenu est ce qu’il fait de mieux.

Nous avons utilisé le module Paragraph pour permettre la saisie de contenu riche et flexible :

• Flexibilité de l’affichage
• Permet au client de choisir lui-même parmi un catalogue d’élément comment afficher son contenu
• Affichage cohérent sur tout le site

Et nous avons également utilisé le module Media qui fournit une bibliothèque de médias partagés.

Back-office personnalisé

Lors de besoin métier, qu'il soit e-commerce ou non, le back-office est important. Les opérateurs doivent pouvoir utiliser quotidiennement le back-office pour suivre les commandes, gérer les offres, gérer les clients etc, en leur simplifiant au maximum le travail à réaliser.

Ainsi, un certain nombre d'écrans back-office ont été créés ou personnalisés, pensés pour leurs besoins :

• Listing des commandes (commandes réservation, commandes abonnements, état de paiements etc) avec informations, filtres et tri spécifiques via views.
• Listing des différentes entités créées avec informations, filtres et tri spécifiques via views.
• Configuration de différents fonctionnalités dans des écrans propres via l’utilisation de la form api et le gestionnaire de configuration.
• Export de données.

Réservation en ligne

La réservation en ligne se base sur l'utilisation de Drupal Commerce 2.x, solution e-commerce de Drupal flexible qui fournit déjà :

• Notion de produits
• Notion de commandes
• Panier
• Processus d’achat (checkout)
• Système de promotion
• Événements de calculs et de disponibilité
• Événements aux différentes étapes de la commande
• Systèmes de paiement

2 processus d'achat

Réservation et Abonnements sont de types de commandes avec des besoins différents. De ce fait, chacun à son propre processus d’achat. On peut citer par exemple les différences suivantes :

• Saisie de plusieurs conducteurs pour l’abonnement
• Récapitulatifs différents
• Solutions de paiement différentes (CB et/ou virement)
• Mails et contenus différents suivant le type de commande.

Processus personnalisés

Dans ce cas, il n'y a pas besoin de panier. Dès lors que le client choisi la place pour les options et au tarif indiqué, il rentre directement dans un processus d'achat.

Durant le processus, il doit saisir le/les conducteurs et de leur véhicule, avec la possibilité de réutilisater des données existantes s'il a déjà passé commande.

Un récapitulatif et des mises en avant propres à l’achat en court permettent de valider les informations.

Un paiement spécifique (payline / slimpay) à été mis en place.

On finit par afficher les informations personnalisées (code d’accès, informations de réservation) liées à cette réservation et un envoi de mails personnalisés.

Notion de produits spécifiques

Les différentes possibilités de réservations amènent à une infinie de produits possibles si l’on souhaitait tous les représenter en terme de place de parking.

Un produit est donc ici une zone de parking dans un lieu donné.

La réservation sera ensuite qualifiée en fonction de différents paramètres :

• De la période de réservation souhaitée.
• Du temps resté.
• Des options souhaitées.

Gestion de disponibilités spéficiques

La disponibilité d’une place dépend :

• De la période de réservation souhaitée.
• Des options souhaitées.
• Des horaires d’ouverture du parking.
• Capacité d’accueil possible.
• Du nombre de places déjà réservées sur la période selon les options.

Chaque parking dispose de sa capacité d’accueil par période.

Le nombre de places déjà réservées par option sont stockées dans une entité.

Pas de tarif fixe par produit

Une place de parking n’a pas un prix, mais différents prix selon une multitude de critères.

Le calcul du prix d’une réservation dépend :

• De la période de réservation souhaitée.
• Du temps resté.
• Des options souhaitées.
• Des promotions en cours (automatique ou via coupon).
• De règles de yield.

Toutes les données nécessaires au calcul de ces tarifs sont :

• Importées depuis un ERP
• Stockées dans des entités liées aux modèles de données envoyées

Le système de calcul est géré directement dans Drupal (non externalisé).

Drupal Commerce 2.x fournit un service qui nous permet d’intégrer nos propres règles de calcul de tarif.

Webservices et import/export

Plusieurs outils sont utilisés pour réaliser les imports, exports et synchronisation :

• Import en masse depuis ERP via Migrate:
  • Commandes
  • Promotions
  • Données métier (tarifs, parkings, ouvertures etc)
• Webservices de synchronisation en Soap et JSON
  • CRUD commandes, utilisateurs, conducteurs, véhicules
  • Disponibilités
  • Calcul tarifs
• Export de données fichiers. Une dizaine d’exports différents à différent formats: CSV et formats propriétaires.

Rétrospectives sur les faiblesses de Drupal Commerce 1.x

Ce qui aurait été plus compliqué (ou impossible) :

• Calcul de prix à la volée.
• Différents processus d’achat.
• Exposition de webservices.
• Gestion des caches.
• Structure des données « entité » via le module features.
• Gestion via le module Rules au lieu des événements.

Problèmes et solutions

Il y a une infinité de produits

Solution

• Un produit est une zone de parking dans un lieu donné.
• Un produit n'a pas une quantité mais une disponibilité sur une période donnée.
• Les données propres à notre réservation (période, option) sont directement stockées dans notre commande.

Le tarif est dynamique

Solution

• Utilisation du service de Commerce 2.x commerce_price.price_resolver.
• Stockage de toutes les données utiles au calcul dans des entités.
• Utilisation de ces données dans des règles de calcul.

Image

Trouver le meilleur tarif / calcul de tarif à l’affichage

Solution

Génération de commandes éphémères pour bénéficier des fonctionnalités de calcul de commerce liées a une commande :

• Ajustements
• Promotions
• Résolveur de prix

Les appels à Drupal et aux services externes ne doivent pas souffrir d’indisponibilité

Solution

• Ajout d’une couche d’abstraction et de rétention via Symfony + RabbitMQ.
• Drupal ne fournit et ne gère que du JSON.
• Application Symfony s’occupe de la conversion entre Drupal et externe si besoin.

Image

Sécurisation des fonctionnalités critiques

Solution

• Mise en place de tests automatiques via PHPUnit.
• Tests fonctionnels manuels par une équipe de testeurs.

Développement de qualité et conforme aux bonnes pratiques

Solution

• Relecture systématique de tout code. Utilisation de Gitlab et de « merge requests ». Branche de développement bloquée et validation obligatoire par le Lead dev.
• Utilisation de Code Sniffer :
  • PHPCS
  • Eslint
• Audit de code via SonarQube.

Les deux services de paiement utilisés n’existent pas sur commerce 2.x

Solution

• Création de deux modules.
• Le système de plugin et d’interface de commerce 2.x raccourci le temps de création de modules de paiement et permet de conserver une consistance entre les différents modules.

Exposer des webservices

Solution

• Drupal 8.x propose par défaut un module REST pour exposer au format JSON un CRUD des données.
• Commerce 2.x intègre parfaitement ces entités à cette fonctionnalité.
• Création simple et facile de nouvelles ressources REST selon les besoins.

Axes d'amélioration

Calcul de prix

• Optimisation du moteur de calcul de prix pour améliorer ses performances.

Sécurisation développement

• Un maximum de tests fonctionnels automatiques pour éviter des régressions sur des fonctionnalités critiques.
• Utilisation de BeHat ou équivalent pour inclure le client dans la rédaction des tests.

Saisie Back-office

• Gestion des paragraphs via une « bibliothèque » plus explicite que l’interface fournie par défaut
• Amélioration de l’interface de paragraphs imbriqués.

Front-Office

• Utilisation plus harmonieuse du javascript lors des recherches et calcul de prix pour une meilleure expérience utilisateur.
• Réduire le poids des pages.
• L’intégration des formulaires en front-office reste le point noir des intégrateurs.

Conclusion

Ce projet est un projet e-commerce métier en dehors des traditionnels sites de vente en ligne.

Celui-ci met en avant de gros points de complexités métier avec lesquels Drupal commerce répond à brio.

Drupal Commerce 2.x est plus flexible et mieux conçu que Drupal Commerce 1.x, ce qui nous permet de mieux répondre aux besoin pour un coût moindre.

Drupal Commerce 2.x est adapté au commerce métier et ce plie à vos besoins.

Le site est en ligne et son nombre de ventes ne cesse de croître.