Die Test-Dienstprogramm-API

Zum Erstellen eines Schadenfalls benötigen Sie Informationen aus einem Policenverwaltungssystem. In bestimmten Situationen benötigen Sie möglicherweise auch Informationen aus einem externen Benutzerverwaltungssystem oder Kontaktmanagementsystem. Während der Entwicklung hat Ihre Instanz von ClaimCenter jedoch möglicherweise keinen Zugriff auf diese Systeme.

Um die Entwicklung zu erleichtern, enthält die Cloud-API eine Test-Dienstprogramm-API. Die Test-Dienstprogramm-API ist eine API, die Funktionen bereitstellt, die das Testen während der Entwicklung erleichtern. Mit der Test-Dienstprogramm-API haben Sie folgende Möglichkeiten:

Erstellen und Suchen von Testpolicen
Erstellen und Suchen von Testkontakten und Testbenutzerrollen
Erstellen und Suchen von Testbenutzern

Warning: Die Test-Dienstprogramm-API ist nur für die Verwendung in einer Entwicklungsumgebung vorgesehen. Verwenden Sie die Test-Dienstprogramm-API nicht in einem Produktionssystem.

Anzeigen von Informationen zur Test-Dienstprogramm-API

Die Test-Dienstprogramm-API ist nur verfügbar, wenn die ClaimCenter-Umgebung auf ci-test gesetzt ist. Die Umgebung kann nur während des Startens eingestellt werden. Weitere Informationen zum Starten des ClaimCenters in einer bestimmten Umgebung finden Sie im Systemadministrationshandbuch.

ClaimCenter-Umgebung in Studio festlegen

Warum und wann dieser Vorgang ausgeführt wird

In Studio können Sie eine Umgebung angeben, die das ClaimCenter verwenden soll, wenn es von Studio aus gestartet wird.

Prozedur

Klicken Sie in Studio auf Run > Edit Configurations. Studio öffnet das Dialogfeld Run/Debug Configurations.
Klicken Sie im linken Fensterbereich auf Server.
Fügen Sie am Ende des Feldes VM Options Folgendes hinzu: -Dgw.cc.env=ci-test
- Wenn das Feld VM Options bereits eine env-Einstellung enthält, ersetzen Sie die vorhandene Einstellung durch ci-test.
Klicken Sie auf OK.

Ergebnisse

Wenn der Server von Studio aus gestartet wird, wird er mit der ci-test-Umgebung gestartet. Dazu gehören:

Starten des Servers über das Menü Run.
Starten des Servers mit den Tools Run in der oberen rechten Ecke der Studio-Benutzeroberfläche.

Anzeigen der Test-Dienstprogramm-API in der Swagger-Benutzeroberfläche

Warum und wann dieser Vorgang ausgeführt wird

Nachdem das ClaimCenter mit der ci-test-Umgebung gestartet wurde, können Sie die Swagger-Benutzeroberfläche verwenden, um die Test-Dienstprogramm-API anzuzeigen.

Prozedur

Starten Sie das ClaimCenter mit der ci-test-Umgebung.
Geben Sie in einem Webbrowser die URL für die Swagger-Benutzeroberfläche ein. Damit wird das Tool „Swagger UI“ geladen.
- Das Format der URL ist <applicationURL>/resources/swagger-ui/
- Für eine lokale Instanz von ClaimCenter verwenden Sie beispielsweise: http://localhost:8080/cc/resources/swaggerui/
Geben Sie im Textfeld oben in der Swagger-Benutzeroberfläche die folgende URL ein:
- <applicationURL>/rest/test-util/v1/swagger.json
Klicken Sie auf Explore.

Testpolicendaten erstellen

Die TestSupportPolicyPlugin-Klasse

Zu Beginn des Schadenerstmeldungsprozesses muss der Benutzer oder Dienst, der die Schadenerstmeldung ausführt, die entsprechende Police ermitteln. Nachdem sie ermittelt worden ist, kopiert ClaimCenter Informationen zu dieser Police in sein eigenes Policendiagramm. Diese Prozesse werden als Policensuche und Policenabruf bezeichnet. Die Details zur Ausführung dieser Prozesse werden vom Plugin IPolicySearchAdapter festgelegt.

Die Basiskonfiguration enthält eine Implementierung des Plugins IPolicySearchAdapter, das auf eine Gosu-Klasse mit der Bezeichnung TestSupportPolicyPlugin verweist. Diese Implementierung wird nur verwendet, wenn ClaimCenter in der ci-test-Umgebung gestartet wird.

Die Test-Dienstprogramm-Endpunkte

In der Basiskonfiguration bietet keine der API-Rollen Zugriff auf die Endpunkte in der Test-Dienstprogramm-API. Daher ist der einzige Benutzer, der Testpolicen erstellen kann, der Superbenutzer su, der grundsätzlich Zugriff auf alle Endpunkte hat.

Sie können die vorhandenen API-Rollen konfigurieren, um den Zugriff auf diese Endpunkte auf andere Benutzer auszuweiten. Weitere Informationen zum Konfigurieren von API-Rollen entnehmen Sie dem Cloud-API-Authentifizierungshandbuch.

Testpolicen erstellen

Sie können den Endpunkt /test-util/v1/policies verwenden, um Testpolicen zu erstellen. Wenn Sie diesen Endpunkt ausführen, nehmen die System-APIs die in den Nutzdaten angegebenen Daten und fügen sie den Daten in der Klasse TestSupportPolicyPlugin hinzu. Auf diese Weise können Sie bei späteren Aufrufen, die Schadenfälle und Schadenfalldaten erstellen, auf Testpolicen und deren Daten verweisen.

Zum Erstellen einer Testpolice sind keine Mindestdaten erforderlich. Wenn Sie eine Police mit leeren Anforderungs-Nutzdaten erstellen, hat die Police die folgenden Attribute:

Die Policenwährung wird auf die Standardwährung des ClaimCenter gesetzt.
Das Gültigkeitsdatum wird auf das aktuelle Datum gesetzt.
Das Ablaufdatum wird auf ein Jahr ab dem aktuellen Datum gesetzt.
Die Police ist eine nicht verifizierte Police.

Sie können die Policen in den Beispieldaten als Modelle für die Erstellung von Testpolicen verwenden. Geben Sie dazu die Schadenfall-ID eines Schadenfalls an, dessen Police ein geeignetes Modell ist. Führen Sie dann ein GET für einen beliebigen der Endpunkte aus, beginnend mit /claims/{claimId}/policy, um anzuzeigen, wie Daten in JSON-Nutzdaten strukturiert werden. Eine vollständige Beschreibung der Daten, die in den Anforderungs-Nutzdaten angegeben werden können, finden Sie in der Swagger-Benutzeroberfläche.

Eindeutige Policennummer für jede Police verwenden

Bei der Erstellung einer Testpolice ist es für die System-APIs nicht erforderlich, dass sich die Policennummer von bereits vorhandenen Policennummern unterscheidet. Wenn es jedoch zwei oder mehr Policen mit derselben Policennummer gibt, können Sie keinen Schadenfall mit dieser Policennummer erstellen. Das liegt daran, dass die System-API, die Schadenfälle erstellt, mehrere Policen findet und nicht ermitteln kann, welche Police verwendet werden soll.

Beispiele für Testpolicendaten

Die folgenden Abschnitte enthalten Beispiele für einige der häufiger verwendeten Felder. Um auf diese Beispiele zuzugreifen, die in den einzelnen Nutzdaten zusammengefasst sind, siehe Beispiel für die Nutzdaten einer Police.

Allgemeine skalare Felder

Der folgende Codeblock erstellt eine Police, die vom 1. Januar 2020 bis zum 1. Januar 2021 in Kraft ist. Ihre Policennummer lautet FNOL-POLICY und ist eine verifizierte Police.

{
  "data": {
    "attributes": {
      "effectiveDate": "2020-01-01T07:00:00.000Z",
      "expirationDate": "2021-01-01T07:00:00.000Z",
      "policyNumber": "FNOL-POLICY",
      "verifiedPolicy": true
    }
  }
}

Allgemeine Typenschlüsselfelder

Der folgende Codeblock erstellt eine Police für ein Privatfahrzeug, die in Kraft ist. (Mit anderen Worten: Die Police wurde nicht gekündigt.)

{
  "data": {
    "attributes": {
      "policyType": {
        "code": "PersonalAuto"
      },
      "status": {
        "code": "inforce"
      }
  }
}

Policenkontakte

Der folgende Codeblock erstellt eine Police, bei der der Versicherte eine Person mit dem Namen Ray Newton ist und in 287 Kensington Rd. #1A, South Pasadena, CA wohnt. Die ID in der Policenverwaltung für diesen Kontakt lautet ab:0001-1.

Beim Erstellen von Testpolicen werden Policenkontakte unter Verwendung der Einschließung von Anforderungen angegeben. Weitere Informationen zu diesem Thema finden Sie unter Anforderungseinschluss.

{
  "data": {
    "attributes": {
      "policyContacts": [
        {
          "contact": {
            "refid": "rayNewton"
          },
          "roles": [
            {
              "code": "insured"
            }
          ]
        }
      ]
    }
  },
  "included": {
    "Contact": [
      {
        "attributes": {
          "firstName": "Ray",
          "lastName": "Newton",
          "primaryAddress": {
            "addressLine1": "287 Kensington Rd. #1A",
            "city": "South Pasadena",
            "country": "US",
            "postalCode": "91145",
            "state": {
              "code": "CA"
            }
          },
          "subtype": {
            "code": "Person"
          },
          "policySystemId": "ab:0001-1"
        },
        "method": "post",
        "refid": "rayNewton",
        "uri": "/test-util/v1/contacts"
      }

    ]
  }
}

Policenorte

Der folgende Codeblock erstellt einen Policenort.

{
  "data": {
    "attributes": {
      "policyLocations": [
        {
          "address": {
            "addressLine1": "287 Kensington Rd. #1A",
            "city": "South Pasadena",
            "postalCode": "91145",
            "state": {
              "code": "CA"
            }
          }
        }
      ]
    }
  }
}

Deckungen auf Policenebene

Der folgende Codeblock erstellt eine Deckung auf Policenebene. Beachten Sie, dass die Deckung einen Deckungstyp (ein Typenschlüsselfeld) und zwei Währungsbetragsfelder hat. Eine Police kann auch Wagnisdeckungen enthalten, die im nächsten Abschnitt angezeigt werden.

{
  "data": {
    "attributes": {
      "policyCoverages": [
        {
          "coverageType": {
            "code": "PALiabilityCov"
          },
          "incidentLimit": {
            "amount": "30000.00",
            "currency": "usd"
          },
          "exposureLimit": {
            "amount": "15000.00",
            "currency": "usd"
          }
        }
      ]
    }
  }
}

Wagnisse

Ein Wagnis ist eine Punkt in einer Police, an die Deckungen geknüpft sind, wie z. B. ein Fahrzeug oder ein Gebäude. Der folgende Codeblock erstellt ein Wagnis. Je nach Produkttyp der Police gibt es verschiedene Arten von Wagnissen. Da die anderen Beispiele aus einer Police für ein Privatfahrzeug stammen, handelt es sich bei diesem Beispiel um ein Kfz-Wagnis.

Wagnisse beinhalten in der Regel Wagnisdeckungen (z. B. Unfalldeckung für ein Fahrzeug). Für jede Deckung müssen Sie einen CoverageType angeben, der auf einen Wert aus der Typenliste CoverageType gesetzt werden muss. Die Deckung kann auch Deckungsbedingungen enthalten (z. B. einen Selbstbehalt). Wenn Sie Deckungsbedingungen einschließen, muss jede Deckungsbedingung ein covTermPattern (festgelegt auf einen Code aus der Typenliste covTermPattern) und einen covTermSubtype (festgelegt auf einen Code aus der Typenliste covTerm) haben. Je nach Art der Deckungsbedingung können weitere Felder erforderlich sein. Beispielsweise ist für Deckungsbedingungen, bei denen es sich um finanzielle Beträge handelt, ein financialAmount-Feld erforderlich.

{
  "data": {
    "attributes": {
      "vehicleRiskUnits": [
        {
          "RUNumber": 1,
          "vehicle": {
            "licensePlate": "1HGJ465",
            "make": "Saturn",
            "model": "SL",
            "policySystemId": "pcveh:0001-1",
            "state": {
              "code": "CA"
            },
            "vin": "1GV234TV347463345",
            "year": 1997
          },
          "coverages": [
            {
              "coverageType": {
                "code": "PACollisionCov"
              },
              "covTerms": [
                {
                  "covTermPattern": {
                    "code": "PACollDeductible"
                  },
                  "covTermSubtype": "FinancialCovTerm",
                  "financialAmount": {
                    "amount": "500.00",
                    "currency": "usd"
                  }
                }
              ],
              "incidentLimit": {
                "amount": "15000.00",
                "currency": "usd"
              }
            }
          ]
        }
      ]
    }
  }
}

Lernprogramm: Erstellen einer Police mithilfe der Test-Dienstprogramm-API

In diesem Lernprogramm wird davon ausgegangen, dass Sie Postman in Ihrer Umgebung mit dem korrekten Beispieldatensatz eingerichtet haben. Weitere Informationen finden Sie unter Lernprogramm: Einrichten Ihrer Postman-Umgebung.

In diesem Lernprogramm fügen Sie den Policendaten, die in der Klasse TestSupportPolicyPlugin gespeichert sind, eine Police hinzu. Sie können dann beim Erstellen eines neuen Schadenfalls auf diese Police verweisen.

Wenn Sie dies noch nicht getan haben, konfigurieren Sie Studio so, dass das ClaimCenter mit der ci-test-Umgebung gestartet wird.
1. Klicken Sie in Studio auf Run > Edit Configurations. Studio öffnet das Dialogfeld Run/Debug Configurations.
2. Klicken Sie im linken Fensterbereich auf Server.
3. Fügen Sie am Ende des Feldes VM Options Folgendes hinzu: -Dgw.cc.env=ci-test
4. Klicken Sie auf OK.
Starten Sie das ClaimCenter in Studio, indem Sie Run > Run und Server auswählen.
Starten Sie in Postman eine neue Anforderung, indem Sie auf das + rechts neben der Registerkarte Launchpad klicken.
Geben Sie als Basic-Auth-Autorisierung den Benutzer su und das Kennwort gw an.
Geben Sie den folgenden Aufruf ein, klicken Sie jedoch noch nicht auf Senden:
- POST http://localhost:8080/cc/rest/test-util/v1/policies
Geben Sie die Anforderungs-Nutzdaten an.
1. Klicken Sie in der ersten Zeile der Registerkarten (die mit Params beginnt) auf Body.
2. Wählen Sie in der Optionsfeldzeile raw aus.
3. Ändern Sie am Ende der Zeile mit den Optionsfeldern den Wert der Dropdown-Liste von Text in JSON.
4. Kopieren Sie den Text im Beispiel für die Nutzdaten einer Police in das Textfeld unter den Optionsfeldern:
Klicken Sie auf Senden.

Ihre Arbeit überprüfen

Das ClaimCenter zeigt keine Daten zu Policen an, die nicht mit einem Schadenfall verknüpft sind. Daher gibt es keine unabhängige Möglichkeit, Ihre Arbeit für dieses Lernprogramm zu überprüfen, außer zu bestätigen, dass Sie einen Antwortcode erhalten und dann zu versuchen, einen Schadenfall mithilfe der Police zu erstellen.

Erstellen von Testdaten für zugehörige Objekte

Sie können auch die Test-Dienstprogramm-API verwenden, um Objekte zu erstellen, die mit Policen verbunden sind, z. B. Kontakte und Fachservices. Dies kann nützlich sein, wenn Sie die Funktionalität während der Entwicklung testen möchten und es zu umständlich ist, die erforderlichen Objekte manuell zu erstellen.