Analyse und Bewertung einer Enterprise Searchengine auf der Basis von Microsoft SharePoint
Aus Winfwiki
| Namen der Autoren: | Markus Möller, Martin Schröder |
| Titel der Arbeit: | "Analyse und Bewertung einer Enterprise Searchengine auf der Basis von Microsoft SharePoint" |
| Hochschule und Studienort: | Fachhochschule für Oekonomie und Management in Hamburg |
1 Einleitung
"Wenn Siemens wüsste was Siemens weiß ..." Dieser nicht mehr eindeutig auf seinen Ursprung zurück zu verfolgende Satz beschreibt prägnant das Problem vor dem viele, vor allem größere Unternehmen stehen: Die vorhandenen Informationen müssen bei Bedarf sofort zum Zugriff bereitstehen. Dabei kann es sich um Informationen handeln, die in einem der vielen Informationssysteme des Unternehmens abgespeichert sind, es können aber auch Informationen sein, die in den Köpfen der im Unternehmen angestellten Know How Träger vorhanden sind. Dabei sind Informationen neben den klassischen Produktionsfaktoren Arbeit, Boden und Kapital der zunehmend entscheidende Faktor zum Generieren von Wettbewerbsvorteilen. Die Wettbewerbsvorteile müssen mehr denn je nicht nur erlangt sondern auch verteidigt werden. Aufgrund der Globalisierung sind Einstiegsbarrieren teilweise gesenkt, da Produkte z.B. weltweit erworben werden können und Unternehmen so einer globalen Konkurrenz gegenüber stehen. Es gibt kaum noch Geschäftsprozesse, die nicht durch ein IT gestütztes Informationssystem abgebildet werden. So entsteht zunehmend die Herausforderung des Auffindens aller relevanten Informationen. Oft ist auch nicht die eine Information gefragt, sondern es werden mehrere Informationen in Kombination benötigt, die aus verschiedenen Systemen stammen. Des Weiteren wird dann auch der Mitarbeiter benötigt der als Träger einer Information und durch sein spezifisches Fachwissen das Unternehmen erst in die Lage versetzt die relevanten Informationen zu einem Ganzen zu verknüpfen. Hier setzt Enterprise Search an um dieses Problem zu beseitigen. In der folgenden Fallstudie soll nun untersucht werden, inwieweit die Search Engine von Microsoft SharePoint einem Lösungsansatz dieser Problematik gerecht wird.
2 Grundlagen
2.1 Information Retrieval
Die Anwendung von Information Retrieval löst zwei Problemarten, die entstehen, wenn eine Person oder abstrakter, ein Objekt einen Informationsbedarf hat.[1] Der Bedarf kann konkret sein, wie bei der Fragestellung "wie groß ist der Umfang einer Hausarbeit bei der FOM". Der Bedarf kann jedoch auch unschärfer gefasst sein, daher problemorientiert wie "in welchem Umfang haben Junk Bonds in den 1980ern zu Unternehmensgründungen und Erweiterungen beigetragen".[2] Suchmaschinen sind folglich die Werkzeuge mit denen Information Retrieval betrieben wird.
Es existieren verschiedene Retrieval-Modelle, mit Hilfe derer Informationen aus Informationsspeichern wieder aufgefunden werden können. Hierbei ist nicht die technische Wiederauffindbarkeit gemeint, sondern die Fähigkeit alle Dokumente in einem Informationsspeicher zu bewerten und lediglich die am höchsten bewerteten Informationen zurückzugeben. Stock teilt die Modelle in vier Klassen ein: Boolscher Ansatz, informationslinguistischer Ansatz, Vektorraum Ansatz und probabilistischer Ansatz.[3]
Der boolsche Ansatz in seiner ursprünglichen Form ist boolsche Algebra. Wahrheitswerte werden mit den Operatoren UND, ODER sowie UND NICHT miteinander verbunden. Das Ergebnis ist entweder wahr oder falsch.[4] Es sind auch Verfeinerungen möglich mit Abstandsoperatoren[5] und Häufigkeitsoperatoren.[6] Diese harte Trennung wird mit dem erweiterten boolschen Ansatz aufgefangen indem Gewichtungen von Thermen eingeführt werden.[7]
Der informationslingusitische Ansatz betrachtet Informationen als Ansammlung von Buchstaben aus denen zum Beispiel n-Gramme gebildet werden können. Die Sprache der zugrundeliegenden Informationen ist dabei irrelevant.[8] Weitere Methoden, die dieser Ansatz verwendet sind Stoppwörter, die nicht dazu führen dass Begriffe nicht gefunden werden: "bienen und honig" wird gefunden auf die Anfrage "bienen honig".[9] Mit der Lemmatisierung werden Grundformen gebildet: "Büchern" wird zur Grundform "Buch".[10] Mit Stemming werden Wortstämme gebildet, so würde "Weihnachten" auch "Weihnachtsmann" finden.[11]
Im Vektorraum Ansatz sind die Informationen des Informationsspeichers sowie die Anfragen als Vektoren realisiert. Zeilen repräsentieren die Dokumente, Spalten die ggf. gewichteten Terme. Dokumente sind umso relevanter desto geringer der Abstand der Winkel von Anfrage- und Dokument-Vektoren ist.[12]
Beim probabilistischen Ansatz wird ausgegeben, wie wahrscheinlich es ist, dass ein Dokument relevant für den Anfrager ist. Das Modell lässt außer Acht, dass der Grenznutzen weiterer relevanter Informationen mit zunehmender Anzahl abnimmt. Der Ansatz arbeitet außerdem mit einer Form des Relevanzfeedbacks, entweder durch mehrfache Abfragen oder Sammeln von Nutzerverhalten.[13]
Es sei angemerkt, dass die Modelle auch miteinander kombiniert verwendet werden.
2.2 Suchmaschinenarten
Croft et al. unterscheiden zwischen fünf Suchmaschinengebieten, die für jeweils spezielle Einsatzzwecke entwickelt sind. Das Web search umfasst das World Wide Web (WWW) und bildet das bekannteste Gebiet ab. Ein spezialisierter Unteraspekt des Web Search ist der Vertical Search, der nicht das gesammte WWW indiziert, sondern Thementeile daraus. Das Enterprise Search beschäftigt sich mit der Indizierung von Inhalten in Unternehmen. Die Unterschiede zum Web Search werden in den Bewertungskriterien deutlich gemacht. Das Desktop Search ist die kleine Variante des Enterprise Search, da hier zum Teil die gleichen Fragestellungen behandelt werden. Das Peer-to-Peer Search beinhaltet das Suchen und Auffinden von Informationen ohne zentrale Instanz, so wie es bei den anderen Suchmaschinenarten der Fall ist.[14]
2.3 SharePoint
Microsoft SharePoint, so wie der Begriff im weiteren Verlauf verwendet wird, besteht aus zwei Teilkomponenten: Microsoft Office SharePoint Server 2007 bildet dabei das Produkt für Zusammenarbeit und Informationsverwaltung aus der Microsoft Office Familie. Es enthält die Microsoft Windows SharePoint Services 3.0. Diese separat nutzbare, nicht eigenständig zu lizenzierende Komponente ist Teil des Betriebssystems Windows Server 2003.[15] In Verbindung mit den Qualitäten der Search Engine stellt sich die Abstufung folgendermaßen als Kontinuum dar: Die Windows SharePoint Services stellen, möglicherweise erweitert um Microsoft Search Server 2008, das untere Ende dar. Für den Bereich Enterprise Search kommt dann der Microsoft Office SharePoint Server in Betracht. Als High End Produkt hat Microsoft noch den Suchtechnologieanbieter Fast Technology and Transfer (FAST) gekauft.[16] Der Search Server bietet nahezu dieselben Funktionen, wie sie in Microsoft Office SharePoint Server enthalten sind. Er ist in der Express Variante ebenfalls kostenlos. Die Vollversion ist vor allem nicht auf einen Server beschränkt.[17] Im Verlauf dieser Fallstudie wird aber ausschließlich der Microsoft Office SharePoint Server 2007 untersucht werden.
3 Enterprise Search
3.1 Basis-Umfeld
3.1.1 Ontologien
Durch Ontologien werden anders als bei Taxonomien Verhältnisse von Informationen zueinander abgebildet. Eine Ontologie erlaubt es Menschen sowie Softwareprogrammen Zusammenhänge zwischen Informationen zu erkennen. Durch das semantische Modell, welches die Ontologie bereitstellt, wird es möglich mit verschiedenen Anfragen auf die semantisch gleichwertigen Antworten zu stoßen. Das Ontologiesystem kann manuell erstellt oder von einem System bereitgestellt worden sein. In Unternehmen sind Ontologien und Taxonomien tendenziell eher vorhanden als im Internet.[18] Auf die Thematik der Taxonomie wird später noch genauer eingegangen.
3.1.2 Metadaten
Metadaten, also Informationen über Informationen, sollten im Unternehmen vorhanden sein. Wenn im Unternehmen vorhanden, helfen diese Informationen, allgemein gültige Beschreibungen über Wissen zu erstellen und dieses kontextbezogen korrekt zu benutzen. Durch einheitliches Management von Metadaten wird erreicht, dass im Unternehmen über dieselben Dinge gesprochen wird und Informationen eindeutiger werden.[19]
3.1.3 Coverage
Coverage gibt an, wieviel der Grundgesamtheit an vorhandenen Informationen indiziert wurde.[20] Je höher der Coveragewert, desto grundsätzlich besser kann der Precision/Recall-Wert sein. Hier ist es gleich ob es sich um Enterprise oder Web Search handelt. Wie in späteren Kapiteln noch erläutert wird, hat es das Enterprisesearch per Definition grundsätzlich leichter einen höheren Coverage Wert zu erreichen. Der Wert der Web Search Coverage im Jahr 1999 ist laut einer Studie von Thelwall relativ gering mit 16%.[21] Dieser Wert ist laut einer Studie Thelwall/Vaughan, je nach Suchmaschine, auf bestenfalls 72% erhöht worden.[22] Dies ist bedingt durch technische oder sicherheitstechnische Einschränkungen.
3.1.4 Freshness
Als Freshness bezeichnet wird die Aktualität einer indizierten Informationsressource bezeichnet. Das Gegenteil eines aktuellen Indexes ist ein veralteter, der nicht mehr die aktuellsten Änderungen der Informationsressource beinhaltet.[23] Grundsätzlich gilt, je aktueller der Index, desto besser. Im Internet ist es normalerweise nicht möglich vorauszusehen, wann sich Inhalte ändern werden. Für derartige unbekannte Quellen kann das Alter einer Informationsressource geschätzt werden. Daraus geht hervor wie alt eine Seite ist; die ältesten Seiten sollten daher indiziert werden.[24]
Je nach Informationsart werden im Unternehmensumfeld aktuelle Suchergebnisse verlangt, die nicht älter als 1 Tag sein sollten.[25] Wie die Internet Search hat auch der Enterprise Search Bereich die gleichen Probleme um die Veränderung von Inhalten zu registrieren.[26] Allerdings sind im Enterprise Umfeld öfter die Zeitpunkte bekannt, wann sich Inhalte geändert haben. Grundsätzlich gilt, dass im Enterprise Umfeld Inhalte öfter geändert werden als dies im Internet der Fall ist.[27]
3.1.5 Inhalte
Die Inhalte in einem Unternehmen zeichnen sich unter anderem durch folgende Eigenschaften aus:
Nichtexistenz von Spam
Die Bezeichnung "Spam" (Abwandlungen wie "Spamming", "Spamdexing" und "Linkspamming" sind als gleichwertig anzusehen) wird von Gyöngyi und Garcia-Molina definiert als eine Methode um Relevanz für einen Suchtreffer vorzutäuschen. Spam ist daher kontraproduktiv um dem Benutzer eine relevante Antwort auf seine Anfrage zu liefern. Es ist deutlich von Search Engine Optimization (SEO) zu unterscheiden, da hier eine Website besser gefunden werden soll und sie zugleich die gesuchte Information enthält.[28] Es existieren noch weitere Definitionen von Spam, die von den Autoren jedoch als gleichwertig, mindestens jedoch ähnlich zu oben angegebener Definition angesehen werden.[29][30][31]
Nach der Definition von Spam sind die Informationen im Intranet generell frei von Spam in jeglicher Hinsicht. Mitarbeiter haben generell kein Interesse daran, Dokumente falsch zu verlinken. Durch diesen Umstand ist es sogar sinnvoll, den Linktext mit der Logik selbst auszuwerten, daher wird, wenn im Linktext der gesuchte Term enthalten ist, die verlinkte Seite als wertvoller eingestuft.[32]
Relevanz von SEO
SEO wird betrieben um die eigene Website im Vergleich zu anderen Websites in einem hohen Ranking zu platzieren.[33] Mit dieser Definition ist SEO im Enterprise Search Bereich unnötig. Wird eine allgemeinere Definition gefasst, sodass SEO lediglich dazu dient Verkehr auf eine Website zu lenken, so ist SEO im Unternehmensbereich doch wieder relevant.[34] Dieser Punkt wird erneut aufgegriffen werden in Punkt 4.2.2. in dem bestimmte Formatierungsregeln eingehalten werden sollten.
Linkanzahl
Der Großteil des Content im Enterprise Umfeld liegt nicht in HTML vor. 90% des Content besitzt folglich keine Hyperlinks, wie dies im Internet der Fall ist.[35]
3.2 Kriterien
In diesem Kapitel werden die Kriterien aufgestellt und erläutert, die für die Klassifizierung von Enterprise Search Systemen herangezogen werden. Es wird dabei eine Aufteilung in technische und fachliche Kriterien vorgenommen. Sie dient der Lesbarkeit und kann nicht ganz trennscharf durchgeführt werden.
3.2.1 Technisch
3.2.1.1 Deep Web
Ein grundlegendes Kriterium, welches das Web Search vom Enterprise Search unterscheidet, ist das Durchsuchen von Informationen, die nicht sofort abrufbar sind. Das heißt, dass die Internetsearch ausschließlich auf Informationen sucht, die über einen Hyperlink verfügbar sind. Sobald ein Informationsangebot über ein Formular erreichbar ist, welches z. B. die Eingabe unterschiedlicher Parameter erlaubt, so endet die Indizierung an diesem Punkt. Dies wird allgemein als "Deep Web" oder "Hidden Web" bezeichnet, da Informationen, die hinter der Barriere des Formulars liegen, nicht ausgewertet sind.
Würde der Inhalt indiziert werden sollen, so müsste der Crawler die unterschiedlichen Formulare bedienen können. Das heißt, dass Suchargumente in korrekter Konstellation zueinander verknüpft werden müssen. Gleiches gilt für die Auswertung der Ergebnismengen, die möglicherweise im Fließtext als Antwort auf die Anfrage geliefert wird.[36]
Im Intranet ist es praktisch möglich, im Gegensatz zum Internet, einen direkteren Zugriff auf die relevanten Daten zu erhalten. Im Falle der Formulare bedeutet dies: Zugriff auf die Datenbank, also Durchsuchbarkeit des "Hidden Web". Dies ist ein elementares Kriterium.
3.2.1.2 Rechtesystem
Informationen im Internet sowie Intranet sind nicht jedem uneingeschränkt zugänglich. Grundsätzlich wird im Internet alles gecrawled, auf das der Crawler Zugriff erhält.[37] Der augenscheinliche Zugriff der Suchmaschine kann zu dem des Benutzers abweichen. Normalerweise sollte der Crawler lediglich auf dieselben oder wegen der Deep Web Thematik, auf weniger Daten zugreifen können als ein normaler Benutzer. Jedoch werden wiederholt Fälle bekannt, in denen mehr gecrawled wird als öffentlich sichtbar ist.[38][39] Dies soll verdeutlichen, dass Internetsuchmaschinen per Definition nicht ausschließlich das öffentliche Web indizieren.
Es ist denkbar, dass auch im Intranet Daten durch Sicherheitslücken Personen zur Verfügung stehen, die keinen Zugriff auf diese Daten haben sollen. Im Intranet sind die Informationen in der Regel nur begrenzten Personenkreisen zugänglich. Trotzdem sollen alle Informationen indiziert werden. Die Enterprise Search Engine muss folglich Mechanismen unterstützen um bestimmten Personen Daten vorzuenthalten. Es ist darauf hinzuweisen, dass in Unternehmen unterschiedliche Berechtigungssysteme vorliegen können, sodass diese Berechtigungen harmonisiert werden müssen.[40]
3.2.1.3 Datenquellen
Um eine vollständige Abdeckung an gebotenen Informationen gewährleisten zu können, muss Enterprise Search mit verschiedenen Datenquellen umgehen können.[41] Die Art in der Informationen gespeichert werden, ist vielschichtig. Zum einen auf welchen Einheiten, zum anderen in welchen Formaten sie auf diesen Einheiten gespeichert sind.[42]
Die Formate, die auf Fileservern abgelegt sind, bestehen aus dutzenden Standards. Werden im Web Inhalte beispielsweise über Common Gateway Interface Scripte, Active Server Pages einfache Hyper Text Markup Language (HTML) und einer Vielzahl noch weiterer Techniken bereitgestellt, kommen im Unternehmen noch weitere Formate hinzu. Die Formate können veraltet sein und ggf. mit Programmen erstellt worden sein, von denen keine aktuellen Versionen mehr existieren. Ebenso müssen aktuelle Formate lesbar und somit indizierbar gemacht werden können.[43] Diese Formatvielfalt zu unterstützen, ist wichtig, da laut Mao und Mukherjee lediglich 10% des Inhalts in Unternehmen in HTML vorliegen.[44]
E-Mail bildet ebenfalls ein Medium in dem relevantes Wissen gespeichert ist. Hier ist zu beachten, dass verschiedene E-Mailsysteme existieren (z.B.: Lotus Notes, Microsoft Exchange usw.).[45]
Anders als im Internet ist es im Unternehmen möglich unmittelbar auf Datenbanken zuzugreifen.[46] Die Fähigkeit auch solche Daten erfassen zu können zu denen keine Oberflächen für die Anzeige existieren, ist ebenfalls ein relevantes Kriterium.
Da die Informationen nicht ausschließlich auf E-Mail-Servern, File-Servern usw. abgelegt sind, sondern auch auf den Desktop-Rechnern der Mitarbeiter, sollte hier ebenfalls eine Indizierung des Inhalts möglich sein.[47]
3.2.1.4 Federated Search
Nicht alle Informationsquellen müssen durch die Enterprise Search Engine direkt gecrawled werden. Der Federated Search Ansatz nutzt vorhandene Schnittstellen zu anderen Search Engines. Von dieser fremden Quelle werden die Ergebnisse einer Abfrage geladen und ggf. transformiert für den Benutzer bereitgestellt. Hierbei wird die Suchfunktionalität der fremden Quelle benutzt. Dies schließt Indizes genauso ein wie ein eventuell existierendes Sicherheitssystem.[48][49]
3.2.2 Fachlich
3.2.2.1 Recall und Precision
Recall und Precision werden häufig in Verbindung erwähnt. Sie sind ein Qualitätsmerkmal über die gelieferten Informationen von einer Anfrage. Recall bezeichnet, wie vollständig alle potenziellen Informationen aus der Grundgesamtheit der Informationen ermittelt worden sind. Dieser Wert für sich misst noch nicht ob eine Abfrage gewinnbringend war. Erst in Verbindung mit dem Wert der Precision, also der Aussage, wieviele Informationen aus der zurückgelieferten Menge an Informationen für den Anfragenden relevant sind, ist eine Anfrage qualitativ bewertbar.[50]
Beim Enterprise Search ist es wichtig, einen hohen Precision Wert zu haben. Im Gegensatz zur Internet Search gibt es hier weniger Informationen, die für die Anfrage von Relevanz sind.[51] Beim Enterprise ist es also wichtig, dass auch Informationen gefunden werden, die fallweise nur einmal oder nur in geringer Anzahl vorhanden sind und nicht paraphrasiert wurden. In Unternehmen ist es oftmals der Fall, dass für eine Fragestellung nur wenige Dokumente die richtige Antwort enthalten, z.B. "Wo kann ich mein Passwort zurücksetzen lassen".[52]
3.2.2.2 Application Programming Interface
Auf die Inhalte der Enterprise Search Engine sollte nicht nur via grafischer Benutzeroberfläche zugegriffen werden können, sondern auch maschinell. Erreicht wird dies durch die Bereitstellung eines Application Programming Interface (API). Andere Programme können so die Inhalte nutzbar machen.[53] Dieses Kriterium bietet das Equivalent zum bereits erläuterten Federated Search, bei dem die Enterprise Search Engine selbst aktiv via APIs bei anderen Search Engines Anfragen absetzt.
3.2.2.3 Taxonomien
Das User Interface bildet die Schnittstelle zur Enterprise Searchengine. Sie sollte alle Informationen an einem zentralen Punkt so aufbereiten, dass sie für den jeweiligen Einsatzzweck optimal zu verarbeiten sind. Dies kann erreicht werden durch das Bilden von Taxonomien. Es sind zwei Arten zu unterscheiden: automatische und manuell gebildete Taxonomien. Die manuelle Variante ist z.B. beim Webkatalog von Yahoo zu sehen. In Unternehmen, wie auch im Internet, steigt die Menge an Information kontinuierlich an. Derartige Taxonomien für die Ergebnisse in der Suche manuell zu pflegen wird dadurch zunehmend zeitaufwändiger. Es ist daher als nutzbringend anzusehen, dass sogenanntes "facetted search" oder "document clustering" automatisch von der Enterprise Searchengine vorgenommen wird.[54]
3.2.2.4 Personalisierung
Durch Personalisierung kann erreicht werden, dass Suchabfragen besser beantwortet werden können, da Informationen über den Kontext einer Person bekannt sind. Zu der Personalisierung gehört nicht nur die Pflege eines eigenen Benutzerprofils, sondern auch z.B. die Nutzung eines Unternehmens Verzeichnis über die hierarchische Struktur. Ferner kann die Personalisierung auch dafür genutzt werden, Benutzungsstatistiken zu speichern, die ausgewertet zu weiteren Verbesserungen in der Ergebnismenge führen können.[55] Die Personalisierung wird daher als sehr wichtiges Kriterium angesehen.
3.2.2.5 Information Extraction
Informationen lassen sich grob in strukturierte und unstrukturierte Daten aufteilen. Innerhalb dieser beiden Gruppen gibt es Abstufungen. Im Unternehmen sind nicht alle Informationen strukturiert abgespeichert, wie dies z.B. in einer Datenbank der Fall wäre. Hier sind Informationen auch in einer semistrukturierten Art abgespeichert. HTML ist als so eine Struktur zu sehen, kann doch zum Beispiel der Titel bereits an dem "Title" Tag erkannt sowie Metainformationen aus den Metatags extrahiert werden.[56]
Mit Hilfe von Regeln oder Wörterbüchern können Informationen aus Fließtext extrahiert werden. Eine Regel könnte Straßennamen extrahieren nach dem Muster "<Wort><'Straße'><Nummer>". Der Vorteil hiervon ist, dass im Voraus nicht bekannt sein muss, welche Wörter ggf. gesucht werden. Der Wörterbuchvergleich kann im Unternehmen sinnvoll sein, da hier eine Vielzahl von internen Begriffen verwendet wird, die Unternehmensweit eindeutig sind, wie z.B. Mitarbeiternamen, Geschäftsbereiche etc. Jedoch auch um Informationen wie Stückzahlen, Umsatzzahlen etc. zu extrahieren, bietet sich das Wörterbuch an.[57][58]
3.2.2.6 Expertenwissen
In Unternehmen sind Mitarbeiter angestellt, die für die Erreichung von Unternehmenszielen eingestellt wurden. Sie erhalten einen Ausgleich für die Arbeit. Dies ist eine Ressource, die unbedingt auch in Enterprise Search Engines genutzt werden sollte.[59]
Expertenwissen kann dann sinnvoll sein, sobald ein Thema komplex ist. Beispielsweise benötigt ein Mitarbeiter Informationen über Thema A in Verbindung mit Thema B. Mithilfe einer Suchmaschine werden Dokumente zu jeweils Thema A oder Thema B gefunden. Der Informationswunsch wird dadurch nicht gedeckt. Er benötigt eine Kombination der beiden Themen in einem Dokument. Da dieses Dokument nicht existiert kann eine Suchabfrage niemals das gewünschte Ergebnis erzeugen. Es kann folglich notwendig sein, direkt nach einem Mitarbeiter zu suchen, der über Expertise in beiden Gebieten verfügt um so den Informationsbedarf decken zu können. Diese Form ist direkter als das "Community-based question answering" (CQA) welches lediglich ein Forum für spezielle Fragen darstellt.[60]
3.2.2.7 Enterprise Bookmarking
Durch Enterprise Bookmarking werden einzelnen Dokumenten Metainformation hinzugefügt. Dies kann erfolgen durch Tags. So könnte ein Mitarbeiter bestimmte Dokumente als "Dokumentation" oder "Kundeninfo" taggen. Wie aufgezeigt ist dies ein manueller Vorgang. Der Mitarbeiter unterstützt die automatische Indexierung bei der Bewertung von Inhalten.[61]
Laut der Studie von Croft und Rajashekar steigert eine Kombination aus automatischer und manueller Indexierung die Treffergüte.[62] Auch andere Studien kommen zu diesem Ergebnis.[63][64]
3.2.3 Kurz-Übersicht
Zur Bewertung, inwieweit Microsoft SharePoint die Kriterien des Enterprise Search erfüllt, zeigt Tabelle 1 noch mal die Erfüllungskriterien zusammengefasst:
| Kriterium | Relevanz |
| "Hidden Web" Durchsuchbarkeit | hoch |
| Extensives Rechtesystem | hoch |
| Unterschiedliche Datenquellen | hoch |
| Recall und Precision | hoch |
| Taxonomien | hoch |
| Personalisierung | hoch |
| Federated Search | normal |
| API | normal |
| Information Extraction | normal |
| Expertenwissen nutzen | normal |
| Enterprise Bookmarking | normal |
Tabelle 1: Kriterienübersicht
4 Microsoft SharePoint
4.1 Aufbau
4.1.1 Allgemein
4.1.1.1 Farms
| SharePoint ist eine hoch skalierbare Plattform. Das bedeutet, dass die einzelnen Rollen der Plattform sowohl auf einem Server zusammengefasst, als auch auf viele verschiedene Server verteilt werden können, um Ausfallsicherheit und Verfügbarkeit zu erhöhen. Bezogen auf den Untersuchungsgegenstand dieser Fallstudie, die Search Engine, sind die Hauptrollen der Web Frontend Server (WFE), der Indexdienst, die Query Engine und als Basis die Datenbank.[65]
Aufwärts skalierend können diese Rollen in folgender Weise verteilt werden:[66]
|  In Anlehnung an Rizzo et al. (2008), S. 29 ff. Abb. 1: SharePoint Serverfarm Konfigurationen |
4.1.1.2 Shared Service Provider
Der Shared Service Provider (SSP) nimmt innerhalb einer SharePoint Serverfarm eine bedeutende Rolle ein. Er verwaltet eine Reihe von zentralen Diensten, die innerhalb der Farm von verschiedenen Anwendungen gleichermaßen zur Verfügung stehen. Die Suche ist eine davon.[67] Neben der Suche sind weitere Dienste innerhalb des SSP der Business Data Catalog (BDC) und das User Profile Management, die für diese Fallstudie von Bedeutung sind. Ohne Relevanz im weiteren Verlauf sind die Dienste Sitzungsverwaltung, Excel Services oder Forms Services.[68]
4.1.2 Search Engine
Die SharePoint Search Engine setzt sich aus verschiedenen Komponenten zusammen, die teilweise schon Erwähnung fanden. Sie seien hier noch einmal kurz und prägnant herausgestellt und Ihre Bedeutung explizit erläutert. Zunächst ist der Indexserver für die Indizierung des Inhalts und seiner Metadaten zuständig. Er erzeugt genau einen Index, der innerhalb des Dateisystems abgelegt wird und speichert die Metadaten innerhalb einer Datenbank des SSP. Der Web Frontend Server dient den Benutzern zur Anzeige der Seiten einer SharePoint Farm, aber auch der Indexserver greift über ihn auf die Inhalte der SharePoint Farm zu. Der Query Server beantwortet die Suchanfragen der Benutzer. Zum einen erhält der vom Indexserver den Index als lokale Kopie, zum anderen bezieht er die Metadaten vom Datenbankserver. Dieser Datenbankserver wiederum hält neben den Metadaten auch die Sucheinstellungen und die Indizierungslogs vor.[69]
4.2 Indizierung
4.2.1 Allgemeine Arbeitsweise
Obwohl der Indexserver Teil von SharePoint ist und somit über die Existenz der Content Datenbank weiß, läuft der Indexprozess so ab, dass die URL über DNS aufgelöst wird und die betreffende Seite dann vom Web Frontend Server (WFE) abgerufen wird. Dieser bezieht seine Informationen zur Darstellung und Weitergabe der Seite dann analog zur normalen Benutzeranfrage aus der Content Datenbank bzw. aus seinem Cache. Ist die Seite beim Indexserver angekommen, so zerlegt er sie in den Index einerseits und die Metadaten andererseits. Spätestens ab einer 3-Server-Farm kann es hier zu einer größeren Netzwerkbelastung kommen. Dies beruht darauf, dass der separate Indexserver, den ebenfalls von den Benutzern frequentierten WFE crawlt. Der WFE, wiederum über das Netzwerk, kontaktiert zur Beantwortung der Indizierungsanfrage den Datenbankserver.
Abb. 2: SharePoint Indexserver indiziert sich selbst
Um dies zu optimieren, besteht die Möglichkeit dem Indexserver selbst eine Rolle als WFE zu geben, ohne diese den Benutzern bekannt zu machen. Lediglich der Indizierungsprozess wird darüber in Kenntnis gesetzt. Dies funktioniert entweder über eine Einstellmöglichkeit oder (empfohlen, da so ein separates Netzwerkinterface adressiert werden kann) über einen Eintrag in der hosts des Indexservers zum Überschreiben der DNS-Antwort.[70]
Es existieren zwei Arten von Crawls: Full crawls und incremental crawls. Wie der Name vermuten lässt, geht es dabei darum im ersteren Fall die genannten Quellen vollständig, im letzteren Fall dagegen nur inkrementell zu indizieren. Inkrementell bedeutet dabei, dass lediglich geänderte Inhalte berücksichtigt werden. Im Zuge der bereits erwähnten intensiven Beanspruchung der verschiedenen Ressourcen bei einem Indizierungsprozess ist der inkrementelle Vorgang in den meisten Fällen vorzuziehen und ausreichend. Vor allem in produktiven Zeiten ist eine vollständige Indizierung hinderlich und sollte daher maximal in unproduktive Nachtstunden verlegt werden. Der Unterschied der Vorgehensweise ist dabei, dass der vollständige Crawl die genannte Quell-URL anfragt und dort den Webservice sitedata.asmx kontaktiert. Dieser liefert dann alle URLs der Quelle, die dann einzeln nach o.g. Vorgehensweise angefragt und indiziert werden. Bei der inkrementellen Vorgehensweise wird zwar ebenfalls der genannte Webservice kontaktiert, in diesem Fall liefert er aber unter Zuhilfenahme eines Änderungsprotokolls nur die seit dem letzten Vorgang geänderten URLs zurück. Diese werden vom Indexserver dann auch als Änderungen direkt in den aktuellen Index geschrieben. Dem gegenüber steht der komplette Austausch des Index beim vollständigen Prozess.[71] Bei der fortlaufenden Aktualisierung des Index stellt damit die sofortige Verfügbarkeit für Suchanfragen einen weiteren Vorteil dar.[72] Extrem effizient ist der inkrementelle Vorgang allerdings nur bei SharePoint Inhalten. Andere Inhalte unterliegen gewissen Abstrichen. Bei Dateien aus dem Dateisystem oder Microsoft Exchange prüft der Indexserver die Zeitstempel der einzelnen Inhalte, was aber immer noch als schnell bezeichnet wird. Gewöhnliche Websites hingegen müssen pro Seite über eine http Anfrage auf das Änderungsdatum überprüft werden, hier ist zeitlich mit Einschränkungen zu rechnen.[73]
Leider lässt sich das Ressourcenproblem beim Indizieren nicht durch das Einsetzen mehrerer Indexserver bekämpfen. Dies ist nicht möglich, da es pro SSP nur einen Indexserver geben kann.[74] Da der Indexserver somit einen Single-Point-of-Failure darstellt, sollte dieser möglichst mit redundanter Hardware ausgestattet werden um seine Verfügbarkeit zu erhöhen.[75] Ebenso hilft gleichzeitig produktiv nutzbare Hardware dabei die Geschwindigkeit des Indexprozesses zu erhöhen. So kann ein Raid-10 als Array für den Index im Dateisystem signifikant die Performance erhöhen.[76] Da der Indexprozess mit mehreren Threads gleichzeitig arbeiten kann, wird auch der Einsatz mehrerer CPUs optimal ausgenutzt. Standardmäßig setzt der Indexprozess, abhängig von der Hardware, bis zu 64 Threads ein. Dies kann aber manuell über die Registry konfiguriert werden.[77] Dennoch gibt es letztlich ein getestetes Maximum von 50 Millionen Einträgen pro Index. Das Ausweichen und Aufteilen auf mehrere getrente SSPs ist auch beschränkt. Empfohlen sind 3 pro Fram, 20 sind das harte Limit. Auch kann ein Suchergebnis nicht aus mehreren SSPs gleichzeitig bezogen werden.[78]
4.2.2 Wörtertrennung und Wortstammerkennung
Zwei ähnliche Punkte, die der Verbesserung der Suchergebnisse dienen sollen, sind die Wortstammerkennung und die Wörtertrennung. Erstgenannter findet bei der Suche Anwendung und kann daher in den Suchwebparts ein- und ausgestellt werden. Die Wörtertrennung hingegen findet bereits bei der Indizierung statt. Hierbei geht es nicht um die bloße Reduzierung eines Wortes auf seinen Stamm sondern um die Zerlegung eines Wortes in seine Einzelteile. So ist das Wort Kernkompetenz in die Teile Kern und Kompetenz zerlegbar, die selbständige Bedeutungen haben, bei der Suche nach den Teilen kann dann aber durchaus auch das zusammengesetzte Wort Suchtreffer mit einer gewissen Relevanz erzeugen.[79] Insbesondere die deutsche Sprache ist reich an zusammengesetzten Wörtern. Dies resultiert in einem ressourcenintensiveren Indexprozess.[80] Es ist möglich über sog. Custom Dictionaries Wörter anzugeben, die durch den Indexprozess nicht getrennt werden, sondern in ihrem ursprünglichen Wortlaut im Index auftauchen sollen.[81] Um der Wörtertrennung die Arbeit zu erleichtern, wird empfohlen in Titeln und Dateinamen Leerzeichen (Beispiel?) einzufügen.[82] Dies ist einer der wenigen Punkte von SEO im Bereich eines Intranets.
4.2.3 Metaindizierung
Es gibt zwei Arten von Daten, die von einer Suchmaschine verarbeitet werden: Strukturierte und Unstrukturierte Daten. Die vorigen Abschnitte zielten speziell auf unstrukturierte Daten wie der Inhalt von Textdokumenten, E-Mails oder Websites ab. Strukturierte Daten sind dagegen tabellarisch darstellbar und zielen neben den klassischen relationalen Datenbankinhalten vor allem auf Metadaten der o.g. Dokumentenarten wie Titel, Autor u.a. ab. SharePoint erkennt diverse Arten von Metadaten automatisch und speichert diese beim Indexprozess separiert vom eigentlichen Index in der SSP Datenbank in Tabellen ab. Diese automatisch erkannten Metadaten, zu denen Dateieigenschaften, SharePoint Spalten, HTML Meta Tags oder auch Datenbankfelder gehören, werden als Crawled Properties bezeichnet.[83] Des Weiteren existieren Managed Properties die manuell erzeugt werden. Dabei wird eine Managed Property angelegt und ihr eine oder mehrere Crawled Properties hinzugefügt. Die Managed Property dient nun dazu um explizit danach suchen zu können, in den Suchergebnissen explizit angezeigt werden zu können, bei der Einordnung in Suchbereiche (Scopes) zu helfen oder um die Relevanz zu beeinflussen.[84] Der Sinn und Vorteil der Managed Property ist dabei der, dass so verschiedene Spalten bzw. Properties trotz unterschiedlicher Namen und Herkunft vereinheitlicht werden können. Ein „Last Name“ hat eine ziemlich eindeutige Bedeutung, kann aber aus unterschiedlichen Quellen stammen und daher, teilweise syntaktisch bedingt, völlig unterschiedliche Namensschreibweisen (Last Name, LastName, ows_Last%20Name, ...) haben. Über die Zusammenführung zu einer Managed Property kann nun einheitlich über alle verfügbaren Quellen nach dem Nachnamen gesucht werden.[85] Die aufgezeigte Behandlung von Metadaten erfüllt eindeutig das Kriterium „Enterprise Bookmarking“.
4.2.4 Protocol Handler
Für den Zugriff auf diverse, unterschiedliche Inhaltsquellen werden Protocol Handler benötigt. Als Beispiel für verschiedene Quellen seien SharePoint, Dateisysteme, Webserver oder Lotus Notes genannt. Die Aufgaben der zugehörigen Protocol Handler umfassen dabei zunächst das Verbinden, die Authentifizierung und das Herunterladen des Inhalts im Bezug auf die jeweilige Inhaltsquelle. Des Weiteren ist er auch für das Extrahieren von Metadaten, die nicht im Inhalt selbst proprietär untergebracht sind und für das Abrufen von Sicherheits- und Zugriffsinformationen und dem Zuordnen dieser zugehörigen Windows Zugriffskonten zuständig. Auch die Anzahl der Einzelinhalte pro Quelle, die indiziert werden, werden vom Protocol Handler ermittelt. Einerseits durch Ermitteln von Aufzählungslisten, die z.B. alle Dateien eines Ordners oder alle URLs einer Website enthalten, andererseits wird beim Abrufen zwischen allen oder nur inkrementellen Informationen unterschieden. Für den letztgenannten Punkt ist von Bedeutung, dass SharePoint beim Abrufen von SharePoint Seiten und Inhalt nicht auf den HTTP Handler sondern auf seinen eigenen STS/SPS Handler zurückgreift, der diese Informationen ohne Untersuchung des Einzelinhalts bietet.[86] Bei Bedarf können eigene Protocol Handler über eine seit SharePoint 2001 existierende Windows C++ API entwickelt werden.[87]
4.2.5 IFilter
IFilter dienen dem Zerlegen des einzelnen Inhaltselements, insbesondere bei einem proprietärem Format. Als veranschaulichendes Beispiel kann hier Microsoft Word angeführt werden. Beim Öffnen eines Word Dokuments mit einem einfachen Texteditor wie bspw. Notepad, ist der korrekte Text nicht erkennbar. Abhilfe für den Indexprozess schafft hier der korrekte IFilter für das entsprechende Dateiformat.[88] In SharePoint gibt es im Standardumfang IFilter u.a. für plain text, Word, Excel, Powerpoint, Html, XML, E-Mail und Zip. IFilter dienen nicht speziell SharePoint, sondern stellen eine generelle Microsoft Technologie dar, die auch von Drittanbietern unterstützt wird. So gibt es für das allgemein verwendete PDF Format von diversen Anbietern IFilter. Bei Bedarf können eigene IFilter über eine gut dokumentierte Windows C++ API entwickelt werden.[89]
4.2.6 Kriterienerfüllung
| Enterprise Bookmarking | X |
|---|
Tabelle 2: Kriterienerfüllung des Indexers
Zur Erläuterung: X = Kriterium voll erfüllt, (X) = Kriterium teilweise erfüllt, o = Kriterium nicht erfüllt oder offen (ungeklärt)
4.3 User Interface
4.3.1 Zugriffsarten
4.3.1.1 Web Oberfläche
Der übliche Zugriff auf die Suche ist der über die Web Oberfläche. Dabei gibt der Benutzer eine Anfrage in ein Suchfeld eines Steuerelementes ein und sendet diese an den Abfrageserver. Der Server führt die Anfrage aus und sendet das Ergebnis im XML Format zurück. Im Anhang sind hierzu zwei Beispiele aufgeführt. Dieses Ergebnis im XML Format wird nun von dem Ergebnis Webpart mithilfe von Extensible Style Language Transformation (XSLT) in HTML gerendert und angezeigt.[90] Die Suchabfrage kann dabei aus einer bloßen Angabe einer oder mehrerer Begriffe bestehen, die Treffer erzeugen sobald einer der Begriffe vorkommt. Darüber hinaus gibt es folgende Möglichkeiten:
- Suche nach der kompletten Phrase durch Einschließen in Anführungszeichen
- Und Verknüpfung der Begriffe durch Angabe des + Zeichens
- Suche auf Nichtvorkommen des zweiten Begriffs durch Angabe des – Zeichens
- Suche nach einem Text/Begriff nur innerhalb einer Managed Property durch Angabe der Property, gefolgt von einem Doppelpunkt und dem Text/Begriff
- Wildcard Suche innerhalb einer Managed Property durch Angabe der Property, gefolgt von einem Doppelpunkt und dem Textteil plus einem *
Die Verwendung dieser einschränkenden Syntax kann eine erhebliche Auswirkung auf die Relevanz der Ergebnisse haben.[91] Dies ist ein Aspekt für die Erfüllung des Kriteriums "Recall und Precision".
4.3.1.2 API
Über eine API kann ebenfalls auf die Suche zugegriffen werden. Dabei gibt es zwei Arten, die vom Ort des Zugriffs abhängen: Applikationen auf einem SharePoint Server selbst greifen über das Objekt Modell zu, während solche, die von remote des Servers zugreifen nur die ebenfalls angebotenen Webservices verwenden können.[92] Die Verwendung der API wird im weiteren Verlauf anhand des Fallbeispiels erläutert. Durch ihr Vorhandensein ist aber das gleichnamige Kriterium erfüllt.
Ein Aspekt, wo API und Web Interface zusammen wirken, ist bei ergänzenden Lösungen für Microsoft SharePoint. Diese können Open Source oder auch kommerziell sein. Ein Beispiel ist die Open Source Lösung Faceted Search, die auf der CodePlex Plattform heruntergeladen werden kann. Das Thema Faceted Search, welches bereits im Kriterienteil erläutert wurde, wird von SharePoint von Haus aus nicht unterstützt, die freie Programmierbarkeit aber macht dies dennoch möglich. Bei der genannten Lösung werden neben dem üblichen Suchergebnis kategorisierende Metadaten incl. Zahlen über deren resultierendes Teilergebnis angezeigt, so dass der Benutzer mittels flexiblem Drilldown sein Suchergebnis nach seinen Bedürfnissen weiter einschränken kann.[93] Somit werden "Taxonomien" auch automatisch behandelt.
4.3.2 Search Scopes
Wie bereits im Abschnitt allgemeine Arbeitsweise aufgezeigt, gibt es nur einen Index pro SSP. Und da SSP und somit Indexübergreifend nicht gesucht werden kann, wird auch meist nur ein SSP eingesetzt, es sei denn, dass die bewusste Trennung bei Mandantensystemen o.ä. erwünscht ist.[94] Um bei einem großen allumspannenden Index aber die Zahl der Suchtreffer auf ein relevantes Maß zu reduzieren, existieren Search Scopes. Sie können manuell auf zwei Ebenen angelegt werden. Search Scopes können bei der Suche ausgewählt werden und dann gibt der Query Server nur Ergebnisse zurück, die innerhalb des Search Scopes liegen. Ein einzelner Inhalt kann überlappend mehreren Scopes zugeordnet sein. Ein Search Scope besteht aus dem Scope selbst und zugehörigen Rules, die festlegen, welche Inhalte zu dem Scope gehören. Kriterien nach denen gewählt werden kann, sind die Web Address, wobei der genannte URL Teil dann im Ergebnis enthalten sein muss. Als zweites kann nach den bereits erwähnten Managed Properties gesucht werden. Der dritte Punkt ist die Inhaltsquelle. Zuletzt kann auch der gesamte Inhalt einbezogen werden. Mehrere Rules können in Kombination gestellt werden. Dies geht über das Verhalten der Rule. Include bedeutet praktisch eine Oder-Kombination, d.h. alles was der Rule nach zutrifft wird in den Scope mit einbezogen. Require dagegen steht für eine Und-Verknüpfung, denn hier muss sämtlicher Inhalt auf diese Rule passen. Inhalt der nur eine Rule erfüllt, wird somit nicht dem Scope zugeordnet. Exclude wiederum schließt den Inhalt aus, der diese Rule erfüllt. Hier wird auch der Sinn von All Content deutlich, kann doch eine Rule, die All Content berücksichtigt mit spezifischen Exclude Rules kombiniert werden, was dann sinngemäß "alles außer" bedeutet. Welcher Inhalt zu welchem Scope gehört wird aus Gründen der Performanz weder beim Indizieren noch bei der Suchabfrage festgelegt. Dies geschieht separat durch einen eigenen Job auf den Abfrageservern. Dieser kenzeichnet im vorhandenen Index, welches Element zu welchem Scope gehört. So wird weder der ressourcenintensive Indexprozess noch der zeitkritische Abfrageprozess belastet.[95] Dennoch sollten Scopes entfernt werden, die selten bis nie für Abfragen genutzt werden, um Ressourcen zu sparen und den Benutzern keine überflüssigen Auswahlmöglichkeiten bereitzustellen. Dies kann in den Query Reports ermittelt werden.[96] Auch dies ist ein Aspekt für die Erfüllung des Kriteriums "Recall und Precision".
4.3.3 Freshness
Neben dem Anzeigen des richtigen Inhalts, also der Relevanz, ist auch die Aktualität der Suchergebnisse von entscheidender Bedeutung für den Erfolg und die Akzeptanz einer Suchmaschine. Microsoft SharePoint trägt diesem Kriterium auf verschiedene Weise Rechnung. Basis für Aktualität ist die Häufigkeit der Indizierungsvorgänge. Hier existiert das Dilemma, dass häufiges Indizieren gut für die sogenannte Freshness und schlecht für die Ressourcenbelastung ist.[97] Wie bereits dargelegt, trägt inkrementelle Indizierung zur Schonung der Ressourcen bei. Dies verstärkt sich noch, je häufiger indiziert wird, da in kürzeren Zyklen weniger Inhalt geändert werden kann.[98] Des Weiteren können die Inhaltsquellen nicht nur nach den verschiedenen zu durchsuchenden Systemen getrennt werden, sondern auch innerhalb solcher Systeme nach Inhalt, der sich häufig und Inhalt der sich weniger häufig ändert. Da pro Inhaltsquelle die Indizierungszeiträume festgelegt werden, kann so relativ statischer Inhalt vom häufigen Indizieren ausgenommen werden und spart so Ressourcen ohne die Freshness zu beeinträchtigen. Umgekehrt bleiben mehr Zeit und Ressourcen für die sich häufig ändernden Inhalte. Inkrementelle Crawls sollten also relativ dicht aufeinanderfolgend ausgeführt werden. Dabei ist jedoch darauf zu achten, dass die Laufzeit des Einzelnen nicht größer wird als der Zeitabstand zwischen zwei Vorgängen, so dass sich die Crawls quasi selbst überholen.[99] Bei inkrementellen Crawls kommt schließlich die sogenannte Continuous propagation zum Tragen. Das bedeutet, dass beim inkrementellen Crawl direkt in den bestehenden Index geschrieben wird, während beim Full Crawl der Index ersetzt wird. So ist schon während des inkrementellen Vorgangs neu indizierter Inhalt für Suchabfragen verfügbar. Beim Full Crawl dauert es dagegen bis zum Abschluss des Vorgangs.[100] [101]
4.3.4 Thesaurus
Entgegen der Gepflogenheit in guten wissenschaftlichen Arbeiten eine klare Begriffsbestimmung und –verwendung zu praktizieren, kommt es doch vor, dass in Texten für den gleichen Begriff diverse Synonyme verwendet werden. Auch im Umfeld von Enterprise Search ist dies sicher häufig der Fall. Microsoft SharePoint hat dafür das Konzept der Thesaurus Dateien bereitgestellt. In diesen XML Dateien, die pro Sprache und in einer neutralen Version existieren, können auf zwei Arten Synonyme gepflegt werden. Zum einen können sogenannte Expansion Sets angelegt werden, zum anderen sogenannte Replacement Sets. Beim Expansion Set wird nach allen aufgeführten Synonymen additiv gesucht, wenn eins der Synonyme in der Suchabfrage angegeben war. Beim standardmäßigen Inhalt der XML Dateien wird also immer sowohl nach Internet Explorer als auch nach IE oder IE5 gesucht, egal welcher der drei Begriffe eingegeben wurde. Beim Replacement Set werden Synonyme auf zwei Arten definiert: Die einen sollen ersetzt werden mithilfe eines Ersatzbegriffs. Beim standardmäßigen Inhalt sagt das Beispiel aus, dass, egal ob NT5, W2K oder Windows 2000 vom Benutzer in die Suchabfrage eingegeben wird, letztlich nur nach Windows 2000 gesucht wird. Tabelle 3 zeigt die erwähnten Standardinhalte.[102]
| Expansion Set | Replacement Set |
|---|---|
<expansion>
</expansion> | <replacement>
</replacement> |
Tabelle 3: Standardinhalt einer Thesaurus Datei
Replacement Sets sind sinnvoll, wenn in den Query Reports festgestellt wird, dass viele Benutzer beim Suchen Begriffe falsch schreiben und somit keine Suchergebnisse bekommen. Ein Thesaurus gilt immer pro SSP, also pro Index und ist case insensitive, Groß- und Kleinschreibung werden also nicht beachtet.[103] Somit dient auch dies der Erfüllung des Kriteriums "Recall und Precision".
4.3.5 Kriterienerfüllung
| Recall und Precision | X |
|---|---|
| Taxonomien | (X) |
| API | X |
Tabelle 4: Kriterienerfüllung der User Interfaces
4.4 Datenquellen
4.4.1 File-, Mail- und Webserver
Im Shared Service Provider können diverse Inhaltsquellen angelegt werden. Zum einen können damit Inhaltsquellen in unterschiedlichen Zeitabständen indiziert werden, zum anderen können so die verschiedenen Inhalte, wie SharePoint Sites oder fremde Inhalte, wie andere Websites, Dateisysteme, E-Mail Systeme oder der Business Data Catalog indiziert werden.[104] Für den Zugriff auf die einzelnen Inhalte sind die schon beschriebenen Protocol Handler verantwortlich. Fremde Websites werden unter Angabe der Start-URL indiziert. Je nach Einstellung kann es bei dieser Seite bleiben, oder es werden alle URLs, die als Links auf dieser (und den weiteren Seiten) gefunden werden indiziert. Dies kann auf den ursprünglichen Server beschränkt bleiben oder darüber hinaus ausgedehnt werden. Ein Security Trimming ist nicht möglich.[105]
Auch Dateisysteme können indiziert werden. Dabei ist der Pfad Universal Naming Convention (UNC) konform anzugeben. Unterordner können wahlweise mit indiziert werden. Zugriffskontrolllisten können beim New Technology File System (NTFS) Dateisystem für das Security Trimming verwendet werden.[106]
Des Weiteren zählen die gängigen Mailsysteme in Unternehmen zu den Inhaltsquellen, die mehr oder weniger vorbereitet indiziert werden können. Für Microsoft Exchange reicht, Zugriff vorausgesetzt, die Angabe der Outlook Web Access URL. Es ist auch hier möglich mit oder ohne Unterordner zu indizieren.[107] Auch ein inkrementelles Indizieren ist zügig möglich.[108] Möglich macht dies ein eigens für Exchange vorhandener Protocol Handler.[109] Für die Indizierung des zweiten in Unternehmen sehr verbreiteten Mailsystems Lotus Notes, ist hingegen die Nachinstallation des Lotus Notes Clients und eines speziellen Toolkits erforderlich. Darüber hinaus ist zum Zugriff und zur Einrichtung des Kontenabgleichs zwischen Notes und Windows Benutzerkonten ein Wizard auszuführen. Somit wird dann aber auch Security Trimming möglich.[110]
Schon diese Zahl an verschiedenen Quellen reicht aus, das Kriterium „Unterschiedliche Datenquellen“ zu erfüllen, aber auch die folgenden Abschnitte unterstützen die Erfüllung noch.
4.4.2 Business Data Catalog
Klassische Line Of Business (LOB) Systeme enthalten in einem Unternehmen meist die wertvollsten und äußerst kritischen Daten. Gleichzeitig sind diese Daten auch von hoher Bedeutung für das Treffen von Entscheidungen. Diese Tatsache bedingt häufig auch noch den Faktor Schnelligkeit um im Wettbewerb bestehen zu können. Die modernen Entscheidungsträger sind häufig parallel mit unstrukturierten aber entscheidungsrelevanten Informationen konfrontiert und die häufig noch klassischen Hostapplikationen der LOB Systeme nicht mehr gewohnt. Deshalb ist ein sicherheitsrelevanter Zugriff auf diese Daten aus anderen Systemen und in Kombination mit unstrukturierten Inhalten notwendig und die Motivation für die Implementierung des Business Data Catalog (BDC) gewesen. Dabei wird mithilfe der ActiveX Data Objects (ADO) .Net Technik auf klassische relationale Datenbanken, wie Oracle oder Microsoft SQL Server zugegriffen. Auch ein Verwenden bestehender Webservices ist möglich.[111] Es kann hier eindeutig von der Erfüllung des „Hidden web“ Kriteriums gesprochen werden, da diese LOB Daten erst durch nachfolgend beschriebene Technik verfügbar gemacht werden.
Für den Zugriff wird ein sogenanntes Application Definition File (ADF) benötigt, dessen Inhalt in der Extensible Markup Language (XML) die Datenbank beschreibt. Für die Generierung dieser Datei gibt es diverse grafische Tools.[112] Die wichtigen Bestandteile dieser Datei werden im weiteren Verlauf anhand eines praktischen Beispiels beschrieben.
Vorhandene BDC Applikationen können analog der o.g. als weitere Inhaltsquelle zum Indizieren konfiguriert werden. Dabei ist sowohl die Auswahl des kompletten Katalogs als auch einzelner Applikationen möglich.[113] Beim Indizieren wird zunächst eine Liste aller Primärschlüssel über den sogenannten IDEnumerator abgerufen und anschließend zu jedem Schlüssel in dieser Liste der Satz abgerufen. Wird der IDEnumerator so konfiguriert, dass er auch ein Datum der letzten Änderung zurückliefert, ist auch ein inkrementelles Indizieren möglich.[114] Die Spalten der Datenbanktabellen werden, wie bereits bei den Metadaten beschrieben, den Crawled Properties unter der Kategorie BDC hinzugefügt und können (gepaart mit anderen Properties aus der gleichen oder anderen Kategorien) zu Managed Properties zusammengefasst und bei der Suche verwendet werden.[115]
Da durch den BDC Daten durchsuchbar gemacht werden, die sonst nicht direkt dem Intranet zur Verfügung stünden, erfüllt der BDC eindeutig das Kriterium „Hidden Web Durchsuchbarkeit“.
4.4.3 Federated Search
Mit Einführung des Microsoft Search Server 2008 unterstützt Microsoft auch das Weiterleiten von Suchanfragen. Dies wird Federated Search oder Federation genannt. In SharePoint ist diese Technik ab dem Infrastrukturupdate aus 2008 verfügbar. Es werden dabei Federated Locations eingerichtet, an welche die Suchanfragen weitergeleitet werden. Diese müssen den OpenSearch Standard unterstützen. Ist das nicht der Fall, wird ein Federated Search Connector benötigt, der praktisch als Mittler zwischen SharePoint als Anfragesystem und die Federated Location geschaltet wird. Solche Connectoren werden für viele bekannte Systeme bereits von Drittanbietern geliefert, können aber auch selbst geschrieben werden. Ziel ist es, dass die Federated Location Ihre Ergebnisse in XML nach dem RSS oder ATOM Format zurückliefert. Typische Beispiel bei denen Federated Search Verwendung findet, sind selbstindizierende Systeme, wie bspw. ein externes Content Management System oder auch externe Suchanbieter. Die Suchergebnisse sind jedoch nicht mit den SharePoint eigenen mischbar.[116] Zunächst muss eine Federated Location eingerichtet werden. Zentraler Parameter neben anderen ist dabei das Query Template. Dies ist ein parametrisierter Suchstring, der die jeweiligen Anfrageparameter aufnimmt und dann weiterleitet.[117] Dies ist vergleichbar mit der Einrichtung weiterer Suchanbieter im Internet Explorer ab Version 7. Problematisch ist bei der Federated Search das Security Trimming. Dies muss bereits bei der Federated Location geschehen, die dann bereits getrimmte Resultate zurückliefert.[118] Da das von einem System aber auch erwartet werden sollte, da es anderenfalls selbst ein Sicherheitsproblem hätte, erfüllt SharePoint das Kriterium „Federated Search“ eindeutig.
4.4.4 People Search
Neben dem Auffinden von Informationen ist es häufig von großer Bedeutung die richtigen Personen innerhalb des Unternehmens zu finden. SharePoint bietet hier das Konzept der Benutzerprofile an, die aus verschiedenen schon im Unternehmen vorhandenen Quellen importiert werden können. Dies kann ein Microsoft Active Directory, ein anderes Lightweight Directory Access Protocol (LDAP) Verzeichnis oder ein über BDC angebundenes Human Ressource System sein. Es ist auch möglich Daten aus den verschiedenen Systemen zusammen zu führen, wenn einzelne Informationen in dem einen und weitere in einem anderen System vorhanden sind.[119] Dies ist möglich indem zu einer Master Connection, die typischerweise zum eigenen Active Directory oder LDAP eingerichtet ist, eine zusätzliche Verbindung z.B. zu einem HR System über BDC eingerichtet wird um zusätzliche Benutzereigenschaften zu importieren.[120] Die Eigenschaften eines Benutzers können nun mit den Importquellen verknüpft werden oder aber auch erst im SharePoint gepflegt werden. Welche Eigenschaften dies sind, spielt praktisch keine Rolle, da sowohl vorhandene verwendet als auch neue angelegt werden können. Für jede Eigenschaft kann entweder allgemein, oder auf einen speziellen Benutzer bezogen, festgelegt werden, wer darauf zugreifen darf, so dass bspw. eine private Telefonnummer nur von den eigenen Kollegen eingesehen werden darf.[121] Des Weiteren ist es möglich zur Pflege der Werte und deren Freigabe auch die eigenen Benutzer zuzulassen, so dass eine Art „Self Service“ entsteht.[122] Dies adressiert eindeutig das Kriterium "Personalisierung", da jeder seien Eigenschaften zielgerichtet pflegen und freigeben kann. Des Weiteren wird hier auch das Kriterium "Expertenwissen nutzen" exakt abgedeckt, da bereits im Standard Benutzerprofil ein Feld Skills enthalten ist. So können die Benutzer hier ihre Kompetenzen pflegen (oder dies geschieht durch eine zentrale Instanz) und darüber gefunden werden. Ebenso wird dies Kriterium durch die Relevanz bei der Suche nach Personen adressiert. Gesucht werden können die Personen nach sämtlichen festgelegten und für den Suchanfragenden einsehbaren Kriterien, sofern dies eingerichtet wurde. Die Reihenfolge der angezeigten Personentreffer richtet sich nun wahlweise u.a. nach der sog. Social Distance. Jede Person hat die Möglichkeit andere als Kollegen hinzuzufügen. So entsteht ein soziales Netzwerk, wie es von XING her bekannt ist. Die Personentreffer werden nun nach dem Grad der Kontakte sortiert angezeigt.[123]
4.4.5 Kriterienerfüllung
| "Hidden web" Durchsuchbarkeit | X |
|---|---|
| Unterschiedliche Datenquellen | X |
| Personalisierung | X |
| Federated Search | X |
| Expertenwissen nutzen | X |
Tabelle 5: Kriterienerfüllung der Datenquellen
4.5 Personalisierung
4.5.1 Grundlegende Funktionalität
Wie bereits erwähnt, ist es in Intranet Systemen wichtig, Inhalt vor unerlaubtem Zugriff zu schützen. Das Problem bei Enterprise Search ist, dass zunächst einmal jeglicher Inhalt indiziert werden muss. Dazu ist ein Zugriffskonto erforderlich, das sämtlichen Inhalt abrufen kann. Bei der Suchabfrage wiederum soll den Zugriffsrechten des abfragenden Benutzers ent- bzw. widersprochen werden. Diese Technik wird als Security Trimming bezeichnet und im Folgenden detaillierter erläutert.[124] Ein weiterer Sicherheitsaspekt kann es sein, einzelnen, sensiblen Inhalt von der Indizierung auszuschließen.[125] Dies ist möglich durch Erstellen einer Crawl Rule, die den einzelnen Inhalt ausschließt.[126] Ist der Inhalt bereits indiziert kann er auch sofort aus dem Index entfernt werden über den Punkt Search Result Removal, ohne den nächsten Indizierungsvorgang abwarten oder anstoßen zu müssen.[127]
4.5.2 Security Trimming
4.5.2.1 Built In
Beim Indizieren des Inhalts, wie SharePoint Seiten, Dateisystemen, Exchange Ordner oder Lotus Notes wird pro Element abgefragt, wer darauf zugreifen darf und dies dann innerhalb der SSP Search Datenbank gespeichert. Bei einer Suchabfrage wird zunächst sämtlicher Inhalt, der auf die Abfrage passt, zurückgeliefert. Bevor er aber dem anfragenden Benutzer angezeigt wird, läuft das Security Trimming darüber und entfernt alle Elemente zu denen der Anfragende keinen Zugriff hat. Kein Security Trimming gibt es bei gewöhnlichem Webinhalt, da dieser im Normalfall keine Access Control Lists (ACLs) zurückgibt. Auch die an anderer Stelle näher erläuterten Best Bets unterliegen keinem Security Trimming. Suchtreffer, auf die der anfragende Benutzer keinen Zugriff hat, werden ihm also gar nicht erst vorgeschlagen. Dies gilt allerdings für den Zeitpunkt der Indizierung des Inhalts, nicht für den der Anfrage. Wird also nur in größeren Zyklen indiziert, kann die ACL für den Suchtreffer bereits veraltet sein. Dies wird im Abschnitt Freshness wieder aufgegriffen.[128]
4.5.2.2 Custom Trimmer
Wo der built in Trimming Mechanismus nicht funktioniert oder nicht ausreichend ist, kann durch das Implementieren eines .Net Interfaces, also programmatisch und nicht administrativ, ein benutzerdefinierter Trimming Mechanismus angewandt werden. Dieser Mechanismus besteht aus zwei Methoden. Einer Initialize Methode, die einmalig beim Laden des Prozesses ausgeführt wird und für Konfigurationszwecke dienen kann und der CheckAccess Methode. Letztere sollte den Algorithmus enthalten, der auf jedes Element des Suchergebnisses angewandt wird. Der Methode wird das Suchergebnis als Array in Form einer sogenannten ICollectionList übergeben und sie sollte ein BitArray in der gleichen Anzahl zurückliefern, welches aussagt ob auf das einzelne Element zugegriffen (1) werden darf oder nicht (0).[129]
4.5.2.3 BDC
Da der BDC auf fremde Datenquellen zugreift, stellt sich die Frage der Authentifizierung und wie diese bei dem Zugriff auf die Daten (direkt oder per Suchanfrage) durch einen Benutzer behandelt wird. Zunächst gibt es zwei grundlegende Arten, wie der BDC die Authentifizierung durchführt: Subsystem Mode und Delegation Mode. Beim Subsystem Mode wird für den Zugriff auf das LOB System ein festes Konto genutzt, in dem der BDC läuft. Beim Delegation Mode hingegen wird das Benutzerkonto, das die Anfrage stellt, verwendet. Dies kann wieder auf zwei Arten geschehen, zum einen durch ein Durchreichen des Benutzerkontos (Pass-through), zum anderen über ein Wechsel zum Konto des Webserver Application Pools (RevertToSelf). Kritisch ist hierbei das sogenannte Double-hop Problem. Dabei geht es darum, dass das Benutzerkonto zweimal durchgereicht wird, einmal vom Client zum Server und dann vom Server zum LOB System. Dies ist nur unter der Verwendung von Kerberos möglich.[130] Kerberos ist ein Authentifizierungsmechanismus, der im Gegensatz zu anderen, wie bspw. dem NT LAN Manager (NTLM) Protokoll, ein automatisches Weiterreichen der Anmeldeinformationen uneingeschränkt unterstützt.[131]
In Verbindung mit dem Impersonation Mode ist auch die Verwendung von Single Sign On (SSO) möglich. Dabei wird dem SharePoint Benutzerkonto in einem Secure Credential Store ein weiteres Benutzerkonto für das LOB System zugeordnet und bei Bedarf verwendet.[132] Unabhängig vom Konto, welches für den Zugriff auf das LOB System verwendet wird, kann im BDC selbst Sharepoint Benutzern die Verwendung des BDC, seiner Applikation oder der darin enthaltenen Entitäten gewährt werden.[133] Unterhalb der Entität, also auf Ebene des Datensatzes, kann ein Security Trimming über das Einfügen einer Methode in der ADF Datei erreicht werden. Diese Methode muss vom Typ AccessChecker sein und prüft über Structured Query Language (SQL) ob ein Zugriff auf den entsprechenden Satz möglich ist oder nicht.[134]
Auch wenn es bei gewissen Datenquellen komplexer wird: Dadurch, dass SharePoint dieses zweifellos komplexe Thema auf breiter Front adressiert, ist das Kriterium "Extensives Rechtesystem" erfüllt.
4.5.3 Search Alerts
Neben den Sicherheitsmechanismen gehören auch die Search Alerts in den Bereich der Personalisierung. Zunächst ist es möglich, sofern im SSP eingestellt, dass Benutzer sich zu Suchanfragen zyklisch eine E-Mail schicken lassen, wenn sich die Suchergebnisse seit der Anfrage oder dem letzten Alert geändert haben. Täglich oder Wöchentlich stehen als Zyklen zur Verfügung. Da dies je nach Zahl der Benutzer zu einer Belastung für die Abfrageserver werden kann, ist ein ad hoc Mechanismus nicht möglich.[135] Entgegen der Mail Alerts, wo die Arbeit beim Server liegt (push based), funktionieren Really Simple Syndication (RSS) Feeds durch Anfragen des Benutzers. Abonniert der Benutzer einen solchen RSS Feed, geht die Initiative von Ihm aus (pull based), wann er den Aufruf startet. Er erhält dann das Suchergebnis in einem RSS Stream, den er mit entsprechenden Clients verarbeiten kann.[136] Dies ist ein weiterer Aspekt für das Kriterium "Personalisierung".
4.5.4 Kriterienerfüllung
| Extensives Rechtesystem | X |
|---|---|
| Personalisierung | X |
Tabelle 6: Kriterienerfüllung der Personalisierung
4.6 Ergebnisrelevanz
4.6.1 Standardrelevanz
Die Relevanz der Suchergebnisse ist der wohl bedeutsamste Erfolgsfaktor einer Suchmaschine. Dabei muss die Relevanz zunächst vom sogenannten Ranking abgegrenzt werden. Ranking und die beeinflussenden Parameter bestimmen die Reihenfolge in der die Suchergebnisse angezeigt werden. Ob sie für die Anfrage relevant sind, ist damit nicht gesagt. So kann die Relevanz der Suchergebnisse, wie im Folgenden aufgezeigt wird, sowohl ohne als auch mit Beeinflussung des Ranking Algorithmus verbessert werden. Bei den Ranking Parametern wiederum wird unterschieden zwischen statischen und dynamischen Parametern. Statische sind unabhängig von der Suchabfrage, während dynamische in Abhängigkeit der Suchabfrage stehen. Zu den statischen Parametern zählen bei SharePoint die Klickdistanz, die URL Tiefe und das sogenannte File Type Biasing. Zu den dynamischen Parametern zählen die bereits erwähnten Properties, die Keywords oder das URL matching. Bei der URL Tiefe geht es um die hierarchische Tiefe der URL, die an der Anzahl der / bemessen wird.[137] Die anderen Punkte werden im weiteren Verlauf näher erläutert, da sie angepasst werden können.
4.6.2 Anpassung
4.6.2.1 Beeinflussung Algorithmus
Ein Ranking Parameter ist die sogenannte Klickdistanz. Der Algorithmus prüft dabei die Anzahl an Klicks über die URL Links, die notwendig sind um von einer festgelegten Seite zum jeweiligen Zielinhalt zu gelangen. Die festgelegten Seiten teilen sich dabei auf in 3 verschiedene (most, second-level, third-level) sogenannte Authoritative Pages und eine Nonauthoritative Page. Bei den drei erstgenannten steigt das Ranking, je kürzer die Distanz ist und je höher die Stufe der Authoritative Page. Bei den Nonauthoritative Pages sinkt umgekehrt das Ranking, je geringer die Klickdistanz. Durch Hinzufügen gewünschter URLs zu einer dieser vier Listen wird signifikanter Einfluss auf den Ranking Algorithmus ausgeübt, da so ganze Bereiche des zu durchsuchenden Inhalts für relevant oder nicht relevant erklärt werden.[138]
Relevanter als das Auftauchen eines Suchbegriffs in Freitext ist, wenn der Suchbegriff in einer der bereits erläuterten Managed Properties auftaucht. So haben die drei im Standard enthaltenen Managed Properties Author, Title und Filename bereits vordefiniert eine hohe Gewichtung. Für eigene Managed Properties kann die Gewichtung bei Bedarf programmatisch angepasst werden. Die sogenannte Length Normalization hilft neben der Gewichtung der Property einzelne Properties mit kurzem Textinhalt solchen mit größerem Textinhalt gleichzustellen oder gar zu überholen. Normalerweise werden Elemente die den Suchbegriff in einer Text Property aufgrund deren Länge mehrfach enthalten, höher gewichtet. Dies kann über die Length Normalization korrigiert werden.[139]
4.6.2.2 Ohne Beeinflussung Algorithmus
4.6.2.2.1 Beste Suchtreffer
Durch den Einsatz von Metadaten kann die Qualität der Suche optimiert werden. Durch das Anlegen von Keywords und zugehörigen Synonymen kann ein Effekt erzielt werden, wie er bei Internetsuchmaschinen als AdWords oder Sponsored Links bekannt ist. Man gibt dabei ein Keyword, ggf. Synonyme und ein oder zwei Ziele an und im Falle einer Suche nach dem Keyword oder den Synonymen wird die Zielseite als erstes in der Ergebnisliste angezeigt.[140] Zu der Zielseite wird auch eine Beschreibung, die gepflegt wurde, angezeigt. Realisiert wird dies durch ein eigenes, oberhalb der Suchergebnisse angeordnetes Webpart, das im Falle von keinen Ergebnissen nicht angezeigt wird. Diese manuellen Eingriffe können bei sorgfältiger und regelmäßiger Pflege eine große Bedeutung für die Benutzer und somit für die Ergebnisrelevanz haben.[141]
Ähnlich wie Beste Suchtreffer funktionieren die High Confidence Results. Das trifft auf Inhalt zu, wo die Suchabfrage auf eine als High Confidence eingestufte Managed Property passt. Die Anzahl der Suchergebnisse kann im Webpart, das die High Confidence Treffer anzeigt und baugleich mit dem Best Bets Webpart ist, angepasst werden. Dieser Wert sollte sehr niedrig gewählt werden, um ausschließlich als höchst relevant geltende Ergebnisse anzuzeigen. Da alles über diese angepasste Zahl unterdrückt wird, machen bei der Wahl der als High Confidence einzustufenden Managed Properties nur solche Sinn, die ein wesentliches Alleinstellungsmerkmal beinhalten.[142]
Wenn der oder die Suchbegriffe in der URL selbst oder im Seitentitel enthalten sind, landet diese Seite ganz oben in der Ergebnisliste im High Confidence Webpart. Somit kann bei der bewussten Titelauswahl und Dateinamensgebung der Seite das Ranking wieder signifikant beeinflusst werden.[143]
Hier wird das Kriterium "Enterprise Bookmarking" in einer verfeinerten Form erneut erfüllt. Auch das Kriterium "Recall und Precision", welches im gesamten Abschnitt Relevanz eine Rolle spielt, wird hier ganz explizit adressiert. Mit besten Suchtreffern kann z.B. ein Dokument zur Passwortänderung in eine exklusive Ergebnisposition gebracht werden.
4.6.2.2.2 Report Auswertung
Die Suchabfragen und –ergebnisse können in SharePoint protokolliert werden. Die Auswertung dieser Protokolle kann helfen, die Suchergebnisse künftig zu verbessern. So können die Top Abfragen der letzten 30 Tage ein Indiz dafür sein, dass bestimmte Inhalte überhaupt nur gesucht werden, weil sie schlecht verlinkt sind. Des Weiteren können Search Scopes identifiziert werden, die selten bis nie für die Einschränkung von Suchabfragen verwendet werden. Sie verschwenden Ressourcen und hindern den Benutzer daran, die für ihn wichtigen und Relevanz erzeugenden Scopes auszuwählen.[144] Für die erwähnten Varianten der besten Suchtreffer sind die Abfragen mit niedriger Klickrate und die Abfragen mit null Best Bets bedeutsam. Abfragen deren Suchergebnisse nicht angeklickt werden, sollten mit Keywords oder Best Bets versehen werden, ebenso Abfragen die keine Best Bets produzieren. Auch die Anwendung des Thesaurus hilft hier weiter. Dies wertet das Suchergebnis auf und wird vom Benutzer als relevanter wahrgenommen.[145]
4.6.3 Kriterienerfüllung
| Recall und Precision | X |
|---|---|
| Enterprise Bookmarking | X |
Tabelle 7: Kriterienerfüllung der Relevanz
5 Fallbeispiel Artikelsuche
5.1 Szenario
In dem folgenden Fallbeispiel sollen einige der analysierten Funktionen anhand eines realitätsnahen praktischen Beispiels demonstriert werden. Ausgehend vom Geschäftsobjekt Artikel existieren logische Verbindungen zu Bestellungen in einem relationalen Datenbanksystem. Im vorliegenden Fall ist dies ein Microsoft SQL Server. Als nächstes werden Rechnungen zu bestellten Artikeln in einem Dokumentenmanagementsystem angenommen, hier realisiert über eine Microsoft SharePoint Dokumentenbibliothek. Die dritte Datenquelle sind lose Dokumente des Einkaufs, wie Produktbeschreibungen, Angebote oder ähnliches. Der Einkauf legt diese im Dateisystem seines Servers ab. Schließlich soll noch der Verantwortliche des Artikelsortiments, das im Beispiel der Warengruppe entspricht, über die Personensuche gefunden werden.
5.2 Suche nach Artikelstammdaten und Bestellungen über BDC
Als erstes müssen die Datentabellen und ihre Datenbank mit einer ADF Datei beschrieben werden. Dazu wird der BDC Definition Editor aus dem SharePoint SDK verwendet. Damit wird zunächst über einen Connection String eine Verbindung zur Datenbank in SQL Server hergestellt. Schließlich werden grafisch die Tabellen ausgewählt und Primär- und Fremdschlüssel angehakt. Anschließend kann eine XML exportiert werden, welche die ADF Datei darstellt. Diese wird nun über den Shared Service Provider in SharePoint importiert. Dann existiert eine Application mit Entities, die die ausgewählten Tabellen darstellen. Die ADF Datei findet sich im Anhang, das Datenmodell ist in Abbildung 3 ersichtlich.
Jede Entity hat durch den Import bereits eine Profilseite erhalten in der unter Angabe des Primärschlüssels alle Datenfelder angezeigt werden. Für den Artikelstamm soll diese angepasst werden. Die Seite wird, nachdem sie aufgerufen wurde, in den Edit Mode versetzt und es wird das BDC List Webpart hinzugefügt. Dieses zeigt alle Bestellungen an, die den Artikel, der als Parameter übergeben wurde, enthält. Dazu wird in der Webpart Konfiguration die Entität Bestellposition mit der aus dem Fremdschlüssel Artikelnummer generierten Methode ausgewählt. Den Parameter Artikelnummer, die diese Methode benötigt, erhält man durch die Verbindung zum bereits vorhandenen Webpart zur Anzeige des Artikelstamms. Nun werden bei jedem Aufrufen der Artikelprofilseite auch die Bestellungen mit angezeigt. Diese werden nun indiziert. Dazu wird in der Suchadministration eine neue Inhaltsquelle vom Typ BDC angelegt und die entsprechende Applikation ausgewählt. Wie schon beschrieben, holt sich der Indexprozess nun über eine Methode alle Primärschlüssel, also z.B. alle vorhandenen Artikelnummern, ruft mit diesen die zugehörige Profilseite auf und indiziert sie. Letztlich wird noch eine Managed Property benötigt um vernünftig nach einer Artikelnummer suchen zu können. Diese wird ebenfalls angelegt und ihr die Artikelnummern des Stamms und der Bestellpositionen zugeordnet. Somit kann nach einem erneuten Full Crawl nach „Artikelnummer:4711“ gesucht werden und es wird das Stammprofil sowie alle Bestellpositionen gefunden.
5.3 Suche nach Rechnungen aus Dokumentenbibliothek
Rechnungen können digital als PDF eingehen oder aus der Papierform in PDF Form gescannt werden. SharePoint bietet mit seinen Dokumentbibliotheken einen sicheren Ablageort für diese Dokumente. Diese können auch indiziert werden, nachdem ein IFilter für das PDF Format installiert wurde. Um Rechnungen zielgerichtet zu durchsuchen und nicht gleichzeitig fremde Treffer zu erhalten, wird ein Search Scope unter Verwendung der URL zu der oder den Dokumentenbibliotheken, die die Rechnungen enthalten, eingerichtet. Nun kann bei der Suche der Scope „Rechnungen“ ausgewählt werden und die Suchtreffer beschränken sich auf die Rechnungen.
5.4 Suche nach Angeboten und Beschreibungen von Fileserver
Dokumente, die nicht in einer Dokumentenbibliothek abgelegt werden sollen, können auch in einem Dateisystem indiziert werden. Dazu ist zu beachten, dass entweder der Default Content Access Account im Dateisystem Rechte zum Lesen hat, oder dass mittels einer Crawl Rule ein spezieller Account gewählt wird, der über die nötigen Rechte verfügt. Des Weiteren wird wieder eine Inhaltsquelle angelegt, diesmal vom Typ File Share. Als Parameter wird der UNC Pfad benötigt und ob auch Unterordner indiziert werden sollen. Für die Dateitypen gilt wieder, dass der jeweilige IFilter installiert sein muss. Mehr wird nicht benötigt. Auch auf diese Inhaltsquelle kann wieder ein spezieller Scope definiert werden um nur diese Quelle explizit durchsuchen zu können.
5.5 Suche nach dem Sortimentsverantwortlichen über die Warengruppe (WG)
Um den Verantwortlichen für das Sortiment, zu dem der Artikel gehört, zu finden, kann eine Personensuche mit Optionen durchgeführt werden. Alle Attribute, die eingerichtet und gepflegt wurden, können auch gezielt durchsucht werden, sofern sie im Suchcenter dafür ausgewählt wurden. Im Fallbeispiel wird das standardmäßig vorhandene Attribut „Department“ verwendet, das dem Sortimentsnamen (entspricht im Fallbeispiel der WG) gleichgesetzt wurde.
5.6 Suche zusammengefügt in einer Applikation mit API Verwendung
Um alle einzelnen Informationen bezogen auf einen Artikel auf einen Blick zu erhalten, können die einzelnen Suchabfragen unter Verwendung der API in einem einzigen Webpart zusammengefasst werden. Dazu werden zunächst ein Eingabefeld für die entsprechende Artikelnummer und ein Button zum Ausführen der Suchabfragen benötigt. Der komplette Programmcode für dieses Webpart befindet sich im Anhang.
Das Anzeigen der zusätzlichen Stammdaten könnte auch über die Search API realisiert werden, in der Praxis macht aber das direkte Aufrufen der vorhandenen Specific Finder Methode des BDC mehr Sinn. Da der Fokus hier auf der Search API liegt, wird diese Funktion nicht näher erläutert.
Um bei der Erläuterung der API Methoden deduktiv vorzugehen, wird entgegen der obigen logischen Abschnittsreihenfolge zunächst die Suche für die Rechnungen und die Dokumente des Einkaufs aus dem Dateisystem implementiert. Dazu werden im EventHandler des Ausführbuttons zwei ähnliche Methoden benötigt, die ein FulltextSQLQuery instanzieren und ausführen. Die Query Syntax ist dabei sehr ähnlich einer SQL Abfrage. Nach der Ausführung werden die Ergebnisse in Form eines Resultsets, ähnlich einer Datenbankabfrage, zurückgeliefert. Die drei der Einfachheit halber abgefragten Werte werden nun in Listenform untereinander dargestellt. Dabei wird aus Titel und Pfad ein Hyperlink gebildet, unter dem dann eine Kurzzusammenfassung des Dokumenteninhalts angezeigt wird. Das ist praktisch gleich der Anzeige in einer gewöhnlichen Suchergebnisseite von SharePoint oder auch Google etc.
//Query vorbereiten und ausführen
FullTextSqlQuery ftq = new FullTextSqlQuery(ServerContext.Current);
//Artikelnummer in Suchstring einbauen
ftq.QueryText = String.Format("SELECT title, hithighlightedsummary, path FROM Scope() WHERE CONTAINS ('\"{0}\"') AND ((\"scope\"='Rechnungen')) ORDER BY \"Rank\" DESC", txtArtikel.Text);
ftq.ResultTypes = ResultType.RelevantResults | ResultType.HighConfidenceResults;
ResultTableCollection rtc = ftq.Execute();
ResultTable rt = rtc[ResultType.RelevantResults];
//Result in Datatable ablegen
DataTable dt = new DataTable();
dt.Load(rt, LoadOption.OverwriteChanges);
//Resultset durchlaufen
for (int i = 0; i < dt.Rows.Count;i++ )
{
DataRow dr = dt.Rows[i];
//Link zusammenbauen aus Pfad und Titel
string strLink = String.Format("<A HREF=\"{0}\">{1}</A><br>", dr["path"], dr["title"]);
mainTable.Rows[2].Cells[0].Controls.Add(new LiteralControl(strLink));
//Zusammenfassung als Text darunter
string strSummary = dr["hithighlightedsummary"] + "<p>";
mainTable.Rows[2].Cells[0].Controls.Add(new LiteralControl(strSummary));
}
Ähnlich verhält es sich auch mit der Personensuche. Hier muss der Scope „People“ verwendet und nach dem Attribut „Department“ gesucht werden. Der zu suchende Wert geht aus dem Datensatz des Artikels und dem dortigen Attribut ARTWG hervor. Die abgefragten Attribute werden wieder teilweise HTML formatiert. So wird auf den Vor- und Nachnamen der Link zur Seite des Personenprofils gelegt und auch die E-Mailadresse wird klickbar gemacht. Die vorhandene URL des Fotos wird gleich als Bild angezeigt.
FullTextSqlQuery ftq = new FullTextSqlQuery(ServerContext.Current);
strDepartment = lblArtikelwg.Text;
//Artikel-WG in Suchstring einbauen
ftq.QueryText = String.Format("SELECT FirstName, LastName, WorkPhone, WorkEmail, PictureURL, Path FROM Scope() WHERE \"scope\"='People' AND ((Department='{0}'))", strDepartment);
ftq.ResultTypes = ResultType.RelevantResults | ResultType.HighConfidenceResults;
ResultTableCollection rtc = ftq.Execute();
ResultTable rt = rtc[ResultType.RelevantResults];
if (rt.RowCount > 0)
{
//Result in Datatable ablegen
DataTable dt = new DataTable();
dt.Load(rt, LoadOption.OverwriteChanges);
DataRow dr = dt.Rows[0];
//Foto anzeigen
string strImage = String.Format("<IMG src=\"{0}\"><br>", dr["PictureURL"]);
mainTable.Rows[0].Cells[1].Controls.Add(new LiteralControl(strImage));
//Name klickbar zur Personenseite
string strName = dr["FirstName"] + " " + dr["LastName"] + "<br>";
string strLink = String.Format("<A HREF=\"{0}\">{1}</A><br>", dr["path"], strName);
mainTable.Rows[0].Cells[1].Controls.Add(new LiteralControl(strLink));
string strPhone = dr["WorkPhone"] + "<br>";
mainTable.Rows[0].Cells[1].Controls.Add(new LiteralControl(strPhone));
string strEmail = String.Format("<a href=\"mailto:{0}\">{0}</a><br>", dr["WorkEmail"]);
mainTable.Rows[0].Cells[1].Controls.Add(new LiteralControl(strEmail));
}
Letztlich sollen auch noch Bestellpositionen angezeigt werden. Um die angelegte Managed Property bei der Suche zu verwenden, muss hier ein KeywordQuery anstelle des FulltextSQLQuery instanziert werden. Als QueryText wird keine SQL ähnliche Syntax, sondern lediglich die Managed Property gefolgt von einem : und der Artikelnummer übergeben. Das Resultset wird analog den Rechnungen oder Einkaufsdokumenten bearbeitet.
//Hier KeywordQuery verwenden, ansonsten analog Rechnungs und Dokumentensuche
KeywordQuery kwq = new KeywordQuery(ServerContext.Current);
kwq.QueryText = String.Format("Artikelnummer:{0}", txtArtikel.Text);
kwq.ResultTypes = ResultType.RelevantResults | ResultType.HighConfidenceResults;
ResultTableCollection rtc = kwq.Execute();
ResultTable rt = rtc[ResultType.RelevantResults];
6 Fazit und Ausblick
Microsoft SharePoint erfüllt die aufgestellten Bewertungskriterien zum größten Teil, insbesondere die Kriterien mit hoher Relevanz. Lediglich bei der Erstellung automatischer Taxonomien und bei der Information Extraction konnten Schwachpunkte aufgezeigt oder die Erfüllung nicht ermittelt werden. Dies zeigt nochmal Tabelle 8.
| Kriterium | Relevanz | Erfüllung |
|---|---|---|
| "Hidden Web" Durchsuchbarkeit | hoch | X |
| Extensives Rechtesystem | hoch | X |
| Unterschiedliche Datenquellen | hoch | X |
| Recall und Precision | hoch | X |
| Taxonomien | hoch | (X) |
| Personalisierung | hoch | X |
| Federated Search | normal | X |
| API | normal | X |
| Information Extraction | normal | o |
| Expertenwissen nutzen | normal | X |
| Enterprise Bookmarking | normal | X |
Tabelle 8: Kriterienerfüllung Gesamtübersicht
Darüber hinaus konnten viele nützliche Funktionen analysiert werden. Besonders hervorzuheben sind die Search Alerts mit denen es möglich ist, sich geänderte Abfragemengen via RSS Feed zu abonnieren. Es ist dadurch unnötig eigenständig und wiederholend Suchabfragen formulieren zu müssen auf Informationen die für den Mitarbeiter von Belang sind. Eine weitere Stärke ist, dass das "Hidden Web" mit Hilfe des BDC durchsucht werden kann. Die neben dem "Hidden Web" ebenfalls unterstützten unterschiedlichen Content Formate werden durch IFilter implementiert. Hier erscheint als durchdacht, dass auch für SharePoint unbekannte Formate mittels C++ API indizierbar gemacht werden können.
Der großen Skalierbarkeit von Microsoft SharePoint allgemein steht das Limit des einen Indexservers mit 50 Millionen Einträgen gegenüber. Dies sollte allerdings nur in sehr großen Umgebungen, die nicht getrennt sondern aggregiert behandelt werden müssen, zu einem Propblem führen. Nur hier ist dann ein High End System vonnöten. Es kann also durchaus von einer leistungsfähigen Enterprise Searchengine gesprochen werden. Dies wurde auch bereits Ende 2006 in einer Pentasys Studie belegt. Hier gewann SharePoint insgesamt den Vergleich dreier Portale gegenüber seinen Wettbewerbern SAP NetWeaver und IBM Websphere Portal. Die Suchtechnologie Microsofts wurde mit gut bewertet gegenüber sehr gut der Mitbewerber.[146] Allerdings stand da, wie dargelegt, noch keine Federation und weitere Verbesserungen zur Verfügung. Auch stellt SharePoint keine High End Enterprise Searchengine dar. Dazu stehen Systeme wie Autonomy oder FAST am Markt zur Verfügung. Es wird interessant sein, wie die Übernahme von FAST durch Microsoft und die daraus resultierende Einbindung der FAST Technologie in SharePoint 2010, das derzeit als öffentliche Betaversion verfügbar ist, die SharePoint Plattform weiter aufwertet. Ersten Ankündigungen zufolge ist u.a. mit folgenden signifikanten Neuerungen zu rechnen:[147]
- Meta Data Extraction: Das Herauslösen von Metadaten aus ansonsten unstrukturierten Texten wird durch FAST übernommen, so wie vom Kriterium "Information Extraction" gefordert
- Faceted Search: Die direkte Verarbeitung von Metadaten im Suchergebnis zur weiteren Unterteilung inclusive der präzisen Anzahl der Ergebnisse bei jeder Größe der Trefferliste
- Dokumentenvorschau: Vorschau auf Dokumente, z.B. über Thumbnails im Resultset
- Persönliche Relevanz: Anpassung der Relevanz auf Benutzer- oder Gruppenbasis
- Hohe Skalierbarkeit: Über 100 Millionen Dokumente in einem Suchindex
Diese Ankündigungen würden die wenigen, hier in der Version 2007 aufgezeigten, Schwächen beheben. Natürlich muss dies in der letztlich ausgelieferten Version in 2010 verifiziert werden.
7 Abkürzungsverzeichnis
| Abkürzung | Bedeutung |
|---|---|
| ACL | Access Control List |
| ADF | Application Definition File |
| ADO | ActiveX Data Objects |
| BDC | Business Data Catalog |
| FAST | Fast Technology and Transfer |
| HTML | Hyper Text Markup Language |
| LOB | Line of Business |
| NTLM | NT LAN Manager |
| NTFS | New Technology File System |
| RSS | Really Simple Syndication |
| SEO | Search Engine Optimization |
| SQL | Structured Query Language |
| SSO | Single Sign On |
| SSP | Shared Service Provider |
| UNC | Universal Naming Convention |
| WFE | Web Frontend Server |
| WWW | World Wide Web |
| XML | Extensible Markup Language |
| XSLT | Extensble Style Language Transformation |
8 Abbildungsverzeichnis
| Abb.-Nr. | Abbildung |
|---|---|
| 1 | SharePoint Serverfarm Konfigurationen |
| 2 | Indexserver indiziert sich selbst |
| 3 | ERM Modell Artikelbeispiel |
9 Tabellenverzeichnis
| Tabelle-Nr. | Quelle |
|---|---|
| 1 | Kriterienübersicht |
| 2 | Kriterienerfüllung des Indexers |
| 3 | Standardinhalt einer Thesaurus Datei |
| 4 | Kriterienerfüllung der User Interfaces |
| 5 | Kriterienerfüllung Datenquellen |
| 6 | Kriterienerfüllung der Personalisierung |
| 7 | Kriterienerfüllung der Relevanz |
| 8 | Kriterienerfüllung Gesamtübersicht |
10 Anhang
XML Result
<ResponsePacket xmlns="urn:Microsoft.Search.Response">
<Response>
<Range>
<StartAt>1</StartAt>
<Count>10</Count>
<TotalAvailable>117</TotalAvailable>
<Results>
<Document xmlns="urn:Microsoft.Search.Response.Document">
<Action>
<LinkUrl fileExt="pdf">http://depsgtst01/finanzen/Rechnungen/Rechnung1998931.pdf</LinkUrl>
</Action>
<Properties xmlns="urn:Microsoft.Search.Response.Document.Document">
<Property>
<Name>TITLE</Name>
<Type>String</Type>
<Value>Rechnung1998931.pdf</Value>
</Property>
<Property>
<Name>HITHIGHLIGHTEDSUMMARY</Name>
<Type>String</Type>
<Value><ddd/> 103026/70kHz/<c0>0</c0>,27LM/TCO03 <c0>0</c0> 23,72 <c0>0</c0> 501487 Mon CRT 17' Belinea 103051/97kHz/<c0>0</c0>,25LM/TCO03 43 23,72 1 <ddd/></Value>
</Property>
<Property>
<Name>PATH</Name>
<Type>String</Type>
<Value>http://depsgtst01/finanzen/Rechnungen/Rechnung1998931.pdf</Value>
</Property>
<Property>
<Name>RANK</Name>
<Type>Int64</Type>
<Value>5</Value>
</Property>
<Property>
<Name>SIZE</Name>
<Type>Int64</Type>
<Value>61028</Value>
</Property>
</Properties>
</Document>
...
...
</Results>
</Range>
<Status>SUCCESS</Status>
</Response>
</ResponsePacket>
XML Result People Search
<ResponsePacket xmlns="urn:Microsoft.Search.Response">
<Response>
<Range>
<StartAt>1</StartAt>
<Count>1</Count>
<TotalAvailable>1</TotalAvailable>
<Results>
<Document xmlns="urn:Microsoft.Search.Response.Document">
<Action>
<LinkUrl fileExt="aspx">http://depsgtst01:12345/Person.aspx?guid=1063E805-5F20-42AE-82B5-FB27E88F4DF1</LinkUrl>
</Action>
<Properties xmlns="urn:Microsoft.Search.Response.Document.Document">
<Property>
<Name>FIRSTNAME</Name>
<Type>String</Type>
<Value>Martin</Value>
</Property>
<Property>
<Name>LASTNAME</Name>
<Type>String</Type>
<Value>Schroeder</Value>
</Property>
<Property>
<Name>WORKPHONE</Name>
<Type>String</Type>
<Value>040 / 12 34 567</Value>
</Property>
<Property>
<Name>WORKEMAIL</Name>
<Type>String</Type>
<Value>schroeder@fomputerhandel.de</Value>
</Property>
<Property>
<Name>PICTUREURL</Name>
<Type>String</Type>
<Value>http://depsgtst01/PublishingImages/martin.jpg</Value>
</Property>
<Property>
<Name>SKILLS</Name>
<Type>Object</Type>
<Value>Peripherie Blondinen Wasserbetten</Value>
</Property>
<Property>
<Name>PATH</Name>
<Type>String</Type>
<Value>http://depsgtst01:12345/Person.aspx?guid=1063E805-5F20-42AE-82B5-FB27E88F4DF1</Value>
</Property>
</Properties>
</Document>
</Results>
</Range>
<Status>SUCCESS</Status>
</Response>
</ResponsePacket>
ADF Datei Artikelbeispiel
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<LobSystem xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://schemas.microsoft.com/office/2006/03/BusinessDataCatalog BDCMetadata.xsd" Type="Database" Version="1.0.0.0" Name="FOM_Erp" xmlns="http://schemas.microsoft.com/office/2006/03/BusinessDataCatalog">
<LobSystemInstances>
<LobSystemInstance Name="FOM_Erp_Instance">
<Properties>
<Property Name="rdbconnection Data Source" Type="System.String">DEPSGTST01\OFFICESERVERS</Property>
<Property Name="rdbconnection Initial Catalog" Type="System.String">FOM_Erp</Property>
<Property Name="rdbconnection Integrated Security" Type="System.String">True</Property>
<Property Name="DatabaseAccessProvider" Type="Microsoft.Office.Server.ApplicationRegistry.SystemSpecific.Db.DbAccessProvider">SqlServer</Property>
<Property Name="AuthenticationMode" Type="Microsoft.Office.Server.ApplicationRegistry.SystemSpecific.Db.DbAuthenticationMode">PassThrough</Property>
</Properties>
</LobSystemInstance>
</LobSystemInstances>
<Entities>
<Entity EstimatedInstanceCount="10000" Name="ARTIKELSTAMM">
<Identifiers>
<Identifier TypeName="System.Decimal" Name="ARTNR" />
</Identifiers>
<Methods>
<Method Name="Find_ARTIKELSTAMM">
<Properties>
<Property Name="RdbCommandType" Type="System.Data.CommandType, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">Text</Property>
<Property Name="RdbCommandText" Type="System.String">Select "ARTNR","ARTBEZ","ARTWG","ARTLIE" from ARTIKELSTAMM where ARTNR=@ARTNR</Property>
</Properties>
<Parameters>
<Parameter Direction="In" Name="@ARTNR">
<TypeDescriptor TypeName="System.Decimal, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" IdentifierName="ARTNR" Name="ARTNR" />
</Parameter>
<Parameter Direction="Return" Name="@ARTIKELSTAMM">
<TypeDescriptor TypeName="System.Data.IDataReader, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" IsCollection="true" Name="Reader">
<TypeDescriptors>
<TypeDescriptor TypeName="System.Data.IDataRecord, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Name="Record">
<TypeDescriptors>
<TypeDescriptor TypeName="System.Decimal, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" IdentifierName="ARTNR" Name="ARTNR" />
<TypeDescriptor TypeName="System.String, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Name="ARTBEZ" />
<TypeDescriptor TypeName="System.String, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Name="ARTWG" />
<TypeDescriptor TypeName="System.Decimal, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Name="ARTLIE" />
</TypeDescriptors>
</TypeDescriptor>
</TypeDescriptors>
</TypeDescriptor>
</Parameter>
</Parameters>
<MethodInstances>
<MethodInstance Type="SpecificFinder" ReturnParameterName="@ARTIKELSTAMM" ReturnTypeDescriptorName="Reader" ReturnTypeDescriptorLevel="0" Name="Find_ARTIKELSTAMM_Instance" />
</MethodInstances>
</Method>
<Method Name="FindAll_ARTIKELSTAMM">
<Properties>
<Property Name="RdbCommandType" Type="System.Data.CommandType, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">Text</Property>
<Property Name="RdbCommandText" Type="System.String">Select "ARTNR" from ARTIKELSTAMM</Property>
</Properties>
<Parameters>
<Parameter Direction="Return" Name="@ARTIKELSTAMM">
<TypeDescriptor TypeName="System.Data.IDataReader, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" IsCollection="true" Name="Reader">
<TypeDescriptors>
<TypeDescriptor TypeName="System.Data.IDataRecord, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Name="Record">
<TypeDescriptors>
<TypeDescriptor TypeName="System.Decimal, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" IdentifierName="ARTNR" Name="ARTNR" />
</TypeDescriptors>
</TypeDescriptor>
</TypeDescriptors>
</TypeDescriptor>
</Parameter>
</Parameters>
<MethodInstances>
<MethodInstance Type="IdEnumerator" ReturnParameterName="@ARTIKELSTAMM" ReturnTypeDescriptorName="Reader" ReturnTypeDescriptorLevel="0" Name="FindAll_ARTIKELSTAMM_Instance" />
</MethodInstances>
</Method>
</Methods>
</Entity>
<Entity EstimatedInstanceCount="10000" Name="BESTELLKOEPFE">
<Identifiers>
<Identifier TypeName="System.Decimal" Name="BKNR" />
</Identifiers>
<Methods>
<Method Name="Find_BESTELLKOEPFE">
<Properties>
<Property Name="RdbCommandType" Type="System.Data.CommandType, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">Text</Property>
<Property Name="RdbCommandText" Type="System.String">Select "BKNR","BKLIE","BKDAT" from BESTELLKOEPFE where BKNR=@BKNR</Property>
</Properties>
<Parameters>
<Parameter Direction="In" Name="@BKNR">
<TypeDescriptor TypeName="System.Decimal, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" IdentifierName="BKNR" Name="BKNR" />
</Parameter>
<Parameter Direction="Return" Name="@BESTELLKOEPFE">
<TypeDescriptor TypeName="System.Data.IDataReader, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" IsCollection="true" Name="Reader">
<TypeDescriptors>
<TypeDescriptor TypeName="System.Data.IDataRecord, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Name="Record">
<TypeDescriptors>
<TypeDescriptor TypeName="System.Decimal, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" IdentifierName="BKNR" Name="BKNR" />
<TypeDescriptor TypeName="System.Decimal, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Name="BKLIE" />
<TypeDescriptor TypeName="System.DateTime, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Name="BKDAT" />
</TypeDescriptors>
</TypeDescriptor>
</TypeDescriptors>
</TypeDescriptor>
</Parameter>
</Parameters>
<MethodInstances>
<MethodInstance Type="SpecificFinder" ReturnParameterName="@BESTELLKOEPFE" ReturnTypeDescriptorName="Reader" ReturnTypeDescriptorLevel="0" Name="Find_BESTELLKOEPFE_Instance" />
</MethodInstances>
</Method>
<Method Name="FindAll_BESTELLKOEPFE">
<Properties>
<Property Name="RdbCommandType" Type="System.Data.CommandType, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">Text</Property>
<Property Name="RdbCommandText" Type="System.String">Select "BKNR" from BESTELLKOEPFE</Property>
</Properties>
<Parameters>
<Parameter Direction="Return" Name="@BESTELLKOEPFE">
<TypeDescriptor TypeName="System.Data.IDataReader, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" IsCollection="true" Name="Reader">
<TypeDescriptors>
<TypeDescriptor TypeName="System.Data.IDataRecord, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Name="Record">
<TypeDescriptors>
<TypeDescriptor TypeName="System.Decimal, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" IdentifierName="BKNR" Name="BKNR" />
</TypeDescriptors>
</TypeDescriptor>
</TypeDescriptors>
</TypeDescriptor>
</Parameter>
</Parameters>
<MethodInstances>
<MethodInstance Type="IdEnumerator" ReturnParameterName="@BESTELLKOEPFE" ReturnTypeDescriptorName="Reader" ReturnTypeDescriptorLevel="0" Name="FindAll_BESTELLKOEPFE_Instance" />
</MethodInstances>
</Method>
</Methods>
</Entity>
<Entity EstimatedInstanceCount="10000" Name="BESTELLPOSITIONEN">
<Identifiers>
<Identifier TypeName="System.Decimal" Name="BKNR" />
<Identifier TypeName="System.Decimal" Name="BPNR" />
</Identifiers>
<Methods>
<Method Name="Find_BESTELLPOSITIONEN">
<Properties>
<Property Name="RdbCommandType" Type="System.Data.CommandType, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">Text</Property>
<Property Name="RdbCommandText" Type="System.String">Select "BKNR","BPNR","BPART","BPMENGE","BPPRS" from BESTELLPOSITIONEN where BKNR=@BKNR and BPNR=@BPNR</Property>
</Properties>
<Parameters>
<Parameter Direction="In" Name="@BKNR">
<TypeDescriptor TypeName="System.Decimal, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" IdentifierName="BKNR" Name="BKNR" />
</Parameter>
<Parameter Direction="In" Name="@BPNR">
<TypeDescriptor TypeName="System.Decimal, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" IdentifierName="BPNR" Name="BPNR" />
</Parameter>
<Parameter Direction="Return" Name="@BESTELLPOSITIONEN">
<TypeDescriptor TypeName="System.Data.IDataReader, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" IsCollection="true" Name="Reader">
<TypeDescriptors>
<TypeDescriptor TypeName="System.Data.IDataRecord, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Name="Record">
<TypeDescriptors>
<TypeDescriptor TypeName="System.Decimal, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" IdentifierName="BKNR" Name="BKNR" />
<TypeDescriptor TypeName="System.Decimal, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" IdentifierName="BPNR" Name="BPNR" />
<TypeDescriptor TypeName="System.Decimal, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Name="BPART" />
<TypeDescriptor TypeName="System.Decimal, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Name="BPMENGE" />
<TypeDescriptor TypeName="System.Decimal, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Name="BPPRS" />
</TypeDescriptors>
</TypeDescriptor>
</TypeDescriptors>
</TypeDescriptor>
</Parameter>
</Parameters>
<MethodInstances>
<MethodInstance Type="SpecificFinder" ReturnParameterName="@BESTELLPOSITIONEN" ReturnTypeDescriptorName="Reader" ReturnTypeDescriptorLevel="0" Name="Find_BESTELLPOSITIONEN_Instance" />
</MethodInstances>
</Method>
<Method Name="FindAll_BESTELLPOSITIONEN">
<Properties>
<Property Name="RdbCommandType" Type="System.Data.CommandType, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">Text</Property>
<Property Name="RdbCommandText" Type="System.String">Select "BKNR","BPNR" from BESTELLPOSITIONEN</Property>
</Properties>
<Parameters>
<Parameter Direction="Return" Name="@BESTELLPOSITIONEN">
<TypeDescriptor TypeName="System.Data.IDataReader, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" IsCollection="true" Name="Reader">
<TypeDescriptors>
<TypeDescriptor TypeName="System.Data.IDataRecord, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Name="Record">
<TypeDescriptors>
<TypeDescriptor TypeName="System.Decimal, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" IdentifierName="BKNR" Name="BKNR" />
<TypeDescriptor TypeName="System.Decimal, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" IdentifierName="BPNR" Name="BPNR" />
</TypeDescriptors>
</TypeDescriptor>
</TypeDescriptors>
</TypeDescriptor>
</Parameter>
</Parameters>
<MethodInstances>
<MethodInstance Type="IdEnumerator" ReturnParameterName="@BESTELLPOSITIONEN" ReturnTypeDescriptorName="Reader" ReturnTypeDescriptorLevel="0" Name="FindAll_BESTELLPOSITIONEN_Instance" />
</MethodInstances>
</Method>
<Method Name="FK_BESTELLPOSITIONEN_ARTIKELSTAMM">
<Properties>
<Property Name="RdbCommandType" Type="System.Data.CommandType, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">Text</Property>
<Property Name="RdbCommandText" Type="System.String">Select "BKNR","BPNR","BPART","BPMENGE","BPPRS" from BESTELLPOSITIONEN where BPART=@ARTNR_ARTIKELSTAMM</Property>
</Properties>
<Parameters>
<Parameter Direction="In" Name="@ARTNR_ARTIKELSTAMM">
<TypeDescriptor TypeName="System.Decimal, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" IdentifierEntityName="ARTIKELSTAMM" IdentifierName="ARTNR" Name="BPART" />
</Parameter>
<Parameter Direction="Return" Name="@BESTELLPOSITIONEN">
<TypeDescriptor TypeName="System.Data.IDataReader, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" IsCollection="true" Name="Reader">
<TypeDescriptors>
<TypeDescriptor TypeName="System.Data.IDataRecord, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Name="Record">
<TypeDescriptors>
<TypeDescriptor TypeName="System.Decimal, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" IdentifierName="BKNR" Name="BKNR" />
<TypeDescriptor TypeName="System.Decimal, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" IdentifierName="BPNR" Name="BPNR" />
<TypeDescriptor TypeName="System.Decimal, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Name="BPART" />
<TypeDescriptor TypeName="System.Decimal, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Name="BPMENGE" />
<TypeDescriptor TypeName="System.Decimal, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Name="BPPRS" />
</TypeDescriptors>
</TypeDescriptor>
</TypeDescriptors>
</TypeDescriptor>
</Parameter>
</Parameters>
</Method>
<Method Name="FK_BESTELLPOSITIONEN_BESTELLKOEPFE">
<Properties>
<Property Name="RdbCommandType" Type="System.Data.CommandType, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">Text</Property>
<Property Name="RdbCommandText" Type="System.String">Select "BKNR","BPNR","BPART","BPMENGE","BPPRS" from BESTELLPOSITIONEN where BKNR=@BKNR_BESTELLKOEPFE</Property>
</Properties>
<Parameters>
<Parameter Direction="In" Name="@BKNR_BESTELLKOEPFE">
<TypeDescriptor TypeName="System.Decimal, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" IdentifierEntityName="BESTELLKOEPFE" IdentifierName="BKNR" Name="BKNR" />
</Parameter>
<Parameter Direction="Return" Name="@BESTELLPOSITIONEN">
<TypeDescriptor TypeName="System.Data.IDataReader, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" IsCollection="true" Name="Reader">
<TypeDescriptors>
<TypeDescriptor TypeName="System.Data.IDataRecord, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Name="Record">
<TypeDescriptors>
<TypeDescriptor TypeName="System.Decimal, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" IdentifierName="BKNR" Name="BKNR" />
<TypeDescriptor TypeName="System.Decimal, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" IdentifierName="BPNR" Name="BPNR" />
<TypeDescriptor TypeName="System.Decimal, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Name="BPART" />
<TypeDescriptor TypeName="System.Decimal, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Name="BPMENGE" />
<TypeDescriptor TypeName="System.Decimal, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Name="BPPRS" />
</TypeDescriptors>
</TypeDescriptor>
</TypeDescriptors>
</TypeDescriptor>
</Parameter>
</Parameters>
</Method>
</Methods>
</Entity>
</Entities>
<Associations>
<Association Name="FK_BESTELLPOSITIONEN_ARTIKELSTAMM_Instance" AssociationMethodEntityName="BESTELLPOSITIONEN" AssociationMethodName="FK_BESTELLPOSITIONEN_ARTIKELSTAMM" AssociationMethodReturnParameterName="@BESTELLPOSITIONEN" AssociationMethodReturnTypeDescriptorName="Reader" AssociationMethodReturnTypeDescriptorLevel="0" IsCached="true">
<SourceEntity Name="ARTIKELSTAMM" />
<DestinationEntity Name="BESTELLPOSITIONEN" />
</Association>
<Association Name="FK_BESTELLPOSITIONEN_BESTELLKOEPFE_Instance" AssociationMethodEntityName="BESTELLPOSITIONEN" AssociationMethodName="FK_BESTELLPOSITIONEN_BESTELLKOEPFE" AssociationMethodReturnParameterName="@BESTELLPOSITIONEN" AssociationMethodReturnTypeDescriptorName="Reader" AssociationMethodReturnTypeDescriptorLevel="0" IsCached="true">
<SourceEntity Name="BESTELLKOEPFE" />
<DestinationEntity Name="BESTELLPOSITIONEN" />
</Association>
</Associations>
</LobSystem>
Quellcode Webpart Verwendung Search API
using System;
using System.Data;
using System.Runtime.InteropServices;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Xml.Serialization;
using Microsoft.SharePoint;
using Microsoft.SharePoint.WebControls;
using Microsoft.SharePoint.WebPartPages;
using Microsoft.Office.Server;
using Microsoft.Office.Server.ApplicationRegistry.MetadataModel;
using Microsoft.Office.Server.ApplicationRegistry.Runtime;
using Microsoft.Office.Server.Search;
using Microsoft.Office.Server.Search.Query;
namespace Fom.Search
{
[Guid("f30bc29f-0b76-4e92-aa2e-591c3367d2f8")]
public class SearchInterface : System.Web.UI.WebControls.WebParts.WebPart
{
TextBox txtArtikel = new TextBox();
Label lblArtikelbez = new Label();
Label lblArtikellief = new Label();
Label lblArtikelwg = new Label();
Button btnSearch = new Button();
DataGrid gridRechnungen = new DataGrid();
DataGrid gridEinkauf = new DataGrid();
Table mainTable = new Table();
private string strDepartment = "";
public SearchInterface()
{
//Haupttabelle
for (int i = 0; i < 5; i++)
{
mainTable.Rows.Add(new TableRow());
mainTable.Rows[i].Cells.Add(new TableCell());
mainTable.Rows[i].Cells.Add(new TableCell());
}
}
protected override void CreateChildControls()
{
base.CreateChildControls();
// Eingabe GUI
btnSearch.Text = "Suche ausführen";
btnSearch.Click += new EventHandler(btnSearch_Click);
Table inputTable = new Table();
for (int i = 0; i < 4; i++)
{
inputTable.Rows.Add(new TableRow());
inputTable.Rows[i].Cells.Add(new TableCell());
inputTable.Rows[i].Cells.Add(new TableCell());
inputTable.Rows[i].Cells.Add(new TableCell());
}
inputTable.Rows[0].Cells[0].Controls.Add(new LiteralControl("Artikelnummer: "));
inputTable.Rows[0].Cells[1].Controls.Add(txtArtikel);
inputTable.Rows[0].Cells[2].Controls.Add(btnSearch);
inputTable.Rows[1].Cells[0].Controls.Add(new LiteralControl("Bezeichnung"));
inputTable.Rows[2].Cells[0].Controls.Add(new LiteralControl("Lieferant"));
inputTable.Rows[3].Cells[0].Controls.Add(new LiteralControl("Sortiment"));
inputTable.Rows[1].Cells[1].Controls.Add(lblArtikelbez);
inputTable.Rows[2].Cells[1].Controls.Add(lblArtikellief);
inputTable.Rows[3].Cells[1].Controls.Add(lblArtikelwg);
mainTable.Rows[0].Cells[0].Controls.Add(inputTable);
Controls.Add(mainTable);
}
void btnSearch_Click(object sender, EventArgs e)
{
showArtikeldaten();
searchRechnungen();
searchEinkauf();
searchPerson();
searchBestellungen();
}
void searchRechnungen()
{
mainTable.Rows[2].Cells[0].ColumnSpan = 2;
mainTable.Rows[2].Cells[0].Controls.Add(new LiteralControl("<b>Rechnungen</b><hr><br>"));
//Query vorbereiten und ausführen
FullTextSqlQuery ftq = new FullTextSqlQuery(ServerContext.Current);
//Artikelnummer in Suchstring einbauen
ftq.QueryText = String.Format("SELECT title, hithighlightedsummary, path FROM Scope() WHERE CONTAINS ('\"{0}\"') AND ((\"scope\"='Rechnungen')) ORDER BY \"Rank\" DESC", txtArtikel.Text);
ftq.ResultTypes = ResultType.RelevantResults | ResultType.HighConfidenceResults;
ResultTableCollection rtc = ftq.Execute();
ResultTable rt = rtc[ResultType.RelevantResults];
//Result in Datatable ablegen
DataTable dt = new DataTable();
dt.Load(rt, LoadOption.OverwriteChanges);
//Resultset durchlaufen
for (int i = 0; i < dt.Rows.Count;i++ )
{
DataRow dr = dt.Rows[i];
//Link zusammenbauen aus Pfad und Titel
string strLink = String.Format("<A HREF=\"{0}\">{1}</A><br>", dr["path"], dr["title"]);
mainTable.Rows[2].Cells[0].Controls.Add(new LiteralControl(strLink));
//Zusammenfassung als Text darunter
string strSummary = dr["hithighlightedsummary"] + "<p>";
mainTable.Rows[2].Cells[0].Controls.Add(new LiteralControl(strSummary));
}
}
void searchEinkauf()
{
FullTextSqlQuery ftq = new FullTextSqlQuery(ServerContext.Current);
ftq.QueryText = String.Format("SELECT title, hithighlightedsummary, path FROM Scope() WHERE CONTAINS ('\"{0}\"') AND ((\"scope\"='Einkauf')) ORDER BY \"Rank\" DESC", txtArtikel.Text);
ftq.ResultTypes = ResultType.RelevantResults | ResultType.HighConfidenceResults;
ResultTableCollection rtc = ftq.Execute();
ResultTable rt = rtc[ResultType.RelevantResults];
DataTable dt = new DataTable();
dt.Load(rt, LoadOption.OverwriteChanges);
mainTable.Rows[3].Cells[0].ColumnSpan = 2;
mainTable.Rows[3].Cells[0].Controls.Add(new LiteralControl("<b>Dokumente Einkauf</b><hr><br>"));
for (int i = 0; i < dt.Rows.Count; i++)
{
DataRow dr = dt.Rows[i];
string strLink = String.Format("<A HREF=\"{0}\">{1}</A><br>", dr["path"], dr["title"]);
mainTable.Rows[3].Cells[0].Controls.Add(new LiteralControl(strLink));
string strSummary = dr["hithighlightedsummary"] + "<p>";
mainTable.Rows[3].Cells[0].Controls.Add(new LiteralControl(strSummary));
}
}
void searchPerson()
{
mainTable.Rows[0].Cells[1].Controls.Add(new LiteralControl("<b>Sortimentsverantwortlicher</b><br>"));
if (lblArtikelwg.Text != "")
{
FullTextSqlQuery ftq = new FullTextSqlQuery(ServerContext.Current);
strDepartment = lblArtikelwg.Text;
//Artikel-WG in Suchstring einbauen
ftq.QueryText = String.Format("SELECT FirstName, LastName, WorkPhone, WorkEmail, PictureURL, Path FROM Scope() WHERE \"scope\"='People' AND ((Department='{0}'))", strDepartment);
ftq.ResultTypes = ResultType.RelevantResults | ResultType.HighConfidenceResults;
ResultTableCollection rtc = ftq.Execute();
ResultTable rt = rtc[ResultType.RelevantResults];
if (rt.RowCount > 0)
{
//Result in Datatable ablegen
DataTable dt = new DataTable();
dt.Load(rt, LoadOption.OverwriteChanges);
DataRow dr = dt.Rows[0];
//Foto anzeigen
string strImage = String.Format("<IMG src=\"{0}\"><br>", dr["PictureURL"]);
mainTable.Rows[0].Cells[1].Controls.Add(new LiteralControl(strImage));
//Name klickbar zur Personenseite
string strName = dr["FirstName"] + " " + dr["LastName"] + "<br>";
string strLink = String.Format("<A HREF=\"{0}\">{1}</A><br>", dr["path"], strName);
mainTable.Rows[0].Cells[1].Controls.Add(new LiteralControl(strLink));
string strPhone = dr["WorkPhone"] + "<br>";
mainTable.Rows[0].Cells[1].Controls.Add(new LiteralControl(strPhone));
string strEmail = String.Format("<a href=\"mailto:{0}\">{0}</a><br>", dr["WorkEmail"]);
mainTable.Rows[0].Cells[1].Controls.Add(new LiteralControl(strEmail));
}
}
}
void showArtikeldaten()
{
//Abfrage vorbereiten
LobSystemInstance LobInstance = ApplicationRegistry.GetLobSystemInstanceByName("FOM_Erp_Instance");
Entity LobEntity = LobInstance.GetEntities()["ARTIKELSTAMM"];
MethodInstance FindArtikel = LobEntity.GetMethodInstances()["Find_ARTIKELSTAMM_Instance"];
Object[] Parameters = FindArtikel.GetMethod().CreateDefaultParameterInstances(FindArtikel);
//Artikelnummer als Parameter übergeben
Parameters[0] = Convert.ToDecimal(txtArtikel.Text);
IEntityInstanceEnumerator EntityInstanceEnumerator = (IEntityInstanceEnumerator)LobEntity.Execute(FindArtikel, LobInstance, ref Parameters);
//Datensatz vorhanden?
if (EntityInstanceEnumerator.MoveNext())
{
//Result in Datatable ablegen
DataTable dt = EntityInstanceEnumerator.Current.EntityAsDataTable;
//Daten werden als Label angezeigt
lblArtikelbez.Text = dt.Rows[0]["ARTBEZ"].ToString();
lblArtikellief.Text = dt.Rows[0]["ARTLIE"].ToString();
lblArtikelwg.Text = dt.Rows[0]["ARTWG"].ToString().Trim();
}
}
void searchBestellungen()
{
//Hier KeywordQuery verwenden, ansonsten analog Rechnungs und Dokumentensuche
KeywordQuery kwq = new KeywordQuery(ServerContext.Current);
kwq.QueryText = String.Format("Artikelnummer:{0}", txtArtikel.Text);
kwq.ResultTypes = ResultType.RelevantResults | ResultType.HighConfidenceResults;
ResultTableCollection rtc = kwq.Execute();
ResultTable rt = rtc[ResultType.RelevantResults];
DataTable dt = new DataTable();
dt.Load(rt, LoadOption.OverwriteChanges);
mainTable.Rows[4].Cells[0].ColumnSpan = 2;
mainTable.Rows[4].Cells[0].Controls.Add(new LiteralControl("<b>Bestellpostionen</b><hr><br>"));
for (int i = 0; i < dt.Rows.Count; i++)
{
DataRow dr = dt.Rows[i];
string strLink = String.Format("<A HREF=\"{0}\">{1}</A><br>", dr["path"], dr["title"]);
mainTable.Rows[4].Cells[0].Controls.Add(new LiteralControl(strLink));
string strSummary = dr["hithighlightedsummary"] + "<p>";
mainTable.Rows[4].Cells[0].Controls.Add(new LiteralControl(strSummary));
}
}
}
}
11 Fußnoten
- ↑ Vgl. Stock (2006), S. 52.
- ↑ Vgl. Stock (2006), S. 51.
- ↑ Vgl. Stock (2006), S. 102.
- ↑ Vgl. Stock (2006), S. 141 f.
- ↑ Vgl. Stock (2006), S. 148.
- ↑ Vgl. Stock (2006), S 150.
- ↑ Vgl. Stock (2006), S. 185 f.
- ↑ Vgl. Stock (2006), S. 201 ff.
- ↑ Vgl. Stock (2006), S. 222 f.
- ↑ Vgl. Stock (2006), S 228 ff.
- ↑ Vgl. Stock (2006), S. 232 ff.
- ↑ Vgl. Stock (2006), S. 334 ff.
- ↑ Vgl. Stock (2006), S. 354 ff.
- ↑ Vgl. Croft et al. (2009), S. 3.
- ↑ Vgl. MindBusiness, HanseVision (2008), S. 73.
- ↑ Vgl. Rizzo et al. (2008), S. 25.
- ↑ Vgl. Rizzo et al. (2008), S. 19 f.
- ↑ Vgl. Rittgen (2007), S. 237 ff.
- ↑ Vgl. Masak (2005), S. 107 ff.
- ↑ Vgl. Croft et al. (2009), S. 8.
- ↑ Vgl. Thelwall (2000), S. 2.
- ↑ Vgl. Thelwall, Vaughan (2004), S. 8.
- ↑ Vgl. Croft et al. (2009), S. 37.
- ↑ Vgl. Croft et al. (2009), S. 39 f.
- ↑ Vgl. Keeton et al. (2009), S. 2.
- ↑ Vgl. Mao, Mukherjee (2004), S. 39 f.
- ↑ Vgl. Bennett (2009).
- ↑ Vgl. Gyöngyi, Garcia-Molina (2005), S. 2.
- ↑ Vgl. Loder et al. (2004), S. 1 f.
- ↑ Vgl. Khong (2001), S. 6 f.
- ↑ Vgl. Henzinger et al. (2003), S. 1573 ff.
- ↑ Vgl. Fagin et al. (2003), o.S.
- ↑ Vgl. Couzin, Grappone (2008), S. 4.
- ↑ Vgl. Davis (2006), S. 2.
- ↑ Vgl. Mao, Mukherjee (2004), S. 41.
- ↑ Vgl. Stock (2006), S. 123 ff.
- ↑ Vgl. Croft et al. (2009), S. 31 f.
- ↑ Vgl. Biel (2006), o. S.
- ↑ Vgl. Leyden (2009), o. S.
- ↑ Vgl. Mao, Mukherjee (2004), S. 6.
- ↑ Vgl. Croft et al. (2009), S 31.
- ↑ Vgl. Mao, Mukherjee (2004), S. 41.
- ↑ Vgl. Stenmark (1999), S. 3 f.
- ↑ Vgl. Mao, Mukherjee (2004), S. 41.
- ↑ Vgl. Mao, Mukherjee (2004), S. 42.
- ↑ Vgl. Hawking (2004), S. 2.
- ↑ Vgl. Croft et al. (2009), S. 46.
- ↑ Vgl. Raghavan (2002), S. 5 f.
- ↑ Vgl. Mao, Mukherjee (2004), S. 6.
- ↑ Vgl. Croft et al. (2009), S. 312 f.
- ↑ Vgl. Lewis (2007), S. 1.
- ↑ Vgl. Fagin et al. (2003), o. S.
- ↑ Vgl. Croft et al. (2009), S. 442 f.
- ↑ Vgl. Mao, Mukherjee (2004), S. 7 f.
- ↑ Vgl. Mao, Mukherjee (2004), S. 10.
- ↑ Vgl. Croft et al. (2009), S. 115.
- ↑ Vgl. Croft et al. (2009), S. 116 f.
- ↑ Vgl. Lewis (2007), S. 2.
- ↑ Vgl. Mao, Mukherjee (2004), S. 6.
- ↑ Vgl. Croft et al. (2009), S. 419 f.
- ↑ Vgl. Croft et al. (2009), S. 404.
- ↑ Vgl. Croft, Rajashekar (1995), S. 15 f.
- ↑ Vgl. Adriani, Croft (1997), S. 5.
- ↑ Vgl. Croft (2002), S. 28.
- ↑ Vgl. Rizzo et al. (2008), S. 27 ff.
- ↑ Vgl. Rizzo et al. (2008), S. 31 ff.
- ↑ Vgl. Rizzo et al. (2008), S. 28.
- ↑ Vgl. Tisseghem, Fastrup (2008), S. 206.
- ↑ Vgl. Tisseghem, Fastrup (2008), S. 364 ff.
- ↑ Vgl. Rizzo et al. (2008), S. 49.
- ↑ Vgl. Rizzo et al. (2008), S. 62 f.
- ↑ Vgl. Tisseghem, Fastrup (2008), S. 231.
- ↑ Vgl. Tisseghem, Fastrup (2008), S. 230.
- ↑ Vgl. Rizzo et al. (2008), S. 28.
- ↑ Vgl. Tisseghem, Fastrup (2008), S. 358.
- ↑ Vgl. Rizzo et al. (2008), S. 37.
- ↑ Vgl. Tisseghem, Fastrup (2008), S. 280.
- ↑ Vgl. Rizzo et al. (2008), S. 34.
- ↑ Vgl. Rizzo et al. (2008), S. 262 f.
- ↑ Vgl. Rizzo et al. (2008), S. 36.
- ↑ Vgl. Rizzo et al. (2008), S. 268.
- ↑ Vgl. Rizzo et al. (2008), S. 259.
- ↑ Vgl. Tisseghem, Fastrup (2008), S. 258.
- ↑ Vgl. Tisseghem, Fastrup (2008), S. 262 f.
- ↑ Vgl. Rizzo et al. (2008), S. 73 f.
- ↑ Vgl. Tisseghem, Fastrup (2008), S. 525 ff.
- ↑ Vgl. Tisseghem, Fastrup (2008), S. 528 ff.
- ↑ Vgl. Rizzo et al. (2008), S. 80.
- ↑ Vgl. Tisseghem, Fastrup (2008), S. 511 ff.
- ↑ Vgl. Rizzo et al. (2008), S. 215.
- ↑ Vgl. Rizzo et al. (2008), S. 270 f.
- ↑ Vgl. Rizzo et al. (2008), S. 15.
- ↑ Vgl. Tisseghem, Fastrup (2008), S. 574 ff.
- ↑ Vgl. Tisseghem, Fastrup (2008), S. 362 ff.
- ↑ Vgl. Tisseghem, Fastrup (2008), S. 249 ff.
- ↑ Vgl. Rizzo et al. (2008), S. 78.
- ↑ Vgl. Rizzo et al. (2008), S. 256.
- ↑ Vgl. Rizzo et al. (2008), S. 63.
- ↑ Vgl. Tisseghem, Fastrup (2008), S. 232.
- ↑ Vgl. Tisseghem, Fastrup (2008), S. 231.
- ↑ Vgl. Rizzo et al. (2008), S. 62.
- ↑ Vgl. Tisseghem, Fastrup (2008), S. 290 ff.
- ↑ Vgl. Rizzo et al. (2008), S. 222 ff.
- ↑ Vgl. Rizzo et al. (2008), S. 63 ff.
- ↑ Vgl. Tisseghem, Fastrup (2008), S. 222 f.
- ↑ Vgl. Tisseghem, Fastrup (2008), S. 223 f.
- ↑ Vgl. Rizzo et al. (2008), S. 63.
- ↑ Vgl. Tisseghem, Fastrup (2008), S. 230.
- ↑ Vgl. Tisseghem, Fastrup (2008), S. 527.
- ↑ Vgl. Tisseghem, Fastrup (2008), S. 227 f.
- ↑ Vgl. Tisseghem, Fastrup (2008), S. 304 ff.
- ↑ Vgl. Rizzo et al. (2008), S. 87.
- ↑ Vgl. Rizzo et al. (2008), S. 117 f.
- ↑ Vgl. Rizzo et al. (2008), S. 104 f.
- ↑ Vgl. Rizzo et al. (2008), S. 119.
- ↑ Vgl. Rizzo et al. (2008), S. 156 ff.
- ↑ Vgl. Rizzo et al. (2008), S. 168.
- ↑ Vgl. Rizzo et al. (2008), S. 181.
- ↑ Vgl. Rizzo et al. (2008), S. 131 f.
- ↑ Vgl. Rizzo et al. (2008), S. 142.
- ↑ Vgl. Rizzo et al. (2008), S. 138.
- ↑ Vgl. Rizzo et al. (2008), S. 141.
- ↑ Vgl. Rizzo et al. (2008), S. 146 ff.
- ↑ Vgl. Rizzo et al. (2008), S. 189.
- ↑ Vgl. Rizzo et al. (2008), S. 191.
- ↑ Vgl. Rizzo et al. (2008), S. 66.
- ↑ Vgl. Rizzo et al. (2008), S. 78.
- ↑ Vgl. Rizzo et al. (2008), S. 190 ff.
- ↑ Vgl. Tisseghem, Fastrup (2008), S. 569 ff.
- ↑ Vgl. Rizzo et al. (2008), S. 201.
- ↑ Vgl. Rizzo et al. (2008), S. 179.
- ↑ Vgl. Tisseghem, Fastrup (2008), S. 312.
- ↑ Vgl. Tisseghem, Fastrup (2008), S. 329 f.
- ↑ Vgl. Rizzo et al. (2008), S. 203 f.
- ↑ Vgl. Tisseghem, Fastrup (2008), S. 272 f.
- ↑ Vgl. Tisseghem, Fastrup (2008), S. 65.
- ↑ Vgl. Rizzo et al. (2008), S. 280 ff.
- ↑ Vgl. Rizzo et al. (2008), S. 280 ff.
- ↑ Vgl. Rizzo et al. (2008), S. 282 f.
- ↑ Vgl. Tisseghem, Fastrup (2008), S. 286 f.
- ↑ Vgl. Rizzo et al. (2008), S. 274 f.
- ↑ Vgl. Rizzo et al. (2008), S. 276 ff.
- ↑ Vgl. Rizzo et al. (2008), S. 279 f.
- ↑ Vgl. Rizzo et al. (2008), S. 78 f.
- ↑ Vgl. Tisseghem, Fastrup (2008), S. 199.
- ↑ Vgl. Computerwoche (2006), o.S.
- ↑ Vgl. Treloar (2009), o.S.
12 Literaturverzeichnis
| Adriani, Croft (1997) | Adriani, M., Croft, B.: Retrieval Effectiveness Of Various Indexing Techniques On Indonesian News Articles, ohne Ort 1995 |
| Bennett (2009) | Bennett, M.: 20+ Differences Between Internet vs. Enterprise Search - And Why You Should Care (Part 2), http://www.ideaeng.com/tabId/98/itemId/157/20-Differences-Between-Internet-vs-Enterprise-Se.aspx (25.10.09 13:37) |
| Biel (2006) | Biel, A., Marketing Pilgrim (Hrsg.): Google Indexing Private Data, http://www.marketingpilgrim.com/2006/06/google-indexing-private-data.html (21.10.09 21:23) |
| Computerwoche (2006) | o.V. Computerwoche (Hrsg.): Portale: Microsoft vor IBM und SAP, 11.12.2006, 2006, Nr. 50, http://www.computerwoche.de/heftarchiv/2006/50/1217137/ (28.12.09 12:34) |
| Couzin, Grappone (2008) | Grappone, J., Couzin, G.: Search Engine Optimization: An Hour a Day, ohne Ort 2008 |
| Croft (2002) | Croft, B.: Combining Approaches to Information Retrieval, in: The Information Retrieval Series, Band 7, Seiten 1-36, ohne Ort 2002 |
| Croft et al. (2009) | Croft, B., Metzler, D., Strohman, T.: Search Engines: Information Retrieval in Practice, ohne Ort 2009 |
| Croft, Rajashekar (1995) | Croft, B., Rajashekar, T.: Combining Automatic and Manual Index Representations in Probabilistic Retrieval, in: Journal of the American Society for Information Science, Band 46, Ausgabe 4, Seiten 272-283, New York 1995 |
| Davis (2006) | Davis, H.: Search Engine Optimization Building Traffic and Making Money with SEO, ohne Ort 2006 |
| Fagin et al. (2003) | Fagin, R., Kumar, R., McCurley, K. S., Novak, J., Sivakumar, D., Tomlin, J. A., Williamson, D. P.: Searching the workplace web, in: Proceedings of WWW2003, Budapest 2008 |
| Gyöngyi, Garcia-Molina (2005) | Gyöngyi, Z., Garcia-Molina, H.: Web Spam Taxonomy, in: First International Workshop on Adversarial Information Retrieval on the Web (AIRWeb 2005), Chiba 2005 |
| Hawking (2004) | Hawking, D.: Challenges in Enterprise Search, in: ACM International Conference Proceeding Series, Band 52, Seiten 15-24, Dunedin 2004 |
| Henzinger et al. (2003) | Henzinger, M., Motwani, R., Silverstein, C.: Challenges in Web search engines, in: Proceedings of the 18th International Joint Conference on Artificial Intelligence (IJCAI’03). 1573–1579., New York 2003 |
| Keeton et al. (2009) | Keeton, K., Morrey, C., Soules, C., Veitch, A.: Lazybase: Freshness vs. performance in information management, in: Proceedings of the 1st Workshop on Hot Topics in Storage and File Systems (HotStorage '09), Big Sky 2009 |
| Khong (2001) | Khong W. K.: Spam Law for the Internet, http://www.buscalegis.ufsc.br/revistas/index.php/buscalegis/article/viewFile/4514/4084 (18.10.09 14:40) |
| Lewis (2007) | Lewis, B.: A Glimpse at the Future of Enterprise Search, 2007, in: IT Professional, Band 9, Ausgabe 2, Seite 12 - 13 |
| Leyden (2009) | Leyden, J., The Register (Hrsg.): Cybercrime server exposed through Google cache UK and US IDs exposed to world, http://www.theregister.co.uk/2009/03/23/cache_exposes_cybercrime_data/ (21.10.09 21:27) |
| Loder et al. (2004) | Loder, T. C.; Van Alstyne, M. W.; Wash, R.: Information Asymmetry and Thwarting Spam, http://ecgi.ssrn.com/delivery.php?ID=736013002124024099104065013031107006049071008034054034076087125076112027014101100011028039028119052022051071106091001080076108020042079063069123096095111068006047079024113006117084126082023025097092&EXT=pdf, (18.10.09 14:12) |
| Mao, Mukherjee (2004) | Mao, J., Mukherjee, R.: Enterprise Search: Tough Stuff, in: Queue, Band 2, Ausgabe 2, Seite 36 - 46, New York 2004 |
| Masak (2005) | Masak, D.: Moderne Enterprise Architekturen., Leipzig 2005 |
| MindBusiness, HanseVision (2008) | MindBusiness GmbH, HanseVision GmbH (2008): SharePoint & Co.: Technologien und Tools im Teamwork, Unterschleißheim 2008 |
| Raghavan (2002) | Raghavan, P.: Information Retrieval for Enterprise Content, in: UPGRADE, Band 3, Ausgabe 3, Seite 5 - 8, ohne Ort 2002 |
| Rittgen (2007) | Rittgen, P.: Handbook of Ontologies for Business Interaction, Hershey 2007 |
| Rizzo et al. (2008) | Rizzo, T., Riley, R., Young, S.: Professional Microsoft Search: SharePoint 2007 and Search Server 2008, Indianapolis 2008 |
| Stenmark (1999) | Stenmark, D.: A Method for intranet search engine evaluations., in: Proceedings of IRIS22, Department of CS/IS, Ausgabe 7-10 August 1999, Jyväskylä 1999 |
| Stock (2006) | Stock, W.: Information Retrieval: Informationen suchen und finden, München 2006 |
| Thelwall (2000) | Thelwall, M.: Web impact factors and search engine coverage, in: Journal of Documentation, Ausgabe 56, Seiten 185-189, ohne Ort 2000 |
| Thelwall, Vaughan (2004) | Thelwall, M., Vaughan, L.: Search Engine Coverage Bias: Evidence and Possible Causes, in: Information Processing & Management, Ausgabe 40, Band 4, Seiten 693-707, ohne Ort 2000 |
| Tisseghem, Fastrup (2008) | Tisseghem, P., Fastrup, L.: Inside the Index and Search Engines: Microsoft Office SharePoint Server 2007, Redmond 2008 |
| Treloar (2009) | Treloar, N.: FAST meets SharePoint - What's Coming in Search for SharePoint 2010, http://blogs.msdn.com/enterprisesearch/archive/2009/10/28/fast-meets-sharepoint-what-s-coming-in-search-for-sharepoint-2010.aspx, (30.12.2009 17:01) |
