Global Franchise DXP Overhaul With Acquia Cloud Site Factory, Drupal & Magento

This client’s extensive global footprint demanded a comprehensive solution. 

We worked through Acquia to service an enterprise-level retail megalith—with a 35 year history and composed of some of the world’s most recognized brands and household names.

The franchise currently operates across the whole of Europe, the Middle East, North Africa and Turkey, with:

Through our close relationship with Acquia, our teams delivered the solutions with Acquia Cloud Site Factory, Magento, and Drupal. This is how, what it took to do it, and the challenges we overcame along the way.

First, a look under the hood.

Our teams use Drupal as frontend—and this isn’t your typical approach.

When we talk of decoupled, we’re generally talking about Drupal as the backend. Most of us do not appreciate how Drupal can also be used as frontend technology. But in some cases, that’s exactly what’s needed.

Magento is one of the biggest and most popular enterprise-level Open Source ecommerce solutions out there, and is expected to grow since its acquisition by Adobe.

As technologies, Drupal and Magento are both giants in their own rights, and their combined capabilities offer a lot of potential for customers in need of complex solutions to challenging problems.

Their technology use across brands was fragmented and inconsistent.

At the start of the engagement, the client had close to 90 brands in its portfolio. Of these, some were on Drupal, while others used a mix of open source and proprietary CMSs.

Additionally, of the 90 brands, not all had a web presence or an ecommerce store. In a lot of Middle Eastern markets, there are no online stores like Amazon or Flipkart. Most brands in these locations had physical stores. Others had a web presence, but no ecommerce capabilities, so customers still had to go to the physical store to buy products.

Given all this, there was a lack of standardization across the brands, both in terms of the customers’ as well as the editors’ experience. It also meant that the client was spending a lot on maintaining and updating these sites, while losing precious time in launching new brands online.

They needed help with their DX initiative.

The client needed to consolidate the digital experience across their diverse brands.

To do this, they needed proven ecommerce capabilities as well as a scalable “multisite”solution that could keep pace with their growth. Together, the two would help them create brand sites that brought together content and commerce capabilities to deliver a seamless user experience that increases conversions.

These were their four key goals:

1. Consolidate all brands onto a single platform that can be centrally managed, and standardize the architecture.
2. Empower editors to make changes to existing brands or launch new brands quickly and efficiently.
3. Enable all brand sites with content and e-commerce capabilities to deliver an integrated customer experience.
4. Reduce cost of website updates and maintenance.

Why Magento + Drupal + Acquia?

In March 2017, Axelerant was brought in to help deliver the solution the client needed.

The client already had a few sites running on Magento. They had some in-house Magento professionals to handle these sites, and a small team from a Magento solutions partner. Their site administrators were comfortable with the Magento backend already.

They now needed a front-end solution that would them to launch websites quickly without the need for involving developers.

Drupal was chosen as the frontend due to its superior editorial and content management experience. But while Drupal has had the multisite feature for decades, it is more complex to use because it requires involving development teams and restructuring code.

Acquia Cloud Site Factory rises to the occasion.

Acquia Cloud and Acquia Cloud Site Factory (ACSF) hid the provisioning of servers behind a layer so that users don’t need to see the complexity involved. Their user-friendly interface allows sites to be deployed easily and effectively without involving developers. This makes the product a great fit for business owners launching in new regions and demographics. 

Acquia Cloud and Acquia Cloud Site Factory (ACSF) hid the provisioning of servers behind a layer so that users don’t need to see the complexity involved. Their user-friendly interface allows sites to be deployed easily and effectively without involving developers. This makes the product a great fit for business owners launching in new regions and demographics. 

The client’s major objective was to establish an online presence for each brand and create a framework that would allow them to launch websites very quickly.  At this point in time, only Acquia offers products that deliver this kind of business model, and are battle-tested by several major brands. This made Acquia the natural choice for this project. These are the various categories of sites built:

• Non-transac: sites which provide information to users, but do not allow them to buy products (non-eCommerce).

• Transac: these are site which allow users to buy products (eCommerce).

• Single page sites (which are neither Transac or Non-transac): These sites give information and allow users to buy tickets to events or activities. These don’t have the typical product catalog or merchandising features but need to allow the sale of tickets.

The eCommerce power of Magento.

While the backend remained on Magento, the frontend was built in Drupal. There are two different sites, one on Drupal, one on Magento, and both are connected through a connector.

All the products are added on the Magento site, and the team can run a command to sync the products on the frontend. Stock is updated in the Magento site and fetched from there through an API.

We needed a Drupal-Magento connector.

Most brand sites had a static website. These needed to be enhanced by integrating e-commerce capabilities within these sites. For example, a customer reading about a particular piece of merchandise needed to be able to simply click on the image and add it to cart, check out, and make the payment—without ever having to leave the site.

The challenge was to bring the content from Drupal and the product management and retail features from Magento together onto a single interface.

To get around this, the Acquia team decided to build an all-new Drupal-Magento connector module, with the Axelerant team participating later on in making modifications and bug fixes.

This demanded close coordination between all technology partners in the projects. Teams from Axelerant, Acquia, Magento, and all the brands worked closely together to build this solution.

Here’s how we solved challenges that came up. 

Configuration Management on the Backend Configuration management is probably the most complicated aspect of Drupal 8 right now. There are multiple ways to handle configurations, but this project called for a unique approach.

The client had different brands that needed different sites built using the same code base, with the configuration shared between all the sites.

Normally, when working with Drupal sites, we would use the new configuration import and export structure, where we define a separate directory outside of the Drupal layer from which to export all the configuration files. These are then used to build new sites. But as the client had different sites with different kinds of configurations, the same structure would not work.

So, instead of the default Drupal way, the team built a new layer by creating a custom module to override the default configuration, and any other custom module can define configurations to override. On installation of that module, the overridden configuration can also be imported.

Three layers of modules are used: one is the commerce modules, the second is the global modules with configurations common across all brands, and the third is the brand-specific module. The multisite is initially set up with transac and non-transac capabilities, and then other aspects are defined depending on the brand, location, language, etc.

For example, a brand may have a different site set up in each of the four regions where it has a presence. The entire configuration for these four sites would be similar, except for the currency. In this case, how the currency is displayed would be managed via the overridden configurations.

To make this easier to do, the teams made the choice at the start of the project to keep all the sites similar in terms of structure. This enables them to launch new sites without involving teams of developers. By doing this, they don’t need to go into the code and write a different use case each time there is a slight change in requirements. Instead, all this can be managed by altering the configurations. 

	theming power on the front-end The same challenges existed on the frontend as well. While the sites might have a similar layout and similar placement of the logo, search bar, footer, newsletter block, every brand would have its own style guide, fonts, colors, etc. The team solved this by having a generic theme which is applied globally for all brands, as well as theme override files on the frontend, which allow them to tweak certain aspects without having to write CSS. While they do customize specific requirements, 70-80 percent of the theming can be managed effectively in this manner.
	Enterprise-level retail = multiple mobile apps The team created APIs so that mobile apps could receive all the data for the frontend from these, while the data for the backend comes from Magento. For all the frontend aspects, like the product detail page, product search page, product listing page, categories list, etc, the Drupal API is used, but for placing orders or registration the Magento API is used.
	successful QA using Behat While the team is not actively using Behat at this point, they have also attempted Behat integration, which didn’t work perfectly because of the number of brands, countries and languages involved. These three are the major aspects to consider while testing a site. And with the normal Behat structure, testing all of these was a lengthy job.
To test a single feature, a QA engineer would have to write a scenario each for each of the brands, languages and regions. This meant that, for example, testing one scenario across three brands, two languages and four countries would require the creation of 24 files. Eventually, the team ended up not writing Behat test cases at all. They decided to restructure Behat and invent a new way to write single configurations for all the sites, and use that configuration to build feature files automatically instead of writing them manually. While this is not in place yet, the team has worked on a proof of concept (POC) that would allow the client to do this. As the sites have 70-80 percent of their code in common, there are only small modifications they need to fix and test. For those parts only, they’d be overriding feature files, while the rest is automatically generated.
	Solr search for multilingual For search, the team used Solr with a lot of customization done for working with Arabic search. Solr does that job gracefully, although some tweaks were needed to make it work perfectly with Arabic (because autocomplete and other aspects can create some challenges). But now, this is working fine.
Now, for faster search, the team is replacing Solr with an Algolia integration. This is the search database that they use to index data, and it will help to make search faster. Solr is on the backend, and Algolia is on the frontend. Whenever a user types in some keywords, Algolia will filter out search results right there on the page (instead of the user having to click on the word, hit search and wait for the page to load).
	seamless payment gateway integration For payment gateways, there is KNET which is a Kuwait specific payment gateway. There’s also CyberSource. The team has already implemented bank transfer. And is also integrating checkout.com and Apple Pay with it.