[53497] in SAPr3-news
Re: BAPI-Aufruf Daten Ein-/Ausgang protokollieren?
daemon@ATHENA.MIT.EDU (Tibor Gerke)
Sat Feb 19 15:49:22 2005
To: sapr3-news@mit.edu
Date: Sat, 19 Feb 2005 21:51:05 +0100
From: Tibor Gerke <tibor.gerke@ebydos.com>
Message-ID: <cv88mo$f8c$05$1@news.t-online.com>
Matthias Laroche wrote:
> Hallo
>
> Patrick Theobald schrieb:
>
>> Das Tracing geht allerdings im Client-Programm recht detailliert. Die
>> RFC-Bibliotheken bieten solche Funktionen. Allerdings ist die erzeugte
>> Datei
>> recht kryptisch zu lesen und ist vermutlich nur für die Fehlersuche
>> gedacht.
>>
>> Was für ein Sinn hat diese Aktion denn, wenn ich fragen darf?
>
>
> Der Sinn liegt im Client, eine Java-Anwendung, welcher leider nicht
> detailliert protokollieren kann. Und die Entwickler dieser externen
> Anwendung wollen im Fehlerfall wissen, was die Anwendung geschickt und
> zurückbekommen hat.
Hallo Matthias,
schau Dir mal die Hinweise
532918 RFC Trace Generierungsszenarien
628962 Aktivierung des SAP JCo Trace
an.
Wie Patrick schon beschrieben hat, bieten die RFC-Bibliotheken eine
Möglichkeit, ein Trace-File zu generieren. Das ist im wesentlichen ein
habwegs lesbarer Dump der RFC-Kommunikation. Dazu müssen auf
Betriebssystemebene die Umgebungsvariblen RFC_TRACE und RFC_TRACE_DIR
gesetzt werden (532918).
Wenn das externe Programm eine Java-Anwendung ist, hilft vielleicht
Hinweis 628962 weiter. Die Java-Anwendung sollte den JCO zur
Kommunikaton mit dem SAP System benutzen. In der JVM lässt sich ein
Schalter setzen, damit der JCO (also ein Schicht höher als Möglichkeit
1) ein Trace-File schreibt. Das ist etwas lesbarer als der RFC-Trace,
es dürfte aber immer noch zuviel mitgeloggt werden. Der JCO baut in der
Regel ein Repository mit DDIC-Daten auf, so dass viele RFC-Aufrufe
protokolliert werden, die keine BAPI-Aufrufe sind (zumindest bei
Programmstart).
Eine dritte Möglichkeit wäre, im Client eine Protokollierung einzubauen.
Der JCO bietet dafür schöne Methoden an (writeXML, writeHTML), die man
vor und nach dem BAPI-Aufruf ausführen kann und genau die Daten liefern,
die Du haben möchtest.
Und wenn man man keinen Zugriff auf dem Quellcode des Client-Programm
hat, lässt sich evtl ein Proxy-Server mit dem JCO realisieren. Man
schreibt ein Programm, dass gegenüber dem Java-Client als RFC-Server und
gegenüber die Ziel-SAP-System als RFC-Client arbeitet. Das kann man im
Proxy-Programm ganz einfach writeXML, writeHTML ausführen und die
übergebenen Daten loggen. Das bricht aber das Transaktionskonzept der
ursprünglichen Java-Anwendung.
> auftreten). Bei 1,2 Millionen RFC-Aufrufe in der Stunde war uns das
1,2 Millionen RFC-Aufrufe in der Stunde auf Vorrat vernüpftig zu loggen
ist ziemlich schwierig ;-)
Grüsse,
Tibor
