Business Connectivity Services

Verwalten von Mitarbeiterboni mit Office und SharePoint BCS

Ying Xiong

Die Verwaltung von Mitarbeiterboni ist für alle Unternehmen eine geschäftskritische Aufgabe. Dies gilt besonders für große Unternehmen wie Microsoft. Bei Microsoft bieten wir viele verschiedene Arten von Boni für die berechtigten Mitarbeiter an, wie erfolgsbasierte Gehaltserhöhungen, Beförderungen, Boni, Aktion und andere Vergütungsarten. Die Verwaltung dieser Boni entsprechend Unternehmensrichtlinien und -budgets (nach Regionen, Unternehmenseinheit oder -abteilung, Mitarbeitergehaltsplan und Gehaltsstufe) ist ein komplexer Prozess.

Viele Unternehmensvorschriften sind beteiligt, wenn es um Boni für Mitarbeiter geht. Unter anderem stellen diese Vorschriften sicher, dass unsere besten Mitarbeiter auf allen Ebenen die höchsten Boni erhalten, während die Unternehmenseinheiten insgesamt ihre Ziele erreichen und innerhalb ihrer Budgets und Richtlinien bleiben. Jedes Jahr analysieren Manager und Mitarbeiter der Personalabteilung die Zahlen und legen die Richtlinien und Grenzwerte für alle Boni auf allen Ebenen fest. Dieser Prozess (die Kalibrierung) ist zeitaufwendig und kompliziert.

Das aktuelle Bonusverwaltungstool, das von unseren Managern und den Mitarbeitern der Personalverwaltung verwendet wird, ist eine Windows Forms-Anwendung. Das Tool funktioniert wie vorgesehen, erfüllt jedoch nicht alle Anforderungen. Es gibt eine Reihe von Möglichkeiten, es zu verbessern, um die Kalibrierung zu vereinfachen und zu optimieren.

Als Reaktion auf Vorschläge zur Verbesserung der Kalibrierungstools haben die Produktteams für Microsoft IT (MSIT), HR Business, Microsoft Office und SharePoint zusammen eine neue Lösung auf der Basis von Microsoft Business Connectivity Services (BCS) entwickelt, einem Feature von Microsoft Office 2010 und SharePoint 2010. BCS stellt den Lese/Schreibzugriff für externe Daten aus Branchenanwendungen, Webdiensten, Datenbanken sowie SharePoint- und Office-Anwendungen bereit.

Die neue Lösung verwendet Microsoft Excel 2010 als Benutzeroberfläche für die Bonusverwaltung und nutzt BCS-Technologie, um die Mitarbeiterdaten und Geschäftsregeln zwischen den lokalen Computern der Benutzer und Back-End-Systemen (Rewards Web Services und eine SQL Server-Datenbank) zu speichern und zu synchronisieren.

In diesem Artikel beschreibe ich die Erfahrungen der Microsoft-Teams bei der Entwicklung und Bereitstellung der BCS-Lösung für die Bonusverwaltung.

Der Beginn

Das vorhandene Bonusverwaltungstool war für die Unterstützung einer integrierten Leistungsverwaltungsumgebung für die Mitarbeiterbeurteilung, die Kalibrierung, Bewertungen und Boni mittels eines einzigen kohärenten Toolsets entwickelt worden. Abbildung 1 zeigt die Architektur des vorhandenen Tools. Bei diesem Tool handelt es sich um eine typische dreischichtige Anwendung. Die Benutzeroberfläche ist eine Windows Forms-Anwendungen, die Daten aus den Back-End-Webdiensten liest und in diese schreibt. Diese Dienste fragen Mitarbeiterberichte, Geschäftsregeln und andere Referenzdaten in einer SQL Server-Datenbank ab.

Abbildung 1 Architektur des aktuellen Bonusverwaltungstools

Die Lösung sollte den Netzwerkverkehr zwischen den Computern der Benutzer und den Webservern minimieren, auf denen die Webdienstkomponente gehostet wurde. Wenn die Clientanwendung gestartet wird, ruft sie alle notwendigen Referenzdaten, Geschäftsregeln und Mitarbeiterberichte ab und speichert diese zwischen. Dies gilt für die Abteilung, für die der jeweilige Benutzer Zugriffsberechtigungen hat. Der größte Teil der Geschäftslogik und Geschäftsregeln der Bonusverwaltung werden in der Clientkomponente implementiert. Dort werden die entsprechenden Geschäftsregeln abgefragt, wenn der Benutzer Mitarbeiterboni zuweist oder ändert, um die Änderungen zu validieren, ohne die Webdienste im Back-End aufzurufen.

Die Webdienstkomponente wurde auf der Basis des Microsoft .NET Framework 2.0-Webdienstframeworks (ASP.NET Web Services) entwickelt. Wie bereits erwähnt, sendet diese Mitarbeiterberichte und Geschäftsregeln an die Clientanwendung und speichert Änderungen an den Daten, die von den Clients an die Datenbank geleitet werden. Im Webdienst ist eine Geschäftsvalidierungslogik implementiert, um die Integrität der Daten vor dem Speichern in die Datenbank sicherzustellen. Alle Webdienstaufrufe sind als synchrone Methoden entworfen.

Den Benutzern werden Fehlermeldungen angezeigt, wenn die Webdienstaufrufe zu Fehlern führen, und sie können entsprechend der Art der Fehler Maßnahmen ergreifen. Außerdem wurde der Webdienst für die Serialisierung der Mitarbeiterberichte und anderer Daten in einem Bytearray entworfen, sodass das Bytearray an die Clients zurückgegeben wird, um den Umfang der Datenübertragung zwischen den Webdienstservern und der Clientanwendung zu minimieren.

Schließlich werden die Bonusdaten in einer relationalen Datenbank gespeichert, die in Microsoft SQL Server 2005 implementiert ist. Diese Datenbank speichert alle Daten, die für die Verwaltung der Mitarbeiterboni benötigt werden sowie die Verlaufsdaten für frühere Kalibrierungsperioden.

Wie ich bereits erwähnt habe, funktionierte diese Anwendung im Großen und Ganzen wie geplant und bedeutete eine wesentliche Verbesserung im Vergleich zu früheren Bonus- und Kalibrierungssystemen. In der Praxis entdeckten wir jedoch zahlreiche Bereiche, in denen wir das Tool verbessern konnten, um die Kalibrierung einfacher und weniger zeitaufwendig zu gestalten. Damit Sie die Gründe für die Designentscheidungen für den neuen Dienst verstehen können, betrachten wir nun einige der Probleme, die wir in der alten Lösung entdeckt hatten.

Das erste, und wahrscheinlich wichtigste, Problem mit dem alten Kalibrierungstool bestand darin, dass es schwierig war, Boni zu modellieren. Während der Kalibrierung müssen Manager den Ausgleich zwischen zwei Variablen herstellen. Jeder Mitarbeiter muss entsprechende Boni auf der Basis einer Leistungsbeurteilung erhalten. Die jeweilige Abteilung muss jedoch ein vordefiniertes Bonusbudget berücksichtigen. Die Herstellung dieses Ausgleichs ist zeitaufwendig. Manager müssen die Mitarbeiterbonuszahlen eingeben, betrachten, wie diese das Bonusbudget des Teams beeinflussen und die Boni anpassen, so dass sie sowohl den Bonusregeln als auch dem Budget entsprechen. Dies kann zu mehreren Iterationen führen, bis die Boni abschließend festgelegt werden können.

Das vorhandene Tool ermöglichte diesen Prozess des Ausgleichens zwischen Boni und Budgets nicht. Es verfügte über keine diesbezügliche Funktionalität, sodass für die einzelnen Boni verschiedene Zahlen eingegeben und die Ergebnisse im Hinblick auf die Auswirkungen auf Budgets und Richtlinien analysiert werden konnten. Stattdessen mussten die Manager häufig die Mitarbeiterdaten in ein Excel-Arbeitsblatt exportieren und die Bonus- und Budgetzahlen manuell modellieren.

Wenn die Kalibrierung abgeschlossen und die Boni für die einzelnen Mitarbeiter festgelegt wurden, müssen die Manager die Daten manuell in das Tool eingeben und die Boni zur Genehmigung absenden.. Diese doppelte Dateneingabe ist ebenfalls zeitaufwendig.

Das Windows Forms-Tools setzt voraus, dass die Benutzer online sind und sich im Unternehmensnetzwerk befinden, da die Tools für die Lese- und Schreibvorgänge Zugriff auf die Back-End-Webdienste benötigen. Dies bedeutet weiteren Aufwand für Mitarbeiter, deren Terminkalender voll ist oder die häufig auf Reisen sind.

Schließlich stellte das vorhandene Bonusverwaltungstools zwar integrierte Berichte bereit, wir erhielten jedoch zahlreiche Anfragen nach zusätzlichen Berichten und flexiblen Ad-Hoc-Berichtsfunktionen, um die Kalibrierung transparenter und effizienter zu gestalten.

BCS-Grundlagen

Mit BCS können Sie Office-Anwendungen (Excel, Outlook, InfoPath, Word usw.) sowie SharePoint für die Verarbeitung von Daten aus Back-End-Systemen verwenden. Wie ich bereits erwähnt habe, ist BCS eine Komponente sowohl von Office 2010 als auch von SharePoint 2010. Es ist daher sowohl auf Clients als auch auf Servern verfügbar. (Weitere Informationen zu den BCS-Tool- und Laufzeitkomponenten finden Sie auf msdn.microsoft.com/library/ee556826.)

Beim Entwerfen einer BCS-basierten Lösung beginnen Sie mit der Definition eines Entitätsmodells, das Verbindungen mit externen Systemen herstellen und der BCS-Struktur Daten aus diesen externen Datenstrukturen zuordnen kann. Dieses Entitätsmodell wird External Content Type (ECT) genannt. Sie können so viele ECTs erstellen, wie Sie für Ihre Lösung benötigen. Dazu dienen Share Point Designer oder Visual Studio.

Die ECT-Metadaten, darunter auch der Code für die Definition des Entitätsmodells, werden in einem SharePoint-Metadatenspeicher gespeichert. Das veröffentlichte ECT-Modell kann heruntergeladen und auf den Clientcomputern der Benutzer mittels eines SharePoint-Arbeitsbereichs oder eines unabhängigen Verpackungstools von BCS installiert werden.

Zur Laufzeit ruft die BCS-Laufzeitkomponente auf dem Client oder auf dem Server das ECT-Modell auf, um mit externen Systemen zu kommunizieren. Auf dem Client werden die Daten aus den externen Systemen in einer SQL Server Compact Edition (SQL CE)-Datenbank zwischengespeichert. Die zwischengespeicherten Daten können anschließend in mittels der BCS-APIs in Office-Anwendungen angezeigt und bearbeitet werden. Die Änderungen an den zwischengespeicherten Daten durch die Benutzer werden auf den Computern der Benutzer in derselben SQL CE-Datenbank in eine Warteschlange eingereiht. Die BCS-Laufzeitkomponente ist anschließend für die Aktualisierung der Änderungen zu externen Systemen auf der Basis des ECT-Modells verantwortlich.

Das neue Bonustool

Für das neue Bonusverwaltungstool haben wir eine Lösung auf der Basis des BCS-Frameworks entwickelt. Excel dient als Benutzeroberfläche der Bonusverwaltung, um die früher beschriebenen Probleme zu vermeiden. In dieser Excel/BCS-Lösung definierten wir insgesamt 15 ECTs für Mitarbeiterdaten, Geschäftsregeln und andere Referenzdaten. Die BCS-Laufzeit verwendet diese ECTs. um Verbindungen zu vorhandenen Webdiensten für die Bonusverwaltung (als externen Systemen) herzustellen und Mitarbeiter- sowie Geschäftsregeldaten abzurufen und zwischenzuspeichern.

Die Mitarbeiterdaten werden in einem Excel-Arbeitsblatt mittels eines Excel-Add-Ins gerendert, das APIs des lokalen BCS-Zwischenspeichers verwendet. Die Manager können die Mitarbeiterboni vollständig innerhalb von Excel zuweisen, kalibrieren und verwalten und dennoch weiterhin alle Geschäftsregeln auf der Basis der Regeldaten durchsetzen, die im lokalen BCS-Speicher zwischengespeichert sind, auch wenn die Manager nicht online sind. Mithilfe der Excel/BCS-Lösung können Manager eine Liste ausgewählter Mitarbeiter (im Excel-Arbeitsblatt) und verschiedene Statistiken (im Excel-Aufgabenbereich) auf demselben Bildschirm anzeigen. Die Statistiken am unteren Rand werden dynamisch anhand der Bonuswerte aktualisiert. Es werden unterschiedliche Statistiken angezeigt, abhängig von dem Feld, das der Benutzer ausgewählt hat. Dies ist eine wesentlich verbesserte Umgebung für die Benutzer.

Mithilfe der systemeigenen Excel-Funktionalität, wie Pivot-Tabellen und Diagrammen, können Manager und Mitarbeiter der Personalabteilung verschiedene Berichte für die von BCS zwischengespeicherten Daten erstellen und visualisieren. Dies steigert die Produktivität. Mittels Excel-Vorlagen können Benutzer Berichte einfacher erstellen. Die Berichte müssen nicht von der IT entwickelt werden.

Abgesehen von den geschäftlichen Vorteilen entdeckten wir bei der Entwicklung der neuen Bonusverwaltungslösung einen interessanten technischen Vorteil. Wir konnten die vorhandene Bonuswebdienstkomponente in der BCS-Lösung nutzen, obwohl die Webdienste nicht für BCS entworfen oder optimiert worden waren. Wir konnten außerdem in der Excel-Add-In-Lösung die vorhandenen Geschäftsregel-Datenobjekte und den vorhandenen Validierungscode nutzen. Daher konnten wir die neue Lösung in vergleichsweise kurzer Zeit bereitstellen und vorführen.

Lösungsarchitektur

Die Architektur der neuen Lösung wird in Abbildung 2 gezeigt. Wie Sie sehen können, wurden die Änderungen der ursprünglichen Architektur nur für die Clientarchitekturkomponente durchgeführt. In Im Diagramm stellen die grünen Felder BCS-Komponenten dar, die bereits auf den Computern der Benutzer installiert sind, wenn diese Office 2010 installieren. Die blauen Felder bezeichnen die Komponenten, die für die neue Lösung entwickelt wurden, und die hellblauen Felder sind die Komponenten des vorhandenen Bonusverwaltungstools.

Abbildung 2 Architektur der neuen Bonuslösung

Wenn die ECTs für die neue Bonuslösung auf dem Computer eines Benutzers installiert werden, ruft der BCS-Synchronisierungsprozess (BCSSync.exe) sofort das Entitätsmodell auf, um die Daten für jeden im Modell definierten ECT von den externen Bonuswebdiensten abzurufen. Welche Daten tatsächlich synchronisiert werden, ist abhängig von den Datenzugriffsberechtigungen des Benutzers (die er über Webdienste für die Benutzersicherheit erhält). Dieser Schritt setzt voraus, dass der Benutzer online ist, um auf die Webdienste zugreifen zu können.

Die abgerufenen Daten, wie z. B. Mitarbeiterberichte einer Abteilung, werden in einer SQL CE-Datenbank gespeichert, die vom BCS-Synchronisierungsprozess als lokaler Datencache für den Benutzer erstellt wurde. Die Daten in SQL CE werden mittels des Zertifikats des Benutzers verschlüsselt und sind auf Benutzerebene sicher.

Der BCS-Synchronisierungsprozess wird regelmäßig ausgeführt, um den lokalen Cache des Benutzers mit dem Bonusserver zu synchronisieren, um die Änderungen auf dem Server zu erhalten. Das BCS-Framework ermöglicht die unabhängige Definition der Synchronisierungshäufigkeit für jede einzelne ECT. Das bedeutet, dass wir eine niedrigere Synchronisierungshäufigkeit (Stunden oder Tage) für selten geänderte Entitäten wie Geschäftsregeln festlegen können, und eine höhere Synchronisierungshäufigkeit (Minuten oder Stunden) für Bonusdaten festlegen können, die während des Beurteilungszeitraums möglicherweise häufig geändert werden.

Da die Daten zu Mitarbeitern, Geschäftsregeln und anderen Bereichen auf dem Computer des Benutzers zwischengespeichert werden, kann der Benutzer das Bonusverwaltungstool einfach durch das Öffnen von Excel starten. Das Excel-Add-In verwendet die BCS-API für den Abruf der Daten aus der SQL CE-Datenbank und bindet die Daten in ein Excel-Arbeitsblatt ein. Ab diesem Punkt kann der Benutzer die Mitarbeiterberichte und die Bonusdaten in Excel anzeigen. Diese Excel-Datei unterscheidet sich nicht von den anderen Excel-Dateien, die Sie normalerweise erstellen oder verwenden. Der Benutzer kann systemeigene Excel-Funktionen nutzen, um die Daten zu bearbeiten und zu analysieren.

Wenn der Benutzer Änderungen im Arbeitsblatt vornimmt, um Mitarbeiterboni wie den Prozentsatz für eine Gehaltserhöhung, einen Beförderungsbetrag oder Aktienanteile, werden die entsprechenden Geschäftsregeln initialisiert, um diese Änderungen zu validieren und zu verarbeiten. Wir erreichen dies, indem wir die Wertänderung einer Excel-Zelle mit dem vorhandenen Geschäftsregelcode verknüpfen.

Darüber hinaus können einige Mitarbeiterdaten wie die Personalnummer, der Positionstitel und die E-Mail-Adresse nicht von den Benutzern geändert werden. Wir erreichen dies, indem wir die systemeigene Excel-Schutzfunktion verwenden.

Wenn der Benutzer bereit ist (offline oder online), die Änderungen an den Back-End-Server zu übermitteln, werden die Änderungen in eine lokale Warteschlange eingereiht, die in der SQL CE-Datenbank gespeichert ist. Der BCS-Synchronisierungsprozess ruft die Änderungen einzeln aus der Warteschlange ab und sendet sie an die Rewards Web Services im Back-End. Wenn der Benutzer offline ist oder die Back-End-Webdienste nicht verfügbar sind, wiederholt BCS den Prozess solange, bis der Benutzer online ist oder die Webdienste verfügbar sind.

Wenn der Benutzer noch nicht bereit ist, die Änderungen an den Back-End-Server zu übermitteln und die Änderungen als Entwurf speichern möchte, wird dies als ein normaler Excel-Speicherungsvorgang behandelt.

Definieren von ECTs

Wie bereits ausgeführt, besteht in jedem BCS-Projekt ein wichtiger erster Schritt darin, die ECTs für die Lösung zu erstellen. Das Entwerfen von ECTs bedeutet, dass Sie die Datenentitäten modellieren, die Sie in der Office- oder SharePoint-Lösung verwenden werden. Die Anzahl der ECTs und die Datenstruktur für die einzelnen ECTs sind abhängig von der Art der Anwendungsdaten, der Art der Verwendung der Daten in der Anwendung und den Schnittstellen der externen Systeme.

Da die Daten für die ECT-Entitäten aus externen Systemen stammen (in unserem Fall Rewards Web Services), ist es am einfachsten, wenn Sie die Entitäten genau wie die von den externen Systemen zurückgegebenen Typen modellieren. Dabei wird keine Datenzuordnung zwischen den Strukturen erforderlich. Dies ist jedoch nicht immer möglich, besonders dann nicht, wenn die externen Webdienste Daten zurückgeben, die komplex sind und eine tiefe Hierarchie aufweisen. Dies war beim Bonusverwaltungssystem der Fall.

Die vorhandenen Rewards Web Services geben ein serialisiertes Bytearray zurück (für Mitarbeiter- und Geschäftsregeldaten), die auf dem Client zu angepassten System.Data.DataTable-Typen deserialisiert werden müssen. Diese angepassten Datentypen werden standardmäßig in BCS nicht unterstützt.

Die ECT-Implementierung des neuen Bonussystems definiert für Mitarbeiter- und Geschäftsregelentitäten eine vergleichsweise flache Datenstruktur (mit einfachen Datentypen). Sie konvertiert außerdem die Daten aus den angepassten Datentabellen (nach der Deserialisierung) in die flache ECT-Struktur, bzw. ordnet diese zu. Wenn die Benutzer mittels der ECTs aktualisieren, konvertieren wir die Daten zu angepassten Datentabellentypen zurück und senden die Änderungen an die Back-End-Webdienste.

Für jeden ECT müssen mindestens zwei Methoden definiert werden. Die Finder-Methode wird von der BCS-Laufzeit aufgerufen, um alle Daten herunterzuladen. Im Fall des Mitarbeiter-ECT werden alle Mitarbeiterberichte zurückgegeben, zu denen der Benutzer über eine Zugriffsberechtigung verfügt. Wenn ein ECT auf einem Clientcomputer installiert wird, wird durch den Installationsvorgang ein Abonnement auf der Basis der Finder-Methode für die BCS-Laufzeit erstellt, um den ECT regelmäßig zu synchronisieren.

Die SpecificFinder-Methode gibt die spezifische Instanz der Daten (Mitarbeiter) auf der Basis des Entitätsidentifizierers (Personalnummer) zurück. SpecificFinder wird von der BCS-Laufzeit verwendet, um die Mitarbeiterinstanz mit dem Back-End-Server zu synchronisieren. Im Fall von Datenentitäten, die Benutzer clientseitig aktualisieren, wie Mitarbeiterdatensätze, stellen die ECTs eine Aktualisierungsmethode bereit, die die BCS-Laufzeit für das Senden von Updates an den Server aufrufen kann. Wenn ein Benutzer für eine Entität neue Datensätze erstellen muss, ist im ECT auf ähnliche Weise eine Erstellungsmethode definiert. Referenzdatenentitäten, die von den Benutzern nicht geändert werden, benötigen die Update- oder Erstellungsmethoden für ihre ECTs nicht.

In Ihren eigenen ECT-Implementierungen können Sie jede Geschäftslogik hinzufügen, die Sie für die Validierung oder Verarbeitung von Daten benötigen, bevor die externen Webdienste aufgerufen werden. Dies stellt eine hervorragende Entwurfsoption in BCS dar, mit der Sie die Geschäftslogik direkt in Ihre ECTs integrieren und diese auf dem Client und auf dem Server ausführen können.

Es gibt zwei Möglichkeiten zum Entwerfen und Erstellen von ECTs. Wenn die externen Systeme vergleichsweise flache und stark typisierte Datentypen zurückgeben, können Sie SharePoint Designer für die Generierung der ECTs verwenden. SharePoint Designer generiert ECTs auf der Basis externer Systemschnittstellen, Vorgangs- und Datendefinitionen im Fall von Windows Communication Foundation (WCF)-Webdiensten. Zu diesem Zeitpunkt unterstützt SharePoint Designer jedoch keine komplexen und angepassten Typen wie angepasste Datensätze und Datentabellen.

Die zweite und leistungsfähigere Methode stellt die Verwendung von Visual Studio zum Entwerfen und Erstellen von ECTs dar. Visual Studio 2010 enthält eine Projektvorlage für die Erstellung von BCS-Entitätsmodellen. Diesen Ansatz verwenden wir in der Bonuslösung.

ECT-Bereitstellung und -Installation

Damit das Bonusverwaltungssystem funktioniert, müssen die ECT-Modelle auf den Clientcomputer heruntergeladen und dort installiert werden. Microsoft Office und SharePoint 2010 stellen zwei Verfahren für die Bereitstellung von ECTs bereit. Abbildung 3 zeigt die Bereitstellung mittels SharePoint Workspace, das auf den Computern der Benutzer im Rahmen der Office 2010-Installation installiert wird. Abbildung 4 zeigt, wie dies funktioniert.

Abbildung 3 ECT-Bereitstellung mittels SharePoint Workspace

Abbildung 4 ECT-Bereitstellung mittels BCS Solution Packaging Tool

Zunächst werden die ECTs von Visual Studio zum SharePoint Server-Metadatenspeicher veröffentlicht (Schritt 1). Damit Visual Studio die ECT-Metadaten in den SharePoint Server-Datenspeicher veröffentlichen kann, muss es auf dem gleichen Server wie SharePoint 2010 installiert werden.

Als Nächstes erstellen Sie für jeden veröffentlichten ECT eine externe Liste (Schritt 2). Sie können die externe Liste von jedem Computer aus, der eine Verbindung mit SharePoint Server herstellen kann, über die SharePoint-Homepage erstellen.

Nach der Erstellung der externen Liste für einen ECT führt SharePoint sofort den EX`CT aus, der eine Verbindung mit den externen Systemen herstellt, Daten abruft und diese als Listeninhalt auf der SharePoint-Website anzeigt. Mittels dieses Bereitstellungsvorgangs können Sie die Daten anzeigen, die vom ECT an den SharePoint Server zurückgegeben werden, zusätzlich zur Office-Anwendung auf dem Client. Dies ist in einigen Fällen wünschenswert, jedoch nicht erforderlich. Die Bonusverwaltungslösung verwendet diese Funktion nicht, da wir nicht möchten, dass sensible Bonusdaten von Mitarbeitern mittels SharePoint angezeigt werden.

Laden Sie nun die externen Listen auf den lokalen Computer herunter, die von SharePoint Server in Schritt 2 erstellt wurden (Schritt 3). Sie können den Download starten, indem Sie in Internet Explorer eine Verbindung mit der SharePoint-Homepage herstellen und Site Actions | Sync to SharePoint Workspace auswählen. Dadurch wird das SharePoint Workspace-Programm auf dem Clientcomputer gestartet. Die externen Listen werden einzeln heruntergeladen. In der aktuellen Version von Workspace 2010 muss der Benutzer für jede externe Liste, die heruntergeladen werden soll, auf die Installationsschaltfläche klicken.

Durch das Herunterladen einer externen Liste installiert SharePoint Workspace automatisch den ECT (Metadaten und Assembly) im lokalen BCS-Datenspeicher (Schritt 4). Zusätzlich wird ein Abonnement für den installierten ECT für die BCS-Laufzeit erstellt, um die ECT-Daten regelmäßig mit den externen Systemen zu synchronisieren. Die voreingestellte Datensynchronisierungsfrequenz ist sechs Stunden.

Die Bonusverwaltungslösung verwendet einen zweiten Bereitstellungsprozess für die Installation von ECTs auf den Clientcomputern (wie in Abbildung 4 gezeigt).

Bei dieser Bereitstellungsmethode verwenden wir das BCS Solution Packaging Tool (code.msdn.microsoft.com/odcsps14bcspkgtool), und es sind keine externen Listen am Bereitstellungsprozess beteiligt. Daher benötigen wir die SharePoint-Homepage und SharePoint Workspace nicht, obwohl wir weiterhin den SharePoint Server-Metadatenspeicher nutzen.

Bei diesem Bereitstellungsprozess verwenden wir nach der Veröffentlichung der ECTs zum SharePoint-Metadatenspeicher SharePoint Designer, um die ECTs in eine Modelldatei zu exportieren (.bdcm). Sie können SharePoint Designer auf dem Server oder auf dem Client ausführen, und Sie können die exportierte Modelldatei in einem freigegebenen Ordner speichern. Das BCS Solution Packaging Tool liest die Modelldatei und generiert ein Visual Studio Tools for Office (VSTO)-Installationspaket, das von den Benutzern ausgeführt werden kann.

Aus der Sicht der Benutzer ist dies ein einfacher und transparenter Installationsprozess. Die Benutzer müssen nur einmal klicken, wenn Sie die setup.exe ausführen, um alle ECTs zu installieren, die aus SharePoint Designer exportiert wurden. Die Installation startet außerdem sofort BCSSync.exe, um die ECTs auszuführen und die ECT-Daten direkt von den externen Systemen in den lokalen BCS-Datencache herunterzuladen.

Das Excel-Add-In

Wie bereits gesagt, haben wir die vorhandene Windows Forms-Anwendung als Excel-Add-In neu entworfen und Excel als Benutzeroberfläche für die Verwaltung der Mitarbeiterboni verwendet. Das Excel-Add-In führt die beiden folgenden Hauptfunktionen aus:

• Es rendert die Mitarbeiterdatensätze und verwandte Anleitungen und Statistiken als Excel-Arbeitsblatt und -Aufgabenbereich.
• Es verwendet BCS-APIs, um Mitarbeiterdaten und Geschäftsregeldaten aus dem lokalen BCS-Cache abzurufen, und schreibt alle Änderungen zurück in die lokale BCS-Updatewarteschlange.
• Es ruft vorhandenen Geschäftslogikcode auf, wenn Benutzer Mitarbeiterboni ändern, um sicherzustellen, dass die Änderungen den entsprechenden Richtlinien und den oberen und unteren Grenzwerten entsprechen.

Abbildung 5 zeigt die neue Excel-basierte Benutzeroberfläche für die Bonusverwaltung. In der oberen Hälfte des Bildschirms wird ein Excel-Arbeitsblatt angezeigt, in dem Mitarbeiterdatensätze für die Abteilung des Benutzers angezeigt werden. In der unteren Hälfte des Bildschirms befindet sich ein Aufgabenbereich, in dem die Richtlinien für den markierten Mitarbeiter (ausgewählte Zeile) und die Statistik für die Abteilung angezeigt werden. Richtlinien und Statistiken für ausgewählte Spalten werden in der unteren Hälfte des Bildschirms angezeigt.

Abbildung 5 Excel-Entwurf für die Bonusverwaltungslösung

Diese einfache und benutzerfreundliche Excel-Schnittstelle hilft Managern und Mitarbeitern von Personalabteilungen bei der effektiven Verwaltung von Mitarbeiterboni. Sie führen alle Aufgaben in einem einzigen Bildschirm aus. Dabei wird Ihnen eine Übersicht über die Boni für ihre Abteilungen angezeigt. Natürlich können sie zusätzliche Statistiken und Diagramme auf der Basis der Mitarbeiterdaten im Arbeitsblatt erstellen. Dazu verwenden sie systemeigene Excel-Funktionen wie Pivot-Tabellen und Pivot-Diagramme.

Beim Starten des Excel-Programms wird neben dem Excel-Add-In auf der Menüleiste eine angepasste Registerkarte für das Bonusverwaltungssystem angezeigt. Wenn die Benutzer auf diese Registerkarte klicken, wird ein Band mit mehreren Schaltflächen angezeigt, sodass die Benutzer mit der Verwendung der Bonusverwaltungslösung beginnen können.

Verwenden der BCS-APIs

Die BCS-APIs bilden natürlich die Grundlage jeder BCS-Lösung. Betrachten wir einige Teile des Beispielcodes, um die Verwendung von BCS-APIs zu demonstrieren.

Als Erstes betrachten wir den Code, der verwendet wird, um alle Benutzerdatensätze aus dem lokalen Zwischenspeicher abzurufen (siehe Abbildung 6).

Abbildung 6 Abrufen von Mitarbeiterdatensätzen

string entityNameSpace = "MSIT.HR.Rewards.BCS";
string entityName = "EmployeeDetails";
// Initialize and connect to BCS local cache
RemoteSharedFileBackedMetadataCatalog catalog = 
  new RemoteSharedFileBackedMetadataCatalog();
// Get the ECT for employee entity
IEntity entity = catalog.GetEntity(@entityNameSpace, entityName);
// Get the finder method defined for employee ECT
string methodName = entity.GetMethodInstance(
  MethodInstanceType.Finder)[0].Value.Name;
IMethodInstance mi = entity.GetMethodInstance(
  methodName, MethodInstanceType.Finder);
// Get external system instance
ILobSystemInstance LobSysteminstance = 
  entity.GetLobSystem().GetLobSystemInstances()[0].Value;
// Retrieves all instances of employee ECT
IEntityInstanceEnumerator instanceEnumerator = 
  entity.FindFiltered(entity.GetDefaultFinderFilters(),
  mi, LobSysteminstance, OperationMode.CachedWithoutRefresh);
// Loop each employee and add it to Excel worksheet list object
while (instanceEnumerator.MoveNext()) {
  ... // Loop each instance of employee record and
      // add it to Excel worksheet list object
}

IEntity ist die Hauptschnittstelle von BCS für die ECTs, die Sie für die Lösung definieren. IEntityInstance stellt eine spezifische Dateninstanz für die Entität dar, von der Sie Daten erhalten möchten. Jeder ECT hat einen eindeutigen Entitätsnamen innerhalb eines Entitäts-Namespace. Jede Entitätsinstanz wird durch eine eindeutige ID identifiziert, die Sie bei der Definition des ECT definieren. In diesem Fall ist dies die Personalnummer.

Sie können einen Mitarbeiterdatensatz (oder genauer gesagt, eine ECT-Instanz eines Mitarbeiters) mittels der Updatemethode für BCS-Enitätsinstanzen aktualisieren. Dadurch wird ein Updatevorgang in der lokalen BCS-Warteschlange erstellt. Es werden daher 10 Vorgänge im lokalen Cache in die Warteschlange eingereiht, wenn Sie 10 Mitarbeiterdatensätze ändern. Die BCS-Synchronisierung verarbeitet jeweils einen Vorgang:

// Query the employee instance you want to change
Identity identity = new Identity(employeeNumber);
IEntityInstance myEmployee = 
  entity.FindSpecific(identity, LobSysteminstance);
// Update the employee bonus amount
myEmployee["BonusAmount"] = 1000;
// Submit the changes to BCS local cache
myEmployee.Update();

Der Code in Abbildung 7 zeigt, wie der BCS-Cache für alle ausstehenden Vorgänge oder für Vorgänge abgefragt wird, die fehlgeschlagen sind, weil das System nicht verfügbar war, weil es Fehler gab oder weil es Datenkonflikte gab.

Abbildung 7 Prüfen von ausstehenden oder fehlgeschlagenen Vorgängen

// Initialize and connect to offline cache store
RemoteOfflineRuntime offlineRuntime = new RemoteOfflineRuntime();
ISynchronizationManager syncManager = 
  offlineRuntime.GetSynchronizationManager();
IMetadataCatalog catalog = 
  offlineRuntime.GetMetadataCatalog();
// Get all current operations from local operation queue
IOperationCollection allOps = syncManager.GetOperations();
foreach (IOperation op in allOps) {
  // ECT associated with the operation
  IEntity entity = op.Entity;
  // Query for operation status
  string operationstatus = op.OperationStatus.ToString();
  // Query for operation retry count
  int retryCount = op.RetryCount;
  // Get last exception message if operation errored out
  string errMsg = op.LastException.Message;
  // Retry the operation if status is pending or error
  op.Retry();
  // Decide if error is due to data conflict
  if (errMsg.Contains("ConflicDetectedException"))
    // Then the error is due to data conflict
}

ISynchronizationManager ist die Hauptschnittstelle für den Entitätssynchronisierungsprozess in BCS. Jeder Vorgang (IOperation) stellt eine Änderung an Entitätsdaten dar, die von der BCS-Laufzeit verarbeitet werden muss. Nach der Verarbeitung erhält jeder Updatevorgang den Status "Ausstehend" oder "Fehler". Wenn ein Vorgang erfolgreich verarbeitet wurde, wird der Vorgang aus der Warteschlange entfernt. Sie können den Vorgang anschließend nicht mehr über den Synchronisierungsmanager abfragen.

Der Status "Ausstehend" zeigt an, dass der Vorgang aufgrund der fehlenden Verfügbarkeit des externen Systems ausstehend ist. BCS wiederholt den Vorgang automatisch, bis dieser erfolgreich abgeschlossen ist oder ein Fehler zurückgegeben wird.

Der Status "Fehler" zeigt an, dass der Vorgang aufgrund eines Validierungsfehlers, eines Datenintegritätsfehlers oder eines Datenkonflikts von den externen Systemen nicht verarbeitet werden konnte.

Benutzer werden gelegentlich den lokalen Cache mittels der externen Systeme aktualisieren wollen, anstatt auf die regelmäßige Synchronisierung durch die BCS-Laufzeit zu warten. So erzwingen Sie die Aktualisierung der Daten für alle ECTs:

// Initialize and connect to offline cache
RemoteOfflineRuntime offlineRuntime = new RemoteOfflineRuntime();
ISubscriptionManager subManager = 
  offlineRuntime.GetSubscriptionManager();
// Get all subscriptions
ISubscriptionCollection mysubs = subManager.GetSubscriptions();
IEnumerator<ISubscription> ie = mysubs.GetEnumerator();
while (ie.MoveNext()) {
  ISubscription mySub = ie.Current;
  mySub.RequestRefresh(true);
}

Wie bereits erwähnt, erstellt die BCS-Laufzeit bei der ersten Bereitstellung und Installation eines ECT auf dem Computer eines Benutzers ein Abonnement für die Daten aus den externen Systemen in den lokalen Datenspeicher. Das Abonnement wird von der BCS-Laufzeit verwendet, um die ECT-Daten mit externen Systemen zu synchronisieren.

Im Beispielcode ist ISubscriptionManager die Schnittstelle, um alle Abonnements (ISubscription) zu erhalten, die im BCS-Datenspeicher erstellt wurden. Mit einem Abonnementobjekt können Sie verschiedene Aktionen durchführen, darunter das Ändern der Synchronisierungsfrequenz für den ECT, das Hinzufügen zusätzlicher Abfrageparameter, das Abrufen des letzten Aktualisierungsstatus, das Anfordern einer umgehenden Aktualisierung (wie im Beispiel) und das Abrufen der Anzahl der Instanzen, die für den ECT synchronisiert wurden.

Gewonnene Erkenntnisse

Während des Entwurfs, der Entwicklung und der Bereitstellung der neuen Bonusverwaltungslösung erhielten wir zahlreiche praktische Einblicke in die Entwicklung von Office-Add-Ins und in die Implementierung von SharePoint 2010 BCS. Im Folgenden führe ich einige dieser Einblicke auf:

Als Erstes sollten Sie so viel Zeit wie möglich für das Entwerfen der ECTs für Ihre Lösung aufwenden. Der ECT-Entwurf ist wesentlich für eine funktionierende BCS-Lösung. ECTs wirken sich direkt auf das Verhalten der BCS-Laufzeit aus. Ein schlecht entworfener ECT kann dazu führen, dass die BCS-Laufzeit abstürzt oder Out-of-Memory-Ausnahmen verursacht werden.

Wir haben dies auf die harte Art erfahren. Wir hatten ursprünglich einen großen ECT entworfen, der alle Geschäftsregeln als eine einzige Instanz zurückgibt. Die Einzelinstanz enthielt ein Array mit 40 MB, das in Spitzenzeiten zu einer Arbeitsspeichernutzung durch die BCS-Laufzeit von 600 MB führte, wenn das Array zu Objekten deserialisiert wurde.

Um die Speichernutzungsprobleme abzumildern, entwarfen wir die große ECT neu, sodass wir einige getrennte ECTs erhielten, basierend auf Regelkategorien. Jede Kategorie-ECT gibt eine Anzahl von Entitätsinstanzen zurück, die der tatsächlichen Anzahl der Regeln entspricht. Mit diesen neuen, besser fokusierten ECTs funktioniert die BCS-Synchronisierung auf eine wesentlich effizientere Weise.

Ein anderes bewährtes Verfahren besteht darin, eine möglichst stark typisierte und vergleichsweise flache Struktur zu verwenden, um die ECTs zu definieren. Wenn Sie SharePoint Designer für die Generierung der ECTs verwenden können, spart Ihnen dies viel Entwicklungszeit. Die Erstellung von ECTs in Visual Studio mit einer Vielzahl von Entitätsattributen ermöglicht Ihnen eine höhere Flexibilität, kann jedoch zeitaufwendig und mühsam sein.

Denken Sie gründlich über Ihre Anforderungen nach, was die Menge der Daten angeht, die heruntergeladen und auf dem Computer eines Benutzers zwischengespeichert werden können. Dadurch wird die Implementierung der Finder-Methode für die ECT festgelegt. Die von den Aufrufen des externen Systems zurückgegebenen Daten legen natürlich die Grenze für die Anzahl der Datensätze fest, die heruntergeladen werden können. Wenn Ihr ECT-Entwurf mehr Daten benötigt, als es diese Grenzen zulassen, muss das externe System entsprechend Ihren Anforderungen geändert werden.

In unserer Bonuslösung kann ein Manager nur die Mitarbeiterdatensätze für seine eigene Abteilung herunterladen und zwischenspeichern. Daher gibt es für zwei verschiedene Benutzer wahrscheinlich auch zwei verschiedene Sätze von Mitarbeiterdaten, die in den lokalen Zwischenspeicher heruntergeladen werden. Die vorhandenen Rewards Web Services authentifizieren den Benutzer und geben nur die Mitarbeiterdaten zurück, auf die der Benutzer zugreifen darf. Mit anderen Worten, die Datenfilterung wird durch die externen Systeme durchgeführt, und die ECT-Implementierung muss die Daten nicht anhand der Benutzerberechtigungen filtern. Wenn dies für Ihre Lösung nicht der Fall ist, müssen Sie zusätzlich Zeit für den Entwurf und die Entwicklung aufwenden, sodass die ECT-Daten für die lokale Zwischenspeicherung gefiltert werden.

Behandeln Sie Ausnahmen der externen Systeme in Ihrer ECT-Implementierung mit Sorgfalt. An einem gewissen Punkt müssen Ihre ECT-Implementierungen für die Finder- und SpecificFinder-Methoden die Methoden der externen Systeme aufrufen, um Daten abzurufen. Sie müssen Ausnahmen in den externen Systemen in Ihrem Code abfangen und behandeln. Sie müssen die Ausnahmen nach der Behandlung an die BCS-Laufzeit zurückgeben. Andernfalls nimmt die BCS-Laufzeit an, dass der Aufruf der externen Systeme erfolgreich war, keine Datenzeilen zurückgeben und die Daten entfernen, die im lokalen Cache bereits vorhanden sind. Sie möchten sicher nicht, dass der lokale Datencache augrund einer Ausnahme in einem externen System gelöscht wird.

Es gibt weitere Überlegungen hinsichtlich der Verwendung von Bibliotheken von Drittparteien in Ihrer ECT-Implementierung. In einem unserer ECTs mussten wir auf eine Assembly verweisen, die von einer anderen Gruppe entwickelt worden war, um zusätzliche Geschäftslogik- und Datentransformationen durchzuführen. Während der Bereitstellung dieses ECT stellten wir fest, dass die referenzierte Assembly nicht als Teil der ECT-Installation auf den Clientcomputern installiert worden war. Daher konnte BCS den ECT nicht ausführen und die Daten herunterladen.

Zurzeit arbeiten wir mit dem BCS-Produktteam an der Lösung dieses Problems. Das Problem kann dadurch umgangen werden, dass die Assembly dem Global Assembly Cache als Teil der VSTO-Installation hinzugefügt wird.

Es ist äußerst wichtig, dass Sie die ECTs testen und debuggen. Sie werden von der BCS-Laufzeit im Hintergrund ausgeführt, und Sie können ECTs in Visual Studio debuggen, wenn sie auf Clientcomputern ausgeführt werden. Wir empfehlen das Testen und Debuggen der ECTs auf dem Server durch das Erstellen von externen Listen in SharePoint. Wenn Sie den Inhalt einer externen Liste auf einer SharePoint List-Seite anzeigen und ändern, führen Sie den ECT-Code aus, der mit der externen Liste verknüpft ist, und Sie können den ECT von einer Visual Studio-Instanz aus debuggen, die auf dem gleichen SharePoint-Server ausgeführt wird.

Schließlich ist es von essenzieller Bedeutung, dass Sie den BCS-API-Entitätsbetriebsmodus verstehen. In der Clientanwendung, die BCS-APIs für die Bearbeitung von ECT-Entitätsinstanzen verwendet, gibt es vier Betriebsmodi, die Sie für die Verwaltung von ECT-Daten verwenden können. Im Folgenden finden Sie eine kurze Übersicht über deren Funktionsweisen:

• OperationMode.CacheWithoutRefresh: Bei Verwendung dieses Betriebsmodus für eine Entitätsinstanz gibt BCS die Entitätsinstanz aus dem Cache zurück. Wenn im Cache keine Daten vorhanden sind, aktualisiert BCS den Cache aus den externen Systemen und gibt die zwischengespeicherte Kopie zurück. Wenn keine Verbindung mit den externen Systemen hergestellt werden kann, löst BCS eine Ausnahme aus.
• OperationMode.CacheWithImmedicateRefresh: In diesem Betriebsmodus aktualisiert BCS die Entitätsinstanz im Cache zuerst aus dem externen System und gibt die zwischengespeicherte Kopie zurück. Wenn keine Verbindung mit dem externen System hergestellt werden kann, gibt BCS dennoch die zwischengespeicherte Kopie zurück. Wenn die Entitätsinstanz nicht zwischengespeichert ist, und keine Verbindung mit dem externen System hergestellt werden kann, löst BCS eine Ausnahme aus.
• OperationMode.Offline: Im Offlinebetriebsmodus wird niemals eine Verbindung mit externen Systemen hergestellt, auch dann nicht, wenn im Cache keine Daten vorhanden sind. BCS gibt die Entitätsinstanz aus dem Cache zurück. Wenn diese nicht vorhanden ist, löst BCS eine Ausnahme aus.
• OperationMode.Online: Im Onlinebetriebsmodus verwendet BCS zu keinem Zeitpunkt lokal zwischengespeicherte Daten und stellt stets eine Verbindung mit externen Systemen her, um eine Kopie der Entitätsinstanz zu erhalten. Wenn keine Verbindung mit dem externen System hergestellt werden kann, löst BCS eine Ausnahme aus.

Zusammenfassung

Microsoft Office und SharePoint 2010 mit BCS bilden die Grundlage für die Implementierung einer einfachen, benutzerfreundlichen und leistungsfähigen Lösung für Unternehmen, um Unternehmensdaten aus mehreren externen Systemen innerhalb der vertrauten Office-Umgebung zu verwalten. Diese Grundlage ermöglicht die Verfügbarmachung von Geschäftsdaten und Prozessen überall und jederzeit. Dies steigert die Geschäftsproduktivität.

Die BCS-Synchronisierungsinfrastruktur löst zahlreiche Probleme, die mit Kopien, Änderungen und Konflikten in Bezug auf Daten verbunden sind. Einer der Vorteile der BCS-Synchronisierung im Vergleich zu anderen Frameworks für die Datensynchronisierung besteht darin, dass BCS die Einbettung von Geschäfts- und Datenvalidierungslogik in den Synchronsierungsprozess mittels ECT-Implementierungen ermöglicht. Ein weiterer Vorteil von BCS ist die Fähigkeit, zusammengesetzte Daten aus mehreren disparaten Systemen (mittels des ECT-Entwurfs) zu synchronisieren, anstelle der Punkt-zu-Punkt-Synchronisierung, die von vielen anderen Synchronisierungslösungen bereitgestellt wird.

Ying Xiong ist führender Architekt im Microsoft IT-Team. Er entwickelt Architekturen und entwirft Unternehmensanwendungen und -integrationen innerhalb von Microsoft. Er arbeitet mit einer Vielzahl von Microsoft-Technologien, um verteilte Unternehmensanwendungen zu entwickeln. Sie können Ying Xiong unter yingx@microsoft.com erreichen.

Unser Dank gilt den folgenden technischen Experten für die Durchsicht dieses Artikels: Rolando Jimenez Salgado und Satish Thatte