I am looking for some feedback regarding usage of multiple clients vs. multiple systems for parallel project development environment. I am constructing a system landscape where I am using multiple clients in the same R/3 server to facilitate development and testing of more than one projects (with same delivery time line). The challenges I am facing are management of ABAP objects (with overlaps) and client refresh from (production system for test data creations).

I would like to know if anybody else has managed similar circumstances and has any suggestion for me.

There are various ways to handle multiple projects within the SAP environment.  The first and in my opinion, when possible, the best is to stop thinking of them as different projects and treat them as one implementation. If as you state both of these are working to the same timeline then I would suspect that they should be treated as one. Please remember that the last place that you want to test whether these two projects coexist is the first time that they run together in your production system.

If you do have to keep them separate a way to do this is for any ABAP that you write to check an own (Z or Y) table to determine whether it is relevant. I.e. have a flag per project determining whether in the run environment the project is active. I would do this with a function module / method so that it is very easy to switch off when no longer needed as then you would only have to change the function module rather than all the programs.

Proliferation of clients often leads to confusion, management and space problems. Wherever possible the simpler the landscape the better. Unfortunately simple is not always possible!

As you have mentioned we are already trying to club together all the projects (changes) with same delivery time. This actually leads us to move towards a coordinated integration test and roll out effort. However, the challenge is we have some project which are starting at the same time, but will go-live at different time line. This adds a difficult dimension of managing all the ABAP (especially when there are conflicts due to changes on the same object). I am trying to address this by separating the
development and test environment for the projects belonging to two different delivery schedules.

I am still interested to use different clients in the development system to facilitate unit test for different projects (or changes) that has to the common delivery time. As for the unit test (especially data conversion) the programs and configurations may need their own set of data. For integration test I am trying to stage all the CTS on a different environment and then perform the complete test there. We have not used multiple clients a lot in the past and that actually forced us to use multiple systems for different project which has been a administrative headache. We are trying to streamline the system landscape (of course with some clean up of development and testing processes along with).

Please let me know if you have any other thought or come across any material that can be helpful for me.

OK there are a few things that I have done in the past. The first as I mentioned before is to separate the new code using a flag on an own table.

I don't know how many systems there are involved in your landscape. Generally when multiple projects have to be catered for I have used a 4 system landscape. Development, system test, UAT and production. What we then try to do is progress the different projects through the landscape at different times. I.E.  projects 1 & 2 start. Project 1's timeline is quicker than project 2's. Both develop and unit test in the development system (using the separating flag).  Project 1 when it is reasonably happy with its unit testing will then move into the system testing environment to start serious testing. Project 2 (as it has a different timeline) will still be in development. Once project 1 goes into UAT (moves out of system test) project 2 can then go into the system test environment. The same thing then happens in UAT. I.E. project one goes into live and project 2 then goes into system test.

If you already have SAP in production you also have to cope with the possibility that a live problem will occur necessitating changes to code that could potentially be being changed by both, either or none of the development projects. This does not seem to happen very often although when it does it can be painful. Some people who have a large budget have then gone to a 5 system landscape (2 UAT systems) and have kept the second UAT system in line with production. Others have decided to deal with this problem as it occurs. In my experience it does not occur frequently and can be dealt with within the 4 system landscape. This normally necessitates bringing the productive version back into the development system, correcting it and promoting it back up into the production system. The advantage that the 5 system landscape gives you is that you can then test against a production release level in the second UAT system. Without it you have to be sure what effect the new release level will have. After this you have to reapply the changes for the different project releases.

In a 5 system landscape when project 1 goes live and project 2 goes to UAT what is normally done then is that the UAT server that reflects live is brought up to date via the CTS and all the transports are applied to production via that system. The UAT test system is then completely rebuilt from that server. This ensures that project 2 will start from the right release.

Even within these complicated landscapes I try to ensure that the projects work in the same client. This is not always possible. When it is not possible a regression tasting phase is normally then included in project 2's testing.

Over and above all this when things get this complicated a release strategy is normally required. I.E. predetermined release dates (say 4) in the year at which point major releases can be implemented. This also tends to force co-ordinated testing / regression testing.

Obviously much of this is very expensive and heavily dependent on budget!

On the subject of multiple clients. when absolutely unavoidable I will have the following
Client 1 - Master UAT client. This has all transports. No testing is allowed in this client. Minimum master data.
Clients 2 & 3 are the different projects clients.
Client 4 is a copy of client 1 and can be used for co-ordinated testing. If it gets messed up it can always be recreated from client 1.
Client 5 is the user training client.

The numbering is not important. The number of project clients would depend on how many there have to be.

The hardest challenge once you start down the route of multiple clients is stopping! What seems to happen is then that as soon as a new project starts one of the first things you here is "I must have my own client, it won't work without it". Beware this route it can be very very expensive in both administration time and real money.

More Function Module
Functions / SAP Script / ALV

Tables
Database Table

ABAP Books List
ABAP/4 Certification, Programming, Smartforms, Sapscripts and Object Oriented Programming Books

Smart Forms
SAP Smartforms

ABAP Menu:
ABAP Example Hints and Tips

Return to Index:-
SAP ABAP/4 Programming, Basis Administration, Configuration Hints and Tips