Fortuna Entwickler Blog

Hier wird Ihnen geholfen

Transfer von DBWEBTESTDMZ1 nach DBWEBTEST3

  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)


listener.ora (580B)

Neuinstallation Datenbank.txt (1,8KB)

Fullimport_DBWEBTEST3.bat (79B)

VENTA Import für HV und BV

Aktuell wird im Honorarmanager sowohl nach Honorar- und Betreuungsvertrag, als auch nach Angebot und Bestand getrennt. Im VENTA gibt es bei der Anzeige keinerlei Trennung. Im VENTA werden Verträge grundsätzlich unter den einzelnen Kunden angezeigt; im Honorarmanager werden immer alle Verträge des HFB angezeigt.
Die Abfrage der HV/BV aus VENTA läuft immer über eine Liste von GUIDs. Diese GUIDs liegen in FRW_VERTRAG. Die Verbindung ergibt sich im Prinzip so:

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.



 

Import von Versichrungs- und HV/BV-Daten in VENTA

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.