MSXFAQ RealTracking -Import Prozess
Damit Realtracking entsprechende Daten auswerten kann, müssen andere Prozesse natürlich dafür sorgen, das die Daten auch in der SQL-Datenbank landen. Hierfür gibt es zwei mögliche Wege.
- Geplanter Import
Ein regelmäßig gestartetes Skript Importiert vorgegebene Quelldaten. Das kann interessant sein, wenn keine direkte Verbindung zwischen Quelle und Ziel möglich ist oder die Datenübertragung Offline (z.B. nachts) erfolgen soll. Nachteil ist hier die Verzögerung für die Analyse - Import per "TAIL"
Um mehr "Echtzeit" in die Umgebung zu bringen, könnte eine Art "TAIL" die Dateien oder Quellen permanent überwachen und die Daten entsprechend in das Ziel übertragen.
Zudem ist nicht nur Exchange eine mögliche Datenquelle. Denkbar wäre alles, was Daten liefert, so dass mit der MessageID und dem Empfänger eine Zuordnung erfolgen kann und die weiteren Daten einen Nutzwert über die Station, die Quelle bzw. Ziel und Zeit liefert
- Ex2000/2003 Tracking Logs
- Ex2007 Tracking Logs
- SendMail / Postfix Transport Logs
- NoSpamProxy Logs
- andere Quellen
Multi-Tier-Modell
Der einfachste Ansatz wäre natürlich nun ein VBScript o.ä., welches die Daten auf dem Quellserver ausliest und direkt in die SQL-Datenbank pumpt. Damit müsste aber auch die Logik mehrfach verteilt werden, um auf allen Servern die Daten der verschiedenen Quellen aufzubereiten. Zudem sind je nach Verbindung und Firewall bestimmte Ports geöffnet werden oder Protokolle gar nicht nutzbar., Ich denke kaum, dass ein Programm auf UNIX per ODBC auf eine SQL-Datenbank zugreifen kann.
Daher habe ich mich für einen Webservice als Zwischenmodul entschieden, welches per SOAP over HTTP/S) die Daten annimmt und auch die Verarbeitung und Aufbereitung bezüglich SQL übernimmt. Seit dem .NET 3.0 Framework gibt es ja auch mit xxx eine Implementierung einer Message Queue, so dass selbst bei Unterbrechungen die Daten nicht verloren gehen.
Dieses Modul analysiert die Daten und speichert Sie in der SQL-Datenbank ab
