By Mike DeWolf - Associate Director of Engineering at Third & Grove
Enterprise companies need to leverage the power of a strong CMS with a best-in class ecommerce system, but for too long, none of the existing platforms on the market provided both. Drupal's ecommerce options have historically been limited, and Magento’s primary concern is more with commerce than content. Combine the two, and you've got a best in class use case for each system.
A Magento / Drupal headless e-store delivers Drupal as the website frontend and Magento as the cart backend. Website visitors always experience Drupal. All frontend HTML is generated, transformed and cached by the Drupal application stack. Ecommerce operations on the front end are processed via REST API with the Magento backend.
The front end of checkout is driven by Drupal’s form API; Customer account pages are managed through Drupal’s user entities; Authenticated sessions are managed in Drupal. To summarize, Drupal is the glass, while Magento is the mission-critical head of the e-commerce operation.
Here are five lessons we’ve learned when doing this type of integration.
1. Choose Sources of Truth
When mashing up two systems like Magento and Drupal, each has its own way of handling similar data. They are both well adapted to modeling item, user, taxonomy and customizable entity objects. From a software engineering perspective, it is helpful early on in the build to decide which data will be managed in Magento vs. Drupal, or stated differently, what the source of truth will be.
We have often found that the ideal split of obligations between the two platforms mirrors an organization's marketing and fulfillment team structure. A good way of breaking it out is to picture the fulfillment team only using Magento and the marketing team only using Drupal. Along these lines:
The most common split for source of truth is to put critical ecommerce data like user addresses, order histories, price, SKU, and stock in Magento and all frontend product marketing and display data in Drupal. Done right, the two sides of the business, marketing and fulfillment should only need logins to a single system.
2. Model Magento Products in Drupal
In order to structure a headless ecommerce experience in Drupal, we’ve had success making a “product” node type which is edited in Drupal and operates as the “presentation entity” for the product view. We’ve then added custom Commerce SKU entities (associated via entity reference) to make product attributes that are sourced from Magento available to the presentation layer. We’ve then written cron routines and drush / Magento CLI commands to sync SKU data between the two systems. Structuring SKUs as custom entities allows us to create different bundles to handle the different frontend processes needed to support the different product types that Magento (ie configurable, bundleable, grouped, downloadable, custom etc.).
The end result is a system which isolates ecommerce data, giving the marketing team free reign over a rich content driven Drupal website. Drupal updates price, stock and other fulfillment related attributes from the Magento backend both synchronously and in real time in response to edits.
3. Loose Coupling and Outages
Usually checkout involves 3rd party services (Payment Gateway, Tax calculations, Real-time shipping quotes etc). Unfortunately all 3rd party dependencies occasionally fail. One huge advantage of separating the eStore from the brand frontend is that when the the eStore gets backed up, the brand site doesn’t need to go down.
It is important to take the invariable eStore outage in consideration when structuring Drupal’s relationship with the Magento API layer. On nearly all of the Magento / Drupal integrations we’ve done, there has been a time where the eStore backend failed and we needed to seamlessly disable cart and checkout on the frontend in order to preserve user experience.
We suggest planning what the end user experience will be during an outage and making a setting to turn off ecom accessible via the Drupal GUI. User experience when the eStore is down can be as simple as a redirect on checkout paths or as elaborate as hiding add to cart buttons on all product pages and removing links to cart from page templates.
4. Conductor Application for BE Integrations
A conductor platform is a message bus system that handles non checkout-essential checkout transactions/integrations (CRM updates, email lists etc.) so that if one of these systems goes down, the eStore still functions. Using a conductor improves fault tolerance by removing non-essential http transactions from checkout and deferring them to a queue system that will store the requests until the operation succeeds. If a CRM update fails because of an outage, the conductor tries again later. As successful checkout is mission critical, it makes sense to decouple non-essential operations from the logic driving order completion.
5. Keep Price, Tax and Shipping in Magento
Magento should always maintain supremacy over price and other data essential to the checkout transaction. What a customer sees in their basket, their cart or during checkout should always be an accurate reflection of what ecom backend is saying.
At TAG we like to make a rule for these integrations that there is no math in Drupal. We sync price fields as strings and display price totals during checkout via live API calls. This removes duplicative logic by taking all math out of Drupal and ensures that there are never discrepancies between what a user sees on the checkout frontend and what they are billed.
Above we have provided 5 of the technical lessons we’ve learned doing Magento / Drupal headless stores. There are many more. Thank you for reading!
The mashup of Magento / Drupal combines the strengths of both platforms to create a compelling brand and ecommerce technology solution. By using both in harmony an organization gets a much more powerful site, capable of moving massive sales volumes via Magento, while at the same time personalizing content to ages, regions, whatever; selling products internationally, in multiple languages and handling huge publishing flows via Drupal.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.