typical sap charm implementation scenarios and their answers

IT Intelligence Group SAP Solution Manager Training

1. How many development clients are possible?

2. How to work with target groups

3. How to work with transport groups

4. Virtual systems

5. Temporary inactive system flag in SMSY

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

7. Several Solution Managers in the landscape

8. Completing a task list

9. Completing inconsistent task lists (note 933705)

10. Can I delete a project with Charm activated?

11. Scheduling of import job /TMWFLOW/SCMA_TRORDER_IMPORT hourly

12. Import options

13. Return codes and tp errors

14. Urgent correction SDHF stays in the import buffer after the import

15. Working with urgent corrections and normal corrections in the same task list --REALLY

interesting case to know

16. Task list "logs"

17. Error: "No maintenance cycle is opened for the current system"

18. Dump ITAB_DUPLICATE_KEY

19. Retrofit functionality

20. System copy

21. Missing authorizations for READ RFC connections

22. Registering transport requests in ChaRM

23. Report CRM_SOCM_SERVICE_REPORT and email actions not processed

24. What happens when the solman system is down?

25. Special considerations for non-ABAP landscapes in ChaRM


26. In which situations a ChaRM project is locked?

27. Several managed system with same SID

28. Incorrect use of SM_*_LOGIN RFC connection

1. How many development clients are possible?

By default Charm only recognize the standard SAP transport layer (if there is SAP transport layer

pointing the DEV system to the QAS system) so this means that you can create several clients in a dev

system, but all transport orders, of customizing and workbench type, created in these clients will use

the same standard SAP transport layer.

Sometime this SAP transport layer is not used or you want to use the customer Z transport layers, in

this case you need to run report /TMWFLOW/SET_TRACK_GENERATION according to note 922779, after

that you should create a NEW project with its new cycle to get this Z transport layer assigned to the

transport track.

After you decide which kind of transport layer you want to use, you must configure their STMS settings

(transport routes, client specific transport layer,...) accordingly.

Example of client specific transport layer:

http://scn.sap.com/servlet/JiveServlet/showImage/38-50314-60224/Q1.jpg


One example of the use of several customer Z transport layer is when you have different Z transport

layers for different DEV:clients, ZAAA and ZBBB for client 100 and 200 for example and you want to

separate your customizing and workbench changes, customizing in client 100 and workbench changes in

client 200, then by using customized layers for the generation of the transport tracks you will be able to

move the changes using different transport layers. This separation for the moment is only possible using

this customized transport layers.

After you need to define a project with several logical components, one per development client, always

these logical components must fit with the real TMS configuration, them when developer creates a

correction, he can select the source dev system: client.

Usual errors during the project check are: "No consolidation system found for SID-XXX", please see note

922779 carefully because it is very important to the track generation of Charm..

Note: In Charm, during the creation of task list, all possible tracks based on your STMS settings on

managed system and transport layer settings are calculated. Therefore, during the generation of

transport tracks in ChaRM, the transport request type (workbench/customizing) can not be taken into

consideration. And after that, the transport layer of the project will be fixed in table

/TMWFLOW/TTRCKEC (usually standard layer 'SAP'). So when you create a request afterwards, Charm

uses this transport layer (which has been checked as correct and consistent when generating task list)

but will not consider your local settings on DEV systems (which might contain inconsistencies because

they have never been checked in Charm).

Always remind that when generating tracks Charm will try to find connections among all DEV systems

and QAS systems in your system landscape, not only the systems defined in the same logical

components.

However as charm is triggering the "tp import transport request of a CTS project" if you are using two

development clients that will come into the same target system, one qua and one prd system for

example, then you can face dependences issues between the transport requests of these two different

CTS projects.

SAP should always suggest to set up only one development client to avoid inconsistences in the follow

up systems, and make the whole scenario more complex. "Merged" transport routes, I mean two

development clients pointing to the same target, are not SAP recommended configuration, due to this

this scenario is not supported in Charm.

2. How to work with target groups

If you are using target groups in your TMS landscape and you want that all system: clients defined in

your target group get the transport order imported them you need to enter these systems: clients in the

logical component.

Imagine this TMS Landscape:


DEV:XXX-->/Q/ -->QUA:YY1 -->PRD:ZZZ

-->QUA:YY2

-->TST:MMM

You have three possibilities for this landscape:

- Defined/ add each client as target systems to the existing logical component

Click on System Role Assignment and go to System Roles:

Enter a Target system entry like the marked on:



Then:




Then:

Enter QUA:YY2 for Quality2, TST:MMM for Quality3, etc....

Create a separate logical component for each target client.

Z_LC1:DEV:XXX-->QUA:YY1-->PRD:ZZZ

Z_LC2 with Quality Assurance system QUA:YY2

Z_LC3 with Quality Assurance system TST:MMM

This will create a task list with one source system, three target systems: clients and one Production

system.

For urgent corrections the system try to use the shortest way to the production systems, see details in

this URL:

http://help.sap.com/saphelp_smehp1/helpdata/en/b4/f2178b54a546a2a9590ea1be4c8fbd/content.ht

m

"The task list of a maintenance cycle contains all the systems that you defined in the maintenance

project. The task list of an urgent correction contains the production system in which the problem

occurred, and only the systems on the shortest transport route from the development system to the

http://help.sap.com/saphelp_smehp1/helpdata/en/b4/f2178b54a546a2a9590ea1be4c8fbd/content.htm

http://help.sap.com/saphelp_smehp1/helpdata/en/b4/f2178b54a546a2a9590ea1be4c8fbd/content.htm



production system. This implements your urgent correction as quickly as

possible."

In the example the task list of the urgent correction will see this transport track: DEV:XXX-->QUA:YYY--

>PRD:ZZZ

The first quality system of the first LC is used.

The third possibility is to define these LC:

Z_LC1: DEV:XXX->QUA:YY1->PRD:ZZZ

Z_LC2: DEV:XXX->QUA:YY2

Z_LC3: DEV:XXX->TST:MMM

This will also create the correct transport tracks.

Please apply note 1374153 "Changeable transport requests are invisible in new cycle" if you want to use

this option.

Always remember that the Logical Component in Systems tab and the TMS information in STMS in the

domain controller of your real landscape must fit together.

Transport routes must be set client specific if several dev system: clients are used.

3. How to work with transport groups

This is a landscape with two transport groups and files that need to be move from one transport group

to the other.

Charm supports transports between different transport groups within the same transport domain. In

such cases, transport group comparison shall be carried out before the import of change requests.

Charm is able to do the transport group adjustment for different transport groups in different transport

domains as well, as long as the transport domains are connected by a domain link!

Please refer also to note 954516: "Transport groups comparison in the Change Request"

The general recommendation is to use the same transport group for systems of the same track! For

different tracks it may make sense to store the transport data in different directories.

For transports between different transport domains, Charm only supports domain links in the

configuration. And the setup is really complicated, which goes beyond the scope of development

support. Actually it is a consulting issue.

Charm does NOT support external systems in more than one domain.


SAP STRONGLY recommend to setup system landscape only in one transport domain to reduce the

complexity and administration effort! This is in accordance with our designed goal of Charm.

4. Virtual systems

To define a virtual system in SMSY ensure you define this system like virtual in the corresponding TMS

landscape and fill the field Transport Domain with the corresponding DOMAIN_SID, create virtual

system in SMSY and use the button "read system data remote" in the domain controller system of the

managed system, you will get the Virtual System flag selected.

Virtual system can be used in Charm but only "temporally" for testing purposes because not all action

can be selected because if the system is virtual so not import or logon is possible at all.

You can start using just one physical development system and complete your landscape with virtual

systems.

Create a virtual system in STMS with the same SID that you will use.

When the real system is ready replace it in STMS and refresh the information in SMSY, run the “read

system data remote” again from the domain controller system of the managed system and from the

virtual system itself.

The logical component does not need to be changed because the SID is still the same.

Also there is no need to close the maintenance cycle of the project, but refresh the project.

In case of problems, you can close the tasklist and re-generate the cycle to bring the new physical

systems to the tasklist.

Please see also the document “ChaRM_ST400_Virtual_System.pdf” attached to note 1520678 - Change

Request Management Configuration & Operation Guide

See also notes:

1004569 "Virtual systems in Change Request Management"

1007217 "SMSY (SLD): Do not read TMS systems"!

5. Temporary inactive system flag in SMSY

Select this switch whenever a system is down, for maintenance reasons, or because of a crash, charm

will stay working, unless the system is the domain controller of the landscape.

You can enter the task list as usual and if you try for example to process the task system logon onto a

system which is down you get a message "The system is temporarily inactive" and the action will be

canceled.


In the track where the system is down you can't do any action at all because it makes no sense if one

system is down on the transport route.

But every other Actions with the active systems are working as before. So you can continue your work in

the task list.

If the inactive system is online again you have to delete the inactive flag in the smsy and everything

works fine again.

Note: If the DEV system is also the Domain Controller and this system is down, the whole project is not

working; this is just works as what we designed to prevent further inconsistency in the project. If some

DEV system is down but it is not a Domain Controller then you can work with the project without the

system which is down. Configure a backup Domain Controller if possible in this situation.

In case you change the domain controller of your landscape and the system has been already defined in

the solman system, go to smsy and refresh the system information clicking in "Read System Data

Remote or ensure you have activated the Automatic Data Capture for System Landscape.

See function Module 'SMSY_GET_ALL_TMS_DOMAINS' and note 1255174.

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.

7. Several Solution Managers in the landscape

You can have several Solution Managers with this landscape for example: SMD:XXX->SMQ:YYY--

>SMP:ZZZ

Is possible to use Charm scenario to manage the changes in a solution manager

Landscape formed by tree systems?

Yes! You can configure one Solution Manager to manage changes in your solman landscape. This will

mean to create Change Request for all changes that you want to perform in the Solution Manager

system itself.

8. Completing a task list


In order to close the task list work ALWAYS with the SDMN document of the maintenance cycle and go

from Development wo release phase to Development with release to Test phase, etc, until you get the

last phase "Completing" in order to close the task list correctly.

A task list can be closed even with modifiable transport orders according to note 1071412 "Completing a

task plan with changeable transport requests".

Then when you create a new cycle, the system automatically assigns these processes and objects to the

new cycle. This is also logged in application log. To display the log entries, you can use transaction

/TMWFLOW/MAINTINST. Navigate to the tab with your project type (usually the maintenance project)

and choose 'Create...' and 'Execute'. Then select the required project and choose 'Messages at Time of

Creation'.

Other related notes: 1354638, 1344191 and 1158885.

9. Completing inconsistent task lists (note 933705)

When you have no chance to close the project cycle by switching the project phase to in completion

status, via the actions in the cycle document, SDMN document for a maintenance project for example,

then you should evaluate the reasons that make this task list inconsistent, because depending on the

reasons you could have different solutions.



1. You cannot operate on the cycle because the phase of the task list M* and the phase on the cycle

document, SDMN for example, are not consistent.

This can be fixed by using option "Set phase value" in report /TMWFLOW/PHCNTRL_DB_UTILITY. There

is no need to close the whole cycle due to this simple point.

2. If the above was not your case see the possible ways to handle a task list inconsistency, but you

should be aware that if you adopt this solution, close the task list forcibly, then probably all the old

change documents and transport requests will not be able to be processed in charm anymore. You

should know this possible side effect before closing the project forcibly.

Select the project phase transaction by starting the transaction CRM_DNO_MONITOR.

Select transaction type SDMN for selecting maintenance project cycle transactions or SDDV for selecting

implantation, upgrade or template project cycles.

Start cycle transaction document and choose document flow button.

The document flow button should show you all dependant open transactions like regular corrections

and urgent corrections. Navigate into the transactions and write down the numbers of the corrections

and also the number of the cycle document itself.

Now you have these options:

2.1. You can leave the corrections in the status they have, open corrections, and do the following steps

for closing a cycle task list:

a. Start program /TMWFLOW/TL_COMPLETE_FORCE (see note 1345459), type in the cycle task list name

you got from the cycle transaction document flow.

b. The cycle task list is now unconditionally closed but the IMG and CTS projects are still

open.

c. As a last step destroy any reference of the cycle by starting the program

/TMWFLOW/PHCNTRL_DB_UTILITY. Select the option: "delete all cycles of a project" and insert the

project name of the cycle you just withdraw unconditionally.

Now the project cycle is completely withdrawn and the project can be used for creating a new cycle.

Note: the above operations are irreversible!!!

Now when you create a new task list, using the same IMG project, in the better case the open

corrections, with the involved TRs, will be inherit to the new task list. But this is the nicest possibility I

mean we cannot assure that the open corrections will be inherit to the new task list.


In the case that the open corrections do not get inherit in the new task list, them these old change

documents and transport requests open corrections will not be able to be processed in charm, I mean as

the task list where they are linked is completed you could not work at all with this corrections in charm.

At this point, you can only withdrawn them with report CRM_SOCM_SERVICE_REPORT using

'unconditional withdraw'.

Still you have the TRs in the TMS real landscape and you should move the TRs manually to the

production system, but not via charm processing anymore.

2.2. Another "cleaner" possibility for forcibly closing a task list is to withdrawn all cycle dependant

transactions and then also withdrawn the cycle transaction itself. Now follow the steps to close the task

list a, b, c.

Close manually the IMG project via spro_admin.

At this point you should work manually with the TRs involved in the closed task list, as the corrections

are withdrawn at charm level.

Create a new cycle, this new cycle will not contain any relation to the corrections of the previous task

list.

Note. In the case of the SDMN or SDDV document has been accidentally deleted then there is not

standard way to get the corrections documents assigned automatically to the new task list, for

important correction changes in place open a message in SAP SMP for further analysis of the situation.

To avoid this situations, for all charm roles, please remove delete activity (authorization key '06') for

authorization objects CRM_ORD_PR and CRM_ORD_OP. This activity will allow manual deletion of CRM

documents, which might lead to data inconsistency in charm, so please for all users who will participate

in charm processes, make sure they do not have this particular authorization key.

3. If you don´t know how to handle the situation and there are important corrections changes in place,

please open a message in SAP SMP for further analysis of the situation.

10. Can I delete a project with Charm activated?

Since the project has been used for Change Request Management you can not delete it anymore, for

traceability reasons.

11. Scheduling of import job /TMWFLOW/SCMA_TRORDER_IMPORT hourly


Test to run 23 jobs per day, one at each hour, but choose Ends on 2099 to avoid to run only 1 time.

The second option is to schedule the import job for the CTS project directly from the TMS (this is a

standard TMS functionality).

Go to the import queue, filter it by the Project (CTS Project) ID and then select the import button (the

truck) you will get a popup to schedule the import.

See also SAP Note 911051.

However notice that this is just recommended for the QA system when you needs to import

periodically.

12. Import options



- Select All Requests for Later Import

The requests remain in the import queue after the import and can be imported, for example, into

another client. This is only useful if you have not switched on extended transport control, but you want

to provide several clients with requests.

- Overwrite Originals

The transport control program also imports objects if the objects are the originals in the target system.

The object directory entry determines the SAP System where the original version of an object is located.

- Overwrite Objects in Unconfirmed Repairs

The transport control program also imports objects if they were repaired in the target system and the

repair is not yet confirmed.

- Ignore Predecessor Relationships

You can choose this option if you want to import all the requests for one or several projects, but

additional requests from other projects exist for which there are dependencies. This option is switched

off by default, which means the predecessor's relationships are checked before the import. The import

only occurs if the predecessor's relationships will not be damaged.

These are the only import options available for Charm.



13. Return code and tp errors

To display import errors, under General Tasks in the task list mark the function "Correcting Imports with

Errors (Repair Flag)" and choose Executing Tasks.

The system displays an overview of the imports with errors in each of the target systems in the task list.

Select the target system and choose Log.

The system displays the log overview.

To display more detailed information about import errors, select the import with errors with the status

Ended with Errors.

The system displays the log file that sets out the import error.

Correct the error in the target system that attempted the import with errors. If, for example, a missing

domain caused the import error, import the domain transport request and regenerate the

corresponding data element.

To change the status of the corrected import error and to be able to end the task list, under General

Tasks remark the function in the task list "Correcting Imports with Errors (Repair Flag)" and choose

Execute Task.

The system displays an overview of the imports with errors with each target system in the task list.

To change the import status of the corrected error, mark the transport request and choose "Errors

Corrected".

14. Urgent correction SDHF stays in the import buffer after the individual first import

You should be able to disable this by setting the task list parameter from SAP0 to SAP1. For more

information please do following:

Call T-code /TMWFLOW/MAINTINST -> Go to tab "Settings" -> Choose "Variants for task lists in task list"

-> Press "Maintain Configuration" -> Put mouse in column "Buffer" -> Press F1

Then you'll find detail information for those variants, this would be a summary:

Currently there are two kind of import strategies one is referred to variant SAP0 and the other is for

variant SAP1.

1) By using SAP0 the corresponding maintenance cycle type is SDMN, by using SAP1 it is SDMM, in the

later case BC-set SOLMAN40_CHARM_TRANSTYPE_SDMM needs to be activated

2) With variant SAP0, it is possible to create both normal corrections and urgent corrections under this

maintenance cycle. And we have different import considerations: for normal correction we are using

import project all, which means in this case all requests on the same CTS project will be imported all


together (including those in urgent corrections); while for urgent correction we are using import subset,

which means only those requests created under specific urgent corrections will be imported.

To resolve the dependency issues caused by the conflictions of these two import options, we have

designed that all urgent corrections will stay in the import buffer after the first import, and they will be

imported the second time together with project import.

3) With variant SAP1, there is another import strategy, that is urgent correction will only import the

associated transport request one time. After the import, this request will be flagged as "Request Already

Imported" in the transport queue. Even though it is visible there, no more import can be done for this

request.

If you don´t want to see these requests in the transport buffer, you can manually remove them by

selecting "Extras -> Delete Imported Requests" in the import queue.

So, really these are not removed from the import buffer but yes flagged as "Request Already Imported".

So this variant is only designed for project cycles which contain ONLY urgent corrections. I mean you

cannot link a normal correction to a maintenance cycle with SAP1 variant.

The reason is if we have both normal corrections and urgent corrections in these cycles then that will

lead to serious dependency problems. (later version might be imported ahead of previous

version!)

15. Working with urgent corrections and normal corrections in the same task list --REALLY interesting

behaviour to know

This is the case:

MC in status Go-Live with several Normal corrections in status consolidated and two urgent corrections

assigned to this MC, one urgent correction already in status Confirmed and the other in status "To be

tested".

From the MC I schedule the import into production system:

- the two transport orders of normal correction in status "Consolidated" were imported correctly

- the urgent correction in status "confirmed" ( already imported into production) is imported again in

production as we see in point 14, see the log of the transport order

- the urgent correction in status "to be tested" is ALSO IMPORTED in production ----- WHY????? I HAVE

NOT EVEN TEST THIS URGENT CORRECTION!!!

Ok! What I have described is the correct behavior; all TRs are imported, also when you do not want to

import the second UC.

How to handle the situation and why cannot it be solved:

Every time a transport request is imported into QUA system, this transport request is entered into the

import buffer of the production system.

Note: The same happens when the transport request is released, the transport request is entered into

the import buffer of the quality system.


The process of an urgent correction includes the import into PRD, so we have to fill the import buffer of

PRD, there we use standard SAP technique, when import into QAS the import buffer of the following

system will be filled.

The IMPORT into PRD made from ChaRM is a pour call of TMS functionality, so we can not manipulate

the import queue.

How to handle this situation:

Always switch the phase/status in the SDMN transaction and not in the task list, in the CRM transaction

you will get the info that there are already urgent corrections in the import buffer switch are in status to

be tested.

Which this information you should contact the colleague who owns the urgent correction and solve this,

means forcing the colleague to test his urgent correction.

So this means, it is not recommended to switch to status going-live and import immediately, because

you always have to check the import buffer before import, by checking the status of the SDMN

transaction.

This describes the process how it should work.

Basically this is the main idea of the ChaRM concept, that you manage your project in phases and during

the Go-Live phase all transports connected to this project are applied to production.

Therefore before switching into the Go-Live phase, the project has to be finished completely.

I can only recommend holding the Go-Live phase as short as possible and don't work with urgent

corrections unless is mandatory because this is really an urgent change.

Sorry for using capital letters in this area but this behavior is really creating important issue when this

behavior is not known.

16. Task list "logs"

When you see the action "Release transport request" or/and action "Import transport request" in the

task list /nscma, you see a light next to this action. These lights are only showing the tp command has

been sent or not successfully to the satellite system.

These lights are never storing the log information of this action in the satellite sytem.

Every time you perform an import you should check the TMS import monitor. From charm we trigger

the tp import command for the correction transport request, and this is what is logged in the task list,

but we will only trigger the import action but for the detail transport log they must be checked on the

remote system directly.

We can not wait to see if the import of the transport request is correct or not, imagine a long import and

charm waiting until the tp import command finishes.

This is right that the correction goes to the next status, however when you try to move to the next

status the import logs are checked in conditions IMPORT_INTO_PROD_OK (SDHF) or


PRODUCTION_IMPORT_OK (SDMJ) and if these import logs are not available or are not correct you get

an error saying that the import was not really performed.

When checking one of these conditions think that we check this condition, we wait for this import to

finish, during a time determined with the CHECK_NTIMES_SOCM parameter, see note 1426029 for

details, we don´t recommend values biggers than 20 for this parameter CHECK_NTIME_SOCM.

Sometimes happens that you are moving the status of the correction in a faster than the import time

finishes and you can get an error saying that the import is not ok only because the import is not really

finished yet in the managed system.

17. Error "No maintenance cycle is opened for the current system"

When creating a normal correction or urgent correction (or setting it from "Created" to "In

development"), the customer receives error "No maintenance cycle is opened for current system."

(SOCM_ACTION_LOG011).

Possible reasons are:

- The IBase is wrong: The IBase/component must represent the production system in the project

landscape.

- Lack of authorizations: Assign role "SAP_SOCM_ADMIN" or "SAP_CM_ADMINISTRATOR_COMP" (or

equivalent) to the user who would like to approve the change request.

- Project is locked in table /TMWFLOW/PROJMAP: If an error is detected during the processing, then the

project might be locked in this table. The customer can unlock it by pressing the refresh button under

tab "System Landscape" -> "Change Requests". If there are other error messages shown during the

refresh process, the customer must fix those errors beforehand.

P.S. The 'Check' button under tab 'Change Requests' (the same as transaction /TMWFLOW/CHARMCHK)

will only do the checking. On the other hand, the 'Refresh' button will do the checking and update the

relevant database entries.

18. Dump ITAB_DUPLICATE_KEY

Actually, the root cause of this dump is that you are trying to configure more than one IMG projects for

the same charm project in the same physical DEV system, in /nsolar_project_admin->System Landscape-

> IMG Projects.

If you have for example this landscape with two development clients in the SAME development system,

at the moment of creating the IMG project only one IMG project should be created, each with their own

CTS project:


Firstly you select the first entry of the IMG Projects tab for first client, SMM:888 in our example and

create the IMG Project.

After you select the second entry for SMM:100 and select the same IMG project name:

If you try to select for this second entry a different IMG Project name then you will get the dump

ITAB_DUPLICATE_KEY.

If you go to the IMG Project in the development system SMM:888, you will see that for IMG project in

client SMM:800 the CTS project is SMM_P00048:




If you go to the IMG Project in the development system SMM:100, you will see that for IMG project in

client SMM:100 the CTS project is SMM_P00049:



If you to see the related entries in table /tmwflow/projmap:

See the following picture, an IMG project in DEV system can have assigned several CTS projects, one per

client of this DEV system.




19. Retrofit functionality

Please see the following SDN Blog Change Request Management scenario: Retrofit Functionality

For further information about this Charm scenario see also SDN Blogs:

- First steps to work with Change Request Management scenario

- "Change Request Management scenario: Working examples"

20. System copy

In case you want to make a system copy for the managing system, solman system, please have a look to

this notes:

1297727 Change Request Management and System Copy

In the case that you want to make a system refresh of a consolidation managed system from production

managed system please follow these steps:

- Implement notes 1487892 and note 1512342 in the solman system.

- Implement note1269192 on all your managed systems.

- Go to SMSY and select flag "Temporarily Inactive System" for the system that is going to be refreshed

http://scn.sap.com/people/dolores.correa/blog/2009/08/27/change-request-management-scenario-retrofit-functionality

http://scn.sap.com/people/dolores.correa/blog/2008/07/26/first-steps-to-work-with-change-request-management-scenario

http://scn.sap.com/people/dolores.correa/blog/2009/07/23/change-request-management-scenario-working-examples



- Make the system refresh

- Removed the old ALOG files after the system copy, leave this directory empty

- Press button "Delete Buffered Transport Data" in SMSY for the refreshed system to remove the

obsolete transport data

- Them, re-import manually all transports in to the refreshed system which, at this time, are not in the

production system.

- Remove in SMSY the flag "Temporarily Inactive System" for the refreshed system

- Run report /TMWFLOW/REP_DATA_READ according to note 1546452

21. Missing authorization for READ RFC connections

Our default authorizations for remote READ RFC users (created in SMSY) do not allow us to read

transport requests information. But READ RFC users are used extensively in Charm to get those

information. It is a bug in SMSY which has not been fixed by now. So currently for such kind of messages

we have to ask our customer to manually add appropriate authorizations (e.g. profile S_TMW_CREATE)

to those READ RFC users.

- Open transport requests are not marked as red when release them from task list.

Note 1279558 - Red Question Mark Icon Missing from Charm Transport Release

- "Error RFC destination SPROJECT_GET_SMI_DATA_R" when register outside transport requests into

Charm.

Please assign enough authorizations to all those READ RFC users on their DEV system (including client

000).

- Cannot complete maintenance cycle due to "Error RFC destination

/TMWFLOW/TL_COMPL_CHK_TR_WO_TL"


000).

- Transport request information is missing in the result of Charm Reporting.


000). And after that they should re-execute background job SM:TMWFLOW_CMSSYSCOL to update

those information on Solution Manager system again.

22. Registering transport requests in ChaRM


You can register a transport request created outside a charm correction after in a tasklist.

Please keep in mind the three points below:

1) To register a request into ChaRM task list that transport request must have already been assigned

to the CTS project which belongs to that ChaRM project cycle, for doing this assign the associated IMG

project to the transport request by entering the IMG project name in the Project field on Properties tab

of the involved transport request.

2) Only when the request is still modifiable you can register them into ChaRM. For released request it

won’t work.

3) After registering, those requests can only be managed in the task list directly, there is no change

document associated with it and hence no workflow is possible.

See note 1150426 for details.

23. Report CRM_SOCM_SERVICE_REPORT and email actions not processed

We have observed this behavior when there are issues in your actions condition definition, between

start and scheduling conditions, when they are in conflict with each other, therefore, the action cannot

be determined correctly.

For example: The action is relevant (scheduled) if "user status = E0009SDHFHEAD" and can be started if

"user status = E0006SDHFHEAD".

When your start condition is fulfilled, your scheduling condition is not fulfilled anymore. When the

scheduling condition is not met anymore, the action is removed:

E0006SDHFHEAD = E0009SDHFHEAD => false

Here is a suggestion to solve this issue:

Please check if it would be possible to use your start condition as a scheduling condition. Remove the

start condition. Normally, a 'status check' belongs in a scheduling condition.

If the above suggestion is not enough for your scenario, you can also take a look at consulting note

1007346.

But really this is a CRM-BF-ACI issue more than a Charm issue.

24. What happens when the solman system is down?

Please see note 1528657 "Workaround when SolMan system is temporarily unavailable"

25. Special considerations for non-ABAP landscapes in ChaRM

1. Definition of a dual stack system as single ABAP stack in ChaRM


Please see note 1573825 “ChaRM: only use ABAP stack for a dual stack system”.

This is a new functionality, previously if you has a dual stack system and you declare both parts like

relevant in SMSY, then you make sure both ABAP and non-ABAP stacks have the correct STMS

configurations when try to use system logon action from ChaRM.

However sometimes you do not need to use ChaRM on the on-ABAP stack and you don´t want those

redundant configuration. After implementing note 1573825, you will be able to define such systems as

pure ABAP stack system, so no CTS+ configuration is needed for them.

2. For non-ABAP system, the IMG project is created on the communication system and the CTS project

will be created "implicitly". That means, you will not be able to see the CTS project in SPRO_ADMIN.

However if you check in table CTSPROJECT, in the solman system, the correct entry is there looking like

"SID/IMG project ID”.

So, please keep in mind that you should NEVER activate the CTS project manually for non-ABAP systems.

Let me explain this with some screenshots, imaging that you create project I020554_N8 for a non-ABAP

landscape:

You create the IMG project I02055_IN8:

http://scn.sap.com/servlet/JiveServlet/showImage/38-50314-85744/CT1.jpg



If you go to see this IMG project in the communication system you will see that the CTS project “looks”

no activated:

However if you go to see in the solman system, table CTSPROJECT you will see that the entry

EPD/I02055_IN8 is there:

In the case that you activate the CTS project manually in the IMG project you will create an entry with

this name: I020554_IN8 and this can generate further issue at the time of the maintenance cycle

closure.

3. The CTS project status switch for non-ABAP systems cannot be displayed





Please implement note 1354430 to non-ABAP communication system, and notes 1517644, 1552230 to

SOLMAN system.

However you must know that still the import action switch is currently not working for non-ABAP

systems due to basis CTS+ restrictions.

4. If you want to user ChaRM on non-ABAP systems, make sure the communication system is with

SAP_BASIS Release 701 SP Level SAPKB70103 or higher.

For more information, check note 1356771 “Complete maintenance cycle with non-ABAP systems”.

26. In which situations a ChaRM project is locked?

In principle, the ChaRM project will be locked if your STMS configuration and your logical component

definition are not consistent with each other.

First point to clarify is that the ChaRM project is locked for all the logical components, for all TMS

landscapes managed in the project, not only for the TMS landscape that has for example the domain

controller down, I mean, this is a global lock not a particular lock affecting to the entire project.

Possible situations:

1. ChaRM project will be locked when domain controller system is down

If the domain controller system is unavailable, then in principle no transport should be performed in this

transport domain.



In this case ChaRM cannot get STMS configuration so there is no way to check whether they are

consistent or not, the result is the project will be locked as a self defensive action. For more information,

check note 1322696 “Work with Project Cycles where some systems are unavailable”.

2. ChaRM project will be locked when one RFC destination to a managed system is not working

correctly, because of a momentary network error or because the user used in the TMW or READ RFC

connection is locked.

This case is similar to the first point because we may not be able to get the correct STMS settings, so the

project will be locked.

RFC destination plays a very crucial and important role through the whole ChaRM processes. If you take

a look in the ChaRM check result, you will see we are also checking a lot of RFCs just to ensure the

project is consistent. If there are some errors for those RFCs, especially to your domain controller

systems, then we will say the whole project might be in danger because the communication to remote

systems might have been closed for a moment. Here we do not differentiate whether it is a READ RFC or

TMW RFC, it is also very hard for us to decide the real root cause of the error. It might disappear after a

few seconds; it might also be some network problems or even hardware issues which need a longer time

to solve it. Therefore, to make sure the whole project is safe and consistent, I am afraid the best solution

is just to lock it.

All those errors can be found in SLG1 system log and the system administrator has to investigate the

issue and fix it.

3. You have changed the STMS settings after the cycle is generated, i.e., replaced the QAS system with a

new one, but in the logical component the new system is not inserted. In this case there will also be

some inconsistencies and the project will be locked as well.

4. You have changed the logical component settings in the project, i.e., change the QAS system role from

‘Target System’ to ‘Single System’. Similar to the third point, the project will be locked due to

inconsistencies.

As long as the locking is not caused by some “instability” of the network connections you should always

be able to do a ChaRM check and figure out the real root cause.

These are some suggestions to such kind of issues:

1) If possible, please keep stable RFC destinations to your managed systems, especially to those domain

controller systems.

2) In case there are RFC errors and the project is locked, you can find the root cause very easily by

performing a ChaRM check. And after the error is cleared please simply refresh the project to unlock it.

In solar_project_admin, select the project and go to "System Landscape" -> "Change Requests" -> Click

on Refresh icon.


If there are other error messages shown during the refresh process, you must fixes those. In this way

you will be able to solve the issue immediately without delaying the project.

Check table /TMWFLOW/PROJMAP to see if the project is locked or not.

See also points:

5. Temporary inactive system flag in SMSY2

17. Error "No maintenance cycle is opened for the current system"

in this blog in relation with this point.

27. Several managed system with same SID

In Solman 7.0 we cannot differentiate distinct systems with the SID, even if they are located in different

domains.

In Solman 7.1 this issue will be solved by using the long SID functionality provided by SMSY, that is,

systems in different transport domains with the same SID can be managed by charm, you only need to

assign them to different technical system names in SMSY, see also note 1358071.

28. Incorrect use of SM_*_LOGIN RFC connection

In case of problems creating or completing maintenance cycles check that you are having the correct

RFC indicated under column "RFC for SAP Solution Manager" in the Client tab of your ABAP relevant

instance of your system in SMSY.

Ensure that you are always using the SM_*_TRUSTED RFC connection instead of the SM_*_LOGIN RFC

connection.

We have noticed that this change is done automatically when you are creating the RFC connection from

the LMDB, according to the LMDB colleagues the

behaviour is by design.

The "RFC for SAP Solution Manager" always take the last created RFC connection (login or trusted) in

LMDB:

You can do the following.

1. Create the trusted connection

2. Create the login connection. Both fields will be filled with "login" connection now.

3. Now update the trusted connection by selecting option "update XXXX_TRUSTED" from the drop down

list of "Trusted System RFC Destination" and click on "Execute", the RFC entered under "RFC for SAP

Solution Manager" will be the SM_*_TRUSTED connection.

ChaRM development is working in a solution for this.


See also KBA 1832160 How to analyze issues when trying to close a ChaRM maintenance cycle

http://service.sap.com/sap/support/notes/1832160

typical sap charm implementation scenarios and their answers

Documents