Umbenennen in Massen
11 Beiträge
•
Seite 1 von 1
11 Beiträge
Seite 1 von 1
Hallo,
In naher Zukunft müssen wir unsere ganzen Objekte (Programme, Tabellen, ...) umbenennen (neuer Namensraum).
Da das seher zeitaufwendig ist, habe ich die Frage, ob man irgendwie ein Programm schreiben kann, das dann diese Arbeit für einen übernimmt.
Dann müsste das Programm aber natürlich noch in jedem Programm die Vorkommen der Objekte ebenso umbenennen.
MfG
Kai Dräger
In naher Zukunft müssen wir unsere ganzen Objekte (Programme, Tabellen, ...) umbenennen (neuer Namensraum).
Da das seher zeitaufwendig ist, habe ich die Frage, ob man irgendwie ein Programm schreiben kann, das dann diese Arbeit für einen übernimmt.
Dann müsste das Programm aber natürlich noch in jedem Programm die Vorkommen der Objekte ebenso umbenennen.
MfG
Kai Dräger
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
SAP stellt einen Service zur Verfügung, mit dem sich genau das machen läßt. Da solltest Du aber direkt bei SAP nachfragen. Ein Tool im Standard gibt es dazu nicht.
Schreiben kann man selbst sowas auch, das wird aber sicherlich zeitaufwendiger sein. Es muß erstmal überprüft werden, wo alle Objekte verwendet werden, dann muß überall dort, wo umbenannte Objekte verwendet werden auch die Verwendungen geändert werden. Dafür mußt Du den Sourcecode parsen. Das so zu realisieren, das alles berücksichtigt wird und zudem fehlerfrei ersetzt wird, ist ein ziemlicher Aufwand. Um die Verwendungen herauszufinden, hilft Dir vielleicht die Transaktion 'DECO' weiter.
Schreiben kann man selbst sowas auch, das wird aber sicherlich zeitaufwendiger sein. Es muß erstmal überprüft werden, wo alle Objekte verwendet werden, dann muß überall dort, wo umbenannte Objekte verwendet werden auch die Verwendungen geändert werden. Dafür mußt Du den Sourcecode parsen. Das so zu realisieren, das alles berücksichtigt wird und zudem fehlerfrei ersetzt wird, ist ein ziemlicher Aufwand. Um die Verwendungen herauszufinden, hilft Dir vielleicht die Transaktion 'DECO' weiter.
Beitrag
von Frank Dittrich (Expert / 674 / 0 /
15
)
»
Aus dem Kundennamensraum in einen bei SAP reservierten Namensraum /.../, nehme ich an.Kaiwalker hat geschrieben:In naher Zukunft müssen wir unsere ganzen Objekte (Programme, Tabellen, ...) umbenennen (neuer Namensraum).
OSS-Hinweis 104010 und verwandte Hinweise kennst Du?
Wann ist "in naher Zukunft"?
In welchem Release soll die Umstellung erfolgen?
(Du hast mal was von 4.6C geschrieben, und der Wechsel auf 4.7 und damit Basis-Release 6.x steht bevor oder ist in Arbeit.)
Wer ist "wir"? D.h., sind die bisher im Kundennamensraum entwickelten Objekte auch an andere Kunden ausgeliefert worden?
Wenn ja, wie viele etwa, welche Releases haben die Kunden im Einsatz, wann planen die einen Releasewechsel?
Wie viele verschiedene Produktive Systeme gibt es insgesamt, in denen das bisher im Kundennamensraum entwickelte AddOn eingesetzt wird?
Gibt es für verschiedene Releases unterschiedliche Versionen, oder sind die von Euch entwickelten Programme ... release-unabhängig?
Könnt Ihr die umzustellenden Objekte anhand von Originalsystem / Entwicklungsklassen (bzw. Transportschicht der Entwicklungsklassen) eindeutig von nicht unzustellenden Objekten abgrenzen?
In wie vielen verschiedenen Systemen erfolgt die Entwicklung?
Mit welchem Release sind die ersten Objekte entstanden, die jetzt umgestellt werden sollen?
(Damit lässt sich abschätzen, in welchem Maße man sich bei der Namensraum-Umstellung noch mit Altlasten herumschlagen muss.)
Um überhaupt sinnvolle Aussagen machen zu können, braucht man außerdem mindestens noch ein Mengengerüst.
Poste doch mal die Liste, die folgender Q&D-Report erzeugt:
Code: Alles auswählen.
REPORT z.
TABLES: tadir, tdevc.
DATA: cnt TYPE i.
DATA: cnt_total TYPE i.
SELECT-OPTIONS: s_devl FOR tdevc-pdevclass,
s_devc FOR tadir-devclass,
s_system FOR tadir-srcsystem DEFAULT sy-sysid.
IF s_devc[] IS INITIAL AND NOT s_devl[] IS INITIAL.
SELECT devclass AS low
FROM tdevc
INTO CORRESPONDING FIELDS OF TABLE s_devc
WHERE pdevclass IN s_devl.
CHECK sy-subrc IS INITIAL.
s_devc(3) = 'IEQ'.
MODIFY s_devc TRANSPORTING sign option
WHERE sign NE s_devc-sign.
ENDIF.
FORMAT RESET.
SELECT object COUNT(*) FROM tadir
INTO (tadir-object, cnt)
WHERE devclass IN s_devc AND
srcsystem IN s_system
GROUP BY object.
WRITE: / tadir-object, cnt.
ADD cnt TO cnt_total.
ENDSELECT.
ULINE.
WRITE: AT /(4) sy-dbcnt NO-SIGN,
cnt_total UNDER cnt INTENSIFIED.
Das ist erst ein minimaler Bruchteil des Gesamt-Aufwands.Da das seher zeitaufwendig ist, habe ich die Frage, ob man irgendwie ein Programm schreiben kann, das dann diese Arbeit für einen übernimmt.
Dann müsste das Programm aber natürlich noch in jedem Programm die Vorkommen der Objekte ebenso umbenennen.
Ich habe 2002 zu 4.6B eine Namensraum-Umstellung gemacht.
Insgesamt mehr als 10000 TADIR-Objekte (also noch nicht mal die einzelnen Dynpros, FUGR-Includes, FBs ... gezählt) aus mehr als 40 verschiedenen Objektarten.
-mehr als 1200 Tabellen und DDIC-Strukturen
(davon ca. 800 DB-Tabellen)
-ca. 4000 Programme, Includes und Functions mit insgesamt etwa 1.000.000 Quelltext-Zeilen.
-ca. 1500 Dynpros (ohne Selectionsbilder) mit insgesamt 35.000 Feldern und 40.000 Zeilen Ablauflogik
-2.500 Dokumentationen (Programme, Message-Langtexte, Datenelement-Doku, ...)
Was wir automatisch umgestellt haben (fast alles) und wo nur Listen erzeugt wurden, die manuell abzuarbeiten waren, haben wir u.a. anhand des Mengengerüsts entschieden.
Zusätzlich haben wir entsprechende Tools an die anderen Anwender des AddOns ausgeliefert, damit die ihre darauf aufbauenden Eigenentwicklungen mit möglichst wenig Aufwand umstellen konnten.
Dass es Tools von SAP gibt, wäre mir neu.
Ein Hinweis darauf war damals nirgends zu finden.
Und die vielen SAP-Standard-Fehler, die im Zusammenhang mit dem neuen Namensraum bzw. im Zuge der Umstellung gefunden wurden, deuten auch eher darauf hin, dass vor 2002 noch niemand eine Namensraum-Umstellung versucht hat.
Und im März (2004) var ich zu einem Vortrag auf dem Treffen des DSAG-Arbeitskreises Development Workbench.
Von den anwesenden SAP-Leuten hat sich niemand gemeldet und gesagt: "Aber wozu denn der Aufwand, da gibt es doch auch von uns Tools."
Unsere zu 4.6B erstellten Tools sollten eigentlich größtenteils auch zu 4.6C noch funktionieren. Mit 6.x sind vermutlich ein paar mehr Anpassungen nötig.
der Vortrag hatte mir gezeigt, dass man sich das gut überlegen sollte - ich bin gottfroh, dass wir keine Umstellung in unseren Namensraum durchgeführt haben, sondern alte Entwicklungen einfach auslaufen liessen.Frank Dittrich hat geschrieben: Und im März (2004) var ich zu einem Vortrag auf dem Treffen des DSAG-Arbeitskreises Development Workbench.
Von den anwesenden SAP-Leuten hat sich niemand gemeldet und gesagt: "Aber wozu denn der Aufwand, da gibt es doch auch von uns Tools."
Unsere zu 4.6B erstellten Tools sollten eigentlich größtenteils auch zu 4.6C noch funktionieren. Mit 6.x sind vermutlich ein paar mehr Anpassungen nötig.
Christian
Genau so war das gemeint.Aus dem Kundennamensraum in einen bei SAP reservierten Namensraum /.../, nehme ich an.
Diese Hinweise sind mir leider unbekannt.OSS-Hinweis 104010 und verwandte Hinweise kennst Du?
Nahe Zukunft heißt Anfang NovemberWann ist "in naher Zukunft"?
Die Umstellung soll in Release 4.7 erfolgen.In welchem Release soll die Umstellung erfolgen?
(Du hast mal was von 4.6C geschrieben, und der Wechsel auf 4.7 und damit Basis-Release 6.x steht bevor oder ist in Arbeit.)
Das Problem mit dem Transportieren der Programme war ja gelöst.
Wir heißt wir Anwendungsentwickler in der Firma.Wer ist "wir"?
Das ist der Fall.D.h., sind die bisher im Kundennamensraum entwickelten Objekte auch an andere Kunden ausgeliefert worden?
Erstmal soll nur ein Kunde umgestellt werden und das zum oben genannten Termin.Wenn ja, wie viele etwa, welche Releases haben die Kunden im Einsatz, wann planen die einen Releasewechsel?
Es gibt diverse Produktive Systeme.Wie viele verschiedene Produktive Systeme gibt es insgesamt, in denen das bisher im Kundennamensraum entwickelte AddOn eingesetzt wird?
Nur ab 4.7 mussten geringfügig Änderungen gemacht werden.Gibt es für verschiedene Releases unterschiedliche Versionen, oder sind die von Euch entwickelten Programme ... release-unabhängig?
Die Objekte können alle anhand des Namens ermittelt werden.Könnt Ihr die umzustellenden Objekte anhand von Originalsystem / Entwicklungsklassen (bzw. Transportschicht der Entwicklungsklassen) eindeutig von nicht unzustellenden Objekten abgrenzen?
Ein Entwicklungssystem für 4.6c und eines für 4.7.In wie vielen verschiedenen Systemen erfolgt die Entwicklung?
Das kann ich leider nicht beantworten, weil ich nicht seit Anfang an dabei war.Mit welchem Release sind die ersten Objekte entstanden, die jetzt umgestellt werden sollen?
(Damit lässt sich abschätzen, in welchem Maße man sich bei der Namensraum-Umstellung noch mit Altlasten herumschlagen muss.)
Aber so weit ich weiß sind es kaum Programme die vor Release 4.6c entwickelt wurden.
Um überhaupt sinnvolle Aussagen machen zu können, braucht man außerdem mindestens noch ein Mengengerüst.
Poste doch mal die Liste, die folgender Q&D-Report erzeugt:
Das Ergebnis des Reports ist:
Code: Alles auswählen.
CLAS 2
CMOD 3
CUS0 88
CUS1 86
DEVC 1
DOCV 1
DOMA 43
DSYO 1
DSYS 112
DTEL 195
FORM 12
FUGR 12
PROG 271
SCVI 233
SHI5 1
SHLP 20
SOBJ 2
SPLO 1
SSFO 5
STVI 38
SXCI 1
TABL 123
TOBJ 62
TRAN 299
VCLS 1
VKOI 3
VKOS 3
27 1.619 Was für Tools wären das ? Wäre es möglich den Quelltext dieser Tools zu posten ?Zusätzlich haben wir entsprechende Tools an die anderen Anwender des AddOns ausgeliefert, damit die ihre darauf aufbauenden Eigenentwicklungen mit möglichst wenig Aufwand umstellen konnten.
Inzwischen soll es (angeblich) ein Tool von SAP geben, das das o.g. verwirklicht.Dass es Tools von SAP gibt, wäre mir neu.
Ein Hinweis darauf war damals nirgends zu finden.
Und die vielen SAP-Standard-Fehler, die im Zusammenhang mit dem neuen Namensraum bzw. im Zuge der Umstellung gefunden wurden, deuten auch eher darauf hin, dass vor 2002 noch niemand eine Namensraum-Umstellung versucht hat.
Beitrag
von Frank Dittrich (Expert / 674 / 0 /
15
)
»
Wenn man die Wahl hat.Anonymous hat geschrieben:der Vortrag hatte mir gezeigt, dass man sich das gut überlegen sollte - ich bin gottfroh, dass wir keine Umstellung in unseren Namensraum durchgeführt haben, sondern alte Entwicklungen einfach auslaufen liessen.
Christian
Solange man nicht AddOns an neue Kunden ausliefern will, die schon seit längerer Zeit SAP im Einsatz haben (mit der dazugehörenden Menge von Objekten im Kundennamensraum), geht das.
Verteilte Entwicklungen im Kundennamensraum lassen sich bei entsprechender Planung auch per TRESN organisieren, nur für Funktionsbausteine klappt das Verfahren nicht (auch so ein Entwicklungsantrag, den ich vor Jahren mal gestellt habe, der aber nie umgesetzt wurde).
Selbst bei Fusionen, Übernahmen, ... ist die Bereinigung von Namenskollisionen in Eigenentwicklungen bestimmt nur ein geringfügiges Problem im Vergleich zum Gesamtaufwand.
Aber sobald man ein AddOn an einen größeren Kundenkreis ausliefern möchte, hat man langfristig keine andere Wahl.
Und je länger man wartet, desto größer ist die Kundenbasis, desto mehr Verwendungen der AddOn-Objekte in den Eigenentwicklungen der Kunden ... gibt es.
Und mit zunehmender Anzahl der beim Kunden entwickelten (oder von sonstigen Dritt-Anbietern erstellten) Objekten im Kundennamensraum steigt die Wahrscheinlichkeit von Namens-Kollisionen.
Bei Objekten von Dritt-Anbietern (also mit abweichendem Originalsystem) warnt noch nicht mal ein Test-Import vor dem Überschreiben von Originalen.
Viel Spaß, wenn der Kunde ein Datenelement YXXX mit Bezug auf Domäne TEXT60 hat, das in mehreren DB-Tabellen verwendet wird, und der AddOn-Import überschreibt das Datenelement mit einem, das sich auf CHAR1 bezieht.
Oder im AddOn-Transport ist ein Datenelement YZZZ enthalten.
Genauso heißt eine beim Kunden verwendete DB-Tabelle:
keine Warnung beim Import, auch wenn die Tabelle im Zielsystem Original ist.
Dafür kennt die SE11 anschließend die Tabelle YZZZ nicht mehr, und alle Programme, die die Tabelle YZZZ verwenden, haben plötzlich Syntaxfehler.
Auch das Step-by-Step-Umsetzen eines AddOns aus dem Kundennamensraum in einen reservierten Namensraum (mit jedem "Release" werden weitere Objekte, die bisher im Kundennamensraum lagen, im neuen Namensraum ausgeliefert) verursacht jede Menge Ärger, jedenfalls beim AddOn-Anwender.
Beitrag
von Frank Dittrich (Expert / 674 / 0 /
15
)
»
Das konntest Du ja inzwischen ändern ;)Kaiwalker hat geschrieben:Genau so war das gemeint.Aus dem Kundennamensraum in einen bei SAP reservierten Namensraum /.../, nehme ich an.
Diese Hinweise sind mir leider unbekannt.OSS-Hinweis 104010 und verwandte Hinweise kennst Du?
Warum Ihr nicht einfach im Entwicklungssystem einen Upgrade auf 4.7 gemacht habt, leuchtet mir zwar nicht auf Anhieb ein, aber vermutlich gab es Gründe dafür.Die Umstellung soll in Release 4.7 erfolgen.In welchem Release soll die Umstellung erfolgen?
(Du hast mal was von 4.6C geschrieben, und der Wechsel auf 4.7 und damit Basis-Release 6.x steht bevor oder ist in Arbeit.)
Das Problem mit dem Transportieren der Programme war ja gelöst.
Das verstehe ich nicht.Erstmal soll nur ein Kunde umgestellt werden und das zum oben genannten Termin.
In Eurem Entwicklungssystem bleiben die Objekte im Kundennamensraum, aber bei einem Kunden (der bisher die im Kundennamensraum liegenden Objekte nutzt?) soll die Umstellung erfolgen?
Wie soll denn das funktionieren?
(Dass nicht alle Kunden zeitgleich unstellen, leuchtet ein.
Insofern braucht man wohl einen Übergangszeitraum, indem man sowohl den alten als auch den neuen Namensraum supporten muss - übrigens ein weiterer Grund, warum "Umbenennen" der Objekte keine so gute Idee ist; andere Gründe erwähne ich evtl. weiter unten noch.)
Und welche Releases haben Eure Kunden in Einsatz, wann planen sie Release-Wechsel?Es gibt diverse Produktive Systeme.
Dann bleibt Euch einiges erspart, einige wenige von mehreren Beispielen, an die ich mich noch erinnere:so weit ich weiß sind es kaum Programme die vor Release 4.6c entwickelt wurden.Mit welchem Release sind die ersten Objekte entstanden, die jetzt umgestellt werden sollen?
-FB-Schnittstellen mit gleichnamigen IMPORTING- und EXPORTING-Parametern (CHANGING gab es zu 2.x noch nicht, und die Development Workbench mag es (ohne Modifikation) gar nicht, wenn man versucht, die Typisierung zu ändern
-Feldnamen in DB-Tabellen, die in früheren Releases erlaubt waren, aber im aktuellen Release nicht mehr zugelassen sind
-Klassifizierungs-Matchcodes (die FBs werden auch in den beim Releasewechsel nach 4.x daraus erzeugten Suchhilfen aufgerufen)
-bei der Generierung von Tabellenpflege-Dialogen (für SM30) waren früher z.B. Dynpro-Nummern 1000 und 1010 erlaubt, spätestens seit 4.6B nicht mehr
Da hast Du wohl recht.Auch bei dieser Menge ist es eine Arbeit die Objekte umzustellen.
Dass Ihr ohne Nummernkreis-Objekte und SET/GET-Parameter-IDs auskommt, kann ja sein.
Aber auch ohne Änderungsbeleg-Objekte?
Sind Eure Tabellen alles Customizing-Tabellen?
Oder protokolliert ihr auch für größere Tabellen mit Stamm- und Bewegungsdaten die Tabellenänderungen per DBTABLOG?
Tools für Prüfungen, welche eigenentwickelten Objekte beim Kunden angepasst werden müssen, weil sie sich auf AddOn-Objekte beziehen.Was für Tools wären das ?Zusätzlich haben wir entsprechende Tools an die anderen Anwender des AddOns ausgeliefert, damit die ihre darauf aufbauenden Eigenentwicklungen mit möglichst wenig Aufwand umstellen konnten.
Tools zum Anpassen der eigenentwickelten Objekte (viele Ähnlichkeiten mit den im AddOn-Entwicklungssystem genutzten Tools, z.B. für Quelltext-Analyse und -Anpassung)
Teilweise aber Änderungen, weil das AddOn in den neuen Namensraum kopiert wurde und dann die Kopien angepasst wurden, während die Objekte in den Kundensystemen direkt angepasst wurden. Da gab es also Unterschiede bzgl. Aufnahme in einen TA ...)
Tools zum
-Kopieren der Tabelleninhalte
-Anpassen der kopierten Tabelleneinträge (da wo in den Customizing-Tabellen Felder mit Bezug auf Objekte der Development Workbench vorkamen)
-Anpassen Benutzerstämme (SET/GET-Parameter, Favoritenliste, ...)
-Anpassen SAPoffice-Inbox ("Workflow")
-Anpassen von Änderungsbelegen
-Umsetzen der Tabellenänderungshistorie
-Kopieren von Report-Varianten, ALV-Listvarianten, ...
-jede Menge Prüf-Tools
...
Außerdem haben wir einen Löschtransport für alle alten AddOn-Objekte erzeugt, zum Import nach erfolgter Umstellung der Zielsysteme.
Nummernkreisobjekte und Änderungsbelegobjekte ließen sich zu 4.x noch nicht per Transport löschen, da PGMID hier 'R3OB' und nicht 'R3TR' war.
Das haben wir per Programm gemacht.
Die anderen Objekte wurden per Transport gelöscht.
(Auch hier hat der SAP-Standard einiges "vergessen".
Funktionsgruppen und Funktionsbausteine wurden zwar gelöscht, die Doku zu FBs und zu FB-Parametern gab es aber noch.
Ebenso wurden die Programm-Loads nicht gelöscht ...)
Im AddOn-Entwicklungssystem kamen noch ein paar Tools hinzu,
z.B. für die Vorbereitung der Umstellung:
-diverse Konsistenzprüfungen, z.B. Syntax-Check, Verwendung von Objekten aus dem Kundennamensraum, die eigentlich nicht mit umgestellt werden sollen, ...
-Festlegung der neuen Objektnamen (auch das ist nicht ganz trivial)
Außerdem zog dort auch die Versionshistorie in den neuen Namensraum um.
Nein.Wäre es möglich den Quelltext dieser Tools zu posten ?
Ersten gehört der Quelltext nicht mir (auch wenn ich den größten Teil entwickelt habe).
Und zweitens wäre es zum Posten doch etwas zu viel.
Frag doch mal bei SAP nach.Inzwischen soll es (angeblich) ein Tool von SAP geben, das das o.g. verwirklicht.
Mich würde wirklich interessieren
-wie ausgereift die Tools sind ("ein Tool" glaube ich irgendwie nicht), oder ob bisher nur Pilot-Kunden Beta-Tester spielen
-inwiefern die Umstellung sowohl beim AddOn-Anbieter als auch bei den AddOn-Anwendern (hier Entwicklungs-, Test- und Produktiv-Systeme) unterstützt wird
-welche SAP-Releases unterstützt werden
-was die Tools kosten
-welchen Zeitraum SAP für so ein Projekt veranschlagt
(Tests, Umsetzung im AddOn-Entwicklungssystem, in den Entwicklungssystemen der Kunden, in Produktivsystemen)
-wie viel Beratungsleistung eingekauft werden muss
-welcher Aufwand durch den AddOn-Anbieter bzw. durch AddOn-Anwender zu leisten ist ...
Ach ja, gegen ein "Umbenennen" sprechende Gründe (abgesehen von dem oben bereits genannten):
Was passiert, wenn Ihr auf halbem Wege merkt, dass Ihr Euch verrant habt? Spielt Ihr dann das Backup ein?
Wenn man die Objekte kopiert und die Kopien anpasst, kann man mit wenig Aufwand alle in den neuen Namensraum kopierten Objekte (oder nur die "kaputten") löschen.
Das Umbenennen ist für etliche Objektarten nicht vorgesehen.
Selbst da, wo es klappt, prüft SAP, ob es noch Verwendungen gibt. Das Kopieren (angefangen von Objektarten ohne Abhängigkeiten zu anderen Objekten) und Anpassen der Abhängigkeiten zu bereits umgestellten Objektarten ist einfacher.
Für brauchbare Ergebnissse beim automatischen Anpassen der Quelltexte greift man lieber auf Quelltexte ohne Syntaxfehler zurück.
...
Ich weiß, der Thread ist fast 20 Jahre alt, hat aber keine Lösung. Das Problem wird aber sicher immer noch auftreten, wenn z.B. Software verkauft wird oder sich Firmen umbenennen.
Wir haben vor gut 10 Jahren die Namensraumumstellung mit dem Open-Source-Tool "SAPLink" gemacht.
Dieses schreibt die Objekte in eine Datei ".nugg". Dort haben wir per Suchen&Ersetzen den Namensraum ersetzt und die Datei wieder zurück ins System gespielt.
Klingt einfach, ist es aber nicht:
a) SAP Link unterstützt nur Z-Namensraum
-> Da Open-Source, kann man es beliebig anpassen
b) Es wurden nicht alle Entwicklungsobjekte unterstützt.
-> Da Open-Source, kann man es beliebig anpassen
c) SAP Link unterstützt logischer Weise kein Customizing. Wenn man also die Customizing-Tabelle in den neuen Namensraum überführt, so muss man den Inhalt manuell rüber schieben. Dazu haben wir dann eigene Entwicklung gemacht.
Am Ende war das Ziel, dass der Kunde (Produktentwicklung) bei sich nur den alten und den neuen Namensraum eingibt und EINEN Knopf drückt.
Wir haben vor gut 10 Jahren die Namensraumumstellung mit dem Open-Source-Tool "SAPLink" gemacht.
Dieses schreibt die Objekte in eine Datei ".nugg". Dort haben wir per Suchen&Ersetzen den Namensraum ersetzt und die Datei wieder zurück ins System gespielt.
Klingt einfach, ist es aber nicht:
a) SAP Link unterstützt nur Z-Namensraum
-> Da Open-Source, kann man es beliebig anpassen
b) Es wurden nicht alle Entwicklungsobjekte unterstützt.
-> Da Open-Source, kann man es beliebig anpassen
c) SAP Link unterstützt logischer Weise kein Customizing. Wenn man also die Customizing-Tabelle in den neuen Namensraum überführt, so muss man den Inhalt manuell rüber schieben. Dazu haben wir dann eigene Entwicklung gemacht.
Am Ende war das Ziel, dass der Kunde (Produktentwicklung) bei sich nur den alten und den neuen Namensraum eingibt und EINEN Knopf drückt.
Funktioniert ebenfalls mit abapGit.
Zusätzlich arbeitet Lars an einer automatischen Umbenennung bei Upload/ Download.
https://blogs.sap.com/2021/04/20/automa ... p-objects/
Es werden jedoch nur Reports und Klassen unterstützt AFAIK.
Zusätzlich arbeitet Lars an einer automatischen Umbenennung bei Upload/ Download.
https://blogs.sap.com/2021/04/20/automa ... p-objects/
Es werden jedoch nur Reports und Klassen unterstützt AFAIK.
Seite 1 von 1
Vergleichbare Themen
10
Antw.
Antw.
3922
Views
Views
BAPI_DOCUMENT_CHECKOUTVIEW2 erzeugt Massen von Unix-Prozesse
von ralf.wenzel » 19.04.2016 10:35 • Verfasst in ABAP® Core
von ralf.wenzel » 19.04.2016 10:35 • Verfasst in ABAP® Core
3
Antw.
Antw.
2255
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.