Harry Potter und der Team Foundation Server 29.04.2011

Rudolf Sauer
Rudolf Sauer, Principal eXpert

Harry Potter Zauberformel: „Aparecium

Anwendung / Funktion:

Man tippt dreimal mit dem Zauberstab gegen den Gegenstand in dem man einen unsichtbaren Inhalt vermutet und spricht Aparecium. Damit sollte das Verborgene enthüllt sein.

Auch anwendbar ohne Zauberstab, aber mit dem Team Foundation Server:

TFS Zauberformel: „Wie können gelöschte Dateien im TFS wiederhergestellt werden

Anwendung / Funktion:

  1. In Visual Studio, gehe im Menü zu “Tools | Options | Source Control | Visual Studio Team Foundation”
  2. Aktiviere die Checkbox “Show deleted items in the Source Control Explorer”
  3. Öffne den Source Control Explorer “View | Other Windows | Source Control Explorer”
  4. Navigiere in den Bereich, wo die gelöschten Objekte sind. Diese werden ausgegraut dargestellt.
  5. Nachdem die gewünschten Dokumente lokalisert sind. Rechtsklicke auf das gewünschte Item und Klicke auf “Undelete”.
  6. Das war’s. Die gewünschten Dateien werden jetzt im “Pending Changes”-Bereich aufgeführt, und vom TFS wiederhergestellt.

It’s magic :)

Share |

Apple: Skandal oder Panikmache? 27.04.2011

Alexander Jung
Alexander Jung, Chief eXpert

Was bin ich froh, kein iPhone zu haben. "Ein Begleiter, der ihr Bewegungsprofil sorgfältig aufzeichnet", "heimlich hat es [das iPhone] in den letzten Monaten seinen jeweiligen Aufenthaltsort gespeichert" und "Apple is watching you!" heißt es in den heute-Nachrichten vom 21.04. (ab 10:00). Dort und im heute journal (ab 23:25) werden dann auch entsprechende Fachleute bemüht:

"An wen Apple jetzt genau die Daten weitergibt weiß man nicht, wir vermuten natürlich an Werbepartner..." (Lisa Brack, CHIP)

und

"...und da hätte Apple vielleicht mal das deutsche Bundesdatenschutzgesetz lesen sollen, da steht nämlich drin, dass nur die Daten erhoben werden sollen, die man tatsächlich für die Vertragsabwicklung braucht." (Prof. Peter Wedde, Experte für Datenschutz)

In der tagesschau (8:45) ARD kann man immerhin mit dem Bundesdatenschutzbeauftragen höchstpersönlich aufwarten...

"Grundsätzlich gilt, die Daten dürfen nur so lange gespeichert werden, wie sie wirklich erforderlich sind. Und wenn diese Daten überhaupt nicht erforderlich sind um einen Dienst zu erbringen, und danach sieht es ja aus, dann dürfen sie überhaupt nicht gespeichert werden." (Peter Schar, Bundesdatenschutzbeauftragter)

Und natürlich hat man entsprechende Horrorszenarien parat:

“Wenn Du zum Beispiel einen eifersüchtigen Partner hast, oder jemanden der Dir nachspürt, erzählen diese Daten schrecklich viel über Dein Leben.” (ZDF)

"Jede Mutter aus Hamburg könnte mit dem Telefon ihrer Tochter also nachprüfen, ob diese tatsächlich bei einer Freundin in Berlin war." (ARD)

Kann es schlimmer kommen? Natürlich! Zu allem Übel sind die Daten unverschlüsselt!

Der unbedarfte Anwender lernt also: Mein iPhone überwacht mich, Apple sammelt Daten zu meinen Aufenthaltsorten. Und weil sie das unverschlüsselt tun könn(t)en auch andere Personen – der Partner oder die Mama – darauf zugreifen. Und womöglich verkaufen sie meine Daten auch noch und verdienen damit Geld. Apple ist böse.

Diese Einschätzung entspräche jedenfalls genau dem Inhalt und der (für öffentlich-rechtliche Sender) beinahe reißerischen Aufmachungen. Das die Berichte auch andere Aussagen enthalten, die dem widersprechen, geht da schnell mal unter:

"Apple leitet das vermutlich nicht an eine zentrale Datenbank weiter." (ZDF)

“Im Internet einsehbar sind die Daten nicht.” (ZDF)

“Sie fanden keine Anzeichen dafür, dass die Informationen an Apple oder andere weitergeleitet werden.” (tagesschau.de)

Ganz verdummungsfrei sind diese Aussagen aber auch nicht. Wenn es heißt…

"Immerhin, iPhone und iPad Nutzer können den Datenfluss stoppen, wobei dadurch auch andere Dienste unbrauchbar werden… " (ZDF)

… dann erweckt das den Eindruck, Apple würde einem die Bespitzelung geradezu aufnötigen. Faktisch sind aber genau die Anwendungen betroffen, die auf Positionsdaten angewiesen sind.

Fakten?

Fakt ist, dass die Daten auf dem Gerät gespeichert werden; unverschlüsselt und dem normalen Backup unterworfen. Punkt. Weder werden Daten an Apple oder jemand anderen übertragen, noch gibt es Hinweise, dass die Daten zu einem anderen Zweck gesammelt werden, als dem der Positionsbestimmung.

Das wird für jeden offensichtlich, der sich die Mühe macht, sich die ersten 10 Minuten des Videos der Entdecker anzusehen. Und auch sie haben eine valide Einschätzung zum Zweck:   

"So this all looks like it is related to the whole general geo capabilities that they put in to iOS4" (Video 7:08)

Außerdem:

“Don't panic. As we discuss in the video, there's no immediate harm that would seem to come from the availability of this data. Nor is there evidence to suggest this data is leaving your custody.”

Auch wenn sie damit den Auslöser für eine erneuten “Datenschutzskandal” liefern – sie liefern auch eine weit weniger kontroverse und deutlich naheliegendere Erklärung: Das iPhone macht schlicht was es soll, vielleicht gepaart mit schlampiger Implementierung!

Aber wozu braucht man überhaupt diese “Datenaufzeichnung”?

Geolocation und positionsabhängige Dienste sind momentan ein großer Hype. Damit eine Anwendung auf Positionsdaten zugreifen kann, muss das Betriebssystem diese zur Verfügung stellen. Ermitteln kann das Gerät diese auf verschiedenen Wegen:

  • GPS: Am genauesten, aber nicht überall verfügbar und es belastet den Stromverbrauch am stärksten.
  • Funkzellen der Mobilfunkbetreiber: Am ungenauesten, aber dafür am verlässlichsten verfügbar.
  • WLAN/WiFi: Bieten genauere Positionsbestimmung als Funkzellen, setzen aber entsprechende Datenbanken voraus. (Beispiel)

Da mit keiner Methode eine schnelle und genaue Positionsbestimmung auf Zuruf garantiert werden kann, muss das Gerät die letzte Position vorhalten. Da keine einzelne Positionsbestimmung fehlerfrei ist oder nicht durch mehrere vorherige Messungen noch durch Interpolation verbessert werden könnte, brauche ich mehrere Messpunkte. Und da ich diese Informationen beim Einschalten gleich verfügbar haben möchte halte ich sie natürlich nicht im Speicher.

Von diesen Überlegungen ausgehend ist es kein großer Schritt mehr zu unterstellen, dass der Entwickler zu faul war ältere Daten zu löschen und dass er die Datenbank – mit exakt den eben beschriebenen Daten! – in den vom normalen Backup gesicherten Bereich legt. Nicht mehr, nicht weniger.

Auch das ist eine Erklärung für die “Datensammelwut” von Apple: Das Gerät erfüllt ganz einfach seine Funktion und benötigt dafür ein Caching! Vielleicht gepaart mit Insensibilität, Faulheit, oder gar erschreckenden Inkompetenz. Aber nicht mit verwerflicher Intention.

Aus dieser ebenso validen Erklärung ergeben sich aber zwei Konsequenzen:

Erstens lässt sie die Berichterstattung und nicht zuletzt auch die oben zitierten “Experten” in einem deutlich anderen Licht erscheinen. Speziell Frau Brack kommt dabei schlecht weg, wenn sie Apple unterstellt Daten weiterzugeben, auf die das Unternehmen gar keinen Zugriff hat (was auch nie behauptet wurde). Und ob ein Caching von Daten mit einer “Datenerhebung” im Sinne des Bundesdatenschutzgesetzes kollidiert darf bezweifelt werden.

Zweitens – und das ist bislang ziemlich untergegangen – kommen auch die anderen Betriebssysteme nicht um ein im Grundsatz vergleichbares Verfahren herum. Entgegen der Aussagen auf heute.de gibt es sehr wohl Hinweise, dass das auch für Android gilt (via netzpolitik.org). Und auch Windows Phone wird sich davon nicht freimachen können, selbst wenn man hier jeder Anwendung explizit den Zugriff auf die Daten erlauben muss.

Fazit

Selbst wenn man die Apple-freundlichere Interpretation akzeptiert gilt immer noch: Natürlich hat Apple bei der Implementierung geschlampt und aus Security-Sicht ein Scheunentor-großes Loch gerissen. Aber die Berichterstattung will uns Apple nicht als inkompetent darstellen, sondern als Big Brother mit in Teilen krimineller Intention – und das ist in meinen Augen mehr Panikmache als journalistische Leistung.

Das einzig Positive, das ich der Berichterstattung in den Hauptnachrichtensendungen der beiden großen öffentlich-rechtlichen Sender abgewinnen kann, ist, dass das Thema Datenschutz und die Sensibilität im Umgang mit gerade bei Mobilgeräten anfallenden Daten deutlich gewachsen ist. In Zeiten von Facebook und Vorratsdatenspeicherung keine schlechte Sache.

 

PS: Eine ausgewogenere Darstellung der Dinge findet sich bei heise: “Wirbel um Aufzeichnung von Ortungsdaten im iPhone” (link)

PPS: Wer tatsächlich Angst vor der Erstellung von Bewegungsprofilen hat sollte sich diesen Protest gegen die Vorratsdatenspeicherung anschauen: “Vorratsdaten: Sechs Monate im Leben des Malte Spitz” (link)

Share |

Was HTML 5 im Enterprise-Umfeld bringt (Teil 2/2) 26.04.2011

Torben Graefe
Torben Graefe, Senior eXpert

Den ersten Teil dieses Artikels finden Sie >hier<.

Im ersten Teil dieser Beitragsserie wurden nach einem kurzen historischen Überblick zwei wesentliche Features von HTML 5 betrachtet: Die Wiedergabe von Medien (bzw. speziell: Videos) und die Generierung von 2D-Grafikelementen.

Bei dieser Gelegenheit wurde festgestellt, dass die Marktreife von HTML 5 in Punkto Video-Wiedergabe bereits hoch und bei der Grafikgenerierung noch eher niedrig ist. Im zweiten Teil der Beitragsserie stehen die Implikationen, die HTML 5 für den Enterprise-Bereich hat, stärker im Vordergrund.

HTML 5 ist kein Selbstzweck

Im Enterprise-Bereich ist die Wiedergabe von Videos eher ein Randthema. Für die Darstellung von 2D-Grafikelementen gibt es zudem bereits eine ganze Reihe ausgereifterer Alternativen (z. B. Microsoft Silverlight). Auch die meisten anderen Features von HTML 5, deren detaillierte Beschreibung den Rahmen dieser Beitragsserie sprengen würde, sind keine Must-Haves, sondern dienen eher dazu, die Umsetzung häufig verwendeter Webseiten-Elemente zu vereinfachen und zu vereinheitlichen. Das kann zwar ziemlich nützlich sein, stellt aber für sich allein genommen keinen so großen Mehrwert dar.

HTML 5 – Eine Technologie mit Nebenwirkungen

Man kann also festhalten, dass es sich im Moment in der Regel noch nicht lohnt, Web-Entwicklung auf HTML-5-Basis zu betreiben. Das wäre momentan auch mit Hinblick auf die teilweise uneinheitliche Behandlung der HTML-5-Elemente durch die verschiedenen Browser nur in einer Umgebung sinnvoll, in der nur ein einziger Browser (z. B. Internet Explorer 9) zum Einsatz kommt. In einer heterogeneren Umgebung wären durch exzessiven Einsatz von HTML 5 Kompatibilitätsprobleme vorprogrammiert.

Viel entscheidender ist, dass es durch HTML 5 und die gewachsene Konkurrenz-Situation auf dem Browser-Markt einen allgemeinen Trend hin zu Web-Standards und Verbesserungen der Browser-Performance gibt, welcher sich schon heute für bessere Enterprise-Anwendungen nutzen lässt. Der kürzlich erschienene Microsoft Internet Explorer 9 stellt in dieser Hinsicht im Vergleich mit seinen Vorgängerversionen nicht weniger als einen Quantensprung dar.

Fazit: Von der Bewegung im Browsermarkt profitieren

Zum ersten Mal seit den den Anfängen des Internet-Zeitalters ist es möglich, attraktive, interaktive und hochperformante Web-Applikationen nahezu unabhängig vom verwendeten Browser zu entwickeln.

Das hat auch Auswirkungen für Unternehmen, in denen ausschließlich der Browser eines bestimmten Herstellers zum Einsatz kommt. Auch wenn durch die verwendete Version dieses Browsers HTML 5 noch nicht oder nur rudimentär unterstützt wird, sind diese Unternehmen dennoch von der maßgeblich durch HTML 5 entstandenen Bewegung betroffen. Wer sich heute schon mit den Chancen und Risiken durch den Technologie-Sprung im Browsermarkt auseinander setzt und die gewonnenen Erkenntnisse in die (Weiter-)Entwicklung seiner Anwendungslandschaft mit einfließen lässt, kann schneller und zu deutlich niedrigeren Kosten auf die kommende Browsergeneration umstellen.

Die Frage, ob HTML 5 kommt, haben die großen Browserhersteller schon beantwortet. Die Frage ist jetzt nur noch, wann es für die Unternehmen und ihre Enterprise-Anwendungen so weit ist. Dass es noch einmal 10 Jahre dauern wird, bis Microsoft dringend zum Umstieg auf die aktuelle Version des Internet Explorers rät, darf getrost bezweifelt werden. Deshalb ist HTML 5, obwohl es auf den ersten Blick noch Zukunftsmusik zu sein scheint, für uns als SDX schon jetzt ein großes Thema.

Share |

SharePoint 2010 und Business Intelligence Serie Teil 1: Excel Services 20.04.2011

Nicolas Meseth
Nicolas Meseth, Senior eXpert

Der SharePoint bietet in der Version 2010 einige neue Features für das Bereitstellen von Business Intelligence Inhalten. Dazu gehören die neuen PerformancePoint Services sowie die Visio Services. Bereits in 2007 vorhanden und in 2010 weiter entwickelt wurden die Reporting Services im SharePoint-integrated mode sowie die Excel Services (plus PowerPivot Services). Dieser Blogbeitrag ist der erste Teil einer Serie von vier Beiträgen, in dem die vier genannten Services kurz vorgestellt werden. Wir beginnen in diesem Beitrag mit den Excel Services.

Was sind die Excel Services?

Excel kennt jeder. Ein Doppelklick auf ein XLS bzw. XLSX öffnet automatisch die Excel Anwendung und zeigt die ausgewählte Datei an. Dies geschieht aber nur, falls auf dem Computer auch Excel installiert ist. Das dürfte zwar auf den meisten Geräten der Fall sein, aus verschiedenen Gründen kann es aber auch sein, dass auf einem Rechner gerade kein Excel installiert ist (Lizenzierung, Tablet-PC, mobiles Endgerät, nicht erwünscht etc.). In solchen Fällen wäre es schön, ein Excel-Dokument in einem Web-Browser darstellen zu können. Genau hier kommen die Excel Services ins Spiel.

Die Excel Services sind ein Dienst, der standardmäßig im SharePoint mit installiert wird. In der Site Collection müssen nur die Enterprise Features aktiviert werden und schon funktionieren die Excel Services in allen Unterseiten. Die Excel Services erlauben es, Excel Dokumente, die z.B. in einer SharePoint-Library gespeichert sind, direkt im Browser zu rendern, ohne dass auf dem Client Excel installiert sein muss. Zunächst einmal kann ein Dokument im SharePoint mit den Excel Services nur angezeigt werden. Es können aber Filter und Slicer in Pivottabellen verwendet werden, die dann den Inhalt des Dokuments verändern. Somit sind im Browser angezeigte Excel Sheets zwar nicht editierbar, aber dennoch interaktiv. Eine wichtige Voraussetzung für Business Intelligence Analysen.

Wie stelle ich ein Excel-Dokument im SharePoint bereit?

Einfacher könnte es nicht sein: In Excel 2010 einfach unter File –> Save & Send – Send to SharePoint klicken und dann die URL der SharePoint Library eingeben, in der das Dokument bereitgestellt werden soll. Das funktioniert mit jeder Excel-Edition von 2010. Zuvor kann noch bestimmt werden, welche Inhalte des Dokuments veröffentlicht werden sollen. Hier kann man beispielsweise einzelne Arbeitsblätter auswählen oder nur bestimmte Pivottabellen oder Charts selektieren. Seit der Version 2010 werden Charts auch standardmäßig in Excel Services unterstützt. Jeder, der Zugriffsrechte auf der SharePoint-Library besitzt, kann von nun an das Excel Dokument im Browser öffnen.

image

image

Excel in Webseiten einbetten

Mit dem Excel Services Web Part hat man zudem die Möglichkeit, Inhalte eines Excel-Dokuments in eine Webseite einzubetten. So kann beispielsweise ein Chart aus einem Excel-Dokument auf einer Webseite im SharePoint automatisch angezeigt werden. Falls hinter diesem Chart eine Datenquelle (z.B, ein Cube) hängt, so wird das Chart automatisch aktualisiert wenn die Daten sich verändern. So ist die Webseite immer auf dem aktuellen Stand ohne dass der Benutzer etwas unternehmen muss. In der Abbildung unten rechts ist beispielhaft ein Web Part zu sehen, dass eine Pivottabelle in einem Excel-Dokument anzeigt. Alle Navigationsfunktionen wie das Auf- und Zuklappen von Hierarchien bleiben auch im Web Part bestehen. Genauso können auch Filter und Slicer weiter verwendet werden.

imageimage

Web Service Schnittstelle

Neu in 2010 ist auch die REST und JSON Schnittstelle der Excel Services. Grundsätzlich bietet die REST-Schnittstelle ein API an Funktionen, um ein Excel-Dokument in einer Library per Web Service abzufragen. Ein Beispiel findet sich auf http://msdn.microsoft.com/de-de/library/ee556820.aspx

Standardmäßig ist der Web Service unter

http://<ServerName>/_vti_bin/ExcelRest.aspx

erreichbar, wenn er korrekt konfiguriert wurde. Das Modell eines Dokuments in der Library /Docs/Documents/sampleWorkbook.xlsx ist beispielsweise unter dem Aufruf

http://<ServerName>/_vti_bin/ExcelRest.aspx/Docs/Documents/sampleWorkbook.xlsx/model

abrufbar. Die Web Service Schnittstelle bietet vor allem für Entwickler einen Mehrwert, die darüber Inhalte aus Excel Service in externe Applikationen einbinden können. Auf diese Weise kann z.B. ein Diagramm aus Excel in einer PowerPoint Präsentation eingebunden werden. Der Vorteil hierin ist, dass das Diagramm stets aktuelle Daten anzeigt wenn die Präsentation geöffnet wird. Die JSON-Unterstützung erlaubt zudem den Zugriff auf ein Excel Services Dokument via JavaScript.

PowerPivot Services

Mit der Client-Version von PowerPivot, dem neuen Self-Service BI Tool für Excel, wurde auch eine Serverversion für den SharePoint 2010 entwickelt. Die PowerPivot Services sind ebenfalls mit der Enterprise Edition des SharePoint verfügbar und bieten die Möglichkeit, PowerPivot Workbooks über den SharePoint bereitzustellen. Dabei wird bei der Bereitstellung das eigentliche Excel Dokument von dem eingebetteten PowerPivot Modell getrennt und beide werden separat voneinander im SharePoint gespeichert. Öffnet man das Excel Dokument nun über die Excel Services im Browser, so greift das Excel Dokument auf das PowerPivot Modell im SharePoint zu. Das PowerPivot Modell ist also nun im SharePoint veröffentlicht und kann prinzipiell von anderen Workbooks wiederverwendet werden, ist also nicht länger an ein Excel Dokument gebunden.

Fazit

Das Fazit lautet: Die Excel Services sind eines der Instrumente, über die im SharePoint 2010 BI Inhalte bereitgestellt werden können. Dazu benötigt der Benutzer lediglich einen Web-Browser und muss keinen Excel Client mehr installiert haben. Zudem sind die Excel Services im Vergleich zur Version 2007 stark weiterentwickelt worden. So werden nun fast alle Elemente des Clients unterstützt, es gibt neue Web-Service Schnittstellen (REST und JSON), und mit den PowerPivot Services werden auch PowerPivot Workbooks unterstützt. Wer also Excel als BI Client und Frontend nutzt, der sollte sich die Möglichkeiten der Excel Services und des SharePoint genauer ansehen, da hier eine Menge Potential für die Bereitstellung von zentralen BI Lösungen sowie für Self-Service BI steckt.

Share |

Was HTML 5 im Enterprise-Umfeld bringt (Teil 1/2) 18.04.2011

Torben Graefe
Torben Graefe, Senior eXpert

Als Tim Berners-Lee vor 20 Jahren die erste Fassung der “Hypertext Markup Language” (HTML) publizierte, steckte das Internet noch in den Kinderschuhen. Bereits Anfang der 2000er-Jahre, als es durch die Breitband-Revolution so richtig an Fahrt aufnahm, “surfte” man auf Basis der HTML-Version 4. Doch obwohl sich das Internet inzwischen zu einem aus unserem Alltag nicht mehr wegzudenkenden Massenphänomen weiterentwickelt hat, ist die “Sprache” des Word Wide Web die gleiche geblieben, nämlich die schon erwähnte Version 4 der HTML-Spezifikation.
>> mehr...

Share |

Smartphone-Domino 15.04.2011

Matthias Jauernig
Matthias Jauernig, Senior eXpert

Immer wieder erfreut uns der Domino Day im TV mit dem schier endlosen Klicken fallender Dominosteine und hübschen Bildern. In der modernen Techie-Variante funktioniert das auch… mit Smartphones! Welche kreativen Möglichkeiten die moderne Technik mit sich bringt, zeigen die Domino-Künstler von Vodafone in einem aktuellen Video:

Smartphones sind eben doch das, als was sie angepriesen werden: echte Multitalente Zwinkerndes Smiley

Share |

Scrum Detailbetrachtung: Scrum Kennzahlen 13.04.2011

Rudolf Sauer
Rudolf Sauer, Principal eXpert

Dieser Blog-Eintrag ist Teil einer Serie zur Detailbetrachtung von Scrum. Weitere Einträge finden Sie hier:

Innerhalb des Scrumprozesses werden folgende unterschiedliche Scrum Kennzahlen, die einen Blick auf das Team oder den jeweiligen Projektfortschritt erlauben, definiert: Die Team Velocity, der Sprint Burndown, der Release Burndown.

Die einzelnen Kennzahlen im Detail

Die Team Velocity

Die Velocity zeigt an wie viel Arbeit ein Team innerhalb eines Sprint leisten kann. Diese Kennzahl kann dafür genutzt werden, um innerhalb der Releaseplanung die Leistungsfähigkeit und Sprintdauer für das komplette Projekt berechnen zu können (vgl. [Srinivasan], [Szalvay]).

Der Wert der Velocity berechnet sich aus den aktuell geleisteten Story Points aus den vorherigen Sprints. Diese Kennzahl verändert sich somit automatisch, sobald sich das Team verändert.

Velocity

Der dargestellte Velocity-Report stellt einen automatisch generierten Team Foundation Server Report dar, der mithilfe des TFS-Projekt-Templates „Scrum for Team System“ in der Version 3 automatisch erzeugt und jederzeit abgerufen werden kann (vgl. [Scrum For Team System]).

Mit Hilfe dieser Kennzahl ist es folglich möglich folgende Fragen zu beantworten (vgl. [Bielicki]):

  • Wie viel Funktionalität kann bis zur nächsten Iteration realisiert werden?
  • Wie sieht der Funktionsumfang in drei Monaten aus?
Der Sprint Burndown

Der Sprint Burndown zeigt den noch zu leistenden Arbeitsaufwand für einen gesamten Sprint an. Hierfür werden auf der x-Achse die Tage des aktuellen Sprints und auf der Y-Achse der aktuelle Funktionsumfang des Sprints, typischerweise in Stunden, angezeigt.

Idealerweise erreicht der Sprint Burndown am Ende des Sprints die x-Achse (Aufwand gleich Null).

SprintBurndownChart

Der dargestellte Sprint Burndown stellt einen automatisch generierten Team Foundation Server Report dar, der mithilfe des TFS-Projekt-Templates „Scrum for Team System“ in der Version 3 automatisch erzeugt und jederzeit abgerufen werden kann (vgl. [Scrum For Team System]).

Mit Hilfe des Sprint Burndowns ist es möglich folgende Fragen zu beantworten (vgl. [Szalvay]):

  • Wie viel Prozent der Arbeit des aktuellen Sprints wurde schon geschafft?
  • Wann ist die Arbeit des aktuellen Sprints fertig, wenn das aktuelle Tempo beibehalten wird?
Der Release Burndown

Der Release Burndown zeigt vergleichbare Informationen wie ein Sprint Burndown (Restaufwand pro Tag), jedoch nicht bezogen auf einen Sprint, sondern bezogen auf das komplette Release / Product. Der Release / Product Burndown zeigt somit das Gesamtbild des Projektes, während hingegen der Sprint Burndown jeweils nur einen Auszug darstellt.

ProductburndownChartbyDay001

Der dargestellte Release / Product Burndown stellt einen automatisch generierten Team Foundation Server Report dar, der mithilfe des TFS-Projekt-Templates „Scrum for Team System“ in der Version 3 automatisch erzeugt und jederzeit abgerufen werden kann (vgl. [Scrum For Team System]).

Mit Hilfe des Release Burndowns ist es möglich folgende Fragen zu beantworten (vgl. [Szalvay]):

  • Wie viel Prozent der Arbeit des kompletten Releases wurde schon geschafft?
  • Wann ist das komplette Projekt fertig, wenn das aktuelle Tempo beibehalten wird?

In der Praxis

Die Fallen in der Scrum Metrik liegen im Detail, so werden in der Praxis häufig unterschiedliche Scrum-Teams miteinander verglichen. Hierbei erfolgt auch ein Vergleich auf Velocity-Kennzahl-Ebene. Ein Vergleich der Kennzahl, welche leider nicht Teamübergreifend eingesetzt werden kann und somit nicht vergleichbar ist. „Ohne Velocity-Vergleich lässt man der Selbstorganisation zwischen den Teams den notwendigen Freiraum. Hierbei können sich sogar einzelne Teams herauskristallisieren, die besonderen Wert auf Verbesserungsmaßnahmen im Sinne nachhaltiger Entwicklung legen und daher meist eine niedrigere Velocity erreichen – zum Vorteil der gesamten Entwicklungs-Organisation.“ (vgl. [Gutjahr])

Eine Hauptmaßnahme des Scrum Masters ist es die Leistung des Teams darzustellen. Der Transparenzgedanke durch die Veröffentlichung der unterschiedlichen Burndown-Charts macht hierbei die Team-Performance jederzeit ersichtlich und bietet somit allen Teammitgliedern eine gute Übersicht über den Projektfortschritt. Diese Charts zeigen somit jederzeit wie gut ein Team im Zeitplan liegt.

Die Erstellung der jeweiligen Kennzahlen kann hierbei entweder „per Hand“ oder automatisch über ein Tool, wie beispielsweise den Team Foundation Server von Microsoft, durchgeführt werden. Eine aktuelle Untersuchung von VersionOne (State of Agile Survey – The state of agile development) aus dem Jahre 2010 zeigt hierbei eine Übersicht über die Tools die im agilen Kontext eingesetzt werden (vgl. [VisionOne]). Generell gilt aber: Projekte werden von Menschen erledigt und nicht von Tools. Schlechte Leistungen können niemals durch gute Tools kompensiert werden, schlechte Tools aber durch herausragende Leistungen ausgeglichen werden.

Literatur

[Scrum For Team System] Scrum for Team System Guidance / Version 3 von EMC Consulting [2010]

[Bielicki] Predicting the team's Velocity: yesterday's weather method von Przemysław Bielicki [September 2008]

[Srinivasan] What is Velocity in a scrum team von Vibhu Srinivasan [November 2007]

[Szalvay] Glossary of Scrum Terms von Victor Szalvay [März 2007]

[Gutjahr] Team Velocity vergleichen – eine gute Idee? von Till Gutjahr [Oktober 2009]

[VisionOne] State of Agile Development Survey Results von VisionOne [2011]

Share |

Scrum Detailbetrachtung: Scrum Meetings 11.04.2011

Rudolf Sauer
Rudolf Sauer, Principal eXpert

Dieser Blog-Eintrag ist Teil einer Serie zur Detailbetrachtung von Scrum. Weitere Einträge finden Sie hier:

Innerhalb des Scrumprozesses werden folgende unterschiedliche Scrum Meetings definiert: Das Estimation Meetings, das Release Planning, das Sprint Planning, das Daily Scrum und das Scrum-Abschluss-Meeting.

Die Scrum Meetings im Detail

Das Estimation Meeting

Das Team trifft sich regelmäßig mit dem Product Owner, um neue Features zu schätzen. Dieses Estimation Meeting erfolgt immer dann, wenn neue Product Backlog Items in das Product Backlog überführt werden. Diese Schätzung sind keine Aufwandsschätzungen (Personen Tage Aufwand), sondern Schätzungen nach Story Points (Komplexitäts- und Vergleichwerte), die pro Product Backlog Item vorliegen.

Das Sprint Planning 1 – Release Planning

Das Release Planning ist ein Planungsmeeting, in dem die nächsten Releases in Zusammenarbeit zwischen Team und Product Owner geplant werden. Innerhalb dieses Meetings einigen sich das Team und der Product Owner auf das Selected Product Backlog welches im Rahmen des nächsten Sprints abgearbeitet wird. Sind schon Kennzahlen aus den vorherigen Sprints vorhanden (Velocity), so kann auch hier schon eine Prognose über mögliche weitere Sprints und deren Inhalt gemacht werde. Aufgrund des agilen Product Backlog Inhalts ist diese Planung aber als ein grober Vorgehensplan zu verstehen.

Das Sprint Planning 2 – Sprint / Iteration Planning

Sprint Planning ist ein Planungsmeeting an dem das Team den aktuellen Sprint detailliert plant. Hier werden die jeweils zu bearbeitenden User Stories in Arbeitspakete aufgeteilt und mit konkreten Zeitschätzungen versehen. Hierbei gilt, ein Arbeitspaket darf maximal einen Aufwand von einen Tag haben. Diese Zeitschätzung erfolgt, um so verlässlich wie möglich zu sein, vom jeweiligen Entwickler des Arbeitspaketes. Ein Wechsel der gesetzten Personen erfordert automatisch eine Neuschätzung der Aufgaben.

Das Daily Scrum

Im Daily Scrum Meeting erfolgt die eigentliche Scrum-Implementierung bzw. deren Team-Statusupdate. Hier werden die jeweiligen Aufgaben nach und nach abgearbeitet und innerhalb des fünfzehn-minütigen, täglichen StandUp Meetings besprochen. Um das Meeting so kurz wie möglich zu halten, dürfen nur drei Fragen beantwortet werden. Erstens: Was hast du gestern gemacht? Zweitens: Was wirst du heute machen? Drittens: Welche Probleme hindern dich bei deiner aktuellen Arbeit?

Das Daily Scrum Meeting findet jeden Tag zur gleichen Zeit und am gleichen Ort statt. Über die komplette Sprintdauer gesehen, werden die jeweiligen Tasks abgearbeitet und am Taskboard in der Reihenfolge aus dem Product Backlog und gruppiert pro Product Backlog Item visualisiert dargestellt.

Der Sprint Abschluss (Review und Retrospektive)

Am Ende jedes Sprints findet der Sprint Abschluss statt. Dieser teilt sich in zwei Bereiche: Einerseits die „Review“-Präsentation der Sprintergebnisse (Teilnehmer: Product Owner, Stakeholder, Scrum Master und Team) und andererseits die Sprint Retrospektive (Teilnehmer: Scrum Master und Team). Im Review wird der erarbeitete Stand präsentiert. Ohne lange Vorbereitung bzw. ohne Powerpoint-Folien. Demonstration direkt am System.

In der Retrospektive werden die lessons learned Punkte angesprochen und die Verbesserungspunkte im Team erarbeitet und die wichtigen Prozessanpassungen für den nächsten Sprint festgelegt.

In der Praxis

In der Praxis zeigt sich, dass eine gute Vorbereitung für das Release Planning viel Arbeit erspart. Hier können der Scrum Master und der Product Owner schon im Vorfeld das Ziel des Releases festlegen. Gute Anhaltspunkte und Planungsgrundlagen sind schon vorhandene Velocity-Kennzahlen aus vorangegangenen Sprints / Iterationen. Innerhalb dieses Meetings sollte jedoch folgendes, aufgrund der Veränderlichkeit des Backlogs, bedacht werden: Don’t go into too much detail (vgl [Baker]).

Wenn Schätzen zu einem größeren Akt wird macht man es zu einer Aufgabe im Scrum-Prozess und arbeitet es wie jeden andere Aufgabe ab. So ist es durchaus valide diese im Rahmen einer Proof-of-Concept-Implementierung zu erarbeiten. Diese PoC-Implementierung wird vor der eigentlichen User-Story-Umsetzung z.B. als Sprint 0, durchgeführt und erlaubt eine validere Schätzung des Aufwandes (vgl. [Waters], [Baker2]).

Ein Video zum Thema „Maximizing Value with Agile Release Planning“ findet sich hier (vgl. [Shore])

Im Lauf der Zeit haben sich folgende Zeitrahmen als grober Startpunkt eines eingespielten Scrum-Teams herausgestellt:

  • Sprint Planning ca. 4 Stunden
  • Sprint Review ca. 4 Stunden
  • Retrospektive ca. 3 Stunden
  • Daily Scrum: 15 Minuten

Literatur

[Baker] – Release Planning von Simon Baker [April 2006]

[Baker 2] - User stories part 3: Using spikes to help estimate user stories von Simon Baker [Februar 2006]

[Waters] – Agile Release Planning von Kelly Waters [Februar 2008]

[Shore] – Maximizing Value with Agile Release Planning von James Shore [März 2009]

Share |

Kurze Reise durch die Zeit: Windows von Anfang an 08.04.2011

Nicolas Meseth
Nicolas Meseth, Senior eXpert

Eines meiner Lieblingsvideos auf YouTube!

Gezeigt wird in unter 10 Minuten eine Zeitreise durch alle Windows-Versionen von Anfang an bis Windows 7. Da kommen Erinnerungen hoch, auch wenn ich persönlich erst bei Windows 3.1 eingestiegen bin. Besonders lustig: Der Autor setzt als Maßstab für ein erfolgreiches Update, ob Monkey Island und Doom jeweils in der aktuellen Version noch laufen, und ob alle Startmenüeinträge (oder Programmmanager-Items) noch vorhanden sind. Zudem legt er Wert darauf, dass der Desktophintergrund übernommen wird, was aber ab XP nicht mehr der Fall ist. Ein absolut sehenswertes Video!

In diesem Sinne: Viel Spaß und ein schönes Wochenende!

Share |

Scrum Detailbetrachtung: Scrum Artefakte 06.04.2011

Rudolf Sauer
Rudolf Sauer, Principal eXpert

Teil 1 der kleinen Serie zur Detailbetrachtung von Scrum finden Sie >hier<

Innerhalb des Scrumprozesses werden folgende unterschiedliche Scrum Artefakte definiert: Das Product Backlog, das Sprint Backlog und das Impediment Backlog.

Die einzelnen Backlogs im Detail

 
1. Product Backlog

Das Product Backlog dient der Erfassung aller Anforderungen an das zu erstellende Produkt. Hier werden alle Anforderungen (technischer als auch fachlicher Art), Features und Tätigkeiten (wie beispielsweise Deployment) aufgeführt, und in strenger Reihenfolge nach Wichtigkeit (Return on Investment) aufgelistet. Das Product Backlog wird geführt und gepflegt vom Product Owner. Das Team ergänzt die eingepflegten Einträge um Schätzungen (Story Points) und verwendet das Product Backlog für die Sprint- bzw. Releaseplanung. Hierbei gilt, dass nur vollständig beschriebene Features in den Planungsmeetings berücksichtigt werden können.

Bugs und aufgetretene Fehler landen ebenfalls im Product Backlog. Jeder Bug gilt als „Feature“ und die Behebung wird gleichberechtigt mit anderen Features vom Product Owner priorisiert und vom Team abgearbeitet.

Zusätzlich zur Beschreibung der Anforderung sollten pro Backlog Eintrag die jeweiligen Akzeptanzkriterien aufgeführt werden, nach denen die jeweilige Anforderung vom Product Owner abgenommen wird.

2. Sprint Backlog

Die Auswahl der Product Backlog Items, an denen im aktuellen Sprint gearbeitet wird, nennt sich Selected Product Backlog. Diese Auswahl wird am Anfang des Sprints gemeinsam mit dem Product Owner erstellt.

Das Sprint Backlog enthält die jeweiligen Aufgaben der Selected Product Backlog Items, die das Team im aktuellen Sprint erledigen muss.

Die Abarbeitung der Aufgaben erfolgt innerhalb des Sprints und dessen Visualisierung erfolgt mit Hilfe eines Taskboards, wo eine Aufgabe nur drei Statusausprägungen haben darf: „ToDo“, „In Progress“, „Done“.

Der Aufwand pro Aufgabe sollte kleiner gleich einem Arbeitstag sein, um einen Fortschritt im Daily Scrum Meeting bzw. eine Bewegung auf dem Taskboard sichtbar zu machen. Die zugrundeliegende Zeitschätzung wird vom Team vorgenommen und im Rahmen des Sprint Planning Meetings diskutiert.

3. Impediment Backlog

Das Impediment Backlog wird geführt vom Scrum Master und beinhaltet alle Hindernisse und Probleme, die nicht vom Team selbst gelöst werden können bzw. zu deren Behebung das Team den Scrum Master benötigt. Diese Liste kann kategorisiert und priorisiert geführt werden. Die Aufgabe des Scrum Masters ist die Behebung aller Impediments, sodass das Team effektiv weiterarbeiten kann. Das Impediment Backlog wird genauso wie das Sprint Backlog im Daily Scrum Meeting aktualisiert und der jeweilige Status kommuniziert.

In der Praxis

Eine aktuelle Untersuchung von VersionOne (State of Agile Survey – The state of agile development) aus dem Jahre 2010 zeigt, dass Scrum und dessen Featureerfassung vor allem für die Bereiche „Accelerate Time to Market“ und „Enhance Ability to Manage Changing Priorities“ genutzt wird (vgl. [VisionOne]). Die Verwaltung des Product Backlogs und deren Priorisierung durch den Product Owner stellen somit große Anforderungen an das Projekt.

Bei der Erfassung der Product Backlog Items sollte beachtet werden, dass die Anforderungen klar genug beschrieben sind. Hierfür bieten sich folgende Beschreibungsarten an: Die Software Requirements Specification IEEE 830 oder die SMART Definition für die eindeutige Beschreibung der Ziele (vgl. [IEEE 830], [SMART]). Alternativ dazu, kann ein gut beschriebenes Feature auch als User Story mit Hilfe der INVEST Kriterien erstellt werden (vgl. [Vaibhav]). Hierfür bietet sich folgendes User Story Template an: Als <Benutzer/ Benutzerrolle> möchte ich die <Funktion> haben, so dass ich folgenden <Nutzen> erhalte.

Die generelle Erfassung der Anforderungen kann auch als separater Sprint ausgelagert werden, in dem nur die Definition und Beschreibung der Features als Initialphase durchgeführt wird: „Es kann empfehlenswert sein, selbst diese Aufgaben als Sprints zu organisieren oder aber auch eine Initialphase von einigen Tagen/Wochen einzulegen, die Scrum losgelöst ist und das initiale Product Backlog organisiert. Sollten sich die ersten Anforderungen mit geringem Zeitaufwand beschreiben lassen, kann auch zunächst mit einem sehr kleinen Team gestartet werden und dieses abhängig von den weiteren Anforderungen, die noch formuliert werden, aufgestockt werden. Dies ist vom Product Owner zu entscheiden.“ (vgl. [Scrum Kompakt])

Literatur:

[VisionOne] State of Agile Development Survey Results von VisionOne [2011]

[IEEE 830] Software Requirements Specification von Wikipedia [Februar 2011]

[SMART] SMART (Projektmanagement) von Wikipedia [Januar 2011]

[Scrum Kompakt] Anforderungsaufnahme und deren Dokumentation von Scrum Kompakt [2011]

[Vaibhav] Six Features of a Good User Story - INVEST Model von Vaibhav [Oktober 2007]

Share |

SharePoint 2010 Workflow mit Visual Studio 2010 und InfoPath 2010 (Part 3) 04.04.2011

Matthias Straßer
Matthias Straßer, Chief eXpert

Dies ist der dritte und letzte Teil einer kleinen Reihe zu dem Thema SharePoint 2010 Workflows mit Visual Studio 2010 und InfoPath 2010.

Es soll ein Workflow für eine Dokumentenliste einer SharePoint 2010 Site erstellt werden, welcher eine Association Form, eine Initiation Form sowie eine Task Form verwendet. Alle Formulare sollen mit Hilfe des InfoPath Designers 2010 erzeugt werden und in einem Visual Studio 2010 Workflow Projekt verwendet werden. Fachlich handelt es sich auch um einen Freigabeprozess für Dokumente. Dabei soll der Workflow bei der Zuordnung zu einer Liste eine Association Form anzeigen, in der bereits Felder vorbelegt sind. Des Weiteren sollen dann die Daten aus der Association Form an die Initiation Form übergeben werden und ggfs. vom Anwender verändert werden können. Abschließend werden dann die Daten in der Task Form dem Bearbeiter angezeigt.

Ein sehr guter Beitrag zu diesem Thema ist in einer Blogreihe von Reiner Ganser (1st Quad Blog) zu finden. Diese Blogreihe ist eine Schritt für Schritt Anleitung für die Erstellung eines Workflows, allerdings werden in diesem Beispiel für Association und Initiation Form ASPX Seiten verwendet. Das Hauptaugenmerk in meiner dreiteiligen Blogreihe liegt auf dem Datenaustausch zwischen den Formularen und dem Workflow. Ansonsten  sind nur die wesentlichen Schritte beschrieben. Dabei behandeln die Blogbeiträge folgende Themen

  1. Datenübergabe an Association Form
  2. Datenübergabe von Association Form an Initiation Form
  3. Datenaustausch mit dem Workflow und Task Form

Datenaustausch mit dem Workflow und Task Form

Im ersten Teil der Reihe habe ich aufgezeigt wie Datenfelder in einer Association Form über die Metadaten des Workflows vorbelegt werden können. Im zweiten Teil wurden dann die Daten an die Initiation Form weitergereicht. Nun möchte ich im dritten und letzten Schritt zeigen, wie diese Daten in dem Workflow verwendet werden können und wie der Datenaustausch mit einer Task Form erreicht werden kann.

Die Daten der Association Form und der Initiation Form stehen der Workflow-Instanz als Properties AssociationData und InitiationData zur Verfügung, denn im MSDN Artikel How to: Design a Workflow Form to Use Association and Initiation Data heißt es:

“When a workflow instance starts, this data is also passed into the workflow via the AssociationData property of the SPWorkflowActivationProperties object.”

“After the workflow starts, the initiation data is stored in the InitiationData property of the SPWorkflowActivationProperties object returned by the WorkflowProperties property of the OnWorkflowActivated activity.”

Diese beiden Eigenschaften sind vom Typ string und beinhalten XML. Um an die einzelnen Feldinhalte zu gelangen stehen 2 Möglichkeiten zur Verfügung:

1.) Einlesen in ein XmlDocument und Auslesen über XPath-Ausdrücke, wobei die Namespaces beachtet und gegebenenfalls Datenkonvertierungen vorgenommen werden müssen.

2.) Deserialisierung in eine Klasseninstanz, die auf den Schemata der Formulare basiert.

Eine Schritt für Schritt Anleitung der Möglichkeit 2 ist hier How to: Access Association and Initiation Form Data in a Workflow nachzulesen. Anschließend stehen die Informationen typisiert für die Aufgaben des Workflows zur Verfügung.

Fehlt noch der Datenaustausch zwischen dem Workflow und einer Task Form. Eine Task Form kommt zum Einsatz, wenn durch den Workflow eine “Create Task Acitivity” verwendet wird. Möchte man hier eine InfoPath Form verwenden, so wird die InfoPath Form zum Beispiel auf Basis des “Blank Form” Templates erstellt. Da die Form Daten erhalten soll, muss eine Data Connection erstellt werden, die Daten entgegen nehmen kann. Dafür modelliert man sämtliche Daten für den Austausch in einer Datei namens ItemMetadata.xml, die lediglich eine XML Tag namens <z:row xmlns:z=”#RowsetSchema” /> beinhaltet und die für jedes Datenfeld ein Attribute namens “ows_NameDatenfeld” mit sich bringt.

   1: <z:row xmlns:z="#RowsetSchema"
   2:  ows_Instructions=""
   3:  ows_ReviewHints=""
   4:  ows_ReviewComment=""
   5:  ows_ReviewStatus=""
   6:  /> 

Im obigen Bespiel sind die Datenfelder “Instructions”, “ReviewHints”, “ReviewComment” und “ReviewStatus” definiert. Der Präfix “ows_” ist aus historischen Gründen zu verwenden. Die so definierte ItemMetadata.xml ist in der InfoPath Form Data Connection vom Typ “Retrieve data” zu definieren. Sind Felder im InfoPath Formular vorzubelegen, dann kann dies über das Setzen eines Default Values erreicht werden.

image

Nun muss das Formular publiziert (Network Location) werden, die publizierte XSN-Datei unterhalb des Workflows in das Projekt aufgenommen werden und der Deployment Type auf “ElementFile” zu setzen. Zur Verwendung des Formulars ist dann noch die Metadatendatei “Elements.xml” des Workflows an zwei Stellen anzupassen.

   1: <Elements xmlns="http://schemas.microsoft.com/sharepoint/">
   2:   <Workflow
   3:      Name="HowToWorkflow - ReviewWorkflow"
   4:      Description="My SharePoint Workflow"
   5:      Id="64261495-cba6-417c-bc7d-83ec41fd0cec"
   6:      AssociationUrl="_layouts/CstWrkflIP.aspx"
   7:      InstantiationUrl="_layouts/IniWrkflIP.aspx"
   8:      TaskListContentTypeId="0x01080100C9C9515DE4E24001905074F980F93160"
   9:      CodeBesideClass="HowToWorkflow.ReviewWorkflow.ReviewWorkflow"
  10:      CodeBesideAssembly="$assemblyname$">
  11:     <AssociationData>...</AssociationData>
  12:     <MetaData>
  13:       <AssociationCategories>List</AssociationCategories>
  14:       <!-- Tags to specify InfoPath forms for the workflow; delete tags for forms that you do not have -->
  15:       <Association_FormURN>...</Association_FormURN>
  16:       <Instantiation_FormURN>...</Instantiation_FormURN>
  17:       <Task0_FormURN>urn:schemas-microsoft-com:office:infopath:TaskForm:-myXSD-2011-03-07T09-52-14</Task0_FormURN>
  18:       <StatusPageUrl>_layouts/WrkStat.aspx</StatusPageUrl>
  19:     </MetaData>
  20:   </Workflow>
  21: </Elements>

In Zeile 8 wird ein TaskListContentTypeId Attribut auf den Wert “0x01080100C9C9515DE4E24001905074F980F93160” gesetzt und in Zeile 17 wird die URN gesetzt, die im InfoPath Designer über File –> Form Template Properties –> ID ermittelt wird. Die ContentTypeId ist der von SharePoint definierte Wert für Tasks. Das <TaskX_FormURN> Tag verweist auf die URN der zu verwendenden Task Form. Hierbei ist X ein Numerierung, die bei der Create Task Activity eine Rolle spielt. Denn hier wird zum Beispiel codiert:

   1: private void OnCreateReviewTask(object sender, EventArgs e)
   2: {
   3:   XmlSerializer serializer = 
   4:     new XmlSerializer(typeof(SDX.Workflows.myFields));
   5:   XmlTextReader reader = 
   6:     new XmlTextReader(new System.IO.StringReader(workflowProperties.InitiationData));
   7:   SDX.Workflows.myFields initform = 
   8:     (SDX.Workflows.myFields)serializer.Deserialize(reader);
   9:  
  10:   string assignedTo = initform.Reviewer[0].AccountId;
  11:  
  12:   this.createReviewTaskId = Guid.NewGuid();
  13:   this.createReviewTaskProperties.Title = "Review des Dokuments";
  14:   this.createReviewTaskProperties.AssignedTo = assignedTo;
  15:   this.createReviewTaskProperties.DueDate = DateTime.Today.AddDays(5);
  16:   this.createReviewTaskProperties.TaskType = 0; // Nr. des Formulars 
  17:   this.createReviewTaskProperties.ExtendedProperties["Instructions"] 
  18:     = initform.Instructions;
  19:   this.createReviewTaskProperties.ExtendedProperties["ReviewHints"] 
  20:     = initform.ReviewHints;
  21: }

In Zeile 16 wird die Nummer des Formulars verwendet, welches bei der Anzeige des Tasks verwendet werden soll. Die Felder aus der ItemMetadata.xml werden über die Hashtable “ExtendedProperties” gefüllt, wobei der Name des Feldes der Schlüsselwert ist (siehe Zeilen 17 – 20). Entsprechend stehen Werte, die im Formular durch den Anwender und das Formular selbst gesetzt werden, wieder in den ExtendedProperties im Rahmen einer OnTaskChanged Activity in deren AfterProperties wieder zur Verfügung (siehe unten Zeilen 3 und 11).

   1: private void OnReviewTaskChanged(object sender, ExternalDataEventArgs e)
   2: {
   3:   switch (this.onReviewTaskChangedAfterProperties.ExtendedProperties["ReviewStatus"].ToString())
   4:   {
   5:     case "freigegeben":
   6:       this.documentAccepted = true;
   7:       break;
   8:     case "zurückgewiesen":
   9:       this.documentAccepted = false;
  10:       this.reviewerComment
  11:         = this.onReviewTaskChangedAfterProperties.ExtendedProperties["ReviewComment"].ToString();
  12:       break;
  13:     default:
  14:       this.documentAccepted = false;
  15:       break;
  16:   }
  17: }
Fazit

Die Daten der Association Form und der Initiation Form im Workflow stehen über die Properties AssociationData und InitiationData zur Verfügung. Diese können per XPath oder per Deserialisierung ausgelesen werden. Um Daten mit Task Forms auszutauschen bedarf es einer ItemMetadata.xml als Data Connection in der InfoPath Form und der Verwendung der Hashtable ExtendedProperties bei Task Activities.

Share |

Auf vielfachen Wunsch: Spezielle Männer-Kurse jetzt auch als SDX Inhouse Training 01.04.2011

Svenja Henß
Svenja Henß, Senior Assistant

Diese Kurse der VHS Rotenburg haben bei unseren männlichen eXperts wahre Begeisterungsstürme ausgelöst. Endlich scheint eine Lösung für wahrhaft komplexe Probleme in Sicht, welche ganze Generationen von Männer beschäftigt haben.

Dies möchten wir Ihnen – unseren treuen Lesern - natürlich nicht vorenthalten:

VHS

Das erste SDX Inhouse Training wird sich mit der Selbstreinigung schmutzigen Geschirrs beschäftigen. Interessiert? Auch Sie können dabei sein!

Zögern Sie nicht und melden Sie sich heute noch bei mir an. ( Ihre Frau wird es Ihnen danken :-))

In diesem Sinne wünsche ich Ihnen einen schönen 1. April und ein sonniges Frühlingswochenende!

Share |