MESO-WorkerService

.NET Dienst zur Automatisierung von Hintergrundaufgaben zur Mesonic WinLine

---

Maildienst

Der dotnet 9 Dienst versendet automatisch eMails auf Basis eines hierarchischen Regelsystems.

Mandantenübergreifend können Workflows zu Workflowgruppen zusammengefasst werden (z.B. alle Workflows, die eine automatische Benachrichtigung an den Kunden erfordern).

Jede Workflowgruppe kann zusätzlich mittels Filterkriterien flexibel eine Selektion der tatsächlich relevanten Fälle zugewiesen werden, so dass z.B. nur Fälle mit einer bestimmten Eigenschaft ("Mailversand = JA") oder nur für bestimmte Kunden herangezogen werden.

Zusätzliche Einstellungen wie Selektion von Anhängen, die angefügt werden sollen (aus dem ersten, zweiten, letzten oder allen Schritten) - optional auch eingeschränkt auf ein spezifisches Archivformular - die Selektion der Empfänger (Kunde, Ansprechpartner, oder statische Empfänger) sowie einer objektbasierten Gestaltung des Mailtextes aus Kontext-Variablen des Workflows (z.B. Projekt => Bezeichnung, Kunde => FaktStamm => Umsatz) sowie Inhalt von Eigenschaften des Falles (z.B. "Gewählte Ausführung: Rot") runden den Dienst ab.

Das MesoWorker E-Mail-System bietet ein leistungsstarkes, hierarchisches Empfängerverwaltungssystem für die automatische E-Mail-Versendung basierend auf Workflow-Ereignissen. Es unterstützt sowohl klassische boolean-basierte Konfigurationen als auch erweiterte regelbasierte Empfängerverwaltung mit einem dreistufigen Prioritätssystem (Hauptpriorität, Verarbeitungsreihenfolge, Verarbeitung bei Treffer stoppen) für maximale Flexibilität und Kontrolle.

Es können beliebig viele SMTP-Accounts inkl. M365 mit OAuth Authentifizierung angelegt werden.

Eine grafische Administrationsoberfläche inkl. Mail-Journal und Benachrichtigung per eMail, wenn eine geplante Mail nicht versandt werden konnte, steht für Administratoren zur Verfügung.

Workflow-Erzeugung aus Bestelldateizeilen (NEU)

Der MesoWorkerService unterstützt nun auch die automatische Erzeugung von CRM-Fällen auf Basis von Bestelldateizeilen (BestelldateiMitte). Diese Funktion ermöglicht es, für jede passende Belegzeile automatisch einen Workflow-Fall zu erstellen.

Hauptfunktionen:

• ✅ Automatische Workflow-Erzeugung aus Bestelldateizeilen
• ✅ Flexible Filterkriterien für Zeilenselektion
• ✅ Mehrfachverarbeitung wird verhindert (Journal-basiert)
• ✅ Optionale Speicherung der Fall-ID in benutzerdefinierter Spalte
• ✅ Konfigurierbar über bestehende WorkflowSettings
• ✅ Läuft standardmäßig alle 5 Minuten

Identifikation: Jede Zeile wird eindeutig über Kontonummer, Laufnummer und ZeilennummerIntern identifiziert. Bereits verarbeitete Zeilen werden im OrderLineWorkflowJournal protokolliert und bei zukünftigen Durchläufen übersprungen.

Screenshots

---

Systemvoraussetzungen

• Kompatible WinLine Version: ab WinLine Edition 2022

• MDP Runtime Lizenz (vom Mesonic Vertriebspartner bereitzustellen)

• Optional Mesonic Server 64 Bit um Workflow-Schritte anlegen zu lassen

• dotnet 9 Runtime

  Um die Anwendung auszuführen, ist die dotnet 9 Runtime erforderlich. Diese kann von der offiziellen Microsoft Webseite heruntergeladen und dann installiert werden: Download dotnet 9 Runtime

---

Installation

Der MesoWorkerService kann auf zwei verschiedene Arten betrieben werden:

Option 1: On-Premise Windows Dienst

Voraussetzungen:

• Windows Server oder Windows 10/11
• dotnet 9 Runtime
• Direkte Netzwerkverbindung zur WinLine-Datenbank

Installation: Bitte wenden Sie sich für die On-Premise Installation an [email protected]

Vorteile:

• ✅ Direkter Zugriff auf lokale WinLine-Installation
• ✅ Optimale Performance bei lokaler Datenbank
• ✅ Vollständige Kontrolle über das System
• ✅ Einfache Integration in bestehende Windows-Infrastruktur

Nachteile:

• ⚠️ Erfordert Windows Server-Umgebung
• ⚠️ Manuelle Installation und Wartung
• ⚠️ dotnet 9 Runtime muss installiert werden
• ⚠️ Skalierung nur über Hardware-Upgrades

Option 2: Container-Deployment

Verfügbare Container Images:

• Service: ghcr.io/css-edv-support/mesoworkerservice-service
• Blazor UI: ghcr.io/css-edv-support/mesoworkerservice-blazor

Deployment-Optionen:

• Docker Compose
• Portainer Stacks
• Kubernetes
• Docker Swarm

Beispiel Docker Compose Stack:

services:
  mesoworkerservice-ui:
    image: ghcr.io/css-edv-support/mesoworkerservice-blazor:${IMAGETAG}
    pull_policy: always
    container_name: mesoworkerservice-ui
    restart: unless-stopped
    hostname: mesoworkerservice-ui
    ports:
      - "8012:5000"
    environment:
      # Database Connections (REQUIRED)
      - ConnectionStrings__ConnectionString=${CONNECTION_STRING}
      - ConnectionStrings__WinLineSystemDBConnectionString=${WINLINE_SYSTEM_DB_CONNECTION_STRING}

  mesoworkerservice:
    image: ghcr.io/css-edv-support/mesoworkerservice-service:beta
    pull_policy: always
    container_name: mesoworkerservice
    hostname: mesoworkerservice
    ports:
      - "8013:5000"
    environment: 
      # Container Configuration
      - ASPNETCORE_ENVIRONMENT=Production
      - DOTNET_RUNNING_IN_CONTAINER=true
      - ASPNETCORE_URLS=http://+:5000
      - TZ=Europe/Berlin
      - LANG=de_DE.UTF-8
      
      # License Configuration (REQUIRED)
      - LICENSE_CUSTOMER_NR=${LICENSE_CUSTOMER_NR}
      - LICENSE_LICENSE_NR=${LICENSE_LICENSE_NR}
      
      # Database Connections (REQUIRED)
      - ConnectionStrings__ConnectionString=${CONNECTION_STRING}
      - ConnectionStrings__WinLineSystemDBConnectionString=${WINLINE_SYSTEM_DB_CONNECTION_STRING}
      
      # WinLine Configuration (REQUIRED)
      - WinLineServer__Url=${WINLINE_SERVER_URL}
      - WinLineSettings__WinLinePath=${WINLINE_PATH}
      - WinLineSettings__MesospoolServiceUrl=${MESOSPOOL_SERVICE_URL}
      - WinLineSettings__TemplateForWorkflowImport=101
      
      # Session Settings
      - SessionSettings__MinimumSessions=1
      - SessionSettings__DefaultUser=${WINLINE_DEFAULT_USER}
      - SessionSettings__DefaultPassword=${WINLINE_DEFAULT_PASSWORD}
      - SessionSettings__DefaultCompany=${WINLINE_DEFAULT_COMPANY}
      - SessionSettings__ValidationInterval=01:00:00
      
      # Mail Configuration (REQUIRED)
      - MailSettings__EmailFrom=${MAIL_FROM}
      - MailSettings__DisplayName=MesoWorkerService Production
      - MailSettings__SmtpHost=${SMTP_HOST}
      - MailSettings__SmtpPort=${SMTP_PORT}
      - MailSettings__SmtpUser=${SMTP_USER}
      - MailSettings__SmtpPass=${SMTP_PASSWORD}
      - MailSettings__UseSSL=${SMTP_USE_SSL}
      - MailSettings__UseStartTls=${SMTP_USE_STARTTLS}
      - MailSettings__AdminMailRecipients__0=${ADMIN_EMAIL}
      
      # Quartz Job Configuration
      - Quartz__MailWorkerJob__scheduler=0/30 * * * * ?
      - Quartz__MailWorkerJob__enabled=true
      - Quartz__MailWorkerJob__startnow=false
      - Quartz__NoRuleWarningJob__scheduler=0 0 8 * * ?
      - Quartz__NoRuleWarningJob__enabled=true
      - Quartz__NoRuleWarningJob__startnow=false
      - Quartz__quartz.scheduler.instanceName=Meso Worker Services Scheduler (Production)
      
      # Logging Configuration
      - Logging__LogLevel__Default=Information
      - Logging__LogLevel__Microsoft.Hosting.Lifetime=Information
      - Logging__LogLevel__MesoWorkerService.Jobs.MailWorkerJob=Information
      - Logging__LogLevel__Quartz=Information
      - Serilog__MinimumLevel__Default=Information
      - Serilog__MinimumLevel__Override__Microsoft=Information
      - Serilog__MinimumLevel__Override__System=Warning
      - Serilog__MinimumLevel__Override__MesoWorkerService=Information
      - Serilog__MinimumLevel__Override__MesoWorkerService.Jobs=Information
      - Serilog__MinimumLevel__Override__MesoWorkerService.Jobs.MailWorkerJob=Information
      - Serilog__MinimumLevel__Override__Quartz=Information

    restart: unless-stopped
    
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:5000/health"]
      interval: 3600s
      timeout: 10s
      retries: 3
      start_period: 60s
    
    # Optional: Resource limits
    deploy:
      resources:
        limits:
          memory: 1G
          cpus: '1.0'
        reservations:
          memory: 512M
          cpus: '0.5'

Vorteile:

• ✅ Plattformunabhängig (Linux, Windows, macOS)
• ✅ Einfache Skalierung und Deployment
• ✅ Containerisierte Umgebung mit definierten Abhängigkeiten
• ✅ CI/CD-freundlich
• ✅ Keine lokale dotnet-Installation erforderlich
• ✅ Isolation und Ressourcenkontrolle
• ✅ Einfache Updates über Image-Tags

Nachteile:

• ⚠️ Erfordert Container-Runtime (Docker, Podman)
• ⚠️ Zusätzliche Netzwerk-Konfiguration für Datenbankzugriff
• ⚠️ Container-Orchestrierung kann komplex sein
• ⚠️ Debugging kann aufwendiger sein

Empfehlung

• On-Premise: Ideal für kleinere Installationen mit direktem Server-Zugriff
• Container: Empfohlen für moderne Infrastrukturen, Multi-Environment-Deployments und Cloud-Umgebungen

---

Lizenzierung

Die License-Einstellung enthält die Lizenzdaten, die Ihnen von Ihrem Mesonic Partner mitgeteilt wurde.

• CustomerNr: Die Kundennummer, die den Lizenzinhaber eindeutig identifiziert. Dieser Wert ist standardmäßig leer und muss vom Benutzer ausgefüllt werden.
• LicenseNr: Die Lizenznummer für die Softwareaktivierung. Auch dieser Wert ist initial leer und muss vom Benutzer bereitgestellt werden.

"License": 
{
  "CustomerNr": "",
  "LicenseNr": ""
}

---

Grundeinstellungen

Der MesoWorkerService benötigt verschiedene Konfigurationseinstellungen für den ordnungsgemäßen Betrieb. Die Konfiguration erfolgt je nach Installationsmethode unterschiedlich:

Lokale Installation (appsettings.json)

Bei der lokalen Windows-Installation werden alle Einstellungen in der Datei appsettings.json konfiguriert:

{
  "Kestrel": {
    "Endpoints": {
      "Http": { "Url": "http://0.0.0.0:5000" }
    }
  },
  "License": {
    "CustomerNr": "IHRE_KUNDENNUMMER",
    "LicenseNr": "IHRE_LIZENZNUMMER"
  },
  "ConnectionStrings": {
    "ConnectionString": "Data Source=SERVER;Initial Catalog=MesoWorkerDb;Integrated Security=true;TrustServerCertificate=true",
    "WinLineSystemDBConnectionString": "Data Source=SERVER;Initial Catalog=CWLSYSTEM;Integrated Security=true;TrustServerCertificate=true"
  },
  "WinLineSettings": {
    "WinLinePath": "C:\\WinLine\\",
    "MesospoolServiceUrl": "http://winline-server:42024",
    "TemplateForWorkflowImport": 101
  },
  "WinLineServer": {
    "Url": "http://winline-server:8080"
  },
  "SessionSettings": {
    "MinimumSessions": 1,
    "DefaultUser": "mesouser",
    "DefaultPassword": "password",
    "DefaultCompany": "500M",
    "ValidationInterval": "01:00:00"
  },
  "Quartz": {
    "MailWorkerJob": {
      "scheduler": "0/30 * * * * ?",
      "enabled": true,
      "startnow": false
    },
    "NoRuleWarningJob": {
      "scheduler": "0 0 8 * * ?",
      "enabled": true,
      "startnow": false
    }
  }
}

Container Installation (Docker Environment Variables)

Bei der Container-Installation werden die Einstellungen über Umgebungsvariablen gesetzt:

environment:
  # Kestrel Web Server
  - ASPNETCORE_URLS=http://+:5000
  
  # Lizenzierung (ERFORDERLICH)
  - LICENSE_CUSTOMER_NR=IHRE_KUNDENNUMMER
  - LICENSE_LICENSE_NR=IHRE_LIZENZNUMMER
  
  # Datenbankverbindungen (ERFORDERLICH)
  - ConnectionStrings__ConnectionString=Data Source=SERVER;Initial Catalog=MesoWorkerDb;User ID=user;Password=pass;TrustServerCertificate=true
  - ConnectionStrings__WinLineSystemDBConnectionString=Data Source=SERVER;Initial Catalog=CWLSYSTEM;User ID=user;Password=pass;TrustServerCertificate=true
  
  # WinLine Einstellungen
  - WinLineSettings__WinLinePath=/app/winline/
  - WinLineSettings__MesospoolServiceUrl=http://winline-server:42024
  - WinLineSettings__TemplateForWorkflowImport=101
  
  # WinLine Server (nur für Workflow-Schritte erforderlich)
  - WinLineServer__Url=http://winline-server:8080
  
  # Session Einstellungen
  - SessionSettings__MinimumSessions=1
  - SessionSettings__DefaultUser=mesouser
  - SessionSettings__DefaultPassword=password
  - SessionSettings__DefaultCompany=500M
  - SessionSettings__ValidationInterval=01:00:00
  
  # Mail Worker Job
  - Quartz__MailWorkerJob__scheduler=0/30 * * * * ?
  - Quartz__MailWorkerJob__enabled=true
  - Quartz__MailWorkerJob__startnow=false
  
  # No-Rule Warning Job
  - Quartz__NoRuleWarningJob__scheduler=0 0 8 * * ?
  - Quartz__NoRuleWarningJob__enabled=true
  - Quartz__NoRuleWarningJob__startnow=false

Wichtige Konfigurationseinstellungen

🌐 Kestrel (Web Server)

• Zweck: Konfiguration des integrierten Web-Servers
• Standard: Port 5000
• Container: Automatisch über ASPNETCORE_URLS konfiguriert

🔑 License (Lizenzierung)

• CustomerNr: Ihre Kundennummer (erhalten Sie über Ihren Mesonic Partner)
• LicenseNr: Ihre Lizenznummer (erhalten Sie über Ihren Mesonic Partner)
• Wichtig: Ohne gültige Lizenz startet der Service nicht

🗄️ ConnectionStrings (Datenbankverbindungen)

• ConnectionString: Hauptdatenbank für MesoWorkerService-Daten
• WinLineSystemDBConnectionString: Verbindung zur WinLine-Systemdatenbank
• Authentifizierung: Windows-Authentifizierung oder SQL-Authentifizierung möglich

⚙️ WinLineSettings (WinLine Konfiguration)

• WinLinePath: Pfad zur WinLine-Installation
• MesospoolServiceUrl: URL zum Mesospool-Service (für Dokumentenarchivierung)
• TemplateForWorkflowImport: Standard-Vorlage für Workflow-Import

🌐 WinLineServer (WebService)

• Url: URL zum WinLine WebService
• ⚠️ Wichtig: Nur erforderlich wenn Workflow-Schritte geschrieben werden sollen
• Lizenz: Benötigt separaten Mesonic WebService User (zusätzliche Lizenz)

👥 SessionSettings (Sitzungsverwaltung)

• MinimumSessions: Mindestanzahl aktiver WinLine-Sitzungen
• DefaultUser/Password/Company: Standard-Anmeldedaten für WinLine
• ValidationInterval: Intervall für Sitzungsvalidierung

📧 MailWorkerJob (E-Mail Verarbeitung)

• scheduler: Cron-Expression für Ausführungszeitpunkt (z.B. alle 30 Sekunden)
• enabled: Job aktivieren/deaktivieren
• startnow: Sofortiger Start beim Service-Start

🚀 Wichtigste Features im Überblick

• ✅ Automatische E-Mail-Versendung basierend auf WinLine-Workflows
• ✅ Hierarchisches Empfängerverwaltungssystem mit erweiterten Regeln
• ✅ Multi-SMTP-Unterstützung mit M365 OAuth-Authentifizierung
• ✅ Flexible Anhangsverwaltung aus Workflows und Belegen
• ✅ Mandantenfähigkeit für Multi-Company-Umgebungen
• ✅ Grafische Administrationsoberfläche (Blazor UI)
• ✅ Mail-Journal mit umfassender Protokollierung
• ✅ Container-ready für moderne DevOps-Umgebungen
• ✅ Automatische Fehlerbenachrichtigung bei Mail-Problemen
• ✅ Template-basierte E-Mails mit dynamischen Platzhaltern
• ✅ Workflow-Filter für zeitgesteuerte Verarbeitung
• ✅ Health-Checks für Monitoring und Überwachung
• ✅ No-Rule Warning Service für Workflows ohne passende Mail-Regeln

---

Erste Schritte

Nach der Installation müssen einige wichtige Schritte zur Ersteinrichtung durchgeführt werden.

1. Anwendungsdatenbank erstellen

Bei der ersten Ausführung der Anwendung wird automatisch die Anwendungsdatenbank erstellt. Dies erfolgt über das DevExpress XAF Framework:

Automatische Datenbankerstellung:

• Beim ersten Start erkennt die Anwendung eine leere/fehlende Datenbank
• Das XAF Framework erstellt automatisch alle benötigten Tabellen
• Standard-Benutzer und -Rollen werden eingerichtet

Für Container-Deployment:

# Erste Ausführung - Datenbank wird automatisch erstellt
docker-compose up mesoworkerservice

Für lokale Installation:

• Starten Sie die Anwendung über MesoWorker.Win.exe oder MesoWorker.Blazor.Server.exe
• Die Datenbank wird beim ersten Start automatisch initialisiert

2. Benutzer- und Rollenverwaltung

Das System erstellt automatisch Standardbenutzer und -rollen:

Automatisch erstellte Rollen:

• Administrators: Vollzugriff auf alle Funktionen (IsAdministrative = true)
• Default: Standardrolle für normale Benutzer mit eingeschränkten Rechten

Standard-Administrator:

• Benutzername: Admin
• Passwort: Leer (muss bei erster Anmeldung gesetzt werden)
• Rolle: Administrators

Passwort-Verwaltung:

• Standard-Admin-Benutzer hat initial kein Passwort
• Bei der ersten Anmeldung muss ein Passwort vergeben werden
• Passwörter können über die Benutzeroberfläche geändert werden
• Unterstützung für "Passwort bei nächster Anmeldung ändern"-Funktionalität

3. Administrationsoberflächen

Für die Einrichtung stehen zwei Anwendungen zur Verfügung:

Option A: Windows Desktop Client (MesoWorker.Win)

• Verwendung: Lokale Administration und Konfiguration
• Vorteile:
  • ✅ Vollständige XAF Desktop-Funktionalität
  • ✅ Erweiterte Entwicklertools verfügbar
  • ✅ Optimiert für umfangreiche Konfigurationsarbeiten
• Start: MesoWorker.Win.exe
• Verbindung: Direkte Datenbankverbindung über ConnectionString

Option B: Blazor Web Interface (MesoWorker.Blazor.Server)

• Verwendung: Web-basierte Administration
• Vorteile:
  • ✅ Plattformunabhängiger Zugriff über Browser
  • ✅ Ideal für Remote-Administration
  • ✅ Moderne Web-UI
  • ✅ Gleichzeitige Nutzung durch mehrere Administratoren
• URL: http://localhost:5000 (standardmäßig)
• Container: ghcr.io/css-edv-support/mesoworkerservice-blazor

4. E-Mail-Template-Generierung

Das System bietet zwei Methoden zur E-Mail-Inhaltsgenerierung:

Methode 1: Textbausteine mit Objekt-Variablen

Einfache Textbausteine mit dynamischen Platzhaltern für Workflow-Daten:

Verfügbare Platzhalter: Das System stellt alle Eigenschaften und Untereigenschaften des CrmIncidencesUndSchritte-Objekts zur Verfügung. Einige häufig verwendete Beispiele:

{{Kurzbeschreibung}}                    - Workflow-Kurzbeschreibung
{{LangbeschreibungExtern}}              - Externe Langbeschreibung
{{OpNummer}}                            - Operations-/Workflow-Nummer
{{AktuellsterBeleg.DatumFaktura:dd.MM.yyyy}} - Rechnungsdatum des letzten Beleges mit Formatangabe
{{AktuellsterBeleg.Endbetrag:C2}}       - Rechnungsbetrag als Währung
{{Kunde.Kontoname1}}                    - Firmenname 1 des Kunden
{{Projekt.Bezeichnung1}}                - Projektbezeichnung 1
{{DatumSchrittGeschrieben:dd.MM.yyyy}}  - Formatiertes Fallerfassungsdatum
{Property:123}                          - Eigenschaftswert nach ID
{UserColumn:456}                        - Benutzerdefiniertes Feld

Hinweis: Alle Eigenschaften des CrmIncidencesUndSchritte-Objekts können verwendet werden, einschließlich verschachtelter Objekte (z.B. {{Kunde.Adresse.Strasse1}}, {{Projekt.Bezeichnung1}}). Die Formatierung erfolgt über Standard-.NET-Formatstrings (z.B. :dd.MM.yyyy für Datum, :C2 für Währung).

Beispiel-Template:

##Empfaenger##

im Anhang finden Sie Ihre Rechnung {{OpNummer}} vom {{AktuellsterBeleg.DatumFaktura:dd.MM.yyyy}}. Der Gesamtbetrag beträgt {{AktuellsterBeleg.Endbetrag:C2}}.

Melden Sie sich gerne, wenn etwas unklar ist – wir unterstützen Sie schnell und unkompliziert.

{{LangbeschreibungExtern}}

##Anlagen##

Methode 2: DevExpress XAF MailMerge-Vorlagen

Erweiterte Rich-Text-Vorlagen mit vollem Funktionsumfang:

Features:

• ✅ Rich-Text-Formatierung: Schriftarten, Farben, Tabellen
• ✅ Erweiterte Platzhalter: Komplexe Objektnavigation
• ✅ Bedingte Logik: If-Then-Else-Konstrukte
• ✅ Schleifen: Wiederholung von Inhalten
• ✅ Bilder: Eingebettete Grafiken und Logos
• ✅ Tabellen: Dynamische Datenbereichstabellen

Erstellung von MailMerge-Vorlagen:

1. In der Administrationsoberfläche zu "Mail Vorlagen" navigieren
2. Neue RichTextMailMergeData-Vorlage erstellen
3. Rich-Text-Editor öffnen und Inhalte gestalten
4. Mail-Merge-Felder über Ribbon-Menü einfügen
5. Vorlage in den Mail-Einstellungen zuweisen

MailMerge-Beispiel:

«TableStart:Fall»
Projekt: «Projekt.Bezeichnung1»
Status: «Status»
«TableEnd:Fall»

«IF «Status» = 50»
⚠️ DRINGEND: Sofortige Bearbeitung erforderlich
«ENDIF»

5. Konfiguration der Mail-Einstellungen

Nach der Benutzeranmeldung konfigurieren Sie die E-Mail-Verarbeitung:

1. SMTP-Konten einrichten (unter "SMTP Konten")
2. Mail-Einstellungen konfigurieren (siehe Grundeinstellungen)
3. Empfängerregeln definieren (klassisch oder erweitert)
4. Mail-Vorlagen zuweisen (Textbausteine oder MailMerge)
5. Workflow-Filter einrichten (zeitbasiert)

6. Erste Test-E-Mail

Für einen ersten Test:

1. Workflow-Einstellungen für einen Mandanten aktivieren
2. Test-SMTP-Konto konfigurieren
3. Einfache Mail-Einstellungen mit statischen Empfängern
4. Mail-Worker-Job aktivieren
5. Test-Workflow in WinLine auslösen

---

Erweiterte Benutzerdokumentation

Ausführliche Anwenderdokumentation für das erweiterte Empfängerverwaltungssystem

SMTP-Konto-Prioritäten

Das System ermittelt SMTP-Konten in folgender Prioritätsreihenfolge:

Priorität 1: Workflow-spezifisches SMTP-Konto

• Konfiguration: Workflow -> Verwende dieses SMTP Konto
• Verwendung: Wenn ein spezifischer Workflow ein eigenes SMTP-Konto definiert hat
• Anwendungsfall: Spezielle Workflows mit besonderen Absenderanforderungen

Priorität 2: Mandanten-spezifisches SMTP-Konto

• Konfiguration: Mandant -> Verwende dieses SMTP Konto
• Verwendung: Fallback wenn kein Workflow-spezifisches SMTP-Konto definiert ist
• Anwendungsfall: Mandanten-spezifische E-Mail-Absender

Priorität 3: Standard-SMTP-Konto

• Konfiguration: SMTP-Konto mit Standard-Konto = Aktiviert
• Verwendung: Systemweiter Fallback wenn keine spezifischen Konten definiert sind
• Anwendungsfall: Allgemeine E-Mail-Versendung

Wichtig: Es muss mindestens ein Standard-SMTP-Konto im System definiert sein!

Klassische Empfängerkonfiguration

Grundeinstellungen

Name und Status

• Name: Eindeutige Bezeichnung für die E-Mail-Einstellungen
• Aktiv: Bestimmt, ob diese Einstellungen verwendet werden

Standardanrede

• Verwendung: Fallback-Anrede wenn keine spezifische Anrede ermittelt werden kann
• Beispiel: "Sehr geehrte Damen und Herren,"

Empfängertypen (Boolean-Flags)

Kundenempfänger

• An Kunden senden: Primäre Firmen-E-Mail-Adresse des Kunden
• An Kundenkontakt senden: E-Mail-Adresse des zugewiesenen Ansprechpartners
• Sende an Emailadresse für Rechnungsempfang: Spezielle Rechnungs-E-Mail-Adresse
• Rückfallempfänger Kunde: Fallback auf Kunden-E-Mail wenn Kontakt nicht verfügbar
• Rückfallempfänger Standardansprechpartner: Fallback auf Standard-Ansprechpartner

Weitere Empfänger

• An Vertreter senden: E-Mail an zugewiesenen Vertriebsmitarbeiter
• Statische Empfänger: Feste E-Mail-Adressen (kommagetrennt)
• Statische Empfänger BCC: Feste BCC-Empfänger
• Zusatzempfänger aus Personenkonto: E-Mail-Adressen aus benutzerdefinierten Feldern

Beispiel: Klassische Konfiguration

✓ An Kundenkontakt senden
✓ Rückfallempfänger Standardansprechpartner
✓ An Vertreter senden
Statische Empfänger BCC: [email protected]

Ergebnis:
- Primär: Kundenkontakt-E-Mail
- Fallback: Standard-Ansprechpartner
- Zusätzlich: Vertriebsmitarbeiter als normale Empfänger
- Immer: [email protected] als BCC

Erweiterte Empfängerregeln

Aktivierung

• Einstellung: Erweiterte Empfängerregeln verwenden = Aktiviert
• Effekt: Klassische Boolean-Flags werden ignoriert, nur Regeln werden verwendet
• Fallback: Bei leeren Regeln wird das klassische System verwendet
• Attachment-Validierung: Alle Attachment-Validierungsregeln (SkipIfArchiveFormAttatchmentIsMissing, SkipIfVoucherArchiveFormAttatchmentIsMissing, OnlyWithAttachments) funktionieren identisch mit dem klassischen System

Regelkonfiguration

Grundparameter

• Aktiv: Regel ein-/ausschalten
• Hauptpriorität: Prioritätsgruppen (10=Primär, 15=Zusätzlich, 20=Sekundär, etc.)
• Verarbeitungsreihenfolge: Feinabstimmung innerhalb derselben Hauptpriorität
• Verarbeitung bei Treffer stoppen: Stoppt die Regelverarbeitung bei einem Treffer
• Regeltyp: Art der Empfängerquelle
• Zustellungsart: To/CC/BCC
• Separate E-Mails pro Empfänger: Individuelle vs. gruppierte E-Mails

Regeltypen

CustomerContact (Kundenkontakt)

• Quelle: Zugewiesener Ansprechpartner des Kunden
• Fallback: Automatisch zum nächsten verfügbaren Kontakt
• Beispiel: Hauptansprechpartner für Rechnungen

Customer (Kunde)

• Quelle: Primäre E-Mail-Adresse der Firma
• Verwendung: Fallback wenn kein Ansprechpartner verfügbar
• Beispiel: [email protected]

InvoiceEmail (Rechnungs-E-Mail)

• Quelle: Spezielle E-Mail-Adresse für Rechnungsempfang
• Verwendung: Oft in bedingter Logik als Hauptempfänger
• Beispiel: [email protected]

SalesRepresentative (Vertriebsmitarbeiter)

• Quelle: Zugewiesener Vertriebsmitarbeiter
• Verwendung: Meist als CC für Information
• Beispiel: [email protected]

StaticRecipients (Statische Empfänger)

• Quelle: Fest konfigurierte E-Mail-Adressen
• Format: Kommagetrennte Liste
• Beispiel: "[email protected],[email protected]"

CustomFieldRecipients (Benutzerdefinierte Felder)

• Quelle: Beliebiges Feld im Kundenstamm
• Konfiguration: Feldname in Benutzerdefiniertes Feld
• Beispiel: Feld "NotfallKontakt" → "[email protected]"

Individuelle vs. Gruppierte E-Mail-Zustellung

Das erweiterte System bietet Kontrolle darüber, ob Empfänger einzelne personalisierte E-Mails oder eine gruppierte E-Mail erhalten.

Separate E-Mails pro Empfänger

Zweck: Steuert die Art der E-Mail-Zustellung pro Regel

Aktiviert: Jeder Empfänger erhält eine separate E-Mail

• ✅ Personalisierte ##Empfaenger##-Anrede für jeden Empfänger
• ✅ Individuelle Betreffzeile und Inhalte möglich
• ✅ Datenschutz: Empfänger sehen sich gegenseitig nicht
• ⚠️ Mehr E-Mails versendet

Deaktiviert: Alle Empfänger der Regel in einer E-Mail

• ✅ Weniger E-Mails versendet
• ✅ Effizientere Verarbeitung
• ⚠️ Allgemeine ##Empfaenger##-Anrede ("Sehr geehrte Damen und Herren")
• ⚠️ Empfänger können sich gegenseitig sehen (je nach Zustellungsart)

Empfohlene Verwendung

• Aktiviert: CustomerContact, Customer, FallbackContact (personalisierte Kommunikation)
• Deaktiviert: SalesRepresentative als CC, interne Teams
• Aktiviert: StaticRecipients wenn externe Partner/Kunden
• Deaktiviert: StaticRecipients wenn interne Verteiler

Bedingte Zustellungslogik

Funktionsweise

Regeln können ihre Zustellungsart dynamisch ändern basierend auf anderen gefundenen Empfängern:

• Bedingung: Empfängertyp vorhanden: Welcher Regeltyp geprüft wird
• Alternative Zustellungsart: Zustellungsart wenn Bedingung erfüllt ist

Beispiel: InvoiceEmail-Priorität

Regel 1: InvoiceEmail, Priorität 1, To
Regel 2: CustomerContact, Priorität 1, To
         Bedingung: InvoiceEmail vorhanden → CC

Ergebnis wenn InvoiceEmail existiert:
- InvoiceEmail: To (Hauptempfänger)
- CustomerContact: CC (Information)

Ergebnis wenn InvoiceEmail NICHT existiert:
- CustomerContact: To (Hauptempfänger)

Praktische Regel-Beispiele

Beispiel 1: Standardkonfiguration mit Hierarchie

Regel 1: CustomerContact, Hauptpriorität 10, Verarbeitungsreihenfolge 100, To
Regel 2: Customer, Hauptpriorität 20, Verarbeitungsreihenfolge 100, To
Regel 3: StaticRecipients ("[email protected]"), Hauptpriorität 30, Verarbeitungsreihenfolge 100, To

Verarbeitung:
1. Hauptpriorität 10: Versuche Kundenkontakt
2. Falls gefunden: Fertig
3. Falls nicht: Hauptpriorität 20: Versuche Kunde
4. Falls nicht: Hauptpriorität 30: [email protected]

Beispiel 2: Compliance mit verschiedenen Prioritäten

Regel 1: CustomerContact, Hauptpriorität 10, Verarbeitungsreihenfolge 100, To
Regel 2: SalesRepresentative, Hauptpriorität 10, Verarbeitungsreihenfolge 200, CC
Regel 3: StaticRecipients ("[email protected]"), Hauptpriorität 10, Verarbeitungsreihenfolge 300, BCC

Ergebnis (alle Hauptpriorität 10 werden verarbeitet):
- Kunde erhält E-Mail als Hauptempfänger
- Vertrieb erhält Kopie (falls Kundenkontakt gefunden)
- Compliance erhält Blindkopie (falls Kundenkontakt gefunden)

Anhänge und Vorlagen

E-Mail-Vorlage

• Rich-Text-Editor: Formatierte E-Mail-Inhalte
• Platzhalter: Dynamische Inhalte aus Workflow-Daten
• Textbaustein-Überschreibung: Alternative Textbausteinnummer

Anhangskonfiguration

Grundoptionen

• Anhänge einschließen: Aktiviert Anhangsfunktionalität
• Nur mit Anhängen: E-Mail wird nur gesendet wenn Anhänge vorhanden
• Überspringe bei fehlendem Archivformular-Anhang: Stoppt E-Mail-Versand wenn spezifische Archivformular-Anhänge fehlen
• Überspringe bei fehlendem Beleg-Anhang: Stoppt E-Mail-Versand wenn Beleg-Anhänge fehlen

Attachment-Validierung und Skip-Logik

Das System bietet erweiterte Validierungsoptionen, die den E-Mail-Versand stoppen können:

SkipIfArchiveFormAttatchmentIsMissing

• Zweck: Verhindert E-Mail-Versand wenn erforderliche Archivformular-Anhänge fehlen
• Funktionsweise: Prüft die FilterArchiveFormIds und stoppt den Versand wenn keine Uploads mit den entsprechenden Formulartypen vorhanden sind
• Anwendungsfall: Sicherstellung dass wichtige Dokumente (z.B. Rechnungen, Verträge) vor dem E-Mail-Versand vorhanden sind

SkipIfVoucherArchiveFormAttatchmentIsMissing

• Zweck: Verhindert E-Mail-Versand wenn Beleg-Anhänge fehlen
• Funktionsweise: Prüft ob Anhänge aus dem verknüpften Beleg geladen werden konnten
• Anwendungsfall: Sicherstellung dass Belege (Rechnungen, Lieferscheine) vor dem Versand vollständig sind

OnlyWithAttachments

• Zweck: Verhindert E-Mail-Versand wenn überhaupt keine Anhänge vorhanden sind
• Funktionsweise: Prüft die Gesamtzahl aller Anhänge (Uploads + Beleg-Anhänge + Auto-Archiv)
• Anwendungsfall: E-Mails die ausschließlich zur Übermittlung von Dokumenten dienen

Workflow-Filter

Zeitbasierte Filter

Zeitraum-Filter (Since)

• Aktiv: Workflowabruf innerhalb Zeitraum aktiv
• Zeitraum: Abrufen von Workflows seit
• Beispiel: Nur Workflows der letzten 24 Stunden
• Format: TimeSpan (z.B. "1.00:00:00" für 1 Tag)

Datum-Filter (After)

• Aktiv: Workflowabruf ab Datum aktiv
• Datum: Workflowabruf ab Datum
• Beispiel: Alle Workflows seit 01.01.2024
• Format: DateTime

Logischer Zeitbereich-Filter (Time Range) ⭐ NEU

• Aktiv: Filtert Workflows nach logischem Zeitbereich - aktiv
• Zeitbereich: Workflows nach logischem Zeitbereich
• Verfügbare Zeitbereiche:
  • Dieses Jahr: Seit 1. Januar des aktuellen Jahres (00:00 Uhr)
  • Dieser Monat: Seit 1. Tag des aktuellen Monats (00:00 Uhr)
  • Dieses Quartal: Seit 1. Tag des aktuellen Quartals (Q1-Q4)
  • Diese Woche: Seit Montag der aktuellen Woche (00:00 Uhr)
  • Heute: Seit Beginn des heutigen Tags (00:00 Uhr)
  • Seit gestern: Seit Beginn des gestrigen Tags (00:00 Uhr)
• Vorteil: Keine Wartung fester Datumswerte erforderlich - das System berechnet den Zeitraum automatisch
• Anwendungsfall: Regelmäßige Verarbeitung ohne manuelle Anpassung der Filter

Filter-Priorität

Die Filter werden in folgender Reihenfolge angewendet (erster aktiver Filter wird verwendet):

1. Zeitraum-Filter (Since): Relative Zeitspanne (z.B. letzte 24 Stunden)
2. Datum-Filter (After): Festes Startdatum
3. Logischer Zeitbereich-Filter (Time Range): Automatisch berechneter Zeitraum
4. Fallback: 1. Januar 1970 (alle Workflows)

Hinweis: Es kann immer nur einer der drei Filter gleichzeitig aktiv sein. Aktivieren Sie nur den Filter, der Ihren Anforderungen entspricht.

Best Practices

Regeldesign

1. Hauptpriorität logisch strukturieren:
   • 10 = Primäre Empfänger
   • 15 = Zusätzliche/parallele Empfänger
   • 20 = Fallback-Empfänger
   • 30+ = Ultimate Fallback
2. Verarbeitungsreihenfolge sinnvoll nutzen: Innerhalb jeder Hauptpriorität logische Reihenfolge
3. Verarbeitung bei Treffer stoppen sparsam einsetzen: Nur bei exklusiven Empfängern
4. Bedingte Logik gezielt nutzen: Nur wenn wirklich benötigt
5. Klare Bemerkungen: Jede Regel mit Hauptpriorität und Zweck dokumentieren
6. Separate E-Mails gezielt nutzen: Nur für personalisierte Inhalte

Wartung

1. Regelmäßige Überprüfung: Mail-Journal auf Fehler prüfen
2. Empfängerdaten aktuell halten: Kundenstamm-Pflege
3. SMTP-Konten überwachen: Verbindungen und Authentifizierung
4. Test-E-Mails: Regelmäßige Funktionstests

---

No-Rule Warning Service

Der No-Rule Warning Service überwacht Workflows mit aktiven Regeln und benachrichtigt Administratoren automatisch, wenn für CRM-Fälle keine E-Mails versendet wurden, obwohl der Workflow aktivierte Regeln hat. Dies hilft, Konfigurationsfehler oder fehlende Stammdaten frühzeitig zu erkennen.

Übersicht

Funktionsweise

Der Service prüft periodisch (standardmäßig täglich um 8:00 Uhr):

1. Workflows mit aktivierten Mail-Einstellungen: Nur Workflows mit aktiven Regeln werden überwacht
2. CRM-Fälle im konfigurierten Zeitraum: Prüfung der Fälle im definierten Lookback-Zeitraum
3. E-Mail-Versand-Status: Vergleich mit tatsächlich versendeten E-Mails

Wenn Fälle ohne E-Mail-Versand gefunden werden, erhalten die konfigurierten Empfänger eine Warnungs-E-Mail mit einer tabellarischen Auflistung aller betroffenen Fälle.

Warnungs-E-Mail Inhalt

Die automatisch generierte Warnungs-E-Mail enthält:

• Anzahl der betroffenen CRM-Fälle
• Mandanteninformation
• Überprüfungszeitraum
• Detaillierte Tabelle mit:
  • Fall-ID
  • Schritt-Nummer
  • Workflow-Nummer und -Bezeichnung
  • Kurzbeschreibung
  • Erstellungsdatum

Konfiguration

Admin-Oberfläche Einstellungen

In der Administrationsoberfläche kann für jeden Mandanten eine NoRuleWarningSettings-Konfiguration erstellt werden:

Einstellungsparameter:

Parameter	Typ	Beschreibung	Beispiel
Name	String	Bezeichnung für diese Warnungs-Einstellung	"Workflow-Überwachung Mandant 500M"
Enabled	Boolean	Aktiviert/deaktiviert die Warnungs-E-Mails	true
Company	Auswahl	Zugeordneter Mandant	500M
LookbackPeriod	TimeSpan	Zeitraum, wie weit zurück überprüft werden soll	1.00:00:00 (24 Stunden)
GracePeriod	TimeSpan	Mindestalterzeitspanne für Workflows vor Überprüfung	00:15:00 (15 Minuten)
WarningRecipients	String	Kommagetrennte Liste der Empfänger	[email protected],[email protected]
UseSmtpAccount	Auswahl	Optionales SMTP-Konto für Warnungs-E-Mails	Standard-SMTP oder spezifisches Konto

Grace Period - Vermeidung von Race Conditions

Die Grace Period (Schonfrist) ist ein wichtiges Feature zur Vermeidung von Fehlalarmen:

Problem: Der MailWorkerJob läuft kontinuierlich (standardmäßig alle 30 Sekunden) und verarbeitet neue Workflows. Ohne Grace Period könnte der NoRuleWarningJob einen Workflow als "keine Mail versendet" markieren, während er gerade vom MailWorkerJob bearbeitet wird.

Lösung: Die GracePeriod-Einstellung stellt sicher, dass nur Workflows überprüft werden, die älter als die Grace Period sind.

Empfehlung:

• Setzen Sie die Grace Period auf mindestens das 2-3-fache des MailWorkerJob-Intervalls
• Beispiel: Bei MailWorkerJob-Intervall von 30 Sekunden → Grace Period von 15-20 Minuten
• Bei häufigeren Intervallen entsprechend anpassen

Beispiel: Mit einer Grace Period von 15 Minuten werden nur Workflows überprüft, die vor mindestens 15 Minuten erstellt wurden. Workflows der letzten 15 Minuten werden ignoriert.

Job-Konfiguration (appsettings.json)

{
  "Quartz": {
    "NoRuleWarningJob": {
      "scheduler": "0 0 8 * * ?",
      "enabled": true,
      "startnow": false
    }
  }
}

Scheduler-Parameter (Cron-Expression):

• 0 0 8 * * ? - Täglich um 8:00 Uhr (Standard)
• 0 0 */4 * * ? - Alle 4 Stunden
• 0 0 9-17 * * MON-FRI - Stündlich von 9-17 Uhr, Montag bis Freitag

Weitere Parameter:

• enabled: Aktiviert/deaktiviert den Job global
• startnow: Startet den Job sofort beim Service-Start (für Tests)

Container-Konfiguration

environment:
  # No-Rule Warning Job
  - Quartz__NoRuleWarningJob__scheduler=0 0 8 * * ?
  - Quartz__NoRuleWarningJob__enabled=true
  - Quartz__NoRuleWarningJob__startnow=false

Anwendungsfälle

Der No-Rule Warning Service hilft bei der Erkennung verschiedener Probleme:

1. Fehlende Stammdaten

Problem: Für einen Kunden ist keine E-Mail-Adresse hinterlegt.
Ergebnis: Keine Mail wird versendet.
Lösung: Warnung identifiziert fehlende Stammdaten → Daten können nachgepflegt werden.

2. Fehlkonfiguration

Problem: Mail-Einstellungen sind nicht korrekt konfiguriert (z.B. falsche Empfänger-Regeln).
Ergebnis: Keine Mail wird versendet.
Lösung: Warnung zeigt Konfigurationsprobleme → Einstellungen können korrigiert werden.

3. Zu restriktive Filter-Kriterien

Problem: Filter-Kriterien selektieren keine Fälle.
Ergebnis: Keine Mail wird versendet.
Lösung: Warnung macht auf Filter-Probleme aufmerksam → Filter können angepasst werden.

Duplikatsverhinderung

Der Service protokolliert versendete Warnungen in der NoRuleWarningJournal-Tabelle:

• Jeder gewarnter Fall wird mit Fall-ID, Schritt-Nummer und Workflow-Nummer gespeichert
• Verhindert mehrfache Warnungen für denselben Fall
• Protokollierung erfolgt nur bei erfolgreichem E-Mail-Versand
• Ermöglicht Nachverfolgung der Warnungshistorie

Best Practices

1. Zeitraum (LookbackPeriod):

   • Wählen Sie einen angemessenen Zeitraum (z.B. 24 Stunden)
   • Zu kurze Zeiträume: Wichtige Fälle könnten übersehen werden
   • Zu lange Zeiträume: Zu viele Warnungen für bereits bekannte Probleme

2. Grace Period:

   • Setzen Sie auf mindestens das 2-3-fache des MailWorkerJob-Intervalls
   • Standard-Empfehlung: 15-20 Minuten
   • Bei sehr frequenten MailWorkerJob-Ausführungen: 20-30 Minuten
   • Verhindert Fehlalarme für gerade in Bearbeitung befindliche Workflows

3. Empfänger (WarningRecipients):

   • Konfigurieren Sie administrative E-Mail-Adressen
   • Stellen Sie sicher, dass E-Mails regelmäßig geprüft werden
   • Verwenden Sie Verteiler für Team-Benachrichtigungen

4. Ausführungshäufigkeit (Scheduler):

   • Täglich um 8:00 Uhr (Standard) für normale Überwachung
   • Mehrmals täglich für kritische Workflows
   • Passen Sie die Cron-Expression an Ihre Anforderungen an

5. SMTP-Konto:

   • Verwenden Sie ein dediziertes SMTP-Konto für Warnungen
   • Stellt separate Nachverfolgung und Zustellung sicher
   • Fallback auf Standard-SMTP-Konto funktioniert automatisch

Troubleshooting

Problem: Warnungen werden nicht versendet

Mögliche Ursachen:

• ✗ Enabled ist auf false gesetzt
• ✗ Keine gültigen Empfänger konfiguriert (WarningRecipients leer oder ungültig)
• ✗ SMTP-Konto nicht verfügbar oder falsch konfiguriert
• ✗ Job ist in appsettings.json deaktiviert (enabled: false)
• ✗ Cron-Expression ist fehlerhaft

Lösungsschritte:

1. Überprüfen Sie die Logs nach Fehler-Meldungen
2. Prüfen Sie die Konfiguration in der Administrationsoberfläche
3. Testen Sie das SMTP-Konto mit einer Test-Mail
4. Validieren Sie die Cron-Expression mit einem Online-Tool

Problem: Zu viele Warnungen

Mögliche Ursachen:

• ✗ LookbackPeriod ist zu groß (z.B. 7 Tage statt 1 Tag)
• ✗ GracePeriod ist zu klein (z.B. 2 Minuten statt 15 Minuten)
• ✗ Viele Workflows haben tatsächliche Konfigurationsprobleme
• ✗ Job läuft zu häufig (mehrmals stündlich)

Lösungsschritte:

1. Reduzieren Sie den LookbackPeriod (z.B. auf 24 Stunden)
2. Erhöhen Sie die GracePeriod (z.B. auf 20-30 Minuten)
3. Beheben Sie die zugrunde liegenden Konfigurationsprobleme
4. Passen Sie die Job-Häufigkeit an (z.B. nur 1x täglich)

Problem: Duplikate werden versendet

Mögliche Ursachen:

• ✗ E-Mail-Versand schlägt fehl (keine Journal-Protokollierung)
• ✗ Datenbank-Commit schlägt fehl
• ✗ Transaktion wird zurückgerollt

Lösungsschritte:

1. Überprüfen Sie die Logs auf Fehler beim E-Mail-Versand
2. Prüfen Sie die Datenbank-Verbindung
3. Kontrollieren Sie die NoRuleWarningJournal-Tabelle auf Einträge
4. Testen Sie mit einem einzelnen Fall

Problem: Grace Period funktioniert nicht

Mögliche Ursachen:

• ✗ Grace Period ist auf 0 oder sehr klein gesetzt
• ✗ MailWorkerJob läuft sehr selten
• ✗ Systemzeit ist nicht synchronisiert

Lösungsschritte:

1. Setzen Sie Grace Period auf mindestens 15 Minuten
2. Überprüfen Sie die MailWorkerJob-Konfiguration
3. Validieren Sie die Systemzeit auf allen Servern
4. Prüfen Sie die SQL-Query in den Logs

Migration und Einrichtung

Bei der ersten Verwendung des No-Rule Warning Service:

1. Automatische Datenbankerstellung: Die Tabellen NoRuleWarningSettings und NoRuleWarningJournal werden automatisch erstellt
2. Konfiguration erstellen: In der Admin-Oberfläche neue NoRuleWarningSettings für gewünschte Mandanten anlegen
3. Job aktivieren: In appsettings.json oder Container-Umgebungsvariablen aktivieren
4. Erste Ausführung: Optional startnow: true setzen für sofortigen Test
5. Monitoring: Logs überprüfen nach erfolgreicher Ausführung

Hinweis: Es sind keine manuellen Migrationsschritte erforderlich. Das DevExpress XAF Framework erstellt alle benötigten Tabellen automatisch.

---

Versionshistorie

Version 2.1 (November 2025)

💎 Added

• Automatische EML-Neuerzeugung für Entwürfe im Postausgang: Wenn E-Mails als Entwurf im Postausgang gespeichert werden, werden Änderungen an email-relevanten Feldern automatisch erkannt und die EML-Datei wird neu generiert

  • Automatische Regenerierung bei Änderungen an Empfänger, Betreff, Text, CC und BCC
  • Erhaltung der bestehenden Anhänge beim Regenerieren
  • Funktioniert nur bei E-Mails mit aktiviertem Draft-Status
  • Nahtlose Integration in die Detailansicht von QueuedMail

• Logische Zeitbereiche für Workflow-Filterung: Alternative zu festen Datumswerten in Mail-Einstellungen

  • Unterstützte Zeitbereiche: Dieses Jahr, Dieser Monat, Dieses Quartal, Diese Woche, Heute, Seit gestern
  • Automatische Berechnung des Startdatums basierend auf dem gewählten Zeitbereich
  • Kompatibel mit bestehenden Filter-Optionen (Since, After)
  • Vereinfachte Konfiguration ohne Wartung fester Datumswerte

• No-Rule Warning Service: Neuer automatischer Überwachungsdienst für Workflows mit aktiven Regeln aber ohne E-Mail-Versand

  • Mandantenspezifische Konfiguration mit flexiblen Zeiträumen
  • Grace Period zur Vermeidung von Race Conditions mit MailWorkerJob
  • Automatische Duplikatsverhinderung durch Journal-Protokollierung
  • HTML-formatierte Warnungs-E-Mails mit detaillierter Fall-Auflistung
  • Konfigurierbare Empfänger und optionale SMTP-Konten
  • Quartz-basierte Job-Planung mit Cron-Expressions
  • Umfassende Fehlerbehandlung und Logging

Version 2.0 (Oktober 2025)

💎 Added

• Erweiterte Empfängerregeln mit Prioritätssystem
• Bedingte Zustellungslogik
• Individuelle E-Mail-Zustellung pro Empfänger
• M365 OAuth-Authentifizierung für SMTP
• Container-Support mit Docker Images
• Health-Checks für Monitoring

🏗️ Refactoring

• Migration auf dotnet 9
• Modernisierung der Codebase
• Verbesserung der Administrationsoberfläche

🐛 Fixed

• Diverse Bugfixes im Mail-Versand
• Verbesserungen der Anhangsverwaltung

---

Downloads

ℹ️ Download dieser Dokumentation als pdf

• Blazor Server (Win x64)
• Worker Service (Win x64)
• MesoWorker.Win (Desktop, Win x64)
• SHA256SUMS

---

Support und Kontakt

Bei Fragen oder Problemen wenden Sie sich an das CSS EDV Support Team:

• E-Mail: [email protected]
• Verbesserungsvorschläge: [email protected]

---

CSS EDV Support GmbH
Ihr Partner für professionelle EDV-Lösungen

Website: https://css-edv-support.de
Dokumentation erstellt von CSS EDV Support Tobias Forbrich e.K. - November 2025

Version: 2.1
Erstellt: 2024
Aktualisiert: November 2025