Fortuna Entwickler Blog

1. Gesamt Backup der BCAS-Tabellen (optional)

Noch bevor die Monatliche Bearbeitung gestartet wird, werden alle aktuellen Daten gesichert, sodaß man im Falle eines Falles immer wieder auf den Ausgangsstand zurück kann:

2. Backup der aktuell hinzugekommenen Daten (BCAS_SELECT_BACKUP.sql)

Zudem werden die aktuell gelieferten Daten nochmals separat gesichert. Diese Daten werden später in einem Testlauf auf der Testumgebung eingespielt, um die korrekte Durchführung zu überprüfen.

Hierzu werden die SQL-Statements im genannten Script ausgeführt und die Ergebnisse jeweils als SQL-Script exportiert. Die Scripte werden auch historisch aufgehoben.

3. Kopieren der monatlichen Scriptvorlage (Autoscript_XX_YYYY-MM.sql)

Damit nach alles vorbereiteten Arbeiten letztlich nur ein einziges Script ausgeführt werden muss, gibt es eine Vorlage, die man sich für jeden Monat kopiert und anpasst.

4. Monatstext, Dateinamen der Exports, Änderungen anpassen/einfügen

Aus diesem Script (Schritt 3) heraus werden die unter Schritt 2 erstellten Scripte aufgerufen, Änderungen, welche BCAS per Excel mitteilt, durchgeführt und die monatliche Verarbeitung aufgerufen. (BCAS_Unterschiede_SELECT.sql)

5. BCAS_Autoscript.sql um neues Script erweitern (optional)

Das genannte Script ist eine Zusammenfassung aller bisherigen Datenlieferungen; hier werden die Scripte aller monatlichen Verarbeitungen (Schritt 4) nacheinander aufgerufen. Dadurch kann man von einer leeren Datenbank ausgehend immer wieder den aktuellen Stand herstellen.

6. Ändern aller neuen .SQL-Dateien auf ANSI

dbForge speichert Scripts immer als UFT-8. Dieses wiederum wird von SQL plus nicht korrekt gelesen. Deswegen sind - nachdem alle Scripte vollständig sind - selbige auf ANSI zu Ändern. Dies kann z.B. mit Notepad++ gemacht werden.

7. Sicherung des Daten-Ordners als ZIP-Datei und Verschieben des ZIP-Archivs, Umbenennen in BCAS_YYYY_MM.zip (optional)

Nachdem nun alles vorbereitet ist und alle Daten zur Verfügung stehen, wird ein komplettes Backup auf Dateiebene durchgeführt, da monatlich neue Dateien hinzukommen aber auch bestehende Dateien geändert werden.

8. Script in Testumgebung ausführen

Das Script aus Schritt 3 mit den Änderungen von Schritt 4 wird anschließend in SQL plus auf der Testumgebung ausgeführt

9. Änderungen aus Script und monatliche Verarbeitung auf Produktionsumgebung ausführen

Die Änderungen aus Excel und die eigentliche Verarbeitung werden dann auf der Produktionsumgebung ausgeführt, wenn der Test (Schritt 8) erfolgreich war. Hierzu entweder die SQL-Statements einzeln ausführen oder das Script temporär anpassen.

10. Auswertungen für SK und CZ erstellen und Almut zur Verfügung stellen

Auswertung Slowakei.sql und Auswertung Tschechien.sql ausführen, die einzelnen Ergebnisse nach Excel exportieren und die Exporte dann Almut zur Verfügung stellen. Eine Besonderheit sind die Monats- und die Statusübersicht. bei diesen wird das Excel-Blatt des vorherigen Monats kopiert, umbenannt und um die entsprechenden Daten aus den Auswertungen erweitert.

Als derzeitigen Anbieter nutzen wir smstrade.de zum Versenden der TAN per SMS in den Anwendungen myLife Invest und mylifedirekt.de.

Um für das Versenden der SMS Guthaben aufzuladen, muss man sich auf der Seite http://www.smstrade.de mit Benutzername und Kennwort anmelden (Zugang ist bei Christoph Biegner und Christian Mielke bekannt):

Im internen Bereich klickt man anschließend auf "Jetzt aufladen":

Als nächstes wird die Rechnung in der Höhe erstellt, wie in das Konto eingezahlt werden soll:

Ist dies getan, so wird eine verbindliche Rechnung als PDF erstellt. Mit dem PDF sind folgende Schritte zu tun:

1. PDF ausdrucken
2. Kostenstellenstempel auf den Ausdruck anbringen (gibt es im REWE bei Holger Scholze oder im Sekretariat oder bei Silke Lücke im Keller)
3. Peter Ellrott muss Kostenstelle und seine Unterschrift eintragen
4. Jemand, der befugt ist, muss bei "sachl. geprüft" unterschreiben
5. Rechnung muss dem REWE (Holger Scholze) zur sofortigen Überweisung vorgelegt werden

Um aus Webanwendungen E-Mails über den VWS Mail Dienst zu verschicken, benötigt man lediglich die Assembly "Fortuna.Communication.VwsMail". In dieser Assembly gibt es die Klasse "VwsMail" mit der Methode "CreateMail". 

Die Methode wird statisch verwendet:

var mailId = VwsMail.CreateMail(styleKz, ausfuehrung, absender, empfaenger, cc, bcc, betreff, anhaenge, variablenTexte, objRefs);

Die Parameter haben folgende Bedeutung:

Der VWS Scheduler auf IASPROD2 hat einen Job, der alle zwei Minuten nachschaut, ob eine Mail verschickt werden muss. Er erkennt dies am Status 1. Bereits versendete Mails haben den Status 99. Zurück liefert die Methode die ID, unter der die zu verschickende Mail in der Datenbank abgelegt wird.

Wenn eine Mail versendet wird, wird sie auch als PDF in der Tabelle GUTINGIA.MAIL_HEADER archiviert.

Die Styles / Templates, die man zum Versenden nutzen möchte, müssen in der Tabelle GUTINGIA_MAIL_STYLE_KZ vorher angelegt werden. 

Im Modus DEBUG und TEST wird der Empfänger immer durch test@mylife-leben.de ersetzt. Gleiches geschieht mit CC und BCC, sollten diese Felder belegt sein.

ACHTUNG: Stand aktuell gibt es auf Entwicklung und Test keinen Scheduler Job, der die Mails dann auch wirklich verschickt. Dieser existiert nur auf Produktion!!!

Mit fincon wurde vereinbart, daß wir eine Versionsnummer in unseren ExternalServices einführen. VisualStudio Projekte bieten grundsätzlich die Möglichkeit, eien Versionsnummer über die AssemblyInfo zu pflegen, dies aber nur manuell: man muss die Datei ändern dann wird beim nächsten Build die angegebene Versionsnummer in die Binary übernommen. Dieses Vorgehen ist natürlich fehleranfällig bzw. es kann vergessen werden, nach Änderungen die Versionsnummer anzupassen.

Eine Extension für VisualStudio macht die Sache leichter:

• In VisualStudio aus Tools -> Extensions and Updates aufrufen
  
• Online nach 'Automatic Versions' suchen (Pecision Infinity, Version 1.5.1) und installieren
• Nach einem Neustart von VisualStudio hat man im Menü Tools einen neuen Eintrag 'Automatic Versions Setting'

Für das ScanProgramm und die ExternalServices habe ich hier jetzt für alle Versionen eingestellt:

Die Major lasse ich unangetastet (Default: 1), Minor wird über die Jahreszahl (4stellig) gesetzt, der Build bekommt den aktuellen Monat und Revision lasse ich automatisch hoch zählen. Das Inkrement passiert dabei nur, wenn VisualStudio erkennt, daß die Binary neu erstellt werden soll (Rebuild Solution) oder muss (Build Solution nach Änderungen)

Für die genannten Projekte ist dies schon eingerichtet (nicht für die zugehörigen Libraries!) und da muss dann auch nichts weiter gemacht werden. Allerdings muss sich jeder, der in die Produktionsumgebung published, die Extension installieren, damit bei einer Produktivstellung auch sicher eine neue Versionsnummer vergeben wird.

Wenn das auch bei anderen Projekten eingeführt werden soll, schlage ich vor, die Einstellungen wie oben zu wählen. Theoretisch kann man für unterschiedliche Plattformen (x86, x64) und Konfigurationen (Entwicklung, Test, Produktion) auch unterschiedliche Einstellungen hinterlegen, da sehe ich aber bei uns keinen rechten Sinn.

Eventuell sollten wir uns überlegen das Ganze auch auf die Libraries auszuweiten, insbesondere, wenn wir vielleicht doch irgendwann selbige in NuGet verwalten wollen (http://webentw3/blog/post/2015/10/29/nuget-package-source-fur-mylife-bibliotheken)

Allgemein

Fortuna Scheduler updaten

VWS Scheduler updaten

Probleme mit DevArt

Da wir meistens mit Entities arbeiten in unseren .NET-Anwendungen, kriegen wir hierbei gar nicht so mit, welche Statements eigentlich an die DB abgeschickt werden. Hierfür gibt es von DevArt ein sehr gutes Tool: DBMonitor

Mit dem DBMonitor hat man die Möglichkeit den gesamten Datenbank-Traffic, der innerhalb einer Anwendung läuft, zu beobachten.

Der DBMonitor kann ohne zusätzliche Kosten hier heruntergeladen werden:

https://www.devart.com/dbmonitor/download.html

Wenn das Tool heruntergeladen wurde, einfach lokal auf dem Entwicklungsrechner installieren und starten.

Nun muss noch der Anwendung, die man monitoren möchte, gesagt werden, dass die Daten an den DBMonitor geschickt werden. Dazu ist es erforderlich, dass man zwei Assemblies der Anwendung hinzufügt:

• Devart.Data
• Devart.Data.Oracle

var monti = new OracleMonitor() { IsActive = true };

Erster Schritt

Herunterladen der aktuellen Version vom fincon FTP mittles WinSCP auf den eigenen PC:

Zweiter Schritt

Kopieren des heruntergeladenen Verzeichnisses auf den Zielserver.

Drittee Schritt

Snapshot von Web- und Datenbankserver erstellen

Folgende Schritte:

Alles weitere zur Installation ist auch in update.pdf aufgeführt, welches im Venta-Ordner mitgeliefert wird.

• Tomcat Dienst stoppen
• Venta-Datenbank-Archiv entpacken und Properties anpassen. Für den Showroom-Server

database.url=jdbc:oracle:thin:@10.98.98.164:1521:twdbshow
database.username=C##VENTA_KVM_HK_TRUNK
database.password=venta_kvm

• Datenbank aktualisieren
• Alte webapps löschen, war-Archive ersetzen
• Tomcat startet
• Testen
  

Was ist bereits vorhanden:

TWWEBSHOW

• Microsoft Windows Server 2008R2
• Apache Tomcat (konfiguriert für VENTA)
  
• Microsoft Internet Information Server (konfiguriert für Fortuna)
  
• ...
  

TWDBSHOW

• Oracle DB
• User GUTINGIA, WEBDATA, WEBFRW, WEBSERVICES, VENTA-User
  
• ...

Was ist zu tun:

TWWEBSHOW

• Kopieren der aktuellen Version von VENTA
• Kopieren der aktuellen Version der iPad App
  
• Publilshen der aktuellen Version der Fortuna-Anwendungen
• ...

TWDBSHOW

• Anlegen der Tabellen / Views / Functions etc. für VENTA
• Anlegen der Tabellen / Views / Functions etc. für Fortuna
• Anlegen der Tabellen / Views / Functions etc. für VWS / GPS
• Übernehmen von Basisdaten
• Automatisiertes Befüllen von Anfangsdaten (per Script)
• ...
  

Die Excel-Tabelle enthält eine Übersicht über die Tabellen in WEBDATA, WEBFRW, WEBSERVICES und GUTINGIA. Man sollte diese Übersicht als Basis dafür nehmen, welche Tabellen ob und wie gefüllt werden müssen. Auf Basis dieser Übersicht lässt sich dann ein Script entwickeln.

Server für Tabletworld Showroom:

TWWEBSHOW

• Windows Server 2008R2
• 8GB RAM,  2 CPU
• 10.98.98.163 (intern)
• 81.20.117.20 (extern)
• http://showroom.honorarkonzept.de
  
• Apache Tomcat (Port 80)
  
• Microsoft IIS (Port 88)
  

TWDBSHOW

• Windows Server 2008R2
• 8GB RAM, 2 CPU
• 10.98.98.164 (intern)
  
• Oracle DB
  
• Oracle AppServer
  
• dbshow (VWS/GPS-DB)
• iasshow (Forms)

Voraussichtliche Aufwände: 1x/ Jahr je 3 Tage

Grundeinrichtung ohne Daten:

VENTA -> Christian? Ist das möglich?

VWS / GPS -> Torsten / Klaus / Helge (IAS)

Fortuna -> Christoph

Venta / iPad App (Tablet) -> Christoph

Infrastruktur / BS /WS -> Erico

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.