Aufruf per RFC oder nicht?
Ein nicht so schöner Lösungsansatz könnte wie folgt sein:
RFC-Destinationen werden in der Tabelle RFCDES gespeichert. Man kann also alle erlaubten RFC Destinationen leicht ermitteln und ggf. noch Filtern auf nur die relevanten.
Mit dem Funktionsbaustein RFC_CONNECTION_IS_OPEN kann man prüfen, ob eine Verbindung offen ist und dann bei Bedarf schliessen.
p.s.
Im Debugger kann man in dem Systembereich RFC auch erkennen welche RFC-Verbindungen geöffnet sind. Aber ob man an solche Systembereiche per ABAP herankommt ist fraglich.
RFC-Destinationen werden in der Tabelle RFCDES gespeichert. Man kann also alle erlaubten RFC Destinationen leicht ermitteln und ggf. noch Filtern auf nur die relevanten.
Mit dem Funktionsbaustein RFC_CONNECTION_IS_OPEN kann man prüfen, ob eine Verbindung offen ist und dann bei Bedarf schliessen.
p.s.
Im Debugger kann man in dem Systembereich RFC auch erkennen welche RFC-Verbindungen geöffnet sind. Aber ob man an solche Systembereiche per ABAP herankommt ist fraglich.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von a-dead-trousers (Top Expert / 4282 / 214 /
1141
)
»
ABAP-RFC-Verbindungen (Typ 3)Dele hat geschrieben:Kannst du ein paar Details zu diesen RFC-Verbindungen sagen ?
Sind das Verbindungen zu anderen SAP Systemen oder externen Systemen.
Sind das ggf. Verbindungen ins eigene System mir Destination 'NONE'.
Werden da eigene RFC-Bausteine aufgerufen (modifizierbar) oder sind das Bausteine von SAP oder Drittanbietern.
Wieviele RFC-Verbindungen mit unterschiedlichen Destinationen werden gleichzeitig bzw. parallel aufgebaut ?
Wieviele RFC-Aufrufe werden pro RFC-Destination ausgeführt ?
Es sind Verbindungen ins eigene System, aber auf unterschiedliche Mandanten
Hauptsächlich werden Kunden-FBs aufgerufen, aber auch SAP sowie Drittanbieter Bausteine.
Theoretisch 24 (Anzahl unserer Mandanten) vermutlich aber so um die 5. Was bei 5000 Concurrent-Usern eine ganze Menge werden kann. (Natürlich sind nicht alle in der gleichen Transaktion unterwegs
)Es sind auch mehrere verschiedene Aufrufe über eine Verbindung möglich, aber ich würde auf max. 3 schätzen.
Die Idee hatte ich schon weiter oben gepostet, aber trotzdem Danke!Dele hat geschrieben:RFC-Destinationen werden in der Tabelle RFCDES gespeichert. Man kann also alle erlaubten RFC Destinationen leicht ermitteln und ggf. noch Filtern auf nur die relevanten.
Mit dem Funktionsbaustein RFC_CONNECTION_IS_OPEN kann man prüfen, ob eine Verbindung offen ist und dann bei Bedarf schliessen.
Interessant! Das hab ich bislang übersehen bzw. nicht gekannt, bestätigt aber meine Vermutung, dass es da was geben muss um die Informationen die ich benötige zu ermitteln. Jetzt muss ich nur noch den Debugger debuggenDele hat geschrieben:Im Debugger kann man in dem Systembereich RFC auch erkennen welche RFC-Verbindungen geöffnet sind. Aber ob man an solche Systembereiche per ABAP herankommt ist fraglich.
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
Das wird dir gefallen. Die Objekte sind alle in dem Paket SWDP_ADT. Die Klassen heißen alle CL_ADT_*a-dead-trousers hat geschrieben:Jetzt muss ich nur noch den Debugger debuggen
lg ADT
Beitrag
von black_adept (Top Expert / 3946 / 105 /
886
)
»
Wenn du ein System ohne die von Enno genannten Klassen hast - schau mal in die Methode CL_TPDA_CONTROL=>IF_TPDA_CONTROL~GET_SYSTEM_AREA
Dort wird ein System-Call abgesetzt, der irgendwie die Daten füllt. Aber ob/wie du den aufrufen kannst um einen Dump zu vermeiden ?????
Dort wird ein System-Call abgesetzt, der irgendwie die Daten füllt. Aber ob/wie du den aufrufen kannst um einen Dump zu vermeiden ?????
Beitrag
von a-dead-trousers (Top Expert / 4282 / 214 /
1141
)
»
Schade, die Klassen gibts bei uns noch nichtewx hat geschrieben:Das wird dir gefallen. Die Objekte sind alle in dem Paket SWDP_ADT. Die Klassen heißen alle CL_ADT_*
Schaut vielversprechend aus. Meld mich wieder sobald ich mehr weiß.black_adept hat geschrieben:Wenn du ein System ohne die von Enno genannten Klassen hast - schau mal in die Methode CL_TPDA_CONTROL=>IF_TPDA_CONTROL~GET_SYSTEM_AREA
Dort wird ein System-Call abgesetzt, der irgendwie die Daten füllt. Aber ob/wie du den aufrufen kannst um einen Dump zu vermeiden ?????
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
Ich dachte, die SIND von DIR!!!a-dead-trousers hat geschrieben:Schade, die Klassen gibts bei uns noch nichtewx hat geschrieben:Das wird dir gefallen. Die Objekte sind alle in dem Paket SWDP_ADT. Die Klassen heißen alle CL_ADT_*
lg ADT
Beitrag
von a-dead-trousers (Top Expert / 4282 / 214 /
1141
)
»
Danke für die Blumen, aber ich arbeite nicht in Walldorf.ewx hat geschrieben:Ich dachte, die SIND von DIR!!!
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 a-dead-trousers (Top Expert / 4282 / 214 /
1141
)
»
Scheinbar lassen sich weder CL_TPDA_CONTROL noch der verwendete CALL 'TPD_CONTROL' außerhalb einer Debugger-Session verwenden.a-dead-trousers hat geschrieben:Schaut vielversprechend aus. Meld mich wieder sobald ich mehr weiß.black_adept hat geschrieben:Wenn du ein System ohne die von Enno genannten Klassen hast - schau mal in die Methode CL_TPDA_CONTROL=>IF_TPDA_CONTROL~GET_SYSTEM_AREA
Dort wird ein System-Call abgesetzt, der irgendwie die Daten füllt. Aber ob/wie du den aufrufen kannst um einen Dump zu vermeiden ?????
Selbst wenn ich die ProzessID mit TH_WP_DETAIL_INFO ermittle und übergebe kommt nix zurück.
Kennt zufällig wer das Pendant zu CL_TPDA_CONTROL im "klassischen" ABAP-Debugger? Ich vermute nämlich, dass TPD_CONTROL über die Interprozess-Kommunikation läuft und daher die Daten nicht lesen kann, weil ja ohne Debugger keine IPC aktiv ist. Der alte Debugger hingegen läuft ja (vermutlich) im aktuellen Prozessraum und dürfte daher "leichter" die Systembereiche auslesen können.
(Im "klassischen" Debugger im Menü unter Springen->Systembereiche->Interne Information)
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 a-dead-trousers (Top Expert / 4282 / 214 /
1141
)
»
Ach ja, ich bin euch ja noch die Lösung schuldig die ich jetzt umgesetzt hab:
Es ist bei RFC_CONNECTION_IS_OPEN geblieben. Ich selektiere einfach alle ABAP-RFC (Typ 3) Verbindungen die im System angelegt sind und rufe dann für jede einmal den FuBa auf. Ist gar nicht einmal so aufwändig wie ich ursprünglich gedacht hab.
Zu Testzwecken hab ich den Funktionsbaustein und alles was ich damit mache mit der Laufzeitanalyse ausgewertet:
Bei 500 abzufragenden Verbindungen und das 4-mal hintereinander durchgeführt, komme ich in diesem Bereich auf eine Laufzeit von knapp 3 - 4ms.
Das Erstaunliche ist, dass knapp 45% für den Funktionsbaustein-Aufruf draufgehen und weitere 30% für die Schleife (LOOP AT verbindungen).
Daher hab ich auch getestet wie es ausschaut wenn ich direkt den CALL 'RFCControl' aufrufe und siehe da die Laufzeit liegt dann bei 1 - 2ms. Wobei nun fast 60% für die Schleife benötigt werden. Also wird vermutlich der direkte Aufruf bleiben, da es ja darum geht die Performance zu verbessern. Aber das werden wir bei uns auch noch Entwicklungsintern klären.
Wie ist eure Meinung dazu? Besser den Baustein verwenden und Performanceeinbrüche riskieren oder direkt die schnelleren Systemkommandos verwenden und evtl. nicht releasesicher zu sein?
(Ich weiß 3ms Unterschied hört sich jetzt nicht nach viel an, aber wir haben 5.000 - 8.000 Concurent User und das System stöhnt zu den Spitzenzeiten schon ziemlich unter der Last; 80 - 90% CPU Auslastung)
lg ADT
Es ist bei RFC_CONNECTION_IS_OPEN geblieben. Ich selektiere einfach alle ABAP-RFC (Typ 3) Verbindungen die im System angelegt sind und rufe dann für jede einmal den FuBa auf. Ist gar nicht einmal so aufwändig wie ich ursprünglich gedacht hab.
Zu Testzwecken hab ich den Funktionsbaustein und alles was ich damit mache mit der Laufzeitanalyse ausgewertet:
Bei 500 abzufragenden Verbindungen und das 4-mal hintereinander durchgeführt, komme ich in diesem Bereich auf eine Laufzeit von knapp 3 - 4ms.
Das Erstaunliche ist, dass knapp 45% für den Funktionsbaustein-Aufruf draufgehen und weitere 30% für die Schleife (LOOP AT verbindungen).
Daher hab ich auch getestet wie es ausschaut wenn ich direkt den CALL 'RFCControl' aufrufe und siehe da die Laufzeit liegt dann bei 1 - 2ms. Wobei nun fast 60% für die Schleife benötigt werden. Also wird vermutlich der direkte Aufruf bleiben, da es ja darum geht die Performance zu verbessern. Aber das werden wir bei uns auch noch Entwicklungsintern klären.
Wie ist eure Meinung dazu? Besser den Baustein verwenden und Performanceeinbrüche riskieren oder direkt die schnelleren Systemkommandos verwenden und evtl. nicht releasesicher zu sein?
(Ich weiß 3ms Unterschied hört sich jetzt nicht nach viel an, aber wir haben 5.000 - 8.000 Concurent User und das System stöhnt zu den Spitzenzeiten schon ziemlich unter der Last; 80 - 90% CPU Auslastung)
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 black_adept (Top Expert / 3946 / 105 /
886
)
»
Hallo ADT,
nimm den Baustein.
Auch wenn ihr tierisch viel Last habt - ich kann mir kaum vorstellen, dass die Mehrlast, die durch den FuBa erzeugt wird auch nur irgendwo signifikant durchschlägt. Es sei denn euer gesamtes System besteht fast ausschließlich aus RFC-Aufrufen und diese sind fast all extrem kurz ( auch im ms-Bereich). Aber so ein System habe ich bisher nicht gesehen.
Und hattest du nicht irgendwo in einem deiner Vorpostings erwähnt, dass die offenen RFC-Verbindungen auch nicht 100% als der Problemfaktor identifiziert wurden sondern eher als "auch ein Kandidat" und vor allem wegen brennender Hüte im Management geschlossen werden sollen.
Alles Gründe für Releasesicherheit ggü. Geschwindigkeit.
nimm den Baustein.
Auch wenn ihr tierisch viel Last habt - ich kann mir kaum vorstellen, dass die Mehrlast, die durch den FuBa erzeugt wird auch nur irgendwo signifikant durchschlägt. Es sei denn euer gesamtes System besteht fast ausschließlich aus RFC-Aufrufen und diese sind fast all extrem kurz ( auch im ms-Bereich). Aber so ein System habe ich bisher nicht gesehen.
Und hattest du nicht irgendwo in einem deiner Vorpostings erwähnt, dass die offenen RFC-Verbindungen auch nicht 100% als der Problemfaktor identifiziert wurden sondern eher als "auch ein Kandidat" und vor allem wegen brennender Hüte im Management geschlossen werden sollen.
Alles Gründe für Releasesicherheit ggü. Geschwindigkeit.
Beitrag
von a-dead-trousers (Top Expert / 4282 / 214 /
1141
)
»
Tja, aber es ist halt um den Faktor 3 langsamer.
Ich glaub auch inzwischen nicht, dass es der Aufruf des Bausteins (allein) ist, sondern, dass der Fehlerfall "Verbindung ist nicht geöffnet" als Exception abgehandelt wird und die sind meines Wissens im Vergleich zu einem einfachen Rückgabewert immer um einiges aufwändiger in der Abarbeitung.
Leider kann ich nur auf einem relativ lastarmen System testen, daher weiß ich absolut nicht wie sich der Befehl im laufenden Betrieb auswirkt. Wir werden es wohl vorerst mit dem Baustein versuchen und auch hoffen, dass der System-Call darin den Kernel nicht zu sehr beansprucht.
Dann haben wir noch immer zwei Ersatzpläne: Direkter System-Call oder die aufwändige "bei jedem CALL FUNCTION ... DESTINATION" die verwendete Verbindung aufzeichnen.
lg ADT
Ich glaub auch inzwischen nicht, dass es der Aufruf des Bausteins (allein) ist, sondern, dass der Fehlerfall "Verbindung ist nicht geöffnet" als Exception abgehandelt wird und die sind meines Wissens im Vergleich zu einem einfachen Rückgabewert immer um einiges aufwändiger in der Abarbeitung.
Leider kann ich nur auf einem relativ lastarmen System testen, daher weiß ich absolut nicht wie sich der Befehl im laufenden Betrieb auswirkt. Wir werden es wohl vorerst mit dem Baustein versuchen und auch hoffen, dass der System-Call darin den Kernel nicht zu sehr beansprucht.
Dann haben wir noch immer zwei Ersatzpläne: Direkter System-Call oder die aufwändige "bei jedem CALL FUNCTION ... DESTINATION" die verwendete Verbindung aufzeichnen.
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
Vergleichbare Themen
0
Antw.
Antw.
1644
Views
Views
5
Antw.
Antw.
4723
Views
Views
Aufruf von BAPI_SALESORDER_SIMULATE
von Trulchen » 23.11.2016 08:39 • Verfasst in Sales and Distribution
von Trulchen » 23.11.2016 08:39 • Verfasst in Sales and Distribution
1
Antw.
Antw.
95
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.