Konstanten Interface - LOAD_PROGRAM_CLASS_MISMATCH
9 Beiträge
•
Seite 1 von 1
9 Beiträge
Seite 1 von 1
Guten Tag zusammen,
bei meinen ABAP Entwicklungen bin ich auf ein kleines Problem gestoßen und hoffe, dass mir hier jemand helfen kann.
Ich verwende zur Verwaltung von allgemeinen Konstanten ein Interface, in dem ich etliche Konstanten angelegt habe. Auf diese Konstanten wird aus verschiedenen Programmen zugegriffen.
Mein Problem ist, dass wenn ich eine neue Konstante in mein Interface hinzufüge, (nach dem Transport auf das Q/P-System) alle dort laufenden Programme mit einem Laufzeitfehler abbrechen:
LOAD_PROGRAM_CLASS_MISMATCH
Gibt es irgendeine Möglichkeit, dieses Problem zu umgehen? Wie verwaltet ihr eure allgemeinen Konstanten?
Grüße
Kai N.
bei meinen ABAP Entwicklungen bin ich auf ein kleines Problem gestoßen und hoffe, dass mir hier jemand helfen kann.
Ich verwende zur Verwaltung von allgemeinen Konstanten ein Interface, in dem ich etliche Konstanten angelegt habe. Auf diese Konstanten wird aus verschiedenen Programmen zugegriffen.
Mein Problem ist, dass wenn ich eine neue Konstante in mein Interface hinzufüge, (nach dem Transport auf das Q/P-System) alle dort laufenden Programme mit einem Laufzeitfehler abbrechen:
LOAD_PROGRAM_CLASS_MISMATCH
Gibt es irgendeine Möglichkeit, dieses Problem zu umgehen? Wie verwaltet ihr eure allgemeinen Konstanten?
Grüße
Kai N.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Tach.
Meines Wissens kann man das nicht umgehen. In der Praxis wird daher ein Zeitfenster für Produktiv-Transporte festgelegt; jeder, der dann noch ein Programm benutzt macht das auf eigene Gefahr.
Du könntest versuchen, die Gefahr eines Programmabbruchs zu reduzieren, indem Du Deine Definitionen nach irgendwelchen Kriterien auf mehrere Klassen aufteilst. Das Grundproblem beseitigt das aber nicht.
Gruß,
Haubi
Meines Wissens kann man das nicht umgehen. In der Praxis wird daher ein Zeitfenster für Produktiv-Transporte festgelegt; jeder, der dann noch ein Programm benutzt macht das auf eigene Gefahr.
Du könntest versuchen, die Gefahr eines Programmabbruchs zu reduzieren, indem Du Deine Definitionen nach irgendwelchen Kriterien auf mehrere Klassen aufteilst. Das Grundproblem beseitigt das aber nicht.
Gruß,
Haubi
Danke für deine Haubi,
das habe befürchtet. Eine Trennung in mehrere Klassen würde die komplizierte Verteilung und verwendung der ganzen Konstanten nur auf einer anderen Ebene verkomplizieren.
Denkst du es wäre ggf. besser, die Konstanten in eine Typgruppe zu schmeissen? Ich habe irgendwo gelesen (finde die Stelle nicht mehr), dass Typgruppen wohl obsolet werden und man sie nicht mehr verwenden soll. Hmm evtl. teste ich das trotzdem einfach mal aus - mehr dumpen als jetzt kann es ja nicht.
Grüße
Kai N.
das habe befürchtet. Eine Trennung in mehrere Klassen würde die komplizierte Verteilung und verwendung der ganzen Konstanten nur auf einer anderen Ebene verkomplizieren.
Denkst du es wäre ggf. besser, die Konstanten in eine Typgruppe zu schmeissen? Ich habe irgendwo gelesen (finde die Stelle nicht mehr), dass Typgruppen wohl obsolet werden und man sie nicht mehr verwenden soll. Hmm evtl. teste ich das trotzdem einfach mal aus - mehr dumpen als jetzt kann es ja nicht.
Grüße
Kai N.
Hi Kai.
Die Dumps wirst Du nach meinem Wissensstand trotzdem noch bekommen, da die Typgruppen ja auch geladen werden müssen; wenn sie sich im Zuge eines Imports ändern unterscheiden sich geladene und letzte verfügbare Version, somit kommt es zum Dump. Ganz sicher bin ich mir hier aber nicht, da ich nur vordefinierte Typgruppen verwende (z.B. ABAP) und selber keine anlege.
Ich würde bei Deiner Strategie bleiben und organisatorisch sicherstellen, dass Importe nicht zu Abbrüchen führen, indem ein Zeitfenster für Prod-Transporte festgelegt wird.
Grüße,
Haubi
Die Dumps wirst Du nach meinem Wissensstand trotzdem noch bekommen, da die Typgruppen ja auch geladen werden müssen; wenn sie sich im Zuge eines Imports ändern unterscheiden sich geladene und letzte verfügbare Version, somit kommt es zum Dump. Ganz sicher bin ich mir hier aber nicht, da ich nur vordefinierte Typgruppen verwende (z.B. ABAP) und selber keine anlege.
Ich würde bei Deiner Strategie bleiben und organisatorisch sicherstellen, dass Importe nicht zu Abbrüchen führen, indem ein Zeitfenster für Prod-Transporte festgelegt wird.
Grüße,
Haubi
Falls eure "Konstanten" wirklich so häufig geändert werden, dass Probleme im prod. System gibt, dann kannst du dir evtl. überlegen die "Konstanten" in einer Parametertabelle auf der DB abzulegen. So wäre bei einer Änderung/ Erweiterung des Konstanten-Pools keine "Programmänderung" notwendig, sondern nur ein paar Tabelleneinträge.
Mit einer geschickten Verwaltungsklasse dürfte auch der Zugriff nicht groß anders aussehen, als bisher.
Die Laufzeit wäre wahrscheinlich höher...
Alt:
Neu:
Probleme gibt es allerdings bei z.B. WHERE-Klauseln.
kann also nicht ohne weiteres ersetzt werden durch
Hier müsste man mit einer Hilfsvariablen arbeiten.
Es gibt ja wirklich Firmen, wo wirklich kaum Zeit für Transport ist, da das System rund um die Uhr genutzt wird...
Im Regelfall sollte aber eigentlich ein von Haubi beschriebenes Zeitfenster ausreichen.
Ggfs. könnte vielleicht ein CTS*-BADI ausprogrammiert werden, der auf bestimmte "kritische" Programme prüft. Ich weiß nicht, ob es da einen BADI/ Exit gibt, der vor Import eines TA aufgerufen wird. Vielleicht reicht aber auch bei Auftragsfreigabe ein Exit, der dann zwei ** an die erste Stelle des Auftragstextes setzt um zu zeigen: Achtung Import erst nach 20:00 Uhr!!
Mit einer geschickten Verwaltungsklasse dürfte auch der Zugriff nicht groß anders aussehen, als bisher.
Die Laufzeit wäre wahrscheinlich höher...
Alt:
Code: Alles auswählen.
if auart = zy01_auart_standard.Code: Alles auswählen.
if auart = zcl_const=>get( 'AUART_STANDARD' ).Code: Alles auswählen.
...WHERE auart = zy01_auart_standard.Code: Alles auswählen.
... where auart = zcl_const=>get( 'AUART_STANDARD' )Es gibt ja wirklich Firmen, wo wirklich kaum Zeit für Transport ist, da das System rund um die Uhr genutzt wird...
Im Regelfall sollte aber eigentlich ein von Haubi beschriebenes Zeitfenster ausreichen.
Ggfs. könnte vielleicht ein CTS*-BADI ausprogrammiert werden, der auf bestimmte "kritische" Programme prüft. Ich weiß nicht, ob es da einen BADI/ Exit gibt, der vor Import eines TA aufgerufen wird. Vielleicht reicht aber auch bei Auftragsfreigabe ein Exit, der dann zwei ** an die erste Stelle des Auftragstextes setzt um zu zeigen: Achtung Import erst nach 20:00 Uhr!!
Beitrag
von a-dead-trousers (Top Expert / 4399 / 223 /
1182
)
»
hi!
Ich möchte das Thema kurz aufwärmen:
Bei uns ist das hier beschriebenen Problem etwas anders aufgetreten. Die betroffene Klasse wurde korrekt auf das Produktivsystem transportiert und die erwarteten LOAD_PROGRAM_CLASS_MISMATCH sind aufgetaucht. Auf den meisten Applikationsservern hat sich auch das Problem nach einiger Zeit beruhigt.
ABER bei dreien ist der Fehler am nächsten Tag noch immer aufgetreten. Eine Analyse der Kurzdumps ergab, dass es hier bei der "Schnittstellenversion" einen Unterschied im Sekundenbereich gab. (siehe dazu auch die OSS 1563925)
Eine nachträgliche Aktivierung des Objektes am Produktivsystem, hat zwar den Fehler korrigiert, aber danach sind dann alle User (wegen des neuem LOAD auch auf den anderen Appl.Servern) wieder rausgeflogen.
Jetzt hätte ich ein paar Fragen an die Community:
- Gibt es eine Möglichkeit nur ein bestimmtes Objekt auf einem bestimmten Server aus dem LOAD zu kicken, sodass nur dieses eine von der DB nachgeladen werden muss? SGEN, erneute Aktivierung und /$Sync (sofern das überhaupt geht) wirken eher wie mit Kanonen auf Spatzen zu schießen. Außerdem kann es dadurch auch Auswirkungen auf die eigentlich korrekten Appl.Server LOADs geben.
- Kann man irgendwie die "Schnittstellenversion" einer Klasse/eines Programms in der Datenbank bzw. auf dem Appl.Server ermitteln und so einen möglichen Schiefstand erkennen?
lg ADT
Ich möchte das Thema kurz aufwärmen:
Bei uns ist das hier beschriebenen Problem etwas anders aufgetreten. Die betroffene Klasse wurde korrekt auf das Produktivsystem transportiert und die erwarteten LOAD_PROGRAM_CLASS_MISMATCH sind aufgetaucht. Auf den meisten Applikationsservern hat sich auch das Problem nach einiger Zeit beruhigt.
ABER bei dreien ist der Fehler am nächsten Tag noch immer aufgetreten. Eine Analyse der Kurzdumps ergab, dass es hier bei der "Schnittstellenversion" einen Unterschied im Sekundenbereich gab. (siehe dazu auch die OSS 1563925)
Eine nachträgliche Aktivierung des Objektes am Produktivsystem, hat zwar den Fehler korrigiert, aber danach sind dann alle User (wegen des neuem LOAD auch auf den anderen Appl.Servern) wieder rausgeflogen.
Jetzt hätte ich ein paar Fragen an die Community:
- Gibt es eine Möglichkeit nur ein bestimmtes Objekt auf einem bestimmten Server aus dem LOAD zu kicken, sodass nur dieses eine von der DB nachgeladen werden muss? SGEN, erneute Aktivierung und /$Sync (sofern das überhaupt geht) wirken eher wie mit Kanonen auf Spatzen zu schießen. Außerdem kann es dadurch auch Auswirkungen auf die eigentlich korrekten Appl.Server LOADs geben.
- Kann man irgendwie die "Schnittstellenversion" einer Klasse/eines Programms in der Datenbank bzw. auf dem Appl.Server ermitteln und so einen möglichen Schiefstand erkennen?
lg ADT
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Warum überhaupt ein Interface?
Ich verstehe noch nicht ganz, wieso ein Interface für Konstanten definiert wird. Ändert sich das, so sind natürlich alle verwendenden Klassen betroffen.
Was spricht gegen eine eigene Konstantenklasse, z.B. ZCL_CONSTANTS und der Verwendung dieser Konstanten mit ZCL_CONSTANTS=>KONSTANTE_1 o.ä.?
Ich verstehe noch nicht ganz, wieso ein Interface für Konstanten definiert wird. Ändert sich das, so sind natürlich alle verwendenden Klassen betroffen.
Was spricht gegen eine eigene Konstantenklasse, z.B. ZCL_CONSTANTS und der Verwendung dieser Konstanten mit ZCL_CONSTANTS=>KONSTANTE_1 o.ä.?
Beitrag
von a-dead-trousers (Top Expert / 4399 / 223 /
1182
)
»
Okay, es ging mir nicht um das Problem mit den Konstanten, sondern um den Kurzdump an sich.
Irgendwie gibt es in SAP ein Problem beim "Verteilen" der Objekte bei einem Transport, sodass der LOAD auf dem einen Server mit Zeitstempel X landet und auf einem anderen mit Zeitstempel Y wobei zwischen den beiden 1 Sekunde Unterschied ist.
In diesem Fall kommt es auch nicht mehr zu einer "spontanen Selbstheilung" des Systems indem nacheinander alle User mit dem alten LOAD rausfliegen.
Stattdessen fliegen die User immer wieder raus, weil die Zentralinstanz den Zeitstempel X vorgibt, der Applserver aber Y hat und weil sich das Objekt auch seither nicht mehr geändert (aktiviert) hat, erfolgt auch keine Aktualisierung des fehlerhaften LOADs.
Daher eben meine Frage ob man den LOAD irgendwie auswerten kann, bzw. ob man ein Objekt gezielt rausschmeißen kann ohne es nochmals zu Aktivieren, was dann ja wieder Auswirkungen auf den LOAD aller Server hat.
Zur Info: Wir haben immer so an die 20 Applserver im Einasatz und beim letzten Mal als das aufgetreten ist, hatten drei die falschen Zeitstempel im LOAD.
lg ADT
Irgendwie gibt es in SAP ein Problem beim "Verteilen" der Objekte bei einem Transport, sodass der LOAD auf dem einen Server mit Zeitstempel X landet und auf einem anderen mit Zeitstempel Y wobei zwischen den beiden 1 Sekunde Unterschied ist.
In diesem Fall kommt es auch nicht mehr zu einer "spontanen Selbstheilung" des Systems indem nacheinander alle User mit dem alten LOAD rausfliegen.
Stattdessen fliegen die User immer wieder raus, weil die Zentralinstanz den Zeitstempel X vorgibt, der Applserver aber Y hat und weil sich das Objekt auch seither nicht mehr geändert (aktiviert) hat, erfolgt auch keine Aktualisierung des fehlerhaften LOADs.
Daher eben meine Frage ob man den LOAD irgendwie auswerten kann, bzw. ob man ein Objekt gezielt rausschmeißen kann ohne es nochmals zu Aktivieren, was dann ja wieder Auswirkungen auf den LOAD aller Server hat.
Zur Info: Wir haben immer so an die 20 Applserver im Einasatz und beim letzten Mal als das aufgetreten ist, hatten drei die falschen Zeitstempel im LOAD.
lg ADT
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von Hannes Rempel (ForumUser / 2 / 0 /
0
)
»
Hallo zusamen,
mir hat das hier geholfen: http://service.sap.com/sap/support/notes/1758783
Diese Generierungstools sind evtl. auch interessant: http://service.sap.com/sap/support/notes/162991
Viele Grüße
mir hat das hier geholfen: http://service.sap.com/sap/support/notes/1758783
Diese Generierungstools sind evtl. auch interessant: http://service.sap.com/sap/support/notes/162991
Viele Grüße
Seite 1 von 1
Vergleichbare Themen
3
Antw.
Antw.
1605
Views
Views
6
Antw.
Antw.
5095
Views
Views
ALV OO Set_table_for_first_display Load Layout YES/Change NO
von RIG » 29.01.2018 14:36 • Verfasst in ABAP® für Anfänger
von RIG » 29.01.2018 14:36 • Verfasst in ABAP® für Anfänger
5
Antw.
Antw.
7577
Views
Views
Fehlermeldung: Der Speicher für die Dynpro-LOAD ist erschö
von Anfänger » 20.09.2012 11:31 • Verfasst in Basis
von Anfänger » 20.09.2012 11:31 • Verfasst in Basis
2
Antw.
Antw.
2499
Views
Views
index.html Fehlermeldung Failed to load resource: net::ERR_F
von AliR » 12.08.2015 16:07 • Verfasst in Web-Dynpro, BSP + BHTML
von AliR » 12.08.2015 16:07 • Verfasst in Web-Dynpro, BSP + BHTML
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.