Salesforce Commerce Cloud’s public cloud-based sandboxing solutions can be set up quickly, used as part of a CI/CD process, and offers improved performance. The on-demand sandboxes offer numerous advantages over the traditional model, including a usage-based pricing model, flexibility, and the ability to scale.
Sandboxes are testing environments that offer companies virtual settings to build, test, and deploy software. They sequester untested code changes and experimentation from the production environment/repository, using virtual servers to test software in an isolated environment – this allows developers to test specific features without worrying about compatibility issues due to programs running in the background.
Sandboxing solutions, such as the ones offered by Salesforce Commerce Cloud, can be easily reformatted for repeated use, which provides the ideal environment for testing IT solutions. A company can use them to improve the development process, identify and fix bugs, test patches, and analyze suspicious software, malicious code, and other threats without contaminating their own systems.
Sandboxing technology offers businesses numerous advantages, including :
- Easy creation and deployment of environments at scale
- Enhanced collaboration across departments
- Access to advanced networking and nested virtualization support
- Significant cost savings
All sandboxes are part of a realm, which is a combination of instances.
Sandboxing technology initially offered only POD-based sandboxes, which were part of the Secondary Instance Group (SIG) and had POD-based Infrastructure. These were not as powerful as Primary Instance Groups (PIG) instances when it came to performance, memory, and storage.
Traditional sandboxing environments needed every company to invest in equipment and infrastructure to provision and deploy virtual servers. Apart from taking up physical space, these servers were expensive to run and maintain. Requesting a new POD sandbox was also time-consuming, especially in big projects where teams could need many of them. The pricing model was a subscription model; companies had to pay whether or not they used the service.
In 2019, Salesforce B2C commerce launched on-demand sandboxes. These public cloud-based sandboxing solutions can be set up quickly, offer improved performance, and can be used as part of a CI/CD process. They offer numerous advantages over the traditional model: the usage-based pricing model, flexibility to manage sandboxes, and the ability to scale.
How on-demand sandboxes work
On-demand sandboxes have completely eliminated the need for localized servers and let companies expand their sandbox usage when needed and roll back usage during slow periods. Salesforce commerce cloud offers these additional features for on-demand sandboxes:
- Reside in the public cloud with independent infrastructure
- Self-serviced via API for sandbox management
- OCAPI and WebDAV settings configurable on sandbox creation
- Quick creation encourages innovation, quick delivery
- Time to live (TTL) setting allows deletion after a specific time
- Usage-based pricing based on credits consumed for sandbox uptime and downtime
Accessing an on-demand sandbox needs you to purchase sandbox credits, enable appropriate permissions and users, and configure a client API ID. Developers can then use the self-service API to create sandbox environments themselves and can also control how many on-demand sandboxes they use and how long they are active. Permissions for creating and managing on-demand sandboxes are integrated with B2C Commerce Account Manager.
To create and manage sandboxes, you must know the ID of your realm. A realm contains the PIG and SIG. The SIG contains the sandboxes. Each realm has a unique four-character ID.
Using on-demand sandbox credits efficiently
Credits must be purchased for uptime and downtime sandbox usage. The credit system offers the flexibility to use sandboxes efficiently. For example, developers can choose to keep a few sandboxes running for an extended period or create many short-term sandboxes – it all depends on their needs. A user assigned to the Sandbox API User role can control how the credits are spent.
When created/ started, an on-demand sandbox begins consuming uptime, at the rate of 1 credit per minute/ portion of a minute. When stopped, a sandbox consumes downtime, at the rate of 0.3 credits per minute/ portion of a minute.
Sandboxes consume credits even in the “stopped state”; they only stop consuming credits when deleted, which is why they should always be deleted when not needed. It is advisable to stop and restart the same sandbox only if you must retain that particular set of data. Developers who need a sandbox repeatedly for the same purpose should consider using APIs to automate creating a sandbox and importing the applicable data and code. This allows them to quickly recreate the sandbox environment after it is deleted.
Best use practices for on-demand sandboxes
An on-demand sandbox allows configuration of an optional Time-to-Live (TTL) value that specifies how many hours the sandbox lasts. So, if a sandbox has a TTL of 24, it will last for 24 hours and then automatically be deleted. It is vital to remember that a sandbox will be permanently deleted and no data will be available after the TTL value is reached. The maximum TTL for a sandbox is 2,160 hours. A sandbox with a TTL value of 0 or less lasts until it is deleted.
This makes it ideal to specify a TTL that is exactly when you need a sandbox for short-term use. For a project with an uncertain end date, a TTL of 0 or less ensures that the sandbox lasts until it is deleted. Or else, a large TTL such as 2100 hours keeps the sandbox going until you manually delete it after the project is completed.
An administrator uses an Account Manager to assign appropriate roles to users of on-demand sandboxes. For each role, it is essential to configure a scope filter and set it to all sandboxes in the realm. Users assigned to the Sandbox API User role can consume credits and affect costs, so this role is typically not appropriate for developers. Developers can use all other roles to fully access on-demand sandbox features.
The Sandbox API can be used to manage on-demand sandboxes.
Get/Update Realm operations include the following, using the Swagger UI
- Create a sandbox
- Get details on the list of sandboxes
- Find details about a specific sandbox
- Update a sandbox
- Delete a sandbox
- Start/stop/dbinit/restart a sandbox
- Get the list of operations performed for a sandbox
- Seek a list of operations for a sandbox with a specific operation filter
- Obtain sandbox settings
Like traditional sandboxing solutions, on-demand sandboxes offer isolated testing environments to run programs and execute files without affecting the application, system, or platform on which they run. Remove this isolation, and any application or system process could get unlimited access to all user data and system resources on a network.
Apart from offering multiple out-of-box features, SFCC on-demand sandboxes can help hasten innovation, increase developer productivity, and accelerate continuous integration and delivery.
Latest posts by Shifali Dumpala (see all)
- Tactics to Enable a Headless Approach Using SFCC - March 31, 2021
- How SFCC Can Help Reduce Cart Abandonment and Convert Online Shoppers - March 30, 2021
- Explore the Out-of-the-Box Features on SFCC: On-Demand Sandboxes - March 30, 2021