Change Request Management scenario: Usual questions and known errors

Posted by Dolores Correa in dolores.correa on Jul 22, 2009 2:58:46 PM inShare1

Change Request Management scenario: Usual questions and known errors

With this blog you will be able to understand better the Charm functionality in Solution Manager 7.0. I will try to give tips and tricks for the usual questions and the daily work with Charm. The hints given are valid for Solution Manager 7.0 since SPS15 and above. ALWAYS! ALWAYS! ALWAYS! ensure that you have applied all the notes indicated in note 907768 for solman 7.0 and your patch level, this will avoid you some known errors. For solman 7.1 implement the latest version of the Master Note for Change Request Management 7.10 regularly. Ensure you have seem the configuration guides attached to note 1520678 "Change Request Management Configuration & Operation Guides", they are really splendic documents.

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:

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.htm "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 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 sy stem 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 dont 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 dont 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 GoLive 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 dont 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 - 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" Please assign enough authorizations to all those READ RFC users on their DEV system (including client 000). - Transport request information is missing in the result of Charm Reporting. Please assign enough authorizations to all those READ RFC users on their DEV system (including client 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 wont 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 dont 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:

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 in consistencies. 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 17712 Views
Average User Rating (7 ratings)

inShare1

Comments
I have question to the phase controller. How can I create my own phase controller and my own phases ?

I found this tables : /TMWFLOW/TPCPVAA -> actions mapping to phase /TMWFLOW/TPPHMCV -> phase controllers

But I found no customizing entry in the img

Regards

o
Dolores Correa Jul 28, 2009 3:26 AM (in response to Daniel Rothmund)

Hello! Look this note 927124, maybe helps. Best regards, Dolores
Like (0)


Teresita Mendoza Nov 1, 2009 6:48 PM

Hi Dolores.

Thanks so much for creating the CHARM blogs. I read all your CHARM blogs and I found that your blogs are really great and very helpful in understanding the CHARM scenario.

In this particular blog, you mentioned about refreshing the dev managed system. Is there anything we need to know about refreshing the QA managed system (any "pre" or "post" refresh activities related to CHARM)?

Thanks, Tess
Like (0)

o
Dolores Correa Nov 1, 2009 11:16 PM (in response to Teresita Mendoza)

Hi Tess, Please have a look to these notes: 1297727 Change Request Management and System Copy 985692 Copying a satellite system: Change Request Management

The second one for your case. Best regards, Dolores

Like (0)

Bobby z Mar 29, 2010 9:42 AM (in response to Dolores Correa)

Hi Dolores,

Your work is amazing in this area. We appreciate all the development work that you are doing at sap and the great amount of knowledge that you are sharing with the SAP Solution Manager user community here at SDN.

I am working as an SAP architect at one of SAP's customers. We are interested in knowing what the latest developments that are going to happen with regard to the ChaRM functionality with EHP2 or 7.1 release, which ever is relevant.

I am looking for features that would include html e-mail notifications with direct gui navigation for a particular Change Request.

Regards, Bobby
Like (0)

Marina Savchina May 19, 2010 6:03 AM

Hi Dolores! Thanks a lot for your explanation! We've some more questions: We have two development clients in our development system (RD3-100 and RD3-500). We have Logical component "SAP ERP ECC SERVER" with Development system (RD3-100) and ABAP Programming system (RD3-500). We have Maintenance Project with activated "Change Request Management" option and with assigned Logical component "SAP ERP ECC SERVER". Can we use both of our Development clients (RD3-100 and RD3-500) in Change Request Management ? So we need something like: When developer takes Correction into development and then choose Action "Create transport request" system should ask in which development client developer need to create transport request. The same with Action "Logon". Is it possible? And how?
Like (0)

o
Dolores Correa May 19, 2010 6:14 AM (in response to Marina Savchina)

Hello, You can create two logical components each of them with one source dev system, in the same qua and prd system for both. This would generate two separate tracks. But see the problems that you can have at the end of point 1 regarding transport orders dependencies between the Tr created in the two clients...

Also test this solution, you will see that SAP transport layer will be used for the TRs in the two clients, if you want to use the Z transport layer you have to run the indicated report in point1. Please test well this scenario before using it for a real TMS landscape you know the behaviour of this configuration. Still I have to recommend to you to use only one development client per system. Best regards, Dolores
Like (0)

Mahesh Garud Sep 17, 2012 5:37 PM (in response to Dolores Correa)

Hi Dolores , Pls Reply to my issue with Authorization. Request is first Approved by Business Owner . Once Approved by Business Owner it is then Approved by Change Manager. The Requirement is if Business Owner approves the request instead of Change Manager it Gives Message that he is no authorized as we are controlling by B_USERSTAT. But in the actions the Options of Approve Change Request and Reject Change Request is not available for change manager to Approve it. My Requirement is to check the authorization and raise error message if Business Owner tries to approve the request for which he is not authorized. Please suggest BADI / Exit and which fields / structure to check for authrorization of business owner. Appreciare your help. Thanks Mahesh
Like (0)

Alejandro Mejias Sep 10, 2010 8:44 AM

Your blogs about ChaRM are a MUST in for ChaRM knowledg. Congratulations.

A question about reporting, are available some extractors to get ChaRM ratios in BI?

Best regards

Like (0)

Natalyia Veleva Sep 17, 2010 7:14 AM

Thank you for the useful infos.

When working with transport groups, how can one enter more than one target system as IBase component in the change request?
Like (0)

Luis Alberto Nieto Iglesias Oct 21, 2010 2:24 AM

Hi Dolores, First of all, thank you for the CHARM blogs. I have two different questions about ChaRM. First; how does ChaRM act when we need to transport some changes to SAP standard? Does Charm use automatically SAP transport layer? SAP layer need client?.

The second question is about SCMATREET table. I have just change a tasklist to remove a track and add one new, and when i save the tasklist im getting an error in this table, and im not able to change the tasklist. there might be some kind of inconsistency with another table? Thank you very much/ Muchas gracias
Like (0)

Tom Cenens Dec 15, 2010 12:43 AM

Hello

Good topic to blog about, lots of questions are raised concerning Charm on SDN Solution Manager forum.

Kind regards

Tom

Like (0)

Natalyia Veleva Dec 15, 2010 3:39 AM

Hello Dolores,

thank you for your contribution!

We have a complex landscape with multiple development clients and multiple transport layers for one of the clients. But we can only choose one standard layer. How will the rest layers be handled?

One more question: after switching the CTC parameter to "1" in out test landscape, we couldn't add the client number to the existing transport routes. We had to delete all of them and create new routes. Is this correct or is there a way to edit the existing routes?
Like (0)

Federico Montanana Jan 21, 2011 11:46 AM

Dear Dolores:

First off thank you a lot for your great work, it has helped me REALLY A LOT.

I have installed charm in different clients, and I have come to realize that none of them works with "maintenance cycles", its to say, none of them want to use normal corrections. All the projects I have worked with use only UCs.

Have you faced the same? Is it very uncommon to use only UCs?

Best regards! Federico

Like (0)

Rake Zion Apr 26, 2012 7:41 PM

Hi Dolores,

I have to a question on changing status of NC status back to In Development from Consolidated. When we change the NC status to consolidated. Can we reset to back to In Development?
Like (0)

Peter Hendriksen Sep 5, 2012 4:49 PM

Hi Dolores,

We have a problem with ChaRM: with a landscape of 2 & 4 systems together in one project. This doesn't seem to work as expected. The problem is 1 physical development system contains 3 clients, i.e. 1 for CUA (100), 1 for SLD (200) and 1 for EP Roles (201). The transport route for the first system is DEV100 -> PRD100, the second system is DEV200 -> PRD200, the third is real OTAP so DEV201 -> TST202 -> ACC203 -> PRD201. For route-1 (DEV100 -> PRD100) there is a SAP and Zxxx layer defined, for route-2 (DEV200 -> PRD200) there is only layer Zxx2 and for route-3 Zxx3.

SCMA however shows the following: DEV100 -> PRD100 DEV200 -> PRD100 & PRD200 DEV201 -> TST202 -> ACC203 -> PRD100 & PRD201 This strange behaviour showed up after including DEV100 & DEV200 in the ChaRM project.

Question: how can we avoid this? For more info please have a look into SAP Msg 689810/2012.

Any feedback would appreciated, Peter

Like (0)

Mohammad Hanfi Jul 3, 2013 12:40 AM

Hi Dolores, Incredible!!! Howsoever, I have a question. We are at SolMan 7.1 SP8, and are facing error while copying a project from another. The error says "SAPSQL_ARRAY_INSERT_DUPREC", for which there is a note- 668466. But, the customer doesn't want any notes to be implemented. Is there any other way out? Thanks in anticipation. Hanfi