SFCC - Automating On-Demand Sandbox Operations

Salesforce provides us limited no of Sandbox credits, and as a primary On-Demand Sandbox Owner, it falls upon you to use those credits judiciously. To achieve this you might have calculated the no of hours you need to keep your sandboxes up in a day, and how long it would take you to consume your allocated credits.

The key here is to being consistent in starting and stopping your sandboxes at specified time, because if you fail to start sandboxes on time it would impact development and if you fail to stop sandboxes on time, you’ll overrun your allocated credits sooner then it should.

As a Sandbox Owner for your organisation, there are 2 ways you can manage your On-Demand Sandboxes, from Salesforce provided Swagger APIs or by using the SFCC-CI tool. There is also an another way of having a user friendly GUI application from which you can manage Sandboxes, monitor your credit usages and get insight on when you’d next need to buy credits based on your usages, but Salesforce doesn’t provide such an application, So, I have worked to build such application and hoping to release it soon for the community.

Meanwhile, you can follow this guide to create your own process of automatically starting/stopping On-Demand Sandboxes based on a schedule.

Benefits of automating Sandbox start/stop operations.

1. Better control over credit usages:

You can define a schedule on which Sandboxes need to be up, this will help in get a more accurate estimation of how long your credits will last, as there won’t be any human intervention needed.

2. No need to daily remember to start/stop Sandboxes

Sandboxes will automatically start and stop daily at the time you specify, no need to set reminders for them.

We will be using the SFCC-CI tool in this guide to setup a cron to manage the Sandboxes. This guide assumes you are working on a Linux distro and have some experience with shell scripts, if not, help can be taken from a developer having this experience.

Step 1: Setup sfcc-ci tool

Install the SFCC-CI tool from here.

You’ll need to have access to the github repositories to download this. If you don’t have access to them, follow this Trailhead module for steps.

After sfcc-ci is installed, you should see the help documentation when you run sfcc-ci in terminal

Step 2: You’ll need to have the ability to create API keys to proceed further

1. Log into your account.demandware.com portal.
2. Go to “API Client” navigation.
3. Select your organisation from the dropdown, and click on “Add API Client”.
4. Enter “Display Name”, set the password(and note it down somewhere, we’ll need this later), make sure “Access Control” is enabled, Add the organisation.
5. Provide “tenantFilter” in Default Scope.
6. Add these in Redirect URIs section, we might need these if we authenticate using this key from Swagger APIs or using client:auth sfcc-ci command.

https://admin.us01.dx.commercecloud.salesforce.com/oauth2-redirect.html
http://localhost:8080

7. Save the form.

Step 3: Disable MFA for Organisation

This needs to be confirmed with all concerned Stakeholders, even though we will still have MFA enforced for all other roles.

1. Go to Organisations navigation
2. Select your Organisation
3. At the bottom of the page uncheck MFA enabled for all users in the organization.
4. Under Users with the following roles need to authenticate using a second factor. section, add all roles except Sandbox API User role.

Step 4: Create a user for automating sfcc-ci commands

If you haven’t already, create a new user with limited role just for managing Sandbox automation.

1. Add a user in your organisation.
2. Assign Sandbox API User Role.
3. Note the username and password for this user, we’ll need this later.

Step 5: Create a shell script

1. Create a shell script with sfcc-ci client:auth login command.
2. Add actions for start/stop for each sandbox.
3. Create different shell scripts for start and stop actions.
4. Logout after all actions are done (sfcc-ci auth:logout).
5. All paths must be absolute paths in this script including commands and file paths, otherwise cron won’t know which files/commands to run.
6. You can also take reference from the screenshot attached below, this file contains example of starting a single Sandbox, you can replicate this line and change the Sandbox ids to manage as many Sandboxes you want, ideally there should be different files for Start and Stop Operations.

example of a start operation(left), stop operation(right)

Step 6: Create a dw.json for maintaining your login credentials

For storing credentials we have multiple options of using dw.json, .env file or setting up environment variables, in this example we will be creating a dw.json file

1. Create a dw.json file in same folder where you are keeping you shell scripts.
2. The sfcc-ci client:auth used in shell scripts above, looks for a dw.json file and automatically authenticate the user based on credentials stored in dw.json.
3. Sample dw.json file, you’ll need to replace placeholders with the credentials noted previously.

sample dw.json file

Step 7: Create a file for logging Cron outputs

1. Create a file anywhere you want.
2. When cron runs this file will be overwritten with latest output of cron.
3. Note the file path, it will be used when creating a cron entry.

Step 8: Create a Cron entry

1. Run in terminal: crontab -e (to edit crontab).
2. Create entries for all your scripts.
3. Provide schedule when they should run, you can use this link to create the format needed for Cron scheduling.
4. Before that do a test with limited action(like authenticating and stopping a single sandbox) cron running every minute, and check the output in log file, if all ok, create the final entries and schedules for your cron.
5. You can also use Slack notification to be sent when cron runs, refer https://www.cloudsavvyit.com/289/how-to-send-a-message-to-slack-from-a-bash-script/
6. Example cron entry running every weekday 10 AM in the morning

0 10 * * 1–5 sh <path-to-folder>/<script-name>.sh > <path-to-log-file>/<log-filename>.txt 2>&1

Step 9: Enjoy a beer

Well done! You have automated the menial work you needed to do on a daily basis. Your On-Demand Sandboxes will start/stop based on the schedule you have defined in Cron, as long as your workstation where you have stored the shell scripts is running and you have internet access 😉