Sandbox Tooling - Full sandbox package installation on reset sandbox skipping custom schemas and datasets

[bjoern__koth]

Hi all,

has anyone come across issues with the sandbox tooling when it comes to deploying a full sandbox package on a freshly reset sandbox?

The job says success, but the details basically say nope.

On top of that, the import details just show a blank overlay.

and my custom schemas all got omitted as if something kept them from being installed properly.

however, my custom datatypes, identityNamespaces and field groups are all there.

Again, the target sandbox was just wiped 5 minutes before which the dialog even suggests.

It almost looks like things were not imported in order to make sure dependencies are met, leading to this behavior.

I mean, what makes a successful job? That everything from Adobe side is present but ignoring the 50% missing custom item? xD

[bjoern__koth · Accepted solution]

Ok here's the solution to above question. It was a lot of trial and error and discussions with support.

The error logs were showing that an $id was not found in the package which makes little sense, given that the sandbox tooling should handle these $id values by itself.

Important to understand here is that the $id values of a resource like a schema change from sandbox to sandbox when you are using the sandbox tooling.

They do not change however, when you use the API (/rpc/export/ and /rpc/import/) to shift the resource from sandbox A to sandbox B.

Ok, so the sandbox tooling should handle these different $id values for packages that include all resources that use a given resource.

Example: you have a custom data type A that is used in schema B and schema C. As long as your initial package contains custom type A, schema B and schema C, sandbox tooling will make sure that the changed $id of custom type A is updated in the JSON definitions of schema B and C.

• type A
• schema B
• schema C

However, this still did not work, and the error I was seeing was indicating that this $id rewriting did / does not work properly when you have dependencies between custom data types.

In our Example, we now have a custom data type A2 that custom data type A references

• type A2
• type A with field n of type A2
• schema B
• schema C

This won't work anymore in the sandbox tooling, which looks like a bug or missing feature to me.

Workaround

• as a workaround, I had to refactor A2 directly into A (and in my case a couple other locations)
• benefit: sandbox tooling runs through
• disadvantage: potentially high maintenance overhead upon any future changes/extension of my previously isolated custom data type A2 (now part of A et. al.).