xRM-Dokumente in Sage 100: Warum eingebettete Dateien Deine Datenbank ausbremsen

Im xRMxRMDas in die Sage 100 integrierte Beziehungsmanagement (Extended Relationship Management). Es verbindet Kunden, Verkaufschancen, Projekte, Service und Support direkt mit den ERP-Daten.Mehr im Glossar → der Sage 100 hängen an Kontakten, Vorgängen und Projekten Dokumente: Angebote, Serviceberichte, Fotos, vor allem aber E-Mails aus dem Outlook-Mailtracking. In den meisten Installationen landen die alle am selben Ort, nämlich direkt in der Datenbank. Das funktioniert jahrelang unauffällig, und irgendwann fällt jemandem auf, dass die Sage-Datenbank 40 GB groß ist und das Backup-Fenster nicht mehr reicht.

Dieser Beitrag zeigt Dir, wo die Dokumente technisch liegen, welche Probleme das Einbetten mit sich bringt, welche Speichermodelle das xRM kennt und wie Du sowohl die Grundlagen als auch den vorhandenen Bestand umstellst.

Wo die Dokumente wirklich liegen

Alle xRM-Dokumente stehen in einer einzigen Tabelle, und die heißt BCSPjmDokumente. Der Aufbau ist schnell erzählt:

CREATE TABLE [dbo].[BCSPjmDokumente](
    [ID]              [int] IDENTITY(1,1) NOT NULL,
    [Mandant]         [smallint] NOT NULL,
    [PosID]           [int] NOT NULL,
    [Typ]             [smallint] NOT NULL,
    [Dokument]        [varbinary](max) NULL,
    [SourceRoot]      [varchar](512) NULL,
    [SourceFile]      [varchar](512) NULL,
    [SourceExtension] [varchar](10) NULL,
    [Beschreibung]    [varchar](max) NULL,
    [Erstellt]        [datetime] NULL,
    [Kategorie]       [varchar](20) NULL,
    [DocIDSageDMS]    [varchar](60) NULL,
    [Timestamp]       [timestamp] NOT NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

Interessant sind zwei Stellen. Die Spalte Dokument ist ein varbinary(max) und nimmt bei eingebetteten Dokumenten den kompletten Dateiinhalt auf. Bei verknüpften Dokumenten bleibt sie leer, stattdessen sind SourceRoot, SourceFile und SourceExtension gefüllt. Dass der Wurzelpfad getrennt vom Dateinamen gespeichert wird, ist kein Zufall. Genau darauf setzt die Grundlageneinstellung für die Dateiablage auf, dazu gleich mehr.

Die zweite Stelle ist das TEXTIMAGE_ON [PRIMARY] am Ende. Die Dokumentinhalte liegen also in derselben Dateigruppe wie alle übrigen Sage-Daten. Es gibt keine getrennte Dateigruppe für Dokumente, die Du separat auf günstigen Speicher legen oder read-only schalten könntest, und auch kein FILESTREAM. Was eingebettet wird, ist damit Teil der operativen Datenbank und wird mit ihr zusammen gesichert, wiederhergestellt, kopiert und geprüft.

Wie viel das bei Dir ist, verrät eine kurze Abfrage auf dem Mandanten:

SELECT COUNT(*)                                             AS Dokumente,
       SUM(CASE WHEN Dokument IS NOT NULL THEN 1 ELSE 0 END) AS Eingebettet,
       SUM(CASE WHEN Dokument IS NULL     THEN 1 ELSE 0 END) AS Verknuepft,
       CAST(SUM(DATALENGTH(Dokument)) / 1048576.0 AS decimal(18,1)) AS MB
FROM dbo.BCSPjmDokumente;

In der Praxis kommen dabei schnell einige Gigabyte zusammen. In dem Demobestand, an dem wir unser Tool getestet haben, waren es 8.729 Dokumente mit 2,3 GB. Bei Kunden mit aktivem Mailtracking über mehrere Jahre sehen wir deutlich größere Bestände, weil dort jede archivierte Mail samt Anhang in der Tabelle landet.

Was eingebettete Dokumente im Betrieb kosten

Das Problem ist nicht der Speicherplatz an sich. Plattenplatz ist billig geworden. Das Problem ist, dass diese Datenmenge in jedem einzelnen Vorgang mitläuft, der die Datenbank anfasst.

• Sicherung und Wiederherstellung. Ein Vollbackup zieht die Dokumente jedes Mal komplett mit, obwohl sich an einem Angebot von 2019 nichts mehr ändert. Aus einem 20-Minuten-Backup wird eine Stunde, und im Ernstfall dauert die Wiederherstellung genauso lange. Die Zeit bis zur Wiederverfügbarkeit Deiner Warenwirtschaft hängt dann zu großen Teilen an Dateien, die im Tagesgeschäft niemand braucht.
• Mandanten- und Testkopien. Jede Kopie für Schulung, Test oder eine Updateprobe vervielfacht die Dokumentmenge. Wer drei Testumgebungen betreibt, sichert und lagert seine Dokumente viermal.
• Wartungsfenster. Ein DBCC CHECKDB und die Indexpflege laufen über eine größere Datenbank länger. Das ist keine Katastrophe, verschiebt aber jedes Wartungsfenster nach hinten.
• Transaktionsprotokoll. Wird ein 30-MB-Anhang eingebettet, geht er durch das Log. Bei vielen und großen Dokumenten wächst das Protokoll, und die Protokollsicherungen wachsen mit.
• Zugriff nur über Sage. Was in der Tabelle steckt, kann kein Explorer öffnen, kein Dokumentenmanagementsystem indizieren, keine Windows-Suche finden und kein Virenscanner prüfen. Ein Dokument aus dem xRM zu bekommen, heißt immer: Sage 100 starten, Eintrag suchen, Dokument extrahieren.
• Bearbeiten ist umständlich. Ein eingebettetes Dokument wird beim Öffnen aus der Datenbank in eine temporäre Datei geschrieben und muss nach der Bearbeitung wieder zurück. Das ist der von Sage selbst genannte Nachteil des Modells und macht sich vor allem bei großen Dateien bemerkbar.
• Doppelte Stände. Bettest Du eine bestehende Datei ein, existiert sie danach zweimal, einmal im Dateisystem und einmal in der Datenbank. Änderungen musst Du in beiden nachziehen, und bei der nächsten Rückfrage weiß niemand mehr, welcher Stand der richtige war.

Die Speichermodelle des xRM

Das xRM kennt beim Anlegen eines Dokuments mehrere Speichermodelle. Praktisch relevant sind heute drei davon. Die früher ebenfalls angebotenen OLE-Dokumente spielen in aktuellen Installationen keine Rolle mehr.

Als Faustregel gilt: Je größer ein Dokument, desto mehr überwiegen die Vorteile der Verknüpfung. Bei einer 40 KB großen Notiz ist die Diskussion müßig, bei einem 200-MB-Video nicht.

Die Grundlagen umstellen

Alles Weitere steuerst Du in den Grundlageneinstellungen. Zwei Einträge sind dafür wichtig.

Speichermodell für neue Dokumente

Unter Kontakt- und Vertriebsmanagement findest Du im unteren Drittel vier Eigenschaften, die das Verhalten beim Anlegen festlegen.

• Bevorzugtes Speichermodell Dokumente ist die Voreinstellung, wenn ein Anwender ein Dokument zu einem Eintrag hinzufügt oder erstellt.
• Großes Speichermodell Dokumente greift ab einer bestimmten Dateigröße. Es gilt unter anderem dann, wenn eine bestehende Datei manuell angehängt wird und das Modell nicht geändert werden darf, wenn ein Dokument über Dokument erstellen entsteht und wenn E-Mails über das Senden und Erstellen von Mails oder über das Outlook-Mailtracking an einem Eintrag landen.
• Großes Speichermodell verwenden ab [MB] legt die Schwelle fest, im Screenshot 10 MB.
• Anwender kann Speichermodell auswählen entscheidet, ob der Anwender im Dokumentdialog davon abweichen darf.

Die im Screenshot gezeigte Kombination ist ein brauchbarer Kompromiss für den Einstieg: Kleines wird eingebettet, alles ab 10 MB wird verknüpft. Wer die Datenbank konsequent schlank halten will, stellt beide Modelle auf verknüpft und setzt Anwender kann Speichermodell auswählen auf Nein, damit niemand aus Gewohnheit wieder einbettet.

Wurzelpfad für verknüpfte Dokumente

Damit die Verknüpfung funktioniert, braucht das xRM ein Zielverzeichnis. Das steht in der Grundlageneinstellung Dateiablage verknüpfte Dokumente.

Der Stern in der Spalte Anwender bedeutet, dass der Pfad für alle gilt. Du kannst darunter aber auch einzelne Anwender mit einem abweichenden Pfad eintragen, etwa wenn ein Standort dieselbe Ablage über einen anderen Servernamen erreicht.

Das ist mehr als eine Bequemlichkeit. Weil in der Tabelle SourceRoot und SourceFile getrennt stehen, kann das xRM den Wurzelpfad zur Laufzeit ersetzen. Zieht die Ablage später auf einen anderen Server um, änderst Du hier eine Zeile statt zehntausende Verknüpfungen in der Datenbank. Genau das entschärft den klassischen Nachteil verknüpfter Dokumente, nämlich tote Pfade nach einem Serverumzug. Nutze deshalb immer einen UNC-Pfad auf eine Freigabe und keinen lokalen Laufwerksbuchstaben, den nur ein Rechner kennt.

Wenn Du die strukturierte Dateiablage einsetzen willst, konfigurierst Du sie direkt darunter unter Konfiguration der strukturierten Dateiablage. Der hinterlegte Pfad dient dann als Wurzelverzeichnis, unter dem die Ordner für Jahr, Monat und gegebenenfalls Projektnummer automatisch entstehen.

Der Haken: Bestehende Dokumente ändern das Modell nicht

Mit den Grundlagen hast Du geregelt, was künftig passiert. Für die Dokumente, die längst in der Datenbank stehen, ändert sich dadurch nichts. Das Speichermodell eines bestehenden Dokuments lässt sich im Dokumentdialog nicht umstellen, das Feld ist dort gesperrt.

Der manuelle Weg wäre, jedes Dokument einzeln über das Optionsmenü als Datei zu speichern, das alte zu löschen und die Datei neu als Verknüpfung anzuhängen. Bei fünfzig Dokumenten ist das ein Nachmittag, bei achttausend ist es keine Option. Zumal dabei jedes Mal Erstellungsdatum, Beschreibung und Kategorie von Hand wieder gesetzt werden müssten.

Bestand umstellen mit der xRM Dateiablage

Für genau diesen Schritt haben wir ein kleines Tool gebaut. Die xRM Dateiablage liest die eingebetteten Dokumente aus BCSPjmDokumente, schreibt sie in ein Verzeichnis Deiner Wahl und stellt die zugehörigen Einträge in Sage anschließend auf die verknüpfte Ablage um. Die Zuordnung zum Kontakt oder Vorgang bleibt dabei erhalten, für die Anwender ändert sich an der Bedienung nichts.

Der Ablauf ist bewusst schlicht gehalten:

• Anmeldung per Windows-Authentifizierung oder SQL-Anmeldung, dazu Server, Datenbank und Mandantennummer.
• Beim Feld Ablagepfad hast Du die Wahl. Lässt Du es leer, übernimmt das Programm beim Prüfen den in Sage hinterlegten Standardpfad aus der Grundlageneinstellung. Trägst Du einen Pfad ein, gilt dieser.
• Verbindung und Bestand prüfen zeigt Dir vorab, wie viele Dokumente betroffen sind und welches Volumen sie haben. Dieser Schritt ändert nichts.
• Migration starten arbeitet die Dokumente einzeln ab. Jede Datei wird zuerst temporär geschrieben, auf Vollständigkeit geprüft und erst dann in der Datenbank umgehängt. Gleichzeitige Änderungen am selben Datensatz werden erkannt, sodass ein Dokument nicht verloren gehen kann, das jemand parallel bearbeitet.
• Bricht der Lauf ab, etwa weil das Netzwerk wegbricht, setzt ein erneuter Start an der Stelle auf, an der er aufgehört hat. Bereits umgestellte Dokumente werden nicht erneut angefasst.

Zum Ausprobieren: Die Freeware-Fassung

Du musst uns nicht glauben, dass das funktioniert, Du kannst es selbst ausprobieren. Die xRM Dateiablage steht als Freeware zum Download bereit, ohne Anmeldung und ohne dass Du uns Deine Adresse dalassen musst. Ohne Lizenz lassen sich damit einmalig bis zu 25 Dokumente extrahieren. Das reicht, um an einer Kopie Deiner Datenbank zu sehen, wie der Ablauf aussieht, ob die Dateien sauber im Zielverzeichnis landen und ob die Anwender die Dokumente danach wie gewohnt im xRM öffnen können.

Für die Umstellung eines kompletten Bestands brauchst Du eine Lizenz. Sprich uns dafür einfach an, wir schauen uns Deinen Bestand vorher ohnehin gemeinsam an.

Was Du vorher klären solltest

Darüber hinaus sind das die Punkte, die in Projekten regelmäßig aufkommen:

• Berechtigungen. Solange die Dokumente in der Datenbank stehen, kommt niemand ohne Sage 100 an sie heran. Nach der Umstellung entscheidet das Dateisystem. Die Freigabe muss so berechtigt sein, dass alle xRM-Anwender lesen und schreiben können, aber eben auch nicht mehr Leute als vorgesehen. Das ist der eine Punkt, an dem die Umstellung mehr ist als eine technische Übung.
• Datensicherung. Das Zielverzeichnis muss in das Sicherungskonzept, und zwar mit einem Rhythmus, der zur Datenbanksicherung passt. Sonst hast Du nach einer Wiederherstellung Verknüpfungen auf Dateien, die es nicht mehr gibt.
• Kein Cloud-Sync-Ordner. Ordner, die im Hintergrund synchronisiert werden, sind als Ziel ungeeignet. Umbenennungen, Platzhalterdateien und verzögerte Verfügbarkeit vertragen sich nicht mit fest gespeicherten Pfaden.
• Virenscanner. Ein Scanner, der Dateien beim Schreiben in Quarantäne schiebt, sorgt für genau die toten Verknüpfungen, die Du vermeiden willst. Die Ausnahmeregeln gehören vor den Lauf abgestimmt.
• Die Datenbank schrumpft nicht von allein. Nach der Migration ist der Platz in der Datei frei, die Datei selbst bleibt aber gleich groß. Wenn Du den Platz zurückgeben willst, brauchst Du ein DBCC SHRINKFILE und danach eine Indexreorganisation, weil ein Shrink die Indizes zerlegt. Plane das ins Wartungsfenster ein und mach es einmal richtig statt regelmäßig. Dass dieser Shrink oft nicht so läuft wie erwartet, haben wir im Folgebeitrag DBCC SHRINKFILE läuft, aber die Datei bleibt groß auseinandergenommen.
• Testkopien. Denk daran, dass Kopien der Datenbank auf denselben Ablagepfad zeigen. In einem Testmandanten willst Du in aller Regel ein anderes Verzeichnis hinterlegen, damit dort niemand versehentlich produktive Dateien überschreibt.

Fazit

Eingebettete Dokumente sind bequem und in kleinen Installationen völlig in Ordnung. Ab einer gewissen Größe drehen sich die Vorzeichen aber: Die Datenbank trägt dann Ballast, der das Backup verlängert, jede Kopie aufbläht und im Ernstfall die Wiederherstellung verzögert. Die Trennung von strukturierten Sage-Daten und Dokumentdateien schafft an dieser Stelle Luft und gibt Dir die Freiheit, beides getrennt zu sichern und zu skalieren.

Der Weg dorthin besteht aus zwei Teilen. Die Grundlageneinstellungen regeln, was künftig passiert, und sind in zehn Minuten gesetzt. Den vorhandenen Bestand bekommst Du damit nicht umgestellt, dafür braucht es einen kontrollierten Lauf über die Tabelle. Wichtig ist, dass Du die Umstellung nicht als reines Datenbankthema behandelst. Berechtigungen und Sicherung der neuen Ablage sind der Teil, der hinterher zählt.

Wenn Du wissen willst, wie groß das Thema bei Dir überhaupt ist, fang mit der Abfrage oben an. Bei der Bewertung der Zahlen und der Umstellung helfen wir gerne. Passend dazu ist auch unser Beitrag zum Prüfen von Sage-100-Backups, und was das xRM sonst noch kann, steht auf unserer Seite zu Sage 100 xRM.