RFC-/Webservice-Aufrufe feststellen
5 Beiträge
•
Seite 1 von 1
5 Beiträge
Seite 1 von 1
Hallo,
kennt jemand eine Lösung für dieses eigentlich sehr profane Problem:
Es geht um ein Z-Include in den Tiefen eines SAP-Programms, das an mehreren Stellen verwendet wird. Zusätzlich nutzt ein Funktionsbaustein diese Funktionalität, der per Webservice aufgerufen wird.
Nun hat sich ergeben, daß diese Funktionalität nicht mehr im Rahmen der Webanfrage genutzt werden soll, sondern nur noch im Rahmen der anderen Verwendungen.
Ich müsste also in dem Z-Include feststellen, wer da gerade das Coding ausführt.
Ist der folgende CALL die einzige (und sichere) Möglichkeit, das festzustellen?
CALL 'RFCControl' ID 'CODE' FIELD 'B'.
IF sy-subrc = 0.
*** running under RFC
ELSE.
Habe leider nicht wirklich die Möglichkeit, einen Webservice-Aufruf nicht-produktiv zu testen, darum meine Info-Sammlung zuerst...
Danke im Voraus!
Roddy
kennt jemand eine Lösung für dieses eigentlich sehr profane Problem:
Es geht um ein Z-Include in den Tiefen eines SAP-Programms, das an mehreren Stellen verwendet wird. Zusätzlich nutzt ein Funktionsbaustein diese Funktionalität, der per Webservice aufgerufen wird.
Nun hat sich ergeben, daß diese Funktionalität nicht mehr im Rahmen der Webanfrage genutzt werden soll, sondern nur noch im Rahmen der anderen Verwendungen.
Ich müsste also in dem Z-Include feststellen, wer da gerade das Coding ausführt.
Ist der folgende CALL die einzige (und sichere) Möglichkeit, das festzustellen?
CALL 'RFCControl' ID 'CODE' FIELD 'B'.
IF sy-subrc = 0.
*** running under RFC
ELSE.
Habe leider nicht wirklich die Möglichkeit, einen Webservice-Aufruf nicht-produktiv zu testen, darum meine Info-Sammlung zuerst...
Danke im Voraus!
Roddy
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 / 4395 / 223 /
1182
)
»
Eine andere Möglichkeit wäre es den Aufrufstack nach (nicht) erlaubten Programmen zu durchsuchen.
FuBa SYSTEM_CALLSTACK
Oder die sy-repid abfragen wenn das das Include einbindende Programm schon aussagekräftig genug ist.
FuBa SYSTEM_CALLSTACK
Oder die sy-repid abfragen wenn das das Include einbindende Programm schon aussagekräftig genug ist.
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
Roddy
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
wenn du weisst wie das include heisst, such doch den string mal mit dem Programm RPR_ABAP_SOURCE_SCAN
vielleicht bringt dir das auh noch etwas an Info wer das Include so verwendet..
gruss
ratsnus
vielleicht bringt dir das auh noch etwas an Info wer das Include so verwendet..
gruss
ratsnus
<:: XING-Gruppe Tricktresor::>
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
naja, der Verwendungsnachweis sollte schon ein entsprechend gutes ergebnis liefern.
(Nur halt nicht für dynamische Aufrufe oder in Smartforms)
(Nur halt nicht für dynamische Aufrufe oder in Smartforms)
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
Hallo zusammen und danke soweit,
ich löse das Problemchen mittels des FuBas SYSTEM_CALLSTACK - da der Z*-FuBa exklusiv vom Webservice aufgerufen wird, lasse ich die Funktionalität im Z-Include nur in dem Fall außen vor, wenn sich der besagte FuBa im Stack wiederfindet - denn dann war's eine Online-Anfrage.
AKTUALISIERUNG ->
TESTERGEBNIS:
Unerwartete Probleme - die RFC-Verbindung per Webservice hat (mir unerklärliche) Schwierigkeiten, den STACK korrekt zu lesen - weiß jemand etwas über ein "abweichendes" Verhalten bei Webserviceaufrufen?
Folgendes Coding steht im Z-Include Z_CHECK_KVGR2:
*****
DATA: gt_call_stack TYPE abap_callstack,
lv_fc_calling(1) VALUE ''.
CALL FUNCTION 'SYSTEM_CALLSTACK'
IMPORTING
callstack = gt_call_stack.
LOOP AT gt_call_stack TRANSPORTING NO FIELDS WHERE mainprogram CS 'Z_CHECK_KVGR2'.
lv_fc_calling = 'X'.
EXIT.
ENDLOOP.
IF lv_fc_calling = ''.
… dann Coding zur Nutzung bei Auftragsanlage oder sonstiges
*****
Der Test auf dem System war erfolgreich:
Sowohl der FuBa im Testmodus (FuBa wird im Stack gefunden und IF-Zweig wird NICHT durchlaufen)
als auch z. B. die Anlage eines Auftrags (VA01) funktioniert (FuBa ist nicht Aufrufer, wird also nicht gefunden und IF-Zweig
WIRD durchlaufen).
Sobald der FuBa aber über einen WebAccess-Dienst (XML) bzw. Webservice aktiviert wird, scheint obiges nicht mehr zu greifen – als ob der CALLSTACK leer wäre ...
Weiss jemand Rat?
ich löse das Problemchen mittels des FuBas SYSTEM_CALLSTACK - da der Z*-FuBa exklusiv vom Webservice aufgerufen wird, lasse ich die Funktionalität im Z-Include nur in dem Fall außen vor, wenn sich der besagte FuBa im Stack wiederfindet - denn dann war's eine Online-Anfrage.
AKTUALISIERUNG ->
TESTERGEBNIS:
Unerwartete Probleme - die RFC-Verbindung per Webservice hat (mir unerklärliche) Schwierigkeiten, den STACK korrekt zu lesen - weiß jemand etwas über ein "abweichendes" Verhalten bei Webserviceaufrufen?
Folgendes Coding steht im Z-Include Z_CHECK_KVGR2:
*****
DATA: gt_call_stack TYPE abap_callstack,
lv_fc_calling(1) VALUE ''.
CALL FUNCTION 'SYSTEM_CALLSTACK'
IMPORTING
callstack = gt_call_stack.
LOOP AT gt_call_stack TRANSPORTING NO FIELDS WHERE mainprogram CS 'Z_CHECK_KVGR2'.
lv_fc_calling = 'X'.
EXIT.
ENDLOOP.
IF lv_fc_calling = ''.
… dann Coding zur Nutzung bei Auftragsanlage oder sonstiges
*****
Der Test auf dem System war erfolgreich:
Sowohl der FuBa im Testmodus (FuBa wird im Stack gefunden und IF-Zweig wird NICHT durchlaufen)
als auch z. B. die Anlage eines Auftrags (VA01) funktioniert (FuBa ist nicht Aufrufer, wird also nicht gefunden und IF-Zweig
WIRD durchlaufen).
Sobald der FuBa aber über einen WebAccess-Dienst (XML) bzw. Webservice aktiviert wird, scheint obiges nicht mehr zu greifen – als ob der CALLSTACK leer wäre ...
Weiss jemand Rat?
Seite 1 von 1
Vergleichbare Themen
4
Antw.
Antw.
3735
Views
Views
11
Antw.
Antw.
2954
Views
Views
2
Antw.
Antw.
2246
Views
Views
Protokollierung RFC Aufrufe Schnittstellenparameter
von almialmi » 04.09.2006 15:48 • Verfasst in Basis
von almialmi » 04.09.2006 15:48 • Verfasst in Basis
4
Antw.
Antw.
2839
Views
Views
8
Antw.
Antw.
2965
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
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor einer Stunde von DeathAndPain 4 / 464
vor einer Stunde von DeathAndPain 4 / 464
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 einer Stunde von DeathAndPain 4 / 464
vor einer Stunde von DeathAndPain 4 / 464