Ansicht
Dokumentation

BANK_API_CHDOC_PREPARE_HISTORY - API: Historientabellen aufbereiten

CL_GUI_FRONTEND_SERVICES - Frontend Services   General Material Data  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Funktionalität

Dieser Funktionsbaustein sollte für Neuentwicklungen nicht mehr verwendet werden. Verwenden Sie statt dessen das Interface IF_CDV_COLLECT zum Sammeln von Änderungsbelegen.

In Historientabellen wird die Historie eines Objektes festgehalten. Der Funktionsbaustein erstellt aus solchen Historientabellen Änderungsbelege. Diese Änderungsbelege existieren temporär, d.h. sie werden nicht auf die Datenbank geschrieben. Das Ergebnis sind gelesenen Änderungsbelege, die in der internen Tabelle des Parameters C_TAB_CHDOCREAD abgelegt sind.

Mittels des Parameters C_TAB_HISTORY_ATTACH beschreiben Sie die Historientabellen. Sie können also in einem Schritt mehrer Historientabellen aufbereiten lassen. Jeder Zeile der internen Tabelle beschreibt eine Historientabelle. Für das Versorgen der Felder der Tabellenzeile sind zwei Fälle zu betrachten.

• Für die Historientabelle werden keine Änderungsbelege geschrieben, d.h. es wurde kein Änderungsbelegobjekt angelegt.

• OBJECTCLAS

fiktives Änderungsbelegobjekt, welches jedoch über alle in diesem Verarbeitungsschritt anzuzeigenden Änderungsbelege unikat sein muss.

• OBJECTCLASTEXT

Beschreibung des fiktiven Änderungsbelegobjektes.

• OBJECTID

gewünschter Objektwert, zu dem die Änderungsbelege erzeugt werden

• OBJECTIDTEXT

Aufbereiteter Objektwert, wenn er nicht vom Tool ermittelt werden soll

• REF_TO_HISTORY

Verweis auf die interne Tabelle mit den Historien

Liegt der internen Tabelle eine Struktur zu Grunde, sollte sie die Struktur BANK_STR_CD_HISTORY_CHANGEDATA mit den Änderungsinformationen inkludieren. Sollen beim Erstellen der Änderungsbelege Gültigkeitsinformationen dargestellt werden, so sind sie in den Feldern der Struktur BANK_STR_CD_HISTORY_VALIDITY abzulegen, die ebenfalls nur in diesem Fall mit in die Struktur der Historie eingebunden werden muss. Die Schlüsselfelder sind in der richtigen Reihenfolge am Anfang der Struktur der Historie zu platzieren und in der Definition des Tabellentyps als Schlüsselfelder zu kennzeichnen.

Es empfiehlt sich nicht die Datenbanktabelle, in der die Historie auf der Datenbank gespeichert ist, als Grundlage für die interne Tabellen zu verwenden, sondern eine geeignete Struktur anzulegen. In dieser Struktur sollten dann alle Schlüsselfelder, alle änderungsbelegrelevanten Felder, die Änderungsinformationen und bei Bedarf die Gültigkeitsinformationen abgelegt sein.

• REF_TO_HISTORY_CHANGEDATA

Verweis auf die interne Tabelle mit Änderungsinformationen zur Historie; i.d.R. in diesem Fall nicht notwendig, da die Änderungsinformationen in der Historie angegeben werden können.

• OBJECTKEYSTRUC

Name der Struktur , in der die Felder des Objektwertes beschrieben sind

• FOR_ALL_FIELDS

die Änderungen aller Nicht-Schlüsselfelder werden protokolliert, ansonsten gelten die Einstellungen am Datenelement für das Erstellen von Änderungsbelegen

• MULTCASE

Im "Single Case"-Fall werden die Einträge in der Historie als eine Folge betrachtet. Im "Multiple Case"-Fall bilden die Einträge zu jedem Schlüsselwert eine separate Folge (siehe auch Online-Dokumentation der Änderungsbelege).

• HISTORY_SORTED

die Historie liegt nach Schlüssel und Zeit sortiert vor; der Schalter muss gesetzt werden, wenn ein Verweis auf Änderungsinformationen zur Historie angeben wurde

• VALIDITY_DAILY

es gilt eine tägliche Gültigkeit; die Angabe ist nur relevant, wenn in der Historie Gültigkeitsangaben gemacht worden sind

• FUNCTIONMODULE

Namen des Funktionsbausteins, der die Namen der Call-Back-Methoden bereitstellt; dieser Funktionsbaustein wird als Kopie des Funktionsbausteins BANK_API_CHDOC_FUMO_HIST_GET erstellt.

• Für die Historientabelle werden Änderungsbelege geschrieben, d.h. es wurde ein Änderungsbelegobjekt angelegt.

• OBJECTCLAS

Sie geben das Änderungsbelegobjekt an.

• OBJECTCLASTEXT

keine Angabe notwendig, da die Beschreibung aus der Definition des Änderungsbelegobjektes ermittelt wird

• OBJECTID

gewünschter Objektwert, zu dem die Änderungsbelege erzeugt werden

• OBJECTIDTEXT

Aufbereiteter Objektwert, wenn er nicht vom Tool ermittelt werden soll

• REF_TO_HISTORY

Verweis auf die interne Tabelle mit den Historien

In diesem Fall muss der internen Tabelle auf einem Zeilentyp einer Datenbanktabelle aufbauen, die im Änderungsbelegobjekt spezifiziert wurde. Die notwendigen Schlüsselinformationen werden aus der Datenbanktabelle abgeleitet. In der Regel sind in Datenbanktabellen, für die Änderungsbelege erzeugt werden, keine Änderungsinformationen abgelegt. Deshalb sind sie unter REF_TO_HISTORY_CHANGEDATA bekannt zu machen.

• REF_TO_HISTORY_CHANGEDATA

Verweis auf die interne Tabelle mit Änderungsinformationen zur Historie

Jeder Eintrag in den Änderungsinformationen referiert auf den entsprechenden Eintrag in der Historie. D.h. in den Änderungsinformationen und der Historie müssen gleich viele Einträge vorhanden sein und die Historie muss nach dem Schlüssel und der Zeit sortiert sein, da durch das sonst notwendige Sortieren diese Beziehung zerstört werden würde.

• OBJECTKEYSTRUC

Name der Struktur , in der die Felder des Objektwertes beschrieben sind

• FOR_ALL_FIELDS

die Änderungen aller Nicht-Schlüsselfelder werden protokolliert, ansonsten gelten die Einstellungen am Datenelement für das Erstellen von Änderungsbelegen

• MULTCASE

Im "Single Case"-Fall werden die Einträge in der Historie als eine Folge betrachtet. Im "Multiple Case"-Fall bilden die Einträge zu jedem Schlüsselwert eine separate Folge (siehe auch Online-Dokumentation der Änderungsbelege).

• HISTORY_SORTED

die Historie liegt nach Schlüssel und Zeit sortiert vor; der Schalter muss gesetzt werden, wenn ein Verweis auf Änderungsinformationen zur Historie angeben wurde

• VALIDITY_DAILY

keine Angabe notwendig, da für Tabellen zu den Änderungsbelege erstellt werden, Gültigkeitsangaben nicht sinnvoll erscheinen.

• FUNCTIONMODULE

keine Angabe notwendig, da die Namen der Call-Back-Methoden aus der Definition des Änderungsbelegobjektes der Änderungsbelegtools ermittelt werden

Beispiel

Der unter dem Parameter C_TAB_HISTORY_ATTACHdargestellte 2. Fall ist dann sinnvoll, wenn aus Performancegründen zu einem bestimmten, einmaligen und sehr häufig vorkommenden Zustandswechsel keine Änderungsbelege geschrieben werden sollen. In diesem Fall sind die notwendigen Änderungsinformationen bei diesem Zustandswechsel mit in der Datenbank abzulegen. Aus diesen Informationen kann dann der fehlende Änderungsbeleg rekonstruiert und zusammen mit den in der Datenbank abgelegten Änderungsbelegen dargestellt werden. So erhält der Endanwender einen vollständigen Verlauf seiner Änderungen dargestellt.

Hinweise

Weiterführende Informationen

Parameter

C_TAB_CHDOCREAD
C_TAB_HISTORY_ATTACH
I_FLG_EMSG

Ausnahmen

FIELD_MISSING
INTERNAL_ERROR
KEYLENGTH_IS_NULL
NO_FLAT_STRUCT_TYPE
NO_TABLE_TYPE
OUTPUTLENGTH_IS_INITIAL
TABLE_DESCRIPTON_NOT_FOUND
TABLE_NOT_DEFINED

Funktionsgruppe

BANK_API_CHDOC_HISTORY

Addresses (Business Address Services)   General Material Data  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 10421 Date: 20240523 Time: 111138     sap01-206 ( 142 ms )