Projekte

ios-basis-extapimapper

Die Mapper dieses Schnittstellenmodells sind kompatibel zum alten Schnittstellenmodell des Versicherungsmodells. Weitere Informationen hierzu befinden sich in der Dokumentation des F10-Versicherungsmodells

  • stellt Mapper und notwendige Utility-Klassen für die Konvertierung der Modellklassen aus dem Angebotsmodell in DTO-Darstellungen zur Verfügung

  • definiert Abhängigkeiten zu den entsprechenden Mappern aus dem Versicherungsmodell, um die Versicherung und ihre Komponenten mappen zu können

<dependency>
    <groupId>de.faktorzehn.versicherungsmodell</groupId>
    <artifactId>vm-basis-extapimapper</artifactId>
</dependency>

Mapper-Klassen

Für folgende Modellklassen wurde ein Mapper implementiert:

Mapper Modellklasse

AngebotDtoMapper

Angebot und Verkaufsprodukt

AngebotVariantenDtoMapper

AngebotsVariante

RollenDtoMapper

RolesAndPartner und Role

PolicenReferenzDtoMapper

PolicyReference

Der AngebotDtoMapper ist hierbei der Ausgangspunkt. Wenn die Methode mapFromModel(Angebot angebot, EXTERNAL_PARENT null, ServiceMappingContext context) aufgerufen wird, werden auch die anderen Mapper über mapChildrenToModel(AngebotDto dto, Angebot angebot, ServiceMappingContext context) aufgerufen. In bestimmten Fällen können auch die Methoden mapFromModel() und mapToModel() von Mappern auf der tieferen Ebene direkt aufgerufen werden (beispielsweise in den TAA-Services, wo der RollenDtoMapper ohne die Anwendung des AngebotDtoMapper verwendet wird).

Zusätzlich steht auch ein MessageListMapper für das Mappen von IPS-Messages in DTO’s zur Verfügung.

Partnerdaten

Wenn optional Partnerdaten für die Ein- und Ausgabe verwendet werden, befindet sich im Standard ein PartnerDtoMapper für das Mapping zwischen den hier definierten DTO’s und den Modellklassen aus dem Partnerinterface. Zum Zugriff auf partnerbezogene Informationen wird das PartnerRepository verwendet, diese Abhängigkeit kann jedoch in einer Ableitung aufgelöst und anders definiert werden.

Customizing

Um die Mapper anwenden zu können, muss ein ServiceMappingContext instanziiert und mitgegeben werden, der mehrere unterstützende Komponenten enthält. Im Standard sind folgende Eigenschaften definiert:

  • Function<Versicherung, VersicherungDto> : Das Mapping der Versicherung ist spartenspezifisch und sollte in einer Spartenableitung der jeweiligen Versicherungsmodell-Schnittstelle entnommen werden. Diese Komponente wird für jeden Service benötigt.

  • Function<VorversicherungsInfo, VorversicherungsInfoDto> : Das Mapping der Vorversicherungsinfo ist spartenspezifisch und sollte in einer Spartenableitung der jeweiligen Versicherungsmodell-Schnittstelle entnommen werden. Diese Komponente wird für Services benötigt, in denen Vorversicherungsinformationen teil der Ausgabe sind.

  • HashMap<RoleKind, String> : Ein Rollenart-Mapper, der für nicht-primäre Rollen anhand der RoleKind einen Rollennamen ausgibt. Für die primären Rollen Versicherungsnehmer, Beitragszahler, Korrespondenzempfänger und Vermittler (RoleKind = POLICY_HOLDER, PREMIUM_PAYER, CORRESPONDENCE_RECIPIENT und BROKER) muss kein Rollennamenmapping bereitgestellt werden. Ein beispielhafter RollenartMapper RollenArtMappingContainer ist im Modul enthalten. Diese Komponente wird für Services benötigt, in denen Rolleninformationen teil der Ein- oder Ausgabe sind.

  • Function<VersicherungDto, Versicherung> : Das Mapping des VersicherungDto’s ist spartenspezifisch und sollte in einer Spartenableitung der jeweiligen Versicherungsmodell-Schnittstelle entnommen werden. Diese Komponente wird für Services benötigt, in der gesamte Versicherungsdaten mitgegeben werden müssen (beipielsweise die Tarifierung).

  • Function<VorversicherungsInfoDto, VorversicherungsInfo> : Das Mapping des VorversicherungsinfoDto’s ist spartenspezifisch und sollte in einer Spartenableitung der jeweiligen Versicherungsmodell-Schnittstelle entnommen werden. Diese Komponente wird für Services benötigt, in der Vorversicherungsinformationen relevante Bestandteile sein können (z.B. Abschluss eines Angebots).

  • boolean mapPartnerData : Über ein Boolean kann gesteuert werden, ob zusätzlich die Ausgabe von Partnerdaten berücksichtigt werden soll und ist standardmäßig auf false gesetzt.

  • PartnerRepository : Schnittstelle zur Kommunikation mit einem externen Partnersystem. Wenn im Standard boolean mapPartnerData auf true gesetzt ist, muss diese Schnittstelle mit angegeben werden. Diese Komponente wird für Services benötigt, in denen Partnerinformationen teil der Ein- oder Ausgabe sind.

  • IProductConfiguration: Zugang zur Produktkonfiguration, die bereits in der Superklasse MappingContext implementiert ist. Diese Komponente wird für Services benötigt, in denen produktkonfigurierte Enum-Werte ausgelesen werden müssen.

  • Function<Angebot, MessageList> : In dieser Komponente kann für die Ausgabe des Angebots optional eine nachfolgende Validierungsstrategie festgelegt werden, deren Messages bei der Ausgabe ebenfalls in DTO’s gemappt weden.

  • FilterVariantenContainer : Optional kann eine Filterregel angewendet werden, wenn nicht alle Varianten eines Angebots ausgegeben werden sollen (beispielsweise aus Performancegründen). Der Container beinhaltet zwei Komponenten: die eigentliche Filterregel in Form eines Predicate<AngebotsVariante> (z.B. AngebotsVariante::isGewaehlt, um nach gewählten Varianten zu filtern) und eine optionale, benutzerdefinierte Message, die als Info in der Ausgabe mit angezeigt wird. Die Message ist als BiFunction<Integer, Integer, Optional<Message>> definiert, um die Gesamtanzahl der Varianten und die Anzahl der in der Ausgabe beibehaltenen Varianten nachträglich in die Message mappen zu können.

Der ServiceMappingContext enthält eine integrierte Builder-Klasse, mit der alle benötigten Komponenten durch Verkettung in einem Schritt hinzugefügt werden können.

Ausgabe von Metadaten und Wertebereichen

Ein AttributeHandler kann dazu genutzt werden, einzelne Metadaten zu einem Attribut auszugeben. Die Mapper Klasse AbstractAttributeHandlerMapper ruft die entsprechende Methode am AttributeHandler automatisch auf. Dazu wird der konfigurierte Mapper (Instanz von MetadataMapperProcessor) vom AttributeHandler oder einer Implementierung im IMappingContext verwendet.

Eine Implementierung von MetadataMapperProcessor ist im Modul basis-extapimapper enthalten. Die Klasse MetadataMapper implementiert dabei die Interface-Methode createMetadata und erzeugt ein MetadataDto im übergebenen externen Dto-Objekt.

    /**
     * Creates the meta data and adds the data to the external object.
     */
    <EXTERNAL, MODEL_OBJECT extends IModelObject, EXTERNAL_VALUE, MODEL_VALUE, CONTEXT extends IMappingContext> void createMetadata(
            AttributeHandler<EXTERNAL, MODEL_OBJECT, EXTERNAL_VALUE, MODEL_VALUE, CONTEXT> attributeHandler,
            MODEL_OBJECT modelObject,
            EXTERNAL externalObject,
            CONTEXT context);

Um Metadaten im Dto ausgeben zu können, muss die Klasse das Interface MetadataContainer mit der Methode addMetadata(Object dto) implementieren.

Die Klasse MetadataDto enthält die Wertebereiche in einem Attribut vom Typ ValueSetDto.

Beispielausgabe von Metadaten und Wertebereichen eines Attributes wohnflaeche mit einem gültigen Bereich.

"metadata": [
    {
        "attributeName": "wohnflaeche",
        "defaultValue": null,
        "valueSet": {
            "type": "RANGE",
            "min": 1,
            "max": 150,
            "step": null,
            "containsNull": false
        }
    }
]

Beispielausgabe von Metadaten und Wertebereichen eines Attributes selbstbehalt mit einer Aufzählung.

"metadata": [
    {
        "attributeName": "selbstbehalt",
        "defaultValue": 100,
        "valueSet": {
            "type": "ENUMERATION",
            "values": [
                0,
                100,
                200
            ],
            "containsNull": false
        }
    }
]

Im Kundenprojekt kann die Ausgabe der Metadaten nach eigenen Wünschen angepasst werden.