Aufbau Customizing

• Die Unterteilung der Objekte sollte in mehrstufige Stammdaten/Bewegungsdaten erfolgen

• Funktional separate Teile eines Objekts sollten in separate Objekte ausgelagert und verknüpft werden, so dass die Objekte nicht zu groß/komplex werden

• Je nach Anwendungsfall sollte eine Verwendung durch Kopieren/Referenzieren/Links/BOMs umgesetzt werden:

  • Verwendung von Stammdaten in Bewegungsdaten durch Kopieren

  • Elementverknüpfung: Falls Daten nicht vererbt werden müssen, reicht entweder die Angabe des Vorschriftennamens des Objekts als Elementwert (zu bevorzugen) oder ein LINK auf das Objekt. Ein LINK initialisiert mehr Daten und ist daher langsamer als die Verknüpfung mit dem Elementwert

  • Falls Daten vererbt werden sollen, wird die Nutzung von Primärreferenzen bevorzugt. Hierbei gilt: Keine Referenz von Bewegungsdaten in Stammdaten

  • Die Verknüpfung innerhalb der Stammdaten oder Bewegungsdaten kann auch mittels LINK/BOM durchgeführt werden

Entwicklungsumgebung/Architektur

• Es sollte die SUPER-Klasse für Redefinitionen verwendet werden, falls es mehrere Redefinitionen einer Klasse gibt, bspw. VART- und Generierungsklassen

• Es sollte immer die FACTORY für die Instanziierung verwenden werden, wenn möglich durch SINGLETON

• Die Implementierung von Kundenlogik sollte möglichst nur über die offiziellen APIs durchgeführt werden:

  • Objektbezogene Kundenimplementierungen sollten möglichst in einem Z-Interface der VART-Klasse durchgeführt werden, welches von dem Standard-Interface /SCT/QP_IF_VART erbt.

  • Der Zugriff auf QPPD-Funktionalität sollte möglichst über die VART-Klasse oder den BUS getätigt werden

  • Weitere Möglichkeiten sind:

    • CHECK- und Generierungsklassen

    • TOE-Plausibilitäts-Klassen

    • BADI

    • VART-Ereignisbehandler (ON-Methoden)

  • Des Weiteren sollte möglichst keine Redefinitionen von Objekttypen, MODEL, Controller usw. getätigt werden

Automatische Erzeugung von Knoten

Wenn eine Vorschriftenart über eine Hierarchie verfügt, kann es eine Anforderung sein, die jeweiligen Knoten automatisch aufzubauen. Hierbei spricht man vom Builder. Der Builder sollte über die VART-Klasse implementiert werden, durch die jeweilige Methode aus dem VART-Interface. Im Standardfall werden alle Pflichtknoten aus der Hierarchie aufgebaut. Für Zusatzanforderungen kann die Build-Methode angepasst werden. Ein Anwendungsfall wäre zum Beispiel das Auflösen von Stammdaten. 

Werte-Generierung

Neben dem Builder gibt es auch noch Generierungsmethoden, welche dazu verwendet werden sollten, Werte auf Objekttypen zu ändern. 

Hierbei gilt:

• Generierungsmethode generieren Werte, können aber auch zur Plausibilisierung von Werten genutzt werden, welche Abhängigkeiten zu anderen Elementen des Knotens/des Objekts haben.

• Die Plausibilisierung von Werten mit Abhängigkeiten sollte wenn möglich durch TOE realisiert werden

Plausibilisierung

• In Abhängigkeit zu den Abhängigkeiten der Elemente kann die Prüfung am Element durch TOE/Objekttypen, durch die Generierungsklassen/Knoten und durch Checkklasse/BUILDER auf Objektebene durchgeführt werden

• Einzelwerten werden durch TOE geprüft

Globale Generierung

• Eine feste Abarbeitung von "oben nach unten" oder "unten nach oben" wird bevorzugt 

• Es sollten möglichst wenig Abhängigkeiten zwischen den Knoten erstellt werden, so dass die globale Generierung nicht allzu oft durchlaufen muss, um einen konsistenten Zustand zu erreichen

Zugriff von Kundenentwicklungen auf Daten

• Diagramm beschreiben

• Ändern: Z-VART-Klasse ist Wrapper für BUS/CONTROLLER etc.