Skip to Content
author's profile photo Former Member
Former Member

Does CHaRM support a dual track system landscape phased project approach?

Hi All.

I'm in the process of rolling out NW 2004s SR2 (ECC 6.00, PI/XI 7.00, BI 7.00 & Solution Manager 4.00) here driven centrally from a SAP Solution Manager project connected to the local DEV img's and I'm considering using CHaRM.

As this is a "phased roll-out" (by Business Division) we are implementing a dual track system landscape (SAP Standard) with dual Dev & QA systems in the ECC 6.00 landscape. The deployment plan is as follows:

Release 1 Implementation

ED1 -> EQ1 -> EP1

Release 2 Implementation (Release 2 into Support)

ED1 -> EQ1 -> EP1 (Support track Release 1)

ED2 -> EQ2 -> EP1 (Release track after cut over to production)

Release 3 Implentation (Release 1 & 2 into Support)

ED2 -> EQ2 -> EP1 (Support track Release 1 + Release 2)

ED1 -> EQ1 -> EP1 (Release track after cut over to production)

Release 3 etc. up to Release X with the Dev system alternating between Support and Release tracks.

It's a little bit more complicated than that as we have production approved transports going to Migration and Training but I assuming that the TMS delivery group will handle that.

I am assuming that you would have an "implementation cycle" project and a "maintenance cycle" in existance with CHaRM at the same time with the systems being moved within project landscapes within SMSY.

The big question for me is that we intend to "feed back" production approved transports from the Support (maintenance project) into the Development system of the next release track (implementation) to handle potential clashes between objects changed between releases.

The frequency and scope of the clashes is assumed to pretty low as we are 90 - 95% SAP standard, to a near enough common template between Business Divisions / Releases with the bulk of the project scope post initial go-live being data migration work.

On previous projects using Enhanced CTS and TMS with QA approvals and Virtual systems, I've checked for these "clashes" using a variety of bespoke reports (Accenture) and manually on transport error but does anyone know how CHaRM would handle this or do this for me automatically?

the questions.....

1) Does the "cross client / system" lock have anything to do with this?

2) Has anyone else out there done this before?

3) Is CHaRM stable and mature enough to support this?

4) How would the link between the two landscapes / project work?

5) What's the integration with CTS+ for non ABAP (PI/XI) transports / objects like with CHaRM?

6) Does it work like a CHaRM?

Sorry for the chapter and verse (long post) but I wanted to state the position clearly. SAP AGS are hopefully lining up a day's consultancy on this with a CHaRM expert but that's a few weeks off and some blueprint deliverables are looming.

Any assistance, advice, guidance or real life experiences with this would be truly appreciated...

Best regards

John Watson

SAP Basis Consultant.

Add a comment
10|10000 characters needed characters exceeded

Assigned Tags

Related questions

2 Answers

  • author's profile photo Former Member
    Former Member
    Posted on Jan 27, 2008 at 01:39 AM


    Your planning is quite sound and should be on-par for ChaRM with a few corrections to your assumptions. One is that when you have a dual-landscape as such, you really cannot automate the support transports into the next release - this should be done manually for a number of reasons but a good pratice to get in so when you apply support packs or upgrade, you are already used to it. One other good reason for doing this is that not every change is necessary in the next release - additionally some changes can cause problems (such as old notes being applied to a system that is already ahead in support packs due to the next release - also developer code can get overwritten if the change is in a program that has changes applied due to the next release). Killed that to death but it is an issue that you should keep from getting in the middle of and manually helps ChaRM to work properly as you create the new change in the support landscape manually so it will cancel out when you goto production if it is a necessary change. One good point to use to keep things sane is that you don't send a transport to PRD unless it has been applied or addressed in the next release.

    This answer also keeps you from running into issues with Urgent Corrections feeding back to the other landscape because they are two distinct cycles. If you lay it out on paper - it makes sense and keeps things simple, which is what you want to do - keep it simple as much as possbile.

    Additionally there are other ways to do this which are completly different than how you are expecting to do it that work even better with ChaRM, but require a lot of developer control. Just not enough time and space in a question/answer thread to talk about all of these possibilities.

    Add a comment
    10|10000 characters needed characters exceeded

  • author's profile photo Former Member
    Former Member
    Posted on Jan 28, 2008 at 08:56 AM

    Hi David....

    Thanks for the response, good concise advice of which i will duly take.

    Nice to have a the decision ratified.

    All the best and thanks again.

    John W

    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.