The life of an ABAP development is like many things only temporary. This topic is about phasing out "old" developments, an approach where users are stopped and pointed to the alternative development.

Description

Implementing a project or implementing projects in SAP can involve version change of programs and even phase out the use or programs (classes, methods or function modules). This is part of the normal life-cycle of developments and can be regarded as such. In fact, on larger implementations, it's a good idea to take control over which development supercedes other developments. A simple central administration can be set up do activate and de-activate developments along with a hint pointing to the new version.

This way you can ensure the latest version of software is being used, and when an upgrade is knocking on the door, the development team will know which bits can be ignored (or eventually even removed). 

Goal and objectives

Keep track of developments that should no longer be used. Prevent obsolete developments from being called (which can have a disastrous effect !). Have a mechanism where a development that is no longer being used can still be executed - if necessary. Hint the end user to the solution. Make sure old developments are not processed when a release change takes place ("Is this still being used ?")... Monitor the usage of a development, by logging calls. 

Blue print

A step-plan to implement the grave yard for developments:

1. Set up a transparent table (further referred to as the grave yard table) with the program name as a key (further referred to as the corpse) - however, it's not necessarily the actual program name that needs to be filled in (it could also be used to disable part of a program or e.g. use of a function module). The table should contain main information about the status of the development (active / inactive), when it was last disabled with a reason (1 line text), the alternative program or transaction, or a reference to documentation on the matter (help the end user along), a "last called" date & time (& user) and the user ID that disabled the (grave yard) object. An indicator to state whether actual calls should be logged and another indicator to state there is an alarm on the call. 
2. Build a class with a class method that is called by developments that are disabled. The method simply checks to see if the potential corpse is listed as inactive object. If it is, it will prompt the end user with information about the deactivation.

   zcl_graveyard=>check( ). 

   Or when a check is done against another object (e.g. a function module that goes with a report, or if several reports are part of the same solution/setup)

   zcl_graveyard=>check( 'ZZ_OLD_REPORT' ). 

3. For every development that needs to be deactivated, call the above method, which will leave the program when it should no longer be executed. In fact: this call could be added to all Z-developments by default, so all developments can be "switched off". 
4. Now set up a nice report about inactive and active corpses, listing all information from the grave yard table. Inactive objects can be activated and vice versa. Make sure is also reveals call-logs, which are in fact log files on the server somewhere.
5. The possible statuses on the graveyard table can be:
1. Not monitored (no entry for the program's main program is available);
2. Monitored (the entry is on the graveyard table, status "Monitored", the last 3 visits are recorded (name, date, time) and an overall visitor count is maintained;
3. "Phaseout initiated", the last 3 visits are recorded, the user gets a message every time the report is started (only once in the same session) stating: (free text) "This development will be taken out of commission, please use such and such". Along with contact information (which is also available on the graveyard table);
4. "Phaseout round-off", user is prompted to go elsewhere. However, the user can claim he/she needs the functionality to be available by choosing "I need this". After pressing this button, a bit of comments need to be filled in and the user can continue using the report;
5. "Phaseout blocked", users that pressed "I need this" can continue using it, other users will be prompted to use the alternative;
6. "Phaseout completed", the status "Phaseout round-off" has been available for at least 10 weeks, which is when the phaseout is completed. User will be prompted to go to the alternative, without "I need this" option. 
6. Much like standard SAP, the graveyard definition can have a processing mode which dictates whether the "Monitored" status or "Phaseout round-off" status is skipped, e.g. to take a set of conversion programs to the graveyard after go-live. 

Taking it further...

• Instead of calling a class, for the reports that have to be started via SE38 or SA38, this graveyard functionality could be put in place in a single enhancement point. This way a great part of the system's developments would already be monitored; 
• Elsewhere in Abapcadabra there is an article on sizing the system, which is an excellent candidate to link up to the graveyard administration. This would give insight information on the custom (Z) coding the system has available and which part of that is on the Graveyard monitor (an in which status).
• Set or clear the graveyard statuses via a scheduled program call - which would allow the development or developments to be switched off (or made available: switch on) at a predefined date/time.
• Logging on activation deactivation and program calls. A setting (flag) on the grave yard table should enable/disable the logging of program calls. This can be used to monitor program usage for a while (and determine which users group actually uses it) before the development is disabled (and after it has been disabled of course)

When the above is implemented, the user community will be speaking of "developments on the grave yard"...

Pro's and cons

Success story

Only implemented in much simpler form than described here. Check against a table which enables "switching back on" has proven to be valuable. The setup would have been very helpful in the upgrade projects I've done to date, it's quite difficult to identify which developments are no longer used. As the system grows older, the overall complexity also grows...

• Prev
• Next