Ansicht
Dokumentation

AS_API_READ - Lesen von Daten aus dem Archivinformationssystem

BAL_S_LOG - Application Log: Log header data Vendor Master (General Section)
Diese Dokumentation steht unter dem Copyright der SAP AG.

Funktionalität

Mit dem Funktionsbaustein AS_API_READ können Sie auf die Daten des Archivinformationssystems (AS) zugreifen. Nach der Übergabe von Selektionsbedingungen an den Funktionsbaustein liefert dieser die passenden Inhalte aus einer Archivinformationsstruktur zurück. Ein wesentlicher Teil dieser Inhalte ist die Archivdatei und der Offset. Diese ermöglichen mit Hilfe des Funktionsbausteins AS_API_READ die Implementierung eines indexgestützten Zugriffs auf archivierte Daten.

Damit lässt sich beispielsweise ein schneller automatischer Archivzugriff innerhalb einer Anwendungsfunktion realisieren. Ohne eine Schnittstelle zum Archivinformationssystem müssten dazu eigene Indexlösungen entwickelt werden. Der Funktionsbaustein AS_API_READ selbst führt keine Archivzugriffe durch. Er ermittelt lediglich die Information darüber, an welcher Stelle im Archiv ein bestimmtes Datenobjekt zu finden ist. Die eigentlichen Archivzugriffe erfolgen dann mit den üblichen Funktionsbausteinen des Archive Development Kit (ADK), wie zum Beispiel ARCHIVE_READ_OBJECT und ARCHIVE_GET_TABLE.

Beispiel

Im Folgenden wird ein einfaches Beispiel zur Verwendung des Funktionsbausteins AS_API_READ gezeigt. In diesem Beispiel werden Datenobjekte ermittelt, in denen Buchungen von Rauchern für Flüge am 7.9.1998 enthalten sind. Dem Beispiel liegt der folgende Feldkatalog mit den Namen "DEMO_SBOOK" zu Grunde:

Zielfeld	Quelltabelle	Referenzfeld
CARRID	SBOOK	CARRID
CONNID	SBOOK	CONNID
FLDATE	SBOOK	FLDATE
CLASS	SBOOK	CLASS
BOOKID	SBOOK	BOOKID
SMOKER	SBOOK	SMOKER

Ausgehend von diesem Feldkatalog bietet sich folgendes Coding an:

    DATA: BEGIN OF g_sbook,
            smoker LIKE sbook-smoker,
            fldate LIKE sbook-fldate,
          END OF g_sbook,
          gt_result TYPE TABLE OF aind_arkey.
    g_sbook-smoker = 'X'.
    g_sbook-fldate = '19980907'.

    CALL FUNCTION 'AS_API_READ'
      EXPORTING
        i_fieldcat   = 'DEMO_SBOOK'
        i_selections = g_sbook
      IMPORTING
        e_result     = gt_result[].

Dieses Coding-Fragment bedeutet im Wesentlichen Folgendes:

Finde eine passende Infostruktur zum Feldkatalog DEMO_SBOOK

Ermittle aus dieser Infostruktur alle Sätze mit SMOKER = 'X' und FLDATE = '19980907'

Liefere die Archivdatei und den Offset der gefundenen Sätze zurück.

Diese Art des Zugriffs ist insbesondere für Einzelobjektzugriffe, wie zum Beispiel das Auffinden von Belegen bei bekannter Belegnummer, meistens schon ausreichend.

Ermittlung der Infostruktur

Der Funktionsbaustein AS_API_READ erlaubt nicht die direkte Eingabe einer Infostruktur, sondern nur eines Feldkatalogs. Meist gibt es zu einem Feldkatalog nur eine wirklich produktiv genutzte Infostruktur, sodass die Wahl der passenden Infostruktur eigentlich nur theoretisch eine Rolle spielt. Allerdings kommt es - gerade während der Entwicklung oder Testphase - vor, dass mehrere aktive Infostrukturen zu einem bestimmten Feldkatalog existieren. Diese Infostrukturen sind gegebenenfalls für unterschiedliche Archivdateien aufgebaut, so dass sie unterschiedliche Daten enthalten. Der Funktionsbaustein AS_API_READ wählt dann unter Umständen eine Infostruktur, die die gewünschten Daten nicht enthält, obwohl eine andere Infostruktur aktiv ist, die die gewünschten Daten enthält. In diesem Fall liefert das System keine Daten zurück, obwohl die gesuchten Daten prinzipiell im Archivinformationssystem enthalten sind.
Da in der Regel etwas schwer zu durchschauen ist, wie der Funktionsbaustein AS_API_READ die Infostruktur ermittelt, aus der die Daten gelesen werden, soll dieser Vorgang hier näher erläutert werden.

Das System ermittelt alle aktiven Infostrukturen zum Feldkatalog (I_FIELDCAT). Falls keine solche Infostruktur existiert, wird die Ausnahme NO_INFOSTRUC_FOUND ausgelöst.
Falls im Parameter I_OBLIGATORY_FIELDS etwas übergeben wurde, werden nur solche Infostrukturen weiter berücksichtigt, die alle obligatorischen Felder enthalten. Falls keine solche Infostruktur existiert, wird die Ausnahme NO_INFOSTRUC_FOUND ausgelöst.
Falls im Parameter I_EXCLUDED_FIELDS Feldnamen übergeben wurden, werden Infostrukturen, die eines dieser Felder enthalten, bei der Selektion nicht berücksichtigt.

Ab hier gibt es auf jeden Fall eine passende aktive Infostruktur. Möglicherweise gibt es jedoch mehrere passende Infostrukturen, so dass eine weitere Auswahl getroffen wird.

Es werden nur die Infostrukturen weiter berücksichtigt, die die maximale Anzahl an Selektionsfeldern enthalten. Als Selektionsfelder gelten alle Felder aus I_SELECTIONS, die auch im Feldkatalog enthalten sind.
Falls jetzt immer noch mehrere Infostrukturen in Frage kommen, dann werden davon nur die mit den meisten Ergebnisfeldern betrachtet. Ergebnisfelder sind hier die Felder, die in E_RESULT und im Feldkatalog vorkommen.
Kommt weiterhin mehr als eine Infostruktur in Frage, führt das System eine Gewichtung der Selektionsfelder nach deren Reihenfolge in I_SELECTIONS durch. Infostrukturen, die das erste Selektionsfeld enthalten, gelten dann als passender als solche, die das erste Selektionsfeld nicht enthalten, usw.
Sollten auch jetzt noch mehrere Infostrukturen in Frage kommen, dann sind sich diese sehr ähnlich. In einem solchen Fall wird von den verbleibenden Infostrukturen eine beliebige gewählt.

Die Ermittlung der Infostruktur ist rein regelbasiert. Die Anzahl der Einträge in der Infostruktur oder Ähnliches wird dabei nicht in Betracht gezogen. Das System liest immer nur von einer einzelnen Infostruktur, auch wenn mehrere zur Selektion geeignet wären.

Jede Infostruktur enthält außer Feldern, die aus dem zugrundeliegenden Feldkatalog ausgewählt wurden, drei weitere Felder, nämlich Mandant (MANDT), Archivdatei (ARCHIVEKEY) und Offset (ARCHIVEOFS).

ILM Retention Warehouse Szenario

Ab SAP NetWeaver 7.02 können Infostrukturen zwei weitere Felder enthalten, nämlich ORIGINAL_SYSID (Name des SAP-Originalsystems im ILM) und ORIGINAL_CLIENT (Mandant des SAP-Originalsystems im ILM). Die beiden Felder sind nur für das Retention-Warehouse-Szenario vorgesehen. Bei Nutzung dieser Funktionalität sollten Sie mit diesem Szenario vertraut sein.

Damit AS_API_READ Infostrukturen mit ORIGINAL_SYSID und ORIGINAL_CLIENT ermitteln kann, müssen folgende Bedingungen erfüllt sein:

I_SELECTIONS muss die beiden Felder enthalten.
Diese beiden Felder müssen auch dem Importparameter I_OBLIGATORY_FIELDS übergeben werden.

Die Felder sind vom Typ admi_run-sysid (ORIGINAL_SYSID) und admi_run-original_client (ORIGINAL_CLIENT).

Hinweise

Da der Funktionsbaustein AS_API_READ generische (nicht typisierte) Parameter hat, kann er in der Testumgebung für Funktionsbausteine (SE37-> "Ausführen") nicht getestet werden. Zum Testen des Bausteins muss man sich daher immer ein Programm schreiben.

Weiterführende Informationen

Weitere Informationen zum Archivinformationssystem und zum Funktionsbaustein AS_API_READ finden Sie über den Hinweis 671421. Das dort referenzierte Dokument "AS_API_READ - Programmierte Zugriffe auf das AS" enthält unter Anderem weitere Beispiele zur Verwendung und zur Vermeidung typischer Fehler.

Parameter

E_RESULT
I_EXCLUDED_FIELDS
I_FIELDCAT
I_MAXROWS
I_OBLIGATORY_FIELDS
I_SELECTIONS

Ausnahmen

FIELD_MISSING_IN_FIELDCAT
NO_INFOSTRUC_FOUND
PARAMETERS_INVALID

Funktionsgruppe

AS_API

SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 10687 Date: 20240523 Time: 133326 sap01-206 ( 162 ms )

Ansicht Dokumentation