CNoetzel
Elite Observer

DataAccessPlugin als public component mit Konfiguration

Jump to solution

Werte Community,

ich stehe vor der folgenden Herausforderung. Ich möchte Daten, die extern über eine API bereitgestellt werden in FirstSpirit verfügbar machen und verwende dazu ein DataAccessPlugin. Um die Daten über die API abgreifen zu können, verwenden wir einen API-Client, der konfigurierbar sein soll (Credentials, URL, etc.). Damit wir nicht in jedem Projekt, in dem wir das DAP einsetzen, die Konfiguration pflegen wollen, haben wir das DAP als public Komponente in der module.xml eingetragen und eine Configurable-Klasse bereitgestellt, über die sich das DAP (bzw. der API-Client) konfigurieren lässt.

Soweit so gut, aber wir kommen wir an diese Konfiguration heran, wenn ein Redakteur das DAP im SiteArchitekt nutzt und während dieser Nutzung der API-Client auf Basis der in den Server-Eigenschaften (Konfiguration erfolgt global über die Modul-Konfiuration)  hinterlegten Konfiguration erzeugt werden soll?! Geht das überhaupt?

Gibt es Best-Practices hierzu? Sollten man den API-Client evtl. als Service implementieren, den man sich über den ServiceBroker holt und im DAP nutzt? Kann man DAPs mit einer globalen Konfiguration bereitstellen?

Für Rückmeldungen und Anregungen wäre ich dankbar.

Freundliche Grüße

Carsten Noetzel

0 Kudos
1 Solution

Accepted Solutions
stefan_brauneis
I'm new here

Hallo Carsten,

wir nutzen DAP ebenfalls in verschiedenen Szenarien. Allgemein hat es sich aus meiner Sicht als gutes Design abgezeichnet, den Client zur Abfrage des externen Systems in einen Service auszulagern.

Wenn Du die Verbindung direkt aus dem DAP heraus erzeugst, dann führt das ja dazu, dass der jeweilige FirstSpirit-Client die Verbindung zum externen Server direkt aufbaut, dass also bspw. der jeweilige SiteArchitect mit dem externen Server eine Verbindung aufbaut. Auch im ContentCreator wäre das dann so, dass diese Verbindung aus der entsprechenden Web-Application heraus aufgebaut wird. Das ist auch nicht optimal und kann auch, je nach Systemlandschaft, in manchen Konstellationen gar nicht erlaubt sein.

Außerdem hast Du eben im Service noch die Möglichkeit Konfigurationen, Clienterzeugung und Caching zentral zu halten wenn Du das willst.

So wie ich Deine Frage verstanden habe ist das ja für die Konfiguration der Fall, womit Deine Anforderung erfüllt wäre.

Schöne Grüße

Stefan Brauneis

View solution in original post

0 Kudos
2 Replies
stefan_brauneis
I'm new here

Hallo Carsten,

wir nutzen DAP ebenfalls in verschiedenen Szenarien. Allgemein hat es sich aus meiner Sicht als gutes Design abgezeichnet, den Client zur Abfrage des externen Systems in einen Service auszulagern.

Wenn Du die Verbindung direkt aus dem DAP heraus erzeugst, dann führt das ja dazu, dass der jeweilige FirstSpirit-Client die Verbindung zum externen Server direkt aufbaut, dass also bspw. der jeweilige SiteArchitect mit dem externen Server eine Verbindung aufbaut. Auch im ContentCreator wäre das dann so, dass diese Verbindung aus der entsprechenden Web-Application heraus aufgebaut wird. Das ist auch nicht optimal und kann auch, je nach Systemlandschaft, in manchen Konstellationen gar nicht erlaubt sein.

Außerdem hast Du eben im Service noch die Möglichkeit Konfigurationen, Clienterzeugung und Caching zentral zu halten wenn Du das willst.

So wie ich Deine Frage verstanden habe ist das ja für die Konfiguration der Fall, womit Deine Anforderung erfüllt wäre.

Schöne Grüße

Stefan Brauneis

0 Kudos

Hallo Stefan,

danke für die Antwort. Ich dachte mir, dass es in diese Richtung gehen würde. Ich habe mittlerweile einen Service implementiert über den ich Anfragen an die API stellen kann. Gibt es eine elegante Möglichkeit das Interface für den Service irgendwie so exportieren und anderen Modulen zur Verfügung zu stellen, damit diese sich den Service über den ServiceBroker holen können? Im Optimalfall möchte man ja nicht alles in einem Modul entwickeln, wie macht man also das Interface anderen Modulen bekannt?!

Freundliche Grüße

Carsten Noetzel

0 Kudos