SharePoint

Ein intelligenter Ansatz für die Datensammlung im Unternehmen

Keith Deshaies

Kurz zusammengefasst:

• Sammeln und Verarbeiten von Daten
• Trennen der Darstellungslogik von der Informationsverwaltungslogik
• Erstellen einer Datensammlungslösung mithilfe von Microsoft Office 2007-Technologien

Laden Sie den Code für diesen Artikel herunter: DataGathering2008_02.exe (567KB)

Unternehmen sammeln mit verschiedenen Methoden eine Vielzahl von Informationen. Die Daten gehen über E-Mail, Umfragen, Webformulare und andere Datensammlungsmethoden ein. In der Regel sind Daten eine gute

Sache. Die Verwaltung der Palette von Datensammlungstools und des gesamten Spektrums verschiedenartiger Informationen gestaltet sich jedoch schwierig. Die zuverlässige Integration und die sichere Freigabe von Daten stellen ständige Herausforderungen für IT-Organisationen dar. Standards und serviceorientierte Architekturen entwickeln sich weiter, wodurch es für IT-Experten leichter wird, den Zugriff auf Daten auf sicherere Weise zu vereinfachen. Obwohl Sie jedoch über die Tools und Technologien verfügen, die Sie zum Aufbau einer effizienten Unternehmensarchitektur benötigen, kommt es allzu häufig vor, dass eine Vielzahl proprietärer Schnittstellen verwendet wird, was zu isolierten Lösungen führt.

Nehmen wir die in Microsoft® Office System verfügbaren Technologien als Beispiel. Sie können auf Grundlage von Windows® SharePoint® Services 3.0 schnell eine Abteilungsumfrage erstellen – ob es sich dabei um eine Standardlösung handelt, hängt jedoch von Ihrer Organisation ab. Wenn in Ihrem Unternehmen ASP.NET und SharePoint als Plattform für webbasierte Zusammenarbeit und Datenintegration verwendet werden, bietet diese Umfrage tatsächlich eine Standardlösung. Wenn Ihre Umgebung jedoch der Umgebung ähnelt, in der ich arbeite, ist SharePoint nur eine Plattform unter vielen.

Zugegeben, SharePoint bietet zahlreiche Optionen für die Integration in Systeme von IBM, HP, Siebel usw. Dies ist eine gute Nachricht für Poweruser, die Ad-hoc-Lösungen erstellen und dennoch die resultierenden Daten in verschiedene Back-End-Systeme einfließen lassen möchten. Wenn Sie jedoch ein Lösungsarchitekt sind, gibt es eine noch bessere Möglichkeit – InfoPath® 2007.

Mit InfoPath 2007, einer Komponente von 2007 Office System, können Sie die Darstellungslogik Ihrer Lösungen von der auf Ihren Servern gehosteten Informationsverwaltungslogik abkoppeln. Mithilfe XML-basierter InfoPath-Technologie können Sie für Unternehmen geeignete Datensammlungslösungen erstellen. Darüber hinaus benötigen Designer von InfoPath-Formularen zum größten Teil keine ausführlichen Kenntnisse im Bereich von XML, Webdiensten, Lösungsarchitekturen, ASP.NET oder dem SharePoint-Objektmodell.

In diesem Artikel erläutere ich, wie Sie mit InfoPath 2007, Office SharePoint Server 2007 und Forms Services flexible Lösungen zum Sammeln von Daten erstellen können. Darüber hinaus zeige ich Ihnen, wie Sie mithilfe von XML in einer mehrstufigen Unternehmensarchitektur die Darstellungslogik von der Geschäftslogik trennen können.

Beachten Sie, dass ich mit dem Begriff „Datensammlung“ den Prozess des Sammelns von Informationen von menschlichen Quellen meine. Es gibt selbstverständlich weitere Möglichkeiten für das Sammeln von Daten, beispielsweise das Crawlen von Datenquellen. Diese automatisierten Methoden gehen jedoch über den Rahmen dieses Artikels hinaus.

Erfassen und Verarbeiten von Daten

Obwohl die Anforderungen an die Datenerfassung kompliziert sein können, haben diese Prozesse einige Gemeinsamkeiten. Durch Berücksichtigung dieser Ähnlichkeiten in zentralen Modulen und die Abdeckung spezieller Anforderungen in dezentralen Komponenten können Sie redundante Arbeiten, den Wartungsaufwand und die Gesamtkosten verringern.

Vorschriften für Aktiengesellschaften hinsichtlich der Einhaltung gesetzlicher Bestimmungen führen beispielsweise zu Geschäftsanforderungen, die sich in unternehmensweiten Richtlinien zur Informationsverwaltung niederschlagen. Diese Richtlinien betreffen Datensammlungslösungen über Abteilungsgrenzen hinweg und führen in einzelnen Abteilungen häufig zu doppeltem Aufwand – beispielsweise Regeln für das Sammeln personenbezogener Informationen, die von einer Personalabteilung (Umgang mit Mitarbeiterdaten) und einer Kundendienstabteilung (Umgang mit Kundendaten) zusammengetragen werden. Selbst Geschäftsprozesse zwischen einzelnen Abteilungen, die ähnlich sind, aber nicht zusammenhängen, bieten Gelegenheiten für die Vereinheitlichung von Lösungen zur Informationsverwaltung.

Abbildung 1 zeigt ein Beispiel für einen typischen Geschäftsprozess. Ein Mitarbeiter, der eine ihm zugewiesene Aufgabe mit einem Kollegen tauschen möchte, muss erst die Zustimmung des Kollegen, dann die Genehmigung eines Managers oder Koordinators des Aufgabenzeitplans und schließlich die Genehmigung des Vorgesetzten einholen. Hierzu kann beispielsweise gehören, dass Mitarbeiter die Arbeitsschichten tauschen. Obwohl diese Tauschvorgänge in verschiedenen Abteilungen stattfinden und möglicherweise auf unterschiedlichen Formularen basieren, können die Workflows und die Informationsverwaltungslogik von den verschiedenen Abteilungslösungen gemeinsam verwendet werden.

Abbildung 1** Beispielprozess für die Datensammlung, der von mehreren Abteilungen gemeinsam verwendet werden kann **(Klicken Sie zum Vergrößern auf das Bild)

Natürlich stellt die Konsolidierung redundanter Komponenten eine gewaltige Aufgabe dar. Es ist nicht einfach, organisatorische Änderungen im gesamten Unternehmen zu bewirken, mit den Office System-Technologien können Sie jedoch ein solides Fundament aufbauen, um diese Änderungen zu erleichtern. Mithilfe von InfoPath 2007 können einzelne Abteilungen Formularanwendungen erstellen, die sich in zentrale, standardisierte Informationsverwaltungssysteme integrieren lassen. Derweil ermöglicht SharePoint 2007 IT-Abteilungen, die administrative Kontrolle über Websitesammlungen, Websites und Dokumentbibliotheken an einzelne Abteilungen und Teams zu delegieren. Dadurch können Teams eigene Lösungen mit minimaler Beteiligung der IT-Abteilung erstellen und bereitstellen, während die IT-Abteilung die Kontrolle über alle freigegebenen Dienste und Komponenten wie Workflows, Informationsverwaltungsrichtlinien und Sicherungsverfahren behält.

Zentralisieren der Datensammlungsprozesse

Unternehmen stellen Teams häufig abteilungsinterne Anwendungsserver zur Verfügung, um individuellen Anforderungen an die Informationsverwaltung Rechnung zu tragen. Die IT-Abteilung ist lediglich für die Aufrechterhaltung des Betriebs von Hardware und Betriebssystem verantwortlich, während sich die einzelnen Abteilungen um sämtliche Aspekte ihrer Lösungen kümmern. Zwischen den Abteilungen erfolgt nur eine geringe Koordination, und die Freigabe von Informationen gestaltet sich schwierig.

Technische Herausforderungen bei der Zentralisierung der Datensammlungsprozesse drehen sich hauptsächlich um die Sicherheit, Leistung, Verwaltung und Unterstützung benutzerdefinierter Komponenten, die in einer freigegebenen Umgebung gehostet werden. So bleiben beispielsweise die Auswirkungen einer fehlerhaften Komponente isoliert, wenn einzelne Lösungen auf abteilungsinternen Anwendungsservern gehostet werden. In einer freigegebenen Umgebung kann sich jedoch eine fehlerhafte Komponente in viel größerem Umfang auf Geschäftsprozesse auswirken. Daraus folgt, dass die IT-Abteilung strenge Richtlinien für die Bereitstellung und Verwaltung benutzerdefinierter Komponenten auf zentralen Systemen festlegen muss.

Das Hosten abteilungsinterner SharePoint-Lösungen in einer zentralen Serverfarm erfordert, dass Sie alle benutzerdefinierten Komponenten dieser Abteilungslösungen auf den zentralen Anwendungsservern bereitstellen und verwalten. Bei einer Lösung könnten benutzerdefinierte Feldtypen verwendet werden, um die Benutzeroberfläche der Lösung mit Dropdownlisten zu erweitern, die von Back-End-Webdiensten aufgefüllt werden. Bei einer anderen Lösung könnten für denselben Zweck Webparts herangezogen werden, während in einer weiteren Lösung benutzerdefinierte Workflows verwendet werden, die alle in verwaltetem Code geschrieben und als Microsoft .NET Framework-Assemblys bereitgestellt werden.

Das Verschieben selbst einer relativ kleinen Anzahl von SharePoint-Lösungen in eine zentrale Anwendungsserverfarm kann zu ernsthaften Konfigurations- und Unterstützungsproblemen führen. Wenn Assemblys im globalen Assemblycache (GAC) bereitgestellt werden müssen, wird die Sicherheit zu einem Problem, da diese Assemblys mit voller Vertrauenswürdigkeit ausgeführt werden. Mangelhaft programmierte Komponenten könnten das System für die Einschleusung von SQL-Befehlen, für siteübergreifende Skripterstellung oder für Denial-of-Service-Angriffe anfällig machen. Sie müssen sicherstellen, dass die Komponenten die typische Arbeitsauslastung sowie den Spitzenbedarf und Vorgänge mit langer Laufzeit bewältigen können. Zudem müssen Sie sicherstellen, dass die Komponenten keine anderen Prozesse blockieren, indem sie Ereignisse synchron behandeln, und dass die Komponenten eine zuverlässige Eingabeüberprüfung durchführen, sodass Benutzer keine SQL-Anweisungen oder Skripts in Spalten einfügen können, die zum Aktualisieren einer Datenbank oder eines Remotewebsystems verwendet werden.

Kurz gesagt, besteht das Ziel darin, den Schwerpunkt auf eine sichere und skalierbare Serverkonfiguration auf Grundlage von Standardproduktfeatures zu legen. Durch die Arbeit mit wiederverwendbaren, gründlich getesteten Lösungen können Sie die Probleme vermeiden, die durch Erstellen zahlreicher benutzerdefinierter Komponenten entstehen. Es ist sinnvoll, das Front-End dezentralisiert und das Back-End zentralisiert zu halten. Der Schlüssel liegt darin, die Komponenten in einer locker gekoppelten Weise zu integrieren, die die Wiederverwendung vorhandener Lösungen fördert.

Aufteilen der Geschäftslogik

Wie erstellen Sie also flexible Datensammlungslösungen, die auf Ihren Servern konfiguriert werden können? Die beste Strategie besteht darin, die Lösungsarchitektur wie in Abbildung 2 in einzelne Ebenen aufzuteilen: Datenspeicherung, Geschäftslogik und Darstellung oder Benutzeroberfläche. Heutzutage ist die Benutzeroberfläche in der Regel browserbasiert, während sich die Geschäftslogik auf Webanwendungsservern befindet. Diese greifen wiederum auf Datenbanken und nicht relationale Datenrepositorys zu.

Abbildung 2** Eine typische Unternehmenslösung auf Grundlage einer Dreistufenarchitektur **(Klicken Sie zum Vergrößern auf das Bild)

Die Geschäftslogik umfasst häufig Transaktionslogik, um sicherzustellen, dass Transaktionen atomar auf Datenbankverwaltungssysteme angewendet werden. Durch die Geschäftslogik können auch mehrere Dienste mittlerer Ebene über HTTP, Message Queuing, RPCs usw. integriert werden. Die allgemeine Lösungsarchitektur bleibt jedoch im Wesentlichen ein Dreistufenmodell.

Was Abbildung 2 nicht zeigt, ist die Komplexität der Geschäftslogik in einer Unternehmensumgebung. Es sieht so aus, als ob sich der Anwendungsserver in dieser Abbildung lediglich auf das Rendern eines browserbasierten Formulars und auf das Verarbeiten der übermittelten Daten konzentriert. In dieser Darstellung werden jedoch Workflows, die Einhaltung von Bestimmungen sowie Anforderungen an die Informationsverwaltung nicht berücksichtigt. Zur Berücksichtigung dieser Anforderungen müssen Sie die Geschäftslogik in zwei Teile teilen – in die Darstellungslogik und die Informationsverwaltungslogik. Dadurch können Sie nach Bedarf die Komponenten mittlerer Ebene beliebig kombinieren, ohne für jede Lösung Komponenten von Grund auf neu erstellen zu müssen.

Abbildung 3 zeigt diese Architektur. Den Kern bilden die Inhalte oder Daten. Sie sind von der Informationsverwaltungslogik umgeben, die die Inhalte während ihres gesamten Lebenszyklus steuert. Zwischen Darstellungslogik und Informationsverwaltungslogik ist eine Schnittstelle vorhanden, um über die Benutzeroberfläche Zugriff auf die Daten zu bieten.

Abbildung 3** Trennen der Darstellungslogik von der Informationsverwaltungslogik **

Sammeln und Verarbeiten von XML

In SOA-Umgebungen (Service-Oriented Architecture, serviceorientierte Architektur) ist XML der vorherrschende Standard, der zum Definieren und Freigeben von Daten und Datenstrukturen zwischen Komponenten verwendet wird. Daher ist XML eine gute Wahl für Schnittstellen zwischen Darstellungs- und Informationsverwaltungskomponenten.

Die Kommunikation muss auf zweierlei Weise erfolgen: Sie müssen das XML in ein von einem Browser lesbares Dokument sowie als ein vom Formular generiertes XML-Dokument übersetzen. Bis vor kurzem erforderte die Erstellung XML-basierter Formularanwendungen umfangreiche Programmierkenntnisse. Dies traf insbesondere zu, wenn die resultierenden XML-Daten einem Branchenschema entsprechen mussten, um den Informationsaustausch zwischen Organisationen zu erleichtern.

InfoPath 2007 vereinfacht die Entwicklung XML-basierter Formulare erheblich. Ein gründliches Verständnis der XML-Details ist sicherlich hilfreich, Formulardesigner und Poweruser müssen jedoch keine XML-Experten sein, um XML-basierte Formularanwendungen erstellen zu können. Der Formulardesigner importiert einfach ein XML-Dokument oder XML-Schema in InfoPath und ordnet dann die einzelnen Attribut- und Elementknoten aus dieser Datenquelle den Feldern im Formular zu. Ein Formulardesigner kann auch mit einem Webdienst oder einer SQL Server®-Datenbank oder mit einer leeren Vorlage beginnen und ein Formular von Grund auf neu erstellen, während InfoPath automatisch das zugrunde liegende Schema und die Datenbindungen im Hintergrund erstellt.

Die Standardisierung von Formularen mithilfe von InfoPath und XML-Schemas bietet mehrere Vorteile. Wenn Sie bereits über ein klar definiertes XML-Schema verfügen, können Formulardesigner und Entwickler von Workflows und Informationsverwaltungskomponenten Lösungen auf Grundlage der gleichen Datenstrukturen erstellen. Wenn ein Formulardesigner ein Formular von Grund auf neu erstellt, müssen Entwickler bis zur Fertigstellung des Formulars warten, um feststellen zu können, wie es sich auf die zugrunde liegenden Datenstrukturen auswirkt. Nachdem die Datenstrukturen definiert wurden, können in zukünftigen Lösungen, beispielsweise in neuen Formularvorlagen, vorhandene Workflows und Informationsverwaltungskomponenten wiederverwendet werden, wenn sie auf den gleichen Datenstrukturen basieren. Darüber hinaus können zukünftige Workflows und Informationsverwaltungskomponenten mit vorhandenen Formularen und Daten zusammenarbeiten. Wenn Sie Ihre Datensammlungslösungen auf Grundlage festgelegter Branchenschemas erstellen, werden die Ergebnisse noch flexibler. Tatsächlich sind diese Lösungen dann mit Lösungen kompatibel, die von anderen Unternehmen erstellt werden, die die gleichen Schemas verwenden.

Ich habe ein einfaches DirectReports-Schema erstellt, das Mitarbeiter Vorgesetzten zuordnet. Die Vorgesetzten können das resultierende Formular zur Beurteilung der ihnen direkt unterstellten Mitarbeiter verwenden. Im Download zu diesem Artikel, der unter technetmagazine.com/code08.aspx verfügbar ist, finden Sie im Ordner „Direct Reports“ das Schema, das Formular und die Datei „readme.htm“ mit Anweisungen für das erneute Erstellen des Formulars. Das Formular ist einfach aufgebaut, veranschaulicht aber das allgemeine Konzept.

Hierbei ist ein sehr wichtiger Punkt zu beachten: Ich habe in InfoPath keine Überprüfungslogik erstellt. Dennoch erfordert InfoPath, dass Benutzer-ID und E-Mail-Adressen in einem bestimmten Format (domäne\konto und empfänger@domäne.tld) eingegeben werden. Andernfalls ist das resultierende XML-Dokument ungültig. Dies beruht darauf, dass das XML-Schema diese Formate definiert. Sie können das Formular mit ungültigen Daten speichern, aber es nicht senden (siehe Abbildungen 4a und 4b). (Ich habe dem Formular eine Dummysenderegel hinzugefügt, damit Sie dies testen können, ohne tatsächlich Daten an einen Standort zu senden.) Durch die Überprüfung in InfoPath 2007 wird automatisch sichergestellt, dass das Formular vollständig ausgefüllt ist und keine derartigen Fehler aufweist.

Abbildung 4a** Überprüfungsfehler verhindern das Senden eines Formulars durch den Benutzer **(Klicken Sie zum Vergrößern auf das Bild)

Abbildung 4b** Die generierte Fehlermeldung **(Klicken Sie zum Vergrößern auf das Bild)

Das XML-Schema dient als verbindlicher Vertrag zwischen der Darstellungslogik und der Informationsverwaltungslogik. InfoPath sperrt das Schema, damit der Formulardesigner die Datenstrukturen nicht absichtlich ändern kann. Dies ist wichtig, weil durch Ändern eines festgelegten XML-Schemas vorhandene Unternehmenslösungen beschädigt werden können, beispielsweise Workflowmodule, die Sie in Kombination mit der neuen Formularvorlage verwenden möchten.

InfoPath bietet eine Fülle von Features für die Integration erweiterter Darstellungslogik in Formularanwendungen. Sie können Daten aus XML-Dateien, Webdiensten, SharePoint-Bibliotheken und -Listen, Datenbanken usw. nutzen, um sinnvolle Standardwerte zu erhalten. Sie können Feldwerte auf Grundlage der Benutzerauswahl über Regeln ändern, Überprüfungslogik einbeziehen, verwalteten Code für äußerst komplexe Anpassungsanforderungen hinzufügen und die Formularvorlage mithilfe von Forms Service über das Web zugänglich machen. In jedem Fall erreichen die Daten aus dem Formular schließlich die Informationsverwaltungslogik als XML-Dokument, das einer Schemadefinition entspricht.

Arbeiten mit XML oder Metadaten

Sie fragen sich möglicherweise, ob Sie Informationsverwaltungslogik direkt auf das übermittelte XML-Dokument anwenden oder stattdessen einen Parser verwenden sollten, der die erforderlichen Informationen in Metadaten extrahiert. SharePoint unterstützt beide Ansätze. Entwickler sind daran gewöhnt, direkt mit XML-Dokumenten zu arbeiten, Metadaten bieten jedoch eine höhere Flexibilität.

Um dies zu demonstrieren, habe ich einen einfachen Webdienst erstellt, der ein XML-Dokument analysiert, das von dem in Abbildung 4a gezeigten Direct Reports-Formular übergeben wird. (Der Quellcode, die Setupdateien und die Datei „readme.htm“ mit Schritt-für-Schritt-Anweisungen sind im Ordner „XMLParsingWebService“ im Download zu diesem Artikel zu finden.) Der Webdienst liest einfach die Benutzer-ID des Vorgesetzten aus dem XML-Dokument, teilt die Benutzer-ID in Domäne und Benutzername, erstellt eine Nachricht auf Grundlage dieser Bestandteile und löst dann eine generische Ausnahme aus, um die verarbeiteten Informationen in Form einer Pseudofehlermeldung im InfoPath-Formular zurückzugeben und anzuzeigen. Dies ist eine einfache Möglichkeit für das Anzeigen eines Dialogfelds in InfoPath, nachdem Daten übermittelt wurden. Der Webdienst funktioniert hervorragend. Wenn Sie jedoch die zugrunde liegende Datenquelle ändern (wenn Sie beispielsweise in DirectReports.xsd das OrgPerson-Element in „Manager“ umbenennen und das InfoPath-Formular gemäß der Beschreibung in der Datei „readme.htm“ mit dem neuen Schema aktualisieren), tritt ein Fehler beim Webdienst auf. Dies sollte jedoch keine Überraschung darstellen. Das XML-Dokument sieht jetzt anders aus, und der alte XPath-Ausdruck für den Zugriff auf das Element „user-id“ ist ungültig. Die Schemas „OrgPerson“ und „Manager“ stimmen nahezu überein, und die InfoPath-Formulare sowie die gewünschten Verarbeitungsergebnisse sind identisch. Obwohl die Unterschiede minimal sind, müssen Sie dennoch doppelte Webdienste bereitstellen und verwalten.

Dies ist kein guter Ansatz, wenn Sie den Platzbedarf von benutzerdefiniertem Code auf Ihren Anwendungsservern minimieren möchten. Wenn Sie hingegen die XML-Knoten Metadatenfeldern zuordnen und die Verarbeitung auf Grundlage der Metadaten durchführen, können Sie die gleichen Workflows und dieselbe Informationsverwaltungslogik für ähnliche Datenstrukturen verwenden, selbst wenn sich die XML-Schemas unterscheiden. Sie müssen nur sicherstellen, dass das untergeordnete Element dem richtigen Metadatenfeld zugeordnet wird und dass das Datenformat die Verarbeitungsanforderungen erfüllt – dann können Sie den vorhandenen Code wiederverwenden.

Die Zuordnung von XML-Knoten zu Metadatenfeldern ähnelt dem Binden von XML-Knoten an Steuerelemente der Benutzeroberfläche in einem InfoPath-Formular, wie in Abbildung 5 dargestellt. In SharePoint entsprechen Metadatenfelder Spalten, die auf der Website- oder Listenebene definiert sind und auf die in Inhaltstypdefinitionen verwiesen wird. Inhaltstypen definieren die Merkmale von Inhaltselementen wie Metadatenfeldern, Workflows und Formularen. Um die Metadatenfelder eines Inhaltstyps mit den entsprechenden Knoten im zugeordneten XML-Dokument synchron zu halten, verwendet SharePoint einen integrierten XML-Parser, der die Herauf- und Herabstufung von Eigenschaften durchführt. Während der Eigenschaftenheraufstufung extrahiert der XML-Parser Knotenwerte aus einem XML-Dokument in entsprechende Spalten in der Dokumentbibliothek. Als „Eigenschaftenherabstufung“ wird der umgekehrte Prozess bezeichnet, bei dem Spaltenwerte aus der Dokumentbibliothek genommen und in das Dokument zurückgeschrieben werden. Der wichtigste Punkt besteht darin, dass der XML-Parser die Metadatenfelder und die zugeordneten XML-Knoten synchron hält.

Abbildung 5** XML-Schemazuordnungen zwischen InfoPath und SharePoint **(Klicken Sie zum Vergrößern auf das Bild)

Wenn Sie das SharePoint-Objektmodell verwenden, können Ihre Webparts, Workflows und die Informationsverwaltungslogik mit Metadatenfeldern sowie mit den zugrunde liegenden XML-Dokumenten arbeiten. Durch Ändern des Werts eines zugeordneten Metadatenfelds wird der Knotenwert im XML-Dokument geändert und umgekehrt. Dennoch wird durch die direkte Arbeit mit dem XML-Dokument die Geschäftslogik eng mit dem XML-Schema verbunden. Andererseits erhöhen zugeordnete Metadatenfelder die Wiederverwendbarkeit des Codes. Natürlich müssen Sie entscheiden, welcher Ansatz für Ihre Umgebung der richtige ist, in den meisten Fällen bieten jedoch SharePoint-Lösungen, die auf Metadatenfeldern basieren, eine höhere Flexibilität und mehr Möglichkeiten zur Wiederverwendung von Code.

Um zu veranschaulichen, wie XML-Knoten mittels SharePoint Metadatenfeldern zugeordnet werden, habe ich ein SharePoint-Feature zur Bereitstellung einer benutzerdefinierten Dokumentbibliothek in das Begleitmaterial einbezogen (siehe Datei „OrgPersonContentType.xml“ im Ordner „OrgPersonLib“ im Download zu diesem Artikel). Der Inhaltstyp „OrgPerson“ verweist auf vier Felder: UserID, FullName, EMail und Direct_x0020_Reports. FullName und EMail sind vordefinierte Felder. UserID und Direct_x0020_Reports sind benutzerdefinierte Felder, die in OrgPersonSiteColumns.xml definiert sind.

Die Felddefinitionen sind relativ einfach. Es ist möglich, Felder direkt in den Felddefinitionen an XML-Knoten zu binden, diese Informationen können jedoch auch in den Inhaltstypen überschrieben werden. Ich habe mich für die Verwendung des letzteren Verfahrens entschieden, weil ich dadurch die benutzerdefinierten Felder in nicht mit XML-Dokumenten in Verbindung stehenden Inhaltstypen sowie in Inhaltstypen, die auf verschiedenen XML-Strukturen basieren, verwenden konnte. Der Inhaltstyp „OrgPerson“ bindet die Metadatenfelder an XML-Knoten, die in ihrer Anordnung dem bereits beschriebenen Schema „OrgPerson“ entsprechen. Es ist auch eine Datei namens „AdditionalContentTypes.xml“ vorhanden, die weitere Inhaltstypen definiert, die dieselben Metadatenfelder an unterschiedliche XML-Knoten binden. Sie können die Unterschiede erkennen, wenn Sie die XPath-Ausdrücke in den Node-Attributen betrachten.

In Dokumentbibliotheken vom Typ „OrgPersonLib“ können verschiedene Arten von XML-Dokumenten gespeichert werden, während die Knotenwerte über die gleichen Bibliotheksspalten verfügbar gemacht werden. Dieses einfache Zuordnungsverfahren ermöglicht Ihnen auch die Wiederverwendung von Workflows und Informationsverwaltungslogik, da die vier Inhaltstypen (OrgPerson, Manager, Supervisor und User) auf einen gemeinsamen Satz von Metadatenfeldern verweisen.

Abbildung 6 zeigt das FieldRef-Element aus dem Inhaltstyp „OrgPerson“ für Direct_x0020_Reports, der das Feld den user-id-Knoten von direkt unterstellten Mitarbeitern gemäß dem XPath-Ausdruck „/OrgPerson/direct-report/user-id“ zuordnet. Da das XML-Dokument mehrere Einträge für direkt unterstellte Mitarbeiter enthalten kann, ist es wichtig, dass Sie ein Aggregation-Attribut angeben. Dieses definiert, wie der XML-Parser die zurückgegebene Auflistung von Werten behandelt. Wenn Sie dieses Attribut auslassen, extrahiert der XML-Parser nur den ersten Knotenwert. Unterstützte Aggregationswerte sind „sum“, „count“, „average“, „min“, „max“, „merge“, „plain text“, „first“ und „last“.

Abbildung 6** Einem XPath-Ausdruck zugeordnetes Metadatenfeld **(Klicken Sie zum Vergrößern auf das Bild)

Alle Beispielinhaltstypen verwenden die Standardseite „upload.aspx“ als DocumentTemplate, sodass Sie XML-Dateien in die Dokumentbibliothek hochladen können, wenn Sie auf der SharePoint-Benutzeroberfläche auf die Schaltfläche „Neu“ klicken. Solange Sie Dateien mit der Dateinamenerweiterung „.xml“ hochladen, ruft SharePoint automatisch den integrierten XML-Parser auf (eine Ausnahme bilden WordProcessingML-Dateien, für die SharePoint einen WordProcessingML-Parser aufruft). Der XML-Parser untersucht die hochgeladene XML-Datei, um den zugeordneten Inhaltstyp zu bestimmen. Dadurch kann er die Knotenwerte aus den in den Felddefinitionen angegebenen Speicherorten extrahieren und die Eigenschaftenheraufstufung durchführen. (Sie können diesen Prozess überprüfen, wenn Sie die im Ordner „OrgPersonLib\XMLFiles“ enthaltene Datei „OrgPerson.xml“ hochladen.) Die Struktur dieses XML-Dokuments entspricht den in der Definition des Inhaltstyps „OrgPerson“ angegebenen XPath-Ausdrücken. Dementsprechend extrahiert SharePoint die Daten aus der XML-Datei, schreibt die Daten in die entsprechenden Bibliotheksspalten und zeigt sie auf der Seite „EditForm.aspx“ an, damit Sie die nicht als schreibgeschützt markierten Dokumenteigenschaften überprüfen und aktualisieren können. Abbildung 7 zeigt das Formular „EditForm.aspx“ mit den aus OrgPerson.xml extrahierten Daten.

Abbildung 7** Formular „EditForm.aspx“ mit extrahierten Daten **(Klicken Sie zum Vergrößern auf das Bild)

Wenn Sie den Wert von „User ID“, „Full Name“ oder „E-Mail“ in EditForm.aspx ändern, führt SharePoint eine Eigenschaftenherabstufung durch, um die Knotenwerte im zugrunde liegenden XML-Dokument zu ändern. Beachten Sie jedoch, dass SharePoint nur dann XML-Schemaeinschränkungen durchsetzt, wenn Sie die erforderliche Logik selbst im Formular implementieren.

SharePoint führt auch nicht die Darstellungslogik einer Formularanwendung aus. Wenn Sie beispielsweise die Benutzer-ID ändern, überprüft SharePoint nicht, ob der neue Wert den NetBIOS-Konventionen entspricht, und aktualisiert nicht automatisch die Felder „Full Name“ und „E-Mail“ entsprechend der neuen Auswahl. Daher sollten Sie die entsprechende Spalte in der Inhaltstypdefinition als schreibgeschützt markieren, wenn die Änderung eines einzelnen Felds zu Inkonsistenzen führen kann. Dadurch ist der Benutzer gezwungen, die Formularanwendung, beispielsweise InfoPath, zum Aktualisieren der Daten zu verwenden. Zudem reicht der XML-Parser alle Änderungen aus dem XML-Dokument an die entsprechenden Metadatenfelder in SharePoint weiter.

Im Beispiel „OrgPersonLib“ können Sie jede der XML-Dateien aus dem Ordner „OrgPersonLib\XMLFiles“ hochladen. In den XML-Dateien werden ganz andere Datenstrukturen verwendet, SharePoint erkennt jedoch die Inhaltstypen und reicht die richtigen Knotenwerte an die Websitespalten weiter. Dies beruht darauf, dass ich eine Verarbeitungsanweisung in den XML-Dateien verwendet habe, um die XML-Dokumente ihren entsprechenden Inhaltstypen zuzuordnen. Die Datei „OrgPerson.xml“ enthält diese Informationen jedoch nicht, was aber kein Problem darstellt. Wenn SharePoint ein XML-Dokument nicht über eine Verarbeitungsanweisung oder die Dokumentvorlage einem Inhaltstyp zuordnen kann, verwendet es den Standardinhaltstyp. Im Fall von „OrgPersonLib“ ist dies der Inhaltstyp „OrgPerson“, und daher wird das XML-Dokument korrekt analysiert.

Abbildung 8 zeigt, wie Sie ein XML-Dokument explizit einem Inhaltstyp zuordnen können. Die Verarbeitungsanweisung „MicrosoftWindowsSharePointServices“ definiert ContentTypeID als 0x010100668E393E4F0EFF4294DBD202D5D8321D. Dabei handelt es sich um die ID des Inhaltstyps „User“, wie in AdditionalContentTypes.xml definiert.

Abbildung 8** Verarbeitungsanweisungen und XML-Daten der Beispieldatei „User.xml“ **(Klicken Sie zum Vergrößern auf das Bild)

Der XML-Parser verarbeitet die Verarbeitungsanweisung „MicrosoftWindowsSharePointServices“ und schreibt den Wert von ContentTypeID in das Metadatenfeld „ContentType“. Alle SharePoint-Inhaltstypen haben dieses Metadatenfeld gemein, weil es auf der Stammebene im Inhaltstyp „System“ definiert ist. Wenn Sie die Datei „fieldswss.xml“ (im Ordner „%CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Fields“) auf einem SharePoint-Server öffnen und nach „MicrosoftWindowsSharePointServices“ suchen, können Sie sehen, wie SharePoint die Verarbeitungsanweisung dem Feld „ContentType“ zuordnet. Das PITarget-Attribut zeigt auf MicrosoftWindowsSharePointServices (dies ist die Verarbeitungsanweisung), und PIAttribute zeigt auf ContentTypeID (enthält die ID des Inhaltstyps „User“).

Inhaltstypzuordnungen in InfoPath

Die technischen Einzelheiten von XML-Analyse und Inhaltstypzuordnungen schüchtern viele Formulardesigner ein, alle wesentlichen Details können jedoch InfoPath 2007 überlassen werden. Die zum OrgPersonLib-Beispiel gehörige Datei „readme.htm“ enthält Anweisungen für die Veröffentlichung der Formularvorlage „Direct Reports“ in SharePoint und für die Erstellung eines Inhaltstyps, der erneut an die gleichen Metadatenfelder (UserID, FullName, EMail und Direct_x0020_Reports) gebunden wird. Sie können den neuen Inhaltstyp problemlos der Dokumentbibliothek „OrgPersonLib“ in der Benutzeroberfläche von SharePoint hinzufügen. Der neue Inhaltstyp zeigt jedoch auch auf die InfoPath-Formularvorlage als die Dokumentvorlage, die die Formularanwendung aufrufen soll, wenn vorhandene XML-Dokumente aktualisiert werden. Abbildung 9 zeigt, wie der Veröffentlichen-Assistent von InfoPath die Eigenschaftenzuordnung zwischen XML-Knotenwerten und SharePoint-Websitespalten vereinfacht. Wenn Sie die Knotenwerte vorhandenen Websitespalten zuordnen, können Sie vorhandene SharePoint-Komponenten wiederverwenden.

Abbildung 9** Eigenschaftenzuordnung in InfoPath 2007 **(Klicken Sie zum Vergrößern auf das Bild)

Zusammenfassung

Zusätzliche Onlineressourcen

• InfoPath 2007-Teamblog
• W3C-XML-Schemaspezifikationen und -entwicklung
• Einführung in XML-Schemas
• Workflows in Office SharePoint Server 2007
• InfoPath 2007 Forms Services

Mit den in Office verfügbaren Technologien können Unternehmensarchitekten Datensammlungslösungen erstellen, die die Wiederverwendung von Code und den Informationsaustausch direkt fördern. InfoPath 2007 ermöglicht Abteilungen das Erstellen von Lösungen, die Informationen aus verschiedenen Quellen abrufen können, und die Daten können dann an verschiedene Systeme wie beispielsweise SharePoint übertragen werden. SharePoint bietet zudem Entwicklern einen umfassenden Satz von Webdiensten und Schnittstellen zum Erstellen von Workflows und Informationsverwaltungskomponenten. Durch das Hosten dieser Komponenten auf zentralen SharePoint-Servern verfügen Abteilungen dann über die Infrastruktur, die sie für die Erstellung ihrer individuellen Anwendungen benötigen.

Gleichzeitig können einzelne Abteilungen schneller eigene Datensammlungslösungen erstellen. Vorschriften hinsichtlich der Einhaltung von Bestimmungen und andere globale Geschäftsanforderungen können auf abteilungsübergreifender Ebene berücksichtigt werden, und die Verwaltbarkeit und Zuverlässigkeit der IT-Umgebung wird durch Verwenden einer geringeren Anzahl benutzerdefinierter Komponenten auf Anwendungsservern erhöht.

Keith Deshaies ist als freiberuflicher technischer Redakteur und als IT-Analyst für ein großes Telekommunikationsunternehmen tätig. Er ist auf Microsoft Office- und SharePoint-Technologien spezialisiert und Mitglied der Society for Technical Communications.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.