GWK Gesellschaft fuer 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 Informationen vom Benutzer

Vollkonfigurierbar
Strukturierung der Fragen (Attribute) in Klassen.
Alle Texte (Fragetext, Hilfetexte, …) sind frei definierbar.
Der Typ der Antwort ist wählbar (Text, Datum, Ganzzahl, Gleitkommazahl…)
Vorschlagslisten können für alle Typen 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 Type „Datum“, aber mit folgender Validierung…)
Frei in Java erweiterbares 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ährende 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 Leistung hat, und ggf. auch eine Einschränkung (z.B. „bis 1.000 €“ ) dazu formuliert werden.
Einschränkungen können als Template oder Javascript formuliert werden und so auf vorher abgefragte Informationen zugreifen. (z.B. „bis $VT.Versicherungssumme €“)
Hilfetexte per Tarif, per Leistung oder per Leistung des Tarifs.
Automatische Berechnung der Kosten für eine wählbare Leistung. 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: hervorgehobene Anzeige aller Produkt- bzw. Leistungsmerkmale die dem geäußerten Wunsch nicht entsprechen.

Protokoll & Angebot

Gestaltung des PDF 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 (z.B. zum Ausfüllen von Formularen) [ 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 incl. der Aufrufprotokolle externer Rechner als XML.
Bei Nutzung durch den Kunden: Import/Export von auf dem PC des Kunden ablegbaren Benutzerdaten durch den Anwender. Dadurch muss der Kunde Daten nur einmal eingeben und bleibt trotzdem Herr seiner Daten.

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.
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 WePo2 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 lokal der Browser auf 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 zur Sitzung von der Bestandsführung abgeholt und zum 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 von einem Hintergrund-Prozess regelmäßig vom Portal-Server abgeholt und ins Bestandssystem übernommen.