SuiteCommerce Platform and Architecture
SuiteCommerce Platform and Architecture
This domain tests whether you understand how a SuiteCommerce Advanced (SCA) store is assembled and served: what runs in the shopper's browser, what runs in NetSuite, and which build-and-publish step actually puts a change in front of a shopper.
Layers you must be able to separate
- Presentation: Backbone.js/Marionette views plus Handlebars templates, compiled by the gulp build into the
distro/output, then pushed to NetSuite. - Data and services: models and collections call services that resolve to SuiteCommerce endpoints and to your own SuiteScript (RESTlets, SSP application endpoints).
- Platform: NetSuite records - the web site, domain and hosting setup, items, commerce categories, customers, and the SuiteCommerce Configuration record that switches features on and off.
- Checkout and My Account are separate SSP applications from the shopping application; that is why a broken script can leave browsing healthy while checkout is dead.
Worked example
A theme tweak "doesn't show up" after a developer uploaded files to the File Cabinet. Reasoning: uploading is neither building nor publishing. The change must live in extension source, be compiled with gulp so templates and Sass land in distro/, be deployed to the correct SSP application for the target account, and the site must then be published. If the build was clean, suspect an asset still served from the CDN and confirm with a cache-busting query before deploying again.
Traps
- Treating SCA as server-rendered: page structure comes from client-side views, so "just edit the HTML file" rarely works.
- Deploying to sandbox but testing production (or the reverse) because
deploy.json/local.jsontargets the wrong account. - Forgetting that configuration is data on a record, not code, and that a publish is required after changing it.