Architektur klassischer BAdIs
Um für ein Programm eine Erweiterung vorzusehen, wird ein Business Add-In definiert. Im Rahmen des Add-Ins legt der Anwendungsentwickler ein Interface an. Die Erweiterungsverwaltung generiert daraus eine Adapterklasse, die das Interface implementiert und damit die Schnittstelle zur Implementierung des Kunden, Partners etc. herstellt. Der Entwickler erzeugt im Anwendungsprogramm eine Instanz der Adapterklasse und ruft zum gegebenen Zeitpunkt die entsprechende Methode auf.
Zu einem Business Add-In gehört ein Interface und eine dieses implementierende Adapter-Klasse. Das Interface wird vom Verwender implementiert.
Die generierte Klasse (Add-In-Adapter) hat folgende Aufgaben:
· Steuerung
Die Adapter-Klasse ruft die aktiven Implementierungen auf.
· Filterung
Falls ein Business Add-In nur unter bestimmten Bedingungen ausgeführt werden soll, sorgt die Adapter-Klasse dafür, dass nur die gültigen Implementierungen aufgerufen werden.
Dieses Konzept gewährleistet die Mehrfachverwendung: Ein einmal implementiertes Business Add-In kann auch von in der Softwarekette weiter rechts stehenden Gliedern implementiert werden.
Der Kunde findet die Erweiterungen im IMG und in der Komponentenhierarchie. Wenn er ein Business Add-In nutzen möchte, legt er eine Implementierung an. Der Kunde muß die Methoden und die Erweiterungen der Oberfläche implementieren und anschließend seine Implementierung der Erweiterung aktivieren. Zur Laufzeit werden die aktiven Komponenten der Erweiterung aufgerufen.
Ein Business Add-In enthält in der Regel ein Interface und weitere Komponenten wie Funktionscodes für Menüerweiterungen und gegebenenfalls Erweiterungen für Screens. Erweiterung, Interface und generierte Klasse liegen im Namensraum der Anwendungsentwicklung. Die Implementierung eines Business Add-Ins wird im Namensraum des Implementierers angelegt.
Beispiele für Programm-, Menü- und Screen-Erweiterungen finden Sie in den folgenden Abschnitten.
Für die neuen BAdIs, siehe BAdIs - Architektur.