Abfrage Messages nach call transaction

[Jonny2227]

Sali,

also die S-Message wird ja im Perform - Beleg_sichern - an dieser Stelle (siehe Coding) ausgegeben

...
if tvak-lisof eq space and vbap_korli eq space or
da_subrc_lf = 1.
if message_type = chari or cfm = charx.
message i311 with tvakt-bezei vbak-vbeln.
else.
message s311 with tvakt-bezei vbak-vbeln.
endif.
message_collect_lord.
else.

... nach der Ausgabe erfolgt also noch der Aufruf des Macro message_collect_lord - dort wird der FB -> APPL_LOG_WRITE_SINGLE_MESSAGE aufgerufen und in der FG gibt es noch den FB -> APPL_LOG_READ_INTERN - vielleicht hilft das ja an der Stelle irgendwie weiter das man an die S-Message kommt


Gruss Jens

[Ramon2764]

ist so zu verstehen:
bei einem "normalen" Call Transaction-Aufruf, also ohne die Übergabe einer Batch-Input-Tabelle über den Zusatz "...using bdc_tab", ist ein "... messages into messtab" nicht möglich. ( Ist laut Doku so und habe ich auch ausprobiert ).

Natürlich könnte ich das alles machen, aber meine Frage ist ja, ob es auch ohne geht. Zumal sich die Transaktion VA02 ja bestens über die Parameter vorbesetzen läßt.

[Jonny2227]

Sali,

also ich würde mir das - was ich in meinem Beitrag geschriebn habe dazu - mal noch anschauen - vielleicht passt das ja - denn der BAL_LOG_MSG_ADD wird nicht aufgerufen - das ist richtig aber dafür der APPL_LOG_WRITE_SINGLE_MESSAGE

Gruss Jens

[Ramon2764]

Hallo Jens,
Dein Ansatz war zumindest vielversprechend. Ich habe es versucht:

Der FuBa APPL_LOG_READ_INTERN kommt immer mit Returncode 1 zurück: object_not_found.

Ich gebe als Object das Objekt 'LORD' mit. Dieses wird ja auch mit dem FuBa APPL_LOG_WRITE_SINGLE_MESSAGE gesetzt.
Allerdings gelingt es mir keinesfalls, letzteren FuBa zu debuggen ( weil er in einem Makro aufgerufen wird? ), weder mit Session- noch externem Break-Point.

Desweiteren habe ich die FuBas
APPL_LOG_READ_DB und
APPL_LOG_DISPLAY_INTERN

ausprobiert, ebenfalls ohne Ergebnis für die VA02-Meldungen.

Eine auf den ersten Blick banale Angelegenheit ist also anscheinend doch komplexer.
Danke für Euer Interesse und Euer Mitwirken, hat auf jeden Fall mal wieder Spaß gemacht.
ich gebe mirch derweil mal mit der "B-Lösung" zufrieden ( ich hoffe, meine Anwender auch ).

( Oder zaubert jemand vielleicht doch noch das Kaninchen aus dem Hut? )

Beste Grüße, l.

[Fiona462]

Wenn der FuBa das Objekt 'LORD' nicht findet, leg es doch einfach mal an?!?! (falls möglich)

[Ilja583]

Natürlich könnte ich das alles machen, aber meine Frage ist ja, ob es auch ohne geht. Zumal sich die Transaktion VA02 ja bestens über die Parameter vorbesetzen läßt.

Hallo lucolan,

wenn es dir nur um die Theorie geht, dann kannst du das alles sicher irgendwie rausfinden - aber der Aufwand den du betreiben musst steht in keinem Verhältnis dazu einfach die Version mit "USING t_bdctab MESSAGES INTO t_messages" zu verwenden und dann aus der Messagetabelle auszulesen, ob nun die Meldung drin steht oder nicht. Und da du in beiden Fällen das Coding anpassen musst würde ich zu der einfachen Methodik greifen.

[Ramon2764]

... das ist vollkommen richtig. Aber meine Ausgangsvermutung war ja, das es eine einfache, elegante Lösung geben könnte. Erst diese Diskussion hat ja - bis jetzt - zum Vorschein gebracht, daß dem offenbar nicht so ist.
Ich finde, es hat sich trotzdem gelohnt, denn wenn es dazu eine elegante Lösung geben würde, wäre das ja sicher von allgemeinem Interesse und könnte für viele andere auch von Nutzen sein.

Beste Grüße, l.

[Ramon2764]

Und zu guter letzt, um das ganze abzurunden:

(@Jens:) Im Makro message_collect_lord passiert letztendlich auch nichts, weil im Coding des Makros:

if call_activity eq gc_activity_lord.
move-corresponding sy to mess.
call function 'APPL_LOG_WRITE_SINGLE_MESSAGE'
exporting
object = 'LORD'
message = mess.
endif.

die if-Bedingung nicht erfüllt ist: call_activity hat den Wert space und gc_activity_lord ist eine Konstante mit Wert 'LORD'. D.h.: APPL_LOG_WRITE_SINGLE_MESSAGE findet nicht statt, was erklärt, daß auch kein Objekt 'LORD' gefunden wird.

Die Frage ist also wirklich: Wie können Meldungen, die mit Typ 'S' abgesetzt wurden, ermittelt werden?

Dann noch eine Expertenfrage, in der ich mir selbst nicht sicher bin:

Beim CALL TRANSACTION läuft laut Doku die gerufene Transaktion in einer eigenen SAP- LUW ( Logical Unit of Work ). Läßt das nicht doch den Schluß zu, daß nach Rücksprung der Verbucher für diese LUW in jedem Fall durch ist? Quasi so, als würde ein CALL TRANSACTION using bdc_tab UPDATE 'S' für synchrone Verbuchung ausgeführt?
In meiner Praxis vor Ort ist der Verbucher auch immer durch, auch bei hoher Systemlast, wenn das System langsam arbeitet.

Gruß,l.

[Jonny2227]

Sali,

na das mit den Meldungen und dem Fuba Aufruf - hatte ich auch schon festgestellt
Was den Aufruf Call TA ... - angeht - das Verbucher durch ist ist nicht sicher und wenn es bei euch meist passt - dann ist es Glück - aber es hat auch Fälle das der Verbucher hängt oder so - daher kann die Datenänderung noch nicht durch sein und deine Daten passen dann echt nicht wenn du den Select machst. Daher wäre hier der Tip von EWX - CALL TRANSACTION einen SET UPDATE TASK LOCAL absetzt - der bessere Ansatz.

Gruss

[ewx]

Beim CALL TRANSACTION läuft laut Doku die gerufene Transaktion in einer eigenen SAP- LUW ( Logical Unit of Work ). Läßt das nicht doch den Schluß zu, daß nach Rücksprung der Verbucher für diese LUW in jedem Fall durch ist? Quasi so, als würde ein CALL TRANSACTION using bdc_tab UPDATE 'S' für synchrone Verbuchung ausgeführt?

Das ist ein Trugschluß! Die Verbuchung findet zwar in der gleichen LUW aber in einem separaten Verbucherprozeß statt. Auch ein COMMIT WORK AND WAIT ändert nichts daran, dass der Verbucher langsamer sein kann. Hier hilft nur ein vorheriges SET UPDATE TASK LOCAL.

In meiner Praxis vor Ort ist der Verbucher auch immer durch, auch bei hoher Systemlast, wenn das System langsam arbeitet.

Dann habt ihr evtl. ausreichend Verbuchungsprozesse. Wenn Dialog- und Updateprozesse beide gleichviel vorhanden sind, dann ist es im Prinzip egal. Wenn allerdings zu wenig Updateprozesse vorhanden sind, dann muss der Verbucher warten während die Transaktion bereits meldet: "Fertich."