Framework

ERR_MAIL_TO

BY KARL HAJEK

Überprüfen des Systemparamters ERR_MAIL_TO auf dessen Funktionsfähigkeit und das Vermeiden von Folgefehlern aufgrund von nicht übermittelten Systembenachrichtigungen

Gestern war ich mit einem Thema konfrontiert, das bei der Initialeinrichtung von MD-Premium.NET immer wieder vergessen oder nur teilweise abgehandelt wird und zu Systemfehlern führen kann, die leicht zu vermeiden wären. Ich spreche vom Systemparameter ERR_MAIL_TO, der die Mailadresse für Benachrichtigungen bei Systemfehlern festlegt und derzeit beim Exchangeserver- und Spoolerdienst als auch bei der Datensicherung Anwendung findet. Wie ich aus leidvoller Erfahrung mitteilen kann, nützt die schönste Definition nichts, wenn die Benachrichtigung nicht zugestellt werden kann. Deshalb ist es unbedingt notwendig die Funktionalität nach Einrichtung des Systemparameters mittels eines Scripts zu testen. 

declare
 thePwd syuser.Passwort%TYPE;
begin
 select Passwort into thePwd from syuser where Klient_ID='1' and User_ID='MBAB4';
 Md_Klient.SetNr ('1', 'MBAB4', thePwd);
 
 MD_Message.LogError('ERR_MAIL_TO', 'Dies ist ein Testtext');
end;

Ersetzen sie die Ownerangabe MBAB4 und die Klienten-ID '1' durch die richtigen Werte und führen Sie anschließend das Script aus. Falls dieses durchläuft und die im Systemparamter angegebene Mailadresse erhält die Benachrichtigung, zählen Sie zu einem glücklichen Anwender, der dieses Thema abschließen und sich anderen Dingen widmen kann. Wird die Nachricht jedoch "verschluckt" und kommt nie an, ist eine Liste von möglichen Ursachen abzuhandeln, um den Grund lokalisieren zu können.

Die häufigsten Ursachen für eine fehlerhafte Nachrichtenübermittlung:

  • Falsche SMTP_Serverangabe im Systemparameter MDMAIL_SMTPSVRINFO
  • Der MD-Premium.NET User (Systemdaten/Klienten/Benutzer), mit dessen User-ID die fehlerverursachende Prozedur ausgeführt wird, hat keine gültige Emailadresse hinterlegt
  • Der Mailserver akzeptiert keinen Zugriff vom Datenbankserver aus
  • Der Datenbankserver kann nicht auf den Mailserver zugreifen, da kein ACL-Eintrag für SMTP existiert
  • Ein Zertifikat für die Verbinung zum Mailserver fehlt im Wallet
  • Nach der Änderung von Systemparametern wurde der Exchange- oder Spoolerdienst nicht neu gestartet

Auswirkungen

Eine nicht fuktionierenden Benachrichtigung kann z.B. in Verbindung mit dem Exchangeserver-Dienst recht dramatische Folgen nach sich ziehen. Dieser Dienst kümmert sich grundsätzlich um den Abgleich von Ordnern wie Kalender, Mail, Aufgaben oder Personen mit den dazugehörigen Tabellen in MD-Premium.NET. Nach erfolgreicher Synchronisierung eines Ordners wird ein Token des Exchangeservers zurückgeliefert, der bei der nächsten Synchronisierung übergeben wird und garantiert, dass nur die nach Synchronisierungsstart vorgenommen Änderungen von einem erneuten Synchronisierungsprozess erfasst werden.

Aber was hat das dann mit unserer Thematik zu tun?
Die Antwort dafür ist leicht gefunden wenn man sich den Ablauf der Synchronisierung der Daten zwischen Exchangeserver und MD-Premium.NET ansieht. Tritt nämlich bei einem Ordner ein Fehler auf, wird der Vorgang abgebrochen, eine Benachrichtigung an die durch ERR_MAIL_TO definierten Adressen gesendet und das nächste Mal mit dem identen Token aufgesetzt. Wenn aber in der Zwischenzeit die Anzahl der zu synchronisierenden Einträge durch z.B. neu erstellte Kalendertermine zunimmt und der Fehler erst am Ende des Synchronisierungsvorganges auftritt, wird die Anzahl der abzuarbeitenden Einträge immer größer, das Datenbanksystem im Laufe der Zeit dadurch immer mehr ausgelastet und die Prozessdauer der Synchronisierung generell sukzessive erhöht.