ReportWeb - Evolution
Software ist nie fertig und genauso geht es mir mit ReportWeb. Es gab einige Vorläufer, von denen ich ganz kurz erzählen m�chte.
Die Version 1-3 wurden nie von mir veröffentlicht.
Version | Funktionsweise |
---|---|
1 |
Dies war mein erster Start und ist letztlich nicht viel mehr als das Beispiel auf ReportWeb. Ein paar PowerShell-Skripte die direkt HTML-Dateien geschrieben haben |
2 |
Zuerst hat mir natürlich die Formatierung gefehlt. Also habe ich mit dem kostenfreien Sharepoint Designer 2007, mit dem ich auch die komplette MSXFAQ verwalte, eine kleine HTML-Seite gebaut, die ich als Textbausteine abgelegt habe. Die "einfachen Skripte" konnten dann einfach den Teil "vor" und "nach" der Tabelle einlesen und mit den eigenen Ausgaben zusammenführen. Damit war schon mal Farbe und Format einfacher möglich. Aber der ganze Code zum Zusammensetzen musste in jedem Skript eingebaut und gepflegt werden. |
3 |
Sie können sich sicher denken, dass die nächste Evolution dann darin bestand, dass ein Hauptprogramm aus einer Konfigurationsdatei ausgelesen hat, welche Report-Module zu starten sind. Die Rückgabe dieser Module über die Pipeline wurde dann in ein Template eingelesen und herausgeschrieben. Hier habe ich umfangreich mit verschiedenen Optionen experimentiert, den "Einfüge-Bereich" zu finden. Schließlich wollte ich keinen HTML-Editor instanziieren um "nur" etwas Text zu ersetzen. Da kam mir die Logik der Frontpage DWT-Vorlagen grade zurecht. Auch waren die Module ursprünglich sogar PS1M-Dateien, was ich aber wieder verworfen habe. für die Steuerung der Reports gab es eine ganz einfache CSV-Datei:
reportname,reportps1,ausgabehtml Auf dieser Version hat sich dann alles weiter entwickelt und erweitert z.B.
|
Version 4 |
Immer mehr Reports sind langsam an die Grenzen der sequentiellen Verarbeitung gekommen. Insofern war der große Schritt bei Version 4 die parallele Ausführung von Reports durch einen "Controller", der eine einstellbare Zahl von "Worker"-Prozessen startet. Der "Start-Process" war so eigentlich noch einfach aber wichtig war mich auch die Synchronisation der Aufrufe, z.B. dass nicht zu viele Worker parallel laufen und nur ein Controller gestartet werden kann. Auch die "Trigger"-Funktion ist dazu gekommen, um per Webbrowser optional einen Report zu forcieren. Aber auch hier wieder nur im Rahmen der Belastung. Um verschiedene Umgebungen parallel zu betreiben und die variablen Teile von den statischen teilen zu separieren, habe ich z.B. das Verzeichnis "CONFIG" erzeugt und die CSV-Konfiguration in eine XML-Datei überführt. Auch können nun Reports einfacher "disabled" oder "hidden" gekennzeichnet werden. Diverses Finetuning bei den Vorlagen und dem Layout wurde addieren, z.B. der direkte Link auf ERROR-Seite und die Option den Report mit einem Mausklick anzufordern. |
Plan 5 |
|
Zwischendurch gab es natürlich einige Irrwege, auf die ich aber nicht weiter eingehen will. Aber auch in Zukunft plane ich weitere Entwicklungen.
Ideen für Morgen
Das ReportWeb mit statischen Seiten, die per Taskplaner im Hintergrund geplant werden, ist natürlich nur eine erste Version, die aber durch ihre Einfachheit vielleicht gerade häufiger eingesetzt wird. Speziell in größeren Umgebungen können Berichte und Reports nicht nur lange zu Auswertung dauern sondern auch die HTML-Tabellen werden mehr und mehr "unlesbar", wenn Sie aus 500,1000 oder mehr Zeilen bestehen. Da helfen auch keine jQuery-Tricks weiter, die die Tabellen clientseitig sortieren, Filtern etc. Ich behelfe mich z.B. damit, die Reports nicht mehr als HTML-Datei aufzubereiten sondern eine CSV als Download dem Anwender anzubieten.
Aber irgendwann könnte es passieren, dass die Reports doch dynamisch per ASPX aus einer Datenbank erzeugt werden, die durch asynchron ablaufende Prozesse immer aktualisiert werden. Das könnte sogar effektiver sein, wenn heute verschiedene Reports immer wieder die gleichen Daten abfordern, diese so auch noch zu cachen.
- Listen nach Sharepoint und
Views
Viele Ausgaben sind ja einfache "Listen". Nun sind Sharepoint oder Excel Services natürlich sehr viel leistungsfähiger was sortieren etc. betrifft. Die PowerShell Skripte könnten ihre Listenausgaben ja einfach in Sharepoint Listen hochladen. Die grafische Aufbereitung könnte dann Sharepoint übernehmen - Sharepoint Wiki und
generierte Dokumentation
Einige Daten geben eine Dokumentation wieder. Wenn Firmen ihre Umgebung z.B. in einem WIKI dokumentieren, dann wäre doch mal zu Prüfen, ob nicht Teile einer solchen Dokumentation automatisch aktualisiert werden könnten. - Trigger und Filter
Das Wiederholungsintervall der verschiedenen Skripte ist mit dem Taskplaner natürlich statisch. Eine "UpdateNow"-Funktion wäre schon wünschenswert. Ebenso könnten bestimmte Daten nicht immer wieder erstellt, sondern erst auf Anforderung generiert werden, z.B. ein Bericht für einen bestimmten Benutzer. Beide Funktionen erfordern natürlich etwas "Aktives" auf dem Server, z.B.: eine ASPX, ASP oder CGI-Lösung. - Anzeige aus Datenbank
Selbst mit Sharepoint Designer und einem IIS kann man ohne viel Codeentwicklung Daten aus Datenbanken extrahieren und als Tabellen anzeigen. Vielleicht könnte man den "Ermitteln"-Teil im Hintergrund die Daten in eine Datenbank bringen lassen und die Aufbereitung erst beim Zugriff durch den Benutzer durchführen. Gerade umfangreiche Tabellen wären durch vorgeschaltete Sortier und Filterfunktionen besser zu realisieren als der komplette Download der Daten und die Filterung/Sortierung auf dem Client über JavaScript. - Performance
Gerade die Exchange Commandlets brauchen sehr lange für große Umgebungen. Da müsste man überlegen, ob man die Daten nicht differenziell in eine Datenbank bringt und aktiv "Änderungen " überwacht (Siehe DirSync-API). Dann könnte die Auswertung auf einer Datenbank erfolgen. Auch könnten mehrere verschiedene Reports, die die gleichen Daten anfordern, auf einem Zwischenspeicher zugreifen und so Zeit sparen. - Erstellen von Grafiken a la
MRTG oder mit WPF
Aktuell gibt es keine Grafiken. Aber es gibt auch hier Module für einen IIS, die solche Optionen bieten. - System Dokumentation
Wenn man einige weitere Vorlagen erstellt, könnte ein Report quasi ein vorgefundenes System sogar dokumentieren. Das muss ja nicht alle Stunde passieren. Aber wäre eine HTML-Darstellung einer Exchange Konfiguration nicht interessant ?
Ich bin nicht sicher, ob ich die Ressourcen habe, diese Erweiterungen zeitnah umzusetzen.
- PowerShell.ASP - PowerShell
im IIS nutzen
http://www.PowerShellinside.com/PowerShell/asp/
Aber wie verhält sich das, wenn z.B. ein Quota-Report 10 Minuten arbeitet und sie so lange auf den Browser warten ? - How to run a CGI program under IIS 7.0 or IIS 7.5
http://blogs.iis.net/thomad/archive/2010/04/04/how-to-run-a-cgi-program-under-iis-7-0-or-iis-7-5.aspx
Ob man damit auch PowerShell direkt starten kann ? - Writing to Event Log in
ASP.NET application
http://pranas.net/2008/12/writing-to-event-log-in-asp-net-application/
Damit könnte man eine Aktion als Eventlog protokollieren und mit dem Taskplaner drauf reagieren - PowerShellASP
http://www.PowerShellinside.com/PowerShell/asp/
PowerShell Skripte direkt im IIS ausführen - Interprocess Communication
in PowerShell
http://gbegerow.wordpress.com/2012/04/09/interprocess-communication-in-PowerShell/
Zukunft: SQL mit Reports?
Ich denke ich habe mit ReportWeb eine relativ einfach umzusetzende Möglichkeit gefunden, für kleinere und mittlere Firmen ein Reporting zu Exchange zu erhalten und mir bei Migrationen das Leben zu erleichtern. Mit ist aber natürlich klar, dass diese Daten nicht für größere Firmen reichen und die Geschwindigkeit auch nicht skaliert.
Ich kann mit also gut vorstellen, dass irgendwann diese ganzen Skripte, die Daten aus dem System auslesen ihre Ausgaben nicht mehr in CSV oder HTML-Dateien ausgeben, sondern in entsprechende SQL-Tabellen schreiben. Dann dürfte es auch viel einfacher sein, diese Daten z.B. mit SQL-Reporting Services aufzubereiten, inklusive Filterungen und Grafiken. Unterm Strich könnte das sogar noch in der Summe sparsamer sein, da die Reports ja nur dann erzeugt werden, wenn ein Benutzer/Admin diese auch ansehen will.
Weitere Links
- Run PowerShell Script using
Windows Server 2008 Task
Scheduler
http://blog.pointbeyond.com/2010/04/23/run-PowerShell-script-using-windows-server-2008-task-scheduler/ - DumpConnector
- DumpAddresslist
- Get-DAGStatus
- Get-CASURL