Elasticpath & Drupal 8 integration
CMS

Drupal 8 and Elastic Path Integration

With a lot of focus coming to inbound marketing, there is always a high amount of investment which companies do on the content. To serve this need it becomes very necessary that the online solution you have has the content management capabilities which can allow seamless creation and publishing of content.

We ended up with a similar solution scenario where Elastic Path was the baseline e-commerce solution with excellent commerce features but lacked content authoring capabilities. We could resolve it two ways choose a solution which does both or adds a plugin to Elastic Path.

To address this issue we introduced Drupal as the content management system which would seamlessly integrate with Elastic Path for commerce features and also provide a content enrichment layer which would act as the e-commerce front end. Let’s look at how we implemented this integration:

High-level Architecture

For the above-said integration, the diagram below shows the high-level integration details:

Few more details about the architecture as follows:

Drupal 8

Drupal is used to manage the content here and for the rendering of Products & other transactional pages like Cart, CheckoutOrder Details etc.

The inbuilt REST API layer is used to interact with Elastic Path and to make changes to the API responses to convert them in a presentable manner by the Drupal’s Rendering layer.

Elastic Path

ElasticPath is the e-commerce system that manages the Products & Catalogs.  Also, it manages a customer base by default to make them related to various purchases.

ElasticPath also has a REST API  layer to interact with multiple operations like Cart (CRUD), Checkout, Order Processing etc.

Cortex

The REST layer in Elastic Path is known as Cortex.  Elastic Path Cortex adjusts thoroughly to the HATEOAS limitation and Level 3 of the Richardson Maturity Model.

The Cortex is outlined in a multi-layered application structure and each layer is responsible to perform a unique and very specific operation.

Few people also name it as reflection, where each layer is in charge of an arrangement of errands and each layer isn’t associated with alternate layers to finish assignments.

The motivation behind why this engineering configuration was picked is that it streamlines the activity of Java designers who are altering the Cortex.

Ideally, developers would just need to understand only two layers as,

  • Integration Layer
  • Rest Resources Layer

One of the best things regarding this architecture is that if there is a customization required then both the layers can be managed separately as they are abstract and developers would need to work on their part only.

Response Format

All API responses are formed in JSON and indeed it is an ideal choice for transferring to and from different networks, as it’s lightweight, programing language independent, and supported by a large number of third-party tools.

Every response is formed with 3 main parts:

  • Self Object
  • Properties set specific to the resource being represented
  • An array of links to other resources

Response Properties

A self-object returns with every API response and contains following properties:

PROPERTY

DESCRIPTION

type This denotes to the type of resource is being requested for.
uri Resource locator to the requested resource.
href A fully qualified URL to the API resource requested.

For every resource, as a response, it contains an array of links with a specific or consistent order. It will have following properties:

PROPERTY

DESCRIPTION

rel

A unique and non-changeable relationship name that describes the relationship between resource and resource links pointed at.

rev

This is the reverse relationship name that is opposite to rel property. By using this, the parent can be traversed of a resource object.

type Resource type.
uri Resource locator to the requested resource.

href

A fully qualified URL to the API resource requested

Integration Flow

Elastic Path follows a specific journey from the addition of a product to Cart till it gets ordered. This can be understood as follows:

Authentication

An access token would be required in order to access information from Cortex API. The first thing a developer would require to capture a valid access token.

Access tokens are generated for anonymous users or the visitors who have not logged in to the system and for authenticated users who wish to proceed with purchases.

Authentication can be done by giving an API call to Cortex as a POST request to the OAuth2 Resource and by setting the content-type to application/x-www-form-urlencoded. Here is an example:

Include the following parameters to the body of this request.

If the request is processed with no issues, the response would be in the following format.

If the request is unsuccessful, it would return a 401 response code.

Once the access token is granted then it should be part of request headers of all subsequent API calls to Cortex. Please see the example below:

The Access token would be validated for 1 week’s time and after that, it will be no longer a valid access token.

In some cases, you may want to revoke the access and for that, you can send a DELETE request to cortex API.

Updating Cart

Once authorized, the end-user will be able to perform cart operations. The AddToCart operation uses a 3-step workflow as follows:

  1. GET – Retrieve an item from the catalog.
  2. GET – AddtoCart Form needs to be fetched.
  3. POST – the item to cart’s addtodefaultcartaction operation.

 

Cortex API Add to Cart Flow
Cortex API Add to Cart Flow

Request body of POST addtocartform needs to be updated with quantity in the following format:

Upon successful addition to the cart, it would return response code 201.

For deleting a lineitem from Cart, there is a specific sequence of API calls as follows:

  1. GET – get default user’s cart
  2. GET – get lineitems details from the received cart.
  3. DELETE – select a lineitem from lineitems and Delete it.

Flow can be seen as :

Delete Cart Item
Delete Cart Item

In the same way, for updating the cart items it follows a sequence of synchronous API calls as:

  1. GET – get default user’s cart
  2. GET – get lineitems details from the received cart.
  3. GET – get specific lineitem to update.
  4. PUT – add product attributes like quantity to request’s BODY, for e.g., {‘quantity’: ’10’}

 

Update Cart
Update Cart
https://developers.elasticpath.com
Complete Purchase Flow Credits: Elastic Path (https://developers.elasticpath.com)

Integration Support

As of now, there have been no specific extensions or modules are available for Elastic Path & Drupal. A sandbox project is created on drupal.org at following page:

https://www.drupal.org/sandbox/diveshkumar/2937566

This module does a basic integration of Drupal 8 and Elastic Path. You would find following features after using this module:

Configurations Screen

It provides a configuration screen to manage the Elastic Path’s Endpoint, URIs, Store ID etc.

Cortex API Configurations
Cortex API Configurations

Category Importer

This feature pulls the catalog from Elastic Path and creates it as taxonomy terms as part of a Drupal Vocabulary, that can be used to tag a product content.

Category Importer
Category Importer

Products Importer

This feature lets you import the Elastic Path managed products. However, only a few meta details like Product Title, SKU, Size Attribute, Price get pulled and it creates a Product node for that. It executes a batch process and imports products one by one.

Product Importer
Product Importer

Access Token Generator

For generating an access token forcibly, you can also use this feature.

Access Token Generator
Access Token Generator

Deep Dive

This section will provide you more details about the module created on sandbox for the integration.

An explanation has been provided about the different directories and files under them for more information about the code structure.

 

Custom Database Table

A custom table cpl_product_mapping has been created to keep the mapping of Products Imported from Elastic Path & created as Drupal Node. The benefit of using this database table is to keep track of existing imports and not to create another new record. Here is the structure of Database table:

mid: – Primary Key / auto increment value.

ep_id: – Elastic Path item code that is unique to each imported product & SKU.

nid: – Drupal node ID.

type: – This tells that what kind of information is being imported to Drupal i.e., a Master Product or Product SKU.

System Flows

This section details about various flows taking place. Here is the list:

Cart Operations

Right now we are using Add To Cart and Delete Lineitems from the Cart flows only. We have not implemented Update Cart feature as part of this POC.

Add To Cart

Cart Item Delete

Order Processing

Order processing requires an access token generated based on information of a registered user in Elastic Path. It would include another process called Merge Cart, i.e., for every user visiting the site, an authenticated token will be generated initially and when he goes to checkout it’ll ask for login information and for a valid credentials it will generate another access token and merge the content of anonymous cart with registered users’ cart.

Flow given below covers only Order processing assuming a registered user’s access token.

Authentication & Access Token Generation

Summary

This integration is one of the potential integrations that can be done with the powerful REST API of Drupal 8. It not only make content and product information available in the same place, however, make authors more capable to enrich the product data in more presentable manner. Apart from that, it gives you the power of using all capabilities provided by a CMS with product data from any e-commerce source.

About the sandbox module, it is a small effort to make this integration possible. Please feel free to drop your suggestion and recommendations in the comment box given below.

About The Author

Leave a Reply

*