Working with target groups in ChaRM?

[Former Member]

Is it possible to have multiple target groups in ChaRM? Sometimes we need to transport to PRD1, PRD2 and PRD3 at once, but sometimes we only need to do it to PRD1 and PRD2. Should I define different maintenance projects or could such landscape be handled by different logical components in one project?

If I define the logical components for a target group like in [here|http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/15116] [original link is broken] [original link is broken] [original link is broken];, how will they be used in ChaRM? Which destination will be assigned to the transport requests created in ChaRM, will it be the target group or just the single IBase component?

[prakhar_saxena · Accepted solution]

Hi

You can have ur landscape this way

Dev-QA--PRD1

DevQAPRD2

Dev-QAPRD3

so you can create 3 logical components inthe same project or different based upon the requirement

I hope it clarifies.

Regards

Prakhar

[Former Member · Accepted solution]

Thank you, Prakhar.

But how will ChaRM choose the target system or group in the transport request?

Sometimes I need to transport to all the three PRDs, and sometimes - only to one or two. When creating a transport request in ChaRM, the target field is not visible.

[prakhar_saxena · Accepted solution]

Hi

the request follows the logical component path

so if it dev1 qa1 prd1 the request follows that path.

but 2 you need to define a consistent landscape like

Dev Q PRD1

and

Dev Q PRD2

but both PRD can't happen.

so in above case create 2 logical component and you can have them in different project

so when approve a reques based upon Project 1 or project 2 it wil goto PRD 1 or PRD2.

Hope it helps

Regards

Prakhar

[Former Member · Accepted solution]

So if I want to be able to import to all possible combinations PRD1, PRD2, PRD3, (PRD1, PRD2), (PRD1, PRD3), (PRD2, PRD3), (PRD1, PRD2, PRD3) I must define 7 projects with the corresponding logical components?

[prakhar_saxena · Accepted solution]

Hi,

Better to have them separated so that users admin and everyone will be able to understand the different path for diff systems

you can merge but then admin need to be very cautious

you can manage them better but its entirely project requirement decision

based upon the situation you can take the decision.

Regards

Prakhar

[Former Member · Accepted solution]

Thank you, Prakhar, I'll think about it

[Former Member]

I agree with Prakhar - admin/operator who performs the actual import into production must be VERY careful:

in case when you have several target systems in the transport route, when you release transport from source system, the transport is exported into the buffer of EVERY target system that is defined in the route - no matter how you group your target systems.

In the Task List however each producton system will have it's own CTS project generated.

So your operator must be very well aware of which production system is accotiated with which CTS-project so to execure Import from SCMA correctly, and also be aware of what transports are in the buffer of that system at that time - there will be no pick-n-choose once Import is run.

But I don't agree that it is a good idea to create multiple maintenance projects (i.e. separate for each production system) - if all your PRD* systems are fed from the same DEV... In this case it must be just one maintenance project with multiple target systems, I think.

So not much choice...

Elena

[Former Member]

Hello Elena,

I agree with Prakhar - admin/operator who performs the actual import into production must be VERY careful:
in case when you have several target systems in the transport route, when you release transport from source system, the transport is exported into the buffer of EVERY target system that is defined in the route - no matter how you group your target systems.
In the Task List however each producton system will have it's own CTS project generated.
So your operator must be very well aware of which production system is accotiated with which CTS-project so to execure Import from SCMA correctly, and also be aware of what transports are in the buffer of that system at that time - there will be no pick-n-choose once Import is run.

The import into production will NOT be made via SCMA or the change request itself, but directly in STMS via the QA buffer.

We will generate an email with the target systems and transport request numbers out of the change request and send it to the basis team. They are not going to work in the Solution Manager.

So, actually we need that the target group to be written directly in the transport request itself.

Do you think this is possible?

But I don't agree that it is a good idea to create multiple maintenance projects (i.e. separate for each production system) - if all your PRD* systems are fed from the same DEV... In this case it must be just one maintenance project with multiple target systems, I think.

It is ok if the transports are written to all production buffers.

[Former Member]

Has really nobody worked with transport groups in ChaRM??