Approche fonctionnelle

La classe d'objet Java liée est une implémentation d'une interface. Contrairement au service basé sur REST, il n'existe pas de méthode de rappel spécifique HTTP dans ce type d'implémentation de service. En réalité, le service fonctionnel n'est pas nécessairement lié à une invocation HTTP. Ce type de service peut inclure toute opération qui ne dispose pas d'une prise en charge prête à l'emploi depuis Content Integration Framework. Il peut communiquer avec la base de données, invoquer un service Web tiers, gérer le fonctionnement du système de fichiers, etc.

Implémentez la méthode suivante pour un service fonctionnel. Cette méthode accepte également un argument de type ExecutionContext, contenant les informations contextuelles requises pour réaliser la tâche souhaitée. Le paramètre de type générique de la classe ExecutionContext représente le type d’entrée requis pour le service respectif lors de son appel.

• RS execute(ExecutionContext<RQ> executionContext)

  Cette méthode effectue sa tâche désignée à l'aide des informations contextuelles qui lui sont transmises. En retour, elle donne la valeur souhaitée après avoir terminé son opération. La valeur de retour indiquée dans cette signature est un type générique et se base sur le type utilisé lors de l'implémentation de l'interface FunctionalService.

Gestion des erreurs

La méthode ci-dessus ne doit déclencher aucune exception vérifiée. Au besoin, il est possible de déclencher des exceptions non vérifiées.

Common methods

Voici les méthodes communes applicables à RESTful et aux services fonctionnels. Ces méthodes sont héritées de l'interface com.hcl.unica.system.integration.service.AbstractService.

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

  L'implémentation de cette méthode est plus pertinente pour l'appel de service que pour l'implémentation de service. Pour plus d'informations, voir Développement de plug-ins SDK.

• void init(SystemConfig systemConfig, ServiceConfig serviceConfig)

  Remplacez cette méthode facultative pour effectuer une initialisation unique (après la construction de l’objet de service) avant de traiter une demande. Utilisez l’objet SystemConfig et l’objet ServiceConfig, transmis à cette méthode, afin d'obtenir les détails spécifiques au système et au service pour effectuer les initialisations nécessaires, telles que l’obtention d’une connexion de base de données, l’ouverture d’un descripteur de fichier, etc. Un objet distinct de votre classe de service est créé pour chaque configuration système individuelle dans Unica Platform. Par conséquent, si le même système cible est configuré pour deux partitions différentes dans Unica Centralized Offer Management, deux objets différents de votre classe de service seront créés pour chaque partition. De même, si le même système cible est configuré pour tout autre produit Unica, un objet distinct pour cette configuration existera. L'objet com.hcl.unica.system.integration.config.SystemConfig encapsule toutes les configurations système effectuées dans la section de configuration d'Unica Platform, tandis que l'objet com.hcl.unica.system.integration.config.ServiceConfig conserve toutes les configurations effectuées pour le service correspondant dans les fichiers <ASSET_PICKER_HOME>/conf/plugin-services.yml et <ASSET_PICKER_HOME>/conf/custom-plugin-services.yml. Ces objets sont également accessibles à l’aide de ExecutionContext dans toutes les méthodes décrites plus haut.

  Remarque : Content Integration Framework ne fournit pas de méthode spéciale de fin de cycle de vie pour que les services nettoient les éléments initialisés dans la méthode init. Nous vous recommandons d’utiliser l’approche Java standard en implémentant la méthode Finalize, si nécessaire.