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:
Parameter | Beschreibung |
| styleKz | Die ID des E-Mail Styles / HTML Templates, welches für die Mail verwendet werden soll. |
| ausfuehrung | Das Datum und die Uhrzeit, wann diese Mail frühestens verschickt werden soll |
| absender | Die E-Mail-Adresse des Absenders, z.B. "info@mylife-leben.de |
| empfaenger | Die E-Mail-Adresse(n) des / der Empfänger durch Semikolon getrennt, z.B. "test@mylife-leben.de;bcc@mylife-leben.de" |
| cc | Die E-Mail-Adresse(n) des / der CC-Empfänger durch Semikolon getrennt. Kann auch NULL sein. |
| bcc | Die E-Mail-Adresse(n) des / der BCC-Empfänger durch Semikolon getrennt. Kann auch NULL sein. |
| betreff | Der Betreff dieser E-Mail |
Weitere
Parameter | Beschreibung |
| anhaenge | Liste mit Anhängen, die mitgeschickt werden sollen. Kann auch NULL sein. |
| variablenTexte | Liste mit Texten, um die Platzhalter im verwendeten Style zu befüllen. Kann auch NULL sein, wenn es keine Platzhalter gibt, die befüllt werden müssen. |
| objRefs | Liste mit OBJ-Nummern, die mit der Mail verknüpft werden sollen, z.B. Versicherungsverträge oder Honorarverträge. Kann auch NULL |
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)