[50825] in SAPr3-news
Re: ABAP-Anfängerfrage
daemon@ATHENA.MIT.EDU (ABAP-Entwickler)
Sun Jul 25 08:59:45 2004
To: sapr3-news@mit.edu
Date: Sun, 25 Jul 2004 15:00:40 +0200
From: "ABAP-Entwickler" <entwickler@versanet.de>
Message-ID: <4103aea4$1@olaf.komtel.net>
Hallo Roland,
es handelt sich um reine Kommunikation des Dynpros auf der SAPGUI mit Deinem
ABAP auf dem Server. Die Daten werden im Process-after-input (PAI) in deinen
ABAP-Arbeitsspeicher in die entsprechenden Felder transferiert.
Normalerweise am Anfang des PAI, es sein denn Du hast in der Ablauflogik
eine FIELD-Anweisung, dann eben erst später zu diesem Zeitpunkt. Das ist
wichtig zu wissen, weil Du in den PAI-Modulen eventuell auch auf veraltete
Speicherinhalte zugreifst, und nicht auf die im Dynpro aktuell eingegebenen
!
Das Speichern in der Datenbank ist ein ganz anderes Thema. Die Daten landen
absichtlich nicht sofort dort, denn sie müssen ja noch geprüft werden,
eventuell in mehreren Tabellen aufgeteilt werden , es sollen Änderungsbelege
erstellt werden, usw. Ausserdem willst Du die Daten ja erst speichern, wenn
jemand auf die Sichern-Taste drückt, oder ?
Zum Sichern kann man im Prinzip die Open-SQL-Anweisungen INSERT, UPDATE,
MODIFY und DELETE benutzen. Aber ganz so einfach sollte man sich das nicht
machen ! Wichtig ist, erst einmal die SAP-Transaktionlslogik zu verstehen.
Das Grundprinz ist so, dass auf der Datenbank bei jedem (!) Dynpro immer
automatisch ein Datenbank-Commit ausgeführt wird. Dies ist notwendig, damit
der Applikationsserver den Workprozess einem anderen Programm zuweisen kann,
während Dein Programm auf eine Benutzereingaben wartet. Du musst also alle
Daten im ABAP-Arbeitsspeicher in Strukturen und internen Tabellen sammeln.
Erst beim letzten Dynpro, wenn jemand "Sichern" drückt, schreibst Du die
Daten gesammelt auf die Datenbank.
Jetzt kommt die Sperrlogik in's Spiel: Die Daten die der Anwender sieht und
ändert müssen gesperrt werden, damit niemals zwei Leute gleichzeitig den
gleichen Datensatz ändern. Das macht man mit Sperrobjekten und den
ENQUEUE-Funktionsbausteinen. Die Sperre bleibt solange bestehen, bis Du den
Open-SQL-Befehl COMMIT WORK oder ROLLBACK WORK ausführst, oder einen
passenden DEQUEUE-Baustein aufrufst, oder eben das ABAP-Programm beendest.
Und um das alles zu verkompilizieren, sollte man die Datenbankänderungen gar
nicht im ABAP-Programm selbst ausführen, sondern dazu besser sogenannte
Verbucher benutzen. Das ist ein Funktionsbaustein, den Du extra dafür
programmierst. Er wird mit CALL FUNCTION '...' IN UPDATE TASK aufgerufen.
Diese Funktionsaufrufe stellt der Applikationsserver in eine Liste und führt
sie erst später auf, sobald der Befehl COMMIT WORK ausgeführt wird. Die
Verbuchung läuft asynchron in einem separaten Workprozess.
Ich würde empfehlen, diese von SAP vorgegebene Vorgehensweise in jedem Fall
zu verwenden, auch wenn Sie auf dem ersten Blick etwas kompiliziert
erscheint. Wenn man ein paar Anwendungen unter SAP für den
Mutli-User-Betrieb programmiert hat, erkennt man auch mit der Zeit die
deutlichen Vorteile und Notwendigkeiten. Ich habe auch noch kein von SAP
erstelltes Programm gesehen, dass nicht so arbeitet. Zu diesem Thema gibt es
natürlich auch noch ausführlichere Schulungen, der BC400 kann das ganze
Thema natürlich nur streifen.
Weiter viel Spass mit ABAP, Torsten.
"Roland Wester" <Roland.Wester@gmx.de> schrieb im Newsbeitrag
news:2m9oblFkmoobU1@uni-berlin.de...
> Hallo NG,
>
> bei Durcharbeit des Kurses BC400 bin ich auf ein Verständnisproblem
> gestoßen:
>
> Grundsätzliche Aufgabe: Über ein Dynpro werden Daten ausgegeben und
> Veränderungen zurückgeschrieben.
>
> Im ABAP wird mit TABLES ein Arbeitsbereich angelegt, der namensgleich mit
> der Dictionary-Struktur ist (hier sdyn_book). Die Felder im Dynpro
beziehen
> sich ebenfalls auf die Struktur (z.b sdyn_book-carrid). Durch die
> Namensgleichheit werden "die vom Benutzer eingegebenen oder veränderten
> Daten in das Datenobjekt zurückgestellt". Mit Datenobjekt ist die Struktur
> gemeint, denke ich. Soweit ok aber wie aber kommen die Daten von der
> Struktur (die ja auch nur eine Feldleiste/Arbeitsbereich ist) in die
> eigentliche Datenbanktabelle z.B. SPFLI ? Warum arbeitet man eigentlich in
> so einem Fall nicht mit internen Tabellen und schreibt die Änderungen per
> ABAP (UPDATE) in die Tabellen SPFLI & Co?
>
> Danke
> Roland
>
>
