Workbench erweitern

Workbench erweitern

Hallo,

Ich hoffe ich hab mit SAP Allgemeines das richtige Thema für mein Post gefunden.

zu meinem Problem:

Ich möchte unsere Workbench dahingehend erweitern, dass beim Anlegen verschiedener Objekte (Methoden, Reports, Form-Routinen etc.) automatisch ein Dokumentationskopf im Quellcode eingefügt wird. Das soll dann Beispielsweise folgendermaßen aussehen...

FUNCTION Beispiel.
*"----------------------------------------------------------------------
*"*"Lokale Schnittstelle:
*" IMPORTING
*"
*"----------------------------------------------------------------------
***********************************************************************
* Erstellt am / von: autom. Datum / autom. Benutzername
**Änderungen***********************************************************
* Datum Name Änderung
* 24.04.2008
***********************************************************************
.....

Ich habe auch schon ein wenig geforscht und rausgefunden das man so etwas über WB Actions und WB Objecte realisieren kann. diese werden in den Tabellen WBActions, WBTooltype und WBRegistry gepflegt. Außerdem scheint das Interface IF_WB_Program eine wichtige Rolle zu spielen.

Hat zufällig schon mal jemand versucht seine Workbench auf diese Weise zu Modifizieren oder hat das auf anderem Weg geschafft ohne den Quellcode der WB zu verändern?

Gruß
Roberto

Erst mal vielen Dank.

Das Problem was ich leider bei der Lösung habe ist das $Date und $User leider nicht verarbeitet werden. Bei mir sind die Felder im SAP Code ausgesternt d.h. ich müsst wieder an den SAPcode ran . Ich such also immer noch eine Möglichkeit das ganze z.B. über das Interface IF_WB_PROGRAM mit den Methoden PROCESS_WB_REQUEST und RESTORE_WB_REQUEST zu realisieren und dann mit der BAdI WB_OBJ_CTMENU zu übergeben. Leider reichen wohl meine Progkünste noch nicht aus. Wenn ichs schaffe Post ichs hier (hätte nichts dagegen wenn jemand schneller ist als ich .

Gruß
Roberto

Re: Am Besten bleibenlassen ...

babap hat geschrieben:wozu den ganzen "Sternenhimmel" im Coding unterbringen. Alle Angaben, Wer, Wann, Wo etc. wird von SAP protokolliert......In der Versionsverwaltung kann man sehen, was geändert wurde.

Mit Verlaub, das ist Humbug. In der Versionverwaltung hast du eine Liste von Transportaufträgen. Sicherlich kann man anhand derer auch Änderungen nachvollziehen, aber eben nicht was fachlich dahinter steht. Darum gehört in ein Programm eine Änderungsmarkierung mit einem Kopfkommentar, auf wessen Anweisung (Fachabteilung, steht nicht in der Versionsverwaltung) mit welcher Ticket-ID (steht nicht in der Versionsverwaltung) eine Änderung gemacht wurde und wozu sie fachlich dient.

Ich nehme mal ein Beispiel, direkt aus der Praxis. Ich habe einen Report, der aus dem Jahre 2002 ist. Inzwischen wurde dieser Report 43 mal (!!!) geändert. Mal wurde in die eine Richtung erweitert, mal in die andere. Dann wurde hier eine Routine gestrichen und durch eine andere ersetzt, weil die Prozesse sich geändert haben.

Nun wird ein Fehler gemeldet. Wenn du den einkreisen willst, ist es einfacher, wenn dort anhand der Änderungsmarkierung nachvollziehbar ist, wer bei welcher Änderung und mit welcher Absicht die fehlerhafte Codingstrecke eingesetzt hat.

Bei den Stundensätzen, die ich kenne, möchte ich keinen Entwickler dafür bezahlen, dass er erstmal drei Stunden in der Versionverwaltung rumsucht. Das sind auf einen Schlag ein paar hundert Euro!!!!!

Ich war bei noch KEINEM Kunden (die über Entwickler verfügen), bei dem es keine entsprechende Hausregel zur Markierung von Änderungen gab. Und ich bin seit zehn Jahren bei den unterschiedlichsten Kunden gewesen.

Ich sage gern SCHERZHAFT: Ein Programm dokumentiert sich durch sein Coding. Die Wahrheit ist: Man kann NIE zuviel kommentieren, nur zu wenig oder zu unverständlich.


Ralf *kommentiert jeden nichttrivialen anweisungsblock

Warum ist dein Problem noch nicht gelöst? Die Tabelle wo das drin steht kennst du doch nun.

Ich könnte dir MEINE Lösung präsentieren, aber die willst du nicht lesen.


Ralf

P.S: Falls doch: Meine Lösung dieses Problems besteht aus lokalen Dateien, die ich mir einmal hochlade, wenn ich beim Kunden das erste mal aufschlage. Ich habe zum Beispiel eine für ALV-Listen [1]. Da ist alles schon vorgestrickt - inklusive Events, etc. Alles nur Denkbare ist vorgedacht und muss nur noch mit Leben gefüllt werden. Sind inkl. Ausfüllhinweisen ca 500 Codingzeilen. Ich hab noch eine weitere für Batch-Inputs (die hab ich aber schon ewig nicht mehr gebraucht) und für viele andere Fälle.

Zusätzlich hat jeder Kunde seinen eigenen Kopf mit Änderungshistorie, da kann ich natürlich nicht mit meinem Kram kommen. Da hilft mir dann die Zwischenablage.

[1] Basiert allerdings alles auf dem REUSE-FuBau. Ich hätte gern noch eine objektorientierte Variante dieses Reports, wobei ich kaum Erfahrung damit habe. Die würde mir auch helfen, ABAP-OO besser zu verstehen. Allerdings weiß ich nicht ob ich dann so eine schöne "hochladen und wohlfühlen"-Lösung habe oder ob ich mit so nen Kram bekomme wie bei Funktionsbausteinen, die man ja gar nicht mehr in eine lokale Datei komplett wegsichern kann (Schnittstelle!)