Nicht mehr verwendete Repositoryobjekte

Re: Nicht mehr verwendete Repositoryobjekte

chrizz9988 hat geschrieben:Hallo zusammen,
mich beschäftigt hier eine Frage bezüglich nicht mehr verwendeter RepositoryObjekte. Eigentlich(!) müsste es doch in jedem Unternehmen mit Eigenentwicklungen genügend kundeneigener Tabellen, Funktionsbausteine, Reports, Klassen, etc. geben, die kein Mensch mehr verwendet.

Bei Quelltexten gehe ich (bei seit mehreren Jahren betriebenen SAP-Systemen) von mindestens 30 bis deutlich über 50% obsoletem Code aus.
Für Systeme, die seit mehr als 10 Jahren produktiv genutzt werden, wahrscheinlich eher mehr als 50%.

Frage: Fallen Euch noch mehr Nachteile ein? Oder sind einige der o.g. Nachteile aus Eurer Sicht gar nicht so schlimm? Weiß jemand von Euch was die SAP dahingehend empfiehlt? (evtl. gibt es aus Walldorf sogar die Empfehlung das System dahingehend aus den Gründen x, y, z "sauber" zu halten)

So ungefähr passt das schon mit den Nachteilen.
Insbesondere bei Unicode-Umstellungen kommt noch hinzu, dass gerade die Altlasten aus dem vorigen Jahrtausend (Migrationsprogramme aus der SAP-Einführung) u.U. überproportional viele Unicode-Fehler und -Warnungen enthalten.
Zum einen gibt es jede Menge OPEN-DATASET-Anweisungen aus Zeiten, in denen es die ENCODING-Zusätze noch gar nicht gab. Außerdem findet man auch häufiger untypisierte Schnittstellenparameter in FORM-Routinen, untypisierte FIELD-SYMBOLS, sonstige inzwischen obsolete Anweisungen... Und diejenigen, die das mal verbrochen haben, sind bei so altem Code noch schwerer "haftbar" zu machen als bei halbwegs aktuellem Code.

Nicht alle Verwendungen finden sich aber im Verwendungsnachweis. Zum Beispiel gibt es auch Customizing-Tabellen, in denen Funktionsbausteine eingetragen sind. (Wenn man Pech hat, sind noch nicht mal die Tabellenfelder entsprechend typisiert. Ich habe auch schon Felder mit Bezug auf TEXT60 gesehen, die dann u.a. Funktionsbausteinnamen enthielten.)
Oder ein Quelltext dient nur als Vorlage und wird von einem anderen Programm mit READ REPORT eingelesen, um dann Anpassungen vorzunehmen und daraus mit GENERATE SUBROUTINE POOL den tatsächlich auszuführenden Code zu generieren.
Insofern ist das Identifizieren obsoleten Codes nicht ganz trivial.

Ich würde gern wissen, wie Ihr mit der Problematik umgeht. Es gibt da ja verschiedene Möglichkeiten:

• Es ist egal, denn Entwicklungsobjekte die nicht mehr verwendet werden, stören ja eigentlich nicht

Na ja, entweder man ignoriert sie (führt zu Problemen, wenn man sich über die Benutzung getäuscht hat) oder man verschwendet unnötigen Aufwand. Und selbst das Ignorieren kostet ja einen gewissen Aufwand. Denn erst mal erscheinen die Objekte ja im Verwendungsnachweis, und man muss darüber nachdenken (oder jemanden fragen), ob das nun noch benöigt wird oder nicht.

• Die Organisation ist so gut, dass z.B. Einmalprogramme sofort nach Verwendung gelöscht werden, bzw. dass auf Grund guter Dokumentation immer klar ist, welche Entwicklungsobjekte noch verwendet werden und welche nicht

Dann steckt man aber zumindest den organisatorischen Overhead (Unterschriften für Transportformulare o.ä.) in die Bereinigung.
Und während man für die Lösung eines den Fachbereich betreffenden Problems (Einmalprogramm bereinigt aufgetretene Daten-Inkonsistenzen, nachdem die eigentliche Ursache erkannt und behoben wurde) relativ leicht eine Unterschrift bekommt, wird das schon schwieriger, wenn der einzige Grund ist, dass die Entwickler den zukünftigen Wartungsaufwand um einen vernachlässigbaren Bruchteil des Gesamtaufwands reduzieren möchten.

Außerdem würde ich beim Löschen von Objekten mit Sicherheit nicht auf die Aktualität der vorhandenen Dokumentation vertrauen. Denn dann bleiben etliche Objekte im System, die kein Mensch mehr braucht, und andere Objekte werden gelöscht, obwohl sie noch gebraucht werden.

• Es gibt ein Auswertungprogramm, dass euch diese Objekte regelmäßig auflistet - anschließend werden sie gelöscht/stillgelegt

Das ist nicht wirklich praktikabel.
Zum einen versenkst Du da regelmäßig Aufwand. Irgendwer muss die Liste ja prüfen. Und von einer Woche zur nächsten dürfte sich nicht so viel ändern, dass man sofort wieder aktiv werden muss.

Frage: Was fallen Euch noch für Möglichkeiten ein, die Problematik zu lösen?

Ich würde in jedem Fall die Finger davon lassen, nicht mehr verwendete Tabellen zu löschen.
Denn während man andere Objekte relativ leicht z.B. über die Versionshistorie oder aus einem Transportauftrag wieder herstellen kann, sollte später mal jemandem einfallen, dass ein Objekt doch noch gebraucht wird, reicht die wieder hergestellte Tabellendefinition nicht aus, die Daten sind weg.
Dass ein Objekt mehrere Jahre lang nicht gebraucht wurde, dann aber doch wieder gebraucht wird, kann gut vorkommen.
Fall 1:
EIn Objekt wird nur gebraucht, wenn jemand für ein bestimmtes Dynprofeld die F4-Hilfe drückt.
Vor kurzem ist ein Mitarbeiter ausgeschieden, ein anderer arbeitet sich neu ein und braucht ausgerechnet diese F4-Hilfe.
Fall 2:
Ein Objekt wir nur in einem bestimmten Step eines Batch-Jobs einer Jobkette in der Jahresendverarbeitung gebraucht, und auch nur dann, wenn zu diesem Zeitpunkt eine bestimmte Datenkonstellation auftritt, die durchschnittlich nur alle drei Jahre mal vorkommt.
Du darfst Dir selbst ausrechnen, wie wahrscheinlich es ist, dass der fragliche Code in den letzten Jahren mal getestet wurde.
Und was für Konsequenzen es hat, wenn der gelöschte Code dann plötzlich doch gebraucht wird.

Rechtzeitig vor absehbaren umfangreichen Änderungen, z.B. Unicode-Umstellung, Releasewechsel, das ist sicher der beste Zeitpunkt, zu dem man so etwas machen sollte. Da kann man am ehesten argumentieren, dass der Aufwand an anderer Stelle sofort eingespart wird. Gegebenenfalls auch, dass das Einsparpotential auch für nachfolgende Releasewechsel o.ä. noch gegeben ist. Wenn das Risiko gescheut wird, die Objekte ohne umfangreiche fachliche Tests zu löschen, kann man das auch zeitlich so planen, dass man erst löscht, dann den Upgrade macht, und dann die Tests plant.
Nur sollte man dann nicht versehentlich zu viele Objekte als obsolet eingestuft und gelöscht haben, sonst gerät der Zeitplan mächtig durcheinander.

Ich habe solche Aufräum-Aktionen schon mehrfach gemacht (und nebenher noch andere potentielle Risiken wie z.T. Jahre alte Abweichungen von Kundenobjekten zwsichen Entwicklungssystem und Produktivsystem bereinigt).

Ken Thompson hat ja mal gesagt: "One of my most productive days was throwing away 1,000 lines of code."
Ich habe mal an nicht einmal einem Tag ca. 1,2 Millionen Zeilen Quelltext von insgesamt ca. 2 Millionen Zeilen Quelltext im Kundennamensraum aus dem produktiven SAP-System eines Kunden gelöscht (und den auch nicht mehr im Entwicklungssystem benötigten Code natürlich auch im Entwicklungssystem gelöscht.)

Der Kunde war von meinem Herangehen so überzeugt, dass er sich darauf eingelassen hat, der Löschung ohne vorherigen Fachbereichstest zuzustimmen.
Und im Produktivsystem hat auch kein Anwender etwas davon gemerkt, dass der Code dann weg war.
(Im Testsystem habe ich ein paar Wochen vorher aus Versehen den Fehler gemacht, etliche Quelltexte zu löschen, die erst in den letzen Monaten ins Testsystem importiert worden waren und dort deshalb noch nicht benutzt worden sind, weil die Entwicklung noch nicht abgeschlossen war. Das war dann eine prima Gelegenheit, zu beweisen, dass die Wiederherstellung der versehentlich gelöschten Objekte wie vorgesehen funktioniert hat und mit minimalem Aufwand erledigt war.)

Von den tausenden gelöschten Quellltexten wurden in den Jahren danach drei Reports im Entwicklungs- und im Testsystem wieder gebraucht. Im Produktivsystem wurde kein einziger gelöschter Quelltext mehr gebraucht.

Der Gesamtaufwand war deutlich geringer als der Aufwand, der für die anschließend stattfindende Unicode-Anpassung nötig gewesen wäre.
Glücklicherweise musste ich nicht sämtliche Dokumentationen nach den gelöschten Reports, Funktionsbausteinen und Transaktionscodes durchsuchen, sondern es reichte aus, die gelöschten Objekte in einer Dokumentation zu erfassen, so dass bei der Suche nach einem Reportnamen neben dem Dokument, das diesen Report bzw. Funktionsbaustein erwähnt, auch das Dokument gefunden wird, das die Löschung beschreibt.

Wenn man die Systemlandschaft einmal entsprechend aufgeräumt hat, dauert es aber normalerweise wieder eine Weile, bis die nächste Aufräum-Aktion lohnt.
Die Wiederholung wird dann fast schon zur Routine, auch weil die Tools, die der SAP-Standard nicht hergibt, schon entwickelt sind und allenfalls ans aktuelle SAP-Basis-Release angepasst werden müssen.

Frank

Re: Nicht mehr verwendete Repositoryobjekte

Ja, so etwas hilft natürlich, wenn man noch Zweifel hat und sicher sein möchte... So fängt man auch externe PERFORMs sicher ab...