rLOOKvUPs alias rvsLOOKUP
Verfasst: 30.06.2010 21:58
So, dann will ich hier auch mal ein Projekt vorstellen. Es ist nicht das Spiel wegen dessen ich mich schon hier an das Forum gewand habe, sondern ein kleines Tool, welches ich zum betrieblichen Einsatz geschrieben habe. Doch damit man verstehen kann, welchen Sinn dieses Tool erfüllt, muss ich am Anfang ein klein wenig ausholen.
Motivation:
========
Für den Datenaustausch mit einem Kunden verwenden wir das hauptsächlich in der Automobilindustrie verbreitete RVS-System (wer sich dafür interessiert, findet nähere Informationen bei T-Systems, aber ich kann mir nicht vorstellen, dass sich jemand freiwillig mit diesem Teil abgeben will
). Dabei handelt es sich um ein System, welches auf sicherem Wege einen Datenaustausch zwischen zwei Endstationen ermöglicht. Leider ist das Programm selbst nicht sehr komfortabel. Die Übertragung erfolgt im Prinzip im Push-Verfahren, d. h. wenn unser Kunden auf "Senden" klickt, wird die Datei ohne unser Zutun an uns übertragen und in einem bestimmten Verzeichnis abgelegt. Zwar schreibt rvs dieses "Ereignis" sehr schön in ein Protokoll, aber zumindest die von uns eingesetzte Version biete keinerlei weiter Benachrichtigungsmöglichkeiten oder ähnliches. Das bedeutet, wir bekommen von der Dateiübertragung überhaupt nur etwas mit, wenn jemand manuell ständig das Protokoll und/oder das Verzeichnis in dem die vollständig übertragene Datei abgelegt wird, überprüft. Vor etwa zwei Wochen kam es für nus nun zum Gau indem alle 4 Mitarbeiter unserer IT-Abteilung, welche mit der Aufgabe betraut wurden durch Urlaub und Krankheit nicht anwesend waren. Da ausserhalb der IT-Abteilung keiner was vom Fehlen dieser Mitarbeiter wusst und umgekehrt sonst keinem unserer ITler das rvs-Problem bekannt war, wurde über 3 Tage hinweg der Eingang nicht geprüft. Dort "stapelten" sich in der folge mehre Dateien und somit auch Arbeit auf dessen Erledigung unser Kunde wartet....
Nun, ich glaube, an dieser Stelle muss ich nicht weiter ausführen, warum das für uns fast ein GAU geworden wäre.
Da dies auch in direkte Weise meine Arbeit/Position/Abteilung betroffen hat, habe ich mich dazu entschlossen, ein kleines Programm zu schreiben, welches nur eine Aufgabe hat, nämlich ein vorgegebenes Verzeichnis zu überprüfen, ob eine neue Datei hinzugefügt und/oder eine vorhanden Datei aktualisiert wurde. Tritt dieser Fall ein, soll eine Benachrichtigungs-Email versendet werden. Im Vorfeld wurde das natürlich mit unserer IT-Abteilung abgeklärt (naja, ich hatte eher den Eindruck, dass ihnen fast alles recht ist, mit denen sie selbst keine Arbeit haben....) und letzte Woche in meinen Pausenzeiten das Programm in PB geschrieben und getestet. Seit Montag dieser Woche läuft nun so etwas wie die Pilotphase in unserem Betrieb
Auch wenn mir auf Anhieb einige Sachen einfallen würden, welche man noch verbessern könnte, stelle ich das Programm an dieser Setelle einfach einmal vor. Da es für meine bzw. unsere betrieblichen Zwecke scheinbar ausreichend ist, mache ich etwaige Verbesserungen jedoch hauptsächlich vom Feedback abhängig, das ich dazu bekomme, denn worum sollte ich ein Programm weiterentwickeln, an dem keiner Interesse hat?
Hier mal ein Screenshot und den Download:
Download:
http://ul.to/y5e0o4
Beschreibung / Anleitung:
===================
Nach dem Start der Exe erscheint ein Icon im Systray. Durch ein Doppelklick darauf (Contex-Menü ist (noch?) keine vorhanden) öffnet man das Hauptfenster mit den Einstellmöglichkeiten (siehe Screenshot).
Von oben nach unten kurz erklärt:
Zuerst erfolgt die Info, ob der "Service" läuft. "Service" ist an dieser stelle etwas viel gesagt, denn die Programmierung eines echten Services habe ich mir zwar in PBOSL angesehn, muss jedoch zugeben, dass dies derzeit meinen Kenntnisstand übersteigt. Daher habe ich das ganze als normales Programm läuft. Es wurde lediglich die Überprüfungs-Methode in einen eigenen Thread ausgelagert. Konnte dieser Thread erstellt werden, geht mein Programm davon aus, dass der "Service" läuft. Mit dem Button ganz rechts kann der "Service" angehalten (Thread wird mit KillThread zerstört) oder neu gestartet (Thread wird neu erstellt) werden. Darunter befindet sich die Möglichkeit den Pfad, welcher überprüft werden soll zu ändern. Mitdem Button ganz rechts in dieser Zeile öffnet sich ein PathRequester, welcher einem das Leben etwas leichter machen soll. Evtl. vorhandene Unterverzeichnisse des hier angegebenen Pfades, werden rekursiv durchlaufen und somit ebenfalls berücksichtigt. Getestet habe ich das jedoch nur mit einem einzigen Unterverzeichnis, da dieser Anwendungsfall für unseren Betrieb nicht relevant ist. Bei Intervall kann eingestellt werden, wie viele Sekunden zwischen den einzelnen Checks des Verzeichnisses gewartet werden soll. Wie gesagt, es geht hier um die Wartezeit zwischen den Checks, d. h. wenn ihr hier 300 (Sekunden = 5 Minuten) eingibt bedeutet das nicht, dass alle 5 Minuten geprüft wird, sondern nach dem Ende eines Checks 5 Minuten gewartet wird, bis der neue startet (ein einfaches Delay). Da die Benachrichtigung per Email erfolgen soll, sind in den verbleibenden 5 Zeilen die Daten für den Email-Account einzutragen. Email ist hierbei die Email-Adresse, welche die Benachrichtigung erhalten soll. Zu beachten ist hierbei, dass diese Adresse für die Email sowohl Empfänger wie auch Absender darstellt. Im Weiteren sind ganz normal der Server, der User und das Passwort einzugeben, mit dem die Mail versendet werden soll. Da die Empfangs-Email-Adresse auch gleichzeit der Absender ist, ist hier Vorsicht geboten, wenn mit den Daten eines anderen Accounts die Mails verschickt werden. Ich kann nicht garantieren, dass das immer funktioniert. Generell habe ich das Versenden der Mail ausschliesslich mit dem SMTP-Auth-Verfahren implementiert. D. h. es wird weder Pop-befor-SMTP unterstützt noch ein senden ganz ohne Authentifizierung. Mit dem Button "Testmail senden" wird eine einfache Test-Mail verschickt, welche sicherstellen soll, dass die gemachten Angaben korrekt sind. Zum Versenden der Testmail werden die Einstellungen berücksichtigt, welche in den jeweiligen StringGadgets sichtbar sind. Der Button "Aktualisieren" sorgt dafür, dass die StringGadgets mit den aktuellen Daten gefüllt werden, mit denen das Programm im Hintergrund arbeitet. Der Button "Übernehmen" sorgt dafür, dass die hier gemachten Einstellungen vom Programm ab dem nächsten Check übernommen werden. Solange dieser Button nicht gedrückt wird, haben die im Fenster vorgenommenen Einstellung für die Überprüfung im Hintergrund eigentlich keine Bedeutung.
Wird das Programmfenster minimiert, wird es komplett geschlossen und muss erst wieder durch einen Klick auf das TrayIcon geöffnet werden. Mit beenden kann man das Programm komplett beenden, dies gilt auch für den "Service", der im Hintergrund läuft.
Ja, wie gesagt, das Programm ist im Prinzip genau auf die ganz oben geschilderten Einsatzbedingungen zugeschnitten. Änderungen sind für den betrieblichen Einsatz zumindest nach derzeitigem Stand nicht notwendig, daher mache ich wie gesagt, die Weiterentwicklung des Programms in erster Linie vom hier gegebenen Feedback abhängig (wird sowas überhaupt gebraucht?).
So, damit bin ich dann am Ende dieser doch sehr ausführllichen Vorstellung. Nur ein Wort zur Namensgebung möchte ich noch los werden:
Ich habe das Programm wegen oder viel mehr für den betrieblichen Einsatz mit rvs geschrieben. Daher läuft die Version, welche unser Admin für mich laufen lässt unter dem namen "rvsLOOKUP". Da rvs jedoch ein geschützer Markenname von T-Systems ist, habe ich mich dazu entschlossen die hier veröffentlichte Version in rLOOKvUPs umzutaufen. Mehr steck nicht hinter diesem eigenwilligen Namen.
Motivation:
========
Für den Datenaustausch mit einem Kunden verwenden wir das hauptsächlich in der Automobilindustrie verbreitete RVS-System (wer sich dafür interessiert, findet nähere Informationen bei T-Systems, aber ich kann mir nicht vorstellen, dass sich jemand freiwillig mit diesem Teil abgeben will
). Dabei handelt es sich um ein System, welches auf sicherem Wege einen Datenaustausch zwischen zwei Endstationen ermöglicht. Leider ist das Programm selbst nicht sehr komfortabel. Die Übertragung erfolgt im Prinzip im Push-Verfahren, d. h. wenn unser Kunden auf "Senden" klickt, wird die Datei ohne unser Zutun an uns übertragen und in einem bestimmten Verzeichnis abgelegt. Zwar schreibt rvs dieses "Ereignis" sehr schön in ein Protokoll, aber zumindest die von uns eingesetzte Version biete keinerlei weiter Benachrichtigungsmöglichkeiten oder ähnliches. Das bedeutet, wir bekommen von der Dateiübertragung überhaupt nur etwas mit, wenn jemand manuell ständig das Protokoll und/oder das Verzeichnis in dem die vollständig übertragene Datei abgelegt wird, überprüft. Vor etwa zwei Wochen kam es für nus nun zum Gau indem alle 4 Mitarbeiter unserer IT-Abteilung, welche mit der Aufgabe betraut wurden durch Urlaub und Krankheit nicht anwesend waren. Da ausserhalb der IT-Abteilung keiner was vom Fehlen dieser Mitarbeiter wusst und umgekehrt sonst keinem unserer ITler das rvs-Problem bekannt war, wurde über 3 Tage hinweg der Eingang nicht geprüft. Dort "stapelten" sich in der folge mehre Dateien und somit auch Arbeit auf dessen Erledigung unser Kunde wartet....Nun, ich glaube, an dieser Stelle muss ich nicht weiter ausführen, warum das für uns fast ein GAU geworden wäre.
Da dies auch in direkte Weise meine Arbeit/Position/Abteilung betroffen hat, habe ich mich dazu entschlossen, ein kleines Programm zu schreiben, welches nur eine Aufgabe hat, nämlich ein vorgegebenes Verzeichnis zu überprüfen, ob eine neue Datei hinzugefügt und/oder eine vorhanden Datei aktualisiert wurde. Tritt dieser Fall ein, soll eine Benachrichtigungs-Email versendet werden. Im Vorfeld wurde das natürlich mit unserer IT-Abteilung abgeklärt (naja, ich hatte eher den Eindruck, dass ihnen fast alles recht ist, mit denen sie selbst keine Arbeit haben....) und letzte Woche in meinen Pausenzeiten das Programm in PB geschrieben und getestet. Seit Montag dieser Woche läuft nun so etwas wie die Pilotphase in unserem Betrieb
Auch wenn mir auf Anhieb einige Sachen einfallen würden, welche man noch verbessern könnte, stelle ich das Programm an dieser Setelle einfach einmal vor. Da es für meine bzw. unsere betrieblichen Zwecke scheinbar ausreichend ist, mache ich etwaige Verbesserungen jedoch hauptsächlich vom Feedback abhängig, das ich dazu bekomme, denn worum sollte ich ein Programm weiterentwickeln, an dem keiner Interesse hat?
Hier mal ein Screenshot und den Download:
Download:
http://ul.to/y5e0o4
Beschreibung / Anleitung:
===================
Nach dem Start der Exe erscheint ein Icon im Systray. Durch ein Doppelklick darauf (Contex-Menü ist (noch?) keine vorhanden) öffnet man das Hauptfenster mit den Einstellmöglichkeiten (siehe Screenshot).
Von oben nach unten kurz erklärt:
Zuerst erfolgt die Info, ob der "Service" läuft. "Service" ist an dieser stelle etwas viel gesagt, denn die Programmierung eines echten Services habe ich mir zwar in PBOSL angesehn, muss jedoch zugeben, dass dies derzeit meinen Kenntnisstand übersteigt. Daher habe ich das ganze als normales Programm läuft. Es wurde lediglich die Überprüfungs-Methode in einen eigenen Thread ausgelagert. Konnte dieser Thread erstellt werden, geht mein Programm davon aus, dass der "Service" läuft. Mit dem Button ganz rechts kann der "Service" angehalten (Thread wird mit KillThread zerstört) oder neu gestartet (Thread wird neu erstellt) werden. Darunter befindet sich die Möglichkeit den Pfad, welcher überprüft werden soll zu ändern. Mitdem Button ganz rechts in dieser Zeile öffnet sich ein PathRequester, welcher einem das Leben etwas leichter machen soll. Evtl. vorhandene Unterverzeichnisse des hier angegebenen Pfades, werden rekursiv durchlaufen und somit ebenfalls berücksichtigt. Getestet habe ich das jedoch nur mit einem einzigen Unterverzeichnis, da dieser Anwendungsfall für unseren Betrieb nicht relevant ist. Bei Intervall kann eingestellt werden, wie viele Sekunden zwischen den einzelnen Checks des Verzeichnisses gewartet werden soll. Wie gesagt, es geht hier um die Wartezeit zwischen den Checks, d. h. wenn ihr hier 300 (Sekunden = 5 Minuten) eingibt bedeutet das nicht, dass alle 5 Minuten geprüft wird, sondern nach dem Ende eines Checks 5 Minuten gewartet wird, bis der neue startet (ein einfaches Delay). Da die Benachrichtigung per Email erfolgen soll, sind in den verbleibenden 5 Zeilen die Daten für den Email-Account einzutragen. Email ist hierbei die Email-Adresse, welche die Benachrichtigung erhalten soll. Zu beachten ist hierbei, dass diese Adresse für die Email sowohl Empfänger wie auch Absender darstellt. Im Weiteren sind ganz normal der Server, der User und das Passwort einzugeben, mit dem die Mail versendet werden soll. Da die Empfangs-Email-Adresse auch gleichzeit der Absender ist, ist hier Vorsicht geboten, wenn mit den Daten eines anderen Accounts die Mails verschickt werden. Ich kann nicht garantieren, dass das immer funktioniert. Generell habe ich das Versenden der Mail ausschliesslich mit dem SMTP-Auth-Verfahren implementiert. D. h. es wird weder Pop-befor-SMTP unterstützt noch ein senden ganz ohne Authentifizierung. Mit dem Button "Testmail senden" wird eine einfache Test-Mail verschickt, welche sicherstellen soll, dass die gemachten Angaben korrekt sind. Zum Versenden der Testmail werden die Einstellungen berücksichtigt, welche in den jeweiligen StringGadgets sichtbar sind. Der Button "Aktualisieren" sorgt dafür, dass die StringGadgets mit den aktuellen Daten gefüllt werden, mit denen das Programm im Hintergrund arbeitet. Der Button "Übernehmen" sorgt dafür, dass die hier gemachten Einstellungen vom Programm ab dem nächsten Check übernommen werden. Solange dieser Button nicht gedrückt wird, haben die im Fenster vorgenommenen Einstellung für die Überprüfung im Hintergrund eigentlich keine Bedeutung.
Wird das Programmfenster minimiert, wird es komplett geschlossen und muss erst wieder durch einen Klick auf das TrayIcon geöffnet werden. Mit beenden kann man das Programm komplett beenden, dies gilt auch für den "Service", der im Hintergrund läuft.
Ja, wie gesagt, das Programm ist im Prinzip genau auf die ganz oben geschilderten Einsatzbedingungen zugeschnitten. Änderungen sind für den betrieblichen Einsatz zumindest nach derzeitigem Stand nicht notwendig, daher mache ich wie gesagt, die Weiterentwicklung des Programms in erster Linie vom hier gegebenen Feedback abhängig (wird sowas überhaupt gebraucht?).
So, damit bin ich dann am Ende dieser doch sehr ausführllichen Vorstellung. Nur ein Wort zur Namensgebung möchte ich noch los werden:
Ich habe das Programm wegen oder viel mehr für den betrieblichen Einsatz mit rvs geschrieben. Daher läuft die Version, welche unser Admin für mich laufen lässt unter dem namen "rvsLOOKUP". Da rvs jedoch ein geschützer Markenname von T-Systems ist, habe ich mich dazu entschlossen die hier veröffentlichte Version in rLOOKvUPs umzutaufen. Mehr steck nicht hinter diesem eigenwilligen Namen.