Ansicht
Dokumentation
ABENBDL_ANCESTOR_EXT - BDL ANCESTOR EXT
Vendor Master (General Section) ROGBILLS - Synchronize billing plansDiese Dokumentation steht unter dem Copyright der SAP AG.
- ancestor association
... ancestor association _Assoc$[;$]
$[abbreviation _newName$]
$[without response$]
$[{$[with draft;$]}$]
Wirkung
Deklariert eine Assoziation als Vorfahrenassoziation. Für Vorfahrenassoziationen gelten folgende Regeln:
- Auf dem Weg vom aktuellen Knoten zum Wurzelknoten muss genau eine Assoziation für jede Hierarchieebene als Vorfahrenassoziation definiert werden.
- Nur Assoziationen, die zu einem Knoten auf einer höheren Hierarchieebene als der aktuelle Knoten führen, können als Vorfahrenassoziation definiert werden.
- Die Assoziation zur direkten übergeordneten Entität darf nicht als Vorfahrenassoziation definiert werden, da sie automatisch und implizit als Vorfahr betrachtet wird.
- Eine Vorfahrenassoziation muss eine Kardinalität von 1 haben.
- Wenn mehrere Assoziationen auf dasselbe Assoziationsziel verweisen, kann nur eine davon als Vorfahr gekennzeichnet werden.
- Die Schlüsselfelder aller Vorfahrenassoziationen müssen als readonly gekennzeichnet sein.
Mit Vorfahrenassoziationen soll die Stabilität von Erweiterungen auch dann gewährleistet werden, wenn das ursprüngliche BO modifiziert wird. Über Vorfahrenassoziationen kann der Pfad zur RAP-Berechtigungs-Master-Entität, RAP-Sperr-Master-Entitätund RAP-ETag-Master-Entität abgeleitet werden und muss nicht explizit angegeben werden. Daher macht die Syntax ancestor association den direkten Verweis auf Berechtigungs-Master, Sperr-Master und ETag-Master obsolet:
- Syntax zur Angabe einer sperrabhängigen RAP-Entität: lock dependent statt lock dependent by _Assoc
- Syntax zur Angabe einer berechtigungsabhängigen RAP-Entität: authorization dependent statt authorization dependent by _Assoc
- Syntax zur Angabe einer ETag-abhängigen RAP-Entität: etag dependent statt etag dependent by _Assoc
Es steht eine kurze Syntaxform zur Verfügung: ( lock, authorization, etag ) dependent. Jede der drei Komponenten lock, authorization und etag ist optional, aber mindestens eine davon muss innerhalb der Klammern angegeben werden.
Zusätze:
- abbreviation _newName: Definiert einen alternativen Namen für eine Assoziation. Die Abkürzung _newName kann maximal 16 Zeichen lang sein. Assoziationen befinden sich im Namensraum ihrer Wurzelentität und können bis zu 30 Zeichen lang sein. Dies ist unter Umständen für eine Verarbeitung in ABAP RAP zu lang. Wenn ein kürzerer Name benötigt wird, werden Sie zur Eingabe einer maximal 16 Zeichen langen Abkürzung für die Assoziation aufgefordert.
- without response Der optionale Zusatz without response ist für Cross-BO-Assoziationen konzipiert, die über ein Assoziationsziel aus einem anderen BO verfügen. Bei einer solchen Cross-BO-Assoziation wird die Assoziationszielentität automatisch als fremde Entität (foreign entity) in die Antworttypen einbezogen. Somit können Probleme in Bezug auf die Zielentität bei read-by-association- oder create-by-association-Operationen in die Antworttypen einbezogen werden. without response verhindert das Einbeziehen des Standardverhaltens der fremden Entität, die in die Antworttypen einbezogen wird.
- with draft: Definiert eine Assoziation als entwurfsfähig. Eine entwurfsfähige Assoziation ruft aktive Daten ab, wenn sie auf eine aktive Instanz folgt, und ruft Entwurfsdaten ab, wenn sie auf eine Entwurfsinstanz folgt (detaillierte Informationen zur RAP-Entwurfsbehandlung finden Sie unter CDS BDL - verwaltet, with draft).
- Wenn ein BO entwurfsfähig ist, sollten alle Assoziationen entwurfsfähig sein, damit die Assoziationen stets zur Zielinstanz mit demselben Zustand (Entwurf oder aktiv) führen. Sobald Sie mit dem Zusatz with draft ein BO als entwurfsfähig definieren, werden alle BO-internen Assoziationen automatisch entwurfsfähig. Um dieses Verhalten als explizit zu definieren, werden Sie vom Verhalten zur Angabe der Kompositionen innerhalb eines Entwurfs-BOs mit with draft aufgefordert.
Beispiel
Mit der Erweiterung DEMO_RAP_EXTENSION_1 wird die CDS-Verhaltensdefinition DEMO_RAP_EXTENSIBLE_ROOT erweitert. Sie macht einen Erweiterungsknoten verhaltensfähig und definiert die Assoziationen zu seinen Geschwistern, Großeltern und Urgroßeltern als Vorfahrenassoziationen. Sperr-, Berechtigungs- und ETag-Master werden nicht explizit angegeben, sondern implizit über Vorfahrenassoziationen abgeleitet.
Das ausführbare Beispiel Knotenerweiterung erläutert das obige Beispiel im Detail.
CPI1466 during Backup Fill RESBD Structure from EBP Component Structure
Diese Dokumentation steht unter dem Copyright der SAP AG.
Length: 8767 Date: 20240523 Time: 181540 sap01-206 ( 114 ms )