Fortuna Entwickler Blog

Anders als bei der initialen Übernahme werden die Zuordnungen Dokument <-> Vertrag nicht mehr in der Tabelle IMP_VORGANG_CE abgelegt, sondern das gelieferte Excel-Dokument wird in die Tabelle IMP_POSTFACH manuell importiert; mit dbForge geht das rechts einfach über Rechtsklicke auf IMP_POSTFACH -> Import Data … -> Excel Datei wählen -> Erste Zeile enthält Spaltennamen und Import. 

Das Programm zur Übernahme der Dokumente findet man im Projekt Akazie.Console.Document im Teamprojekt Akazie. Hier muss der Release-Stand gebaut und verwendet werden. Nur dann wird nach dbDok geschrieben. Bitte vorm Ausführen der Befehle nochmals die app.config prüfen, ob die DB-Einträge korrekt sind.

Hilfe-Seite aufrufen:

Import durchführen:

Auslöser: E-Mail von i. d. R. Retkowski (Ergo-Vorsorge) „neue Dateien vorhanden“ (siehe Anhang Datenlieferung.msg)

Folgende Dateigruppen werden erwartet:

1. AXA_SAP.zip
2. AXA_ICIS.zip
3. AXA_TIF.zip
4. AXA_Gewinnkonten.zip
5. AXA_Technikkonten.zip

6. AXA_Anlagebewegungen.zip

Öffnen einer Verbindung auf dem EUHOST-SFTP-Server mit WinSCP

Verbindungs-/Zugangsdaten:

WinSCP ergänzende Einstellungen:

Herunterladen der Dateien auf lokales Verzeichnis 

(z.B. C:\Users\msommer\Downloads)

• Downloadzeit (insgesamt ca. 9 Min. )
• AXA_SAP.zip (45 Sek.)
• AXA_ICIS.zip (60 Sek.)
• AXA_TIF.zip (60 Sek.)
• AXA_Gewinnkonten.zip (30 Sek.)
• AXA_Technikkonten.zip (160 Sek.)
• AXA_Anlagebewegungen.zip (170 Sek.)

Kopieren der Dateien, wie folgt:

Dokumente:

• AXA_TIF.zip nach \\BACKUP3\Import kopieren
• Dateiname um das Import-Datum (z. B. AXA_TIF_201809019.zip) erweitern
• entsprechendes ZIP-File in einen namensgleichen Ordner (z. B. AXA_TIF_20180919) entpacken 
• Kopierzeit: AXA_TIF.zip (5 Sek.)
• Entpackzeit: AXA_TIF.zip (2 Min / ca. 6000 Dateien)

DB-Dateien

• unter \\web3\Dokumente\system\import\Akazie\Axa ein Ordner mit aktuellem Datum anlegen (Lieferung_20180919)
• in diesem Ordner 2 weitere Ordner („SAP“und „Zipfiles“) anlegen
• die restlichen Zip-Dateien nun in den neu angelegten Unterordner ZIPfiles kopieren

AXA_SAP in den Unterordner SAP entpacken

die ZIPs (AXA_ICIS, AXA_Gewinnkonten, AXA_Technikkonten, AXA_Anlagebewegungen) in den Lieferung-Ordner (z. B Lieferung_20180919) entpacken

Kopierzeit der 5 ZIP-Dateien (insgesamt 45 Sek.)

Entpackzeit: (insgesamt ca. 22 Min. ):

• AXA_SAP.zip (5 Min.)
• AXA_ICIS.zip (1 Min.)
• AXA_Gewinnkonten.zip (2 Min)
• AXA_Technikkonten.zip ( 10 Min.)
• AXA_Anlagebewegungen.zip ( 4 min)

AXA den Erhalt nach erfolgreichem Herunterladen und Entpacken bestätigen 

(siehe Anhang Bestätigung Datenlieferung.msg)

Christoph / Torsten über das Bereitstellen informieren

(siehe Anhang Bereitstellung Dateien.msg)

Die Quellen zum Import Tool sind im Teamprojekt Akazie abgelegt. Das Tool selbst heißt Akazie.Console.

Nach dem Laden der Solution und erstellen von Akazie.Console liegen alle notwendigen Dateien im bin-Verzeichnis des Projektes vor und ein Import kann damit ausgeführt werden.

Herauszuheben sind hier folgende Dateien:

AkazieImport.exe

Dies ist die Applikation für den Import. Diese .exe muss aufgerufen werden.

AkazieImport.exe.config

Dies ist die Konfigurationsdatei zur Applikation. Hier ist u.a. die Datenbankverbindung (=Ziel des Imports) hinterlegt.

NLog.config

Dies ist die Konfigurationsdatei für die Protokollierung. Hier ist u.a. Festgelegt, in welche Datei Protokolliert wird und wie Protokolldateien archiviert werden.
Hier wird es in Zukunft voraussichtlich noch Änderungen geben, sodass die Protokollierung besser nachvollziehbar wird, wenn man mehrere Parallele Imports startet.

Die Anwendung selbst biete einige Optionen und auch eine kurze Hilfe hierzu:

Ohne Eingabe von Parametern erhält man also den Hinweis auf die Hilfeseite. Mit Eingabe von Parameter /? erhält man die Hilfeseite.

/silent

Bei normaler Ausführung werden diverse Meldungen über die aktuelle Bearbeitung am Bildschirm ausgegeben. Mit /silent wird dies unterdrückt.

/debug

Neben der normalen Ausgabe über die aktuelle Bearbeitung erhält man mit /debug weitere Informationen; u.a. den jeweiligen Zeitpunkt der Benachrichtigung.

/log

Neben der Ausgabe am Bildschirm werden Ausgaben zusätzlich in einer Logdatei erfasst. Dies ist insbesondere dann sinnvoll, wenn es beim Import zu Fehlern kommt. Diese werden entsprechend auch in der Logdatei protokolliert. Die Konfiguration genau dieser Logdatei erfolgt derzeit noch über die Datei NLog.config im Verzeichnis der AkazieImport.exe

/noclear

Normalerweise wird vor einem Import die Zieltabelle mittels Truncate Table geleert. Mit /noclear lässt sich dies unterbinden. Daten, die mit /noclear Importiert werden, werden entsprechend dem aktuellen Datenbestand der Zieltabelle hinzugefügt.

/i:[Dateiname(n)]

Mit diesem Parameter gibt man an, welche Dateien importiert werden sollen. Hier kann man eine einzelne Datei eingeben, eine Liste von Dateien mit Komma getrennt angeben, eine Menge von Dateien mit dem Joker (*) angeben, oder eine Kombination der Möglichkeiten:

Eine Datei Importieren unter Angabe des vollen Dateinamens

Mehrere Dateien importieren unter Angabe der Dateinamen

Mehrere Dateien importieren unter Verwendung von Dateinamen und/oder Joker. hier zusätzlich mit Logging und Debuginformationen (nur zur Visualisierung der Optionen

Das Logging sah in diesem Beispiel dann so aus

1. Erstellen eines Exports auf DBWEBTESTDMZ1
   Über die Eingabeaufforderung auf dem Datenbankserver wird mittels des Kommandos EXPDP (https://oracle-base.com/articles/10g/oracle-data-pump-10g) ein kompletter Datenbankdump erstellt. Hierfür verwendet werden die Batchdatei 'fullexport_dbwebtestdmz1.bat' und dir darin verwiesene 'fullexport_dbwebtestdmz1.dat' (siehe Attachments). bei Anderen Datenbankservern müssen die Namen / Logindaten entsprechend angepasst werden.
   
   
2. Erstellen einer neuen Datenbank auf DBWEBTEST3
   Über die Anwendung 'Datenbank-Konfigurationassistent' wird eine neue Datenbank erstellt:
   
   Zu beachten ist hier insbesondere der verwendete Zeichensatz. Das abgefragte "dbora"-Kennwort ist das Kennwort des entsprechenden Windows-Benutzers. Wichtig ist auch, den Haken bei 'Als Containerdatenbank erstellen' zu entfernen, da dies Implikationen auf die Lizenzen hätte. Mit Klick auf 'Weiter' wird dann die Datenbank erstellt und steht nach kurzer Zeit zur Verfügung.
   
   
3. Konfigurieren und starten des Listeners
   Der Listener auf dem Server muss einmalig erstellt werden. Dies kann entweder über das Tool 'netca' erfolgen, welches über die Kommandozeite aufgerufen wird, oder man erstellt einfach unter {ORACLE_HOME}/NETWORK/ADMIN (das Verzeichnis, in dem auch tnsnames.ora und sqlnet.ora liegen) eine Textdatei listener.ora (Beispieldatei siehe Attachments). Der Listener muss dann noch einmalig über die Eingabeaufforderung mittels 'lsnrctl start' gestartet werden (https://docs.oracle.com/cd/B16351_01/doc/server.102/b14196/network004.htm).
   
   
4. Notwendige Datenbankobjekte erstellen
   Spezifisch für diesen aktuelle Transfer wurden einige Objekte vorab angelegt.
   Dies ist zum einen der Tablespace. Dieser wurde initial auf 20GB gesetzt und wie in der Entwicklungs- und Produktionsumgebung WEBDATA genannt (anders als auf DBWEBTESTDMZ1; hier hiess er DATA01).
   Desweiteren wird der User GUTSUPER mit DBA-Rechten angelegt. Es werden diverse Rollen erstellt und diesen Rechte erteilt und zuletzt noch Database Links erstellt. Bei Erstellung der Links ist darauf zu achten, daß auch tatsächlich eine Verbindung zum Zielserver hergestellt werden kann. Dies kann man in der Eingabeaufforderung mit 'TNSPING [Servername]' testen. Der Ping muss erfolgreich sein, ansonsten fehlen hier ggf. entsprechende Konfigurationen in Firewall/Proxy.
   Das Vollständige Script 'Neuinstallation Datenbank.txt' ist in den Attachments enthalten.
   
   
5. Import der Daten und Strukturen aus DMWEBTESTDMZ1
   Zuletzt werden dann Strukturen und Daten aus dem Datenbankdump (siehe 1.) mittest IMPDP (https://oracle-base.com/articles/10g/oracle-data-pump-10g) übernommen. Dies geschieht über eine Batchdatei 'Fullimport_DBWEBTEST3.bat' und die darin verwiesene Konfigurationsdatei 'Fullimport_DBWEBTEST3.dat'.
   Im vorliegenden Fall wurden nur die Schemas WEBDATA, WEBFRW, WEBSERVICES übernommen. Dies ist ggf. in der Konfigurationsdatei anzupassen. Die Transformation des Tablespaces (DATA01 zu WEBDATA, siehe 4.) wird in der Konfigurationsdatei berücksichtigt (Dateien siehe Attachments)

Attachments

fullexport_dbwebtestdmz1.bat (82B)

SELECT fv.VERTRAG_ID, hv.HV_NR, vtw.MODEL_ID
	FROM HV hv
	INNER JOIN VWS_TO_WEB vtw ON hv.HV_NR = vtw.OBJ_NR AND vtw.OBJ_KZ = 17 AND vtw.ANTRAG_STAT = 2
	INNER JOIN FRW_VERTRAG fv ON vtw.MODEL_ID = fv.VERTRAGSNUMMER
WHERE
	hv.HIST_KZ = 2;

respektive für Betreuungsverträge:

SELECT fv.VERTRAG_ID, bv.BV_NR, vtw.MODEL_ID
	FROM BV bv
	INNER JOIN VWS_TO_WEB vtw ON bv.BV_NR = vtw.OBJ_NR AND vtw.OBJ_KZ = 18 AND vtw.ANTRAG_STAT = 2
	INNER JOIN FRW_VERTRAG fv ON vtw.MODEL_ID = fv.VERTRAGSNUMMER
WHERE
	bv.HIST_KZ = 2;

HV_NR in HV und BV_NR in BV sind jeweils eindeutig. MODEL_ID in VWS_TO_WEB und VERTRAGSNUMMER in FRW_VERTRAG sind derzeit nicht eindeutlig; es gibt eine ganze Reihe von Einträgen mit Mehrfachvorkommen:

-- Mehrfache VERTRAGSNUMMER
SELECT fv.VERTRAGSNUMMER, COUNT(*) AS ANZAHL
    FROM FRW_VERTRAG fv
    GROUP BY fv.VERTRAGSNUMMER
    HAVING COUNT(*) > 1;

-- Mehrfache MODEL_ID
SELECT vtw.MODEL_ID
    FROM VWS_TO_WEB vtw
    GROUP BY vtw.MODEL_ID
    HAVING COUNT(*) > 1;

-- Verträge in FRW_VERTRAG mit mehr als 1 Eintrag in VWS_TO_WEB
SELECT fv.VERTRAG_ID, COUNT(*) AS ANZAHL
    FROM FRW_VERTRAG fv
    INNER JOIN VWS_TO_WEB vtw ON vtw.MODEL_ID = fv.VERTRAGSNUMMER
    GROUP BY fv.VERTRAG_ID
    HAVING COUNT(*) > 1;

Diese Einträge sollten bereinigt werden, sodaß es eine VERTRAGSNUMMER in FRW_VERTRAG nur genau ein Mal gibt und es eine MODEL_ID in VWS_TO_WEB nur genau einmal gibt.

Anschließend sollten fehlende HV/BV ergänzt werden. Somit sollte dann zuletzt für jede HV_NR ein Eintrag in VWS_TO_WEB existieren und für jeden Eintrag in VWS_TO_WEB ein Eintrag in FRW_VERTRAG.

Um diesen Zustand dann auch weiterhin sicherzustellen, sind ggf. Prozesse anzupassen:

• Eine Vertragsnummer aus FRW_VERTRAG darf nur genau einmal verwendet werden und muss danach gekennzeichnet sein, sodaß eine erneute Verwendung nicht möglich ist.
• HV/BV, welche ohne Verwendung einer VERTRAGSNUMMER/MODEL_ID angelegt werden, müssen (z.B. in einem abendlichen Job) um Einträge in VWS_TO_WEB und FRW_VERTRAG ergänzt werden.
• In VENTA ist der Service zur Übertragung von HV/BV derart anzupassen, daß er nicht mehr - wie bisher - über die Anmeldedaten des jeweiligen HFB aufgerufen werden muss, sodern z.B. über die Anmeldung eines Admin-Accounts der Import für beliebige VENTA-Benutzer durchgeführt werden kann. Selbiger müsste dann nach Beendigung des vorherigen Punktes aufgerufen werden.

Damit diese Tätigkeiten greifen ist es nötig, den Service zum Abrufen der HV/BV anzupassen. Daten müssen dann neben FRW_VERTRAG (wird heute schon verwendet) auch aus HV und BV abgefragt werden.

Nach Aufruf des Programm wird die zentrale Benutzeroberfläche angezeigt:

• VKVO: Hier ist die VKVO des Benutzer/HFB einzutragen. Über diese VKVO werden die Verträge (Versicherung, HV, BV) selektiert.
• VENTA Benutzername: Hier ist der Benutzername des HFB in VENTA einzutragen. Über den Benutzernamen werden die HV/BV selektiert und die Anmeldung am VENTA-Service zu Übertragung der HV/BV durchgeführt.
• VENTA Benutzerkennwort: Hier ist das Kennwort des o.a. Benutzers anzugeben. Über das Kennwort wird die Anmeldung am VENTA-Service zu Übertragung der HV/BV durchgeführt.

Die nächsten Auswahlen sind optional. Man kann wählen, ob Versicherungsverträge und/oder HV/BV exportiert werden sollen.

• Export Versicherungsdaten in CSV: Entsprechend der VKVO werden die Versicherungsverträge zum HFB exportiert. Der Export erfolgt per CSV und kann dann in VENTA über den CSV-Import eingelesen werden. Die CSV-Datei wird unter C:\Temp\Venta_[VKVO]_[Datum].csv abgelegt. Der Pfad ist hierbei konfigurierbar.
  
• Export/Import HV/BV Daten per Service: Entsprechend der VKVO und dem Benutzernamen werden HV/BV exportiert und über den VENTA-Service importiert in VENTA.

Schaltfläche Export: Der Export (und ggf. Import) wird entsprechend der angegebenen Daten / gewählten Optionen durchgeführt. Die Schaltfläche ist nur aktiviert/klickbar, wenn eine 6-stellige VKVO eingegeben wurde.

Schaltfläche Schließen: Die Anwendung wird beendet.

Im TFS unter Fortuna/Tools/Fortuna.MuenchenerVerein/ExcelTrasition gibt es eine Solution Fortuna.MuenchenerVerein.ExcelTrasition. Hier gibt es Klassen zu Übernahme der Excel-Daten in eine Oracle Datenbank.

Die Excel-Dateien von MV sind im Projekt enthalten. Gibt es neue Daten, müssen diese ausgetauscht werden.

Ebenso enthalten ist ein Script zur Erzeugung der Datenbanktabellen.

Um die Daten zu Übernehmen gibt es eine ganze Reihe von Tests (zu sehen über den Testexplorer. Diese Test können/müssen einzeln oder en bloc ausgeführt werden. Die Ausführungszeit liegt bei ca. 30 Minuten (Stand September 2013)

Aktuell werden zwei Excel-Tabellen zur Verfügung gestellt:

• Attributkatalog.xslx enthält eine Beschreibung zu allen Attributen/Feldern für die Importtabellen
• Daten.xslx enthält mit insgesamt 8 Sheets die eigentlichen Daten

Die Solution für den Datenimport findet man unter $/Fortuna/Tools/Fortuna.MuenchenerVerein. In der Solution sind auch die beiden o.a. Excel-Sheets hinzugefügt.

Der eigentliche Import läuft ohne eigenes interface/ohne Applikation, sondern man fürht in Visual Studio schlicht die in der Solution enthaltenen Tests durch. Diese holen sich je Tabelle aus dem Attributkatalog.xslx die relevanten Felder, suchen je Feld und Satz die zugehörigen Daten und Speichern diese - ggf. nach Tranformation - in die Datenbank ab.