Das Drittsystem "PersonalEinfachGemacht" wird von Gesellschaft A, B und C eingesetzt. Das System archiviert die gesamte Personalakte eines Mitarbeiters.

Gesellschaft A möchte aufgrund von Datenschutz und Compliance ein eigenes Archiv nutzen.

Die Gesellschaften B und C werden hingegen zusammengelegt. Da die Personalverwaltung für beide Gesellschaften von einer zentralen Verwaltung ausgehen, sollen die Mitarbeiter beider Gesellschaften auch in allen Archiven gleichzeitig suchen können (siehe IndexGroup in der Tabelle).

Die A GmbH hat ein fest definiertes Feldschema, da in diesem System keine weiteren Felder mehr hinzukommen sollen. Die B und C GmbH hat ebenfalls ein fest definiertes Feldschema. Allerdings sollen im System "PersonalEinfachGemacht" neue Felder definiert werden können. Die Felder sollen dem Index (Feldwertsuche) hinzugefügt werden können. In den Feldern soll auch gesucht werden können (siehe Festes Indexfeld-Schema: Ja / Support Free Fields in der Tabelle).

Die Dokumente der Gesellschaft A sollen nach 10 Jahren automatisch gelöscht werden. Die Dokumente für die Gesellschaften B und C sollen bereits nach 7 Jahren (siehe Aufbewahrungsfrist in der Tabelle) gelöscht werden. Die Dokumente der Gesellschaft A müssen aufgrund der DSGVO versioniert werden. Die Dokumente der Gesellschaften B und C hingegen nicht (siehe Versionierung: Ja /Nein in der Tabelle).

In den Personalakten der Gesellschaft A sind Standardformulare hinterlegt, die identisch sind (Hash-Wert ist gleich). Die Größe der Formulare pro Akte ist 12 MB. Das Archiv "A Personalakte" enthält 80.000 Personalvorgänge mit durchschnittlich 5 Versionen, d.h. 400.000 gespeicherte Akten im Archiv. Bei 12 MB Formulargröße werden 4.8 TB Datenvolumen allein für Formulare benötigt. Daher wird Single Instance aktiviert, was den benötigten Speicherplatz auf 960 GB reduziert.

Das Archiv von B und C enthält ebenfalls 80.000 Vorgänge, jedoch ohne Standardformulare. Zudem gibt es aufgrund der Fusion derzeit sehr viele Zugriffe. Daher wird Single Instance nicht aktiviert. Bei jedem Zugriff mit Single-Instance wird sonst ein Hash-Nummern-Vergleich zwischen dem zu archivierenden Beleg und den bereits archivierten Belegen vorgenommen. Dies hätte Einfluss auf die Zugriffszeiten (siehe Single Instance in der Tabelle).

Bei der A GmbH sollen alte Versionen nicht über eine Feldsuche recherchierbar sein, daher können alle alten Versionen aus dem Index entfernt werden. Die alten Versionen sind dann nur noch über die Dokumenten-ID auffindbar. Da das BC-Archiv nicht versioniert wird, ist hier nichts weiter zu berücksichtigen (siehe Delete Last Version from Index in der Tabelle).

Die Gesellschaft A möchte beim Aufrufen der Personalakte immer den aktuellen Stand angezeigt bekommen (siehe Letzte Version in Query in der Tabelle). Darüber hinaus benötigt Gesellschaft A die Möglichkeit, in der erweiterten Suche auch spezifische Versionen oder alle Versionen zu laden (siehe Spezifische Version in Query in der Tabelle) . Für B und C entfallen die letzten beiden Überlegungen, da hier nicht versioniert wird.

Nachfolgend ist dargestellt, welches System welche Geschäftsfälle mit unterschiedlichen Gesellschaftsformen und der entsprechenden Anzahl an separaten Archiven am besten abbilden kann.

Im Folgenden finden Sie kurze Erläuterungen zu den genutzten Archivkonfigurationen.

xSuite Archive Prism ist ein schemafreies Archiv. Die Feldinformationen, die von einem Drittsystem übergeben werden, werden im Index automatisch mit dem mitgegebenen Datentyp angelegt. Diese Felder können auch für eine Suche genutzt werden. Die Definition eines Schemas, d.h. eines Dokumenttyps mit fest definierten Feldern, ist über den Konfigurationsknoten DocumentTypes möglich. Dabei können feste Felder definiert werden. Bei der Konfiguration kann auch festgelegt werden, dass Felder über das Drittsystem angelegt werden dürfen.

Eine Aufbewahrungsfrist (siehe Retention in der Tabelle) kann für das Archiv oder für einen Dokumenttyp festgelegt werden. Die Konfiguration ist abhängig von den Archivinhalten. Wenn innerhalb eines Archivs mehrere Dokumenttypen mit unterschiedlichen Aufbewahrungsfristen abgelegt werden, kann die Aufbewahrungsfrist auch auf Ebene der Dokumenttypen gesetzt werden.

Bei jeder Änderung eines Indexfeldes wird eine neue Version angelegt. Auch die Anlagen werden dupliziert.

Wenn "Single Instance" konfiguriert ist, werden die Anlagen der Archivdokumente bei der Versionierung nur dupliziert, wenn die Anlagen nicht gleich sind. Dies wird durch eine MD5-Hash-Prüfung sichergestellt. Die Prüfung gilt für das ganze Archiv, d.h. eine Anlage kann mehreren Archivdokumenten zugeordnet werden. Dies funktioniert nur in Verbindung mit dem Ablageformat (StorageType) FileBox.

Die Beschränkung der Indexierung auf die aktuelle Version eines Archivdokuments ist nur in Verbindung mit einer Versionierung möglich. Dokumente werden versioniert, sind aber nur über die Dokumentenreferenz auffindbar und nicht über den Index. Das spart Speicherplatz und ist daher für große Datenmengen sinnvoll.

Wenn bei der Suche immer die aktuelle Version eines Archivdokuments angezeigt werden soll, muss geprüft werden, ob dies aufgrund spezifischer Anforderungen des Drittsystems möglich ist. Hierzu muss die Index-Eigenschaft TopVersionFlag und die Trefferlisteneigenschaft ForceTopVersionFlag aktiviert werden. Diese Eigenschaft kann bei der Definition der Trefferliste im REST-Call ebenfalls gewählt werden (HitlistDescription → ForceTopVersionFlag).

Wenn bei der Suche alle Archivdokumentversionen angezeigt werden soll, muss geprüft werden, ob dies aufgrund der Anforderungen des Drittsystems möglich ist.