ChaRM: How it all began!

Our three-part summer blog series is all about Change Request Management (ChaRM) in SAP Solution Manager.
How did SAP come up with the idea of establishing something like ChaRM in the first place? What is the technology and what is the philosophy behind it? You can find out all about this in my three-part summer blog series.

History

When you dive deep into the past after so many years and look at the documents from the beginning, you are amazed at how much Change Request Management (ChaRM) in SAP Solution Manager has grown over the years. I don’t know of any tool for managing changes that is so powerful and perfectly integrated with others:

• Convenient orchestration of SAP transports
• Extensive checks of transports and their contents (critical transport objects, cross-system locks, downgrade protection, cross-reference checks, etc.)
• Support for dual system landscapes with retrofit and cutover (focused build extensions)
• Powerful search functions, right down to individual transport objects
• Release management with minor and major releases
• Bidirectional integration with SAP project and portfolio management, including aggregated time recording feedback.
• Extensive integration with the Test Suite
• End-to-end traceability
• Integration with the solution documentation
• Integration with incident and problem management
• Integration with job management
• Integration with the System Recommendations
• Integration with the IT calendar

Integration wherever the now moist eye can see 🙂

Gestation period and birth

At the beginning of the noughties, R/3 systems sprang up like mushrooms in our company. Each plant had its own, as did the head office. Managing the transports via STMS became time-consuming. We set up a central TSM system (our first test systemfor SAP SolutionManager, version 2.2) to distribute the transports with the TMS Transport Workflow. But we also wanted to introduce TMS QA Approval. But the TMS workflow ignored the QA. A message to SAP only resulted in the creation of a note with which SAP declares: That’s just the way it is, bang!

I dutifully submitted an extension request to SAP. At the beginning of 2004, Michael D. (SAP) announced his visit to present his “Venice” project. Motto: Everything is available to develop a change management tool (cProject, Solution Manager for Implementation, Transport Management System, SMSY), you just have to combine them.

We became pilot customers.

This was the birth of ChaRM, which was first delivered as the TMWFLOW add-on to Solution Manager 3.2 and therefore had its own, more frequently rolled out support packages. With Solution Manager 4.0, it became part of ST.

Overview

Instead of slaying everything with a single monster transaction, the ChaRM consists of individual specialized CRM “transaction types” identified by four letters.

Amendment

A change starts with a change request (old SDCR, now SMCR), either by creating a new document or as a follow-up document to a problem; it is the place of business clarification, and its approval initially created exactly one change document as a child document, which was used to control the technical changes (transports); it was not until 7.1 that it became possible to create several change documents for one request.

With release management, the business requirement (SMBR) was added; it offers the business the opportunity to evaluate a requirement internally (does it fit into our strategy? Is the budget available?) and approve it before it is handed over to IT.

The IT requirement (SMIR) is created as a follow-up document; only when the change manager approves this are change documents created as with the analogous SMCR.

Change documents

The initial four amendment documents have now become seven. Here is an annotated list (the original ones in brackets):

• (SDMI) SMMJ: normal correction, may turn into an urgent one with pre-import.
• (SDHF) SMHF: urgent change (aka hotfix), initially very popular, but today it should only be used in exceptional cases where a correction is rushing towards production as if with sirens and blue lights.
• (SDAD) SMAD: administrative change, without transports, is used for audit-proof documentation of changes to the systems of a transport track, e.g. client opening.
• (SDMT) SMTM: Test message, used for error correction during testing (see below).
• SMCG: generic change; is completely detached from the transport system and is used for ITIL-compliant documentation of changes to configuration items (CI) or for the release of SolDoc elements under Change Control.
• SMSG: Standard change; with this, a key user or business expert can make changes to the productive system without external help, which are their responsibility but for which the transport connection is mandatory (examples: a logistician changes modes of transport, a purchaser creates new supplier groups)
• SMGH: Git-enabled change. The latest addition to the family. Used to control the gCTS via ChaRM, which was introduced with SAP S/4HANA 1909.

Problems

As with every birth, there were afterpains. Would you have expected anything else?

Asynchronous export

ChaRM has been struggling with a problem from the very beginning, namely that the export of a transport by the operating system program tp is basically asynchronous.

This doesn’t hurt so much in SE09, because an export immediately releases the session again, and instead of always pressing the “Refresh” button, you can simply do something else.

The ChaRM, on the other hand, freezes the session and shows a nice animated GIF (the hourglass of the SAP Gui has become the donut of death of the CRM WebUI). By default, the ChaRM waits 120 seconds for the end of the export, but you can use the user parameter CHECK_NTIMES_SOCM to increase this default 24 times 5-second wait units. If you set the parameter with transaction SU3 to 50, for example, the ChaRM would wait a maximum of 250 seconds for the end of the export process.

Error absconditus

Perhaps the biggest annoyance in ChaRM was (and sometimes still is) that ChaRM is a rather mute waiter who simply does not communicate the problems from the transportation kitchen (CTS) directly to the customer, who can therefore despair at the dull message “Status could not be set”. This is because the real error message from the CTS is hidden deep in the task list monitor or in the application log (SLG1).

Here is the compassionate example of a colleague who – perhaps because he is very experienced – tried very stubbornly to set the status change to “ToBeTested” with implicit transport release.

After the old warhorse’s soul was boiling with curses, he finally turned to the ChaRM expert. This then navigated to the task list via an action and – after several double-clicks – brought the banal error message “Request/task C11K9A043A is not completely locked” to light.

This path to the real CTS error message was documented, but what developer reads documentation?

Even today, with SolMan 7.2, users still find it difficult to track down the transport errors in the “Application Log” assignment block, which are still quite well hidden.

CHARM, we need to talk

The two winds blowing on Aphrodite in the first picture are Gerhard B. from Nordmilch AG and yours truly, who are blowing on ChaRM.

At a meeting of the DSAG AG Solution Managers, we quickly agreed on the existing gaps and founded the “Error Logging” Workforce Group in September 2007, which we renamed the “ChaRM Ergonomics and Stability” Workforce in December 2007 – the name says it all.

We collected many customer-specific developments as a list of requirements and presented them to Mr. Matthias M. (SAP) at the DSAG Technology Days in Dresden in February 2008.

The list has probably disappeared into a drawer in St. Leon-Rot, because nothing has happened. Only with Solution Manager 7.1 and 7.2 were there finally substantial improvements.

But at least it was the beginning of years of commitment within DSAG to help improve ChaRM (and also the Test Workbench).

In the second part of the blog series, we take a closer look under the hood of the ChaRM.