RAP - Numbering

Inhaltsverzeichnis

• Szenarien
• Frühe Nummernvergabe (intern)
• Späte Nummernvergabe
• Test
• Fazit

Wenn wir mit der bisherigen App gearbeitet haben, mussten wir bei neuen Datensätzen immer selbst eine Nummer vergeben. Hier sollte das RAP Objekt aber selbst die Vergabe der Nummer übernehmen und uns als Anwender damit in Ruhe lassen. 

 

Szenarien

Für die Vergabe von Nummern gibt es in RAP drei verschiedene Szenarien, die auch für unterschiedliche Einsatzzwecke gedacht sind:

• Frühe Nummernvergabe (Extern) - Diese Variante wurde bereits in der alten App von uns eingesetzt, der Anwender ist selbst für die Vergabe des Primärschlüssels verantwortlich. Die Validierung prüft nur auf doppelte Schlüssel und ob der Schlüssel befüllt wurde.
• Frühe Nummernvergabe (Intern) - Bei dieser Variante besteht das Schlüsselfeld meist aus einer UUID und die Vergabe der eindeutigen ID geschieht über das RAP Framework. Eine Prüfung auf Eindeutigkeit ist nicht mehr nötig, da die UUID immer eindeutig ist.
• Späte Nummernvergabe - Die späte Nummernvergabe geschieht erst in der Speichersequenz des Frameworks, kurz bevor die Daten auf die Datenbank geschrieben werden. An dieser Stelle kannst du eine Nummer per Nummernkreis vergeben oder auf eine andere Art den Schlüssel vergeben.

 

Die Vergabe der Nummer kann vor allem dann wichtig sein, wenn es um lückenlose Belege oder Nummerierungen geht. Ein Beleg, der den Draft-Status nicht verlässt oder wieder gelöscht wird, würde so eine Lücke in den Belegnummern erzeugen, was betriebswirtschaftlich nicht geht.

 

Frühe Nummernvergabe (intern)

Für diese Form der Nummernvergabe gibt es zwei Ausprägungen, einmal die Variante über die automatische Vergabe einer UUID und die zweite Variante mit der manuellen Vergabe einer Nummer. Bei der ersten Variante wird an dem dafür entsprechenden Feld das Attribut "numbering" definiert. Damit weiß RAP das hier eine automatische UIUD vergeben werden soll.

field ( numbering : managed ) FieldName;

 

Für die interne Vergabe per Methode, muss in der Verhaltensdefinition des Objekts der Zusatz "early numbering" verwendet werden. Im Anschluss muss die Methode "FOR NUMBERING" implementiert werden. Dort hat man dann die Möglichkeit mit Coding eine Nummernvergabe zu implementieren. Diese Variante ist so ähnlich wie das nachfolgende Beispiel für die späte Nummernvergabe.

 

Späte Nummernvergabe

Um die späte Nummernvergabe zu realisieren, muss in der Verhaltensdefinition am Objekt der Zusatz "late numbering" ergänzt werden. Gleichzeitig sollte das Schlüsselfeld auf Read-Only gesetzt werden, da der User hier keine Eingabe mehr machen kann. Dazu der Auszug aus der Verhaltensdefinition:

managed implementation in class zbp_bs_demo_rappartner unique;
strict;

define behavior for ZBS_I_RAPPartner alias Partner
persistent table zbs_dmo_partner
lock master
authorization master ( instance )
late numbering
{
  create;
  update;
  delete;

  field ( readonly ) PartnerNumber;

  mapping for zbs_dmo_partner
  {
    PartnerNumber = partner;
    PartnerName = name;
    Street = street;
    City = city;
    Country = country;
    PaymentCurrency = payment_currency;
  }
}

 

Der Compiler verweist uns im Anschluss darauf, dass wir noch die Implementierung generieren müssen, was über STRG + 1 automatisch erledigt wird. Die leere Implementierung wird in der Speichersequenz angelegt und nicht wie bisher, in der Verhaltensimplementierung. Die Methode "ADJUST_NUMBERS" kann nun befüllt werden:

CLASS lsc_zbs_i_rappartner DEFINITION INHERITING FROM cl_abap_behavior_saver.
  PROTECTED SECTION.
    METHODS adjust_numbers REDEFINITION.
ENDCLASS.


CLASS lsc_zbs_i_rappartner IMPLEMENTATION.
  METHOD adjust_numbers.
  ENDMETHOD.
ENDCLASS.

 

Für die Nummernvergabe verwenden wir eine sehr einfach Logik, in dem wir die maximale Nummer ermitteln und dann bei allen neuen Datensätzen erhöhen:

SELECT FROM zbs_dmo_partner
  FIELDS MAX( partner )
  INTO @DATA(ld_max_partner).

LOOP AT mapped-partner REFERENCE INTO DATA(lr_partner).
  ld_max_partner += 1.
  lr_partner->PartnerNumber = ld_max_partner.
ENDLOOP.

 

 

Test

Bevor wir mit dem Test beginnen können, müssen wir noch die Implementierung der Methode "validateKeyIsFilled" auskommentieren. Die Vergabe des Schlüssels erfolgt nicht mehr extern, sondern erst in der Speichersequenz. Da die Validierung vor der Sequenz aufgerufen wird, würde die Validierung des Speichervorgang behindern. Schauen wir uns dazu einmal größte Partnernummer an:

 

Über "Create" legen wir einen leeren Datensatz an und sehen auch, dass die Partnernummer gesperrt ist, eine manuelle Eingabe wie bisher ist nicht möglich

 

Nachdem die Felder befüllt wurden, können wir auf den "Save" Button klicken, die Felder werden gesperrt und der neue Datensatz wird präsentiert. Die Nummer wurde vergeben und ist im Detailbild zu sehen.

 

Fazit

Du siehst, die Implementierung der automatischen Nummernvergabe ist kein Hexenwerk und benötigt nur einige kleinere Schritte. Bereits beim Design der RAP Business Objekte solltest du dir Gedanken machen, welche Art von Schlüsseln du verwenden möchtest. Egal ob UUID oder Nummernkreis, nimmt die automatische Vergabe einiges an Arbeit ab.