GWK Gesellschaft für Informationstechnologie mbH

Implementiert sind Authentifizierungen über eine Benutzerdatei und/oder IP-Absendernummern. Die Authentifizierung ist modular erweiterbar, LDAP z.B. ist in Vorbereitung.

Abfrage der Anwender-Informationen

vollkonfigurierbar
Strukturierung der Fragen (Attribute) in Klassen.
Alle Texte (Fragetext, Hilfetexte, …) sind frei definierbar.
Der Datentyp der Antwort ist wählbar (Text, Datum, Ganzzahl, Gleitkommazahl…).
Vorschlagslisten können für alle Datentypen gebildet werden.
Stile sind wählbar (Pulldown, Radiobutton, Checkbox, Standard Eingabefeld)
Standardvalidierungen (z.B. Min./Max. bei Ganzzahlen, Alter beim Datum)
erweiterte feldbezogene Validierungen in Javascript (Server-Side) oder als reguläre Ausdrücke
objektorientiertes Typsystem (Dieser Typ ist wie der Typ „Datum“, aber mit folgender Validierung…)
frei in Java erweiterbare Typen
ausgefeilte Konditionierungsmöglichkeiten ("Diese Frage nur anzeigen wenn…")
Berechnete Attribute können zur Konditionierung als Ausgabefelder definiert werden („Ihre Versorgungslücke beträgt 10.000 €“)
Spezielle Erweiterungsattribute können externe Rechner zur Ermittlung von Zwischenwerten schon während der Informationsabfrage nutzen.

Objektmodell

freie Definition der für diesen Tarif relevanten Objekte und deren Klasse
Objekte können Mengencharakter haben (mehrere möglich)

Beispiel:

Beispiel aus der Versicherungsbranche als Dienstleistung: Unfallversicherung

Zum berechnen eines Unfallversicherungsantrags, werden folgende Objekte benötigt:

ein Versicherungsnehmer (VN)
ein oder mehrere versicherte Personen (VP/VPs)
allgemeine Vertragsdaten zur Unfallversicherung (VT)

Diese Objekte werden in der Unfallversicherungs-Konfiguration definiert: VN, VP und VT.

VN und VP sind vom Typ Person, VT ist vom Typ Unfallversicherungsvertragsdaten.

Die relevanten Attribute/Fragen aus den gewählten Klassen können frei selektiert werden.

Automatische Dublettenerkennung d.h. sind VN und VP dieselbe Person werden Fragen nicht doppelt gestellt. Je VP können Leistungen voneinander abweichen.

Produktkonditionierung & Berechung

Bedingungen wie „Diesen Kühlschrank nur zeigen, wenn die Höhe kleiner ist als die vom Benutzer vorgegebene“ können per Javascript (Server-Side) gesetzt werden.
Prämienberechnung in Javascript, Java oder
Prämienberechnung durch den Aufruf externer Rechner.

Vergleichsansicht

Anzeige einer Übersicht aller angebotenen Produkte mit Ihren Leistungen in einer Tabelle
Optionale Leistungen können noch in der Tabelle gewählt oder abgewählt werden.
Per Dienstleistung/Produkt kann festgelegt werden, ob diese(s) eine Zusatzleistung hat, und ggf. auch eine Einschränkung (z.B. „bis 1.000 €“ ) dazu formuliert werden soll.
Einschränkungen können als Template oder Javascript formuliert werden und so auf vorher abgefragte Informationen zugreifen (z.B. „bis $VT.Versicherungssumme €“).
Hilfetexte zu jeder Zeile, Spalte oder Zelle der Tabelle
Kosten für eine wählbare Leistung werden automatisch berechnet. Diese Kosten werden dann im Vergleich angezeigt.
Es können auch Nichtleistungen definiert werden, also Leistungen, die zwar von keinem angezeigten Produkt angeboten werden, aber ggf. im freien Markt erhältlich sind.
optionale Bedarfsanalyse, in der der Kunde nach jeder möglichen Leistung gefragt wird (gewünscht oder nicht)
automatischer Vorschlag des günstigsten Angebots, das alle Kriterien erfüllt
In der Vergleichsübersicht werden alle Produkt- bzw. Leistungsmerkmale hervorgehoben angezeigt, die dem geäußerten Wunsch nicht entsprechen.

Protokoll & Angebot

Gestaltung des PDFs mit denselben Elementen, in denen auch die Inhalte definiert werden
Anzeige einer Übersicht aller angebotenen Produkte mit Ihren Leistungen in einer Tabelle
Textblöcke können mehrfach verwendet werden.
Hinterlegen von PDFs hinter den Text des Systems, beispielsweise zum Ausfüllen von Formularen (diese Leistung ist aufwändig)
Aufdrucken von Fußzeilen auf vorgegebene externe PDFs
Zugriff auf alle bis dahin eingegebenen Informationen
Logikfunktionen wie if/then/else und foreach (Velocity Templates)
Aufruf externer Rechner (z.B. zur Beschaffung einer eVb bei KFZ-Versicherungsanträgen)
Aufruf externer Rechner zur Beschaffung von vorausgefüllten PDFs von einem Anbieter
Protokollfunktionen zur Protokollierung aller Eingaben sowie der Vergleichstabelle

Datenschnittstelle

Import von Bestandsdaten als XML mit Mapping per Template. [Mapping über XSL in Vorbereitung]
Export aller Daten inklusive der Aufrufprotokolle externer Rechner als XML
Kundendaten können auf dem PC des Kunden abgelegt und importiert/exportiert werden. Dadurch muss der Kunde Daten nur einmal eingeben, die Datensicherheit bleibt dabei trotzdem gewährleistet.

Externer Rechneraufruf

Aufruf von Fremdrechnern per HTTP/HTTPS per GET oder POST, Übermittlung von Parametern per GET oder POST, Übermittlung von Dokumenten per POST/MIME oder als direkter POST, Übermittlung von SOAP-Requests.
Proxy Support mit Benutzeranmeldung
HTTP/HTTPS Benutzeranmeldung
Dateitransfer und Dateiempfang
variable Kodierungsmöglichkeiten
Parsen der Antwort per XPath oder mit regulären Ausdrücken.
Fehlerkennung in der Antwort
Kommunikationsfehlererkennung
asynchrones paralleles Absenden multipler Requests
Der externe Rechnerabruf ist als Client-Modul einsetzbar zum Absetzen von vorher vorbereiteten Requestanweisungen (z.B. aus der Bestandsführung)

Integration mit der Unternehmensführungssoftware (z.B. Bestandsführung)

Auch wenn WePo grundsätzlich in der Lage wäre, eine Bestandsführung zu bieten, so ist ein im Internet von außen zugänglicher Server aus Sicherheitsgründen nicht die erste Wahl, um Bestandsdaten zu speichern.

Daher wird folgender Ablauf unterstützt:

Der Agent startet aus der lokalen Bestandsführung heraus einen Ablauf, in dem die Daten des aktuellen Kunden in geeigneter Form an das Portal übergeben werden.
Danach wird der Browser lokal mit den übergebenen Daten gestartet. Alle Masken des Portals zeigen nun vorausgefüllt bereits die aus der Bestandsführung übergebenen Daten an.
Am Ende der Sitzung (wenn das Browserfenster wieder geschlossen wird) werden die erzeugten Daten der Sitzung von der Bestandsführung abgeholt und beim Kunden hinterlegt.
In der Regel lassen sich Schnittstellenprogramme dieser Art für jede Bestandsführung erstellen.
Die Daten werden nach der Abholung vom Portal-Server gelöscht und sind so sicher vor Angreifern.

Kundendaten, die vom Kunden selbst (ohne einen Agenten) erzeugt wurden, werden durch einen Hintergrund-Prozess regelmäßig vom Portal-Server abgeholt und ins Bestandssystem übernommen.