Ansicht
Dokumentation

VENDOR_DYNAM_DATA_SELECTION - Ermitteln von Lieferanten-Daten für dynamisch übergebene Selektionsfelder

Vendor Master (General Section)   rdisp/max_wprun_time - Maximum work process run time  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Funktionalität

Zu den in der Tabelle IN_SELECT_FIELDS hinterlegten Selektionskriterien und unter Berücksichtigung der in den Key-Tabellen (z.B IN_LIFNR_KEYS, IN_BUKRS_KEYS, IN_EKORG_KEYS) zusätzlich hinterlegten Keyfeld-Selektionskriterien werden die in den zugeordneten Lieferantenstammtabellen vorhandenen Daten ermittelt und in den Ausgabetabellen (z.B. OUT_LFA1_TAB, OUT_LFB1_TAB, OUT_LFM1_TAB) zurückgeliefert.

Dabei besteht folgender Zusammenhang zwischen Key-Tabelle und zugeordneter Lieferantenstammtabelle:

• IN_LIFNR_KEYS dient zum Auslesen der Tabelle LFA1.

• IN_BUKRS_KEYS dient zum Auslesen der Tabelle LFB1.

• IN_EKORG_KEYS dient zum Auslesen der Tabelle LFM1.

Anhand der übergebenen Selektionskriterien in der Tabelle IN_SELECT_FIELDS wird pro betroffener Tabelle die WHERE-Bedingung für das entsprechende SELECT dynamisch aufgebaut. Da beliebige Selektionskriterien übergeben werden können, kann die zu selektierende Datenmenge sehr groß werden. Deshalb werden die Daten bei Bedarf blockweise an den Aufrufer zurückgegeben, damit dort mit einer verarbeitbaren Anzahl von Daten operiert werden kann.

Die Anzahl der in einem Lesevorgang zu verarbeitenden Lieferanten, kann über den Parameter IN_MAX_LIFNR vorgegeben werden. Der Parameter legt nicht fest, wieviele Datensätze letztendlich zurückgegeben werden. Die Anzahl der zurückgelieferten Datensegmente hängt davon ab, wieviele Datensegmente am Lieferanten hängen, die den gegebenen Selektionskriterien entsprechen. Dies muß beim Festlegen des Parameterwertes beachtet werden.

Wird ein blockweises Lesen durchgeführt, erfolgt der Aufruf des Funktionsbausteins jedesmal mit den gleichen Eingabedaten innerhalb einer Verarbeitungsschleife. Wenn die Daten zu den ersten IN_MAX_LIFNR Lieferanten selektiert wurden, werden diese an den Aufrufer zurückgeliefert. Außerdem wird der Parameter MORE_DATA_EXISTS gesetzt. Ist der Parameter nicht belegt, weiß der Aufrufer, daß keine weiteren Aufrufe des Funktionsbausteins notwendig sind, weil alle Daten selektiert werden konnten. Ist der Parameter belegt, muß der Funktionsbaustein nochmals aufgerufen werden. Beim ersten Aufruf des Funktionsbausteins muß der Parameter also immer vom Aufrufer initial übergeben werden, bei Folgeaufrufen mit gleichen Eingabedaten wird der zurückgelieferte Wert übergeben.

Zum blockweisen Lesen der Daten werden entsprechende Datenbank-Cursor geöffnet, die so lange offen bleiben, wie noch Daten selektiert werden können. Es darf deshalb im aufrufenden Programm kein COMMIT erfolgen, denn dadurch werden alle offenen Cursor geschlossen. Wird der letzte Datenblock gelesen, ist noch nicht bekannt, ob noch weitere Daten zu lesen sind. D.h. das Kennzeichen MORE_DATA_EXISTS ist gesetzt. Erst beim darauffolgenden Lesen erkennt das Programm, daß keine Daten mehr vorhanden sind und schließt den offenen Cursor. Deshalb dient der letzte Aufruf des Funtkionsbausteins im Prinzip nur zum korrekten Schließen der noch offenen Cursor. Daten werden keine mehr zurückgeliefert.

Es werden nur Daten zu den Tabellen zurückgegeben, für die der zugeordnete READ-Parameter (z.B. READ_LFA1_DATA, READ_LFB1_DATA, READ_LFM1_DATA) gesetzt ist. Evtl. kann es aufgrund der Selektionskriterien in der Tabelle IN_SELECT_FIELDS notwendig werden eine Tabelle zu lesen, obwohl die Daten zu dieser Tabelle nicht zurückgegeben werden sollen.

Über den Parameter JOIN_OPTION kann festgelegt werden, ob sich die selektierten Daten einer hierarchisch untergeordneten Tabelle auf die selektierten Daten der übergeordneten Tabelle auswirken sollen (OUTER-Join vs. INNER-Join).

Abhängig davon welche Daten zurückgeliefert werden sollen, wird das Lesen der Daten unterschiedlich durchgeführt.

1. Fall: Es sollen Daten zu hierarchisch abhängigen Tabellen ermittelt werden. In diesem Fall wird ein Cursor für die in der Hierarchie an oberster Stelle stehende Tabelle geöffnet (z.B. LFA1). Es wird der erste Block von Daten gelesen, die den vorgegebenen Selektionsbedingungen genügen. Mit der Liste der gefundenen Sätze aus der in der Hierarchie oben stehenden Tabelle werden anschließend die Daten der untergeordneten Tabellen ermittelt. Wurde über den Parameter JOIN_OPTION ein INNER-Join ausgewählt, müssen in den übergeordneten Datensegmenten alle Einträge entfernt werden, zu denen es in den untergeordneten Datensegmenten keine Einträge gibt.
2. Fall: Es sollen Daten zu hierarchisch unabhängigen Tabellen (z.B. LFB1 und LFM1) ermittelt werden. In diesem Fall wird für die, in der jeweiligen Hierarchie oben stehende Tabelle ein Cursor geöffnet (es würde ein Cursor für LFB1 und ein Cursor für LFM1 geöffnet werden). Nacheinander werden dann die Daten blockweise gelesen. Sind auch untergeordnete Tabellen zu berücksichtigen, greift das im ersten Fall beschriebene Vorgehen.
3. Fall: Es sollen Daten zu Tabellen ermittelt werden, die hierarchisch unabhängig voneinander sind, und zu denen es keine abhängigen Tabellen gibt. In diesem Fall wird für jede Tabelle ein Cursor geöffnet und die Daten werden nacheinander blockweise gelesen, solange, bis keine weiteren Daten gefunden werden. Der Parameter JOIN_OPTION hat in diesem Fall keine Auswirkungen.

Beispiel

Hinweise

Da beliebige Felder zur Selektion dienen können, müssen u.U. beim Anwender entsprechende Indizes angelegt werden, die eine performante Datenselektion gewährleisten, wenn nur Felder angesprochen werden, die nicht über den Primär-Index oder bereits vorhandene Sekundär-Indizes abgehandelt werden können.

Weiterführende Informationen

Weitergehende Informationen findet man evtl. im Langtext des entsprechenden Schnittstellen-Parameters.

Parameter

IN_BUKRS_KEYS
IN_EKORG_KEYS
IN_LIFNR_KEYS
IN_MAX_LIFNR
IN_SELECT_FIELDS
JOIN_OPTION
MORE_DATA_EXISTS
OUT_LFA1_TAB
OUT_LFB1_TAB
OUT_LFM1_TAB
READ_LFA1_DATA
READ_LFB1_DATA
READ_LFM1_DATA

Ausnahmen

WRONG_INPUT_DATA

Funktionsgruppe

WYSE

rdisp/max_wprun_time - Maximum work process run time   Vendor Master (General Section)  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 7607 Date: 20240523 Time: 041308     sap01-206 ( 163 ms )