cancel
Showing results for 
Search instead for 
Did you mean: 

ChaRM: Transport strategy

Former Member
0 Kudos

Hi!

We have the following system landscape:

EO1 --> QO2 --> VO2

EO1 --> VO3

VO2 and VO3 are both the virtual systems.

Between EO1 and VO3 and Q02 and VO2 we have a lot of transport routes (SAP, YABK, ZEO1, .., ZIAN).

Now we would like to use ChaRM approach with new client specific transport routes (EO1 --> QO2 --> PO1) as well as leave the old TMS settings unchanged.

The questions we have:

1) Do we need standard transport route u201CSAPu201D for the ChaRM approach?

2) Can we leave the old TMS configuration for old requests, but use ChaRM with new configuration?

Thank you very much!

regards

Thom

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

Thom,

ChaRM will use the transport route as the systems are defined within the project (TA SOLAR_PROJECT_ADMIN).

The system with system role 'source system' is the DEV system, system role 'target system' are your test systems, system role 'production system' reflects your PRD system.

Your STMS configuration should at least contain the transport route between these systems. However more systems or connections with systems are allowed in STMS.

i.e. if you have systems DEV / TST1 / TST2 / PRD and STMS configuration goes from DEV to TST1 & TST2 (in parallel) and from TST1 to PRD.

Your ChaRM project only contains DEV / TST1 / PRD. This will work perfectly within ChaRM as the transport route is known within STMS.

At the same time, non-ChaRM transport requests can simply be imported following the complete STMS configuration.

Hope this sheds some light on your questions.

Roel

Former Member
0 Kudos

Hi Roel,

many thanks for your helpful information. I think you understood my problem.

I have one DEV system that has several transport routes to a virtual system.

Now I would like to add the real QAS system that should get transports from same DEV system via ChaRM-scenario. The same problem I have with the transport from QAS to PRD. There I currently transport to virtual system, but I would like to deliver real PRD system via ChaRM-scenario.

I understood your suggestion to map in SOLMAN only real systems, and do not add any virtual systems.

The question still is:

1) how can I prevent by normal or urgent correction in ChaRM that the transports from DEV to TST don't go to VO3 (virtual system)?

Is there possibilities to choose the transport routes?

Or does ChaRM read the standard transport routes, such a "SAP"?

If Yes, then I have problems, because "SAP" transport routes go to virtual system

2) Does the ChaRM-scenario have any influences for the old and currenct transports using the old TMS configuration with virtual system, because the current TMS settings are:

a) transport strategy: Mass transports

b) CTC=0, no client specific routes

c) We have an automatic transport twice daily (10 and 14 o'clock)

Many thanks again!

Thom

Former Member
0 Kudos

Thom,

1) The suggestions I see:

a. create a Transport Group which contains your VO3 and QAS system and create the necessary transport routes to this group. If you now setup your project for ChaRM and only specify the real systems, SolMan will recognize the correct systems (even though it will give you a full overview of STMS when clicking the button 'Shipment Routes' in the System Landscape of the project - once the Task List is created, you'll see ChaRM only mentiones the systems you've added in the System Landscape). The disadvantage of this is that all Transport Requests you release in your DEV system will be added to the import queue of QAS and VO3. This is of course only a disadvantage if both systems don't need to receive the same changes.

b. Not 100% sure if this is technically possible. Create separate consolidation routes for VO3 and QAS from DEV. Again when you specify the correct systems in the project, SolMan will use only those.

As far as I know, ChaRM doesn't make a choice based on type of transport route, such as 'SAP'.

2) a. I know 'single transport' is recommended by SAP, but this is not a showstopper for the configuration of ChaRM. ChaRM also works with 'mass transport'.

b. ChaRM needs to be client-specific, can be that here there is some interference between ChaRM and non-ChaRM.

c. As ChaRM corrections are all assigned to a Maintenance Cycle and a Maintenance Cycle is based on a CTS project in your DEV satellite system; SolMan is in complete control of your Transport Request. What I mean with this is that if you do automatic import on your systems, only your non-ChaRM changes will be imported. Because by default ChaRM changes all status switches of the CTS project to 'inactive'. From the moment you trigger the import from a Transport Request out of ChaRM in Solution Manager; only then the necessary status switch will be activated and it will be possible to import a change into your satellite system. Periodic import of ChaRM changes is also possible, but has to be scheduled using the correct Task List out of SolMan.

You can look and change these status switches manually in your satellite system with TA SPRO_ADMIN, select the correct project and navigate to tab Transport Request. Here is a button 'CTS Status Switches'.

Hope this helps you a little further!

Good luck and let me know if you have any more questions...

Roel

Former Member
0 Kudos

Hi Roel,

many thanks again. Your information is very helpful.

To save my and your time I enclosed the TMS picture of the actual and target TMS with ChaRM.

[TMS picture is here|http://www.file-upload.net/view-1086963/SDN_TMS_Ist_Soll.jpg.html]

I have thougt about the usage of target group, but the systems don't need to receive the same changes.

Could you please tell me which changes from the current TMS layer/routes do I need to do for ChaRM implementation?

E.g. do I need to switch all the standard transport layer/routes from virtual systems to real QAS and PRD systems or can I start as follows:

1) Leave the current TMS settings unchanged

2) Activate the extended transport control

Result: the current setting will be client specific and all the old transport requests will be moved to client specific transport routes

3) change the transport strategy (from mass transport to single transport)

3) Define new transport layer

4) Define new transport route for SAP objects from DEV to QAS

and assign the transport layer from 3) (client specific)

5) Define new transport route ZXXX from DEV to QAS

and assign the transport layer from 3) (client specific)

6) Define the delivery transport route from QAS to PRD (client specific)

7) activate and distribute the settings

It will ge great if you would find time to answer my question again.

Thank you very much!

regards

Thom

Former Member
0 Kudos

Hi Thom,

If you swith your transport routes from virtual systems to real systems, I'm pretty sure it will work.

No idea what the result will be of your approach - I'd say, if you have the possibility to try it out - do so.

Concerning the different transport layers I don't know. We haven't had that issue yet, so no experience with this.

If I can be of any more help, let me know...

Roel