In ECC 6.0, can I link a CTS project id to a transport target group?

[Sajid]

I have searched a lot of blogs and forums but could not get an answer to this question. In ECC 6.0, can I link a CTS project id to a specific transport target group? Is there an alternative to achieve this ?

I configured two IMG projects, namely, Phase1 and Phase2.  In SPRO, I tied them to CTS project ids, DEV_P00001 and DEV_P00002, respectively.  In STMS, I configured two transport target groups called /PHASE1/ and /PHASE2/ that I want to link with the corresponding project ids.  The intention is that Phase1 transports will go to the clients specified in the /PHASE1/ target group and that Phase2 transports will go to the clients specified in the /PHASE2/ target group

I want to link the CTS project ids to the respective transport target groups so that (e.g.) if a team member creates a transport in SE01/SE09/SE10 and chooses the DEV_P00001 project id from the Project dropdown, then /PHASE1/ will appear as the default transport target.  Likewise, if the team member instead chooses the CTS project id DEV_P00002, then /PHASE2/ will appear as the default transport target.

Right now, the user has to REMEMBER to choose the correct combination of CTS project id/transport target group.

Currently Solution Manager is NOT involved in this scenario but can be used if needed.

Does anyone know of a way to do this in ECC 6.0?

[Former Member · Accepted solution]

Hi Sajid,

Your requirement actually fails the entire concept of project management. Project management was brought into picture so as manage different projects with in a single landscape.With your requirement you might as well get rid of need of project id. I mean for repository object changes the entire program/table definition etc. would get transported to both the clients. So only thing left is customizing. Customizing transports if I remember correctly (has been few years since I have worked on transports) as such don't warn about cross project dependencies but anyways that might not be your concern. Simply ask users not to use projects and use target groups. Of course if more than two projects are involved it is a separate ball game altogether.However if you still want it  I had implemented something like this years though it didn't involve different target groups. We created a Z program (dialog program) where in users would specify the description,project etc and request for a transport to be generated for the. The program would create a transport in background and send the e-mail to users within 5 mins of request. Here you can extend by creating a custom table mapping project id to target group and then inserting it.

Regards.

Ruchit Khushu

[Sajid · Accepted solution]

Thanks for the ideas Jagadish and Ruchit. I will explore both options. CTS project in our case is primarily to identify and bundle transports of a specific roll-out and all dependencies  will be handled manually (hopefully).

We are still exploring the best strategy to handle new roll-outs in our global implementation. We are already live with one site and will be rolling out with different sites in near future. I understand there might be issues with dependencies if we use existing development system for roll-out activities, but won't there be challenges if we go with dual development track? How are then two developments systems merged after each go-live?

I guess i am trying to know different approach for multiple roll-out implementations. what are best practices? Is single client for production support as well as roll-outs a good strategy?

Can someone weigh in?

[Former Member · Accepted solution]

Hi Sajid,

For roll-outs you don't necessary need multiple clients atleast in production. Then why have multiple target groups for transports i.e multiple test clients.I mean if you one singular production client then you can't perform proper integration/regression testing with multiple quality clients.

Now coming to the scenario where you have gone live with some countries and are having roll-outs running for others you can have more one approach. One approach is to have a  development system for support route and then retro-fit the changes in the main development system and at the end of every release move the cumulative changes from development to production passing through the entire landscape. So after every release go-live all the systems would be in sync from change perspective except for main development where the version would always be the highest if not then the same as other systems.Many projects follow this kind of an approach. Retro-fitting sis needed and not a merger per se.

Another approach though cumbersome could be having single development system and then retrieving versions of repository objects in development to same version as production  to handle support issues,making the changes in development and moving them through entire landscape to production and then resetting the versions accordingly in other systems (manually in development and through transports in other non production systems).For customizing there is no version dependency on most occassions but if there is it can be again handled in a similar way though not the same way.

If however you have multiple production clients (a rarity) then have multiple customizing clients and then you probably don't need projects.Repository is anyways independent of client concept except SAP scripts which is kind of client dependent repository.

Regards.

Ruchit.

[Sajid · Accepted solution]

Hi Ruchit,

You have been a great help with your input. Here is more specific plan if we were to go with a single client approach. For Support track we will use the path DEV -> TST + INT -> PRD, where INT is new integration test system for roll-outs. For Release track, path will be DEV -> INT -> TST -> PRD.

Out intention is to do final regression/integration testing for the roll-out in TST by applying roll-out transports from INT, (hence the use of CTS project). It's not clear to me when you say "one singular production client then you can't perform proper integration/regression testing with multiple quality clients". Do you see any issue with above proposal?

For overlapping repository changes in DEV we can use version retrieval as you suggested but I am not sure how is customizing handled which normally do not have any versions? I guess we would need to create a set of rules and stick to the procedure.

Thanks again and any additional input will be greatly appreciated !

Regards

Sajid

[Former Member · Accepted solution]

Hello Sajid,

I am not sure abt your plan but lemme explain my statement.: "one singular production client then you can't perform proper integration/regression testing with multiple quality clients".

Suppose you have one singular production client 100 and two test client 110 and 220 and two development clients 010 and 020. Now all customizing changes in 010 will move to 110 while those of 020 will move to 220.So 110 won't have 220 customizing and vice-versa.But actual production client would have both the customizing s. So before moving to production how do you plan to test the effect of 020/220 customizing in 110.Now you have mentioned integration and regression but how do you plan to do that in separate clients?

Regards.

Ruchit.

[Former Member]

Hi Sajid,

I checked the config .. but did not find any config related to project to target group mapping ...

May be you can check with some abaper who can implement some Badi kind of thing so that it will check the field of project and assign the proper target group in the pop-up..

It needs some customisation.

Thanks,

Jagadish.