std.GetCPObjectIdxFulltext

Dieser Job liefert dem Volltext-Indexer den indexierbaren Inhalt eines DMS-Objekts. Der Inhalt wird nicht als Datenfeld zurückgegeben, sondern serverseitig in eine temporäre Datei geschrieben; der Aufrufer erhält den Pfad und transferiert die Datei selbst zum Auslesen.

Die Datei enthält den extrahierten Volltext zusammen mit den vom Indexer benötigten Metadaten (Objekt-IDs, Pfadangaben, Indexfeldwerte, Mimetype) in einem dem Volltext-Backend bekannten Format. Quelle des Volltext-Inhalts ist die Tabelle osftcontent.

Typischer Aufrufkontext ist der Folgejob nach std.GetNextCPMessage und std.GetCPObjectInfo im CP-Lebenszyklus.

Der Job ist in der offiziellen enaio®-Standard-Engine-Übersicht (std) nicht gelistet.

1. Eingabeparameter

Name Typ Pflicht Beschreibung

ObjectID

INT

Ja

Numerische ID des DMS-Objekts, für das der Indexierungs-Input erzeugt werden soll.

ObjectType

INT

Ja

Numerische ID des Objekttyps. Wird verwendet, um die korrekten Indexfeld-Definitionen und Pfadinformationen einzubinden. Sollte mit dem tatsächlichen Objekttyp übereinstimmen — bei unbekanntem Objekttyp kann er zuvor über std.GetCPObjectInfo ermittelt werden.

Flags

INT

Ja

Reserviert; stets 0 übergeben.

2. Ausgabedateien

Name Beschreibung

Dateiliste

Pfad und Name der temporär erzeugten Indexierungs-Datei (eine Datei pro Aufruf, unter einer pro Aufruf neu erzeugten GUID). Der Aufrufer ist dafür verantwortlich, die Datei nach dem Auslesen über die normale Dateitransfer-Schicht abzuholen und freizugeben, damit der Server sie aufräumen kann.

3. Rückgabe

(INT): 0 = Job erfolgreich, sonst Fehlercode. Auch wenn für das Objekt aktuell kein Volltext-Inhalt in osftcontent vorliegt, schliesst der Aufruf erfolgreich ab — die erzeugte Datei enthält dann nur die Metadaten ohne Volltext-Block. Der Aufrufer erkennt dies und reagiert auf Anwendungsebene (typisch: Nachforderung einer Rendition über std.CreateCPMessages mit CreateRenditionMessages=true und Setzen von osftslog.flag2 = 404, siehe Wertebereich flag2).

4. Hinweise

  • Reiner Lesezugriff auf Datenbankebene — keine DB-Schreibvorgänge. Allerdings wird serverseitig eine Datei im Temp-Verzeichnis erzeugt; ein nicht abgerufenes Ergebnis hinterlässt Datei-Leichen.

  • Pro Aufruf wird eine neue Datei mit eigener GUID erzeugt — zwei aufeinanderfolgende Aufrufe für dieselbe ObjectID liefern unterschiedliche Pfade mit potenziell identischem Inhalt.

  • Der Job ist für den Volltext-Indexer-Service vorgesehen. Andere Worker-Services (z. B. der Rendition-Cache) lesen Volltext-Inhalte nicht über diesen Pfad.

5. Verwandte Jobs

  • std.GetNextCPMessage — liefert die ObjectID, die typischerweise direkt im Anschluss in diesen Job geht (Queues FULLTEXTIDX und FULLTEXTDOC)

  • std.GetCPObjectInfo — wird in der Regel direkt vorher aufgerufen, um über HasVolltextFile zu entscheiden, ob ein Volltext-Inhalt verfügbar ist und welcher Pipeline-Zweig zuständig ist

  • std.CreateCPMessages — vom Indexer aufgerufen, wenn die zurückgegebene Datei keinen Volltext-Block enthält, um eine Rendition nachzufordern

  • std.DispatchCPMessage — quittiert die zugrunde liegende CP-Message nach Abschluss der Indexierung

  • std.CPRenditionChanged — triggert eine Re-Indexierung; anschliessend wird dieser Job erneut aufgerufen, dann mit befülltem osftcontent