102 lines
6.6 KiB
Markdown
102 lines
6.6 KiB
Markdown
# Überlegungen
|
|
|
|
* Typische Operationen für Vermittler auf der Wolke der Geschäftsobjekte einer Versicherung sind: Neuanlage, Update und Lesen.
|
|
Löschen kommt schon eher selten vor. Im Folgenden geht es um Neuanlage und um Update bzw. Änderung von Geschäftsobjekten.
|
|
* Die Frage ist dabei, wie viel Wissen und Logik auf Clientseite vorausgesetzt werden soll, bzw. wie viel von Serverseite
|
|
unterstützt werden kann.
|
|
* Bei der OMDS Antragsstrecke setzen wir bisher stark darauf, dass der Client in der Lage ist, einen gültigen Antrag zu
|
|
erstellen. Dafür muss er das Metamodell kennen und bei sich abbilden. Heute erfolgt das über Programmierung z.B. auf
|
|
Basis einer Produkt- und Schnittstellendokumentation.
|
|
* Bei Update könnte man auch diesen Ansatz nutzen und vom Client verlangen, dass er das Metamodell kennt und die Instanz
|
|
in neuer Form gültig übermittelt.
|
|
* Für viele Änderungen wirkt dies aber übertrieben anspruchsvoll für den Client. Wenn die Zahlungsfrequenz eines Vertrags
|
|
geändert werden soll, so genügt es die Polizzennummer und die neue Zahlungsfrequenz zu übermitteln. Die Kombination aus
|
|
Verfahren und reduziertem Objektmodell für das Verfahren erscheint zweckmäßiger.
|
|
* Theoretisch ließen sich nicht nur Änderungen auf diese Weise abbilden, sondern auch Neuanlagen, wenn sie sich in
|
|
Verfahrensschritte zerlegen lassen. Allerdings ist die Frage, wie sinnvoll das ist, da Clients oft Produkte
|
|
vergleichen müssen und dabei eine sukzessive Anlage nicht in Betracht kommt.
|
|
* Metamodell und Instanzen können für unterschiedlichste Zwecke erstellt werden. Theoretisch ist es auch möglich,
|
|
sehr statische Modelle auf diese Weise zur Laufzeit zu übermitteln. Dies ist aber nicht sinnvoll. Für Zwecke, wo
|
|
das Modell auf absehbare Zeit konstant ist, ist es sinnvoll, das Modell traditionell statisch zu definieren.
|
|
Dies schließt gemeinsame, service-übergreifende Elementdefinitionen nicht aus. Beispiele hierfür sind Abfrage von
|
|
Dokumenten, Maklerpost, Ereignissen.
|
|
* Metamodelle zur Laufzeit machen Sinn für - komplizierte, zur Laufzeit veränderliche Requests. Zur Laufzeit veränderlich
|
|
ist insbesondere das Produktwissen, welches für Anträge, Konvertierungen und Vertragsänderungen erforderlich ist.
|
|
|
|
```
|
|
### Process Flows
|
|
|
|
#### Antragsstrecke:
|
|
|
|
```
|
|
|
|
# Anforderungen
|
|
|
|
## Basis
|
|
* Es gibt _Verfahren_, diese legen fest, welche Services aufrufbar sind und welche Daten erwartet werden.
|
|
* Ein Auskunftsservice soll das Metamodell für den eigentlichen Request zurückgeben.
|
|
* Es soll einen Service zur probeweisen Ausführung der Modellinstanz geben (Validierung, Berechnung am Server) und
|
|
einen Service zur eigentlichen Durchführung.
|
|
* Es gibt Use-Cases, wo man vollständige Modelle übermitteln möchte, z.B. um ein neues Geschäftsobjekt anzulegen
|
|
oder zu erzeugen. Ein Beispiel wäre einen Versicherungsantrag zu übermitteln. In diesem Beispiel wird das
|
|
Geschäftsobjekt komplett neu erzeugt.
|
|
* Es gibt Use-Cases, wo man existierende Geschäftsobjekte referenziert und durch die Übermittlung eines kleinen
|
|
Änderungsobjekts oder Teilmodells modifiziert. Aber auch für kleinere Änderungsobjekt kann die Technik angewendet werden,
|
|
dass es einen Auskunftsservice und Services für die Validierung und Durchführung der Instanz gibt.
|
|
* Versionierung: Es gibt verschiedene Versionen eines Metamodells.
|
|
|
|
|
|
Schichten
|
|
```
|
|
| Objekte | Prozesse |
|
|
|================================================|================================================|
|
|
| VU-spezifische Datenobjekte | |
|
|
|------------------------------------------------| |
|
|
| Spartenobjekte | |
|
|
|------------------------------------------------| |
|
|
| Märkte (Österreich, CEE ...) | |
|
|
|------------------------------------------------| |
|
|
| Spezielle Datenobjekte: | |
|
|
| - Versicherungsverträge | |
|
|
| - Anträge | |
|
|
| - Schaden | Konkrete Prozesse: |
|
|
| - ... | Verknüpfung mit Datenobjekten | |
|
|
|------------------------------------------------|------------------------------------------------|
|
|
| Datenobjekte allgemeine Eigenschaften | Pattern / Profile Geschäftsprozesse |
|
|
|------------------------------------------------|------------------------------------------------|
|
|
| Technologie: Webservices, SOAP, REST, JSOM-LD |
|
|
|------------------------------------------------|------------------------------------------------|
|
|
| TCP-IP |
|
|
|------------------------------------------------|------------------------------------------------|
|
|
```
|
|
|
|
|
|
## Versicherungsprodukte
|
|
### Antragsverfahren
|
|
* Das Antragsverfahren hat eine a-priori Produktauskunft, welche das Produktwissen übermittelt.
|
|
* Es gibt spezielle Objekte für
|
|
* Produktbaum, bestehend aus
|
|
* Deckungsbaum
|
|
* (Produkt, Ereignis, Leistung wie bei VP/MS ?)
|
|
* Versicherungssummen
|
|
* Selbstbehalten
|
|
* Deckungsvarianten
|
|
* Versicherte Interessen (ein Objektmodell)
|
|
* Umschläge für Berechnung, Offerterstellung, Antrag
|
|
* Personendaten
|
|
* Sicherstellungen (Vinkulierungen...)
|
|
* Zahlungsinformationen
|
|
* Vertragsrollen
|
|
* Bezugsrechte
|
|
|
|
### Konvertierungsverfahren
|
|
* Scope: Für einen bestehenden Vertrag bzw. mehrere bestehende Verträge werden die Änderungsmöglichkeiten bezüglich
|
|
der Deckung angezeigt.
|
|
* Proposal: Es wird ein Vorschlag, für eine der gewünschten Deckung entsprechenden Folgevertrag erstellt.
|
|
* Es wird ein Antragsverfahren durchgeführt, um die Konvertierung auf den neuen Vertrag durchzuführen.
|
|
|
|
### Vertragsänderungsverfahren
|
|
* Behandelt Teilmodelle bezogen auf existierende Geschäftsobjekte (insbesondere Verträge)
|
|
* Kennt zwei Profile:
|
|
* Profil 1: stateless. Services Check und Execute
|
|
* Profil 2: stateful. Services Create und Submit |