Programmlogik

Innerhalb des Dialogablaufes wurden vom BDT fest definierte Zeitpunkte eingeführt, zu denen die Anwendungen eigene Programmlogik in Form von Funktionsbausteinen entwickeln können. Je Zeitpunkt können die Namen mehrerer Funktionsbausteine hinterlegt werden, die vom BDT automatisch aufgerufen werden.

Abbildung 1 gibt einen Überblick über den Ablauf beim Dialog. Die Zeitpunkte sind am dunkleren Hintergrund zu erkennen.

Menüpfad: Steuerung <Objekt Anfang des Navigationspfads > Navigationsschritt Zeitpunkte Ende des Navigationspfads

Im folgenden werden die wichtigsten Zeitpunkte für den Dialog detailliert beschrieben:

  • ISSTA (Initialisierung)

    Die Anwendungen initialisieren ihre globalen Variablen und holen sich vom BDT die für sie wichtigen Steuerinformationen. Außerdem können hier Vorbelegungen für das Einstiegsbild vorgenommen werden

    Aufrufzeitpunkt: Vor dem Einstiegsbild, der Zeitpunkt wird auch beim Wechsel der Aktivität auf dem Einstiegsbild prozessiert.

    Anwenderkreis: Alle Anwendungen

    Namenskonvention: <Anwendung>_<Anwendungsobjekt>_EVENT_ISSTA

    (Kunde: Funktionsbausteinname erhält zusätzlich das Präfix Y_ oder Z_ )

    Beispiele:

    • BUP_BUPA_EVENT_ISSTA

    • FI_BUPA_EVENT_ISSTA

      Aktionen:

    • Globale Variablen der Funktionsgruppe initialisieren

    • Steuerinformationen vom BDT holen wie

      • Aktivität

      • Bearbeitungsmodus (Sichern- oder Übernehmen-Modus)

      • Kennzeichen: Einstiegsbild anzeigen

      • selektierte Rollen/Rollengruppierungen

      • zu bearbeitende Rollen (ergeben sich aus selektierten Rollen/Rollengruppierungen)

      • u.a.

        Rufen Sie dazu den BDT-Funktionsbaustein BUS_PARAMETERS_ISSTA_GET auf und merken Sie sich die Informationen in globalen Variablen Ihrer Funktionsgruppe.

    • Vorbelegungen für die Felder des Einstiegsbildes vornehmen

      • Vorbelegungswerte mit Hilfe des BDT-Funktionsbausteins BUS_PARAMETERS_ISSTA_GET lesen (Schnittstellentabelle T_FLDVL)

      • Falls zu einem Feld Vorbelegungswerte übergeben wurden, sollten diese in die entsprechenden Dynprofelder übernommen werden

      • Wurde zu einem Feld kein Vorbelegungswert übergeben, sollte - falls vorhanden - der SET/GET-Parameter gelesen werden

  • ISDAT (Daten lesen)

    Die tabellenbesitzenden Anwendungen (nicht die partizipierenden Anwendungen!) lesen ihre Tabellen und merken sich diese Daten innerhalb ihres Aktualgedächtnisses sowohl als neuen als auch als alten Stand.

    Einige Anwendungstabellen müssen allerdings bereits in den PAI-Funktionsbausteinen zu den Sichten der Einstiegsbilder gelesen werden, um die dort notwendigen Feldprüfungen durchzuführen. Diese Tabellen müssen dann zu ISDAT nicht mehr nachgelesen werden.

    Aufrufzeitpunkt: Zwischen Einstiegsbild und erstem Datenbild

    Anwenderkreis: Tabellenbesitzende Anwendungen

    Namenskonvention: <Anwendung>_<Anwendungsobjekt>_EVENT_ISDAT

    (Kunde: Funktionsbausteinname erhält zusätzlich das Präfix ‚Y_‘ oder ‚Z_‘)

    Beispiele:

    • BUP_BUPA_EVENT_ISDAT

    • FI_BUPA_EVENT_ISDAT

      Aktionen:

    • Daten anderer Tabellen ermitteln, falls diese zum Lesen der eigenen Tabellen benötigt werden. Dazu können die Kommunikationsbausteine zum Lesen einer Tabelle verwendet werden.

    • Eigene Anwendungstabellen lesen.

      • Nachlesen im Gesamtgedächtnis, wenn die Daten zur aktuellen Instanz in dieser LUW schon einmal gemerkt wurden (Übernehmen-Modus).

      • Wurden in dieser LUW die Daten zur aktuellen Instanz noch nicht übernommen, werden diese von der Datenbank gelesen.

    • Daten im Aktualgedächtnis merken als alten und als neuen Stand der aktuellen Instanz

    • Vorläufige Nummer ziehen (bei Anlegen mit interner Nummernvergabe). Diese Nummer wird zum Zeitpunkt DSAVC durch die endgültige Nummer ersetzt.

    • Dynprofeldwerte für Felder besonderer Datentypen bestimmen, falls die Prüfung nicht direkt auf dem Dynpro erfolgen soll (siehe Bildaufbau , Sichten).

  • ISDST (Daten verteilen)

    Die tabellenpartizipierenden Anwendungen ermitteln den Inhalt der Tabelle mit Hilfe des Funktionsbausteins zum Lesen der Daten. Die Daten werden als alter und als neuer Stand im Aktualgedächtnis der partizipierenden Anwendung gemerkt.

    Aufrufzeitpunkt: Zwischen Einstiegsbild und erstem Datenbild.

    Anwenderkreis : Tabellenpartizipierende Anwendungen.

    Namenskonvention : <Anwendung>_<Anwendungsobjekt>_EVENT_ISDST

    (Kunde: Funktionsbausteinname erhält zusätzlich das Präfix ‚Y_‘ oder ‚Z_‘).

    Aktionen :

    • Daten zur Tabelle ermitteln von der tabellenbesitzenden Anwendung mit Hilfe des Funktionsbausteins zum Lesen der Daten.

    • Daten im Aktualgedächtnis merken als alten und als neuen Stand.

  • XCHNG (Daten verändert?)

    Versucht der Anwender, die Datenpflege zu verlassen, muß ein Abfragepopup erscheinen, wenn die Daten verändert wurden. Innerhalb dieses Zeitpunktes ermittelt das BDT, ob Daten verändert wurden.

    Dieser Zeitpunkt wird nur bei der Aktivität Ändern prozessiert. Bei der Aktivität Anlegen erfolgt die Abfrage immer, während bei der Aktivität Anzeigen keine Daten verändert werden können und eine Abfrage deshalb nicht notwendig ist.

    Aufrufzeitpunkt: Beim Verlassen der Datenpflege (nur Aktivität ‚Ändern‘).

    Anwenderkreis: Alle Anwendungen.

    Namenskonvention: <Anwendung>_<Anwendungsobjekt>_EVENT_XCHNG

    (Kunde: Funktionsbausteinname erhält zusätzlich das Präfix ‚Y_‘ oder ‚Z_‘).

    Beispiele:

    • BUP_BUPA_EVENT_XCHNG

    • FI_BUPA_EVENT_XCHNG

      Aktionen:

    • Alten und neuen Stand des Aktualgedächtnisses vergleichen.

    • Ergebnis, ob Daten verändert wurden, an BDT zurückgeben.

  • DCHCK (Prüfungen vor dem Sichern)

    Vor dem Sichern der Daten kann jede Anwendung noch Konsistenzprüfungen durchführen. Eventuelle Meldungen erscheinen innerhalb eines Popups. Wird in diesem Zeitpunkt eine Fehlermeldung ausgelöst, ist das Sichern der Daten nicht möglich, bis der Fehler bereinigt ist.

    Aufrufzeitpunkt: Beim Sichern der Daten.

    Anwenderkreis: Alle Anwendungen

    Namenskonvention: <Anwendung>_<Anwendungsobjekt>_EVENT_DCHCK

    (Kunde: Funktionsbausteinname erhält zusätzlich das Präfix ‚Y_‘ oder ‚Z_‘)

    Aktionen:

    • Konsistenzprüfungen ausführen und eventuell Meldungen über Message-Handler ausgeben.

  • DSAVB (Daten sammeln)

    Die tabellenpartizipierenden Anwendungen übergeben den neuen Datenstand aus ihrem Aktualgedächtnis an die tabellenbesitzende Anwendung. Dazu rufen sie den Tabellenfunktionsbaustein zum Sammeln der Daten auf.

    Aufrufzeitpunkt: Beim Sichern der Daten.

    Anwenderkreis: Tabellenpartizipierende Anwendungen

    Namenskonvention: <Anwendung>_<Anwendungsobjekt>_EVENT_DSAVB

    (Kunde: Funktionsbausteinname erhält zusätzlich das Präfix ‚Y_‘ oder ‚Z_‘)

    Aktionen:

    • Neue Daten aus dem Aktualgedächtnis an tabellenbesitzende Anwendung übergeben. Dazu wird der für die Tabelle hinterlegte Funktionsbaustein zum Sammeln der Daten aufgerufen

  • DTAKE (Daten übernehmen ins LM)

    Das Sichern der Daten läuft beim BDT in mehreren Schritten ab. Die Daten mehrerer Instanzen können gemeinsam gesichert werden, was sowohl beim Übernehmen-Modus als auch bei der Pflege im Hintergrund genutzt wird. In diesem ersten Schritt schreibt die tabellenbesitzende Anwendung die Daten aus ihrem Aktualgedächtnis in ihr Gesamtgedächtnis.

    Aufrufzeitpunkt: Beim Sichern der Daten.

    Anwenderkreis: Tabellenbesitzende Anwendungen.

    Namenskonvention: <Anwendung>_<Anwendungsobjekt>_EVENT_DTAKE

    (Kunde: Funktionsbausteinname erhält zusätzlich das Präfix ‚Y_‘ oder ‚Z_‘).

    Beispiel: BUP_BUPA_EVENT_DTAKE

    Aktionen:

    • Neue Daten aus dem Aktualgedächtnis in das Gesamtgedächtnis für neue Daten schreiben.

    • Alte Daten aus dem Aktualgedächtnis in das Gesamtgedächtnis für alte Daten schreiben, falls die Daten zu dieser Objektinstanz in dieser LUW erstmals gemerkt werden.

      Hinweis: Zum Zeitpunkt DSAVE wird das Gesamtgedächtnis pro Instanz daraufhin überprüft, ob Änderungen stattgefunden haben und die Daten deshalb auf die Datenbank geschrieben werden müssen. Der alte Stand des Gesamtgedächtnisses muß deshalb dem alten Stand des Aktualgedächtnisses entsprechen, das dieses beim erstmaligen Merken der Daten innerhalb der LUW hatte.

  • DSAVC (Daten vervollständigen)

    Das Gesamtgedächtnis wird vorbereitet für das Speichern der Daten auf der Datenbank. Alle Aktionen, bei denen noch Fehler auftreten können, müssen hier durchgeführt werden. Innerhalb des Zeitpunktes DSAVE darf es dagegen nur aufgrund von Dateninkonsistenzen bzw. Programmfehlern zu Abbruchmeldungen kommen.

    Aufrufzeitpunkt: Beim Sichern der Daten.

    Anwenderkreis: Tabellenbesitzende Anwendungen

    Namenskonvention: <Anwendung>_<Anwendungsobjekt>_EVENT_DSAVC

    (Kunde: Funktionsbausteinname erhält zusätzlich das Präfix ‚Y_‘ oder ‚Z_‘)

    Beispiel: BUP_BUPA_EVENT_DSAVC

    Aktionen:

    • Objektnummer ziehen (nur beim Anlegen mit interner Nummernvergabe)

    • Vorläufige Nummer (siehe Zeitpunkt ISDAT) ersetzen durch die soeben gezogene Nummer

  • DSAVE (Daten sichern auf der DB)

    Die tabellenbesitzende Anwendung schreibt die Daten aus dem Gesamtgedächtnis auf die Datenbank. Aufgrund der besseren Laufzeit speziell beim Direct Input sollte dort immer mit Array-Operationen gearbeitet werden.

    Aufrufzeitpunkt: Beim Sichern der Daten.

    Anwenderkreis: Tabellenbesitzende Anwendungen

    Namenskonvention: <Anwendung>_<Anwendungsobjekt>_EVENT_DSAVE

    (Kunde: Funktionsbausteinname erhält zusätzlich das Präfix ‚Y_‘ oder ‚Z_‘)

    Beispiel: BUP_BUPA_EVENT_DSAVE

    Aktionen:

    • Neue Daten aus dem Gesamtgedächtnis auf die Datenbank schreiben. Das BDT gibt über einen Parameter des Funktionsbausteins BUS_PARAMETERS_ISSTA_GET vor, ob dies mit oder ohne Verbucher geschehen soll.

    • Änderungsbelege schreiben mit Hilfe des alten und des neuen Standes aus dem Gesamtgedächtnis.

    • Erfolgsmeldung ausgeben (nur anwendungsobjektbesitzende Anwendung).

  • DLVE1 (Aktualgedächtnis initialisieren)

    Das Aktualgedächtnis wird initialisiert. Bei der Rückkehr auf das Einstiegsbild erfolgt kein (!) LEAVE TO TRANSACTION, so daß für den korrekten Start der nächsten Datenpflege das Aktualgedächtnis zu diesem Zeitpunkt initialisiert werden muß. Die anwendungsobjektbesitzende Anwendung hebt die Sperre auf.

    Aufrufzeitpunkt: Beim Verlassen der Datenpflege.

    Anwenderkreis: Alle Anwendungen.

    Namenskonvention: <Anwendung>_<Anwendungsobjekt>_EVENT_DLVE1.

    (Kunde: Funktionsbausteinname erhält zusätzlich das Präfix ‚Y_‘ oder ‚Z_‘).

    Beispiel: BUP_BUPA_EVENT_DLVE1

    Aktionen:

    • Aktualgedächtnis initialisieren.

    • Sperre für aktuelle Instanz aufheben (nur anwendungsobjektbesitzende Anwendung).

  • DLVE2 (Gesamtgedächtnis initialisieren)

    Aufrufzeitpunkt: Beim Verlassen der Datenpflege.

    Beschreibung: Das Gesamtgedächtnis wird initialisiert.

    Anwenderkreis: Alle Anwendungen.

    Namenskonvention: <Anwendung>_<Anwendungsobjekt>_EVENT_DLVE2

    (Kunde: Funktionsbausteinname erhält zusätzlich das Präfix ‚Y_‘ oder ‚Z_‘).

    Beispiel: BUP_BUPA_EVENT_DLVE2

    Aktionen:

    • Gesamtgedächtnis initialisieren.