Derivatives of RestService

Derivatives of RestService interface facilitates creation of RESTful implementation of standard services.

Simple search (simple-search)

The following are the specialized interfaces and classes available for the simple-search service:
  • com.hcl.unica.system.integration.service.search.RestSearchService

    The com.example.service.rest.SimpleSearchService class in asset-integration-starter project is a quick starter implementation for RESTful simple-search service. Its parent is com.hcl.unica.system.integration.service.search.RestSearchService class.

    The RestSearchService class has a type parameter RS, which represents the type of response (post deserialization) received from the remote REST API. In this case it is SimpleSearchResponse class defined inside the asset-integration-starter project.

    RestSearchService class implements RestService interface and defines the SearchRequest class as the type argument RQ for RestService. Thus, the object of SearchRequest becomes input to all the simple-search services (same input is used for Functional counterpart of simple-search as well). SearchRequest class is part of the Content Integration SDK.

    In addition to defining the input type for the simple-search service, RestSearchService class also overrides the transformResponse method and defines return value of this method to be of ContentPage type. ContentPage is also part of the Content Integration SDK and encapsulates the search result and associated pagination details.

    The plugin must extend its simple-search implementation from the service com.hcl.unica.system.integration.service.search.RestSearchService to be recognized as a simple-search service by the Content Integration Framework (Functional counterpart, discussed later, is also a valid choice to extend from, for the simple-search services implemented using the Functional approach).

    RestSearchService extends from com.hcl.unica.system.integration.service.search .AbstractSearchService abstract class.

    We recommend looking at com.aem.service.AemSimpleSearchService class from the aem-integration project to know more about how the SearchRequest class and the ContentPage class are used during service implementation.

    Adhering to the contract of Presentable interface while populating list of contents in ContentPage is a crucial part of this service implementation. Presentable interface is covered in more detail in subsequent section.

  • com.hcl.unica.system.integration.service.search.AbstractSearchService

    This is a common base class for RESTful as well as Functional simple-search implementations. So, the details of this class also apply to the Functional implementation of simple-search.

    This class defines the com.hcl.unica.system.integration.service.gateway.SimpleSearchServiceGateway interface as the service gateway for the simple-search service. A closer look at this interface tells us that the simple-search takes the SearchRequest object and returns the ContentPage object.

    In addition to defining the service interface for simple-search, it introduces one more method for the simple-search service, named getSupportedContentTypes. Every simple-search implementation can optionally override and implement this method. Please note that this method is very simple-search specific and has nothing to do with other standard and custom services. The signature of this method is as follows:
    public Map<String, String> getSupportedContentTypes();

    Implementation of this method returns a Map<String, String> representing the supported categories of contents that can be searched in the target system. There is no specific semantic associated with the entries in this Map. It can be any meaningful key-value pair. It acts as a filter for client application during the search operation. As of current implementation of Unica Content Integration, this Map is used to populate entries in a drop down, wherein keys of the Map become values of the options, and values of the Map become display labels for the options. Thus, keys can carry internal names, or identifiers, and values should be readable and meaningful texts. If the user needs to search any specific type of content, he can choose one or more options from the supported types. In such case, simple-search service receives a set of keys corresponding to the values chosen by the user. Set of keys received from the client application can be obtained from ExecutionContext object by navigating through the getRequest method and then calling getTypes() on it. The simple-search implementation deals with these set of keys, as per the target system’s programming interface, and filters the search items accordingly.

    Standard service parameter - supportedContentTypes

    Overriding getSupportedContentTypes method is recommended only if the Map needs to be generated dynamically. Content Integration Framework provides an alternate approach to statically define this Map using a standard service parameter called supportedContentTypes, configured under params element in the service declaration file. For example, refer the simple-search service declaration for AEM and WCM inside <ASSET_PICKER_HOME>/conf/plugin-services.yml file.

List content categories (list-content-categories)

The following are the specialized interfaces and classes available for the list-content-categories service:

  • com.hcl.unica.system.integration.service.content.categories.list. RestContentCategoriesListService

    The com.example.service.rest. ExampleContentCategoryListingService class in asset-integration-starter project is a quick starter for RESTful list-content-categories service. ExampleContentCategoryListingService class extends from RestContentCategoriesListService class.

    The RestContentCategoriesListService class has a type parameter RS, which represents the type of response (post deserialization) received from the remote REST API. In this case it is specified as List<ContentCategoryDetails> for the sake of example.

    RestContentCategoriesListService class implements RestService interface and defines the com.hcl.unica.system.model.request.content.categories.ContentCategoryListRequest class as the type argument RQ for RestService. Thus, the object of ContentCategoryListRequest becomes input to all the list-content-categories services (same input is used for Functional counterpart of list-content-categories as well). ContentCategoryListRequest object should be consulted for parent category ID as well as for parent folder ID if categories are hierarchical and/or maintained in folder hierarchy.

    In addition to defining the input type for the list-content-categories service, RestContentCategoriesListService class also overrides the transformResponse method and mandates the return value of this method to be an object of List<ContentCategory> type. ContentCategory class is part of Content Integration SDK.

    The plugin must extend the implementation of list-content-categories service from com.hcl.unica.system.integration.service.content.categories.list. RestContentCategoriesListService class to be recognized as a valid list-content-categories service by the Content Integration Framework (Functional counterpart, discussed later, is also a valid choice to extend from).

    RestContentCategoriesListService extends from 
    com.hcl.unica.system.integration.service.content.categories.list.AbstractContentCategoriesListService class
    .

  • com.hcl.unica.system.integration.service.content.categories.list.AbstractContentCategoriesListService

    This is a common base class for RESTful as well as Functional implementations of list-content-categories service. So, the details covered herein applies to Functional version of list-content-categories as well.

    This class defines the com.hcl.unica.system.integration.service.gateway.ContentCategoriesListServiceGateway interface as the service gateway for the list-content-categories service. This interface extends from com.hcl.unica.system.integration.service.gateway. ServiceGateway interface and mandates the ContentCategoryListRequest & List<ContentCategory> objects to be the input and output types for the list-content-categories service.

List folders (list-folders)

The following are the specialized interfaces and classes available for the list-folders service:

  • com.hcl.unica.system.integration.service.folder.list.RestFolderListService

    The com.aem.service.AemFolderListService class in aem-integration project is a reference implementation for RESTful list-folders service. AemFolderListService class extends from RestFolderListService class.

    The RestFolderListService class has a type parameter RS, which represents the type of response (post deserialization) received from the remote REST API. In this case it is SimpleSearchResponse class defined inside the aem-integration project.

    RestFolderListService class implements RestService interface and defines the com.hcl.unica.system.model.request.folder.list.FolderListRequest class as the type argument RQ for RestService. Thus, the object of FolderListRequest becomes input to all the list-folders services (same input is used for Functional counterpart of list-folders as well).

    In addition to defining the input type for the list-folders service, RestFolderListService class also overrides the transformResponse method and mandates the return value of this method to be an object of List<Folder> type. Folder is a standard type defined in Content Integration SDK.

    The plugin must extend the implementation of list-folders service from com.hcl.unica.system.integration.service.folder.list.RestFolderListService class to be recognized as a valid list-folders service by the Content Integration Framework (Functional counterpart, discussed later, is also a valid choice to extend from).

    RestFolderListService extends from com.hcl.unica.system.integration.service.folder.list.AbstractFolderListService class.

  • com.hcl.unica.system.integration.service.folder.list. AbstractFolderListService

    This is a common base class for RESTful as well as Functional implementations of list-folders service. So, the details covered herein applies to Functional version of list-folders as well.

    This class defines the com.hcl.unica.system.integration.service.gateway.FolderListServiceGateway interface as the service gateway for the list-folders service. This interface extends from com.hcl.unica.system.integration.service.gateway.ServiceGateway interface and mandates the FolderListRequest and List<Folder> objects to be the input and output types for the list-folders service.

List category folders (list-category-folders)

The specialized types used for implementing list-category-folders are exactly same as the ones used for list-folders.

List contents (list-contents)

The following are the specialized interfaces and classes available for the list-contents service:

  • com.hcl.unica.system.integration.service.content.list.RestContentListService

    The com.aem.service.AemContentListServiceclass in aem-integration project is a reference implementation for RESTful list-contents service. AemContentListServiceclass class extends from RestContentListService class.

    The RestContentListService class has a type parameter RS, which represents the type of response (post deserialization) received from the remote REST API. In this case it is SimpleSearchResponse class defined inside the aem-integration project.

    RestContentListService class implements RestService interface and defines the com.hcl.unica.system.model.request.content.list.ContentListRequest class as the type argument RQ for RestService. Thus, the object of ContentListRequest becomes input to all the list-contents services (same input is used for Functional counterpart of list-contents as well).

    In addition to defining the input type for the list-contents service, RestContentListService class also overrides the transformResponse method and mandates the return value of this method to be an object of ContentPage type. This return type is same as the one used for simple-search service. ContentPage is a standard type defined in Content Integration SDK.

    The plugin must extend the implementation of list-contents service from com.hcl.unica.system.integration.service.content.list.RestContentListService class to be recognized as a valid list-contents service by the Content Integration Framework (Functional counterpart, discussed later, is also a valid choice to extend from).

    RestContentListService extends from com.hcl.unica.system.integration.service.content.list.AbstractContentListService class.

  • com.hcl.unica.system.integration.service.content.list.AbstractContentListService

    This is a common base class for RESTful as well as Functional implementations of list-contents service. So, the details covered herein applies to Functional version of list-contents as well.

    This class defines the com.hcl.unica.system.integration.service.gateway.ContentListServiceGateway interface as the service gateway for the list-contents service. This interface extends from com.hcl.unica.system.integration.service.gateway.ServiceGateway interface and mandates the ContentListRequest and ContentPage objects to be the input and output types for the list-contents service.

Get content details (get-content-details)

The following are the specialized interfaces and classes available for the get-content-details service:

  • com.hcl.unica.system.integration.service.content.details.RestContentDetailsService

    The com.aem.service.AemObjectDetailsService class in aem-integration project is a reference implementation for RESTful get-content-details service. AemObjectDetailsService class extends from RestContentDetailsService class.

    The RestContentDetailsService class has a type parameter RS, which represents the type of response (post deserialization) received from the remote REST API. In this case it is SimpleSearchResponse class defined inside the aem-integration project.

    RestContentDetailsService class implements RestService interface and defines the com.hcl.unica.system.model.request.content.details.ContentDetailsRequest class as the type argument RQ for RestService. Thus, the object of ContentDetailsRequest becomes input to all the get-content-details services (same input is used for Functional counterpart of get-content-details as well).

    In addition to defining the input type for the get-content-details service, RestContentDetailsService class also overrides the transformResponse method and mandates the return value of this method to be an object of Presentable type.

    The plugin must extend the implementation of get-content-details service from com.hcl.unica.system.integration.service.content.details.RestContentDetailsService class to be recognized as a valid get-content-details service by the Content Integration Framework (Functional counterpart, discussed later, is also a valid choice to extend from).

    RestContentDetailsService extends from the com.hcl.unica.system.integration.service.content.details.AbstractContentDetailsService class.

  • com.hcl.unica.system.integration.service.content.details.AbstractContentDetailsService

    This is a common base class for RESTful as well as Functional implementations of get-content-details service. So, the details covered herein applies to Functional version of get-content-details as well.

    This class defines the com.hcl.unica.system.integration.service.gateway.ContentDetailsServiceGateway interface as the service gateway for the get-content-details service. ServiceGateways are the means to programmatically define input and output types of the service and facilitate invocation of the services. A closer look at this interface tells us that the get-content-details service accepts the ContentDetailsRequest object and returns a Presentable object.

Get cognitive analysis (get-cognitive-analysis)

The following are the specialized interfaces and classes available for the get-cognitive-analysis service:

  • com.hcl.unica.system.integration.service.cognitive.analysis.RestCognitiveAnalysisService

    The com.example.service.rest.ExampleCognitiveAnalysisService in asset-integration-starter project is a quick starter implementation for RESTful get-cognitive-analysis service. ExampleCognitiveAnalysisService in class extends from RestCognitiveAnalysisService class.

    The RestCognitiveAnalysisService class has a type parameter RS, which represents the type of response (post deserialization) received from the remote REST API. In this case it is CognitiveDetails class defined inside the asset-integration-starter project.

    RestCognitiveAnalysisService class implements RestService interface and defines the com.hcl.unica.system.model.request.cognitive.analysis.CognitiveAnalysisRequest class as the type argument RQ for RestService. Thus, the object of CognitiveAnalysisRequest becomes input to all the get-cognitive-analysis services (same input is used for Functional counterpart as well).

    In addition to defining the input type for the get-cognitive-analysis service, RestCognitiveAnalysisService class also overrides the transformResponse method and mandates the return value of this method to be an object of com.hcl.unica.system.model.response.cognitive.analysis.CognitiveAnalysis type. CognitiveAnalysis is a standard type defined in Content Integration SDK.

    The plugin must extend the implementation of get-cognitive-analysis service from com.hcl.unica.system.integration.service.cognitive.analysis.RestCognitiveAnalysisService class to be recognized as a valid get-cognitive-analysis service by the Content Integration Framework (Functional counterpart, discussed later, is also a valid choice to extend from).

    RestCognitiveAnalysisService extends from com.hcl.unica.system.integration.service.cognitive.analysis.AbstractCognitiveAnalysisService class.

  • com.hcl.unica.system.integration.service.cognitive.analysis.AbstractCognitiveAnalysisService

    This is a common base class for RESTful as well as Functional implementations of get-cognitive-analysis service. So, the details covered herein applies to Functional version of get-cognitive-analysis as well.

    This class defines the com.hcl.unica.system.integration.service.gateway.CognitiveAnalysisServiceGateway interface as the service gateway for the get-cognitive-analysis service. This interface extends from com.hcl.unica.system.integration.service.gateway.ServiceGateway interface and mandates the CognitiveAnalysisRequest and CognitiveAnalysis objects to be the input and output types for the get-cognitive-analysis service.

Object extension service

The following are the specialized interfaces and classes available for the object extension service:
  • com.hcl.unica.system.integration.service.object.extension.RestObjectExtensionService

    The com.example.service.rest.ExampleObjectExtensionService in asset-integration-starter project is a quick starter implementation for RESTful object extension service. ExampleObjectExtensionService class extends from RestObjectExtensionService class.

    The RestObjectExtensionService class has a type parameter RS, which represents the type of response (post deserialization) received from the remote REST API. In this case, it is CognitiveDetails class defined inside the asset-integration-starter project.

    RestObjectExtensionService class implements RestService interface and defines the com.hcl.unica.system.model.request.object.extension.ObjectExtensionRequest class as the type argument RQ for RestService. Thus, the object of ObjectExtensionRequest becomes input to object extension services (same input is used for Functional counterpart as well). ObjectExtensionRequest is discussed in subsequent section.

    In addition to defining the input type for object extension service, RestObjectExtensionService class also overrides the transformResponse method and allows returning any type of object.

    The plugin must extend the implementation of object extension service from com. hcl.unica.system.integration.service.object.extension.RestObjectExtensionService class to be recognized as a valid object extension service by the Content Integration Framework (Functional counterpart, discussed later, is also a valid choice to extend from).

    RestObjectExtensionService extends from com.hcl.unica.system.integration.service.object.extension.AbstractObjectExtensionService class.

  • com.hcl.unica.system.model.request.object.extension.ObjectExtensionRequest

    The ObjectExtensionRequest provides and API to retrieve values of request attributes. The core principle of object extension service is to accept desired request attributes, perform designated operation and optionally return with a response object. Request attribute values are obtained from the object whose capabilities need to be extended by using the object extension service being implemented. Implementation of object extension service must be request object agnostic. It is the responsibility of Content Integration Framework to extract request attributes from the object to be extended and supply it to the object extension service by means of ObjectExtensionRequest. Thus, object extension service must be able to extend the capability of any object if the object being extended contains the required request attributes for the object extension service. ObjectExtensionRequest provides following methods for obtaining request attribute values –

    • Collection<AttributeValue> getAttributeValues() – This method returns a collection of all request attribute values.

      Attribute values are wrapped inside AttributeValue object, which provides API for reading the value of attribute. It provides a convenience method, as(Class<T> type), for obtaining type cast value of the attribute. Likewise, getValue() method can be used to read the uncast value.

      Furthermore, AttributeValue class provides getAttributeSchema() method to obtain the meta information about respective attribute. getAttributeSchema() returns an object of AttributeSchema containing the required meta information about attribute. The most important methods in AttributeSchema are getType() & getFormat(). These methods can be consulted to check if the attribute is of desired type. As of 12.1.1 release of Content Integration Framework, object extension service may receive values for the attributes which are not of required type. Hence, extension service must consult the type & format of the attribute before using its value. Service implementation must filter the required attribute values by itself. Refer to the buildRequest method implementation in com.example.service.rest.ExampleObjectExtensionService to learn how this can be achieved. This example implementation tries to extract first URL & first Text attribute from the request.

    • Map<String, AttributeValue> getAttributes() - From release 12.1.2 onward, request attributes of object extension service can also be mapped to source object’s attributes. get-object-schema service must be enhanced in such case to generate schema for request object. Following standard service parameter must be set to true if request attribute mapping is desired for the given object extension service. If this parameter is missing, it is assumed to be false by default. Likewise, requirement of response attribute mapping can also be indicated using attributeMappingSupport | response parameter. By default, Content Integration Framework assumes value for response to be true.
          params:
      attributeMappingSupport:
        request: true
        response: true
      getAttributes() method returns map of attribute values, wherein values are organized by respective attribute identifiers. The Map object returned by this method is useful for retrieving attribute value using its identifier (as used in object schema).

      Object extension service can override void validateRequest(ExecutionContext<ObjectExtensionRequest> executionContext) method to probe request attributes before performing core operation. InvalidServiceRequestException can be raised If desired attributes are not found in the ObjectExtensionRequest. Refer to the Validation support

    • boolean isStronglyBound() – Object extension services written prior to 12.1.2 may still receive unmapped requests if user hasn’t changed the request mapping for such services. This method can be consulted to check if request object attribute mapping exists for the given execution request. This method returns true if object extension service does have request object attribute mapping, false otherwise. If this method returns true, service can look for its request object attributes by their identifiers in the Map returned by getAttributes() method. Else, it must find out required type of attributes the way ExampleObjectExtensionService does in asset-integration-starter project.
  • com.hcl.unica.system.integration.service.object.extension.AbstractObjectExtensionService

    This is a common base class for RESTful as well as Functional implementations of object extension service. So, the details covered herein applies to Functional version as well.

    This class defines the com.hcl.unica.system.integration.service.gateway.ObjectExtensionServiceGateway interface as the service gateway for object extension service. This interface extends from com.hcl.unica.system.integration.service.gateway.ServiceGateway interface and mandates the ObjectExtensionRequest to be the input type for object extension service. Object extension service can return any type of object.

    Service title & summary

    Object extension services are listed as Custom actions in Centralized Offer Management. The title/label for object extension service is derived from I18n resource bundles using the key same as service name declared for respective object extension service. Likewise, a brief summary is also shown for the service to help users working with it. Summary is maintained in I18n resource bundles using {service-name}.summary key. For example, check example-object-extension-service & example-object-extension-service.summary keys in asset-integration-starter\src\main\resources\i18n\Foo_Messages.properties file.

Collaboration services

  • Channel creation service (collaboration.create-channel)
    - The following are the specialized interfaces and classes available for the collaboration.create-channel service:

    • com.hcl.unica.system.integration.service.collab.channel.create.RestChannelCreationService –

      The com.example.service.rest.collaboration. ExampleChannelCreationService in asset-integration-starter project is a quick starter implementation for RESTful collaboration.create-channel service. ExampleChannelCreationService class extends from RestChannelCreationService class.

      The RestChannelCreationService class has a type parameter RS, which represents the type of response (post deserialization) received from the remote REST API. In this case it is JsonNode class defined inside the ExampleChannelCreationService class.

      RestChannelCreationService class implements RestService interface and defines the com.hcl.unica.system.model.request.collab.channel.CollaborationChannelCreationRequest class as the type argument RQ for RestService. Thus, the object of CollaborationChannelCreationRequest becomes input to all the collaboration.create-channel services (same input is used for Functional counterpart as well). CollaborationChannelCreationRequest carries the name of channel to be created.

      In addition to defining the input type for the collaboration.create-channel service, RestChannelCreationService class also overrides the transformResponse method and mandates the return value of this method to be an object of com.hcl.unica.system.model.response.collab.channel.CollaborationChannelDetails type. CollaborationChannelDetails must carry the identifier of the newly created channel in addition to its name.

      Plugin must extend the implementation of collaboration.create-channel service from RestChannelCreationService class to be recognized as a valid collaboration.create-channel service by the Content Integration Framework (Functional counterpart, discussed later, is also a valid choice to extend from).

  • Channel modification service (collaboration.update-channel)
    The following are the specialized interfaces and classes available for the collaboration.update-channel service:

    • com.hcl.unica.system.integration.service.collab.channel.update.RestChannelModificationService –

      The com.example.service.rest.collaboration. ExampleChannelModificationService in asset-integration-starter project is a quick starter implementation for RESTful collaboration.update-channel service. ExampleChannelModificationService class extends from RestChannelModificationService class.

      The RestChannelModificationService class has a type parameter RS, which represents the type of response (post deserialization) received from the remote REST API. In this case it is JsonNode class defined inside the ExampleChannelModificationService class.

      RestChannelModificationService class implements RestService interface and defines the com.hcl.unica.system.model.request.collab.channel.CollaborationChannelModificationRequest class as the type argument RQ for RestService. Thus, the object of CollaborationChannelModificationRequest becomes input to all the collaboration.update-channel services (same input is used for Functional counterpart as well). CollaborationChannelModificationRequest carries the identifier of the channel to be updated along with the new channel name.

      In addition to defining the input type for the collaboration.update-channel service, RestChannelModificationService class also overrides the transformResponse method and mandates the return value of this method to be an object of com.hcl.unica.system.model.response.collab.channel.CollaborationChannelDetails type. CollaborationChannelDetails must carry the identifier & name of the updated channel.

      Plugin must extend the implementation of collaboration.update-channel service from RestChannelModificationService class to be recognized as a valid collaboration.update-channel service by the Content Integration Framework (Functional counterpart, discussed later, is also a valid choice to extend from).

  • Channel details service (collaboration.get-channel-details)
    The following are the specialized interfaces and classes available for the collaboration.get-channel-details service:

    • com.hcl.unica.system.integration.service.collab.channel.details.RestChannelDetailsService –

      The com.example.service.rest.collaboration.ExampleChannelDetailsService in asset-integration-starter project is a quick starter implementation for RESTful collaboration.get-channel-details service. ExampleChannelDetailsService class extends from RestChannelDetailsService class.

      The RestChannelDetailsService class has a type parameter RS, which represents the type of response (post deserialization) received from the remote REST API. In this case it is JsonNode class defined inside the ExampleChannelDetailsService class.

      RestChannelDetailsService class implements RestService interface and defines the com.hcl.unica.system.model.request.collab.channel.CollaborationChannelDetailsRequest class as the type argument RQ for RestService. Thus, the object of CollaborationChannelDetailsRequest becomes input to all the collaboration.get-channel-details services (same input is used for Functional counterpart as well). CollaborationChannelDetailsRequest carries the identifier of the channel to be retrieved.

      In addition to defining the input type for the collaboration.get-channel-details service, RestChannelDetailsService class also overrides the transformResponse method and mandates the return value of this method to be an object of java.util.Optional of com.hcl.unica.system.model.response.collab.channel.CollaborationChannelDetails type. CollaborationChannelDetails must carry the identifier & name of the requested channel. If requested channel is not found, this method can return Optional.empty().

      Plugin must extend the implementation of collaboration.get-channel-details service from RestChannelDetailsService class to be recognized as a valid collaboration.get-channel-details service by the Content Integration Framework (Functional counterpart, discussed later, is also a valid choice to extend from).

  • Member addition service (collaboration.add-members-to-channel)
    The following are the specialized interfaces and classes available for the collaboration.add-members-to-channel service:

    • com.hcl.unica.system.integration.service.collab.channel.member.RestChannelMemberAdditionService –

      The com.example.service.rest.collaboration.ExampleMemberAdditionService in asset-integration-starter project is a quick starter implementation for RESTful collaboration.add-members-to-channel service. ExampleMemberAdditionService class extends from RestChannelMemberAdditionService class.

      The RestChannelMemberAdditionService class has a type parameter RS, which represents the type of response (post deserialization) received from the remote REST API. In this case it is JsonNode class defined inside the ExampleMemberAdditionService class.

      RestChannelMemberAdditionService class implements RestService interface and defines the com.hcl.unica.system.model.request.collab.channel.CollaborationChannelMembers class as the type argument RQ for RestService. Thus, the object of CollaborationChannelMembers becomes input to all the collaboration.add-members-to-channel services (same input is used for Functional counterpart as well). CollaborationChannelMembers carries the channel identifier & list of com.hcl.unica.system.model.request.collab.channel.CollaborationChannelMember objects. Each CollaborationChannelMember object carries identifier of the user/member to be added to the channel corresponding to the supplied channel identifier.

      In addition to defining the input type for the collaboration.add-members-to-channel service, RestChannelMemberAdditionService class also overrides the transformResponse method and mandates the return value of this method to be an object of com.hcl.unica.system.model.response.collab.channel.ChannelMembersAdditionStatus type. ChannelMembersAdditionStatus must carry the list of com.hcl.unica.system.model.response.collab.channel.ChannelMemberAdditionStatus objects containing addition status for each supplied member. The memberId property in ChannelMemberAdditionStatus object should carry the identifier of member/user the status is being reported for. The error property can be used to convey error message associated with specified member’s addition operation. Plugin can choose to send localized error using an API provided by ExecutionContext. The ok property must be set to true if member is successfully added to the channel, or to false otherwise. Reason property should be used to convey appropriate failure reason. The entire list of member addition status should be set on the status property of ChannelMembersAdditionStatus object to be returned from transformResponse method.

      Plugin must extend the implementation of collaboration.add-members-to-channel service from RestChannelMemberAdditionService class to be recognized as a valid collaboration.add-members-to-channel service by the Content Integration Framework (Functional counterpart, discussed later, is also a valid choice to extend from).

  • Member removal service (collaboration.remove-members-from-channel)
    The following are the specialized interfaces and classes available for the collaboration.remove-members-from-channel service:

    • com.hcl.unica.system.integration.service.collab.channel.member.RestChannelMemberRemovalService –

      The com.example.service.rest.collaboration.ExampleMemberRemovalService in asset-integration-starter project is a quick starter implementation for RESTful collaboration.remove-members-from-channel service. ExampleMemberRemovalService class extends from RestChannelMemberRemovalService class.

      The RestChannelMemberRemovalService class has a type parameter RS, which represents the type of response (post deserialization) received from the remote REST API. In this case it is JsonNode class defined inside the ExampleMemberRemovalService class.

      RestChannelMemberRemovalService class implements RestService interface and defines the com.hcl.unica.system.model.request.collab.channel.CollaborationChannelMembers class as the type argument RQ for RestService. Thus, the object of CollaborationChannelMembers becomes input to all the collaboration.remove-members-from-channel services (same input is used for Functional counterpart as well). CollaborationChannelMembers carries the channel identifier & list of com.hcl.unica.system.model.request.collab.channel.CollaborationChannelMember objects. Each CollaborationChannelMember object carries identifier of the user/member to be removed from the channel corresponding to the supplied channel identifier.

      In addition to defining the input type for the collaboration.remove-members-from-channel service, RestChannelMemberRemovalService class also overrides the transformResponse method and mandates the return value of this method to be an object of com.hcl.unica.system.model.response.collab.channel.ChannelMembersRemovalStatus type. ChannelMembersRemovalStatus must carry the list of com.hcl.unica.system.model.response.collab.channel.ChannelMemberRemovalStatus objects containing removal status for each supplied member. The memberId property in ChannelMemberRemovalStatus object should carry the identifier of member/user the status is being reported for. The error property can be used to convey error message associated with specified member’s removal operation. Plugin can choose to send localized error using an API provided by ExecutionContext. The ok property must be set to true if member is successfully removed from the channel, or to false otherwise. reason property should be used to convey appropriate failure reason. The entire list of member addition status should be set on the status property of ChannelMembersRemovalStatus object to be returned from transformResponse method.

      Plugin must extend the implementation of collaboration.remove-members-from-channel service from RestChannelMemberRemovalService class to be recognized as a valid collaboration.remove-members-from-channel service by the Content Integration Framework (Functional counterpart, discussed later, is also a valid choice to extend from).

  • Message posting service (collaboration.post-message-to-channel)
    The following are the specialized interfaces and classes available for the collaboration.post-message-to-channel service:

    • com.hcl.unica.system.integration.service.collab.channel.message.RestMessagePostingService –

      The com.example.service.rest.collaboration.ExampleMessagePostingService in asset-integration-starter project is a quick starter implementation for RESTful collaboration.post-message-to-channel service. ExampleMessagePostingService class extends from RestMessagePostingService class.

      The RestMessagePostingService class has a type parameter RS, which represents the type of response (post deserialization) received from the remote REST API. In this case it is JsonNode class defined inside the ExampleMessagePostingService class.

      RestMessagePostingService class implements RestService interface and defines the com.hcl.unica.system.model.request.collab.channel.GroupMessage class as the type argument RQ for RestService. Thus, the object of GroupMessage becomes input to all the collaboration.post-message-to-channel services (same input is used for Functional counterpart as well). GroupMessage carries the identifier of target channel & the message itself.

      In addition to defining the input type for the collaboration.post-message-to-channel service, RestMessagePostingService class also overrides the transformResponse method and mandates the return value of this method to be an object of same GroupMessage type. The response GroupMessage object should carry the identifier of newly posted message.

      Plugin must extend the implementation of collaboration.post-message-to-channel service from RestMessagePostingService class to be recognized as a valid collaboration.post-message-to-channel service by the Content Integration Framework (Functional counterpart, discussed later, is also a valid choice to extend from).