std.IndexDataChanged

Dieser Job teilt dem Indexserver mit, dass sich die Indexdaten eines Objekts geändert haben.

Der Job ist ein serverinterner Folgejob und wird im Allgemeinen nicht von außen aufgerufen. Es gibt zwei Auslöserpfade:

Der Job ändert die Indexdaten nicht selbst — diese wurden bereits durch den vorangehenden Schreibvorgang geschrieben. Sowohl das Server-Event KernelBeforeJob als auch KernelAfterJob (siehe Server-Events) werden für diesen Job daher erst nach der eigentlichen Metadatenänderung ausgelöst.

Die geänderten Metadaten werden dem Job nicht als Parameter übergeben (siehe Eingabeparameter — nur Action, dwObjectID, dwObjectType usw.). Ein Server-Event-Skript, das auf die Änderung reagieren möchte, muss die aktuellen Metadaten daher selbst nachladen.

1. Eingabeparameter

Name Typ Pflicht Beschreibung

Flags

INT

Ja

1 = in der DB-Tabelle objectXXX wird das Feld osowner geändert;
sonst wird osowner nicht verändert.

Action

INT

Ja

Aktion, die mit dem Objekt ausgeführt wurde (siehe Aktions-IDs unten)

dwObjectID

INT

Ja

ID des Objekts

dwObjectType

INT

Ja

Typ des Objekts

Info

STRING

Ja

Information, die in die DB-Tabelle osobjhist geschrieben wird

GUID

STRING

Ja

Eindeutiger Schlüssel für die DB-Tabelle osobjhist

2. Aktions-IDs

ID Beschreibung ID Beschreibung

1

Elektronische Signatur

28

Objekt wiederhergestellt

2

Objekt angelegt

29

Objekt endgültig gelöscht

3

Indexdaten geändert

30

Kenntnisnahme bestätigt

4

Dokument geändert

31

Objektinfo

5

Dokument archiviert

32

Besitzer des Objektes gewechselt

6

Dokument gelöscht

33

Variante aktiviert

7

Dokument ausgegeben

34

Variante deaktiviert

8

Dokumentstatus geändert

35

Variante gelöscht

9

Dokumentstatus geändert

36

Variante angelegt

10

Dokument erzeugt

37

Typenlosem Objekt Typ zugewiesen

11

Verknüpfung über Notizen

38

Dokument aus Ablage verschoben

12

Verknüpfung aufgelöst

39

Verweiskopie erstellt

13

SQL-Abfrage

40

Benutzerinfo

14

SQL-Kommando

41

Retentionzeit gesetzt

15

Elektronische Signatur

42

Dokument dearchiviert

16

Signiertes Dokument gelöscht

43

Dokumenttyp geändert

17

Version angelegt

44

Vorschauanmerkung erstellt

18

Version gelöscht

45

Vorschauanmerkung geändert

19

Wiederhergestellt aus Version

46

Vorschauanmerkung gelöscht

20

Volltextanfrage

47

Kenntnisnahme durch Passwort bestätigt

21

Dokument verschoben

48

Freigabe erstellt

22

Register verschoben

49

Freigabe geändert

23

Ordner zusammengeführt

50

Freigabe gelöscht

24

Ordner zusammengeführt

51

Aus Kopie erstellt

25

Register zusammengeführt

52

Aus einem Standort entfernt

26

Register zusammengeführt

53

Status 'aktive Variante' geändert

27

Objekt zum Löschen vorgemerkt

54

Weitere Variante angelegt

3. Übliche Aktionen (Beispiel)

In der Praxis tritt bei diesem Job nur ein kleiner Teil der oben gelisteten Aktionen auf. Beispielhaft die in einer Produktivumgebung tatsächlich beobachteten Werte mit dem Job, der sie typischerweise auslöst:

Action Bedeutung Auslösender Job

3

Indexdaten geändert

dms.XMLUpdate, dms.XMLImport (Update-Zweig)

2

Objekt angelegt

dms.XMLInsert, dms.XMLImport (Insert-Zweig)

9

Dokumentstatus geändert

Statuswechsel beim Ablegen bzw. Zurückschreiben eines Dokumentes (std.StoreInWork, std.StoreInCacheByID usw.)

7

Dokument ausgegeben

Anforderung eines Dokumentes zur Bearbeitung (std.StoreInCache mit schreibendem DocState)
Die Werte wurden per Job-Monitoring beobachtet. Da der enaio® Windows Client den Job selbst aufruft (siehe Hinweis am Seitenanfang), kann eine so beobachtete Ausführung sowohl aus dem serverinternen Pfad der XML-Jobs als auch direkt aus dem Client stammen.

4. Auslösung durch die DMS-XML-Jobs

Ob ein XML-Job den Folgejob auslöst, hängt allein davon ab, ob im übergebenen XML mindestens ein <Field> enthalten ist (verifiziert an enaio® 12.0):

Fall Ausgelöst Action

dms.XMLUpdate, Feld mit geändertem Wert

ja

3 (Indexdaten geändert)

dms.XMLUpdate, Feld mit identischem Wert

ja

3 (Indexdaten geändert)

dms.XMLUpdate ohne jedes Feld (<Object/> ohne <Fields>)

nein

—

dms.XMLImport, Update-Zweig, identische Werte

ja

3 (Indexdaten geändert)

dms.XMLImport, Insert-Zweig

ja

2 (Objekt angelegt)

dms.XMLInsert

ja

2 (Objekt angelegt)
Der Server vergleicht die übergebenen Werte nicht mit dem Bestand. Ein identisch übertragener Wert zählt als Schreibvorgang und löst den Folgejob samt Historieneintrag in osobjhist aus. Stumm bleibt nur ein Request ganz ohne Feld — unveränderte Felder aus dem XML weglassen ist damit die einzige Möglichkeit, den Historieneintrag zu vermeiden.

5. Als Hook verwenden

Ein eigenes Server-Event für Indexdatenänderungen existiert nicht. Für die serverseitige Reaktion auf eine Indexdatenänderung stehen zwei Wege offen:

  • KernelBeforeJob bzw. KernelAfterJob an diesen Job binden (siehe Indexdatenänderung abfangen). Beide Skripte laufen hier erst nach der Änderung.

  • OnObjectHistoryEntry (5011) verwenden. Das Event ist nicht job-gebunden und feuert bei jedem Historieneintrag.

Ein Hook an dms.XMLUpdate deckt nur den API-Pfad ab und verpasst jede Änderung, die der enaio® Windows Client vornimmt. Nur std.IndexDataChanged liegt auf beiden Schreibpfaden.

6. Rückgabe

(INT): 0 = Job erfolgreich, sonst Fehlercode.