Skip to Content

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 in SAP Solution Manager 7.0

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 in SAP Solution Manager 7.0 , 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:

image

 

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

image

image

image

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.

image

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

 image

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:

image

Go to Document Flow button to see the associated correction.

image

image

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

image

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.

image

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.

  • Test

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. 

  • Go-Live

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.

  • Completed

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.

image

 

4. Working case

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

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

image

image

image

 

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

image

image

 

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:

image

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:

image

image

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 in SAP Solution Manager 7.0

Change Request Management scenario: Usual questions and known errors

Change Request Management scenario: Retrofit Functionality

To report this post you need to login first.

9 Comments

You must be Logged on to comment or reply to a post.

  1. Anonymous
    Dear Dolores,

    I find the tutorials for normal en urgent corrections very helpful. Is there also a tutorial for Test messages?

    Kind regards,
    Sebastian Zondag

    (0) 
  2. Elena Ainoulina
    Dolores,
    This information is priceless – very helpful !

    I have 1 question about cycle task list :

    if in the middle of the mtc. cycle my system landscape has changed (ex. QAS client changed from 200 to 300, or I need to add a completely new system: say I had logical component for ECC, now I am adding new log component for portal).

    How do I update/recreate a task list of the cycle to include new component ?
    Is it possible ? Or I just have to create a separate cycle for each logical component ?

    Thanks
    Elena

    (0) 
    1. Dolores Correa Post author
      Hi Elena,
      If you have one logical component per project, the management of the MC will be simpliest but this is all, so, you can have several LC per project.
      However in case of a LC system needs to be changed, as you say, you should close your current task list, change the LC and create a new task list.
      The problem in the case you have several LC for project is that you have to check in this case the status of all the correction assigned to this MC, all open corrections will move to the new task list depending on their status, but for some of them you should process them until the completion point.
      I mean, more LC assigned to a project more work in case you have a change in a included LC.
      So, if the lanscape is not really stable for a LC I will work with it separatelly in a project.
      Hope this helps,
      Dolores
      (0) 
  3. Nathaniel Williams
    Dolores-
    Very Helpful as this clarifies the SDMJ process very nicely.

    Was wondering if you could share the name of the Batch job that imports the transport of copies.

    (0) 
  4. David Weeda
    Hello Dolores,

    I have been working on figuring out ChaRM for a while now and I would like to check something with you. SDMJ_01, the workflow does not seem to match the Workflow in your blog. If Corrections are set to “Confirm Successful Test” in the Development with Release Phase they are released in the order that they are “Confirmed” in the Test Phase these transports need to me released by the task list which releases the transports in numerical order which is order of creation.
    What do I do if I want a development freeze for a project but also want the transports to be released in the order of the final “Development Complete”?

    Regards,
    David Weeda

    (0) 
    1. Dolores Correa Post author
      Hello David,
      The release of the transport request is done automatically when you select action “confirm sucessfully tested”. This is creating an entry in the qua import buffer.
      The next time you execute and import_All from the M* task list into the qua system this TR will be imported into qua system, but the import is not done following the TR numerical order, it is not following the TR creation order, the import is done following the sequence found in the qua import buffer, I mean, the transport requests are imported in the same sequence you exported or released them.
      So, if you want to freeze a change, a TR, them the only solution is to leave in status “to be tested”, I mean you should not release the TR.

      Hope this helps,
      Dolores

      (0) 
  5. Ravindran Pather

    Hi Dolores

    i must say wow , if there where more poeple like you in the SAP world , it will be a better world 🙂

    i have been recently tasked with providing SAP Solman 7.1 functionality for a client

    all i have is a systems with 7.1 installed (lol)

    the client wants to utilise functionality to compliment the following :

    Transports

    Testing

    Job Control

    i have been downloading tons of paper , poor trees and they seems to be very helpful sepeciall the cHram docs

    i am now looking for the test and job control

    why i need to is provide proof of concelpt for value add as this client is on a support contract with me and is already 5 years in the productive enviroment

    any advice will greatley help

    much apprecitaed

    Kind Regards

    Ravi

    (0) 
  6. Kathiravan Jegatheesan

    Hi Dolores,

    Your blogs are my first and best source of information for any ChaRM related questions and problems.

    I have a question!

    I am working on 7.1 SP 8 version and in the TEST phase we are seeing that creating Normal Change documents are possible by extending scope and approving the existing Request for Change documents.

    Is this a standard behavior?Should it not prevent all Normal changes during TEST Phase (for both Existing RfCs and new RfCs) and allow only Test Messages?

    I have searched for relevant SAP notes but could find none.

    Regards,

    Kathir

    (0) 
  7. Martin Ponce

    Hi Dolores.

    We have a doubt working with “Normal Changes” and “Urgent Changes”. In our case we have

    implemented Charm on Solution Manager 7.1 SPS 12. So, we have created a proyect ZPrueba and

    a Maintenace Cycle (MC) for  “Normal Changes” and “Urgent Changes”.

    We want to test how work it !.  For example, we have created a “Normal Change”, and we have

    performed two modifciations on the program Z_Test1, so, we have generated two versions of the

    program Z_Test1. Besides, the “Normal Change” is in the phase “To be Tested” and the MC is in the

    phase “In Development with release”.

    Now, we going to create a “Urgent Change” on the same MC and we want modified the program Z_Test1 but it is locked stiil for the Transport Request generated on the “Normal Change”.

    The question is if is it the normal behaviuor ?, or Is possible to modify the program Z_test1 in order to transport to production system asap ?.

     

    Regards,

    Martín.

     

     

    (0) 

Leave a Reply