Varianten archivieren?

enaio®
1

ich bilde Varianten im enaio, diese sollen aber bis zu einem bestimmten Zeitpunkt auf «nicht archivierbar» bleiben. Ist der Zeitpunkt erreicht diese zu archivieren, dann kann ich immer nur die aktive Variante setzten, die nicht aktiven Varianten bleiben «nicht archivierbar». Kennt ihr eine Möglichkeit das mit enaio Boardmitteln zu lösen?
Ich habe jetzt den Workbereich voll mit nicht archivierten Varianten.
Via Talend und direkt über die DB ist es klar zu lösen, aber sollte man das nicht auch via API können?

Merci
Grüsse
Gerd

1 „Gefällt mir“
2

Hoi @Gerd_Lobmeyer, wie viele Dokumente sind es denn?

Also, wäre std.SetActiveVariant gefolgt von dms.XmlUpdate mit Options ARCHIVABLE=1 noch eine Option oder wäre das zu langwierig bzw. würde zu viele Historieneinträge produzieren?

Eine andere Option, welche allerdings viele OSIDs etc. „verbraucht“ wäre es, alle aktiven, nicht archivierten Varianten zu suchen und darüber in Schleife

  • Verweisdokumente anlegen
  • Verweisdokument archivieren
  • Verweisdokument löschen (ggf. direkt und nicht in den Papierkorb)

Ich befürchte, wenn keine dieser Ideen geeignet ist, dass nur eine DB-Aktion in Rücksprache mit OS hilft und in Zukunft alle neuen Files direkt mit ARCHIVABLE=1 angelegt werden sollten.

3

Hoi @rk,

das mit std.SetActiveVariant ist wohl der Weg, den sich dann OS gedacht hat. Ich muss das mal überlegen, da der tatsächliche Trigger die Dokumente nun zu archivieren in einem REST-Service aufschlägt und ich daraus sowieso nicht an die DB komme (habe ich zumindest nie geschafft und macht auch keinen Sinn). Das würde aber nur neue Dokumente betreffen. Für die rückwirkende Korrektur brauchts eh einen dedizierten Job. Via der DB ist das dann aus meiner Sicht einfacher.
Ich habe sowieso schon sehr viel mit Varianten in der DB rumgespielt. Beim Importieren von Varianten passieren immer wieder Fehler, die dazu führen, dass z.B. mehrere Varianten eines Dokumentes die selbe Versionsnummer erhalten usw. Dazu habe ich schon passende Jobs entwickelt, die das korrigieren.

4

Spräche im dedizierten Job etwas gegen die Schleife über temporäre Verweisdokumente? Das fände ich „sauberer“ als SetActiveVariant auszulösen und danach rückgängig zu machen.

5

@Gerd_Lobmeyer @rk

Ich habe es kurz in einem Testscript ausprobiert.
Es funktioniert mit CHECKEXISTENCE=0;ARCHIVABLE=1.

from ecmind_blue_client.client import Job
from ecmind_blue_client.tcp_pool_client import TcpPoolClient
from XmlElement import XmlElement as X

tcp_client = TcpPoolClient(
    '127.0.0.1:4000:1', 'TestClient', 'ecmind', 'ecmind', True)

update = {
    'Archive': {
        'ObjectType': {
            "@internal_name": "ClientContract",
            "Object": {
                "@object_id": 422,
                "Fields": {
                }
            }
        }
    }
}

xml = X.from_object(node_name='DMSData', data=update)

job = Job("dms.XmlUpdate", Flags=0, XML=xml,
          Options='CHECKEXISTENCE=0;ARCHIVABLE=1')

tcp_client.execute(job)
1 „Gefällt mir“
6

@uw
Was genau funktioniert mit deinem Script? Ist das eine ID eines inactiven Variantendoks?

7

Ja, 422 ist hier eine inaktive Variante.

8

Okay, dann ist es klar. Somit kann muss man die IDs der Varianten ermitteln und hiermit auf archivierbar setzten. Meiner Erfahrung nach ist es aber mühsam die Varianten IDs via ResultList zu ermitteln. Geht aber.
Merci!

9

@Gerd_Lobmeyer Um zumindest nur die Dokumente mit Varianten zu ermitteln könntest das Systemfeld OBJECT_SEARCHFLAGS verwenden.

    "ConditionObject": {
        "@internal_name": "ClientContract",
        "FieldCondition": {
          "@internal_name": "OBJECT_SEARCHFLAGS",
          "@operator": "=",
          "@system": 1,
          "Value": 2048
        }
    }

Siehe Server-API auf Seite 82-83.