ALM Coffee Party III – ChaRM, Why? Wherefore? Why ever? – Part 2

The technology behind ChaRM

In the first part, we dealt with general topics. This second part of our summer blog series is all about ChaRM technology.

Technology

Technically speaking, the ChaRM is an alloy consisting of the CRM OneOrderthe Post Processing Framework (PPF), the task plan of the Schedule Manager (SCMA – as the main developer came from HR, he brought along this very popular tool for starting reports) and the Transport Management System (TMS with CTS) with a pinch of SMSY/LMDB and IBase/Configuration Items.

Basic framework

The basic structure has not changed significantly in these fifteen years.

Status-driven workflow

The transport workflow is realized by status changes. The status values are not selected directly via the status field, but are set via PPF actions that use the “method” HF_SET_STATUS when saving.

Which status can be set and when is decided by the so-called “Scheduling/Start Conditions” of the PPF Framework. All these PPF elements work with constant status values, which makes changing the status scheme very laborious.

Up to now, we were still pretty much in the CRM standard. The ChaRM Framework, on the other hand, is specific to ChaRM.

ChaRM Framework

For each status set, there is a list of ChaRM “Actions” and “Consistency checks”, which generate a message in the event of an error and may cancel the status change.

An example: When changing the status of a change document to ToBeTested, the action “CLEAR_EMPTY” is executed first, which removes all empty tasks and transports, then the action “COPY_ALL_ENH” is executed, which copies the parts list of the “real” transport into a freshly created Transport of Copies (ToC), exports it and imports it into the test system. The system checks whether all tasks have been released (a condition) and whether the ToC has been imported into the QA system without errors (a results check).

Initially, there was only a list of actions followed by the consistency checks. However, the latter have a dual character. Some are conditions for actions, others check the result of actions. As a result, many users began to create additional statuses in order to fine-tune them. SAP has therefore introduced the later execution time of actions (i.e. the action is executed after the checks). Finally, the whole thing was rounded off with the later execution time of tests, which can also be used to check the success of the late actions.

The hope that this shaky four-layer structure has been simplified with the new data model for 7.2 (1. Execution condition → 2nd action → 3rd results check) has unfortunately not been fulfilled.

Task list reports

The correct work is carried out by specialized reports, which are all ready to start with the prefix “/TMWFLOW/SCMA_” in the active task list and which are called internally via the function module /TMWFLOW/TASK_START1.

You can see these calls, their parameterization and the runtime messages in the “Application Log” assignment block.

Two ways of working

Since its initial introduction, there have been two ways to live the ChaRM: Project and phase-oriented with the normal change (SDMI/SMMJ) and as a set of individual changes with the hotfix (SDHF/SMHF).

These two working methods differ in the type of import: the former (project) always uses the tp command “IMPORT PROJECT ALL” to import everything that is available for a ChaRM project in the import queue, the latter (hotfix) uses the tp command “IMPORT SUBSET” to import exactly those transports that belong to the hotfix.

As the hotfix removes transports from the correct sequence, they are only imported “in advance” in project and phase orientation, i.e. they continue to wait for the final project import in order to be imported in the correct sequence this time. Unless: you don’t want it because you only think in individual changes (see below) and therefore use the SAP1 variant, which only recognizes final imports, instead of the SAP0 task list variant (hotfix as preliminary import).

Hotfix

Since the hotfix corresponds to the single change mentality (see below), it was very popular, but it was also very expensive, because each hotfix creates its own task list with prefix H, which consists of hundreds of table entries. It was often like fetching the newspaper in a tank. Since the normal change (SMMJ) can turn into an urgent one, you should avoid it and only use it in the test or go-live phase (see below), because it is very dangerous, as it releases the original transport when the status changes to ToBeTested. Don’t let it rot in this state for too long: you quickly risk being downgraded by an overtaker.

Normal change

The normal change, on the other hand, is very convenient and safe. For the functional tests within the document (status ToBeTested), the QA system is only supplied by ToCs (see above), the original transport remains modifiable until the tester gives his OK. The second advantage of ToCs is that they do not fill the import queue of the downstream system with reservations. Only when the tester gives his OK is the real shipment released and imported into the QA system, and thus marked in the delivery system.

If you do not intervene manually in this process, nothing can go wrong.