Projekte

ios-basis-extservices

Die externen Services sind kompatibel zum alten Schnittstellenmodell des Versicherungsmodells. Weitere Informationen hierzu befinden sich in der Dokumentation des F10-Versicherungsmodells

  • stellt eine Schnittstelle für externe Aufrufe zur Verfügung, die Sparten- und technologisch unabhängig ist (diese Abhängigkeiten müssen im Projekt definiert werden)

AngebotAuskunftExternalService

Dieser Service ermöglicht einen lesenden Zugriff auf ein Angebot anhand einer spezifizierten Angebotsnummer. Die Hauptaufgabe besteht in der Konvertierung des Ergebnisses in eine DTO-Darstellung, während die Geschäftslogik an die Klasse AngebotAuskunftService delegiert wird, die im Modul ios-basis-business zu finden ist.

Wichtige Methoden:

  • angebotsauskunft(String offerNumber, ServiceMappingContext context) - Hauptmethode der Klasse. Das Angebot wird vom AngebotAuskunftService anhand der Angebotsnummer geladen, in ein DTO gemappt und dieses DTO zurückgegeben. Optional können Partnerdaten zu den Rollen im Angebot ausgegeben werden.

  • angebotsauskunftByBusinessId(String businessId, ServiceMappingContext context) - Hauptmethode der Klasse. Das Angebot wird vom AngebotAuskunftService anhand der Business-Id geladen, in ein DTO gemappt und dieses DTO zurückgegeben. Optional können Partnerdaten zu den Rollen im Angebot ausgegeben werden.

  • In einer Spartenableitung müssen zum Aufbau des ServiceMappingContext Komponenten bereitgestellt werden, die eine Versicherung in ein VersicherungDto und eine Vorversicherung in eine VorversicherungsInfoDto mappen. Wenn weitere als die im Standard definierten Rollen vorhanden sind, muss zusätzlich ein RoleKind-Rollennamen - Mapper mitgegeben werden.

  • Wenn zusätzlich Partnerdaten ausgegeben oder neu angelegt werden sollen, muss im ServiceMappingContext boolean mapPartnerDaten auf true gesetzt und gegebenenfalls eine Schnittstelle zum Partnersystem (beispielsweise das PartnerRepository) mitgegeben werden.

AngebotAnlegenExternalService

Dieser Service ermöglicht einen schreibenden Zugriff zum Anlegen eines neuen Angebots anhand einer Gesellschafts-Id, Versicherungsnehmer-Id, Vermittler-Id, Verkaufsproduktart und eines Beginndatums. Die Hauptaufgabe besteht in der Konvertierung des DTO’s mit den vorher beschriebenen Input-Parametern in einen Container (VbStartNewOfferData), der von der Geschäftslogik verwendet werden kann, und die anschließende Konvertierung des erzeugten Angebots zurück in eine DTO-Darstellung. Die Geschäftslogik wird an die Klasse AngebotAnlegenService delegiert, die im Modul ios-basis-business zu finden ist.

Wichtige Methoden:

  • angebotAnlegen(AngebotAnlegenDto dto, ServiceMappingContext context) - Hauptmethode der Klasse. Das DTO mit den Input-Parametern wird in einen Container (VbStartNewOfferData) gemappt, mit dem das Angebot vom AngebotAnlegenService erzeugt werden kann. Dieses Angebot wird anschließend in ein DTO gemappt und zurückgegeben. Optional können Partnerdaten zu den Rollen im Angebot ausgegeben werden.

  • In einer Spartenableitung müssen zum Aufbau des ServiceMappingContext Komponenten bereitgestellt werden, die eine Versicherung in ein VersicherungDto mappen. Wenn weitere als die im Standard definierten Rollen vorhanden sind, muss zusätzlich ein RoleKind-Rollennamen - Mapper mitgegeben werden.

  • Wenn zusätzlich Partnerdaten ausgegeben oder neu angelegt werden sollen, muss im ServiceMappingContext boolean mapPartnerDaten auf true gesetzt und gegebenenfalls eine Schnittstelle zum Partnersystem (beispielsweise das PartnerRepository) mitgegeben werden.

AenderungsangebotAnlegenExternalService

Dieser Service ermöglicht einen schreibenden Zugriff zum Anlegen eines neuen Änderungsangebots anhand einer Policennummer, Vermitler-Id und eines Gültigkeitsdatums. Die Struktur und das Vorgehen ist weitestgehend gleich dem AngebotAnlegenExternalService. Lediglich verwendet die Hauptmethode aenderungsangebotAnlegen(AenderungsangebotAnlegenDto dto, ServiceMappingContext context) ein anderes Input-DTO mit anderen Inputwerten, daraus resultierend ein anderes Mapping-Verfahren in einen anderen Container VbStartChangeOfferData, und die Delegation an den AenderungsangebotAnlegenService.

TAAExternalService

TAA (Tarifierung, Angebot, Antrag) ist eine spartenübergreifende Service-Schnittstelle, angelehnt an das BiPRO Modell und bietet die prozesstypischen Schnittstellen für ein Angebot. Dieser Service akzeptiert je nach Service ein spezifisches Input-DTO und führt einen TAA-bezogenen Service an der Versicherung und/oder am Angebot aus. Aufgrund von Spartenabhängigkeiten muss beim Aufruf ein Versicherungsmapper in beide Richtungen in den ServiceMappingContext mitgegeben werden. Die Versicherung, die dem VersicherungsDto entnommen wird, und gegebenenfalls weitere notwendige Paramter werden in ein Container (TAAData) gemappt. Vor der eigentlichen Durchführung der Aktion wird ein Angebot erzeugt, in der die Versicherung (in einer Angebotsvariante) und weitere notwendige Daten abgelegt werden. Zusätzlich werden entweder das gesamte Angebot oder nur die Angebotsvariante mit den Versicherungsdaten validiert. Wenn sowohl die Angebotserzeugung als auch die Validierung erfolgreich ist, wird der angesprochene Service ausgeführt. Bei Fehlern im Prozess werden zusätzlich Fehlermeldungen zurückgegeben. Während der TAAExternalService für das Mapping zwischen DTO und Domain verantwortlich ist, wird die Geschäftslogik im TAAService im Modul ios-basis-business ausgeführt.

Wichtige Methoden:

  • tarifieren(DTO_TARIFIERUNG dto, ServiceMappingContext context) - Mappt das DTO vom Typ TarifierungDto mit den Input-Parametern in ein Container (TAAData) und führt anhand der Versicherung eine Tarifierung durch. Nach der Tarifierung werden die Versicherungsdaten mit den Beiträgen anschließend in ein DTO gemappt und zurückgegeben.

  • anbieten(DTO_ANBIETEN dto, ServiceMappingContext context) - Mappt das DTO vom Typ AnbietenDto mit den Input-Parametern in ein Container (TAAData) und führt anhand des erzeugten Angebots sowohl die Tarifierung der Versicherung als auch das Anbieten an den Kunden durch. Nach dem Serviceaufruf werden die Angebotsdaten mit der Versicherung und den berechneten Beiträgen anschließend in ein DTO gemappt und zurückgegeben. Optional können Partnerdaten zu den Rollen im Angebot ausgegeben werden oder Partnerdaten für Rollen mit unbekannten Partnern mitgeliefert werden. Details zum Vorgehen werden im nächsten Unterkapitel beschrieben.

  • abschliessen(DTO_ABSCHLIESSEN dto, ServiceMappingContext context) - Mappt das DTO vom Typ AbschliessenDto mit den Input-Parametern in ein Container (TAAData) und führt anhand des erzeugten Angebots sowohl die Tarifierung der Versicherung und das Anbieten an den Kunden als auch den Abschluss und das Versenden von Antragsdaten an das Bestandssystem oder Antragssystem durch. Nach dem Serviceaufruf werden die Angebotsdaten mit der Versicherung und den berechneten Beiträgen, und gegebenenfalls Vorversicherungs- und Vorschadendaten, anschließend in ein DTO gemappt und zurückgegeben. Optional können Partnerdaten zu den Rollen im Angebot ausgegeben werden oder Partnerdaten für Rollen mit unbekannten Partnern mitgeliefert werden. Details zum Vorgehen werden im nächsten Unterkapitel beschrieben.

  • In einer Spartenableitung müssen zum Aufbau des ServiceMappingContext Komponenten bereitgestellt werden, die die Versicherung in beide Richtungen mappen. Wenn weitere als die im Standard definierten Rollen vorhanden sind, muss zusätzlich ein RoleKind-Rollennamen - Mapper mitgegeben werden.

  • Wenn zusätzlich Partnerdaten ausgegeben oder neu angelegt werden sollen, muss im ServiceMappingContext boolean mapPartnerDaten auf true gesetzt und gegebenenfalls eine Schnittstelle zum Partnersystem (beispielsweise das PartnerRepository) mitgegeben werden.

Bereitstellung von Partnerdaten bei unbekannten Rollen

Wenn für eine oder mehrere Rollen der Partner im externen Partnersystem nicht bekannt sind, können in der Eingabe zusätzlich Partnerdaten bereitgestellt werden. Dafür müssen im AnbietenDto oder AbschliessenDto Angaben über das PartnerAnlegenDto und ein oder mehreren NeuerPartnerDto hinzugefügt werden. Der Prozess läuft in folgenden Schritten ab:

  • In jedem VerwaltungsrolleDto, in der der Partner unbekannt ist, muss das Feld für die Partner-Id leer sein oder entfernt werden und stattdessen eine Verwaltungsrollennummer eingetragen werden.

  • In jedem NeuerPartnerDto muss neben den Partnerdaten die gleiche Partnernummer zur Zuordnung mit den richtigen Rollen eingetragen werden.

  • Werden im Angebotsservice im TAAExternalService Partnerdaten erkannt, wird vor der eigentlichen Ausführung des Services zusätzlich der Prozess zum Anlegen der neuen Partner aktiv. Werden keine mitgegebenen Partnerdaten erkannt, wird dieser Prozess gänzlich übersprungen. Treten Fehler während der Partneranlage auf, wird der gesamte Service ohne Ausführung des Angebotsservice abgebrochen.

  • Vor der Kommunikation mit dem externen Partnersystem wird die Struktur der Partnerdaten und die Zuordnung der Partner zu den Rollen geprüft. Werden Fehler festgestellt, findet keine Kommunikation mit dem Partnersystem statt und der Service wird mit der entsprechenden Fehlermeldung abgebrochen.

  • Die Partnerdaten werden an das Partnersystem übertragen. Wenn das Anlegen der Partner scheitert, wird der Service abgebrochen und die Fehlermeldungen aus dem externen Partnersystem zurückgegeben.

  • Wurden alle Partner erfolgreich angelegt, wird den zugehörigen Rollen alle notwendigen Id’s (wie PartnerId und Adresse-Id) ergänzt. War eines der unbekannten Partner ein Versicherungsnehmer, wird zudem die Versicherungsnehmer-Id in der Versicherung eingetragen.

  • Wenn der gesamte Prozess erfolgreich verlaufen ist, wird mit dem eigentlichen Angebotsservice fortgefahren.

Architektur der REST Services

Der Mustercontent kann als Vorlage verwendet werden, wie man einen spartenspezifischen REST Service aufbauen kann. Dabei ist der REST Service Prozess in diese Architektur gegliedert:

Klasse Beschreibung

[Sparten]RestService

Einstiegspunkt für REST Anfragen über die Swagger-UI. Hier werden die spartenspezifischen externen Services definiert und die Statusausgabe der Responses verwaltet.

[Sparten]ExternalService

Einstiegspunkt für die Verarbeitung von Anfragen, die unabhängig von der Technologie des Webservices ist. Hier werden spartenspezifische Konfigurationen (wie der Versicherungsmapper) definiert und an eine untere Schicht weitergegeben. Zudem können hier für eine flexiblere Austauschbarkeit sowohl die untere ExternalService-Schicht als auch die Logik-Schicht definiert werden.

ExternalService

Hier beginnt die eigentliche Verarbeitung der Anfrage. Der ExternalService ist eine Zwischenschicht, der Input-Parameter für die Geschäftslogik und das Ergebnis der Geschäftslogik für die Ausgabe im Webservice konvertieren kann.

Service

Hier findet die Geschäftslogik statt und greift auf Klassen und Methoden zu, die in IOS implementiert wurden (wie das Anlegen und Laden von Angeboten)

Datenaustausch in der Schnittstelle

Neben dem Austausch von Angebots- und Versicherungsdaten sowohl clientseitig (POST-Operationen) als auch serverseitig (POST- und GET-Operationen) müssen für die vollständige Funktionalität noch Auskunft über weitere bestimmte Daten gegeben werden:

Art von Daten Client-Server-Kommunikation Server-Client-Kommunikation

Angebotsdaten

Notwendige Angaben zur Verarbeitung von angebotsspezifischen Anfragen wie Anlegen oder Tarifieren.

Auskunftsdaten für Bearbeitung an der Oberfläche oder Weiterverarbeitung.

Produktbaustein-Id’s

Identifizierung, welche IPS-Produktbausteine den jeweiligen produktkonfigurierbaren Vertragsobjekten zugeordnet werden sollen (bspw. Verkaufsproduktart-Id).

-

Produkt-und Wertebereichsauskunft

-

Identifizierung aus IPS-Produktbausteinen von produktkonfigurierten Informationen, erlaubten Werten, mögliche Einschlüsse und ähnliches, um Auskunft der zulässigen Optionen in der clientseitigen Angebotsbearbeitung zu geben.

Fehlermeldungen

-

Aussagekräftige Fehlermeldungen, die dem Client das Feststellen der exakten Fehlerquelle während der serverseitigen Verarbeitung oder Validierung der Daten ermöglicht.