Konvertierung S/4Hana Custom Code
3 Beiträge
•
Seite 1 von 1
3 Beiträge
Seite 1 von 1
Hi,
ich habe jetzt schon recht viel gelesen bzgl. ERP -> S/4Hana Custom Code Konvertierung, aber leider ist mir folgendes noch nicht ganz klar:
Angenommen, wir machen eine Brownfield Migration auf S/4Hana (on-premise). In der Vorbereitungsphase lassen wir den Custom Code Check laufen und passen den Code in unseren Z-Programmen und Erweiterungen, soweit es zu diesem Zeitpunkt geht, an.
Nun gibt es ja etliche Änderungen, die man erst nach der Konvertierung in dem neuen S/4Hana System machen kann und muss ("functional adaption"). Diese Anpassungen müssen aber erstens erstmal durchgeführt und zweitens dann noch getestet werden.
Bis die Anpassungen gemacht sind, kann nicht produktiv mit dem System gearbeitet werden. SAP spricht bei der S4 Konvertierung von einer Downtime von 8-60 Stunden. In dieser Zeitspanne kann die funktionale Anpassung aber noch nicht gemacht worden sein.
Wie funktioniert das also in der Praxis?
Eventuell vereinfacht in etwa so:
es gibt einen Entwicklungsstopp im Altsystem zum Zeitpunkt X,
eine Konvertierung des Entwicklungssystems auf S/4Hana wird durchgeführt und
dort werden die Anpassungen dann gemacht und später beim Go-Live in das Zielsystem transportiert?
Erfahrungsberichte erwünscht 😉
ich habe jetzt schon recht viel gelesen bzgl. ERP -> S/4Hana Custom Code Konvertierung, aber leider ist mir folgendes noch nicht ganz klar:
Angenommen, wir machen eine Brownfield Migration auf S/4Hana (on-premise). In der Vorbereitungsphase lassen wir den Custom Code Check laufen und passen den Code in unseren Z-Programmen und Erweiterungen, soweit es zu diesem Zeitpunkt geht, an.
Nun gibt es ja etliche Änderungen, die man erst nach der Konvertierung in dem neuen S/4Hana System machen kann und muss ("functional adaption"). Diese Anpassungen müssen aber erstens erstmal durchgeführt und zweitens dann noch getestet werden.
Bis die Anpassungen gemacht sind, kann nicht produktiv mit dem System gearbeitet werden. SAP spricht bei der S4 Konvertierung von einer Downtime von 8-60 Stunden. In dieser Zeitspanne kann die funktionale Anpassung aber noch nicht gemacht worden sein.
Wie funktioniert das also in der Praxis?
Eventuell vereinfacht in etwa so:
es gibt einen Entwicklungsstopp im Altsystem zum Zeitpunkt X,
eine Konvertierung des Entwicklungssystems auf S/4Hana wird durchgeführt und
dort werden die Anpassungen dann gemacht und später beim Go-Live in das Zielsystem transportiert?
Erfahrungsberichte erwünscht 😉
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Hi, bei einem Kunden haben wir es so gelöst :
Systemlandschaft 6 Systeme, Zeit für die Umstellung ca 1,5 Jahre, Transportwege :
Dev ECC -> Qual ECC -> Prod ECC ( -> Dev S/4 )
( von Prod ECC -> ) Dev S/4 -> Qual S/4 -> Prod S/4
alle Customizing Aufgaben mussten in ECC UND S/4 durchgeführt werden ( kein Transport von ECC -> S/4 )
alle (Kunden) Objekte die NICHT in Dev S/4 angefasst wurden, durften von der ECC auch in D S/4 -> Q S/4 -> P S/4 importiert werden.
alle (Kunden) Objekte die in D S/4 angefasst wurden, gingen -> Q S/4 -> P S/4 und durften ab diesem Zeitpunkt nicht mehr aus der ECC kommen, da sie sonst überschrieben wurden, diese Objekte liefen jetzt als "dual maintenance" Objekte.
Enhancements im Transportsystem ( ECC und S/4 )
wurde in der D S/4 ein Kunden Objekt geändert und in einen Transport Auftrag aufgenommen, wurde per RFC in D ECC ein Eintrag dafür in einer Z*Tabelle vorgenommen
bei Änderung eines Objektes in ECC wurde geprüft ob es bereits eine Änderung in S/4 gab, falls ja wurde dieser Transport als "(1) NICHT in S/4 importieren" gekennzeichnet, sonst "(2) in S/4 importieren erlaubt" .
Bei der Freigabe wurde geprüft ob im Transport Objekte (1) und (2) vorkamen, die Freigabe wurde dann solange verweigert, bis die Transporte nur Objekte (1) oder nur (2) enthalten haben ( Objekte mussten dann umziehen in neuen Transport ).
Transporte mit Objekten (1) wurden dann nur bis P ECC importiert, Transporte mit Objekten (2) wurden dann auch auf den S/4 Systemen importiert.
Zusätzlich musste jeder Entwickler die Objekte, die nicht per Transport die S/4 gingen, mit "Habe Änderung auch auf S/4 manuell geprüft/durchgeführt" absegnen, damit nichts verloren ging.
ich hoffe ich habe es halbwegs verständlich geschildert, war eine ziemlich komplexe Angelegenheit.
am besten die ATC - Checks für S/4, so früh wie möglich laufen lassen und alles was schon auf der ECC machbar ist, durchführen und erst dann S/4 aufsetzen.
Es gab dabei natürlich auch einige Probleme, aber wir haben es hinbekommen :-)
Grüße Edwin
Systemlandschaft 6 Systeme, Zeit für die Umstellung ca 1,5 Jahre, Transportwege :
Dev ECC -> Qual ECC -> Prod ECC ( -> Dev S/4 )
( von Prod ECC -> ) Dev S/4 -> Qual S/4 -> Prod S/4
alle Customizing Aufgaben mussten in ECC UND S/4 durchgeführt werden ( kein Transport von ECC -> S/4 )
alle (Kunden) Objekte die NICHT in Dev S/4 angefasst wurden, durften von der ECC auch in D S/4 -> Q S/4 -> P S/4 importiert werden.
alle (Kunden) Objekte die in D S/4 angefasst wurden, gingen -> Q S/4 -> P S/4 und durften ab diesem Zeitpunkt nicht mehr aus der ECC kommen, da sie sonst überschrieben wurden, diese Objekte liefen jetzt als "dual maintenance" Objekte.
Enhancements im Transportsystem ( ECC und S/4 )
wurde in der D S/4 ein Kunden Objekt geändert und in einen Transport Auftrag aufgenommen, wurde per RFC in D ECC ein Eintrag dafür in einer Z*Tabelle vorgenommen
bei Änderung eines Objektes in ECC wurde geprüft ob es bereits eine Änderung in S/4 gab, falls ja wurde dieser Transport als "(1) NICHT in S/4 importieren" gekennzeichnet, sonst "(2) in S/4 importieren erlaubt" .
Bei der Freigabe wurde geprüft ob im Transport Objekte (1) und (2) vorkamen, die Freigabe wurde dann solange verweigert, bis die Transporte nur Objekte (1) oder nur (2) enthalten haben ( Objekte mussten dann umziehen in neuen Transport ).
Transporte mit Objekten (1) wurden dann nur bis P ECC importiert, Transporte mit Objekten (2) wurden dann auch auf den S/4 Systemen importiert.
Zusätzlich musste jeder Entwickler die Objekte, die nicht per Transport die S/4 gingen, mit "Habe Änderung auch auf S/4 manuell geprüft/durchgeführt" absegnen, damit nichts verloren ging.
ich hoffe ich habe es halbwegs verständlich geschildert, war eine ziemlich komplexe Angelegenheit.
am besten die ATC - Checks für S/4, so früh wie möglich laufen lassen und alles was schon auf der ECC machbar ist, durchführen und erst dann S/4 aufsetzen.
Es gab dabei natürlich auch einige Probleme, aber wir haben es hinbekommen :-)
Grüße Edwin
Seite 1 von 1
Vergleichbare Themen
3
Antw.
Antw.
2391
Views
Views
Eingabefeld zu Custom Container hinzufügen (Code)
von Dyrdek » 30.06.2015 10:49 • Verfasst in ABAP® für Anfänger
von Dyrdek » 30.06.2015 10:49 • Verfasst in ABAP® für Anfänger
3
Antw.
Antw.
1866
Views
Views
(Service-Consumer) Proxy erstellen mit Custom Code
von Tim310 » 20.03.2020 13:19 • Verfasst in ABAP Objects®
von Tim310 » 20.03.2020 13:19 • Verfasst in ABAP Objects®
1
Antw.
Antw.
3219
Views
Views
1
Antw.
Antw.
1784
Views
Views
1
Antw.
Antw.
2531
Views
Views
Erfahrungen mit S/4HANA-Cloud-Entwicklung?
von IHe » 10.11.2020 10:34 • Verfasst in SAP Cloud Platform
von IHe » 10.11.2020 10:34 • Verfasst in SAP Cloud Platform
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 4 Stunden von DeathAndPain 2 / 118
vor 4 Stunden von DeathAndPain 2 / 118
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 4 Stunden von DeathAndPain 2 / 118
vor 4 Stunden von DeathAndPain 2 / 118