Here’s what I thought before using CHARM:

Charm will:

  • Remove Conflicts between developers
  • No more missing objects when transporting to production
  • No more keeping track of transport dependencies
  • Allow to bundle transports outside of SAP
  • Keep defects with original requests
  • There will be less transports

The above is living in Michelle’s world of what CHARM will do.  NOT WHAT SAP or CHARM Claims to do.

So here’s a scenario:

I would make changes to an object.  There would be changes to an outside system.  Developer 2 makes changes to a different object that is a part of my project.  All of the previous transports/objects will be bundled in one CHARM request.  Emergency and non-emergency transports will be taken into consideration.

Dum, Dum, Dum, Da, Dum – Drum roll please.  Charm to the rescue.

See below:

charm4.JPG

So was my vision correct?

In practice:

  • A regular transport is created.   Table 1 is not changed.
  • The transport and CHARM ticket are released for an emergency change.  It is immediately moved to production. (After testing in quality)
  • The regular transport has fields removed from table 1, and the emergency transport object is changed so it no longer requires those fields.
  • The emergency change is moved to production again.
  • The regular change is moved.  Now when the programs are regenerated – the table is generated, and then the program.    The emergency program is generated with errors – so it goes with error – 8, and the regeneration stops.

If the above confuses you.  You are not alone.  It confuses me and my BASIS people.   So the only solution I found was to create a new CHARM ticket with just the table.   Transport it first.  Re-transport the 2 Charm tickets.  They will go into the system clean.

In theory:

All transports are moved to production with the release.

In Practice:

  • Not all transports move to production.
  • The changes are backed out of the object, and the object is changed by the developer.  The developer ignores the conflict and can create the new transport request.
  • At this point the changes can’t be moved without BASIS help.  Why?  Because there is a conflict.

In theory:

Only one developer works on an object at a time.  Or if more than one developer is working on it, then it’s for the same project.

In Practice:

  • There can be more than one developer working on an object.  And yes, it is for two different projects.
  • So there are two options – add the object to the two different CHARM tickets.   Leave the object in the CHARM ticket that has it in it.  Either one will cause one CHARM ticket to be dependent on the other.  It will be a manual task to keep track of that.

In theory:

When a new table is created, all your developer’s will know it is new and won’t use it in their objects.

In Practice:

  • Developer’s miss that the table was created in a different CHARM ticket.   They have no idea on the dependencies.
  • CHARM doesn’t notify of the dependencies.
  • The move to production has errors.

OK – I’m done with the things CHARM doesn’t do well.    There are some things that it does very well.

CHARM is amazing at:

  • Limiting the number of transports.   For a regular CHARM ticket that goes with a release, only the transport task will need released.   When the task is released, it moves in the background to the test system.  If there are problems, then I just create another task.  The transport request is never really moved until the move to production.
  • It is easy to create a configuration transport request and a development transport request.   Since they are both on the same CHARM ticket, they will move to production together.
  • If your CHARM ticket has been released,  and an error is found.  It is easy to create a defect request and attach it to your CHARM ticket.  This will keep the transports together in one CHARM ticket.
  • The test environment is easily locked down when the system is moved to testing.  This will stop everything except for emergency transports from moving to the test client/system.
  • The approval process is at the front end.  A CHARM ticket is not created until the CHARM request is approved.  That means a transport request can’t be created.
  • Outside objects – I’m not sure as we haven’t used CHARM for that yet.

So there you have it, my personal thoughts on CHARM.  Keep in mind, like all SAP products, different companies will have CHARM configured differently.  So some (or none) of what I’ve written may apply to you.

Does CHARM do what it claims to do?  Yes.  Does it do what you think it should?  You be the judge of that.  Personally, I think it does make my job easier.  It’s not a silver bullet.  It doesn’t fix all transport issues.

Please comment with some pros and cons.  And do let me know if I’m losing my mind with some of my comments.  🙂

:

To report this post you need to login first.

12 Comments

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

  1. Amine Lahlou

    Hi Michelle,

    I have some additional inputs that might help you improve your ChaRM experience:

    • CSOL (Cross system object lock) customization allows to define if the conflicts are cross project/project specific, overlapping/ partial overlapping and cross client/client specific, with many combinations.
      So you can modify this parameters in order to suit your organization needs.
      (cf. CSOL- Managing Parallel Projects)
    • In order to keep track about dependent tickets, you can use request for changes as an initial container of all the dependent changes, which is one of the SAP/ITIL best practices.
      Otherwise, you can also use “Related transactions” assignment blocs or a specific field

    I hope my answer was helpful.

    Kind regards,

    Amine

    (0) 
    1. Michelle Crapo Post author

      Hi Amine,

      It’s good morning for me!   Yes, it does help.  CSOL – cross system object lock – it’s something to ask my BASIS team about.

      Dependent tickets – OK so perhaps we don’t follow best practices.  But when you think about it, I as a developer am creating objects that can be used in several different ways – with several other objects or other projects.   I do that to avoid duplicate work, and to keep everything up to date.  So that means my object can be used in several different projects.   So there could be several RFCs that ultimately contain the same object.  As our functional/testing/business side people create RFC they would never know that.   I will check out the related transactions assignment.  

      Thank you for the great information!

      Michelle

      (0) 
      1. Issac Ohasi

        Dear Michelle,

        I would like to add a new input too:

        There’s a functionality in ChaRM (starting on SPS06) called DGP or Downgrade Protection. This is an enhancement in the CSOL Cross System Object Locking feature.

        Downgrade Protection functionalities help you to increase consistency throughout your system landscape by identifying parallel developments on same objects or customizing settings.


        If conflicts are detected, the related transport management activity will be canceled by default. To proceed it is required to specifically tell the system to “ignore” those conflicts.


        So in this case, CSOL will alert conflicts the developer when the customizing/workbench settings will be recorded at a Transport Request. DGP will alert conflicts when the TR will be released and / or when the TR will be imported. This can be a huge input for the ChaRM`s user to avoid a downgrade.


        For more information check the Help SAP Library: http://help.sap.com/saphelp_sm71_sp12/helpdata/en/6a/2347390517468db54e767b122110a1/content.htm?frameset=/en/2b/614e1cb8204f35b477eac703073589/frameset.htm&current_toc=/en/b3/64c33af662c514e10000000a114084/plain.htm&node_id=1337&show_children=false&fullscreen=true


        BR, Issac

        (0) 
        1. Michelle Crapo Post author

          Hi Issac,

          You have just outlined one of the things about Charm that I hate.  Ok – hate is too strong of a word.   That I dislike.

          Yes, that’s the way our CHARM is set up.   And guess what?  We as developer’s are really good at pressing the ignore conflict then green check. 

          Conflicts are so much fun:

          If for some reason a transport is not transported into production.   The Charm ticket is never going to be used.  We’ve backleveled the code, and are working on a different project.   The stupid conflict box comes up.   Then we need help to get it transported to our testing environment.

          If there are times when that object needs to be worked on in two different projects (Charm tickets) – then we have to press ignore conflicts.  Then we work in two different tickets – Probably I’ve gotten done with one project and it is in test but not production yet. The next person needs the object for their project (Charm ticket).  They ignore the conflict. 

          If there is an emergency transport that has made it to production, and I need to change the object for a project that will go with a release.  Guess what?  You’ve got it, another conflict.

          We – as developer’s get really used to ignoring the conflicts.  It is causing more work for our BASIS team as the transports won’t automatically move to our quality (test) environment.

          Have I ranted enough?   I really hate this feature.  It may save us a couple of times when we really can work around it, but for the majority of the time – it’s just annoying.

          Again – remember I am a developer, and don’t claim to know the ins and outs of CHARM.  I just have to have the pain or enjoyment of using it.

          It really was a good thought though in theory.  In practice….  One of my least liked features.

          Have a great day, and thank you for bringing that up!   I’m sure there are other companies that would find it useful.   (And we use it too.  🙂 )

          Michelle

          (0) 
  2. Jansi Rani Murugesan

    Hi Michelle,

    Thanks for sharing your experience on Charm, It is one of the beautiful tool which has such a flexiblity to support different kind of unique scenarios.

    There are plenty of posiblity in Charm, as you mentioned every customers use that in their own way.

    One case, if same object touched by 2 different developers in the same project, Change manager approves for single TR, and normally it appends to the existing TR as new tasks, this way you can control the dependencies.

    other than that, we do have some features like Assign and Decouple of transport request,  in such case, if you know the other dependent transport request in the other change doument, decouple TR from that request, assign to the change document where your other dependent transport assigned. so both the TR imported one step into production.

    or if you do the import via automatic import_all job, all your dependencies and sequencing dependencies taken care.

    or try out Preliminary Import for normal changes where you can keep the change in import buffer,follows import_All ( project import ) and prevents the changes moves out of order wih the urgent change.

    and the whole purpose of CSOL, is the collabration between the team or developers, who is working on what, means I would like to know what are the other people working on my object, so dev A gets popup says that so and so objects been locked in TR by Dev B, he should consult Dev A or administrator to remove the Lock, it is depends on your project requirement out of 12 various locking features, which one you want to setup, if you setup only for warning messages for all the conflicts, ofcourse you end up conflict in production, you should nt, some usecase, you should setup error messages, where no one are allowed to work on until unless the lock been released.

    it is good to know the views and way of working with the various features. 🙂

    Thanks and Best regards,

    Jansi

    (0) 
    1. Michelle Crapo Post author

      Hi Jansi,

      Yes, 2 different projects – under one TR.   That makes things a little hard when trying to promote them to production..   If one is broke and then other isn’t, well it just doesn’t work out well.

      Assign and decouple TRs.   Yes, I have used that as well.  🙂    I’m beginning to think I’ve used a lot of the options.    Again trying to keep all the tickets as a part of one project, and that project is a Charm “ticket”.   It has come in very useful.

      And transporting…   Transporting is a little over my head.   Again that would be something my BASIS team works out.

      I will start to look at all the different features.   Slowly.    Maybe I’ll like Charm even better.

      Thank you for the great comments!

      Michelle

      (0) 
  3. Tom Cenens

    Hi Michelle

    Really glad you’re blogging again, good memories on how blogging changed our lives 🙂 .

    I see this blog post as a big “challenge” sign for others to provide thoughts and come up with (if needed) creative ways to solve this problem you’re experiencing.

    I hope it’s possible to overcome this problem through means of reporting to keep an eye on which changes reside where.

    Did you check out transaction /TMWFLOW/TRMO?

    It can give you a view on what’s going in terms of transport requests, zoomed out let’s say so you see which transport requests are where. So you can compare systems (or clients) and see the delta of transport request imports, you also get errors or sequence errors highlighted in there.

    Best regards

    Tom

    (0) 
    1. Michelle Crapo Post author

      Hi Tom,

      Oh boy – you’ve made me dangerous now.   A little bit of knowledge on my part and I could bring down a system! 

      Really this report is great.  I’m still digging into it.   It looks like it’s going to help me a lot.   I can check it out before they move my transports into production.

      Thank you!

      Michelle

      Nice hearing from you!

      (0) 
      1. Tom Cenens

        Hi Michelle

        You’re most welcome.

        It triggered me this morning, I very much like the blog and the problem you mention.

        Thinking about it some more, there are more features which could be interesting if those are not already in place:

        Selective import and status dependent import could also be interesting  to activate to aid in the import strategy / release:

        New Import Strategy : Selective Import Solman 7.1 – SP10 (How To)

        Some Hints to Status Dependant Import Control

        I’m working on a new CHARM study at the moment so I’m digging through all of this stuff again (we configured CHARM one year ago). We’re (SolMan team on customer side) drinking our own champagne now, using incident & change management for incidents and changes on SolMan.

        We still have to meet so I hope I see you at one of the events this year!

        Best regards

        Tom

        (0) 

Leave a Reply