Prämisse
Ein AddOn stellt eine Erweiterung oder Ergänzung eines Fachmodells dar. AddOns können nur in Verbindung mit dem jeweiligen Fachmodell (Basismodul) verwendet werden. AddOns stellen Zusatzleistungen dar, die nicht im Standardumfang des Fachmodells enthalten sind. Zusatzleistung bedeutet hier nur, dass es gesondert ausgeliefert und aktiviert werden muss. Es kann kostenpflichtige und kostenlose AddOns geben.
Funktionen bzw Zusatzinformationen werden in AddOns ausgelagert da sie:
-
nicht in jedem Kundenumfeld relevant sind
-
den Mehraufwand beim Support des laufenden Systems erheblich erhöhen
-
Vorsystem-spezifisch sind
Ein Basismodul kann über mehrere AddOns verfügen, während ein AddOn immer nur einem Basismodul zugeordnet wird.
Zielstellung
Bei der Verwendung und Erstellung eines AddOns werden zwei Ziele verfolgt. Es gibt einerseits das fachliche Ziel: es soll eine Funktion oder Informationen ergänzt werden. Beispiele hierfür sind ICPartner Informationen oder eine weitere Schicht im Datenmodell.
Das zweite Ziel ist die techn Standardisierung der benannten Anforderung. Damit muss eine sich wiederholende Anforderung nicht immer wieder “neu erfunden” werden. Bei der techn.
Designgrundsätze
Im einfachsten Fall ist ein AddOn so aufgebaut, dass keine Änderungen am Basismodul vorgenommen werden. Hierdurch kann gewährleistet werden, dass Fachmodelle unverändert und damit vergleichbar bleiben, auch wenn verschiedene AddOns verwendet werden. Es gibt 2 Möglichkeiten, dies zu erreichen:
-
Content-Elemente von Basismodul und AddOn weisen keine Überschneidungen auf, das AddOn ersetzt und erweitert keine Content-Elemente des Basismoduls sondern bringt eigene mit. AddOns setzen nur auf dem Basismodul auf.
-
Die Funktionserweiterung, die durch das AddOn eingebracht werden, sind bereits im Basismodul enthalten und werden durch den Erwerb des AddOn nur noch aktiviert.
Der Grundsatz sollte sein, dass jedes Modul, ob Fachmodell oder AddOn, eigene Content-Elemente mitbringt und nur diese manipuliert.
Umsetzungmöglichkeiten
Variante 1: Ein AddOn baut nur auf dem Basismodul auf
In dieser Variante verwendet ein AddOn ausschließlich eigene Content-Elemente. Es wird nur auf Daten des Basismodul zugegriffen, ohne die Strukturen zu beeinflussen. Ein solches AddOn kann aus Prozeduren und Views bestehen, die auf das Basismodul aufbauen. Im Basismodul sind keine Bestandteile des AddOn vorbereitet.
Vorteile dieser Lösung sind die Unabhängigkeit des Basismoduls vom AddOn, Änderungen am AddOn führen nie zu Änderungen am Basismodul. Hierdurch ist es möglich, bei der Datensicherung, genauer nachverfolgen zu können, ob Änderungen am Basismodul vorliegen.
Beispiele solcher AddOns finden sich REWE Modell.
Variante 2: Ein AddOn wird inhaltlich mit dem Basismodul ausgeliefert, und später aktiviert
In dieser Variante ist das AddOn bereits im Basismodul hinterlegt und deaktiviert. Diese Lösung bietet sich an, wenn sich die fachl Anforderung des AddOn nur umsetzen lässt, indem das Basismodul manipuliert wird.
Ein Teil des Contents des AddOn wird dann bereits ausgeliefert und ein Teil kommt erst mit dem AddOn. Die Funktion des AddOn wird durch das einspielen des Moduls (Lizenzabhängig) aktiviert.
Eine Mögliche Umsetzung ist das AddOn FIN-ICP, dieses wird, in Teilen, bereits mit dem Fachmodell FIN ausgeliefert. Durch das einspielen des AddOn über die Modulverwaltung in OCT wird dann auch die Funktionalität aktiviert.
Technisch kann das wie folgt realisiert werden:
SELECT
T1.Column1 AS C1
, T1.Column2 AS C2
, T2.Column1 AS C3
, T2.Column2 AS C4
FROM integration.tTEST_Tabelle1 T1
LEFT JOIN integration.tTEST_Tabelle2 T2
ON 1 = (SELECT 1 WHERE EXISTS (SELECT * FROM system.tModules WHERE ModuleID = 'TEST-ADDON'))
AND T1.DataSourceKey = T2.DataSourceKey
In diesem Beispiel wird die Funktion eines AddOn, ein Join auf eine weitere Tabelle, bereits im Fachmodell ausgeliefert. Über die erste ON Bedingung ist der JOIN deaktiviert und liefert kein Ergebnis. Wird das Modul TEST-ADDON in OCT eingespielt, wird ein entsprechender Eintrag in der Tabelle system.tModules erstellt. Wird dieser Eintrag gefunden, ergibt sich für den JOIN die Bedingung 1=1 und der JOIN liefert Daten.
Variante 3: Ein AddOn überschreibt Teile des Basismoduls
Diese Variante stellt die komplizierteste Form dar, in der ein AddOn ins System eingespielt werden kann. Hier bringt das AddOn neben eigenen Content-Elementen auch Änderungen an anderen Content-Elementen mit. Für die Modulverwaltung bedeutet das, dass Content-Elemente immer doppelt vorgehalten werden müssen, da es im MSSQL Server nicht möglich ist, z.B. View-Definitionen zu ändern ohne diese komplett einzuspielen.
Ein Beispiel für ein solches AddOn ist FIN-CP. Bei diesem AddOn werden eigene Content-Elemente, die CP Prozeduren, mitgebracht. Er werden aber auch beim Einspielen Änderungen an bestehenden Content-Elementen das Basismoduls vorgenommen. In diesem Fall die CP Keys im vFIN_Buchungsjournal.
Nachteil: Gerade bei Views muss jedes AddOn die Definition des Basismodul mitführen, wenn mehrere AddOns existieren gerät das Konzept schnell an seine Grenzen