Regeln für das Auslagern von Daten erstellen

Diese Dokumentation beschreibt, wie Sie eigene Regeln für das Auslagern von Daten in den Storages anlegen. Dabei können Sie konfigurieren, wie das System diese Daten auslagern soll, etwa, dass das System nur bestimmte Dokumententypen abspeichern soll, oder ein Storage einem bestimmten Pfad zugewiesen wird.

Bei der Speicherung unterteilt das System jede Datei in je 512 KB-Datenblöcke und schreibt sie in die Datenbank.
Eine 10 MB große Datei ergibt etwa 20x 512 KB Datenblöcke in der Datenbank.
Durch dieses Verfahren können Sie beliebig große Dateien in der Datenbank schreiben.

Mehr zu diesem Verfahren und dem Umgang mit Regeln erfahren Sie anhand eines Beispielprojekts.

Hinweis: Erstellen und testen Sie eigene Regeln zuerst auf einem Testsystem, bevor Sie sie produktiv einsetzen.

Das Beispielprojekt „agorum core demo storage“ installieren

Laden Sie das Beispielprojekt agorum core demo storage undefined>herunter.
Installieren Sie es auf einem Testsystem über das agorum core support tool.

Nach der Installation finden Sie im Ordner Dateien das Beispielprojekt unter der Ordnerstruktur:

Dateien/agorum core demo storage

Ordnerstruktur nach der Installation

In den Ordnern Kunden und Lieferanten finden Sie Beispielakten.

Eine Regel und ein Storage anlegen

Für das genannte Beispielprojekt existiert ein Skript, das die Regeln sowie die Storages automatisch anlegt.
Ihre eigenen Storages legen Sie über die grafische Oberfläche an.

So legen Sie die Regeln und Storages des Beispielprojekts per Skript an:

Öffnen Sie links in der Seitenleiste Weitere Apps und dann Storage.
Klicken Sie auf Neu.
Klicken Sie auf Back-End-Konfiguration.
Speichern Sie diese Einstellung, löschen Sie sie wieder und speichern Sie die Änderungen erneut.
Öffnen Sie links in der Seitenleiste Explorer.

Öffnen Sie den Pfad:

Eigene Dateien/Administration/customers/agorum.demo.storage/js

Öffnen Sie das Skript create-test-storages.js mit einem Doppelklick.
Klicken Sie auf Run.

Eine Regel und ein Storage aktivieren

Nach der Skriptausführung müssen Sie eben erstellten Regeln und die Storages manuell in der MetaDB aktivieren. D. h. das Skript legt diese Regeln und die Storages nur an, sie sind aber zu diesem Zeitpunkt noch deaktiviert.

Eine Regel aktivieren

Öffnen Sie links in der Seitenleiste Administration und dann MetaDB.
Öffnen Sie den Pfad:
```
MAIN_MODULE_MANAGEMENT/backend/[ agorum.demo.storage ]/rules-demo
```
Ergebnis: Sie sehen verschiedene Ordner (Property-Bundles), die durchnummeriert sind.

Durchnummerierte Regeln im Ordner rules-demo

• Jeder Ordner entspricht einer Regel.
• In jedem Ordner befinden sich zwei Property-Entrys namens backend und query.
• Beschreibung dieser Property-Entrys siehe Property-Entrys „backend“ und „query“

Hinweis: Regeln beginnen im Normalfall mit der Ziffer 0. Die Regeln in den Abbildungen beginnen bei 4, weil in der agorum core-Installation bereits 4 Regeln existieren und somit belegt sind.
Schneiden Sie die Ordner aus und fügen Sie sie in diesen Pfad ein:
```
MAIN_MODULE_MANAGEMENT/backend/rules
```

Ein Storage aktivieren

Öffnen Sie diesen Pfad in der MetaDB:
```
MAIN_MODULE_MANAGEMENT/backend/[ agorum.demo.storage ]/configurations-demo
```
Ergebnis: Sie sehen 5 verschiedene Ordner.

Storage-Bereiche im Ordner configurations-demo

Jeder dieser Ordner steht für ein Storage.
Schneiden Sie die Ordner aus und fügen Sie sie in diesen Pfad ein:
```
MAIN_MODULE_MANAGEMENT/backend/configurations
```

Eine Regel anpassen

Nachdem Sie die Regeln und Storage-Bereiche aktiviert haben, passen Sie die Regeln an, um eigene zu definieren.

Öffnen Sie diesen Pfad in der MetaDB:
```
MAIN_MODULE_MANAGEMENT/backend/rules
```
Öffnen Sie die Regel.
Doppelklicken Sie auf das Property-Entry query, um es zu bearbeiten.
Ändern Sie das Property-Entry ab, um die Regel anzupassen.

Beispiele siehe Enthaltene Regeln im Beispielprojekt (Beispiele für Regeln)

Tipps:
• Haben Sie eine Regel falsch hinterlegt und korrigieren diese, wendet das System die Regel direkt an und zieht die Daten um. In dieser Zeit kann der Speicherverbrauch kurzfristig steigen, weil Daten über eine gewisse Zeit doppelt oder öfter vorhanden sind.
• Eigene Regeln legen Sie jederzeit über weitere Property-Bundles und Property-Entrys an (siehe Beispielhaftes Regelwerk).
• Sie können einen neuen Ordner erstellen, etwa rules-edit, in diesen Ordner bereits vorhandene Regeln einfügen und diese dort anpassen und testen. Anschließend verschieben Sie diese Regeln wieder in rules, um sie zu aktivieren.

Property-Entrys „backend“ und „query“

Property-Entry	Beschreibung
backend	Definiert, für welchen Storage-Bereich (UUID des Storages) die Regel gilt (siehe UUID eines Storages herausfinden).
query	Definiert, wonach das System genau sucht (siehe Enthaltene Regeln im Beispielprojekt (Beispiele für Regeln).

Die UUID eines Storages herausfinden

Öffnen Sie links in der Seitenleiste Administration und dann Root.
Öffnen Sie den Pfad:
```
Root/agorum/roi/backend
```
Klicken Sie mit der rechten Maustaste auf ein Storage.
Öffnen Sie rechts im Detailfenster die Registerkarte Objektinfo.
Kopieren Sie den Wert bei Objekt-UUID in die Zwischenablage.

Enthaltene Regeln im Beispielprojekt

Hinweis: Bei den folgenden UUIDs in den Property-Entrys backend und query handelt es sich um Beispiele. Die UUIDs unterscheiden sich auf jedem System, da das System sie durch das obige Skript bei jeder Ausführung zufällig erzeugt.

Regel	Werte/Beschreibung
2	Wert des Property-Entrys „backend“ e9f7f8c0-a3a0-11ec-a97c-02420a0a0010 Wert des Property-Entrys „query“ area:("agorum core demo storage") updatedate_date_range:[* TO NOW/MINUTE-7MINUTE] isfolder:false Regel gilt für alle Dokumente, die unter dem Bereich agorum core demo storage des Storages TSTUp6Mmdd liegen und deren letzte Änderung 7 Minuten her ist. Es werden alle Ordner ausgeschlossen. Das System legt Ordner ins Storage, wenn Sie isfolder:false entfernen. Alle Objekte, die Sie unterhalb dieser Ordner anlegen, legt das System ebenfalls ins Storage, obwohl deren Änderungsdatum bis jetzt nicht erreicht wurde. Bei dieser Regel sucht das System nach speziellen Objekten und überführt nur diese in das Storage. Zugehörige Objekte, etwa DOKUMENTTEXT oder PREVIEW oder auch Metadaten-Objekte, legt das System nicht ins Storage ab. Eine solche Regel ist sinnvoll, wenn Sie ein schnelles Storage vorziehen, damit Sie etwa Ihre CAD-Dateien schnell laden und speichern können.
3	Wert des Property-Entrys „backend“ eb154fa0-a3a0-11ec-a97c-02420a0a0010 Wert des Property-Entrys „query“ area:("agorum core demo storage") classname:(mailobject OR amailmail OR MailDocumentObject) Regel gilt für alle E-Mails, die unter dem Bereich agorum core demo storage des Storages TSTMailmdd liegen. Bei dieser Regel sucht das System nach speziellen Objekten und überführt nur diese in das Storage. Zugehörige Objekte, etwa DOKUMENTTEXT oder PREVIEW oder auch Metadaten-Objekte, legt das System nicht ins Storage ab. Eine solche Regel ist sinnvoll, wenn Sie ein schnelles Storage vorziehen, damit Sie etwa Ihre CAD-Dateien schnell laden und speichern können.
4	Wert des Property-Entrys „backend“ ed10aa70-a3a0-11ec-a97c-02420a0a0010 Wert des Property-Entrys „query“ area:("agorum core demo storage" (Kundenakte OR Lieferantenakte)) nameextension:(htm OR html) isfolder:false Regel gilt für alle HTML-Dokumente, die unter dem Bereich agorum core demo storage des Storages TSTHtmlmdd und dort innerhalb einer Kunden- oder Lieferantenakte liegen. Es werden alle Ordner ausgeschlossen.
5	Wert des Property-Entrys „backend“ edf95cc0-a3a0-11ec-a97c-02420a0a0010 Wert des Property-Entrys „query“ area:("agorum core demo storage" Lieferantenakten Lieferantenakte Belege) Regel gilt für die Belege, die unter dem Bereich agorum core demo storage des Storages TSTLiAkmdd und dort innerhalb einer Lieferantenakte liegen. Diese Regel findet auch Pfade und ordnet diese Pfade dem Storage zu. Das System nimmt auch interne Objekte, die unter diesen Pfaden liegen, mit in das Storage auf, da das System Metadaten auch auf die internen Objekte vererbt.
6	Wert des Property-Entrys „backend“ ef25a7c0-a3a0-11ec-a97c-02420a0a0010 Wert des Property-Entrys „query“ area:("agorum core demo storage" Kundenakten Kundenakte Belege) Regel gilt für die Belege, die unter dem Bereich agorum core demo storage des Storages TSTKuAkmdd und dort innerhalb einer Kundenakte liegen. Diese Regel findet auch Pfade und ordnet diese Pfade dem Storage zu. Das System nimmt auch interne Objekte, die unter diesen Pfaden liegen, mit in das Storage auf, da das System Metadaten auch auf die internen Objekte vererbt.
7	Wert des Property-Entrys „backend“ edf95cc0-a3a0-11ec-a97c-02420a0a0010 Wert des Property-Entrys „query“ storagebackend:edf95cc0-a3a0-11ec-a97c-02420a0a0010 Regel gilt für alle Belege, die im Storage mit der UUID edf95cc0-a3a0-11ec-a97c-02420a0a0010 liegen (Storage TSTLiAkmdd). Diese Belege bleiben in diesem Storage liegen, auch wenn sich der Ablageort ändert (wenn sie etwa gelöscht oder in einen anderen Bereich verschoben werden).
8	Wert des Property-Entrys „backend“ ef25a7c0-a3a0-11ec-a97c-02420a0a0010 Wert des Property-Entrys „query“ storagebackend:ef25a7c0-a3a0-11ec-a97c-02420a0a0010 Regel gilt für alle Belege, die im Storage TSTKuAkmdd liegen. Diese Belege bleiben in diesem Storage liegen, auch wenn sich der Ablageort ändert (wenn sie etwa gelöscht oder in einen anderen Bereich verschoben werden).
9	Wert des Property-Entrys „backend“ e9f7f8c0-a3a0-11ec-a97c-02420a0a0010 Wert des Property-Entrys „query“ storagebackend:e9f7f8c0-a3a0-11ec-a97c-02420a0a0010 Regel gilt für alle Belege, die im Storage TSTUp6Mmdd liegen. Diese Belege bleiben in diesem Storage liegen, auch wenn sich der Ablageort ändert (wenn sie etwa gelöscht oder in einen anderen Bereich verschoben werden).

Hinweise:

Wenn Sie das Property-Entry query zwar anlegen, aber nicht befüllen, verwendet das System eine leere Suchanfrage, die alle Objekte als Ergebnis zurückgibt.
Sollten Sie in einer Regel einen Syntax-Fehler im Property-Entry query haben, arbeitet das System alle vorherigen Regeln ab und stoppt bei der Regel, die den Fehler enthält. Alle nachfolgenden Regeln führt es nicht aus, das System fängt in diesem Falle wieder bei Regel 1 an.

Beispielhaftes Regelwerk

Das folgende Regelwerk dient als Beispiel, um die generelle Funktionsweise von Regeln zu erklären.

Erste Regel (fest vorgegeben, nicht änderbar und nicht einsehbar)
Alles gelangt in die Datenbank.

0. Regel
<Ihre eigene Konfiguration>

1. Regel
<Ihre eigene Konfiguration>

2. Regel
<Ihre eigene Konfiguration>

3. Regel
<Ihre eigene Konfiguration>

4. Regel
<Ihre eigene Konfiguration>

5. Regel
<Ihre eigene Konfiguration>

6. Regel
<Ihre eigene Konfiguration>

7. Regel
<Ihre eigene Konfiguration>

8. Regel
<Ihre eigene Konfiguration>

9. Regel
<Ihre eigene Konfiguration>

Letzte Regel (fest vorgegeben, nicht änderbar und nicht einsehbar)
MetaDb und Versionsobjekte gelangen in die Datenbank.

Hinweise:

Die erste und die letzte Regel sind fest vorgegeben. Sie sind nicht änderbar und nicht einsehbar.
Die Regeln dazwischen sind Property-Bundles und frei definierbar. Das System arbeitet sie nach ASCII-Sortierung ab.
Jede Regel enthält die zwei Property-Entrys backend und query.
Wenn mehrere Regeln für ein Storage zutreffen, führt das System immer diejenige Regel aus, die in der Reihenfolge zuletzt aufgeführt ist.
Geben Sie die Regeln stets in Ziffern an:

• Wenn Sie weniger als 10 Regeln haben, nummerieren Sie jede Regel mit einer Ziffer von 0 bis 9.
• Wenn Sie genau 10 Regeln oder mehr als 10 Regeln haben, nummerieren Sie jede Regel mit zwei Ziffern von 00 bis 99 (etwa 01, 02, 03.).

• Wenn Sie genau 100 Regeln oder mehr als 100 Regeln haben, nummerieren Sie jede Regel mit drei Ziffern von 000 bis 999 (etwa 001, 002, 003.).

Wenn Sie keine Ziffern angeben, stoppt das dazugehörige Storage.