Learn about the Salesforce Commerce cloud starter kit architecture

Transcript

Welcome back to the Commerce Optimizer SSCC Connector video series. Let’s dive into the architecture of our Connector Starter Kit to understand how all of the pieces fit together.

Looking at the architecture diagram in our Starter Kit repo, you can see we have three main components. We have the Salesforce Commerce Cloud instance, we have the App Builder application, which is the starter kit we’re currently looking at, and we have the Commerce Optimizer instance, which powers your EDS Storefront. Starting with the SFCC side, we’ve created a custom cartridge called IntAdobeCommerceOptimizer. The reason for this is that we needed an in-process extension to leverage the delta exports functionality of the SFCC instance to detect changes in catalog, price, pricebooks, and other entities. Our custom cartridge includes a custom scheduled job which tracks changes in these delta export files. This job also runs on a cadence that you are able to define when configuring the job. It will parse the delta export files, determine the appropriate catalog changes that are relevant, and track them in a custom object called ACOTrackChanges. We then have a set of custom endpoints using the SFCC SCAPI API framework to expose this data in a manner that our App Builder Starter Kit can consume.

Moving to the App Builder side, this is where our Connector Starter Kit lives. App Builder is Adobe’s serverless application framework, and our Starter Kit runs as a collection of runtime actions. These actions handle different synchronization scenarios.

We have asynchronous actions for heavy lifting, like the full site sync that synchronizes all products, prices, and pricebooks.

The delta site sync, which runs on a schedule, checking for recent changes using our Track Changes custom API, and then syncing only what’s been modified.

We also have a set of synchronous runtime actions which are manually triggered from our admin UI. Taking a look at this UI, we can see it does a few things here. We can trigger any of these asynchronous actions as well, including the full sync and the delta sync, each which can run for up to three hours.

We also have a metadata synchronization, a pricebook sync, and a specific product sync repindefined SKUs that you would like to sync immediately. We also have a few basic actions for checking connectivity, where we can check our connection to SFCC from App Builder, as well as Commerce Optimizer. After running the synchronization, you can also use our Storefront API validation runtime action, which takes an input of a SKU, pricebook ID, and a locale. This will retrieve data live from our Storefront Catalog Service API. This gives you a good validation mechanism to be sure that your sync data will appear correctly on your storefront.

The data flow is straightforward. The SFCC instance will detect and expose changes to your catalog. The Connector Starter Kit’s runtime actions will retrieve your catalog from the SFCC APIs, transform the data as necessary, and then synchronize it to Commerce Optimizer using our TypeScript SDK.

State management is handled through App Builder’s state service, allowing us to track things like last sync timestamps and whether a synchronization is currently in progress to prevent conflicts.

If we go over to our ACO Sync Panel UI again, we can see the timestamps which these syncs have last completed. This state tracking allows us to intelligently run delta synchronizations when necessary, so that we only pick up unsynced changes in your catalog. All of this is orchestrated through the App Builder runtime actions that are defined in your code. If we go back to the repo, we can look at this app config.yaml.

This manifest houses the definitions for all of our runtime actions.

These actions are then defined in the actions directory, where they can be fully customized or changed to your needs.