Skip to Content
Author's profile photo Former Member

My Sandbox and Me

“Hmmm… Transports between environments… That could be complicated…” This was one of my first thoughts when I started working with SAP BW and for the first time had to deal with making changes in a Development environment to transport them later on to QA for testing and, finally, to Production.

The typical / classic SAP BW landscape (and that of SAP R/3 and many other platforms) is Development – QA – Production. Anyone who has worked in an implementation is familiar with how high can be the volume of transport requests generated while developing, making changes, adjusting, fixing, etc. You have to really pay attention if you don’t want to have problems when moving all those transports to Production and, even worse, compromise what was working fine up to that point.

Yes, it can be a nightmare.

So, how to avoid or minimize the common mistakes (hey, we’re humans after all) and production emergencies when transporting massive amounts of transports requests for a new project?

That’s when the advantage of having a Sandbox environment comes to the picture.

A Sandbox environment, as the word indicates, will allow you to “play” with your new development, make changes, delete, activate, etc., without compromising or impacting your Production Landscape. It has been a practice I have reinforced in every project I have worked on and it has proven to be a very successful one.




Here, the Sandbox environment is totally disconnected from the rest of my landscape, isolated, no transports come from it. It only connects to, in my case with BW, R/3 Development and R/3 QA.


The “Gold Client”

The idea of the “Gold Client” in a landscape comes from the need of having a pristine environment where all your development objects reside that can be used, among other things, as reference and as starting point to re-create from scratch any environment (QA, Production, etc.) in your landscape in case your Disaster Recovery (DR) strategy fails and you can’t recover from backups (Yes, it happens).

It is good to notice that the “Gold Client” does not contain any data, only prototypes, structures, development or any other way you’d like to call it. It’s just a skeleton, a template, a mold.

In this worse-case DR scenario you just make a copy of your Gold Client, change the logical System Names and mappings to Source Systems and start loading the data.

As you know, different to R/3, we can’t have more than one client in the same SAP BW instance, like Development Client 100, Client 500, etc.

In this case, my Development environment is my Gold Client and my Sandbox is my Development Client.

Once my initial Unit Test is done and completed in Sandbox, that version is the “final version” of my development, after normally several enhancements/change cycles, the one ready to move to my BW QA environment. 


Development Cycle 

These are the steps of the “development cycle” I normally follow, once the Requirements Gathering and Analysis phases are completed, of course, all this in my BW Sandbox environment:

  • Develop extraction structures in R/3 Development (Datasources, includes, views, etc)
  • Develop BW structures in BW Sandbox (Infosources, DSOs, InfoCubes, etc.)
  • Connect BW Sandbox structures to R/3 Development structures (Replicate Datasources, map Infosources to Datasources, etc.)
  • Test load (small sample of data from R/3 Development) 
  • Basic Unit Test
  • Transport R/3 structures to R/3 QA
  • Connect BW Sandbox structures to R/3 QA structures (Replicate Datasources, map Infosources to Datasources, etc.)
  • Test load (more and better data from R/3 QA)
  • Validation, initial Unit Test with Key Users
  • Key Users / Development sign-off to move to BW QA

As I mentioned at the beginning, I just did all this without generating a single Transport Request in BW since my Sandbox does not participate in the Transport Management System. The only transport request(s) created is (are) in R/3.


Moving to the Production Landscape

The next step for me is to “replicate” the final version of my objects from Sandbox to Development. Remember there’s no transport from Sandbox to the rest of the landscape, so the only way for those objects to get there is by replicating them in Development.

Now, this is one of the arguments people make when this approach is presented: The developer has to work twice.

Well, it depends on how you look at it.

By doing this, first of all, you’re creating something that was already tested and you know it works. Second, it doesn’t take that long to just replicate what you have in your Sandbox environment to your Development; you can always copy and paste the routines, code, etc. Third, and this is probably what I like the most, you are “forced” to double-check what you’re doing so there’s some “Quality Control” process going on while you do that.

Once the replication is completed and since we don’t have data in the Development environment (Gold Client, remember?) you transport your objects, in a single transport request, maximum a couple, depending on the type of objects, to your BW QA where you’ll load data and finish the Unit Test, Training and Validation with the additional advantage that you can use the same Unit Test script you used in Sandbox where you already know what results to expect and how to validate them.

After you’re done in QA, then it is to Production, preparation, Go Live and celebration… 🙂

I have been using this type of landscape in all my Projects and it has proven successful to me over and over.


Some Points

  • Sandbox is a safe environment where you can play and even make mistakes that otherwise would impact your Production Landscape
  • Minimizes the amount of Transport Requests going on in your landscape, especially during new implementations and big projects where several people are working at the same time which provides a better Transport Control
  • Better control over what’s transported, what can be affected/impacted in the existing environments
  • Helps you maintain a cleaner and more “in-sync” Production landscape
  • Doesn’t complicate your Landscape. In my case, Sandbox is on its own physical server while Development and QA reside in the same server, since my Development, as Gold Client, is so small so I still have 3 servers in my landscape. No need for an additional box for Development
  • Sandbox can be “refreshed” at any time (a copy from Development before starting any major project, for example)
  • Provides you with a real “Gold Client”

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Martin English
      Martin English
      Hi Luis,
        One of the issues is the data management - when you have multi terrabyte systems, its gets hard to justify ( yet) another system.  Of course, you should make the sandpit much smaller than the QA or Production (and Regression Testing, if you have one) systems, but not every one know how to do this ( and, given the BW internal structure, just reducing the volume of data being loaded from R3 / ECC6 doesn't always help.
        Large size systems are also harder / take longer to backup and restore, which is a useful adjunct to Cloud / Virtual Computing.

        Have you any ideas or tips on how to reduce data volumes so that the sandpit become more mangeable ?

      Author's profile photo Nelis Lamprecht
      Nelis Lamprecht
      "Have you any ideas or tips on how to reduce data volumes so that the sandpit become more mangeable ?"

      You could use TDMS -

      Author's profile photo Former Member
      Former Member
      Blog Post Author
      Hi Martin,

      I agree with you. You don't want your Sandbox to become a nightmare for you.

      Normally we "refresh" it making a copy of our Development environment, where there is no data, then load small portions of data, let's say 2-4 months or fiscal periods, for the specific area we're developing and testing at that point. We do this normally before starting any new development "wave" or project.

      Once the project is done, we either delete the data from it or just refresh Sandbox again.

      That way the size of Sandbox remain basically under the same limit in every cycle.

      I wouldn't advise making a copy of Production or QA to refresh your Sandbox since then the space requirements would have to be the same as those environments.

      Even in our BW QA we just keep 3-4 months of data, no more than that... Of course, in case we need to test some year to year comparison or something similar, we'd load selectively the data we need.

      It's kind of "recycling" the space in those environments so integral growth is limited. Of course, it's just one of many ways to do it.

      Author's profile photo Juan Reyes
      Juan Reyes
      Love the blog, I'm also a big fan of sandboxes...

      From the Basis point of view its a great platform for proactive maintainance and solution testing.