Use sandboxes

Transcript

In this video, we’re going to talk about sandboxes in Adobe Experience platform. A sandbox is a virtual partition of a platform instance. Using sandboxes, you can develop, test, and experiment with platform features without affecting your production environment and run multiple platform-enabled applications in parallel.

When you create resources, ingest data, and perform other data operations in platform, all of the activity is contained within a sandbox. When you create additional sandboxes, you are essentially creating different separate versions of your platform instance. Each sandbox maintains its own resources, including schemas, datasets, profiles, and more, and actions taken in one sandbox do not affect any other sandboxes. Outside of experience platform support for sandboxes varies across the experience cloud ecosystem, such as in Adobe Target or Adobe Audience Manager. For details on how each product support sandboxes, please refer to the documentation. There are two types of sandboxes in platform, production sandboxes and development sandboxes. A production sandbox is meant to be used with profiles in your production environment. When you purchase platform, you have one production sandbox, which is a default sandbox for your organization. If needed, you can create additional production sandboxes dedicated to distinct lines of business, brands, projects, or regions. However, only one of these production sandboxes can be set as the default. Unlike other sandboxes, the default production sandbox cannot be deleted or reset. When integrating with platform, certain applications like Adobe Target and Adobe Audience Manager are only able to work with the default production sandbox. By contrast, development sandboxes are used exclusively for development and testing with non production profiles. Your development sandboxes can collectively use up to 10% of your license profile commitment. A default experience platform license grants you a total of five sandboxes. Each of these sandboxes can be classified as production or development depending on your business needs. If required, you can also license additional packs of sandboxes. For more information on sandbox licensing, please refer to the documentation.

Access to sandboxes must be granted by an administrator through Adobe admin console. Within the permissions tab of a platform product profile, administrators can control access to individual sandboxes in the same way as permissions to platform features and capabilities. See the video on how to control access to platform using admin console for more information. In the platform UI, the sandbox ribbon shows which sandbox you are currently working in, including whether it’s production or development. Using the sandbox switcher, we can quickly switch the experience between any sandbox that we’ve been granted access to through Adobe admin console. In our case, a production sandbox and a development sandbox. Note that in production, there are a number of schemes and datasets already defined and in use. Switching to the development sandbox, these are gone, providing a clean slate for us to begin experimenting and testing. Also, notice that in the development sandbox, some of the features in the left rail are unavailable. This is because there’ve not been permission to our user for this sandbox in Adobe admin console. Let’s say that we’re running some experiments in our development sandbox. After we’ve ingested data and attempted to run a query on the resulting data set, we realized that some key fields are missing and we need to try again. We could just upload a new dataset in this case, but since we’re working in a development sandbox, we have the option to reset the entire sandbox instead. This allows us to start from a clean slate and not have to worry about getting confused by the old, incomplete dataset. If we’ve been granted sandbox reset permissions through admin console, we can go to sandboxes in the left nav and select the sandbox we want to reset from the list. After selecting sandbox reset, we’re warned that this will delete all user-created resources in the sandbox and that this cannot be undone. We’ll confirm our choice by entering the sandbox name. And after hitting Reset, our sandbox is returned to the original pristine state. We can now continue running experiments on our data and operations. And ultimately, with confidence, we can switch to production and load any changes we may have proved out in the development environment. Keep in mind that the default production sandbox cannot be reset if the identity graph hosted within it is also being used by Adobe Analytics for the cross-device analytics feature, or if the identity graph hosted within it is also being used by Adobe Audience Manager for the people based destinations feature. If we have sandbox administration permissions for platform, we can also use the Sandboxes tab to edit the basic details for the sandbox. If a sandbox is not currently acting as our default production sandbox and we otherwise don’t need it, we can also delete it from here.

Finally, let’s take a quick look at how sandboxes work in platform APIs. In platform API calls, the x-sandbox-name request header is used to indicate which sandbox and operation will take place in. Here in Postman, let’s make a call to the catalog API to list all data sets. Providing the name for our development sandbox and our API call, we can see that this only returns a single test dataset that we uploaded to the development sandbox earlier. If we switch the sandbox name to prod and make the call again, we can see all of our production data sets.

You should now have a better understanding of how to leverage sandboxes to use, explore, and experiment with platform features without the risk of adversely affecting your production environment. For more information on managing sandboxes in platform, please refer to the documentation. Thanks for watching. -