ChaRM assigns wrong transport group

[Former Member]

After creating transport request via ChaRM, the request is assigned to the wrong Transport group. Customizing changes should target the transport group /RD1CFG/ as outlined in our STMS routes, but it is currently targeting /RD1DEV/.

The following error appears when attempting to release the transport request into the buffer:

Transport target /RD1DEV/ from request RD1K900054 is not standard consolidation target

Message no. TK010

Diagnosis

You chose request RD1K900054. This request has the transport target /RD1DEV/. However, in this SAP system the transport routes are configured so that Customizing changes in this client are transported into transport target /RD1CFG/ as standard.

If you do not stick to the configured transport routes, you may cause inconsistencies between the SAP systems in your system landscape.

I believe this may have happened because we changed transport layers AFTER the creation of our task list. Am I on the right track? And how would I go about fixing this issue?

Thanks!

Quan

[Former Member]

Dolores in her blog mentioned this: Pardon me for quoting the entire text as is, (huge wall of text I know, but worth a read.)

6. Changes in the logical components of a project where Charm is already activated

Please never add or remove Logical Components for active project cycle, this is always dangerous.

If you would like to add/remove Logical Component to project landscape or to manually adjust systems (change systems and roles) included in exiting Logical Component for active project cycle after the task list generation, I would recommend always follow the following steps:

Close the current project cycle

Add/remove Logical Component

Generate a new project cycle

Any change in the TMS configuration, in the transport routes for example, will be handling in the same way.

NOTE: When you refreshed the managed system with development role them you need to follow the same steps, closing the current MC and opening a new one or work with a new maintenance project directly. This must be done to avoid problems with the CTS ID project attached to the IMG project.

When you refresh your development managed system, the number range for CTS projects in your DEV system is refreshed to, but that old information is still used in your solman system, closing the cycle and re-creating a new one will generate a new CTS project.

Check in table /TMWFLOW/PROJMAP that CTS_ID projects are always unique.

The task list is generated with help of some tables:

/TMWFLOW/TTRCKHC transport track header

/TMWFLOW/TTRCKEC transport track entries

/TMWFLOW/CMSCONF all systems in the task list

A transport track contains all systems belonging to exact one development system.

'Belonging' means: they are linked by TMS transport routes.

'Development system' means: the systems have the role type 'D' in the Solution Manager (SMI) project.

'All systems' means: they are linked by TMS transport routes and they are included in the SMI project.

These three tables are built up when you define a SMI project and mark it as relevant for the Change Request management.

If you change the SMI project or the TMS transport routes after the generation of the task list, you will have to complete the task list and generate a new one.

Why? when systems in the logical component of the SMI project or TMS transport routes has been changed after the generation of the task list, tables /TMWFLOW/TTRCKHC and /TMWFLOW/TTRCKEC will be updated partly, the tables will be updated in that way that new entries will be created. The new entry in the header table /TMWFLOW/TTRCKHC will get the 'active' flag , and the old entry will remain, but get the 'Completed' flag. The task list will go on working with the old entries. But if you complete the task list and generate a new one, this will use the new entries.

To consolidate the above information, I think this is what you need to do:

Close the cycle,

Make the changes to TMS/Log Comp.

Recreate a new cycle.

Hope this helps!

Cheers!

[Former Member]

We're having the same issue. Were you able to fix this?

[Former Member]

Have you tried refreshing the Project in SOLAR_PROJECT_ADMIN; Systems Landscape: Change Requests Tab, since you altered the transport layer?

Paul