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
dagstatus,dagstatus.ps1,dagstatus.htm

Auf dieser Version hat sich dann alles weiter entwickelt und erweitert z.B.

  • Angabe der "Vorlage"
    Mittlerweile kann ich bei jedem Report angeben, welche HTML-Datei als Vorlage genutzt wird
  • Vordefinierte Informationen
    Ich belege einige Felder wie Titel, Generierungszeit schon vor, so dass in der Webseite auch diese Information sichtbar ist.
  • Rückgabe als einfaches HTML oder als PSCustomObject mit Properties
    Ein einfaches Skript kann einfach einen HTML-Block liefern. Es kann aber auch ein Objekt mit mehreren Properties liefern, die dann Entsprechend dem Property-Namen in die Platzhalter der Vorlage eingefügt werden
  • Intervall
    Das Skript "drosselt" Reports, indem ich eine Pausenzeit angeben kann. Wird ein Report "vorher" angefordert, dann wird er nicht ausgeführt. Das ist schon eine Vorarbeit um später den Report auch "auf Bedarf" anzustoßen
  • Error-Handling
    Alle Fehler der Module bleiben in $error und werden am Ende von dem Hauptprogramm ausgewertet und in eine Error-Datei gespeichert.
  • Report-Status
    Ein eigenes Status-Report-Modul erstellt eine Übersicht, wann welcher Report wie lange gelaufen und mit wie vielen Fehlern ist und verlinkt auf den Report als auch auf die Error-Seite.
  • Mail
    Die Module können bei Verwendung der PSObject-Rückgabe auch einfach eine Mail generieren lassen

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.

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