“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.
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.
- 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”