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.
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.
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.
- Emergency correction
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.
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.
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.
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.
- 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.
MC is closed. 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.
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.
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:
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:
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: