Windows-Anwendungen automatisieren

Eines der großartigsten Tools unter Mac OSX ist der Automator, der es mir erlaubt, interaktive Arbeiten zu automatisieren. Für ein aktuelles Projekt, bei dem es um die Umwandlung mehrerer tausend Dokumente geht, hätte ich dieses Werkzeug auch sehr gut unter Windows gebrauchen können. Doch auch hier gibt es interessante Werkzeuge um Prozesse zu skripten und immer wieder auszuführen (das bei Bedarf natürlich auch mit wechselnden Parametern).

autoitDas Tool meiner Wahl unter Windows ist derzeit das kostenfreie AutoIT v3. Es ist nicht viel mehr als eine Ausführungsumgebung für Basic-ähnliche Skripte, die Windows-Anwendungen und deren Fenster (bzw Kontrollelemente) analysieren und fernsteuern können. Über diese Funktion hinaus beinhaltet das Werkzeug lediglich einen Compiler für die Skripte sowie Analyse-Werkzeuge für die zu automatisierenden Anwendungen.

AutoIT Skripte erstellen ist Programmierarbeit, nichts „grafisches“, aber es erleichtert die Automatisierung gewaltig. Eine Aufgabe wie „wandeln sie mir diese 10.000 Dokumente in PDFs um“ wird durch AutoIT möglich, sobald ich den Weg finde, ein einzelnes davon per Hand umzuwandeln. Doch auch vereinfachende Oberflächen die ich vor komplexere Installations-Prozesse schalte sind möglich. Will ich zum Beispiel WinZIP in der Firma ausrollen, die Anwender aber nicht durch dessen Installationsprozedur verschrecken, kann ich dem Setup eine AutoIT GUI vorschalten, die alle dafür nötigen Parameter und Schalter in einem einzelnen Dialog zusammenfasst. Auch die vollständige Automatisierung ist möglich.

Ich denke ich werde dieses Tool noch für einige Umstellungs- und Einführungsprozesse gut einsetzen können, es ist auf jeden Fall extrem hilfreich. Ein Blick darauf lohnt sich sicher für jeden Programmierer oder System-Administrator.

Excel, Daten und etwas ODBC Magie

ODBC Verbindungen sind definitiv nichts Neues, aber Überraschungen gibt es scheinbar immer wieder damit. Gerade letzte Woche bin ich im Zusammenhang mit Excel über die ODBC DSN Verwaltung gestolpert, die wie bekannt die 3 DSN Typen User/BenutzerSystem und File/Datei bietet. Im Prinzip sind die Unterschiede ja klar (User ist für den aktuellen Nutzer von Windows sichtbar, System für alle Nutzer des Computers, File ist verteilbar zwischen Systemen), aber die File DSN spielte für Excel in meinem aktuellen Projekt eine mir bisher unbekannte Rolle.

odbcdsn01

Der Hintergrund: Wenn ich in Excel mit MSQuery Daten dynamisch importiere brauche ich dafür eine Datenbankverbindung und diese baue ich über eine der genannten DSN-Typen auf. Nachteil: Verteile ich das Excel Sheet an Kollegen, läuft es nur, wenn diese die passenden DSN Verbindungen im Datenquellen-Verwalter eingerichtet haben.

Doch man kann die DSN auch einbetten so daß keine separate DSN auf dem Computer mehr von Nöten ist. Und genau das passiert automatisch (oder sollte ich sagen automagisch ?) wenn wir für die Verbindung eine File/Datei DSN benutzen. Danach ist das Excel Sheet frei verteilbar… vorausgesetzt natürlich der Zielcomputer hat die passenden Treiber zur Verfügung.

Fazit: Man lernt auch bei alten Techniken nie aus. Aber mal ganz ehrlich: Wo hätte man dieses kleine aber wichtige Detail auch nachlesen sollen?