Generieren und Installieren von spartenspezifischen APIs

Das folgende Diagramm bietet eine allgemeine Übersicht darüber, wie Sparten normalerweise mit dem Advanced Product Designer erstellt werden.


Lebenszyklus des Produkts im Advanced Product Designer
  1. Das Produkt und seine Sparten beginnen als Metadaten, die entweder in einer Mind Map oder einer Vorlage erfasst werden.
  2. Der Versicherer erstellt ein visualisiertes Produkt, indem er die Metadaten für die Sparte in PolicyCenter importiert.
    1. Während des Imports generiert PolicyCenter eine Reihe von „speicherinternen“ APIs, die die Struktur der Sparte widerspiegeln.
  3. Im Advanced Product Designer bearbeitet der Versicherer das Produkt in der Regel.
    1. Meistens handelt es sich hierbei um einen iterativen Prozess, bei dem der Versicherer die Metadaten nach Bedarf verfeinert.
    2. Jedes Mal, wenn das Produkt geändert wird, werden die „speicherinternen“ APIs neu generiert.
  4. Sobald die Verfeinerung abgeschlossen ist, erstellt der Versicherer ein finales Produkt, indem er das Produkt installiert. Die finalen Produkte bestehen aus:
    1. Den erforderlichen Artefakte für das Produkt, einschließlich der Datenbanktabellen und PCFs.
    2. Einer Reihe von „aktiven“ APIs, die jetzt Teil der System-APIs sind.
Anmerkung: Beim Importieren, Bearbeiten oder Installieren einer Sparte über den Advanced Product Designer gibt es keinen separaten Schritt zum Generieren von spartenspezifischen APIs. Die APIs werden automatisch generiert, wenn das Produkt importiert, bearbeitet oder installiert wird.

Weitere Informationen zum Advanced Product Designer finden Sie im Advanced Product Designer-Handbuch.

Zugehörige Entwickleraufgaben

Wenn sie mit spartenspezifischen APIs arbeiten, können Entwickler:

  • Spartenspezifische APIs als Teil eines gesamten Produkts generieren (über Advanced Product Designer)
  • Eine Vorlage aus einem vorhandenen finalen Produkt generieren
  • Spartenspezifische APIs installieren, ohne andere produktspezifische Artefakte zu ändern

Generieren von spartenspezifischen APIs über APD

Wenn Sie ein Produkt über Advanced Product Designer importieren, bearbeiten oder installieren, werden automatisch spartenspezifische APIs generiert. Weitere Informationen zur Verwendung von Advanced Product Designer finden Sie im Advanced Product Designer-Handbuch.

Beachten Sie, dass die Generierung von APIs über Advanced Product Designer entweder nahtlos oder per Bootstrapper erfolgen kann.

  • Wenn die Sparte die nahtlose Generierung unterstützt, werden die spartenspezifischen APIs automatisch aus dem visualisierten Produkt generiert. Es sind keine manuellen Änderungen erforderlich.
  • Wenn die Sparte nur die Generierung von Bootstraps unterstützt, ist eine manuelle Änderung der generierten APIs erforderlich.

Generieren von spartenspezifischen APIs

Warum und wann dieser Vorgang ausgeführt wird

Sie können eine spartenspezifische API aus einer APD-Vorlage generieren. Dieser Prozess gilt sowohl für das Erstellen neuer spartenspezifischer APIs als auch für das Aktualisieren vorhandener APIs.

Anmerkung:

PolicyCenter-Aktualisierungen enthalten neue Funktionen für die Verwendung mit den Cloud-APIs. Um diese neuen Funktionen auf Ihre spartenspezifischen APIs anzuwenden, müssen Sie jede dieser APIs nach dem Upgrade von PolicyCenter selbst aktualisieren.

Um diese Aufgabe auszuführen, benötigen Sie eine APD-Vorlage für die Sparte. Bei Bedarf können Sie eine APD-Vorlage aus dem vorhandenen visualisierten Produkt generieren und die Vorlage importieren. Weitere Informationen finden Sie unter Erstellen einer Vorlage mit dem umgekehrten Vorlagengenerator

Prozedur

  1. Legen Sie in PolicyCenter unter Optionen > Einstellungen > Produktentwurfsmodus auf Entwickler fest und klicken Sie dann auf Aktualisieren.
  2. Um die Vorlage hinzuzufügen, klicken Sie auf Verwaltung > Produktmanagement > Aus Vorlage importieren, suchen und wählen Sie Ihre Vorlage aus und klicken Sie dann auf Aktualisieren.
  3. Um die API zu generieren, klicken Sie im Bereich Details auf Produkt bearbeiten > Produktcode generieren > System-APIs > System-APIs - Code
  4. Überprüfen Sie das Modell, und klicken Sie, wenn dies akzeptabel ist, auf Erstellung abschließen.
  5. Klicken Sie auf Zurück zu Produktdefinition und dann auf Speichern.
  6. Führen Sie einen Neustart von PolicyCenter durch.

Ergebnisse

Um das Ergebnis zu überprüfen, navigieren Sie zum Bereich APD-verwaltet auf der Seite Produktverwaltung. Das Spartenprodukt wird angezeigt und die Spalte Letzte Aktualisierung enthält einen Wert, der angibt, dass das Produkt installiert wurde. Details zum Anzeigen der API in Swagger finden Sie unter Anzeigen eine rAPI-Definition mit der Swagger-Benutzeroberfläche.

Generieren von Vorlagen aus einem vorhandenen finalen Produkt

Produkte können in PolicyCenter auch mit anderen Ansätzen als Advanced Product Designer erstellt werden. Diese Ansätze erstellen ein Produkt mit mehreren spartenspezifischen Artefakten (z. B. spartenspezifische Datenbanktabellen oder PCFs). Sie erstellen jedoch keine spartenspezifischen APIs. Wenn Sie diese Sparten den System-APIs zur Verfügung stellen möchten, müssen Sie spartenspezifische APIs generieren.

Dies erreichen Sie, indem Sie Folgendes tun:

  1. Erstellen Sie eine Vorlage für das Produkt mithilfe des umgekehrten Vorlagengenerators.
  2. Importieren Sie das Produkt in Advanced Product Designer.
  3. Installieren Sie aus dem importierten Produkt nur die spartenspezifischen APIs.

Der umgekehrte Vorlagengenerator ist ein Skript, das eine XML-Vorlage aus einem installierten Produkt erstellt. Da der Generator XML auf der Basis des installierten Produkts generiert, enthält die resultierende Vorlage in der Regel mehr Informationen als in einer Mind Map oder in einem Produkt, das nur visualisiert wird.

Für die Ausführung des umgekehrten Vorlagengenerators ist Advanced Product Designer nicht erforderlich. Daher ist es möglich, in älteren Versionen von PolicyCenter den umgekehrten Vorlagengenerator auszuführen, um eine Vorlage zu generieren. Advanced Product Designer ist jedoch erforderlich, um die Vorlage zu importieren und die entsprechenden APIs zu installieren.

Erstellen einer Vorlage mit dem umgekehrten Vorlagengenerator

Prozedur

  1. Wählen Sie in PolicyCenter Verwaltung > Produktmanagement > Externe Verwaltungaus. Dieser Bereich enthält eine Liste von Produkten, die mit anderen Mitteln als APD installiert wurden.
  2. Wählen Sie im Bereich Installierte Produkte das Produkt aus, für das Sie eine APD-Vorlage generieren möchten.
  3. Klicken Sie im Bereich Details auf APD-Darstellung extrahieren. PolicyCenter generiert die APD-Vorlage und speichert sie im Verzeichnis <USER_HOME>/Downloads.

Ergebnisse

Sobald das Produkt als visualisiertes Produkt importiert und etwaige Inkonsistenzen behoben wurden, können Sie nur die APIs installieren. Details finden Sie unter Generieren von spartenspezifischen APIs.

Installieren von spartenspezifischen APIs ohne Installieren anderer Artefakte

In einigen Situationen ist möglicherweise ein Produkt installiert, das keine spartenspezifischen APIs hat. Dies kann beispielsweise der Fall sein, wenn ein Produkt außerhalb von Advanced Product Designer erstellt wurde, z. B.:

  • ein Produkt der Basiskonfiguration
  • ein Produkt, das über eine standardbasierte Vorlage (SBT) installiert wird
  • ein in Product Designer erstelltes Produkt

Sie können mithilfe des umgekehrten Vorlagengenerators eine Vorlage aus dem installierten Produkt erstellen und die Vorlage dann in Advanced Product Designer importieren. Nachdem das Produkt importiert wurde, können Sie nur die APIs installieren, ohne die anderen vorhandenen produktspezifischen Artefakte zu ändern.

API-Codegen-Konfiguration

APD-generierte Produkte erfüllen bestimmte Namenskonventionen und Verhaltensweisen, die die API-Generierung vereinfachen. Beim Generieren von spartenspezifischen APIs aus einer APD-Vorlage, die aus einem Nicht-APD-Produkt exportiert wurde, können jedoch während der Code-Generierung Namenskonflikte auftreten, die einen Buildfehler verursachen, da das vorhandene Produkt möglicherweise unregelmäßige Entitätsnamen oder andere Funktionen hat, die von APD noch nicht unterstützt werden.

In diesem Fall können Sie eine API-Codegen-Konfigurationsdatei für das Nicht-APD-Produkt anwenden. Die Codegen-Konfiguration kann verwendet werden, um fehlende Übereinstimmungen von Typ- oder Feldnamen zwischen dem Nicht-APD-Produkt und den in der zugehörigen APD-Vorlage verwendeten Produkten zuzuordnen. Darüber hinaus ist es möglich, bestimmte Verhaltensweisen, z. B. Beschränkungen, zu überschreiben, die im Nicht-APD-Produkt vorhanden sind, aber nicht in der zugehörigen APD-Vorlage wiedergegeben werden.

Anmerkung:

Je nach Sparte kann die Konfiguration von API-Codegen sehr komplex werden. Wenn Sie Hilfe benötigen, wenden Sie sich an den Guidewire-Support.

Anwenden von API-Codegen-Überschreibungen

Um API-Codegen-Überschreibungen auf ältere Produkte anzuwenden, müssen die folgenden Kriterien erfüllt sein:

  • Das Verzeichnis config > Integration > apis > installedlobs muss in Ihrem System vorhanden sein. Wenn es nicht vorhanden ist, müssen Sie es erstellen.
  • Dieses Verzeichnis muss die API-Codegen-Konfigurationsdatei im YAML-Format enthalten.
  • Der Dateiname muss im Format <xx>_codegen_config.yaml vorliegen, in dem <xx> das Produktsuffix ist.

Nachdem Sie die oben genannten Bedingungen erfüllt haben, müssen Sie die Produkt-API neu generieren.

API-Codegen-Konfigurationssyntax

Lösen von nicht übereinstimmenden Typ-/Feldnamen

Es kann vorkommen, dass APD-generierte Typen und die Felder im entsprechenden Produkt nicht übereinstimmen, insbesondere wenn die Vorlage aus einem anderen Produkt als APD exportiert wurde. Die API-Codegen-Konfigurationsdatei kann verwendet werden, um Zuordnungsinformationen anzugeben, die diese Abweichungen auflösen.

Die API-Codegen-Konfigurationsdatei muss über eine Eigenschaft types der höchsten Ebene verfügen, gefolgt von einem oder mehreren APD-generierten Typen. Jeder APD-generierte Typ kann eine nameOverride-Eigenschaft angeben, die den relevanten Typnamen im Produkt angibt. Bei Produktwerten wird die Groß-/Kleinschreibung nicht beachtet, bei APD-generierten Werten wird jedoch die Groß-/Kleinschreibung beachtet, und die Groß-/Kleinschreibung muss übereinstimmen. Die Syntax dafür sieht wie folgt aus:

types:
  <APDGeneratedName>:
    nameOverride: <TypeNameInProduct>

Als Beispiel folgende Annahme: Sie haben einen APD-generierten Typ PALine, welcher der PersonalAutoLine des Produkts entspricht. Der folgende Code ordnet diese Werte zu.

types:
  PALine:
    nameOverride: PersonalAutoLine

Für jeden Typ können Sie auch eine Typ-zu-Feld-Zuordnung bereitstellen, indem Sie eine fields-Eigenschaft angeben. Die Eigenschaft fields enthält ein Array von einem oder mehreren APD-generierten Typen, die überschrieben werden sollen. Jeder Typname enthält eine nameOverride-Eigenschaft, die den im Produkt verwendeten Feldnamen angibt. Wie beim Wert des übergeordneten Typs müssen die von APD generierten Werte auf Feldebene mit der Groß-/Kleinschreibung der von APD generierten Typwerte übereinstimmen. Die Syntax dafür sieht wie folgt aus:

types:
  <APDGeneratedName>:
    nameOverride: <TypeNameInProduct>
    fields:
      <APDGeneratedName>:
        nameOverride: <FieldNameInProduct>

Als Beispiel folgende Annahme: Sie haben einen APD-generierten Typ PALine, welcher der PersonalAutoLine des Produkts entspricht. Es gibt auch einen APD-generierten Year-Typ, der dem Feld ModelYear des Produkts entspricht. Der folgende Code gibt an, wie diese Werte zugeordnet werden.

types:
  PALine:
    nameOverride: PersonalAutoLine
    fields:
      Year:
        nameOverride: ModelYear

Ändern von Feldbeschränkungen

Zusätzlich zum Anwenden von Namensüberschreibungen können in der APD-Vorlage erzwungene Typ- oder Feldbeschränkungen angewendet oder gelockert werden, die sich vom im Ursprungsprodukt erwarteten Verhalten unterscheiden.

Die folgenden optionalen Eigenschaften können verwendet werden, um bestimmte Aspekte eines Typs oder Felds zu überschreiben:

  • autonumber: Akzeptiert den Ressourcennamen des Schemas und der Zuordnung, die anstelle der Standardsortierung verwendet werden sollen
  • canDelete: DELETE-Methode aktivieren oder deaktivieren (Boolescher Wert)
  • canPatch: PATCH-Methode aktivieren oder deaktivieren (Boolescher Wert)
  • canPost: POST-Methode aktivieren oder deaktivieren (Boolescher Wert)
  • canSplit: Aktiviert oder deaktiviert die benutzerdefinierte Teilungsaktion (Boolescher Wert)
  • createOnly: Modifikatoren aktivieren oder deaktivieren (Boolescher Wert)
  • identifier: Standard-Identifizierungseigenschaft überschreiben
  • ignored: Feld ausblenden oder verfügbar machen (Boolescher Wert)
  • nullable:: Null-Wert zulassen (Boolescher Wert)
  • oneToOne: Erzwingen einer 1:1-Beziehung durch Entfernen der Möglichkeit, Werte hinzuzufügen oder zu entfernen
  • requiredForCreate: Überschreiben des von APD abgeleiteten requiredForCreate-Werts (Boolescher Wert)
  • resourceName: Überschreiben des Standardschemas und des Ressourcennamens. Wenden Sie diesen Wert an, wenn sich der Ressourcenname vom nameOverride-Namen unterscheidet.
  • toCreateAndAdd: Überschreiben der createAndAdd-Standardmethode.
  • toRemove: Überschreiben der remove-Standardmethode
  • wizardStepIds: Schrittkennungen des Assistenten hinzufügen oder löschen (Boolescher Wert)

Der folgende Codeblock ist ein Beispiel für eine API-Codegen-Konfiguration für eine Sparte für Privatfahrzeuge, die optionale Eigenschaften enthält:

types:
  PADriver:
    nameOverride: VehicleDriver
    fields:
      PolicyDriver:
        createOnly: true
  PALine:
    nameOverride: PersonalAutoLine
  PAPolicyDriverMVR:
    nameOverride: PolicyDriverMVR
    # PolicyDriverMVRs are managed implicitly via requests to retrieve an MVR on individual drivers and are read-only
    canDelete: false
    canPatch: false
    canPost: false
  PAVehicle:
    nameOverride: PersonalVehicle
    fields:
      GarageLocation:
        requiredForCreate: false
      Year:
        nameOverride: ModelYear
    autonumber: VehicleNumber
    toCreateAndAdd: createAndAddVehicle
    toRemove: removeVehicle
wizardStepIds: false