CHARM - A Developer's Point of View - in other wor...

Former Member · ‎01-02-2015

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:

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. :smile:

: