Der IBM FileNet Content Manager ist ein sehr beständiges System auf dem Markt. Und das hat auch seine Gründe! Mit diesem Blogartikel räumen wir mit weiteren Missverständnissen auf und bringen Klarheit in den Volltextindex, die FileStores und den Virenscanner.
Was Sie hier erwartet – ein Überblick
1. FileNet Content Manager: Vom Umgang mit dem Volltextindex
Viele unserer Kunden nutzen aus guten Gründen den IBM FileNet Content Manager. Damit sie Herr ihrer Dokumente sind und nicht andersherum, haben sie dieses Tool als zentrales Dokumenten-Management-System im Unternehmen eingeführt.
Doch manche FileNet-Nutzer sind nicht so richtig zufrieden mit ihrem Tool. Woran liegt das? Diesen Gründen sind wir auf der Spur gekommen und haben in diesem Blogpost zwei Themen ausgeführt, die unsere Kunden beschäftigen: der Volltextindex und der FileStore und dessen Tücken mit dem Virenscanner. Schnell stellt sich heraus, dass die vermeintlichen Probleme ganz natürlich sind oder aber mit kleinen Kniffen zu beheben sind.
Übrigens: Zum Thema „Dos and Don‘ts im Umgang mit dem FileNet Content Manager“ gibt es bereits einen initialen Blogpost. Hier nachzulesen.
FileNet Content Manager: Vom Umgang mit dem Volltextindex
Das erste große Thema des Blogposts ist der Volltextindex. Hierzu ein paar einleitende Worte: Die optionale Möglichkeit, Dokumentenbestände auch über eine Volltextsuche zugänglich zu machen, ist grundsätzlich eine großartige Sache. Es gibt aber eine Handvoll Einschränkungen dabei zu beachten.
Treffergenauigkeit
Ein Volltextindex allein bietet keine Sicherheit, alle relevanten Dokumente zu finden – auch nicht im IBM FileNet Content Manager.
Der Volltextindex, das liegt in der Natur der Sache, ist fehleranfällig. Beispiel: ein dediziertes Attribut zur Klassifikation von Fahrzeugtypen enthält Werte wie „PKW“, „LKW“ oder „Bus“. In einem Fließtext könnte für den Begriff „PKW“ genauso gut auch „Auto“, „Fahrzeug“, „Kfz“ oder auch „Rostlaube“ stehen. Hier kann man in gewissen Grenzen mit der Definition von Synonymen gegensteuern.
Es wird aber schnell klar, dass das Ergebnis einer Volltextsuche immer nur eine Näherung und nie ein wirklich exakt sein wird.
Zeitpunkt der Indizierung
Im IBM FileNet Content Manager erfolgt die Indizierung asynchron.
Das ist sinnvoll, wenn man an Szenarien mit Massenablage denkt. Die liefernden Systeme bekommen eine Quittung für jedes abgelegte Dokument. Auf diese Quittung muss nicht gewartet werden, bis der Volltextindex aufgebaut worden ist, sie wird in dem Moment zugestellt, in dem das Dokument auf dem Speichermedium angekommen und in der Datenbank registriert ist. Ab diesem Zeitpunkt ist eine Recherche über die mitgelieferten Indexwerte – unter Berücksichtigung der vergebenen Berechtigungen – konsistent möglich. Je nach Belastung des Systems, kann es dann noch eine Weile dauern, bis das Dokument auch über seinen Volltextinhalt gefunden werden kann.
Daher ist unsere Empfehlung den Volltext nur additiv zur Suchmöglichkeit über Attribute zu verwenden.
Kombinierte Suchen aus Attributen und Volltextstichworten
Bereits im Standard des IBM FileNet Content Managers ist es möglich, eine Suchmaske zu konfigurieren, die sowohl über Attribute als auch über Volltextstichworte arbeitet. Dabei wird vom Backend zunächst die Suchabfrage über die Attribute an die Datenbank geschickt. Die daraus resultierende Trefferliste wird an die Volltextsuche übergeben. Durch diese Reihenfolge wird sichergestellt, dass die gesuchten Stichworte nur in den Dokumenten gesucht werden, deren Attribute den gewünschten Bedingungen entsprechen.
Dies dient der Performanceoptimierung.
Technisch möglich ist es auch, eine Suche nur nach Volltextstichworten zu konfigurieren. Da der Volltext aber keinerlei Berechtigungsinformationen enthält, kann es sein, dass ein Dokument nicht gefunden wird, obwohl es im Bestand vorhanden und korrekt indiziert ist. Wie kann so etwas passieren?
Um auch bei großen Datenbeständen den Anwender nicht zu lange warten zu lassen, ist die Größe der Trefferliste bei einer Volltextabfrage begrenzt. Da der Volltextindex keinerlei Berechtigungs-informationen enthält, muss diese Bruttotrefferliste noch über den Berechtigungsfilter laufen, damit sichergestellt ist, dass dem Anwender keine Dokumente angezeigt werden, zu denen er nicht mindestens über das Leserecht verfügt.
Wird in einem großen Datenbestand nach trivialen, häufig vorkommenden Worten gesucht, ist diese Gefahr besonders groß. Mit anderen Worten: auch Volltextsuche will gelernt sein.
Nicht alle Dateiformate werden indiziert
Die Volltext-Engine arbeitet mit einem Filter für Dateiformate. Platt gesagt werden z.B. Bilder nicht indiziert. Das gilt auch dann, wenn die TIFF-Tags mit Textinhalten gefüllt sind oder die EXIF-Daten einer jpeg-Datei Schlagworte enthalten. Ebenso ignoriert werden Daten in „exotischen“ Formaten wie etwa AFP-Datenströme. Diese sind nach dem EBCDIC-Standard codiert und werden nicht erkannt.
Für solche Anwendungsfälle gibt es einen eleganten Workaround. Dazu muss in einer vorgelagerten Verarbeitung der gewünschte Textinhalt extrahiert und in einer separaten Textdatei abgespeichert werden. Das Ladeprogramm übergibt diese Textdatei als zweites Contentelement an das FileNet-System. Durch diesen Trick wird der Volltextindex gefüllt und die Benutzeroberfläche liefert das korrekte Element zurück. Im Standard ist es immer das erste Contentelement eines Dokumentes.
Was genau wird indiziert?
In Projekten hören wir immer den Wunsch nach einer möglichst einfachen „Google Like“-Suche im IBM FileNet Content Manager.
Aus den oben genannten Gründen ist das für größere Dokumentenbestände nicht sinnvoll. Geht es aber nur um ein paar tausend Vertragsdokumente, kann man diesem Ziel mit einem Trick sehr nahekommen. Dazu ist es möglich, die fachlichen Attribute eines Dokumentes (soweit es denn welche vom Typ Text sind) durch einen Mausklick in der Attributdefinition zusätzlich zum Dokumenteninhalt in den Volltext zu übernehmen. Dadurch lassen sich mit tatsächlich nur einem einzigen Suchfeld, Attributwerte und Textinhalte durchsuchen.
FileNet Content Manager: FileStores und Virenscanner
Das Überraschungsmoment bei Migrationen
Zu unangenehmen Überraschungen kann es kommen, wenn auf den beteiligten Systemen unterschiedliche Virenscanner oder auch unterschiedliche Parameter für den gleichen Virenscanner eingesetzt werden.
Im konkreten Fall kann es im Zuge einer Migration von einem Linux- zu einem Windows-System zu einem Datenverlust kommen. Ein Dokument, das auf dem Linux-System dem eingesetzten Virenscanner als unverdächtig erschien, wurde an ein Windows-gestütztes FileNet-System übertragen. Hier muss man sich jetzt die Reihenfolge der technischen Ablage genau anschauen.
Die Reihenfolge der technischen Ablage
1. Schritt
2. Schritt
Ergebnis
Wenn nun ein Anwender auf dieses Dokument zugreift, findet er über die Attributsuche das Dokument. Der Versuch auf den Inhalt zuzugreifen wird allerdings mit einer Fehlermeldung beantwortet, da das gewünschte Contentelement nicht mehr im FileStore vorhanden ist.
Diese missliche Situation hätte auch ein regelmäßig ausgeführter FileNet Consistency Check aufgedeckt.
Wir freuen uns auf Ihre „Aha“-Momente
Cihan Klingsporn
Senior Account & Marketing Managerin
Business Process Automation
cihan.klingsporn@isr.de
+49(0)151 422 05 471
