The following data shows the key tables and persisted JSON structures used by the Sandbox Service.
A ChangeSummary
encapsulates information related to a change made to a sandbox trackable entity. It
stores the change details, as well as author, and state information. It is also aware of exception
information related to problems that may have occurred during an attempted transition at the resource
tier service. It is also aware of rejection messaging to display to the change author should the
change be refused by an approval user.
A ChangeSummaryGroup
serves as a grouping structure that contains multiple ChangeSummaries
. User
authored changes are always grouped together into a ChangeSummaryGroup
at the time of promotion by
the author. Approvers always review groups and can view details on the group to look at more
granular details.
A ChangeDeploy
represents one or more groups (and all the associated individual summaries) that
are deployed at a moment in time. Deployment signifies the operation during which approved changes
are applied to the production state of one or more sandboxable entities.
A Sandbox
is a marker construct to identify changes conceptually. Sandboxes can signify a commonly
used concept, like "default sandbox" or "hot fix sandbox". Sandboxes can also denote a more temporary
concept, like "fall campaign". Changes by multiple users can be associated with a sandbox, and multiple
sandboxes can be active at any time to serve different needs.
Sandbox Services uses the following Common Data Features which create additional tables within the Sandbox Services data schema.
Catalog Trackable - Sandbox Services uses the full complement of catalog and application trackable tables to properly work with incoming changes from a variety of resource tier services supporting a variety of trackable styles.
Durable Messaging - Employs DefaultNotificationHandler
for sending sandbox transition messages
with durable retry. Leverages BLC_NOTIFICATION_STATE
table for message send acknowledgement.
Resource Locking - Employs ResourceLockRepository
for transition resource locking to prevent
collision. Also utilizes locking for message idempotency checking. Leverages BLC_RESOURCE_LOCK
table.