Aller au contenu principal

DataAccessPlugin als public component mit Konfiguration

Commentaires

2 commentaires

  • Zendesk API User
    Author: stefan_brauneis - 11/23/2017 7:49

    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
  • Zendesk API User
    Author: CNoetzel - 11/23/2017 13:11

    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

Vous devez vous connecter pour laisser un commentaire.