How to handle difference in landscape in ChaRM

[FransLelieveld]

We have a SAP landscape consisting of

• a BW Development/QA instance (1 client) and a BW production instance (so transport from BWD 100 --> BWP 100)
• a ECC Development instance (2 clients), ECC QA instance and ECC Prod instance (transport ECD 101 --> ECD 100 --> ECQ 100 --> ECP 100)

We want to use ChaRM with transport management for this landscape.

How can we handle the difference between the different landscapes? I suppose a solution would be to define different task lists for each system, but that would mean we would get different projects as well. Is there an alternative?

[Former Member · Accepted solution]

Hi Frans,

It is good to keep 2 different project for your scenario, the reason would be

1. You can maintain 2 logical components ( one for bw and other for ECC) for one project, but the risk is you need to make a move for phase changes in both these system tracks, which is cumbersome, you cant expect this always both systems go same time for same phases.

2. BW and ERP logical components cant tie together in any solution with any valid business cases, until unless you have dependency like ( CRM goes to ERP) then you can tie these logical component together in a change project,

3, BW transports are quiet risk, its good to keep the separate charm project for bw.

But i am looking any possibility to use Central cts+ released on Sp10 for this usecase. I will update you if I got some input for this,

Best regards

Jansi

[FransLelieveld · Accepted solution]

Hi Jansi,

Thanks for your reply. Some further questions:

1. You can maintain 2 logical components ( one for bw and other for ECC) for one project, but the risk is you need to make a move for phase changes in both these system tracks, which is cumbersome, you cant expect this always both systems go same time for same phases. 

Actually the phasing would not be a problem as we will be using urgent transport mainly/only. The question is more if it is possible to handle the transports for a 2 system and a 4 system landscape from within the same maintenance project in some way (with the same transaction type).

2. BW and ERP logical components cant tie together in any solution with any valid business cases, until unless you have dependency like ( CRM goes to ERP) then you can tie these logical component together in a change project,

I don't understand this. Why is it not possible to tie together BW and ERP logical components? Can you ellaborate a bit on this?

3, BW transports are quiet risk, its good to keep the separate charm project for bw.

So you say it is better to have BW and ERP in separate maintenance projects anyway?

Having 2 maintenance projects also makes it difficult to connect the maintenance projects to the Solution as there can only be 1 for a Solution.

[Former Member · Accepted solution]

Hi Frans,

ctually the phasing would not be a problem as we will be using urgent transport mainly/only. The question is more if it is possible to handle the transports for a 2 system and a 4 system landscape from within the same maintenance project in some way (with the same transaction type).

If you dont have constraints on running parallel then, you can proceed with single Project, its purely depends on your actual requirements.

I don't understand this. Why is it not possible to tie together BW and ERP logical components? Can you ellaborate a bit on this?

You can add as many as logical component in one solution, But one of the best practice could be group the system based on business use cases, like CRM, ERP and SCM can be one solution, because business process flow like order from CRM, goes to ERP, update in SCM, But technically there is no restriction to add any systems and any number of logical components into one solution.

So you say it is better to have BW and ERP in separate maintenance projects anyway?

This is my personal opinion, because I think of complexity and suggested, but you can try of with one project too. There is no technical discrepancy, since Charm still follows your STMS transport route, irrespective of number of systems.

Best regards

Jansi

[prakhar_saxena]

Hi Frans,

You can also have a single maintenance project with 2 logical components

then you can use it by creating a single RfC with multiple Change Documents or 2 Urgent corrections for your ecc and bw respectively

check my article below

http://scn.sap.com/docs/DOC-46777

Further, in my opinion you don't need to create a new transaction type but rather a short cut or action to skip one system stages status for BW.

Which means you have an action which will directly go for BW changes from Status say 1 to N and skipping some middle status values which are valid for ECC.

I hope above resolves if not let us know

Regards

Prakhar

[FransLelieveld]

Hello Prakhar,

I am sure this will work if both the ECC and BW landscape are similar, but that is not the case. My ECC transports have 3 steps before they are in production, BW only 1 step. So my question actually is wether I can use 1 single maintenance project/cycle to handle transports for both the BW landscape as for the ECC landscape.

[Former Member]

Hi Frans,

I had such missions before with different landscapes but i didnt created separate Charm Transaction type for each system.

Right now i have Charm for 2 tier landscape likr your BW and 4 tier ERP.

Any questions welcome.

Rg Dan

[prakhar_saxena]

Hi Frans

it doesn't matter because you can design the combination of action and status profile in such a way that it will take care of 2 3 4 or 5 tier without any hassles

infact we have multiapproval as well now

thus create a configuration workflow as per your requirement

Regards

Prakhar

[FransLelieveld]

Hi Daniyar,

That sounds like my environment. How did you set that up? 1 maintnenace project with 2 logical components? If so, how do you link the 2 tier and the 4 tier landscape with their status related transport moments to the different landscapes?

For example: When change doc goed from In Development to Unit Test in the ECC environment it needs to be transported to test environment, but in the BW environment it should stay in the same client as there only is a development and a production client. Or is this handled automatically by ChaRM becasue there is no target system?

[FransLelieveld]

Hi Prakhar,

Thanks for your reply.

So I can have 1 maintnenace project with 2 logical components? If so, how do you link the 2 tier and the 4 tier landscape with their status related transport moments to the different landscapes? 

For example: When change doc goed from In Development to Unit Test in the ECC environment it needs to be transported to test environment, but in the BW environment it should stay in the same client as there only is a development and a production client. Or is this handled automatically by ChaRM becasue there is no target system? Or do I need to put special conditions in the actions?

[prakhar_saxena]

Hi frans

Since the BW doesn't have quality in your case the cycle will be executed with changing status only and nothing will happen in terms of transport to production

transport to production will happen only later on when they are ready to be imported and awaiting in the queue.

Regards

Prakhar

[Former Member]

Hi,

Yes we have one Maintenance cycle for all systems including ERP, BW, SOLMAN( dev - prd ).

Yes this handled automatically by Transport Routes Design, Charm only triggers if there is test system it will go there if there is not test system, so you only get status updated.

Don't bother so much its more Basis question than Solman CHARM.

Rg Dan

[Former Member]

Hi Frans,

BW landscape having 3 system landscape.

ECC system having 4 system landscape

So first create the two customize trans type Z* and Y* ( like ZMHF /ZMMJ  - 3 system landscape and YMHF/YMMJ - 4 system landscape ) for SMHF or SMMJ.

Also create the separate project for BW and ECC landscape and use the ChaRM.

Rg,

Karthik

[FransLelieveld]

Thanks Karthik. I agree separate transactions could also solve this. But this would make things messy and complicated especially if there would be other types of landcape to (the example I gave is just a sample).

Regards,
Frans Lelieveld