In this article, we will introduce reasons companies are moving from Salesforce Commerce Cloud to microservices. We will also share some of the major technical considerations you’ll need to make as you plan the transition, and offer you a look at how you might start this migration using Salesforce Commerce’s export features and API.

​
Why Microservices over Salesforce Commerce?

  • Flexibility: Need custom reports? Spin up a reporting service. Need a product importer? Deploy an independent microservice to handle it and ensure that long-running imports don’t slow down your user experience.
  • Speed: Performance has been an issue that Salesforce Commerce users have noted, especially in the admin areas. One of the most compelling reasons to adopt microservices is the potential to speed up internal operations. While you need to understand the latency implications of microservices, the fact that you can scale pieces of your application independently is invaluable in e-commerce.
  • Security: The isolation of microservices can minimize the effects of a malware attack and limit the amount of information hackers can steal.

​
Planning the Salesforce Commerce Migration

Once you know that microservices are the right choice, the next step is to create a plan to migrate each piece of your store from Salesforce Commerce Cloud to your new microservices. Because of its monolithic design, it isn’t necessarily easy to migrate from Salesforce Commerce, but by taking it piece-by-piece and starting with the most valuable functionality, you can start to see benefits early in the process.
The first step is to decide which of the components or services you need to replace first. This decision should be based on your business goals and an understanding of the technical lift required to migrate each part of your store.

For example, if your team is struggling to make bulk edits to products in your catalog, you might want to start with fabric’s Product Catalog. If customers are complaining about a clunky checkout process, you can start with the OMS (order management system).

  • fabric Product Catalog: A product information manager is typically an isolated service that stores your product data, provides an admin interface to modify products, and interfaces with your various distribution channels. Because a product information manager typically stores structured data (product names, descriptions, etc.) and rich media (images, videos, user guides, etc.), you will need a database and file storage system like fabric Product Catalog.
  • fabric Orders: If your primary business goals surround increasing conversions, checkout speed, or offering new payment options, you should start your migration with the OMS. fabric Orders handles incoming orders, processes payments, tracks inventory, coordinates with warehouses and delivery providers, and allows customers to cancel or change orders in progress.
  • User Interface: If the Salesforce Commerce Cloud UI is not providing the experience you want, you might start your migration with the frontend. In this case, you can decouple the Salesforce Commerce UI from the API and migrate to fabric Experiences as a first step. Then, as you build the supporting backend services, you can swap out various parts of the Salesforce Commerce API.
  • Supporting Services: Another place you can start with is your application’s supporting services. For example, if you’re not satisfied with the personalization engine in Salesforce Commerce Cloud, you could replace it as a standalone microservice. If you need subscription options that Salesforce doesn’t support, you could build a pricing and subscription microservice first with fabric Offers and fabric Subscriptions.

Once you’ve decided which part of your e-commerce application to replace first, you’ll need a way to “swap” it in for your new microservice. A common solution to this challenge is to implement an API gateway. Using the gateway pattern, you can abstract the interface to Salesforce Commerce Cloud’s API and replace each endpoint with requests to your new microservices as they go online.

As you move more of your application to microservices, another consideration you’ll need to make is how each service will be networked, monitored, and accessed. This problem gets inherently more difficult as the number of microservices you have grows, so many businesses have adopted the service mesh pattern to assuage this.

Before you “flip the switch” on your new service, you’ll need to move data from Salesforce Commerce to your new microservice’s database. The easiest way to accomplish this is to export the requisite data from Salesforce Commerce, import it into your microservice, and then configure your API gateway to start serving requests through your API instead of Salesforce Commerce.

Exporting Data from Salesforce Commerce

Salesforce Commerce Cloud offers XML exports for each of the schemas they use. You can export your data via the Business Manager or Pipelets. The catalog.xsd schema, for example, contains all your products and custom attributes:

...

<product product-id="123456789">

<ean/>

<upc>123456789</upc>

<unit/>

<searchable-flag>true</searchable-flag>

<tax-class-id>standard</tax-class-id>

<custom-attributes>

<custom-attribute attribute-id="color">navy</custom-attribute>

<custom-attribute attribute-id="size">007</custom-attribute>

<custom-attribute attribute-id="width">N</custom-attribute>

</custom-attributes>

</product>

...

Importing Data into Your Microservices

Once you’ve downloaded the data that corresponds to the microservice you’re currently implementing, you can parse and import the data into your database. These files may be quite large, so you will likely need to load the data in chunks.

Here’s an example in Node that uses the XmlStream library:

const fs = require('fs');

const XmlStream = require('xml-stream');

const stream = fs.createReadStream('catalog.xml');

const xml = new XmlStream(stream);

xml.preserve('product-id', true);

xml.collect('product');

xml.on('endElement: product-id', function(item) {

saveToDatabase(item);

});

If you’re saving thousands of products and each insert takes even a second, this import could take a long time. Even worse, if a single record fails to save, the whole script will fail, and you’ll have to start over or try to figure out where it left off.

To combat this limitation, you can queue jobs up using a service like Amazon SQS in your saveToDatabase function:

...

const sqs = new AWS.SQS({apiVersion: '2012-11-05'});

const saveToDatabase = (item) => {

const params = {

// Add any parameters for SQS here

MessageAttributes: item,

};

sqs.sendMessage(params, function(err, data) {

// Handle errors here

});

}

This example isn’t comprehensive, so be sure to read up on how to process and receive messages in SQS in the documentation.

Note: This article only begins to tell the story of migrating from Salesforce Commerce to microservices-based commerce with fabric. We are currently creating a Salesforce Commerce migration playbook with more detailed information.

Was this page helpful?

Migrate from Shopify Plus to fabricMigrate from Magento to fabric