dolores.correa

Change Request Management - New features in SAP Solution Manager 7.1

Dolores Correa — Tue, 27 Dec 2011 23:58:57 GMT

Change Request Management - New features in SAP Solution Manager 7.1

The idea of this blog is to be a fast read of the changes and new functionalities in Change Request Management in SAP Solution Manager 7.1.

1. General information

1. 1. New user interface
This new user interface is based on CRM Web Client UI framework.

As of SAP Solution Manager 7.1, completely new transaction types are available for ChaRM, these new transaction types should be created and edited only using the WebClient UI interface.

Documents will be opened in a url with this format:

https://xxx:yyyyy/sap/bc/bsp/sap/... crm_ui_start/

As you can see from the url above the SAP CRM Web UI, crm_ui, is based on BSP-Applications.

The new user interface does not support the existing “old” transaction types, so you cannot open an old transaction type document in this interface, only in SAP GUI or via the workcenter webdympro url.

The old CRM functionality for CRM 5.0 is based on SAP GUI but the new CRM 7.0 based on HTML-browser pages, the look and feel between these two versions of CRM are completely different.

If you go to the transaction type and you click in Channel of a transaction type you will see that for the new transaction types the channel is “GUI CRM WebClient UI”, for the old transaction types the channel was empty, see for example the new SMCR with the old SDCR:

The WebClient UI interface replaces the SAPGUI transactions crmd_order and crm_dno_monitor. The Change Request Management Work Center is still available in Solman 7.1.

1. 2. New transaction types

As of SAP Solution Manager 7.1, completely new transaction types are available for ChaRM.

All new functionalities and features are only available for new transaction types.

These are the ChaRM new transaction types supplied by SAP:

- SMCR Request for change RfC:

In solman 7.1 you can find several improvements to this Request for Change.

several change documents can be created from the request for change and linked to it. For example, if a change affects several production systems of a project, you can record all changes in one change request.
A change request can still be changed or extended after its approval when it is in status Being Implemented. For example, you can add another change document.

- SMMJ Normal Change

- SMHF Urgent Change

- SMAD Administration Change

- SMTM Defect Correction (test corrections)

- SMCG General Change

This is a new document supports the documentation of non-system related changes like printers, this documents can be created during all phases of a project. In fact is totally independent of a project and can even be used without a project.

- SMMN: Maintenance cycle for variant SAP0

- SMMM: Maintenance cycle for variant SAP1

- SMDV: Project cycle

- SMCT: Change Request Template

Templates that can be created for reoccurring request for changes.

1.3. Use of Assignment blocks in the new transaction types

When you open a new transaction type document the first thing that you see is that the tabs under Transactional Data, Partners, Actions, Status, etc. are being replaced by different Assignment blocks.

Depending on the transaction type there are some AB available, like for SMCR that you can always select or not to display, see below:

Initially the feeling is strange but after playing a little with the documents types you will see that all information is there, only in a different way.

For request for change I have to remark Details, Change Request Scope and Approval AB.

For maintenance projects you can create: Admin Changes, General Changes, Urgent Changes and Normal Changes.

For implementation projects you can create: Admin Changes, General Changes and Normal Changes.

For Normal and Urgent Changes I would like to remark these AB:

- Transport Management

See there that you can create the transport request from this AB, also task, TOCs, and see this Assign Request (coming in SP05):

By clicking in the buttons under Actions column you will be redirect via a sapgui shortcut to the logs and details, but the open sapgui screen is only a display mode:

- Landscape: for login actions to the systems included in the project:

- Related Transactions (document flow button in old SDMJ):

- Processing Log (Change documents in old SDMJ):

- Application Log (Action tab in old SDMJ documents/task list actions/SLG1):

- Scheduled actions:

- Parties Involved (Partners tab in old SDMJ document):

1. 4. How to work and search Charm documents

For the new CRM_UI transaction types you can use the IT Service Management, ITSM, for creating and for searching the created documents.

You can get this ITSM by calling /ncrm_ui from a solman 7.1 system, this will open a url like:

http://.../sap/bc/bsp/sap/crm_ui_start/ | http://.../sap/bc/bsp/sap/crm_ui_start/

For the old transaction types you can work and search them in the Charm work center. Work center will show you the old and also the new transaction types documents.

You can call the workcenter via:

-/nsolman_workcenter: this will open the WC embedded in a sapgui screen

-/nsm_workcenter: this will open the WC in a Internet browser

If you choose an old document the URL opened will be a webdynpro url: http://xxx:yyy/sap/bc/webdynpro/sap/ags_workcenter...

For the new document crm_ui bsp will be open: http://xxx:yyy/sap/bc/bsp/sap/crm_ui_start/

From the Change Management work center you can start the WebClient UI directly, call “IT Service Management”

1. 5. Support of ChaRM 7.0 transaction types in Solman 7.1

See note 1613908 Old Transaction Types in SAP Solution Manager 7.1

There is no support for using crmd_order or the old ChaRM documents in 7.1. The note states that existing documents can be finished but if you continue creating new ones with the old transaction types you will not get any support.

1.6 Adding new 7.1 custom transaction to the CRM_UI

Since SP03 in solman_setup there is step copying transaction types to customer namespace, the report AI_CRM_CPY_PROCTYPE will perform everything for you, and all newly created transactions will be available in crm_ui!

See note 1493264.

1.7. How to work with charm projects

The maintenance cycle phases remains without changes in solman 7.1.

For old projects, project created in solman 7.0, you can choose several options:

- you can close the maintenance cycles-task list and create a new ones after the upgrade or

- you can leave the old projects maintenance cycles open and use them with the old SDMN after the upgrade

All old projects will be stored in a special table at the first start after upgrade and for these old projects you can work with it in the same way as in the past, table /TMWFLOW/OLDPROJ.

All new created projects will be generated within the new crm_ui environment.

You also have the possibility to enter a new created project in table /tmwflow/switch and if you do so an old crm-document will be created if you generate tasklist and service desk transaction out of transaction SOLAR_PROJECT_ADMIN.

So, there are several possibilities depending on your needs and decision about on which environment you want to work.

2. Configuration

Please get the guide “Change Request Management -Configuration and Upgrade Guide” Sep 2011 from service.sap.com/instguides ->SAP Components ->SAP Solution guide

It is a really good guide and there are very few things that I can add to this Configuration section.

Just like a summary, when you finish your upgrade to solman 7.1 or the new installation you need to perform these steps:

- Run solman_setup and run System Preparation, Basis Configuration and Managed System Configuration steps

Note: In SP03, in the Basis Configuration step 5 you activate the PIECE LISTS that contains the standard customizing.

“Piece list AI_CUSTOMIZING imported”

This piece list contains the default configuration, for example Maintenance Optimizer, Service Desk or Change Request. The SAP default customizing will be copied from client 000 to your logon client and overwrite only SAP customizing. This activity has no effect on customer configuration and has to be run after each Support Patch import.

Because of this it is very VERY IMPORTANT that you copy all transaction types into your own namespace or <Z>, <Y> namespace before starting to use Charm, copy transaction types, copy status profiles, action profiles, etc… if not your modifications to the standard will be overwritten after the next support package import. So, when using standard customizing, you should copy all standard entries into your own namespace or <Z>, <Y> namespace. This is really important in Solman 7.1!!!

After each Support Patch application you have the option to use report AI_CRM_CPY_PROCTYPE "Update option" to update already copied transaction types with new shipped SAP standard configuration.

You cannot perform this activity in a production client, so you can change your client settings in scc4 temporarily or do this activation in solman development system and imported it in the next systems.

As of release 7.1 you do not need to activate BC-sets for any functionality as they are replaced by the customizing piece list.

- After run solman_setup and select section “IT Service Management”, select Change Request Management:

There there is a first check that ensures that the piece list has been imported successfully.

Go through all the steps.

Also go to spro and check all the steps under:

Important things in this documentation are for:

- “Copy Transaction types” via report AI_CRM_CPY_PROCTYPE

- Business Roles concept in crm_ui

- How to create a project and charm activation

- Create BP and su01 users with report ai_sdk_user_bp_gen, transaction /nbp_user_gen

- Impact ad urgency fields

- Approval procedures and customizing

- Scope assignment block, customizing for the available change documents

- Adding custom actions to crm_ui

- Support team determination

- Multilevel categorization

2.1. RFC communications in solman 7.1 to managed systems

Please implement note 1384598 in all managed system, with this in solman 7.1 the domain links are not required and them also not the connection to client 000 of the domain controller.

Initially we use the trusted connection to qua:xxx and prd:yyy so the same user should exists there with import authorizations, if this user is not existing we call the old method domain links existing and user in 000.

3. Upgrade roadmap

If you have upgraded your solman system to 7.1, please make the solman_setup sections:

- System Preparation

- Basic Configuration, at this point you activate the piece list that brings the new transaction types and the standard customizing in 7.1

- Managed system configuration

- IT Service Management ->Change Request Management

After this follow this flow:

See also in the indicated guide the sections:

- “Configuration Comparison”->really interesting!!!

- Background Jobs

Service Desk: SLA configuration hints for SAP Solution Manager 7.0

Dolores Correa — Fri, 03 Jun 2011 21:07:03 GMT

Service Desk: SLA configuration hints for SAP Solution Manager 7.0

With the following hints you will be able to configure the use of Service Level Agreement SLA to make sure that messages are processed within the defined period of time.

For configuring SLA you should get this document Advanced Quick Guide for VARs Service Desk (Jan 2010) even when the name of the document can lead to confusion, this guide can be used for all Service Desk scenarios and not only for Service Providers configurations.

Here I will try to give you some hints of the problems that I found following this guide, if you are coming from technology world this can be useful, for CRM experts probably these hints are not necessary at all :-)

The screenshots are taken from a Solution Manager 7.0 EhP1 SP24 system with Service Desk standard scenario.

Step 1. IBase model, sold-to party

The IBase models the customer’s system landscape with their respective system ID, installation number, and client. Data from support messages is compared with the IBases so that the right IBase and the right customer are found automatically and entered in the service process.

Ensure that the system:client you are selecting for SLA has a Sold-to party assigned to it:

/nib52 -->Goto/Partner

Sold-to party 241

Step 2. Organizational Model

Create your own organizational data for Service Provider model of your company from transaction ppoma_crm.

In CRM, the main focus is on modeling the sales and service structure. You need model only the organizational data that is relevant for processes specific to sales and services.

For example you can create the following Support Desk organization model:

Note: One OU can have the 3 attributes: Sales, Marketing and Service at the same time, I mean when you are selecting attribute Sales, you fill the corresponding data and you save, after you also can add data to the attribute Service, the data entered before for the attribute Sales remains, it is not deleted.

Assigning Attributes to Service Desk Organizational Units

What it is really important here is to indicate the country , because after when creating the Service Desk contract SLFV the organizational data determination Sales and Service are using the rules AC10000177 and AC14000164 respectively and both rules are based on the country value.

- 1^st Level Support definition:

- 2^nd Level Support definition:

-Organization Unit SALES:

For SLA you need to define one OU with SALES attribute.

See the important entries here are Country, Currency, division and distribution Channel.

Save your changes.

Step3. Sold-to party

By default the BP for the sold-to party has only the sold-to party and general role:

In Sold-to party role go to icon: Sales Area Data

By default you get this empty screen always.

Click on “Choose Sales Area…” icon

When you select one sales organization/ distribution channel you will get the already entered data for each sales organization/ distribution channel combination, don´t think that the data you store are not saved, they are saved but you will see them only when you select a sales organization/ distribution channel combination.

For this combination Sales Organization/ Distribution channel ensures you fill these data in Billing tab:

Note: you do not need to fill the sales data for the Sales organization with division. Important is the sales data of the Sales org. without division.

Check the about BP sold-to party configuration to avoid errors like:

Pricing data for partner 241 could not be read. Message no. CRM_PRICING101

In case the Sales Area Data icon is grey out in edit mode please execute report HRBCI_ATTRIBUTES_BUFFER_UPDATE

Please read the documentation attached to this report and request your system administrator to schedule this report for execution on a regular basis (if necessary every night) using the settings outlined in the documentation.

Step4. Product Maintenance definition

You use products (service products) in the SLA contract, to represent service level agreements in the form of response times.

- Creating a Base Hierarchy and Root Category /nCOMM_HIERARCHY

Please see point 4 of the indicated guide.

- Creating Service Products /nCOMMPR01

Create a service profile in /nCRMD_SERV_SLA

Per each entry we need to specify parameters SRV_RF_DURA y SRV_RR_DURA:

Sales and Distribution tab: assign here the Sales2 organizational unit created before

Step5. Create a Service Desk contract SLFV

This structure of a service contract is:

A SLFV document can have several items, in our example the item is the product created before.

The item category for SLFV is SOL3.

The item category for SLFN is SOL4.

In transaction /ncrmd_order:

Create!

Note: if you can not see this entry “SERVICE DESK Contrct” ensure the BC-set SOLMAN40_SDESK_SLFV is activated in your solman system.

Service Desk contract is transaction type SLFV:

Enter sold-to party, receiver cost center and contact person and product in General tab:

All the text is:

Organizational data determination Sales

Transaction type: SLFV

Organizational data profile: SLFN00000002

Organizational data model determination role: AC10000177

Container:

Attribute: COUNTRY, Evaluation: DE

….

Following organizational units were found:

O 50001036 Sales2

Organizational data determination Service

Transaction type: SLFV

Organizational data profile: SLFN00000002

Organizational data model determination role: AC14000164

Container:

Attribute: COUNTRY, Evaluation: DE

Attribute: SE_ORG, Evaluation:

Following organizational units were found:

O 50000609 1stLevel

Click on the product down in the screen:

In object list tab we have to include the systems affected by this contract:

We save the contract to verify that there are not errors.

Now we release the contract:

For my patch level SP26 I have to apply notes 1400326 and 1048685.

Step6. Check SLFN settings for contract determination

Note: See that the Org.Data Profile needs to be indicated.

How it works:

You create a SLFN document, Contract determination E is indicated for this transaction type.

The system checks the SLFV document that fits for this SLFN document on the basis of the following selection criteria:

- Sold-to party business partner

The sold-to party BP in the service contract SLFV and in the business transaction SLFN document must be identical.

The corresponding partner functions must therefore be provided in the corresponding partner

determination procedure of the transaction types.

- Sales Organization

The sales organization and the distribution channel in the service contract and in the business transaction, it means in the sold-to party sales area data, must be identical.

- Service Organization

If a service organization has been edited in the service contract, it must be identical to the service

organization in the business transaction.

- Status

The status of the service contract item must be released.

- Validity

The date in the field for customer's requested start in the business transaction must fall within the

validity period of the service contract item.

- Object List

The reference object (for example, an IBase component) from the business transaction must be

entered in the object list of the service contract item.

- Product List

If a product list exists, the system checks whether the product entered in the business transaction item is present in the product list of the service contract item.

- Copy Control

The copying of contract items to the items of a business transaction in service must be set in

Customizing, see next point step 7 for details.

After the system has determined service contracts, it will automatically transfer the contract data to the business transaction in service, or it will prompt you to select a contract for the transfer from a list.

Step 7. Copy control

The relevant information for configuring copy control can be found in the IMG:

Customer Relationship Management ->Transactions -> Basic Settings -> Copying Control for Business Transactions

Perform point “Define Copying Control for Transaction Types”

From SLFV to SLFN:

Perform point “Define Copying Control for Item Categories”:

From SOL3 to SOL4

Note: If SOL4 is not existing, create it according to pg 44

In the PartnerDetProc of SLFN0001 add BUS2000140

Don´t forget this assignment:

To avoid error in SLFN document:
No sales-specific Customizing entries maintained for item category SOL4
Message no. CRM_ORDER_CUST028

Perform spro point Define item category determination

See if note 1381128 is good for you, already in SAPKU50016.

Step8. Contract Determination Procedure

For this action profile SLFN0001_ADVANCED we need to create one action:

Processing type:

Processing parameters:

Initial value:

Define a condition:

You can enter here also the condition that the:

Step 8.Add Item Detail tab in SLFN

If SLFN has not ITEM DETAIL tab, we need to modify the screen profile of transaction type SLFN:

Change to SRV_SLFN_2: And then you can see again the tab Item Detail.

Step 9: Create a SLFN document

Now create a SLFN document:

In Item Detail tab you need to see the contract determined:

Note: Error that still you can get when trying to create a SLFN document:
Object CRMTE_CCKPT_H_IB_BORDERSO does not exist in the Web Repository
Message no. SWWW000
Apply note 1454138

Please go on with point "5.2.3 Automatic Monitoring of Service Level Agreements" of the guide in order to configure the monitoring of the deadlines of the created messages.

Change Request Management: Reporting

Dolores Correa — Fri, 08 Oct 2010 00:51:43 GMT

Change Request Management: Reporting

The idea of this blog is to show how to check that the reporting tool for Change Request Management is configured and working correctly.

You can access the charm reporting tool via:

- Transaction dswp (solution-specific reporting)

- Transaction solar_eval (cross-solution reporting)

- Transaction /tmwflow/reportingn (cross-solution reporting) -->new charm reporting tool since SP17, don´t use the old reporting tool /tmwflow/reporting (see note 1467227)

Step 1. Get systems, projects that you are looking for reporting information

Check the following per each satellite system SID:

- RFC connection SID SM_SIDCLNT000_READ, find the user SOLMANSIDXXX used for this RFC connection and ensure that this user in SID:000 has this authorizations (note 881553):

"An important prerequisite for reporting is the authorization of the user that is entered for the READ RFC connection to client 000 of the relevant component system (see transaction SMSY). This user for client 000 requires the authorization values ACTVT = 03 and TTYPE = <*> (full authorization) for the authorization object S_TRANSPRT. Check the authorizations. The system does not display any data for transport requests if the corresponding user does not have the authorization described above."

Step 2. Look for job SM:TMWFLOW_CMSSYSCOL running in solman system, the schedule is indicated in the spro point below:

The job SM:TMWFLOW_CMSSYSCOL collects tracking data asynchronously from systems.

ABAP program: /TMWFLOW/CMSSYSCOL2

Start time: Immediate start

Repetition period: Hourly

The current logic is, for open transport requests, we need to update them everytime the job is running, because there might be changes since our last update. However for released request, we will only update those requests which were newly released. Then those data is fixed in both managed system and solman system.

Step 3. Decide if you want solman get also object information or not from the managed system.

In case you want to get this object information of the transport request, then select "Object Reporting Active" radio button in se38: /TMWFLOW/CONFIG_SERVICES

o in transaction /TMWFLOW/CONFIG_LOCK too.

See note 1582386 ChaRM reporting data collector jobs performance improvement for details.

Step 4. See that the data from this satellite systems (tables E070, E071*) has arrived to tables /TMWFLOW/REP71* and /TMWFLOW/REPE7* in solman system (se16).

Look in /tmwflow/proj for transport orders assigned to this project to check if these tables has information above these transport orders.

If these tables show: "0 Entries", data from this satellite system has not arrived to solman system.

In this case run report /TMWFLOW/REP_DATA_READ to build the reporting data for a specific project, with start date empty, this will use the project creation date.

Tips and tricks when running /tmwflow/reportingn:
1. To make sure all CRM documents can be successfully addressed, increase the number in field "Maximum Number of Hits" to a large enough value like 1.000.000.

2. Enter your Project ID

3.If the output display contains transport requests information, always mark "All" box in "Transport Status" tab, otherwise the search over those requests won't be a complete one

4. When some managed system data is missing in ChaRM reporting result, try to run report /TMWFLOW/REP_DATA_READ manually with the project ID to refresh the entries in background database tables

NOTE: Charm reporting is not showing information for transport requests released in the closed project cycles of a project.

Relevant notes to check:

1166457 ChaRM: New Collecting data method for reporting

1269192 ChaRM: Collecting New Data in Asynch and Synch Mode-in solman and in satellite systems

1618113 ChaRM Reporting: duplicate requests displayed in the result

1466131 ChaRM Reporting: Performance of data update

1412234 ChaRM Reporting: incorrect transport request's information

1467227 Incorret Usage of the old ChaRM reporting)

1383249 ChaRM: Delete empty non-ABAP transport request

1180232 ChaRM reporting with and without document assi

1412234 ChaRM Reporting: incorrect transport request's information

1282473 ChaRM Reporting: save layout

1445062 ChaRM Reporting: incomplete overview result in the task list

1180232 ChaRM reporting with and without document assignment

1417492 ChaRM Reporting: IBase/Component is empty in the result

1396547 Change Request Management reporting: Change requests

1377427 ChaRM Reporting: track table has been incorrectly updated

1378310 ChaRM Reporting: background job updates systems out of ChaRM

1383853 /TMWFLOW/CHARMCHK - Performance and enhancements

1347872 ChaRM Reporting: corrections in CRM area from SP15 to SP20

1370647 Error Correction for New ChARM Reporting based on EHP1

1328928 Error Correction of New ChaRM reporting based on SP18

1275638 Error Correction of New ChaRM reporting based on SP16/SP17

1297032 Missing transport objects in ChaRM reporting

1285513 Error Correction of New ChARM Reporting SP15

1244945 ChaRM reporting jump to TR-request in client 000

1487892 Inconsistencies when deleting buffered transport data

1512342 Inconsistencies when fetching track data after a system copy

1582113 ChaRM Reporting: correction for search in project header

1582386 ChaRM reporting data collector jobs performance improvement

1599507 ChaRM Reporting: not all systems in projects are updated

1602276 ChaRM Reporting: display the whole tracking history

1618113 ChaRM Reporting: duplicate requests displayed in the result

Change Request Management scenario: Retrofit Functionality

Dolores Correa — Thu, 27 Aug 2009 13:51:48 GMT

Change Request Management scenario: Retrofit functionality

With the following steps you will be able to create a test landscape to practice with the Retrofit functionality in Solution Manager 7.0 EhP1 without creating interferences with real TMS landscapes.

Also I will try to give tips and tricks for the common mistakes in the configuration of this scenario.

Introduction

Software changes are done in one system and will be transported to the system landscape which is linked to this system by transport routes of the Transport Management System. But sometimes it is necessary to implement these changes into another system landscape but without using the import function of the transport requests.

Imagine this scenario with a Maintenance landscape and also an Implementation landscape:

It is essential that changes done in the maintenance landscape will also be applied to the development-implementation landscape. But the changes must not be imported directly with the transport requests because of inconsistencies between the objects of the two different landscapes. Instead of importing the transport request intelligent tools called 'correction workbench' and ‘BC Sets' will be used.

The correction workbench will import an object into the target system, if it does not exist there or whenever it can find the exact position for the new parts of the object. For these cases it will lead to a green traffic light. If such a position cannot be identified, the new parts of the objects will not be imported, and a yellow traffic light will be set. For all objects which are not supported by the correction workbench, a red traffic light will be set.

Configuration

The configurations given are valid for Solution Manager 7.0 EhP1 (SPS18) and above.

I will be working with the test scenario described in my previous SDN blog "First steps to work with Change Request Management scenario"

I will add to the previous landscape, Maintenance Landscape, also a Implementation Landscape in this way:

SMM:100->SMM:200->SMM:300 (Maintenance Landscape)

SMM:888->SMM:200->SMM:300 (Implementation Landscape)

For that I create a new client in my solman system:

I will run "Read System Data Remote" to refresh the system data in SMSY, after I will create the corresponding RFC connections for this client:

And also I will create two new logical components, one for the existing Maintenance landscape with a new system with role Retrofit:

And another logical component for the new Implementation landscape:

Create a maintenance project in transaction SOLAR_PROJECT_ADMIN.

Go to System Landscape tab -> Systems and assign these logical components. If not all of your systems appear in the project, push button 'System Role Assignment' and insert the new system role "Retrofit" there. Now you should see all systems of your logical components.

Explanation of role types:

D - Development System

O - Ongoing System

P - Production / target System

R - Retrofit System / Post processing System

For a general example:

1st LC: DEV impl (type D) -> QAS impl (type O) -> PRD impl (type P)

2nd LC: DEV maint (type D) -> QAS maint (type O) -> PRD maint (type P); DEV impl (type R)

Make sure that there transport routes are defined in the transaction STMS which link your developments system with the quality assurance systems (consolidation route) and your quality assurance systems with the production systems (delivery routes).

Create the IMG projects for both development systems:

Go to 'Change Requests' and mark 'Activate Change Requests Management'. Save your project. Now press 'Generate Task List'. When the task list is generated, you will be prompted to enter the task list. Do so and stay in this task list.

In the task list notice that you need to have two project tracks one per each source system and a Post-Processing System: Retrofit system

In the General Task there is a task called "Assignments of Postprocessing Systems to Development Systems", if you execute it:

You can change the assignments at any time by starting this task again. Really you only need execute this if more than one post processing system exists.

Now unlock both your transport tracks by highlighting the line 'Project Track <project name> Source System <system-client>' and using the right mouse click.

Now is time to work as usual with your project and corrections, see SDN Blog "Change Request Management scenario: Working examples"

We are going to create some normal and urgent correction corrections:

1. Normal correction for a workbench change request:

SDMJ 8000001143->Created Workbench request SMMK900724->program ZTEST60

In the development system, create e new report and save it in a package which can be exported (no local object). Use the transport request for workbench you have just created.

Save

2. Normal correction for a customizing change request:

SDMJ 8000001145->Created Customizing request SMMK900727

For customizing choose a customizing table and change an entry in this table. Save the changes in the transport request for customizing you have just created.

For example "Maintain Academic Titles":

Proceed with your normal corrections as described up to the point that the transport orders are imported into quality system SMM:200, normal corrections in "Consolidated" status.

At this point you will see that the available actions are:

This step is the main connector to the retrofit process.

This step is only available if the overall process has reached the status Consolidated for a SDMJ.

3. Urgent correction for a workbench change request:

SDHJ 8000001147->Created Customizing request SMMK900730 ->program ZTEST61

4. Urgent correction for a customizing change request:

SDHJ 8000001149->Created Customizing request SMMK900732

Proceed with your urgent corrections as described up to the point that the transport orders are imported into quality system SMM:200 and urgent corrections in "Authorized for Import" status.

At this point you will see that the available actions are:

This step is the main connector to the retrofit process.

This step is only available if the overall process has reached the status "Authorized for Import" for SDHF.

If I select "Start Retrofit":

The system will now calculate a number of possible retrofit systems, maintained in the retrofit customizing.

The result of this step is NONE, ONE or MORE systems.

- In case of NONE found systems the process will stop with an appropriate message.

- In case of ONE or MORE systems the system will prompt you with a list.

Please select one or more systems. This depends on your retrofit strategy.

Working from the task list M*

Now search the post-processing systems in your task list. Unlock the corresponding utmost task group via the right mouse-click.

In the following dialog you will see the transport request (which must be already released) of the System DEV maintenance which you created before. Choose this and enter. Now the changes of report which you created in DEV maintenance will be transported into DEV implementation and save to the transport request which you created in DEV implementation. You should see a green traffic light.

Internal retrofit preparations will fill the db table /tmwflow/rfitc:

Execution of Retrofit-Process

You will see a dialog which shows you the transport requests of system DEV maintenance. Assign a transport request from the retrofit system (DEV implementation) which will contain the changes of the post processing step.

Note: In order to be able to assign a transport request from the retrofit system, SMM:888 in our example, I created two SDMJ and two SDHF for development system SMM:888 for the same project and created the corresponding transport requests:

- Normal correction for a workbench change request:

SDMJ 8000001165->Created Workbench request SMMK900750

- Normal correction for a customizing change request:

SDMJ 8000001163->Created Customizing request SMMK900748

- Urgent correction for a workbench change request:

SDHJ 8000001169->Created Workbench request SMMK900754

- Urgent correction for a customizing change request:

SDHJ 8000001167->Created Customizing request SMMK900752

You could create corrections also for any other project that has the retrofit system like development system.

For a workbench change I get the two workbench transport request available:

For a customizing change I get the two customizing transport request available:

I continue working with Customizing request SMMK900727:

Mark the transport request of system DEV maintenance (where you've made the changes) and press Retrofit button:

For customizing request you should see following screens:

After activating the BC Set you get an activation log :

Close the screen with Exit shows the following dialog:

Decide if the retrofit is finished successful.

Note: You must allow repository changes for clients in which you would like to create BC Set for customizing changes. This is a purely prerequisite for BC Set.

This Z-BC Set is created in SMM:100 and also in SMM:888.

So, for a customizing request, we are using BC set functionality to transport the changes. That means, if the object in this request is not supported by BC set, then we will not be able to transport it. To check whether a object is supported by BC set or not call transaction /nSOBJ or see table OBJH for the object type.

Press DISPLAY to go to the next screen:

Select object you want to examine and double click on the selected object

Choose Button BC Set Compatibility:

On the selected TAB you can see all Activation Information for BC Set

As customizing changes are retrofitted via BC Set functionality, if BC Set functionality is no available for this object then Retrofit cannot transport it.

There is also a button call "list of transport critical Objects", press this button and you'll get all objects of all transports which are not able to retrofit it.

Another example for a role, object type ACGR:

So this object is not supported by BC Set functionality. If you try to retrofit such a transport request that contains this object you will get an error.

And in this case you have to manually transport those changes, there is no other solution.

On the other hand if the object is supported and still you get activation error, check if you have performed some deletion in this request but the deletion functionality has not been activated for BC set, activate the Deletion Functionality:

Start Transaction /nSCPR20 -> Open Menu Utilities-> Choose Menu Item "User Settings"

Choose Tab "Maint. Transaction" (see below):

Note: If you forgot to activate deletion functionality, then the retrofit will fail. In this case please activate deletion functionality and delete the old BC-set (and re-create it manually by following Charm name convention) to process again.

Or manually transport those changes without using Retrofit.

If Retrofit is approved by "Yes" the retrofit Status is updated on the central Database Table and the Retrofit-List will be refreshed after additional checks and the Transport Request which has been successfully retrofitted has the Retrofit-Status "Retrofitted".

For workbench requests the Correction Workbench -> /nSCWB tool is used.

Note: In SCWB, one prerequisite is the object to be modified in the target system must have the same version as in the original system before the change. Otherwise it will not be able to locate the places for insertion/deletion/modification. That means for workbench request you could retrofit only once, because you can only copy the changes one time.

See a similar screen as followed:

Note: The Critical Retrofit indicates which transport requests contain objects which cannot be imported directly by the tools used because of:

(1) Object not found due to object check

Note: The concept of using Retrofit to transport workbench requests is to copy the changes in source system by comparing to its original version, and insert the same changes to the same object in target system. But there is a prerequisite to make sure the change can be copied correctly, that is at the time when you perform the Retrofit action, the object version in system MUST be identical to the original object version in system before you do the changes. Otherwise there maybe inconsistencies in the final objects in retrofit system.

(2) Object not supported for BC Set activation

(3) Object Type not supported in Correction Workbench

To prevent the processing of transport requests, e.g. because the change is no longer required, choose Change Retrofit Status. The status of the selected transport request in the overview changes to No Retrofit.

To flag transport requests which have not been processed by the retrofit process tools, as completed, choose Manually Retrofitted. The status of the selected transport request in the overview changes to Manually Retrofitted. If there are no other transport requests for processing, before this request, in the overview, transport requests with this status are removed from the overview, to keep the list understandable.

Choose List Retrofit-Critical Objects to list all transport-critical transport objects, objects which cannot be retrofitted by the tools Retrofit uses (SCWB and BC Set Activation), so that you can process them manually. You can export the objects to the front-end PC in various formats, for further processing (e.g. manual retrofit of transport objects).

Choose Cancel to close the list and go back to the transport request overview for the selected retrofit system.

When you set the retrofit to completed successfully, the transport requests no longer appear in the transport request overview for the retrofit.

If you specify the retrofit as not having been completed successfully, the transport requests remains in the transport request overview for the retrofit, and continue to show the retrofit status Process Retrofit.

To leave the retrofit transport request window, choose End.

The task list overview appears.

Involved RFC Destinations

First time retrofit run creates these two RFC destinations, in our scenario:

In a real scenario:

1) RFC-Destination from Solution Manager to DEV-System of Maintenance landscape

2) RFC-Destination from Solution Manager to DEV-System of Implementation landscape

3) RFC-Destination from DEV-System of Maintenance to DEV-System of Implementation

4) RFC-Destination from DEV-System of Implementation to DEV-System of Maintenance

Process of Retrofit for Workbench (SCWB):

Read RFC-DESTINATION (1) of DEV-Maint
Call Function Module TMW_DO_RETROFIT_WB on Retrofit System (DEV-Impl)
Create RFC-Destination (4) with Information of RFC-Destination of DEV-Maint. CWBADM_<SID>_<CLNT>
'SCWB_APPLY_REFERENCE_CORR_NEW' gets the information from DEV-Maint and stores it in the transport request of DEV-Impl.

Process of Retrofit for Workbench (BC-SET):

Read RFC-DESTINATION (2) of DEV-Impl.
Call Function Module TMW_DO_RETROFIT_CUS on Maintenance System
Create RFC-Destination (3) with Information of RFC-Destination of DEV-Impl. RETRO_<SID>_<CLNT>
Copies BC-Set from DEV-Maint. to Retrofit System (DEV-Impl.) and activates the BC-Set on the retrofit system.

For more information about RFC-Destination in Retrofit please have a look at the following note:

1175098 - Change Request Management retrofit configuration

Important things to take into account

- Authorization S_RFC_ADM is needed for all users because it allows the remote connection to the managed systems, also to users in READ and TMW RFC connections in client 000 of the managed systems.

- In general, the retrofit function is importing a transport request in a client, and therefore the import authorization is required also in the retrofit client. However, you distribute and, in particular, you import the transport requests in the Transport Management System (TMS).

For technical reasons, the remote-communication of the TMS always occurs using the 000 client of the target system.

Therefore, the TMS requires that the people responsible for the import (operators or administrators with import authorization) have a user in client 000 of the target systems.

Please find more details about this behaviour in the following note:

913232 - Users and authorizations are missing in client 000

- RFC Connection RETRO_<SID>_<CLNT> is only needed for BC Sets.

- RFC connection CWBADM_<SID>_<CLNT> is only needed for Workbench objects.

- Check the domain links in your landscape. Be sure that there exists an inter domain link between the two domains in which the development systems are configured in.

- If at this point you can not retrofit customizing requests, please check this note 1363546 "ARFC options for destination", the root case might be the ARFC settings of TRUSTED RFC connections from SOLMAN system to managed systems that are incorrect, re-generate those RFC in SMSY and try again.

Notes implemented in our system in EhP1 before testing this funcionality:

1150335 Delivery information for retrofit

1371694 Retrofit: Wrong sort order in retrofit list

1317068 Retrofit extensions for managed systems

1363936 Focus on selected entry of retrofit list disappears

1353374 Object not found in module /TMWFLOW/TR_OBJECT_CHECK

1356984 Cross System Object Lock: Timeout in checking lock conflicts

1281812 Retrofit processed for records with status retrofitted

1242899 Cross-system object locking: Cutover scenario

1246877 Performance problems displaying retrofit list

Read notes

1250430 Retrofit usability

1175098 Change Request Management retrofit configuration

996865 Tx SCPR20: Error SCPR 116 occurs during BC set activation

1044741 BC set deletions

1153253 Customizing distribution - deletions by BC set activation

Notes to be implemented in satellite systems

1040612 Retrofit function for satellite systems

1066123 Retrofit functions for satellite systems Customizing

1157393 Retrofit func. for systems w/ Basis Release 7.0 as of SP11

Retrofit documentation

It can be found in:

http://help.sap.com/saphelp_smehp1/helpdata/en/a3/0aae435a1342e8a56998d83a797161/content.htm

Copy Changes -> Objects supported in list below

http://help.sap.com/saphelp_sm40/helpdata/EN/b6/6de59f9abc4d17a04ac6486c2e8b84/frameset.htm

There will be important enhancement for Retrofit functionality for Solman 7.0 EhP2, I will try to update this blog as soon as this information is available.

Appendix A: Explanation of Retrofit-Functionalities (ALV-List and Buttons)

Working with filter buttons:

Filter Buttons

Filter value is "Retrofit Status"

"Retrofitted" or "Manually Retrofitted" green line

"Process Retrofit" yellow line

"Retrofit Rejected" red line

These Buttons are toggle buttons

Fade out -> hides the described values

Show -> displays the values again

Change the Retrofit Status

Select an entry and press button <Change Retrofit Status>. The colour of the entry changes to red and the Retrofit Status is set to Retrofit Rejected.
Select the entry once more and press button <Change Retrofit Status> again the Status is switched back to Process Retrofit. Only entries with status "Process Retrofit" are processible.

Change to Manually Retrofitted

If you have processed the objects of this transport request manually in the retrofit system you can set the status in the retrofit list manually by using this function.
Select an entry and press button <Manually Retrofitted>. The colour of the entry changes to green and the Retrofit Status is set to Manually Retrofitted.
Select the entry once more and press button < Manually Retrofitted > again the Status is switched back to Process Retrofit. Only entries with status "Process Retrofit" are processable.

Check Consistency

Before you want to start the Retrofit process (post processing) you have the possibility to check weather the transport request is consistent or not. You can process the check by selecting an entry and use "Check Consistency" or click on the icon in column "Retrofit critical"
The following checks will be performed when using this function:

Note Check -> Objects determined from a note in transport request. This request contains objects from the import of a note. This can cause retrofit problems in the target system.

The target system can have a different release, with its own note.

The target system does not recognize the changes from the note, and ignores it because the attribute of the transport request get lost.

You should not import this transport request into the target system, to avoid these problems. Separate requests for notes and user changes (Workbench und Customizing).

No transport is selected for retrofit Request

Changes cannot be retrofitted without a target request. The request cannot be processed.

Assign a request to the selected entry, and repeat the procedure

Check the transport order -> The selection of this transport request does not obey the release sequence. This can cause inconsistencies and overwrite data because of overtakers (premature requests) or downgrades (subsequently importing old requests). Check and correct the selection, to avoid inconsistencies due to incorrect release sequence. This procedure is logged in a file
Possible order conflicts can appear:

There are transport requests found which have been processed by the selected transport request.

There are transport requests found which have not been processed by the selected transport request.

Combinations of the above cases.

Object Check -> Checks if the objects of the transport request can be handled with the tools the retrofit process is used (Correction Workbench and BC Set). This check can be ignored when you use the auto import functionality. The prerequisite is that the object is not changed in the target system (retrofit system)
The following cases prevent an automatic retrofit process:

Object not found due to object check

Object not supported for BC Set activation

Object Type not supported in Correction Workbench

Example: Check the consistency of transport order I2IK900560

Result: The outcome of this check will be displayed in a log below the retrofit list

Object-List for Transport Request

To get a detailed list of the Objects in a selected Transport Request mark an entry of the Retrofit-List and use Function "Object-List for Transport Request" or double-click on the entry you want to display.

Description of the Object-List:

Auto-Import: Corresponds to the Category "2" of the object entry and is green colored. Objects of this category will be transported automatically. That means the Object is not changed in the retrofit system and can be imported directly.

Retrofit: Corresponds to the Category "1" of the object entry and is yellow colored. The Objects of this category are changed in maintenance system and retrofit system and has to be processed by retrofit tools (Correction Workbench or BC Set Activation).

Manual: Corresponds to the Category "4" of the object entry and is red colored. Objects of this category are not supported by the retrofit process and have to handle by the customer.

Manual setting of Implementation Status

All entries in the Object List with category "4" (manual) can be set by customer on this display. Trying to change other entries as category "manual" is not allowed here because these entries will be set automatically by the auto import or retrofit process. The customer can make the following possible entries:

Implemented (Value "I"): The Object is processed manually in the retrofit system.

Not implemented (Value "N"): The Object is not processed in the retrofit system because it is not needed in the retrofit system or any other reasons from the customer.

Not processed (Value <SPACE>): This is the default Value. If one of the Objects of the Transport Request is not processed the retrofit process cannot complete this transport request, because all objects should has been processed.

Appendix B: Explanation of Object-List functionalities (Buttons)

Confirm & Save

A popup appears which indicates that data is not saved if you leave the display.

Cancel: Go back to the display.

No: Leave screen without saving data.

Yes: Save data and leave screen.

Save Data

Saves the data to Database table and processes following Message:

Compare Source & Target System

Customizing Compare

Result of a compare of a customizing object

Workbench Compare

Result of a compare of a workbench object

Cancel Processing

A popup appears which indicates that data will be lost if you leave the display.

Cancel: Go back to the display.

No: Go back to the display.

Yes: No data will be saved and leave screen.

Appendix C

Before EhP1 this project definition was working:

Change Request Management scenario: Working examples Development with Release phase

Dolores Correa — Thu, 23 Jul 2009 05:01:20 GMT

Change Request Management scenario: Working examples "Development with Release" phase

This blog covers the Development with release phase as part of the working case initiated in SDN blog: Change Request Management scenario: Working examples.

Here you will find also the possible actions and statuses of normal and urgent corrections, when you are in this MC phase.

In this phase:

TRs can be released from within a regular correction.

For regular corrections, the administrator has to use the task list to import all released corrections into the test system or he has to schedule regular import batch jobs.

If any regular corrections exist whose status has not yet been set to Tested successfully when the maintenance cycle phase is changed from Development w Release to Test, the system issues a warning in the SDMN document. These corrections are then excluded from the integration test and cannot be released.

This is the suggested test for the set of corrections in this phase:

*Correction*	*User Status*	*Action*	*Final User Status*	*Details*
SDMJ 8000001049	Created
SDMJ 8000001046	In Development
SDMJ 8000001051	In Development			Created SMMK900664 but left empty
SDMJ 8000001053	In Development			SMMK900666, task released
SDMJ 8000001055	To be Tested			SMMK900668, TOC SMMK900680, created and exported AUTOMATICALLY (also imported as you can see in SDMJ *1059)
SDMJ 8000001057	Withdrawn
SDMJ 8000001059	Created	Set to "In development"	In Development
	In Development	Created Transport Request	In Development	SMMK900681
	In Development	Logon to System	In Development	Release task
	In Development	Complete Development	To be Tested	TOC SMMK900683 created and exported
	To be Tested	Go to the Task List	To be Tested	IT OPERATOR should go to task list to import the TOC to SMM:200 From SMM:200 tas list "Import Transport Request"--> IMPORT ALL, all released transport orders of this project will be imported!! Also from SDHF correction already imported to SMM:200 - TOC SMMK900680 is imported, because this request is already in the qua import buffer Also: - SMMK900674 ( SDHF 8000001075) - SMMK900676 (SDHF 8000001077) - SMMK900676 (SDHF 8000001079) are imported again in SMM:200, this happens only with the first import ALL in QUA, not with the others. Job /TMWFLOW/SCMA_TRORDER_IMPORT
	To be Tested	Logon to System	To be Tested
	To be Tested	Confirm Successful Test	Consolidated	Task "Release Transport Request" appears AUTOMATICALLY in the task list, TR SMMK900681 is released! AGAIN IT Operation should go to task list to import this released TR into SMM:300
SDMJ 8000001061	Created	Set to "In development"	In Development
	In Development	Created Transport Request	In Development	SMMK900684
	In Development	Logon to System	In Development	Release task
	In Development	Test Transport	In Development	"Select Transport Request to be copied" popup--> selected SMMK900684 TOC SMMK900686 created and exported IT OPERATOR go to task list to import the TOC to SMM:200
	In Development	Complete Development	To be Tested	Another TOC is created automatically SMMK900687 IT OPERATOR go to task list to import the TOC to SMM:200
	To be Tested	Confirm Successful Test	Consolidated	Task "Release Transport Request" appears AUTOMATICALLY in the task list, TR SMMK900684 is released! AGAIN IT Operator should go to task list to import this released TR into SMM:300 but not until Go-Live phase
	Consolidated	Set Production Status	Consolidated	Error: Unable to successfully complete import into production system This error appears because transport order is not imported in SMM:300, this can not be done in this phase, only in Go-Live phase after the Import ALL in SMM:300
SDHF 8000001067	Created
SDHF 8000001069	Withdrawn
SDHF 8000001071	In Development			created SMMK900670 but left empty, H000000398
SDHF 8000001073	In Development			SMMK900672, task released H000000399
SDHF 8000001075	To be tested			SMMK900674, H000000400, imported in SMM:200, and in SMM:300 import buffer
SDHF 8000001077	Successfully Tested			SMMK900676, H000000401, imported in SMM:200
SDHF 8000001079	Completed			SMMK900678, H000000402, imported in SMM:300
SDHF 8000001091	Created	Set to "In Development"	In Development	The "Create transport request" popup appears automatically, created SMMK900688, H000000411
	In Development	Logon to System	In Development	SMMK900688, task released
	In Development	Pass Correction to Test	To be tested	"Select Transport Request to be Released" popup for SMMK900688 appears, select it. Import into system SMM 200 started
	To be tested	Logon to System	To be tested	Check if the change is correct
	To be tested	Confirm Successful Test	Successfully Tested
	Successfully Tested	Released for Production	Authorized for Import

With these correction statuses I change the phase to from "Development with release" to "Test":

TR and TOC situation:

There are 8 warnings:

Normal Correction 8000001046 still has status 'In Development'

Normal Correction 8000001049 still has status 'Created'

Normal Correction 8000001051 still has status 'In Development'

Normal Correction 8000001053 still has status 'In Development'

Normal Correction 8000001055 still has status 'To Be Tested'

Normal Correction 8000001063 still has status 'Created'

Normal Correction 8000001065 still has status 'Created'

In Test phase the code is freeze, I mean, you can not release any request, so if you want to be able to work with these corrections you should go back to Development with release phase.

If not, only these corrections will be included in the actual test and go-live:

Normal Correction 8000001059 Consolidated
Normal Correction 8000001061 Consolidated
All urgent corrections

During this Test phase you can work with SDMJ in Status "Consolidated" and with SDHF corrections.

The other will be included in the next test phase, SDN Blog: Change Request Management scenario: Working examples “Test” phase

Note:

When one normal correction is at status "Consolidated", then the transport requests should have already been released, so you are not allowed to withdraw the normal correction at this status.
However if you do not want to transport the changes to follow up systems, you should create a new normal correction, edit the same object and cancel the changes made in the first normal correction, set the new normal correction to status "Consolidated". In this way when you trigger the import from project task list, everything will be transported all together, which means the requests in two normal corrections will be able to cancel each other, hence no change will be made.

Change Request Management scenario: Working examples Test phase

Dolores Correa — Thu, 23 Jul 2009 05:01:00 GMT

Change Request Management scenario: Working examples “Test” phase

This blog covers the Test phase as part of the working case initiated in SDN blog: Change Request Management scenario: Working examples.

Here you will find also the possible actions and statuses of normal and urgent corrections, when you are in this MC phase.

In this phase:

Release of regular corrections is not possible anymore (code freeze).

During the test phase, errors are detected in the test systems, and are reported to the relevant developers by means of test messages. The developers correct these errors. If all test messages have been closed, the maintenance cycle proceeds to the emergency correction phase.

Urgent corrections can be used as in the previous phase.

Unfinished developments will not be included in the actual test and go-live, they can be included in the next test phase.

This is the suggested test for the set of corrections in this phase:

*Correction*	*User Status*	*Action*	*Final User Status*	*Details*
SDMJ 8000001049	Created
SDMJ 8000001046	In Development
SDMJ 8000001051	In Development			Created SMMK900664 but left empty
SDMJ 8000001053	In Development			SMMK900666, task released
SDMJ 8000001055	To be Tested	Confirm Successful Test	Consolidated	SMMK900668, TOC SMMK900680 imported in SMM:200, but not released automatically in this phase, the release is done via task list and also the import to SMM:200
SDMJ 8000001057	Withdrawn
SDMJ 8000001059	Consolidated			SMMK900681, TOC SMMK900683 created and exported Imported in SMM:200 TOC and after SMMK900681
SDMJ 8000001061	Consolidated			SMMK900684, TOC SMMK900686 and SMMK900687 created and exported Imported in SMM:200 TOC and after SMMK900684
SDMJ 8000001063	Created
SDMJ 8000001065	Created
SDHF 8000001067	Created
SDHF 8000001069	Withdrawn
SDHF 8000001071	In Development			created SMMK900670 but left empty, H000000398
SDHF 8000001073	In Development			SMMK900672, task released H000000399
SDHF 8000001075	To be tested			SMMK900674, H000000400, imported in SMM:200, and in SMM:300 import buffer
SDHF 8000001077	Successfully Tested			SMMK900676, H000000401, imported in SMM:200
SDHF 8000001079	Completed			SMMK900678, H000000402, imported in SMM:300
SDHF 8000001091	Authorized for Import			SMMK900688, H000000411 "Select Transport Request to be Released" popup for SMMK900688 appears, select it. Import into system SMM :200

In this phase you have to test your changes in SMM:200 and create a Test message in case you need to make any correction in these changes, to create a Test Message you can do it from a document if you have included this type of transaction in Extras--> Settings

I click in Test message:

I assigned it to our MC.

*Correction*	*User Status*	*Action*	*Final User Status*	*Details*
SDTM 8000001092	Created	Take "In Process"	In Process
	In Process	Create Transport Request		SMMK900690
	In Process	Release Transport Request		"Select transport release" popup appears
	In Process	Pass to "Retest"	To be Retested	IT OPERATOR go to task list to import the TR to SMM:200
	To be Retested	Confirm Correction	Confirmed	The tester role cannot be the same as the developer role, see pg 898 from Solution Manager Documentation for EhP1 This TR will get imported into SMM:300 after in Go-Live phase when executing the "Import Transport Request (Background)" in SMM:300

With these correction statuses I change the phase to from "Test" to "Emergency Correction":

There are 7 warnings:

Normal Correction 8000001046 still has status 'In Development'

Normal Correction 8000001049 still has status 'Created'

Normal Correction 8000001051 still has status 'In Development'

Normal Correction 8000001053 still has status 'In Development'

Normal Correction 8000001063 still has status 'Created'

Normal Correction 8000001065 still has status 'Created'

Note: In TEST phase don't work at all with your SDMJ corrections, only with SDHF corrections and with SDTM test messages.

Next phase in SDN Blog: Change Request Management scenario: Working examples “Emergency Correction” phase

Change Request Management scenario: Working examples Final Points and Appendix

Dolores Correa — Thu, 23 Jul 2009 05:00:41 GMT

Change Request Management scenario: Working examples Final Points and Appendix

This blog is the last part of the working case initiated in SDN blog : Change Request Management scenario: Working examples.

Here you will find also the possible actions and statuses of normal and urgent corrections, change documents and test messages.

Final points to remember

Never leave the SDMN document in edit mode you can get action errors in the associated corrections like "No link to maintenance cycle". Put the SDMN document in display mode and recheck the correction to fix the error.

You can move the MC phase to previous phases and move up again.

In TEST phase don't work at all with your SDMJ corrections, only with SDHF corrections and with SDTM test messages.

In EMERGENCY CORRECTION phase don't work at all with your SDMJ and SDHF corrections because you only are allow to create a TR and released it by using the task list directly.

Usually customers are most of the time in Development with Release phase.

Every time you move the phase up check the warning to see the corrections that are not in the correct status for this phase and contact the responsible to see how to work with these corrections.

When you schedule task "Import Transport Request (Background)" check that if you are running this job from an urgent correction the command is: tp IMPORT SMMK900688 SMM clires200 U0, and this TR remains in the import buffer until you don´t execute the job "Import Transport Request (Background)" from the M* task list. This job will run a tp IMPORT ALL SMM clires200 proj=0001,SMM_P00044

Last point, manual deletion of CRM documents in Charm may lead to serious problems such as database inconsistencies, please see note 902973 "Unrestricted deletion of change transactions"

Note that I am always working with same user and not with the correct users, change manager, developer, tester, IT user, etc. In the appendix you will see the person in charge of each action in each MC phase.

Appendix A. Interesting transactions to know

- solar_project_admin: to manage the project

- crmd_order or crm_dno_monitor: to find your documents

- /tmwflow/maintinst: to see your SDHF document and see to which project are assigned and to see the project task list directly

- /tmwflow/proj: to see the CTS status Switches and in Project Structure tab the TRs assigned to each correction, see below.

- /tmwflow/cmsconf: System Change Options

- /tmwflow/trmo: Tracking

Appendix B. Change request SDCR possible actions per status

*Step*	*Who- Where*	*User Status*	*Action*	*Final User Status*	*Details*
1	Change Manager - Solman	To be Approved	Authorize Change Request	Authorized
1	Change Manager - Solman	To be Approved	Reject ECR

Appendix C. Normal correction possible actions per status

*Step*	*Who- Where*	*Initial User Status*	*Action*	*Final User Status*
1	Change Manager- Solman	Created
2	Developer- Solman	Created	Set to "In Development"	In Development
2	Developer- Solman	Created	Cancel Procedure	Withdrawn
3	Developer - Solman	In Development	Logon to System	In Development
			Complete Development	To be Tested
			Cancel Procedure	Withdrawn
			Create Transport Request	In Development
			Create Task	In Development
			Critical Transport Objects	In Development
			Test Transports	In Development
			Transport into Sandbox System	In Development
			Go to the Task Plan	In Development
4	Tester- Solman	To be Tested	Logon to System	To be Tested
			Confirm Successful Test	Consolidated
			Reset Status to "in Development"	In Development
			Go to the Task Plan	To be Tested
5	Change Manager- Solman	Consolidated	Logon to System	Consolidated
			Set Production Status	Production
			Start Retrofit	Consolidated
			Go to the Task Plan	Consolidated

Appendix D. Urgent correction possible actions per status

*Step*	*Who- Where*	*Initial User Status*	*Action*	*Final User Status*
1	Change Manager- Solman	Created
2	Developer- Solman	Created	Set to "In Development"	In Development
2	Developer- Solman	Created	Withdraw Correction	Withdrawn
3	Developer - Solman	In Development	Logon to System	In Development
			Release Transport Request
			Pass Correction to Test	To be Tested
			Withdraw Correction	Withdrawn
			Create New Transport Request	In Development
			Create Task	In Development
			Critical Transport Objects
			Transport into Sandbox System
			Go to the Task Plan	In Development
4	Tester- Solman	To be Tested	Logon to System	To be Tested
			Confirm Successful Test	Successfully Tested
			Reset Status to "In Development"	In Development
			Go to Task Plan	To be Tested
5	Change Manager- Solman	Successfully tested	Logon to System	Successfully tested
			Released for Production	Authorized for Import
			Reset Status to "In Development"	In Development
			Go to Task Plan	Successfully tested
6	IT- Solman	Authorized for Import	Logon to System	Authorized for Import
			Import Correction to Production System	Production
			Reset Status to "In Development"	In Development
			Start Retrofit
			Go to Task Plan	Authorized for Import
7	Change Manager - Solman	Production	Logon to System	Production
			Confirm Correction	Confirmed
			Reset Status to "In Development"	In Development
			Go to Task Plan	Production
8	Change Manager - Solman	Confirmed	Logon to System	Confirmed
			Complete Correction	Completed
			Reset Status to "In Development"	In Development
			Go to Task Plan	Confirmed

Appendix E. Test Messages possible actions per status

*Step*	*Who- Where*	*Initial User Status*	*Action*	*Final User Status*
1	Tester- Solman	Created	Take "in Process"	In Process
2	Developer- Solman	Created	Take "in Process"	In Process
3	Developer- Solman	In Process	Logon to System	In Process
			Pass to "Retest"	To be Retested
			Create Transport Request	In Process
			Release Transport Request	In Process
			Create Task	In Process
			Go to Task Plan	In Process
4	Tester- Solman	To be Retested	Logon to System	To be Retested
			Confirm Correction	Confirmed
			Reset "in process"	In Process
			Go to Task Plan	To be Retested

Appendix F. Administration Messages possible actions per status

Change Request Management scenario: Working examples Development without Release phase

Dolores Correa — Thu, 23 Jul 2009 05:00:20 GMT

Change Request Management scenario: Working examples “Development without Release” phase

This blog covers the Development without release phase as part of the working case initiated in SDN blog: Change Request Management scenario: Working examples.

Here you will find also the possible actions and statuses of normal and urgent corrections, when you are in this MC phase.

In this phase:

Corrections can be developed; Transport requests, TR from now on, and transport tasks can be created. Export, however, are not permitted (except for the urgent corrections)

Export of urgent corrections are permitted in every phase except for the Go-Live phase.

When using the regular correction SDMJ, this phase is not recommended because the transport of copies can not be exported.

This is the suggested test for the set of corrections created before in this phase:

*Correction*	*Initial User Status*	*Action*	*Final User Status*	*Details*
SDMJ 8000001046	Created	Set to "In Development"	In Development
SDMJ 8000001049	Created		Created
SDMJ 8000001051	Created	Set to "In Development"	In Development
	In Development	Create Transport Request		Created SMMK900664 but left empty
SDMJ 8000001053	Created	Set to "In Development"	In Development
	In Development	Create Transport Request	In Development
	In Development	Logon to System	In Development	SMMK900666, task released
SDMJ 8000001055	Created	Set to "In Development"	In Development
	In Development	Create Transport Request	In Development	SMMK900668
	In Development	Logon to System	In Development	SMMK900668, task released
	In Development	Complete Development	To be Tested	Error: Action cannot be performed during this maintenance phase Notice that status has changed to "To be tested" but further available actions not allow you to go on until you don´t change the phase, see screen 1 below.
	To be Tested	Reset Status to "In development"	In development
SDMJ 8000001057	Created	Cancel Procedure	Withdrawn
SDHF 8000001067	Created
SDHF 8000001069	Created	Withdraw Correction	Withdrawn
SDHF 8000001071	Created	Set to "In Development"	In Development	The "Create transport request" popup appears automatically, created SMMK900670 but left empty, H000000398
SDHF 8000001073	Created	Set to "In Development"	In Development	The "Create transport request" popup appears automatically, created SMMK900672,H000000399
	In Development	Logon to System		SMMK900672, task released
SDHF 8000001075	Created	Set to "In Development"	In Development	The "Create transport request" popup appears automatically, created SMMK900674, H000000400
	In Development	Logon to System	In Development	SMMK900674, task released
	In Development	Pass Correction to Test	To be tested	"Select Transport Request to be Released" popup appears with the transport orders of this SDHF, in our case only entry for SMMK900674 appears, select it, see screen 2 below. When saving a new Information popup appears saying: Import into system SMM 200 started Go to the task list from the document flow area to see if this import in quality system is ok, see screen 3.
SDHF 8000001077	Created	Set to "In Development"	In Development	The "Create transport request" popup appears automatically, created SMMK900676, H000000401
	In Development	Logon to System	In Development	SMMK900676, task released
	In Development	Pass Correction to Test	To be tested	"Select Transport Request to be Released" popup for SMMK900676 appears, select it. Import into system SMM 200 started
	To be tested	Logon to System	To be tested	Check if the change is correct
	To be tested	Confirm Successful Test	Successfully Tested
SDHF 8000001079	Created	Set to "In Development"	In Development	The "Create transport request" popup appears automatically, created SMMK900678, H000000402
	In Development	Logon to System	In Development	SMMK900678, task released
	In Development	Pass Correction to Test	To be tested	"Select Transport Request to be Released" popup for SMMK900678 appears, select it. Import into system SMM 200 started
	To be tested	Logon to System	To be tested	Check if the change is correct
	To be tested	Confirm Successful Test	Successfully Tested
	Successfully Tested	Released for Production	Authorized for Import
	Authorized for Import	Import Correction to Production System	Production	Popup: Import into system SMM 300 started Confirm Correction
	Production	Confirm Correction	Confirmed
	Confirmed	Complete Correction	Completed	Popup Complete Urgent Correction appears, see screens 4

Screen 1:

Screen 2:

Screens 3:

You should also go to the satellite to check that the import is correctly performed.

Screens 4:

With these correction statuses I change the phase to from "Development without release" to "Development with Release":

I go to the SDMN document:

If you click on Flow icon you will see the corrections assigned to this MC:

Then I select action button:

I select "In Development with Release":

See that there is not warning or error indicated, so all is ok with this MC phase change.

Note: implement note 1239726 "Incorrect status for scheduled jobs" if you have not already done before going to the next phase.

Next phase in SDN Blog: Change Request Management scenario: Working examples “Development with Release” phase

Change Request Management scenario: Working examples Emergency Correction phase

Dolores Correa — Thu, 23 Jul 2009 04:59:58 GMT

Change Request Management scenario: Working examples “Emergency Correction” phase

This blog covers the Emergency Correction phase as part of the working case initiated in SDN blog: Change Request Management scenario: Working examples

Here you will find also the possible actions and statuses of normal and urgent corrections, when you are in this MC phase.

In this phase:

If changes still have to be made after the test phase has been completed, TRs and tasks can be created and released as part of the Preparation for Go-Live phase, but only by using the task list of the scheduler manager.

This is the suggested test for the set of corrections in this phase:

*Correction*	*User Status*	*Action*	*Final User Status*	*Details*
SDMJ 8000001049	Created
SDMJ 8000001046	In Development
SDMJ 8000001051	In Development			Created SMMK900664 but left empty
SDMJ 8000001053	In Development			SMMK900666, task released
SDMJ 8000001055	Consolidated			SMMK900668, imported in SMM:200
SDMJ 8000001057	Withdrawn
SDMJ 8000001059	Consolidated			SMMK900681, TOC SMMK900683 Imported in SMM:200 TOC and after SMMK900681
SDMJ 8000001061	Consolidated			SMMK900684, TOC SMMK900686 and SMMK900687 created and exported Imported in SMM:200 TOC and after SMMK900684
SDMJ 8000001065	Created
SDHF 8000001067	Created
SDHF 8000001069	Withdrawn
SDHF 8000001071	In Development			created SMMK900670 but left empty, H000000398
SDHF 8000001073	In Development			SMMK900672, task released H000000399
SDHF 8000001075	To be tested			SMMK900674, H000000400, imported in SMM:200, and in SMM:300 import buffer
SDHF 8000001077	Successfully Tested			SMMK900676, H000000401, imported in SMM:200
SDHF 8000001079	Completed			SMMK900678, H000000402, imported in SMM:300
SDHF 8000001091	Authorized for Import			SMMK900688, H000000411 "Select Transport Request to be Released" popup for SMMK900688 appears, select it. Import into system SMM :200

Don't work with the SDMJ corrections in this phase because you only are allow to create a TR and released it by using the task list directly.

With these correction statuses I change the phase to from "Emergency Correction" to "Go-Live" phase:

11 Warnings:

Normal Correction 8000001046 still has status 'In Development'

Normal Correction 8000001049 still has status 'Created'

Normal Correction 8000001051 still has status 'In Development'

Normal Correction 8000001053 still has status 'In Development'

Normal Correction 8000001065 still has status 'Created'

Urgent Correction 8000001067 still has status 'Created'

Urgent Correction 8000001071 still has status 'In Development'

Urgent Correction 8000001073 still has status 'In Development'

Urgent Correction 8000001075 still has status 'To Be Tested'

Urgent Correction 8000001077 still has status 'Successfully Tested'

This means I SHOULD only work in this Go-Live phase with the SDMJ corrections in "Consolidated" status, and with all SDHF in status "Authorized for Import", "Production", "Confirmed" and "Completed", this means with the following corrections:

SDMJ 8000001055 Consolidated SMMK900668 Imported in SMM:200

SDMJ 8000001059 Consolidated SMMK900681 Imported in SMM:200

SDMJ 8000001061 Consolidated SMMK900684 Imported in SMM:200

SDHF 8000001079 Completed SMMK900678 Imported already in SMM:300

SDHF 8000001091 Authorized for Import SMMK900688 Imported in SMM :200

Next phase in SDN Blog: Change Request Management scenario: Working examples “Go-Live” phase

Change Request Management scenario: Working examples Go-Live phase

Dolores Correa — Thu, 23 Jul 2009 04:59:12 GMT

Change Request Management scenario: Working examples “Go-Live” phase

This blog covers the Go-Live phase as part of the working case initiated in SDN blog: Change Request Management scenario: Working examples

Here you will find also the possible actions and statuses of normal and urgent corrections, when you are in this MC phase.

In this phase:

Importing the entire project buffer into the production system, all transport orders are imported into the production system at the same time in the same sequence as they were exported, also the urgent corrections that has been already imported into the production system to ensure consolidated system status.

No type of correction can be released during this phase.

If there are still any open TRs, you have to return to the Development with Release phase and repeat the process including the test phase to ensure that any open requests can be released and transported.

This is the suggested test for the set of corrections in this phase:

*Correction*	*User Status*	*Action*	*Final User Status*	*Details*
SDMJ 8000001049	Created
SDMJ 8000001046	In Development
SDMJ 8000001051	In Development			Created SMMK900664 but left empty
SDMJ 8000001053	In Development			SMMK900666, task released
SDMJ 8000001055	Consolidated	Set Production Status	Production	IT operator run task "Import Transport Request" in SMM:300, production system TR imported in SMM:300 ALL
SDMJ 8000001057	Withdrawn
SDMJ 8000001059	Consolidated	Set Production Status	Production	IT operator run task "Import Transport Request" in SMM:300, production system TR imported in SMM:300 ALL
SDMJ 8000001061	Consolidated	Set Production Status	Production	IT operator run task "Import Transport Request" in SMM:300, production system TR imported in SMM:300 ALL
SDMJ 8000001065	Created
SDHF 8000001067	Created
SDHF 8000001069	Withdrawn
SDHF 8000001071	In Development			created SMMK900670 but left empty, H000000398
SDHF 8000001073	In Development			SMMK900672, task released H000000399
SDHF 8000001077*	Successfully Tested	Released for Production	Authorized for Import	SMMK900676, imported in SMM:200 I run firstly "Import Transport Request" in SMM:300
	Authorized for Import	Import Correction to Production System	Production	Error: Action cannot be performed during this maintenance phase Action: Recheck correctionàstatus remains in Production, now without errors
	Production	Confirm Correction	Confirmed
	Confirmed	Complete Correction	Completed	I close the H* because as you can see below the TR was already imported by the "Import Transport Request"
SDHF 8000001075*	To be tested	Confirm Successful Test Released for Production Import Correction to Production System Confirm Correction Complete Correction	Completed	SMMK900674, imported in SMM:200 I run firstly "Import Transport Request" in SMM:300 Error: Action cannot be performed during this maintenance phase I close the H* because as you can see below the TR was already imported by the "Import Transport Request"
SDHF 8000001079	Completed			SMMK900678, imported in SMM:300
SDHF 8000001091*	Authorized for Import	Import Correction to Production System Confirm Correction Complete Correction	Completed	SMMK900688, Import into system SMM :200 Error: Action cannot be performed during this maintenance phase

These orders were imported in SMM: 300 when I run task "Import Transport Request" in SMM: 300, production system:

SDMJ 8000001055 Consolidated SMMK900668 Imported in SMM: 200

SDMJ 8000001059 Consolidated SMMK900681 Imported in SMM: 200

SDMJ 8000001061 Consolidated SMMK900684 Imported in SMM: 200

SDHF 8000001079 Completed SMMK900678 Imported again in SMM: 300

SDHF 8000001091 Authorized for Import SMMK900688 Imported in SMM :200

SDMJ 8000001063 SMMK900692 Document Deleted via Business Transactions->Delete

SDTM 8000001092 Completed SMMK900690

SDHF 8000001077 Successfully Tested SMMK900676

SDHF 8000001075 To be tested SMMK900674

You will say why system is importing TR of corrections like SDHF 8000001075 that has status "to be tested"????

All TRs that were in the production import buffer are imported.

When you import a TR in quality system this order is added to the next import system buffer, usually production system buffer.

How to handle the situation and why can't it be solved.

The IMPORT into PRD is a pour call of TMS functionality, so we can not manipulate the import queue.

Recommendation: Always switch the phase/status in the SDMN transaction and not in the task list, in the SDMN transaction you will get the info that there are already SDMJ and SDHF correction in the import buffer switch are in status to be tested.

Which this information you should contact the colleague who owns the correction, mainly the SDHF correction and solve this, means forcing the colleague to test his SDHF.

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.

*In the case of these two SDHF corrections 8000001075, 8000001077 and 8000001091, in "To be tested" and "Successful Test" and "Authorized for Import", after running the Import in SMM:300 I can go with these corrections until Completed status because these TR are already in production. No new import into production system is done because with the tp import ALL these TR are deleted from the production import buffer.

With these correction statuses I change the phase to from "Go-Live" to "Being Completed" phase:

9 warnings:

Normal Correction 8000001046 still has status 'In Development'

Normal Correction 8000001049 still has status 'Created'

Normal Correction 8000001051 still has status 'In Development'

Normal Correction 8000001053 still has status 'In Development'

Normal Correction 8000001065 still has status 'Created'

Urgent Correction 8000001067 still has status 'Created'

Urgent Correction 8000001071 still has status 'In Development'

Urgent Correction 8000001073 still has status 'In Development'

Next phase in SDN Blog: Change Request Management scenario: Working examples "Being Completed" and "Completed" phase

Change Request Management scenario: Working examples "Being Completed" and "Completed" phase

Dolores Correa — Thu, 23 Jul 2009 04:57:59 GMT

Change Request Management scenario: Working examples "Being Completed” and "Completed"phase

This blog covers the Being Completed and Completed phase as part of the working case initiated in SDN blog: Change Request Management scenario: Working examples.

Here you will find also the possible actions and statuses of normal and urgent corrections, when you are in this MC phase.

In this phase:

If there are no open TRs, the MC can be closed by setting the status to "To be closed". Subsequently a new MC can be create.

No further changes are possible in this MC are possible.

When completing the MC all open request and transactions will be decoupled from the task list. When generating a new task list for the same project, all open request and transactions will be linked to this new task list and can be processed further, see note 1071412 for details.

This is the suggested test for the set of corrections in this phase:

*Correction*	*User Status*	*Action*	*Final User Status*	*Details*
SDMJ 8000001049	Created
SDMJ 8000001046	In Development
SDMJ 8000001051	In Development			Created SMMK900664 but left empty
SDMJ 8000001053	In Development			SMMK900666, task released
SDMJ 8000001055	Production
SDMJ 8000001057	Withdrawn
SDMJ 8000001059	Production
SDMJ 8000001061	Production
SDMJ 8000001065	Created
SDHF 8000001067	Created
SDHF 8000001069	Withdrawn
SDHF 8000001071	In Development			created SMMK900670 but left empty, H000000398
SDHF 8000001073	In Development			SMMK900672, task released H000000399
SDHF 8000001077*	Completed
SDHF 8000001075*	Completed
SDHF 8000001079	Completed
SDHF 8000001091*	Completed

I am going to go to Completed phase and see how to handle these open corrections.

Always close the task list working with the SDMN document of the MC.

A task list can be closed even with modifiable transport orders according to note 1071412 "Completing a task plan with changeable transport requests", also apply note 1344191.

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'.

There are 8 open corrections, 4 of them with TR created and not released:

8000001067 Change 11- SDHF SDHF Urgent Correction Created

8000001071 Change 13- SDHF SDHF Urgent Correction In Development

8000001073 Change 14- SDHF SDHF Urgent Correction In Development

8000001046 Change 1- SDMJ SDMJ Normal Correction In Development

8000001049 Change 2- SDMJ SDMJ Normal Correction Created

8000001051 Change 3- SDMJ SDMJ Normal Correction In Development

8000001053 Change 4- SDMJ SDMJ Normal Correction In Development

8000001065 Change 10- SDMJ SDMJ Normal Correction Created

SDMJ 8000001051	In Development	Created SMMK900664 but left empty
SDMJ 8000001053	In Development	SMMK900666, task released
SDHF 8000001071	In Development	created SMMK900670 but left empty, H000000398
SDHF 8000001073	In Development	SMMK900672, task released H000000399

If you go now to see TR in the satellite SMM: 100 you will see that the project is called now "ALL_FLOW_1_DECOUPLED_0000000001":

For an already imported TR you can see SAP_CTS_PROJECT filled.

For the TR SMMK900666 you can see that now it is not assigned to any CTS project:

I create a new MC cycle for the project in solar_project_admin:

Create Task List:

Checking again the open TRs:

All 8 open corrections are assigned now to the new MC and you can continue working on it.

Please see the last SDN Blog of this working example: Change Request Management scenario: Working examples Final Points and Appendix

Change Request Management scenario: Working examples

Dolores Correa — Thu, 23 Jul 2009 04:55:10 GMT

Change Request Management scenario: Working examples

With the following blog you will be able to understand better the Charm functionality in Solution Manager 7.0.

I will be working with the test scenario described in my previous SDN blog First steps to work with Change Request Management scenario

So, now you have a project with Charm activated and a maintenance cycle generated but how to work with it???

I will try to give tips and tricks for the daily work with Charm since the maintenance cycle creation to the competition of the maintenance cycle, showing different examples.

The actions and workflow shown in this blog are valid for Solution Manager 7.0 EhP1 (SPS18) and for maintenance projects.

1. Create a project

You want to make changes in systems as part of your planned maintenance period, and import all these changes simultaneously into production systems at the end of the maintenance period managing this process with the Solution Manager system.

For this purpose, you have to create a project according to step 4 of the above SDN blog First steps to work with Change Request Management scenario , subsequently you create a maintenance cycle for this project from solar_project_admin transaction.

A maintenance cycle, MC from now on, is represented as a change transaction of type SDMN (for maintenance projects) and by a task list in the Schedule Manager.

See the next example:

8000001047 is the SDMN document of the MC.

M000000395 is the task list of this MC.

A maintenance cycle is the period of time in which you:

- Make changes in maintenance systems

- Include these changes in new TRs

- Import these requests into follow-on systems for testing

At the end of a maintenance cycle, all TRs are imported simultaneously into all production systems in the project system landscape in the same sequence as the exports.

From the Charm point of view these activities will be the available in the difference phases of a project and subsequently in the phases of the associated maintenance cycle. Depending on the project phase, different activities are available.

2. Types of corrections or Change Transactions in Change Request Management

These changes in the maintenance systems will be included in these three kinds of corrections in Charm scenario:

- Regular corrections: use the task list M* of the MC of the project

- Urgent corrections: create their own H* task list

- Test corrections: can only be used in Test phase, do not required approval, and allow creating and releasing TRs. They must be released before the phase Go-Live.

The workflow for any change starts with the occurrence of an error or missing function in the production system. This is reported to the Service Desk message SLFN.

If this error or missing function required a development then a Change request document, transaction type SDCR, is created, usually by the Change Manager.

First point, the SDCR have to be created for a system with production role in the logical component of the involved project, I mean the ibase component should be the ibase component of a production system always.

You can create this SDCR document from CRMD_ORDER: Business Transaction-->Create

Fill the Description and the BP numbers for the Sold-to party, requester and change Manager.

Also fill the ibase component for which the change is being requested, note that this ibase component can not be changed afterward.

Pay attention to field "Subject", here you have to decide if you need an urgent correction or a regular correction for your change. You will see after the different workflows between these corrections.

The change request is then approved via action "Authorized Change Request":

Subsequently, depending on the subject in the change request, a change transaction of the type Urgent Correction SDHF or Regular Correction SDMJ is then created.

If subject is Normal correction or Urgent correction and there is more of one MC opened for this ibase component, you will get a popup asking for the MC to which assign this correction:

Go to Document Flow button to see the associated correction.

You can navigate to this correction making double-click over it.

You can create regular and urgent corrections, both, for the same MC, after you will see some examples of this.

Each change requests SDCR and change transactions, SDHF and SDMJ, are a document of the service order transaction and can be maintained by using transaction CRMD_ORDER and CRM_DNO_MONITOR.

All users involved in the correction process (the corresponding Business Partners have to be maintained) navigate from the change transaction into the relevant target systems in the maintenance or development landscape. Users perform various tasks in these systems, provided that they are authorized. The change transaction can be passed on to the next processor (a tester, for example). Each time that the change transaction receives a new status (Tested successfully, for example), certain change management actions such as releasing a TR have to be performed. These actions are performed either automatically when the change document is saved, or are performed explicitly by a particular user.

Actions can only be performed under certain conditions. Which actions are performed depends on the status of the change transaction and on the status of the corresponding maintenance cycle. The statuses of a maintenance cycle represent phases of a change process.

3. Maintenance Cycle Phases

These are the MC phases, which represent the phases of a change process.

Note: "Preparation for Go-Live" = "Emergency correction"

What can be doing in each MC phase? Workflow for Maintenance Cycles

The change manager should be the person in charged to create a project, and the associated MC from the solar_project_admin. He would be also the person switching the phases according to the project needs.

The MC has these phases:

Created: Initial status of the MC.
Development wo release: In EhP1 the MC get this phase directly when is created.

Corrections can be developed; Transport requests, TR from now on, and transport tasks can be created. Export, however, are not permitted (except for the urgent corrections)

Export of urgent corrections are permitted in every phase except for the Go-Live phase.

When using the regular correction SDMJ, this phase is not recommended because the transport of copies can not be exported.

Development with release

TRs can be released from within a regular correction.

For regular corrections, the administrator has to use the task list to import all released corrections into the test system or he has to schedule regular import batch jobs.

Test

Release of regular corrections is not possible anymore (code freeze).

Urgent corrections can be used as in the previous phase.

Unfinished developments will not be included in the actual test and go-live, they can be included in the next test phase.

Emergency correction

Go-Live

Note: this happens because the urgent correction transports stay in import queue after import when using variant SAP0.

No type of correction can be released during this phase.

To be closed

If there are no open TRs, the MC can be closed by setting the status to "To be closed". Subsequently a new MC can be created.

Completed

MC is closed. No further changes are possible in this MC are possible.

4. Working case

I created a maintenance project ALL_FLOW to be used like example for my landscape:

SMM: 100->SMM: 200->SMM: 300

By default the new task list is created with tasks locked in EhP1, then unlock the task groups and tasks in the Schedule Manager.

Also in EhP1 the MC phase at this moment of creation is Createt, click on Phase icon to see it.

Note: Please always change the phases of this maintenance cycle, since SPS13 and above, via the SDMN document directly, go to CRM_DNO_MONITOR (select transaction type SDMN) enter your document number and change the phase via Actions in the document directly.

In this case from Created to In evelopment without release in order to be able to work with this MC:

Now I am going to create a set of normal and urgent correction associated to the MC of this project and work with them leaving them with different user statuses through the different phases of a MC to see what happens with them.

SDMJ 8000001046

SDMJ 8000001049

SDMJ 8000001051

SDMJ 8000001053

SDMJ 8000001055

SDMJ 8000001057

SDMJ 8000001059

SDMJ 8000001061

SDMJ 8000001063

SDMJ 8000001065

SDHF 8000001067

SDHF 8000001069

SDHF 8000001071

SDHF 8000001073

SDHF 8000001075

SDHF 8000001077

SDHF 8000001079

Please go to http://service.sap.com/rkt-solman-> SAP Solution Manager 7.0 - EHP1 Learning Map: Optimization with SAP Solution Manager -> Section: Improvements of Processes, Components, and Solutions: Change Management

Have a look to these tutorials to get familiar with the way to work with Normal (Regular) and Urgent corrections:

Change Request Management - Regular Correction

Change Request Management - Urgent Correction

You will find these two orientating workflow slides:

In order to handle this long document I have split it in several blogs, each per maintenance cycle phase:

- Change Request Management scenario: Working examples “Development without Release” phase

- Change Request Management scenario: Working examples “Development with Release” phase

- Change Request Management scenario: Working examples “Test” phase

- Change Request Management scenario: Working examples “Emergency Correction” phase

- Change Request Management scenario: Working examples “Go-Live” phase

- Change Request Management scenario: Working examples "Being Completed" and "Completed" phase

- Change Request Management scenario: Working examples Final Points and Appendix

You will see how to work with the set of created corrections in each phase.

For further information about the Charm scenario see also the following SDN Blogs:

- First steps to work with Change Request Management scenario

- Change Request Management scenario: Usual questions and known errors

- Change Request Management scenario: Retrofit Functionality

Change Request Management scenario: Usual questions and known errors

Dolores Correa — Wed, 22 Jul 2009 12:58:46 GMT

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 your patch level, this will avoid you some known errors.

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

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:

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 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

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".

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.

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

- 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 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:

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.

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.

CTS+ Configuration in Solution Manager 7.0 EhP1 and 7.1

Dolores Correa — Fri, 05 Jun 2009 01:31:50 GMT

Configuring CTS+ in Solution Manager 7.0 EhP1 and 7.1

With the following steps you will be able to create a project to practice with the CTS+ scenario in Solution Manager 7.0 EhP1.

Also I will try to give tips and tricks for the common mistakes in the configuration of this scenario.

The configurations given are valid for Solution Manager 4.0 EhP1 and above.

I will work in this example TMS landscape for portal systems: XAD->XAQ->XAP

NOTE: Please check note 1803185 if you are implemententing this for a Solution Manager 7.1

Step 1- TMS configuration for CTS+ in solman system

Please check in detail the following document regarding this step:

Best Practices for Implementing CTS+

The first step is always to create the system in the TMS of the Transport Domain Controller TDC, also called communication system.

This TDC can be located on the SAP Solution Manager for example in the case of the non-ABAP systems.

Important note: In order to use Charm with the CTS+, the communication system for your non-ABAP systems must have at least SAP_BASIS Release 701 SP Level SAPKB70103 or higher. For more information, check note 1356771.

For the case of a system with only Java-stack create a non-ABAP systems, This system type is needed for all pure AS Java landscapes for example EP, JAVA or SLD.

/nSTMS -> Overview -> Systems -> Create -> Non-ABAP System.

Existing systems in the transport landscape that are dual-Stack systems (e.g. use case PI) can now be enhanced with the new Transport Tool parameters for the Java stack to be able to transport non-ABAP objects. Typically the ABAP stacks are already configured and included in the transport domain. To add the CTS+ functionality for transports to the Java stack, the existing configuration for the ABAP systems needs to be extended with the relevant CTS+ parameters. Since SAP NetWeaver 7.0 SP Stack 14 a wizard can be used to add the relevant parameters to existing ABAP system configurations (/nSTMS -> Overview -> Systems -> Create ->Java Stack).

However in solman 7.0 we have some limitations for this CTS+ functionality in a dual stack system, as in solman 7.0 we cannot differentiate distinct systems with the same SID, even if they are located in different domains. I mean if you define a system in SMSY with two Main instances, one for the ABAP stack and the other for the Java stack with the Technical name for the Java like in the screen below, the non-ABAP instance of a dual-stack system could not be used in charm because we will still consider it as an ABAP system by reading its main instances from SMSY.

But not only non-ABAP instance will not work, the ABAP instance might also be affected. The logic is this: we try to read the system configuration from SMSY -> we can correctly determine that it is dual stack system because the relevant flags are selected -> but when we want to do the real transport we need to read the domain info -> two systems with exactly the same SID -> cannot differentiate them and cannot get the domain info correctly -> both ABAP and non-ABAP instance might not work in charm.

So, in the case that you want to transport Java objects for ABAP systems (dual-stack) via charm in solman 7.0 them you have two options:

1. If you only want to manage the transport in the non-ABAP stack side, you could simply create the project by using ABAP stack of the system, and create transport requests in the ABAP system. After that, you will be able to use those requests to save non-ABAP changes as well and transport them. This is a existing functionality for CTS+.

2. If the dual-stack system is called DEV, create a non-ABAP system for DEV system but with a different SID in the STMS of the domain controller. Then assign this system to the technical system field of the non-ABAP stack in SMSY entry of DEV, and use this new to create the logical component/projects.

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

Note: In this case we are doing this is the solman system itself because we are going to use the solman system like COMMUNICATION SYSTEM for this non-ABAP system.

In case you want to use another ABAP system like communication system do this TMS configuration in the TMS domain controller of this ABAP systems landscape.

After create a domain link between this TMS domain controller and the domain controller of the solman systems landscape where charm is configured.

The following parameters are mandatory:

For XAD system (source system):

- CTC 0

- CTS_SYSTEM_TYPE JAVA (others for a MDM system, according to note 1464456 it should be MDM for MDM system...)

- NON_ABAP_SYSTEM 1

- COMMUNICATION_SYSTEM: CXE

(SAPSID of the ABAP communication system (e.g. the domain controller))

- NON_ABAP_WBO_CLIENT 100

(Client of the ABAP stack on which the Transport Organizer Web UI (CTS_BROWSER) is activated and will run.)

- WBO_GET_REQ_STRATEGY TAGGED

- WBO_REL_REQ_STRATEGY MANUAL

For quality and production Java system (target systems):

- CTC 0

- CTS_SYSTEM_TYPE JAVA (others for a MDM system)

- NON_ABAP_SYSTEM 1

- COMMUNICATION_SYSTEM: CXE

- DEPLOY_WEB_SERVICE CTSDEPLOY

- DEPLOY_DATA_SHARE: <DIR_TRANS>\\data

- DEPLOY_URL: http://<JQS_host>:<JQS_SDM_Port>

Note: This would be the CTC correct value:
CTC=1 Client specific for ABAP and Double Stack systems
CTC=0 Client independent for Java standalone systems

/nSTMS in the solman system -> Transport routes

Look for XAD->XAQ->XAP landscape

Specify the transport layer used for the development system, in this case ZXAD.

More details in:

http://help.sap.com/saphelp_nw70/helpdata/en/45/EC25370FDC3481E10000000A1553F6/frameset.htm

http://help.sap.com/saphelp_nw70/helpdata/en/44/b4a09a7acc11d1899e0000e829fbbd/frameset.htm

In ChaRM for non-ABAP systems, notice that we will only use the standard transport layer as they defined in STMS. So we could only recognize one Q system.

In case you have two Q systems, configure a target group to the two Q systems, this will link your D system to the group by using one transport layer, in this way both systems will be recognizable under the same "standard transport layer".

Step 2- Definition of non-ABAP Systems in SMSY

The Java system must be defined in this way for a portal system:

Product version: SAP Netweaver 7.0

Data source should be AUT_LCR SLD:

In selection of Main Instances tab you need to flag as relevant the Enterprise Portal instance:

Always use SLD landscape fetch for systems in Solman EhP1.

Important point: Communication system´s information will be read in the background from the tranport parameter settings on remote systems ("COMMUNICATION_SYSTEM" and "NON_ABAP_WBO_CLIENT").

I mean this data are fullfilled automatically from TMS, these values can not be maintained in SMSY.

This data are stored in database table SMSY_SYSTEM_OTO. If the relevant entry is missing, try to press the button "Read System Data Remote" for the domain controller of the non-ABAP system in SMSY.

In this example we are using the Solman system itself.

Note: Don’t forget the create the RFC connection for CXE:100 system in order to be able to create the IMG project afterward in solar_project_admin. Also don´t forget to create the ibase component for the non-ABAP system or to check that the ibase component was created automatically.

For the quality Java portal XAQ and XAP created them as explained about for XAD with only one difference, you need to see only the ABAP Transport System and not the client.

Note: Please run Read System Data Remote in SMSY from the communication system to get the data under Transport System/Client for non-abap systems

Note: For a PI system select Java System instance as relevant.

Note: For a MDM system select Master Data Server instance as relevant type MDM server (correct definition for Diagnostics) or Thirdparty.

Step 3- Definition of Logical Components in SMSY

Note: Not clients are selected.

Note: For a PI system choose Application Server JAVA

Step 4- Definition of a Project and a Task List

To use Change Request Management, you need to define a project in the Solution

Manager in transaction SOLAR_PROJECT_ADMIN.

Call transaction SOLAR_PROJECT_ADMIN, choose New Project.

Choose tab System Landscape and then tab strip Logical Components, enter your Logical component and save:

Choose tab IMG Project and create the IMG project:

The IMG project is created in the communication system of the development system.

If there are different non-ABAP dev systems share the same communication systems, then you should created different IMG projects for each non-ABAP dev system separately.

Please see point "25. Special considerations for non-ABAP landscapes in ChaRM" in SDN blog: Change Request Management scenario: Usual questions and known errors

Choose tab Change Requests and select Activate Change Request Management. Choose Create Task List.

Now you can use the Change Request Management within/with help of this task list.

Tables to check in Solman system:

SMSY_SYSTEM_OTO: check the RFC to the communication system (OTO_SYSTEM and

OTO_CLIENT)

SMSY_SYSTEM_SAP

Now you can work with Charm to manage your changes also for non-ABAP objects, take care of the ibase component selected when you create a change request

document for a non-ABAP object, the ibase component must be the ibase of the

productive Java system, select the upper entry without client. DO NOT use the IBase of the communication system!

The main differences between managing ABAP and non-ABAP sytem are:

- IMG and CTS project is created on the communication system of the non-ABAP development system and not in the development system like for an ABAP system.

- To manage the transport request we will use CTS+ web UI and not se09 like for ABAP systems, however still you can see the transport logs in se09 of the communication system.

- The action "System Logon" for non-ABAP dev system will open a pop-up for the user to choose: 1)Open the CTS+ web UI on the communication system (Request button) or 2)Logon to the non-ABAP system directly (Logon button).

For the non-ABAP qua and prd system action "System Logon" will go to the respective non-ABAP system directly.

Please check note 907768 for all available corrections concerning non-ABPA feature in Charm up to now.

To use the full non-ABAP functinoality in ChaRM, the communication system should have SAP_BASIS version at least NetWeaver 7.01 SP 03 or higher.

If you are going to use normal corrections SDMJ to manage non-ABAP transports, please implement notes 1388112, 1410010 and 1293449 to your SOLMAN system and TMS communication system.

Still there are these restrictions:

- At present empty non-ABAP requests cannot be deleted automatically when releasing them from ChaRM, further correction/development in component BC-CTS-ORG-PLS is required to realize this functionality.
- As a prerequisite for transport request to be used in CTS+ web UI of "Close Coupling", you must pre-selected it as the default request. Currently we cannot do it in ChaRM. Therefore you have to do it manually for each request in the CTS-Browser within the TMS:
1. Call transaction "STMS".
2. Press the button "Transport Organizer WEB UI" (or press F7) to start the Browser.
3. Select the system in the popup where the request was created.
4. Mark the request you want to use for the Non-ABAP-Objects
5. Set the marked request as preselected request (button "Preselect Request").
After that the request is available and can be used to add objects.

Further information in:

1003674 - Enhancement for non-ABAP systems in CTS

1045501 Integration of CTS+ in Change Request Management

1155884 - CTS+, configuration 'close coupling': Troubleshooting guide

Check also notes:

1360910 Deploy error of NWDI or CTS deploy proxy 7.0 to NW CE/7.20

1266133 CommunicationData-Address (no URL):'null' error

First steps to work with Change Request Management scenario

Dolores Correa — Sat, 26 Jul 2008 04:20:06 GMT

First steps to work with Change Request Management scenario

With the following steps you will be able to create a test landscape to practice with the Charm scenario in Solution Manager 7.0 without creating interferences with real TMS landscapes.

Also I will try to give tips and tricks for the common mistakes in the configuration of this scenario.

The configurations given are valid for Solution Manager 7.0 since SP9 and above.

Note: Ensure you have seem the configuration guides attached to note 1520678 "Change Request Management Configuration & Operation Guides"

Step 1- Create the test landscape

Usually you would like to use Charm to manage the changes in this kind of TMS landscapes:

DEV:100 -->QUA:200 -->PRD:300

The test landscape that I am proposing is this one: your Solution Manager is installed in system SMM for example, and you are configuring client 001 for being used as Charm client, them SMM:001 is your Charm client.

Create three additional clients in SMM, like local client copy from client 000 with SAP_ALL profile (this will need some extra space in SMM system, but not too much), let say you create clients 100, 200 and 300.

We assume that SMM:100 is going to be the Development system, SMM:200 the Quality system and SMM:300 is the Production system.

In SCC4 assign the following client settings, roles, etc. to these clients, this is important!

Customizing role for SMM client 100

Test role for SMM:200

Production role for SMM:300

The indications given for this test case from now on also apply to for your real TMS landscape, to DEV, QUA and PRD system.

Note:

In ChaRM we do support two-system landscape, to use it you should firstly configure the consolidation route in STMS correctly.

Then set up the development system as type of role "Source System", and production system as type of role "Production System" in your project system landscape. In such projects there should be no target system needed.

Please always keep in mind that production system is very special in ChaRM so make sure there is at least one in each of your project.

See that in two-system landscape no test transport will be generated for normal correction SDMJ, since officially this functionality is only designed for test system, see note 1419150 ChaRM: Transport of Copies (ToC) with two-system landscape.

Step 2- Configuration of TMS for this scenario according to Charm prerequisites

In Solution Manager, in client 000, call STMS (the same must be done in the domain controller system of your real landscape)

Note: SMM client 001 does not need to take part of your TMS landscape.

Select Transport Routes icon:

For this test landscape initially you have system SMM and none transport route defined (for a real landscape you will have the three system boxes DEV, QUA and PRD):

Make double-click on system SMM and fill the following values (or in the box of the development system and after in the quality box):

In System Attributes tab: the use of Single transport is a prerequisite for Charm for all the systems in the landscape; you will see this in detail in section Step 3.

In Standard Transport Layer tab: ensure you enter the client 100, (client with customizing role for the development box, client with test role for the quality box).

Create the consolidation transport routes to SMM:200, transport route must be CLIENT SPECIFIC for the use in Charm scenario, this is real important!

From development system to quality system you need at least two consolidation routes, SAP and ZXXX.

Go with the pencil from the system SMM to system SMM and get this pop-up:

I create the consolidation route for transport layer SAP and I do the same to create transport route for transport layer ZSMM (for customer developments).

In case of a real landscape you need to choose from which system to which system and client.

I make the same to create the Delivery transport route from SMM:200 to SMM:300, delivery routes are always from quality to production systems.

Finally you will get the following situation:

Save and distribute the changes:

All the previous work has to be done in the satellite systems in real landscapes.

Step 3- Review of the main configuration points in SPRO

1. All point under SAP Solution Manager -->Configuration -->Basis Settings must be performed.

Especially important point is:

RFC connections from Solution Manager to DEV, QUA and PRD system, don’t forget to create also SM_..._TMW connection to all satellites DEV, QUA and PRD, to clients with customizing, test and production roles, in our example, we will create the RFC connection to 100, 200 and 300. Also to client 000 of all the involved systems, DEV, QUA and PRD systems in our example.

In transaction SMSY:

Also you need to create the RFC connections from Solution Manager SMM:001 to client 000 in the system that is the domain controller of your real landscape, this is really IMPORTANT!!! You will see more information about this in spro point “Generate RFC Destinations to Client 000"

Note: usually the domain controller is always in DEV system as this was the first system in the landscape to be installed. If you move the domain controller to PRD system, as it is recommended, don´t forget to create the RFC connection to client 000 of this domain controller system.

2. In SPRO go to Scenario-Specific Settings-->Change Request Management -->Standard Configuration

General Activities:

2.1. Run “Activate Integration with Change Request Management”

After this check in SM30 that view BCOS_CUST has the following entries:

CHARM W NONE CUST620 1.0

CHARM_DEST W NONE CUST620 1.0

This means that Charm configuration has been done in this client.

2.2. Activate BC Sets: Check note 903527

Bc Set for Charm: SOLMAN40_CHARM_BASICFUNC_001

Under Transport Management System check the following in detail:

2.3. Define Transport Routes for System Landscape: already explain in steps above

2.4 Activate Extended Transport Control: apply this point to all systems in real scenario

2.5 Configure Transport Strategy: apply this point to all systems in real scenario

2.6. Activate TMS Trusted Services: apply this point to all systems in real scenario

2.7. Activate Domain Links: you have to create inter-domain links

If you go to STMS in the solman system you can see that the solman system is in transport domain DOMAIN_SMM for example.

In your real landscape, DEV, QUA and PRD will belong to another transport domain, usually called DOMAIN_DEV.

What you need to do in this spro point is to make these two transport domains known each other, I mean as the solman system is going to call TMS functions in the transport domain of DEV, QUA and PRD, the TMS of solman must know this other transport domain.

From help.sap.com:

To request a link between two transport domains, proceed as follows:

- Log on to one of the two domain controller systems, in solman system for example.

- Call transaction STMS (always being in client 000).

- Choose Overview --> Systems.

The system overview appears.

- Choose SAP System-->Create --> Domain link.

The dialog box Request for Linking 2 Domains appears.

Enter system name, DEV for example, hostname where is installed the system and system number, all this information is in SM51 of this DEV system, if DEV system is the domain controller of your real landscape.

Your SAP System performs the following actions automatically:- Generates the required RFC destinations. - Sends the address data of the controller to the controller in the other domain.After you have to logon in the domain controller, client 000, of your real landscape and confirm the link between these two domains as follows:

- Log on to the domain controller in the other domain.

- Call Transaction STMS in client 000.

- Choose Overview -->Systems. The system overview appears.

- Position the cursor on the domain controller where you requested the domain link, DOMAIN_SMM in our example, and choose SAP Systemà Approve.

- Confirm the prompt and distribute the configuration.

The two domain controllers now exchange all necessary information about the systems in their domains. This information is distributed to all systems in the domain whose controller you are currently logged on to. A transport profile is generated, which contains all systems in both domains.

You have to see something like this in your solman system (called SSM in this real example):

And this in the DEV system (called ED4 in this real example):

To check that the domain link is ok go in solman system and in development system to STMS->transport routes, in the top of the screen you will see that in solman system the systems belonging to the other transport domain appear like boxes and the same if you go to STMS in DEV system, the box of the solman system can be seen.

The information about the systems in the other domain is not automatically distributed to the systems in the domain where you requested the domain link. This means that you must distribute the new configuration to these systems.

2.8. Generate RFC Destinations to Client 000: already explained.

2.9. Add Import Authorization to Operator/Administrator: According to note 913232

"Therefore, the TMS requires that the people responsible for the import (operator or administrators with import authorization) have a user in the client 000 of the target system".

This means that you need to define these users in the client 000 of all target systems involved in the landscape with import authorizations.

Under Change Request Management:

2. 10. Set Project Assignment of Requests as Mandatory: not totally mandatory but this will avoid users creating transport orders directly in development system. All transport orders in development system in your real landscape must be created from the solman system via a Change Request.

2. 11. Maintain Number Ranges: run this.

None of the configuration points under “Extended configuration” are required if you want to use the standard Charm scenario.

Now you are ready to create a project.

Step 4. In Solution Manager go to transaction SOLAR_PROJECT_ADMIN

Please go to http://service.sap.com/rkt-solman

Select SAP Solution Manager 7.0, select Learning Map for Supp Organizations/Serv providers, open Change Request Management section and see the iTutor called:

“Create a Project”

The main points in the creation of a project for Change Request Scenario are:

- Decide if your project is an implementation or a Maintenance project; see the differences in the Solution Manager Documentation. For our test case select a maintenance project.

- In System Landscape Tab

Systems: here you have to enter your logical component

Take into account that all systems that belongs to the TMS landscape must be assigned to the same logical component, because all system must have the

same product version (exception in case of an upgrade).

This means that in the same logical component each system must have assigned a role, you can have a minimum of two systems for Charm scenario but you can have for example 5 systems with different roles in your real landscape.

In our test case you will have this:

Always define here the same landscape that you have defined in the STMS of the real landscape, if not the Charm scenario can not be activated. This point is always the point that more problems gives in the activation of Charm scenario!!!

- In IMG project tab: define always a project in the development system ONLY! You need to define this project in the development system in order to assign to this project all transport orders that you are going to create via a Change request in the solman system, this is a prerequisite for Charm scenario!

See the above iTutor to see how to define this IMG project.

Don’t define IMG projects in other roles, systems, different to development.

- In Change Request tab: Select “Activate Change Request Management”

Select Create Task List

Select the name of your Maintenance Cycle also called Project Cycle.

Note: Choose Lock/Unlock Grroup/Subsequent Groups to unlock the tasks in the task list.

If all is working correctly a Task List and a Maintenance transaction type SDMN (called Service Desk Transaction in the screenshot) is being created.

Service Desk Transaction Tab: This tab is not appearing in SP9 but appears in SP13 and above and shows the SDMN document for this project cycle.

The task list is one representative of the cycle and represents the system landscape tracks with tasks to be used by an IT operator for managing project related IT activities, especially imports.

The SDMN transaction represents the service request for managing the phase changes.

In SP9 you went to Task List to Activate the maintenance cycle and also to change the phases of this maintenance cycle, in SP13 and above it are recommended to go to the maintenance transaction directly, via CRM_DNO_MONITOR (select transaction type SDMN) and activate and change the phase via Actions in the transaction directly.

So, phase shifts should be done from within the cycle transaction SDMN but not from within the tasklist.

In case of the Task list in not created please run the Check (transaction /n/tmwflow/charmchk) or go to the Application Log via the button or calling SLG1 directly.

In both place you will get information above the reasons why the Task List and the Maintenance Cycle is not being created.

As summary pay special attention to the following points:

- Ensure that the Logical Component in Systems tab and the TMS information in STMS in the domain controller of your real landscape fits together

- Transport routes must be set client specific

Now is time to check the RKT material, iTutors:

- Regular correction

- Urgent correction

to fully understand the complete process.

When everything in the test scenario is running fine, then you can connect the Production System landscape to Solman system.

This will ensure that you do not stop the TMS in the production landscape.

Update information of Charm can be found in:

907768 “General note for Change Request Management ST 400”

881553 “Roles for Change Request Management (SAP Solution Man 7.0)”

1520678 "Change Request Management Configuration & Operation Guides"

For further information about the Charm scenario see also the following SDN blogs:

- Change Request Management scenario: Usual questions and known errors

- Change Request Management scenario: Working examples

- Change Request Management scenario: Retrofit Functionality

dolores.correa

Change Request Management - New features in SAP Solution Manager 7.1

Change Request Management - New features in SAP Solution Manager 7.1

1. 4. How to work and search Charm documents

Service Desk: SLA configuration hints for SAP Solution Manager 7.0

Service Desk: SLA configuration hints for SAP Solution Manager 7.0

Step 1. IBase model, sold-to party

Step 2. Organizational Model

Step3. Sold-to party

Step4. Product Maintenance definition

Step5. Create a Service Desk contract SLFV

Step6. Check SLFN settings for contract determination

Step 7. Copy control

Step8. Contract Determination Procedure

Step 8.Add Item Detail tab in SLFN

Step 9: Create a SLFN document

Change Request Management: Reporting

Change Request Management: Reporting

Change Request Management scenario: Retrofit Functionality

Change Request Management scenario: Retrofit functionality

Introduction

Configuration

Working from the task list M*

Execution of Retrofit-Process

Involved RFC Destinations

Important things to take into account

Appendix A: Explanation of Retrofit-Functionalities (ALV-List and Buttons)

Appendix B: Explanation of Object-List functionalities (Buttons)

Appendix C

Change Request Management scenario: Working examples Development with Release phase

Change Request Management scenario: Working examples "Development with Release" phase

Change Request Management scenario: Working examples Test phase

Change Request Management scenario: Working examples “Test” phase

Change Request Management scenario: Working examples Final Points and Appendix

Change Request Management scenario: Working examples Final Points and Appendix

Final points to remember

Appendix A. Interesting transactions to know

Appendix B. Change request SDCR possible actions per status

Appendix C. Normal correction possible actions per status

Appendix D. Urgent correction possible actions per status

Appendix E. Test Messages possible actions per status

Appendix F. Administration Messages possible actions per status

Change Request Management scenario: Working examples Development without Release phase

Change Request Management scenario: Working examples “Development without Release” phase

Change Request Management scenario: Working examples Emergency Correction phase

Change Request Management scenario: Working examples “Emergency Correction” phase

Change Request Management scenario: Working examples Go-Live phase

Change Request Management scenario: Working examples “Go-Live” phase

Change Request Management scenario: Working examples "Being Completed" and "Completed" phase

Change Request Management scenario: Working examples "Being Completed” and "Completed"phase

Change Request Management scenario: Working examples

Change Request Management scenario: Working examples

1. Create a project

2. Types of corrections or Change Transactions in Change Request Management

3. Maintenance Cycle Phases

4. Working case

Change Request Management scenario: Usual questions and known errors

Change Request Management scenario: Usual questions and known errors

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 code and tp errors

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

15. Working with urgent corrections and normal corrections in the same task list --REALLY interesting behaviour 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 authorization for READ RFC connections

22. Registering transport requests in ChaRM

Change Request Management scenario: Working examples Development with Release phase

Change Request Management scenario: Working examples Test phase

Change Request Management scenario: Working examples Development without Release phase

Change Request Management scenario: Working examples Emergency Correction phase

Change Request Management scenario: Working examples Go-Live phase