Fortuna Entwickler Blog

·         BCAS Tschechien

o   Quellcode komplette in Azure DevOps unter Fortuna.Service

o   Datenbankscripte unter U:\Gesamt\Entwicklung\Scripte\DBWEB1\Webdata

o   Kontakte:

§  Vaclav Stumbauer vaclav.stumbauer@bcas.cz

§  Vojtěch Ouška vojtech.ouska@bcas.cz

o   Script BCAS Transfer löschen.sql habe ich genutzt, wenn BCAS unvollständige Daten übermittelt hat (im Anhang)

·         Tablet World

o   Zugänge

§  Anmeldung über Remote Desktop an TWWEB, TWWEBTEST, TWDB, TWDBTEST jeweils mit eigenem Windows Account

§  Datenbank Server: TWDB, TWDBTEST

§  Datenbank User

·         C##VENTA_KVM_HK_TRUNK / venta_kvm, siehe Anhang 1

·         sys / $ventaDB!12c, siehe Anhang 2

§  Skripte zu Tickets wurden jeweils beim Ticket in JIRA abgelegt

§  Anmelden als Admin mit hk-admin / Cyriupkmr2

o   keine offenen Tickets im JIRA / Andreas organisiert da alles

o   Vorgehensweise Update / Insert Tarif im Vergleichsrechner

§  siehe z.B. HKAW-2107, HKAW-2115

§  Update immer erst in Testumgebung, dann Test durch Andreas

§  Nach Freigabe Script in Produktion ausführen, dann Test durch Andreas

o   Update der App

§  Vorgehensweise

·         Fincon aktualisiert den Webserver sowohl in der Test- als auch der Produktionsumgebung.

·         Aktualisierte App wird auf FTP Server zur Verfügung gestellt

o   Zugang über WinSCP (von Erico zur Verfügung gestellt)

o   Zugangsdaten siehe Anhang 3, Password cKvyH5LA74tG8. Ansonsten kann hier vermutlich auch fincon ein neues Password vergeben

o   Aktuellsten Ordner per FTP laden (hierin findet man entweder nur die Apps (Test, Produktion) oder auch weitere Ordner mit der aktuellen Venta-Version (die man aber nicht weiter beachtet, siehe oben)

o   Apps (sowohl Test als auch Produktion, Endung .ipa,) nach \\web3\webhome\Fortuna\app kopieren

o   Anpassen der Downloadseite der App

§  \\twwebtest\ApacheTomcat\webapps\app\index.html

§  \\twweb\C\Program Files\Apache Software Foundation\Tomcat 7.0\webapps\app\index.html

§  Ich habe die index.html immer kopiert in indexXXX.html (XXX = Versionsnummer) und dort die Änderungen eingefügt

§  Anpassen der Versionnummer (Zeile 32)

§  Changelog (nach Zeile 37) Text wird von Andreas zur Verfügung gestellt

§  In der Testumgebung ersetzt die neue Version dann gleich index.html; in Produktion erst nach Freigabe durch Andreas. Hierzu dann index.html und indexXXX.html öffnen und den neuen Inhalt nach index.html kopieren, Speichern.

§  VORSICHT! Index.html unterscheidet sich zwischen Test- und Produktionsumgebung (Downloadlinks). Man muss das also auf beiden Umgebungen getrennt machen

·         Fundsaccess Service

o   Individueller Zugang ist direkt im Code hinterlegt: $/Fortuna/_dev/logic/Fortuna.Fundsaccess/SessionID.CS hier dann die Konstante _private_key). Wenn ich mich recht erinnere, Wurde dieser Key mir vor langer Zeit telefonisch von Fundsaccess mitgeteilt.

o   (Veraltete, aber für den aktuellen Stand gültige) Spezifikationen liegen noch unter $/Fortuna/Releases/Branch_Vor_Umstellung/Lib/Fortuna.Fundsaccess in AzureDevOps. Zuletzt hatte Michael mit FundsAccess Kontakt; es gibt wohl keine neuere Spezifikation; hier muss sich aber demnächst etwas ändern (fehlende TER-Daten)

·         Entwickler Blog auf WEBENTW4

o   Zugänge zur Webanwendung: http://webentw4.gutingia.local/Blog/Account/login.aspx Admin / logo1234 Mit dem Admin kann man alle User verwalten

o   Blogengine arbeitet ohne Datenbank; alles wird auf dem Webserver in Dateien abgelegt.

o   \\webentw4\webhome\blog

·         myLife Invest

o   Keine offene Punkte

o   Anlegen oder Bearbeiten von Strategien

§  Dokumentation als Word und PDF habe ich hier angehängt

§  Das erste Erstellen eines Strategieverwalters geschieht in Zusammenarbeit von Simone, Peter und Klaus; den ‚Prozess‘ kennt Peter am Besten

·         Sonstige Themen

o   VMs, bei denen das Patchen übernommen wurde: TWWEB, TWWEBTES, TWDB, TWDBTEST (wurde zuletzt teilweise auch von sycor übernommen)

o   „Interessante“ Emails, die noch weitergeleitet werden sollten

§  Feature/Bug Anfragen habe ich als Workitems in AzureDevOps abgelegt

o   Azure

§  UPLA going Azure

·         Ruht seit letztem Jahr. Helge ist hier der am ehesten Ansprechpartner

·         Die Planung aus UPLA ON Docker.xslx (im Anhanh) ist vollkommen obsolet

·         Script zum Erstellen eines Windows 2016 Nano Images in NanoServer.txt

BCAS Transfer löschen.sql (3,79 kb)

NanoServer.txt (386,00 bytes)

Strategieverwaltung.docx (733,64 kb)

Strategieverwaltung.pdf (1,17 mb)

UPLA ON Docker.xlsx (14,08 kb)

Übergabe.docx (16,17 kb)

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:

Mithilfe von WebDeploy und Scripts ist das Deployment der Webanwendungen, Services und Dokumente mit nur wenigen Handgriffen zu erledigen:

• Abrufen der aktuellen Quellen über den Source Control Explorer von Visual Studio 2017
  Benötigt werden Fortuna\_dev und Common\Vorlagen
• (optional) Builden der Solutions Fortuna.Web und Fortuna.Service um vorab schon mal zu prüfen, ob alle Projekte korrekt gebaut werden können. Nur dann macht das Deployment Sinn.
• Start des Developer Command Prompts für Visual Studio 2017
  Dies ist notwendig, damit das in den Scripts verwendete MSBuild korrekt arbeiten kann.
• Wechseln in das lokale Fortuna\_dev Verzeichnis (z.B. C.\vso\Fortuna\_dev)
  Von hier aus sind alle notwendigen Quell- und Scriptdateien erreichbar
• Deployment von Fortuna.Web:
  
  Nach drücken von ENTER wird man noch zur Eingabe von Benutzername und Passwort aufgefordert. Hier ist der serviceadmin mit dem bekannten Passwort zu verwenden. Dieser Benutzer ist auf dem Testserver zum Deployment via WebDeploy berechtigt.
  Daraufhin werden alle relevanten Projekte neu kompiliert und auf den Testserver gestellt. Im CommandPrompt-Fenster werden alle Nachrichten für diese Vorgänge ausgegeben. Da dies doch ziemlich viel ist und ziemlich schnell geht, wird zudem ein Log mit den Nachrichten unter C:\Temp\[Projektname].log geschrieben.
• Beim Deployment von Fortuna.Services wird analog zu Fortuna.Web verfahren:
  
  Auch hier ist dann wieder Benutzername/Passwort anzugeben und die Logdateien werden nach C:\Temp\ geschrieben.
• Zuletzt sind noch die Dokumente und Vorlagen in aktueller Version auf den Server zu bringen. Auch hierfür gibt es ein Script; der Ablauf ist hier aber deutlich einfacher, da hier nur Dateien kopiert werden müssen:
  
  Der Vorgang dauert recht lange und man kann das kopieren jeder einzelnen Datei gut verfolgen. Daher wird auch keine Logdatei geschrieben.

Axa zu PASS

Die Dateilieferung besteht i. d. R. ZIP-/ Dat-Dateien inkl. ein Lieferschein (Exceldatei)!

Auslöser: E-Mail von i. d. R. Taplick (Ergo-Vorsorge) „Dateilieferung an PASS“  (siehe Anhang AXA Migration.msg)

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

Verbindungs-/Zugangsdaten:

WinSCP ergänzende Einstellungen:

Herunterladen der Dateien auf das lokales Verzeichnis

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

Kopieren der Dateien inkl. Lieferschein 

unter \\web3\Dokumente\system\import\Akazie\Axa\Lieferung_YYYYMMD\ ZIPfiles (z. B. \\web3\Dokumente\system\import\Akazie\Axa\ Lieferung_20180919\ ZIPfiles) 

Kopieren der Dateien ohne Lieferschein 

unter \\web3\Dokumente\system\export\PASS\Archiv

Anpassung des Lieferscheins:

PASS zu AXA

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)

Um Änderungen, welche im Produktivstand durchgeführt werden (müssen), in die aktuelle Entwicklungsversion zu übernehmen, geht man wie folgt vor (am Beispiel einer web.config):

• Änderungen in der Release-Version durchführen
• Testen der Änderungen
• Eventuell publish in Testumgebung und erneutes Testen
• Publishen in Produktionsumgebung

Anschließend müssen die Änderungen auch in den aktuellen _dev-Zweig aufgenommen werden. Hierzu führt man die Änderungen nicht nochmals durch, sondern macht einen Merge:

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

Benötigt wird:

• Visual Studio 2017: https://www.visualstudio.com/de/thank-you-downloading-visual-studio/?sku=Community&rel=15
• VS2017 Developer Command Prompt: Kommt mit Visual Studio 2017
• nuget.exe: VSO -> Fortuna -> Build and Release -> Packages -> Connect to feed -> Get the Tools
• Personal Access Token (PAT): Siehe Anhang

nuget.exe idealerweise im gleichen Verzeichnis wie Visual Studio (C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\) speichern.

Vorgehensweise um die neue Package Source in Visual Studio hinzuzufügen:

• Visual Studio 2017 schliessen
• VS2017 Developer Command Prompt öffnen
• nuget.exe sources Add -Name "Fortuna" -Source "https://mylife-leben.pkgs.visualstudio.com/_packaging/Fortuna/nuget/v3/index.json" -username VSTS -password (PAT)
• (PAT) ist hierbei durch das Personal Access Token aus dem Anhang zu ersetzen

Das Personal Access Token ist 1 Jahr gültig. Danach muss ein neues erstellt werden und der Vorgang ggf. wiederholt werden.

Vorgehensweise um eine neues Package in die Package Source zu bringen:

• VS2017 Developer Command Prompt öffnen
• in das Package-Verzeichnis navigieren (vso/Common/External/Eigene nuGet Packages)
• nuget.exe push -Source "Fortuna" -ApiKey VSTS packagename.nupkg

Links:

• https://docs.microsoft.com/de-de/vsts/accounts/use-personal-access-tokens-to-authenticate
• https://docs.microsoft.com/de-de/vsts/package/nuget/nuget-exe
• https://docs.microsoft.com/de-de/vsts/package/nuget/consume#windows-add-the-feed-to-your-nuget-configuration

Wie im Workshop von Herrn Schmidt kurz gezeigt, habe ich nun mal eine packages.config exemplarisch angepasst:

Die eckige öffnende Klamme und die Runde schließende Klammer bedeuten ein 'Inclusive Min' respektive 'Exclusive Max'. Demnach ist eine Version von wenigstens 6.01 erlaubt und eine Version unterhalb (nicht einschliesslich) 10.0.2.

In Visual Studio stellt sich das dann so dar:

nuGet packages

Es ist nicht sinnvoll, nuGet Packages in unsere Release-Zyklen einzubinden; dies widerspricht dem eigentlichen Sinn der nuGet Packages.

In einem Package sollen Funktionen umgesetzt werden, welche Produktunabhängig sind und allgemein Verwendet werden können, z.B. Mailversand, PDF Erstellung und Ähnliches

Empfehlung Herr Schmidt: 

• Rückführung Produktspezifischer Packages in die jeweiligen Solutions

• Neustrukturierung der Ordnerstruktur für Solutions

• Alle Solutions in einem Ordner

• Alle Webanwendungen in einem eigenen Ordner in einem Unterordner (‚web‘)

• Alle Bibliotheken in einem eigenen Ordner in einigen wenigen Unterordnern (‚logic‘, ‚data‘)

• Damit dann Kombination aus nuGet und Bibliotheken

• Builds für Projekte automatisieren

• Builds für nuGet Packages erstellen Symbole für Debugging, welche vorgehalten werden

Branches, Merges, etc.

Der aktuelle Stand kann so weiter geführt werden.

Das Verschieben von Branches kann möglicherweise in Zukunft wieder verfügbar sein. Derzeit gibt es keine andere Möglichkeit, als es so zu tun, wie wir es derzeit machen.

Herr Schmitt hat uns Alternativen zur derzeitigen Vorgehensweise aufgezeigt. Diese wären gggf. Zu diskutieren.

Event- und Fehlerlogging

Das Logging, so wie wir es derzeit betreiben ist weder performant noch sonst zu empfehlen.

Empfehlung Herr Schmidt: 

• Einsatz von NLog

• Umstellung aller Anwendungen auf einen Asynchronen Logger

• Logging gegen einen WebService (in Azure)

• Archivierung von Logs in Azure Storage

• Ggf. Automatisiertes Herunterladen aus Azure Storage

Benutzer, Security

Eine eigene Benutzerverwaltung ist aufwendig, fehleranfällig und nur schwer abzusichern.

Empfehlung Herr Schmidt:

• Microsoft Azure Active Directory

• Vergleichsweise einfache Integration in bestehende Webanwendungen

• Keine Verwendung mit VENTA möglich

• Derzeit nur für Versicherungskunden

• Integration in Azure Service Management, um APIs abzusichern (myPension z.B.)

Swagger

Der Einsatz von Swagger, so wie es derzeit bei uns verwendet wird, entspricht vorgesehenen Verwendung. Keine ToDos.

Oracle / Entities

Oracle ODP.NET ist nicht empfehlenswert, weil vergleichsweise langsam und schlechte Tool-Unterstützung.

DevArt for Oracle ist das Tool der Wahl für den Zugriff auf Oracle Datenbanken via Entities. Der fehlende Service seitens DevArt muss selbst geleistet werden: Neue Versionen als nuGet zur Verfügung stellen, eigene Versionshistorie vorhalten.

Sonstiges

Herr Schmitt empfiehlt die Anbindung unseres AD an Azure AD.

C# 7.0/8.0 bringt wenig sinnvolles Neues, was wir nicht schon kennen

ASP.NET Core bringt für uns keine Vorteile, solange wir nicht mit Docker und/oder anderen Betriebssystemen arbeiten.

Angular.js (oder React.js oder Vue) sind Frameworks, die interessant sein können und gesondert betrachtet werden müssten.

TypeScript als Ersatz für JavaScript ist empfehlenswert.

JavaScript in Webseiten selbst sollte überhaupt nicht benutzt werden, sondern immer in eigene Dateien (dann auch als TypeScript) ausgelagert werden.

Fotos