Fileorientierte Dokumentendatenbank

In der standard Installation deines Kieselstein ERP Systems wird als Dokumentendatenbank eine eigene Datenbank deines Postgres-Datenbank-Servers verwendet.

Hast du nun einige Zeit dein KIESELSTEIN ERP im Einsatz, so kann diese Datenbank schon deutlich anwachsen. Da selbstverständlich auch diese Dateien gesichert werden müssen, denke dabei an die eRechnung und die Aufbewahrungspflichten auf der Datei von 10Jahren oder mehr, so kann hier schon auch die Nacht für die tägliche Sicherung zu kurz werden.

In diesem Falle kommt die Fileorientierte Dokumentendatenbank zum Einsatz.

Der besondere Vorteil ist, dass die eigentlichen Daten im Datei-System liegen und, da die Dokumentendatenbank nur einen Datenzuwachs kennt / erlaubt, können die Dateien z.B. mit rsync täglich gegen dein Backupsystem gesichert werden. Dabei werden nur die geänderten Dateien übertragen, was deutlich schneller geht.

Zusatzinfo: Es muss trotzdem die KIESELSTEIN_DOCUMENTS gesichert werden, da nach wie vor die Verwaltung der Dokumente in dieser Datenbank abgebildet ist.

Solltest du von Anfang an bereits die fileorientierte Datenbank verwenden wollen, also bevor das erste Dokument abgelegt wurde, so nutze die unter LW:\kieselstein\dist\bin\README.md beschriebene Environment-Variable DOC_CONFIG, mit der die verwendete Art der Dokumentendatenbank definiert wird.

Bitte beachte:

1. Die Umstellung darf nur bei gestopptem Kieselstein ERP Server erfolgen
2. Idealerweise nur bei faktische leerer Dokumentendatenbank (siehe KIESELSTEIN_DOCUMENTS, Tabelle: Datastore)
3. Wenn du umstellst, OHNE die bestehenden Dokumente verwenden zu wollen/müssen, so muss LW:\kieselstein\data\jackrabbit\workspaces entfernt werden
4. Für die Übertragung bestehender Daten siehe unten

Übertragung der Dokumentendatenbank

Für die Übertragung deiner Dokumenten (Inhalte) aus der Postgres Datenbank in die Fileorientierte Dokumenten-Datenbank steht folgende Vorgehensweise zur Verfügung

Ab der Version 2.1 ist dieser Vorgang ähnlich der Migration der Datenbank auf OAK. Siehe daher

Die Details der durchzuführenden Schritte sind unter LW:\kieselstein\dist\bootstrap\jcrmigration\README.md beschrieben. Erstmalig wurde dies unter https://gitlab.com/kieselstein-erp/sources/kieselstein/-/merge_requests/256 dokumentiert.
Die Angaben in der Readme beziehen sich immer auf das jcrmigration Verzeichnis.

Du benötigst dafür auch die PostgresQL Commands. D.h. es muss der Pfad auf dein Postgres bzw. deinen PGadmin in der path Environment eingetragen sein. Dies ist default.

Beachte dass dafür auch ein entsprechender Speicherplatz auf deinem System erforderlich ist. Hier kannst du, für die Dauer der Übertragung, vom doppelten Platz deines Backups ausgehen.

Wichtig: Wenn du deinen Kieselstein ERP Server neu startest und der Index der bestehenden Dokumenten Datenbank neu aufgebaut werden muss und du eine entsprechende Menge an Dokumenten hat, dann beachte, dass normalerweise nach ca. 5Minuten ca. eine Fehlermeldung kommt, dass auf das (bestehende) Dokumentensystem nicht zugegriffen werden kann. WICHTIG: Der Dokumenten-Task (Jackrabbit) läuft trotzdem weiter und schreibt seine Infos in das server.log. D.h. du musst so lange warten, bis hier keine Einträge mehr dazu kommen. Die Einträge sehen ungefährt wie 2025-04-25 11:39:50,466 INFO [org.apache.jackrabbit.core.query.lucene.IndexMerger] (jackrabbit-pool-5) merged 7660 documents in 119 ms into _9p.

aus.

Es muss, für den Neustart, LW:\kieselstein\data\jackrabbit.. leer sein.

Es muss jedenfalls die Dokumentenablage vollständig im Ausgangssystem funktionieren.

Beispielzeiten:

• Größe der Postgres Dokumentendatenbank ca. 56GB

  • Starten mit neu zu initialisierendem JackRabbit ca. 30Minuten
    Um die erlaubte Startzeit zu erhöhen nutze die Environment Variable.

  • Pfade erneuern der Dokumentendatenbank 25 Minuten

  • Dump der Dokumentendatenbank in ein neues Ziel ca. 2,25 Std

    • Hinweis: Dass die Verarbeitung beendet ist erkennt man daran, dass am Schluss
      
      Der Stop Button deaktiviert ist und dass erwartet und verarbeitet erscheint.

  • Stoppen des Servers nach 2.

  • Es muss alles in der Std KES Struktur ausgeführt werden. Gemischt ist nicht vorgesehen!

Info: Ein Neustart des Dumps setzt normalerweise beim Abbruch fort.

Zusätzlich die Parametrierungsarbeiten

am 3.Punkt Das Workspaces und das Workspacesdump wegschieben ??

Vorher:
Pfade erneuern lassen, damit defekte Dokumente erkannt werden.
Diese Job kannst du auch mal im laufenden Betrieb vor der Umstellung laufen lassen.

Info:
Siehe server.log, hier steht bei den Fehlerhaften Dokumenten ev. auch ein Eintrag sPath=/HELIUMV/001/Auftrag/Auftrag/25488 so ist hier die 25488 die ID des Datensatzes, womit man dann die Auftragsnummer findet.

Nach der Pflege mit Dokumentenablage Dump erkennt das System das Ende nicht sauber. D.h. er springt dann nach den 100% wieder auf 33% zurück und sucht, was noch zu übertragen wäre.

Was tun wenn

• Der Cursor für die Anzeige bleibt stecken
  Ins Server.log rein sehen, vielleicht steht da so etwas wie Java Heap Space -> bedeutet deinem KES ist der Speicher ausgegangen. Ev. solltest du
  • KIESELSTEIN_JAVA_OPT_XMX auf 5G
  • KIESELSTEIN_JAVA_OPT_XMS auf 512M
    setzen

Alleine am / im Kieselstein ERP arbeiten

Da du für die Übertragung der Dokumente aus der Postgres-Datenbank in die Fileorientierte Datenbank benötigst, in dieser Zeit aber niemand am System arbeiten sollte, solltest du vor dem Start deines Kieselstein-Servers alle Benutzer ausgenommen deinem eigenen Admin sperren.

update pers_benutzer set b_gesperrt = 1 where c_benutzerkennung != 'Admin';

ACHTUNG:
Dies funktioniert nur richtig, wenn alle eingetragenen Benutzer dein Kieselstein ERP System nutzen durften. Sollte dem nicht so sein, so bereinige die Zugangsdaten vorher.

Denke daran, nach der gesamten Umstellung die Benutzer auch wieder freizuschalten.

update pers_benutzer set b_gesperrt = 0 where c_benutzerkennung != 'Admin';

Migration mit bestehender OAK Datenbank

Ab der Version 2.1 RC5 kann die Migration der Dokumentendatenbank von der Ablage im Postgres auf die Fileorientierte Datenbank mit dem JCR Migrationstool vorgenommen werden.

Folgende Schritte:

• notiere dir einige Dokumente die du nach der Migration prüfen möchtest um zu beurteilen, dass die Migration funktioniert hat
• Stoppen des Kieselstein ERP Servers
• Um die Tests durchführen zu können, ohne dass andere Benutzer nach dem Start bereits Daten erzeugen siehe
• Anpassen der LW:\kieselstein\dist\bootstrap\jackrabbitmigration\migrate-jackrabbit.conf
  • setzen der INPUT_VERSION=oak
• Starten der Migration
  Eine eventuell bestehende KIESELSTEIN_DOCUMENTS_OAK vorher löschen
  durch ausführen von migrate-jackrabbit.bat aus dem Verzeichnis LW:\kieselstein\dist\bootstrap\jackrabbitmigration\migrate-jackrabbit.bat
  Achte darauf, dass der Prozess ohne Exception beendet wird. D.h. es sollte zum Schluss eine Meldung ähnlich folgender stehen:
  TT:MM:JJJJ 09:48:54.033 [main] INFO migrate - Migration completed without exception
• Verschiebe nun den Inhalt des neu erzeugten Verzeichnisses LW:\kieselstein\dist\bootstrap\jackrabbitmigration\output\oak\ in dein LW:\kieselstein\data\jackrabbit\datastore<br> Bitte die Datei reference.key nicht übertragen
• Benenne nun die Datenbank KIESELSTEIN_DOCUMENTS um auf z.B. KIESELSTEIN_DOCUMENTS_OLD
• Benenne die neue Datenbank KIESELSTEIN_DOCUMENTS_OAK um auf KIESELSTEIN_DOCUMENTS
• Ändere bzw. erstelle neu, die Environment Variable DOC_CONFIG auf

LW:\kieselstein\dist\conf\jackrabbit-datastore-fs.xml

• Starte nun deinen Kieselstein ERP Server
• Prüfe die notierten Dokumente, wenn alles passt, schalte die Benutzer wieder frei.
  Damit ist die Migration abgeschlossen