Zu den täglich anfallenden Aufgaben gehört es, Einstellungen zu myInfoPoint Benutzern zu ändern bzw. anzulegen. Dies geschieht derzeit noch direkt auf der Datenbank und wird damit von IT erledigt. Der Auftrag hierzu kommt üblicherweise von Service, also Versicherungsbetrieb.
Um Wartezeiten für Versicherungsbetrieb zu minimieren und gleichzeitig die Arbeiten aus IT auszulagern ist für die anfallenden Aufgaben eine Weboberfläche zu erstellen, um die Aufgaben durch Versicherungsbetrieb ausführen zu lassen.
1. Einstellen / Ändern der Sicht eines Benutzers in myInfoPoint
1.1 Abfrage der Aktuellen Sicht
Für jeden Benutzer kann eine individuelle Sicht in myInfoPoint eingestellt werden. Dies kann auf mehreren Ebenen geschehen und wird in dieser Reihenfolge geprüft. Die letzte Zuordnung ist dann die gültige:
- Sicht aufgrund des zugrunde liegenden Vertriebsweges (der Kunde hat über einen Vermittler einen Versicherungsvertrag abgeschlossen und der Vermittler ist einem Vertriebsweg zugeordnet. Die Vertriebswege sind alle mit Sichten in myInfoPoint hinterlegt)
- Sicht aufgrund des Wunsches des Vermittlers für alle seine Kunden (zum Vermittler wurde auf dessen Veranlassung eine Sicht hinterlegt, die sich vom Vertriebsweg unterscheiden kann)
- Sicht aufgrund des Wunsches des Vermittlers für einen bestimmten Kunden (zum Kunden wurde auf Veranlassung des zugeordneten Vermittlers eine Sicht hinterlegt, die sich von den Sichten der anderen Kunden des Vermittlers unterscheiden kann)
Die aktuelle Einstellung zur Sicht erhält man z.B. über folgende Abfrage auf WEBDATA:
SELECT v.V_NR, r.P_NR, ov.VKVO, v.VERTRIEBSWEG_KZ,
NVL(msz1.SICHT_KZ, 0) AS SICHT_VERTRIEBSWEG, NVL(msz2.SICHT_KZ, 0) AS SICHT_VKVO, NVL(msz3.SICHT_KZ, 0) AS SICHT_P_NR
FROM V@BSTDB v
INNER JOIN OBJ_VM@BSTDB ov ON v.V_NR = ov.OBJ_NR AND ov.OBJ_KZ = 1 AND ov.HIST_KZ = 2
INNER JOIN ROLLE@BSTDB r ON v.V_NR = r.V_NR AND r.R_KZ = 1
LEFT OUTER JOIN MLS_SICHT_ZUORDNUNG msz1 ON v.VERTRIEBSWEG_KZ = msz1.VERTRIEBSWEG_KZ
LEFT OUTER JOIN MLS_SICHT_ZUORDNUNG msz2 ON ov.VKVO = msz2.VKVO
LEFT OUTER JOIN MLS_SICHT_ZUORDNUNG msz3 ON r.P_NR = msz3.P_NR
WHERE v.HIST_KZ = 2
ORDER BY v.V_NR DESC;
Das Ergebnis der Abfrage muss auf einen Kunden (P_NR) oder einen Vermittler (VKVO) gefiltert werden um den jeweiligen Wert korrekt abzufragen.
Bei Abfrage auf einen Kunden (P_NR) gilt:
Die Abfrage kann keinen, einen oder mehrer Datensätze liefern. Wird kein Datensatz geliefert, hat der Kunde keinen Vertrag und damit Sicht 0, also keine Sicht. Dies ist allerdings nur ein theoretische Konstellation; die Abfrage auf einen 'Kunden' der keinen Vertrag hat, erscheint unsinnig; ein Kunde definiert sich dadurch, daß er einen Vertrag hat.
Wird genau ein Datensatz von der Abfrage geliefert, so liefert SICHT_P_NR die für den Kunden eingestellte Sicht. Ist der Wert 0, gilt der Wert aus SICHT_VKVO. Ist dieser Wert auch 0, liefert SICHT_VERTRIEBSWEG die gültige Sicht für den Kunden.
Werden mehrere Datensätze geliefert, so gilt der erste Datensatz (aktuellster Vertrag durch absteigende Sortierung nach V_NR) und damit wird so verfahren wie zuvor beim Ergebnis mit nur einem Datensatz beschrieben.
Bei der Abfrage auf einen Vermittler (VKVO) gilt:
Die Abfrage kann keinen, einen oder mehrer Datensätze liefern. Wird kein Datensatz geliefert, hat der Vermittler keinen Kunden mit einem gültigen Vertrag und damit alle seine Kunden Sicht 0, also keine Sicht. Auch dies ist nur eine theoretische Konstellation.
Wird genau ein Datensatz zurückgeliefert gilt der Wert aus SICHT_VKVO. Ist dieser Wert 0, liefert SICHT_VERTRIEBSWEG die gültige Sicht für den Kunden.
Bei mehreren Datensätzen wird wiederum der erste Datensatz betrachtet und wie zuvor bei genau einem Datensatz verfahren. Das Feld SICHT_P_NR hat bei der Abfrage auf einen Vermittler keine Relevanz.
1.2 Setzen der Sicht
Gesetzt wird die Sicht in der Tabelle MLS_SICHT_ZUORDNUNG
für einen Kunden:
INSERT INTO MLS_SICHT_ZUORDNUNG (ID, SICHT_KZ, P_NR, KOMMENTAR) VALUES (DEFAULT, [SICHT], [Kundennummer], '[Kommentar]');
für einen Vermittler:
INSERT INTO MLS_SICHT_ZUORDNUNG (ID, SICHT_KZ, VKVO, KOMMENTAR) VALUES (DEFAULT, [SICHT], [VKVO], '[Kommentar]');
Zu beachten ist, daß die Felder alle angegeben werden müssen. Also Kommentar kann der Benutzer einen kurzen Freitext angeben; Idealerweise wird der aktuelle Zeitstempel angefügt. Das Kommentarfeld ist nur beschreibend und wird derzeit nicht ausgewertet. Dennoch sollte es immer gefüllt sein.
Das Schreiben der Daten mit INSERT geschieht nur, wenn noch keine Daten hinterlegt waren. gibt es zu einem Kunden oder zu einem Vermittler bereits eine Zugeordnete Sicht, so wird diese nach Änderung durch den Benutzer mittels UPDATE aktualisiert. Es darf immer nur maximal einen Datensatz pro Vermittler und genau ein Datensatz pro Kunde in der Tabelle MLS_SICHT_ZUORDNUNG vorhanden sein.
1.3 Umsetzung
In einer Maske gibt der Benutzer entweder eine Kundennummer oder eine VKVO an. Wird beides angegeben, wird nur nach der Kundennummer gesucht. Wurden Daten gefunden (siehe 1.1) Werden die Informationen aus VKVO und Sicht in die Maske übernommen, der Benutzer kann die Sicht anpassen und dann seine Einstellung speichern, wodurch die Informationen in der Datenbank aktualisiert werden. Der Benutzer erhält eine entsprechende Meldung, die Daten aus den Eingabefeldern werden gelöscht und es kann bei Bedarf gleich eine neue Abfrage ausgeführt werden. Entsprechend sollten Suche, Dateneingabe und Ergebnis auf genau einer Seite durchgeführt werden; für Suche und Dateneingabe sollten die gleichen Felder verwendet werden. Die Sicht kann der Benutzer nicht frei eingeben, sondern wählen aus
1 - Eingeschränkte Sicht
2 - Volle Sicht
3 - Volle Sicht mit Aktionen
Sollte die Abfrage (siehe 1.1) den Wert 0 liefern, wird als Voreinstellung 1 (Eingeschränkte Sicht) gesetzt; ansonsten wird der ermittelte Wert als Voreinstellung übernommen.
2. Ändern eines Benutzernamens in myInfoPoint
Benutzer können über myInfoPoint eine Änderung Ihres Benutzernamens (= ihrer Emailadresse) beantragen. Dies bedeutet derzeit, daß die Emailadresse in VWS geändert durch Versicherungsbetrieb geändert wird und für myInfoPoint selbst durch IT geändert wird.
2.1 Prüfen des Benutzernamens
Um zu prüfen, ob der Benutzer in myInfoPoint existiert, nutzt man auf WEBSERVICES eine der folgenden Abfragen:
SELECT * FROM ASPNET_USERS au WHERE au.USERNAME = '[alter Username]';
SELECT * FROM ASPNET_USER_EXTENSIONS aue INNER JOIN ASPNET_USERS au ON aue.USERID = au.USERID WHERE aue.PNR = [Kundennummer];
[alter Username] bzw. [Kundennummer] sind durch die entsprechende Information zu ersetzen.
Die Abfrage sollte genau einen Datensatz zurückliefern. Wird kein Datensatz gefunden, so ist der Benutzer unter diesem Namen / mit dieser Kundennummer nicht in myInfoPoint registriert.
2.2 Ändern des Benutzernamens / der Emailadresse
Die Änderung für myInfoPoint betrifft sowohl den Benutzernamen als auch die Emailadresse. Obwohl beide Informationen identisch sind, werden sie getrennt verwaltet und sind entsprechend auch einzeln in WEBSERVICES zu ändern:
UPDATE ASPNET_USER_EXTENSIONS aue SET aue.MAIL = '[neuer Username]' WHERE aue.USERID = (SELECT au.USERID FROM ASPNET_USERS au WHERE au.USERNAME = '[alter Username]');
UPDATE ASPNET_USERS aue SET aue.USERNAME = '[neuer Username]' WHERE aue.USERID = (SELECT au.USERID FROM ASPNET_USERS au WHERE au.USERNAME = '[alter Username]');
[alter Username] bzw. [neuer Username] sind durch die entsprechende Information zu ersetzen.
2.3 Umsetzung
In einer Maske gibt der Benutzer wahlweise einen Benutzernamen oder eine Kundennummer ein und erhält den aktuell hinterlegten Benutzernamen in myInfoPoint.
Wurde kein Eintrag gefunden, erhält der Benutzer eine entsprechende Meldung und kann dann seine Angaben ggf. Ändern und eine neue Abfrage durchführen.
Wurde ein Eintrag gefunden, hat der Benutzer die Möglichkeit, einen neuen Benutzernamen einzugeben und die Änderung durchführen zu lassen. der Wert wird dann sowohl als Benutzername als auch als Emailadresse übernommen. Die beiden Felder sind identisch zu führen; es werden entsprechend keine getrennten Eingabefelder hierfür angeboten.
3. Technische Umsetzung
Für die Umsetzung sind im folgenden technischen Aspekte zu beachten.
3.1 Zugriff auf die Datenbank
Der Zugriff erfolgt sowohl lesend als auch schreibend ausschließlich über EntityFramework. Für die Abfrage (siehe 1.1) ist der Zugriff auf Daten der Bestandsdatenbank (GUTINGIA, @BSTDB) notwendig, welche im Webkontext nicht erreichbar ist. Entsprechend ist hierfür eine View auf WEBDATA zu erstellen. Analog zu bisherigen Datenbankobjekte für myInfoPoint und zur schnelleren Einordnung beginnt der Name der View mit 'MLS_'.
3.2 Umsetzung als Services
Die Aktionen (Lesen der Daten, Schreiben von Daten) sind als REST-Services zu implementieren welche die Entities (3.1) verwenden.
3.3 Umsetzung der Webseite
Punkt 1 und Punkt 2 der Anforderungen sind in getrennten Seiten und jeweils als eine einzelne Seite umzusetzen. Die Seiten nutzen die REST-Services (3.2) um Daten abzufragen und zu schreiben.