Suchen Sie noch oder finden Sie schon?

Veröffentlicht am von ,

Nach ca. 4,5 Jahren der Bereitstellung und des Betriebs von SharePoint 2007 / SharePoint 2010 als Intranet, Extranet sowie als Internet in schweizer Unternehmen kann man sagen:

Mit SharePoint 2007 suchen Sie, mit SharePoint 2010 finden Sie.

Dabei stellt das weniger eine Kritik an SharePoint 2007, sondern vielmehr ein Lob auf SharePoint 2010 dar. Verwöhnt durch Google stellen Nutzer automatisch die gleichen Anforderungen an die Suche eines Intranets. Microsoft hat die SharePoint 2010 Suche derart verbessert, dass man bereits nach der Basiskonfiguration brauchbare Suchergebnisse erhält.

1989-image_thumb.png

Features

Während man mit SharePoint 2007 noch mühsam versucht hat, out-of-the-box Suche, Wildcard Search (Drittanbieter) und Facetted Search (anderer Drittanbieter) zu verheiraten, um brauchbare Sucheergebnisse zu erhalten, bietet SharePoint 2010 bereits folgende Features:

  • Wildcard search
  • People and expertise search
  • Metadata-driven refinement panel (Facetted Search )
  • Taxonomy tag integration
  • Relevance improves with social behavior

Folgende Quellen können durch einen oder mehrere Server indexiert werden:

  • SharePoint sites (in the same farm, or in external farms)
  • Windows file shares
  • Microsoft Exchange public folders
  • Web sites that are not SharePoint sites
  • People Profiles
  • External line-of-business applications
  • Structured content in databases
  • Content returned by Web services
  • Third-party products and solutions including Lotus Notes and Documentum

Die gefühlte / gemessene Dauer der Indexierung einer grossen Menge an Daten ist deutlich geringer als noch in der 2007er Version.

Search Server 2010 Express

Der Search Server 2010 Express kann abhängig von der zugrunde liegenden Hardware eine unterschiedliche Menge an Daten indexieren, kommt aber nicht an die Menge des Search Server an sich heran, da die Express Version nicht skaliert werden kann. Dafür werden keine Lizenzkosten für den Search Server 2010 Express fällig.

Search Server 2010

Der Search Server 2010 bietet den gleichen Funktionsumfang wie die SharePoint Server 2010 Suche und kann durch die Skalierung des Indexservers auch grössere Mengen an Daten indexieren.

FAST Search

Der Funktionsumfang der FAST Search ist gegenüber der SharePoint 2010 Suche nochmals erweitert und bietet u.a.

  • Contextual search und
  • Thumbnails and previews.

Ausserdem kann durch Skalierung eine weit grössere Menge an Daten indexiert werden als es bei der SharePoint 2010 Suche möglich ist.

Fazit

Die SharePoint 2010 Suche macht Spass weil sie nützlich ist, die Arbeit vereinfacht und den User sinnvoll unterstützt.

One world-Der Hybris Connector

Veröffentlicht am von , Kommentar hinterlassen

<< Einführung in die Serie one world

Einleitung
In diesem Artikel soll aufgezeigt werden, wie ein custom Service durch die Vererbung einiger Basisklassen des SAF (Service Application Framework) in die SharePoint 2010 Serviceinfrastruktur integriert werden kann. Wie auch bereits in der Einleitung geschehen, wollen wir uns dabei am Beispeil des Hybris connector Service orientieren. Dieses Mal werden wir aber vermehrt auf die technische Umsetzung des Service eingehen und insbesondere aufzeigen, wie sich der Service mit dem SAF verbindet.

Der Aufbau des Service
Das Design eines custom SAF Service wird grundsätzlich durch die zu vererbenden Basisklassen des Frameworks bestimmt. Diese werden in den folgenden Darstellungen kurz besprochen. Die vererbten Klassen des SAF sind in den Abbildungen jeweils blau interlegt. Gelb hinterlegt sind die Klassen des connector Service.

2961-HybrisService.jpg

Die Klasse HybrisService steht für den Service selber und vererbt von SPIisWebService. Somit beinhaltet er eine Liste aller Service Applikationen und aller Service Application Proxies., die für diesen Service angelegt worden sind. Der Service selber kann sich in der Services-Liste der Farm ein- oder auch wieder austragen. Dazu kennt die Klasse einen Link für den ‚Create Service‘ Dialog. Weiter können durch die Implementierung von IServiceAdministration neue Applikationen und Proxies anlegen.

2976-HybrisServiceInstance.jpg

Die Klasse HybrisServiceInstance steht für eine Instanz des Service, die auf einem bestimmten Server in der Farm läuft.

2979-HybrisServiceProxy.jpg

Die Klasse HybrisServiceProxy etabliert die Verbindung zwischen dem Service und den ServiceApplicationProxies.

2964-HybrisServiceApplication.jpg

Die Klasse HybrisServiceApplication ist die eigentliche Service Applikation. In unserem Beispiel wird die Konfiguration des Service durch diese Klasse gespeichert und gelesen. Dadurch erreichen wir, dass der HybrisConnector-Service mehrfach in einer Farm laufen kann und sich dabei die jeweiligen Konfiguration unterscheiden können. Diese Klasse implementiert auch IHybrisWCFService, unseren Service Kontrakt.

2970-HybrisServiceApplicationProxy.jpg

Die Klasse HybrisServiceApplicationProxy wird für den Zugriff auf HybrisServiceApplication verwendet. Diese Klasse wird benützt, um im client code auf den Service zuzugreifen.

2960-HybrisServicApplicationHost.jpg

Die Klasse HybrisServicApplicationHost wird für das hosting des Service im IIS verwendet

2967-HybrisServiceApplicationHostFactory.jpg

Die Klasse HybrisServiceApplicationHostFactory wird für das Erstellen der s Servicehost verwendet.

2973-HybrisServiceImplementation.jpg

Schliesslich wollen wir noch einen kurzen Einblick in die Logik unseres Service geben. Die von den REST Services ausgelieferten Datenstrukturen werden jeweils durch eine einfach gehaltene Datacontainer-Klasse abgebildet. Wir wollen hier an einem Beispiel aufzeigen, wir die Daten von Hybris geladen werden: Die Klasse Catalogs beinhaltet eine Liste von Katalogen. Wie alle Datencontainer implementiert sie das Interface IDataItem, dass die properties URL und ID erzwingt. Da es sich bei Catalogs um den Einstiegspunkt in die Hybris Catalog-Struktur handelt, muss an dieser Stelle die Url gesetzt werden. Sie wird aus der Konfiguration des Service entnommen. Die Logik des Hybris-Aufrufs und die Verarbeitung des Xml-Streams wird in der Klasse XmlDataElement implementiert. Diese verlangt die Angabe eines generischen Typs T (hier Catalogs). Dieser Typ entspricht dem zu ladenden Datacontainer. Die Hilfsklasse HtmlBase schliesslich übernimmt die Kommunikation mit den REST Services. Der response stream wird geparsed und in die DataContainer Klasse abgefüllt. Im Falle der Catalogs handelt es sich dabei um eine Liste von weiteren REST Urls, die für den Bezug der Detailinformationen zu den einzelnen Katalogen aufgerufen werden können. Dazu wird für jeden Katalog ein XmlDataElement vom Typ Catalog erstellt und die REST Urls der einzelnen Kataloge werden übernommen. Die Katalogdaten können nun geladen werden.

Schlussfolgerung
Durch den Hybris Connector Service können wir von SharePoint-Customcode aus sehr einfach auf Hybris lesend zugreifen. Wir erhalten Instanzen von .Net Klassen zurück und brauchen uns weder um den Aufruf von Hybris noch um das Parsen des ausgelieferten xml zu kümmern. Weiter kann der Service auch business Logik implementieren. So können zum Beispiel durch eine Service-Methode gleich die Daten eines ganzen Katalogs mit allen Kategorien und Produkten zusammengesucht werden. Natürlich würde eine solche Service Methode bald mit Performance-Problemen zu kämpfen haben, weil dazu eine Vielzahl Hybris REST calls nötig sind. Man kann sich aber auch gut vorstellen, dass der Hybris Connector Service eine cache-Struktur aufbaut, um eine ausreichend schnelle Ausleiferung der Daten zu gewährleisten.

Links

Step by Step SharePoint Service Applications
EInführung in Application Services von Daniel Larson. Sehr hilfreich!

MatchPoint (Teil 2): Funktionen und Stärken in der Lösungsentwicklung

Veröffentlicht am von , 4 Kommentare

In diesem Artikel beschäftigen wir uns mit den Funktionen aus dem SharePoint Framework MatchPoint und sich den daraus ergebenden Stärken und Vorteilen in der Lösungsentwicklung.

Beginnen wir mit möglichen Einsatzszenarien des Frameworks (kleiner Auszug):

  • Dynamische Intranets, die auf hohe Personalisierungsfunktionen setzen. Personalisierung kann hier nicht nur im Kontext eines einzelnen Benutzers verstanden werden, sondern auch Länder-, Standort-, Abteilungsspezifische Sichten auf die Inhalte im Intranet
  • Composite Applications: hierbei handelt es sich um konfigurierbare Szenarien, die unter normalen Umständen oft in Entwicklungsarbeit ausarten. Folgende Beispiele sollen dies verdeutlichen:
    • Newsapplikation: eine der häufigsten Anwendungen in einem Intranet. Heute reicht es aber nicht mehr, dass ein Newsbereich mit entsprechenden Seiten vorhanden ist. News sollen kategorisiert, verschiedene Darstellungsformen (z.b. Highlight-Artikel; Top-Artikel; allgemeiner Artikel) aufweisen aber auch zu verschiedenen Unternehmensbereichen/Standorten zugeteilt werden können. Selbstverständlich soll dann dem Benutzer beim Einstieg seine News aus seinem Bereich dargestellt werden. Auf einer Standortseite sollen nur die Standort-News dargestellt werden. Und dann gehören ein News-Archiv und eine News-Suche natürlich auch dazu.
    • Absenzenverwaltung: Beantragung von Absenzen (Ferien, Militär, Ausbildung…) kann mittels einfachem Formular erfolgen, über einen konfigurierten Workflow wird die Genehmigung gesteuert und alle Absenzen können schlussendlich in einer Kalenderübersicht dargestellt werden (dabei besteht die Möglichkeit spezifische Ansichten für Teams, Gruppen, Projektteams etc. zu konfigurieren)
    • Job- und Bewerberverwaltung: Verwaltung der offenen Stellen im Unternehmen sowie der effektiven Bewerbungen. Dabei kann über Konfigurationen ein Matching erfolgen, wie gut ein bestimmter Bewerber die geforderten Qualifikationen für einen Job erfüllt.
  • Dossierverwaltung: sobald wiederkehrende Strukturen/Ablagen benötigt werden, die standardmässig genutzt werden sollen, dann macht es Sinn, diese als Dossiers zu organisieren und dem Benutzer das Anlegen solcher Dossiers zu ermöglichen. Beispiele von Dossiers: Projektdossier, Falldossier, Patientendossier, Kampagnendossier, Vorhabendossier etc.
  • Intelligente Ablagesysteme: bei klassischen DMS ist der Benutzer gefordert, viele manuelle Schritte vornehmen zu müssen (z.B. Einpflegen der Metadaten). Mit intelligenten Ablagesystemen kann dies stark reduziert werden: automatische Vergabe, Vererbung und Korrektur von Metadaten stellen eine hohe Qualität der Daten sicher; die Metadatenstruktur hilft zudem, die benötigten Dokumente direkt zu finden aber auch die Ablageorte entsprechend zu lokalisieren. Metadaten werden dabei auch durch die Einbindung externer Systeme automatisch aktuell gehalten.

Betrachtet man die oben erwähnten Beispiele und fragt einen SharePoint-Entwickler, wie dies am besten realisiert werden kann, dann habe ich öfters eine klare Antwort erhalten: wir müssen dies programmieren. Ach ja? Leider hat sich dies mehrheitlich bewahrheitet, weil sich SharePoint auf der Konfigurationsebene schwer tut. Gerade dann, wenn die eigenen Element und Funktionen so intelligent verknüpft werden sollen, dass daraus wirklich eine Applikation entsteht. Diese Verknüpfungen können oft nur programmatisch und mit entsprechendem Aufwand gelöst werden.

Und wo hilft nun MatchPoint in diesem Bereich, was SharePoint alleine nicht kann? Um dies zu beantworten, betrachten wir als erstes die Architektur von MatchPoint:

2950-matchpoint_sharepoint_architecture.png

Naja, sind wir ehrlich: eine solche Grafik bietet auch Microsoft und das klingt da genau gleich gut. Der grosse Unterschied bei MatchPoint ist, dass die im Framework (Service Layer/WebParts) enthaltenen Elemente darauf ausgelegt sind, miteinander kombiniert zu werden. Zudem baut die Architektur von MatchPoint auf der von SharePoint bereitgestellten Service orientierten Architektur auf. Dies stellt sicher, dass ein homogenes und hochgradig konfigurierbares System bereitgestellt wird.

Für den Entwickler sind im MatchPoint-Framework deshalb die folgenden Punkte besonders interessant. Diese stellen die besonderen Stärken des Frameworks dar (die Liste ist nicht abschliessend):

  • Configuration Framework: zentrales Element von MatchPoint. Das Konfigurations-Framework erlaubt über XML-Konfigurationen die entsprechenden Lösungen zu realisieren. Die XML-Konfigurationen können dabei dank dem MatchPoint-Editor direkt in der SharePoint-Oberfläche vorgenommen werden (diese werden dabei gegen ihr Schema validiert).
  • Connection Framework: Dient dazu, die einzelnen WebParts und Funktionen innerhalb des Frameworks miteinander zu vernetzen. So kann eine Aktion in einem bestimmten WebPart zu einer weiteren Aktion in einem anderen WebPart führen. Dies geht weit über das klassische DataProviding von SharePoint-WebParts hinaus!
  • Expression Engine: mit der Expression-Engine lassen sich entsprechende Logiken konfigurieren und auf bestimmte Gegebenheiten reagieren (z.B. zur Personalisierung). Dies ist besonders interessant in Kombination mit dem Configuration und Connection Framework.
  • Data Providers: Anbindung von Daten aus Drittsystemen. Diese können zum Import von Metadaten dienen (z.B. Kundendaten aus SAP) oder für die Inhaltsabfrage/-aggregation durch die einzelnen MatchPoint-WebParts. Auch diese basieren auf einfachen XML-Konfigurationen.
  • Tagging Infrastructure: Der Term Store von SharePoint 2010 bietet eine Basis für die Vergabe von Metadaten. MatchPoint geht hier einen Schritt weiter, in dem es ein dynamisches Modell erlaubt, das sich um automatisches Tagging, Vererbung wie auch um Anpassungen bei Inhaltsverschiebungen etc. kümmert. Dabei können mit den DataProviders die Metadaten automatisiert eingelesen und aktualisiert werden (ein solcher Mechanismus bietet der Termstore OOB nicht an).
  • Provisioning Templates: Mittels einfachster Konfigurationen können Templates definiert werden, die Sites/Workspaces/Dossiers anlegen und mit entsprechenden Inhalten/Metadaten provisionieren. Vgl. unten Site Creator WebPart
  • Role Management: Berechtigungsvergabe innerhalb eines Workspaces – dies wird insbesondere in kollaborativen Szenarien verwendet. Ein Projektleiter kann so sehr einfach definieren wer im Workspace mitarbeitet und das Role Management kümmert sich automatisch um die Berechtigungen (Benutzer muss die komplexen Strukturen von SharePoint nicht kennen).
  • Grenzen sprengen: das ist zwar nicht wirklich ein Funktion, aber als SharePoint-Entwickler stösst man öfters an gewisse Grenzen von SharePoint. Eine zentrale Grenze ist die Site Collection: als Beispiel ist die Frage im Vordergrund, wie Aggregationen über mehrere Site Collections gelöst werden. Mit SharePoint-Standardmitteln: Programmieren. Mit MatchPoint: Die Grenze existiert gar nicht. Wie sich der Content auf Site Collections etc. verteilt, spielt hier keine Rolle. Dank MatchPoint hat man über die entsprechende Konfiguration auf sämtliche Inhalte in einer Farm den einfachsten Zugriff.

Nebst den grundsätzlichen Funktionen des Framework wie sie oben beschrieben sind, bietet das Framework auch ein Set von zehn verschiedenen WebParts an. Diese dienen der Ein-/Ausgabe von Daten an den Endanwender und lassen sich entsprechend über Konfigurationen steuern. Alle MatchPoint-WebParts bauen auf den oben abgebildeten Funktionen auf. D.h. alle verstehen das Configuration Framework, das Connection-Framework, die Expression Engine etc.

Für den Entwickler sind die folgenden WebParts interessant (auch hier ist die Aufzählung nicht abschliessend):

  • Data Grid WebPart: Tabellarische Darstellung von Aggregationen und Suchergebnissen (insbesondere auch über mehrere SiteCollections). Dabei stehen die typischen SharePoint-Funktionen aus Listen/Bibliotheken wie Sortierung und Filterung ergänzend zur Verfügung.
  • Composite WebPart: mit dem Composite-WebPart können Aggregationen / Suchergebnisse speziell gerendert werden. Ein Beispiel: Bildersuche bei der die Ergebnisse als Thumbnails dargestellt werden.
  • Site Creator WebPart: Viele Firmen nehmen den klassischen Weg von SharePoint für die Erstellung einer Site als Zumutung wahr. Es braucht zu viele manuelle Schritte bis ein Space im Sinne des Unternehmens einsetzbar ist. Ursprünglich haben wir selbst in mehreren Projekten spezifische Site-Wizards gebaut, um diesem Problem zu begegnen. Mit dem Site Creator von MatchPoint erübrigt sich dies, weil damit über Konfigurationen die Site-Erstellung angeboten und für den jeweiligen Fall angepasst werden kann. Der Site Creator kümmert sich zudem um automatische Provisionierung der Inhalte und der relevanten Metadaten. Zudem können dabei auch gleich die entsprechenden Benutzer automatisch berechtigt werden. Für den Endanwender geschieht dies somit alles in einem Schritt.
  • Form WebPart: Hiermit kann ein Benutzer bestimmte Angaben erfassen. Diese können z.B. dazu verwendet werden, eine Liste bequem aufgrund von Benutzereingaben zu filtern.
  • Chart WebPart: Darstellung von Informationen in grafischer Form. Dies kann das Resultat von Suchabfragen wie auch Abfragen von anderen Quellen (z.B. SQL-Datenbank; Konfiguration über die DataProviders) sein.
  • Image Tag WebPart: Darstellung von Metadaten mittels grafischer Ausgabe (z.B. wird ein Prozessablauf dargestellt und ein Benutzer kann auf den entsprechenden Schritt klicken).
  • Workflow-Kit: dies ist eine Extension zum MatchPoint-Framework, welches die Konfiguration von Workflows anbietet, die aufgrund der Metadaten gesteuert werden. Somit ist dies eine einfache Art und Weise Status getriebene Workflows zu realisieren (Anmerkung: State Driven Workflows können im SharePoint-Kontext ansonsten nur mit Visual Studio programmiert werden).

Fazit zu MatchPoint und seinen Funktionen

Microsoft hat es leider verschlafen mit SharePoint ein einfaches Konfigurationsframework bereitzustellen, so dass effektiv über einfachste Mittel leistungsstarke Lösungen realisiert werden können. In diese Lücke springt MatchPoint und zeigt auf beeindruckende Weise, wie ein solches Framework wirklich funktionieren kann. Das Potenzial in der Kombination SharePoint und MatchPoint ist enorm. Die üblichen technischen Grenzen – insbesondere auf Site Collection-Basis – werden mit MatchPoint elegant gelöst. Aggregationen, Sichten etc. können über die ganze Farm hinweg erstellt werden. Aufgrund konkreter Beispiele wollen wir dies in den nächsten Artikeln der Serie vertiefen.

Weitere Details zum MatchPoint Framework können Sie der Website des Herstellers entnehmen.

One world Einführung

Veröffentlicht am von , 1 Kommentar

Stellt man SharePoint 2007 und SharePoint 2010 einander gegenüber, dann wird man viele Dinge finden, die sich nicht grundlegend verändert haben. Allerdings gibt es einen sehr interessanten, grundlegenden Wandel der klar zu Tage tritt: SharePoint 2010 ist viel serviceorientierter geworden. Viele SharePoint Features sind neu als Services implementiert. Mit dabei sind zentrale Funktionen wie die Profilverwaltung oder die Suche. Dies ist aber noch nicht alles! SharePoint 2010 bietet auch ein sehr flexibles Framework um unsere Custom Services in eine SharePoint Farm nahtlos zu integrieren. Dabei muss es sich bei einem Service nicht zwingend um einen ‚echten‘ Webservice oder WCF Service handeln. Vielmehr kann SharePoint 2010 auch zentrale Funktionen, die auf allen Frontend Servern verfügbar sein sollen als Service behandeln. Durch das Service Application Framework (SAF) können wir diese entsprechend einbinden.

In diesem Artikel wollen wir nicht die Möglichkeiten und Features diskutieren, die das SAF zur Verfügung stellt. Vielmehr wollen wir eine ‚top down‘ Übersicht darüber geben, wie das SAF und SharePoint 2010 unser Denken über die Integration von SharePoint Applikationen in einer Enterprise Umgebung verändern können.

Um dabei nicht zu theoretisch zu werden, wollen wir an einem Beispiel aufzeigen, wie Daten von einem Hybris Server (Produktinformationssystem) durch einen Service gelesen- und in SharePoint WebPart angezeigt werden können. Dabei soll das WebPart nicht direkt die Hybris Rest Services aufrufen, sondern wir wollen einen generischeren Hybris Connector als SharePoint Application Service anbieten. In unserem Beispiel soll dieser Service ein ‚echter‘ wcf-Service sein, der im IIS gehosted wird. Dabei erfolgt das Deployment des Service über eine SharePoint Solution und die Konfiguration wird in der SharePoint Central Administration vorgenommen. Weiter bindet SharePoint unseren custom Service in die Farmtopologie ein und kann den Zugriff auf den Service sowie Loadbalancing und Disasterrecovery für unseren Service mit anbieten.

Das Beispiel

2941-BeispielHConnector.jpg
  1. Ein Hybris Server wird als Datensenke benützt. Er stellt Rest-Services für den externen Zugriff bereit. Au der Hybris Seite sind keinerlei Änderungen nötig.
  2. Der Hybris Connector Service kann auf einem oder mehreren Servern in der Farm betrieben werden. Er wird über SharePoint Deployment Mechanismen verteilt und in der Central Administration konfiguriert. Der Service ruft die Rest Services von Hybris auf und erhält Daten im xml Format. Der Service parsed diesen xml-Stream und befüllt einfache .Net Datenobjekte, die über wcf an den Client zurückgegeben werden.
  3. Der Client kann über eine ServiceApplicationProxy Instanz auf den Service zugreifen. Dieser wird als Teil des Connector Service implementiert und von der SharePoint Farm zur Verfügung gestellt wird.

Schlussfolgerung

Was sind die Vorteile des hier vorgestellten Ansatzes? Warum wollen wir die Hybris Rest Services nicht direkt im Code behind des WebParts aufrufen? Die Antwort ist: Bessere Wiederverwendbarkeit, bessere Skalierbarkeit und bessere Isolation des Service Codes.
Wir wollen uns vorstellen, dass der Kunde sehr glücklich war, über das WebPart, das im Intranet direkt Produktdaten aus Hybris anzeigen kann. Weiter hat er sich dazu entschlossen, auch sein Internet neu zu lancieren. Unter anderem möchte er dabei einen Produkt-Teaser haben, der die Produktinformationen aus Hybris anzieht. Gut gemacht! Wir können ihm für dieses Feature einen sehr interessanten Preis offerieren, weil unser Hybris-Connector Service wiederverwendet werden kann. Nach dem Relaunch des Internet stellt sich nun heraus, dass die neue Website des Kunden zur beliebtesten Website des Jahres avanciert. Um die zunehmende Last abzufangen stellt der Kunde einige zusätzliche Frontend Server in seine Farm. Wie wird dabei unser Service skalieren? Der SharePoint Administrator erstellt auf den neuen Servern einfach zusätzliche Service Instanzen und SharePoint übernimmt automatisch das load balancing für den Service.
Natürlich ist die Implementierung des Hybris-Connector Codes in einem Application Service etwas aufwendiger als wenn man Hybris direkt vom WebPart aus aufrufen würde. Allerdings können wir leicht einsehen, dass der Zusatzaufwand sich in vielen Fällen leicht rechtfertigen lässt.
Zu guter Letzt wollen wir noch auf einen weiteren Aspekt der Service orientated Architecture (SOA) eingehen: In einem Unternehmen wird man niemals gewillt oder dazu in der Lage sein, den gesamten custom code als einen monolithischen Block in einem Aufwasch neu zu implementieren. Die Risiken und die Kosten sowie die internen Vorbehalte gegenüber einem solchen Unterfangen wären einfach zu gross. Gelingt es aber, einzelnen Anforderungen durch Services nach und nach abzudecken, dann können wir die notwendigen Modernisierungen und Veränderungen viel besser portionieren und schrittweise umsetzen.

Ausblick

Dieser Artikel soll der erste der Serie ‚One world‘ sein. Wir wollen an dieser Stelle mehre blog posts anbieten, die sich alle mit den Themen Services, Service Architektur und dem SAF befassen. Ein spannendes Gebiet, das zudem einen grossen Einfluss darauf haben kann, wie wir für SharePoint 2010 zukünftig Applikationen entwickeln können.

MatchPoint (Teil 1): Entwicklung komplexer SharePoint-Lösungen

Veröffentlicht am von , Kommentar hinterlassen

Mit diesem Blog-Post beginnen wir eine Serie zum Thema Entwicklung von komplexen SharePoint-Lösungen. Es stellt sich zuerst die Frage: ab wann ist eine SharePoint-Lösung komplex? Nun, leider ist man schneller in diesem Bereich als allgemein angenommen, denn das Produkt selbst ist aufgrund seines Funktionsumfangs und den vielen möglichen Wegen, wie eine Lösung aufgebaut werden kann, komplex genug.

SharePoint sollte als Framework betrachtet werden (es ist keine fixfertig Anwendung wie Microsoft Word das installiert wird und dann ist gut). Es ist ein Baukasten, der viele verschiedene Elemente und Funktionen enthält, mit denen ein Benutzer „arbeiten“ kann. Die Stärke liegt darin, wenn kleinere Teams/Arbeitsgruppen sich komplett selbst organisieren und es zur Zusammenarbeit anwenden. Sobald dies in etwas grösserem Zusammenhang betrachtet werden muss, besteht oft der Drang, dass eine gewisse Vereinheitlichung, Steuerung und auch übergreifende Funktionalitäten anzubieten.

Und hier beginnt die eigentliche Komplexität: das alles muss gut und sauber geplant und konzipiert werden. Und leider sind dank der Hochglanz-Broschüren des Produktes oft die Erwartungshaltungen wesentlich höher, als was dann mit Standardmitteln effektiv möglich ist. Ich habe als Berater schon sehr oft den Satz gehört „ich erwarte aber von einem Produkt wie SharePoint, dass es das einfach standardmässig kann“. Und hier lässt sich meist mit „ja, das geht…. ABER….“ antworten.

Es bleibt die Frage, mit welchen Mitteln baue ich denn überhaupt eine richtig gute SharePoint-Lösung? Diese soll exzellente Personalisierungsmöglichkeiten bieten, hoch dynamisch sein und natürlich völlig unterschiedliche Fragestellungen auf einmal lösen. Folgende Möglichkeiten stehen zur Verfügung:

  • Fokus auf Out-of-the-Box-Mitteln: ja, eine SharePoint-Lösung kann rein auf Basis von OOB-Mitteln realisiert werden. Das kann aber nur dann funktionieren, wenn Sie das Produkt und seine Funktionen so akzeptieren, wie es ist und Ihre Anforderungen sich am Produkt ausrichten. Und dies ist so in der Realität nicht anzutreffen, denn die Funktionen mögen für eine Firma wie Microsoft passen — aber ticken alle Firmen weltweit genau gleich wie Microsoft? Hier ist oft entsprechendes Frustpotential vorherzusehen (auf längere sichtweise)
  • Zusätzliche Eigenentwicklungen: SharePoint ist ein Framework und bietet somit eine weitere klare Stärke: das Teil kann praktisch unendlich mit allen sich erdenklichen Funktionalitäten erweitert werden. Hier steht im Prinzip die gesamte Funktionsfülle von Visual Studio und dem .NET-Framework zur Verfügung. Nachteil dieser Variante sind die hohen Kosten, erhöhte Projektrisiken, höhere Wartungsaufwände, komplexeres Change Management, Upgrade-Fähigkeiten etc.
  • Einsatz von Add-Ons: der Markt für Add-Ons/Erweiterungen zu SharePoint ist massiv am Wachsen. Dies zeigt, dass SharePoint nur Basis-Instrumente anbietet, aber nicht einfach alles damit gelöst werden kann. Betrachten wir die verschiedenen Kategorien von Add-Ons:
    • Ersatz von Standardfunktionen: diese Kategorie von Add-Ons zielt darauf ab, ganze Funktionen SharePoint mit mächtigeren Instrumenten zu ersetzen. Beispiel hierfür sind Workflow-Lösungen, Search-Lösungen, Analytics-Lösungen etc.
    • Erweiterungen mit neuen Funktionen: dies sind oft spezifische WebParts oder ganze Lösungen, die komplett neue Funktionen für SharePoint bereitstellen. Dies sollte jeweils genauer betrachtet werden, bevor ein individuelles WebPart entwickelt wird. Auf der Website „Codeplex“ findet sich eine Vielzahl von Open-Source-WebParts und Funktionen, die dies untermauern.
    • Funktionale-Frameworks: diese gehen weit über einzelne WebParts etc. hinaus. Diese umfassen eine Vielzahl von Funktionen / Möglichkeiten die sich ideal vernetzen und sich mit den Standardfunktionen von SharePoint kombinieren lassen. Ein solches Framework ist MatchPoint.

In unserer Serie wollen wir uns auf das SharePoint-Framework MatchPoint fokussieren und aufzeigen, welche Stärken und Vorteile es bei der Entwicklung komplexer Lösungen bringt.

Die Serie besteht aus den folgenden Artikeln: