Functional approach

Refer to the com.example.service.functional.CustomService class to understand the functional service implementation.

This class is an implementation of FunctionalService interface. Unlike REST based service, there are no HTTP specific callback methods in this type of service implementation. In fact, functional service may not necessarily be related to any HTTP invocation. This type of service can include any operation which has no out of the box support from Content Integration Framework. It can talk to the database, invoke third party web service, do the file system operation etc.

Implement the following method for a functional service. This method also accepts an argument of type ExecutionContext, containing the contextual information required for completing the desired task. The generic type parameter to the ExecutionContext class represents the type of input required for the respective service on its invocation.

  • RS execute(ExecutionContext<RQ> executionContext)

    This method performs its designated task using the contextual information passed to it. In return, it gives the desired value after finishing its operation. The return value shown in this signature is a generic type and is based on the type used while implementing FunctionalService interface.

Error Handling

Above method must not throw any checked exception. Unchecked exceptions can be thrown if required.

Common methods

The following are the common methods applicable for RESTful as well as Functional services. These methods are inherited from com.hcl.unica.system.integration.service.AbstractService interface.

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

    Implementation of this method is more relevant to the service invocation rather than service implementation. For more information, see Plugin Development SDK.

  • void init(SystemConfig systemConfig, ServiceConfig serviceConfig)

    Override this optional method to perform one-time initialization (after service object construction), prior to serving any request. Use the SystemConfig object and the ServiceConfig object, passed to this method, to obtain system and service-specific details respectively to make necessary initializations, such as obtaining a DB connection, opening a file handle etc. A separate object of your service class is created for each individual system configuration in Unica Platform. Thus, if the same target system is configured for two different partitions in Unica Centralized Offer Management, then two different objects of your service class will be created for each partition. Likewise, if the same target system is configured for any other Unica product, a separate object for that configuration will exist. The com.hcl.unica.system.integration.config.SystemConfig object encapsulates all the system configurations made in Unica Platform Configuration section, whereas com.hcl.unica.system.integration.config.ServiceConfig object holds all the configurations made for the corresponding service in <ASSET_PICKER_HOME>/conf/plugin-services.yml and <ASSET_PICKER_HOME>/conf/custom-plugin-services.yml files. These objects are also accessible using ExecutionContext in all the methods discussed earlier.

    Note: Content Integration Framework does not provide any special end-of-lifecycle method for services to clean up the things initialized inside the init method. We recommend you to use the standard Java approach by implementing the finalize method, if necessary.