Versionsmanagement für (kundeneigene) Customizing-Tabellen
5 Beiträge
•
Seite 1 von 1
5 Beiträge
Seite 1 von 1
Beitrag
von m.andreschak (ForumUser / 22 / 2 /
3
)
»
Hallo zusammen,
ich habe leider über die Suche nichts passendes gefunden.
Ich suche nach einer Möglichkeit, Daten(-banktabellen) zu "versionieren".
Das soll ultimativ dazu dienen, dass ich dem User - für eine sehr detailierte und komplexe Customizing-Transaktion (aktuell ein Viewcluster - perspektivisch eine kundeneigene Pflegetransaktion mit Wizards etc.) - ein Versionsmanagement anbieten kann. Er soll keine Scheu haben, Änderungen vorzunehmen, weil er alles in einer eigenen Version pflegen kann und im Notfall eine andere Version wieder zur "aktiven" macht. Klassische Versionsverwaltung eben - so wie es sie ja auch für Workbench-Objekte im SAP gibt.
In der IDoc-Definition z.B. finde ich ja auch ein Versionsmanagement für Segmentdefinitionen etc., deshalb frage ich mich, ob es ggf. ein entsprechendes Framework dafür im Standard gibt.
Ich habe schon lange nicht mehr mit persistenten Objekten gearbeitet - könntet Ihr euch vorstellen, dass es darüber abbildbar ist? Oder gibt es eine andere Technik, die ich übersehen habe?
Das "normale" Änderungsmanagement der SAP - also Änderungshistorien, ggf. Änderungszeiger, Transporte mit Customizing-Änderungen, usw. - ist für mich nicht hinreichend "einfach". Ich möchte sicherlich keine Applikation schreiben, in der ich "zu Fuß" irgendwelche Änderungen aggregiere, Feldinhalte zurücksetze und all das. Dafür habe ich im Hinblick auf meine Projekttimeline nicht die Zeit.
Ich wäre dankbar um jeden Hinweis.
Gruß
ich habe leider über die Suche nichts passendes gefunden.
Ich suche nach einer Möglichkeit, Daten(-banktabellen) zu "versionieren".
Das soll ultimativ dazu dienen, dass ich dem User - für eine sehr detailierte und komplexe Customizing-Transaktion (aktuell ein Viewcluster - perspektivisch eine kundeneigene Pflegetransaktion mit Wizards etc.) - ein Versionsmanagement anbieten kann. Er soll keine Scheu haben, Änderungen vorzunehmen, weil er alles in einer eigenen Version pflegen kann und im Notfall eine andere Version wieder zur "aktiven" macht. Klassische Versionsverwaltung eben - so wie es sie ja auch für Workbench-Objekte im SAP gibt.
In der IDoc-Definition z.B. finde ich ja auch ein Versionsmanagement für Segmentdefinitionen etc., deshalb frage ich mich, ob es ggf. ein entsprechendes Framework dafür im Standard gibt.
Ich habe schon lange nicht mehr mit persistenten Objekten gearbeitet - könntet Ihr euch vorstellen, dass es darüber abbildbar ist? Oder gibt es eine andere Technik, die ich übersehen habe?
Das "normale" Änderungsmanagement der SAP - also Änderungshistorien, ggf. Änderungszeiger, Transporte mit Customizing-Änderungen, usw. - ist für mich nicht hinreichend "einfach". Ich möchte sicherlich keine Applikation schreiben, in der ich "zu Fuß" irgendwelche Änderungen aggregiere, Feldinhalte zurücksetze und all das. Dafür habe ich im Hinblick auf meine Projekttimeline nicht die Zeit.
Ich wäre dankbar um jeden Hinweis.
Gruß
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Konkret helfen kann ich dir nicht, aber vielleicht ein paar Hinweis/Erfahrungen geben.
A:
Wir haben bei uns ähnliches Problem habt, dass wir nach einem Korrespondenzdruck die zu dem Zeitpunkt gültigen Daten kennen wollten. Die Suche im KorrespondenzContainer war zu aufwendig und über die Änderungsbeleg zu ungenau. Daher haben wir die erforderlichen Daten aus den Tabellen zum Zeitpunkt des Druckes einfach kopiert.
Somit war es auch einfacher die Änderungen seit dem letzten Druck besser ermitteln zu können, als über die Änderungsbelegtabellen.
---
B: Sagt dir die PSOBWORK was?
Hier lädt die SAP ihre Daten nach Gültigkeitstag, den man beim Laden des Vertragsgegenstandes mitgeben kann (nur taggenau). Das geht auch für Änderungen in der Zukunft - also geplante Änderungen.
Das ganze macht die SAP auf Basis der Änderungsbelegtabelle (CDHDR; CDPOS). Konkret für den Vertrag im FuBa FMCA_DPSOB_READ, wenn I_VALDT ungleich aktuelles Tagesdatum übergeben wird. Intern werden über den Fuba BUS_TABLE_CHANGEDOCUMENTS_READ quasi die zu dem Stichtag gültigen Daten geliefert.
Das Ganze setzt aber voraus, dass beim Speichern auch Änderungsbelege geschrieben.
A:
Wir haben bei uns ähnliches Problem habt, dass wir nach einem Korrespondenzdruck die zu dem Zeitpunkt gültigen Daten kennen wollten. Die Suche im KorrespondenzContainer war zu aufwendig und über die Änderungsbeleg zu ungenau. Daher haben wir die erforderlichen Daten aus den Tabellen zum Zeitpunkt des Druckes einfach kopiert.
Somit war es auch einfacher die Änderungen seit dem letzten Druck besser ermitteln zu können, als über die Änderungsbelegtabellen.
---
B: Sagt dir die PSOBWORK was?
Hier lädt die SAP ihre Daten nach Gültigkeitstag, den man beim Laden des Vertragsgegenstandes mitgeben kann (nur taggenau). Das geht auch für Änderungen in der Zukunft - also geplante Änderungen.
Das ganze macht die SAP auf Basis der Änderungsbelegtabelle (CDHDR; CDPOS). Konkret für den Vertrag im FuBa FMCA_DPSOB_READ, wenn I_VALDT ungleich aktuelles Tagesdatum übergeben wird. Intern werden über den Fuba BUS_TABLE_CHANGEDOCUMENTS_READ quasi die zu dem Stichtag gültigen Daten geliefert.
Das Ganze setzt aber voraus, dass beim Speichern auch Änderungsbelege geschrieben.
Beitrag
von m.andreschak (ForumUser / 22 / 2 /
3
)
»
Hi,
danke Dir, den Teil mit der PSOBWORK muss ich mir mal anschauen! Ich befürchte aber schon fast, dass ich auf technische Grenzen stoßen werde, sobald ich mich auf die Änderungsbelege verlasse; ich habe einige CLOB's, und so wie ich SAP kenne, steckt da irgendwo ein CHAR100 Feld o.ä. mittendrin, wo der Feldwert durchgeschleift und dann *hups* getrimmt wird.
Wenn es keine Standardfunktionen gibt: Ich hatte gestern Abend kurz die Idee, das mittels EXPORT zu lösen - so könnte ich in einer Cluster-Tabelle, z.B. in verschiedenen Bereichen, meine einzelnen Customizing-Tabellen ablegen und mittels des Schlüssel versionieren. Gibt's Meinungen zu dieser Idee? Schön ist bestimmt anders, aber so stelle ich mir zumindest vor, keine bestehenden Datenbankstrukturen "aufbohren" zu müssen.
..Oder sonstige Ideen?
VG,
danke Dir, den Teil mit der PSOBWORK muss ich mir mal anschauen! Ich befürchte aber schon fast, dass ich auf technische Grenzen stoßen werde, sobald ich mich auf die Änderungsbelege verlasse; ich habe einige CLOB's, und so wie ich SAP kenne, steckt da irgendwo ein CHAR100 Feld o.ä. mittendrin, wo der Feldwert durchgeschleift und dann *hups* getrimmt wird.
Wenn es keine Standardfunktionen gibt: Ich hatte gestern Abend kurz die Idee, das mittels EXPORT zu lösen - so könnte ich in einer Cluster-Tabelle, z.B. in verschiedenen Bereichen, meine einzelnen Customizing-Tabellen ablegen und mittels des Schlüssel versionieren. Gibt's Meinungen zu dieser Idee? Schön ist bestimmt anders, aber so stelle ich mir zumindest vor, keine bestehenden Datenbankstrukturen "aufbohren" zu müssen.
..Oder sonstige Ideen?
VG,
Die Möglichkeit über EXPORT ist vielfältig.
Ein direkter Export to database ist zwar praktisch und bequem, versagt aber, sobald sich die Tabellenstruktur ändert.
Ich nutze gerne die Umwandlung der Daten in XML und speichere diese. Das ermöglicht ein flexibles Laden der Daten, denn inzwischen gelöscht Felder werden einfach ignoriert, ebenso wie neu hinzugekommen Felder, die dann einfach nicht gefüllt werden.
Im Zweifelsfall musst du dir zu den Daten noch die Strukturdefinition der Tabelle speichern. Das wird schnell komplex und bietet viele Fallstricke.
Ein direkter Export to database ist zwar praktisch und bequem, versagt aber, sobald sich die Tabellenstruktur ändert.
Ich nutze gerne die Umwandlung der Daten in XML und speichere diese. Das ermöglicht ein flexibles Laden der Daten, denn inzwischen gelöscht Felder werden einfach ignoriert, ebenso wie neu hinzugekommen Felder, die dann einfach nicht gefüllt werden.
Im Zweifelsfall musst du dir zu den Daten noch die Strukturdefinition der Tabelle speichern. Das wird schnell komplex und bietet viele Fallstricke.
Darum versioniert man das Cluster selbst ebenfalls. Das macht die SAP und wir beim KorrespondenzContainer auch so. Ändert sich die Tabellestruktur, so bekommt auch das Cluster eine neue Version. Wichtig ist, dass beim Cluster neue Tabellefelder immer nur hinten angehängt werden dürfen.
Seite 1 von 1
Vergleichbare Themen
8
Antw.
Antw.
15815
Views
Views
Customizing-Tabellen vs. Anwendungs-Tabellen
von beterman » 02.11.2011 17:53 • Verfasst in SAP - Allgemeines
von beterman » 02.11.2011 17:53 • Verfasst in SAP - Allgemeines
3
Antw.
Antw.
3614
Views
Views
Vergleich Customizing Tabellen auf zwei Systemen
von hausi » 13.11.2018 11:04 • Verfasst in ABAP® Core
von hausi » 13.11.2018 11:04 • Verfasst in ABAP® Core
14
Antw.
Antw.
6621
Views
Views
3
Antw.
Antw.
394
Views
Views
17
Antw.
Antw.
1387
Views
Views
Best Pratices: Kundeneigene Pakethierarchie
von ralf.wenzel » 03.03.2021 14:43 • Verfasst in ABAP® Core
von ralf.wenzel » 03.03.2021 14:43 • Verfasst in ABAP® Core
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.