Ableitungen von Funktionsservice

Einfache Suche (simple-search)

Im Folgenden sind die spezialisierten Schnittstellen und Klassen aufgeführt, die für die einfache Suche verwendet werden können:

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

  Die com.example.service.functional.SimpleSearchService-Klasse im asset-integration-starter-Projekt ist eine Schnellstartimplementierung für den simple-search service-Funktionsservice. Es wird von der com.hcl.unica.system.integration.service.search.SearchService Klasse abgeleitet.

  Die SearchService-Klasse implementiert die FunctionalService-Schnittstelle und definiert die SearchRequest-Klasse und ContentPage-Klasse als die Typargumente RQ & RS für den Funktionsservice. Dadurch wird das Objekt des SearchRequest zu einem Input für alle simple-search-Services, und das ContentPage wird nach Beendigung des Services als Output erwartet.

  Das Plug-in muss seine simple-search-Implementierung aus der com.hcl.unica.system.integration.service.search.SearchService-Klasse ableiten, um von der simple-search als Content Integration Framework-Service erkannt zu werden (das im vorigen Abschnitt beschriebene RESTful-Pendant ist ebenfalls eine gültige Wahl für die simple-search-Services, die mit dem RESTful-Ansatz implementiert wurden).

  Das SearchService wird von der folgenden com.hcl.unica.system.integration.service.search.AbstractSearchService abstrakten Klasse abgeleitet: Es wird eine weitere Methode mit dem Namen getSupportedContentTypes eingeführt. Weitere Informationen zur Methode finden Sie unter Ableitungen von RestService .

Ressourcenlader (resource-loader)

Im Folgenden sind die spezialisierten Schnittstellen und Klassen aufgeführt, die für den Ressourcenlader-Service zur Verfügung stehen:

• com.hcl.unica.system.integration.service.resourceloader.WebResourceLoaderService
  Die com.example.service.functional.ResourceLoaderService-Klasse im asset-integration-starter-Projekt ist eine Schnellstartimplementierung für resource-loader Funktionsservice. Es wird von der folgenden Klasse abgeleitet:

  com.hcl.unica.system.integration.service.resourceloader.WebResourceLoaderService

  Die WebResourceLoaderService-Klasse implementiert die FunctionalService-Schnittstelle und definiert die ResourceRequest und HttpResponse-Typen als die Typargumente RQ & RS für den FunctionalService. Somit wird das Objekt des ResourceRequest zu einem Input für alle resource-loader-Services, und das HttpResponse wird nach Abschluss des Services als Output erwartet (die gleichen Input- und Outputtypen werden für das RESTful-Pendant des Ressourcen-Laders verwendet). Weitere Informationen zu ResourceRequest- und HttpResponse-Typen finden Sie unter Ableitungen von RestService.

  Das Plug-in muss seine resource-loader-Implementierung aus der com.hcl.unica.system.integration.service.resourceloader.WebResourceLoaderService-Klasse ableiten, um von der resource-loader als Content Integration Framework-Service erkannt zu werden (das im vorigen Abschnitt beschriebene HTTP-Pendant ist ebenfalls eine gültige Wahl für die resource-loader-Services, die mit dem HTTP-Ansatz implementiert wurden).

  Der WebResourceLoaderService erstreckt sich über die folgende Klasse:

  com.hcl.unica.system.integration.service.resourceloader.
  AbstractWebResourceLoaderService

  Weitere Informationen zu dieser Klasse finden Sie in der Ableitungen von RestService.

Inhaltskategorien auflisten (list-content-categories)

Im Folgenden sind die speziellen Schnittstellen und Klassen aufgeführt, die für den Dienst Listeninhaltskategorien verfügbar sind:

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

  Das Plugin kann alternativ den funktionalen Ansatz zur Implementierung des list-content-categories-Dienstes wählen, indem die Implementierung von der ContentCategoriesListService-Klasse erweitert wird. Die ContentCategoriesListService-Klasse implementiert die FunctionalService-Schnittstelle und beauftragt die ContentCategoryListRequest und List<ContentCategory>-Klassen als die Typargumente RQ und RS für den FunctionalService. Dadurch wird das Objekt des ContentCategoryListRequest zu einem Input für alle list-content-categories-Dienste und das Objekt vom Typ List<ContentCategory> wird nach Abschluss des Dienstes als Output erwartet.

• Das Plugin muss seine Implementierung von Listeninhaltskategorien aus der com.hcl.unica.system.integration.service.content.categories.list.ContentCategoriesListService-Klasse ableiten, um vom Content Integration Framework als gültiger list-content-categories-Dienst erkannt zu werden (das im vorherigen Abschnitt beschriebene RESTful-Gegenstück ist ebenfalls eine gültige Option, um es zu erweitern).

  ContentCategoriesListService wird von der Klasse AbstractContentCategoriesListService abgeleitet. Details zur Klasse AbstractContentCategoriesListService werden im Thema Ableitungen von RestService behandelt.

Ordner auflisten (list-folders)

Im Folgenden sind die für den Dienst Ordner auflisten verfügbaren speziellen Schnittstellen und Klassen aufgeführt:

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

  Das Plugin kann alternativ den funktionalen Ansatz zur Implementierung des list-folders-Dienstes wählen, indem die Implementierung von der FolderListService-Klasse erweitert wird. Die FolderListService-Klasse implementiert die FunctionalService-Schnittstelle und beauftragt die FolderListRequest und List<Folder>-Klassen als die Typargumente RQ und RS für den FunctionalService. Dadurch wird das Objekt des FolderListRequest zu einem Input für alle list-folders-Dienste und das Objekt vom Typ List<Folder> wird nach Abschluss des Dienstes als Output erwartet.

• Das Plugin muss seine Implementierung von Listenordnern aus der com.hcl.unica.system.integration.service.folder.list.FolderListService-Klasse ableiten, um vom Content Integration Framework als gültiger list-folders-Dienst erkannt zu werden (das im vorherigen Abschnitt beschriebene RESTful-Gegenstück ist ebenfalls eine gültige Option, um es zu erweitern).

  FolderListService wird von der Klasse AbstractFolderListService abgeleitet. Details zur Klasse AbstractFolderListService werden im Thema Ableitungen von RestService behandelt.

Listeninhalt (list-contents)

Im Folgenden sind die speziellen Schnittstellen und Klassen aufgeführt, die für den Dienst Listeninhalte verfügbar sind:

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

  Das Plugin kann alternativ den funktionalen Ansatz zur Implementierung des list-contents-Dienstes wählen, indem die Implementierung von der ContentListService-Klasse erweitert wird. Die ContentListService-Klasse implementiert die FunctionalService-Schnittstelle und beauftragt die ContentListRequest und ContentPage-Klassen als die Typargumente RQ und RS für den FunctionalService. Dadurch wird das Objekt des ContentListRequest zu einem Input für alle list-contents-Dienste und das Objekt vom Typ ContentPage wird nach Abschluss des Dienstes als Output erwartet.

• Das Plugin muss seine Implementierung von Listeninhalten aus der com.hcl.unica.system.integration.service.content.list.ContentListService-Klasse ableiten, um vom Content Integration Framework als gültiger -Dienst erkannt zu werden (das im vorherigen Abschnitt beschriebene RESTful-Gegenstück ist ebenfalls eine gültige Option, um es zu erweitern).

  ContentListService wird von der Klasse AbstractContentListService abgeleitet. Details zur Klasse AbstractContentListService werden im Thema Ableitungen von RestService behandelt.

Inhaltsdetails abrufen (get-content-details)

Im Folgenden sind die speziellen Schnittstellen und Klassen aufgeführt, die für den Dienst Inhaltsdetails beschaffen verfügbar sind:

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

  Das Plugin kann alternativ den funktionalen Ansatz zur Implementierung des get-content-details-Dienstes wählen, indem die Implementierung von der ContentDetailsService-Klasse erweitert wird.

  Die ContentDetailsService-Klasse implementiert die FunctionalService-Schnittstelle und beauftragt die ContentDetailsRequest- und Presentable-Klassen als die Typargumente RQ und RS für den FunctionalService. Dadurch wird das Objekt des ContentDetailsRequest zu einem Input des get-content-details-Dienstes und das Objekt vom Typ Presentable wird nach Abschluss des Dienstes als Ausgabe erwartet.

  Das Plugin muss seine get-content-details-Implementierung aus der com.hcl.unica.system.integration.service.content.details.ContentDetailsService-Klasse ableiten, um vom Content Integration Framework als gültiger get-content-details-Dienst erkannt zu werden (das im vorherigen Abschnitt beschriebene RESTful-Gegenstück ist ebenfalls eine gültige Option, um es zu erweitern).

  ContentDetailsService wird von der Klasse AbstractContentDetailsService abgeleitet. Details zur Klasse AbstractContentDetailsService werden im Thema Ableitungen von RestService behandelt.

Objektschema abrufen (get-object-schema)

get-object-schema -Dienst wird verwendet, um das Hauptschema des Domänenobjekts oder der Domänenentität zu generieren, das bzw. die vom jeweiligen System zur Darstellung des Inhalts verwendet wird. Das Master-Schema in einfachster Form besteht nur aus hierarchischen Metadaten jedes zuordenbaren Inhaltsattributs. Es wird erwartet, dass die Attributhierarchie und die Metadaten mit der JSON-Darstellung des Domäne übereinstimmen. Attributmetadaten umfassen hauptsächlich den Datentyp des Attributs, das Format des im Attribut gespeicherten Werts, die eindeutige ID des Attributs und den Anzeigetitel oder die Anzeigebezeichnung für das Attribut.

Im Folgenden sind die für den get-object-schema-Service verfügbaren speziellen Schnittstellen und Klassen aufgeführt:

• com.hcl.unica.system.integration.service.object.schema.ObjectSchemaProviderService

  Die ObjectSchemaProviderService-Klasse implementiert die FunctionalService-Schnittstelle und beauftragt die com.hcl.unica.system.model.ObjectSchemaRequest und com.hcl.unica.system.model.json.schema.ObjectSchema-Klassen als die Typargumente RQ und RS für den FunctionalService. Dadurch wird das Objekt des ObjectSchemaRequest zu einem Input für alle get-object-schema-Dienste und das Objekt vom Typ ObjectSchema wird nach Abschluss des Dienstes als Output erwartet. Das Plugin sollte das ObjectSchema jedoch nicht selbst erstellen. Es sollte nur die folgende abstrakte Methode aus der ObjectSchemaProviderService-Klasse überschreiben und implementieren.

  ObjectProfile getObjectProfile(ObjectSchemaRequest objectSchemaRequest)

  Die getObjectProfile() Methode akzeptiert ObjectSchemaRequest und gibt ObjectProfile zurück. (Diese Typen werden in nachfolgenden Abschnitten behandelt.)

  Das Plugin muss get-object-schema-Implementierung aus der com.hcl.unica.system.integration.service.object.schema.ObjectSchemaProviderService-Klasse ableiten, um vom Content Integration Framework als gültiger get-object-schema-Dienst erkannt zu werden. Es gibt kein RESTful-Gegenstück zu dieser Standard-Superklasse, da die Objektschemagenerierung keine HTTP-Interaktion enthält. Plugins können benutzerdefinierte RESTful-Dienste implementieren und bei Bedarf intern aus dem get-object-schema-Dienst heraus aufrufen.

• com.hcl.unica.system.model.ObjectSchemaRequest

  Das Objekt dieser Klasse wird als Eingabe für den get-object-schema-Dienst bereitgestellt. Die wichtigste Methode dieser Klasse ist getObjectIdentity(), das ein Objekt vom Typ com.hcl.unica.system.model.ObjectIdentity zurückgibt, das die Details des Inhalts enthält, den der Benutzer ausgewählt hat, um das Masterschema anzufordern. Dazu gehören applicationId (die System-ID), objectType (Inhaltstyp-/Kategorie-ID) und objectId (eindeutige Kennung des ausgewählten Inhalts). Unabhängig von der Kategorie und/oder dem Inhalt, die der Benutzer beim Einrichten der Inhaltszuordnung ausgewählt hat, muss das generierte Schema Attribute aller Inhaltsarten enthalten, die vom jeweiligen System unterstützt werden. Mit anderen Worten, für die Zuordnung aller vom angegebenen System bereitgestellten Inhaltstypen wird nur ein Masterschema verwendet.

  Die getEnrichmentObjectJson()-Methode in der ObjectSchemaRequest-Klasse kann ab dem aktuellen Release ignoriert werden.

• com.hcl.unica.system.integration.service.object.schema.ObjectProfile

  Dies ist ein Rückgabetyp der getObjectProfile()-Methode im get-object-schema-Dienst. Sie enthält den Java-Typ, der der Domäne / dem Objekt für das jeweilige System entspricht. Content Integration Framework verwendet diesen Java-Typ, um das Schema für öffentliche und nicht öffentliche, nicht statische Klasseneigenschaften (einschließlich Enums & Optionals) zu generieren. Mit der @MappableAttribute-Annotation kann jede einzelne Klasseneigenschaft konfiguriert werden, um das von Content Integration Framework generierte Schema zu steuern. Lesen Sie das com.aem.model.response.simplesearch.SimpleSearchItem-Domänenobjekt im aem-integration reference-Projekt, um eine Vorstellung davon zu erhalten, wie diese Anmerkung verwendet wird. Weitere Details zu @MappableAttribute finden Sie im nächsten Abschnitt. ObjectProfile kann optional eine Instanz von com.hcl.unica.system.integration.service.object.schema.ObjectSchemaEnricher einschließen, um Attribute dynamisch zu dem so generierten Schema hinzuzufügen, zu ändern oder zu entfernen. Im nächsten Abschnitt wird ObjectSchemaEnricher detailliert erläutert.

• com.hcl.unica.system.integration.service.object.schema.ObjectSchemaEnricher

  ObjectSchemaEnricher ist eine abstrakte Klasse. Plug-in sollte es erweitern, um die gewünschte Implementierung zu haben. Der Typparameter für die ObjectSchemaEnricher-Klasse stellt den Java-Typ mit den zusätzlichen Details dar, die zur Bereicherung des statisch generierten Objektschemas erforderlich sind. Diese zusätzlichen Details werden möglicherweise von den Clientanwendungen der Unica Content Integration bereitgestellt. Ab dem aktuellen Release werden keine zusätzlichen Details bereitgestellt, daher sollte sie bei der Implementierung der Schemaerweiterung auf Ungültig gesetzt werden. ObjectSchemaEnricher deklariert nur eine abstrakte Methode, die vom Plug-in implementiert werden sollte:

  abstract public ObjectSchema enrich(
  		ObjectSchema objectSchema, 
  		ObjectSchemaEnrichmentRequest<T> objectSchemaEnrichmentRequest
  )

  Das erste Argument für diese Methode ist eine Instanz der com.hcl.unica.system.model.json.schema.ObjectSchema-Klasse. Es enthält das automatisch generierte Domänenobjektschema, das vom in ObjectProfile angegebenen Java-Typ abgeleitet ist. Im Kern ist ObjectSchema nur ein Map<String, AttributeSchema>, wobei Klasseneigenschaftsnamen die Schlüssel dieser Karte bilden und Eigenschaftsmetadaten als Objekt von AttributeSchema enden. Wenn sich die Klasseneigenschaft wiederum auf ein anderes Objekt bezieht, hat das entsprechende AttributeSchema ein weiteres Map<String, AttributeSchema>, das die Attribute dieses Objekttyps enthält, usw.

  Anmerkung: Es ist wichtig, zu beachten, dass Attributnamen, die als Schlüssel in der Attributzuordnung verwendet werden, den JSON-Eigenschaften entsprechen, die in der JSON-Darstellung des Domäne enden. Wenn die @JsonProperty-Annotation verwendet wird, um den JSON-Eigenschaftsnamen für ein bestimmtes Klassenattribut zu überschreiben, erkennt Content Integration Framework diesen automatisch und verwendet den überschriebenen Eigenschaftsnamen.

  ObjectSchema und AttributeSchema erweitern sich von der abstrakten Klasse com.hcl.unica.system.model.json.schema.AttributeContainer. AttributeContainer bietet ObjectSchema- und AttributeSchema-Klassen bequeme Methoden zum Navigieren durch die Attributhierarchie sowie zum Hinzufügen, Ändern und Entfernen von Attributen auf jeder Hierarchieebene, um die Schemaanreicherung zu vereinfachen. Auf Attribute auf jeder Hierarchieebene kann mithilfe ihrer Namen, wie sie in der JSON-Darstellung erscheinen, zugegriffen und bearbeitet werden.

• com.hcl.unica.system.model.json.schema.generator.annotations.MappableAttribute

  @MappableAttribute-Annotation bietet eine Möglichkeit, um zu steuern, wie Content Integration Framework ein Objektschema aus dem entsprechenden Java-Typ generiert. Die Verwendung @MappableAttribute von ist nicht obligatorisch. Wird es nicht verwendet, berechnet Content Integration Framework automatisch Metadaten für Eigenschaften. Falls erforderlich, sollte diese Anmerkung über den gewünschten Klasseneigenschaften platziert werden. Die folgenden Annotationsattribute können zur Steuerung der Schemagenerierung verwendet werden:

  • ausgeblendet – Setzen Sie diese Eigenschaft auf wahr, um bestimmte Eigenschaften explizit aus dem Objektschema auszuschließen (@JsonIgnore wird derzeit vom Content Integration Framework nicht berücksichtigt. Daher muss jede Eigenschaft, die von der JSON-Darstellung mit @JsonIgnore ausgeschlossen ist, explizit vom Schema ausgeschlossen werden.
  • id – Angabe einer eindeutigen Kennung für die Eigenschaft. Content Integration Framework benötigt für jede zugeordnete Klasseneigenschaft eine eindeutige ID. Wenn @MappableAttribute nicht verwendet wird oder keine ID angegeben ist, wird eine ID automatisch basierend auf der Position der Eigenschaft innerhalb der Klasse generiert.

    Die automatische Generierung der Attributkennung hängt vom Namen und der hierarchischen Position der Klasseneigenschaft im Domänenobjektdiagramm ab. Wenn der Eigenschaftsname geändert und/oder in der Hierarchie des Objektdiagramms nach oben oder unten verschoben wird, ändert sich die ihm zugeordnete ID. Ein solches Refaktorieren kann das Content Integration Framework beim Lesen der Werte refaktorierter Attribute irreführen und zu unerwünschten Daten in zugeordneten Inhalten führen (z. B. Angebote in COM). Daher wird empfohlen, eindeutige Attribut-IDs manuell zu zuordnen, um solche unbeabsichtigten Änderungen an Attribut-IDs zu vermeiden, die unabhängig vom Namen und der Position der Klasseneigenschaften konstant bleiben.

  • Titel – Anzeigetitel/-bezeichnung für die Eigenschaft. Wird dies nicht angegeben, generiert Content Integration Framework eines unter Verwendung des Eigenschaftsnamens.
  • Typ – Einer der Werte aus com.hcl.unica.system.model.json.schema.generator.annotations.AttributeType. Wird dies nicht angegeben, erkennt Content Integration Framework automatisch den entsprechenden Typ.
  • Format – Einer der Werte aus com.hcl.unica.system.model.json.schema.generator.annotations.AttributeFormat. Content Integration Framework kann standardmäßige temporäre Java-Typen (Date, LocalDateTime, Instant) automatisch identifizieren und den Attributtyp auf DATETIME setzen. Andere Formate sollten explizit deklariert werden.
  • Implementation – Sollte für polynische Referenzen verwendet werden, um explizit den Java-Typ zu deklarieren, der für die automatische Schemagenerierung berücksichtigt werden soll.
  • hiddenProperties - @MappableAttribute-Annotation kann auf Klassenebene verwendet werden, um mehrere Eigenschaften an einer einzigen Stelle auszublenden. hiddenProperties nimmt ein Array aus Zeichenfolgen, die die Namen der Eigenschaften (direkt und übernommen) enthalten, die aus dem automatisch generierten Schema ausgeschlossen werden sollen. Dies ist besonders nützlich, um Eigenschaften zu ausblenden, die von übergeordneten Klassen von Drittanbietern übernommen wurden.

  Zuordnung zwischen Java-Typ und AttributeType

  In der folgenden Tabelle wird die Zuordnung zwischen Java-Typ und AttributeType/AttributeFormat zusammengefasst, die vom Content Integration Framework für die automatische Schemagenerierung verwendet wird:

  Java-Typ	AttributeType	AttributeFormat
  String Character Char CharSequence LocalDate LocalTime ZonedDateTime OffsetDateTime OffsetTime ZoneId Calendar UUID	STRING
  Boolean boolean	BOOLEAN
  BigInteger Integer Int Long Long Short Short Byte byte	INTEGER
  BigDecimal Number Double Double Float float	NUMBER
  Date LocalDateTime Instant Das Content Integration Framework erwartet, dass Datumswerte in UTC-Standardzeit ausgedrückt werden. Temporäre Werte, die in einer anderen Zeitzone ausgedrückt werden, können in weiteren Anwendungsfällen zu ungenauen zeitlichen Berechnungen führen.	INTEGER	DATETIME

kognitive Analyse abfrufen (get-cognitive-analysis)

Im Folgenden sind die für den Dienst Kognitive Analyse abrufen verfügbaren speziellen Schnittstellen und Klassen aufgeführt:

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

  Das Plugin kann alternativ den funktionalen Ansatz zur Implementierung des get-cognitive-analysis-Dienstes wählen, indem die Implementierung von der CognitiveAnalysisService-Klasse erweitert wird. Die CognitiveAnalysisService-Klasse implementiert die FunctionalService-Schnittstelle und beauftragt die CognitiveAnalysisRequest und CognitiveAnalysis-Klassen als die Typargumente RQ und RS für den FunctionalService. Dadurch wird das Objekt des CognitiveAnalysisRequest zu einem Input für alle get-cognitive-analysis-Dienste und das Objekt vom Typ CognitiveAnalysis wird nach Abschluss des Dienstes als Output erwartet.

• Das Plugin muss seine get-cognitive-analysis-Implementierung aus der com.hcl.unica.system.integration.service.cognitive.analysis.CognitiveAnalysisService-Klasse ableiten, um vom Content Integration Framework als gültiger get-cognitive-analysis-Dienst erkannt zu werden (das im vorherigen Abschnitt beschriebene RESTful-Gegenstück ist ebenfalls eine gültige Option, um es zu erweitern).

  CognitiveAnalysisService erweiter sich von der AbstractCognitiveAnalysisService-Klasse. Details zur Klasse AbstractCognitiveAnalysisService werden im Thema Ableitungen von RestService behandelt.