Funktionaler Ansatz

Diese Klasse ist eine Implementierung der Funktionsservice-Schnittstelle. Im Gegensatz zu einem REST-basierten Service gibt es bei dieser Art von Serviceimplementierung keine HTTP-spezifischen Rückrufmethoden. Eigentlich muss der funktionale Service nicht unbedingt mit einem HTTP-Aufruf verknüpft sein. Diese Art von Service kann jede Operation einschließen, für die es keine vorkonfigurierte Unterstützung von Content Integration Framework gibt. Er kann mit der Datenbank kommunizieren, den Webservice eines Dritten aufrufen, das Dateisystem bedienen usw.

Implementieren Sie die folgende Methode für einen Funktionsservice. Diese Methode akzeptiert auch ein Argument vom Typ ExecutionContext, das die für die Ausführung der gewünschten Aufgabe erforderlichen Kontextinformationen enthält. Der generische Typenparameter für die ExecutionContext-Klasse stellt die Art der Eingabe dar, die für den entsprechenden Service für seinen Aufruf erforderlich ist.

• RS-Ausführung (ExecutionContext<RQ> executionContext)

  Diese Methode erfüllt die ihr zugewiesene Aufgabe unter Verwendung der ihr übermittelten Kontextinformationen. Im Gegenzug gibt sie nach Beendigung ihrer Operation den gewünschten Wert an. Der in dieser Signatur angezeigte Rückgabewert ist ein generischer Typ und basiert auf dem bei der Implementierung der FunctionalService-Schnittstelle verwendeten Typ.

Fehlerbehandlung

Die obige Methode darf keine überprüfte Ausnahme auslösen. Nicht überprüfte Ausnahmen können bei Bedarf ausgelöst werden.

Common methods

Im Folgenden sind die gängigen Verfahren aufgeführt, die sowohl für RESTful- als auch für funktionale Services anwendbar sind. Diese Methode werden von der com.hcl.unica.system.integration.service.AbstractService-Schnittstelle übernommen.

• Klasse<? extends ServiceGateway<RQ, ?>> getServiceInterface()

  Ihre Implementierung ist jedoch eher für den Serviceaufruf als für die Implementierung des Service relevant. Weitere Informationen finden Sie in Plug-in-Entwicklung SDK.

• void init(SystemConfig systemConfig, ServiceConfig serviceConfig)

  Überschreiben Sie diese optionale Methode, um eine einmalige Initialisierung (nach der Installation des Serviceobjekts) durchzuführen, bevor Sie eine beliebige Anforderungen bedienen. Verwenden Sie das Objekt ' systemConfig ' und das ServiceConfig-Objekt, das an diese Methode übergeben wird, um System- und servicespezifische Details zu erhalten bzw. um erforderliche Initialisierungen zu ermöglichen, wie z. B. eine Datenbankverbindung zu erhalten, ein Datei-Handle zu öffnen usw. Für jede einzelne Systemkonfiguration in Unica Platform wird ein separates Objekt ihrer Serviceklasse erstellt. Wenn also dasselbe Zielsystem für zwei verschiedene Partitionen in Unica Centralized Offer Management konfiguriert ist, werden für jede Partition zwei verschiedene Objekt ihrer Serviceklasse erstellt. Auch wenn dasselbe Zielsystem für ein anderes Unica-Produkt konfiguriert ist, ist ein separates Objekt für diese Konfiguration vorhanden. Das com.hcl.unica.system.integration.config.SystemConfig-Objekt verkettet alle Systemkonfigurationen, die im Abschnitt Unica Platform Konfiguration vorgenommen werden, während das com.hcl.unica.system.integration.config.ServiceConfig-Objekt alle für den entsprechenden Dienst vorgenommenen Konfigurationen in den <ASSET_PICKER_HOME>/conf/plugin-services.yml- und <ASSET_PICKER_HOME>/conf/custom-plugin-services.yml-Dateien enthält . Diese Objekte können auch in allen zuvor besprochenen Methoden über ExecutionContext aufgerufen werden.

  Anmerkung: Content Integration Framework bietet keine spezielle End-of-Lifecycle-Methode für Dienste zur Bereinigung der Dinge, die innerhalb Methode ' init ' initialisiert wurden. Wir empfehlen Ihnen, den standardmäßigen Java-Ansatz zu verwenden, indem Sie gegebenenfalls die Methode ' Finalize ' umsetzen.